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

Chia sẻ: Nguyen Huy Hoang | Ngày: | Loại File: DOC | Số trang:11

Thêm vào BST

Báo xấu

1.286
lượt xem 290
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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. ...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: ĐÁP ÁN ĐỀ CƯƠNG MÔN CÔNG NGHỆ PHẦN MỀM

ĐÁ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 bài tập lớn em đã làm Trả Lời: 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 So với bài tập lớn em đã làm thì em áp dụng mô hình thác nước trong suốt quá trình làm bài tập lớn. Theo đúng cách hoàn thành xong giai đoạn này thì 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 bài tập lớn em đã làm Trả Lời: Mô hình xoắn ốc có thể xem là sự kết hợp giữa mô hình thác nước và mô hình mẫu và đồng thời thêm một thành phần mới – Phân tích rủi ro. Bao gồm 4 hoạt động chính 1. Planning: Xác định mục tiêu, tương tác và ràng buộc 2. Riskanalysis: Phân tích các lựa chọn và chỉ định / giải quyết rủi ro 3. Engineering: Phát triển sản phẩm 4. Customerevaluation: Đánh giá kết quả xây dựng +) Ưu Điểm: - Loại bỏ được khoảng cách giữa nhà sản xuất và khách hàng - Khắc phục được nhược điểm của 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 mới - Đòi hỏi khách hàng có kĩ năng đánh giá tốt và việc phân tích rủi ro cũng phải tốt Câu 3: So sánh mô hình mẫu và mô hình tiến hoá Trả Lời : +) Giống nhau: - Rút ngắn khoảng cách giữa khách hàng và người phát triển hệ thống - Hệ thống dễ kết cấu kém - Khách hàng không hiểu rõ về hệ thống +) Khác nhau: Mô Hình Mẫu Mô Hình Tiến Hoá - Khách hàng có thể biết được hệ - Không lãng phí các bản mẫu thống ngay từ ban đầu - Nhà sản xuất không hiểu biết về - Mô hình này dễ thất bại công nghệ - Người sản xuất hiểu được hệ - Khách hàng không thể biết được thống hệ thống từ ban đầu - Người sản xuất không chắc về hiệu quả giao diện Câu 4 : So Sánh mô hình lặp và mô hình tăng dần Trả Lời : +) Giống nhau: Giống mô hình tiến hoá nhưng mà mẫu thì được đưa vào sử dụng
- Phiên bản mẫu đầu tiên thì phải có được 1 số chức năng chính cốt lõi, phần mềm +) Khác Nhau : Mô Hình Lặp Mô Hình Tăng Dần -Có đầy đủ các chức năng ở phiên - Phiên bản đầu không đầy đủ các bản đầu -> tiếp tục lặp và phát chức năng mà là do phiên bản thứ 2 triển các phiên bản sau bổ xung vào các chức năng đó riêng - Đội ngũ phát triển quen thuộc với khi chu trình thứ 2 thì không bắt lĩnh vực dự án nhưng không có buộc phải làm như khúc đầu mà có nhiều kinh nghiệm, nhất là về công thể áp dụng ở mô hình khác nghệ được dùng phát triển dự án. - Đội ngũ phát triển quen thuộc với - Khách hàng không hiểu rõ về hệ lĩnh vực của dự án và có nhiều kinh thống nghiệm. - Có nhiều rủi ro về mặt kĩ thuật - Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khai sớm một số phần của hệ thống. Câu 5: Mô tả sơ lược cá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 tiếp theo - Chú ý tới thái độ, trung thực của người phỏng vấn +) Đoạn giữa: - Vấn đề chính - Với những vấn đề quan trọng, không được trả lời rõ ràng thì chúng ta nên gợi ý +) Kết thúc: Tổng quát-> khách hàng Ưu điểm: Cơ bản lấy được đầy đủ thông tin Nhược điểm: Không thu thập được 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 những thông tin: Tổng quát, chi tiết nhất Ưu điểm: - Lấy được thông tin , tổng quát, chi tiết - Lấy được 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, những hoạt động xử lí +) Tự động : Hoạt động xử lí trong 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 là xây dựng các câu hỏi để phỏng vấn trên giấy hoặc máy tính. Các câu hỏi được dùng để nhận các thông tin từ số lượng lớn người sử dụng và thường ở dạng khả năng lựa chọn, người trả lời chỉ việc đánh dấu. Các mục câu hỏi, như là phỏng vấn, có thể là câu hỏi mở hoặc câu hỏi đóng nhưng không chỉ rõ tên, dẫn đến các câu trả lời trung thực hơn nhiều phỏng vấn. Ưu điểm :  Các trả lời không cần biết tên nên quan điểm và cảm nhận thu được là trung thực  Có thể tiến hành với nhiều người Hạn chế :  Không thể thêm các thông tin khi đã tiến hành công việc  Thông tin thu được hạn chế trong một phạm vi hẹp  Khó tiến hành  Chỉ dùng nó như một 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 những thông tin chi tiết, qui trình  Thông tin qui trình CSDL -> đưa ra những câu hỏi Hệ thống cũ lấy những thông tin về quá trình, chức năng, lấy những 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ủa bản đặc tả yêu cầu Trả lời: Bản đặc tả yêu cầu gồm các phần 1. Giới thiệu mô tả mục đích khái quát, chức năng, thuật ngữ, từ viết tắt, từ chuyên ngành, Mô tả về mô hình chung cho hệ thống • Mô tả chức năng hay phi chức năng • Những yêu cầu chức năng • Những yêu cầu phi chức năng • Hướng phát triển của hệ thống : làm được gì, giới hạn, định hướng • Đặc tả chi tiết các yêu cầu • Có thể có các thành phần • Nêu ra các phần cứng • Mục lục • Yêu cầu về cơ sở dữ liệu Tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE 1. Giới thiệu 1.1. Mục đích của tài liệu yêu cầu 1.2. Phạm vi của 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 về tài liệu yêu cầu 2. Mô tả chung 2.1. Giới thiệu chung về sản phẩm 2.2. Các chức năng của sản phẩm 2.3. Đặc điểm của người sử dụng 2.4. Các ràng buộc 2.5. Giả thiết và các phụ thuộc 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền ứng dụng và giao diện. 4. Phụ lục 5. Chỉ mục
4. Đánh giá các yêu cầu Đánh giá yêu cầu phần mềm liên quan tới việc cho biết các yêu cầu đã được định nghĩa có đáp ứng được các đòi hỏi của khách hàng không. Nếu việc đánh giá này không chính xác thì việc thiết kế hệ thống và triển khai hệ thống cũng bị ảnh hưởng. Chi phí sửa chữa lỗi sẽ rất lớn. Một số vấn đề của yêu cầu cần được đánh giá là:  Giá trị: người dùng có thể nghĩ rằng hệ thống cần một số chức năng, tuy nhiên sau một số phân tích, có thể xác định các chức năng khác cần được đưa vào. Vì vậy cần xác định đầy đủ các yêu cầu.  Chắc chắn: mọi yêu cầu không được mâu thuẫn với các yêu cầu khác  Hoàn chỉnh: định nghĩa cần phải bao gồm mọi chức năng và các ràng buộc,  Hiện thực: không có các yêu cầu đặc biệt đến mức phi hiện thực. Các xem xét yêu cầu có thể là hình thức hoặc phi hình thức. Xem xét phi hình thức liên quan tới việc các người ký hợp đồng thảo luận các yêu cầu với khách hàng. Nhiều vấn đề có thể được giải quyết dễ dàng khi thảo luận trực tiếp với khách hàng. Đối với các 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 các yêu cầu hệ thống, giải thích các triển khai của mỗi yêu cầu. Câu 7: Nêu cấu trúc phân cấp của 1 phần mềm và 1 số yêu cầu thiết kế khi thiết kế kiến trúc phần mềm Trả Lời: Một số chỉ số của bản cấu trúc phân cấp thủ tục:  Chiều rộng: độ trải rộng của toàn bộ cấu trúc phân cấp  Chiều sâu: độ cao của cấu trúc phân cấp  Số module ra của một module: số các module trực tiếp bị điều khiển của module đó  Số module vào của một module: số các module trực tiếp điều khiển module đó  Thượng cấp: là module điều khiển module khác  Thuộc cấp: là module bị module khác điều khiển
Cấu trúc một chương trình và các chỉ số được minh họa như hình dưới đây: Một số yêu cầu thiết kế khi thiết kế kiến trúc phần mềm là: Yêu cầu: • Vạch ra các thành phần của phần mềm • Mô hình của phần mềm • Giải thích, đặc tả về mô hình • Dễ hiểu và dễ đọc • Linh hoạt với những yêu cầu thay đổi • Giảm kích thước của mô hình • Giảm chiều rộng • Giảm chiều sâu • Chỉ rõ các module chưa làm được • Giả sử giao diện của modunle
Câu 8: Nêu các yêu cầu thiết kế giao diện phần mềm, phân biệt sự khác nhau giữa yêu cầu người dùng và yêu cầu hệ thống Trả Lời : Các yêu cầu khi thiết kế giao diện phần mềm : • Đảm bảo sự quen thuộc của người dùng • Giao diện phải có tính thống nhất • Đảm bảo khả năng 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 • Chú trọng cấu trúc bên trong bên trong của hệ thống • Đánh giá và cảm nhận qua • Đánh giá hệ thống qua các giao diện tương tác chức năng và cấu trúc của nó Câu 10: Nêu sơ lược các bước trong một 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 các bước • Lập kế hoạch kiểm tra • Thiết kế test case • Phát triển test script • Thực hiện test • Đánh giá kết quả test +) Lập kế hoạch : Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện. Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch KTPM bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phân định lực lượng kiểm tra viên +) Thiết kế test: Nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phiên PM. Giai đoạn thiết kế test là hết sức quan trọng, hết sức
quan trọng , nó đảm bảo tất cả các tình huống kiểm tra hết tất cả các yêu cầu Các bước thiết kế test • Xác định và mô tả test cây • Mô tả các bước chi tiết để kiếm tra • Xem xét và khảo sát độ bao phủ của việc kiểm tra • Xem xét test case và các bước kiểm tra +) Phát triển test Script: Bước này thường không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các test script có khả năng chạy trên máy tính giúp tự động hoá việc thực thi các bước kiểm tra đã định nghĩa ở các bước thiết kế test +) Thực hiện test Mục đích thực hiện các bước kiểm tra đã thiết kế và ghi nhận kết quả +) Đánh giá test Mục đích: Đánh giá toàn bộ quá trình kiểm tra bao gồm xem xét và đánh giá kết quả kiểm tra lỗi, chỉ định các yêu cầu thay đổi và tính toán số liệu liên quan, đến quá trình kiểm tra Câu 11: Nêu sơ lược các mức độ kiểm thử phần mềm Trả Lời : 1. Kiểm thử đơn vị :là tiến trình kiểm thử tập trung vào các đơn vị nhỏ nhất của thiết kế phần mềm đó là ham, cac lớp, cac thủ tuc hoăc cac ̀ ́ ́ ̣ ̣ ́ phương thức. Kiểm thử đơn vị bao giờ cũng hướng theo hộp trắng và bước này có thể được tiến hành song song cho nhiều môđun. Unit được chon để kiêm tra thường có kich thước nhỏ và chức năng ̣ ̉ ́ hoat đông đơn gian nên không khó khăn gì trong viêc tổ chức, kiêm tra, ghi ̣ ̣ ̉ ̣ ̉ nhân và phân tich kêt qua. Nêu phat hiên lôi, viêc xac đinh nguyên nhân và ̣ ́ ́ ̉ ́ ́ ̣ ̃ ̣ ́ ̣ khăc phuc cung tương đôi dễ dang vì chỉ khoanh vung môt đơn thể đơn vị ́ ̣ ̃ ́ ̀ ̀ ̣ đang kiêm tra. Thời gian tôn cho Unit Test sẽ được đên bù băng viêc tiêt ̉ ́ ̀ ̀ ̣ ́ kiêm rât nhiêu thời gian và chi phí cho viêc kiêm tra và sửa lôi ở cac mức ̣ ́ ̀ ̣ ̉ ̃ ́ độ kiêm tra sau đo. ̉ ́ Unit Test thường do lâp trinh viên thực hiên. Công đoan nay được ̣ ̀ ̣ ̣ ̀ thực hiên cung với giai đoan viêt code và xuyên suôt chu kỳ phat triên phân ̣ ̀ ̣ ́ ́ ́ ̉ ̀ ̀ mêm.
Cung như cac mức kiêm tra khac, Unit Test cung đoi hoi phai chuân bị ̃ ́ ̉ ́ ̃ ̀ ̉ ̉ ̉ trước cac tinh huông (test case) hoăc kich ban (script), trong đó chỉ đinh rõ ́ ̀ ́ ̣ ̣ ̉ ̣ dữ liêu vao, cac bước thực hiên và dữ liêu mong chờ sẽ xuât ra. Cac test ̣ ̀ ́ ̣ ̣ ́ ́ case và script nay nên được giữ lai để tai sử dung. ̀ ̣ ́ ̣ 2.2. Kiểm thử tích hợp (Integration Test) Kiểm thử tích hợp kêt hợp cac thanh phân cua môt ứng dung và kiêm ́ ́ ̀ ̀ ̉ ̣ ̣ ̉ tra như môt ứng dung đã hoan thanh. Kiểm thử mức đơn vị là kiêm tra cac ̣ ̣ ̀ ̀ ̉ ́ thanh phân, các đơn vị riêng lẻ thì kiểm thử tích hợp kêt hợp chung lai với ̀ ̀ ́ ́ ̣ nhau và kiêm tra sự giao tiêp giữa chung. ̉ ́ ́ Integration Test có 2 muc tiêu chinh: ̣ ́  Phat hiên lôi giao tiêp xay ra giữa cac Unit. ́ ̣ ̃ ́ ̉ ́  Tich hợp cac Unit đơn lẻ thanh cac hệ thông nho, và cuôi cung là ́ ́ ̀ ́ ́ ̉ ́ ̀ nguyên hệ thông hoan chinh để chuân bị kiêm tra ở mức hệ thông. ́ ̀ ̉ ̉ ̉ ́ Trừ môt số it ngoai lê, Integration Test chỉ nên thực hiên trên Unit đã ̣ ́ ̣ ̣ ̣ được kiêm tra cân thân trước đó băng Unit Test, và tât cả cac lôi mức Unit ̉ ̉ ̣ ̀ ́ ́ ̃ đã được sửa chữa. Với cac Unit đã qua giai đoan Unit test với cac giao tiêp ́ ̣ ́ ́ giả lâp thì vân cân thiêt phai thực hiên Itegration Test nữa. Thực tế viêc tich ̣ ̃ ̀ ́ ̉ ̣ ̣ ́ hợp giữa cac Unit dân đên nhiêu tinh huông khac với giả lâp giao tiêp. ́ ̃ ́ ̀ ̀ ́ ́ ̣ ́ 2.3. Kiểm thử mức hệ thống (System Test) Muc đich cua kiêm tra hệ thông là kiêm tra thiêt kế và toan bộ hệ thông ̣ ́ ̉ ̉ ́ ̉ ́ ̀ ́ sau khi tich hợp có thoa man yêu câu đăt ra hay không. ́ ̉ ̃ ̀ ̣ Có 2 cách : • Kiểm thử Alpha - Được bên phát triển tiến hành - Phần mềm sẽ được dùng trong bối cảnh tự nhiên để người phát triển đứng vao vai trò người sử dụng và báo cáo các sai và các vấn ̀ đề sử dụng - Được tiến hành trong một môi trường được điều khiển (theo kế hoạch của người phát triển) • Kiểm thử Beta - Được một hay nhiều người đặt hàng tiến hành - Không có sự hiện diện người phát triển
- Áp dụng phần mềm trong môi trường thực, không có sự kiểm soát của người phát triển - Khách hàng sẽ báo cáo tất cả các vấn đề mà họ gặp trong quá trình kiểm thử cho người phát triển một cách định kỳ - Dựa theo báo cáo đó người phát triển tiến hành sửa đổi và chuẩn bị phân phối bản phát hành cho toàn bộ các 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 được khach hang thực hiên. Muc đich cua kiểm ́ ̀ ̣ ̣ ́ ̉ thử chấp nhận là để chứng minh phân mêm thoa man tât cả yêu câu cua ̀ ̀ ̉ ̃ ́ ̀ ̉ khach hang và khach hang châp nhân san phâm chưa. ́ ̀ ́ ̀ ́ ̣ ̉ ̉ Kiểm thử chấp nhận có ý nghia quan trong, măc dù hâu hêt moi ̃ ̣ ̣ ̀ ́ ̣ trường hợp, cac phep kiêm tra cua kiểm thử hệ thống và kiểm thử chấp ́ ́ ̉ ̉ nhận gân tương tự như nhau, nhưng ban chât và cach thức thực hiên lai rât ̀ ̉ ́ ́ ̣ ̣ ́ ́ khac biêt.̣ Thực tế cho thây, nêu khach hang không quan tâm và không tham gia ́ ́ ́ ̀ vao quá trinh phat triên phân mêm thì kêt quả của kiểm thử chấp nhận sẽ ̀ ̀ ́ ̉ ̀ ̀ ́ sai lêch rât lớn, măc dù phân mêm đã trai qua tât cả cac kiêm tra trước đo. ̣ ́ ̣ ̀ ̀ ̉ ́ ́ ̉ ́ Sự sai lêch nay liên quan đên viêc hiêu sai yêu câu và sự mong chờ cua ̣ ̀ ́ ̣ ̉ ̀ ̉ ́ khach hang̀ 2.5. Kiểm thử hồi quy (Regression Test) Kiểm thử hồi quy không phai là môt mức kiêm tra như cac mức khac ̉ ̣ ̉ ́ ́ noi trên. Nó đơn thuân kiêm tra lai phân mêm sau khi có môt sự thay đôi ́ ̀ ̉ ̣ ̀ ̀ ̣ ̉ xay ra, để bao đam phiên ban phân mêm mới thực hiên tôt cac chức năng ̉ ̉ ̉ ̉ ̀ ̀ ̣ ́ ́ như phiên ban cũ và sự thay đôi không gây ra lôi mới trên những chức năng ̉ ̉ ̃ đã hoat đông tôt. Kiểm thử hồi quy có thể thực hiên tai moi mức kiêm tra. ̣ ̣ ́ ̣ ̣ ̣ ̉