Bài giảng Công nghệ phần mềm - Chương 1: Tiến trình phần mềm - Phạm Đào Minh Vũ

Nội dung text: Bài giảng Công nghệ phần mềm - Chương 1: Tiến trình phần mềm - Phạm Đào Minh Vũ

1. CHƢƠNG 1. TIẾN TRÌNH PHẦN MỀM (SOFTWARE PROCESS) 26
2. 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
3. 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
4. 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
5. 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 2. Phân tích, thiết kế kỳ sống phần mềm, 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
6. 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
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 3.1.2. Dòng qui trình PSP 44
20. 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 -Ghi nhận kích thước sản phẩm PSP0 • 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
21. 3.1.4. Ƣu và khuyết điểm của PSP  Ƣu điểm:  Cung cấp cho các kỹ sư những phương pháp cụ thể giúp cải tiến chất lượng công việc và nâng cao hiệu quả làm việc cá nhân  Giúp các kỹ sư nâng cao khả năng dự đoán, lập kế hoạch chính xác và theo dõi chặt chẽ tiến độ công việc => giúp chủ động hơn trong công việc được giao và thực hiện công việc  Làm nền tảng để xây dựng thành nhóm phát triển phần mềm (TSP)  Là cách tiếp cận hiệu quả để cải tiến qui trình CMM cấp độ 3 lên cấp độ 4  Khuyết điểm:  Việc áp dụng PSP vào thực tế còn nhiều khó khăn do mức độ nghiêm ngặt và chi tiết của nó  Bản thân PSP không mang lại hiệu quả tốt nhất, mà nó cần kết hợp vào trong một qui trình khác (qui trình mang tính chất lặp) 46
22. 3.2.1. Tiến trình TSP  Watt S.Humphrey (thuộc viện SEI – Software Engineering Institute) đưa ra lần đầu tiên vào năm 1996  Qui trình phần mềm nhóm - Team Software Process (TSP) là phương pháp tạo ra khả năng cho "nhóm phần mềm PSP" để xây dựng sản phẩm phần mềm hiệu quả hơn.  TSP bổ sung thêm các kỷ thuật quản lý dự án để giúp nhóm lập kế hoạch công việc và lịch biểu → điều này yêu cầu mỗi thành viên trong nhóm phải kết hợp chặt chẽ với các thành viên khác để tạo ra hiệu quả làm việc nhóm cao nhất  Người kĩ sư vẫn quản lí công việc riêng của mình và nhận quyền làm chủ kế hoạch riêng của mình nhưng TSP giúp từng kĩ sư trở thành thành viên nhóm hiệu quả 47
23. 3.2.2. Đặc điểm của TSP 48
24. 3.2.2. Đặc điểm của TSP  Ƣu điểm:  Nhiều thành viên làm việc cùng nhau sẽ tạo ra bản kế hoạch chính xác hơn so với người quản lý làm việc một mình.  Hoạt động nhóm sẽ nhận diện các nhiệm vụ chi tiết rõ ràng hơn là một người làm việc cô lập  Các nhiệm vụ tổng thể sẽ có ít lỗi hơn bởi vì lỗi từ nhiều hoạt động không liên hệ có xu hướng cắt bỏ lẫn nhau  Khuyết điểm:  Không thể hoạt động độc lập, mà cần kết hợp với PSP để tạo thành qui trình phát triển phần mềm ít chi phí, năng suất cao và chất lượng. 49
25. 3.2.1. Tiến trình Agile  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  Vào 2/2001, 17 nhà phát triển phần mềm đã gặp gỡ nhau ở Snowbird, Utah Resort để thảo luận về các phương pháp phát triển phần mềm gọn nhẹ và linh hoạt.  Công bố “Tuyên ngôn Phát triển phần mềm linh hoạt” (“Manifesto for Agile Software Development” – gọi tắt là “Tuyên ngôn Agile”) 50
26. 3.2.1. Tuyên ngôn Agile  Cá nhân và sự tƣơng tác hơn là quy trình và công cụ  Phần mềm chạy tốt hơn là tài liệu đầy đủ;  Cộng tác với khách hàng hơn là đàm phán hợp đồng;  Phản hồi với các thay đổi hơn là bám sát kế hoạch. 12 nguyên lý Agile 51
27. 12 nguyên lý Agile 1. Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị. 2. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng. 3. 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 các khoảng thời gian ngắn hơn. 4. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án. 5. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc. 52
28. 12 nguyên lý Agile (tt) 6. Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp. 7. Phần mềm chạy tốt là thước đo chính của tiến độ. 8. 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, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn. 9. Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự 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 – là căn bản. 11. Các kiến ​​trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức. 12. Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp. 53
29. 3.2.1. Tiến trình Agile Agile (Phát triển linh hoạt) - bản thân nó không phải là một phương pháp, mà là một thuật ngữ chung mô tả rất nhiều các phương pháp linh hoạt. Tuyên ngôn Agile năm 2001 đã bao gồm những phương pháp: Scrum, XP, Crystal, FDD, Lean và DSDM  Mỗi phương pháp phát triển linh hoạt có một cách tiếp cận hơi khác nhau để thực hiện các giá trị cốt lõi trong tuyên ngôn Agile.  Theo 1 cuộc khảo sát các học viên đang theo học, 50% là Scrum, 20% Scrum + XP, 12% XP, 18% còn lại là các phương pháp khác Agile là chiếc ô – Các phƣơng pháp đƣợc triển khai dƣới chiếc ô này 54
30. Nội dung 1. Khái niệm về tiến trình phần mềm 2. Sự trƣởng thành phần mềm 3. Các tiếp cận cải tiến tiến trình 4. Ví dụ minh họa 55
31. Ví dụ về sự nổ lực của 1 tổ chức phần mềm  Giới thiệu: Đề án phần mềm phi thuyền con thoi  Phát triển tại IBM – Houston, Texas (từ năm 1993 công ty này đã chuyển nhượng cho tập đoàn Loral và được sát nhập vào “Bộ phận Hệ thống thông tin không gian” của Loral)  Mục tiêu: nhằm xây dựng một phần mềm hỗ trợ vận hành phi thuyền con thoi, đáp ứng những đòi hỏi an toàn và tin cậy nhất  Phấn đấu bằng mọi khả năng để đảm bảo rằng không có lỗi phần mềm trong mỗi phiên bản được chuyển giao đến trung tâm không gian Johnson của NASA 56
32. Đề án Phần mềm phi thuyền con thoi (tt) Một số đặc trƣng về sản phầm và đề án PM  Hỗ trợ những chức năng giao tiếp giữa phi thuyền và các tác vụ trên mặt đất  Theo dõi, quản lý các hệ thống được lặp đặt trong phi thuyền, kiểm soát lỗi, tự sửa chữa lỗi,  Nhiều bản sao của phần mềm chạy đồng thời trên 4 hoặc 5 máy tính lắp đặt trong phi thuyền: đòi hỏi sự đồng bộ hóa thời gian thực cực kỳ chính xác  Hệ thống phần mềm dự phòng: Phát triển độc lập bởi một nhà thầu khác, hệ thống này chưa bao giờ dùng trong suốt mấy năm qua 57
33. Đề án Phần mềm phi thuyền con thoi (tt) Đặc trƣng sản phẩm  420,000 dòng mã nguồn  Hệ điều hành: viết bằng hợp ngữ  Phần mềm: viết bằng ngôn ngữ HAL/S  Phát triển và bảo trì khoảng 1,7 triệu dòng mã nguồn (chạy trên máy tính IBM S/370) cài đặt các 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ự  Giả lập và kiểm thử động cho các hoạt động của 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
34. Đề án Phần mềm phi thuyền con thoi (tt) Cấu trúc nhân lực  Thực hiện bởi hơn 270 thành viên  Hầu hết các thành viên: trẻ, tài ba, xuất thân từ nhiều nguồn khác nhau  Để đáp ứng được đòi hỏi tuyệt đối tin cậy và 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 là các công đoạn khác 59
35. Đề án Phần mềm phi thuyền con thoi (tt) Cấu trúc nhân lực Công việc Tỉ lệ % ngƣời tham gia Phân tích các yêu cầu của 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 trong Đề án phi thuyền con thoi 60
36. Đề án Phần mềm phi thuyền con 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 yêu cầu thực tế và nhóm kiểm chứng hiệu năng phần mềm  1984: tiến trình phân tích yêu cầu được định nghĩa chính thức, quá trình phân tích tập trung vào tính khả thi, xem xét kỹ càng các vấn đề trước khi cài đặt  1986: thực hiện thanh tra chặt chẽ các yêu cầu thực tế, ghi nhận và theo dõi các vấn đề phát sinh  Sau 1 năm tiến hành: số lượng các vấn đề phát sinh giảm 75%  Thay đổi quan trọng về quan điểm: chất lượng các yêu cầu thực tế là sở hữu của các phân tích viên, thay vì là của khách hàng (NASA)  Đầu những năm 1990: vận dụng các phương pháp hình thức và chặt chẽ để xác định các yêu cầu thực tế 61
37. Đề án Phần mềm phi thuyền con thoi (tt) Nổ lực cải tiến quy trình (2)  Xem lại (review) và thanh 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 đối với các lập trình viên) -> không đủ hiệu quả để sửa lỗi  1978: tiến hành thanh tra phần mềm (cho tất cả các thiết kế lẫn mã nguồn) -> dò tìm sớm các lỗi phần mềm, đẩy bớt chi phí kiểm chứng và kiểm thử vào các pha thiết kế và cài đặt, nhờ đó giảm thiểu đáng kể chi phí khắc phục lỗi  Đầu những năm 1980: Tiến hành phân tích những yếu điểm có thể đưa đến việc bỏ sót các lỗi phần mềm trong tiến trình thanh tra dò tìm lỗi -> là tiền đề cho việc phân tích, đánh giá tiền trình phần mềm 62
38. Đề án Phần mềm phi thuyền con thoi (tt) Nổ lực cải tiến quy trình (3)  Quản lý, kiểm soát cấu hình  Tiến hành ngay khi bắt đầu đề án  1980: được thực hiện chính thức và chặt chẽ (việc theo dõi vết sản phẩm vẫn còn làm thủ công)  1982: cơ sở dữ liệu quản lý cấu hình đã được thiết lập (nhờ kinh nghiệm thực tiễn đã được tích lũy về quản lý phần mềm trên giấy)  1983: phần mềm quản lý cấu hình đã được phát triển dựa trên CSDL quản lý cấu hình  => tự động hóa kiểm soát cấu hình và theo dõi lỗi, cải tiến năng suất lao động đáng kể (theo dõi đến từng dòng mã nguồn)  Ghi nhận  Quản lý trên giấy nghiêm túc khi chưa có công cụ phần mềm hỗ trợ [xác định và giải quyết cấp bách các mục tiêu đề ra thay vì phải chờ đợi các công cụ hỗ trợ tự động]  Công cụ nhằm gia tăng năng suất lao động  80% lỗi tìm ra là các dòng mã nguồn “sống” trong hệ thống trên 10 năm 63
39. Đề án Phần mềm phi thuyền con 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 được giao cho 1 đội ngũ làm việc độc lập với những nhân viên phát triển phần mềm  1981: các kỹ thuật kiểm chứng được biên soạn, ghi nhận bằng văn bản  1982: cài đặt việc lưu trữ dữ liệu về lỗi trong hệ thống quản lý cấu hình  1984: hệ thống hỗ trợ kiểm chứng được xây dựng [Công việc thanh tra các thủ tục kiểm chứng, kiểm thử cũng được tiến hành đồng thời]  1985: dùng phương pháp Prototype với mục đích hoàn thiện đặc tả yêu cầu thông qua quá 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 của phần mềm sẽ không cần dùng nữa]  1986: công cụ phân tích (mã nguồn) được phát triển và đưa vào sử dụng trong tiến trình kiểm chứng phần mềm 64
40. Đề án Phần mềm phi thuyền con thoi (tt) Nổ lực cải tiến quy trình (5)  Quản lý sự thay đổi của 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 hiện 2 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 được vận dụng và bảng câu hỏi chính là 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 và SEI) đã đánh giá đề án phần mềm con thoi có cấp độ trưởng thành là 5  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 và phân tích các độ đo tiến trình . Cải tiến tiến trình và hỗ trợ huấn luyện vận dụng tiến trình . => Các tiến trình được cài đặt dưới sự kiểm soát cấu hình: khi có yêu cầu chính thức về việc thay đổi tiến trình, tiến trình phê duyệt được “chạy” để cập nhật (đổi mới) tiến trình 65
41. Đề án Phần mềm phi thuyền con 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 một cá nhân . 1 dòng mã nguồn được xem xét bởi ít nhất 6 người . Toàn nhóm phải chịu tránh nhiệm cho mỗi lỗi phát sinh sau khi chuyển giao  Không chỉ dựa vào hay chờ đợi các công cụ tự động  Để giảm số lỗi xuống càng ít thì chi phí càng cao. Để vài ngàn dòng mã nguồn có ít hơn một lỗi thì chi phí bắt đầu tăng rất “dữ dội”. [thực tế vào năm 1993 thì trung bình chỉ còn 0.3 lỗi trên vài ngàn dòng mã lệnh]  Các tổ chức chưa trưởng thành thì dựa vào “nhân tài” để cứu nguy các đề án, trong khi các tổ chức trưởng thành thì dựa vào họ để “vận dụng phương pháp, kinh nghiệm, ” vào các ứng dụng mới 66