SDLC - Hướng dẫn nhanh

Vòng đời phát triển phần mềm (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 tra 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 đá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 Vòng đời phát triển phần mềm.
Nó còn được gọi là Quy trình Phát triển Phần mềm.
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ế cho các quy trình vòng đời phần mềm. Nó 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 theo sau 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 luận để 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à 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.

Một Vòng đời Phát triển Phần mềm đ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ách tiếp cận dự án cơ bản và thực hiện 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.

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. Kết quả của nghiên cứu khả thi kỹ thuật là xác định các phương pháp tiếp cận kỹ thuật khác nhau có thể được tuân theo để thực hiện dự án thành công với rủi ro tối thiểu.

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

Khi việc 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à ghi lại 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 mộtSRS (Software Requirement Specification) tài liệu 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 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 được chỉ định trong SRS, thường nhiều hơn một cách tiếp cận thiết kế cho kiến trúc sản phẩm được đề xuất và ghi lại trong một DDS - Đặc tả tài liệu thiết kế.

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 phải được xác định rõ ràng với những chi tiết nhỏ nhấ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, sự 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 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 tra 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 thử nghiệm hầu như liên quan đến tất cả các giai đoạn của SDLC. Tuy nhiên, giai đoạn này chỉ giai đoạn kiểm tra sản phẩm trong đó các lỗi sản phẩm được báo cáo, theo dõi, khắc phục và kiểm tra lại cho đến khi sản phẩm đạt đượ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à duy trì

Sau khi sản phẩm được thử nghiệm và sẵn sàng được triển khai, nó sẽ được phát hành chính thức trên 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 đó. Trước tiên, sản phẩm có thể được phát hành trong một phân khúc hạn chế và được thử nghiệm trong môi trường kinh doanh thực tế (UAT- Thử nghiệm chấp nhận người dùng).

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 có.

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à Mô hình Quy trình Phát triển Phần mềm ". Mỗi mô hình quy trình tuân theo một Chuỗi các bước duy nhất cho kiểu của nó để đảm bảo sự thành công trong quá 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 theo sau trong ngành:

Mô hình thác nước
Mô hình lặp lại
Mô hình xoắn ốc
V-Model
Mô hình Big Bang

Các phương pháp luận liên quan khác là Mô hình Agile, Mô hình RAD, Phát triển ứng dụng nhanh chóng và Mô hình tạo mẫu.

Mô hình Thác nước là Mô hình Quy trình đầu tiên được giới thiệu. Nó cũng được gọi làlinear-sequential life cycle model. 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 Waterfall 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 quá 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 pha không chồng lên nhau.

Mô hình thác nước - 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 "The Waterfall", 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 Waterfall này, thông thường, kết quả của một giai đoạn đóng vai trò là đầu vào tuần tự cho giai đoạn tiếp theo.

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 Waterfall là:

Requirement Gathering and analysis - Tất cả các yêu cầu có thể có của hệ thống sẽ được phát triển đượ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.
System Design- Các thông số kỹ thuật yêu cầu từ giai đoạn đầu đượ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ể.
Implementation- Với các đầ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ị.
Integration and Testing- Tất cả các đơn vị được phát triển trong giai đoạn triển khai được tích hợp vào một hệ thống sau khi thử nghiệm của 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.
Deployment of system- 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 được tung ra thị trường.
Maintenance- Có một số vấn đề nảy sinh trong môi trường khách hàng. Để khắc phục những vấn đề đó, các bản vá được phát hành. Ngoài ra để nâng cao 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 như chảy đều đặn xuống dưới (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 "Mô hình thác nước". Trong mô hình này, các giai đoạn không chồng chéo lên nhau.

Mô hình thác nước - Ứ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 phương pháp 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 Waterfall 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.
Dự án ngắn hạn.

Mô hình thác nước - Ưu điểm

Ưu điểm của phát triển thác nước là nó cho phép phòng ban và kiểm soát. Một lịch trình có thể được thiết lập với thời hạn cho từng giai đoạn phát triển và một sản phẩm có thể tiến hành từng giai đoạn của mô hình quy trình phát triển.

Sự phát triển di chuyển từ ý tưởng, thông qua thiết kế, thực hiện, thử nghiệm, cài đặt, khắc phục sự cố và kết thúc là vận hành và bảo trì. Mỗi giai đoạn phát triển diễn ra theo thứ tự nghiêm ngặt.

Một số ưu điểm chính của Mô hình thác nước như sau:

Đơn giản và dễ hiểu và sử dụng
Dễ dàng quản lý do độ cứng của mô hình. Mỗi giai đoạn có các phân phối cụ thể và một quy trình xem xét.
Các giai đoạn được xử lý và hoàn thành cùng một lúc.
Hoạt động tốt cho các dự án nhỏ hơn, nơi các yêu cầu được hiểu rất rõ.
Các giai đoạn được xác định rõ ràng.
Các mốc quan trọng được hiểu rõ.
Dễ dàng sắp xếp các công việc.
Quá trình và kết quả được ghi lại đầy đủ.

Mô hình thác nước - Nhược điểm

Nhược điểm của phát triển thác nước là nó không cho phép phản ánh hoặc sửa đổi nhiều. Khi một ứng dụng đang trong giai đoạn thử nghiệm, rất khó để quay lại và thay đổi một cái gì đó không được ghi chép đầy đủ hoặc được nghĩ đến trong giai đoạn khái niệm.

Những nhược điểm chính của Mô hình thác nước như sau:

Không có phần mềm đang hoạt động nào được sản xuất cho đến cuối vòng đời.
Lượng rủi ro cao và không chắc chắn.
Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng.
Mô hình kém cho các dự án dài và đang diễn ra.
Không phù hợp với các dự án mà các yêu cầu có nguy cơ thay đổi từ trung bình đến cao. Vì vậy, rủi ro và sự không chắc chắn là cao với mô hình quy trình này.
Rất khó để đo lường sự tiến bộ trong các giai đoạn.
Không thể đáp ứng các yêu cầu thay đổi.
Điều chỉnh phạm vi trong vòng đời có thể kết thúc một dự án.
Việc tích hợp được thực hiện như một "vụ nổ lớn ở giai đoạn cuối, điều này không cho phép xác định sớm bất kỳ điểm nghẽn hoặc thách thức nào về công nghệ hoặc kinh doanh.

Trong mô hình Lặp lại, quá trình lặp lại bắt đầu với 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ột 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 phần mềm mới vào cuối mỗi lần lặp lại của mô hình.

Mô hình lặp lại - 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 đi lặp lại (lặp đi lặp lại) và trong 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 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 cách tiếp cận "tiếp thu 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 nhiều bản dựng khác nhau. Trong mỗi lần lặp lại, mô-đun phát triển 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 bổ sung chức năng cho bản phát hành trước đó. Quá trình tiếp tục cho đến khi 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 bài kiểm tra 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.

Mô hình lặp lại - Ứ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.

Mô hình lặp lại - Ưu và nhược điểm

Ưu điểm của mô hình này là có một mô hình hoạt động của hệ thống ở giai đoạn phát triển rất sớm, điều này giúp dễ dàng tìm ra các sai sót về chức năng hoặc thiết kế. Việc phát hiện các vấn đề ở giai đoạn phát triển ban đầu cho phép thực hiện các biện pháp khắc phục trong một ngân sách hạn chế.

Nhược điểm của mô hình SDLC này là nó chỉ áp dụng cho các dự án phát triển phần mềm lớn và cồng kềnh. Điều này là do khó có thể phá vỡ một hệ thống phần mềm nhỏ thành các phần / mô-đun nhỏ có thể sử dụng được.

Các ưu điểm của Mô hình SDLC Lặp lại và Gia tăng như sau:

Một số chức năng làm việc có thể được phát triển nhanh chóng và sớm trong vòng đời.
Kết quả thu được sớm và định kỳ.
Có thể lập kế hoạch phát triển song song.
Tiến độ có thể được đo lường.
Ít tốn kém hơn để thay đổi phạm vi / yêu cầu.
Dễ dàng kiểm tra và gỡ lỗi trong quá trình lặp lại nhỏ hơn.
Rủi ro được xác định và giải quyết trong quá trình lặp lại; và mỗi lần lặp lại là một cột mốc dễ quản lý.
Quản lý rủi ro dễ dàng hơn - Phần rủi ro cao được thực hiện trước.
Với mỗi gia số, sản phẩm hoạt động được phân phối.
Các vấn đề, thách thức và rủi ro được xác định từ mỗi bước tăng có thể được sử dụng / áp dụng cho bước tiếp theo.
Phân tích rủi ro tốt hơn.
Nó hỗ trợ các yêu cầu thay đổi.
Thời gian hoạt động ban đầu ít hơn.
Phù hợp hơn cho các dự án lớn và quan trọng.
Trong vòng đời, phần mềm được sản xuất sớm để tạo điều kiện thuận lợi cho việc đánh giá và phản hồi của khách hàng.

Những nhược điểm của Mô hình SDLC Lặp lại và Tăng dần như sau:

Nhiều tài nguyên hơn có thể được yêu cầu.
Mặc dù chi phí thay đổi ít hơn, nhưng nó không phù hợp lắm với các yêu cầu thay đổi.
Cần có thêm sự quan tâm của quản lý.
Các vấn đề về kiến trúc hoặc thiết kế hệ thống có thể phát sinh bởi vì không phải tất cả các yêu cầu đều được tập hợp trong phần đầu của toàn bộ vòng đời.
Việc xác định các gia số có thể yêu cầu xác định hệ thống hoàn chỉnh.
Không thích hợp cho các dự án nhỏ hơn.
Quản lý phức tạp hơn.
Kết thúc dự án có thể không được biết là rủi ro.
Cần có nguồn lực có kỹ năng cao để phân tích rủi ro.
Tiến độ dự án phụ thuộc nhiều vào giai đoạn phân tích rủi ro.

Mô hình xoắn ốc kết hợp ý tưởng phát triển lặp đi lặp lại với các khía cạnh có hệ thống, được kiểm soát của mô hình thác nước. Mô hình xoắn ốc này là sự kết hợp giữa mô hình quá 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 gia tăng hoặc cải tiến gia tăng thông qua mỗi lần lặp lại theo hình xoắn ốc.

Mô hình xoắn ốc - Thiết kế

Mô hình xoắn ốc có bốn 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 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 hiểu các yêu cầu 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. Ở cuối vòng xoáy, sản phẩm được triển khai trên 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 hoặc 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ế theo từng 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 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 một 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à giám sát 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 chi phí. 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 đá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.

Ứng dụng mô hình xoắn ốc

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, bao gồm 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ể thay đổ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.

Mô hình xoắn ốc - Ưu và nhược điểm

Ưu điểm của mô hình vòng đời xoắn ốc là nó cho phép các thành phần của sản phẩm được thêm vào, khi chúng có sẵn hoặc được biết đến. Điều này đảm bảo rằng không có xung đột với các yêu cầu và thiết kế trước đó.

Phương pháp này phù hợp với các phương pháp tiếp cận có nhiều bản phát hành và xây dựng phần mềm cho phép thực hiện chuyển đổi có trật tự sang hoạt động bảo trì. Một khía cạnh tích cực khác của phương pháp này là mô hình xoắn ốc buộc người dùng sớm tham gia vào nỗ lực phát triển hệ thống.

Mặt khác, để hoàn thành các sản phẩm như vậy cần phải có sự quản lý rất chặt chẽ và có nguy cơ chạy theo vòng xoáy không xác định. Vì vậy, kỷ luật thay đổi và mức độ thực hiện các yêu cầu thay đổi là rất quan trọng để phát triển và triển khai sản phẩm thành công.

Các ưu điểm của Mô hình Spiral SDLC như sau:

Các yêu cầu thay đổi có thể được đáp ứng.
Cho phép sử dụng rộng rãi các nguyên mẫu.
Yêu cầu có thể được nắm bắt chính xác hơn.
Người dùng xem hệ thống sớm.
Việc phát triển có thể được chia thành các phần nhỏ hơn và các phần rủi ro có thể được phát triển sớm hơn để giúp quản lý rủi ro tốt hơn.

Các nhược điểm của Mô hình Spiral SDLC như sau:

Quản lý phức tạp hơn.
Kết thúc của dự án có thể không được biết sớm.
Không thích hợp cho các dự án nhỏ hoặc rủi ro thấp và có thể tốn kém cho các dự án nhỏ.
Quy trình phức tạp
Xoắn ốc có thể diễn ra vô thời hạn.
Số lượng lớn các giai đoạn trung gian yêu cầu quá nhiều tài liệu.

Mô hình 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 một giai đoạn thử nghiệm cho mỗi 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 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ột mô hình có tí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.

V-Model - Thiết kế

Theo V-Model, 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 bên của giai đoạn 'V' và xác thực ở phía bên kia. Giai đoạn mã hóa tham gia vào hai bên của V-Model.

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.

V-Model - Các giai đoạn xác minh

Có một số giai đoạn Xác minh 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 mà 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, vì hầu hết khách hàng không chắc chắn về những gì họ cần chính xác. Cácacceptance test design planning đượ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 để 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ẽ hiểu 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 đang được phát triển. Kế hoạch kiểm tra hệ thống được phát triển dựa trên thiết kế hệ thống. Thực hiện điều này ở giai đoạn sớm hơn để 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 cách 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, quyết định cuối cùng được đưa ra. Thiết kế hệ thống được chia nhỏ hơn nữa thành các mô-đun đảm nhận các chức năng khác nhau. Điều này cũng được gọi là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à ghi lại trong giai đoạn này.

Thiết kế mô-đun

Trong giai đoạn này, thiết kế nội bộ chi tiết 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 khác. Các bài kiểm tra đơn vị 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. 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.

Giai đoạn mã hóa

Mã hóa 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 Mã hóa. Ngôn ngữ lập trình phù hợp nhất được quyết định dựa trên yêu cầu về hệ thống và kiến trúc.

Việc mã hóa được thực hiện dựa trên các hướng dẫn và tiêu chuẩn mã hóa. Mã trải qua nhiều lần đánh giá mã 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ác giai đoạn xác thực

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

Kiểm tra đơn vị

Các bài kiểm tra đơn vị được thiết kế trong giai đoạn thiết kế mô-đun được thực thi trên mã trong giai đoạn xác nhận này. Kiểm thử đơn vị là kiểm thử ở cấp mã và giúp loại bỏ lỗi ở giai đoạn đầu, mặc dù không thể phát hiện tất cả các lỗi bằng kiểm thử đơn vị.

Thử nghiệm hội nhập

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 tra 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.

Thử nghiệm hệ thống

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 tra hệ thống kiểm tra toàn bộ chức năng hệ thống và giao tiếp của hệ thống đang phát triển với các hệ thống bên ngoài. Hầu hết các vấn đề 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.

Kiểm tra chấp nhận

Thử nghiệm 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 thử nghiệm sản phẩm trong môi trường người dùng. Kiểm tra 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ế.

V- Mô hình ─ Ứng dụng

V- Ứng dụng mô hình 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ự. Các yêu cầu phải rất rõ ràng trước khi dự án bắt đầu, 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ó là một lĩnh vực có kỷ luật nghiêm ngặ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.

V-Model - Ưu và nhược điểm

Ưu điểm của phương pháp V-Model là rất dễ hiểu và dễ áp dụng. Sự đơn giản của mô hình này cũng giúp bạn dễ dàng quản lý hơn. Điểm bất lợi là mô hình không linh hoạt để thay đổi và chỉ trong trường hợp có yêu cầu thay đổi, điều rất phổ biến trong thế giới năng động ngày nay, việc thay đổi sẽ trở nên rất tốn kém.

Các ưu điểm của phương pháp V-Model như sau:

Đây là một mô hình có tính kỷ luật cao và các giai đoạn được hoàn thành từng giai đoạn một.
Hoạt động tốt cho các dự án nhỏ hơn, nơi các yêu cầu được hiểu rất rõ.
Đơn giản và dễ hiểu và sử dụng.
Dễ dàng quản lý do độ cứng của mô hình. Mỗi giai đoạn có các phân phối cụ thể và một quy trình xem xét.

Những nhược điểm của phương pháp V-Model như sau:

Rủi ro cao và không chắc chắn.
Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng.
Mô hình kém cho các dự án dài và đang diễn ra.
Không phù hợp với các dự án mà các yêu cầu có nguy cơ thay đổi từ trung bình đến cao.
Khi một ứng dụng đang trong giai đoạn thử nghiệm, rất khó để quay lại và thay đổi một chức năng.
Không có phần mềm đang hoạt động nào được sản xuất cho đến cuối vòng đời.

Mô hình Big Bang là mô hình SDLC mà chúng tôi 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 tiền và nỗ lực cần thiết như đầu vào, và đầu ra là phần mềm được phát triển có thể đáp ứng hoặc có thể không theo yêu cầu của khách hàng. Mô hình Big Bang này không tuân theo một quy trình / thủ tục và chỉ cần lập kế hoạch rất ít. Ngay cả khách hàng cũng không chắc chắn về những gì chính xác anh ta muốn và các yêu cầu được thực hiện một cách nhanh chóng 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ỏ.

Mô hình Big Bang ─ Thiết kế và Ứng dụng

Mô hình Big Bang bao gồm việc 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ó kế hoạch. Các yêu cầu được hiểu và thực hiện khi chúng đế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 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ột 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.

Mô hình Big Bang - Ưu và nhược điểm

Ưu điểm của Mô hình Big Bang này là nó rất đơn giản và cần rất ít hoặc không cần lập kế hoạch. Dễ dàng quản lý và không cần thủ tục chính thức.

Tuy nhiên, Mô hình Big Bang là một mô hình có rủi ro rất cao và những thay đổi trong các yêu cầu hoặc các yêu cầu bị hiểu nhầm thậm chí có thể dẫn đến việc đảo ngược hoàn toàn hoặc phá hủy dự án. Nó là lý tưởng cho các dự án lặp đi lặp lại hoặc nhỏ với rủi ro tối thiểu.

Các ưu điểm của Mô hình Big Bang như sau:

Đây là một mô hình rất đơn giản
Ít hoặc không cần lập kế hoạch
Dễ dàng quản lý
Cần rất ít tài nguyên
Mang lại sự linh hoạt cho các nhà phát triển
Nó là một trợ giúp học tập tốt cho những người mới đến hoặc sinh viên.

Những nhược điểm của Mô hình Big Bang như sau:

Rủi ro rất cao và không chắc chắn.
Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng.
Mô hình kém cho các dự án dài và đang diễn ra.
Có thể rất tốn kém nếu các yêu cầu bị hiểu sai.

Mô hình Agile SDLC là sự kết hợp của các mô hình quy trình lặp đi lặp lại và gia tăng tập trung vào khả năng thích ứng của quy trình và sự hài lòng của khách hàng bằng cách phân phối nhanh chóng các sản phẩm phần mềm đang hoạt động. Các phương pháp Agile chia sản phẩm thành các bản xây dựng gia tăng nhỏ. Các bản dựng này được cung cấp trong các lần lặp lại. Mỗi lần lặp lại thường kéo dài từ một đến ba tuần. Mỗi lần lặp lại liên quan đến các nhóm chức năng chéo làm việc đồng thời trên các lĩnh vực khác nhau như -

Planning
Phân tích yêu cầu
Design
Coding
Kiểm tra đơn vị và
Kiểm tra chấp nhận.

Vào cuối quá trình lặp lại, một sản phẩm đang hoạt động được hiển thị cho khách hàng và các bên liên quan quan trọng.

Agile là gì?

Mô hình Agile tin rằng mọi dự án cần được xử lý 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 các 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 chứa tất cả các tính năng theo yêu cầu của khách hàng.

Đâ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). Chúng bây giờ được gọi chung làAgile Methodologies, 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 của Tuyên ngôn Agile -

Individuals and interactions - 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.
Working software - 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.
Customer collaboration - 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 yêu cầu sản phẩm phù hợp.
Responding to change - Phát triển Agile tập trung vào phản ứng nhanh với sự thay đổi và phát triển liên tục.

Mô hình SDLC truyền thống Agile Vs

Agile dựa trên adaptive software development methods, trong khi các mô hình SDLC truyền thống như mô hình thác nước dựa trên cách tiếp cận dự đoán. Các nhóm dự đoán trong mô hình SDLC truyền thống thường làm việc với kế hoạch chi tiết và có dự báo đầy đủ về các nhiệm vụ và tính năng chính xác sẽ được giao trong vài tháng tới hoặc trong vòng đời sản phẩm.

Các phương pháp dự đoán hoàn toàn phụ thuộc vào requirement analysis and planningđược thực hiện vào đầu chu kỳ. Bất kỳ thay đổi nào được đưa vào đều phải trải qua quá trình quản lý và ưu tiên kiểm soát thay đổi nghiêm ngặt.

Agile sử dụng một adaptive approachnơi không có kế hoạch chi tiết và chỉ rõ ràng về các nhiệm vụ trong tương lai đối với những tính năng nào cần được phát triển. Có sự phát triển theo hướng tính năng và nhóm thích ứng với các yêu cầu sản phẩm đang thay đổi một cách linh hoạt. Sản phẩm được kiểm tra rất thường xuyên, thông qua các lần phát hành, giảm thiểu rủi ro xảy ra bất kỳ sự cố lớn nào trong tương lai.

Customer Interactionlà xương sống của phương pháp Agile này và giao tiếp cởi mở với tài liệu tối thiểu là các tính năng điển hình của môi trường phát triển Agile. Các nhóm nhanh nhẹn làm việc phối hợp chặt chẽ với nhau và thường nằm ở cùng một vị trí địa lý.

Mô hình Agile - Ưu và nhược điểm

Phương pháp Agile đang được chấp nhận rộng rãi trong thế giới phần mềm gần đây. Tuy nhiên, phương pháp này có thể không phải lúc nào cũng phù hợp với tất cả các sản phẩm. Dưới đây là một số ưu và nhược điểm của mô hình Agile.

Các ưu điểm của Mô hình Agile như sau:

Là một cách tiếp cận rất thực tế để phát triển phần mềm.
Thúc đẩy làm việc theo nhóm và đào tạo chéo.
Chức năng có thể được phát triển nhanh chóng và được chứng minh.
Yêu cầu tài nguyên là tối thiểu.
Thích hợp cho các yêu cầu cố định hoặc thay đổi
Đưa ra các giải pháp làm việc từng phần sớm.
Mô hình tốt cho môi trường thay đổi ổn định.
Quy tắc tối thiểu, tài liệu dễ dàng sử dụng.
Cho phép phát triển và phân phối đồng thời trong bối cảnh được lập kế hoạch tổng thể.
Ít hoặc không cần lập kế hoạch.
Dễ dàng quản lý.
Mang lại sự linh hoạt cho các nhà phát triển.

Những nhược điểm của Mô hình Agile như sau:

Không thích hợp để xử lý các phụ thuộc phức tạp.
Rủi ro hơn về tính bền vững, khả năng bảo trì và khả năng mở rộng.
Một kế hoạch tổng thể, một nhà lãnh đạo nhanh nhẹn và thực hành PM nhanh nhẹn là điều bắt buộc nếu thiếu nó sẽ không hoạt động.
Quản lý phân phối chặt chẽ quy định phạm vi, chức năng được phân phối và điều chỉnh để đáp ứng thời hạn.
Phụ thuộc nhiều vào sự tương tác của khách hàng, vì vậy nếu khách hàng không rõ ràng, nhóm có thể bị điều khiển sai hướng.
Có sự phụ thuộc cá nhân rất cao, vì phải tạo ra tài liệu tối thiểu.
Việc chuyển giao công nghệ cho các thành viên mới trong nhóm có thể khá khó khăn do thiếu tài liệu.

Các RAD (Rapid Application Development)mô hình dựa trên tạo mẫu và phát triển lặp đi lặp lại mà không liên quan đến kế hoạch cụ thể. Bản thân quá trình viết phần mềm liên quan đến việc lập kế hoạch cần thiết để phát triển sản phẩm.

Phát triển ứng dụng nhanh tập trung vào việc thu thập các yêu cầu của khách hàng thông qua hội thảo hoặc nhóm tập trung, kiểm tra sớm các nguyên mẫu của khách hàng bằng cách sử dụng khái niệm lặp đi lặp lại, tái sử dụng các nguyên mẫu (thành phần) hiện có, tích hợp liên tục và phân phối nhanh chóng.

RAD là gì?

Phát triển ứng dụng nhanh là một phương pháp luận phát triển phần mềm sử dụng quy hoạch tối thiểu để tạo mẫu nhanh. Nguyên mẫu là một mô hình hoạt động có chức năng tương đương với một thành phần của sản phẩm.

Trong mô hình RAD, các mô-đun chức năng được phát triển song song dưới dạng nguyên mẫu và được tích hợp để tạo thành sản phẩm hoàn chỉnh nhằm cung cấp sản phẩm nhanh hơn. Vì không có kế hoạch trước chi tiết, nên việc kết hợp các thay đổi trong quá trình phát triển trở nên dễ dàng hơn.

Các dự án RAD tuân theo mô hình lặp đi lặp lại và tăng dần và có các nhóm nhỏ bao gồm các nhà phát triển, chuyên gia miền, đại diện khách hàng và các tài nguyên CNTT khác đang làm việc liên tục trên thành phần hoặc nguyên mẫu của họ.

Khía cạnh quan trọng nhất để mô hình này thành công là đảm bảo rằng các nguyên mẫu được phát triển có thể tái sử dụng.

Thiết kế mô hình RAD

Mô hình RAD phân phối các giai đoạn phân tích, thiết kế, xây dựng và thử nghiệm thành một chuỗi các chu kỳ phát triển ngắn, lặp đi lặp lại.

Sau đây là các giai đoạn khác nhau của Mô hình RAD -

Mô hình kinh doanh

Mô hình kinh doanh cho sản phẩm đang phát triển được thiết kế dựa trên luồng thông tin và sự phân phối thông tin giữa các kênh kinh doanh khác nhau. Một phân tích kinh doanh hoàn chỉnh được thực hiện để tìm ra thông tin quan trọng cho hoạt động kinh doanh, cách thu thập thông tin đó, thông tin được xử lý như thế nào và khi nào cũng như các yếu tố thúc đẩy luồng thông tin thành công là gì.

Mô hình hóa dữ liệu

Thông tin thu thập được trong giai đoạn Mô hình hóa Doanh nghiệp được xem xét và phân tích để tạo thành các bộ đối tượng dữ liệu quan trọng đối với doanh nghiệp. Các thuộc tính của tất cả các tập dữ liệu được xác định và xác định. Mối quan hệ giữa các đối tượng dữ liệu này được thiết lập và xác định chi tiết phù hợp với mô hình kinh doanh.

Mô hình hóa quy trình

Các tập đối tượng dữ liệu được xác định trong giai đoạn Mô hình hóa dữ liệu được chuyển đổi để thiết lập luồng thông tin kinh doanh cần thiết để đạt được các mục tiêu kinh doanh cụ thể theo mô hình kinh doanh. Mô hình quy trình cho bất kỳ thay đổi hoặc cải tiến nào đối với tập đối tượng dữ liệu được xác định trong giai đoạn này. Mô tả quy trình để thêm, xóa, truy xuất hoặc sửa đổi một đối tượng dữ liệu được đưa ra.

Tạo ứng dụng

Hệ thống thực tế được xây dựng và mã hóa được thực hiện bằng cách sử dụng các công cụ tự động hóa để chuyển đổi các mô hình quy trình và dữ liệu thành các nguyên mẫu thực tế.

Thử nghiệm và Doanh thu

Thời gian thử nghiệm tổng thể được giảm xuống trong mô hình RAD vì các nguyên mẫu được thử nghiệm độc lập trong mỗi lần lặp lại. Tuy nhiên, luồng dữ liệu và các giao diện giữa tất cả các thành phần cần được kiểm tra kỹ lưỡng với phạm vi kiểm tra hoàn chỉnh. Vì hầu hết các thành phần lập trình đã được kiểm tra, nó làm giảm nguy cơ xảy ra bất kỳ sự cố lớn nào.

Hình minh họa sau đây mô tả chi tiết Mô hình RAD.

Mô hình RAD so với SDLC truyền thống

SDLC truyền thống tuân theo một mô hình quy trình cứng nhắc với trọng tâm là phân tích và thu thập yêu cầu trước khi bắt đầu mã hóa. Nó gây áp lực buộc khách hàng phải từ chối các yêu cầu trước khi dự án bắt đầu và khách hàng không cảm nhận được sản phẩm vì không có bản dựng nào hoạt động được trong một thời gian dài.

Khách hàng có thể cần một số thay đổi sau khi xem phần mềm. Tuy nhiên, quá trình thay đổi khá cứng nhắc và có thể không khả thi khi kết hợp các thay đổi lớn của sản phẩm trong SDLC truyền thống.

Mô hình RAD tập trung vào việc cung cấp lặp đi lặp lại và tăng dần các mô hình làm việc cho khách hàng. Điều này dẫn đến việc giao hàng nhanh chóng cho khách hàng và sự tham gia của khách hàng trong chu kỳ phát triển hoàn chỉnh của sản phẩm làm giảm nguy cơ không phù hợp với yêu cầu thực tế của người dùng.

Mô hình RAD - Ứng dụng

Mô hình RAD có thể được áp dụng thành công cho các dự án trong đó có thể mô đun hóa rõ ràng. Nếu dự án không thể được chia thành các mô-đun, RAD có thể bị lỗi.

Các gợi ý sau đây mô tả các tình huống điển hình mà RAD có thể được sử dụng:

RAD chỉ nên được sử dụng khi một hệ thống có thể được mô-đun hóa để được phân phối theo cách gia tăng.
Nó nên được sử dụng nếu có nhiều nhà thiết kế sẵn sàng cho Mô hình hóa.
Nó chỉ nên được sử dụng nếu ngân sách cho phép sử dụng các công cụ tạo mã tự động.
Mô hình RAD SDLC chỉ nên được chọn nếu các chuyên gia miền có sẵn kiến thức kinh doanh liên quan.
Nên được sử dụng khi các yêu cầu thay đổi trong dự án và các nguyên mẫu làm việc sẽ được trình bày cho khách hàng trong các lần lặp lại nhỏ trong 2-3 tháng.

Mô hình RAD - Ưu và nhược điểm

Mô hình RAD cho phép phân phối nhanh chóng vì nó giảm thời gian phát triển tổng thể do khả năng tái sử dụng của các thành phần và phát triển song song. RAD chỉ hoạt động tốt nếu có sẵn các kỹ sư có tay nghề cao và khách hàng cũng cam kết đạt được nguyên mẫu mục tiêu trong khung thời gian nhất định. Nếu thiếu cam kết ở cả hai bên, mô hình có thể thất bại.

Các ưu điểm của Mô hình RAD như sau:

Các yêu cầu thay đổi có thể được đáp ứng.
Tiến độ có thể được đo lường.
Thời gian lặp lại có thể ngắn với việc sử dụng các công cụ RAD mạnh mẽ.
Năng suất với ít người hơn trong thời gian ngắn.
Giảm thời gian phát triển.
Tăng khả năng tái sử dụng của các thành phần.
Đánh giá ban đầu nhanh chóng xảy ra.
Khuyến khích phản hồi của khách hàng.
Tích hợp ngay từ đầu giải quyết rất nhiều vấn đề tích hợp.

Những nhược điểm của Mô hình RAD như sau:

Sự phụ thuộc vào các thành viên trong nhóm mạnh về kỹ thuật để xác định các yêu cầu kinh doanh.
Chỉ hệ thống có thể được mô-đun hóa mới có thể được xây dựng bằng RAD.
Yêu cầu nhà phát triển / nhà thiết kế có tay nghề cao.
Phụ thuộc cao vào kỹ năng Mô hình hóa.
Không thể áp dụng cho các dự án rẻ hơn vì chi phí Tạo mô hình và tạo mã tự động là rất cao.
Quản lý phức tạp hơn.
Thích hợp cho các hệ thống dựa trên thành phần và có thể mở rộng.
Yêu cầu sự tham gia của người dùng trong suốt vòng đời.
Thích hợp cho dự án yêu cầu thời gian phát triển ngắn hơn.

Nguyên mẫu phần mềm đề cập đến việc xây dựng các nguyên mẫu ứng dụng phần mềm hiển thị chức năng của sản phẩm đang được phát triển, nhưng có thể không thực sự giữ logic chính xác của phần mềm gốc.

Tạo mẫu phần mềm đang trở nên rất phổ biến như một mô hình phát triển phần mềm, vì nó cho phép hiểu được các yêu cầu của khách hàng ở giai đoạn phát triển ban đầu. Nó giúp nhận được phản hồi có giá trị từ khách hàng và giúp các nhà thiết kế và phát triển phần mềm hiểu chính xác những gì được mong đợi từ sản phẩm đang phát triển.

Tạo mẫu phần mềm là gì?

Nguyên mẫu là một mô hình phần mềm hoạt động với một số chức năng hạn chế. Nguyên mẫu không phải lúc nào cũng nắm giữ logic chính xác được sử dụng trong ứng dụng phần mềm thực tế và là một nỗ lực bổ sung cần được xem xét theo ước tính nỗ lực.

Prototyping được sử dụng để cho phép người dùng đánh giá các đề xuất của nhà phát triển và thử chúng trước khi triển khai. Nó cũng giúp hiểu các yêu cầu dành riêng cho người dùng và có thể chưa được nhà phát triển xem xét trong quá trình thiết kế sản phẩm.

Sau đây là một cách tiếp cận từng bước được giải thích để thiết kế một nguyên mẫu phần mềm.

Nhận dạng yêu cầu cơ bản

Bước này liên quan đến việc hiểu những yêu cầu rất cơ bản của sản phẩm, đặc biệt là về giao diện người dùng. Có thể bỏ qua các chi tiết phức tạp hơn về thiết kế bên trong và các khía cạnh bên ngoài như hiệu suất và bảo mật ở giai đoạn này.

Phát triển Nguyên mẫu ban đầu

Nguyên mẫu ban đầu được phát triển trong giai đoạn này, nơi các yêu cầu rất cơ bản được giới thiệu và giao diện người dùng được cung cấp. Các tính năng này có thể không chính xác hoạt động theo cùng một cách nội bộ trong phần mềm thực tế được phát triển. Trong khi, các giải pháp thay thế được sử dụng để cung cấp cho khách hàng giao diện tương tự trong nguyên mẫu được phát triển.

Đánh giá Nguyên mẫu

Mẫu thử nghiệm được phát triển sau đó sẽ được trình bày cho khách hàng và các bên liên quan quan trọng khác trong dự án. Phản hồi được thu thập một cách có tổ chức và được sử dụng để cải tiến thêm sản phẩm đang được phát triển.

Sửa đổi và nâng cao nguyên mẫu

Các phản hồi và nhận xét đánh giá được thảo luận trong giai đoạn này và một số cuộc đàm phán xảy ra với khách hàng dựa trên các yếu tố như - hạn chế về thời gian và ngân sách và tính khả thi về mặt kỹ thuật của việc triển khai thực tế. Những thay đổi được chấp nhận lại được đưa vào Nguyên mẫu mới được phát triển và chu kỳ lặp lại cho đến khi đáp ứng được mong đợi của khách hàng.

Nguyên mẫu có thể có kích thước ngang hoặc dọc. Mẫu thử nghiệm Ngang hiển thị giao diện người dùng cho sản phẩm và cung cấp cái nhìn rộng hơn về toàn bộ hệ thống mà không tập trung vào các chức năng bên trong. Một mẫu thử nghiệm theo chiều dọc ở phía bên kia là bản trình bày chi tiết của một chức năng cụ thể hoặc một hệ thống con trong sản phẩm.

Mục đích của cả nguyên mẫu ngang và dọc là khác nhau. Các nguyên mẫu nằm ngang được sử dụng để có thêm thông tin về cấp độ giao diện người dùng và các yêu cầu kinh doanh. Nó thậm chí có thể được trình bày trong các bản giới thiệu bán hàng để có được kinh doanh trên thị trường. Các nguyên mẫu dọc có bản chất kỹ thuật và được sử dụng để lấy chi tiết về hoạt động chính xác của các hệ thống con. Ví dụ, các yêu cầu cơ sở dữ liệu, tải tương tác và xử lý dữ liệu trong một hệ thống con nhất định.

Tạo mẫu phần mềm - Các loại

Có nhiều loại nguyên mẫu phần mềm khác nhau được sử dụng trong ngành. Sau đây là các kiểu tạo mẫu phần mềm chính được sử dụng rộng rãi:

Throwaway / Tạo mẫu nhanh

Tạo mẫu thử nghiệm còn được gọi là tạo mẫu nhanh hoặc kết thúc gần. Loại tạo mẫu này sử dụng rất ít nỗ lực với phân tích yêu cầu tối thiểu để xây dựng nguyên mẫu. Khi các yêu cầu thực tế được hiểu, nguyên mẫu sẽ bị loại bỏ và hệ thống thực tế được phát triển với sự hiểu biết rõ ràng hơn nhiều về các yêu cầu của người dùng.

Tạo mẫu tiến hóa

Tạo mẫu tiến hóa còn được gọi là tạo mẫu breadboard dựa trên việc xây dựng các nguyên mẫu chức năng thực tế với chức năng tối thiểu ngay từ đầu. Nguyên mẫu được phát triển tạo thành trái tim của nguyên mẫu tương lai, trên đó toàn bộ hệ thống được chế tạo. Bằng cách sử dụng tạo mẫu tiến hóa, các yêu cầu đã hiểu rõ được đưa vào nguyên mẫu và các yêu cầu được thêm vào khi và khi chúng được hiểu.

Tạo mẫu gia tăng

Tạo mẫu gia tăng đề cập đến việc xây dựng nhiều nguyên mẫu chức năng của các hệ thống con khác nhau và sau đó tích hợp tất cả các nguyên mẫu có sẵn để tạo thành một hệ thống hoàn chỉnh.

Tạo mẫu cực đoan

Tạo mẫu cực đoan được sử dụng trong miền phát triển web. Nó bao gồm ba giai đoạn tuần tự. Đầu tiên, một nguyên mẫu cơ bản với tất cả các trang hiện có được trình bày ở định dạng HTML. Sau đó, quá trình xử lý dữ liệu được mô phỏng bằng cách sử dụng lớp dịch vụ nguyên mẫu. Cuối cùng, các dịch vụ được triển khai và tích hợp vào nguyên mẫu cuối cùng. Quá trình này được gọi là Extreme Prototyping được sử dụng để thu hút sự chú ý đến giai đoạn thứ hai của quá trình, nơi một giao diện người dùng đầy đủ chức năng được phát triển mà không liên quan rất nhiều đến các dịch vụ thực tế.

Tạo mẫu phần mềm - Ứng dụng

Tạo mẫu phần mềm hữu ích nhất trong việc phát triển các hệ thống có mức độ tương tác cao của người dùng như hệ thống trực tuyến. Các hệ thống cần người dùng điền vào các biểu mẫu hoặc duyệt qua các màn hình khác nhau trước khi dữ liệu được xử lý có thể sử dụng tạo mẫu rất hiệu quả để cung cấp giao diện chính xác ngay cả trước khi phần mềm thực tế được phát triển.

Phần mềm liên quan đến quá nhiều xử lý dữ liệu và hầu hết các chức năng là nội bộ với rất ít giao diện người dùng thường không được hưởng lợi từ việc tạo mẫu. Phát triển nguyên mẫu có thể là một chi phí bổ sung trong các dự án như vậy và có thể cần thêm nhiều nỗ lực.

Tạo mẫu phần mềm - Ưu và nhược điểm

Tạo mẫu phần mềm được sử dụng trong các trường hợp điển hình và quyết định phải được thực hiện rất cẩn thận để những nỗ lực dành cho việc xây dựng nguyên mẫu thêm giá trị đáng kể cho phần mềm cuối cùng được phát triển. Mô hình có những ưu và khuyết điểm riêng được thảo luận như sau.

Các ưu điểm của Mô hình tạo mẫu như sau:

Tăng cường sự tham gia của người dùng vào sản phẩm ngay cả trước khi triển khai.
Kể từ khi mô hình hoạt động của hệ thống được hiển thị, người dùng hiểu rõ hơn về hệ thống đang được phát triển.
Giảm thời gian và chi phí vì các lỗi có thể được phát hiện sớm hơn nhiều.
Phản hồi của người dùng nhanh hơn có sẵn dẫn đến các giải pháp tốt hơn.
Chức năng bị thiếu có thể được xác định dễ dàng.
Các chức năng khó hiểu hoặc khó có thể được xác định.

Nhược điểm của Mô hình Nguyên mẫu như sau:

Rủi ro phân tích yêu cầu không đủ do phụ thuộc quá nhiều vào nguyên mẫu.
Người dùng có thể bị nhầm lẫn giữa nguyên mẫu và hệ thống thực tế.
Trên thực tế, phương pháp luận này có thể làm tăng độ phức tạp của hệ thống vì phạm vi của hệ thống có thể mở rộng ra ngoài kế hoạch ban đầu.
Các nhà phát triển có thể cố gắng sử dụng lại các nguyên mẫu hiện có để xây dựng hệ thống thực tế, ngay cả khi nó không khả thi về mặt kỹ thuật.
Công sức đầu tư vào việc xây dựng nguyên mẫu có thể là quá nhiều nếu nó không được giám sát đúng cách.