Thông tin tài liệu
Hỗ trợ ơn tập [ĐỀ CƢƠNG CHƢƠNG TRÌNH ĐẠI HỌC] Chương 1: Bài tập I Đề bài: Phân biệt hƣớng tiếp cận: Process-Oriented, Data-Oriented, Architecture-Oriented, điểm mạnh yếu hƣớng tiếp cận Process-Oriented Approach Data-Oriented Approach Architecture-Oriented Approach Điểm mạnh yếu phương pháp tiếp cận 1) Process-Oriented Approach Bản chất việc phân tích thiêt kế đặt trọng tâm vào chức phần mềm thực Tập trung vào giải thuật thao tác xử lý liệu Quá trình phát triển phần mềm tập trung vào thể phương pháp xử lý liệu Cấu trúc liệu thông thường rõ 2) Data-Oriented Approach Dữ liệu không thay đổi yêu cầu hay đòi hỏi người dùng thao tác nghiệp vụ Trong thiết kế hướng liệu, hệ thống thiết kế dựa cấu trúc tiến trìn liệu Việc phân tích thiết kế tiến hành cho liệu cách tách bạch với yêu cầu hay đòi hỏi người dùng thao tác Nghiên cứu phát triển sở liệu tập trung vào thực thể mối quan hệ hệ thống thông tin dẫn đến phát triển khái niệm, hợp lý vật lý mơ hình liệu, hệ thống chung công cụ phần mềm phát triển quy trình để hỗ trợ việc phân tích, thiết kế Mô tả tổ chức liệu ,mô tả liệu lấy đâu sử dụng Mơ hình liệu thành lập mô tả mối quan hệ liệu tương ứng quy định mối quan hệ Sử dụng Business rules để phương pháp xử lí liệu 3) Architecture-Oriented Approach Là phương pháp phân tích thiết kế có cấu trúc Các yêu cầu hệ thống đích phát triển phân tích việc đặc biệt ý tới chức hệ thống luồng liệu chức Mục đích phương pháp chuyển tiến trình biểu đồ thành modules chương trình tiến hành phân chia modules cách tiếp cận từ xuống • Lựa chọn kiến trúc cơng nghệ phần mềm để thực tốn • Áp dụng phương pháp Prototyping để nhanh chóng xây dựng phần mềm Phương pháp Prototyping có vai trị duyệt kiểm sốt u cầu phần mềm giúp hoàn thiện yêu cầu, đáp ứng yêu cầu người dùng Cho người dùng dùng thử mẫu thử mẫu thử beta từ người dùng dùng thử đưa điểm tốt, điểm không tốt mẫu thử, không cần thiết mẫu thử từ người phân tích viên duyệt yêu cầu đạt yêu cầu hay yêu cầu rườm rà bỏ qua hay nên bổ sung yêu cầu để thỏa mãn yêu cầu người dùng Ví dụ: cho người dùng delete ghi địi hỏi phải có u cầu có nên delete hay không? Mẫu thử thẩmđịnh yêu cầu giải thích yêu cầu giúp bên liên quan khám phá vấn đề Thẩm định mẫu thử hồn thành có hiệu cao thiết thực dụng chúng cách giống yêu cầu hệ thống Tài liệu đào tạo cho người sử dụng cung cấp • Sử dụng Pattern kiến trúc mẫu để phương pháp xử lý liệu 4) Điểm mạnh yếu phƣơng pháp tiếp cận Hướng tiếp cận Process-Oriented Approach - Thích hợp với tốn phức tạp - Giảm thời gian đáp ứng phần mềm tập trung vào giải thuật xử lí liệu - Tránh trùng lặp sở liệu Điểm mạnh Điểm yếu - Khó điều chỉnh yêu cầu cho nhiều người dùng - Sử dụng chức chồng chéo khó tránh khỏi Kết hệ thống có nhiều chức chồng chéo nhân tố làm cho việc bảo trì trở nên khó khăn - Các tệp liệu xây khó để thỏa mãn phần mềm Data-Oriented Approach ArchitectureOriented Approach - Thích hợp với hệ - Việc thiết kế thống quản lí sở phần mềm nhanh liệu áp dụng - Không phụ thuộc mẫu có sẵn Từ vào chức thưa kế yêu cầu người sử ưu điểm sẵn dụng thiết kế có liệu tách bạch - Áp dụng kiến - Biểu diễn đươc trúc công nghệ tốt mối quan hệ tăng chất bảng lượng phần mềm liệu với - Việc xử lí liệu - Dữ liệu xử khơng linh lí phụ thuộc cao hoạt phụ thuộc vào mẫu vào Business sẵn có rules Bị động - Các chức thiết kế phần mềm phụ thuộc vào cách tổ chức - Phụ thuộc vào công sở liệu nghệ Table 1: Điểm mạnh yếu phƣơng pháp tiếp cận Chương 2: Bài tập II Đề bài: Tổng kết hệ thống lại 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 tài liệu phân tích điểm mạnh yếu mơ hình 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 1) Mơ hình thác nước 1.1) Khái niệm mơ hình Mơ hình thác nƣớc (tiếng Anh: waterfall model) mơ hình quy trình phát triển phần mềm, quy trình phát triển trơng giống dịng chảy, với pha thực theo trật tự nghiêm ngặt khơng có 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 bảo trì Mơ hình thác nước gồm giai đoạn phân tích, thiết kế , lập trình kiểm thử Hình : Các giai đoạn mơ hình thác nƣớc Phân tích yêu cầu tài liệu đặc tả (Requirements) giai đoạn xác định yêu cầu liên quan đến chức phi chức hệ thống phần mềm cần có Giai đoạn cần có tham gia tích cực khách hàng kết thúc tài liệu “Bản đặc tả yêu câu phần mềm” hay SRS, bao gồm tồn tài liệu duyệt nghiệm thu người có trách nhiệm dự án ( từ phía khách hàng) SRS tảng cho hoạt động cuối dự án Phân tích hệ thống (Analysis): giai đoạn xác định 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 giao diện phần mềm phát triển Cần phải tạo tư liệu thảo với khách hang, người dung giai đoạn xác định công việc cần làm để hệ thống phần mềm Thiết kế (Design): q trình nhiều bước với thuộc tính khác chương trình: cấu trúc liệu, kiến trúc phần mềm, biều diễn giao diện chi tiết thủ tục (thuật tốn) Lập trình (coding): Chuyển thiết kế thành chương trình máy tính ngơn ngữ Nếu thiết kế chi tiết hóa lập trình túy học Kiểm thử (Testing): Kiểm tra chương trình module logic bên chức bên ngoài, nhằm phát lỗi đảm bảo với đầu vào xác định cho kết mong muốn Cài đặt bảo trì (Acceptance): giai đoạn cài đặt, cấu hình huấn luyện khách hàng Giai đoạn sửa chữa lỗi phần mềm có phát triển thêm yêu cầu mà khách hàng yêu cầu ( sửa đổi, thêm, bớt chức năng/đặc điểm hệ thống 1.2) Phân tích ƣu nhƣợc điểm Ưu điểm: Chuỗi hoạt động thực theo quy trình rõ ràng Thay đổi yêu cầu giảm tối thiểu 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ế dự án tn theo dịng mơ hình, mà thường có lặp lại Mối quan hệ giai đoạn Khách hàng tuyên bố rõ ràng xong hết yêu cầu Khách hàng phải có lịng kiên nhẫn chờ đợi thời gian định có sản phẩm Nếu phát lỗi nặng khó khắc phục Khả thất bại cao 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 tạo dự án phát triển phần mềm trước nhằm giảm chi phí, tài nguyên cho việc phát triển dự án Việc sử dụng lại cho phép xây dựng hệ thống phần mềm với chất lượng độ tin cậy cao Mơ hình gồm giai đoạn: Requirements specification ( Yêu cầu kỹ thuật) Component analysis ( Phân tích thành phần ) Requirements modification ( Sửa đổi) System design with reuse ( Thiết kế hệ thống với thành phần tái sử dụng) Development and integration ( Phát triển) 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 hệ thống phần mềm hồn tồn Tiết kiệm thời gian giai đoạn phát triển lại sử dụng lại giai đoạn trình phát triển phần mềm trước tinh chế Giảm thiểu sai sót, lỗi sản phẩm cuối so với phần mềm trước b, nhược điểm Việc sử dụng lại khơng khả thi thành phần tái sử dụng khơng đầy đủ, cần phải thiết kế Có thể khơng đáp ứng nhu cầu khách hàng không khả thi thành phần sử dụng lại chứa nhiều lỗi liên quan đến thiết kế hay khắc phục 3) Spiral SDLC 3.1) Spiral Model SDLC gì? Mơ hình xoắn ốc q trình phát triển phần mềm (cịn gọi với thuật ngữ khác software development life-cycle, SDLC) với định hướng giải rủi ro (risk-driven) Nó tương đối giống với mơ hình lặp tăng tiến (iterative and incremental development model), nhấn mạnh vào phân tích quản lý rủi ro dự án phần mềm Mơ hình xoắn ốc phát triển tiến hóa sau mơ hình thác nước, dựa kinh nghiệm cải tiến mơ hình thác nước Riêng bao chứa mơ hình khác trường hợp đặc biệt, cung cấp hướng dẫn làm để kết hợp mơ hình khác cách phù hợp với dự án phần mềm 3.2) Mơ hình Mơ hình trực quan mơ hình phát triển giống tên gọi nó: 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) Có thể thấy, bán kính q trình phát triển tăng dần, đại diện cho chi phí phát sinh q trình hồn thành bước phát triển phần mềm, cịn góc q trình (Boehm gọi angle dimension) biểu diễn q trình hồn thành bước phát triển Các bước triển khai Mơ hình xoắn ốc gồm nhiều vòng lặp khác qua pha: Lên kế hoạch, Phân tích rủi ro, Thực Đánh giá Vòng xoắn ốc sở: pha lên kế hoạch, yêu cầu phần mềm thu thập xác định, rủi ro đánh giá Các vịng xoắn ốc sau xây dựng dựa vòng xoắn ốc sở: Các yêu cầu thu thập suốt pha lên kế hoạch Trong pha phân tích rủi ro, rủi ro nhận diện đưa giải pháp rủi ro Cuối pha này, nhóm phát triển cho nguyên mẫu phần mềm cần phát triển Phần mềm xây dựng pha thực (engineering), với khâu kiểm thử cuối pha Pha đánh giá cho phép khách hàng đánh giá sản phẩm dự án thời điểm trước dự án tiếp tục chuyển sang vòng xoắn ốc 3.3) Áp dụng nào? Khi việc đánh gia chi phí rủi ro dự án quan trọng Cho dự án có rủi ro từ mức trung bình trở lên Các dự án dài hạn mà biết trước thay đổi lớn tiềm ẩn Khi khách hàng không chắn họ cần phần mềm mà yêu cầu Khi yêu cầu phần mềm phức tạp Khi cần cho dịng sản phẩm (các tính bổ sung dần tùy theo yêu cầu thị trường) Khi mong đợi đầu dự án thay đổi lớn (như nghiên cứu, khám phá) 3.4) Các ƣu điểm/nhƣợc điểm? Ƣu điểm: – Quá trình phá triển lặp lặp lại liên tục hữu ích cho quản lý rủi ro Các nhà phát triển cần mơ tả đặc tính cốt yếu trước sau phát 10 triển nguyên mẫu, sản phẩm dựa mô tả Những nguyên mẫu kiểm thử có thay đổi mong muốn, thay đổi thực hệ thống (của vòng xoắn ốc sau) Phương pháp tiếp cận liên tục đặn tối thiểu hóa rủi ro hay thất bại phát sinh từ thay đổi hệ thống – Như mơ hình xoắn ốc có khả đáp ứng cao thay đổi xảy pha dự án phần mềm (nhất thay đổi yêu cầu phần mềm) – Việc xây dựng nguyên mẫu nhanh tốn kém, việc ước lượng chi phí phát triển trở nên dễ dàng hơn; đồng thời khách hàng hiểu sâu giành nhiều quyền quản trị hệ thống (họ tham gia tích cực vào vòng xoắn ốc) Nhƣợc điểm: – Chỉ phát huy hiệu thực so với mơ hình khác dự án lớn (với chi phí liên quan độ phức tạp cao nhiều) Do đó, mơ hình tốn kém, mặt tài lẫn người – Để áp dụng mơ hình này, cần có chun gia nhiều kinh nghiệm, kỹ việc đánh giá bất định rủi ro dự án – Việc thực dự án cần có kỹ luật chặt chẽ, bước dự án cần tuân theo nghiêm ngặt – Chỉ riêng chi phí cho việc đánh giá rủi ro hệ thống cịn cao chi phí để xây dựng lên hệ thống – Thành cơng dự án phụ thuộc nhiều vào pha phân tích rủi ro 4) Evolutionary SDLC 4.1) Khái niệm Mơ hình tiến hóa dựa ý tưởng nhanh chóng phát triển phiên phần mềm từ đặc tả trừu tượng thay đổi, cải tiến phiên theo đánh giá yêu cầu khách hàng Mỗi phiên phần 11 mềm sau kế thừa đặc tính tốt từ phiên trước Các phiên sau cải tiến dựa phản hồi khách hàng để tạo hệ thống thỏa mãn nhu cầu khách hàng Và phần mềm thỏa mãn yêu cầu khách hàng, bàn giao hồn tồn cho khách hàng 4.2) Mơ hình – Để hiểu mơ hình tiến hóa, ta tìm khác mơ hình tiến hóa mơ hình thác nước truyền thống: Hình 4: Sự khác mơ hình thác nƣớc mơ hình tiến hóa phát triển phần mềm (The Evolutionary Development Model for Software - Elaine L May and Barbara A Zimmer) – Mơ hình thác nước áp dụng phổ biến Tuy nhiên, nhược điểm lớn mơ hình này, hiệu dự án phần mềm mà đặc tả rõ ràng từ đầu, yêu cầu nhóm phát triển phải hiểu rõ phần mềm mà xây dựng, lượng giá khó khăn gặp phải suốt trình phát triển Tuy nhiên thực tế yêu cầu phần mềm luôn thay đổi suốt q trình dự án thực hiện, gây nhiều khó khăn cho việc thực dự án (giai đoạn implement) Hơn nữa, nhiều yêu cầu khách hàng lại không rõ ràng từ đầu, hiểu biết nhóm phát triển khơng tồn diện phần mềm mà xây dựng – Mơ hình tiến hóa giúp giải nhược điểm mơ hình thác nước Nó chi giai đoạn thực (implement) thành nhiều chu kỳ Mỗi 12 chu kỳ có bước mơ hình thác nước (incremental waterfalls): Lên kế hoạch, Thiết kế, Thực hiện, Kiểm thử Nhờ đó, người dùng có hội tiếp cận tới phần mềm cuối chu kỳ đưa đánh giá, phản hồi lại cho nhóm phát triển Bằng cách này, thay đổi yêu cầu người dùng giải chu kỳ sau – Vì người dùng tham gia có ảnh hưởng quan trọng q trình thực (implement), sản phẩm cuối đáp ứng sát yêu cầu người dùng 4.3) Các bƣớc triển khai Khảo sát yêu cầu, đưa đặc tả yêu cầu người dùng Thiết kế ban đầu dựa đặc trưng quan trọng hệ thống Lên kế hoạch thực Thực chu kỳ phát triển thác nước (Plan – Design – Implement – Test) Sau bước test giao cho khách hàng phiên trung gian để khách hàng đánh giá nhận phản hồi Bước kế hoạch chu kỳ dựa phản hồi khách hàng chu kỳ trước Kiểm thử phiên cuối Áp dụng nào? Giống với mơ hình xoắn ốc Được áp dụng nhiều cho dự án lớn mà yêu cầu ban đầu cịn chưa rõ ràng, cần có sản phẩm sớm 4.4) Các ƣu điểm/nhƣợc điểm? Ƣu điểm: – Nhờ chia nhỏ trịnh thực thành phần nhỏ quản lý được, kế hoạch dự án trở nên rõ ràng trực quan Nó làm giảm phức tạp dự án, giảm thiểu nhiều rủi ro giải kịp thời rủi ro, thay đổi (nhờ liên tục nhận phản hồi cuối chu kỳ con) – Tầm nhìn dài hạn hệ thống chia thành bước ngắn hạn 13 – Các bước thực xác định độ ưu tiên rõ ràng – Có kết sớm – “công cụ” giao tiếp tốt nhóm phát triển khách hàng (thảo luận phản hồi quanh sản phẩm thời) – Có phản hồi khách hàng từ bên ngồi nhóm phát triển – Có cải tiến cho sản phẩm – Có thể dễ dàng nhận u cầu cơng việc hồn thành – Có thể xác định trước thành phần chức chung Nhƣợc điểm: – Không phù hợp với dự án nhỏ – Độ phức tạp quản lý tăng – Không biết rõ ràng kết thúc dự án than điều rủi ro – Chi phí tốn – Yêu cầu nhiều tài nguyên kỹ 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) trình phát triển phần mềm theo mơ hình lặp (iterative) sáng tạo Rational Software Corporation từ 2003 Nó trình phát triển mang tính thích nghi mang tính khn mẫu mơ hình khác RUP đội phát triển thiết kế, lựa chọn đặc tính phù hợp mà họ thấy cần cho dự án phần mềm 5.2) Mơ hình Các pha khung phát triển RUP có dạng: 14 Hình 5: Mơ hình lặp RUP (Wikipedia) Các pha : Bắt đầu, Cộng tác – chuẩn bị, Xây dựng Chuyển dịch Các cơng việc cần thực hiện: Tìm hiểu mơ hình dịch vụ, Xác định u cầu, Phân tích – Thiết kế, Thực hiện, Kiểm thử Triển khai Ngồi cơng việc trên, cịn có cơng việc hỗ trợ khác: Quản lý cấu hình thay đổi, Quản lý dự án, Môi trường dự án 5.3) Các bƣớc triển khai – Pha bắt đầu (inception phase) Mục đích pha xác định phạm vi hệ thống để làm sở cho việc tính tốn chi phí ban đầu ngân sách Trong pha này, yếu tố liên quan đến kinh doanh xác định (như bối cảnh kinh doanh, yếu tố thành cơng, dự báo tài chính…) Pha sinh mơ hình ca sử dụng, kế hoạch dự án, thẩm định rủi ro ban đầu mô tả dự án Các thành phần yếu tốc kinh doanh để kiểm tra xem xét xem có tiếp tục thực dự án hay khơng (phải vượt qua LifeCyle Objective) – Pha chuẩn bị (elaboration) Mục đích pha giảm thiểu rủi ro Các rủi ro phát đề xuất giải pháp cách phân 15 tích yếu tố liên quan đến dự án Đến pha này, dự án bắt đầu định hình: Vấn đề phân tích kiến trúc dự án ban đầu xác định – Pha phải vượt qua cột mốc kiến trúc vịng đời (LifeCycle Architecture Milestone) Nếu khơng vượt qua cột mốc này, thời gian để thiết kế lại định hủy dự án – Pha xây dựng Mục đích pha xây dựng hệ thống phần mềm Trọng tâm pha đặt vào việc phát triển thành phần chức hệ thống Việc lập trình thực chủ yếu pha Việc xây dựng hệ thống phần mềm pha chia theo chức năng, thành phần (component) thành phận quản lý xây dựng nguyên mẫu (tức phần tương đối hồn chỉnh chức năng) Mỗi phận thực vòng lặp riêng – Pha chuyển dịch Pha thực việc chuyển dịch hệ thống từ trình phát triển sang sản phẩm hồn thiện, đưa tới người sử dụng giúp họ sử dụng hiệu Các hoạt động pha gồm có đào tạo người dùng cuối nhân viên bảo trì; thực kiểm thử hệ thống để kiểm tra tính đắn so với mong muốn người dùng cuối Sản phẩm đối chiếu với yêu cầu chất lượng đề pha bắt đầu – Một lưu ý quan trọng pha RUP: thân pha vịng lặp, thực đạt mục tiêu pha 16 Hình 6: Các pha mục tiêu pha RUP (Introduction to Software Development - Ma’am Marium Nosheen) 5.4) Áp dụng nào? Mơ hình RUP áp dụng rộng rãi, nhờ tính thích nghi (adaptive) Các nhóm phát triển chọn lựa yếu tố cảm thấy cần thiết cho dự án phần mềm để áp dụng RUP 5.5) Các ƣu điểm/nhƣợc điểm? (An overview of the Rational Unified Process (RUP) - Eric Villagomez) Ƣu điểm: – Thường xuyên nhận phản hồi từ cổ đông – Sử dụng tài nguyên dự án cách hiệu – Cung cấp xác mà khách hàng muốn – Các vấn đề phát sớm dự án – Hỗ trợ mơ hình phát triển lặp – Cải thiện quản lý rủi ro 17 Nhƣợc điểm: – Các tiến trình dự án phức tạp để thực – Quá trình phát triển vượt q tầm kiểm sốt (do đánh gia ban đầu sai chi phí, tài nguyên rủi ro yếu tố bất định) – Cần chuyên gia để đáp ứng mục tiêu mơ hình phát triển – Tiến trình nặng 18 Chương 3: Bài tập III Đề bài: Tìm KPA Requirement Engineering vẽ sơ đồ biểu diễn mối quan hệ Mô tả ngắn gọn nội dung KPA Các nc e ui e ent nginee ing 1.1) Đ nh ngh a Requirement Engineering 1.2) Các KPA (key process area – v ng xử lí quan trọng) – Requirement Development (Phát triển yêu cầu) Requirement Elicitation (Phát 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) 19 1.3) Sơ đồ mối quan hệ KPA: Về mặt c u tr c Hình 7: Sơ đồ quan hệ c u tr c KPA (Slide giảng Phân tích yêu cầu phần mềm – Thầy Huỳnh uyết Thắng) uy trình u cầu phần mềm có KPA Phát triển yêu cầu uản lí u cầu, Phát triển u cầu bao gồm KPA thành phần sơ đồ 20 Về mặt hoạt động Hình 8: Sơ đồ quan hệ hoạt động KPA (Slide giảng Phân tích yêu cầu phần mềm – Thầy Huỳnh uyết Thắng) Ban quản lí tiếp thị khách hàng (Marketing Customer Management) tiến hành hoạt động với khách hàng để xác định yêu cầu hệ thống xây dựng Giai đoạn Requirement Development tạo tài liệu yêu cầu sở Base Line Requirement (thơng qua hoạt động phân tích tài liệu, vấn, đàm phán…) để gửi cho khách hàng làm bước khởi đầu cho giai đoạn Requirement Management Sau có yêu cầu sở, ban quản lí tiếp thị khách hàng tiếp tục làm việc với khách hàng để thu nhận, xử lí yêu cầu thay đổi từ khách hàng tạo nên phiên tài liệu yêu cầu Sau yêu cầu lại cập nhật vào Base Line Requirement gửi cho khách hàng, để tiếp tục lấy ý kiến khách hàng uá trình tiếp tục bên liên quan đạt đồng thuận yêu cầu hệ thống 21 Mô t ng n g n 2.1) Requirement Development (Phát triển yêu cầu) Phát triển yêu cầu giai đoạn xác định yêu cầu khách hàng hệ thống, sản phẩm cho yêu cầu sở Bốn giai đoạn nhỏ KPA đảm nhận công việc cụ thể trình yêu cầu phần mềm Phát yêu cầu q trình thu thập tài liệu hóa nhu cầu bên liên quan, xác định yêu cầu tài nguyên thu thập thông tin, tài liệu cần thiết khác Đây bước trình tìm hiểu vấn đề yêu cầu giải Hoạt động thuộc người, bên liên quan thiết lập mối quan hệ đội phát triển khách hàng Giai đoạn gọi „requirements capture‟, „requirements discovery‟, „requirements acquisition‟ (Guide to the Software Engineering Body of Knowledge, 2-4) Các hoạt động cụ thể: • Phỏng vấn khách hàng • uan sát người dùng thực cơng việc họ • Nghiên cứu kịch làm việc • Tổ chức hội thảo • Kiểm tra báo cáo vấn đề • Tái sử dụng yêu cầu Mục tiêu: • Xác định yêu cầu trình phát triển • Xác định tầm nhìn phạm vi • Xác định lớp người dùng • Xác định tiêu chí sản phẩm • Xác định trường hợp ca sử dụng • Xác định kiện hệ thống đáp ứng Phân tích yêu cầu q trình phân tích liệu thu Phát yêu cầu, giải xung đột, phân tích luật thương mại, tài liệu hóa giả định, ràng buộc phụ thuộc, đồng thời làm việc với bên liên quan để tạo lập ưu tiên ban đầu Các hoạt động cụ thể: 22 • Vẽ sơ đồ ngữ cảnh • Tạo mẫu • Phân tích tính khả thi • Gán độ ưu tiên u cầu • Mơ hình hóa u cầu • Tạo từ điển liệu • Phân bổ yêu cầu tới hệ thống • Áp dụng việc triển khai hàm đánh giá chất lượng Mục tiêu: • Phát giải xung đột u cầu • Tìm phạm vi phần mềm cách mà tác động tới mơi trường xung quanh • Nghiên cứu yêu cầu hệ thống để tìm yêu cầu phần mềm + Requirement Specificati Đặc tả yêu cầu trình xác định văn chức bổ trợ dựa yêu cầu hỗ trợ công nghệ trực quan đa dạng mơ hình hóa tiến trình, biểu đồ UML, bảng khung… Các hoạt động cụ thể: • Áp dụng mẫu đặc tả yêu cầu phần mềm • Xác định nguồn yêu cầu • Gán nhãn riêng cho yêu cầu • Ghi lại quy tắc kinh doanh • Xác định 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ả yêu cầu hệ thống • Đặc tả yêu cầu phần mềm Kiểm thử yêu cầu trình xem xét lại đặc tả yêu cầu minh họa trực quan k m với bên liên quan để xác định thuộc tính chất lượng hồn thiện, phù hợp, rõ ràng, tính thực tiễn… Các hoạt động cụ thể: • Kiểm tra tài liệu yêu cầu • Kiểm tra yêu cầu • Xác định tiêu chí chấp nhận • Tạo mẫu thử 23 • Kiểm tra chấp nhận Mục tiêu: • Đảm bảo kĩ sư phần mềm hiểu rõ tất yêu cầu • Đảm bảo yêu cầu đưa khách hàng chấp nhận 2.2) Requirement Management (Quản lí yêu cầu) ent Management uản lý yêu cầu phần mềm thực giao tiếp thoả thuận với người sử dụng yêu cầu phần mềm cần thực (CMU/SEI ) • Xác đ nh giới hạn phần mềm (Requirement baseline) • Duyệt lại giới hạn phần mềm • Quản lý thay đổi yêu cầu phần mềm (Requirement Changes) Xác đ nh q trình kiểm sốt thay đổi yêu cầu: Thiết lập trình mà qua yêu cầu thay đổi đề xuất, phân tích giải uản lý tất thay đổi đề xuất thơng qua q trình Cơng cụ có khiếm khuyết theo dõi thương mại hỗ trợ q trình thay đổi kiểm sốt Thành lập ban kiểm sốt thay đổi: Một nhóm nhỏ bên liên quan thành lập để tiếp nhận đề xuất thay đổi yêu cầu, xử lí chúng, xem xét đề xuất chấp nhận hay loại bỏ thiết lập ưu tiên Phân tích tác động thay đổi yêu cầu: Đánh giá ảnh hưởng thay đổi tới thiết kế hệ thống, mã nguồn chương trình, nhiệm vụ cần tiến hành để đáp ứng thay đổi Thiết lập đƣờng sở kiểm soát phiên tài liệu yêu cầu: Đường sở bao gồm yêu cầu cam kết thực thông cáo cụ thể Các thay đổi thực dựa cam kết có Duy trì l ch sử yêu cầu thay đổi: Ghi lại ngày mà yêu cầu đặc điểm kỹ thuật thay đổi, thay đổi thực hiện, người thực thay đổi, Một phiên điều khiển công cụ yêu cầu thương mại quản lý cơng cụ tự động hoá tác vụ 24 ài li u th h [1] Slide giảng Phân tích yêu cầu phần mềm – Thầy Huỳnh uyết Thắng [2] IEEE Computer Society Professional Practices Committee – Guide to the Software Engineering Body of Knowledge 2004 Version [3] Karl E Wiegers – Software Requirements, Second Edition [4] Ma‟am Marium Nosheen – Introduction to Software Development [5] Boehm – A Spiral Model of Software Development and Enhancement, 1988 [6] Wikipedia 25
Ngày đăng: 22/12/2022, 20:55
Xem thêm:
