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ũ

Chia sẻ: Caphesuadathemmatong | Ngày: | Loại File: PDF | Số trang:41

Thêm vào BST

Báo xấu

21
lượt xem 5
download

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

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ủ đề:

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

Lưu

Nội dung Text: 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ũ

CHƢƠNG 1. 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 1 tập hợp các hoạt động được thực hiện bởi con người nhờ vào :  Vận dụng các phương pháp, tri thức kinh nghiệm  Sử dụng các công cụ hỗ trợ Để sản sinh ra phần mềm và các sản phẩm kèm theo (chẳng hạn như đặc tả yêu cầu, kế hoạch thực hiện, hồ sơ thiết kế, mã nguồn, các bộ dữ 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 Tri thức phần mềm Phương pháp Kinh nghiệm Khách hàng 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ữ cơ bản  Tiến trình phần mềm (software process)  Tiến trình con/ bộ 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ợ các hoạt động  Vai trò (roles) : Mỗi người sẽ có trách nhiệm thực hiện một hoạt động của một tiến trình nào đó 29
1.3. Các pha (các hoạt động) nền tảng 1. Đặc tả phần mềm Tùy theo mô hình chu kỳ sống phần mềm, 2. Phân tích, thiết kế các hoạt động này sẽ 3. Phát triển, xây dựng được tổ chức, phân rã, 4. Xác nhận phần mềm (kiểm thử) sắp xếp để thực hiện 5. Bảo trì/Tiến hóa phần mềm 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 và kiểm soá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, … “role” Reader “activity” “activity” “activity” Make Read Note accept refuse “role” “activity” Author improve 32
1.4. Ví dụ - Tiến trình thanh tra mã nguồn Code Inspection Process  Khái niệm : Tiến trình dò tìm lỗi trong mã nguồn sau khi đã hết lỗi biên dịch (trước khi dịch thành mã thực thi để chạy và kiểm thử)  Thế nào là lỗi ?  Không đáp ứng đặc tả (nếu có)  Lỗi luận lý (vòng lặp, không xử lý mặc nhiên (default), xét thiếu trường hợp,…)  Lỗi kỹ thuật (tràn số, biểu thức, chỉ số mảng, cấp phát bộ nhớ,…)  Chuẩn mực lập trình (code standard) 33
1.4. Ví dụ - Tiến trình thanh tra mã nguồn (tt) Các hoạt động  Preparing for Inspection: Source codes (hardcopies, files) được cung cấp cho mỗi lần thanh tra  Inspection Overview: họp nhanh để giải thích cách bố trí các đoạn mã  Individual Inspection: Mỗi thanh tra cố gắng phát hiện tất cả các lỗi (defects) trong chương trình  Meeting: Để quyết định các khuyết điểm nào cần phải được báo cáo  Tất cả các thanh tra phải tham dự buổi họp này  Moderator (người nhiều kinh nghiệm trong lập trình)  Rework: Danh sách các lỗi sẽ được đưa ra để tác giả của nó sửa đổi và cải tiến mã nguồn  Follow up: sự đúng đắn của giai đoạn rework sẽ được kiểm tra lại trong một buổi họp tổng kết hoặc những lần thanh tra sau này cho đến khi kết thúc dự án  Record keeping: thông tin về sản phẩm, trách nhiệm của các thành viên trong dự án 34
1.4. Ví dụ - Tiến trình thanh tra mã nguồn (tt) Roles, Tools,…  Roles:  Code author: Viết code, sửa chữa những lỗi phát hiện được  Inspector: tìm lỗi do bỏ sót, không nhất quán trong chương trình  Reader: diễn giải các đoạn mã trong cuộc họp thanh tra  Scribe: ghi lại kết quả cuộc họp  Moderator: quản lý qui trình và tiện ích việc thanh tra, báo cáo kết quả xử lý đến chief moderator  Chief moderator: chịu trách nhiệm cải tiến tiến trình thanh tra, cập nhật danh sách kiểm tra, phát hiện các chuẩn  Tools: Code viewers, Code Analysers, File Managers, Workflow Tools,… 35
1.4. Ví dụ - Tiến trình thanh tra mã nguồn (tt) Những điểm đáng ghi nhận  Tìm được hơn 60% lỗi nếu dùng các phương pháp không hình thức [Fagan, 1986]  Tìm được hơn 90% lỗi nếu vận dụng thêm các phương pháp hình thức, phương pháp toán học [Mills et al, 1986] Vì xác định lỗi sớm -> giảm đáng kể chi phí…  Khảo sát từ 1 đề án lớn (1980): giá phải trả để sửa chữa, khắc phục 1 lỗi phát hiện khi:  Thanh tra sản phẩm là 1USD  Kiểm thử là 13 USD  Sau khi phát hành là 95 USD  Mã nguồn đáp ứng được các thuộc tính chất lượng (chuẩn mã hóa, tương thích, dễ bảo trì,…) 36
2.1. Sự trƣởng thành phần mềm  Software Process Maturity  Là mức độ hay quy mô mà một tiến trình phần mềm  được định nghĩa tường minh trong tổ chức sản xuất phần mềm  được vận hành nhờ vào sự  quản lý  kiểm soát  đánh giá định lượng 37
2.2. Tổ chức phần mềm chƣa trƣởng thành  Đặt nặng vai trò cá nhân: phụ thuộc vào sự tùy biến, linh động, “chữa cháy” của các chuyên viên và nhà quản lý  Tiến trình phần mềm (nếu có): Không vận dụng nghiêm ngặt, không kiểm soát nghiêm túc trong quá trình vận hành  Quản lý đề án: không kiểm soát được tiến độ, không kiểm soát được kinh phí  Chất lƣợng sản phẩm:  Không có các tiêu chí khách quan để đánh giá  Xem nhẹ các hoạt động cải tiến chất lượng (việc duyệt lại hồ sơ phần mềm, thanh tra sản phẩm, kiểm thử,…) bị rút ngắn thời gian hoặc bỏ hẳn khi đề án có khả năng bị trễ hạn  Khách hàng không thể hình dung rõ về sản phẩm mãi đến khi nào được giao nộp 38
2.3. Tổ chức phần mềm trƣởng thành  Tiến trình phần mềm :  Được mô tả tƣờng minh bằng các văn bản, truyền đạt tới mọi thành viên tham gia vào hoạt động sản xuất phần mềm  Phân định rõ ràng các vai trò và trách nhiệm của thành viên tham gia vào tiến trình phần mềm  Được vận hành, kiểm soát định lƣợng, tuân thủ xuyên suốt trong quá trình sản xuất phần mềm  Được tiến hóa để phù hợp với các thay đổi về môi trường công nghệ • Cập nhật, cải tiến tiến trình phần mềm trên cơ sở phân tích về lợi ích kinh tế • Giảm sự phụ thuộc vào cá nhân, tận dụng sức mạnh đồng đội 39
2.3. Tổ chức phần mềm trƣởng thành (tt)  Quản lý đề án:  Chuẩn bị kỹ càng kế hoạch sản xuất  Ước tính ngân sách và kiểm soát được chi phí  Làm chủ thời gian và tiến độ thực hiện các đề án  Chất lƣợng sản phẩm: đúc kết được các tiêu chí khách quan và định hướng  Để đánh giá được chất lượng sản phẩm  Để phân tích các sự cố về sản phẩm  Để đạt được các kết quả mong đợi về sản phẩm 40
2.4. Vấn đề Làm thế nào để nâng cao tính trưởng thành, năng lực tổ chức sản xuất của một doanh nghiệp/ công ty phần mềm ?  Những nổ lực cứu cánh  Phát triển năng lực, kỹ thuật cá nhân  Phát triển, áp dụng các phương pháp, kỹ thuật mới  Cải tổ môi trường công nghệ ? → chi phí tăng  Sử dụng các chuẩn về chất lượng qui trình, chất lượng sản phẩm : ISO (các phiên bản), PSP, CMMI, …  Đáp ứng các chuẩn mực quốc tế  Nâng cao quá trình phát triển phần mềm, tăng nhân lực  khó khăn về đào tạo con người → chi phí tăng 41
3.1 Các tiếp cận cải tiến phổ biến 1. Personal Software Process (PSP) 2. Team Software Process (TSP) 3. Tiến trình Angile i. eXtreme Programming (XP) ii. Scump iii. Dynamic Systems Development Method (DSDM) iv. Crystal v. Feature-Driven 4. CMM/CMMi 5. … 42
3.1.1. Tiến trình PSP  Watt S.Humphrey (thuộc viện SEI – Software Engineering Institute) đưa ra lần đầu tiên vào năm 1993 và bắt đầu phổ biến rộng rãi vào năm 1994  Mục đích: hướng dẫn các kỹ sư phần mềm cải tiến kỹ năng và chất lượng công việc  Hai khía cạnh chính mà PSP tập trung hỗ trợ là:  Quản lý thời gian và kế hoạch – quy trình lên kế hoạch  Quản lý chất lƣợng sản phẩm – quy trình quản lý sai sót 43
3.1.2. Dòng qui trình PSP 44
3.1.3. Các cấp độ PSP  PSP đề xuất 4 cấp độ hoàn thiện cá nhân và gợi ý các bước để đạt được mức độ hoàn thiện cao hơn • Áp dụng cho những dự án phức tạp PSP3 nhiều module -Tạo và sử dụng các Design • Sử dụng Design Reviews và Code Template để viết mã nguồn PSP2 Reviews để xem lại thiết kế và mã PSP2.1 nguồn -Lên kế hoạch cho các CV PSP1 • Ước lượng kích thước và thời gian phát -Phân chia CV theo quỹ thời triển sản phẩm gian và bản thân • Ghi nhận thông tin “unit test” và kết quả PSP1.1 PSP0 • -Ghi nhận kích thước sản phẩm Làm quen qui trình PSP -Ghi nhận thông tin dự án và • Ghi nhận thời gian làm việc đưa ra đánh giá • Ghi nhận sai sót trong mỗi pha LV -Lựa chọn chuẩn viết mã nguồn • Phân loại sai sót (của PSP hoặc tự bản PSP0.1 thân đưa ra) 45