chu trình sống của phần mềm - tiến trình phát triển phần mềm

92 385 0
chu trình sống của phần mềm - tiến trình phát triển phần mềm

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

PHẦN 2: Chu trình sống phần mềm / Tiến trình phát triển phần mềm TS TRẦN CAO ĐỆ NĂM 2010 Các bước tiến trình PM Bài tốn Tìm hiểu yêu cầu Đặc tả yêu cầu Thiết kế Đặc tả chương trình Cài đặt Chương trình Kiểm thử Chương trình làm việc Bảo trì CƠNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang Chương 9: Đặc tả yêu cầu Requirement Engineering Khái niệm đặc tả yêu cầu • The hardest single part of building a system is deciding what to build • Đặc tả yêu cầu phần mềm – Bước tiến trình phần mềm – Các yêu cầu người dùng hệ thống tương lai phải thu thập tài liệu hóa Chỉ tập trung vào what bỏ qua how • Đặc tả u cầu khác với phân tích yêu cầu đặc tả hệ thống CÔNG NGHỆ PHẦN MỀM • Nội dung đặc tả – Yêu cầu chức – Yêu cầu không chức năng: hiệu hệ thống, độ tin cậy, tài liệu người dùng, tập huấn, giá thành,… • Kết đặc tả: tài liệu đặc tả yêu cầu – Phản ánh hiểu biết chung vấn đề cần giải người phân tích khách hàng – Cơ sở để nghiên cứu khả thi – Cơ sở để kiểm thử-chấp nhận TS TRẦN CAO ĐỆ 2010 Trang Yêu cầu tài liệu đặc tả yêu cầu • Tài liệu đặc tả phải đáp ứng: – rõ ràng dễ hiểu khách hàng (dễ thuyết phục) – đầy đủ chi tiết nguồn thơng tin dành cho nhóm phân tích & thiết kế • Đặc điểm: – Các lỗi xảy giai đoạn ảnh hưởng đến giai đoạn lại tồn tiến trình – Là hợp đồng (contract) khách hàng nhà phát triển – Phải bao gồm ràng buộc mà sản phẩm phải đáp ứng – Đặc tả yêu cầu khó độc lập với phân tích, thiết kế • Loại đặc tả – Client – driven – Market – driven CÔNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang Nội dung đặc tả • Phần mềm: • Con người: lớp người dùng, trình độ – Mơi trường làm việc phần mềm: OS, DBMS – Các phần mềm giao tiếp với phần mềm muốn phát triển: – người dùng – người quản trị… • Tài liệu • Các hệ thống tồn • Dữ liệu: nguồn liệu, format, dùng lại CSDL cũ • Giải thuật • Phần cứng: khả phần cứng – Khả lưu trữ – Khả đáp ứng tác vụ … CÔNG NGHỆ PHẦN MỀM – Các yêu cầu tài liệu – Các biểu mẫu • Thủ tục – Qui trình nghiệp vụ • Chức – Các chức theo nhóm người dùng • Chất lượng – u cầu chất lượng – Giá thành – Thời gian đáp ứng TS TRẦN CAO ĐỆ 2010 Trang Hình thức đặc tả • Dùng ngơn ngữ tự nhiên – Ngữ nghĩa khơng rõ ràng, thường có nhiều lỗi xảy – Ngôn ngữ tự nhiên phương cách tốt để đặc tả sản phẩm • Dùng ngơn ngữ qui ước – Bán hình thức/ đồ họa • Phân tích theo cấu trúc • Mơ hình thực thể quan hệ • OOP – Ngơn ngữ hình thức • Z, VDM, Petri net CÔNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang Case study - Thảo luận • Viết đặc tả yêu cầu cho “hệ thống QL thư viện” – Nhóm user • • • • Người thủ thư Đọc giả Người quản lí Người quản trị hệ thống – Nhóm u cầu theo • Chức • Chất lượng • Cơng nghệ: DB, nhớ, phần cứng CÔNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang Ba bước đặc tả yêu cầu • Nắm bắt yêu cầu (requirement elicitation): hiểu yêu cầu user User requirements – Nhà phân tích # chun gia lĩnh vực elicitation • Đặc tả yêu cầu: mô tả yêu cầu tài liệu hóa • Kiểm tra xác nhận : knowledge specification Request more knowledge Problem domain TS TRẦN CAO ĐỆ validation validation results Domain knowledge – Kiểm tra (verification): yêu cầu phát biểu – Kiểm tra – xác nhận (validation): yêu cầu phát biểu tài liệu hóa CƠNG NGHỆ PHẦN MỀM User feedback Models to be validated by user Requirements model 2010 Domain knowledge Trang Phát biểu yêu cầu • • • • Các yêu cầu phải phát biểu tường minh tài liệu hóa Mơ hình hóa: phần giới thực quan tâm: universe of discourse (UoD) Mỗi người lên quan UoD có mơ hình riêng, khơng tường minh giới Phát biểu yêu cầu (requirements elicitation) phát biểu tường minh mơ hình khơng tường minh CƠNG NGHỆ PHẦN MỀM • Vai trị người phân tích: – Phân tích tốn – Thương thảo u cầu • Các yêu cầu hệ thống phải phát biểu xác đầy đủ – Nhiều người liên quan – Trình độ khác – Tầm nhìn khác • Các điểm cần lưu ý – Con người thường có thành kiến với vấn – Con người thường suy nghĩ logic quán – Người ta thường khơng thể xác hóa muốn TS TRẦN CAO ĐỆ 2010 Trang 10 Qui trình kiểm thử • • Vấn đề: chọn tập hợp input để test (test cases) Test cases nhằm mục đích phát lỗi Kỹ thuật test: xác định test cases cách có hệ thống – Chia miền liệu input làm lớp • Mục đích test: làm xuất lỗi (fault) CÔNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang 78 Hoạt động kiểm thử tiến trình phần mềm • Hoạt động test diễn suốt trình phát triển phần mềm – Giai đoạn đặc tả • Xác định chiến lược • Đặc tả kiểm thử • Sinh liệu test chức – Cài đặt • Kiểm tra phù hợp cài đặt với thiết kế • Cài đặt test • Sinh liệu test chức kiến trúc • Thực test – Bảo trì • Lặp lại test trình phát triển lại – Thiết kế • Kiểm tra phù hợp thiết kế & đặc tả • Đánh giá kiến trúc • Kiểm thử kiến trúc • Sinh liệu test chức cấu trúc CÔNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang 79 Các giai đoạn test • Mơ hình chử V • Unit test • System test – Test module • Test từ lên • Test từ xuống – Test module nhằm xác định tính đắn module, tức chất lượng code CÔNG NGHỆ PHẦN MỀM – Test tích hợp module (integration testing) hay test chấp nhận (acceptance test) – Thường test tính dùng hệ thống test đắn code với đặc tả – Test tích hợp bao gồm test cài đặt – Test tích hợp cịn nhằm kiểm tra độ tin cậy hệ thống TS TRẦN CAO ĐỆ 2010 Trang 80 Testing Tools CÔNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang 81 Kế hoạch kiểm thử & tài liệu • • Như cơng đoạn khác tiến trình phần mềm, kiểm thử phải có kế hoạch tài liệu Tài liệu bao gồm [IEEE,83] – Test plan: Chuẩn IEEE 1012 – Test design – Test cases: Mỗi test case mơ tả • Input • Output mong đợi • Các điều kiện thực – Test procedure: Đặc tả chuỗi hoạt động để thực test – Test report: Cung cấp thông tin việc thực test Test plan theo IEEE 1012 CÔNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang 82 Các kỹ thuật test thủ cơng • – Các thành viên inspection đọc code thành cụm (chunk) phân tích tìm lỗi: Đọc (reading) – Đọc, đọc đọc lại • Đặc tả yêu cầu, • Design – Peer review • Đọc đánh giá code lẫn • Nặc danh • inspections – Kiểm tra thực đội (thường người) – Mỗi người nhận tài liệu code – Sau vài ngày nghiên cứu, ngồi lại để inspection – Tác giả code có mặt khơng phát biểu, trả lời câu hỏi (nếu có) CƠNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ Lỗi dùng liệu: biến không khởi tạo, vượt số mảng, trỏ nguy hiểm Lỗi khai báo: không khai báo, khai báo tên khối lồng Lỗi tính tốn: chia 0, tràn số Lỗi phép toán quan hệ: dùng > thay >=; thứ tự ưu tiên Lỗi dịng điều khiển: lặp (n+1) lần thay n lần! Lỗi giao tiếp: tham số truyền sai kiểu, sai số tham số… 2010 Trang 83 Các kỹ thuật test thủ cơng(tt) – Q trình inspection để phát lỗi, khơng sửa • • Đánh giá kịch Walkthroughs – Trong q trình test dùng liệu đơn giản để lỗi – Giả lập tay – Walkthroughs inspection thực giai đoạn tiến trình phần mềm miễn tài liệu rõ ràng test – Khuyết điểm PP: • Người tham gia có kiến thức nơng cạn • Không đủ kiến thức lĩnh vực xét CÔNG NGHỆ PHẦN MỀM – Dựa use case senario (mơ tả use case) • Chứng minh tính đắn: {P} S {Q} • Trừu tượng hóa buớc – Ngược lại với stepwise refinement (top-down) – TTH buớc áp dụng với bottom-up: từ cụ thể tổng hóa lên trừu tượng TS TRẦN CAO ĐỆ 2010 Trang 84 Kỹ thuật kiểm thử bao trùm (coverage-based testing) • Kiểm thử bao trùm – Số thị – Số đường / nhánh chương trình • Chương trình mơ hình hóa đồ thị – Control graph: mơ hình hóa dịng điều khiển – Data flow: mơ hình hóa dịng xử lí từ khai báo biến tới kết – Mơ hình hóa đặc tả u cầu đồ thị: mơ hình dịng liệu (DFD) • Dùng độ đo McCabe để tính số test case – V(G) = số nhánh độc lập = số nút đk + CÔNG NGHỆ PHẦN MỀM TS TRẦN CAO ĐỆ 2010 Trang 85 Ví dụ control graph 10 11 Procedure sort(var x:array; n:integer); Var i,j,save:integer; Begin for i:=2 to n for j:=1 to i if x[i]

Ngày đăng: 23/05/2014, 15:22

Từ khóa liên quan

Tài liệu cùng người dùng

Tài liệu liên quan