4 phương pháp phát triển phần mềm phổ biến nhất cho dự án của bạn

Có nhiều mô hình vòng đời phát triển phần mềm khác nhau. Tùy thuộc vào bản chất của dự án của bạn, có một mô hình phù hợp. Mỗi người trong số họ tuân theo một loạt các bước duy nhất phù hợp với loại dự án của mình để đảm bảo quy trình thành công. Waterfall, Iterative, Agile & Scrum và Rapid Application Development (RAD) là những vòng đời phát triển phần mềm phổ biến nhất đang được sử dụng hiện nay.

Waterfall

Mô hình Waterfall là vòng đời phát triển phần mềm sớm nhất và nổi tiếng nhất. Đây là phương pháp phần mềm đơn giản nhất để hiểu và áp dụng. Một phần là do Waterfall diễn ra tuần tự, có nghĩa là mỗi giai đoạn phải kết thúc thì giai đoạn tiếp theo mới bắt đầu. Nói cách khác, đầu ra của một giai đoạn nhất định sẽ là đầu vào cho giai đoạn tiếp theo. Điều này cũng có nghĩa là sẽ không có sự chồng chéo giữa các giai đoạn.

Toàn bộ phương pháp Waterfall và sản phẩm của từng giai đoạn của nó có thể được tóm tắt như sau.

1. Yêu cầu

Yêu cầu là về việc thu thập và phân tích các yêu cầu, được thực hiện bằng cách giao tiếp với người dùng hoặc khách hàng doanh nghiệp. Trong giai đoạn này, người phụ trách (thường là người quản lý dự án) làm việc để hiểu các yêu cầu của người dùng và giải thích chúng một cách chi tiết trong Tài liệu tình huống kinh doanh.

2. Thiết kế 

Dựa trên Tài liệu trường hợp kinh doanh, Nhà phân tích kinh doanh hiện xác định thiết kế logic của phần mềm. Trong giai đoạn này, thiết kế cấp cao cũng được chuyển đổi thành thiết kế vật lý, nơi phần cứng và phần mềm đều được xem xét. Kiến trúc hệ thống cũng được xác định trong giai đoạn này.

3. Thực hiện

Đây là nơi các nhà phát triển viết mã để phát triển phần mềm, theo hướng dẫn trong tài liệu yêu cầu. Đầu ra của giai đoạn này là Yêu cầu chức năng, ghi lại tất cả các chi tiết của các chức năng phần mềm đang được phát triển.

4. Thử nghiệm

Lấy Đặc tả chức năng của giai đoạn Triển khai, người kiểm thử sẽ lập kế hoạch kiểm thử. Các nhà phát triển và nhà phân tích kinh doanh cũng cần chuẩn bị kế hoạch kiểm tra. Các nhà phát triển làm điều này để kiểm tra xem các chức năng có thể thực thi được như mong đợi hay không, trong khi các nhà phân tích kinh doanh muốn đảm bảo phần mềm đáp ứng các yêu cầu của người dùng. Người kiểm tra cuối cùng sẽ thu thập tất cả tài liệu từ các giai đoạn trước và thực hiện kiểm tra tổng thể về mọi khía cạnh ở cấp độ sâu hơn, cố gắng xác minh kiến ​​trúc hệ thống, công nghệ được sử dụng, v.v.

5. Triển khai

Sau khi phần mềm đủ điều kiện để được “PASS”, nó đã sẵn sàng để phát hành. Phần mềm có thể được triển khai cho các máy chủ sản xuất hoặc được phát hành để người dùng cài đặt trên thiết bị của riêng họ.

6. Bảo trì

Thực tế là những khiếm khuyết là không thể tránh khỏi. Hơn nữa, nhu cầu của người dùng liên tục thay đổi và do đó, thỉnh thoảng cần có các bản cập nhật. Bảo trì giải quyết những tình huống này, trong đó các thay đổi được thực hiện để phần mềm thích ứng với những thay đổi mới. Bảo trì chỉ đơn giản là một tập hợp con của Mô hình Waterfall.

Khi nào nên sử dụng Waterfall

• Phần mềm không động, có nghĩa là dự kiến ​​sẽ có một vài thay đổi trong quá trình thực hiện
• Rất ít hoặc lý tưởng nhất là không có yêu cầu mơ hồ
• Phần mềm cần tài liệu hướng dẫn tốt
• Phần mềm sử dụng các công nghệ trưởng thành
• Có đủ nguồn lực và chuyên gia trước cho từng giai đoạn

Thuận lợi

• Dễ quản lý vì mọi thứ đều có lịch trình và mốc rõ ràng
• Dễ kiểm soát với ít yếu tố bên ngoài nhờ không có pha chồng chéo
• Dễ dự đoán vì có nhiều tài liệu

Nhược điểm

• Không cho phép thay đổi phạm vi hoặc yêu cầu
• Không cho phép đánh giá sản phẩm cho đến giai đoạn triển khai
• Không thể đối phó với những rủi ro bất ngờ
• Giao tiếp hạn chế với người dùng hoặc khách hàng do giao tiếp bị ràng buộc ở đầu và cuối dự án
• Thời gian nhàn rỗi dài
• Không phù hợp cho dự án dài hạn và đang diễn ra

Iterative

Iterative việc phát triển phần mềm thành các phần nhỏ hơn được gọi là “xây dựng”. Ở mỗi bản dựng, các cải tiến thiết kế và chức năng mới được thêm vào cho đến khi sản phẩm phần mềm phát triển thành bản triển khai cuối cùng.

Ngược lại với Waterfall, mã trong mô hình lặp lại được phát triển và thử nghiệm theo chu kỳ lặp lại. Điều này làm cho nó linh hoạt cho những thay đổi yêu cầu mới. Mã hóa không phải đợi cho đến khi giai đoạn thiết kế kết thúc. Tương tự như vậy, Thử nghiệm có thể bắt đầu mà không cần phải đợi mã.

1. Yêu cầu

Giống như mô hình Waterfall, Yêu cầu tập trung vào giao tiếp với người dùng doanh nghiệp và chuẩn bị Tài liệu trường hợp kinh doanh

2. Thiết kế 

Cũng giống như mô hình Waterfall, trong Thiết kế, Nhà phân tích nghiệp vụ và Nhà phân tích hệ thống lần lượt làm việc trên các thiết kế logic và vật lý để chuẩn bị Tài liệu Đặc tả Yêu cầu Phần mềm và Đặc tả Thiết kế. Tuy nhiên, trong Iterative, có hai loại thiết kế. Phần đầu tiên ghi lại một cách tổng thể cách phần mềm sẽ được triển khai. Cái còn lại là tập hợp con của cái đầu tiên. Mỗi tập hợp con thiết kế này dành cho mỗi bản dựng và được tách biệt với bản dựng khác. Tập hợp con thiết kế cũng có thể được sửa đổi sau mỗi vòng xây dựng, nghĩa là chúng được hoàn thiện cho đến giai đoạn triển khai.

3. Thực hiện

Các nhà phát triển viết mã dựa trên tập hợp con của các thiết kế được chuyển từ giai đoạn Thiết kế. Các nhà phát triển cũng sẽ chuẩn bị Đặc tả chức năng cho mỗi tập hợp con.

4. Thử nghiệm

Tất cả các nhà phát triển, người thử nghiệm và cả người dùng sẽ tham gia vào từng nhóm thử nghiệm con. Tuy nhiên, trong khi người dùng doanh nghiệp chỉ kiểm tra một phạm vi giới hạn của bản dựng hiện tại, thì các nhà phát triển và người kiểm tra sẽ bao quát tất cả các chức năng mọi lúc. Hơn nữa, đối với bản dựng cuối cùng trước khi chuyển sang giai đoạn phát triển, ba bên không chỉ phải thực hiện thử nghiệm tập hợp con mà còn phải thử nghiệm toàn bộ hệ thống.

5. Triển khai

Tương tự như Waterfall, mọi thứ phải sẵn sàng trong giai đoạn này và giai đoạn triển khai để phát hành

6. Bảo trì

Một lần nữa, giống như Waterfall, việc mọi phần mềm đều cần bảo trì là điều không thể tránh khỏi. Do đó, một tập hợp con khác của mô hình lặp lại sẽ cần thiết cho Giai đoạn Bảo trì.

Sau mỗi tập hợp con, quy trình lặp lại Giai đoạn thiết kế và bắt đầu ở thiết kế tiếp theo cho đến thiết kế cuối cùng.

Khi nào nên sử dụng mô hình Lặp lại

• Các yêu cầu lớn và quan trọng vẫn được xác định nhưng những thay đổi nhỏ có thể được thêm vào khi phần mềm phát triển
• Các công nghệ mới đang được sử dụng và có một đường cong học tập cho các lập trình viên
• Phần mềm có thể gặp rủi ro vì mục tiêu của dự án có thể thay đổi theo thời gian
• Ưu điểm và nhược điểm

Thuận lợi

• Dễ dàng hơn để bắt đầu các dự án phức tạp
• Cho phép xem xét thường xuyên
• Cho phép thực hiện song song
• Các dự án vẫn có thể được quản lý như Waterfall với lịch trình và cột mốc rõ ràng
• Dễ dàng kiểm tra và khắc phục sự cố ở mỗi bản dựng
• Ít tốn kém hơn cho những thay đổi về phạm vi và yêu cầu
• Thích hợp cho các dự án lớn và cốt lõi
• Giao tiếp tốt hơn với người dùng doanh nghiệp vì phản hồi có thể được thu thập ở mỗi bản dựng

Nhược điểm 

• Rủi ro cao do kiến ​​trúc, thiết kế liên tục thay đổi
• Các vấn đề là không thể tránh khỏi khi tích hợp mỗi bản dựng
• Cần quản lý nhiều hơn để đảm bảo mỗi công trình đều đáp ứng tiêu chuẩn
• Việc triển khai chồng chéo có thể gây hỗn loạn
• Cần sự tham gia nhiều hơn của người dùng doanh nghiệp
• Dễ dàng hơn nhưng cần nhiều thời gian hơn cho mỗi lần thử nghiệm vì mỗi lần thử nghiệm phải bao gồm tất cả các công việc trước đó

Agile

Agile mở rộng lợi ích của Iterative. Bằng cách cung cấp sản phẩm nhanh chóng, Agile nhằm mục đích cải thiện sự hài lòng của người dùng và khả năng thích ứng của sản phẩm. Từ giai đoạn yêu cầu đến Giai đoạn triển khai, Agile chia sản phẩm thành các bản dựng nhỏ để có thể tiếp nhận càng nhiều phản hồi và thay đổi càng tốt. Thay vì quay lại giai đoạn thiết kế như Iterative, Agile đi thẳng vào giai đoạn triển khai và phát hành sản phẩm. Do đó, mỗi bản dựng chứa một số tính năng mới. Và đối với bản dựng cuối cùng, nó chứa tất cả các tính năng cần thiết của phần mềm.

1. Yêu cầu

Trong Agile, không phải mọi yêu cầu đều được thu thập ngay từ đầu. Do đó, việc liên lạc thường xuyên với người dùng là điều bắt buộc để thu nhận phản hồi sau mỗi lần phát hành. Tuy nhiên, tài liệu đề án kinh doanh vẫn cần thiết ngay từ đầu để mô tả rộng rãi phạm vi và mục tiêu của dự án. Sau đó, nhóm có thể đánh giá và sắp xếp lại tài nguyên ở mỗi bản dựng.

2. Thiết kế

Do sự không chắc chắn, Agile không dành nhiều thời gian để thiết kế. Nhà phân tích kinh doanh sẽ chủ yếu tập trung vào mục tiêu lớn của tất cả các bản dựng, tuân theo phạm vi được xác định trong Tài liệu tình huống kinh doanh. Tài liệu Đặc tả Yêu cầu Phần mềm và Đặc tả Thiết kế phải ngắn gọn và đơn giản, chỉ liệt kê những gì có trong bản dựng hiện tại.

3. Thực hiện

Trong Agile, các nhà phát triển có nhiều tự do hơn vì tài liệu rất hạn chế. Tuy nhiên, các nhà phát triển vẫn được yêu cầu tuân thủ nghiêm ngặt các tiêu chuẩn viết mã. Đặc tả chức năng của họ thường bao gồm các chức năng cốt lõi và bỏ qua các chi tiết.

4. Thử nghiệm

Người thử nghiệm của Agile có trách nhiệm lớn hơn vì họ có thông tin hạn chế về phần mềm. Trong khi đó, người dùng kiểm tra ở mức rất cao. Đôi khi, người dùng thậm chí còn bị loại khỏi giai đoạn thử nghiệm.

5. Triển khai

Thông thường sản phẩm có thể được xuất xưởng sau 2 - 3 tuần sau khi đáp ứng tất cả các yêu cầu. Kế hoạch triển khai có xu hướng tập trung vào cách cung cấp sản phẩm nhanh chóng nhưng với thông tin hạn chế và không có kế hoạch dự phòng vì một bản dựng khác sẽ xuất hiện.

6. Bảo trì

Không cần bảo trì trong Agile vì bản dựng tiếp theo sắp ra mắt và có thể được thực hiện trong bản dựng tiếp theo.

Agile không chú ý nhiều đến tài liệu theo cách mà Waterfall và Iterative làm. Mặc dù cùng một bộ tài liệu dự kiến ​​sẽ sẵn sàng ở mỗi giai đoạn, nhưng thông tin có thể tìm thấy trong mỗi tài liệu là rất hạn chế.

Khi nào áp dụng Agile

• Người dùng doanh nghiệp hoặc khách hàng không cung cấp yêu cầu chi tiết
• Dự án được định hướng theo tính năng
• Yêu cầu thay đổi linh hoạt
• Có nhiều người thử nghiệm và tài nguyên thử nghiệm lớn
• Đóng thông tin liên lạc trong nhóm và với người dùng doanh nghiệp

Thuận lợi

• Thực tế - cái gì quan trọng, thực hiện trước; cái gì không, để nó sau
• Linh hoạt - các yêu cầu mới có thể được nhập và giải quyết linh hoạt
• Các tính năng có thể được phát triển và phân phối nhanh chóng
• Các thành viên trong nhóm có nhiều tự do và linh hoạt hơn ở mỗi giai đoạn
• Ít tài liệu hơn để xử lý, có nghĩa là ít quy tắc hơn để tuân theo

Nhược điểm

• Rủi ro rất cao đối với việc bảo trì và khả năng mở rộng
• Không phù hợp với các dự án phức tạp và cốt lõi
• Người quản lý dự án phải luôn theo sát để kiểm tra xem các bản dựng có tuân theo phạm vi không
• Phụ thuộc rất nhiều vào phản hồi của người dùng, điều này có thể làm trì hoãn các dự án và cung cấp sai sản phẩm nếu người dùng doanh nghiệp không chắc chắn về những gì họ muốn
• Việc chuyển giao kiến ​​thức cho những người tham gia mới có thể khó khăn do thiếu tài liệu