BÁO cáo đồ án môn học NHẬP môn CÔNG NGHỆ PHẦN mềm đề tài tìm hiểu về các quy trình phát triển phần mềm
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2 MB, 22 trang )
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
BỘ MÔN CÔNG NGHỆ PHẦN MỀM
BÁO CÁO ĐỒ ÁN
MÔN HỌC NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
Đề tài
Tìm hiểu về các quy trình phát triển phần mềm
Giảng viên hướng dẫn: Thầy Huỳnh Quyết Thắng
Sinh viên thực hiện :
1.
Đặng Việt Hùng
2.
Nguyễn Văn Hiệp
Lớp Công nghệ phần mềm K51
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
MỤC LỤC
Giới thiệu………………………………………………………………………………………………………………………..3
I.
Các quy trình phát triển phần mềm chuẩn ..................................................................... 5
I.1
Nội dung ................................................................................................................................. 5
I.2
Chi tiết tìm hiểu ..................................................................................................................... 5
I.2.1
Qui trình là gì?................................................................................................................ 5
I.2.2
SEP, ISO, CMM/CMMI .................................................................................................... 6
I.2.3
Các mô hình SEP ............................................................................................................ 6
II. Tìm hiểu quy trình áp dụng thực tế tại các công ty phần mềm .......................................12
II.1
Nội dung ............................................................................................................................... 12
II.2
Chi tiết thực hiện ................................................................................................................. 12
II.2.1
Giới thiệu GoldeSoft ..................................................................................................... 12
II.2.2
Khảo sát quy trình phát triển phần mềm tại GoldenSoft.......................................... 12
II.2.3
Quy trình phát triển phần mềm tại một số công ty phần mềm khác ...................... 16
III. Nhận xét đánh giá………… ...........................................................................................17
IV. Tài liệu tham khảo…………. ..........................................................................................18
2|P ag e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
Giới thiệu
Đồ án môn học Nhập môn công nghệ phần mềm
Giảng viên hướng dẫn: PGS.TS Huỳnh Quyết Thắng
1.
Danh sách nhóm
STT
1
2
Họ tên
Đặng Việt Hùng
Nguyễn Văn Hiệp
2.
Đề tài
MSSV
20061444
20061208
Lớp
CNPM A K51
CNPM A K51
Tìm hiểu về các quy trình phát triển phần mềm và thực tế ứng dụng tại các công ty
phần mềm / công ty tin học làm việc trên địa bàn Hà nội
-
Công việc cụ thể
Các quy trình chuẩn: cơ sở lí thuyết, phân loại, tìm hiểu chung
Tìm hiểu và thu thập các tài liệu tham khảo tiêu biểu liên quan đến nội dung của bài tập
lớn
Một số quy trình phát triển phần mềm thông dụng: CMM, Prototyping, RAD, RUP, ...
Chú ý SCRUM : chia nhỏ thành các module
Các công cụ hỗ trợ triển khai các quy trình
Thực tế ứng dụng tại các công ty (trên địa bàn Hà Nội): khảo sát thực tế, phỏng vấn,
đánh giá
Bài học kinh nghiệm và kết luận
3|P ag e
Đồ án môn học Nhập môn công nghệ phần mềm
3.
Lớp CNPM K51
Đề cương nghiên cứu
STT
Nội dung
Thời hạn
1
- Tìm
Tuần 9
10/03
2
- Tìm hiểu, thu thập các tài liệu tham khảo liên
quan đến quy trình phát triển phần mềm
hiểu các quy trình chuẩn
Cơ sở lý thuyết
Phân loại
Tìm hiểu chung
Kết quả
cần đạt
Phân
công
nhóm
Cả nhóm
Tuần 10
17/03
Cả nhóm
Tuần 11,
12
31/04
Cả nhóm
Tuần 13
07/04
Cả nhóm
- Một số quy trình thông dụng
CMM
Prototyping
RAD
RUP
SCRUM
- Các công cụ hỗ trợ triển khai các quy trình
3
- Thực tế ứng dụng tại các công ty trên địa bàn Hà
Nội (công ty phần mềm GoldenSoft)
Khảo sát thực tế
Phỏng vấn
Đánh giá
- Công ty cổ phần phần mềm Golden Soft
Giám đốc: KS Vũ Hồng Lĩnh
Địa chỉ: Số 5-Bắc Hồng-Khương TrungThanh Xuân-Hà Nội
Điện thoại: 0947796485
4
- Tổng kết bài học kinh nghiệm, kết luận
- Viết báo cáo
4|P ag e
Đồ án môn học Nhập môn công nghệ phần mềm
I.
Các quy trình phát triển phần mềm chuẩn
I.1
-
Nội dung
Tìm hiểu các quy trình phát triển phần mềm chuẩn
-
Lớp CNPM K51
Cơ sở lý thuyết
Phân loại
Tìm hiểu chung
Một số quy trình thông dụng
-
CMM
Prototyping
RAD
RUP
SCRUM
Các công cụ hỗ trợ triển khai các quy trình
I.2
Chi tiết tìm hiểu
Cũng như mọi ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan
trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên
trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công
việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự
án.
Có thể nói qui trình phát triển/xây dựng phần mềm (Software Development/Engineering
Process - SEP) có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và
năng suất cao, điều này có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần
mềm củng cố và phát triển cùng với nền công nghiệp phần mềm đầy cạnh tranh.
I.2.1 Qui trình là gì?
Qui trình có thể hiểu là phương pháp thực hiện hoặc sản xuất ra sản phẩm. Tương tự
như vậy, SEP chính là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm.Thông
thường một qui trình bao gồm những yếu tố cơ bản sau:
-
Thủ tục (Procedures)
Hướng dẫn công việc (Activity Guidelines)
Biểu mẫu (Forms/templates)
Danh sách kiểm định (Checklists)
Công cụ hỗ trợ (Tools)
Với các nhóm công việc chính:
5|P ag e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
Đặc tả yêu cầu (Requirements Specification): chỉ ra những “đòi hỏi” cho cả các yêu cầu
chức năng và phi chức năng.
Phát triển phần mềm (Development): tạo ra phần mềm thỏa mãn các yêu cầu được chỉ
ra trong “Đặc tả yêu cầu”.
Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất ra đáp ứng
những “đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”.
Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của khách hàng.
Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những
cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình
khác nhau. Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng.
I.2.2 SEP, ISO, CMM/CMMI
Vấn đề được đặt ra là làm thế nào cải tiến qui trình để cải thiện chất lượng và năng
suất?
Câu trả lời chính là qui trình khung (Process Framework - PF). PF sẽ chỉ ra những yêu
cầu mà một qui trình phải đáp ứng tùy theo mỗi mức độ. PF không chỉ ra bất kỳ một qui trình
cụ thể nào mà chỉ đưa ra những yêu cầu ở mỗi mức độ trưởng thành khác nhau của qui trình
phải đạt được. Đây chính là những hướng dẫn cho các hoạt động cải tiến để nâng mức độ
trưởng thành từ thấp lên cao.
Có nhiều PF, nhưng phổ biến nhất là ISO và CMM (Capability Maturity Model) được các
tổ chức thế giới công nhận. ISO nhắm chung đến nhiều loại tổ chức cả sản xuất lẫn dịch vụ,
trong khi CMM được dành riêng cho các tổ chức phát triển phần mềm.
Đối với phần mềm, ISO chỉ ra mức độ chất lượng yêu cầu tối thiểu mà một SEP phải đạt
(ISO certified) và việc cải tiến qui trình được thực hiện thông qua qui trình kiểm định, trong khi
CMM bao gồm những thực tiễn tốt nhất (best practices) được tập hợp rút tỉa từ rất nhiều tổ
chức phát triển phần mềm khác nhau và chúng được tổ chức thành 5 mức độ trưởng thành
khác nhau (Level 1 - Initial, Level 2 - Repeatable, Level 3 - Defined, Level 4 - Managed, Level 5
- Optimizing).
Ngày nay, phần mềm không đứng riêng một mình mà thường là một bộ phận trong hệ
thống hoàn chỉnh. Do đó, CMMI (Capability Maturity Model Integration) ra đời hướng đến các
qui trình cho việc xây dựng cả hệ thống, bao gồm cả việc tích hợp để xây dựng và bảo trì toàn
bộ hệ thống.
I.2.3 Các mô hình SEP
Mô hình SEP còn được gọi là chu trình hay vòng đời phần mềm (SLC - Software Life
Cycle). SLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình
phát triển phần mềm.
Có khá nhiều mô hình SLC khác nhau, trong đó một số được ứng dụng khá phổ biến
trên thế giới:
-
Các mô hình một phiên bản (Single-version models)
• Mô hình Waterfall (Waterfall model)
• Mô hình chữ V (V-model)
-
Các mô hình nhiều phiên bản (Multi-version models)
• Mô hình mẫu (Prototype)
• Mô hình tiến hóa (Evolutionary)
• Mô hình lặp và tăng dần (Iterative and Incremental)
6|P ag e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
• Mô hình phát triển ứng dụng nhanh (RAD)
• Mô hình xoắn (Spiral)
a.
Mô hình Waterfall
Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau như được mô tả trong Hình 1.
Hình 1. Mô hình Waterfall
Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác
định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần
mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài
liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification),
trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi
những người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các
hoạt động tiếp theo cho đến cuối dự án.
Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra “làm
thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng
yêu cầu trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện
thực để đáp ứng yêu cầu đó.
Hiện thực và kiểm thử từng thành phần (Coding and Unit Test): là giai đoạn hiện thực
“làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”.
Kiểm thử (Test): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao
gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một
khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham
gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu
của họ hay không.
Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt, cấu hình và
huấn luyện khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát
triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc
điểm của hệ thống).
Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những
7|P ag e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
giai đoạn trước và phải quay lại để sửa chữa. Đây chính là kiểu waterfall dạng lặp (Iterative
Waterfall) và được minh hoạ trong Hình 1.
b.
Mô hình chữ V
Trong mô hình Waterfall, kiểm thử được thực hiện trong một giai đoạn riêng biệt. Còn
với mô hình chữ V, toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau: phát
triển và kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng
như được minh họa trong Hình 2.
Hình 2. Mô hình chữ V
Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song
song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. Ví dụ,
các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song
với các hoạt động phân tích và thiết kế hệ thống.
c.
Mô hình mẫu (Prototype)
Hình 3. Mô hình mẫu
Mô hình mẫu (prototype) được minh hoạ trong Hình 3. Trong đó, qui trình được bắt đầu
bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả phía phát triển lẫn khách hàng
nhằm định ra mục tiêu tổng thể của hệ thống phần mềm sau này, đồng thời ghi nhận tất cả
những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ.
8|P ag e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua
prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ
thống phần mềm. Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội
ngũ phát triển thông hiểu hơn những gì cần được phát triển.
Tiếp theo sau giai đoạn làm prototype này có thể là một chu trình theo mô hình
waterfall hay cũng có thể là mô hình khác.
Chú ý, prototype thường được làm thật nhanh trong thời gian ngắn nên không được xây
dựng trên cùng môi trường và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự
sau này. Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó.
d.
biệt:
Mô hình tiến hóa (Evolutionary)
Mô hình này thực sự cũng là một dạng dựa trên mô hình mẫu, tuy nhiên có sự khác
Mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau.
Những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng
trong những phiên bản sau.
Hình 4 minh họa mô hình tiến hóa, cho thấy một số phần của hệ thống phần mềm có
thể đuợc xây dựng sớm ngay từ giai đoạn thực hiện phân tích yêu cầu và thiết kế.
e.
Mô hình lặp và tăng dần (Iterative and Incremental)
Mô hình lặp và tăng dần có lúc được hiểu là một. Tuy nhiên, ta có thể phân biệt ít nhiều
sự khác biệt.
Trước tiên, hai mô hình này đều có điểm giống nhau là đều dựa trên tinh thần của mô
hình tiến hóa, và có thêm đặc điểm nhắm đến việc cung cấp một phần hệ thống, để khách
hàng có thể đưa vào sử dụng trong môi trường hoạt động sản xuất thực sự, mà không cần chờ
cho đến khi toàn bộ hệ thống được hoàn thành (trong mô hình mẫu hay tiến hóa, các phiên
bản mẫu hay trung gian đều không nhắm đến đưa vào vận hành thực sự cho khách hàng, trừ
phiên bản cuối cùng).
Để khách hàng có thể sử dụng, mỗi phiên bản đều phải được thực hiện như một qui
trình đầy đủ các công việc từ phân tích yêu cầu với khả năng bổ sung hay thay đổi, thiết kế,
hiện thực cho đến kiểm nghiệm và có thể xem như một qui trình (chu trình) con. Các chu trình
con có thể sử dụng các mô hình khác nhau (thông thường là waterfall). Hình 5 minh họa hai mô
hình này, trong đó mỗi chu trình con là một waterfall nhỏ.
9|P ag e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
Hình 5.
Mục tiêu của phiên bản đầu tiên là phát triển phần lõi và nhóm các chức năng quan
trọng. Sau mỗi phiên bản được đưa vào sử dụng, các kết quả đánh giá sẽ được phản hồi và lập
kế hoạch cho chu trình con của phiên bản tiếp theo để thực hiện:
Những thay đổi cho phiên bản trước đó nhằm đáp ứng nhu cầu khách hàng tốt hơn
Có thể thêm những chức năng hoặc đặc điểm bổ sung
Sự khác nhau giữa hai mô hình tăng dần và lặp có thể được hiểu đơn giản như sau (so
với sản phẩm được hoàn thành trong chu trình con trước):
Mô hình tăng dần (Incremental): thêm chức năng vào sản phẩm (xem minh hoạ Hình
6).
Mô hình lặp (Iterative): thay đổi sản phẩm (xem minh họa Hình 6)
Một SEP có thể kết hợp cả hai mô hình lặp lẫn tăng dần, chẳng hạn RUP (Rational
Unified Process).
f.
Mô hình phát triển nhanh (RAD)
Mô hình phát triển nhanh (RAD - Rapid Application Development) chính là mô hình tăng
dần với chu kỳ phát triển cực ngắn. Để đạt được mục tiêu này, RAD dựa trên phương pháp
phát triển trên cơ sở thành phần hóa hệ thống cùng với việc tái sử dụng các thành phần thích
hợp. RAD thích hợp cho những hệ thống quản lý thông tin.
g.
Mô hình xoắn (Sprial)
Mô hình này được xây dựng bởi Barry Boehm, đặt trọng tâm phân tích rủi ro và xem xét
kế hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên
bản chất của mô hình lặp.
Trong mô hình này, việc phân tích và giải quyết những vấn đề có rủi ro cao tập trung
vào thiết kế từng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung
chung.
Hình 7 minh họa mô hình này với các giai đoạn lặp theo chu kỳ xoay vòng, trong đó mỗi
chu kỳ bao gồm 4 giai đoạn con như sau:
Analysis: Xác định mục tiêu chất lượng cho sản phẩm được thực hiện, đồng thời xác
định sự lựa chọn mua, tái sử dụng hay tự thiết kế và hiện thực các thành phần của hệ
thống.
Evaluation: Phân tích sự lựa chọn và các rủi ro có thể xảy ra. Việc này được thực hiện
bởi nhiều hoạt động khác nhau thông qua làm mẫu hay mô phỏng.
Development: Phát triển và kiểm định sản phẩm ở mức tiếp theo dựa trên kết quả
định hướng được chỉ ra trong giai đoạn con số 2 (phân tích rủi ro)
Planing: Kiểm duyệt tất cả các kết quả của các giai đoạn con xảy ra trước đó và lập kế
hoạch cho chu kỳ lặp tiếp theo.
10 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Hình 7.
11 | P a g e
Lớp CNPM K51
Đồ án môn học Nhập môn công nghệ phần mềm
II.
Tìm hiểu quy trình áp dụng thực tế tại các công ty phần mềm
II.1
-
Nội dung
Tìm hiểu quy trình áp dụng thực tế tại các công ty phần mềm
-
Cụ thể khảo sát tại công ty Golden Soft
Lớp CNPM K51
II.2
Chi tiết thực hiện
Tiếp tục thực hiện theo đề cương đồ án, nhóm đã tiến hành khảo sát, tìm hiểu thực tế
áp dụng các quy trình phát triển phần mềm tại các công ty trên địa bàn Hà Nội.
Cụ thể nhóm đã khảo sát tại các công ty sau:
Trực tiếp khảo sát tại công ty cổ phần phần mềm vàng GoldenSoft
Tìm hiểu thông tin về quy trình tại các công ty
o FPT
o Tinh vân
o Sóc bay
o ..
II.2.1 Giới thiệu GoldenSoft
Công ty GoldenSoft là công ty hàng đầu trong lĩnh vực phát triển các hệ thống phần
mềm hướng dịch vụ. Công ty là một phần trong quá trình hiện thực hóa đề án xây dựng chính
phủ điện tử.
Một số hệ thống được GoldenSoft nghiên cứu, triển khai, phát triển; hiện đang hỗ trợ
hiệu quả cho các cơ quan quản lý nhà nước trong nhiều lĩnh vực, đặc biệt về bất động sản
-
Hệ thống cấp và quản lý giấy chứng nhận chuyên gia môi giới định giá bất động sản
Hệ thống cấp và quản lý giấy chứng nhận quyền sử dụng đất, quyền sở hữu nhà ở và
tài sản khác gắn liền với đất
Hệ thống sàn bất động sản điện tử Việt Nam
Hệ thống website ban chỉ đạo trung ương về các vấn đề nhà ở và bất động sản
..
Công ty GoldenSoft hiện có 20 nhân viên, đều là kỹ sư tốt nghiệp khoa CNTT ĐHBKHN.
II.2.2 Khảo sát quy trình phát triển phần mềm tại GoldenSoft
Hiện tại GoldenSoft đang áp dụng một quy trình SCRUM, theo mô hình linh hoạt. Do đặc
thù đội phát triển số lượng nhỏ (có 3 team, mỗi team khoảng 7 thành viên), nên việc áp dụng
quy trình SCRUM giúp việc phát triển phần mềm trở nên nhanh chóng và dễ dàng.
a.
Giới thiệu SCRUM
Đó là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile). Công nghệ
Agile cung cấp rất nhiều phương pháp luận, quy trình và các thực nghiệm để cho việc phát triển
phần mềm trở nên nhanh chóng và dễ dàng. Scrum theo mô hình này.
Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường mất
2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự thay đổi và
12 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
yêu cầu tốc độ cao.
Một sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống. Các
tác vụ trong sprint được chia ra thành các danh mục, đội làm việc sẽ phát triển và đánh giá lại
sao cho đạt được mục đích ban đầu trong khoảng thời gian đề ra.
Thành phần chính quan trọng của scrum là các role (vai trò) và các cuộc trao đổi đánh
giá. Có các role chính là:
Product Owner: là người làm những công việc bắt đầu cho dự án, tạo ra các yêu cầu
trong quá trình phát triển dự án. Phân tích mục tiêu, giải phóng các kế hoạch.
Scrum Master: họ phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội
làm việc và loại bỏ các trở ngại.
Đội làm việc ở scrum: thường từ 5-9 người, tùy theo quy mô dự án nó có thể có rất
nhiều đội, nhiều người tham gia. Sẽ không có những lập trình viên (programmer), người
thiết kế (designer), kiểm thử viên (tester),… thường thấy ở các dự án phần mềm truyền
thống. Các đội làm việc sẽ tiến hành cài đặt các chức năng được mô tả trong bản yêu
cầu. Họ tự quản lý, tổ chức và điều chỉnh đội làm việc của mình sao cho hiệu quả lớn
nhất. Tất cả các thành viên có ảnh hưởng như nhau đến sự thành công hoặc thất bại
của toàn bộ hệ thống hoặc các hệ thống nhỏ hơn trong đó.
Có 2 pha là lập kế hoạch và kết thúc sẽ xác định các tiến trình cần thiết gồm các dữ liệu
đầu vào đầu ra thật đầy đủ. Có một số vòng lặp phát triển trong pha kế hoạch. Kế hoạch lập ra
ban đầu chỉ là tương đối và sẽ có sự điều chỉnh.
b.
So sánh scrum và các quy trình phần mềm truyền thống
Với các phương pháp truyền thống, việc lập kế hoạch dự án (xác định những việc cần
làm và thời gian kế thúc) dựa trên kinh nghiệm chứ không phải là môi trường làm trực tiếp. Và
so với kế hoạch đó khi bắt tay vào xây dựng thì thường có độ trễ nhất định.
Scrum và quy trình thác nước (waterfall), xoắn ốc (spiral)
13 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
yêu cầu tốc độ cao.
Một sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống. Các
tác vụ trong sprint được chia ra thành các danh mục, đội làm việc sẽ phát triển và đánh giá lại
sao cho đạt được mục đích ban đầu trong khoảng thời gian đề ra.
Thành phần chính quan trọng của scrum là các role (vai trò) và các cuộc trao đổi đánh
giá. Có các role chính là:
Product Owner: là người làm những công việc bắt đầu cho dự án, tạo ra các yêu cầu
trong quá trình phát triển dự án. Phân tích mục tiêu, giải phóng các kế hoạch.
Scrum Master: họ phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội
làm việc và loại bỏ các trở ngại.
Đội làm việc ở scrum: thường từ 5-9 người, tùy theo quy mô dự án nó có thể có rất
nhiều đội, nhiều người tham gia. Sẽ không có những lập trình viên (programmer), người
thiết kế (designer), kiểm thử viên (tester),… thường thấy ở các dự án phần mềm truyền
thống. Các đội làm việc sẽ tiến hành cài đặt các chức năng được mô tả trong bản yêu
cầu. Họ tự quản lý, tổ chức và điều chỉnh đội làm việc của mình sao cho hiệu quả lớn
nhất. Tất cả các thành viên có ảnh hưởng như nhau đến sự thành công hoặc thất bại
của toàn bộ hệ thống hoặc các hệ thống nhỏ hơn trong đó.
Có 2 pha là lập kế hoạch và kết thúc sẽ xác định các tiến trình cần thiết gồm các dữ liệu
đầu vào đầu ra thật đầy đủ. Có một số vòng lặp phát triển trong pha kế hoạch. Kế hoạch lập ra
ban đầu chỉ là tương đối và sẽ có sự điều chỉnh.
b.
So sánh scrum và các quy trình phần mềm truyền thống
Với các phương pháp truyền thống, việc lập kế hoạch dự án (xác định những việc cần
làm và thời gian kế thúc) dựa trên kinh nghiệm chứ không phải là môi trường làm trực tiếp. Và
so với kế hoạch đó khi bắt tay vào xây dựng thì thường có độ trễ nhất định.
Scrum và quy trình thác nước (waterfall), xoắn ốc (spiral)
13 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
Mô hình thác nước chia dự án phần mềm gồm các giai đoạn: đặc tả yêu cầu, thiết kế hệ
thống, cài đặt (lập trình), kiểm thử và bảo trì. Quy trình này dễ quản lý nhưng lại kém
linh hoạt và không hiệu quả bởi nếu có sự thay đổi ở các giai đoạn sau sẽ ảnh hưởng rất
lớn đến các giai đoạn trước.
Quy trình xoắn ốc chia dự án thành các giai đoạn: lập kế hoạch, phân tích rủi ro, giao
tiếp khách hàng, đánh giá lại, sản xuất và phân phối. Nó vẫn chưa được sử dụng rộng
rãi.
Các quy trình phần mềm truyền thống thường có quá khá nhiều giai đoạn, nhiều thành
phần, yếu tố trong suốt thời gian phát triển sản phẩm. Phương pháp scrum tránh điều này.
Đặc
điểm Waterfall Spiral Scrum
c.
-
Áp dụng scrum tại GoldeSoft
Triển khai SCRUM tại GoldenSoft trải qua 10 bước như sau:
Bước 1: Thu nhập các đặc điểm của sản phẩm (backlog) trong đơn đặt hàng. Đây là
bước quan trọng nhất. Lập nên các đội làm việc, có thể tách thành các đội nếu cần thiết
và thảo luận với nhau về nghiệp vụ cần làm. Sau đó bổ nhiệm một người vào vị trí
Product owner, người này có khả năng trao đổi, bao quát công việc tốt, biết sắp xếp ưu
tiên đúng thứ tự các nhiệm vụ. Sau đó tự tổ chức lại đội làm việc, đề xuất ra vị trí
Scrum master và thảo luận chi tiết các yêu cầu, sắp xếp chúng theo thứ tự ưu tiên.
Bước 2: Ước lượng đầy các yêu cầu về sản phẩm đầu ra. Có ước lượng ở mức độ cao,
chia sản phẩm thành số lượng các danh mục backlog. Tuy nhiên số lượng sẽ không
chính xác được, về sau chúng sẽ được bổ sung. Tiếp đến là ước lượng chi tiết từng
backlog, ước lượng số lượng các đội làm việc.
Bước 3: Lên kế hoạch phát triển các vòng lặp sprint. Sử dụng các cuộc trao đổi kế
hoạch phát triển sprint với tất cả các thành viên. Xác định khoảng thời gian sẽ phát triển
14 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
một sprint (thường là 30 ngày), mục tiêu của sprint là gì, sẽ đạt được gì, phân tích các
yêu cầu của sprint một cách rõ ràng.
d.
Bước 4: Lên kế hoạch phát triển các nhiệm vụ của sprint. Tất cả mọi người sẽ xác định
ngân sách của sprint đó, chia các đặc điểm thành các tác vụ nhỏ hơn, ước lượng số thời
gian sẽ làm từng task (giờ), hoàn tất các yêu cầu và nhận dạng task quan trọng.
Bước 5: Tạo ra không gian làm việc cộng tác cho tất cả mọi người. Thường sử dụng
bảng trắng để vẽ nên những vấn đề cần thiết cho tất cả mọi người cùng đánh giá.
Bước 6: Các thành viên bắt tay xây dựng từng sprint. Lập trình, kiểm thử và điều chỉnh
thời gian để có hiệu quả tốt nhất. Đôi khi có thể hủy bỏ một sprint và quay lại với việc
lập kế hoạch khác.
Bước 7: Mọi người báo cáo kết quả để tiếp tục làm việc. Các báo cáo tập trung vào các
vấn đề: đạt được những gì so với lần trao đổi trước; sẽ hoàn thành những gì trong lần
trao đổi tiếp theo; có những trở ngại gì trong quá trình làm việc v.v.
Bước 8: Tổng hợp kết quả trên biểu đồ. Đây là bức tranh tổng quát về những việc đã
làm được, những việc chưa làm được, thời gian ước lượng còn lại và có thể điều chỉnh
lại.
Bước 9: Xem xét để hoàn tất. Khi các thành viên nói công việc đã hoàn thành có nghĩa
là mọi thay đổi sẽ bị từ chối, đẩy lại cho vòng lặp sau.
Bước 10: Đánh giá, phản ánh và lặp lại. Có các cuộc họp đánh giá lại sprint của các
thành viên. Sẽ trình bày những gì đạt được, phản hồi của khách hàng, xét thời hạn của
sprint. Nhìn lại biểu đồ ở bước 8 để xác định lại toàn bộ hệ thống và tiếp nhận những
đóng góp, bổ sung để đưa tiếp vào các vòng lặp sprint tiếp theo.
Các điểm mạnh của quy trình SCRUM áp dụng tại GoldenSoft
Điểm mạnh nhất đó là việc linh hoạt, dự án không được cố định từ đầu về thời gian
hoàn thành hay những yêu cầu mà nó sẽ được xác định khi phát triển thực tế.
Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác định linh hoạt
theo môi trường sử dụng thực tế.
Thời gian biểu linh hoạt: có thể muộn hoặc sớm hơn so với kế hoạch ban đầu.
Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp. Khả năng trao đổi giữa
khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao.
Tốc độ phát triển nhanh, tiết kiệm thời gian. Việc chuẩn bị hành động cho những thay
đổi trong quá trình phát triển tốt hơn vì hầu như hàng ngày luôn có những buổi họp đánh giá
lại ở những vòng lặp phát triển.
Các bugs (lỗi) và các vấn đề được phát hiện sớm hơn rất nhiều so với các phương pháp
truyền thống bởi vì khách hàng được tham gia đánh giá rất nhiều và đầu ra của sản phẩm rất
nhanh. Và khi đi sai hướng, có thể hủy ngay sprint đó để quay lại với bản kế hoạch.
15 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
II.2.3 Quy trình phát triển phần mềm tại một số công ty phần mềm khác
Theo khảo sát của nhóm, các công ty phần mềm khác áp dụng các quy trình dựa trên
các quy trình chuẩn. Tuy nhiên tùy đặc thù từng công ty, về số lượng nhân viên, số thành viên
của team, quy mô dự án; mà có điều chỉnh cho phù hợp.
Nhận xét chung là trong những dự án vừa và nhỏ, quy trình phần mềm thường chưa
được quan tâm đúng mức. Sau khi có bản phân tích, các thành viên bắt tay vào cài đặt. Mỗi khi
có lỗi hoặc yêu cầu chỉnh sửa, thì họp bàn cả team để cùng xử lý.
16 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
Mô hình thác nước chia dự án phần mềm gồm các giai đoạn: đặc tả yêu cầu, thiết kế hệ
thống, cài đặt (lập trình), kiểm thử và bảo trì. Quy trình này dễ quản lý nhưng lại kém
linh hoạt và không hiệu quả bởi nếu có sự thay đổi ở các giai đoạn sau sẽ ảnh hưởng rất
lớn đến các giai đoạn trước.
Quy trình xoắn ốc chia dự án thành các giai đoạn: lập kế hoạch, phân tích rủi ro, giao
tiếp khách hàng, đánh giá lại, sản xuất và phân phối. Nó vẫn chưa được sử dụng rộng
rãi.
Các quy trình phần mềm truyền thống thường có quá khá nhiều giai đoạn, nhiều thành
phần, yếu tố trong suốt thời gian phát triển sản phẩm. Phương pháp scrum tránh điều này.
Đặc
điểm Waterfall Spiral Scrum
c.
-
Áp dụng scrum tại GoldeSoft
Triển khai SCRUM tại GoldenSoft trải qua 10 bước như sau:
Bước 1: Thu nhập các đặc điểm của sản phẩm (backlog) trong đơn đặt hàng. Đây là
bước quan trọng nhất. Lập nên các đội làm việc, có thể tách thành các đội nếu cần thiết
và thảo luận với nhau về nghiệp vụ cần làm. Sau đó bổ nhiệm một người vào vị trí
Product owner, người này có khả năng trao đổi, bao quát công việc tốt, biết sắp xếp ưu
tiên đúng thứ tự các nhiệm vụ. Sau đó tự tổ chức lại đội làm việc, đề xuất ra vị trí
Scrum master và thảo luận chi tiết các yêu cầu, sắp xếp chúng theo thứ tự ưu tiên.
Bước 2: Ước lượng đầy các yêu cầu về sản phẩm đầu ra. Có ước lượng ở mức độ cao,
chia sản phẩm thành số lượng các danh mục backlog. Tuy nhiên số lượng sẽ không
chính xác được, về sau chúng sẽ được bổ sung. Tiếp đến là ước lượng chi tiết từng
backlog, ước lượng số lượng các đội làm việc.
Bước 3: Lên kế hoạch phát triển các vòng lặp sprint. Sử dụng các cuộc trao đổi kế
hoạch phát triển sprint với tất cả các thành viên. Xác định khoảng thời gian sẽ phát triển
14 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
một sprint (thường là 30 ngày), mục tiêu của sprint là gì, sẽ đạt được gì, phân tích các
yêu cầu của sprint một cách rõ ràng.
d.
Bước 4: Lên kế hoạch phát triển các nhiệm vụ của sprint. Tất cả mọi người sẽ xác định
ngân sách của sprint đó, chia các đặc điểm thành các tác vụ nhỏ hơn, ước lượng số thời
gian sẽ làm từng task (giờ), hoàn tất các yêu cầu và nhận dạng task quan trọng.
Bước 5: Tạo ra không gian làm việc cộng tác cho tất cả mọi người. Thường sử dụng
bảng trắng để vẽ nên những vấn đề cần thiết cho tất cả mọi người cùng đánh giá.
Bước 6: Các thành viên bắt tay xây dựng từng sprint. Lập trình, kiểm thử và điều chỉnh
thời gian để có hiệu quả tốt nhất. Đôi khi có thể hủy bỏ một sprint và quay lại với việc
lập kế hoạch khác.
Bước 7: Mọi người báo cáo kết quả để tiếp tục làm việc. Các báo cáo tập trung vào các
vấn đề: đạt được những gì so với lần trao đổi trước; sẽ hoàn thành những gì trong lần
trao đổi tiếp theo; có những trở ngại gì trong quá trình làm việc v.v.
Bước 8: Tổng hợp kết quả trên biểu đồ. Đây là bức tranh tổng quát về những việc đã
làm được, những việc chưa làm được, thời gian ước lượng còn lại và có thể điều chỉnh
lại.
Bước 9: Xem xét để hoàn tất. Khi các thành viên nói công việc đã hoàn thành có nghĩa
là mọi thay đổi sẽ bị từ chối, đẩy lại cho vòng lặp sau.
Bước 10: Đánh giá, phản ánh và lặp lại. Có các cuộc họp đánh giá lại sprint của các
thành viên. Sẽ trình bày những gì đạt được, phản hồi của khách hàng, xét thời hạn của
sprint. Nhìn lại biểu đồ ở bước 8 để xác định lại toàn bộ hệ thống và tiếp nhận những
đóng góp, bổ sung để đưa tiếp vào các vòng lặp sprint tiếp theo.
Các điểm mạnh của quy trình SCRUM áp dụng tại GoldenSoft
Điểm mạnh nhất đó là việc linh hoạt, dự án không được cố định từ đầu về thời gian
hoàn thành hay những yêu cầu mà nó sẽ được xác định khi phát triển thực tế.
Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác định linh hoạt
theo môi trường sử dụng thực tế.
Thời gian biểu linh hoạt: có thể muộn hoặc sớm hơn so với kế hoạch ban đầu.
Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp. Khả năng trao đổi giữa
khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao.
Tốc độ phát triển nhanh, tiết kiệm thời gian. Việc chuẩn bị hành động cho những thay
đổi trong quá trình phát triển tốt hơn vì hầu như hàng ngày luôn có những buổi họp đánh giá
lại ở những vòng lặp phát triển.
Các bugs (lỗi) và các vấn đề được phát hiện sớm hơn rất nhiều so với các phương pháp
truyền thống bởi vì khách hàng được tham gia đánh giá rất nhiều và đầu ra của sản phẩm rất
nhanh. Và khi đi sai hướng, có thể hủy ngay sprint đó để quay lại với bản kế hoạch.
15 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
Lớp CNPM K51
II.2.3 Quy trình phát triển phần mềm tại một số công ty phần mềm khác
Theo khảo sát của nhóm, các công ty phần mềm khác áp dụng các quy trình dựa trên
các quy trình chuẩn. Tuy nhiên tùy đặc thù từng công ty, về số lượng nhân viên, số thành viên
của team, quy mô dự án; mà có điều chỉnh cho phù hợp.
Nhận xét chung là trong những dự án vừa và nhỏ, quy trình phần mềm thường chưa
được quan tâm đúng mức. Sau khi có bản phân tích, các thành viên bắt tay vào cài đặt. Mỗi khi
có lỗi hoặc yêu cầu chỉnh sửa, thì họp bàn cả team để cùng xử lý.
16 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
III.
Nhận xét đánh giá
-
Thông qua việc thực hiện đồ án, nhóm đã rút ra được những bài học sau
Lớp CNPM K51
Nắm được tầm quan trọng của các quy trình phát triển phần mềm
Nắm được các kiến thức cơ bản của các quy trình phát triển phần mềm: cơ sở lý thuyết,
các quy trình thực tế, công cụ hỗ trợ triển khai các quy trình
Học hỏi kinh nghiệm áp dụng các quy trình phát triển phần mềm tại các công ty
17 | P a g e
Đồ án môn học Nhập môn công nghệ phần mềm
IV.
Lớp CNPM K51
Tài liệu tham khảo
Bài giảng của Thầy Huỳnh Quyết Thắng, Viện CNTT&TT, ĐHBKHN
Roger S. Pressman: “Software Engineering: A Practitioner's Approach”, 6th Ed., McGraw
Hill, 2004.
Ian Sommerville: “Software Engineering”, 7th Ed., Addison-Wesley, 2004.
Ghezzi, M. Jazayeri, and D. Mandrioli, Fundamentals of Software
Engineering. 2nd Ed., Prentice-Hall, 2002.
John Musa: “Software Reliability Engineering”, McGraw-Hill, 1998.
Barry W. Boehm et al.: “Software Cost Estimation with COCOMO II”, Prentice Hall PTR,
2000.
Guide to the Software Engineering Body of Knowledge(SWEBOK) – IEEE 2004 Version
wikipedia.org
www.pcworld.com.vn
-
Các bài viết, tài liệu liên quan các mô hình phát triển phần mềm
18 | P a g e
