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

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 1 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 27 tháng 2 năm 2014 2 Mục lục Cc bảng trong bo co 3 Cc hnh trong bo co 3 Chương 1: Bài tập I 4 1) Process-Oriented Approach 4 2) Data-Oriented Approach 4 3) Architecture-Oriented Approach 4 4) Điểm mạnh yu của cc phương php tip cận 6 Chương 2: Bài tập II 7 1) Mô hnh thc nước 7 1.1) Khi niệm và mô hnh 7 1.2) Phân tích ưu nhược điểm 9 2) Mô hnh sử dụng lại 10 2.1) Tổng quan 10 2.2) Phân tích ưu khuyt điểm 10 3) Spiral SDLC 11 3.1) Spiral Model trong SDLC là gì? 11 3.2) Mô hình 11 3.3) Áp dụng khi nào? 13 3.4) Cc ưu điểm/nhược điểm? 13 4) Evolutionary SDLC 14 4.1) Khi niệm 14 4.2) Mô hình 15 4.3) Cc bước triển khai 16 4.4) Cc ưu điểm/nhược điểm? 16 5) RUP (Rational Unified Process) SDLC 17 5.1) Khi niệm 17 5.2) Mô hình 17 5.3) Cc bước triển khai 18 5.4) Áp dụng khi nào? 20 5.5) Cc ưu điểm/nhược điểm? 20 Chương 3: Bài tập III 22 1) Cc KPA cơ bản của Requirement Engineering 22 1.1) Đnh ngha Requirement Engineering 22 1.2) Cc KPA (key process area – vng xử lí quan trng) cơ bản 22 1.3) Sơ đ mi quan hệ gia cc KPA: 23 2) Mô tả ngn gn cc KPA 25 2.1) Requirement Development (Pht triển yêu cu) 25 2.2) Requirement Management (Quản lí yêu cu) 27 Tài liệu tham khảo 28 3 Cc bng trong bo co Table 1: Điểm mạnh yu của cc phương php tip cận Cc hnh trong bo co Hnh 1 : Cc giai đoạn của mô hnh thc nước 8 Hnh 2: Mô hnh sử dụng lại 10 Hnh 3: Mô hnh pht triển phn mềm xon c (A Spiral Model of Software Development and Enhancement - Boehm, 1988) 12 Hnh 4: Sự khc nhau gia mô hnh thc nước và mô hnh tin hóa trong pht triển phn mềm (The Evolutionary Development Model for Software - Elaine L. May and Barbara A. Zimmer) 15 Hnh 5: Mô hnh lặp của RUP (Wikipedia) 18 Hnh 6: Cc pha và mục tiêu mỗi pha trong RUP (Introduction to Software Development - Ma’am Marium Nosheen) 20 Hnh 7: Sơ đ quan hệ cu trc cc KPA 23 Hnh 8: Sơ đ quan hệ trong hoạt động của cc KPA 24 4 Chương 1: Bài tập I Đ bài: Phân biệt các hướng tip cận: Process-Oriented, Data-Oriented, Architecture-Oriented, các điểm mnh và yu của từng hướng tip cận 1. Process-Oriented Approach 2. Data-Oriented Approach 3. Architecture-Oriented Approach 4. Điểm mạnh yu của cc phương php tip cận 1) Process-Oriented Approach Bản cht của việc phân tích và thiêt k đặt trng tâm vào cc chức năng do phn mềm thực hiện.  Tập trung vào các giải thuật và thao tác xử lý d liệu  Quá trình phát triển phn mềm tập trung vào thể hiện cc phương php xử lý d liệu  Cu trúc d liệu thông thường không thể hiện rõ 2) Data-Oriented Approach D liệu không thay đổi bởi cc yêu cu hay đòi hỏi của người dng về cc thao tc nghiệp vụ. Trong thit k hướng d liệu, hệ thng được thit k dựa trên cu trc tin trn d liệu. Việc phân tích thit k được tin hành cho d liệu một cch tch bạch với yêu cu hay đòi hỏi của người dng về thao tc. Nghiên cứu và pht triển cơ sở d liệu tập trung vào cc thực thể và cc mi quan hệ của một hệ thng thông tin và dẫn đn sự pht triển của khi niệm, hợp lý và vật lý mô hnh d liệu, hệ thng chung và cc công cụ cũng như phn mềm pht triển cc quy trnh để hỗ trợ việc phân tích, thit k. Mô tả tổ chức của d liệu ,mô tả d liệu ly ra ở đâu và sử dụng như th nào. Mô hình d liệu được thành lập và được mô tả mi quan hệ gia các d liệu tương ứng này và cc quy đnh về mi quan hệ. Sử dụng cc Business rules để chỉ ra phương php xử lí d liệu. 3) Architecture-Oriented Approach Là phương php phân tích và thit k có cu trúc. Các yêu cu của hệ thng đích được phát triển được phân tích bằng việc đặc biệt chú ý tới chức năng của hệ thng và lung d liệu gia các chức năng. Mục đích của 5 phương php này là chuyển các tin trình trong biểu đ thành các modules chương trình và tiến hành phân chia các modules bằng cách tiếp cận từ trên xuống. • Lựa chn kin trúc và công nghệ phn mềm để thực hiện bài toán. • Áp dụng cc phương php Prototyping để nhanh chóng xây dựng được phn mềm. Phương php Prototyping có vai trò trong duyệt và kiểm sot yêu cu phn mềm gip hoàn thiện hơn về yêu cu, đp ứng được yêu cu của người dng. Cho người dng dng thử mẫu thử như là mẫu thử bản beta từ đó người dng sẽ dng thử và đưa ra nhng điểm tt, điểm không tt của mẫu thử, ci nào không cn thit của mẫu thử từ đó người phân tích viên có thể duyệt yêu cu nào đã đạt được yêu cu nào hay nhng yêu cu nào rườm rà có thể bỏ qua hay nên bổ sung nhng yêu cu g để thỏa mãn được yêu cu của người dng. Ví dụ: khi cho người dng delete một bản ghi th đòi hỏi phải có yêu cu là có nên delete hay không? Mẫu thử thẩmđnh yêu cu giải thích cc yêu cu và gip cc bên liên quan khm ph được vn đề. Thẩm đnh mẫu thử sẽ hoàn thành có hiệu quả cao và thit thực. nó có thể dụng chng trong cch ging nhau như là yêu cu hệ thng. Tài liệu đào tạo cho người sử dụng sẽ được cung cp. • Sử dụng cc Pattern kin trc mẫu để chỉ ra phương php xử lý d liệu 6 4) Điểm mnh yu của các phương pháp tip cận Hướng tip cận Process-Oriented Approach Data-Oriented Approach Architecture- Oriented Approach Điểm mạnh - Thích hợp với các bài toán phức tạp. - Giảm thời gian đp ứng của phn mềm do tập trung vào giải thuật và xử lí d liệu - Trnh được sự trùng lặp trong cơ sở d liệu - Thích hợp với hệ thng quản lí cơ sở d liệu. - Không phụ thuộc vào chức năng và yêu cu người sử dụng do thit k d liệu tách bạch. - Biểu diễn đươc cc mi quan hệ trong các bảng và gia các d liệu với nhau - Việc thit k phn mềm nhanh do áp dụng các bản mẫu có sẵn. Từ đó thưa k được nhng ưu điểm sẵn có. - Áp dụng các kin trúc công nghệ tt nht tăng cht lượng phn mềm. Điểm yu - Khó điều chỉnh các yêu cu cho nhiều người dùng. - Sử dụng các chức năng chng chéo nhau là khó tránh khỏi. Kt quả là hệ thng có nhiều chức năng chng chéo nhau là một trong nhng nhân t làm cho việc bảo trì trở nên khó khăn. - Các tệp d liệu được xây rt khó để thỏa mãn phn mềm - Việc xử lí d liệu không được linh hoạt do phụ thuộc vào các Business rules - Các chức năng của phn mềm phụ thuộc vào cách tổ chức cơ sở d liệu. - D liệu được xử lí phụ thuộc cao vào các bản mẫu sẵn có  B động trong thit k - Phụ thuộc vào công nghệ hiện tại Table 1: Điểm mnh yu của các phương pháp tip cận 7 Chương 2: Bài tập II Đ bài: Tổng kt và hệ thống li các mô hình SDLC: Mô hình thác nước, Mô hình sử dụng li, Mô hình Spiral, Mô hình Evolutionary, Mô hình RUP. Tìm các tài liệu phân tch các điểm mnh yu của các mô hình. 1. Mô hnh thc nước 2. Mô hnh sử dụng lại 3. Mô hình Spiral 4. Mô hình Evolutionary 5. Mô hình RUP 1) Mô hình thc nước 1.1) Khái niệm và mô hình Mô hình thác nước (ting Anh: waterfall model) là một mô hình của quy trình phát triển phn mềm, trong đó quy trnh pht triển trông ging như một dòng chảy, với cc pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt pha là: phân tích yêu cu, thit k, lập trình, kiểm thử, liên kt và bảo trì. Mô hnh thc nước gm 4 giai đoạn phân tích, thit k , lập trình kiểm thử. 8 Hình 1 : Các giai đon của mô hình thác nước  Phân tích yêu cu và tài liệu đặc tả (Requirements) là giai đoạn xc đnh nhng yêu cu liên quan đn chức năng và phi chức năng hệ thng phn mềm cn có. Giai đoạn này cn có sự tham gia tích cực của khch hàng và kt thc bằng một tài liệu “Bản đặc tả yêu câu phn mềm” hay SRS, trong đó bao gm toàn bộ tài liệu đã được duyệt và nghiệm thu bởi nhng người có trch nhiệm đi với dự n ( từ phía khch hàng). SRS chính là nền tảng cho cc hoạt động tip theo và cho đn cui của dự n. 9  Phân tích hệ thng (Analysis): giai đoạn xc đnh các công việc cn làm để hệ thng phn mềm, hiểu lnh vực thông tin, chức năng, hành vi, tính năng và giao diện của phn mềm sẽ phát triển. Cn phải tạo tư liệu và bản thảo với khch hang, người dung. giai đoạn xc đnh các công việc cn làm để hệ thng phn mềm  Thit k (Design): là quá trình nhiều bước với 4 thuộc tính khác nhau của 1 chương trnh: cu trúc d liệu, kin trúc phn mềm, biều diễn giao diện và chi tit thủ tục (thuật toán).  Lập trình (coding): Chuyển thit k thành chương trnh my tính bởi ngôn ng nào đó. Nu thit k đã được chi tit hóa thì lập trình có thể thun ty cơ hc.  Kiểm thử (Testing): Kiểm tra cc chương trnh và module cả về logic bên trong và chức năng bên ngoài, nhằm phát hiện ra lỗi và đảm bảo với đu vào xc đnh thì cho kt quả mong mun.  Cài đặt và bảo tr (Acceptance): đây là giai đoạn cài đặt, cu hnh và hun luyện khch hàng. Giai đoạn này sửa cha nhng lỗi của phn mềm nu có và có thể pht triển thêm nhng yêu cu mới mà khch hàng yêu cu ( như sửa đổi, thêm, bớt chức năng/đặc điểm của hệ thng. 1.2) Phân tch ưu nhược điểm  Ưu điểm:  Chuỗi các hoạt động được thực hiện theo quy trình rõ ràng.  Thay đổi yêu cu được giảm ti thiểu khi dự án bt đu.  Dễ phân công công việc, phân b chi phí, giám sát công việc.  Nhược điểm:  Thực t các dự án ít khi tuân theo dòng tun tự của mô hình, mà thường có sự lặp lại.  Mi quan hệ gia cc giai đoạn không được thể hiện  Khách hàng ít khi tuyên b rõ ràng khi nào xong ht các yêu cu  Khách hàng phải có lòng kiên nhẫn chờ đợi thời gian nht đnh mới có sản phẩm. Nu phát hiện ra lỗi nặng thì rt khó khc phục.  Khả năng tht bại cao 10 2) Mô hnh sử dụng lại 2.1) Tổng quan Hình 2: Mô hình sử dụng li Mô hnh sử dụng lại : ti sử dụng thông tin được tạo ra trong cc dự n pht triển phn mềm trước đó nhằm giảm cc chi phí, tài nguyên cho việc pht triển dự n mới. Việc sử dụng lại cho phép xây dựng hệ thng phn mềm mới với cht lượng và độ tin cậy cao hơn. Mô hnh gm 6 giai đoạn: 1. Requirements specification ( Yêu cu kỹ thuật) 2. Component analysis ( Phân tích thành phn ) 3. Requirements modification ( Sửa đổi) 4. System design with reuse ( Thit k hệ thng với cc thành phn ti sử dụng) 5. Development and integration ( Pht triển) 6. System validation ( Xc nhận hệ thng ) 2.2) Phân tch ưu khuyt điểm a. Ưu điểm  Giảm chi phí pht triển phn mềm so với việc xây dựng một hệ thng phn mềm mới hoàn toàn.  Tit kiệm thời gian v mỗi giai đoạn pht triển lại sử dụng lại cc giai đoạn của qu trnh pht triển phn mềm trước nhưng được tinh ch  Giảm thiểu cc sai sót, lỗi của sản phẩm cui cng so với phn mềm trước đó. [...]... (Phát triển yêu cầu) + Requirement Elicitation (Phát hiện yêu cầu) + Requirement Analysis (Phân tích yêu cầu) + Requirement Specification (Đặc tả yêu cầu) + Requirement Verification (Kiểm thử yêu cầu) – Requirement Management (Quản lí yêu cầu) 22 1.3) Sơ đồ mối quan hệ giữa các KPA: Về mặt cấu trúc Hình 7: Sơ đồ quan hệ cấu trúc các KPA (Slide bài giảng Phân tích yêu cầu phần mềm – Thầy... dụng yêu cầu  Mục tiêu: • Xác định các yêu cầu quá trình phát triển • Xác định tầm nhìn và phạm vi • Xác định các lớp người dùng • Xác định các tiêu chí sản phẩm • Xác định các trường hợp ca sử dụng • Xác định các sự kiện hệ thống và đáp ứng + Requirement Analysis (Phân tích yêu cầu) Phân tích yêu cầu là quá trình phân tích các dữ liệu thu được trong Phát hiện yêu. .. lượng  Mục tiêu: • Phát hiện và giải quyết xung đột giữa các yêu cầu • Tìm ra phạm vi của phần mềm và cách mà nó tác động tới môi trường xung quanh • Nghiên cứu các yêu cầu hệ thống để tìm ra yêu cầu phần mềm + Requirement Specification (Đặc tả yêu cầu) Đặc tả yêu cầu là quá trình xác định các văn bản chức năng và bổ trợ dựa trên các yêu cầu và hỗ trợ bằng các công nghệ trực... tả yêu cầu phần mềm • Xác định các nguồn yêu cầu • Gán nhãn riêng cho mỗi yêu cầu • Ghi lại các quy tắc kinh doanh • Xác định các thuộc tính chất lượng  Mục tiêu: • Tạo tài liệu định nghĩa hệ thống • Đặc tả được yêu cầu hệ thống • Đặc tả được yêu cầu phần mềm + Requirement Verification (Kiểm thử yêu cầu) Kiểm thử yêu cầu là quá trình xem xét lại các đặc tả yêu cầu và. .. tích yêu cầu phần mềm – Thầy Huỳnh Quyết Thắng) Quy trình yêu cầu phần mềm có 2 KPA cơ bản là Phát triển yêu cầu và Quản lí yêu cầu, trong đó Phát triển yêu cầu bao gồm 4 KPA thành phần được chỉ ra trong sơ đồ 23 Về mặt hoạt động Hình 8: Sơ đồ quan hệ trong hoạt động của các KPA (Slide bài giảng Phân tích yêu cầu phần mềm – Thầy Huỳnh Quyết Thắng) Ban quản lí tiếp thị khách... Requirement Development (Phát triển yêu cầu) Phát triển yêu cầu là giai đoạn xác định các yêu cầu của khách hàng đối với hệ thống, sản phẩm cho ra là bản yêu cầu cơ sở Bốn giai đoạn nhỏ của KPA này đảm nhận các công việc cụ thể của quá trình yêu cầu phần mềm + Requirement Elicitation (Phát hiện yêu cầu) Phát hiện yêu cầu là quá trình thu thập và tài liệu hóa các nhu cầu của... cầu, giải quyết xung đột, phân tích luật thương mại, tài liệu hóa các giả định, các ràng buộc và các sự phụ thuộc, đồng thời làm việc với các bên liên quan để tạo lập các ưu tiên ban đầu Các hoạt động cụ thể: 25 • Vẽ sơ đồ ngữ cảnh • Tạo mẫu • Phân tích tính khả thi • Gán độ ưu tiên các yêu cầu • Mô hình hóa các yêu cầu • Tạo một từ điển dữ liệu • Phân bổ các yêu cầu tới hệ thống con... liệu yêu cầu • Kiểm tra các yêu cầu • Xác định các tiêu chí chấp nhận • Tạo mẫu thử 26 • Kiểm tra sự chấp nhận  Mục tiêu: • Đảm bảo các kĩ sư phần mềm hiểu rõ tất cả yêu cầu • Đảm bảo các yêu cầu đưa ra được khách hàng chấp nhận 2.2) Requirement Management (Quản lí yêu cầu) 2.2.1) Định nghĩa Requirement Management Quản lý các yêu cầu phần mềm thực hiện các giao tiếp và thoả... kết thúc dự án  bản than điều này là 1 rủi ro – Chi phí tốn kém – Yêu cầu nhiều tài nguyên và kỹ năng cho phân tích rủi ro (giống spiral model) – Các tiến trình dự án phụ thuộc nhiều vào bước phân tích rủi ro 5) RUP (Rational Unified Process) SDLC 5.1) Khái niệm RUP (Rational Unified Process) là một quá trình phát triển phần mềm theo mô hình lặp (iterative) được sáng tạo bởi Rational Software... xoắn ốc là một quá trình phát triển phần mềm (còn gọi với thuật ngữ khác là software development life-cycle, SDLC) với định hướng giải quyết rủi ro (risk-driven) Nó tương đối giống với mô hình lặp và tăng tiến (iterative and incremental development model), nhưng nhấn mạnh vào phân tích và quản lý rủi ro của dự án phần mềm Mô hình xoắn ốc phát triển và tiến hóa sau mô hình thác nước, dựa . của việc phân tích và thiêt k đặt trng tâm vào cc chức năng do phn mềm thực hiện.  Tập trung vào các giải thuật và thao tác xử lý d liệu  Quá trình phát triển phn mềm tập trung vào thể. Phân tích yêu cu và tài liệu đặc tả (Requirements) là giai đoạn xc đnh nhng yêu cu liên quan đn chức năng và phi chức năng hệ thng phn mềm cn có. Giai đoạn này cn có sự tham gia tích. tự nghiêm ngặt và không có sự quay lui hay nhảy vượt pha là: phân tích yêu cu, thit k, lập trình, kiểm thử, liên kt và bảo trì. Mô hnh thc nước gm 4 giai đoạn phân tích, thit k ,