Bài tiểu luận: Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm. Sử dụng EA trong phát hiện và tổng hợp các yêu cầu phần mềm.docx (Sử dụng EA)

Trường Đại Học Bách Khoa Hà Nội Viện Công Nghệ Thông Tin & Truyền Thông ------------  ------------ BÀI TIỂU LUẬN SỐ 1 Giảng Viên Hướng Dẫn: Huỳnh Quyết Thắng Sinh Viên Thực Hiện: Lê Thị Bích Thuận Lớp: CNPM-K52 MSSV: 20073837 Hà Nội 11-2010 Mục lục Phần 1. Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm. Sử dụng EA trong phát hiện và tổng hợp các yêu cầu phần mềm..............................................4 I. Phân tích bài toán..........................................................................................4 II. Xác định quá trình phát triển các yêu cầu phần mềm..............................7 III. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm..............7 IV. Xác định các nhóm người sử dụng và đặc tính của họ và đại diện tiêu biểu cho mỗi nhóm...............................................................................................9 V. Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm người sử dụng....................................................................................10 VI. Xây dựng các đặc tính xác định chất lượng yêu cầu và các yêu cầu khác (yêu cầu phi chức năng).....................................................................................11 1. Interview....................................................................................................12 2. Requirements Workshops.........................................................................14 3. Brainstorming and Idea Reduction..........................................................14 4. Storyboarding............................................................................................19 5. Applying Use Cases...................................................................................20 6. Prototyping(tạo mẫu)................................................................................20 VII. Sử dụng EA trong phát hiện yêu cầu phần mềm:.................................21 1. Các thành phần của use case:..................................................................22 1.1. Actor:................................................................................................22 1.2. Use case............................................................................................23 1.3. Collaboration....................................................................................25 1.4. Boundary:.........................................................................................26 1.5. Package:...........................................................................................26 Lê Thị Bích Thuận – CNPM-K52 Page 2 2. Use case diagram connectors:..................................................................27 2.1. Use:...................................................................................................27 2.2. Associate...........................................................................................27 2.3. Generalize.........................................................................................28 2.4. Include:.............................................................................................28 2.5. Extend...............................................................................................28 2.6. Realize:.............................................................................................28 2.7. Invokes..............................................................................................29 2.8. precedes............................................................................................29 3. Ví dụ về kĩ thuật use case:........................................................................29 Phần 2. Các kỹ thuật phân tích các yêu cầu phần mềm. Sử dụng EA trong phân tích các yêu cầu phần mềm..................................................................................30 I. Requirements Classification:.......................................................................31 1. Yêu cầu chức năng:....................................................................................31 2. Yêu cầu phi chức năng...............................................................................32 II. Conceptual Modeling................................................................................33 III. Architectural Design and Requirements Allocation................................33 IV. Requirements Negotiation.........................................................................34 V. Using the Use Cases.....................................................................................35 VI. Sử dụng EA trong phân tích yêu cầu phần mềm:.................................36 Phần 3: Xây dựng tài liệu đặc tả yêu cầu phần mềm. Sử dụng EA trong hỗ trợ xây dựng các tài liệu đặc tả yêu cầu phần mềm..................................................38 I. Đặc tả yêu cầu phần mềm:.........................................................................38 1. Các lưu ý khi đặc tả yêu cầu phần mềm (SRS):......................................38 1.1. Ghi lại các nguyên tắc của công việc:............................................39 Lê Thị Bích Thuận – CNPM-K52 Page 3 1.2. Đặc tả các yêu cầu phần mềm theo mẫu:.......................................40 1.2.1. Gán nhãn các yêu cầu phần mềm (labeling):...................................40 1.2.2. Đánh dấu những điểm chưa rõ trong đặc tả:...................................40 1.2.3. Mối liên quan giữa đặc tả và giao diện người sử dụng:..................41 1.3. Các mẫu đặc tả yêu cầu phần mềm (SRS template):.....................41 1.4. Đánh giá chất lượng của các gói đặc tả yêu cầu phần mềm hiện đại: 43 1.5. Các phương pháp đặc tả yêu cầu:...................................................43 2. Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm:................................................................................................................44 II. Sử dụng EA trong đặc tả yêu cầu phần mềm........................................47 1. Tạo các yêu cầu phần mềm bên ngoài:....................................................47 2. Tạo các yêu cầu phần mềm bên trong các yêu cầu khác (Internal Requirement):..................................................................................................47 3. Truy vết và liên kết các yêu cầu ngoài.......................................................51 Tài liệu tham khảo:............................................................................................58 Lê Thị Bích Thuận – CNPM-K52 Page 4 Phần 1. Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm. Sử dụng EA trong phát hiện và tổng hợp các yêu cầu phần mềm. TL: Phát hiện các yêu cầu phần mềm: - Phân tích bài toán - Xác định quá trình phát triển các yêu cầu phần mềm - Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm - Xác định các nhóm người sử dụng và đặc tính của họ và đại diện tiêu biểu cho mỗi nhóm - Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm người sử dụng - Xây dựng các đặc tính xác định chất lượng yêu cầu và các yêu cầu khác (yêu cầu phi chức năng) I. Phân tích bài toán - Phân tích bài toán là quá trình tìm hiểu vấn đề thế giới thực và những gì mà người sử dụng cần và gợi ý cách giải quyết để gặp những điều cần đó. - Mục đích của phân tích vấn đề là để thu được sự hiểu biết nhanh hơn, trước khi bắt đầu phát triên, của việc giải quyết vấn đề. - Để nhận biết cái gốc của nguyên nhân, hoặc vấn đề ẩn giấu sau vấn đề, hỏi mọi người trực tiếp tham gia. - Nhận biết tác nhân của hệ thống là một bước khóa trong việc phân tích vấn đề 5 bước cụ thể phải được thực hiện để đạt được mục tiêu: - Dành được sự thoản thuận trên mỗi giải thuyết vấn đề - Hiểu được cái gốc của những nguyên nhân – vấn đề phía sau vấn đề - Nhận biết được đối tác và người sử dụng Lê Thị Bích Thuận – CNPM-K52 Page 5 - Định nghĩa được sự giải đáp cho bao quanh hệ thống - Nhận biết giới hạn được đặt để giải quyết - Bước 1: dành được sự thỏa thuận của giải thuyết vấn đề  Đơn giản viết vấn đề ra và xem liệu tất cả mọi người có đồng ý?  Trạng thái của vấn đề: Table 4-1. Định dạng trạng thái vấn đề Các thành phần Mô tả Vấn đề Mô tả vấn đề Các ảnh hưởng Nhận ra ảnh hưởng của đối tác nhờ vấn đề Kết quả Mô tả sự đụng chạm của vấn đề này lên các bên liên quan và hoạt động kinh doanh Chỉ ra đề nghị gợi ý giải quyết và danh sách Lợi ích các khóa lợi ích - Bước 2: hiểu gốc của nguyên nhân – vấn đề sau vấn đề  Đội của bạn có thể sử dụng các kí thuật khác nhau để thu được sự hiểu biết của một vấn đề thực và nguyên nhân thực sự của nó. Một kĩ thuật gọi là phan tích nguyên nhân gốc, với một cách có hệ thống của vết lộ của gốc, hoặc cơ bản, nguyên nhân của việc nhận biết vấn đề hoặc một dấu hiệu nhận biết của vấn đề. - Bước 3: nhận biết các bên liên quan và người sử dụng  Ai là người sử dụng hệ thống?  Ai là khách hàng của hệ thống?  Những ai sẽ bị ảnh hưởng bởi các kết quả mà hệ thống sản xuất?  Ai sẽ phát triển và đặc biệt hóa hệ thống khi nó được giao hàng và triển khai?  Có phải là còn có những người sử dụng trong hoặc ngoài khác của hệ thống cần phải thêm địa chỉ?  Ai sẽ duy trì hệ thống mới? Lê Thị Bích Thuận – CNPM-K52 Page 6  Còn gì khác nữa không? - Bước 4: định nghĩa được sự giải đáp cho bao quanh hệ thống  Ai sẽ cung cấp, sử dụng, hoặc lấy đi những thông tin từ hệ thống?  Ai sẽ điều khiển hệ thống  Ai sẽ duy trì hệ thống?  Nơi mà hệ thống có thể sẽ được sử dụng?  Nơi mà hệ thống nhận thông tin của nó?  Những hệ thống bên ngoài nào sẽ tương tác với hệ thống? - Bước 5: nhận biết giới hạn giới hạn được đặt để giải quyết:  Giới hạn hệ thống thế năng: kinh tế, chính trị, kĩ thuật, hệ thống, môi trường, chương trình và tài nguyên II. Xác định quá trình phát triển các yêu cầu phần mềm - Xác định các bước tài liệu và mô tả qui trình chúng ta sẽ thực hiện quá trình phát triển các yêu cầu phần mềm - Mô tả phương pháp xác định các người sử dụng trong phạm vi bài toán của phần mềm và các kĩ thuật sẽ được sử dụng để phát hiện các yêu cầu phần mềm - Mô tả các đặc tả hoặc các mô hình phân tích của phần mềm - Các thông tin cho mỗi yêu cầu, trọn số của yêu cầu - Các bước tiến hành phát hieenjcacs yêu cầu, phân tích yêu cầu. III. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm - Khả năng và phạm vi của phần mềm tập hợp các yêu cầu phần mềm ở mức độ cao - Mô tả khả năng, mục tiêu của phần mềm, các phạm vi ứng dụng của phần mềm,các hạn chế của phần mềm, một số đặc điểm của ứng dụng: ai sử dụng, trong môi trường nào Lê Thị Bích Thuận – CNPM-K52 Page 7 - Thông thường tất cả các thông tin ngày được mô tả ngắn gọn trong 3-8 trang theo cấu trúc sau: o yêu cầu phần mềm: mô tả các đặc điểm chính mà phần mềm mới sẽ cung cấp cho khách hàng. Thông thường phần này sẽ rất khác nhau cho những phần mềm khác nhau  Cơ sở (background): mô tả lí do hợp lí cần phát triển phần mềm mới: tại sao, cơ sở nào. Có thể giải thích tổng thế lịch sử hoặc tình huống quyết định cần phải xây dựng phần mềm.  Cơ hội (business opportunity): mô tả cơ hội trên thị trường đang tồn tại vấn đề mà phần mềm sẽ giải quyết. Có thể mô tả ngắn gọn một số phần mềm tương tự và các đặc tính của chúng và giải thích tại sao cần làm phần mềm này.  Đối tượng/ mục tiêu: mô tả mục tiêu mà phần mềm giải quyết  Yêu cầu khách hàng hay yêu cầu thị trường: mô tả các đối tượng khách hàng mà phần mềm sẽ phục vụ  Các giá trị cung cấp cho khách hàng: mô tả chi tiết các khả năng của phần mềm sẽ cung cấp cho khách hàng: khả năng giải quyết công việc, khả năng tiết kiệm, khả năng tự động hóa các công việc trước đây…  Các rủi ro: mô tả các rủi ro của công việc khi phát triển phần mềm, đánh giá các rủi ro và các phương pháp tránh. o Khả năng của phần mềm (vision of solution): mô tả các khả năng của phần mềm. ở đây sẽ không mô tả các chức năng phần mềm.  Các khả năng: mô tả chính xác ngắn gọn các mục đích dài hạn của phần mềm.  Các đặc điểm: danh sách các đặc điểm chính của phần mềm. các đặc điểm này sẽ khác những phần mềm tương tự như thế nào Lê Thị Bích Thuận – CNPM-K52 Page 8  Các phụ thuộc và chấp nhận: ghi nhận lại các phụ thuộc và các chấp nhận đã thực hiện trong phần mềm. o Phạm vi và giới hạn (scope and limitation): mô tả các giới hạn về khả năng của phần mềm. phần mềm chỉ giải quyết bài toán ở mức độ như vậy.  Phạm vi của phiên bản đầu  Phạm vi của các phiên bản tiếp theo  Hạn chế và ngoại lệ o Ngữ cảnh công việc (business context):  Tiểu sử khách hàng: các đặc điểm của khách hàng, phân loại khách hàng.  Các trọng số dự án: chia làm 3 loại: các mục tiêu chính của phần mềm (objectives); các ràng buộc và hạn chế (constraint); mức độ tự do của phần mềm (khả năng cân đối giữa mục tiêu và các ràng buộc) o Các yếu tố thành công của dự án:  Các yếu tố làm dự án khả thi  Các yếu tố chứng tỏ khả năng cạnh tranh của phần mềm. IV. Xác định các nhóm người sử dụng và đặc tính của họ và đại diện tiêu biểu cho mỗi nhóm - Phân lớp người sử dụng phần mềm:  Phân loại theo đặc điểm:  Phân loại theo vị trí địa lí  Phân loại theo vai trò công việc  Phân loại theo chức năng Lê Thị Bích Thuận – CNPM-K52 Page 9  Liệt kê các phân loại (các lớp) và mô tả chi tiết các đặc điểm của người sử dụng ở từng lớp. - Tìm các người sử dụng tiêu biểu (presentative user) - Khái niệm Product Champion: những đại diện tiêu biểu của từng nhóm người sử dụng. trên thực tếc các yêu cầu phần mềm sẽ được phát hiện từ những khách hàng này. V. Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm người sử dụng Nguyên tắc của phát hiện yêu cầu phần mềm: - Định nghĩa phạm vi và giới hạn phần mềm - Xác định các phân nhóm người sử dụng - Xác định các đại diện của từng nhóm - Xác định Product Champion của từng nhóm - Lựa chọn kĩ thuật phát hiện yêu cầu phần mềm - Áp dụng kĩ thuật cho từng đại diện – Product Champion - Xây dựng các tiêu thức chất lượng Lê Thị Bích Thuận – CNPM-K52 Page 10 - Chi tiết hóa (chuyển hóa) các trường hợp sử dụng thành chức năng phần mềm - Xem xét các trường hợp sử dụng và chức năng - Phát triển mô hình phân tích, giải thích và làm rõ với các khách hàng. - Phát triển và đánh giá giao diện cho từng yêu cầu - Phát triển các trường hợp kiểm thử cho các yêu cầu - Sử dụng các trường hợp kiểm thử để kiểm tra - Lặp lại các bước 6-13 trước khi thiết kế. - Phát hiện các yêu cầu phần mềm là một công việc phức tạp - Đây chính lầ cầu nối để giải quyết bài toán - Đây chính là cầu nối giữa phân tích viên và người sử dụng - Đòi hỏi rất nhiều nỗ lực và các phẩm chất của phân tích viên - Một trong những kĩ thuật tiêu biểu để xác định và phát hiện các yêu cầu sử dụng là “use case – trường hợp sử dụng”. Các lỗi thường hoặc là những điểm nên tránh trong phát hiện yêu cầu: - Có quá nhiều use-case - Có các use-case trùng lặp Lê Thị Bích Thuận – CNPM-K52 Page 11 - Trong mô hình use-case xây dựng không được phép dựa vào giao diện với người sử dụng - Định nghĩa dữ liệu trong các use-case - Cố gắng gắn mỗi yêu cầu với một use-case VI. Xây dựng các đặc tính xác định chất lượng yêu cầu và các yêu cầu khác (yêu cầu phi chức năng) Có 6 kĩ thuật phát hiện và tổng hợp các yêu cầu phần mềm(từ phía khách hàng). Đó là: - Interview (Phỏng vấn) - Requirements Workshops (Hội thảo) - Brainstorming and Idea Reduction - Storyboarding - Applying Use Cases - Prototyping Sau đây ta phân tích từng kĩ thuật 1. Interview - Phỏng vấn là một kĩ thuật đơn giản và thu được thông tin một cách trực tiếp. - Các câu hỏi trong ngữ cảnh tự do có thể giúp cho việc phỏng vấn không bị lệch lạc - Có thể tiếp cận để tìm kiếm những mảng yêu cầu chưa được phát hiện bằng cách thăm dò các tình huống. - Hội tụ một số nhu cầu thông thường cần sẽ khởi đầu một “kho chứa các yêu cầu” cho việc sử dụng trong suốt dự án. - Một bản câu hỏi không thay thế cho một buổi phỏng vấn. Cách thức làm như thế nào? - Lập lịch: thời gian, địa điểm. - Thông báo mục đích và phạm vi Lê Thị Bích Thuận – CNPM-K52 Page 12 - Có thể gửi trước một số câu hỏi. - Chuẩn bị tiếp cận một cuộc phỏng vấn trong bối cảnh tự do, và ghi nhanh nó vào một quyển sổ để xem đó là sự tham khảo trong suốt quá trình phỏng vấn. Xem lại những câu hỏi ngay trước khi thực hiện cuộc phỏng vấn. - Trước khi thực hiện phỏng vấn, nghiên cứu kinh nghiệm của nhà đầu tư và công ti được phỏng vấn. Đừng đẩy cho những người được phỏng vấn những câu hỏi mà bạn có thể đã có câu trả lời. Mặt khác, nó không gây thiệt hại cho những câu trả lời với người phỏng vấn. - Trong suốt buổi phỏng vấn, ghi nhanh những câu trả lời vào trong sổ. (Đừng cố gắng để đạt được một dữ liệu điện tử tại thời điểm này) - Chuyển cho người khác những mẫu trong suốt buổi phỏng vấn để bảo đảm rằng những câu hỏi đúng sẽ được trả lời. Đánh giá cuộc phỏng vấn: - Xác định mức độ đầy đủ của các thông tin thu thập. - Xác định hiệu quả của kế hoạch đã lập và mức độ hoàn thành. - Nếu chưa đạt yêu cầu đề ra: xem xét các giải pháp khác để bổ sung thông tin thu thập, rút kinh nghiệm. Ưu điểm của Interview: - quan điểm cá nhân của người dùng thử sẽ được khai thác và ghi nhận - Những hiểu lầm giữa người phỏng vấn và người được phỏng vấn được nhanh chóng sửa lỗi. - Đầu ra: có thể là những thông tin phi thống kê, những ý kiến này sẽ được nghiên cứu, phân tích bởi các chuyên viên có kinh nghiệm. Kĩ thuật interview được sử dụng khi nào? Thường diễn ra trước quá trình thiết kế nhằm thu thập các thông tin, những tri thức về lĩnh vực hoạt động hay những yêu cầu cụ thể. Vấn đề: đòi hỏi người phỏng vấn và phân tích có kinh nghiệm. Lê Thị Bích Thuận – CNPM-K52 Page 13 Lấy một ví dụ như sau: sử dụng kĩ thuật phỏng vấn cho hệ thống máy hướng dẫn khách tham du lịch(ở Hà Nội, chúng ta thấy khá nhiều loại máy như thế này). - Chuẩn bị một danh sách các câu hỏi xem mọi người thực hiện việc việc tham khảo đường như thế nào, và điều gì họ mong muốn ở một hệ thống hướng dẫn khách du lịch tự động? - Phỏng vấn ít nhất 10 người xem họ mong muốn hệ thống hướng dẫn khách du lịch tự động sẽ hoạt động như thế nào - Xác định các yêu cầu, sở thích và thái độ của người phỏng vấn về hệ thống hướng dẫn khách du lịch tự động. - Các yêu cầu khác từ phía người dùng: hình ảnh trực quan, gợi ý gợi nhớ… 2. Requirements Workshops - Có lẽ đây là kĩ thuật công hiệu nhất cho việc phát hiện yêu cầu. - Tập hợp tất cả các nhà đầu tư trong một thời gian ngắn nhưng lại thu hút được sự tập trung mạnh mẽ - Việc sử dụng một người điều khiển bên ngoài có kinh nghiệp trong các quản lí yêu cầu có thể bảo đảm thành công cho buổi meeting - Động não là phần quan trọng nhất của meeting 3. Brainstorming and Idea Reduction - Động não bao gồm cả ý tưởng chung và ý tưởng giảm. - Các sáng tạo nhất, sự phát triển các ý tưởng thường là kết quả từ việc kết hợp nhiều các ý tưởng, mà dường như chúng không liên quan đến nhau. - Những kĩ thuật biểu quyết khác nhau có thể được sử dụng ưu tiên cho các ý tưởng được tạo ra - Mặc dù kĩ thuật động não được ưa thích, web dựa trên sự động não có thể là một sự thay thế trong một vài tính huống. Khi tiến hành động não, cần tuân theo các nguyên tắc cơ bản: Lê Thị Bích Thuận – CNPM-K52 Page 14 - Loại trừ sự chỉ trích, phê bình: Những người tham gia phải từ bỏ các ý kiến phê bình trong suốt quá trình tìm và phát triển ý tưởng của nhóm. - Duy trì bầu không khí hoàn toàn tự do: Các ý tưởng được đưa ra trong bầu không khí càng thoải mái tự do, cởi mở càng tốt. Đồng thời người đề xuất ý tưởng không bị hạn chế về nội dung và không phải chứng minh tính chất đúng đắn cũng như tính hiện thực của ý tưởng. Có nhiều ý tưởng ban đầu trông có vẻ ngớ ngẩn, khác thường nhưng khi thực hiện lại đem lại kết quả vượt trên sự mong đợi. - Số lượng ý tưởng càng nhiều càng tốt: khi càng có nhiều ý tưởng thì càng có nhiều khả năng tìm được những giải pháp hữu ích. - Kết hợp và phát huy ý tưởng của người khác: Trong quá trình phát triển ý tưởng, thành viên có thể đưa ra các ý tưởng riêng dựa trên sự phát triển ý tưởng của người khác. Hoặc có thể kết hợp nhiều ý tưởng thành một ý tưởng mới Có một số trạng thái tâm lí thường xuất hiện trong các hoạt động, cần tránh phạm phải những trạng thái này để không cản trở sự sáng tạo của cá nhân và của toàn nhóm, dưới đây là một số lời khuyên cần ghi nhớ và thực hiện - Đừng cố tìm một câu trả lời đúng: Tùy theo tầm nhìn và sự hiểu biết của mỗi người mà mỗi vấn đề có thể có nhiều câu trả lời đúng, nên đừng cố tìm một câu trả lời đúng nhất - Đừng luôn cố gắng tuân theo logic: Sự hợp lí không phải lúc nào cũng chiếm ưu thế, mà thường có nhiều sự trái ngược giữa tình cảm của con người và nguyên tắc của tổ chức - Đừng tuân theo các nguyên tắc một cách cứng nhắc: Nếu muốn đổi mới và cải tiến thì cần biết nghi ngờ và xem xét những giới hạn không rõ ràng đối với tư duy Lê Thị Bích Thuận – CNPM-K52 Page 15 - Đừng quá lệ thuộc vào hiện thực: Có nhiều ý tưởng không thực tế có thể trở thành nhữnh bàn đạp để sáng tạo - Đừng cố tránh sự không rõ ràng: Sự sáng tạo có thể bị cản trở bởi sự quá khách quan hay cá biệt hoá. - Đừng quá lo sợ và cố tránh thất bại: Sự lo sợ thất bại có thể làm tê liệt quyết tâm thực hiện những ý tưởng hay. - Thêm một chút hồi tưởng: những trò chơi khôi hài thời thơ ấu sẽ có thể là những gợi ý hay cho hiện tại, hoặc một hình tượng đã bắt gặp ở đâu đó cũng có thể là một điểm trong ý tưởng - Tránh tình trạng quá biệt lập: Sự kết hợp chéo giữa các lĩnh vực chuyên môn khác nhau thường rất hữu hiệu trong việc xác định tìm giải pháp. - Đừng quá quan trọng hóa vấn đề: Sự hài hước, không khí thoải mái làm giảm căng thẳng và thúc đẩy khả năng sáng tạo. - Luôn luôn sáng tạo bắt đầu bằng ý tưởng mới: bằng cách nuôi dưỡng những ý tưởng nhỏ bé bình thường và biến những ý tưởng ấy thành hiện thực, chúng ta sẽ có thể phát triển và thực hiện những ý tưởng lớn hơn nhiều trong tương lai. Các qui tắc của kĩ thuật động não: - Loại trừ sự phán xét - Hoan nghênh sự say mê - Cần có số lượng - Cố gắng kết hợp và cải thiện Ngày nay, các qui tắc này vẫn dẫn dắt các phiên họp động não. Hàng ngày, các doanh nghiệp và các tổ chức tiến hành hàng nghìn phiên họp động não. Không thể tính hết lợi ích mà kĩ thuật này mang lại trong việc nâng cao chất lượng cuộc sống thông qua các sản phẩm và dịch vụ mới. Lê Thị Bích Thuận – CNPM-K52 Page 16 Trong những năm gần đây, người ta tiến hành nhiều nghiên cứu để đánh giá hiệu quả của quá trình động não. Từ những nghiên cứu này chúng ta thấy có ba điều kiện quyết định kết quả của các phiên họp động não: Sự tận tâm trong nhóm: những nhóm nào quan tâm đến kết quả của các phiên họp động não sẽ thu được hiệu quả cao hơn các nhóm đầu tư khác. Cơ cấu nhóm: các nhóm khác nhau về nền tảng, kĩ năng và cấp độ tổ chức sẽ hiệu quả hơn các nhóm đồng nhất. Áp lực về sự đồng nhất: tất cả các nhóm đều tạo áp lực đối với thành viên của mình để hướng tới tính đồng nhất. Để có một phiên họp động não hiệu quả thì cần phải giảm những áp lực này đến mức tối thiểu. Và cách giảm những áp lực này là dành thời gian để ý tưởng cá nhân nảy sinh, chia nhóm thành các tiểu nhóm, thường xuyên sắp xếp lại các nhóm và sử dụng khiếu hài hước để khắc phục những trở ngại về giao tiếp và tổ chức. Các kĩ thuật thực hiện động não: Khám phá con đường chưa được khai phá: Khi bạn trải nghiệm những điều mới lạ, quan sát những cái mà bạn chưa từng quan sát bao giờ sẽ cho bạn có được cách nhìn khác về sự vật, sự việc đó. Cũng như việc, hàng ngày bạn đi đi về trên một con đường cố định, hình ảnh xung quanh con đường đó đã trở nên quá quen thuộc với bạn, đến lúc nào đó bạn đi trên con đường khác, quang cảnh mới lạ hoàn toàn, bạn sẽ dễ dàng kiếm được những điều thú vị mà lâu nay bạn không để ý tới. Đường lạ thì bạn dễ bị lạc, khi bạn đang trong trạng thái không biết đường nào để về nhà, bạn phải tự tìm kiếm đường để về, khi đó vô tình bạn lại biết được một đường đi khác nữa. Trong sáng tạo cũng vậy, cứ mãi đi theo một lối mòn khiến cho ta không thể nào tìm được ý tưởng mới. Bởi vậy, hãy cứ đặt mình vào một trường hợp mới mẻ hoàn toàn, suy nghĩ khác đi, dẫn dắt mình đi xa hơn với những gì mình đã từng nghĩ, bạn sẽ tìm được một “con đường” mới lạ có thể dẫn bạn tới mục tiêu một cách tốt hơn. Lê Thị Bích Thuận – CNPM-K52 Page 17 Nhìn vào sự hiển nhiên: trái ngược với kĩ thuật trên, với kĩ thuật này, bạn cần phải quan sát kĩ những thứ bạn nhìn thấy hằng ngày. Ngoài ra bạn cũng nên quan sát từ cách nhìn của người khác. Bạn thử đặt mình vào trường hợp của người khác xem nếu là người ta thì họ sẽ nhìn nhận vấn đề này như thế nào. Hoặc bạn có thể nhìn sự vật, sự việc theo một hướng khác. Với hình ảnh trên bạn nhận thấy điều gì?Cảnh trên chính là hình ảnh của một quán cafe ở Mĩ. Đây chính là hình ảnh một thư viện được nhìn theo một chiều hướng khác. Khi ta bước vào quán café đó, ta sẽ có cảm giác như mình đang đi vào một cái thư viện bị lật ngược vậy. Lê Thị Bích Thuận – CNPM-K52 Page 18 Đặt ra giới hạn và điều kiện, luật lệ: khi tìm hiểu ý tưởng cho một sự vật, sự việc nào đó mà liệt kê một cách tràn lan thì đó không phải là cách hữu hiệu, nó sẽ dẫn dắt bạn đi quá xa. Do đó, bạ nên đặt ra giới hạn và điều kiện khi thực hiện phiên họp động não. Ví dụ khi thực hiện một phiên họp động não về máy vi tính, ta nên chia nhỏ nó ra, giới hạn chỉ tìm hiểu về kiểu dáng hay về chức năng, về cấu hình, cũng có thể đặt ra điều kiện là máy vi tính được sử dụng dành cho độ tuổi nào, sử dụng trong trường hợp nào. Triển khai từng ý nhỏ đó sẽ cho bạn thật nhiều ý tưởng cụ thể, để qua đó tổng hợp lại thành những ý chính cho sản phẩm của mình. Kết hợp các ý tưởng để tạo ra ý tưởng mới: đây là một kĩ thuật rất quan trọng khi tìm kiếm ý tưởng. Hãy lấy một ví dụ đơn giản: có hai hình ảnh, chiếc bút và con mèo. Hai hình ảnh tưởng chừng không liên quan đến nhau. Vậy khi hãy thử kết hợp chúng lại? Chiếc bút có dán hình con mèo? Hình ảnh con mèo cầm chiếc bút? Chiếc bút đặt trên lưng con mèo? Màu sắc của chiếc bút là màu lông con mèo…Có rất nhiều ý tưởng xung quanh con mèo và chiếc bút. Do đó, khi kết hợp hai hay nhiều thứ khác nhau theo chức năng, cấu tạo, màu sắc, kiểu dáng, ta sẽ có được nhiều, rất nhiều ý tưởng, nghe qua có vẻ ngớ ngẩn, nhưng lại có thể giúp bạn cho ra những sản phẩm độc đáo. Siêu đối lập: khai thác những ý tưởng mang tính đối nghịch với vấn đề ta muốn tìm hiểu, cũng là một cách để tìm kiếm ý tưởng theo nhiều hướng khác nhau. Ví dụ tại sao không đặt chiếc thuyền chạy được trên cạn mà lại đặt cho nó chạy dưới nước? Siêu phóng đại: bên cạnh những ý tưởng mang tính đối nghịch như thế, ta lại triển khai theo hướng phóng đại nó lên, nâng giá trị của nó lên gấp nhiều lần, giống như một quả bóng phóng đại lên thì nó là một chiếc khinh khí cầu vậy. Lê Thị Bích Thuận – CNPM-K52 Page 19 Liên kết và quan hệ: với kĩ thuật này, bạn tạo những liên kết tới chủ đề của mình theo một mối quan hệ nào đó. Hãy liệt kê những suy nghĩ đầu tiên khi nghe nói đến chủ đề đó. 4. Storyboarding - Mục đích của storyboarding là phát hiện sớm các tác động “Vâng, nhưng…” - Storyboards có thể bị động, chủ động hoặc là ảnh hưởng lẫn nhau. - Storyboards có thể nhận biết tham gia, giải thích chuyện gì xảy với họ, và mô tả cách thức mà nó xảy ra. - Tạo một phác thảo storyboard, dễ dàng để sửa đổi - Tiến hành storyboard dễ dàng và thường xuyên trên mọi dự án với sự phát triển nội dung mới. Các dạng của storyboards: - Passive storyboards: kể về một câu chuyện của người sử dụng. Có thể bao gồm bức phác thảo, bức tranh, ảnh chụp, hay trang thuyết trình dùng PowerPoint, hoặc là các đầu ra mẫu. - Active storyboard: cố gẳng để làm cho người dùng thấy “một cuộn phim không thể được tạo ra”. Active storyboard là những hoạt động sống động hoặc được tự động hóa, có lẽ bởi một chuỗi các slide thuyết trình tự động hoặc một công cụ hoạt hình hay thậm chí là một bộ phim. - Interactive storyboards: để cho kinh nghiệm người sử dụng hệ thống một cách thực thế, kiểu cư xử thực tế. Đòi hỏi sự tham dự của người sử dụng trong một trật tự thực hiện. Sự ảnh hưởng lẫn nhau của storyboards có thể bắt chước hoặc có thể nâng cao đến điểm thông báo code. 5. Applying Use Cases - Sử dụng use case, giống như storyboards, để nhận ra ai, cái gì và làm thể nào để hệ thống hoạt động. Lê Thị Bích Thuận – CNPM-K52 Page 20 - Use case mô tả sự tương tác giữa một người sử dụng và một hệ thống, chú ý vào cái mà hệ thống làm cho người sử dụng. - Các mẫu use case mô tả tổng quan hoạt động chức năng của hệ thống. - Mô tả cách thức hệ thống “phản ứng” với các sự kiện kích hoạt. - Sự kiện kích hoạt là nguyên nhân thực thi. - Mọi hoạt động của hệ thống là để “phản ứng” lại các sự kiện - Hữu ích trong trường hợp mô tả các yêu cầu nghiệp vụ phức tạp. 6. Prototyping(tạo mẫu) - Tạo mẫu là một kĩ thuật đặc biệt hữu hiệu trong việc đánh địa chỉ “Đúng, nhưng” và hội chứng “chưa tìm thấy sự dổ nát” - Một tạo mẫu yêu cầu phần mềm là một phần thực thi của một phần mềm hệ thống, xây dựng để giúp cho người phát triển, người sử dụng, và khách hàng tốt hơn việc hiểu yêu cầu hệ thống. - Tạo bản mẫu những yêu cầu không rõ ràng: những điều đó, mặc dù được biết hoặc hiểu ngầm, là những định nghĩa chưa được xác định và chưa được hiểu rõ. VII. Sử dụng EA trong phát hiện yêu cầu phần mềm: Một trong những kỹ thuật tiêu biểu để xác định và phát hiện các yêu cầu sử dụng là “Trường hợp sử dụng” (use-case ). Use case là một mô hình UML mô tả cách thức tương tác giữa các tác nhân (actor) và hệ thống: Lê Thị Bích Thuận – CNPM-K52 Page 21 Các thành phần của toolbox và các kí hiệu liên kết sử dụng trong biểu đồ use case Lê Thị Bích Thuận – CNPM-K52 Page 22 1. Các thành phần của use case: 1.1. Actor: - Actor không phải là một phần của hệ thống. Nó thể hiện một người hay một hệ thống khác tương tác với hệ thống. Một actor có thể:  Chỉ cung cấp thông tin cho hệ thống  Chỉ lấy thông tin từ hệ thống  Nhận thông tin từ hệ thống và cung cấp thông tin cho hệ thống. - Thông thường các actor được tìm thấy trong phát biều bài toán bởi sự trao đổi giữa phân tích viên với khách hàng và các chuyên gia trong lĩnh vực. - Có 3 loại actor chính là:  Người dùng: ví dụ: sinh viên, nhân viên, khách hàng…  Hệ thống khác  Sự kiện thời gian. Ví dụ: kết thúc tháng, đến hạn… - Điều gì tạo nên một tập hợp Actor tốt? cần phải cân nhắc kĩ lưỡng khi xác định actor của hệ thống. Công việc này thường được thực hiện lặp đi lặp lại. Danh sách đầu tiên về các actor hiếm khi là danh sách cuối cùng. Lê Thị Bích Thuận – CNPM-K52 Page 23 Ví dụ như trong bài toán đăng kí các môn học của một trường Đại học, có một câu hỏi là liệu các sinh viên mới vào trường là một actor và sinh viên cũ là một actor khác? Giả sử câu trả lời là acos thì bước tiếp theo là xác định xem cách thức mà hai actor này tương tác với hệ thống. Nếu chúng sử dụng hệ thống theo những cách khác nhau thì chúng là hai actor, ngược lại sẽ chỉ là một actor mà thôi. Việc mô tả một cách ngắn gọn về mỗi actor cần thêm vào mô hình. Mô tả này cần chỉ rõ vai trò của actor khi tương tác với hệ thống. Ví dụ: sinh viên là những người đăng kí các lớp ở trường đại học. 1.2. Use case - Một use case xác định một tập các thể hiện use case - Trong đó mỗi thể hiện là một chuỗi các hành động được hệ thống thực hiện và đem lại một kết quả thấy được có ý nghĩa đối với một actor cụ thể nào đó. Đặc tả use case: - Tóm tắt - Dòng sự kiện phụ: các sự kiện và những hoạt động bất thường của use case ngoài những hoạt động chính. - Các yêu cầu đặc biệt - Pre-condition(tiền điều kiện): mô tả trạng thái của hệ thống phải đạt được để use case có thể bắt đầu Lê Thị Bích Thuận – CNPM-K52 Page 24 - Post-conditions (hậu điều kiện): liệt kê các trạng thái có thể của hệ thống tại cuối use case. Hệ thống phải thuộc một trong những trạng thái đó khi use case kết thúc. - Điểm mở rộng Khi sử dụng usecase ta thể hiện được mối quan hệ giữa: - Actor- actor - Actor- use case - Use case- use case 1.3. Collaboration Collaboration (hợp tác) xác định một tập các vai trò (role) và sự liên kết giữa chúng. Một Collaboration chỉ nên xác định vai trò và thuộc tính cần thiết để hoàn thành một nhiệm vụ hoặc chức năng cụ thể Lê Thị Bích Thuận – CNPM-K52 Page 25 1.4. Boundary: Boundary dùng để phân biệt ranh giới , chẳng hạn các thành phần hay các hệ thống phụ , nhưng vẫn bao quát trong đó một use case 1.5. Package: Lê Thị Bích Thuận – CNPM-K52 Page 26 - Package Diagrams được sử dụng để phản ánh tổ chức của packages và các elements của chúng. Khi được sử dụng để trình bày các elements class trong các package diagram thường cung cấp cái nhìn về các namespaces. Điểm chung nhất sử dụng package diagrams là để sử dụng chúng nhằm mục đích tổ chức use – case Diagrams và Class diagrams, mặc dù sử dụng package diagrams không bị giới hạn trong các elements UML này 2. Use case diagram connectors: 2.1. Use: 2.2. Associate Lê Thị Bích Thuận – CNPM-K52 Page 27 2.3. Generalize 2.4. Include: 2.5. Extend 2.6. Realize: Lê Thị Bích Thuận – CNPM-K52 Page 28 Biểu diễn cho việc thiết kế use case. Cần tách riêng use case và usecase hiện thực nhờ đó có thể quản lí chúng một cách riêng biệt  có thể thay đổi use case thiết kế mà không ảnh hưởng đến use case gốc. 2.7. Invokes 2.8. precedes 3. Ví dụ về kĩ thuật use case: Lê Thị Bích Thuận – CNPM-K52 Page 29 Phần 2. Các kỹ thuật phân tích các yêu cầu phần mềm. Sử dụng EA trong phân tích các yêu cầu phần mềm TL: Yêu cầu phần mềm là tất cả các yêu cầu về phần mềm do khách hàng – người sử dụng phần mềm- nêu ra, bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác. Mục đích của yêu cầu phần mềm là xác định được phần mềm đáp ứng được các yêu cầu và mong muốn của khách hàng- người sử dụng phần mềm. Các kĩ thuật phân tích các yêu cầu phần mềm: - Requirements Classification (Phân loại yêu cầu) - Conceptual Modeling (Mô hình hóa các khái niệm) Lê Thị Bích Thuận – CNPM-K52 Page 30 - Architectural Design and Requirements Allocation (Thiết kế kiến trúc và phân bổ yêu cầu) - Requirements Negotiation (Thương lượng yêu cầu) - Use case I. Requirements Classification: Như đã thấy trên, việc phân loại các yêu cầu được chia theo các yêu cầu phần mềm và các thiết kế, ta đi vào phân tích các yêu cầu phần mềm: gồm yêu cầu chức năng và yêu cầu phi chưc năng. 1. Yêu cầu chức năng: - Yêu cầu chức năng biểu diễn cách thức mà hệ thống hoạt động. Những yêu cầu này thường xuyên được hành động theo định hướng. - Chúng thường quan hệ với những nguồn đặc trưng, thường là các use-case hay những qui tắc nghiệp vụ (business rule) - Một số yêu cầu chức năng:  Chức năng tính toán  Chức năng lưu trữ Lê Thị Bích Thuận – CNPM-K52 Page 31  Chức năng tìm kiếm  Chức năng kết xuất  Chức năng backup, restore  Chức năng đa người dùng  Chức năng đa phương tiện… 2. Yêu cầu phi chức năng - Khả năng dùng được - Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ… - Hiệu năng - Tính hỗ trợ, các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình… - Yêu cầu của người sử dụng: dễ sử dụng, thân thiện - Ràng buộc về ngân sách - Phù hợp với các chính sách của tổ chức sử dụng hệ thống - Yêu cầu tương thích giữa phần cứng và phần mềm - Các yêu cầu từ các tác nhân ngoài. II. Conceptual Modeling Lê Thị Bích Thuận – CNPM-K52 Page 32 - Sự phát triển của các mô hình của một vấn đề thực tế là chìa khóa của phân tích yêu cầu phần mềm. Mục đích cuả chúng là hỗ trợ để hiểu những vấn đề, chứ không phải là để bắt đầu thiết kế các giải pháp. Kể từ đây, mô hình hóa các khái niệm bao gồm mô hình của các thực thể từ các miền vấn đề cấu hình để phản ánh thực tế của mối quan hệ và phụ thuộc. - Một vài loại mô hình có thể được phát triển. Chúng bao gồm dữ liệu và kiểm soát dòng chảy, trạng thái của mô hình, dấu vết sự kiện, tương tác người dùng, mô hình đối tượng, mô hình dữ liệu, và nhiều thể loại khác nữa. - Một vài loại mô hình có thể được phát triển. Các yếu tố ảnh hưởng đến việc lựa chọn các mô hình bao gồm:  Bản chất của vấn đề. Một số loại yêu cầu phần mềm chắc chắn một khía cạnh được phân tích một cách riêng biệt.  Khả năng chuyên môn của kĩ sư phần mềm. Nó thường được sản xuất nhiều hơn để chấp nhận một kí pháp hoặc một phương thức với những kĩ sư phần mềm có kinh nghiệm.  Quá trình yêu cầu của khách hàng.  Tính khả dụng của các phương thức và công cụ. III. Architectural Design and Requirements Allocation - Tại một số điểm, kiến trúc của giải pháp này phải được dẫn xuất. Thiết kế kiến trúc là một điểm mà tại đó, những quá trình yêu cầu đè lên với phần mềm hoặc thiết kế hệ thống, và minh họa cách thức không thể tách riêng ra hai nhiệm vụ một cách rõ ràng. - Trong nhiều trường hợp, kĩ sư phần mềm hoạt động như kiến trúc sư phần mềm bởi vì quá trình phân tích và xây dựng nhu cầu yêu cầu kĩ lưỡng mà các thành phần sẽ có trách nhiệm trong việc đáp ứng các yêu cầu được nhận biết. Việc phân vùng yêu cầu – sự phân công, tới các thành phần, của trách nhiệm đáp ứng các yêu cầu. Lê Thị Bích Thuận – CNPM-K52 Page 33 - Sự phân vùng là quan trọng cho phép các thiết kế chi tiết của yêu cầu. Một ví dụ, một bộ phận của yêu cầu được phân vùng thành một thành phần, các yêu cầu cá nhân có thể được tiếp tục phân tích để tìm ra những yêu cầu trong điều kiện những thành phần cần để tương tác với những thành phần khác trong một trật tự để đáp ứng sự phân vùng yêu cầu. Trong những dự án lớn, sự phân vùng kích thích một vòng tròn mới của phân tích cho mỗi hệ thống con. - Nhắc lại yêu cầu và thiết kế - Sử dụng yêu cầu cha-con để tăng tính đặc thù. - Thiết kế kiến trúc được xây dựng chặt chẽ với mô hình khái niệm. Việc ánh xạ từ miền thực thể thực đến thành phần phần mềm không phải lúc nào cũng rõ ràng, bởi vậy thiết kế kiến trúc được xác định là một chủ đề riêng biệt. Nói chung, những yêu cầu của kí pháp hay phương thức là như nhau cho cả mô hình khái niệm và thiết kế kiến trúc. - Chuẩn IEEE (1471-2000), kiến nghị thực tiễn cho mô tả kiến trúc của hệ thống tập trung phần mềm, yêu cầu một cách tiếp cận đa điểm nhìn để mô tả kiến trúc của hệ thống và mặt hàng phần mềm của họ. IV. Requirements Negotiation Một thuật ngữ khác thường được dùng cho chủ đề nhỏ này là “giải quyết xung đột”. Điều này quan tâm giải quyết vấn đề với các yêu cầu nơi mà xung đột xảy ra giữa hai bên liên quan cần tính năng không tương thích lẫn nhau, giữa những yêu cầu và mã nguồn, hoặc giữa những yêu cầu chức năng và yêu cầu phi chức năng. Trong hầu hết các trường hợp, thật là dại dột cho các kĩ sư phần mềm thực hiện một quyết định đơn phương, và bởi vậy điều đó trở thành cần thiết để hỏi yes kiến các bên liên quan để đạt được một sự thỏa thuận chung. Điều này thường quan trọng vì những lí do hợp đồng mà quyết định đó được theo dõi trở lại khách hàng. Ta có sự phân loại điều này giống như một chủ đề phân tích yêu Lê Thị Bích Thuận – CNPM-K52 Page 34 cầu phần mềm bời vì những vấn đề lộ ra như kết quả của sự phân tích. Tuy nhiên, một trường hợp mạnh có thể cũng được tạo ra do sự cân nhắc một chủ đề chứng thực các yêu cầu. V. Using the Use Cases - Để hỗ trợ việc thiết kế và hoạt động mã hóa, các use case được phát triển trong các hoạt động phải được xây dựng đầy đủ hơn. - Các trường hợp sử dụng là thích hợp nhất khi hệ thống giàu chức năng và phải hỗ trợ những kiểu khác nhau của người sử dụng. - Các trường hợp sử dụng không có công hiệu khi áp dụng cho hệ thống với một ít hoặc không có người sử dụng và giao diện tối thiểu, chủ yếu là những yêu cầu phi chức năng và hạn chế thiết kế. Các đặc tính chất lượng đối với người sử dụng: - Availability (đáp ứng) - Efficiency (hiệu quả) - Flexibility (mềm dẻo) - Intergritiy (bảo mật) - Interoperability (khả năng kết hợp với hệ thống) - Robustness( khả năng kiểm soát các dữ liệu không chính xác) - Usablility(dễ sử dụng) Các đặc tính chất lượng đối với người phát triển: - Maintainablility ( bảo dưỡng) - Portability (mềm dẻo) - Testability (bảo mật)  Tổng hợp có 12 thuộc tính chất lượng  Cần phải cân bằng các thuộc tính chất lượng VI. Sử dụng EA trong phân tích yêu cầu phần mềm: 1. Sử dụng EA hỗ trợ phân tích yêu cầu phần mềm: Lê Thị Bích Thuận – CNPM-K52 Page 35 Xem xét cấu trúc phân cấp và cài đặt của yêu cầu phần mềm Sử dụng cửa sổ Hierachy. Khi lựa chọn 1 Requirement, ta sẽ xem được các thông tin về: - Quan hệ phân cấp của Requirement: cho biết nó là con của các Requirement nào, cha của các Reqiurement nào, quan hệ thuộc loại nào (sở hữu hay kết tập) … - Quan hệ về cài đặt của Requirement: nó được cài đặt bởi các Element nào. Nếu Requirement có các Requirement con, EA có thể chi tiết việc cài đặt của từng Requirement con đó. - Quản lý thay đổi:  Sử dụng cửa sổ Audit View: ghi chép lại các thay đổi đã thực hiện.  Kích hoạt Audit View:  Mở cửa sổ Audit View  Chọn Audit Settings  Enable Auditing - Lập báo cáo Sử dụng menu Project | Documentation  Lập các báo cáo đặc tả thông thường : thông tin về Requirement và các Requirement con tương ứng. Có nhiều định dạng văn bản khác nhau như: Rich Text Format, HTML,…  Báo cáo quan hệ cài đặt  Báo cáo quan hệ phụ thuộc Lê Thị Bích Thuận – CNPM-K52 Page 36 2. Sử dụng EA hỗ trợ mô hình hóa yêu cầu phần mềm. - Xây dựng cấu trúc phân cấp của các Requirement: Với chức năng này, ta có thể xây dựng được cấu trúc phân cấp cho Requirement: 1 requirement lớn có thể bao gồm nhiều Reqiurement nhỏ hơn. Khi muốn chuyển 1 Requirement thành con của 1 Requirement khác, trong cửa sổ Project Browser, ta rê rồi thả Requirement-con vào Requirement-cha. Lê Thị Bích Thuận – CNPM-K52 Page 37 Các Requirement này liên hệ với nhau bằng quan hệ sở hữu ( owns – owned by ) Phần 3: Xây dựng tài liệu đặc tả yêu cầu phần mềm. Sử dụng EA trong hỗ trợ xây dựng các tài liệu đặc tả yêu cầu phần mềm I. Đặc tả yêu cầu phần mềm: - Không phụ thuộc các yêu cầu phần mềm được tìm ra, được xây dựng như thế nào, cuối cùng bao giờ chúng ta cũng phải đặc tả các yêu cầu này. - Các tiêu thức để đánh giá một đặc tả: tính nhất quán, tính thân thiện, dễ sử dụng. - Trong đặc tả phải nêu được cả business requirement (yêu cầu về công việc), phạm vi ứng dụng, giới hạn của ứng dụng. - Trong đặc tả phải nêu được đầy đủ các yêu cầu người sử dụng, sử dụng các mẫu của các trường hợp sử dụng của từng yêu cầu. 1. Các lưu ý khi đặc tả yêu cầu phần mềm (SRS): Lê Thị Bích Thuận – CNPM-K52 Page 38 - Làm theo và sử dụng các mẫu đặc tả: nên qui định một mẫu đặc tả chung trong tổ chức, sử dụng một số mẫu nào đó: IEEE 830-1998. Lưu ý rằng hoàn toàn có quyền sửa đổi qui định lại các biểu mẫu nếu như điều đó là cần thiết. - Xác định rõ nguồn gốc của yêu cầu phần mềm trong đặc tả: để có thể tất các biết được tại sao lại phát sinh các yêu cầu phần mềm này, ta nên chỉ rõ tại sao lại có- từ người sử dụng, yêu cầu chức năng hệ thống, do qui chế, hay do các nguồn khác. - Đặt nhãn cho từng yêu cầu phần mềm: nên thống nhất qui ước cách đặt nhãn cho các yêu cầu – nên đặt nhãn làm sao nhãn của các yêu cầu mang nhiều các thông tin về các yêu cầu đó càng tốt. - Ghi lại các nguyên tắc của công việc: các nguyên lí hoạt động của hệ thống, của các thao tác, công việc cần được miêu tả. - Nên tạo ra ma trận theo dõi các yêu cầu phần mềm: điều này rất có ích trong quá trình phân tích các yêu cầu, quá trình thiết kế, lập trình và kiểm thử các chức năng của hệ thống. Ma trận này cũng rất có ích giúp cho chúng ta liên kết các chức năng với các yêu cầu phần mềm liên quan. Nên sử dụng thường xuyên ma trận trong suốt thời gian phát triển phần mềm. 1.1. Ghi lại các nguyên tắc của công việc: - Khi người sử dụng miêu ta cho ta một hoạt động nào đó chỉ được thực hiện trong những điều kiện nhất định, do những tác nhân nhất định, tức là ta đã có một nguyên tắc công việc. - Nguyên tắc công việc là tập hợp các nguyên tắc hoạt động của quá trình thực hiên công việc. - Chúng ta có nghĩ vụ phải xây dựng các yêu cầu hệ thống về mặt chức năng để đáp ứng các nguyên tắc công việc này – tuy nhiên không nên đồng nhất yêu cầu chức năng với nguyên tắc công việc. Lê Thị Bích Thuận – CNPM-K52 Page 39 - Trong SRS nên tập hợp và đặc tả tất cả các nguyên tắc của công việc vào một mục riêng. 1.2. Đặc tả các yêu cầu phần mềm theo mẫu: - Có thể nó đặc tả yêu cầu phần mềm (SRS) được coi như: đặc tả chức năng hệ thống, sự thỏa thuận về chức năng, đặc tả hệ thống. - SRS lầ cơ sở cho mọi hoạt động của dự án: phân tích, thiết kế, lập kế hoạch, viết mã, kiểm thử… - Khi đặc tả yêu cầu phần mềm có thể sử dụng các công cụ:  Văn bản (textual document)  Mô hình đồ họa (graphical models)  Các ngôn ngữ đặc tả hình thức - Các điểm lưu ý:  Tất cả các yêu cầu phần mềm phải được đưa vào đặc tả  SRS được xây dựng trước khi phân tích và xây dựng phần mềm. 1.2.1. Gán nhãn các yêu cầu phần mềm (labeling): Để có được một đặc tả tốt, có thể theo dõi mối liên quan giữa các yêu cầu, quá trình phát sinh ra chúng, ta cần có một qui định gán nhãn các yêu cầu một cách khoa học. Có một số phương pháp thông dụng: - Gán nhãn liên tiếp (sequence number): UR – xxxx - Gán nhãn theo thứ bậc (Hierarchical numbering): UR 3.2.1 (phương pháp này được sử dụng rộng rãi nhất) - Gán nhãn theo tên thẻ thứ bậc (Hierachical texttual tags): Print. Copies. Confirm 1.2.2. Đánh dấu những điểm chưa rõ trong đặc tả: Đôi khi chúng ta thiếu một số các thông tin về các yêu cầu phần mềm, chúng ta cần thảo luận với người sử dụng để biết chi tiết hơn. Tất cả những chỗ như Lê Thị Bích Thuận – CNPM-K52 Page 40 vậy nên được đánh dấu bằng “To be determined” –TBD. Như vậy chúng ta đã phân rõ những điểm thiếu (gaps) trong đặc tả để cần là sáng tỏ. Tất cả các TBD này phải được giải quyết trước khi bắt đầu quá trình phân tích và xây dựng phần mềm. 1.2.3. Mối liên quan giữa đặc tả và giao diện người sử dụng: Sự kết hợp giữa thiết kế giao diện trong SRS có cả ưu điểm và nhược điểm: Nhược điểm: - Các yêu cầu về giao diện thực chất chỉ là các giải pháp mà không phải là các yêu cầu phần mềm. - Quá trình xây dựng các yêu cầu sẽ kéo dài - Người sử dụng, khách hàng có thể tốn rất nhiều thời gian với giao diện mà quên đi nhiệm vụ chính của họ là giúp chúng ta xây dựng các yêu cầu phần mềm. - Các giao diện xây dựng ở giai đoạn này chỉ mang tính chất định hướng. Ưu điểm: - Có khả nang trau chuốt các yêu cầu phần mềm, xây dựng các tương tác trở nên hữu hình và dễ hiểu hơn cho cả khách hàng và cả phát triển viên - Trợ giúp tốt hơn cho việc lập kế hoạch và đánh giá khối lượng công việc. Kết luận ở đây là nên sử dụng một số giao diện chuẩn hoặc các mô hình giao diện ở mức độ vừa phải để đưa vào đặc tả: mô hình chung của các giao diện nhập liệu, các giao diện – màn hình xử lí, giao diện – màn hình hiển thị, các hộp thoại… 1.3. Các mẫu đặc tả yêu cầu phần mềm (SRS template): - Mỗi tổ chức, công ti phần mềm đều cần xây dựng các SRS template của mình - Một số phiên bản của SRS template được khuyến nghị nên sử dụng: Lê Thị Bích Thuận – CNPM-K52 Page 41  Robertson and Robertson 1999  IEEE 830- 1998 - Các SRS template là các tài liệu có cấu trúc tốt, mềm dẻo, có khả năng tùy biến được theo yêu cầu cảu mỗi công ti phần mềm. IEEE 830-1998 điều chỉnh và mở rộng mẫu:  Introduction (Giới thiệu): - Purpose of this document (Mục đích của tài liệu này) - Document Convention (Qui ước của tài liệu) - Intended Audience and Reading Suggestion (Khán giả dự kiến và Đề nghị đọc) - Product Scope (Chi phí sản xuất) - References (Tham khảo)  Overall Description (Mô tả tổng quan): - Product Perspective (Viễn cảnh sản phẩm) - Product Functions (Chức năng sản phẩm) - User Characteristics (Đặc tính người sử dụng) - Operating Environment (Môi trường vận hành) - Design and Implementation Constraints (Giới hạn thiết kế và thực thi) - Assumptions and Dependencies (Các giả định và phụ thuộc)  External Interface Requirement (Yêu cầu giao diện bên ngoài): - User Interface (Giao diện người dùng) - Hardware Interface (Giao diện phần cứng) - Software Interface (Giao diện phần mềm) - Communication Interface (Giao diện giao tiếp)  System Features (Tính năng hệ thống): - System Feature X:  4.x.1. Description and Priority (Mô tả và quyền ưu tiên) Lê Thị Bích Thuận – CNPM-K52 Page 42  4.x.2. Stimulus/Response Sequences (Chuỗi kích thích/Chuỗi trả lời)  4.x.3. Functional Requirement (Yêu cầu chức năng)  Other Nont- Functional Requirement - Performance Requirement (Yêu cầu đặc trưng) - Safety Requirement (Yêu cầu an toàn) - Security Requirement (Yêu cầu bảo mật) - Software Rules (Các qui tắc phần mềm) - User Documentation (Tài liệu người dùng)  Other Requirement (các yêu cầu khác) - Appendix A: Glossary (Từ điển thuật ngữ) - Appendix B: Analysis Model (Phân tích Mô hình) - Appendix C: To – Be – Determined List (Danh sách quyết định) 1.4. Đánh giá chất lượng của các gói đặc tả yêu cầu phần mềm hiện đại: - Một nội dung bản tốt - Một chỉ số tốt - Một lịch sử chỉnh sửa:  Số lượng chỉnh sửa hoặc mã hóa cho mỗi sự thay đổi các thông tin được công bố.  Ngày tháng của mỗi lần sửa đổi thông tin được công bố  Một bản tóm tắt ngắn của những lần sửa đổi được tạo để công bố thông tin  Tên của người chịu trách nhiệm việc sửa đổi được công bố.  Một từ điển thuật ngữ. 1.5. Các phương pháp đặc tả yêu cầu: Lê Thị Bích Thuận – CNPM-K52 Page 43 - Khi việc mô tả các yêu cầu là quá phức tạp với ngôn ngữ tự nhiên hoặc nếu bạn không thể có đủ thì giờ để có đặc tả mối bất hòa, thì cần phải có phương pháp để đặc tả các yêu cầu một cách thích hợp. - Những phương pháp này bao gồm mã giả, cây quyết định, biều đồ hoạt động, mô hình thực thể liên kết, phân tích hướng đối tượng, và phân tích hướng cấu trúc. - Chúng ta có thể chọn từ một loạt trạng thái khác nhau của kĩ thuật đặc tả: mã giả, cây quyết định, biểu đồ hoạt động, mô hình thực thể liên kết, phân tích hướng cấu trúc, và phân tích hướng đối tượng. 2. Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm: Các nguyên tắc chỉ đạo khi viết đặc tả: - Cố gắng viết các câu và đoạn văn ngắn gọn, không dài dòng - Sử dụng các từ điển thuật ngữ dễ hiểu, đã có trong Glossary - Viết các câu văn trong sáng, đúng ngữ pháp - Tránh sử dụng những từ mang tính chất quảng cáo, giao diện thân thiện, hệ thống hoạt động hiệu quả, một cách chung chung mà cần chỉ rõ như thế nào là thân thiện, như thế nào là hiệu quả - Tránh sử dụng những tính từ so sánh: tốt hơn nhất là nên chỉ ra rõ ràng các tiêu thức đánh giá trong đặc tả. Theo dõi yêu cầu: - Theo dõi dấu vết của một yêu cầu phần mềm cho phép chúng ta quản lí được các yêu cầu phần mềm này, nguồn gốc của nó, các mối liên quan của nó và cách thực hiện kiểm thử, bảo dưỡng và phát triển nó. - Tồn tại bốn thao tác với quá trình theo dõi dấu vết của một yêu cầu phần mềm:  Forward to Requirement (Đặt ở trước yêu cầu)  Backward from Requirement (Đặt ở sau từ yêu cầu) Lê Thị Bích Thuận – CNPM-K52 Page 44  Forward from Requirement (Đặt ở trước từ yêu cầu)  Backward to Requirement (Đặt ở sau yêu cầu) Tại sao cần theo dõi yêu cầu? Lê Thị Bích Thuận – CNPM-K52 Page 45 - Tính chứng nhận (certification): xác thực tất cả các chức năng đã được thực hiện - Khả năng phân tích phần mềm tốt hơn (change impact analysis) - Khả năng bảo dưỡng phần mềm tốt hơn (maintenance) - Khả năng theo dõi quản lí, hiệu chỉnh dự án tốt hơn (project tracking) - Khả năng phát triển hệ thống: Reengineering - Khả năng tái sử dụng (reuse) - Khả năng giảm rủi ro (Risk Reduce) - Khả năng kiểm thử (Testing) Ma trận theo dõi các yêu cầu phần mềm: - Phương pháp hay được sử dụng nhất để liên kết các yêu cầu phần mềm và các thành phần khác của hệ thống là sử dụng ma trận theo dõi các yêu cầu phần mềm - Các liên kết này thường được thể hiện giữa các thành phần:  Các trường hợp sử dụng (yêu cầu phần mềm)  Các yêu cầu chức năng (functional requirement)  Các thành phần thiết kế (design element)  Mã chương trình (code)  Trường hợp kiểm thử (test case) - Các mối liên kết co thể được phân chia:  Một – Một  Một – Nhiều  Nhiều – Nhiều - Các dạng biểu diễn ma trận:  Lập bảng liên kết  Lập ma trận liên kết Quá trình lập ma trận: Lê Thị Bích Thuận – CNPM-K52 Page 46 - Xác định các mối liên kết và các khả nang lập ma trận - Chọn dạng ma trận: tổng hợp hay chi tiết - Chọn các chức năng/ các yêu cầu cần theo dõi - Xác định phương pháp gán nhãn các yêu cầu - Xác định nguồn các thông tin về các yêu cầu phục vụ cho sự liên kết - Thông báo cho những người tham gia về sự liên kết - Kiểm soát sự liên kết trong quá trình phát triển phần mềm. II. Sử dụng EA trong đặc tả yêu cầu phần mềm 1. Tạo các yêu cầu phần mềm bên ngoài: 2. Tạo các yêu cầu phần mềm bên trong các yêu cầu khác (Internal Requirement): - Ta có thể tạo ra các yêu cầu phần mềm bên trong 1 Element khác như Usecase, Class,… để chỉ ra rằng Element đó có nhiệm vụ cài đặt các yêu cầu đã nêu. - Để thực hiện việc này, ta thực hiện như sau:  Mở hộp thoại Properties của Element.  Chọn Require (hoặc ấn tổ hợp phím Alt + Enter)  Nhập tên Requirement và các thuộc tính của nó.  Có thể thực hiện các thao tác quản lý khác ( sắp xếp, sửa, xóa )  Bấm OK để đóng hộp thoại Tham khảo hình minh họa dưới đây Lê Thị Bích Thuận – CNPM-K52 Page 47 - Chuyển yêu cầu bên trong ra ngoài:  Dùng chuột nháy vào chữ package góc trên bên trái  Ra vùng bên cạnh nháy chuột trái  Chọn thẻ Require (hình vẽ dưới)  Giao diện như hình dưới đây: Lê Thị Bích Thuận – CNPM-K52 Page 48 - EA cho phép bạn nhập các yêu cầu ở cấp độ một đối tượng UML riêng rẽ. Ở cấp độ này những yêu cầu này được coi là “trách nhiệm” của đối tượng Lê Thị Bích Thuận – CNPM-K52 Page 49 - Việc xác định các yêu cầu nội tại trong các đối tượng UML, chẳng hạn Use Case, đưa ra một sự mở đầu đơn giản để xác định các yêu cầu phức tạp hơn, sử dụng mô hình UML nói chung - Quản lý các thuộc tính cơ bản của yêu cầu: Các thuộc tính cơ bản của yêu cầu được quản lý trong EA:  Tên  Trạng thái thực hiện (đề xuất, đã phê chuẩn, đang cài đặt, bắt buộc, đã kiểm tra)  Độ khó  Độ ưu tiên Lê Thị Bích Thuận – CNPM-K52 Page 50  Loại yêu cầu ( Chức năng, hiển thị, báo cáo, kiểm thử , …)  Ghi chú  Các thông tin khác - Khi muốn chuyển 1 Requirement thành con của 1 Requirement khác, trong cửa sổ Project Browser, ta rê rồi thả Requirement-con vào Requirement-cha. - Với chức năng này, ta có thể xây dựng được cấu trúc phân cấp cho Requirement: 1 requirement lớn có thể bao gồm nhiều Reqiurement nhỏ hơn 3. Truy vết và liên kết các yêu cầu ngoài Trong EA, có ba phương pháp chính được sử dụng để theo dõi và hình thành các mối quan hệ giữa các yêu cầu ngoài và các yếu tố khác. Ba cách đó là: - Tạo và xem các mối quan hệ sử dụng biểu đồ - Tạo và xem các mối quan hệ bằng cách sử dụng các ma trận quan hệ - Truy xuất các quan hệ sử dụng Tracebility View Tạo các quan hệ bằng cách sử dụng sơ đồ: Việc tạo quan hệ giữa các đối tượng trên biểu đồ là một quy trình đơn giản trong EA. Một phương pháp kéo thả từ đối tượng nguồn đến đích được sử dụng để xác định các mối quan hệ: - Thêm hai đối tượng yêu cầu phần mềm vào sơ đồ: Lê Thị Bích Thuận – CNPM-K52 Page 51 - Chọn một loại quan hệ bạn muốn tạo ra ở nửa dưới của bản tùy chỉnh (ví dụ Kết Tập): - Click và giữ chuột trái ở đối tượng nguồn: - Kéo chuột đến đối tượng đích sau đó thả : Lê Thị Bích Thuận – CNPM-K52 Page 52 Các loại quan hệ: - Kết tập (Aggregation): Các yêu cầu được liên kết bởi mối quan hệ kết tập tạo thành một cấu trúc phân cấp. Các yêu cầu cao cấp có thể bao gồm nhiều yêu cầu cấp dưới, mà lần lượt tạo thành từ các yêu cầu tốt hơn và chi tiết hơn. Cấu trúc phân cấp này giúp quản lí sự phức tạp của các hệ thống lớn với hàng ngàn yêu cầu và nhiều đối tượng được sử dụng để thực thi các yêu cầu - Thực thi (Realization): các yêu cầu được thực thi bới các mô hình đối tượng, chẳng hạn use case, class, interface, component … Bạn có thể chỉ định các mối quan hệ này trong EA sử dụng liên kết thực thi. Một mô hình đối tượng được đánh dấu như “thực thi” một yêu cầu phần mềm. Ma trận quan hệ: - Ma trận quan hệ cho phép tạo và xem các mối quan hệ, bất kể các sơ đồ hoặc các gói các yếu tố đặt trong nó. Nó có thể sử dụng bất kì đối tượng UML nào, nhưng nó đặc biệt hữu ích với quản lí yêu cầu phần mềm vì 2 lí do sau:  Với một định nghĩa hệ thống lớn, sẽ có các yêu cầu được xác định trong cách package và sơ đồ khác nhau mà có thể có mối quan hệ phụ thuộc với nhau. Ma trận quan hệ có thể được sử dụng để định nghĩa các mối quan hệ mà không cần phải định nghĩa bằng tay trong sơ đồ.  Với các giai đoạn phát triển, mỗi yếu tố theo các yêu cầu, ví dụ use case, class… cần phải xác định nguồn gốc bởi một yêu cầu cụ thể hoặc một nhóm yêu cầu, điều này quan trọng để truy xuất nguồn gốc. Tạo hai package, cho hai yêu cầu vào hai package: Lê Thị Bích Thuận – CNPM-K52 Page 53 Để xem ma trận quan hệ, chọn (View| Relationship Matrix) từ menu phía trên màn hình Lê Thị Bích Thuận – CNPM-K52 Page 54 Thêm một quan hệ giữa các yêu cầu bằng cách sử dụng Ma trận quan hệ: - Di chuột và mở biểu đồ các yêu cầu chức năng - Thêm một yêu cầu mới với mô tả: - Di chuột và mở biểu đồ các yêu cầu phi chức năng - Thêm một yêu cầu mới với mô tả “Phải hợp khung nhìn và cảm nhận”. Vì hai yêu cầu là liên quan nên mối quan hệ được xác định - Chọn mối quan hệ bạn muốn tạo từ tùy chọn Link Type (ví dụ Kết tập) - Chuột phải vào khu vực 2 yêu cầu chồng lên nhau và chọn Create new relationship. - Chuột phải lần nữa cho các tùy chọn quan hệ xa hơn Lê Thị Bích Thuận – CNPM-K52 Page 55 Sử dụng cửa sổ truy vết: Cửa sổ truy vết cho phép bạn xem mối quan hệ giữa các yêu cầu. Để sử dụng cửa sổ truy vết: - Mở cửa sổ truy vết (View|Hierarchy hoặc Ctrl+Shift+4): Lê Thị Bích Thuận – CNPM-K52 Page 56 - Chọn một đối tượng để hiển thị quan hệ Lê Thị Bích Thuận – CNPM-K52 Page 57 Tài liệu tham khảo: - Slide thầy Huỳnh Quyết Thắng - Slide phân tích thiết kế hệ thống thông tin – cô Vũ Tuyết Trinh - http://www.hieuhoc.com/camnanghoctap/chitiet/phuong-phap-lam-viectheo-nhom-phan-2-phuong-phap-giai-quyet-van-de-2008-08-15 - Requirements_Management_in_Enterprise_Architect (bản pdf) - Phần help trong EA Lê Thị Bích Thuận – CNPM-K52 Page 58

Bài tiểu luận: Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm. Sử dụng EA trong phát hiện và tổng hợp các yêu cầu phần mềm

Nội dung