1. Trang chủ
  2. » Luận Văn - Báo Cáo

Báo cáo môn học phân tích và yêu cầu phần mềm

37 198 1

Đ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

Thông tin cơ bản

Định dạng
Số trang 37
Dung lượng 677,5 KB

Nội dung

Báo cáo trình bày về các nội dung: “Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mềm (Requirement Elicitation) truyền thống”, “Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mêm (Requirement Elicitation) nâng cao”, “Model– Driven Requirements Engineering (MDRE)”, “Tìm hiểu về các kỹ thuật và phương pháp thương lượng và thỏa thuận các yêu cầu phần mềm” và so sánh một số công cụ UML và lựa chọn công cụ của chúng em.

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ––––––––––––––––––––––––*–––––––––––––––––––––– Báo cáo bài tập tuần Môn học: Phân tích yêu cầu phần mềm Tuần 2 Nhóm 3 Danh sách sinh viên: Lê Trung Hiếu 20111568 CNTT-TT 2.3 K56 Đàm Văn Hoài 20111600 CNTT-TT 2.3 K56 Nguyễn Đức Cương 20111203 CNTT-TT 2.3 K56 Đoàn Văn Đạt 20111370 CNTT-TT 2.3 K56 Giảng viên: PGS.TS Huỳnh Quyết Thắng Hà Nội Ngày 10 tháng 4 năm 2014 Tóm tắt Báo cáo trình bày về các nội dung: “Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mềm (Requirement Elicitation) truyền thống”, “Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mêm (Requirement Elicitation) nâng cao”, “Model-Driven Requirements Engineering (MDRE)”, “Tìm hiểu về các kỹ thuật và phương pháp thương lượng và thỏa thuận các yêu cầu phần mềm” và so sánh một số công cụ UML và lựa chọn công cụ của chúng em Mục lục Contents 1.1.Phương pháp phỏng vấn (Interviewing customers and domain experts) 8 1.1.1.Khái niệm 8 1.1.2.Bản chất, đặc thù của phỏng vấn 8 1.1.3.Bảng câu hỏi và ghi nhận trả lời 9 1.1.4.Các phương pháp phỏng vấn 10 Phỏng vấn với câu hỏi đóng 10 Ưu điểm: .10 Nhược điểm: .10 Phỏng vấn với câu hỏi mở 10 Ưu điểm: .11 Nhược điểm: .11 1.2.Phương pháp bảng hỏi (Questionnaires) 11 1.2.1.Bảng hỏi làm gì? 11 1.2.2.Sử dụng bảng hỏi khi 11 1.2.3.Các kỹ thuật thực hiện 11 1.2.4.Ưu / nhược điểm 12 Ưu điểm 12 Nhược điểm 12 1.2.5.Những lưu ý khi thực hiện phương pháp bảng hỏi 12 1.2.6.Một số mẫu 12 1.3.Phương pháp Quan sát (Observation) .13 1.3.1.Bản chất, đặc thù 13 1.3.2.Phân loại .13 1.3.3.Các kỹ thuật thực hiện 13 1.3.4.Ưu/ nhược điểm 13 Ưu điểm: .13 Nhược điểm: 13 1.4.Phương pháp Nghiên cứu tài liệu và các Hệ thống phần mềm tương tự 14 1.4.1.Bản chất đặc thù 14 1.4.2.Ưu diếm/ nhược điểm của phương pháp 14 Ưu điểm 14 Nhược điểm 14 2.1.Phương pháp nguyên mẫu (Prototyping) 14 2.1.1.Khái niệm, đặc thù 14 2.1.2.Các trường hợp thường dùng .15 2.1.3.Các kỹ thuật thực hiện 15 “Throw-away” prototype .15 Evolutionnary prototype 15 2.1.4.Ưu/ nhược điểm 15 Ưu điểm 15 Nhược điểm 15 2.2.Phương pháp Brainstrorming 16 2.2.1.Đặc thù 16 2.2.2.Các kỹ thuật thực hiện 16 Nêu ý tưởng 16 Thâu tóm ý tưởng 16 2.2.3.Ưu nhược điểm 16 Ưu điểm 16 Nhược điểm 16 2.3.Phương pháp Joint application development (JAD) 16 2.3.1.Khái niệm và đặc thù 16 2.3.2.Các kỹ thuật thực hiện 17 2.3.3.Ưu/ nhược điểm 17 2.4.Phương pháp Rapid application development (RAD) 17 2.4.1.Khái niệm và đặc thù 17 2.4.2.Các kỹ thuật thực hiện 17 2.4.3.Ưu/ nhược điểm 17 Ưu điểm 17 Nhược điểm 17 3.1.Phương pháp luận .18 3.2.Một số kĩ thuật điển hình 20 3.3.Các công cụ phần mềm hỗ trợ 21 3.3.1.GME(Generic Modeling Environment) .21 Tổng quan kỹ thuật .22 GME - giao diện người dùng 23 3.3.2.DSL TOOLS ( Domain-Specific Language Tools) 24 3.3.3.EMF(Eclipse Modeling Framework) 25 3.4.Các dự án phần mềm thành công đã thực hiện dựa trên MDRE 26 3.4.1.DMAN project .26 3.4.2.OPENPROD Project.( Open Model-Driven Whole-Product Development and Simulation Environment) .26 4.1.Các phương pháp chung của thương lượng, thỏa thuân yêu cầu phần mềm 28 Trước khi thương lượng, thỏa thuân: 28 + Định nghĩa vấn đề 28 + Xác định các bên liên quan 28 + Phát hiên mục tiêu 28 + Phân tích mục tiêu .28 Trong khi thương lượng, thỏa thuân: 29 Sau khi thương lượng, thỏa thuân: .29 4.2.Các khia cạnh của thương lượng, thỏa thuân yêu cầu 29 4.2.1.Chiến lược giải quyết xung đôt 29 4.2.2.Các hình thức công tác (Collaboration situations) 31 4.2.3.Các công cụ hỗ trợ thương lượng thỏa thuân 31 4.3.Vi dụ về các hê thống thương lượng, thỏa thuân .32 4.3.1.Aspire 32 4.3.2.Negoisst 32 4.3.3.EasyWinWin 32 4.3.4.SmartSettle 33 5.1.ArgoUML 35 5.1.1.Tinh năng của ArgoUML 35 Các biểu đồ UML mà Argo hỗ trợ 35 Hỗ trợ XMI : 35 Sinh mã : .35 Chỉnh sửa biểu đồ : 35 Ngôn ngữ: .35 Một số định dạng biểu đồ : 36 5.1.2.Ưu điểm: .36 5.1.3 Nhược điểm: 36 5.2.StarUML .36 5.2.1.Tinh năng của StarUML : .36 5.2.2.Ưu điểm: .37 5.2.3.Nhược điểm của StarUML: 37 5.3.Visual Paradigm 37 Các ưu điểm của VP-Paradigm .38 Hình vẽ, bảng biểu 1 Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mềm (Requirement Elicitation) truyền thống 1.1 Phương pháp phỏng vấn (Interviewing customers and domain experts) 1.1.1 Khái niệm Phỏng vấn (interviewing) là một kỹ thuật quan trọng để phát hiện thông tin yêu cầu một cách chi tiết từ một cá nhân Như là một kĩ sư phần mềm, bạn sẽ sử dụng nó trong việc phát hiện yêu cầu phần mềm cho một hệ thống lớn Trong những dự án nhỏ, ta có thể sử dụng phương pháp này như một công cụ phát hiện yêu cầu phần mềm duy nhất 1.1.2 Bản chất, đặc thù của phỏng vấn Phỏng vấn để phát hiện thông tin về: • Các ý kiến của người được phỏng vấn • Các cảm nghĩ của người được phỏng vấn • Tình trạng hiện tại của phần mềm • Các mục tiêu về tổ chức và nhân sự • Các thủ tục không chinh thức • Các văn bản mẫu (template) trợ giúp thực hiện phương pháp Kế hoạch phỏng vấn tổng quan Hệ thống: Đại lý băng đĩa ABC Người lập: Nguyễn Hải Nam Ngày lập: 01/09/2008 STT Chủ đề Yêu cầu Ngày bắt đầu Ngày kết thúc 1 Qui trình băng đĩa bánNắm rõ tất qui trình về bán lẻ, bán02/09/2008 sỉ, và qui trình xử lý đơn đặt hàng 02/09/2008 2 Qui trình đặt muaNắm qui trình khách hàng đặt03/09/2008 băng đĩa mua băng đĩa với đại lý 03/09/2008 3 Quản lý nhập xuất tồn kho 05/09/2008 05/09/2008 4 Hệ thống máyTìm hiểu kỹ về tài nguyên máy10/09/2008 móc, phần mềm móc, trang thiết bị, phần mềm, hệ điều hành đang sử dụng của tổ chức 10/09/2008 Hình 1 Kế hoạch phỏng vấn tổng quan Bảng kế hoạch phỏng vấn Hệ thống:……………………… Người được phỏng vấn:…………… Phân tích viên:…………… Vị tri/ phương tiện Văn phòng, phòng họp, điện thoại,… Thời gian: - Bắt đầu: - Kết thúc: Mục tiêu: Dữ liệu cần thu thập? Lãnh vực nào? Lưu ý: - Kinh nghiệm - Ý kiến đánh giá, nhận xét của người được phỏng vấn Chi tiết buổi phỏng vấn Giới thiệu Tổng quan về hệ thống Tổng quan về buổi phỏng vấn Chủ đề 1 Các câu hỏi Chủ đề 2 Các câu hỏi Tóm tắt các điểm chinh Câu hỏi của người trả lời phỏng vấn Kết thúc Quan sát tổng quan Thời gian ước lượng (? phút) Tổng: Phát sinh ngoài dự kiến Hình 2 Bảng kế hoạch phỏng vấn 1.1.3 Bảng câu hỏi và ghi nhận trả lời Người được phỏng vấn: Hoàng Oanh… Ngày: 03/09/2008 Câu hỏi Ghi nhận Câu hỏi 1: Khách hàng đặt hàng dưới hình thức nào? Trả lời: Gọi điện thoại, đến tận đại lý, gởi fax Kết quả quan sát: Đáng tin cậy Câu hỏi 2: Trả lời: Tất cả đơn đặt hàng của khách hàng phải được Phải thanh toán trước hoặc ngay khi giao thanh toán trước rồi mới giao hàng? Kết quả quan sát: Thái độ không chắc chắn Câu hỏi 3: Trả lời Chị muốn hệ thống mới sẽ giúp cho Chị điều gì? Dữ liệu chỉ nhập một lần và hệ thống tự động phát sinh báo cáo các loại Kết quả quan sát Không tin tưởng lắm, hình như đã triển khai thất bại một lần Hình 3 Bảng câu hỏi và ghi nhận trả lời 1.1.4 Các phương pháp phỏng vấn Phỏng vấn với câu hỏi đóng Là câu hỏi mà các đáp án thường nằm trong các tình huống được xác định trước Câu hỏi đóng thich hợp cho việc tạo các dữ liệu chinh xác, tin cậy để dễ dàng phân tích Hiệu quả và đỏi hỏi người phỏng vấn phải có kỹ năng để điều khiển cuộc phỏng vấn Ưu/nhược điểm: Ưu điểm: • Tiết kiệm thời gian phỏng vấn • Dễ dàng so sánh các cuộc phỏng vấn • Đề cập đến một phạm vi rộng một cách nhanh chóng • Chủ động trong cuộc phỏng vấn • Đạt được dữ liệu thich hợp Nhược điểm: • Buồn chán cho người được phỏng vấn • Khó có được nhiều thông tin chi tiết • Thiếu các ý tưởng • Mất thời gian chuẩn bị các câu hỏi • Không tạo mối quan hệ giũa những người phỏng vấn và những người được phỏng vấn Phỏng vấn với câu hỏi mở Là loại câu hỏi với phạm vi trả lời tự do Câu hỏi thich hợp khi người phân tích quan tâm đến câu trả lời rộng và sâu Câu hỏi mởi làm cho câu trả lời không bị gò bó và không gượng ép việc mở rộng khả năng của GME giao diện người dùng Khi một tên miền cụ thể gọi cho một số hoạt động đặc biệt, chúng có thể được hỗ trợ mà không sửa đổi GME chinh nó Các chế quản lý có thể được coi như một thông dịch viên và một add-on cùng lúc Nó có thể được gọi một cách rõ ràng bởi người sử dụng và nó cũng được gọi khi chế hướng sự kiện có mặt trong các mô hình nhất định Tùy thuộc vào mức độ ưu tiên của một hạn chế, các hoạt động gây ra vi phạm hạn chế được hủy bỏ Đối với hành vi vi phạm it nghiêm trọng, Giám đốc Hạn chế chỉ đưa ra một thông điệp cảnh báo Các GME thành phần giao diện người dùng không có đặc quyền đặc biệt trong kiến trúc này Bất kỳ thành phần khác (thông dịch viên, add-on) có quyền truy cập cùng và sử dụng cùng một bộ giao diện COM cho GME Bất kỳ hoạt động có thể được thực hiện thông qua giao diện đồ họa, cũng có thể được thực hiện thông qua giao diện lập trình Kiến trúc này là rất linh hoạt và hỗ trợ mở rộng của toàn bộ môi trường GME - giao diện người dùng Giao diện người dùng đồ họa gốc của GME được thể hiện trong hình bên dưới Hình ảnh cho thấy một mô hình của một đồ thị dòng tín hiệu nạp Trong mô hình đơn giản này, chỉ có mô hình, nguyên tử và kết nối được sử dụng Cửa sổ ở phia bên tay phải cho thấy trình duyệt mẫu để hiển thị toàn bộ dự án trong một thời trang giống như cây Tab Aggragate hiển thị hệ thống phân cấp ngăn chặn, trong khi các tab thừa kế cho thấy các loại hệ thống phân cấp thừa kế Tab Meta cung cấp một tổng quan về các chi tiết kỹ thuật mô hình mẫu Cửa sổ phia dưới là phần trình duyệt mà tất cả các phần có sẵn trong các khia cạnh hiện tại của mô hình hiện tại được hiển thị Chú ý rằng hai tab chỉ ra các khia cạnh của mô hình dòng chảy tín hiệu: SignalFlow và thông số Hình 7 Giao diện người dùng của GME 3.3.2 DSL TOOLS ( Domain-Specific Language Tools) Domain-Specific Language Tools ,như bạn đã biết, cho phép xây dựng các nhà thiết kế đồ họa tùy chỉnh và thế hệ của mã nguồn sử dụng ký hiệu sơ đồ miền cụ thể Nói cách khác, nó sẽ cho phép bạn tạo ra một thiết kế đồ họa UML giống như trong Visual Studio 2005, mà sẽ tạo ra một yourLanguageName tập tin Sử dụng công cụ DSL là khá đơn giản, và bạn có thể tạo ra ngôn ngữ UML như của riêng bạn tương đối nhanh, nhưng khi bạn muốn làm một số nhiệm vụ phức tạp hơn (giống như thêm một thuộc tính tùy chỉnh cho một tài sản tên miền, hoặc làm công cụ tùy chỉnh của riêng mình thay vì sử dụng các mẫu văn bản), nó có thể nhận được tối hơn và đặc biệt là với việc thiếu các tài liệu hướng dẫn Đây là những gì bài viết này là tất cả về: sáng tạo ngôn ngữ của riêng bạn tên miền cụ thể và một số chi tiết điều khiển thân thiện với người sử dụng, cũng như tạo mã của riêng bạn Trong mã nguồn kèm theo bài viết, bạn sẽ tìm thấy một dự án công cụ vi dụ DSL đã được bắt đầu từ các mẫu ngôn ngữ tối thiểu, và mà tôi thêm hai tính năng tôi sẽ để lộ cho bạn Cuối cùng, dự án đã được tạo ra với Visual Studio SDK 1.0 được phát hành vào tháng 9 Bây giờ trước khi bắt đầu, tôi sẽ nhanh chóng giới thiệu các công cụ DSL Mùa hè này, Công cụ DSL được sáp nhập với SDK Visual Studio (họ sử dụng để được hai phần riêng biệt), nhưng không pha trộn chúng lên vì Công cụ DSL thực sự là một lớp trên vì nó sử dụng Visual Studio SDK để cho phép bạn tạo các ứng của bạn -in Chúng ta có thể thấy được mối quan hệ giữa Visual Studio SDK, Công cụ DSL, và Visual Studio 2005 là ba lĩnh vực như thế này: Nhờ vào các công cụ DSL, bạn sẽ có thể sản xuất một gói người dùng có thể cài đặt trên máy tính của mình và đó sẽ bổ sung thêm chức năng mới cho Visual Studio của mình, các chức năng mới là tính năng liên quan ngôn ngữ của bạn (hộp công cụ của mình, nhà thiết kế đồ họa mới của nó, nó mới mở rộng tập tin, vv) 3.3.3 EMF(Eclipse Modeling Framework) Eclipse EMF có thể được sử dụng để mô hình mô hình tên miền của bạn EMF có một sự phân biệt giữa các siêu mô hình và các mô hình thực tế Meta mô hình mô tả cấu trúc của mô hình Một mô hình sau đó là thể hiện của siêu mẫu này EMF cung cấp một khuôn khổ plugable để lưu trữ các thông tin mô hình, mặc định sử dụng XMI (XML Metadata Interchange) để vẫn tồn tại định nghĩa mô hình EMF cho phép để tạo ra các siêu mô hình thông qua phương tiện khác nhau, vi dụ như XMI, chú thich Java, UML hoặc một lược đồ XML Mô tả sau đây sẽ sử dụng các công cụ EMF trực tiếp để tạo ra một mô hình EMF Một khi EMF meta-mô hình được quy định bạn có thể tạo ra tương ứng Java triển khai các lớp học từ mô hình này.EMF cung cấp khả năng rằng các mã được tạo ra có thể được mở rộng một cách an toàn bằng tay Ưu điểm: Với EMF bạn thực hiện mô hình tên miền của bạn rõ ràng, giúp cung cấp khả năng hiển thị rõ ràng của mô hình EMF cũng cung cấp chức năng thông báo thay đổi mô hình trong trường hợp thay đổi mô hình EMF sẽ tạo ra các giao diện và nhà máy sản xuất để tạo ra đối tượng của bạn, do đó nó giúp bạn giữ cho ứng dụng của bạn sạch từ các lớp học implementaiton cá nhân.Lợi thế khác là bạn có thể tạo mã Java từ mô hình tại bất kỳ thời điểm nào Cài đặt EMF bằng Eclipse: chọn Help → Install New Software Chọn Modeling and install EMF - Eclipse Modeling Framework SDK Tham khảo địa chỉ: http://www.vogella.com/tutorials/EclipseEMF/article.html xem cách cài đặt, và tạo một project 3.4 Các dự án phần mềm thành công đã thực hiện dựa trên MDRE 3.4.1 DMAN project một hệ thống lập kế hoạch và quản lý sự ra đi của máy bay các sân bay lớn của châu Âu Nó mô tả cách hoạt động của con người, trường hợp sử dụng và các mô hình đã được áp dụng và tích hợp sử dụng kiểm tra đồng bộ hóa để yêu cầu mô hình trên DMAN Kiểm tra đồng bộ hóa ứng dụng tại giai đoạn được xác định trước trong RESCUE (Requirements Engineering with Scenarios for User-Centred Engineering) tiết lộ thiếu sót và tiềm năng mâu thuẫn trong các mô hình và yêu cầu các bên liên quan lần lượt hướng dẫn để cải thiện các mô hình và đặc điểm kỹ thuật kết quả Biên bản với tác động đối với các yêu cầu mô hình hội nhập, và mô tả tương lai làm việc để mở rộng và áp dụng RESCUE Hình 8 Quá trình cấu trúc của RESCUE 3.4.2 OPENPROD Project.( Open Model-Driven Whole-Product Development and Simulation Environment) OPENPROD là một dự án ITEA2 châu Âu sẽ cung cấp một, toàn bộ sản phẩm phát triển nhanh chóng hệ thống, mô hình hóa và mô phỏng môi trường mô hình điều khiển mở tích hợp vào nền tảng phát triển phần mềm công nghiệp mở hàng đầu (Eclipse) với mã nguồn mở (OpenModelica, vv) , cũng như mô hình hóa và mô phỏng các công cụ công nghiệp và các ứng dụng Các đề tài nghiên cứu chinh là: Tich hợp mô hình phần mềm phần cứng bằng cách Modelica - UML - SysML hội nhập Cải tiến trình biên dịch mô hình Biên soạn Modelica song song nền tảng đa lõi Công cụ khả năng tương tác Áp dụng Dự án OPENPROD ITEA 2 đặt ra để phát triển một toàn bộ sản phẩm mở, mô hình định hướng phát triển hệ thống, mô hình hóa và mô phỏng (M & S) môi trường tích hợp các OPENPROD môi trường tích hợp hàng đầu phát triển phần mềm công nghiệp mở nền tảng Eclipse với mã nguồn mở hàng đầu mô hình hóa và mô phỏng công cụ như vậy như OpenModelica và công nghiệp M & S các công cụ và ứng dụng Kết quả là một tích hợp môi trường dựa trên mô hình đó cung cấp cho máy tính hỗ trợ và xác nhận phát triển sản phẩm tất cả các cách từ mô hình kinh doanh và các yêu cầu để thức thực thi mô hình và triển khai sản phẩm Điều này cắt giảm thời gian để thị trường và đảm bảo chất lượng cao hơn thông qua việc sử dụng các giải pháp mở dựa trên mô hình với cao tác động Hình 9 Unified Modeling: Meta-modeling & Modelica & UML http://www.isis.vanderbilt.edu/Projects/gme/ http://www.codeproject.com/Articles/16833/DSL-Tools http://www.vogella.com/tutorials/EclipseEMF/article.html 4 Tìm hiểu về các kỹ thuật và phương pháp thương lượng và thỏa thuận các yêu cầu phần mềm 4.1 Các phương pháp chung của thương lượng, thỏa thuận yêu cầu phần mềm Trước khi thương lượng, thỏa thuận: + Định nghĩa vấn đê Trước khi đàm phán thực tế có thể bắt đầu điều quan trọng là xác định các vấn đề bằng cách phân tích tình hình và xác định mục đich của đàm phán Vi dụ, trong một dự án phần mềm vấn đề phụ thuộc vào cả mục tiêu tổng thể của dự án và mục tiêu của giai đoạn hiện nay Các cu ôc đàm phán yêu cầu trong giai đoạn đầu liên quan đến vấn đề cấp cao trong khi các cu ôc đàm phán sau đó có thể tập trung vào các khia cạnh hoặc tiểu dự án cụ thể Các yêu cầu thu thập được trong giai đoạn đầu của một dự án thể hiện một phạm vi rộng hơn những cái có thể thực hiên trong những điều khoản tổng quát và trở nên chinh xác hơn sau này Xác định các vấn đề đàm phán là điều cần thiết để các bên liên quan xác định và điều chỉnh phương pháp và kỹ thuât đàm phán + Xác định các bên liên quan Các “bên liên quan quan trọng cho sự thành công” cần được xác định Viêc tìm ra những người (hay những người đại diên) mà cần lợi ich của họ cần được cung cấp là m ôt nhi êm vụ đầy thử thách nhưng cần thiết cho sự thành công của quá trình đàm phán Những “bên liên quan quan trọng cho sự thành công” là những người có thể tạo các thỏa thu ân cho các yêu cầu và tạo sự liên kết cho các thỏa thuân Viêc xác định đúng người có thể giúp đẩy nhanh quá trình đàm phán + Phát hiện mục tiêu Trước khi các cuộc xung đột có thể được xác định các bên liên quan phải đưa mục tiêu cá nhân của họ ra bàn bạc Mục tiêu là một đối tương mà hệ thống được xem xét nên đạt được Các “bên liên quan quan trọng cho sự thành công” nên thể hi ên mục tiêu cá nhân của họ ho ăc mục tiêu của người mà họ đại diên Tùy thuộc vào vấn đề được xác định và đ ăc điểm của các bên liên quan như vai trò, miền kiến thức, kinh nghiệm… mà các mục tiêu được xây dựng ở các cấp đô chi tiết khác nhau, từ khia cạnh cấp cao (như khả năng của h ê thống nói chung, ngân quỹ, lịch trình dự án…) tới các mối quan tâm kỹ thuât cấp đ ô thấp hơn như môi trường phát triển hay nền tảng đich + Phân tích mục tiêu Các mục tiêu được phát hiên sẽ được kiểm tra để phát hiên các xung đ ôt bằng cách phân tích mục tiêu và sở thich của các bên liên quan Vi dụ có thể xảy ra xung đ ôt giữa các mức đ ô yêu cầu dịch vụ từ phia người dùng với các ràng bu ôc ngân quỹ của nhà cung cấp Xác định các xung đột thường là một quá trình thủ công và dựa vào những kiến thức và chuyên môn của các bên liên quan và khả năng của người điều hành Phân tích mục tiêu không chỉ tiết lộ mâu thuẫn giữa các mục tiêu các bên liên quan mà còn cho thấy sự thiếu nhất quán, rủi ro, bất trắc và giả định ẩn Nhiêm vụ này được hỗ trợ bằng các kĩ thuât về đô ưu tiên Trong khi thương lượng, thỏa thuận: Giai đoạn này liên quan đến việc thực hiện thực tế của việc đàm phán và định nghĩa của thỏa thuận Dựa trên các mục tiêu được phát hiên và các xung đột được xác định, các bên liên quan tìm kiếm giải pháp cùng có lợi có thể chấp nhận được bởi tất cả các bên Hoạt động này cấu trúc lại các vấn đề và phát triển các lựa chọn thay thế để giải quyết vấn đề, vi dụ như lựa chọn trao đổi lợi ich cho nhau Sau khi phát triển các giải pháp có thể có, các bên liên quan sẽ thống nhất môt giải pháp tốt nhất Các giải pháp cần có m ôt sự giải thich theo các tiêu chuẩn được thống nhất bởi các bên liên quan Nếu không có các tiêu chuẩn này, các thông số giá trị giữa các bên sẽ không phù hợp Bởi vây, cần tổ chức m ôt phiên đàm phán mang tính chuẩn bị để xác định các tiêu chuẩn này Tùy thuôc vào các loại xung đôt và các vấn đề cần giải quyết, các chiến lược khác nhau sẽ được thông qua để đối phó với xung đôt Viêc này liên quan tới các thỏa hiêp, trong đó các bên liên quan có thể từ bỏ môt phần yêu cầu của mình để đổi lại sự đồng thu ân trong các yêu cầu khác, hay có thể đưa ra các giải pháp đáp ứng được yêu cầu của các bên, hay có thể thuyết phục các nhà đàm phán khác thừa nhân yêu cầu của mình M ôt số công cụ được phát triển để tự đ ông giải quyết xung đôt vi dụ như hê thống OZ của Robinson và Fickas Sau khi thương lượng, thỏa thuận: Trong giai đoạn này các bên liên quan (hoặc các công cụ tự động) phân tích và đánh giá các kết quả đàm phán và đề nghị tái đàm phán nếu cần thiết Vi dụ nếu có thể tìm ra giải pháp đem lại lợi ich cho môt bên liên quan mà không ảnh hưởng tới các bên còn lại Giai đoạn này cũng liên quan tới viêc đảm bảo chất lượng của kết quả đàm phán Nếu có sự phát triển mới làm cho các thỏa thuân trở nên lỗi thời, cần tiến hành đàm phán lại Nếu phần mềm được phát triển theo mô hình có sự lăp lại, cần liên tục phát triển kết quả đàm phán do các yêu cầu mới phát sinh có thể gây ra các xung đôt mới 4.2 Các khía cạnh của thương lượng, thỏa thuận yêu cầu 4.2.1 Chiến lược giải quyết xung đột Theo cách phân chia của Thomas (Thomas K (1976) Conflict and conflict management) Dựa trên 2 tiêu chi: + Quyết đoán hay không quyết đoán (các bên liên quan tâp trung vào đáp ứng các yêu cầu của bản thân mình) + Hợp tác hay bất hợp tác (các bên liên quan tâp trung vào đáp ứng yêu cầu của người khác) Thomas đưa ra 5 phương hướng giải quyết xung đôt: Phương hướng 1: Cạnh tranh (ép buộc): liên quan đến việc tập trung vào đạt mối quan tâm riêng của mình và làm tốn kém chi phi của người khác, thường dẫn đến tình huống “thắngthua” Phương hướng 2: Giúp đỡ (làm mịn): liên quan đến việc cố gắng để đáp ứng mối quan tâm của người khác mà không cần chú ý đến mối quan tâm của chinh mình Điều này có thể có nghĩa là một bên liên quan là tự hy sinh và nhường chỗ cho người khác Phương hướng 3: Phối hợp (giải quyết vấn đề): tập trung vào đáp ứng mối quan tâm của tất cả các bên để tìm giải pháp thay thế mà cố gắng để đáp ứng những mối quan tâm của tất cả các bên, tâp trung vào viêc tìm kiếm các tình huống “thắng-thắng” Phương hướng 4: Né tránh (rút lui): các bên liên quan có thể từ chối, thờ ơ với cu ôc đàm phán Phương hướng 5: Thỏa hiêp (chia sẻ): các bên liên quan cùng nhượng b ô để tìm được giải pháp trung gian chấp nhân được Theo cách phân chia của Fisher và Ury (Fisher R, Ury W (1983) Getting to yes: Negotiation agreement without giving in) Viêc lựa chọn chiến lược giải quyết xung đ ôt phụ thuôc và lợi ich của các bên liên quan, sự phụ thuôc lẫn nhau của các lợi ich, sức mạnh của mỗi bên, chất lượng của mỗi bên Hai tác giả Fisher và Ury đã đưa ra 3 chiến lược giải quyết xung đ ôt: + Chiến lược mềm (Soft): Giả định cơ bản là các bên sẵn sàng hợp tác để tìm kiếm các thỏa thuận thỏa đáng Các bên liên quan hợp tác trong một nhóm giải quyết vấn theo m ôt quá trình đồng thuận + Chiến lược cứng (Hard): Các bên liên quan được coi là các đối thủ cạnh tranh và không nhất thiết hướng đến môt tình huống “thắng-thắng” Khi các bên liên quan cạnh tranh, các xung đ ôt xảy ra là điều không thể tránh khỏi + Chiến lược nguyên tắc (Principled): Hai tác giả đề xuất chiến lược này như là m ôt cách kết hợp của hai chiến lược nói trên Chiến lược mềm (Soft) Các bên liên quan là bạn Mục tiêu là sự đồng thuận Chiến lược cứng (Hard) Các bên liên quan là đối thủ của nhau Mục tiêu là chiến thắng Cư xử mềm dẻo với con người và các vấn đề Tin tưởng người khác Cư xử cứng rắn với con người và các vấn đề Không tin tưởng người khác Thay đổi quan điểm dễ dàng Tập trung vào quan điểm của bản thân Tạo ra các mối đe dọa Che giấu điểm mấu chốt của mình Chỉ tăng thêm yêu cầu khi thỏa thuận Tìm kiếm một câu trả lời mà mình chấp nhận Nhấn mạnh vào vị trí của mình Làm người đáp ứng yêu cầu Tiết lộ điểm mấu chốt của mình Chấp nhận thua thiệt một mặt nào đó để đạt thỏa thuận Tìm kiếm một câu trả lời mà người khác chấp nhận Nhấn mạnh vào thỏa thuận Cố gắng tránh chạy đua ý chí Chịu áp lực Cố gắng thắng trong chạy đua ý chí Gây áp lực Chiến lược nguyên tắc (Principled) Các bên liên quan là người giải quyết vấn đề Mục tiêu là một kết quả thông minh, đạt hiệu quả và thân thiện Cư xử mềm dẻo với con người và cứng rắn với các vấn đề Xử lí không phụ thuộc vào sự tin tưởng Tập trung vào lợi ích, không phải quan điểm Khám phá lợi ích Tránh có một điểm mấu chốt Phát minh ra những lựa chọn cùng có lợi Phát triển nhiều lựa chọn, quyết định sau Nhấn mạnh vào việc sử dụng các tiêu chí khách quan Cố gắng đạt được kết quả dựa trên các tiêu chuẩn độc lập với ý chí Tạo ra các nguyên tắc, không gây áp lực Hình 10 Các chiến lược giải quyết xung đột Chiến lược nguyên tắc cần 4 yếu tố quan trọng là: - Tách rời con người và vấn đề - Tâp trung vào lợi ich chứ không phải quan điểm - Tạo ra các khả năng có thể trước khi quyết định - Đạt đến kết quả dựa trên các tiêu chuẩn khách quan 4.2.2 Các hình thức cộng tác (Collaboration situations) - Cùng thời gian/Cùng địa điểm: Tổ chức các cuôc họp măt đối măt là cách phổ biến để phát hiên và đàm phán yêu cầu Trong kỹ thuât lấy yêu cầu phần mềm, nhiều phương pháp đạt hi êu quả tốt nhất hoăc chỉ có thể thực hiên khi cả nhóm làm viêc m ôt cách đồng b ô Khi tổ chức các buổi găp măt đối măt, các tín hiêu phi ngôn từ được khai thác tri êt để, giúp mọi người có thể hiểu nhau hơn, qua đó rút ngắn đáng kể thời gian đàm phán - Khác thời gian/Cùng địa điểm: Trong nhiều trường hợp, các bên liên quan có thể ở cùng vị tri nhưng lại không thể tổ chức được những cuôc họp m ăt đối m ăt Quá trình đàm phán thường kéo dài quá thời gian buổi găp măt hoăc khó có thể tổ chức cu ôc họp do hạn chế về m ăt thời gian của các bên Môt nguyên nhân khác là những thông tin để ra quyết định không có sẵn trong cuôc họp Trong trường hợp này, cần phải tiến hành các bước m ôt cách không đồng b ô, tổ chức môt không gian làm viêc chung để các bên lien quan có thể đóng góp ý kiến vào quá trình đàm phán đang diễn ra và theo dõi được tiến trình đàm phán - Cùng thời gian/Khác địa điểm: Trong các trường hợp các bên liên quan không thể ở cùng m ôt địa điểm, vẫn có thể tổ chức những cuôc họp măt đối m ăt thông qua các thiết bị truyền dẫn thông tin từ xa Các bên có thể tương tác cùng thời gian thông qua h ôi nghị trực tuyến Với sự phát triển của công nghê truyền thông tin, khoảng cách về địa lý không còn ảnh hưởng quá lớn tới tiến trình đàm phán - Khác thời gian/Khác địa điểm: Hiên nay, quá trình đàm phán yêu cầu càng có xu hướng diễn ra trong môi trường không đồng bô và xa cách về địa lý do càng có nhiều dự án phần mềm mang tính toàn cầu và có sự tham gia của nhiều tổ chức Trong trường hợp này, cần các công cụ đ ăc biêt để các bên liên quan có thể đóng góp ý kiến từ các địa điểm khác nhau và theo thời gian khác nhau 4.2.3 Các công cụ hỗ trợ thương lượng thỏa thuận + Công cụ thụ đông: Công cụ này cung cấp một cơ sở hạ tầng để đàm phán và hỗ trợ tất cả các tình huống phối hợp khác nhau Chúng cho phép tất cả các bên liên quan để thể hiện mong muốn của họ, để giao tiếp về những ý tưởng, nguồn cung cấp và các tham số, và chia sẻ kết quả trung gian, kết quả cuối cùng Vi dụ như email, chat, hoặc phòng đa phương tiện Hệ thống thụ động không hỗ trợ việc xây dựng nội dung với các gợi ý và hướng dẫn + Công cụ hỗ trợ lợi ich chủ đông: Công cụ của loại hình này có khả năng hướng dẫn các bên liên quan hướng tới một thỏa thuận, vi dụ, bằng cách xác định tình huống cho cùng có lợi Hệ thống như vậy có thể giúp người sử dụng trong việc xây dựng, thẩm định, và giải quyết các vấn đề khó khăn Các công cụ này cũng trợ giúp viêc tạo nhượng bô và tạo ra những người đáp ứng yêu cầu, cũng như hỗ trợ đánh giá tiến trình đàm phán Những h ê thống hỗ trợ lợi ich chủ đ ông thường gắn liền với môt tiến trình đàm phán nhất định + Công cụ hỗ trợ can thiêp chủ đông: Các hệ thống này có khả năng bổ sung của điều phối các hoạt động của các bên liên quan Vi dụ, hê thống phê phán hành động của các bên hoặc đề nghị những thỏa thuận để chấp nhận Để cung cấp khả năng như vậy, hệ thống truy cập và sử dụng tri thức cơ sở và sử dụng tác tử phần mềm thông minh theo dõi quá trình đàm phán và các hoạt động cá nhân của các nhà đàm phán 4.3 Ví dụ về các hệ thống thương lượng, thỏa thuận 4.3.1 Aspire Aspire là một phần mở rộng của hệ thống Inspire và cung cấp sự hỗ trợ chủ động với tác tử phần mềm Atin Tác tử đưa ra lời khuyên cho các nhà đàm phán bằng cách phân tích một cu ôc đàm phán đang diễn ra, sử dụng quy tắc xuất phát từ các tài liêu đã có Thông thường, h ê thống áp dụng cho đàm phán song phương Aspire thực hiện một mô hình đàm phán ba giai đoạn , bao gồm tiền trước đàm phán, tiến hành đàm phán, và sau đàm phán Các hoạt động chinh trong giai đoạn trước đàm phán là phân tích tình hình hiện tại liên quan đến các vấn đề và các tùy chọn và việc xác định các bên liên quan Trong giai đoạn trước đàm phán Aspire hỗ trợ các bên liên quan trong việc tìm hiểu các trường hợp đàm phán bằng cách cung cấp một mô tả chi tiết về tình hình ban đầu Các bên liên quan được mời thể hiện yêu cầu của họ liên quan đến các vấn đề và giải pháp thay thế Trong giai đoạn đàm phán các bên liên quan trao đổi thông điêp và cung cấp thông tin để trình bày quan điểm của mình Đàm phán kết thúc khi một thỏa thuận được thực hiện hoặc một trong các bên liên quan dừng đàm phán Ngoài ra, để phân tích quá trình đàm phán đang diễn ra các bên liên quan có thể xem lịch sử của quá trình đàm phán, được theo dõi bởi công cụ của h ê thống Giai đoạn sau đàm phán được sử dụng để phân tích và đánh giá các kết quả đàm phán và quyết định có cần thiết để thương lượng lại thỏa thuận đã có Dựa trên các thông tin ưu tiên nhập vào giai đoạn trước đàm phán, Aspire xác định nếu thỏa thuận hiện tại đáp ứng được yêu cầu của đối tác Nó sẽ kiểm tra nếu có một giải pháp tốt hơn có thể cho một bên đàm phán, mà không có thiệt hại cho phia bên kia Aspire có hỗ trợ mạnh mẽ cho các giai đoạn phát triển giải pháp bằng cách phân tích quá trình đàm phán và đưa ra những gợi ý tích cực 4.3.2 Negoisst Hệ thống đàm phán Negoisst tập trung vào hỗ trợ đàm phán giữa các doanh nghi êp trong thương mại điện tử Dựa trên lý thuyết về hệ thống thông tin liên lạc nó kết hợp quản lý tài liệu và các mối liên lạc Các đội có thể sử dụng ngôn ngữ tự nhiên để trao đổi tin nhắn bán cấu trúc và cùng nhau soạn các điều khoản của một hợp đồng phức tạp Hệ thống đàm phán cho các giao dịch thương mại điện tử thường hỗ trợ giai đoạn chung của thương mại điện tử: tìm kiếm đối tác tiềm năng; tìm kiếm và đàm phán các thỏa thuận; thực hiện các nghĩa vụ hợp đồng Trong trường hợp này, mục đich của hệ thống Negoisst là hỗ trợ giai đoạn đàm phán bằng cách cung cấp sự trợ giúp trực quan, rõ ràng, hiệu quả và định hướng quá trình đàm phán giữa con người Sử dụng tin nhắn trao đổi bán cấu trúc, các nhà đàm phán có thể lựa chọn các loại tin nhắn khác nhau để làm cho sự diễn đạt ý định được rõ ràng Hệ thống Negoisst cung cấp các loại thông điệp sau và phác thảo quá trình đàm phán: yêu cầu, đề nghị, phản cung cấp, chấp nhận, từ chối, câu hỏi, và làm rõ 4.3.3 EasyWinWin EasyWinWin là một cách tiếp cận đàm phán yêu cầu kết hợp các mô hình xoắn ốc win-win của công nghệ phần mềm với các kỹ thuật, kiến thức hợp tác và tự động hóa của một hệ thống hỗ trợ nhóm Nó được dựa trên mô hình đàm phán của Boehm Các mục tiêu cá nhân của các bên liên quan được thâu tóm như điều kiện giành chiến thắng Mâu thuẫn giữa các điều kiện giành chiến thắng, rủi ro và không chắc chắn được ghi nhận là vấn đề và các tùy chọn được đưa ra để giải quyết vấn đề Thỏa thuận được phát triển từ các điều kiện chiến thắng và ra các lựa chọn bằng viêc tính đến quá trình ra quyết định và lý do trước đó EasyWinWin giúp cho một nhóm các bên liên quan đạt được một sự hiểu biết tốt hơn và kỹ hơn về vấn đề đang nghiên cứu và hỗ trợ viêc hợp tác nghiên cứu quan điểm của người khác Đây là một vi dụ về một hệ thống hỗ trợ đàm phán tích cực EasyWinWin yêu cầu cách tiếp cận đàm phán cũng bao gồm các bước để phát hi ên và phân tích yêu cầu Vi dụ, trong cuôc họp khởi đông, tất cả các bên liên quan được mời gửi ý kiến của họ Môt người trợ giúp sẽ phân tích các ý kiến và tạo lâp các điều kiên thắng của các bên liên quan Các công cụ trợ giúp như cuôc họp khởi đông điện tử hỗ trợ cho vi êc sản sinh ý tưởng, nhóm công cụ phác thảo để tổ chức ý tưởng, các công cụ bỏ phiếu để đánh giá ý tưởng Trong EasyWinWin người tham gia sử dụng một công cụ bỏ phiếu đa tiêu chi để đánh giá đ ô ưu tiên cho các điều kiên thắng Các nhóm sử dụng EasyWinWin trong suốt chu trình phát triển để chia sẻ phạm vi dự án, định nghĩa yêu cầu cấp cao, yêu cầu chi tiết cho các tính năng, chức năng và thu ôc tính, yêu cầu việc chuyển đổi hệ thống cho khách hàng và người sử dụng Viêc gợi mở mục tiêu được hỗ trợ mạnh mẽ; sự hỗ trợ sản sinh giải pháp là yếu hơn và dựa vào sự giúp đỡ của một điều phối viên Không có giới hạn đối với số của các bên liên quan và các tình huống phối hợp với, mặc dù hầu hết các nhóm đã sử dụng EasyWinWin trong cùng một thời gian (cùng địa điểm hoăc không) 4.3.4 SmartSettle SmartSettle là một hệ thống hỗ trợ đàm phán sử dụng Internet để cho phép sự tương tác giữa các bên liên quan dự án với các mục tiêu mâu thuẫn nhau mà muốn tiếp cận một thỏa thuận Viêc hỗ trợ yêu cầu sự mô hình các vấn đề và biểu diễn các ý tưởng theo cách mà có thể được sử dụng bởi các thuật toán tối ưu hóa SmartSettle sử dụng một khu vực họp chung để soạn một khung thỏa thuân với ngôn ngữ tự nhiên Đô ưu tiên có thể thể hiên bằng đồ thị của sự hài lòng Quá trình đàm phán SmartSettle tiếp tục sử dụng các thuật toán tối ưu hóa chuyển đổi mục tiêu mâu thuẫn nhau vào các giải pháp công bằng và hiệu quả và tạo ra các đề xuất trước khi đạt được thỏa thuận Sau khi một thỏa thuận dự kiến đạt được, SmartSettle cải thiện tình hình bằng cách phân phối lợi ich công bằng cho các bên Việc sử dụng các thuật toán tối ưu hóa dẫn đến giải pháp tối đa hóa sự hài lòng lẫn nhau cho tất cả các bên liên quan Môt điều phối viên hướng dẫn các bên liên quan thông qua các giai đoạn của quá trình SmartSettle, bao gồm các giai đoạn sau: - Chuẩn bị cho đàm phán - Xác định lợi ich (các gợi mở của mục tiêu của các bên liên quan và dự thảo khuôn khổ cho thỏa thuận) - Xác định điều kiên thắng (xác định các ưu tiên) - Xác định các điều khoản cơ bản (đề nghị các giải pháp và chấp nhận thỏa thuận dự kiến) - Tối đa hóa lợi ich (tối ưu hóa giải pháp để đạt được các đ ô ưu tiên cao hơn) - Đảm bảo sự cam kết Bảng so sánh các hệ thống đàm phán Aspire Negoisst EasyWinWin SmartSettle - Trước đàm phán: Chuẩn bị - Trong khi đàm phán: Yêu cầu và phản hồi - Sau khi đàm phán: Sự thỏa thuận - Trước đàm phán: Xác định danh mục đàm phán - Trong khi đàm phán: Yêu cầu, lời đáp, các sự đáp ứng, chấp nhận, từ chối, câu hỏi, làm rõ - Sau khi đàm phán: Định nghĩa hợp đồng - Trước đàm phán: Chuẩn bị Xác định lợi ích và sự thỏa mãn - Trong khi đàm phán: Thiết lập sự công bằng Tối đa hóa lợi ích - Sau khi đàm phán: Bảo đảm cam kết Chiến lược giải quyết xung đột Đấu tranh Đấu tranh - Trước đàm phán: Xác định mục đích đàm phán, các chủ đề đàm phán, và chú giải thuật ngữ Xác định các bên liên quan quan trọng Phát hiện và đặt độ ưu tiên cho điều kiện thắng Tìm ra các vấn đề và khó khăn - Trong khi đàm phán: Xác định các vấn đề và các tùy chọn Đàm phán thỏa thuận - Sau khi đàm phán: Mô hình xoắn ốc lặp lại Hợp tác, gây ảnh hưởng Bối cảnh đàm phán Khác thời gian, khác địa điểm Khác thời gian, khác địa điểm Cùng thời gian, khác hoặc cùng địa điểm Khác thời gian, khác địa điểm Đặc tả việc thực hiện quá trình đàm phán Cạnh tranh, gây ảnh hưởng 5 Tìm hiểu, so sánh đánh giá lựa chọn công cụ các công cụ UML 5.1 ArgoUML ArgoUML là một công cụ - môi trường giúp phân tích và xây dựng các hệ thống phần mềm hướng đối tượng Nó hỗ trợ tất cả các sơ đồ UML như biểu đồ lớp, biểu đồ ca sử dụng, biểu đồ hoạt động, biểu đồ trình tự, biểu đồ triển khai… ArgoUML được viết bằng ngôn ngữ Java Nó có thể chạy trên bất kỳ nền tảng nào hỗ trợ Java 5 đến Java 8 Argo giúp tạo ra các tập tin XMI (XML Metadata Interchange) - một định dạng tập tin tiêu chuẩn cho các thiết kế UML 5.1.1 Tính năng của ArgoUML Các biểu đồ UML mà Argo hỗ trợ Sau đây loại biểu đồ được hỗ trợ bởi AgroUML: · Sơ đồ lớp · Biểu đồ trạng thái · Biểu đồ hoạt động · Biểu đồ ca sử dụng · Biểu đồ cộng tác (Collaboration diagram) · Biểu đồ triển khai · Biểu đồ trình tự Hỗ trợ XMI : - XMI là một định dạng trao đổi dựa trên XML giữa các công cụ UML ArgoUML sử dụng cơ chế lưu thông tin theo tiêu chuẩn này để dễ dàng trao đổi với các công cụ và tương thich với các tiêu chuẩn mở XMI Phiên bản 1.0 đã được sử dụng cho UML 1.3 ArgoUML 0.20 hỗ trợ các UML 1.4 với định dạng XMI 1.1 và 1.2 Sinh mã : - ArgoUML sinh mã cho các ngôn ngữ như Java, C + + , C # , PHP4 và PHP Các ngôn ngữ khác có thể được thêm vì chức năng này là 1 module Đặc biệt, mã Java sinh ra cho phép cơ chế dịch ngược (tức là có thể dịch từ mã nguồn Java về sơ đồ UML) Kỹ thuật ngược lại: - ArgoUML cung cấp một mô-đun dịch ngược (framework), cho phép nhập các tệp java (source) để dịch ngược về sơ đồ UML Chỉnh sửa biểu đồ : - ArgoUML hỗ trợ nhiều tính năng chỉnh sửa các biểu đồ UML Ngôn ngữ: - ArgoUML hỗ trợ các ngôn ngữ: Anh tại Mỹ, Anh, Pháp, Đức, Ý, Bồ Đào Nha, Tây Ban Nha, Nga, tiếng Na Uy và Trung Quốc Một số định dạng biểu đồ : - Sơ đồ có thể được lưu dưới dạng GIF, PNG, PostScript, Encapsulated PS, XMI , PGML và SVG • • • • • • • • 5.1.2 Ưu điểm: ArgoUML bao gồm một số tính năng hỗ trợ các yêu cầu (về mặt nhận thức) thiết kế phần mềm theo phương pháp hướng đối tượng ArgoUML hỗ trợ các tiêu chuẩn mở rộng rãi - UML, XMI, SVG, và OCL và các chuẩn khác ArgoUML là một ứng dụng Java 100% Điều này cho phép ArgoUML để chạy trên tất cả các nền tảng ArgoUML là một sản phẩm mã nguồn mở, cho phép mở rộng hay tùy biến 5.1.3 Nhược điểm: Không hỗ trợ đầy đủ UML 2.0 Không thể Undo! Cũng có nghĩa là người dùng gần như không được sai sót (điều không thể xảy ra) Viết bằng Java, vì vậy chạy tương đối chậm hơn so với starUML Thiếu tùy chọn định dạng 5.2 StarUML StarUML là một dự án mã nguồn mở, phát triển một công cụ UML mạnh mẽ, linh hoạt, có thể mở rộng, nhiều tính năng, chạy trên Win32 Mục tiêu của dự án StarUML là xây dựng một phần mềm giúp xây dựng các biểu đồ UML, thay thế thay thế các phần mềm thương mại như Rational Rose 5.2.1 Tính năng của StarUML : i Chinh xác UML mô hình chuẩn : - StarUML tuân thủ nghiêm ngặt các tiêu chuẩn đặc điểm kỹ thuật UML theo quy định của OMG về modeling phần mềm Hiện tại, StarUML hỗ trợ đến chuẩn UML mới nhất là 2.0 ii Open software model format : - StarUML quản lý tất cả các file của mình ở định dạng chuẩn XML Các mã được viết theo cấu trúc dễ đọc hiểu, và định dạng của chúng có thể dễ dàng được chuyển đổi sử dụng bộ phân tích XML Trong khi đó, các phần mềm khác lại quản lý tất cả các tập tin của mình theo hệ thống quản lý riêng của họ 1 cách thiếu hiệu quả iii Hỗ trợ MDA : - StarUML thực sự hỗ trợ Hồ sơ UML (Profile) Điều này tối đa hóa khả năng mở rộng của UML, làm cho ngay cả những lĩnh vực như tài chinh, quốc phòng, thương mại điện tử, bảo hiểm, hàng không cũng có thể sử dụng công cụ mô hình hóa này hỗ trợ cho hoạt động của họ (như xây dựng các hệ thống chẳng hạn) Các Mô hình độc lập nền tảng (PIM), Mô hình phụ thuộc nền tảng ( PSM) và mã thực thi có thể được tự động tạo ra theo bất kỳ cách nào iv Khả năng ứng dụng các phương pháp và nền tảng : - StarUML có thể tạo ra các môi trường phù hợp và thich nghi với bất kỳ quá trình/phương pháp nào Không chỉ với nền tảng như J2EE, NET mà còn cả những cấu trúc cơ bản của mô hình phần mềm v Khả năng mở rộng : - Tất cả các chức năng của công cụ StarUML được tự động theo Microsoft COM Bất kỳ ngôn ngữ nào hỗ trợ COM ( Visual Basic Script , Java Script, VB, Delphi , C + + , C #, VB.NET, Python, vv ) đều có thể được sử dụng để điều khiển StarUML hoặc phát triển các Add-ins vi Chức năng xác minh mô hình phần mềm : - Người dùng có thể gặp phải nhiều sai lầm trong quá trình mô hình hóa phần mềm Sai lầm như vậy có thể rất tốn kém nếu không được khắc phục trước giai đoạn lập trình Để ngăn chặn vấn đề này, StarUML tự động xác minh các mô hình phần mềm được phát triển bởi người sử dụng, cho phép phát hiện sớm các sai sót, và làm giảm sai lệch so với phần mềm hoàn chỉnh vii Hỗ Add-in: - StarUML bao gồm nhiều add-in hữu ich với các chức năng khác nhau : chuyển đổi qua lại giữa mã nguồn và mô hình (sinh mã và dịch ngược về mô hình), hỗ trợ các định dạng tập tin của Rational Rose, trao đổi thông tin mô hình hóa với các công cụ khác sử dụn XMI , và hỗ trợ các mẫu thiết kế Các add-in này tăng khả năng dùng lại, tăng tính năng suất, linh hoạt và khả năng tương tác cho các thông tin mô hình hóa • • • • • • • • • • 5.2.2 Ưu điểm: Hỗ trợ hầu hết các biểu đồ trong UML 2.0 Bộ tính năng rất phong phú và cho phép tùy chọn định dạng Có khả năng tạo ra mã nguồn từ biểu đồ UML Cho phép dịch ngược mã thành sơ đồ UML Hỗ trợ ngôn ngữ: C + +, C # và Java thời gian tải nhanh / thời gian thực hiện so với công cụ UML khác Giao diện người dùng thân thiện và giống Visual Studio Hỗ trợ xuất khẩu sơ đồ thành định dạng phổ biến như JPG / XMI 5.2.3 Nhược điểm của StarUML: Có không hỗ trợ xuất khẩu sơ đồ ở định dạng SVG (Scalable Vector Graphics) Không hỗ trợ làm việc theo nhóm trên các dự án (giai đoạn mô hình hóa có thể bao gồm rất nhiều người) 5.3 Visual Paradigm Visual Paradigm for Unified Modeling Language (VP-UML) là một công cụ UML Công cụ này được thiết kế cho rất nhiều đối tượng sử dụng khác nhau, bao gồm cả kỹ sư phần mềm, nhà phân tích hệ thống, phân tích kinh doanh, kiến trúc sư hệ thống, người quan tâm trong việc xây dựng hệ thống phần mềm quy mô lớn, đáng tin cậy thông qua việc sử dụng các phương pháp tiếp cận hướng đối tượng VP-UML hỗ trợ các tiêu chuẩn mới nhất của Java và ký hiệu UML Giống với ArgoUML, nó hỗ trợ cả quá trình sinh mã Java lẫn dịch ngược từ mã Java về các biểu đồ UML Ngoài ra, VP-UML được tích hợp với Eclipse, Borland ® JBuilder và NetBeans IDE để hỗ trợ các giai đoạn phát triển phần mềm Quá trình chuyển đổi từ phân tích, thiết kế sang thực hiện được tích hợp hoàn toàn trong công cụ VP-UML, do đó làm giảm đáng kể công sức cần bỏ ra trong tất cả các giai đoạn của vòng đời phát triển phần mềm ... thông tin yêu cầu cách chi tiết từ cá nhân Như kĩ sư phần mềm, bạn sử dụng việc phát yêu cầu phần mềm cho hệ thống lớn Trong dự án nhỏ, ta sử dụng phương pháp công cụ phát yêu cầu phần mềm 1.1.2... tả yêu cầu( requirements specification) Thuật ngữ "phân tích yêu cầu" áp dụng cụ thể cho công việc túy phân tích (thay việc khác chẳng hạn làm rõ yêu cầu hay viết tài liệu yêu cầu) Các yêu cầu. .. hóa ngơn ngữ mơ hình bao gồm tồn u cầu quy trình kỹ thuật từ đặc tả yêu cầu , phân bổ để xác minh SysML đề xuất để áp ứng yêu cầu Trong báo mơ hình điều khiển u cầu quy trình kỹ thuật cho ứng dụng

Ngày đăng: 04/08/2020, 22:09

HÌNH ẢNH LIÊN QUAN

Hình 1. Kế hoạch phỏng vấn tổng quan. - Báo cáo môn học phân tích và yêu cầu phần mềm
Hình 1. Kế hoạch phỏng vấn tổng quan (Trang 9)
Không tin tưởng lắm, hình như đã triển khai thất bại một lần - Báo cáo môn học phân tích và yêu cầu phần mềm
h ông tin tưởng lắm, hình như đã triển khai thất bại một lần (Trang 10)
• Thu thập được nhiều thông tin theo chủ ý của người thiết kế bảng hỏi - Báo cáo môn học phân tích và yêu cầu phần mềm
hu thập được nhiều thông tin theo chủ ý của người thiết kế bảng hỏi (Trang 12)
Hình 5. Bảng với câu hỏi đóng. - Báo cáo môn học phân tích và yêu cầu phần mềm
Hình 5. Bảng với câu hỏi đóng (Trang 13)
GME có một kiến trúc thành phần dựa trên mô-đun mô tả trong hình bên dưới. - Báo cáo môn học phân tích và yêu cầu phần mềm
c ó một kiến trúc thành phần dựa trên mô-đun mô tả trong hình bên dưới (Trang 22)
Hình 7. Giao diện người dùng của GME. - Báo cáo môn học phân tích và yêu cầu phần mềm
Hình 7. Giao diện người dùng của GME (Trang 24)
EclipseEMF có thể được sử dụng để mô hình mô hình tên miền của bạn. EMF có một sự phân biệt giữa các siêu mô hình và các mô hình thực tế - Báo cáo môn học phân tích và yêu cầu phần mềm
clipse EMF có thể được sử dụng để mô hình mô hình tên miền của bạn. EMF có một sự phân biệt giữa các siêu mô hình và các mô hình thực tế (Trang 25)
Hình 8. Quá trình cấu trúc của RESCUE. - Báo cáo môn học phân tích và yêu cầu phần mềm
Hình 8. Quá trình cấu trúc của RESCUE (Trang 26)
Tich hợp mô hình phần mềm phần cứng bằng cách Modelica -UM L- SysML hội nhập. Cải tiến trình biên dịch mô hình. - Báo cáo môn học phân tích và yêu cầu phần mềm
ich hợp mô hình phần mềm phần cứng bằng cách Modelica -UM L- SysML hội nhập. Cải tiến trình biên dịch mô hình (Trang 27)
Hình 10. Các chiến lược giải quyết xung đột. - Báo cáo môn học phân tích và yêu cầu phần mềm
Hình 10. Các chiến lược giải quyết xung đột (Trang 30)
Bảng so sánh các hệ thống đàm phán - Báo cáo môn học phân tích và yêu cầu phần mềm
Bảng so sánh các hệ thống đàm phán (Trang 34)

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w