Bài giảng Khó khăn trong xây dựng phần mềm: Chương 1 - ThS. Phạm Đào Minh Vũ

Bài giảng Khó khăn trong xây dựng phần mềm: Chương 1 Tiến trình phần mềm, cung cấp cho người học những kiến thức như: Bức tranh toàn cảnh phát triển phần mềm; Các thuật ngữ cơ bản; Các pha (các hoạt động) nền tảng; Một số tiến trình phổ biến; Tiến trình thanh tra mã nguồn;... Mời các bạn cùng tham khảo!

CHƢƠNG TIẾN TRÌNH PHẦN MỀM (SOFTWARE PROCESS) 26 1.1 Tiến trình phần mềm  Khái niệm : Tiến trình phần mềm bao gồm tập hợp hoạt động thực người nhờ vào :  Vận dụng phương pháp, tri thức kinh nghiệm  Sử dụng công cụ hỗ trợ Để sản sinh phần mềm sản phẩm kèm theo (chẳng hạn đặc tả yêu cầu, kế hoạch thực hiện, hồ sơ thiết kế, mã nguồn, liệu kiểm thử, tài liệu cho người dùng, …) 27 1.1 Bức tranh toàn cảnh phát triển phần mềm  Khái niệm : Nhân viên phát triển phần mềm Khách hàng Tri thức Phương pháp Kinh nghiệm Công cụ hỗ trợ (phần mềm, phần cứng) Yêu cầu thực tế Sản phầm phần mềm Tiến trình phần mềm 28 1.2 Các thuật ngữ  Tiến trình phần mềm (software process)  Tiến trình con/ phận (subprocess)  Hoạt động (activities)  Tự động hóa  Thủ cơng/bán tự động  Sản phẩm (products)  Sản phẩm có sẳn, sản phẩm kết quả, sản phẩm trung gian  Công cụ (Tools): hỗ trợ hoạt động  Vai trò (roles) : Mỗi người có trách nhiệm thực hoạt động tiến trình 29 1.3 Các pha (các hoạt động) tảng Đặc tả phần mềm Phân tích, thiết kế Phát triển, xây dựng Xác nhận phần mềm (kiểm thử) Bảo trì/Tiến hóa phần mềm Tùy theo mơ hình chu kỳ sống phần mềm, hoạt động tổ chức, phân rã, xếp để thực theo thứ tự khác nhau… Các phương pháp, kỹ thuật, kinh nghiệm, phương pháp luận,… 30 1.5 Một số tiến trình phổ biến  Tiến trình xem xét sản phẩm (Code review)  Tiến trình thay đổi phần mềm (Software Change Process)  Tiến trình Quản lý cấu hình  Tiến trình kiểm thử (Testing process)  Tiến trình hoạch định kiểm sốt tiến độ đề án  Tiến trình bảo trì phần mềm  Tiến trình cải tiến tiến trình … 31 1.4 Ví dụ Tiến trình xem xét sản phẩm (review process)  Hoạt động : Make, Read, Note, Decide,…  Sản phẩm : Một văn bản, phương án,…  Vai trị : Author, Reader  Cơng cụ : Word, Graphics Editor, … “activity” Make “activity” Read “activity” Note “role” Reader accept refuse “role” Author “activity” improve 32 1.4 Ví dụ - Tiến trình tra mã nguồn Code Inspection Process  Khái niệm : Tiến trình dị tìm lỗi mã nguồn sau hết lỗi biên dịch (trước dịch thành mã thực thi để chạy kiểm thử)  Thế lỗi ?  Khơng đáp ứng đặc tả (nếu có)  Lỗi luận lý (vịng lặp, khơng xử lý (default), xét thiếu trường hợp,…)  Lỗi kỹ thuật (tràn số, biểu thức, số mảng, cấp phát nhớ,…)  Chuẩn mực lập trình (code standard) 33 1.4 Ví dụ - Tiến trình tra mã nguồn (tt) Các hoạt động  Preparing for Inspection: Source codes (hardcopies, files) cung cấp cho lần tra  Inspection Overview: họp nhanh để giải thích cách bố trí đoạn mã  Individual Inspection: Mỗi tra cố gắng phát tất lỗi (defects) chương trình  Meeting: Để định khuyết điểm cần phải báo cáo  Tất tra phải tham dự buổi họp  Moderator (người nhiều kinh nghiệm lập trình)  Rework: Danh sách lỗi đưa để tác giả sửa đổi cải tiến mã nguồn  Follow up: đắn giai đoạn rework kiểm tra lại buổi họp tổng kết lần tra sau kết thúc dự án  Record keeping: thông tin sản phẩm, trách nhiệm thành viên dự án 34 1.4 Ví dụ - Tiến trình tra mã nguồn (tt) Roles, Tools,…  Roles:  Code author: Viết code, sửa chữa lỗi phát  Inspector: tìm lỗi bỏ sót, khơng qn chương trình  Reader: diễn giải đoạn mã họp tra  Scribe: ghi lại kết họp  Moderator: quản lý qui trình tiện ích việc tra, báo cáo kết xử lý đến chief moderator  Chief moderator: chịu trách nhiệm cải tiến tiến trình tra, cập nhật danh sách kiểm tra, phát chuẩn  Tools: Code viewers, Code Analysers, File Managers, Workflow Tools,… 35 12 nguyên lý Agile Ưu tiên cao thỏa mãn khách hàng thông qua việc chuyển giao sớm liên tục phần mềm có giá trị Chào đón việc thay đổi u cầu, chí muộn q trình phát triển Các quy trình linh hoạt tận dụng thay đổi cho lợi cạnh tranh khách hàng Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho khoảng thời gian ngắn Nhà kinh doanh nhà phát triển phải làm việc hàng ngày suốt dự án Xây dựng dự án xung quanh cá nhân có động lực Cung cấp cho họ môi trường hỗ trợ cần thiết, tin tưởng họ để hoàn thành công việc 52 12 nguyên lý Agile (tt) Phương pháp hiệu để truyền đạt thông tin tới nhóm phát triển nội nhóm phát triển hội thoại trực tiếp Phần mềm chạy tốt thước đo tiến độ Các quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà tài trợ, nhà phát triển, người dùng trì nhịp độ liên tục khơng giới hạn Liên tục quan tâm đến kĩ thuật thiết kế tốt để gia tăng linh hoạt 10 Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – 11 Các kiến ​trúc tốt nhất, yêu cầu tốt nhất, thiết kế tốt làm nhóm tự tổ chức 12 Đội sản xuất thường xuyên suy nghĩ việc để trở nên hiệu hơn, sau họ điều chỉnh thay đổi hành vi cho phù hợp 53 3.2.1 Tiến trình Agile Agile (Phát triển linh hoạt) - thân khơng phải phương pháp, mà thuật ngữ chung mô tả nhiều phương pháp linh hoạt Tuyên ngôn Agile năm 2001 bao gồm phương pháp: Scrum, XP, Crystal, FDD, Lean DSDM  Mỗi phương pháp phát triển linh hoạt có cách tiếp cận khác để thực giá trị cốt lõi tuyên ngôn Agile  Theo khảo sát học viên theo học, 50% Scrum, 20% Scrum + XP, 12% XP, 18% lại phương pháp khác Agile ô – Các phƣơng pháp đƣợc triển khai dƣới ô 54 Nội dung Khái niệm tiến trình phần mềm Sự trƣởng thành phần mềm Các tiếp cận cải tiến tiến trình Ví dụ minh họa 55 Ví dụ nổ lực tổ chức phần mềm  Giới thiệu: Đề án phần mềm phi thuyền thoi  Phát triển IBM – Houston, Texas (từ năm 1993 cơng ty chuyển nhượng cho tập đồn Loral sát nhập vào “Bộ phận Hệ thống thông tin không gian” Loral)  Mục tiêu: nhằm xây dựng phần mềm hỗ trợ vận hành phi thuyền thoi, đáp ứng địi hỏi an tồn tin cậy  Phấn đấu khả để đảm bảo khơng có lỗi phần mềm phiên chuyển giao đến trung tâm không gian Johnson NASA 56 Đề án Phần mềm phi thuyền thoi (tt) Một số đặc trƣng sản phầm đề án PM  Hỗ trợ chức giao tiếp phi thuyền tác vụ mặt đất  Theo dõi, quản lý hệ thống lặp đặt phi thuyền, kiểm soát lỗi, tự sửa chữa lỗi,…  Nhiều phần mềm chạy đồng thời máy tính lắp đặt phi thuyền: đòi hỏi đồng hóa thời gian thực xác  Hệ thống phần mềm dự phòng: Phát triển độc lập nhà thầu khác, hệ thống chưa dùng suốt năm qua 57 Đề án Phần mềm phi thuyền thoi (tt) Đặc trƣng sản phẩm  420,000 dòng mã nguồn  Hệ điều hành: viết hợp ngữ  Phần mềm: viết ngôn ngữ HAL/S  Phát triển bảo trì khoảng 1,7 triệu dịng mã nguồn (chạy máy tính IBM S/370) cài đặt công cụ hỗ trợ  Quản lý cấu hình Các cơng cụ hỗ trợ  Tích hợp phần mềm tự động / bán tự động cho hoạt  Giả lập kiểm thử động tiến trình  Kiểm chứng tự động phát triển phần  Định lại cấu hình phần mềm mềm 58 Đề án Phần mềm phi thuyền thoi (tt) Cấu trúc nhân lực  Thực 270 thành viên  Hầu hết thành viên: trẻ, tài ba, xuất thân từ nhiều nguồn khác  Để đáp ứng đòi hỏi tuyệt đối tin cậy an toàn:  Khoảng 26% nhân viên tham gia testing, verification  Khoảng 18% nhân viên tham gia phát triển phần mềm  Còn lại công đoạn khác 59 Đề án Phần mềm phi thuyền thoi (tt) Cấu trúc nhân lực Cơng việc Tỉ lệ % ngƣời tham gia Phân tích yêu cầu phần mềm 6% Phát triển phần mềm 18% Kiểm chứng phần mềm 26% Hỗ trợ phần cứng giả lập 2% Hỗ trợ người dùng 13% Phân tích phần mềm hỗ trợ 3% Phát triển phần mềm hỗ trợ 15% Kiểm chứng phần mềm hỗ trợ 11% Công việc khác 6% Cấu trúc nhân lực Đề án phi thuyền thoi 60 Đề án Phần mềm phi thuyền thoi (tt) Nổ lực cải tiến quy trình (1)  Quản lý yêu cầu thực tế  1979: sát nhập nhóm phân tích u cầu thực tế nhóm kiểm chứng hiệu phần mềm  1984: tiến trình phân tích u cầu định nghĩa thức, q trình phân tích tập trung vào tính khả thi, xem xét kỹ vấn đề trước cài đặt  1986: thực tra chặt chẽ yêu cầu thực tế, ghi nhận theo dõi vấn đề phát sinh  Sau năm tiến hành: số lượng vấn đề phát sinh giảm 75%  Thay đổi quan trọng quan điểm: chất lượng yêu cầu thực tế sở hữu phân tích viên, thay khách hàng (NASA)  Đầu năm 1990: vận dụng phương pháp hình thức chặt chẽ để xác định yêu cầu thực tế 61 Đề án Phần mềm phi thuyền thoi (tt) Nổ lực cải tiến quy trình (2)  Xem lại (review) tra (inspection) sản phẩm  Khởi đầu đề án: tận dụng lập trình cấu trúc (bắt buộc lập trình viên) -> không đủ hiệu để sửa lỗi  1978: tiến hành tra phần mềm (cho tất thiết kế lẫn mã nguồn) -> dị tìm sớm lỗi phần mềm, đẩy bớt chi phí kiểm chứng kiểm thử vào pha thiết kế cài đặt, nhờ giảm thiểu đáng kể chi phí khắc phục lỗi  Đầu năm 1980: Tiến hành phân tích yếu điểm đưa đến việc bỏ sót lỗi phần mềm tiến trình tra dị tìm lỗi -> tiền đề cho việc phân tích, đánh giá tiền trình phần mềm 62 Đề án Phần mềm phi thuyền thoi (tt) Nổ lực cải tiến quy trình (3)  Quản lý, kiểm sốt cấu hình  Tiến hành bắt đầu đề án  1980: thực thức chặt chẽ (việc theo dõi vết sản phẩm cịn làm thủ cơng)  1982: sở liệu quản lý cấu hình thiết lập (nhờ kinh nghiệm thực tiễn tích lũy quản lý phần mềm giấy)  1983: phần mềm quản lý cấu hình phát triển dựa CSDL quản lý cấu hình  => tự động hóa kiểm sốt cấu hình theo dõi lỗi, cải tiến suất lao động đáng kể (theo dõi đến dòng mã nguồn)  Ghi nhận  Quản lý giấy nghiêm túc chưa có cơng cụ phần mềm hỗ trợ [xác định giải cấp bách mục tiêu đề thay phải chờ đợi công cụ hỗ trợ tự động]  Công cụ nhằm gia tăng suất lao động  80% lỗi tìm dịng mã nguồn “sống” hệ thống 10 năm 63 Đề án Phần mềm phi thuyền thoi (tt) Nổ lực cải tiến quy trình (4)  Cơng nghệ hóa phát triển phần mềm  1970: việc kiểm chứng phần mềm giao cho đội ngũ làm việc độc lập với nhân viên phát triển phần mềm  1981: kỹ thuật kiểm chứng biên soạn, ghi nhận văn  1982: cài đặt việc lưu trữ liệu lỗi hệ thống quản lý cấu hình  1984: hệ thống hỗ trợ kiểm chứng xây dựng [Công việc tra thủ tục kiểm chứng, kiểm thử tiến hành đồng thời]  1985: dùng phương pháp Prototype với mục đích hồn thiện đặc tả u cầu thơng qua q trình làm việc với khách hàng [khi xác định rõ yêu cầu thực tế, Prototype phần mềm không cần dùng nữa]  1986: cơng cụ phân tích (mã nguồn) phát triển đưa vào sử dụng tiến trình kiểm chứng phần mềm 64 Đề án Phần mềm phi thuyền thoi (tt) Nổ lực cải tiến quy trình (5)  Quản lý thay đổi tiến trình phần mềm  1984: Một nhóm nhân viên IBM (Ron Radice dẫn đầu) thực tuần xem xét, duyệt lại đề án  1987: đề xuất bảng câu hỏi đánh giá tiến trình => thủ tục vận dụng bảng câu hỏi tiền đề cho CMM (Capability Maturity Model) – Mơ hình đánh giá tiến trình phần mềm mà Watts Humphrey phát triển viện SEI  1988: Một đội ngũ đánh giá tiến trình phần mềm (các thành viên NASA, Jet Propulsion Lab SEI) đánh giá đề án phần mềm thoi có cấp độ trưởng thành  1990: Thành lập nhóm sở hữu tiến trình có trách nhiệm  Mơ tả tiến trình  Sưu tập phân tích độ đo tiến trình  Cải tiến tiến trình hỗ trợ huấn luyện vận dụng tiến trình  => Các tiến trình cài đặt kiểm sốt cấu hình: có u cầu thức việc thay đổi tiến trình, tiến trình phê duyệt “chạy” để cập nhật (đổi mới) tiến trình 65 Đề án Phần mềm phi thuyền thoi (tt) Ghi nhận  Không phụ thuộc “cá nhân – nhân tài”  Khơng phó mặc vấn đề nảy sinh cho cá nhân  dịng mã nguồn xem xét người  Tồn nhóm phải chịu tránh nhiệm cho lỗi phát sinh sau chuyển giao  Không dựa vào hay chờ đợi công cụ tự động  Để giảm số lỗi xuống chi phí cao Để vài ngàn dịng mã nguồn có lỗi chi phí bắt đầu tăng “dữ dội” [thực tế vào năm 1993 trung bình cịn 0.3 lỗi vài ngàn dịng mã lệnh]  Các tổ chức chưa trưởng thành dựa vào “nhân tài” để cứu nguy đề án, tổ chức trưởng thành dựa vào họ để “vận dụng phương pháp, kinh nghiệm,…” vào ứng dụng 66 ... Phát triển phần mềm 18 % Kiểm chứng phần mềm 26% Hỗ trợ phần cứng giả lập 2% Hỗ trợ người dùng 13 % Phân tích phần mềm hỗ trợ 3% Phát triển phần mềm hỗ trợ 15 % Kiểm chứng phần mềm hỗ trợ 11 % Công... trình 29 1. 3 Các pha (các hoạt động) tảng Đặc tả phần mềm Phân tích, thiết kế Phát triển, xây dựng Xác nhận phần mềm (kiểm thử) Bảo trì/Tiến hóa phần mềm Tùy theo mơ hình chu kỳ sống phần mềm,... CMMI, …  Đáp ứng chuẩn mực quốc tế  Nâng cao trình phát triển phần mềm, tăng nhân lực  khó khăn đào tạo người → chi phí tăng 41 3 .1 Các tiếp cận cải tiến phổ biến Personal Software Process (PSP)