Bài giảng Công nghệ phần mềm nâng cao: Chương 1 - Lê Thị Minh Nguyện

Nội dung<br /> Khái niệm tiến trình phần mềm<br /> Các mô hình tiến trình phần mềm<br /> Mô hình cải tiến quy trình CMMI<br /> CMMI-DEV<br /> <br /> Chương 1: Tiến trình phần mềm<br /> <br /> 1<br /> <br /> Khái niệm tiến trình phần mềm<br /> <br /> 2<br /> <br /> Khái niệm tiến trình phần mềm<br /> <br /> Tiến trình: một chuỗi các bước bao gồm các<br /> hoạt động, các ràng buộc và các tài nguyên mà<br /> chúng tạo ra kết quả được mong đợi.<br />  Các công việc NÀO cần thực hiện,<br />  Theo thứ tự NÀO<br />  Dưới các ràng buộc và các tài nguyên NÀO<br />  Bởi AI<br /> để đạt được “kết quả mong đợi”<br />  Tiến trình: bao gồm một bộ các công cụ và các<br /> kỹ thuật<br /> <br /> Các đặc trưng của tiến trình<br />  Mỗi hoạt động của tiến trình có tiêu chuẩn<br /> vào và ra<br />  Các hoạt động được tổ chức theo trình tự <br /> sự tính toán về thời gian là rõ ràng<br />  Mỗi tiến trình có các nguyên tắc hướng dẫn,<br /> bao gồm các mục tiêu của từng hoạt động<br />  Các ràng buộc có thể áp dụng vào một hoạt<br /> động, tài nguyên hay sản phẩm<br /> <br /> 3<br /> <br /> 4<br /> <br /> 1<br /> <br /> Khái niệm tiến trình phần mềm<br /> <br /> Khái niệm tiến trình phần mềm<br /> <br /> Lý do để mô hình hóa một tiến trình<br />  Hình thành một cách hiểu chung<br />  Tìm ra sự không nhất quán, sự dư thừa hay<br /> sự bỏ sót<br />  Tìm ra và đánh giá các hoạt động phù hợp để<br /> đạt được các mục tiêu của tiến trình<br />  Cụ thể hóa một tiến trình chung cho một hoàn<br /> cảnh cụ thể<br /> <br />  Chu kỳ sống của phần mềm<br />  Khi một tiến trình liên quan tới việc xây dựng một<br /> phần mềm, tiến trình có thể được xem như chu kỳ<br /> sống của phần mềm.<br /> <br /> 5<br /> <br /> 6<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> Mở rộng của tiến trình “đơn giản”<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> Tiến trình đơn giản<br /> <br /> Khi dự án lớn hơn và phức tạp hơn, CẦN:<br /> <br /> <br /> <br /> <br /> <br /> 1.<br /> 2.<br /> <br /> Làm sáng tỏ và cố định các yêu cầu<br /> Kiểm tra các chức năng nhiều hơn<br /> Thiết kế cẩn thận hơn<br /> Sử dụng nhiều phần mềm và công cụ có sẵn hơn<br />  CSDL<br />  Mạng<br />  Các công cụ kiểm soát code<br /> <br /> Hầu hết mọi người thực hiện và tuân theo quy trình đơn giản<br /> này, nhưng một số bỏ qua bước Unit Test và Debug<br /> Một số người thực hiện mà không xem xét và hiểu thấu đáo<br /> “thực trạng của vấn đề” (yêu cầu của phần mềm)<br /> <br /> <br /> <br /> Nhiều người tham gia vào dự án hơn<br />  nhiều CÔNG VIỆC và nhiều NGƯỜI hơn<br /> <br /> 7<br /> <br /> 8<br /> <br /> 2<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> Mở rộng của tiến trình “đơn giản”<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br />  Các tiến trình chính thống để quản lý các dự án lớn<br /> và phức tạp:<br />  Mô hình thác nước (Waterfall)<br />  Mô hình chữ V (V-model)<br />  Mô hình bản mẫu (Prototype)<br />  Mô hình phát triển ứng dụng nhanh (RAD)<br />  Mô hình gia tăng (Incremental)<br />  Mô hình xoắn ốc (Spiral)<br />  Mô hình RUP (Rational Unified Process)<br /> <br />  Khi nhiều CÔNG VIỆC và nhiều NGƯỜI hơn,<br /> chúng ta CẦN “định nghĩa”:<br /> <br /> Tập các công việc cần được tiến hành<br /> <br /> Chuỗi các hoạt động của các công việc<br /> <br /> Đầu vào / đầu ra của các công việc<br /> <br /> Điều kiện trước, điều kiện sau của mỗi công việc<br /> <br /> Con người và các kỹ năng cần thiết để thực hiện<br /> các công việc<br /> <br /> 9<br /> <br /> 10<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> <br /> Mô hình thác nước (Waterfall)<br /> <br /> Mô hình chữ V (V-model)<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Phù hợp với những bài toán được<br /> hiểu kỹ, có rất ít hay không có các<br /> thay đổi về yêu cầu<br /> Các yêu cầu phải được xác định trong<br /> bước đầu tiên<br /> Các giai đoạn phải thực hiện tuần tự<br /> Đầu ra của giai đoạn trước là đầu vào<br /> của giai đoạn sau  người quản lý dễ<br /> theo dõi (kiểm soát)<br /> <br /> <br /> <br /> <br /> <br /> <br /> 11<br /> <br /> Sử dụng kiểm thử đơn vị để xác minh (verify) thiết kế chi tiết<br /> Sử dụng kiểm thử hệ thống để xác minh thiết kế hệ thống<br /> Sử dụng kiểm thử chấp nhận(nghiệm thu) để thẩm định (validate) các yêu cầu<br /> Nếu tìm thấy các vấn đề trong quá trình xác minh và thẩm định, phần bên trái của mô hình<br /> chữ V sẽ được tái thực hiện trước khi việc kiểm thử của phần bên phải được tái thực hiện<br /> 12<br /> <br /> 3<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> Mô hình bản mẫu (Prototype-model)<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> Mô hình phát triển ứng dụng nhanh (RAD: Rapid<br /> Application Development)<br />  Là tiến trình phát triển<br /> phần mềm gia tăng<br />  Thời gian phát triển phần<br /> mềm ngắn<br />  Xây dựng dựa trên hướng<br /> thành phần với khả năng<br /> tái sử dụng<br />  Gồm một số nhóm, mỗi<br /> nhóm làm 1 RAD theo các<br /> pha:<br /> <br /> <br /> <br /> <br /> <br /> <br /> Mô hình hóa nghiệp vụ,<br /> Mô hình hóa dữ liệu<br /> Tạo ứng dụng<br /> Kiểm thử và đánh giá<br /> <br />  Cho phép lặp lại quá trình khảo sát yêu cầu và thiết kế<br />  Giảm sự rủi ro và không chắc chắn trong quá trình phát triển<br />  Sử dụng mô hình bản mẫu khi các yêu cầu chưa rõ ràng<br /> 13<br /> <br /> 14<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> <br /> Mô hình phát triển ứng dụng nhanh (RAD: Rapid<br /> Application Development)<br /> <br /> Mô hình gia tăng (Incremental Model)<br /> <br />  Cần nguồn nhân lực dồi dào để tạo các nhóm cho<br /> các chức năng chính<br />  Yêu cầu 2 bên cam kết trong thời gian ngắn phải có<br /> phần mềm hoàn chỉnh, thiếu trách nhiệm của 1 bên<br /> dễ làm dự án đổ vỡ<br />  RAD không phải tốt cho mọi ứng dụng, nhất là các<br /> ứng dụng không thể module hó hoặc đòi hỏi tính<br /> năng cao<br />  RAD không phù hợp khi các rủi ro kỹ thuật cao<br /> <br /> <br /> <br /> <br /> <br /> Kết hợp mô hình tuần tự và ý tưởng lặp lại của chế bản mẫu<br /> Sản phẩm lõi cho nhưng yêu cầu cơ bản nhất được phát triển<br /> Các chức năng cho những yêu cầu khác được phát triển thêm sau (gia tăng)<br /> Lặp lại quy trình để hoàn thiện dần<br /> <br /> 4<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> <br /> Mô hình xoắn ốc (Spiral Model)<br /> <br /> Mô hình RUP (Rational Unified Process)<br /> <br />  Kết hợp các hoạt động phát triển với các hoạt động quản lý rủi ro để giảm<br /> thiểu và kiểm soát rủi ro<br />  Thích hợp với các hệ thống lớn<br />  Mỗi vòng lặp chu trình phát triển được biểu diễn bởi một vòng gồm 4 hoạt<br /> động chính: Lập kế hoạch; Xác định mục tiêu, các lựa chọn và các ràng<br /> buộc; Đánh giá các lựa chọn và xác định, giải quyết các rủi ro; Phát triển<br /> và kiểm thử<br /> <br /> CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM<br /> Mô hình RUP (Rational Unified Process)<br /> <br /> Mô hình RUP- Rational Unified Process<br /> • Do hãng Rational sản xuất<br /> • Là quy trình phát triển phần mềm hợp nhất Rational (Rational Unified Process hay<br /> RUP) là một quy trình phát triển phần mềm.<br /> <br /> MÔ HÌNH CẢI TIẾN QUY TRÌNH CMMI<br /> (Capability Maturity Model Integration)<br /> <br />  Khởi đầu (inception) Cho một cái nhìn tổng quát về hệ thống sẽ xây<br /> dựng và về dự án sẽ triển khai.<br />  Xác định phạm vi dự án<br />  Chi phí, thời gian<br />  Rủi ro, môi trường<br />  Phác thảo (elaboration) Bao gồm sự phân tích chi tiết hơn về hệ<br /> thống, cả về chức năng lẫn cấu trúc tĩnh.<br />  Phác thảo kiến trúc, yêu cầu<br />  Đánh giá độ rủi ro, các thành phần sử dụng<br />  Xây dựng (construction) Tập trung vào việc thiết kế và thực thi hệ<br /> thống.<br />  Chuyển giao (transition) Nhằm chuyển hệ thống đã xây dựng cho<br /> người dùng cuối<br />  Cài đặt; kiểm thử<br />  Tiếp nhận ý kiến<br />  Bảo trì<br /> 19<br /> <br />  CMMI (Capability Maturity Model® Integration) là một mô<br /> hình quản lý chất lượng cho các tổ chức.<br />  Lịch sử hình thành: Mô hình CMMI được phát triển bởi<br /> Viện Kỹ Nghệ SEI tại trường Đại học Carnegie Mellon<br /> Hoa Kỳ, hiện nay được vận hành và duy trì bởi Viện<br /> CMMI, một đơn vị hoạt động của trường Đại học<br /> Carnegie Mellon.<br /> <br /> 20<br /> <br /> 5<br /> <br />