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

  • Số trang: 97 |
  • Loại file: PDF |
  • Lượt xem: 174 |
  • Lượt tải: 0
tailieuonline

Đã đăng 27679 tài liệu

Mô tả:

ĐẠ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
- Xem thêm -