ĐÁP ÁN ĐỀ CƯƠNG MÔN CÔNG NGHỆ PHẦN MỀM

Mô hình thác nước xem quá trình xây dựng một sản phẩm phần mềm bao gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thì chuyển đến giai đoạn sau: Ưu Điểm: Dễ quản lí; Ước lượng thời gian và chi phí rất chính xác; Nhược Điểm: Rủi ro cao; Đòi hỏi khách hàng đưa ra yêu cầu chính xác ngay từ đầu; Ứng Dụng: Khách hàng đưa ra yêu cầu ngay từ đầu; Nhà phát triển hiểu hệ thống. ...

ĐÁP ÁN ĐỀ CƯƠNG MÔN CÔNG NGHỆ PHẦN MỀM Người Soạn: Nguyễn Huy Hoàng CĐ5.2 – K3 – CNTT DĐ: 01234.321.989 & 01689.989.359 Câu 1: Phân tích mơ hình thác nước Liên hệ với tập lớn em làm Trả Lời: Mơ hình thác nước xem q trình xây dựng sản phẩm phần mềm bao gồm nhiều giai đoạn tách biệt, sau hoàn tất giai đoạn chuyển đến giai đoạn sau +) Ưu Điểm: - Dễ quản lí - Ước lượng thời gian chi phí xác +) Nhược Điểm: - Rủi ro cao - Đòi hỏi khách hàng đưa yêu cầu xác từ đầu +) Ứng Dụng: - Khách hàng đưa yêu cầu từ đầu - Nhà phát triển hiểu hệ thống So với tập lớn em làm em áp dụng mơ hình thác nước suốt trình làm tập lớn Theo cách hồn thành xong giai đoạn chuyển sang giai đoạn khác Câu 2: Phân tích mơ hình xoắn ốc, liên hệ với tập lớn em làm Trả Lời: Mơ hình xoắn ốc xem kết hợp mơ hình thác nước mơ hình mẫu đồng thời thêm thành phần – Phân tích rủi ro Bao gồm hoạt động Planning: Xác định mục tiêu, tương tác ràng buộc Riskanalysis: Phân tích lựa chọn định / giải rủi ro Engineering: Phát triển sản phẩm Customerevaluation: Đánh giá kết xây dựng +) Ưu Điểm: - Loại bỏ khoảng cách nhà sản xuất khách hàng - Khắc phục nhược điểm mơ hình khác - Sử dụng mơ hình mẫu + phân tích rủi ro - Sử dụng mơ hình thác nước + mơ hình lặp +) Khuyết điểm: - Mơ hình - Địi hỏi khách hàng có kĩ đánh giá tốt việc phân tích rủi ro phải tốt Câu 3: So sánh mơ hình mẫu mơ hình tiến hố Trả Lời : +) Giống nhau: - Rút ngắn khoảng cách khách hàng người phát triển hệ thống - Hệ thống dễ kết cấu - Khách hàng không hiểu rõ hệ thống +) Khác nhau: Mơ Hình Mẫu Mơ Hình Tiến Hố - Khách hàng biết hệ - Khơng lãng phí mẫu thống từ ban đầu - Nhà sản xuất không hiểu biết - Mơ hình dễ thất bại công nghệ - Người sản xuất hiểu hệ thống - Khách hàng biết hệ - Người sản xuất không hiệu thống từ ban đầu giao diện Câu : So Sánh mơ hình lặp mơ hình tăng dần Trả Lời : +) Giống nhau: Giống mơ hình tiến hố mà mẫu đưa vào sử dụng - Phiên mẫu phải có số chức cốt lõi, phần mềm +) Khác Nhau : Mơ Hình Lặp -Có đầy đủ chức phiên đầu -> tiếp tục lặp phát triển phiên sau - Đội ngũ phát triển quen thuộc với lĩnh vực dự án khơng có nhiều kinh nghiệm, công nghệ dùng phát triển dự án - Khách hàng không hiểu rõ hệ thống - Có nhiều rủi ro mặt kĩ thuật Mơ Hình Tăng Dần - Phiên đầu khơng đầy đủ chức mà phiên thứ bổ xung vào chức riêng chu trình thứ khơng bắt buộc phải làm khúc đầu mà áp dụng mơ hình khác - Đội ngũ phát triển quen thuộc với lĩnh vực dự án có nhiều kinh nghiệm - Hệ thống lớn phát triển thời gian dài, khách hàng cần triển khai sớm số phần hệ thống Câu 5: Mô tả sơ lược kĩ thuật thu thập yêu cầu Trả Lời: PP1: Phỏng vấn +) Lúc ban đầu - Chào hỏi, giới thiệu - Đặt câu hỏi dễ, mang tính bao quát - Chú ý tới câu trả lời để dẫn dắt phần - Chú ý tới thái độ, trung thực người vấn +) Đoạn giữa: - Vấn đề - Với vấn đề quan trọng, khơng trả lời rõ ràng nên gợi ý +) Kết thúc: Tổng quát-> khách hàng Ưu điểm: Cơ lấy đầy đủ thông tin Nhược điểm: Không thu thập nhiều ý kiến PP2: Phương pháp họp nhóm : Ba người trở lên o Chuẩn bị nội dung : Lịch trình từ trước o Cung cấp nội dung, lịch trình trước cho người tham gia o Tập trung để lấy thông tin: Tổng quát, chi tiết Ưu điểm: - Lấy thông tin , tổng quát, chi tiết - Lấy thông tin từ nhiều người Nhược điểm: Gây nhiều tranh cãi PP3: Phương pháp quan sát thủ công +) Thủ công : Quan sát , ghi chép lại, hoạt động xử lí +) Tự động : Hoạt động xử lí máy tính Tiến trình - Hỏi ý kiến người bị quan sát - Chọn vị trí thích hợp - Chọn lọc thơng tin theo chủ đề định trước +) Điều tra qua bảng câu hỏi Điều tra qua câu hỏi xây dựng câu hỏi để vấn giấy máy tính Các câu hỏi dùng để nhận thông tin từ số lượng lớn người sử dụng thường dạng khả lựa chọn, người trả lời việc đánh dấu Các mục câu hỏi, vấn, câu hỏi mở câu hỏi đóng khơng rõ tên, dẫn đến câu trả lời trung thực nhiều vấn Ưu điểm :  Các trả lời không cần biết tên nên quan điểm cảm nhận thu trung thực  Có thể tiến hành với nhiều người Hạn chế :  Không thể thêm thông tin tiến hành công việc  Thông tin thu hạn chế phạm vi hẹp  Khó tiến hành  Chỉ dùng phương pháp bổ sung, PP4: Xem xét tài liệu Qui định, qui chế , phiếu, bảng biểu Lấy thông tin chi tiết, qui trình  Thơng tin qui trình CSDL -> đưa câu hỏi Hệ thống cũ lấy thơng tin q trình, chức năng, lấy thơng tin cần bổ xung, nâng cấp phần mềm trước Câu 6: Nêu cấu trúc đặc tả yêu cầu Trả lời: Bản đặc tả yêu cầu gồm phần Giới thiệu mơ tả mục đích khái qt, chức năng, thuật ngữ, từ viết tắt, từ chuyên ngành, Mơ tả mơ hình chung cho hệ thống • • • • • • • • • Mô tả chức hay phi chức Những yêu cầu chức Những yêu cầu phi chức Hướng phát triển hệ thống : làm gì, giới hạn, định hướng Đặc tả chi tiết yêu cầu Có thể có thành phần Nêu phần cứng Mục lục Yêu cầu sở liệu Tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE Giới thiệu 1.1 Mục đích tài liệu yêu cầu 1.2 Phạm vi sản phẩm 1.3 Các định nghĩa, từ viết tắt 1.4 Các tham chiếu 1.5 Tổng quan tài liệu yêu cầu Mô tả chung 2.1 Giới thiệu chung sản phẩm 2.2 Các chức sản phẩm 2.3 Đặc điểm người sử dụng 2.4 Các ràng buộc 2.5 Giả thiết phụ thuộc Đặc tả yêu cầu: bao gồm yêu cầu chức năng, phi chức năng, miền ứng dụng giao diện Phụ lục Chỉ mục Đánh giá yêu cầu Đánh giá yêu cầu phần mềm liên quan tới việc cho biết yêu cầu định nghĩa có đáp ứng địi hỏi khách hàng khơng Nếu việc đánh giá khơng xác việc thiết kế hệ thống triển khai hệ thống bị ảnh hưởng Chi phí sửa chữa lỗi lớn Một số vấn đề yêu cầu cần đánh giá là:  Giá trị: người dùng nghĩ hệ thống cần số chức năng, nhiên sau số phân tích, xác định chức khác cần đưa vào Vì cần xác định đầy đủ yêu cầu  Chắc chắn: yêu cầu không mâu thuẫn với yêu cầu khác  Hoàn chỉnh: định nghĩa cần phải bao gồm chức ràng buộc,  Hiện thực: khơng có u cầu đặc biệt đến mức phi thực Các xem xét u cầu hình thức phi hình thức Xem xét phi hình thức liên quan tới việc người ký hợp đồng thảo luận yêu cầu với khách hàng Nhiều vấn đề giải dễ dàng thảo luận trực tiếp với khách hàng Đối với yêu cầu xem xét hình thức, đội phát triển phải dẫn dắt khách hàng thông qua yêu cầu hệ thống, giải thích triển khai yêu cầu Câu 7: Nêu cấu trúc phân cấp phần mềm số yêu cầu thiết kế thiết kế kiến trúc phần mềm Trả Lời: Một số số cấu trúc phân cấp thủ tục:  Chiều rộng: độ trải rộng toàn cấu trúc phân cấp  Chiều sâu: độ cao cấu trúc phân cấp  Số module module: số module trực tiếp bị điều khiển module  Số module vào module: số module trực tiếp điều khiển module  Thượng cấp: module điều khiển module khác  Thuộc cấp: module bị module khác điều khiển Cấu trúc chương trình số minh họa hình đây: Một số yêu cầu thiết kế thiết kế kiến trúc phần mềm là: Yêu cầu: • Vạch thành phần phần mềm • Mơ hình phần mềm • Giải thích, đặc tả mơ hình • Dễ hiểu dễ đọc • Linh hoạt với yêu cầu thay đổi • Giảm kích thước mơ hình • Giảm chiều rộng • Giảm chiều sâu • Chỉ rõ module chưa làm • Giả sử giao diện modunle Câu 8: Nêu yêu cầu thiết kế giao diện phần mềm, phân biệt khác yêu cầu người dùng yêu cầu hệ thống Trả Lời : Các yêu cầu thiết kế giao diện phần mềm : • Đảm bảo quen thuộc người dùng • Giao diện phải có tính thống • Đảm bảo khả phục hồi • Giao diện phải có tính đa dạng Yêu Cầu Người Dùng Yêu Cầu Hệ Thống • Không quan tâm đến cấu truc bên • Chú trọng cấu trúc bên hệ thống • Đánh giá cảm nhận qua giao diện tương tác • Đánh giá hệ thống qua chức cấu trúc Câu 10: Nêu sơ lược bước qui trình kiểm thử phần mềm Trả Lời : Quy trình kiểm thử phần mềm bao gồm bước • Lập kế hoạch kiểm tra • Thiết kế test case • Phát triển test script • Thực test • Đánh giá kết test +) Lập kế hoạch : Nhằm định mô tả loại kiểm tra triển khai thực Kết bước lập kế hoạch tài liệu kế hoạch KTPM bao gồm nhiều chi tiết từ loại kiểm tra, chiến lược kiểm tra, thời gian phân định lực lượng kiểm tra viên +) Thiết kế test: Nhằm định test case bước kiểm tra chi tiết cho phiên PM Giai đoạn thiết kế test quan trọng, quan trọng , đảm bảo tất tình kiểm tra hết tất yêu cầu Các bước thiết kế test • Xác định mơ tả test • Mơ tả bước chi tiết để kiếm tra • Xem xét khảo sát độ bao phủ việc kiểm tra • Xem xét test case bước kiểm tra +) Phát triển test Script: Bước thường không bắt buộc loại mức kiểm tra, yêu cầu trường hợp đặc thù cần thiết kế, tạo test script có khả chạy máy tính giúp tự động hoá việc thực thi bước kiểm tra định nghĩa bước thiết kế test +) Thực test Mục đích thực bước kiểm tra thiết kế ghi nhận kết +) Đánh giá test Mục đích: Đánh giá tồn trình kiểm tra bao gồm xem xét đánh giá kết kiểm tra lỗi, định yêu cầu thay đổi tính tốn số liệu liên quan, đến trình kiểm tra Câu 11: Nêu sơ lược mức độ kiểm thử phần mềm Trả Lời : Kiểm thử đơn vị :là tiến trình kiểm thử tập trung vào đơn vị nhỏ thiết kế phần mềm hàm, lớp, thủ tục phương thức Kiểm thử đơn vị hướng theo hộp trắng bước tiến hành song song cho nhiều môđun Unit chọn để kiểm tra thường có kích thước nhỏ chức hoạt động đơn giản nên khơng khó khăn việc tổ chức, kiểm tra, ghi nhận phân tích kết Nếu phát lỗi, việc xác định nguyên nhân khắc phục tương đối dễ dàng khoanh vùng đơn thể đơn vị kiểm tra Thời gian tốn cho Unit Test đền bù việc tiết kiệm nhiều thời gian chi phí cho việc kiểm tra sửa lỗi mức độ kiểm tra sau Unit Test thường lập trình viên thực Cơng đoạn thực với giai đoạn viết code xuyên suốt chu kỳ phát triển phần mềm Cũng mức kiểm tra khác, Unit Test địi hỏi phải chuẩn bị trước tình (test case) kịch (script), định rõ liệu vào, bước thực liệu mong chờ xuất Các test case script nên giữ lại để tái sử dụng 2.2 Kiểm thử tích hợp (Integration Test) Kiểm thử tích hợp kết hợp thành phần ứng dụng kiểm tra ứng dụng hoàn thành Kiểm thử mức đơn vị kiểm tra thành phần, đơn vị riêng lẻ kiểm thử tích hợp kết hợp chúng lại với kiểm tra giao tiếp chúng Integration Test có mục tiêu chính:  Phát lỗi giao tiếp xảy Unit  Tích hợp Unit đơn lẻ thành hệ thống nhỏ, cuối nguyên hệ thống hoàn chỉnh để chuẩn bị kiểm tra mức hệ thống Trừ số ngoại lệ, Integration Test nên thực Unit kiểm tra cẩn thận trước Unit Test, tất lỗi mức Unit sửa chữa Với Unit qua giai đoạn Unit test với giao tiếp giả lập cần thiết phải thực Itegration Test Thực tế việc tích hợp Unit dẫn đến nhiều tình khác với giả lập giao tiếp 2.3 Kiểm thử mức hệ thống (System Test) Mục đích kiểm tra hệ thống kiểm tra thiết kế tồn hệ thống sau tích hợp có thỏa mãn u cầu đặt hay khơng Có cách : • Kiểm thử Alpha - Được bên phát triển tiến hành - Phần mềm dùng bối cảnh tự nhiên để người phát triển đứng vào vai trò người sử dụng báo cáo sai vấn đề sử dụng - Được tiến hành môi trường điều khiển (theo kế hoạch người phát triển) • Kiểm thử Beta - Được hay nhiều người đặt hàng tiến hành - Khơng có diện người phát triển - Áp dụng phần mềm mơi trường thực, khơng có kiểm soát người phát triển - Khách hàng báo cáo tất vấn đề mà họ gặp trình kiểm thử cho người phát triển cách định kỳ - Dựa theo báo cáo người phát triển tiến hành sửa đổi chuẩn bị phân phối phát hành cho toàn người đặt hàng 2.4 Kiểm thử chấp nhận phần mềm (Acceptance Test) Kiểm thử chấp nhận khách hàng thực Mục đích kiểm thử chấp nhận để chứng minh phần mềm thỏa mãn tất yêu cầu khách hàng khách hàng chấp nhận sản phẩm chưa Kiểm thử chấp nhận có ý nghĩa quan trọng, hầu hết trường hợp, phép kiểm tra kiểm thử hệ thống kiểm thử chấp nhận gần tương tự nhau, chất cách thức thực lại khác biệt Thực tế cho thấy, khách hàng không quan tâm không tham gia vào trình phát triển phần mềm kết kiểm thử chấp nhận sai lệch lớn, phần mềm trải qua tất kiểm tra trước Sự sai lệch liên quan đến việc hiểu sai yêu cầu mong chờ khách hàng 2.5 Kiểm thử hồi quy (Regression Test) Kiểm thử hồi quy mức kiểm tra mức khác nói Nó đơn kiểm tra lại phần mềm sau có thay đổi xảy ra, để bảo đảm phiên phần mềm thực tốt chức phiên cũ thay đổi không gây lỗi chức hoạt động tốt Kiểm thử hồi quy thực mức kiểm tra  ... số minh họa hình đây: Một số yêu cầu thiết kế thiết kế kiến trúc phần mềm là: Yêu cầu: • Vạch thành phần phần mềm • Mơ hình phần mềm • Giải thích, đặc tả mơ hình • Dễ hiểu dễ đọc • Linh hoạt với... dụng giao diện Phụ lục Chỉ mục Đánh giá yêu cầu Đánh giá yêu cầu phần mềm liên quan tới việc cho biết yêu cầu định nghĩa có đáp ứng địi hỏi khách hàng khơng Nếu việc đánh giá khơng xác việc thiết... hệ thống • Đánh giá cảm nhận qua giao diện tương tác • Đánh giá hệ thống qua chức cấu trúc Câu 10: Nêu sơ lược bước qui trình kiểm thử phần mềm Trả Lời : Quy trình kiểm thử phần mềm bao gồm bước