Mở đầu Trình bày lý do chọn đề tài, mục tiêu nghiên cứu, đối tượng nghiên cứu, phạm vi nghiên cứu, những đóng góp của khóa luận. Chương 2: Cơ sở lý thuyết Bao gồm nội dung liên quan đến các khái niệm, công nghệ, mô hình mà nhóm tác giả đã tìm hiểu trong quá trình thực hiện khóa luận. Những kiến thức được trình bày trong chương này là cơ sở đề thực hiện thiết kế và triển khai hệ thống DevSecOps. Ngoài ra, tại chương này còn mô tả về các công cụ kiểm thử bảo mật dé phát hiện các van đề về bao mật và bảo đảm an toàn thông tin cho ứng dụng web.
Chương 3: Phân tích và thiết kế mô hình Trình bày ý tưởng của nhóm tác giả khi thiết kế mô hình. Bao gồm mô hình của hệ thống, Jenkins pipeline để thực hiện CI/CD và ứng dung web quản lý bảo mật tập trung. Giải thích các thành phần trong hệ thống, mô tả chức năng của chúng trong mô hình, liệt kê các bước cần thiết đề triển khai mô hình. Chương 4: Đánh giá kết quả Đánh giá ưu nhược diém của mô hình trong kịch bản thử nghiệm.
Chương 5: Kết luận và hướng phát triển Tổng kết quá trình thực hiện khóa luận và dé xuất các hướng phát triển dé tài trong tương lai. CƠ SỞ LY THUYET 2. Các mô hình phát triển phan mềm 2. Waterfall Mô hình Waterfall được Winston W.
Royce đề xuất vào năm 1970 dé mô tả một quy trình phát triển phần mềm tuần tự [4], trong đó các giai đoạn trong quá trình phát triển phần mềm được thực hiện tuần tự từ trên xuống dưới (tương tự như dòng chảy của thác nước ngày càng chảy xuống). Mô hình xác định một số giai đoạn liên tiếp trong quy trình phát triển phần mềm phải được hoàn thành lần lượt và chỉ chuyên sang giai đoạn tiếp theo khi giai đoạn trước của nó được hoàn thành hoàn toàn. Vì lý do này, mô hình Waterfall mang tính chất đệ quy, trong đó mỗi giai đoạn có thể được lặp lại liên tục cho đến khi hoàn thiện.1 minh họa các giai đoạn khác nhau cua mô hình Waterfall.1: Các giai đoạn của mô hình Waterfall - Giai đoạn 1 (Requirements): Thường được gọi là Software Requirements Specification (SRS). Đây là một mô tả đầy đủ và toàn diện về các yêu cầu của phần mềm sẽ được phát triển.
Nó đòi hỏi các nhà phân tích hệ thống và phân tích nghiệp vụ phải xác định cả các yêu cầu chức năng và phi chức năng. Thông thường, các yêu cầu chức năng được xác định bang các trường hợp liên quan đến tương tác của người dùng với phần mềm. Các yêu cầu chức năng bao gồm như mục đích, phạm vi, quan điểm, chức năng, thuộc tính phần mềm; đặc điểm người dùng, đặc tả chức năng, yêu cầu giao diện và yêu cầu về cơ sở dit liệu. Ngược lại, các yêu cầu phi chức năng đề cập đến các tiêu chí, ràng buộc, giới hạn và các yêu cầu khác nhau được đặt ra đối với việc thiết kế và vận hành phần mềm.
Nó bao gồm các đặc tính như độ tin cậy, khả năng mở rộng, khả năng kiểm thử, tính sẵn sàng, khả năng bảo trì, hiệu suất và tiêu chuẩn chất lượng. Giai đoạn 2 (Design): La quá trình lập kế hoạch và giải quyết các van đề cho một giải pháp phần mềm. Nó yêu cầu các nhà phát triển phần mềm và thiết kế phần mềm xác định kế hoạch cho một giải pháp bao gồm thiết kế thuật toán, thiết kế kiến trúc phan mềm, mô hình khái niệm cơ sở dit liệu và thiết kế sơ đồ logic, thiết kế ý tưởng, thiết kế giao diện người dùng, định nghĩa cấu trúc dữ liệu. Giai đoạn 3 (Implementation): Day là quá trình chuyền đổi toàn bộ các yêu cầu (giai đoạn 1) và bản thiết kế (giai đoạn 2) thành môi trường sản xuất.
Giai đoạn 4 (Verification): Đây là một quá trình dé kiểm tra xem một giải pháp phần mềm có đáp ứng các yêu cầu, thông số kỹ thuật ban đầu và có đạt được mục đích dự kiến hay không. Giai đoạn này gồm hai quá trình là verification va validation. Verification là quá trình đánh giá phần mềm đề xác định xem các sản phẩm của một giai đoạn phát triển nhất định có thỏa mãn các điều kiện đặt ra khi bắt đầu giai đoạn đó hay không. Trong khi validation là quá trình đánh giá phần mềm trong quy trình phát triển hoặc khi kết thúc quy trình phát triển dé xác định xem nó có thỏa mãn các yêu cầu quy định hay không [5].
Hơn nữa, giai đoạn này là đầu ra đề thực hiện gỡ lỗi, trong đó các lỗi và những trục trặc hệ thong được tim thấy, sửa chữa và tinh chỉnh cho phù hợp. - Giai đoạn 5 (Maintenance): Đây là quá trình sửa đổi giải pháp phan mềm sau khi phân phối và triển khai dé tinh chỉnh đầu ra, sửa lỗi, cải thiện hiệu suất và chất lượng. Các hoạt động bảo trì bổ sung có thể được thực hiện trong giai đoạn này bao gồm điều chỉnh phần mềm phù hợp với môi trường của nó, đáp ứng các yêu cầu mới của người dùng và tăng độ tin cậy của phần mềm [6]. Agile Trong các mô hình phát triển phần mềm truyền thống (vi dụ như mô hình Waterfall), các nhóm phải làm việc với một kế hoạch chỉ tiết và có một danh sách đầy đủ các nhiệm vụ phải hoàn thành trong vài tháng tới hoặc trong toàn bộ vòng đời của sản phẩm.
Phương pháp làm việc này hoàn toàn phụ thuộc vào việc phân tích yêu cau và lập kế hoạch một cách can thận ở đầu chu kỳ phát triển phần mềm. Bat kỳ thay đổi nào được đưa vào sẽ phải trải qua một quá trình ưu tiên quản lý kiểm soát thay đổi nghiêm ngặt. Mô hình Agile dựa trên cách tiếp cận lặp đi lặp lại quy trình phát triển. Thay vì lập kế hoạch chuyên sâu ngay khi bắt đầu dự án, các phương pháp Agile san sàng đáp ứng các yêu cầu thay đôi theo thời gian và khuyến khích phản hồi liên tục từ người dùng cuối.
Mục tiêu của mỗi lần lặp là tạo ra một sản phẩm hoạt động tốt. Mô hình Agile đề cập đến bat kỳ quy trình nào phù hợp với các khái niệm trong Tuyên ngôn Agile? được xuất bản vào năm 2001. Chu kỳ phát trién phan mềm của mô hình Agile được mô tả trong hình 2. Jeffries, "Manifesto for Agile Software Development".
URL: https://agilemanifesto.2: Các bước trong chu kỳ phát triển phần mềm của mô hình Agile Một số thuận lợi khi sử dung mô hình Agile: Các thay đôi trong quy trình phát trién phan mềm được chấp nhận. Mô hình Agile có lợi cho các dự án mà mục tiêu cuối cùng không được xác định rõ ràng. Khi dự án tiễn triển, các mục tiêu sẽ trở nên rõ ràng và nhóm phát triển có thé thích ứng. Phân phối nhanh hơn.
Tương tác nhóm làm việc mạnh mẽ. Khách hàng được lắng nghe: Khách hàng có nhiều cơ hội để xem công việc được giao, chia sẻ ý kiến đóng góp của họ. Những ý kiến của khách hàng có nhiêu tác động đên sản phâm cuôi cùng. Mặc dù mô hình Agile rất linh hoạt, tuy nhiên nó cũng đi kèm với một vài sự đánh đôi: Khó thiết lập ngày ban giao sản phẩm một cách chắc chăn, chuan xác.
Đội ngũ nhân viên phải có kiến thức: Các thành viên trong nhóm phải có kỹ năng cao trong nhiều lĩnh vực khác nhau và phải hiểu được phương pháp Agile. Cam kết về thời gian từ các nhà phát triển: Cần có sự tham gia và cộng tác tích cực trong suốt quy trình Agile. Việc này tốn nhiều thời gian hơn so với cách tiép cận truyên thông. Một số phương pháp được sử dụng để triển khai Agile như: Scrum, Kanban,.
Trong số đó, Scrum được sử dụng phổ biến nhất. Scrum là một mô hình phát triển dựa trên cách tiếp cận lặp đi lặp lại quy trình phát trién phan mềm và thường được sử dụng dé quản lý quy trình phát triển phan mềm phức tạp. Thuật ngữ Sprint trong mô hình Scrum thể hiện cho các công việc cần được thực hiện trong khoảng thời gian từ một đến bốn tuần. Dựa vào Sprint sẽ giúp cho nhóm phát triển phân phối phần mềm đều đặn.
Vào cuối mỗi Sprint, các bên liên quan và các thành viên trong nhóm phát triển tiến hành họp dé lập kế hoạch cho các bước tiếp theo. Chu kỳ phát triển phan mềm của mô hình Scrum được minh họa trong hình 2. Daily Scrum Je điệp SPRINT 1-4 WEEKS Pn Sprint =) ) ; = Review o—| Sprint Retrospective Product Sprint Planning Sprint Finished Backlog Meeting Backlog Work Hình 2.3: Chu ky phát trién phan mềm của mô hình Scrum Một số thuận lợi khi áp dụng mô hình Scrum: e Minh bạchhơn: Với các cuộc họp trực tiếp hàng ngày, cả nhóm biết được ai đang lam gi, nắm bắt các van dé đã được xác định trước. Từ đó, giúp cải thiện khả năng giao tiếp và cho phép nhóm xử lý các van đề ngay lập tức.
10 e Tăng trách nhiệm giải trình của nhóm: Không có người quản lý dự án, thay vào đó, nhóm quyết định những công việc họ có thể hoàn thành trong mỗi Sprint và làm việc cùng nhau, có trách nhiệm giải trình. e Dễ dàng điều chỉnh các thay đổi: Với thời gian kéo dài trong mỗi Sprint ngắn và phản hồi liên tục, việc điều chỉnh các thay đôi trở nên dễ dàng hơn. e _ Tiết kiệm chi phi: Các thành viên trao đồi thông tin liên tục đảm bảo nhóm nhận thức được tất cả các vấn đề và thực hiện các thay đôi sớm hơn, từ đó giúp giảm chỉ phí và tăng chất lượng. - Một số khó khăn khi áp dụng mô hình Scrum: e Nhóm cần phải nam rõ các nguyên tắc Scrum, cũng như cần cam kết thực hiện các cuộc họp hàng ngày và không được rời khỏi dự án trong suốt quá trình phát triển.
e Scrum Master sai có thé làm hỏng mọi thứ: Scrum Master rất khác với một người quản lý dự án. Scrum Master không có quyên đối với nhóm, vì vậy người đó phải tin tưởng vào nhóm đề hoàn thành công aA viéc. e Các nhiệm vụ được xác định không rõ rang có thé dẫn đến chi phí và thời gian của dự án không chính xác. Mô hình CI/CD 2.
Continuous Integration - CI 2. Tổng quan Tích hợp liên tục (Continuous Integration - CI) là phương pháp phát triển phần mềm được thiết lập rộng rãi [7], trong đó các thành viên của nhóm phát triển phải thường xuyên tích hợp các thay đổi trong mã nguồn của họ vào một kho lưu trữ trung tâm (central repository), thường thì mỗi người tích hợp ít nhất một lần trong ngày - dẫn đến nhiều lần tích hợp mỗi ngày.