Bài giảng Nhập môn công nghệ học phần mềm - Phần 1: Giới thiệu chung về công nghệ học phần mềm

 SW quality Management 15. Quantitative process management LEVEL 4: Managed LEVEL 5: Optimizing 16. Process change management 17. Technology change management 18. Defect prevention 3.5.2 Mô hình tuyến tính Phân tích Thiết kế Lập trình Kiểm thử Công nghệ học Hệ thống / Thông tin Điển hình là mô hình vòng đời cổ điển (mô hình thác nước) Classic life cycle / waterfall model: là mô hình hay đựoc dùng nhất Mô hình tuyến tính Công nghệ học Hệ thống / Thông tin và mô hình hóa (System / Information engineering and modeling): thiết lập các yêu cầu, ánh xạ một số tập con các yêu cầu sang phần mềm trong quá trình tương tác giữa phần cứng, người và CSDL Phân tích yêu cầu (Requirements analysis): hiểu lĩnh vực thông tin, chức năng, hành vi, tính năng và giao diện của phần mềm sẽ phát triển. Cần phải tạo tư liệu và bàn thảo với khách hàng, người dùng Mô hình tuyến tính Thiết kế (Design): là quá trình nhiều bước với 4 thuộc tính khác nhau của một chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thủ tục (thuật toán). Cần tư liệu hóa và là một phần quan trọng của cấu hình phần mềm Tạo mã / lập trình (Code generation / programming): Chuyển thiết kế thành chương trình máy tính bởi ngôn ngữ nào đó. Nếu thiết kế đã được chi tiết hóa thì lập trình có thể chỉ thuần túy cơ học Mô hình tuyến tính Kiểm thử (Testing): Kiểm tra các chương trình và môđun cả về lôgic bên trong và chức năng bên ngoài, nhằm phát hiện ra lỗi và đảm bảo với đầu vào xác định thì cho kết quả mong muốn Hỗ trợ / Bảo trì (Support / Maintenance): Đáp ứng những thay đổi, nâng cấp phần mềm đã phát triển do sự thay đổi của môi trường, nhu cầu Điểm yếu của Mô hình tuyến tính Thực tế các dự án ít khi tuân theo dòng tuần tự của mô hình, mà thường có lặp lại (như mô hình của Boehm) Khách hàng ít khi tuyên bố rõ ràng khi nào xong hết các yêu cầu Khách hàng phải có lòng kiên nhẫn chờ đợi thời gian nhất định mới có sản phẩm. Nếu phát hiện ra lỗi nặng thì là một thảm họa! 3.5.3 Mô hình chế thử (Prototyping model) Nghe Khách trình bày Tạo / sửa bản mẫu Khách kiểm tra bản mẫu Mô hình chế thử: Khi nào ? Khi mới rõ mục đích chung chung của phần mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao hoặc chưa rõ yêu cầu đầu ra Dùng như “Hệ sơ khai” để thu thập yêu cầu người dùng qua các thiết kế nhanh Các giải thuật, kỹ thuật dùng làm bản mẫu có thể chưa nhanh, chưa tốt, miễn là có mẫu để thảo luận gợi yêu cầu của người dùng 3.5.4 Mô hình phát triển ứng dụng nhanh (Rapid Application Development: RAD) Là quy trình phát triển phần mềm gia tăng, tăng dần từng bước (Incrimental software development) với mỗi chu trình phát triển rất ngắn (60-90 ngày) Xây dựng dựa trên hướng thành phần (Component-based construction) với khả năng tái sử dụng (reuse) Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hình xử lý, Tạo ứng dụng, Kiểm thử và đánh giá (Business, Data, Process, Appl. Generation, Test) Mô hình phát triển ứng dụng nhanh Business Modeling Data Modeling Process Modeling Application Generation Testing & Turnover 60 - 90 days Team #1 Team #2 Team #3 RAD: Business modeling Luồng thông tin được mô hình hóa để trả lời các câu hỏi: Thông tin nào điều khiển xử lý nghiệp vụ ? Thông tin gì được sinh ra? Ai sinh ra nó ? Thông tin đi đến đâu ? Ai xử lý chúng ? RAD: Data and Process modeling Data modeling: các đối tượng dữ liệu cần để hỗ trợ nghiệp vụ (business). Định nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng Process modeling: Các đối tượng dữ liệu được chuyển sang luồng thông tin thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu RAD: Appl. Generation and Testing Application Generation: Dùng các kỹ thuật thế hệ 4 để tạo phần mềm từ các thành phần có sẵn hoặc tạo ra các thành phần có thể tái dụng lại sau này. Dùng các công cụ tự động để xây dựng phần mềm Testing and Turnover: Kiểm thử các thành phần mới và kiểm chứng mọi giao diện (các thành phần cũ đã được kiểm thử và dùng lại) RAD: Hạn chế ? Cần nguồn nhân lực dồi dào để tạo các nhóm cho các chức năng chính Yêu cầu hai bên giao kèo trong thời gian ngắn phải có phần mềm hoàn chỉnh, thiếu trách nhiệm của một bên dễ làm dự án đổ vỡ RAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụng không thể môđun hóa hoặc đòi hỏi tính năng cao Mạo hiểm kỹ thuật cao thì không nên dùng RAD 3.5.5 Các mô hình tiến hóa: gia tăng, xoắn ốc, xoắn WINWIN, ... Phần lớn các hệ phần mềm phức tạp đều tiến hóa theo thời gian: môi trường thay đổi, yêu cầu phát sinh thêm, hoàn thiện thêm chức năng, tính năng Các mô hình tiến hóa (evolutionary models) có tính lặp lại. Kỹ sư phần mềm tạo ra các phiên bản (versions) ngày càng hoàn thiện hơn, phức tạp hơn Các mô hình: incremental, spiral, WINWIN spiral, concurrent development model Mô hình gia tăng(The incremental model) Kết hợp mô hình tuần tự và ý tưởng lặp lại của chế bản mẫu Sản phẩm lõi với những yêu cầu cơ bản nhất của hệ thống được phát triển Các chức năng với những yêu cầu khác được phát triển thêm sau (gia tăng) Lặp lại quy trình để hoàn thiện dần Mô hình gia tăng System/info. Engineering Calendar time Gia tăng 1 Gia tăng 2 Gia tăng 3 Gia tăng 4 Xuất xưởng 2 Xuất xưởng 1 Xuất xưởng 3 XX 4 Mô hình xoắn ốc (spiral) Giao tiếp khách hàng Lập kế hoạch Phân tích rủi ro Kỹ nghệ Xây dựng & Xuất xưởng Khách hàng đánh giá Bảo trì Nâng cấp Làm mới Khái niệm Mô hình xoắn ốc (tiếp) Giao tiếp khách hàng: giữa người phát triển và khách hàng để tìm hiểu yêu cầu, ý kiến Lập kế hoạch: Xác lập tài nguyên, thời hạn và những thông tin khác Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạo hiểm quản lý Kỹ nghệ: Xây dựng một hay một số biểu diễn của ứng dụng Mô hình xoắn ốc (tiếp) Xây dựng và xuất xưởng: xây dựng, kiểm thử, cài đặt và cung cấp hỗ trợ người dùng (tư liệu, huấn luyện, . . .) Đánh giá của khách hàng: Nhận các phản hồi của người sử dụng về biểu diễn phần mềm trong giai đoạn kỹ nghệ và cài đặt Mô hình xoắn ốc: Mạnh và yếu? Tốt cho các hệ phần mềm quy mô lớn Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa Khó thuyết phục khách hàng là phương pháp tiến hóa xoắn ốc có thể kiểm soát được Chưa được dùng rộng rãi như các mô hình tuyến tính hoặc chế thử Mô hình xoắn ốc WINWIN Nhằm thỏa hiệp giữa người phát triển và khách hàng, cả hai cùng “Thắng” (win-win) Khách thì có phần mềm thỏa mãn yêu cầu chính Người phát triển thì có kinh phí thỏa đáng và thời gian hợp lý Các hoạt động chính trong xác định hệ thống: Xác định cổ đông (stakeholders) Xác định điều kiện thắng của cổ đông Thỏa hiệp điều kiện thắng của các bên liên quan Mô hình xoắn ốc WINWIN 1. Xác định mức tiếp của cổ đông 2. Xác định điều kiện thắng của cổ đông 3a. Hòa hợp điều kiện thắng 3b. Thiết lập mục tiêu mức tiếp và các ràng buộc, dự kiến 4. Đánh giá tiến trình và dự kiến sản phẩm, giải quyết rủi ro 5. Xác định mức tiếp của sản phâm và quy trình, kể cả phân chia nhỏ 7. Xét duyệt và đánh giá 6. Kiểm định sản phẩm và quy trình Mô hình phát triển đồng thời(The concurrent development model) Xác định mạng lưới những hoạt động đồng thời (Network of concurrent activities) Các sự kiện (events) xuất hiện theo điều kiện vận động trạng thái trong từng hoạt động Dùng cho mọi loại ứng dụng và cho hình ảnh khá chính xác về trạng thái hiện trạng của dự án Thường dùng trong phát triển các ứng dụng khách/chủ (client/server applications): system and componets are developed concurrently 3.5.6 Mô hình theo thành phần(Component-based model) Gắn với những công nghệ hướng đối tượng (Object-oriented technologies) qua việc tạo các lớp (classes) có chứa cả dữ liệu và giải thuật xử lý dữ liệu Có nhiều tương đồng với mô hình xoắn ốc Với ưu điểm tái sử dụng các thành phần qua Thư viện / kho các lớp: tiết kiệm 70% thời gian, 80% giá thành, chỉ số sản xuất 26.2/16.9 Với UML như chuẩn công nghiệp đang triển khai Mô hình theo thành phần Giao tiếp khách hàng Lập kế hoạch Phân tích rủi ro Kỹ nghệ Xây dựng & Xuất xưởng Khách hàng đánh giá Xác định thành phần ứng viên Tìm thành phần từ thư viện Lấy thành phần nếu có Xây dựng thành phần nếu kh.có Đặt thành phần vào thư viện Xây dựng bước lặp thứ n của hệ thống 3.5.7 Mô hình hình thức(Formal model) Còn gọi là CNHPM phòng sạch (Cleanroom SE) Tập hợp các công cụ nhằm đặc tả toán học phần mềm máy tính từ khâu định nghĩa, phát triển đến kiểm chứng Giúp kỹ sư phần mềm phát hiện và sửa các lỗi khó Thường dùng trong phát triển SW cần độ an toàn rất cao (y tế, hàng không, . . .) Mô hình hình thức: Điểm yếu ? Cần nhiều thời gian và công sức để phát triển Phí đào tạo cao vì ít người có nền căn bản cho áp dụng mô hình hình thức Khó sử dụng rộng rãi vì cần kiến thức toán và kỹ năng của khách hàng 3.5.8 Các kỹ thuật thế hệ 4(Fourth generation techniques) Tập hợp các công cụ cho phép xác định đặc tính phần mềm ở mức cao, sau đó sinh tự động mã nguồn dựa theo đặc tả đó Các công cụ 4GT điển hình: ngôn ngữ phi thủ tục cho truy vấn CSDL; tạo báo cáo; xử lý dữ liệu; tương tác màn hình; tạo mã nguồn; khả năng đồ họa bậc cao; khả năng bảng tính; khả năng giao diện Web; vv 4GT: How ? Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa khách và người phát triển là quan trọng Không nên bỏ qua khâu thiết kế. 4GT chỉ áp dụng để triển khai thiết kế qua 4GL Mạnh: giảm thời gian phát triển và tăng năng suất Yếu: 4GT khó dùng hơn ngôn ngữ lập trình, mã khó tối ưu và khó bảo trì cho hệ thống lớn  cần kỹ năng của kỹ sư phần mềm Tương lai: 4GT với mô hình theo thành phần 3.5.9 Sản phẩm và quy trình(Product and process) Quy trình yếu thì sản phẩm khó mà tốt, song không nên coi trọng quá mức vào quy trình hoặc quá mức vào sản phẩm Sản phẩm và quy trình cần được coi trọng như nhau Bài tập Phần I và Đồ án I Xem lại các khái niệm, mô hình của phần mềm và CNHPM Đồ án môn học I (cho 13 nhóm, nạp báo cáo, tư liệu tìm được trên Web và thư viện): Tìm hiểu và viết báo cáo, trình bày về mô hình phát triển phần mềm (10 mô hình / 10 nhóm) Chuẩn ISO 9001 cho SE Chuẩn CMM (www.sei.com) Các kỹ thuật lập trình (cấu trúc, mô đun, . . .)