Các mô hình phát triển phần mềm ảnh hưởng trực tiếp đến quá trình phát triển phần mềm. Nếu chọn sai mô hình phát triển, rất khó để các lập trình viên tạo nên những dự án thành công. Vì vậy, hãy tìm hiểu các mô hình phát triển phần mềm dưới đây nhé!
Mô hình phát triển phần mềm là gì?
Mô hình phát triển phần mềm hay quy trình phát triển phần là một tập hợp các kỹ thuật và hệ thống tổ chức để tạo ra phần mềm máy tính. Mục tiêu của các phương pháp tiếp cận khác nhau là cấu trúc các nhóm làm việc để họ có thể xây dựng các chức năng chương trình một cách hiệu quả nhất.
Các mô hình phát triển phần mềm cung cấp một framework để kiểm soát sự phát triển của hệ thống thông tin. Các framework này bao gồm phát triển chương trình cũng như các công cụ cần thiết để hỗ trợ quá trình phát triển.
Các mô hình phát triển phần mềm
Mỗi một mô hình phát triển phần mềm mô tả các quá trình từ góc nhìn riêng. Hiện nay có 9 loại mô hình chính thường được sử dụng, hãy cùng tìm hiểu về 9 loại mô hình đó nhé!
Mô hình thác nước – WaterFall
Đây là một mô hình trong đó các giai đoạn phát triển phần mềm được sắp xếp một cách chiến lược để sự bắt đầu của một giai đoạn phát triển được thực hiện trước khi hoàn thành bước đó. Một trong những lợi ích của nó là phù hợp cho khách hàng hiểu được mục tiêu chung của sản phẩm và nhóm phát triển, hiểu rõ hơn về sự tương tác giữa khách hàng với phần mềm và môi trường mà nó phải thực hiện.
Các giai đoạn của mô hình thác nước
- Analysis: Lên kế hoạch, phân tích và đặc tả yêu cầu
- Design: Thiết kế và đặc tả hệ thống
- Implementation: Lập trình và kiểm thử đơn vị
- Verification: Tích hợp hệ thống, kiểm thử hệ thống và tích hợp
- Deployment: Triển khai hệ thống
- Maintenance: Giao hàng, bảo trì, cải tiến
Khi nào nền sử dụng mô hình thác nước
- Khi có một ý tưởng rõ ràng về những gì bạn muốn kết quả cuối cùng như thế nào
- Khi khách hàng không thể thay đổi phạm vi của một dự án khi nó đã bắt đầu
- Khi nói đến thành công, khái niệm và định nghĩa là rất quan trọng
- Khi không còn nghi ngờ về những gì phải làm
Mô hình chữ V
Còn được gọi là mô hình 4 tầng, là một khái niệm được sử dụng trong nhiều quy trình phát triển, chẳng hạn như phát triển phần mềm. Mô hình V cung cấp các phương pháp quản lý chất lượng hỗ trợ và mô tả các giai đoạn riêng biệt này có thể tương tác với nhau, ngoài các giai đoạn phát triển dự án.
Các giai đoạn của mô hình V
Giai đoạn xác minh:
- Requirement Analysis – Phân tích yêu cầu: Bước đầu tiên của giai đoạn xác minh là hiểu được mong đợi của khách hàng về sản phẩm bằng cách giao tiếp, trao đổi
- System Design – Thiết kế hệ thống: Xác định các yêu cầu và mong đợi của khách hàng đối với sản phẩm, hệ thống thiết kế chi tiết phải được phát triển để phát triển sản phẩm
- Architectural Design – Thiết kế cấu trúc: Thiết kế hệ thống được tạch biệt thành các mô-đun khác nhau tùy theo chức năng của chúng. Việc truyền dữ liệu giữa các mô-đun nội bộ và các hệ thống khác được thừa nhận.
- Module Design – Thiết kế Mô-đun: Các thiết kế được tách biệt các mô-đun nhỏ hơn và chi tiết hơn
Giai đoạn xác thực:
- Unit Testing – Kiểm thử đơn vị: Loại bỏ lỗi ở cấp code hoặc đơn vị
- Integration Testing – Kiểm thử tích hợp: Xác nhận thông tin nội bộ giữa các mô-đun trong hệ thống
- System Testing – Kiểm thử hệ thống: Kiểm tra các yêu cầu chức năng và phi chức năng của ứng dụng đã phát triển.
- User Acceptance Testing (UAT) – Kiểm thử chấp nhận người dùng: Xác nhận khả năng sử dụng của hệ thống đã phát triển
Khi nào sử dụng mô hình chữ V
- Khi các yêu cầu và mục tiêu phải rõ ràng
- Có sẵn các điều kiện kỹ thuật như nguồn lực và chuyên gia
- Các lỗi hệ thống được phát hiện có thể chấp nhận được
Mô hình xoắn ốc
Là một loại mô hình phát triển phần mềm trong đó các hoạt động được tạo ra theo hình xoắc ốc và được thực hiện theo thứ tự mà chúng được chọn dựa trên phân tích rủi ro.
Trong mỗi lần lặp lại mô hình này, các mục tiêu hoặc phương án thay thế phải được lựa chọn dựa trên các đặc điểm, bao gồm kinh nghiệm cá nhân, các tiêu chí cần đáp ứng và các hình thức quản lý hệ thống.
Các giai đoạn của mô hình xoắn ốc
- Planing – Lập kế hoạch: Bước đầu tiên là xác định và thiết lập các mục tiêu cần đạt được. Sau đó, với tư cách là những lựa chọn thay thế, trình bày cách tốt nhất để đáp ứng các mục tiêu. Tất cả những điều này đòi hỏi phải trao đổi liên tục giữa khách hàng và nhóm phát triển
- Risk analysis – Phân tích rủi ro: Trong khi lập kế hoạch và hoàn thiện chiến lược giảm thiểu rủi ro, các mối nguy hiểm có thể xảy ra được xác định. Mỗi mối nguy hiểm được đánh dấu phải được kiểm tra kỹ lưỡng. Nguyên mẫu có thể được tạo ra để loại bỏ khả năng các yêu cầu không rõ ràng. Rủi ro được giảm thiểu bằng cách thực hiện các biện pháp ngăn chặn.
- Engineering – Kỹ thuật: Liên quan đến mã hóa, kiểm thử và triển khai của phần mềm. Sau khi đánh giá rủi ro, mô hình phát triển phần mềm được thông qua. Mô hình được sử dụng được xác định bởi mức độ rủi ro đã được công nhận cho giai đoạn đó.
- Evaluation – Đánh giá: Đánh giá của khách hàng về sản phẩm. Nó được quyết định có lặp lại chu kỳ hay không. Ở đây giai đoạn tiếp theo của dự án đang được lên kế hoạch.
Khi nào sử dụng mô hình xoắn ốc
- Mong muốn có bản phát hành phần mềm thường xuyên.
- Nguyên mẫu được sử dụng.
- Quản lý rủi ro và chi phí là rất quan trọng.
- Trong các dự án có rủi ro trung bình cao và rủi ro cao.
- Các tiêu chí yêu cầu là mơ hồ và khó hiểu.
- Có rất nhiều thay đổi đang diễn ra, và nó có thể xảy ra bất cứ lúc nào.
- Cho dù vì lý do kinh tế hay lý do khác, cam kết dự án dài hạn bị tổn hại.
Tiến trình hợp nhất – RUP
The Rational Unified Process – Tiến trình hợp nhất là một phương pháp phát triển ứng dụng phần mềm bao gồm một số công cụ hỗ trợ mã hóa sản phẩm cuối cùng và các hoạt động đi kèm với nó. RUP là một phương pháp hướng tới đối tượng để quản lý dự án và phát triển phần mềm chất lượng cao.
RUP là một tập hợp các phương pháp có thể điều chỉnh theo môi trường và nhu cầu của từng công ty, chứ không phải là một hệ thống với các quy trình cứng nhắc.
Các giai đoạn của RUP
- Bắt đầu: Ý tưởng được hình thành
- Thiết kế: Các trường hợp sử dụng và kiến trúc được thiết kế
- Xây dựng: Các hoạt động từ thiết kế đến thành phẩm
- Chuyển đổi: Các hoạt động tiếp theo để đảm bảo sự hài lòng của khách hàng
Khi nào thì sử dụng mô hình RUP
- Có sự thay đổi liên tục trong các yêu cầu.
- Khi bạn có thông tin và dữ liệu chính xác.
- Khi cần tích hợp nhất định trong suốt quá trình phát triển.
Mô hình tiếp cận lặp
Là một kỹ thuật phát triển phần mềm dựa trên mô hình phát hành và cập nhật theo chu kỳ và sự gia tăng ổn định các tính năng bổ sung.
Bắt đầu bằng việc lập kế hoạch và tiếp tục thông qua các chu kỳ phát triển lặp đi lặp lại với phản hồi liên tục của người dùng và các tính năng gia tăng được bổ sung, đạt đến đỉnh cao trong việc triển khai phần mềm khi kết thúc mỗi chu kỳ.
Các giai đoạn của mô hình tiếp cận lặp
- Giai đoạn bắt đầu: Liên quan đến phạm vi, nhu cầu và các mối nguy hiểm ở cấp độ cao hơn.
- Giai đoạn thiết kế: Tạo một kiến trúc khả thi giúp giảm thiểu rủi ro được xác định trong giai đoạn đầu tiên và đáp ứng các tiêu chí phi chức năng.
- Giai đoạn xây dựng: Dần dần hoàn thành các thành phần kiến trúc với mã sẵn sàng sản xuất, được phát triển thông qua phân tích yêu cầu chức năng, triển khai, thiết kế và thử nghiệm.
- Giai đoạn chuyển tiếp: Cung cấp hệ thống cho môi trường vận hành sản xuất trong giai đoạn chuyển tiếp.
Khi nào nên sử dụng?
- Cung cấp nhanh chóng các chức năng quan trọng là bắt buộc.
- Có một cải tiến công nghệ mới có thể được sử dụng để hoàn thành một dự án.
- Nhóm làm việc không quen thuộc với miền.
Mô hình nguyên mẫu
Khi tạo một phần mềm hoặc ứng dụng, điển hình là sử dụng một mô hình nguyên mẫu để cung cấp một phiên bản cũ hơn và đang hoạt động có thể được sử dụng làm bản trình bày hoặc mẫu của dự án
Tạo nguyên mẫu là một cách tuyệt vời để nhận đầu vào về các yêu cầu, chức năng và khả năng hoạt động, để quá trình phát triển cuối cùng của sản phẩm có thể diễn ra nhanh chóng và hiệu quả hơn.
Mô hình nguyên mẫu là một ứng dụng chức năng của sản phẩm đưa ra ý tưởng về tính năng cơ bản của sản phẩm hoặc hệ thống cuối cùng.
Các giai đoạn của mô hình nguyên mẫu
- Requirement: Bước đầu tiên của mô hình liên quan đến việc thiết lập các yêu cầu của hệ thống mong muốn.
- Design: Sau khi xác định các yêu cầu hệ thống mong muốn, một thiết kế ý tưởng cơ bản được hình thành.
- Prototype formation: Với sự trợ giúp của thiết kế ý tưởng cơ bản, một nguyên mẫu hoạt động được xây dựng cho hệ thống mong muốn.
- Initial Evaluation: Mẫu thử nghiệm được khách hàng thử nghiệm trong bước này để đánh giá các chức năng và hạn chế.
- Refining Prototype: Nguyên mẫu được tinh chỉnh thêm, phân tích đánh giá do khách hàng thực hiện.
- Refining Prototype: Sau khi quá trình tinh chỉnh được thực hiện, hệ thống cuối cùng được sản xuất để sử dụng trong thời gian thực.
Khi nào thì sử dụng mô hình nguyên mẫu?
- Khi yêu cầu của hệ thống mong muốn là rõ ràng.
- Khi các chức năng cơ bản của hệ thống mong muốn vẫn chưa được đánh giá.
- Nếu các yêu cầu của hệ thống kết quả cần phải được thay đổi.
- Để hiển thị các chức năng kỹ thuật của sản phẩm mong muốn bằng cách tạo nguyên mẫu.
- Thời gian phát triển bị giảm bớt
- Các thành phần có thể tái sử dụng
- Đánh giá ban đầu được đưa ra nhanh chóng
- Khách hàng có thể đưa ra phản hồi theo từng nguyên mẫu
Scrum
Khi giải quyết các thách thức, các dự án sử dụng kỹ thuật này đánh giá cao trí tuệ, kinh nghiệm và khả năng mà các thành viên trong nhóm phát triển mang lại.
Các hoạt động của dự án được hoàn thành trong các chu kỳ ngắn được gọi là chạy nước rút, tương đối dễ quản lý và được ưu tiên, cho phép dễ dàng theo dõi tiến độ.
So với các mô hình phát triển phần mềm khác, Scrum sẽ mang lại lợi ích cho các ý tưởng lớn hơn và một trong những lý do là các nhà phát triển cảm thấy tận tâm với các mục tiêu và chịu trách nhiệm cho sự thành công của ý tưởng.
Các giai đoạn của mô hình Scrum
- Product Backlog: Khi các nhiệm vụ ưu tiên được xác định kỹ lưỡng về dự án sẽ được tạo ra được thu thập.
- Sprint: là nhịp tim của quy trình scrum, khung thời gian một tháng trong đó diễn ra việc tạo ra một sản phẩm có thể giao hàng được.
- Burn Down: Là giai đoạn đo lường tiến độ của một dự án scrum. Khi mỗi lần chạy nước rút hoàn thành, scrum master sẽ chịu trách nhiệm cập nhật hình ảnh.
Khi nào thì sử dụng mô hình Scrum
- Cách tiếp cận này được sử dụng trong các tình huống cần có kết quả ngay lập tức.
- Trong những trường hợp khi có nhiều sự mơ hồ và các nhiệm vụ không được xác định rõ ràng.
- Khi khách hàng yêu cầu phương pháp phát triển tùy biến cao cho một sản phẩm nhất định.
Kanaban
Kanban là một framework nổi tiếng để phát triển phần mềm Agile và DevOps. Nó đòi hỏi giao tiếp năng lực thời gian thực và hoàn toàn cởi mở trong công việc.
Kanban là một cách tiếp cận linh hoạt của quản lý công việc trực quan thay đổi khi nhu cầu của nhóm thay đổi.
Kanban giúp trực quan hóa công việc để có thể hiểu rõ hơn, hiển thị cho người khác và những người quan tâm có thể được cập nhật. Nhờ đó, chúng ta có thể yên tâm rằng dịch vụ đủ khả năng thực hiện nhiệm vụ mà khách hàng yêu cầu.
Các giai đoạn của mô hình Kanban
- Xác định và giải thích chi tiết từng quy trình diễn ra trong sản xuất.
- Trực quan hóa các quy trình nêu trên: Chỉ định cho mỗi người trong số họ một thẻ và đặt nó trên bảng Kanban.
- Khi các quy trình đã được hình dung, điều quan trọng hơn là xác định các vấn đề, chẳng hạn như các nút thắt cổ chai, để chúng có thể được sửa đổi và sắp xếp hợp lý nếu cần.
- Giữ công việc đang tiến hành của bạn ở mức tối thiểu. Nghĩa là cố gắng hạn chế số lượng các hoạt động đã hoàn thành để nhân viên có thể tập trung vào những gì quan trọng nhất.
- Thực hiện các phép đo và hành động trên chúng. Vì Kanban là một kỹ thuật năng động nên điều quan trọng là phải kiểm tra kết quả và thực hiện các biện pháp để cải thiện tình hình.
Khi nào nên sử dụng mô hình Kanban.
- Khi cần loại bỏ các quy trình và thông lệ không cần thiết.
- Khi cần một mô hình cung cấp một quy trình phát triển trôi chảy.
- Khi đang hướng tới sự cải tiến liên tục của hệ thống.
Extreme Programming (XP)
Cho phép các chuyên gia thực hiện các thay đổi ngay cả sau khi quá trình lặp đã bắt đầu. Thông thường mất 1 đến 2 tuần để hoàn thành một lần lặp lại.
Cách tiếp cận XP là một phương pháp phát triển linh hoạt với mục tiêu phát triển và quản lý các dự án một cách hiệu quả, linh hoạt và kiểm soát. Nó được xây dựng dựa trên giao tiếp, tái sử dụng code được tạo và phản hồi.
Các giai đoạn của XP
- Planning: Các câu chuyện của người dùng được ưu tiên và chia thành các phiên bản nhỏ dựa trên danh tính của họ. Sẽ có sự đánh giá lại quy hoạch.
- Encoding: Làm việc với một code đơn giản trong giai đoạn này, chỉ thực hiện ở mức tối thiểu tuyệt đối để code đó hoạt động. Nó sẽ có thể có được nguyên mẫu.
- Testing: Điều này đảm bảo rằng một code tổng quát hơn được tạo ra, mà bất kỳ lập trình viên nào khác có thể hiểu và làm việc với nó.
- Launch: Nếu đã đến giai đoạn này, điều đó cho thấy đã thử nghiệm thành công tất cả các câu chuyện của người dùng hoặc các phiên bản nhỏ trong khi xem xét nhu cầu của khách hàng.
Khi nào thì sử dụng mô hình XP?
- Giao tiếp giữa khách hàng và nhóm phát triển luôn cởi mở.
- Thay đổi liên tục đòi hỏi một phản ứng nhanh chóng.
- Với lịch hoạt động linh hoạt, kế hoạch được mở.
- Phần mềm làm việc được ưu tiên hơn tất cả các dạng tài liệu khác.
- Tiêu chí thành công chính của dự án là nhu cầu của khách hàng và nỗ lực của nhóm dự án.
- Cộng tác từ xa trên các dự án.
Quy trình phát triển phần mềm
Sự thành công của phần mềm đều bắt đầu từ một kế hoạch và quy trình rõ ràng. Nếu bạn là người quản lý dự án, có thể bạn đã quen thuộc với các bước khác nhau trong quy trình phát triển phần mềm. Các bước này gần như giống nhau trong mọi quy trình phát triển phần mềm mà bạn sử dụng. Tuy nhiên, thứ tự và trình tự xảy ra của chúng có thể thay đổi tùy thuộc vào nhu cầu, mục tiêu cũng như quy mô dự án…
Phân tích, lập kế hoạch
Sau khi khách hàng và các bên liên quan yêu cầu một dự án, bước đầu tiên là phải lập kế hoạch. Điều này bao gồm:
- Sắp xếp
- Sự phân bố nguồn lực
- Lập kế hoạch dự án
- Ước tính chi phí
Giai đoạn lập kế hoạch đảm bảo bạn đang có khởi đầu thuận lợi. Vì vậy, hãy có gắng đảm bảo các bên liên quan đều có thể tham gia vào dự án
Yêu cầu
Bước tiếp theo là phải hiểu các yêu cầu kỹ thuật của dự án này. Hãy đặt các câu hỏi về các chi tiết cung quanh dự án, chẳng hạn như:
- Điều này sẽ giúp giải quyết vấn đề gì
- Ai sẽ sử dụng nó và tại sao?
- Loại dữ liệu đầu vào, đầu ra nào là cần thiết
- Bạn có cần tích hợp với các công cụ khác hoặc API không?
- Bạn sẽ xử lý vấn đề bảo mật như thế nào?
Sau khi nhóm phát triển của bạn nhận được câu trả lời cho những câu hỏi này, họ có thể bắt đầu vạch ra các yêu cầu kỹ thuật, điều kiện kiểm thử và quyết định technology stack. Giai đoạn này cũng là lúc bạn có thể bắt đầu lập kế hoạch sprint (nếu bạn đang sử dụng quy trình phát triển phần mềm Agile ) hoặc chia nhỏ các nhiệm vụ lớn thành các bước dễ thực hiện hơn .
Thiết kế
Với các yêu cầu đã có, đã đến lúc bắt đầu thiết kế sẽ hoạt động như thế nào. Tùy thuộc vào quy trình phát triển phần mềm mà bạn đang sử dụng, giai đoạn này có thể là bạn tạo các wireframe đơn giản để hiển thị cách các tương tác sẽ hoạt động trong phần mềm hoặc tạo các nguyên mẫu chính thức hơn để thử nghiệm với người dùng . Ngoài ra, có thể quyết định rằng bạn cần thêm phản hồi của người dùng và thực hiện chạy sprint thiết kế để nhanh chóng đưa một tính năng hoặc ý tưởng đến với người dùng.
Phát triển phần mềm
Giai đoạn này là khó khăn nhất và nhiều rủi ro nhất. Tuy nhiên, cho dù bạn đang làm việc với quy trình Agile, xây dựng một MVP hay sử dụng waterfall truyền thống, mục tiêu ở đây là bám sát Statement of Work (SOW), tránh vượt quá phạm vi và xây dựng phần mềm hiệu quả.
Kiểm thử
Khi nhóm của bạn đang phát triển phần mềm, rất có thể bạn sẽ đồng thời kiểm thử, theo dõi và sửa lỗi. Tuy nhiên, khi các tính năng hoàn tất và sản phẩm được cho là đã sẵn sàng hoạt động, bạn sẽ cần thực hiện một vòng kiểm thử chuyên sâu hơn. Điều này có nghĩa là phát hành sản phẩm cho nhóm kiểm thử một bản beta hoặc sử dụng các công cụ UX để theo dõi cách người dùng tương tác với sản phẩm.
Triển khai
Đã đến lúc khởi chạy phần mềm của bạn cho tất cả người dùng của bạn. Điều chúng ta đang nói đến ở đây là đẩy code của bạn vào sản xuất. Không nghĩ ra và thực hiện chiến lược tiếp cận thị trường (điều đó phụ thuộc nhiều hơn vào nhóm bán hàng và tiếp thị). Ở hầu hết các công ty phần mềm lớn, bước này được thực hiện tự động hóa khá nhiều bằng cách sử dụng mô hình triển khai liên tục.
Bảo trì và cập nhật
Yêu cầu và nhu cầu của khách hàng luôn phát triển. Và khi mọi người bắt đầu sử dụng phần mềm của bạn, chắc chắn họ sẽ tìm thấy lỗi, yêu cầu các tính năng mới và yêu cầu thêm hoặc chức năng khác. (Chưa kể đến việc bảo trì và bảo trì để đảm bảo thời gian hoạt động và sự hài lòng của khách hàng.)
Tất cả những yêu cầu này cần được chuyển trở lại product backlog để chúng có thể được ưu tiên và trở thành một phần trong lộ trình sản phẩm.
>>> Xem thêm: Cách viết đặc tả yêu cầu phần mềm đơn giản nhất
