Bài Giảng Công Nghệ Phần Mềm

Bài Giảng Công Nghệ Phần Mềm Software Engineering Giáo viên & Giao tiếp giảng dạy ThS Nguyễn Cao Trí – ngacotri@gmail.com http://www.cse.hcmut.edu.vn/~caotri Room 109 A5 – Trung tâm Kỹ thuật Điện toán Tel: 8647256 – 5370 Mobile: 091 391 6290 Hobbies: Automation , Flying Model http://www.rc-easy.net • Tài liệu download website file: TailieudientuCNPMPrintableVersion.ppt • Học nào?  Hỏi lớp • Bảng mã sử dụng Unicode dựng sẵn • Các tập nộp email, dạng file *.ZIP • Email phải ghi rõ nội dung file đính kèm tiếng Việt Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn Giới thiệu môn học • Nội dung môn học – Giới thiệu khái niệm công nghệ phần mềm – Mục tiêu sản xuất phần mềm công nghệ phần mềm – Các mô hình sản xuất phần mềm – Quy trình sản xuất quản lý dự án phần mềm • Tài liệu tham khảo – Introduction to Software Engineering – Ronald J Leach – CRC Press (Thư viện A2 MS: 9075802004) – Software Engineering – Ian Sommerville – Fifth edition (Thư viện A3 MS: 200032) • Hình thức kiểm tra – Giữa kỳ + Cuối kỳ + Bài tập – Hình thức kiểm tra: trắc nghiệm khách quan – open book – Đánh giá kêt quả: tương đối - phi tuyến Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn ???????? & !!!!!!!! • • • • Công Công Công Công Nghiệp & Công Nghệ Nghiệp Phần Mềm (CNpPM) Nghệ Phần Mềm (CNPM) nghiệp phần mềm & công nghiệp khác – Giống – Khác • Có hay không (những) công nghệ cho sản xuất phần mềm? • Có cần thiết phải có công nghệ cho sản xuất phần mềm không, sản xuất phần mềm hoạt động sản xuất “đặc biệt” nói làm phần mềm sản xuất lon coca Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn Đặc tính sản phẩm phần mềm • Software = Program • Software product = Program + Document + Support • Loại sản phẩm phần mềm – Generic Product: sản phẩm đóng gói bán rộng rãi thị trường – Bespoke Product: sản phẩm phát triển theo yêu cầu đặc thù khách hàng • Các đặc tính quan trọng sản phẩm phần mềm – Maintainability: phần mềm thay đổi thuận tiện theo yêu cầu người dùng – Dependability: tính ổn định, bảo mật an toàn phần mềm Không gây tổn hại vật chất hay kinh cho hệ thống – Efficiency: Sử dụng hiệu tài nguyên hệ thống cho công việc – Usability: giao diện phương thức phải phù hợp với người dùng đồng thời đáp ứng yêu cầu người dùng Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn Software - Đủ hay Thiếu? • Phần mềm viết từ có máy tính programable Được quan tâm phát triền từ sớm • Có nhiều phần mềm viết  Không thiếu phần mềm • Thực tế việc sản xuất phần mềm không đáp ứng kịp yêu cầu người sử dụng: – Không đủ số lượng – Thiếu chất lượng – Không kịp thời gian  Phần mềm không đáp ứng đủ cho ngƣời dùng Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn Nguyên nhân khách quan • Số lượng phần mềm phải hiểu số đầu/loại phần mềm sử dụng cho mục tiêu ứng dụng • Nhu cầu sử dụng phần mềm lớn – Nhiều ngành nghề cần dùng phần mềm máy tính – Mỗi ngành nghề cần nhiều loại phần mềm khác – Mội loại phần mềm cần nhiều cấp độ khác theo trình độ người dùng • Chất lượng phần mềm chưa đáp ứng tốt hoàn toàn người sử dụng: – Tính customize cao sản phẩm phần mềm – Trình độ sử dụng khác điều kiện hạ tầng ứng dụng khác • Nhu cầu phần mềm thường cấp bách – Tầm nhìn chiến lược chưa đầy đủ người sử dụng – Không có kế hoạch lâu dài – Phải thay đổi theo đối tượng người dùng Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn Nguyên nhân chủ quan • Tính chuyên nghiệp sản xuất phần mềm chưa cao Các liệu quan sát đƣợc – Cứ đề án triển khai có bị huỷ bỏ – Trung bình thời gian thực thực tế bị kéo dài 50 % (cá biệt 200300%) – Các đề án lớn dễ thất bại – 3/4 hệ thống lớn có lỗi thực thi – Quá trình phân tích yêu cầu (5 % công sức): để lại 55 % lỗi, có 18 % phát – Quá trình thiết kế (25 % công sức): để lại 30 % lỗi, có 10 % phát – Quá trình mã hoá, kiểm tra bảo trì: để lại 15 % lỗi, có 72 % phát Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn Nguyên nhân chủ quan (tt) Lý hệ – Phát triển phần mềm giống “nghệ thuật”, chưa xem ngành khoa học – Quy trình phát triển phần mềm chưa thống – Phải viết lại s/w có thay đổi ngôn ngữ, h/w o/s – Chưa đạt chuẩn cho việc đo lường hiệu suất sản phẩm – Độ phức tạp phần mềm cao ―kiến trúc sư‖ – Kỹ thuật đặc tả để lại nhập nhằng yêu cầu phần mềm – Làm việc nhóm không kỷ luật gây lỗi  CẦN PHẢI CÓ MỘT/NHIỀU CHUẨN QUY TRÌNH TRONG SẢN XUẤT PHẦN MỀM ĐỂ NÂNG CAO TÍNH CHUYÊN NGHIỆP CỦA NỀN SẢN XUẤT ĐẶC BIỆT NÀY  CẦN CÔNG NGHỆ CHO CÔNG NGHIỆP PHẦN MỀM Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn Định nghĩa ―Công nghệ phần mềm‖ • Công Nghệ Phần Mềm thiết lập sử dụng nguyên tắc khoa học nhằm mục đích tạo phần mềm cách kinh tế mà phần mềm hoạt động hiệu tin cậy máy tính • Công nghệ phần mềm quy trình có hệ thống sử dụng trình phân tích, thiết kế, thực, kiểm tra bảo trì để bảo đảm sản phẩm phần mềm sản xuất hoạt động: hiệu quả, tin cậy, hữu dụng, nâng cấp dễ dàng (modificable), khả chuyển (portable), khả kiểm tra (testable), cộng tác với hệ thống khác (interoperable) vận hành (correct) Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 10 Tích hợp từ dƣới lên  Các module mức thấp kết hợp thành nhóm thể chức đặc biệt phần mềm  Một driver tạo để thao tác test-case  Các module kiểm nghiệm theo nhóm (Cluster): nhóm module mà module phía cần đến kiểm nghiệm  Driver bỏ nhóm module kết hợp dần lên phía sơ đồ phân cấp chương trình  Tiết kiệm chi phí tạo stub Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 245 Tích hợp từ dƣới lên Mo Ma D1 Mb D3 D2 cluster cluster Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn cluster 246 Kiểm nghiệm hồi quy  Việc kết hợp module lại với ảnh hưởng đến vòng lặp điều khiển, cấu trúc liệu hay I/O chia sẻ số module  Điều làm lộ số lỗi phát tiến hành kiểm nghiệm theo đơn vị  Phải kiểm nghiệm hồi quy tích hợp  Kiểm nghiệm hồi quy tiến hành thủ công cách thực lại test-case tạo Hoặc dùng công cụ capture-playback để thực tự động Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 247 Kiểm nghiệm tính  Kiểm nghiệm tính hiểu theo cách đơn giản là: kiểm tra chức phần mềm đáp ứng nhu cầu khách hàng xác định văn đặc tả yêu cầu phần mềm  Áp dụng kỹ thuật black-box  Kiểm nghiệm tính bao gồm  Xem xét lại cấu hình phần mềm theo lược đồ triển khai  Kiểm nghiệm alpha  Kiểm nghiệm beta Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 248 Kiểm nghiệm tính  Kiểm nghiệm alpha  Được tiến hành nơi sản xuất phần mềm  Nhà phát triển phần mềm quan sát người sử dụng dùng sản phẩm ghi nhận lại lỗi phát sinh để sửa chữa  Kiểm nghiệm beta  Phần mềm kiểm tra bên phạm vi đơn vị sản xuất  Khách hành trực tiếp sử dụng ghi nhận lỗi để báo lại cho nhà phát triển sửa chữa Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 249 Kiểm nghiệm hƣớng đối tƣợng  Về chiến thuật kiểm nghiệm hướng đối tượng theo thứ tự giống kiểm nghiệm cổ điển: Kiểm nghiệm đơn vị Kiểm nghiệm tích hợp Kiểm nghiệm chức Kiểm nghiệm toàn hệ thống Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 250 Kiểm nghiệm hƣớng đối tƣợng  Không thể tách rời tác vụ đối tượng/lớp để kiểm nghiệm  Tác vụ đóng bao lớp  Các lớp override tác vụ  Kiểm nghiệm đơn vị hướng đối tượng tập trung vào lớp  kiểm nghiệm hành vi lớp Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 251 Kiểm nghiệm tích hợp hƣớng đối tƣợng  Khái niệm sơ đồ phân cấp không nhiều ý nghĩa chương trình hướng đối tượng  kiểm nghiệm tích hợp theo cách khác  Hai hình thức kiểm nghiệm tích hợp hướng đối tượng  Kiểm nghiệm sở thread: tích hợp lớp tạo thành thread để phục vụ cho input chương trình  Kiểm nghiệm sở sử dụng: lớp client tích hợp để sử dụng dịch vụ cung cấp lớp server Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 252 Kiểm nghiệm theo kịch  Dựa vào use-case để soạn kịch  Ví dụ: kịch cho hệ thống đăng ký môn học qua WEB Login với username = “e59306547”, password = “6547” Chọn chức đăng ký môn học Chọn nhóm môn học môn: CNPM, AI, XLTHS, PTTK, XLSS có nhóm trùng thời khoá biểu Nhấn nút Submit Chương trình phải báo lỗi liệt kê nhóm bị trùng thời khoá biểu Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 253 Nghệ thuật gỡ rối - DEBUG  Gỡ rối trình nhằm loại bỏ lỗi phát trình kiểm tra  Gỡ rối thực kết việc kiểm tra: lỗi phát  tìm kiếm nguyên nhân  sửa lỗi  Có hình thức gỡ rối: brute force, loại trừ nguyên nhân theo vết Nên dùng kết hợp hình thức Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 254 Nghệ thuật gỡ rối  Gỡ rối công việc khó khăn dễ gây tâm lý chán nản nguyên nhân gây lỗi nhiều lại mơ hồ: timeout, độ xác, chủ quan lập trình  Khả gỡ rối gần bẩm sinh người Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 255 Brute Force  Là phương pháp phổ biến lại hiệu cho việc phát nguyên nhân gây lỗi phần mềm  Triết lý phương pháp là: “Hãy để máy tính tìm lỗi”  Có cách thực hiện:  Lấy liệu nhớ để xem xét  Dùng run-time trace để tìm lỗi  Dùng lệnh WRITE để xuất liệu cần kiểm tra hình  Áp dụng phương pháp tất phương pháp khác thất bại Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 256 Loại trừ nguyên nhân  Phương pháp dựa nguyên tắc phân chia nhị phân  Cách thực hiện:  Khi lỗi phát hiện, cố gắng đưa danh sách nguyên nhân gây lỗi  Danh sách nghiệm lại để loại bỏ dần nguyên nhân không tìm thấy nguyên nhân khả nghi  Khi liệu kiểm nghiệm tinh chế lại để tiếp tục tìm lỗi Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 257 Theo vết  Là phương pháp gỡ lỗi phổ biến dùng thành công chương trình nhỏ khó áp dụng cho chương trình lớn  Cách thực hiện: bắt đầu dòng mã nguồn có triệu chứng lỗi thực lần ngược trở lại dòng mã nguồn tìm thấy dòng gây lỗi Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 258 Kết thúc môn học Thi cuối kỳ ? Giới thiệu-Phân tích Thiết kế - Hiện thực/triển khai Kiểm nghiệm - UML  Tất nội dung Chúc mừng bạn hoàn tất môn học Công Nghệ Phần Mềm ! [...]... • Efficiency: Phần mềm được sản xuất trong thời gian và điều kiện vừa phải Phần mềm vận hành đúng mức độ yêu cầu về công việc và thời gian • Reliablity: Phần mềm vận hành ổn định và tương tác được với các hệ thống ứng dụng • Usability: Phần mềm có thể dùng được bởi người sử dụng và với môi trường mà người sử dụng đang có Chú ý tới giao diện, điều kiện hệ thống,… • Modifiability: Phần mềm có thể được... phần mềm (software design), viết code (code generation • Giai đoạn kiểm tra: kiểm tra phần mềm (software testing), kiểm tra tính hợp lý của phần mềm • Giai đoạn bảo trì: Sửa lỗi (correction), thay đổi môi trường thực thi (adaptation), tăng cường (enhancement) Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 15 Các mô hình sản xuất phần mềm. .. Portability: Phần mềm có thể chuyển đổi dễ dàng sang các hệ thống khác mà không cần phải điều chỉnh lớn Chỉ cần recompile nều cần thiết là tốt nhất • Testability: Phần mềmcó thể d0ược kiểm tra dễ dàng Tốt nhất là được modul hóa • Reusability: Phần mềm hay một phần có thể được tái sử dụng cho các ứng dụng khác Các modul có thiết kế tốt, độc lập và giao tiến đơn giản, cả về tình tương thích công nghệ phát... Engineering Công việc của software engineering bao gồm: • • • • • Phân tích hệ thống/vấn đề Xác định các yêu cầu Thiết kế phần mềm Viết phần mềm (coding) Kiểm tra và tích hợp hệ thống • Cài đặt và chuyển giao phần mềm • Lập tài liệu • Bảo trì Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn • • • • Quản lý chất lượng Huấn luyện Dự đoán tài... - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 11 Cụ thể (tt) • Maintainability: thiết kế của phần mềm có thể được hiểu dễ dàng cũng như chuyển giao thuận tiện cho người khác trong quá trình điều chỉnh, nâng cấp hay thay đổi theo yêu cầu • Interoperability: Phần mềm vận hành ổn định và đúng như mong đợi Trên hệ thống nhiều người dùng (multi users) phần mềm vẫn... hợp công nghệ cao và sự thay đổi nhanh chóng của công nghệ  Phải bảo đảm tính chuyên nghiệp trong phát triển dự án phần mềm:     Bảo đảm lịch trình của dự án Điều phối và khai thác tối đa nguồn nhân lực hiện có Bảo đảm chất lượng của sản phẩm Khả năng khắc phục các sự cố xảy ra khách quan  Các dự án càng lớn càng cần có sự quản lý chặt chẻ và đồng bộ Trường Đại Học Bách Khoa - Khoa Công Nghệ. .. của hệ thống Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 16 Mô hình WaterFall – Sequency model • Mô hình phát triển phần mềm đầu tiên • Các công việc tiếp nối nhau một cách tuần tự • Đặt nền móng cho các phương pháp phân tích, thiết kế, kiểm tra… Phân tích yêu cầu Thiết kế hệ thống & phần mềm Hiện thức và kiểm tra moduls Tích hợp và... vào công nghệ phát triển có tính reusable cao • Partten system development Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 23 Các tiêu chuẩn dùng trong CNpPM • The capability Maturity Model (CMM) của Software Engineering Institue (SEI) - Đại học Carnegie Mellon – Chú trọng đến tính hệ thống và khả năng quản trị của các công ty phần mềm. .. triển, thực thi và bảo trì các hệ thống thiên về phần mềm • Tập trung vào quy trình, sự đo lường, sản phẩm, tính đúng thời gian và chất lượng Qui trình Đo lường Tiêu chuẩn Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn Thời gian Quản lý Chất lượng Dịch vụ 14 Mô hình phát triển phần mềm Các công đoạn chính tổng quát bao gồm 4 giai đoạn •... Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 25 Chƣơng 2 Project Management Sub-Team trong Software Projects Project Estimation Project Scheduling Project Management Tools Tại sao cần Project management  Phát triển phần mềm hiện đại làm theo teamworks  Cần quản lý và kiểm soát được rủi ro (Risk) trong quá trình sản xuất  Các dự án phần mềm đòi hỏi