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

55 1.6K 0
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

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

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 tổng hợp các yêu cầu phần mềm. S> d@ng EA trong phát hiện tổng hợp cá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) phạm vi (scope) của phần mềm - Xác định các nhóm người s> d@ng đặc tính của họ đại diện tiêu biểu cho mỗi nhóm - Phân tích 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 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 Lê Thị Bích Thuận – CNPM-K52 Page 2 - Phân tích bài toán là quá trình tìm hiểu vấn đề thế giới thực những gì mà người s> d@ng cần 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 người s> d@ng - Đị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 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 hoạt động kinh doanh Lợi ích Chỉ ra đề nghị gợi ý giải quyết danh sá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 đề Lê Thị Bích Thuận – CNPM-K52 Page 3 • Đội của bạn có thể s> d@ng cácthuật khác nhau để thu được sự hiểu biết của một vấn đề thực 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 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 đặc biệt hóa hệ thống khi nó được giao hàng 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? • 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 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 Lê Thị Bích Thuận – CNPM-K52 Page 4 - Xác định các bước tài liệu 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 cácthuậ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) phạm vi (scope) của phần mềm - Khả năng 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 - 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ự các đặc tính của chúng 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êuphần mềm giải quyết Lê Thị Bích Thuận – CNPM-K52 Page 5 • 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 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 • Các ph@ thuộc chấp nhận: ghi nhận lại các ph@ thuộc các chấp nhận đã thực hiện trong phần mềm. o Phạm vi 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ế 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 hạn chế (constraint); mức độ Lê Thị Bích Thuận – CNPM-K52 Page 6 tự do của phần mềm (khả năng cân đối giữa m@c tiêu 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 đặc tính của họ đạ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 • Liệt kê các phân loại (các lớp) 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. Lê Thị Bích Thuận – CNPM-K52 Page 7 V. Phân tích 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 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 - 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 chức năng - Phát triển mô hình phân tích, giải thích làm rõ với các khách hàng. - Phát triển đá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ê Thị Bích Thuận – CNPM-K52 Page 8 - 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 người s> d@ng - Đòi hỏi rất nhiều nỗ lực 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 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 - 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 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 tổng hợp các yêu cầu phần mềm(từ phía khách hàng). Đó là: Lê Thị Bích Thuận – CNPM-K52 Page 9 - 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 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 phạm vi - 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, 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ư 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. Lê Thị Bích Thuận – CNPM-K52 Page 10 [...]... dụng EA trong phân tích cá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ế 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 mong muốn của khách hàng- người sử dụng phần. .. 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 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 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... phần mềm bởi vì quá trình phân tích 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 - 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. .. 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 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 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. .. CNPM-K52 Page 35 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ử dụng EA trong hỗ trợ xây dựng các tài liệu đặc tả 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 để... 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) • • VI 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 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: Xem xét cấu trúc phân cấp và. .. 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 phần mềm - Các yêu cầu từ các tác nhân ngoài II - Conceptual Modeling 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ỗ... để đá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 36 ... 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) Lê Thị Bích Thuận – CNPM-K52 Page 18 - 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” 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, khách hàng tốt... bằng cách nuôi dưỡng những ý tưởng nhỏ bé bình thường biến những ý tưởng ấy thành hiện thực, chúng ta sẽ có thể phát triển 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 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 các . 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. 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. 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. 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). Đó

Ngày đăng: 27/06/2014, 15:02

Từ khóa liên quan

Mục lục

  • Trường Đại Học Bách Khoa Hà Nội

  • Giảng Viên Hướng Dẫn: Huỳnh Quyết Thắng

  • Hà Nội 11-2010

  • 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ử dụng EA trong phát hiện và tổng hợp các yêu cầu phần mềm.

  • I. Phân tích bài toán

  • II. Xác định quá trình phát triển các yêu cầu phần mềm

  • III. Xây dựng khả năng (vision) và phạm vi (scope) 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

  • 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

  • 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)

    • 1. Interview

    • 2. Requirements Workshops

    • 3. Brainstorming and Idea Reduction

    • 4. Storyboarding

    • 5. Applying Use Cases

    • 6. Prototyping(tạo mẫu)

    • VII. Sử dụng EA trong phát hiện yêu cầu phần mềm:

      • 1. Các thành phần của use case:

        • 1.1. Actor:

        • 1.2. Use case

        • 1.3. Collaboration

        • 1.4. Boundary:

        • 1.5. Package:

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan