Quy Trình Phát Triển Phần Mềm: Mô Hình và Phương Pháp Hiện Đại

Tài liệu nghiên cứu Cong nghe phan mem nguyen thi minh tuyen 02 processupdated cuuduongthancong com, tổng hợp lý thuyết và thực hành, cung cấp kiến thức chuyên sâu về .

• Người hướng dẫn: Ian Sommerville
• Chuyên ngành: Công Nghệ Phần Mềm
• Đề tài: Quy trình phần mềm
• Loại tài liệu: Bài giảng

Tóm tắt

I. Tổng Quan Về Quy Trình Phát Triển Phần Mềm Hiện Đại

Quy trình phát triển phần mềm là một tập hợp các hoạt động có cấu trúc nhằm phát triển một hệ thống phần mềm. Các mô hình quy trình như quy trình waterfall và quy trình agile đã được áp dụng rộng rãi. Mỗi mô hình có những ưu điểm và nhược điểm riêng, ảnh hưởng đến cách thức phát triển phần mềm. Việc hiểu rõ các mô hình này giúp các nhà phát triển lựa chọn phương pháp phù hợp nhất cho dự án của họ.

1.1. Định Nghĩa Quy Trình Phát Triển Phần Mềm

Quy trình phát triển phần mềm bao gồm các giai đoạn như đặc tả, thiết kế, cài đặt, kiểm định và cải tiến. Mỗi giai đoạn có vai trò quan trọng trong việc đảm bảo sản phẩm cuối cùng đáp ứng yêu cầu của người dùng.

1.2. Các Mô Hình Quy Trình Phát Triển Phần Mềm

Các mô hình như mô hình thác nước và mô hình phát triển dần dần có cách tiếp cận khác nhau. Mô hình thác nước yêu cầu hoàn thành từng giai đoạn trước khi chuyển sang giai đoạn tiếp theo, trong khi mô hình phát triển dần dần cho phép các giai đoạn diễn ra song song.

II. Vấn Đề và Thách Thức Trong Quy Trình Phát Triển Phần Mềm

Trong quá trình phát triển phần mềm, nhiều thách thức có thể phát sinh, bao gồm việc thay đổi yêu cầu từ khách hàng và sự không chắc chắn trong việc dự đoán các vấn đề kỹ thuật. Những thách thức này có thể ảnh hưởng đến tiến độ và chất lượng sản phẩm. Việc áp dụng các phương pháp linh hoạt có thể giúp giảm thiểu rủi ro và thích ứng với thay đổi.

2.1. Thay Đổi Yêu Cầu Trong Dự Án Phần Mềm

Thay đổi yêu cầu là điều thường gặp trong các dự án phần mềm lớn. Điều này có thể do sự thay đổi trong hoạt động thương mại hoặc công nghệ mới xuất hiện, dẫn đến việc cần phải điều chỉnh quy trình phát triển.

2.2. Rủi Ro Kỹ Thuật Trong Phát Triển Phần Mềm

Rủi ro kỹ thuật có thể bao gồm các vấn đề về hiệu suất, bảo mật và khả năng mở rộng. Việc đánh giá và quản lý rủi ro là rất quan trọng để đảm bảo rằng sản phẩm cuối cùng đáp ứng được các tiêu chuẩn chất lượng.

III. Phương Pháp Phát Triển Phần Mềm Hiện Đại Agile và Waterfall

Hai phương pháp phát triển phần mềm phổ biến hiện nay là quy trình agile và quy trình waterfall. Mỗi phương pháp có những đặc điểm riêng, phù hợp với các loại dự án khác nhau. Quy trình agile tập trung vào sự linh hoạt và phản hồi nhanh từ khách hàng, trong khi quy trình waterfall yêu cầu một kế hoạch chi tiết trước khi bắt đầu.

3.1. Quy Trình Agile Linh Hoạt và Phản Hồi Nhanh

Quy trình agile cho phép các nhóm phát triển điều chỉnh kế hoạch dựa trên phản hồi từ khách hàng. Điều này giúp sản phẩm phát triển theo hướng đáp ứng tốt nhất nhu cầu thực tế của người dùng.

3.2. Quy Trình Waterfall Cấu Trúc Rõ Ràng

Quy trình waterfall yêu cầu các giai đoạn phát triển phải được hoàn thành tuần tự. Mô hình này thích hợp cho các dự án có yêu cầu rõ ràng và ít thay đổi trong suốt quá trình phát triển.

IV. Ứng Dụng Thực Tiễn Của Các Mô Hình Quy Trình Phát Triển Phần Mềm

Việc áp dụng các mô hình quy trình phát triển phần mềm trong thực tiễn đã mang lại nhiều kết quả tích cực. Các tổ chức có thể cải thiện hiệu suất làm việc và chất lượng sản phẩm thông qua việc lựa chọn mô hình phù hợp với nhu cầu của họ. Nghiên cứu cho thấy rằng việc áp dụng quy trình agile có thể giúp giảm thiểu thời gian phát triển và tăng cường sự hài lòng của khách hàng.

4.1. Kết Quả Nghiên Cứu Về Quy Trình Agile

Nghiên cứu cho thấy rằng các tổ chức áp dụng quy trình agile có khả năng thích ứng tốt hơn với thay đổi và cải thiện sự hợp tác giữa các nhóm phát triển. Điều này dẫn đến việc sản phẩm được phát triển nhanh hơn và đáp ứng tốt hơn nhu cầu của khách hàng.

4.2. Ứng Dụng Mô Hình Waterfall Trong Dự Án Lớn

Mô hình waterfall thường được áp dụng trong các dự án lớn, nơi yêu cầu rõ ràng và có thể dự đoán được. Việc sử dụng mô hình này giúp các nhà quản lý dễ dàng theo dõi tiến độ và đảm bảo rằng các giai đoạn phát triển được thực hiện đúng thời hạn.

V. Kết Luận và Tương Lai Của Quy Trình Phát Triển Phần Mềm

Quy trình phát triển phần mềm đang ngày càng trở nên quan trọng trong bối cảnh công nghệ phát triển nhanh chóng. Các mô hình như agile và waterfall sẽ tiếp tục được cải tiến để đáp ứng nhu cầu ngày càng cao của thị trường. Tương lai của quy trình phát triển phần mềm sẽ tập trung vào việc tích hợp công nghệ mới và cải thiện khả năng tương tác giữa các nhóm phát triển.

5.1. Xu Hướng Tương Lai Trong Phát Triển Phần Mềm

Xu hướng phát triển phần mềm sẽ tiếp tục hướng tới việc sử dụng trí tuệ nhân tạo và tự động hóa để tối ưu hóa quy trình. Điều này sẽ giúp giảm thiểu thời gian và chi phí phát triển, đồng thời nâng cao chất lượng sản phẩm.

5.2. Tích Hợp Công Nghệ Mới Vào Quy Trình Phát Triển

Việc tích hợp công nghệ mới như DevOps và CI/CD sẽ giúp cải thiện quy trình phát triển phần mềm. Những công nghệ này cho phép các nhóm phát triển làm việc hiệu quả hơn và nhanh chóng đưa sản phẩm ra thị trường.

Trích đoạn nội dung tài liệu

Nhập môn Công nghệ phần mềm Tuần 2-3: Quy trình phần mềm Nội dung của slide được dịch và phát triển dựa vào bộ slide của Ian Sommerville Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP Quy trình phần mềm £ Quy trình phần mềm (software process) là một tập có cấu trúc các hoạt động cần thiết để phát triển một hệ thống phần mềm. £ Có nhiều quy trình phần mềm khác nhau. Tất cả đều bao gồm những hoạt động: p Đặc tả: Định nghĩa hệ thống làm gì; p Thiết kế và cài đặt: Định nghĩa tổ chức của hệ thống và cài đặt hệ thống; p Kiểm định: Kiểm tra rằng hệ thống đáp ứng được mong muốn của người dùng; p Cải tiến: thay đổi hệ thống để đáp ứng sự thay đổi yêu cầu người dùng. £ Mô hình quy trình phần mềm (software process model) là biểu diễn trừu tượng của một quy trình.

Nó biểu diễn mô tả của quy trình từ một góc nhìn nào đó. 4 Mô tả quy trình phần mềm £ Khi mô tả về quy trình, ta thường nói về p các hoạt động trong những quy trình này. Ví dụ, đặc tả mô hình dữ liệu, thiết kế giao diện người dùng, … ; p và thứ tự của các hoạt động này. £ Các mô tả quy trình có thể gồm: p Sản phẩm: kết quả đầu ra của một hoạt động; p Vai trò: phản ánh trách nhiệm của những người tham gia vào quy trình; p Điều kiện trước và điều kiện sau (Pre- and post- conditions): là những điều kiện phải đảm bảo trước và sau khi một hoạt động được thực hiện hay một sản phẩm được tạo ra.

5 Quy trình hoạch định sẵn và quy trình linh hoạt £ Các quy trình hoạch định sẵn (plan-driven process) là các quy trình mà trong đó tất cả các hoạt động được lên kế hoạch trước và tiến độ thực hiện được đánh giá dựa vào kế hoạch này. £ Trong các quy trình linh hoạt (agile process), kế hoạch được phát triển dần dần và dễ dàng thay đổi quy trình để đáp ứng sự thay đổi yêu cầu của khách hàng. £ Hầu hết các quy trình thực tế đều gồm những phần tử của cả hai phương pháp này. £ Không có quy trình phần mềm đúng hay sai! 6 Các mô hình quy trình phần mềm £ Mô hình thác nước (waterfall model) p Mô hình hoạch định sẵn.

Các pha đặc tả và phát triển phân biệt và tách rời nhau. £ Mô hình phát triển dần dần (incremental development) p Các pha đặc tả, phát triển và thẩm định đan xen nhau. Có thể là mô hình hoạch định sẵn, có thể là mô hình linh hoạt. £ CNPM theo hướng tái sử dụng (reuse-oriented software engineering) p Hệ thống được xây dựng từ những component có sẵn.

Có thể là hoạch định sẵn, có thể là linh hoạt. £ Thực tế, những hệ thống lớn được phát triển bằng cách sử dụng quy trình tạo ra bằng cách kết hợp các phần tử từ các mô hình này. 7 Mô hình thác nước 8 Mô hình thác nước Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance 9 Ưu điểm £ Quy trình rõ ràng è người quản lý dễ dàng theo dõi tiến độ công việc. £ Mô hình này được sử dụng trong các hệ thống lớn trong đó hệ thống được phát triển tại nhiều địa điểm khác nhau p Vì là quy trình hoạch định sẵn è giúp cho việc phối hợp trong công việc dễ dàng hơn.

10 Nhược điểm £ Khó khăn trong việc thích nghi với sự thay đổi sau khi quy trình đã vào guồng. p Về nguyên tắc, pha này phải hoàn thành trước khi bắt đầu pha tiếp theo. £ Không linh động trong việc phân chia dự án thành những giai đoạn tách biệt èkhó khăn trong việc đáp ứng sự thay đổi yêu cầu người dùng p Mô hình này chỉ hợp lý khi yêu cầu được hiểu rõ và ít thay đổi trong suốt quá trình phát triển; p Hệ thống thương mại thường có yêu cầu không ổn định è mô hình thác nước không phù hợp. 11 Biến thể của mô hình thác nước £ Phát triển hệ thống theo kiểu hình thức p Sử dụng mô hình toán học để đặc tả hệ thống.

p Sử dụng các chuyển đổi toán học để chuyển các đặc tả thành chương trình chạy được è lý do thuyết phục để đảm bảo rằng một chương trình được phát sinh nhất quán với đặc tả đưa ra. £ Những quy trình phát triển hình thức (sử dụng B-method chẳng hạn) phù hợp với việc phát triển hệ thống có độ tin cậy cao, độ an toàn cao và tính bảo mật cao. p Ví dụ: đường metro 14 ở Paris, hệ thống tàu tự động ở sân bay CDG, Paris, etc. 12 Phát triển dần dần Concurrent activities Initial Specification version Outline Intermediate description Development versions Final Validation version 13 Đặc điểm £ Dựa vào ý tưởng của việc phát triển phiên bản đầu tiên, lấy ý kiến khách hàng và cải tiến nó cho đến khi sản phẩm hoàn thiện.

£ Các pha đặc tả, phát triển và thẩm định đan xen nhau. £ Lấy phản hồi nhanh từ khách hàng 14 Ưu điểm £ Giảm được chi phí khi đáp ứng sự thay đổi yêu cầu của khách hàng £ Dễ dàng trong việc lấy phản hồi từ khách hàng. £ Phân phối và triển khai phần mềm đến khách hàng nhanh hơn. 15 Nhược điểm £ Quy trình không rõ ràng.

£ Cấu trúc hệ thống có xu hướng bị giảm đi vì những phần mới của hệ thống được thêm vào. 16 CNPM theo hướng tái sử dụng Requirements Component Requirements System design specification analysis modification with reuse Development System and integration validation 17 Đặc điểm £ Dựa vào việc tái sử dụng một cách có hệ thống p Hệ thống được tích hợp từ những thành phần có sẵn hoặc từ các hệ thống COTS (Commercial-off-the-shelf). £ Các giai đoạn của quy trình p Phân tích component; p Bổ sung yêu cầu; p Thiết kế hệ thống với việc tái sử dụng; p Phát triển và tích hợp. £ Hiện nay, việc tái sử dụng là phương pháp chuẩn cho việc xây dựng nhiều hệ thống thương mại.

18 Các loại component £ Các dịch vụ Web (Web service): được phát triển theo các chuẩn dịch vụ và có sẵn để triệu gọi từ xa. £ Các tập các đối tượng được phát triển như một gói (package) tích hợp trong các framework như .NET hay J2EE. £ Những hệ thống phần mềm độc lập (COTS): được cấu hình để sử dụng cho một môi trường cụ thể. 19 Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP Các hoạt động của quy trình £ 4 hoạt động quy trình cơ bản 1.

Thẩm định và 4. Cải tiến £ Các hoạt đông này được tổ chức khác nhau trong các quy trình phát triển khác nhau p Trong mô hình thác nước: tổ chức tuần tự. p Trong mô hình phát triển dần dần: tổ chức đan xen. Đặc tả phần mềm £ Là quy trình thiết lập danh sách các dịch vụ được yêu cầu và các ràng buộc đối với hoạt động của hệ thống và việc phát triển hệ thống.

£ Quy trình công nghệ yêu cầu (requirements engineering process) p Nghiên cứu khả thi (Feasibility study) p Thu thập và phân tích yêu cầu (Requirements elicitation and analysis) p Đặc tả yêu cầu (Requirements specification) p Thẩm định yêu cầu (Requirements validation) 22 Quy trình công nghệ yêu cầu Requirements Feasibility elicitation and study analysis Requirements specification Feasibility Requirements report validation System models User and system requirements Requirements document 23 2. Thiết kế và cài đặt phần mềm £ Là quy trình chuyển đổi các đặc tả thành hệ thống thực thi được. £ Thiết kế phần mềm (software design) p Thiết kế một cấu trúc phần mềm để hiện thực hóa đặc tả; £ Cài đặt (implementation) p Dịch cấu trúc đó thành chương trình thực thi được. £ Các hoạt động của pha thiết kế và cài đặt thường liên quan đến nhau hoặc có thể đan xen nhau.

24 Một mô hình chung của quy trình thiết kế Design inputs Platform Requirements Data information specification description Design activities Architectural Interface Component design design design Database design Design outputs System Database Interface Component architecture specification specification specification 25 Các hoạt động thiết kế £ Thiết kế kiến trúc (Architectural design) p Nhận diện cấu trúc toàn hệ thống, những component chính, mối quan hệ giữa các component và chúng được phân tán thế nào. £ Thiết kế giao diện (Interface design) p Định nghĩa giao diện giữa các component hệ thống. £ Thiết kế component (Component design) p Xem xét từng component hệ thống và thiết kế xem nó hoạt động thế nào. £ Thiết kế CSDL (Database design) p Thiết kế các cấu trúc dữ liệu hệ thống và cách chúng được biểu diễn trong CSDL.

Thẩm định phần mềm £ Kiểm định (verification) và thẩm định (validation) (V & V) nhằm mục đích chỉ ra rằng p Một hệ thống tuân theo đặc tả của nó; p Thỏa mãn yêu cầu của khách hàng hệ thống. £ Bao gồm các quy trình kiểm tra, duyệt (review) và kiểm thử hệ thống (system testing). £ Kiểm thử hệ thống bao gồm việc chạy hệ thống sử dụng các test case được viết ra dựa vào đặc tả. £ Kiểm thử (Testing) là hoạt động V&V thường được sử dụng nhất.

27 Các giai đoạn kiểm thử phần mềm Component Acceptance System testing testing testing 28 Các giai đoạn kiểm thử phần mềm £ Kiểm thử trong khi phát triển(Development hoặc component testing) p Các component được kiểm thử một cách độc lập; p Các component có thể là hàm hoặc đối tượng hoặc nhóm đồng nhất các thực thể. £ Kiểm thử hệ thống p Kiểm thử toàn bộ hệ thống. £ Kiểm thử người dùng p Kiểm thử với dữ liệu của khách hàng để kiểm tra rằng hệ thống đáp ứng được yêu cầu của khách hàng. 29 Các pha kiểm thử trong quy trình hoạch định sẵn Requirements System System Detailed specification specification design design System Sub-system Module and Acceptance unit code integration integration test plan and test test plan test plan Acceptance System Sub-system Service test integration test integration test 30 4.

Cải tiến phần mềm £ Phần mềm vốn dĩ linh hoạt và có thể thay đổi. £ Yêu cầu thay đổi do hoạt động thương mại thay đổi è phần mềm hỗ trợ cũng phải cải tiến và thay đổi theo. £ Ranh giới giữa phát triển phần mềm và cải tiến phần mềm ngày càng mờ nhạt đi. Ngày càng ít phần mềm được phát triển hoàn toàn mới.