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

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à

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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

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

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

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

Đạ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

 Đề 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ả

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

 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

Ở 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à

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 ở

- 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

- 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

Trạng thái cuối cùng chính là Closed tức là tất cả công việc đã hoàn tất, trong một số trường hợp một công công việc đã đã bắt đầu nhưng vì một lý do nào đó nó lại không thực hiện tiếp thì nó vẫn đi đến trạng thái Closed mà không cần qua trạng thái Concluded

1.2.2.7 Way of woking

- Khái niệm: Là tập hợp những việc thực hành và công cụ được sử dụng tạo thành

tài liệu hướng dẫn và hỗ trợ cho công việc của họ [4]

Cách làm việc của nhóm:

 Là chìa khóa để một nhóm làm việc với nhau hiệu quả

 Nhóm cần tập trung vào việc cộng tác như thế nào để đảm bảo thành công

 Lên kế hoạch và kiểm soát công việc

 Giúp đỡ các thành viên trong nhóm và các bên liên quan để hoàn thành tốt nhiệm vụ của mình

- Các trạng thái của Way of Work:[4]

 Principles Established: Thiết lập những nguyên tắc và những ràng buộc hình thành nên cách làm việc

 Foundation Established: Lựa chọn những Practices và Tool chính để tạo lên nền tảng của cách làm việc sẵn sàng sử dụng

 In Use: Một số thành viên trong nhóm đã sử dụng và thích ứng với cách làm việc

 In place: Tất cả các thành viên trong nhóm đang sử dụng cách làm việc để hoàn thành công việc của họ

 Working well: Cách làm việc đang sử dụng tốt cho công việc của nhóm

 Retired: Cách làm việc không còn được sử dụng nữa

- Mô tả quá trình phát triển của các trạng thái trong Way of Work [4]

Trạng thái đầu tiên trong Way of Work đó là trạng thái Principles Established Bước đầu tiên là cần xác định xem cần áp dụng cách làm việc mới hay vẫn sử dụng

cách làm việc cũ và xác định nguyên tắc cho cách làm việc Nguyên tắc này sẽ có những hướng dẫn cho việc lựa chọn các Practice và Tool Nó cũng chứa những ràng buộc trong việc lựa chọn các Practice và Tool

Khi nguyên tắc đã được thiết lập thì nhóm làm việc sẽ lựa chọn Practice và Tool cho công việc của mình, đây chính là những nền tảng của cách làm việc Lựa chọn Practices và Tool sẽ mang nhóm lại gần nhau, giúp đỡ và cộng tác với nhau để hoàn thành công việc

Sau khi nền tảng của cách làm việc được thiết lập thì lúc này cách làm việc có thể sẵn sàng sử dụng được, trong quá trình áp dụng cách làm việc thì sẽ có những thay đổi để đáp ứng những thay đổi của công việc và sẽ có những Practices và Tool được thêm vào

Ngày càng nhiều các thành viên sử dụng cách làm việc và trong quá trình sử dụng nó luôn luôn được cải tiến đến một lúc nào đó tất cả các thành viên trong nhóm đều sử dụng nó cho công việc của mình

Cách làm việclà Working Well khi nó đã ổn định và tất cả các thành viên trong nhóm đang tiến bộ theo kế hoạch bằng cách sử dụng và thích ứng với nó Cuối cùng,

khi cách làm việc không còn được sử dụng bởi nhóm, nó ở trạng thái Retired

1.2.3 Một ví dụ áp dụng

Ví dụ áp dụng Kernel Alpha để xây dựng quy trình phát triển cho một chương trình quản lý khách hàng của công ty nội thất A Khách hàng của công ty có thể là khách hàng lẻ hoặc khách hàng thường xuyên, vì vậy việc phân biệt loại khách hàng

và thông tin về khách hàng đã có là việc rất quan trọng

Hình 1.2 sau se mô tả các trạng thái của SEMAT được kết hợp với quy trình phát triển RUP Mỗi một giai đoạn của quy trình sẽ có những trạng thái cần đạt được của giai đoạn đó, từ đó người phát triển có thể dựa vào đó để có thể theo dõi xem dự án của mình đang ở trạng thái nào của giai đoạn nào

Hình 1.2: Vòng đời Unified Process [4]

Value Establish

Foundation Established

In Use

Performing Working Well

Retired Adjourned

Colaborating

In Place

- Những người tham gia:

 Anh Hải: phòng kinh doanh

 Chị Lan: Phòng kế toán

 Anh Hùng: Phòng IT – Nhân viên coder

 Anh Thiện: Phòng IT - Nhân viên coder

 Chị hòa: Phòng IT- Nhân viên Tester

Sau đây sẽ là mô tả chi tiết hơn về các trạng thái của mỗi Alpha và cách thức

để đạt được các trạng thái ấy trong các giai đoạn phát triển ứng dụng:

- Giai đoạn khởi đầu: Kết quả cuối của giai đoạn này cần đạt được đó là xác

định được tập các yêu cầu khách hàng, lựa chọn kiến trúc Các trạng thái cần đạt được ở giai đoạn này được mô tả như trong hình 1.3

Để hoàn thành các công việc trong giai đoạn này thì các công việc cần thực hiện được chia làm ba vùng với ba nhóm công việc tương ứng với từng vùng, các nhóm công việc đó chính là:

 Xác định cơ hội và các bên liên quan chịu tác động hoặc tác động vào dự

án Sau đây là thống kê các trạng thái và cách thức để đạt được các trạng thái đó

o Điểm xuất phát ban đầu là trạng thái Identified (cơ hội được xác định): Khi anh Hải – Phòng kinh doanh tiếp nhận một khách hàng, anh ấy không có thông tin nào về vị khách hàng này nhưng anh ấy nhớ rằng trước đây hình như trước đây công ty đã hợp tác với khách hàng này một lần Anh đồng nghiệp phụ trách khách hàng này đã nghỉ lên không có cách nào lấy các thông tin chính chi tiết về khách hàng này Lúc đó anh nghĩ nếu có một chương trình quản lý tất cả các khách hàng của công ty, phân loại các loại khách hàng, tình hình thanh toán và các đặc điểm của khách hàng thì sẽ rất tốt cho phòng kinh doanh cũng như việc thu hồi công nợ của phòng kế toán

o Recognized:Anh Hải đã nêu ý tưởng của mình với giám đốc và được giám đốc công ty đồng ý triển khai phát triển chương trình này, đồng thời yêu cầu phòng kế toán và phòng kinh doanh cùng đưa ra ý kiến đóng góp cho phần mềm

o Represented: Phòng kế toán và phòng kinh doanh đã họp lại với nhau

để cùng thảo luận về phần mềm sẽ được xây dựng Họ đã thống nhất là anh Hải đại diện cho hai phòng tham gia vào quá trình phát triển, cứ 2 tuần họp lại họp lại để cùng trao đổi với nhau về sản phẩm

o Solution Needed: Trong cuộc họp anh Hải nêu ra ý tưởng của mình

về việc phát triển phần mềm quản lý khách hàng Anh ấy giải thích nguyên nhân cần thiết của việc phát triển phần mềm này và được giám đốc cũng như những người khác đồng ý rằng việc phát triển phần mềm này là một ý tưởng tốt và giải quyết được vấn đề trong quản lý khách hàng cũ và chiến lược kinh doanh với các khách hàng

o Value Established: Trong cuộc họp mọi người cũng đã thấy được tầm quan trọng của phần mềm khi được xây dựng, nó giúp phòng kế toán thống kê nhanh công nợ tại bất kỳ thời điểm nào của khách hàng, giúp việc liên lạc với các khách hàng còn nợ đọng, giúp phòng kinh doanh có thể tìm hiểu về một khách hàng đã từng hợp tác với công ty…

o Involved: Khi nhân viên của đội phát triển có bất kỳ thắc mắc nào về nghiệp vụ thì Anh Hùng luôn sẵn sàng giúp đỡ trong khả năng có thể, nếu nghiệp vụ nào liên quan đến phòng kế toán mà anh không rõ thì sẽ trao đổi lại với chị Lan (đại diện phòng kế toán) để có câu trả lời kịp thời Đồng thời cứ đúng như dự kiến ban đầu cứ 2 tuần thì phòng kế toán và phòng kinh doanh sẽ họp một lần để thảo luận về những thay đổi liên quan đến các chức năng của phần mềm để kịp thời phản ánh những điều không phù hợp hoặc đưa ra những ý tưởng mới

 Công việc thứ hai của giai đoạn này là hiểu rõ mục đích của giải pháp Để hiểu rõ được giải pháp thì nhóm phát triển và anh Hùng cần khoanh vùng những yêu cầu của sản phẩm và chọn lựa kiến trúc phát triển phù hợp cho sản phẩm Sau đây sẽ là các trạng thái cần đạt được và cách đạt được các trạng thái đó

Các trạng

thái

Nhiệm vụ của trạng thái [3] Cách để hoàn thành trạng thái

Conceived - Hiểu rõ về hệ thống mới

- Xác định người sử dụng hệ thống

- Xác định người tài trợ cho hệ thống

Để hiểu rõ về ứng dụng thì Anh Hải viết ra một bản mô tả tổng quan về ứng dụng bao gồm cả những người sẽ

đó cùng thảo luận và đưa ra các chức năng của ứng dụng đồng thời đưa ra Bảng 1.1 Các công việc cần thực hiện để hiểu rõ mục đích của giải pháp

Requirement

- Xác định hạn chế

những hạn chế mà ứng dụng chưa thể đạt được

Achitecture

Selected

- Xác định nền tảng phẩn cứng

- Lựa chọn ngôn ngữ lập trình và công nghệ sử dụng

- Cần xác định là làm lại từ đầu hay phát triển từ cái cũ hay mua lại

- Kiến trúclựa chọn giải quyết những rủi ro chính về công nghệ

Hai nhân viên phát triển đã thảo luận với nhau để đưa ra cấu hình máy phù hợp cho ứng dụng của họ, họ cũng thống nhất sẽ sử dụng ngôn ngữ lập trình là C# và CSDL: SQL Bởi ứng dụng là rất nhỏ nên họ sẽ tự phát triển

từ đầu mà không phải thuê hay mua lại một phần nào cả

 Bước thứ ba trong giai đoạn này là chuẩn bị một số điều cần thiết trước khi bắt đầu thực hiện công việc phát triển Bảng sau đây sẽ mô tả cách chuẩn bị và đưa ra những yếu tố cơ bản trong cách làm việc của họ thông qua các trạng thái

và cách để đạt được các trạng thái

State Nhiệm vụ [3] Cách hoàn thành nhiệm vụ

Seeded - Xác định quy mô của

nhóm

- Xác định trách nhiệm của nhóm

- Xác định thành phần cho nhóm

Nhóm được xác định gồm có hai nhân viên code, 1 kiểm thử như đã nêu ở trên Nhóm phát triển được giám đốc thống nhất về thời gian thực hiện dự án

Initiated - Xác định công việc bắt

Nguồn kinh phí dự kiến anh Hùng đề xuất Bảng 1.2 Công việc cuối cần thực hiện để hoàn thành giai đoạn khởi đầu

thi thực hiện được giám đốc công ty duyệt

Principle

Establish

- Xác định các yếu tố cơ bản và các ràng buộc

- Xác định các practice và tool

Nhóm phát triển quyết định sử dụng practice là:

- Sử dụng phát triển theo quy trình RUP

- Phát triển theo hướng điều khiển kiểm thử (TDD)

- Sử dụng Use Case để mô tả chức năng

- Công cụ dùng để phát triển là VS 2013

Prepared - Ước tính chi phí trong

công việc

- Sẵn sàng nguồn tài nguyên

- Đưa ra một kế hoạch tin cậy

- Hiểu rõ những rủi ro có thể gặp

Nhóm phát triển lên kế hoạch về ngân sách

và nguồn tài nguyên cần thiết trong quá trình phát triển ứng dụng

Formed - Làm rõ trách nhiệm của

từng cá nhân

- Tuyển chọn đầy đủ các thành viên

- Xác định cơ chế trao đổi thông tin trong nhóm

Do là ứng dụng nhỏ nên mọi nhóm quyết định không cần thêm thành viên mới Nhóm duy trì đến lúc kết thúc gồm 2 coder và 1 tester

Foundation

Establish

- Xác đinh practice và tool chính trong quá trình phát triển

- Phân tích để hiểu rõ practicevà tool sẽ được

sử dụng

Nhóm phát triển quyết định sử dụng practice là:

- Sử dụng phát triển theo quy trình RUP

- Phát triển theo hướng điều khiển kiểm thử (TDD)

- Sử dụng use case để mô tả chức năng

- Công cụ dùng để phát triển là VS 2013

- Giai đoạn phác thảo: Ở giai đoạn này nền tảng kiến trúc đã được xác định, quy

trình, cơ sở hạ tầng, môi trường phát triển cũng đã được mô tả rõ ràng Hình 1.4 sẽ mô

tả các trạng thái cần đạt được ở giai đoạn này như sau:

Sau đây sẽ là mô tả các công việc cần thực hiện để đạt được các trạng thái như ở hình vẽ 1.4

State Các nhiệm vụ cần đạt được Cách để hoàn thành nhiệm vụ

In Agreement - Thông tin đầu vào của đại

diện các bên liên quan được

Anh Hải tiếp tục chia sẻ những tiến triển của phần mềm với nhân viên liên quan và

Hình 1.4: Các trạng thái cần đạt được ở giai đoạn dự thảo

Bảng 1.3 Các công việc cần thực hiện để hoàn thành các trạng thái ở giai đoạn dự thảo

cung cấp bởi nhóm phát triển

- Thông tin đầu vào của nhóm phát triển được cung cấp bởi đại diện các bên liên quan

- Đại diện các bên liên quan

và nhóm phát triển cùng thống nhất để cùng đạt được những mong đợi tối thiểu của cả hai

cung cấp những góp ý từ các nhân viên liên quan mà anh đại diện tới nhóm phát triển

Viable

- Chọn lựa một giải pháp trong các giải pháp được nêu

- Các dấu hiệu cho thấy các giải pháp có thể được phát triển và triển khai

- Những rủi ro liên quan đến các giải pháp có thể chấp nhận và quản lý được

- Các chi phí chỉ của giải pháp là ít hơn so với giá trị

dự kiến của Opportunity

- Các thành viên trong nhóm phát triển cần hiểu rõ những lý do cần phát triển một phần mềm dựa trên giải pháp được chọn

- Việc theo đuổi các Opportunity rõ ràng là khả thi

- Nhóm phát triển đã họp lại và quyết định xây dựng ứng dụng quản lý khách hàng với những đặc điểm thỏa mãn các tiêu chí của anh Hải nêu ra

- Khó khăn lớn nhất của việc phát triển

dự án này là thời gian hoàn thành ngắn, các thành viên trong nhóm đồng ý sẽ làm thêm giờ để khắc phục khó khăn này

- Kinh phí và giám đốc đưa ra để phát triển là hoàn toàn thỏa mãn

- Như vậy việc phát triển ứng dụng là hoàn toàn khả thi và không gặp trở ngại

gì về mọi mặt

Conherent - Bức tranh tổng thể về

Requirement cần chia sẻ cho tất cả những người liên quan

Anh Hải và nhóm phát triển đã thống nhất lại chức năng của ứng dụng gồm có: Quản trị hệ thống, quản lý thông tin

- Giải thích các kịch bản chính

- Các xung đột cần được giải quyết

Requirement ưu tiên

- Hiểu rõ những tác động khi thực hiện các Requirement

khách hàng và quản lý nợ của khách hàng đồng thời nhóm phát triển lập tài liệu mô tả chi tiết các chức năng nhỏ trong ứng dụng và các hoạt động của nó trong tài liệu

Chị Hòa viết các ca kiểm thử cho các Requirement để các bên nhìn thấy rõ hơn về Requirement

Nhóm xác định chức năng quản lý thông tin khách hàng là chức năng quan trọng nhất

Demonstrable

- Giải thích về sự phù hợp của kiến trúc lựa chọn

- Giải thích về cấu hình phần cứng phù hợp

- Chứng minh về sự phù hợp của giao diện

Họ chứng minh sự phù hợp về kiến trúc, cầu hình phần cứng cũng như giao diện bằng các test case, họ xem lại các test case để chắc chắn tất cả các giao diện đều được kiểm thử

- Nhóm nghiên cứu cần tập trung để đạt được nhiệm vụ

Các thành viên trong nhóm phát triển cùng giúp đỡ nhau hoàn thành nhiệm vụ

đề ra

Mỗi khi hoàn thành một modul thì nhóm lại có một cuộc họp để cùng nhau rút kinh nghiệm cho modul sau để hoàn thành

của nhóm đã nêu ra

- Các thành viên trong nhóm đặt sự thành công của cả một nhóm như là mục tiêu hàng đầu của mình

mục tiêu nêu ra ban đầu

In Use

- Các công cụ được sử dụng trong thực tế

- Nhóm hỗ trợ nhau trong việc sử dụng công cụ

Nhân viên code và kiểm thử đã sử dụng công cụ được đề xuất vào quá trình phát triển sản phẩm

Usable

- Hệ thống có khả năng sử dụng và có những đặc điểm mong muốn

- Hệ thống có thể vận hành bởi người dùng

- Chức năng và hiệu suất của hệ thống được kiểm thử

- Các nhược điểm có thể chấp nhận được

Với kiến trúc đã lựa chọn nhóm phát triển

đã nêu ra các chức năng đã xây dựng và chứng minh nó có khả năng sử dụng được, đồng thời tiếp tục chỉnh sửa hoàn thiện các chức năng chưa đáp ứng yêu cầu và các chức năng chưa hoàn thiện

Nhóm tiếp tục hoàn thành sản phẩm mặc

dù đối mặt với những khó khăn nhưng họ đều giải quyết tốt Điều này chứng tỏ họ đang đi đúng hướng và công việc chắc chắn sẽ hoàn thành đúng thời hạn đề ra Mỗi một chức năng hoàn thành họ đều họp lại để tổng hợp các kinh nghiệm để cải thiện cách làm việc, chia sẻ với nhau

về kinh nghiệm làm việc để kỹ năng làm

việc của cả nhóm được tốt hơn

Performing

- Nhóm luôn làm việc một cách hiệu quả, thích nghi với những thay đổi

- Trong quá trình làm việc cần tránh việcsửa lại

- Loại bỏ những lãng phí

Nhóm tiếp tục tập chung vào công việc để

có đầu ra chất lượng cao, luôn điều chỉnh

và cải tiến những công việc họ làm cho phù hợp khi có bối cảnh thay đổi

In Place

- Toàn bộ nhóm làm việc đều sử dụng các công cụ nêu ra để hoàn thành công việc của mình

- Các thành viên đều tham gia và thích nghi với cách làm việc

Các thành viên trong nhóm sử dụng công

cụ đề ra để phục vụ công việc một cách thành thạo và hoàn thành tốt công việc của mình

- Giai đoạn hoàn thành: Tất cả những thành phần còn lại và tính năng của ứng

dụng được phát triển, tích hợp vào sản phẩm Các trạng thái cần đat được ở giai đoạn này được mô tả trong hình 1.5

Hình 1.5: Các trạng thái cần đạt được ở giai đoạn xây dựng