Báo cáo bài tập tuần 2 môn học phân tích và yêu cầu phần mềm

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.. Phỏng vấn interviewing là một kỹ thuật quan trọ để phát hiện thông tin yêu cầu

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ậ

Môn họ

2

3Danh sách sinh viên:

Mục lục

Contents

Tóm t t 2

Mục lục 3

Hình vẽ, bảng biểu 4

1.Các kỹ thuậ l q a đ p ươ p áp xác định các yêu cầu phần mềm (Requirement Elicitation) truyền thống 5

1 1 ươ p áp p ỏng vấn (Interviewing customers and domain experts) 5

1.1.1.Khái niệm 5

1.1.2.Bản chấ , đặc thù của phỏng vấn 5

1.1.3.Bảng câu hỏi và ghi nhận trả lời 6

1 1 4 Các p ươ p áp p ỏng vấn 6

1 2 ươ p áp bảng hỏi (Questionnaires) 8

1.2.1.Bảng hỏi làm gì? 8

1.2.2.Sử dụng bảng hỏi khi 8

1.2.3.Các kỹ thuật thực hiện 8

1 2 4 Ư / ược đ ểm 9

1.2.5.Nhữ lư ý k ực hiệ p ươ p áp bảng hỏi 9

1.2.6.Một số mẫu 9

1 3 ươ p áp a sá (Obser a o ) 10

1.3.1.Bản chấ , đặc thù 10

1.3.2.Phân loại 10

1.3.3.Các kỹ thuật thực hiện 10

1 3 4 Ư / ược đ ểm 10

1 4 ươ p áp N cứu tài liệu và các Hệ thống phần mềm ươ ự 11

1.4.1.Bản chấ đặc thù 11

1 4 2 Ư d m/ ược đ ểm của p ươ p áp 11

2.Các kỹ thuậ l q a đ n p ươ p áp xác định các yêu cầu phần mêm (Requirement Elicitation) nâng cao 11

2 1 ươ p áp mẫu (Prototyping) 11

2.1.1.Khái niệm, đặc thù 11

2 1 2 Các rường hợp ường dùng 12

2.1.3.Các kỹ thuật thực hiện 12

2 1 4 Ư / ược đ ểm 13

2 2 ươ p áp Bra s rorm 13

2 2 1 Đặc thù 13

2.2.2.Các kỹ thuật thực hiện 13

2.2.3 Ư ược đ ểm 14

2 3 ươ p áp Jo appl ca o de elopme (JAD) 15

2.3.1.Khái niệm à đặc thù 15

2.3.2.Các kỹ thuật thực hiện 15

2 3 3 Ư / ược đ ểm 15

2 4 ươ p áp Rap d appl ca o de elopme (RAD) 16

2.4.1.Khái niệm à đặc thù 16

2.4.2.Các kỹ thuật thực hiện 16

2 4 3 Ư / ược đ ểm 16

3.Model-Driven Requirements Engineering (MDRE) 17

3 1 ươ p áp l ận 17

3.2.Một số kĩ ậ đ ển hình 18

3.3.Các công cụ phần mềm hỗ trợ 19

3.3.1.GME(Generic Modeling Environment) 19

3.3.2.DSL TOOLS ( Domain-Specific Language Tools) 20

3.3.3.EMF(Eclipse Modeling Framework) 21

3.4.Các dự án phần mềm à cô đã ực hiện dựa trên MDRE 23

3.4.1.DMAN project 23

3.4.2.OPENPROD Project.( Open Model-Driven Whole-Product Development and Simulation Environment) 23

4.Tìm hiểu về các kỹ thuậ à p ươ p áp ươ lượng và thỏa thuận các yêu cầu phần mềm25 4 1 Các p ươ p áp c của ươ lượ , ỏa ậ cầ p ầ mềm 25

Trư c k ươ lượ , ỏa ậ : 25

Tro k ươ lượ , ỏa ậ : 25

a k ươ lượ , ỏa ậ : 25

4 2 Các k a cạ của ươ lượ , ỏa ậ cầ 25

4 2 1 C lược ả q x độ 25

4 2 2 Các ì ức cộ ác (Collaboration situations) 27

4 2 3 Các cô cụ ỗ rợ ươ lượ ỏa ậ 27

4 3 dụ ề các ệ ố ươ lượ , ỏa ậ 27

4.3.1.Aspire 27

4.3.2.Negoisst 28

4.3.3.EasyWinWin 28

4.3.4.SmartSettle 28

5.Tìm hiể , so sá đá á lựa chọn công cụ các công cụ UML 30

5.1.ArgoUML 30

5 1 1 T ă của ArgoUML 30

5 1 2 Ư đ ểm: 31

5.1.3 N ược đ ểm: 31

5.2.StarUML 31

5 2 1 T ă của StarUML : 31

5 2 2 Ư đ ểm: 32

5 2 3 N ược đ ểm của StarUML: 33

5.3.Visual Paradigm 33

Các ư đ ểm của VP-Paradigm 33

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ọ để phát hiện thông tin yêu cầu một cách chi ti t từ mộ cá â N ư là mộ kĩ sư p ầ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ụ p ươ p áp

à ư 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ấ để phát hiện thông tin về:

 Các ý ki n của ườ được phỏng vấn

 Các cảm ĩ của ườ được phỏng vấn

 Tình trạng hiện tại của phần mềm

Lư ý - Kinh nghiệm

- Ý ki đá á, ận xét của ườ được phỏng vấn

Quan sát tổng quan

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

N ườ được phỏng vấ oà Oa … Ngày: 03/09/2008

Tất cả đơ đặt hàng của khách hàng phả được

a oá rư c rồi m i giao hàng?

K t quả quan sát

K ô ưởng l m, ì ư đã r ể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ỏ mà các đáp á ường nằm trong các tình huố được xác đị rư c

Câu hỏ đó c ợp cho việc tạo các dữ liệu chính xác, tin cậ để dễ dàng phân tích

Hiệu quả à đỏi hỏ ười phỏng vấn phải có kỹ ă để đ ều khiển cuộc phỏng vấn

 Buồ c á c o ườ được phỏng vấn

 K ó có được nhiều thông tin chi ti t

 Thi các ý ưởng

 Mất thời gian chuẩn bị các câu hỏi

 Không tạo mối quan hệ ũa ữ ười phỏng vấn và nhữ ườ đượ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 thích hợp k ườ p â c q a â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ị ò bó à k ô ượng ép

Ư / ược đ ểm:

Ưu điểm:

 N ườ được phỏng vấn dễ dàng trả lời

 Không ràng buộc câu trả lời

 Có thể p á s ý ưởng m i

 Cung cấp nhiều chi ti ơ

 Có c c o ười phỏng vấ k ô được chuẩn bị rư c

 Tính linh hoạt cao

 Tính chính xác

 Tính tiện lợi

Nhược điểm:

 Thời gian hỏi kéo dài

 Nội dung có thể ượt qua phạm vi câu hỏi

 Ư đ ểm / ược đ ểm của p ươ p áp

 Nguồn thông tin phụ thuộc ào ườ được phỏng vấn

 N ười phỏng vấn phải có kỹ ă ao p tốt

 N u không chuẩn bị tốt dễ bị thất bại

 Có thể bấ đồng về ngôn ngữ khái niệm

1.2 Phương pháp bảng hỏi (Questionnaires)

 Thu thập thông tin ở nhiề ười v các đ ạ đ ểm khác nhau

 Nhiề ười tham gia vào dự án

 Cần thực hiện việc tham dò

 Cần giải quy t vấ đề rư c khi phỏng vấn

1.2.4 Ưu / nhược điểm

 Thu thập thông tin cứng nh c do được thi t k rư c, kém linh hoạt

 N ười lập bảng hỏi phải có kinh nghiệm và kỹ ă đặt câu hỏi

 Trả lời thụ động dễ đ ền không chính xác

1.2.5 Những lưu ý khi thực hiện phương pháp bảng hỏi

 B đầu bằng những câu hỏi thú vị và dễ trả lời

Hình 5 Bảng với câu hỏ đ 1.3 Phương pháp Quan sát (Observation)

1.3.1 Bản chất, đặc thù

Là p ươ p áp lại có kiểm soát các sự kiện hoặc hành vi ứng xử của co ười

T ường k t hợp v các p ươ p áp k ác để kiểm ra c éo độ chính xác của thu thập dữ liệu

1.3.2 Phân loại

Quan sát thụ độ N ười quan sát ngồi tại chỗ và ghi chép lại các hoạ độ , các bư c xử lý công việc Các bă deo đô k có ể được dùng Ghi chép hoặc bă ì được phân tích các sự hiện, các hoạ động công việc hoặc thông tin về công việc

Quan sát chủ động: tham gia trực ti p vào các hoạ đô xử lý

1.3.3 Các kỹ thuật thực hiện

Bư c 1 Xác định mục đ c q a sá

Bư c 2 Lựa chọ đố ượng quan sát

Bư c 3 Tổ chức à ư ng dẫn quan sát

Bư c 4 Báo cáo k t quả quan sát

1.3.4 Ưu/ nhược điểm

Ưu điểm:

Dễ thực hiệ đối v ười quan sát

Theo dõi trực ti p hoạ động của hệ thống thực t

Nhược điểm:

K t quả mang tính chủ quan

Tâm lý của ười bị quan sát có những phản ứng nhấ định

Sự bị động của p ươ p áp q a sá

Tốn kém thời gian

Thông tin bề ngoài, hạn ch k ô đầ đủ

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ự

Nghiên cứu phần mềm: Mộ các ường xuyên, các ứng dụng phải thay th các phần mềm cũ

Hệ thống hiện tại có thể đã có p ần mềm hỗ trợ từ rư c Nghiên cứu các phần mềm đã ồn tại cung cấp cho chúng ta các thông tin về quá trình xử lý công việc hiện thời và các mở rộng có ràng buộc bởi thi t k phần mềm Khi m khuy t của việc thu nhận thông tin từ việc xem xét phần mềm là tài liệu có thể không chính xác hoặc kịp thời, mà có thể k ô đọc được và thời gian có thể lãng phí n u ứng dụ đã bị xóa bỏ

1.4.2 Ưu diếm/ nhược điểm của phương pháp

Ưu điểm

 Tìm được các vấ đề còn tồn tại trong hệ thống

 Có cái nhìn tổng quan về các chức ă mà ệ thống cần phải có

Nhược điểm

 Thi u tài liệu

 Tài liệu h t hạn

 Các tài liệu là nguồn cung cấp ô k ô đú , rù lặp

yêu cầu phần mêm (Requirement Elicitation) nâng cao Phương pháp nguyên mẫu (Prototyping)

Một mô hình làm việc “ a à ô” của giải pháp cho hệ thống nhằm kiểm tra một số chức

ă ào đó

Có thể miêu tả GUI chi các ứng xử khác nhau của hệ thống

Nội dung có thể mã cứ ơ là r cập động CSDL

Không thể thi u trong quy trình phát triển phần mềm

Tính khả thi và hữu dụng của hệ thống có thể ư c lượ q a ro o pe rư c khi thực sự được

cà đặt

2.1.2 Các trường hợp thường dùng

 Hệ thống xây dựng chi các chức ă ươ mại m i

 Dùng trong quá trình xây dựng các kịch bản cho use case

 Các yêu cầ x đột

 Có vấ đề truyền thông giữa k ác à à ười phát triển

2.1.3 Các kỹ thuật thực hiện

“Throw-away” prototype

Bỏ đ k n trình tìm ki m yêu cầu hoàn tất

Tập trung vào các yêu cầu ít hiểu bi t nhất

T ường thực hiện ở bư c xác định yêu cầu

Evolutionnary prototype

Được giữ lại sau khi ti n trình tìm ki m hoàn tất

T ườ đưa ra c o sản phẩm cuối cùng

ư đ n việc phát triển nhanh hệ thống bằng cách tập trung vào các yêu cầ đã ểu bi t nhất

2.1.4 Ưu/ nhược điểm

Ưu điểm

 ươ p áp ữu dụng khi:

 Yêu cầu của ười dùng không rõ ràng

 Í ười liên quan

 Các thi t k phức tạp à đò ỏi mẫu cụ thể

 Vấ đề truyền thông giữa p â c à ười dùng

 Sẵn công cụ để xây dựng mẫu

Nhược điểm

 Khó thích ứng cho nhiều loạ ười dùng

 Chia sẻ dữ liệu v i các hệ thống khác ườ k ô được xem xét

 Kiểm ra ò đời phát triển hệ thố ường bị bỏ qua

 ì à x ư ng không chuẩn mực trong việc tạo ra tài liệu hình thức về yêu cầu hệ thống

 Các mẫ ường xây dựng trên các hệ thố đơ => c ưa xé ươ ác i hệ thống khác

2.2 Phương pháp Brainstrorming

2.2.1 Đặc thù

BrainStorming là kỹ thuật sáng tạo hỗ trợ việc ìm ý ưởng Việc sử dụng Brainstorming cho

p ép ìm được nhiề ý ưở đặc s c nhất trong thời gian ít nhất nhờ vào việc không bị phán

xé a đá á ệc nhận xé a đá á sẽ chỉ được thực hiệ sa k đã ập đủ nhiều

ý ưởng

Brainstorming giúp cho cá nhân hoặc tập thể có thể duy trì luồ s ĩ, ư d một cách liên tục à ý ưởng này có thể là gợi ý cho nhữ ườ k a ĩ ra ý m G a đoạn tìm ý ưởng k t thúc khi số lượ ý ưở ươ đối nhiều thì m i chuyể sa a đoạ đá á các ý ưởng

đã được ra để đưa ra k t luận

 Chọn các giải pháp khả thi, thực tiễn và phù hợp nhất v i hoàn cảnh

 Công cụ đ ển hình thực hiệ p ươ p áp

2.2.3 Ưu nhược điểm

Ưu điểm

Khuy n khích mọi thành viên tham gia

Cho phép các thành viên tranh luận v i nhau về các ý ki đề xuất

N ườ đ ều phố a ư ký d rì c ộc hội thảo không bị á đoạn

Diễn ra nhanh chóng

Đưa ra ải pháp khả thi cho vấ đề

Khuy k c ý ưở , s ĩ sá ạo độc đáo

ươ p áp Jo appl ca o de elopme (JAD) là ì ức phỏng vấn nhóm theo một

c ươ rì à p â c đ ều khiển thứ tự câu hỏi

Thành viên tham dự gồm ười tổ chức, ười sử dụng, nhà quản lý, phân tích viên hệ thố …

2.3.2 Các kỹ thuật thực hiện

Tổ chức cuộc họp từ 10 đ 20 ười

Thời gian diễn ra từ 5 đ n 10 ngày

Lư ữ các ý ki n bằ bă âm

Quản trị các x đột

Công cụ đ ển hình thực hiệ p ươ p áp

2.3.3 Ưu/ nhược điểm

Ư đ ểm

Hiệu quả

Cho k t quả nhanh

Giảm đá kể thời gian, chi phí và lỗi dự án

Nhiều vấ đề được thảo luậ đ n thống nhất

Nhiề ô được bổ sung và làm chính xác

N ược đ ểm

Chi phí l n, tốn kém

Cầ có ă p ò đặc biệ để tổ chức

Cầ ười có kinh nghiệm lã đạo

2.4 Phương pháp Rapid application development (RAD) 2.4.1 Khái niệm và đặc thù

ươ p áp Rap d appl ca o de elopme (RAD) là q rì p á r ển ứng dụng trong thời gian ng , ă dần từ bư c v i mỗi chu k

Xây dựng dựa r ư ng thành phần, tái sử dụng

Gồm một số nhóm, mỗ óm đảm nhiệm một pha trong RAD

2.4.2 Các kỹ thuật thực hiện

Business modeling

Process and Data modeling

Application Generation and Testing

2.4.3 Ưu/ nhược điểm

Ưu điểm

 rì được hoàn thành nhanh

 Khả ă á sử dụng mã nguồn

Nhược điểm

 Yêu cầu có thể bị lặp lại

 Cần nguồn nhân lực dồi dào

 Sự x đột của các thông tin có thể dẫ đ n thất bại

 Không phù hợp v i các ứng dụng khó module hóa hoặc đò ỏ ă cao

3 Model-Driven Requirements Engineering

MDRE được đề xuấ để đối phó v i sự phức tạp ngày cà ă của kỹ thuật hệ thống theo ý

ĩa của việc cung cấp thông số kỹ thuật yêu cầ ư mô ì c ức cần phải chính xác ,

đầ đủ, phù hợp , rõ ràng và dễ đọc và dễ dà để duy trì Một vấ đề quan trọ ro lĩ ực này là thi u một mô hình tổng thể và tiêu chuẩn hóa ngôn ngữ mô ì ro đó bao ồm toàn

bộ các yêu cầu quy trình kỹ thuật từ đặc tả yêu cầu , phân bổ để xác m sML đa được đề xuấ để áp ứng các yêu cầu này Trong bài báo này mộ mô ì đ ều khiển yêu cầu quy trình kỹ thuật cho các ứng dụng công nghiệp ro lĩ ực hệ thống tự độ được mô tả để ti t lộ những thi u sót trong công cụ mô hình gầ đâ à mô ì óa ô ữ Đặc biệt tập trung được la ed ào đị ĩa cầu và việc xác minh tự động của thi t k chống lại các yêu cầu

sử dụng mô hình thực thi Dựa trên phân tích một hồ sơ m i của Unified Modeling Language (UML) được gọi là Model Driven Yêu cầu kỹ thuậ c o Bosc Rexro ( MDRE4BR ) được trình bày nhằm mục đ c óp p ần vào cuộc đ ều tra m i nhấ ro lĩ vực này

Model-Driven Engineering (MDE) dịch theo ti ng Việ có ĩa là cô ệ ư ng mô hình MDE là hệ thố p ươ p áp l ận (Methodology) phát triển phần mềm Hệ thố p ươ pháp luận này nghiên cứu về: quy trình phát triển phần mềm (Process), các loại mô hình dùng

để mô tả hệ thống, ngôn ngữ mô hình hóa (Modeling Laguage), vá các công cụ hỗ trợ (CASE Tool) theo các cách ti p cận khác nhau

Một y u tố thành công quan trọng trong việc phát triển hệ thống thông tin là sự liên k t của hệ thống v i mục tiêu kinh doanh , ngữ ĩa k doa à q rì k doa á r ển nên được giải thoát khỏi mối quan tâm lập trình và có thể tập trung vào những vấ đề liên k t Phát triển hệ thố mô ì đ ều khiển (MDD- Model-driven system development ) không chỉ cung cấp một cách ti p cận có cấu trúc và có hệ thố để phát triển hệ thống , mà còn cung cấp các nhà phát triển khả ă sử dụng công nghệ mô hình chuyể đổ để lấy mô hình của một mức

độ trừ ượng thấp ơ có ể được ti p tục tinh ch , và thậm chí tạo ra phần mềm mã tự động

Kỹ thuậ đị ư mô ì (MDE) đã được chứng minh là có khả ă để đối phó v i sự phức tạp ro lĩ ực công nghệ phần mềm Mộ x ư ng trong mô hình hóa và mô phỏng

là để áp dụng các MDE mô hình các hệ thống kỹ thuật bao gồm các thành phần trong phần cứng và phần mềm Ngày càng phức tạp hệ thống kỹ thuậ đã ra ều thách thức ư ữ thi t k phù hợp và phê duyệ ươ rec ess đối v i các yêu cầu của khách hàng v i nghiên cứu tại Tập đoà Bosc đã c ỉ ra rằ ơ 50% của lĩ ực vấ đề là do k ô đủ yêu cầu kỹ thuậ (RE) RE đ kèm i sự phát triển sản phẩm toàn bộ q á rì , ro đó các à kỹ thuậ k ác a được am a Do đó, một mô hình phổ bi à được tiêu chuẩn hóa ngôn ngữ là yêu cầu mà chia sẻ sự hiểu bi t giữa các kỹ sư ừ các ngành khác nhau chung này ngôn ngữ sẽ cho phép xây dựng các yêu cầu mô hình, mô hình thi t k hệ thống, mô hình truy xuất nguồn gốc cũ ư xác m mô ì có c ứa thông tin chi ti t tên miền cụ thể

Trong các ngành kỹ thuật hệ thống và kỹ nghệ phần mềm, phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống m i hoặc được a đổi, dựa r cơ sở

là các yêu cầu (có thể mâu thuẫn) mà nhữ ười có vai trò quan trọ đối v i hệ thống,

chẳng hạ ười sử dụ , đưa ra ệc phân tích yêu cầ có ý ĩa q a rọ đối v i thành công của một dự án

Việc phân tích yêu cầu một cách có hệ thố cò được gọi là kỹ nghệ yêu cầu (requirements

e eer ) Đô k ó cò được gọi một cách không thật chính xác bằng những cái tên

ư thu thập yêu cầu (requirements gathering, requirements capture), hoặc đặc tả yêu cầu(requirements specification) Thuật ngữ "phân tích yêu cầ " cò được áp dụng cụ thể cho công việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm rõ cầu hay vi t tài liệu yêu cầu)

Các yêu cầu phả có đo được, kiểm thử được, có l q a đ n các nhu cầu hoặc cơ ội doanh nghiệp đã được xác định, và các yêu cầu phả được đị ĩa ở một mức độ chi ti đủ cho việc thi t k hệ thống