Nghiên cứu SEMAT và ứng dụng công cụ EssWork trong phát triển phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐẶNG THỊ PHƯỚC

NGHIÊN CỨU SEMAT VÀ ỨNG DỤNG CÔNG CỤ
ESSWORK TRONG PHÁT TRIỂN PHẦN MỀM

LUẬN VĂN THẠC SĨ

Hà Nội - 2014


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐẶNG THỊ PHƯỚC

NGHIÊN CỨ SEMAT VÀ ỨNG DỤNG CÔNG CỤ
ESSWORK TRONG PHÁT TRIỂN PHẦN MỀM

LUẬN VĂN THẠC SĨ

Ngành
Chuyên ngành
Mã số

CÔNG NGHỆ THÔNG TIN
KỸ THUẬT PHẦN MỀM
60 48 01 03

NGƯỜI HƯỚNG DẪN KHOA HỌC : TS. Mẫn Quang Huy
ĐỒNG HƯỚNG DẪN

: TS. Trương Anh Hoàng

Hà Nội - 2014


LỜI CẢM ƠN
Trước tiên tôi xin chân thành cảm ơn TS. Mẫn Quang Huy và TS. Trương Anh
Hoàng đã tận tình hướng dẫn, giúp đỡ tôi trong suốt quá trình thực hiện luận văn tốt
nghiệp.
Tôi xin chân thành cảm ơn các thầy cô giáo khoa Công nghệ Thông tin, trường Đại
học Công nghệ, Đại học Quốc gia Hà Nội, những người đã tận tình truyền đạt các kiến
thức, quan tâm, động viên trong suốt thời gian tôi học tập và nghiên cứu tại Trường.
Nhân đây cho phép tôi gửi lời cảm ơn tới nhóm các bạn học cùng lớp K16CNPM3,
lớp chuyên ngành công nghệ phần mềm đã thường xuyên quan tâm, giúp đỡ, chia sẻ kinh
nghiệm, cung cấp các tài liệu hữu ích trong suốt thời gian học tập tại trường.

Hà Nội, tháng 10 năm 2014
Tác giả luận văn

Đặng Thị Phước

i


LỜI CAM ĐOAN
Tôi xin cam đoan bản luận văn “Nghiên cứu SEMAT và ứng dụng công cụ
EssWork trong phát triển phần mềm” là công trình nghiên cứu của tôi dưới sự hướng dẫn

khoa học của TS. Mẫn Quang Huy, giáo viên đồng hướng dẫn TS. Trương Anh Hoàng,
tham khảo các nguồn tài liệu đã chỉ rõ trong trích dẫn và danh mục tài liệu tham khảo.
Các nội dung công bố và kết quả trình bày trong luận văn này là trung thực và chưa từng
được ai công bố trong bất cứ công trình nào.

Hà Nội, tháng 10 năm 2014
Tác giả luận văn

Đặng Thị Phước

ii


MỤC LỤC
LỜI CẢM ƠN ........................................................................................................................ i
LỜI CAM ĐOAN .................................................................................................................ii
MỤC LỤC .......................................................................................................................... iii
DANH SÁCH CÁC HÌNH VẼ ............................................................................................ v
MỞ ĐẦU .............................................................................................................................. 1
Lý do chọn đề tài .............................................................................................................. 1
Mục đích nghiên cứu ........................................................................................................ 2
Đối tượng và phạm vi nghiên cứu .................................................................................... 2
Kết cấu của luận văn ......................................................................................................... 2
CHƯƠNG 1- GIỚI THIỆU SEMAT ................................................................................... 4
1.1 Giới thiệu .................................................................................................................... 4
1.2 Kernel ......................................................................................................................... 5
1.2.1 Giới thiệu về Kernel ............................................................................................ 5
1.2.2 Kernel Alpha ....................................................................................................... 7
1.2.3 Một ví dụ áp dụng.............................................................................................. 19
1.2.4 Activity Space ................................................................................................... 38

1.2.5 Các kỹ năng cần thiết (competencies) ............................................................... 41
CHƯƠNG 2 – GIỚI THIỆU ESSWORK [2] .................................................................... 46
2.1 Giới thiệu .................................................................................................................. 46
2.2 Sử dụng EssWork ..................................................................................................... 46
2.2.1 Giao diện EssWork ............................................................................................ 46
2.2.2 Các thành phần sử dụng trong EssWork ........................................................... 47
2.2.3 Work Package .................................................................................................... 50
CHƯƠNG 3 - ỨNG DỤNG CÔNG CỤ ESSWORK ........................................................ 54
3.1 Mô tả bài toán ........................................................................................................... 54
3.2 Giai đoạn khởi đầu ................................................................................................... 56
3.2.1 Opportunity........................................................................................................ 56
3.2.2 Requirement ...................................................................................................... 58
iii


3.2.3 System ............................................................................................................... 63
3.2.4 Team .................................................................................................................. 64
3.2.5 Project ................................................................................................................ 65
3.2.6 Way of Work ..................................................................................................... 65
3.3 Giai đoạn phác thảo .................................................................................................. 66
3.3.1 Opportunity........................................................................................................ 66
3.3.2 Requirement ...................................................................................................... 67
3.3.3 System ............................................................................................................... 71
3.3.4 Project ................................................................................................................ 75
3.3.5 Team .................................................................................................................. 75
3.3.6 Way of Working ................................................................................................ 76
3.4 Giai đoạn hoàn thành ................................................................................................ 77
3.4.1 Opportunity........................................................................................................ 77
3.4.2 Requirement ...................................................................................................... 77
3.4.3 System ............................................................................................................... 77

3.4.4 Team .................................................................................................................. 78
3.4.5 Project ................................................................................................................ 78
3.4.6 Way of Working ................................................................................................ 78
3.5 Giai đoạn chuyển giao .............................................................................................. 79
3.5.1 Opportunity........................................................................................................ 79
3.5.2 Requirement ...................................................................................................... 79
3.5.3 System ............................................................................................................... 79
3.5.4 Team .................................................................................................................. 80
3.5.5 Project ................................................................................................................ 80
3.5.6 Way of Working ................................................................................................ 81
CHƯƠNG 4 - NHẬN XÉT, ĐÁNH GIÁ, THẢO LUẬN ................................................. 82
4.1 Ưu điểm của SEMAT ............................................................................................... 82
4.2 Ưu điểm của EssWork .............................................................................................. 85
4.3 Nhược điểm của SEMAT và EssWork..................................................................... 86
iv


KẾT QUẢ ĐẠT ĐƯỢC ..................................................................................................... 88
TÀI LIỆU THAM KHẢO .................................................................................................. 89

DANH SÁCH CÁC HÌNH VẼ
Hình 1.1: Mối quan hệ giữa các Alpha................................................................................. 8
Hình 1.2: Vòng đời Unified Process. ................................................................................. 21
Hình 1.3: Các trạng thái cần đạt được ở giai đoạn khởi đầu. ............................................. 22
Hình 1.4: Các trạng thái cần đạt được ở giai đoạn dự thảo. ............................................... 27
Hình 1.5: Các trạng thái cần đạt được ở giai đoạn xây dựng. ............................................ 32
Hình 1.6: Các trạng thái cần đạt được ở giai đoạn triển khai. ............................................ 35
Hình 1.7: Activity Space. ................................................................................................... 38
Hình 2.1: Giao diện EssWork. ............................................................................................ 46
Hình 2.2: Tạo một Process mới. ......................................................................................... 48

Hình 2.3: Xây dựng một Process từ các Practice. .............................................................. 49
Hình 2.4: Tạo một Work Pack mới. ................................................................................... 50
Hình 2.5: Bảng mô tả một Alpha trong Work Package...................................................... 51
Hình 2.6: Mô tả môt ví dụ về Work Pad. ........................................................................... 52
Hình 3.1: Quy trình Essential Unified Process................................................................... 55
Hình 3.2: Alpha Opportunity ở giai đoạn khởi đầu. ........................................................... 56
Hình 3.3: Công việc cần thực hiện với Opportunity ở giai đoạn khởi đầu. ....................... 57
Hình 3.4: Danh mục công việc cần thực hiện để Requirement đạt trạng thái Shared....... 58
Hình 3.5: Thống kê các Use Case trên EssWork. .............................................................. 59
Hình 3.6: Ca sử dụng quản trị hệ thống.............................................................................. 61
Hình 3.7: Ca sử dụng quản lý thông tin khách hàng. ......................................................... 61
Hình 3.8: Ca sử dụng theo dõi nợ của khách hàng. ............................................................ 62
Hình 3.9 Cập nhật trạng thái Use Case tới Story Structure Understood. ........................... 62
Hình 3.10: Các công việc cần thực hiện để đạt được trạng thái Approach Selected của
Alpha System. ..................................................................................................................... 63
Hình 3.11: Xác định các Modul cần được tạo trong System.............................................. 63
v


Hình 3.12: Xác định các thành viên trong nhóm. ............................................................... 65
Hình 3.13: Opportunity Game Board ở trạng thái Viability Establish. .............................. 66
Hình 3.14: Requirement với trạng thái đích là Stable. ....................................................... 67
Hình 3.15: Các nhiệm vụ cần thực hiện để Requirement đạt đích là Stable. ..................... 67
Hình 3.16: Use Case Slice ở trạng thái Prepared. .............................................................. 68
Hình 3.17: Use Case Slice ở trạng thái Analyzed. ............................................................. 70
Hình 3.18: Bảng Use Case Game Board khi Requirement đạt trạng thái Stable. ............. 71
Hình 3.19: System Game Board với trạng thái đích là Production Quality Achieved....... 71
Hình 3.20: Các nhiệm vụ cần thực hiện để System đạt được trạng thái Production Quality
Achieve. .............................................................................................................................. 72
Hình 3.21: Thực hiện phát triển một số modul. ................................................................. 72

Hình 3.22: Kiểm thử một số modul đã hoàn thành. ........................................................... 73
Hình 3.23: Xác nhận lỗi...................................................................................................... 73
Hình 3.24: Cập nhật lại những lỗi đã được sửa. ................................................................. 74
Hình 3.25: Cập nhật lại những test case đã hoàn thành...................................................... 74
Hình 3.26: Project Game Board với mục tiêu là Development Complete. ........................ 75
Hình 3.27: Team Game Board với mục tiêu là Collaborating. .......................................... 75
Hình 3.28: Trạng thái của Team Member khi nhóm cộng tác tốt. ..................................... 76
Hình 3.29: System với mục tiêu là trạng thái Release Candidate Available...................... 77
Hình 3.30: Component với trạng thái đích là Reased. ....................................................... 78
Hình 3.31: Opportunity đã đạt được trạng thái Problem Addressed. ................................. 79
Hình 3.32: Requirement đã đạt được trạng thái Fulfilled................................................... 79
Hình 3.33: System đã đạt được trạng thái Released. .......................................................... 80
Hình3.34: Team đạt trạng thái Disbanded. ......................................................................... 80
Hình3.35: Project đã hoàn thành việc chuyển giao. ........................................................... 81
Hình3.36: Way of Work đạt trạng thái Handed Over. ....................................................... 81
Hình 4. 1: Ví dụ về việc dùng chung Kernel trong một dự án. .......................................... 85

vi


MỞ ĐẦU
Lý do chọn đề tài
Công nghệ phần mềm đã có hơn 40 năm phát triển nhưng đến nay các phương pháp
phát triển phần mềm vẫn đang được nghiên cứu, thử nghiệm tích cực. Chúng luôn được
cải tiến dựa trên cả nghiên cứu lý thuyết và kinh nghiệm thực tế nhằm giúp các dự án
phần mềm ngày càng thành công hơn, giải quyết được những vấn đề thường trực như:
Yêu cầu khách hàng thay đổi, thời gian hoàn thành dự án, kinh phí, kỹ năng làm việc. Có
rất nhiều phương pháp phát triển phần mềm như: Quy trình thác nước, phương pháp phát
triển linh hoạt (XP, Scrum, RUP). Mỗi phương pháp có những ưu nhược điểm riêng phù
hợp với từng dự án. Giữa các phương pháp này cũng có nhiều điểm chung nhưng khó

nhận ra hoặc không thống nhất về mặt thuật ngữ và đó không phải là cái chung nhất của
mọi phần mềm khi phát triển. Các phương pháp phát triển thì luôn thay đổi theo thời gian
làm cho ta cảm nhận nó giống như một ngành thời trang chứ không phải là một ngành kỹ
thuật ví dụ như 15 năm trước đây thì người ta thường dùng quy trình Rup (Unified
Process), rồi sau đó đến CMMI, tiếp theo là đến XP và bây giờ là Scrum, Lean và Kaban.
Chúng ta không thể biết ngày mai sẽ là phương thức nào, có quá nhiều quy trình làm cho
đôi lúc chúng ta cũng không biết chọn quy trình phát triển nào là tốt nhất cho dự án của
mình.
SEMAT là một trong những lỗ lực nghiên cứu nhằm tạo ra nền tảng cho việc thống
nhất, kết hợp các phương pháp, qui trình phần mềm. Nó chứa những thành phần cơ bản,
chung nhất trong quá trình phát triển của bất kỳ phần mềm nào. Khi thực hiện SEMAT sẽ
kết hợp với một trong các quy trình phát triển nhờ đó sẽ có những hướng dẫn thực hiện
chi tiết hơn, giúp cho người mới làm phần mềm không bỏ qua một bước nào trong khi
thực hiện việc phát triển, giúp giải quyết các khó khăn gặp phải khi phát triển. Ví dụ nếu
chúng ta chỉ sử dụng quy trình RUP để phát triển chúng ta chỉ biết đầu ra của từng giai
đoạn, một số hướng dẫn tổng quát mà không có những hướng dẫn cụ thể từng việc phải
làm trong từng giai đoạn một cách thật rõ ràng, như khi xác định yêu cầu khách hàng gặp
1


phải khó khăn về việc không thống nhất giữa yêu cầu khách hàng giữa nhóm phát triển và
người sử dụng thì nếu chỉ sử dụng mỗi quy trình RUP thì không có hướng dẫn nào thực
hiện điều này, còn khí kết hợp nó với SEMAT thì lại có hướng dẫn thực hiện khi có sự
không thống nhất này.
SEMAT cũng đang còn khá mới mẻ trên thế giới và đặc biệt ở Việt Nam. Vì vậy việc
hiểu rõ và áp dụng được SEMAT để đưa ra một số nhận xét, đánh giá có ý nghĩa rất lớn
trong việc giúp các đơn vị làm phần mềm tiếp cận với SEMAT, đồng thời cũng giúp các
tổ chức giảng dạy về kỹ thuật phần mềm có những hướng đi mới trong việc giảng dạy về
kỹ thuật phần mềm.
Mục đích nghiên cứu

Mục đích nghiên cứu trong luận văn nhằm tìm hiểu các thành phần của SEMAT,
cụ thể ở đây là nghiên cứu về Kernel, một thành phần quan trọng, cơ bản nhất đều có
trong quy trình phát triển. Nắm vững các thành phần cơ bản trong quy trình phát triển
phần mềm và từ đó ứng dụng nó cho việc theo dõi quy trình phát triển phần mềm. Mục
đích thứ hai trong luận văn là nghiên cứu về công cụ EssWork, áp dụng công cụ này vào
một dự án cụ thể.
Đối tượng và phạm vi nghiên cứu
Đối tượng nghiên cứu ở đây là các thành phần của SEMAT như: Practice, Method,
Kernel, Language. Trong luận văn này tôi tập trung nghiên cứu sâu về các thành phần của
Kernel như: Kernel Alpha, Activity, Competency. Đối tượng nghiên cứu thứ hai trong
luận văn là công cụ EssWork, ứng dụng chức năng tạo Work Package trong công cụ này
trong việc theo dõi quy trình phát triển phần mềm.
Kết cấu của luận văn
Luận văn của tôi trình bày ngoài phần mở đầu, mục lục, danh mục tài liệu tham
khảo, kết quả đạt được thì nội dung của luận văn gồm bốn chương. Chương 1 sẽ nghiên
cứu về SEMAT. Nội dung trong chương sẽ nêu ra những lý thuyết về SEMAT, từng
thành phần trong SEMAT như: Method, Practice, Kernel, Language. Đặc biệt sẽ đi sâu
trình bày kỹ về thành phần Kernel trong SEMAT đồng thời nêu ra một ví dụ áp dụng khi
2


sử dụng Kernel Alpha trong quá trình phát triển phần mềm. Chương 2 sẽ nghiên cứu về
công cụ EssWork, sẽ tìm hiểu những đặc điểm, ứng dụng của công cụ EssWork đồng thời
cũng trình bày cách sử dụng EssWork. Chương 3 sẽ áp dụng công cụ EssWork vào một ví
dụ đơn giản, những áp dụng này giúp người nghiên cứu về SEMAT cũng như công cụ
EssWork hiểu rõ hơn về SEMAT và EssWork, hình dung về ứng dụng của SEMAT rõ
ràng hơn nhờ có những mô tả từng bước thực hiện công cụ. Sau khi sử dụng công cụ
EssWork thì luận văn sẽ đưa ra một số nhân xét, đánh giá, thảo luận về những ưu điểm,
nhược điểm của SEMAT cũng như công cụ EssWork trong chương 4. Nhờ những đánh
giá này mà người phát triển sẽ có những quyết định trong việc có nên dùng SEMAT trong

việc phát triển dự án của mình hay không.

3


CHƯƠNG 1- GIỚI THIỆU SEMAT
1.1 Giới thiệu
SEMAT được thành lập vào tháng 9 năm 2009 bởi Ivar Jacobson, Bertrand Meyer,
và Richard nhằm xây dựng lại các tiêu chuẩn tổng quát, các yêu tố cốt lõi như một nền
tảng chung cho quá trình phát triển phần mềm. SEMAT hoạt động trong bốn khu vực:
Khu vực thực hành, khu vực lý thuyết, khu vực giáo dục và khu vực cộng đồng.
Khu vực thực hành: Thiết lập một thư viện thực hành để mọi người cùng trao đổi
với nhau trên toàn thế giới, tạo tài liệu hướng dẫn sử dụng Essence, làm việc với các dự
án mã nguồn mở mà được hỗ trợ bởi Essence.[1]
Khu vực giáo dục: Khu vực này nhằm tổ chức các khóa học, các tài liệu giúp mọi
người có thể hiểu rõ về một số vấn đề như: Giới thiệu về công nghệ phần mềm, những
khái niệm cơ bản về hạt nhân trong công nghệ phần mềm, đưa ra những thực hành trong
Kernel Language, đánh giá sự tiến bộ và sức mạnh của công nghệ phần mềm khi sử dụng
Kernel và Alpha từ đó có thể mang những kiến thức thu được áp dụng vào trong thực
hành.[1]
Khu vực lý thuyết: Là khu vực nghiên cứu nhằm tìm ra lý thuyết chung cho công
nghệ phần mềm.[1]
Khu vực cộng đồng: Khu vực này nhằm tối đa hóa những chia sẻ về SEMAT trên
toàn thế giới bằng những cách như: Tạo ra và duy trì bài viết về SEMAT trên những trang
web, tạo ra các nhóm sử dụng SEMAT. [1]
Như vậy chúng ta thấy có sự gắn kết giữa thực hành, lý thuyết và giáo dục. Khu vực
lý thuyết tạo ra những nghiên cứu nền tảng chung vững chắc giúp cho khu vực thực hành
áp dụng vào thực tế. Những nghiên cứu về lý thuyết sẽ được công bố rộng rãi qua khu
vực cộng đồng, khu vực giáo dục giúp cộng đồng hiểu được các nghiên cứu mà khu vực
lý thuyết đã nghiên cứu tổng hợp thành. Khu vực thực hành giống như khách hàng của

khu vực lý thuyết bởi muốn áp dụng được các nghiên cứu vào thực tế thì những nhà phát
triển cần hiểu rõ những nghiên cứu đó và khu vực giáo dục sẽ có nhiệm vụ truyền tải

4


những nghiên cứu thông qua tài liệu, qua các buổi đào tạo và giúp cho các nhà phát triển
có thể hiểu rõ nghiên cứu và mang nó áp dụng vào thực tế.
Các chi nhánh hoạt động được đặt ở: Trung Quốc, Mỹ Latin, Nam Phi, Nhật Bản,
Hàn Quốc, Nga và Ấn Độ.
Kiến trúc SEMAT gồm 4 phần: Practices, Method, Kernel, Language.
- Methods: Method bao gồm các Practice, tất cả các Method bao giờ cũng có nền tảng
chung. Thực tế có rất nhiều phương thức để phát triển phần mềm như: SADT, RUP, XP,
Scrum, Kaban, Lean, v.v.[4]
- Practices: Một Practice là một cách tiếp cận lặp lại để làm một việc gì đó với một
mục đích cụ thể, nó cung cấp cách giải quyết một khía cạnh của vấn đề một cách có hệ
thống. Có khoảng hơn 250 practice ví dụ như: Ca sử dụng, đặc tính, thành phần…[4]
- Kernel: Kernel gồm các thành phần cơ bản và cần thiết cho mọi lỗ lực của công
nghệ phần mềm như: Requirement, Stakeholder, Way of work, Team, System, Work, các
khả năng cần thiết của người tham gia vào quá trình phát triển như: Phân tích, kiểm thử,
quản lý dự án… Nó là thành phần ở giữa giúp đỡ cho những người thực hiện như: Nhân
viên thiết kế, người phát triển, nhân viên kiểm thử, v.v lựa chọn phương thức nào tốt hơn
cho công việc của họ. Kernel được tổ chức thành 3 vùng: Customer, Solution,
Endeavor.[4]
- Language: Là ngôn ngữ kịch bản được thực hiện bởi người tham gia phát triển phần
mềm, nó được dùng để mô tả Kernel.[4]
Trong luận văn này tôi tập trung nghiên cứu vào việc tìm hiểu Kernel và áp dụng nó để hỗ
trợ cho việc phát triển phần mềm.
1.2 Kernel
1.2.1 Giới thiệu về Kernel

Như đã giới thiệu ở trên Kernel gồm những thành phần cơ bản, cần thiết cho
phát triển phần mềm. Nó ở giữa giúp những người thực hành như nhân viên thiết kế,
nhân viên lập trình, nhân viên kiểm thử, v.v có thể lựa chọn cho mình phương thức nào
tốt hơn trong công việc của mình.
5


Trong thực tế để tạo ra một phần mềm tốt luôn phải đối mặt với những khó khăn
thường trực như:
- Khó khăn về việc xác định yêu cầu khách hàng: Yêu cầu khách hàng không tập
trung tức là có thể là bạn hiểu sai yêu cầu khách hàng hoặc tại phía khách hàng có thể đưa
ra nhiều yêu cầu không thống nhất.
- Khó khăn trong việc xây dựng tài liệu làm việc: Mất quá nhiều thời gian cho việc
xây dựng tài liệu hướng dẫn về quy trình làm việc nhưng nó lại không hữu ích.
- Khó khăn trong quản lý nhóm: Nhóm làm việc bao gồm nhiều thành viên có thể biết
nhau hoặc chưa biết nhau trước đó vì vậy khi tham gia vào cùng một nhóm thì việc giúp
nhóm cộng tác tốt với nhau là khá khó khăn, đặc biệt là khi dự án đã được bắt đầu mà
người quản lý lo lắng về tiến độ của dự án nên thêm một vài thành viên thì khi đó sự cộng
tác giữa các thành viên cũ và mới cũng là một vấn đề khó khăn cần giải quyết.
- Khó khăn về hệ thống phần mềm: Mục đích của kiến trúc phần mềm dường như
không giải quyết đúng vấn đề và người phát triển không biết làm gì tiếp theo.
Những khó khăn mà chúng ta gặp phải đều tồn tại trong các thành phần của Kernel
như: Yêu cầu khách hàng, cơ hội, các bên liên quan, đội làm việc, công việc, cách làm
việc, hệ thống phần mềm. Kernel có thể giải quyết những khó khăn về kiến trúc, kiểm
thử, quản lý dự án …trong dự án của của chúng ta. Như vậy hiểu rõ Kernel sẽ giúp chúng
ta có thể đối mặt với những khó khăn thường gặp phải trong quá trình phát triển phần
mềm.
Kernel gồm 3 thành phần:
- Kernel Alpha: Là những thành phần cơ bản trong quá trình phát triển phần mềm.
Alpha là một phần rất quan trọng mang lại thành công hay không thành công của phần

mềm.
- Activity space: Những thực hiện cơ bản.
- Competence: Năng lực cần thiết trong quá trình phát triển phần mềm.
Kernel được tổ chức thành ba khu vực riêng biệt, mỗi một khu mục tập trung vào một
khía cạnh của kỹ nghệ phần mềm.
6


- Customer: Khu vực này quan tâm đến việc sử dụng và khai thác phần mềm được
triển khai trong thực tế.
- Solution: Khu vực này chứa những đặc tả về hệ thống và phát triển hệ thống phần
mềm.
- Endeavor: Là khu vực quan tâm đến nhóm làm việc và cách làm việc mà họ hướng
tới trong công việc của họ.
1.2.2 Kernel Alpha
Alpha là những thành phần cơ bản trong quá trình phát triển phần mềm, nhờ vào
nó người phát triển có thể kiểm soát phần nào những rủi ro, đáp ứng yêu cầu nêu ra,
khắc phục những khó khăn phải đối mặt trong quá trình phát triển. Chức năng của nó
là:
-

Đưa ra những khái niệm chính liên quan đến công nghệ phần mềm.

-

Cung cấp những nền tảng chung cho quá trình phát triển phần mềm.

-

Đánh giá và theo dõi sự tiến bộ và sức mạnh của bất kỳ một kỳ vọng nào của

phần mềm
Kernel Alpha gồm nhiều Alpha, mỗi Alpha lại có nhiều trạng thái từ bắt đầu

phát sinh Alpha đó cho đến trạng thái kết thúc Alpha đó. Mỗi một trạng thái sẽ gồm
danh sách các hướng dẫn người dùng đạt được trạng thái đó, đó chính là các Checklist.
Ví dụ như với trạng thái Conceived của Alpha Requirement gồm các Checklist như:
-

Các bên liên quan đồng ý về hệ thống đưa ra.

-

Xác định được những người sử dụng hệ thống mới.

-

Xác định được những người tài trợ cho cho công việc ban đầu của hệ thống

-

Một Opportunity cho hệ thống được giải quyết.

Các Alpha đều có mối liên hệ chặt chẽ khăng khít với nhau. Hình 1.1 sẽ mô tả các
Alpha và mối liên hệ giữa các Alpha.

7


Hình 1.1: Mối quan hệ giữa các Alpha. [4]

Khi bắt đầu dự án thì các Stakeholder (các bên liên quan) sẽ xác định các
Opportunity (cơ hội) và đưa ra Requirement (yêu cầu khách hàng). Các Oppornity phải
tập trung vào các Requirement. Khi các Requirement đã được xác định thì nhóm làm
việc lúc này sẽ có nhiệm vụ thực hiện Work (công việc), Work được giới hạn trong
phạm vi của Requirement đã nêu ra và giải quyết các tình huống của Opportunity, quá
trình làm việc của Team (nhóm làm việc) sẽ được sự hướng dẫn từ tài liệu hướng dẫn
trong Way of Work (cách làm việc) để tạo ra Software System (hệ thống phần mềm),
quá trình làm việc này sẽ liên tục làm cho Software System được thay đổi. Khi hệ
thống phần mềm được tạo ra hoàn thiện thì sẽ được các Stakeholder sử dụng, và hệ
thống này phải thỏa mãn các Requirement, giải quyết được các vấn đề mà Opportunity
đặt ra. [4]
1.2.2.1 Stakeholder
- Khái niệm: Stakeholder là người hoặc nhóm người tác động hoặc chịu tác động của
hệ thống. Stakeholder là những người cung cấp các Opportunity, là nguồn gốc của các
8


Requirement và họ liên quan đến những Opporturnity của hệ thống phần mềm, hỗ trợ
nhóm làm việc để đảm bảo rằng hệ thống được tạo ra đáp ứng các Requirement. [4]
- Các trạng thái của Stakeholder: [4]
 Recognized: Xác nhận các Stakeholder tham gia vào dự án.
 Represented: Chọn ra đại diện cho Stakeholder, có thể mỗi một nhóm
Stakeholder sẽ có một đại diện hoặc sẽ có một người đại diện cho toàn bộ các
Stakeholder.
 Involved: Các đại diện tham gia vào dự án và hoàn thành trách nhiệm của
mình.
 In Agreement: Trạng thái này xuất hiện khi có sự không thống nhất về
Requirement thì cần phải có sự thỏa thuận của các đại diện nhóm Stakeholder.
 Satisfied for Deployment: Những kỳ vọng khi triển khai dự án của Stakeholder
đã đạt được.

 Satisfied in Use: Hệ thống khi đưa vào sử dụng đã đạt được kỳ vọng của các
Stakeholder.
- Quá trình phát triển các trạng thái của Stakeholder [4]
Khi phát triển hệ thống chúng ta sẽ phải xác định xem những người nào sẽ bị tác
động hoặc chịu tác động từ hệ thống sau đó chia các ra thành các nhóm khác nhau,
mỗi nhóm sẽ có những điểm chung về việc tác động vào hệ thống. Chúng ta cũng cần
phải xác định xem nhóm nào có tác động quan trọng đến dự án, tác động đến sự thành
công của dự án. Những nhóm này sẽ tham gia vào dự án.
Trong mỗi nhóm được tham gia vào dự án thì cần phải tìm ra đại diện của nhóm
đó, đại diện nhóm sẽ tham gia trực tiếp vào dự án, sẽ là trung gian giữa nhóm phát
triển dự án và nhóm mà thành viên đó đại diện. Họ được cấp quyền để thực hiện trách
nhiệm của mình để thay mặt cho các bên liên quan tương ứng của họ. Người đại diện
phải biết rõ vai trò trách nhiệm của mình trong hệ thống phần mềm để có thể có
những đóng góp hiệu quả nhất. Nếu không xác định được rõ ràng vai trò của mình thì
rất có thể có một số khía cạnh quan trọng nào đó có thể bị vô ý bỏ qua.

9


Đại diện nhóm của các Stakeholder cần tích cực thực hiện vai trò của mình thì dự
án mới thành công được. Bởi đại diện nhóm là trung gian nên cần phải thông tin lại
cho nhóm những thay đổi từ dự án đến nhóm của mình và phản hồi lại những ý kiến
đóng góp từ thành viên nhóm khi có thay đổi từ dự án đến nhóm phát triển hoặc phản
hồi những gợi ý cần thay đổi của các thành viên cho dự án tới nhóm phát triển. Có như
vậy thì khi sản phẩm hoàn thành mới đáp ứng yêu cầu của các Stakeholder.
Không phải lúc nào hệ thống cũng đáp ứng tất cả những mong đợi từ các bên liên
quan do đó cần phải có những thỏa hiệp được nêu ra. Trong trạng thái In Agreement
đại diện các bên liên quan sẽ phải xác định một tập tối thiểu những kỳ vọng cần được
đáp ứng trước khi hệ thống được triển khai. Những kỳ vọng sẽ được các đại diện của
Stakeholder đồng ý.

Khi những kỳ vọng tối thiểu của người đại diện các nhóm Stakeholder đã đạt
được từ hệ thống phần mềm mới, họ sẽ xác nhận sẵn sàng cho trạng thái sử dụng và
triển khai.
Cuối cùng các bên liên quan bắt đầu sử dụng hệ thống và phản hồi về việc hài
lòng hay không hài lòng về những gì đã được chuyển giao. Đạt được trạng thái
Satisfied in Use có nghĩa là hệ thống đã được triển khai thành công và cung cấp
những lợi ích cho tất cả các bên liên quan.
1.2.2.2 Opportunity
- Khái niệm: Opportunity là tập hợp những tình huống thích hợp để phát triển
hoặc thay đổi hệ thống phần mềm. Nó nêu ra các lý do cho việc tạo ra cái mới hoặc
những thay đổi của hệ thống phần mềm cũ. Những tình huống này phát sinh trong quá
trình các Stakeholder làm việc, họ cung cấp những tình huống ấy cho nhóm phát triển.
Nhóm phát triển sẽ tạo ra những ý tưởng mới từ những tình huống này và phát triển
thành một phần mềm mới hoặc bán cho các bên liên quan khác. Việc hiểu rõ những
tình huống, những ý tưởng ban đầu là rất quan trọng, việc này sẽ giúp cho nhóm phát
triển:
 Xác định được hệ thống.
10


 Đề nghị giúp đỡ từ các bên liên quan.
 Hiểu rõ tại sao hệ thống phần mềm cần được phát triển.
 Nhận thức được việc đánh giá về hệ thống khi triển khai thành công.
 Đảm bảo rằng hệ thống chuẩn bị phát triển là hiệu quả và đáp ứng được yêu
cầu từ các bên liên quan.
- Các trạng thái của Opportunity:[4]
 Indentified: Xác định được cơ hội để phát triển một hệ thống phần mềm từ
một vấn đề xã hội, thương mại hay một nghiệp vụ kinh doanh.
 Solution Needed: Nêu ra những lý giải về sự cần thiết phải có một giải pháp
mới.

 Value Established: Xác nhận giá trị của giải pháp nêu ra.
 Viable: Sự tồn tại của giải pháp.
 Addressed: Giải pháp đã được đưa ra để giải quyết các cơ hội nêu ra.
 Benefit Accrued: Những lợi ích thu được từ việc sử dụng hoặc bán các giải
pháp nêu ra.
- Quá trình phát triển các trạng thái của Opportunity [4]
Như đã nói ở trên trong quá trình làm việc các Stakeholder sẽ gặp những tình
huống khác nhau mà từ những tình huống này phát sinh ra các ý tưởng có thể thay
đổi hệ thống phần mềm cũ hoặc tạo ra một hệ thống phần mềm mới, họ sẽ cung cấp
những ý tưởng, những tình huống này cho nhóm phát triển để nghiên cứu và phân
tích. Đây chính là trạng thái Identified.
Khi nhóm nghiên cứu đã hiểu rõ những tình huống của các bên liên quan cung
cấp thì họ sẽ tiến hành phân tích, tìm hiểu để hiểu rõ hơn về các Opportunity và đưa ra
các giải pháp để thực hiện các Opportuity đó.
Bước tiếp theo đó là nhóm làm việc cần xác định giá trị của các giải pháp mà họ
đưa ra, có thể sẽ có một hoặc nhiều giải pháp được nêu ra. Đây là một việc làm rất
quan trọng xác định việc có tiếp tục hay dừng việc thực hiện Opportunity. Nếu các
giải pháp đưa ra không thực hiện chính xác Opportunity thì giải pháp đó là không khả
11


thi. Nhờ việc xác định giá trị của các giải pháp mà họ có thể lựa chọn được một giải
pháp tối ưu nhất để giải quyết các Opportunity.
Việc tiếp theo là họ cần phải kiểm tra xem giải pháp đó có thể tồn tại được
không, tức là có thỏa mãn các yêu cầu về thời gian, về kinh phí, về tính khả thi hay
không? Dù giải pháp đó có mang lại giá trị to lớn nhưng chi phí để thực hiện giải pháp
đó vượt xa giá trị của nó mang lại thì giải pháp đó cũng không thể thực hiện được…
Khi xác định xong sự tồn tại của giải pháp thì coi như sẽ có một phần mềm chuẩn
bị được phát triển, họ chỉ còn kiểm tra một lần nữa xem nó có đáp ứng yêu cầu của các
bên liên quan hay không? Khi nó chắc chắn thỏa mãn yêu cầu của các bên liên quan

thì trạng thái Addressed coi như được xác nhận. Tức là chắc chắn có một phần mềm sẽ
được phát triển giải quyết được các Opportunity và thỏa mãn yêu cầu của các bên liên
quan, việc đưa phần mềm vào sử dụng khi hoàn thành sẽ mang lại giá trị cả về sử dụng
lẫn kinh tế là điều chắc chắn. Lúc này chính là trạng thái Benefit Accrued được xác
nhận.
1.2.2.3 Requirement
- Khái niệm: Là những gì hệ thống phần mềm phải làm để giải quyết những tình
huống được mô tả ở Opportunity và làm hài lòng các bên liên quan, nó cung cấp
những gì mà hệ thống cần đạt được. [4]
Các Requirement được lưu giữ như một tập hợp các Requirement Item. Các
Requirement Item có thể được ghi lại chi tiết bằng các hình thức khác nhau và ở các
cấp độ khác nhau. Các tài liệu mô tả Requirement có thể có nhiều hình thức và có thể
ngắn gọn như một câu chuyện sử dụng (use story) hoặc toàn diện như một ca sử dụng
(Use Case).
- Các trạng thái của Requirements Alpha [4]
 Conceived: Những điều cần thiết cho hệ thống mới được thống nhất.
 Bounded: Xác định mục đích và phạm vi của hệ thống.

12


 Coherent: Các Requirement cung cấp các mô tả về đặc điểm của hệ thống
mới.
 Acceptable: Các bên liên quan chấp nhận các mô tả về hệ thống của các
Requirement.
 Addressed: Một số Requirement đã được xử lý để đáp ứng những điều cần
thiết cho hệ thống và được các bên liên quan chấp nhận.
 Fulfilled: Các Requirement đã được giải quyết để đáp ứng đầy đủ hệ thống
mới.
- Quá trình phát triển các trạng thái: [4]

Trạng thái Concevied được bắt đầu khi những điều cần thiết cho hệ thống mới
được thống nhất. Lúc này có thể vẫn chưa có sự thống nhất về các Requirement
nhưng tất cả đều phải đồng ý sẽ có một hệ thống mới được tiến hành phát triển.
Lúc đầu có rất nhiều Requirement được đưa ra và sau quá trình sửa đổi, loại bỏ
thì sẽ có một tập các yêu cầu được lựa chọn dùng cho việc phát triển hệ thống. Các
yêu cầu được lựa chọn phải mô tả các khía cạnh của Opportunity và nằm trong phạm
vi của hệ thống. Lúc này có thể vẫn có sự mâu thuẫn giữa các Requirement nhưng tất
cả đều tập trung vào việc mô tả hệ thống mới (trạng thái Bound).
Liên tục phân tích, chứng minh, chỉnh sửa các Requirement thì sẽ thu được một
tập các Requirement, đây chính là những mô tả đầy đủ về các Requirement (đạt được
trạng thái Coherent), một số trong các Requirement đưa ra sẽ được các bên liên quan
chấp thuận (đạt được trạng thái Acceptable).
Khi tất cả các Requirement được thực hiện tạo ra một hệ thống mới thì trạng thái
Addressed được xác nhận. Nếu quá trình thực thi các Requirement là một giải pháp
hoàn thiện thì sẽ chuyển sang trạng thái Fulfilled. Nếu không thì cần xem xét lại
nguyên nhân, có thể là do việc một số Requirement nào đó bị thiếu không được đưa
và tập các Requirement được chọn vì thế cần phải thêm các Requirement này vào tập
các Requirement.

13


Ở trạng thái Fulfilled diễn ra sau khi trạng thái Addressed thành công, các bên
liên quan chấp nhận kết quả thực hiện.
1.2.2.4 System software

- Khái niệm: System Sofware là hệ thống được tạo lên từ phần mềm, phần cứng,
dữ liệu và mang lại giá trị khi chạy phần mềm. Một hệ thống phần mềm có thể là một
phần của giải pháp phần mềm, phần cứng, nghiệp vụ lớn. [4]
- Các trạng thái của Software System [4]

 Architecture Selected: Tổ chức lựa chọn một kiến trúc mới để khắc phục
những rủi ro hoặc hạn chế mà kiến trúc hiện tại mang lại.
 Demonstrable: Kiến trúc đưa ra là phù hợp với mục đích và hỗ trợ việc kiểm
thử bởi luôn có sự tồn tại của một phần mềm dựa vào kiến trúc nêu ra có thể hoạt
động được.
 Useable: Hệ thống có thể dùng được chính là sự giải thích cho tất cả những
đặc điểm chất lượng về một hệ thống hoạt động.
 Readly: Hệ thống sẵn sàng được triển khai trong môi trường thực.
 Operational: Hệ thống được triển khai trong môi trường thực.
 Retired: Hệ thống không còn nhận được sự hỗ trợ nào nữa.
- Sự phát triển các trạng thái của System Software [4]
Một hệ thống phần mềm trải qua 6 trạng thái từ bắt đầu hình thành kiến trúc
cho đến lúc nó không còn hoạt động nữa.
Ban đầu khi muốn xây dựng một hệ thống phần mềm phục vụ cho một mục
đích nào đó đầu tiên là nhóm phát triển cần phải lựa chọn kiến trúc cho hệ thống phần
mềm đó. Kiến trúc của phần mềm khi được lựa chọn có thể là một kiến trúc hoàn toàn
mới, hoặc sửa đổi từ kiến trúc cũ hoặc kết hợp giữa một phần cũ và một phần mới.
Khi đã lựa chọn xong kiến trúc rồi thì cần phải chứng minh kiến trúc đó có phù
hợp với yêu cầu của khách hàng và các bên liên quan không bằng cách xây dựng và

14


thử nghiệm. Hệ thống được xây dựng phải thể hiện đầy đủ kiến trúc đã lựa chọn, và
có thể kiểm thử chức năng và phi chức năng.
Sau khi hệ thống đã được xây dựng ở trạng thái Demonstrable thì nhóm phát
triển cần tinh chỉnh nó để chuyển nó sang trạng thái Usable bằng cách sửa đổi những
chỗ còn chưa đáp ứng được yêu cầu, phát triển thêm những chức năng còn thiếu.
Khi hệ thống đã có đầy đủ các chức năng yêu cầu thì cần phải kiểm tra lại một
lần nữa xem nó có đáp ứng đầy đủ các yêu cầu của các bên liên quan hay chưa trước

khi nó đưa vào chạy ở môi trường thực. Trong giai đoạn này nhóm phát triển cần tạo
tài liệu hướng dẫn sử dụng vận hành hệ thống. Hệ thống lúc này đã đạt ở trạng thái
Readly.
Khi hệ thống đã sẵn sàng hoạt động thì sẽ chọn một thời điểm thích hợp đưa nó
hoạt động trong môi trường thực, đó chính là trạng thái Operational. Lúc này chính là
lúc khai thác hệ thống về cả giá trị sử dụng lẫn giá trị về kinh tế.
Đến một lúc nào đó hệ thống có thể bị lỗi thời không phù hợp với hoàn cảnh
thực tế nữa. Khi ấy tổ chức sẽ không sử dụng hệ thống nữa và sẽ dẫn đến hệ thống ở
trạng thái Retired.
1.2.2.5 Team
- Khái niệm: Team là nhóm người tích cực tham gia vào việc phát triển, bảo trì,
phân phối và hỗ trợ một hệ thống phần mềm cụ thể. [4]
Nhóm làm việc có một vai trò vô cùng quan trọng đến sự thành công của dự án.
Bởi việc phát triển phần mềm cần sự kết hợp của nhiều kỹ năng từ phân tích thiết kế,
lập trình, kiểm thử, quản lý, v.v. Các thành viên trong nhóm có những kỹ năng ở các
cấp độ khác nhau và cũng có những kỹ năng khau. Vì vậy để dự án hoàn thành tốt đẹp
thì rất cần sự gắn kết giữa các thành viên với nhau, sự hiểu biết lẫn nhau và sự hiểu
biết của các thành viên về dự án. Nếu mỗi thành viên trong nhóm đều lỗ lực hoàn
thành nhiệm vụ của mình và giúp đỡ các thành viên khác hoàn thành nhiệm vụ của họ
thì dự án mới có thể thành công tốt đẹp.
15


- Các trạng thái của team [4]
 Seeded: Nhiệm vụ của nhóm đã được xác định, các bí quyết cần thiết đã được
đặt ra.
 Formed: Nhóm đã được thành lập đầy đủ và cam kết thực hiện nhiệm vụ.
 Collaborating: Các thành viên trong nhóm cộng tác làm việc với nhau một
cách chặt chẽ như một đơn vị.
 Performing: Nhóm làm việc với nhau một cách hiệu quả.

 Adjourned: Nhóm nghiên cứu kết thúc công việc và không còn chịu trách
nhiệm về công việc của mình nữa.
- Sự phát triển của các trạng thái. [4]
Trạng thái Seeded của Team được xác định khi bắt đầu thành lập đội, từ các
thành viên riêng lẻ phù hợp những yêu cầu cần thiết đặt ra được lựa chọn, các thành
viên đạt yêu cầu được lựa chọn vào nhóm sẽ phụ trách một số nhiệm vụ cụ thể được
phân công.
Khi nhóm đã được thành lập và nhận nhiệm vụ xong thì các thành viên trong
nhóm bắt đầu thực hiện nhiệm vụ của mình lúc đó trạng thái Formed được thành lập.
Trong quá trình thực hiện nhiệm vụ các thành viên trong nhóm sẽ lỗ lực thực hiện
nhiệm vụ của mình, các thành viên trong nhóm sẽ hỗ trợ lẫn nhau để hoàn thành
nhiệm vụ. Khi ấy trạng thái cộng tác (collaborating) được xác định.
Trạng thái Performing được xác định khi các thành viên cộng tác với nhau và
hoàn thành nhiệm vụ đưa ra. Trạng thái cuối cùng khi nhóm đã hoàn thành nhiệm vụ
và không còn nhiệm vụ nào nữa thì nhóm sẽ ở trạng thái Adjourned.
1. 2.2.6. Work
- Khái niệm: Work là hoạt động liên quan đến nỗ lực về tinh thần hoặc thể chất
thực hiện để đạt được kết quả.
Trong bối cảnh của công nghệ phần mềm, Work là những tất cả những gì cần
làm để đạt được mục tiêu là sản phẩm phù hợp với yêu cầu khách hàng, giải quyết
được những Opportunity được các bên liên quan đưa ra.
16


- Các trạng thái của Work [4]
 Initiated: Khi có yêu cầu thực hiện công việc.
 Prepared: Tất cả các điều kiện để bắt đầu công việc được đáp ứng.
 Started: Khi công việc đang được tiến hành.
 Under Control: Công việc tiến triển tốt, rủi ro được kiểm soát, năng suất đủ
để đạt được một kết quả khả quan.

 Concluded: Công việc đã tạo ra kết quả và đi đến kết luận.
 Closed: Tất cả các nhiệm vụ còn lại đã hoàn thành, công việc chính thức kết
thúc
- Mô tả sự phát triển của các trạng thái [4]
Công việc phát triển một hệ thống phần mềm tiến triển từ trạng thái khởi tạo cho
đến kết thúc thông qua một số trạng thái như: Initiated, Prepared, Started, Under
Control, Concluded, Closed.
Trạng thái đầu tiên của Work là Initiated, đó là lúc nhóm được thành lập xong và
các thành viên trong nhóm được giao nhiệm vụ thực hiện công việc. Khi công việc
được giao cho các thành viên trong nhóm xong thì công việc tiếp theo là chuẩn bị các
điều kiện cần thiết để có thể bắt đầu thực hiện công việc được thuận lợi như: Chuẩn
bị kinh phí, đảm bảo nguồn lực, tìm hiểu các khó khăn…Khi tất cả các điều kiện đều
được đảm bảo thì công việc sẽ bắt đầu được thực hiện, đó chính là trạng thái Started
của Work.
Khi từng phần của công việc được dần hoàn thành thì đó chính là trạng thái
Under Control được xác nhận tức là công việc đã được kiểm soát. Nếu công việc được
kiểm soát tốt điều đó có nghĩa là chúng ta sẽ thấy được công việc tiến triển tốt, những
rủi ro đe dọa không còn hoặc khả năng xảy ra đã được giảm xuống mức chấp nhận
được, năng suất của nhóm nghiên cứu đủ để đạt được kết quả khả quan trong thời gian
dự kiến và ngân sách đề ra khi có khó khăn xuất hiện.
Trạng thái Concluded được xác định khi công việc đã hoàn thành và được các
bên liên quan chấp nhận.
17