Software Development Life Cycle (SDLC) là một quy trình được ngành công nghiệp phần mềm sử dụng để thiết kế, phát triển và kiểm thử phần mềm chất lượng cao. SDLC nhằm mục đích tạo ra một phần mềm chất lượng cao nhằm đáp ứng hoặc vượt quá mong đợi của khách hàng, hoàn thành trong thời gian và chi phí ước tính.

SDLC là từ viết tắt của Software Development Life Cycle.
Nó còn được gọi là Software Development Process.
SDLC là một khuôn khổ xác định các tác vụ được thực hiện ở mỗi bước trong quy trình phát triển phần mềm.
ISO/IEC 12207 là tiêu chuẩn quốc tế về các quy trình vòng đời của phần mềm, nhằm mục đích trở thành tiêu chuẩn xác định tất cả các nhiệm vụ cần thiết để phát triển và bảo trì phần mềm.

SDLC là gì?

SDLC là một quá trình được tuân theo cho một dự án phần mềm, trong một tổ chức phần mềm. Nó bao gồm một kế hoạch chi tiết mô tả cách phát triển, bảo trì, thay thế và thay đổi hoặc nâng cao phần mềm cụ thể. Vòng đời xác định một phương pháp để cải thiện chất lượng của phần mềm và quá trình phát triển tổng thể.

Hình dưới đây là một biểu diễn đồ họa của các giai đoạn khác nhau của một SDLC điển hình. Software Development Life Cycle điển hình bao gồm các giai đoạn sau:

Giai đoạn 1: Lập kế hoạch và Phân tích yêu cầu

Phân tích yêu cầu là giai đoạn cơ bản và quan trọng nhất trong SDLC. Nó được thực hiện bởi các thành viên cấp cao của nhóm với đầu vào từ khách hàng, bộ phận bán hàng, khảo sát thị trường và các chuyên gia lĩnh vực trong ngành. Thông tin này sau đó được sử dụng để lập kế hoạch cơ bản tiếp cận dự án và tiến hành nghiên cứu tính khả thi của sản phẩm trong các lĩnh vực kinh tế, vận hành và kỹ thuật.

Việc lập kế hoạch cho các yêu cầu đảm bảo chất lượng và xác định các rủi ro liên quan đến dự án cũng được thực hiện trong giai đoạn lập kế hoạch.

Giai đoạn 2: Xác định yêu cầu

Sau khi phân tích yêu cầu được thực hiện, bước tiếp theo là xác định rõ ràng và lập thành văn bản các yêu cầu sản phẩm và được khách hàng hoặc các nhà phân tích thị trường chấp thuận. Điều này được thực hiện thông qua tài liệu SRS (Đặc tả yêu cầu phần mềm) bao gồm tất cả các yêu cầu sản phẩm để được thiết kế và phát triển trong suốt vòng đời của dự án.

Giai đoạn 3: Thiết kế Kiến trúc Sản phẩm

SRS là tài liệu tham khảo cho các kiến trúc sư sản phẩm để đưa ra kiến trúc tốt nhất cho sản phẩm được phát triển. Dựa trên các yêu cầu quy định trong SRS, thường nhiều hơn một phương pháp thiết kế cho kiến trúc sản phẩm được đề xuất và ghi lại trong tài liệu DDS - Design Document Specification.

DDS này được xem xét bởi tất cả các bên liên quan quan trọng và dựa trên các thông số khác nhau như đánh giá rủi ro, độ bền của sản phẩm, mô-đun thiết kế, hạn chế về ngân sách và thời gian, phương pháp thiết kế tốt nhất được lựa chọn cho sản phẩm.

Cách tiếp cận thiết kế xác định rõ ràng tất cả các mô-đun kiến trúc của sản phẩm cùng với giao tiếp và biểu diễn luồng dữ liệu của nó với các mô-đun bên ngoài và bên thứ ba (nếu có). Thiết kế bên trong của tất cả các mô-đun của kiến trúc được đề xuất nên được xác định rõ ràng với mức tối thiểu của các chi tiết trong DDS.

Giai đoạn 4: Xây dựng hoặc phát triển sản phẩm

Trong giai đoạn này của SDLC, quá trình phát triển thực tế bắt đầu và sản phẩm được xây dựng. Mã lập trình được tạo theo DDS trong giai đoạn này. Nếu thiết kế được thực hiện một cách chi tiết và có tổ chức, việc tạo mã có thể được thực hiện mà không gặp nhiều rắc rối.

Các nhà phát triển phải tuân theo các nguyên tắc mã hóa do tổ chức của họ xác định và các công cụ lập trình như trình biên dịch, trình thông dịch, trình gỡ lỗi, v.v. được sử dụng để tạo mã. Các ngôn ngữ lập trình cấp cao khác nhau như C, C ++, Pascal, Java và PHP được được sử dụng để viết mã. Ngôn ngữ lập trình được chọn tương ứng với loại phần mềm đang được phát triển.

Giai đoạn 5: Kiểm thử sản phẩm

Giai đoạn này thường là một tập hợp con của tất cả các giai đoạn như trong các mô hình SDLC hiện đại, các hoạt động kiểm tra hầu hết liên quan đến tất cả các giai đoạn của SDLC. , cố định và thử nghiệm lại, cho đến khi sản phẩm đạt được các tiêu chuẩn chất lượng được xác định trong SRS.

Giai đoạn 6: Triển khai trên thị trường và bảo trì

Sau khi sản phẩm được thử nghiệm và sẵn sàng triển khai, sản phẩm sẽ được phát hành chính thức tại thị trường thích hợp. Đôi khi, việc triển khai sản phẩm diễn ra theo từng giai đoạn theo chiến lược kinh doanh của tổ chức đó. Sản phẩm trước tiên có thể được phát hành trong một phân khúc hạn chế và được thử nghiệm trong hoạt động kinh doanh thực tế môi trường (UAT- User acceptance testing).

Sau đó, dựa trên phản hồi, sản phẩm có thể được phát hành như hiện tại hoặc với các cải tiến được đề xuất trong phân khúc thị trường mục tiêu. Sau khi sản phẩm được phát hành trên thị trường, việc bảo trì sản phẩm được thực hiện cho cơ sở khách hàng hiện tại.

Mô hình SDLC

Có nhiều mô hình vòng đời phát triển phần mềm khác nhau được xác định và thiết kế được tuân theo trong quá trình phát triển phần mềm. Các mô hình này còn được gọi là Software Development Process Models. Mỗi mô hình quy trình tuân theo một loạt các bước duy nhất cho loại của nó để đảm bảo thành công trong quy trình phát triển phần mềm.

Sau đây là các mô hình SDLC quan trọng và phổ biến nhất trong ngành:

Waterfall Model
Iterative Model
Spiral Model
V-Model
Big Bang Model
Agile Model

1. Waterfall Model

Mô hình thác nước là mô hình quy trình đầu tiên được giới thiệu. Nó còn được gọi là mô hình vòng đời tuần tự tuyến tính. Nó rất đơn giản để hiểu và sử dụng. Trong mô hình thác nước, mỗi giai đoạn phải được hoàn thành trước khi giai đoạn tiếp theo có thể bắt đầu và không có sự chồng chéo trong các giai đoạn.

Mô hình thác nước là cách tiếp cận SDLC sớm nhất được sử dụng để phát triển phần mềm.

Mô hình thác nước minh họa quá trình phát triển phần mềm theo một dòng tuần tự tuyến tính. Điều này có nghĩa là bất kỳ giai đoạn nào trong quy trình phát triển chỉ bắt đầu nếu giai đoạn trước đó hoàn thành. Trong mô hình thác nước này, các giai đoạn không chồng chéo lên nhau.

a. Waterfall Model - Thiết kế

Phương pháp tiếp cận thác nước là mô hình SDLC đầu tiên được sử dụng rộng rãi trong Kỹ thuật phần mềm để đảm bảo thành công của dự án. Trong cách tiếp cận "Thác nước", toàn bộ quá trình phát triển phần mềm được chia thành các giai đoạn riêng biệt. Trong mô hình thác nước này, thông thường, kết quả của một phase đóng vai trò là đầu vào cho giai đoạn tiếp theo một cách tuần tự.

Hình minh họa sau đây là đại diện của các giai đoạn khác nhau của mô hình thác nước. Các giai đoạn tuần tự trong mô hình thác nước là:

Thu thập và phân tích yêu cầu: Tất cả các yêu cầu có thể có của hệ thống được phát triển đều được ghi lại trong giai đoạn này và được ghi lại trong tài liệu đặc tả yêu cầu.
Thiết kế hệ thống: Các đặc điểm kỹ thuật yêu cầu từ giai đoạn đầu tiên được nghiên cứu trong giai đoạn này và thiết kế hệ thống được chuẩn bị. Thiết kế hệ thống này giúp xác định các yêu cầu phần cứng và hệ thống cũng như giúp xác định kiến trúc hệ thống tổng thể.
Implement: Với đầu vào từ thiết kế hệ thống, hệ thống được phát triển đầu tiên trong các chương trình nhỏ gọi là đơn vị, được tích hợp trong giai đoạn tiếp theo. Mỗi đơn vị được phát triển và kiểm tra chức năng của nó, được gọi là kiểm thử đơn vị.
Tích hợp và Kiểm thử: Tất cả các đơn vị được phát triển trong giai đoạn triển khai đều được tích hợp vào một hệ thống sau khi kiểm tra từng đơn vị. Sau khi tích hợp, toàn bộ hệ thống được kiểm tra xem có lỗi và hỏng hóc nào không.
Triển khai hệ thống: Sau khi thử nghiệm chức năng và phi chức năng được thực hiện; sản phẩm được triển khai trong môi trường khách hàng hoặc tung ra thị trường.
Bảo trì: Có một số vấn đề xảy ra trong môi trường khách hàng. Để khắc phục những vấn đề đó, các bản vá lỗi sẽ được phát hành. Ngoài ra, để cải tiến sản phẩm, một số phiên bản tốt hơn được phát hành. Bảo trì được thực hiện để cung cấp những thay đổi này trong môi trường khách hàng.

Tất cả các giai đoạn này được xếp tầng với nhau, trong đó tiến trình được xem là chảy đều đặn xuống dưới (giống như thác nước) qua các giai đoạn. Giai đoạn tiếp theo chỉ được bắt đầu sau khi đạt được tập hợp mục tiêu đã xác định cho giai đoạn trước và nó được ký kết, vì vậy có tên là "Mô hình thác nước". Trong mô hình này, các phase không trùng lặp.

b. Waterfall Model - Ứng dụng

Mỗi phần mềm được phát triển đều khác nhau và đòi hỏi phải tuân theo một cách tiếp cận SDLC phù hợp dựa trên các yếu tố bên trong và bên ngoài. Một số tình huống mà việc sử dụng mô hình thác nước là thích hợp nhất là:

Các yêu cầu được ghi chép rất đầy đủ, rõ ràng và cố định.
Định nghĩa sản phẩm là ổn định.
Công nghệ được hiểu và không năng động.
Không có yêu cầu mơ hồ.
Có sẵn các nguồn lực dồi dào với kiến thức chuyên môn cần thiết để hỗ trợ sản phẩm.

2. Iterative Model

Trong mô hình lặp lại, quy trình lặp lại bắt đầu bằng việc triển khai đơn giản một tập hợp nhỏ các yêu cầu phần mềm và cải tiến lặp đi lặp lại các phiên bản đang phát triển cho đến khi hệ thống hoàn chỉnh được triển khai và sẵn sàng được triển khai.

Mô hình vòng đời lặp đi lặp lại không cố gắng bắt đầu với đặc điểm kỹ thuật đầy đủ của các yêu cầu. Thay vào đó, quá trình phát triển bắt đầu bằng cách chỉ định và triển khai chỉ một phần của phần mềm, sau đó được xem xét để xác định các yêu cầu tiếp theo. Quá trình này sau đó được lặp lại, tạo ra một phiên bản mới của phần mềm vào cuối mỗi lần lặp lại của mô hình.

a. Iterative Model - Thiết kế

Quá trình lặp đi lặp lại bắt đầu với việc triển khai đơn giản một tập hợp con các yêu cầu phần mềm và cải tiến lặp đi lặp lại các phiên bản đang phát triển cho đến khi triển khai toàn bộ hệ thống. Ở mỗi lần lặp lại, các sửa đổi thiết kế được thực hiện và các khả năng chức năng mới được thêm vào. Ý tưởng cơ bản đằng sau phương pháp này là phát triển một hệ thống thông qua các chu kỳ lặp lại (lặp đi lặp lại) và theo các phần nhỏ hơn tại một thời điểm (tăng dần).

Hình minh họa sau đây là đại diện của mô hình lặp lại và tăng dần: Phát triển lặp đi lặp lại và phát triển tăng dần là sự kết hợp của cả thiết kế lặp đi lặp lại hoặc phương pháp lặp lại và mô hình xây dựng tăng dần để phát triển. "Trong quá trình phát triển phần mềm, nhiều lần lặp lại của chu trình phát triển phần mềm có thể đang diễn ra cùng một lúc". Quá trình này có thể được mô tả như một phương pháp tiếp cận "mua lại tiến hóa" hoặc "xây dựng gia tăng". "

Trong mô hình gia tăng này, toàn bộ yêu cầu được chia thành các bản dựng khác nhau. Trong mỗi lần lặp lại, mô-đun phát triển sẽ trải qua các giai đoạn yêu cầu, thiết kế, triển khai và thử nghiệm. Mỗi bản phát hành tiếp theo của mô-đun sẽ bổ sung chức năng cho bản phát hành trước. Quá trình tiếp tục cho đến hệ thống hoàn chỉnh đã sẵn sàng theo yêu cầu.

Chìa khóa để sử dụng thành công vòng đời phát triển phần mềm lặp đi lặp lại là xác nhận nghiêm ngặt các yêu cầu và xác minh & kiểm tra từng phiên bản của phần mềm theo các yêu cầu đó trong mỗi chu kỳ của mô hình. Khi phần mềm phát triển qua các chu kỳ liên tiếp, các thử nghiệm phải được lặp lại và mở rộng để xác minh từng phiên bản của phần mềm.

b. Iterative Model - Ứng dụng

Giống như các mô hình SDLC khác, phát triển lặp đi lặp lại và tăng dần có một số ứng dụng cụ thể trong ngành công nghiệp phần mềm. Mô hình này thường được sử dụng nhất trong các tình huống sau:

Các yêu cầu của hệ thống hoàn chỉnh được xác định và hiểu rõ ràng.
Các yêu cầu chính phải được xác định. Tuy nhiên, một số chức năng hoặc các cải tiến được yêu cầu có thể phát triển theo thời gian.
Có một thời gian để hạn chế thị trường.
Một công nghệ mới đang được sử dụng và đang được nhóm phát triển học hỏi trong khi thực hiện dự án.
Các nguồn lực với các bộ kỹ năng cần thiết không có sẵn và được lên kế hoạch sử dụng trên cơ sở hợp đồng cho các lần lặp lại cụ thể.
Có một số tính năng và mục tiêu rủi ro cao có thể thay đổi trong tương lai.

3. Spiral Model

Mô hình xoắn ốc này là sự kết hợp giữa mô hình quy trình phát triển lặp đi lặp lại và mô hình phát triển tuyến tính tuần tự, tức là mô hình thác nước với sự nhấn mạnh rất cao vào phân tích rủi ro. Nó cho phép phát hành sản phẩm hoặc cải tiến gia tăng qua mỗi lần lặp lại xung quanh hình xoắn ốc.

a. Spiral Model - Thiết kế

Mô hình xoắn ốc có 4 giai đoạn Một dự án phần mềm lặp đi lặp lại các giai đoạn này được gọi là Spiral.

Nhận biết: Giai đoạn này bắt đầu với việc thu thập các yêu cầu kinh doanh theo đường xoắn ốc cơ sở. Trong các vòng xoắn tiếp theo khi sản phẩm trưởng thành, việc xác định các yêu cầu hệ thống, yêu cầu hệ thống con và yêu cầu đơn vị đều được thực hiện trong giai đoạn này. Giai đoạn này cũng bao gồm việc tìm hiểu các yêu cầu của hệ thống bằng cách liên lạc liên tục giữa khách hàng và nhà phân tích hệ thống. Khi kết thúc vòng xoắn, sản phẩm sẽ được triển khai tại thị trường đã xác định.
Thiết kế: Giai đoạn Thiết kế bắt đầu với thiết kế ý tưởng theo đường xoắn ốc cơ sở và liên quan đến thiết kế kiến trúc, thiết kế logic của các mô-đun, thiết kế sản phẩm vật lý và thiết kế cuối cùng trong các đường xoắn ốc tiếp theo.
Xây dựng: Giai đoạn Xây dựng đề cập đến việc sản xuất sản phẩm phần mềm thực tế ở mọi vòng xoắn. Trong vòng xoắn cơ sở, khi sản phẩm mới được nghĩ ra và thiết kế đang được phát triển, POC (Proof of Concept) được phát triển trong giai đoạn này để lấy ý kiến phản hồi của khách hàng. Sau đó, trong các vòng xoắn tiếp theo với sự rõ ràng hơn về các yêu cầu và chi tiết thiết kế, một mô hình làm việc của phần mềm được gọi là bản dựng được tạo ra với số phiên bản. Các bản dựng này được gửi đến khách hàng để phản hồi.
Đánh giá và phân tích rủi ro: Phân tích rủi ro bao gồm xác định, ước tính và theo dõi tính khả thi về mặt kỹ thuật và rủi ro quản lý, chẳng hạn như trượt tiến độ và chi phí vượt mức. Sau khi thử nghiệm bản dựng, vào cuối lần lặp đầu tiên, khách hàng sẽ đánh giá phần mềm và cung cấp phản hồi.

Hình minh họa sau đây là đại diện của mô hình xoắn ốc, liệt kê các hoạt động trong mỗi giai đoạn. Dựa trên sự đánh giá của khách hàng, quy trình phát triển phần mềm bước vào lần lặp tiếp theo và sau đó tuân theo cách tiếp cận tuyến tính để thực hiện phản hồi do khách hàng đề xuất. Quá trình lặp lại theo đường xoắn ốc tiếp tục trong suốt vòng đời của phần mềm.

b. Spiral Model - Ứng dụng

Mô hình xoắn ốc được sử dụng rộng rãi trong ngành công nghiệp phần mềm vì nó đồng bộ với quá trình phát triển tự nhiên của bất kỳ sản phẩm nào, tức là học theo sự trưởng thành, có liên quan đến rủi ro tối thiểu cho khách hàng cũng như các công ty phát triển.

Các gợi ý sau giải thích các cách sử dụng điển hình của Mô hình xoắn ốc:

Khi có hạn chế về ngân sách và đánh giá rủi ro là quan trọng.
Đối với các dự án rủi ro trung bình đến cao.
Cam kết dự án dài hạn vì có thể có những thay đổi đối với các ưu tiên kinh tế khi các yêu cầu thay đổi theo thời gian.
Khách hàng không chắc chắn về yêu cầu của họ, điều này thường xảy ra.
Các yêu cầu rất phức tạp và cần đánh giá để có được sự rõ ràng.
Dòng sản phẩm mới nên được phát hành theo từng giai đoạn để có đủ phản hồi của khách hàng.
Những thay đổi đáng kể được mong đợi trong sản phẩm trong chu kỳ phát triển.

4. V-Model

Mô hình chữ V là một mô hình SDLC trong đó việc thực thi các quy trình diễn ra tuần tự theo hình chữ V. Nó còn được gọi là Verification and Validation model.

Mô hình V là một phần mở rộng của mô hình thác nước và dựa trên sự liên kết của giai đoạn thử nghiệm cho từng giai đoạn phát triển tương ứng. Điều này có nghĩa là đối với mỗi giai đoạn đơn lẻ trong chu kỳ phát triển, có một giai đoạn thử nghiệm được liên kết trực tiếp. Đây là mô hình kỷ luật cao và giai đoạn tiếp theo chỉ bắt đầu sau khi hoàn thành giai đoạn trước.

a. V-Model - Thiết kế

Theo mô hình V, giai đoạn thử nghiệm tương ứng của giai đoạn phát triển được lên kế hoạch song song. Vì vậy, có các giai đoạn Xác minh ở một phía của giai đoạn 'V' và giai đoạn Xác thực ở phía bên kia. Giai đoạn Coding tham gia vào hai phía của mô hình V.

Hình minh họa sau đây mô tả các giai đoạn khác nhau trong mô hình V của SDLC.

b. V-Model - Giai đoạn Verification

Có một số giai đoạn Verification trong V-Model, mỗi giai đoạn này được giải thích chi tiết bên dưới.

Phân tích yêu cầu kinh doanh: Đây là giai đoạn đầu tiên trong chu kỳ phát triển, nơi các yêu cầu của sản phẩm được hiểu theo quan điểm của khách hàng. Giai đoạn này liên quan đến việc trao đổi chi tiết với khách hàng để hiểu những mong đợi và yêu cầu chính xác của họ. Đây là một hoạt động rất quan trọng và cần được quản lý tốt, cũng như Việc lập kế hoạch thiết kế kiểm tra chấp nhận được thực hiện ở giai đoạn này vì các yêu cầu nghiệp vụ có thể được sử dụng làm đầu vào cho kiểm tra chấp nhận.
Thiết kế hệ thống: Khi bạn đã có các yêu cầu sản phẩm rõ ràng và chi tiết, đã đến lúc thiết kế hệ thống hoàn chỉnh. Thiết kế hệ thống sẽ có sự hiểu biết và chi tiết hóa thiết lập phần cứng và giao tiếp hoàn chỉnh cho sản phẩm. Kế hoạch kiểm tra hệ thống được phát triển dựa trên hệ thống thiết kế. Thực hiện điều này ở giai đoạn trước sẽ để lại nhiều thời gian hơn cho việc thực thi thử nghiệm thực tế sau đó.
Thiết kế kiến trúc: Thông số kỹ thuật kiến trúc được hiểu và thiết kế trong giai đoạn này. Thông thường, nhiều hơn một phương pháp tiếp cận kỹ thuật được đề xuất và dựa trên tính khả thi về kỹ thuật và tài chính sẽ đưa ra quyết định cuối cùng. Thiết kế hệ thống được chia nhỏ hơn thành các mô-đun có chức năng khác nhau. Phần này cũng được tham khảo đến như High Level Design (HLD). Việc truyền dữ liệu và giao tiếp giữa các mô-đun bên trong và với thế giới bên ngoài (các hệ thống khác) được hiểu và xác định rõ ràng trong giai đoạn này. Với thông tin này, các bài kiểm tra tích hợp có thể được thiết kế và lập thành văn bản trong giai đoạn này.
Thiết kế mô-đun: Trong giai đoạn này, thiết kế chi tiết bên trong cho tất cả các mô-đun hệ thống được chỉ định, được gọi là Low Level Design (LLD). Điều quan trọng là thiết kế phải tương thích với các mô-đun khác trong kiến trúc hệ thống và các hệ thống bên ngoài đơn vị. Các bài kiểm tra đơn vị này có thể được thiết kế ở giai đoạn này dựa trên các thiết kế mô-đun bên trong. Các bài kiểm tra là một phần thiết yếu của bất kỳ quá trình phát triển nào và giúp loại bỏ tối đa các lỗi và sai sót ở giai đoạn rất sớm.
Giai đoạn coding: Việc coding thực tế của các mô-đun hệ thống được thiết kế trong giai đoạn thiết kế được thực hiện trong giai đoạn coding. Ngôn ngữ lập trình phù hợp nhất được quyết định dựa trên các yêu cầu về hệ thống và kiến trúc. Việc coding được thực hiện dựa trên các nguyên tắc và tiêu chuẩn coding. Code trải qua nhiều lần review code và được tối ưu hóa để đạt hiệu suất tốt nhất trước khi bản dựng cuối cùng được đưa vào kho lưu trữ.

c. V-Model - Giai đoạn Validation

Các giai đoạnValidation khác nhau trong V-Model được giải thích chi tiết bên dưới.

Unit Testing: Kiểm thử đơn vị được thiết kế trong giai đoạn thiết kế mô-đun được thực thi trên code trong giai đoạn xác thực này. Kiểm thử đơn vị là kiểm thử ở cấp code và giúp loại bỏ lỗi ở giai đoạn đầu, mặc dù kiểm thử đơn vị không thể phát hiện được tất cả các lỗi.
Integration Testing: Kiểm thử tích hợp được liên kết với giai đoạn thiết kế kiến trúc. Kiểm thử tích hợp được thực hiện để kiểm tra sự chung sống và giao tiếp của các mô-đun nội bộ trong hệ thống.
System Testing: Kiểm thử hệ thống được liên kết trực tiếp với giai đoạn thiết kế hệ thống. Kiểm thử hệ thống kiểm tra toàn bộ chức năng của hệ thống và giao tiếp của hệ thống đang được phát triển với các hệ thống bên ngoài. Hầu hết các vấn đề về tương thích phần mềm và phần cứng có thể được phát hiện trong quá trình thực hiện kiểm tra hệ thống này.
Acceptance Testing: Kiểm thử chấp nhận được liên kết với giai đoạn phân tích yêu cầu kinh doanh và liên quan đến việc kiểm tra sản phẩm trong môi trường người dùng. Kiểm thử chấp nhận phát hiện ra các vấn đề tương thích với các hệ thống khác có sẵn trong môi trường người dùng. Nó cũng phát hiện ra các vấn đề phi chức năng như lỗi tải và hiệu suất trong môi trường người dùng thực tế.

d. V-Model - Ứng dụng

Ứng dụng V-Model gần giống như mô hình thác nước, vì cả hai mô hình đều thuộc loại tuần tự. Yêu cầu phải rất rõ ràng trước khi bắt đầu dự án, vì thường tốn kém khi quay lại và thực hiện các thay đổi. Mô hình này được sử dụng trong lĩnh vực phát triển y tế, vì nó hoàn toàn là một lĩnh vực có kỷ luật.

Những gợi ý sau đây là một số tình huống phù hợp nhất để sử dụng ứng dụng V-Model.

Các yêu cầu được xác định rõ ràng, ghi chép rõ ràng và cố định.
Định nghĩa sản phẩm là ổn định.
Công nghệ không năng động và được nhóm dự án hiểu rõ.
Không có yêu cầu mơ hồ hoặc không xác định.
Dự án ngắn hạn.

5. Big Bang Model

Mô hình Big Bang là mô hình SDLC mà không tuân theo bất kỳ quy trình cụ thể nào. Quá trình phát triển chỉ bắt đầu với đầu vào là tiền và nỗ lực cần thiết và đầu ra là phần mềm được phát triển có thể có hoặc có thể không theo yêu cầu của khách hàng. Big Bang Model không tuân theo một quy trình / thủ tục và yêu cầu lập kế hoạch rất ít, thậm chí khách hàng không chắc chắn về chính xác những gì họ muốn và các yêu cầu được thực hiện ngay lập tức mà không cần phân tích nhiều.

Thông thường, mô hình này được áp dụng cho các dự án nhỏ mà các nhóm phát triển rất nhỏ.

Big Bang Model - Thiết kế và Ứng dụng

Các yêu cầu được hiểu và thực hiện khi chúng xuất hiện. Bất kỳ thay đổi nào được yêu cầu đều có thể cần hoặc không cần sửa lại phần mềm hoàn chỉnh. Mô hình Big Bang tập trung tất cả các nguồn lực có thể vào việc phát triển và viết mã phần mềm, với rất ít hoặc không cần lập kế hoạch.

Mô hình này lý tưởng cho các dự án nhỏ với một hoặc hai nhà phát triển làm việc cùng nhau và cũng hữu ích cho các dự án học thuật hoặc thực hành. Đây là mô hình lý tưởng cho sản phẩm mà các yêu cầu không được hiểu rõ và ngày phát hành cuối cùng không được đưa ra.

6. Agile Model

Mô hình Agile tin rằng mọi dự án cần được xử lý theo cách khác nhau và các phương pháp hiện có cần được điều chỉnh để phù hợp nhất với yêu cầu của dự án. Trong Agile, các nhiệm vụ được chia thành các ô thời gian (khung thời gian nhỏ) để cung cấp các tính năng cụ thể cho một bản phát hành.

Phương pháp lặp đi lặp lại được thực hiện và bản xây dựng phần mềm đang hoạt động được phân phối sau mỗi lần lặp lại. Mỗi bản dựng đều tăng dần về tính năng; bản dựng cuối cùng giữ tất cả các tính năng mà khách hàng yêu cầu.

Đây là một minh họa đồ họa của mô hình Agile: Quy trình tư duy Agile đã bắt đầu sớm trong quá trình phát triển phần mềm và bắt đầu trở nên phổ biến theo thời gian do tính linh hoạt và khả năng thích ứng của nó.

Các phương pháp Agile phổ biến nhất bao gồm Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development và Dynamic Systems Development Method (DSDM) (1995). Được gọi chung là Phương pháp Agile, sau khi Tuyên ngôn Agile được xuất bản vào năm 2001.

Sau đây là các nguyên tắc Tuyên ngôn Agile:

Cá nhân và tương tác: Trong phát triển Agile, tự tổ chức và động lực là rất quan trọng, cũng như các tương tác như lập trình đồng vị trí và lập trình cặp.
Phần mềm làm việc: Phần mềm làm việc demo được coi là phương tiện giao tiếp tốt nhất để khách hàng hiểu được yêu cầu của họ, thay vì chỉ phụ thuộc vào tài liệu.
Sự hợp tác của khách hàng: Vì các yêu cầu không thể được thu thập hoàn toàn trong giai đoạn đầu của dự án do nhiều yếu tố khác nhau, nên việc tương tác liên tục với khách hàng là rất quan trọng để có được các yêu cầu sản phẩm phù hợp.
Đáp ứng với sự thay đổi: Phát triển Agile tập trung vào phản ứng nhanh chóng với sự thay đổi và phát triển liên tục.

(Nguồn: https://www.tutorialspoint.com)