Quy trình phát triển phần mềm là một quá trình thông minh và đòi hỏi độ chính xác cao, bao gồm nhiều bước khác nhau, từ lập kế hoạch, phân tích, thiết kế, phát triển và thực hiện, kiểm tra và bảo trì, với mục đích cuối cùng là tạo ra phần mềm hoàn hảo nhất cho khách hàng.
Vậy quy trình phát triển phần mềm là gì? Từng bước cụ thể trong quy trình phát triển phần mềm là như thế nào? Cùng theo dõi bài viết dưới đây của Đọc Sách Hay để có lời giải đáp chính xác nhất nhé!
Quy trình phát triển phần mềm là gì?
Dù bạn muốn hay không, mọi hoạt động của một dự án phát triển phần mềm đều phải được lên kế hoạch, chia thành các giai đoạn và sắp xếp theo một trình tự hợp lý. Thứ tự này được gọi là quy trình phát triển phần mềm hoặc thông thường hơn là vòng đời phát triển phần mềm (SDLC).
Vòng đời phát triển phần mềm (SDLC) là một mô hình quy trình bao gồm 6 giai đoạn phát triển phần mềm khác nhau: (1) Thu thập & Phân tích Yêu cầu, (2) Thiết kế, (3) Mã hóa / Thực hiện, (4) Kiểm tra, (5) Thực hiện, (6) bảo trì .
Theo Jory MacKay, mỗi giai đoạn của quy trình phát triển phần mềm cuối cùng sẽ mang lại một kết quả và giai đoạn tiếp theo của bạn sẽ sử dụng chính kết quả đó làm đầu vào.
Ví dụ, giai đoạn phân tích và lập kế hoạch sẽ làm rõ kỳ vọng của tất cả các bên liên quan bao gồm nhóm phát triển và khách hàng. Tại thời điểm khi tất cả các thành viên đã đồng ý về đầu ra mong muốn, giai đoạn thứ hai sẽ bắt đầu.
Vì ngành công nghiệp phần mềm là một ngành luôn thay đổi, nên rất có thể quá trình này sẽ không bao giờ kết thúc mà tiếp tục lặp lại để cải thiện phần mềm hiện tại hoặc phát triển các tính năng khác.
6 bước trong quy trình phát triển phần mềm
Thu thập & Phân tích Yêu cầu:
Trước khi đội ngũ kỹ thuật viên phần mềm có thể đưa ra ý tưởng chung cho bất kỳ phần mềm nào, điều cần thiết là nhóm phải thu thập các yêu cầu nghiệp vụ trong giai đoạn đầu tiên này. Tại thời điểm này, trọng tâm hàng đầu của các bên liên quan và người quản lý dự án là lưu ý những điều chính xác cần thiết từ bất kỳ phần mềm nào đang được xem xét. Có một số câu hỏi được đặt ra ở giai đoạn này, bao gồm:
- Ai được phép sử dụng phần mềm này?
- Phần mềm sẽ được sử dụng như thế nào sau khi hoàn thành?
- Loại dữ liệu nào nên được thêm vào phần mềm?
- Kết quả đầu ra của phần mềm này là gì?
Khi những câu hỏi chung này được trả lời, một phác thảo chung sẽ được tạo ra để các nhà phát triển phần mềm tập trung vào. Dữ liệu này sau đó được phân tích để đảm bảo tính hợp lệ của nó và bất kỳ khả năng nào để kết hợp dữ liệu giống nhau. Cuối cùng, một tài liệu về đặc tả yêu cầu được chuẩn bị để làm kim chỉ nam cho cấp độ tiếp theo của quy trình phát triển phần mềm.
Thiết kế:
Đây là giai đoạn tiếp theo của quy trình phát triển phần mềm. Trong giai đoạn này, thiết kế nháp được chuẩn bị cho phần mềm từ các đặc tả yêu cầu của giai đoạn 1. Các thiết kế hệ thống giúp xác định phần cứng cũng như các yêu cầu hệ thống. Nó cũng giúp định nghĩa một hệ thống tổng thể trong kiến trúc phần mềm.
Các đặc tả thiết kế cho hệ thống đóng vai trò là đầu vào cho giai đoạn sau của mô hình phát triển phần mềm. Trong giai đoạn cụ thể này, các chiến lược kiểm tra được phát triển bởi người kiểm tra bằng cách đề cập đến những thứ cần kiểm tra và các cách để kiểm tra nó.
Mã hóa / Thực hiện:
Sau khi nhận được tài liệu thiết kế cho phần mềm được tạo, công việc sau giai đoạn thiết kế được chia đều thành các đơn vị và mô-đun khác nhau. Đây là giai đoạn mà mã hóa thực sự bắt đầu. Trọng tâm chính của giai đoạn là phát triển các mã hoàn hảo bởi các nhà phát triển. Giai đoạn cụ thể này là giai đoạn dài nhất trong toàn bộ giao thức.
Kiểm tra:
Giai đoạn cụ thể này rất quan trọng đối với các nhà phát triển. Nếu bất kỳ điều gì sai trong giai đoạn thử nghiệm hoặc bất kỳ lỗi nào được ghi nhận trong các mã, nó có thể dẫn đến việc lặp lại quá trình mã hóa và chu kỳ tiếp tục cho đến khi hoàn thành như cũ. Trong giai đoạn này, tất cả các biến thể của kiểm thử chức năng như kiểm thử tích hợp, kiểm thử đơn vị, kiểm thử hệ thống, kiểm thử chấp nhận và kiểm thử phi chức năng đều được thực hiện.
Triển khai:
Sau khi tất cả các lỗi từ mã hóa được loại bỏ trong giai đoạn thử nghiệm, bước tiếp theo được gọi là giai đoạn triển khai. Mã cuối cùng được thực hiện vào phần mềm và sau đó triển khai hoặc giao cho khách hàng sử dụng.
Khi sản phẩm đang được cung cấp cho khách hàng tiềm năng, điều đầu tiên cần làm để đảm bảo rằng sản phẩm hoạt động tốt trên quy mô lớn là tiến hành thử nghiệm beta. Nếu có bất kỳ khả năng thay đổi nào hoặc có những lỗi có thể mắc phải trong quá trình triển khai, lập tức báo cáo cho nhóm kỹ sư rằng các lỗi của nó hoạt động tốt trong thời gian thực. Sau khi các thay đổi được thực hiện với tất cả các lỗi đã được khắc phục, quá trình phân tán hoặc triển khai cuối cùng sẽ được thiết lập.
Bảo trì:
Một khi khách hàng bắt đầu sử dụng phần mềm được phát triển tốt, các vấn đề thực tế bắt đầu xuất hiện theo thời gian. Điều này không có nghĩa là phần mềm sẽ bị hỏng. Tuy nhiên, nó có thể yêu cầu các vấn đề thỉnh thoảng xuất hiện lặp đi lặp lại. Quá trình cụ thể này được gọi là bảo trì cho sản phẩm hoặc phần mềm đã hoàn thiện.
Mô hình quy trình phát triển phần mềm
Mặc dù SDLC đã nêu ở trên có vẻ giống như một kế hoạch từng bước để xây dựng phần mềm, nhưng nó thực sự mang tính hướng dẫn nhiều hơn.
Trong những năm qua, một số quy trình phát triển phần mềm khác nhau đã được chính thức hóa để giải quyết các dự án ngày càng phức tạp hơn. Nhưng cái nào phù hợp với bạn?
Thực tế, quy trình phát triển bạn sử dụng sẽ phụ thuộc vào mục tiêu của bạn, quy mô của dự án và nhóm của bạn, và các yếu tố khác. Để giúp bạn dễ dàng hơn trong việc đưa ra quyết định, dưới đây là 5 quy trình phát triển phần mềm tốt nhất với những ưu và nhược điểm cho từng quy trình.
Mô hình thác nước
Nó là gì:
Quy trình phát triển phần mềm Waterfall (còn được gọi là “mô hình tuần tự tuyến tính” hoặc “Mô hình vòng đời cổ điển”) là một trong những mô hình lâu đời nhất và truyền thống nhất để xây dựng phần mềm. Ở dạng cơ bản nhất của nó, bạn có thể coi phương pháp Waterfall như làm theo từng bước của SDLC theo trình tự, bạn phải hoàn thành từng bước một trước khi tiếp tục. Tuy nhiên, trong hầu hết các ứng dụng thực tế, các giai đoạn trùng lặp đôi chút, với phản hồi và thông tin được chuyển giữa chúng.
Một số người cũng thích gọi đây là một quá trình “theo kế hoạch” vì để hoàn thành một dự án, trước tiên bạn cần biết mọi thứ cần phải được thực hiện và theo trình tự. Do đó, tên “Waterfall” khi mỗi phần chảy sang phần tiếp theo.
Các giai đoạn:
- Lập kế hoạch
- Yêu cầu
- Thiết kế hệ thống và phần mềm
- Thực hiện
- Thử nghiệm
- Triển khai
- Bảo trì / Cập nhật
Dành cho ai: Các nhóm có cấu trúc cứng nhắc và nhu cầu tài liệu.
Do cấu trúc cứng nhắc và thời gian lập kế hoạch trước lớn, quy trình phát triển phần mềm Waterfall hoạt động tốt nhất khi các mục tiêu, yêu cầu và nền tảng công nghệ của bạn không có khả năng thay đổi hoàn toàn trong quá trình phát triển (chẳng hạn như trong các dự án một lần ngắn hơn).
Nói một cách thực tế hơn, quy trình Waterfall phù hợp nhất với các tổ chức lớn hơn (như các cơ quan chính phủ) yêu cầu đăng ký và tài liệu về tất cả các yêu cầu và phạm vi trước khi bắt đầu dự án.
Nó không dành cho ai:
Nếu bạn đang thử nghiệm một sản phẩm mới, cần phản hồi của người dùng giữa luồng hoặc muốn năng động hơn trong quá trình phát triển của mình, thì việc làm theo quy trình phát triển Waterfall có thể không phù hợp với bạn.
Mặc dù dễ hiểu, nhưng nhược điểm lớn nhất của quy trình này là nó thiếu tính linh hoạt. Bạn sẽ không tạo và thử nghiệm MVP hoặc nguyên mẫu và thay đổi suy nghĩ của mình trong suốt quá trình. Và bởi vì điều này, trừ khi phạm vi của bạn được viết chặt chẽ, bạn có thể sẽ đi sai đường mà không biết cho đến ngày ra mắt.
Mô hình Agile và Scrum
Nó là gì:
Quy trình phát triển phần mềm Agile (và phương pháp luận phổ biến nhất của nó, Scrum) lựa chọn cách tiếp cận năng động và lặp đi lặp lại để phát triển.
Trái ngược với quy trình tuần tự, nghiêm ngặt của quy trình Waterfall, trong Agile, các nhóm chức năng chéo làm việc trong “Sprint” từ 2 tuần đến 2 tháng để xây dựng và phát hành phần mềm có thể sử dụng cho khách hàng để lấy ý kiến phản hồi.
Agile là tất cả về việc di chuyển nhanh chóng, phát hành thường xuyên và đáp ứng nhu cầu thực sự của người dùng, ngay cả khi nó đi ngược lại với những gì trong kế hoạch ban đầu của bạn. Điều này có nghĩa là bạn không cần một danh sách đầy đủ các yêu cầu và một kế hoạch công việc hoàn chỉnh trước khi bắt đầu công việc. Thay vào đó, về cơ bản bạn đang di chuyển theo một hướng với sự hiểu biết rằng bạn sẽ thay đổi hướng đi trên đường đi.
Giả sử bạn đang xây dựng một tính năng mới cho một trong các sản phẩm của mình có thể có các tính năng X, Y và Z. Thay vì dành hàng tháng trời để xây dựng mọi thứ, bạn sẽ dành 2 – 4 tuần để tạo ra mức tối thiểu vừa đủ hữu ích và có thể sử dụng được (trong cái gọi là “Agile Sprint”) và sau đó phát hành nó cho khách hàng của bạn.
Điều này cho phép các vòng phản hồi chặt chẽ hơn trong suốt quá trình phát triển phần mềm để bạn có thể thích ứng và phản ứng với nhu cầu thực tế của khách hàng.
Các giai đoạn:
- Tồn đọng sản phẩm
- Sprint backlog
- Sprint (Thiết kế & Phát triển)
- Phát hành phần mềm làm việc
- Phản hồi và xác nhận (thêm vào công việc tồn đọng)
- Lập kế hoạch chạy nước rút tiếp theo
Dành cho ai: Các nhóm năng động cập nhật liên tục các sản phẩm.
Nhờ bản chất năng động và tập trung vào người dùng, Agile là quy trình phát triển phần mềm được hầu hết các công ty khởi nghiệp và công ty công nghệ thử nghiệm sản phẩm mới hoặc cập nhật liên tục cho những sản phẩm lâu đời.
Khi việc thực hiện các bản phát hành nhỏ và thu thập phản hồi của người dùng trở nên dễ dàng hơn, Agile cho phép các công ty di chuyển nhanh hơn và thử nghiệm các lý thuyết mà không phải mạo hiểm toàn bộ sinh kế của họ trên một bản phát hành lớn mà người dùng của họ ghét. Ngoài ra, vì quá trình thử nghiệm diễn ra sau mỗi lần lặp lại nhỏ, nên việc theo dõi lỗi hoặc quay trở lại phiên bản sản phẩm trước đó sẽ dễ dàng hơn nếu có điều gì đó nghiêm trọng hơn bị hỏng.
Nó không dành cho ai: Team với ngân sách cực kỳ chặt chẽ và các mốc thời gian.
Mặt khác, bản chất năng động của Agile có nghĩa là các dự án có thể dễ dàng vượt quá khung thời gian hoặc ngân sách ban đầu của chúng, tạo ra xung đột với kiến trúc hiện tại hoặc bị trật bánh do quản lý yếu kém. Điều này có nghĩa là nó không phải là lựa chọn tốt nhất cho các đội không thích rủi ro hoặc thiếu nguồn lực.
Ngoài ra, việc sử dụng Agile và Scrum cần có sự cống hiến và hiểu biết vững chắc về quy trình cơ bản để thực hiện đúng cách. Đó là lý do tại sao điều quan trọng là phải có ít nhất một chuyên gia Scrum chuyên sâu trong nhóm của bạn để đảm bảo các bước chạy nước rút và các mốc quan trọng đang được thực hiện và dự án không bị đình trệ.
Mô hình tăng dần và lặp đi lặp lại
Các quy trình phát triển phần mềm gia tăng và lặp đi lặp lại là điểm trung gian giữa cấu trúc và lập kế hoạch trước của quy trình Waterfall và tính linh hoạt của Agile.
Mặc dù cả hai đều theo ý tưởng tạo ra các phần mềm nhỏ và hiển thị chúng cho người dùng phản hồi, nhưng chúng khác nhau về những gì bạn tạo ra trong mỗi lần phát hành.
Trong quy trình phát triển phần mềm Gia tăng, mỗi mức tăng “gia tăng” của sản phẩm sẽ thêm vào một dạng đơn giản của một chức năng hoặc tính năng mới. Bạn có thể tưởng tượng nó tượng tự như lên một kế hoạch tổng thể, xây dựng một MVP chỉ với chức năng cốt lõi và sau đó thêm các tính năng dựa trên phản hồi.
Tuy nhiên, trong quá trình phát triển phần mềm Lặp lại, mỗi phiên bản bạn phát hành bao gồm một phiên bản của tất cả các tính năng đã được lên kế hoạch của bạn. Bạn có thể tưởng tượng như việc xây dựng một phiên bản v0.1 với phiên bản đơn giản nhất của từng tính năng và sau đó nâng cấp nó trên diện rộng trong v0.2, v0.3,….
Các giai đoạn tăng dần:
- Lập kế hoạch gia tăng
- Thông số kỹ thuật
- Phát triển
- Thẩm định
- Lặp lại cho mỗi phiên bản
Các giai đoạn lặp lại:
- Phân tích
- Thiết kế
- Phát triển
- Thử nghiệm (Lặp lại những điều này cho đến khi bạn sẵn sàng phát hành)
Dành cho ai: Các nhóm có yêu cầu rõ ràng muốn linh hoạt hơn so với phương pháp Waterfall cung cấp.
Cả hai điều này đều bổ sung một mức độ linh hoạt nhất định cho quy trình phát triển phần mềm của bạn mà không cần đưa ra một kế hoạch tổng thể ngoài cửa sổ, khiến chúng trở nên lý tưởng cho các dự án lớn với phạm vi xác định (hoặc các nhóm có ít rủi ro hơn).
Với quy trình gia tăng, bạn sẽ nhận được phản hồi sớm về tính năng cốt lõi của mình, điều này có thể giúp bạn xác thực trường hợp kinh doanh của mình ngay lập tức. Trong khi đó, phương pháp lặp đi lặp lại mang đến cho người dùng một cái nhìn đầu vào những gì các sản phẩm đầy đủ có thể có được, từ đó bạn có thể nhận được phản hồi tốt hơn và tập trung hơn.
Không dành cho ai: Nhóm không có kế hoạch công nghệ dài hạn rõ ràng.
Thật không may, việc cố gắng thêm cấu trúc vào một cách tiếp cận linh hoạt có những vấn đề riêng. Có thể các mục tiêu, quy trình hoặc công nghệ của công ty bạn thay đổi theo thời gian, khiến các lần lặp trước đó trở nên vô dụng hoặc bị hỏng. Hoặc có lẽ cơ sở mã của bạn trở nên lộn xộn và cồng kềnh do thêm chức năng mà không tìm kiếm hiệu quả.
Ngoài ra, cả hai mô hình này (và đặc biệt là cách tiếp cận lặp lại) đều đòi hỏi phải có quy hoạch và xây dựng kiến trúc từ rất sớm. Có nghĩa là chúng không lý tưởng cho các dự án hoặc nhóm nhỏ hơn, những người vẫn đang thử nghiệm các trường hợp sử dụng và cố gắng tìm sản phẩm phù hợp với thị trường.
Mô hình hình chữ V
Quy trình phát triển phần mềm hình chữ V là sự tiếp thu của phương pháp Waterfall cổ điển, và khắc phục nhược điểm lớn nhất của nó: Thiếu thử nghiệm.
Thay vì làm việc tuần tự trong quá trình phát triển và lưu tất cả thử nghiệm của bạn cho đến cuối, mỗi giai đoạn của quy trình hình chữ V được tuân theo một bước “xác nhận và xác minh” nghiêm ngặt, nơi các yêu cầu được kiểm tra trước khi tiếp tục.
Các giai đoạn:
- Yêu cầu
- Thông số kỹ thuật
- Thiết kế cao cấp
- Thiết kế cấp thấp
- Phát triển
- Kiểm tra đơn vị
- Thử nghiệm hội nhập
- Thử nghiệm hệ thống
- Kiểm tra chấp nhận
Dành cho ai: Các nhóm làm việc trong các dự án nhỏ hơn với phạm vi hẹp.
Quá trình phát triển phần mềm hình chữ V là rất tốt nếu bạn có một dự án nhỏ với các yêu cầu và phạm vi tương đối rõ ràng (và tĩnh). Thay vì gặp rủi ro khi làm theo một kế hoạch chỉ để tìm ra các vấn đề ở giai đoạn cuối, nó cung cấp nhiều cơ hội để kiểm tra trong quá trình thực hiện.
Không dành cho ai: Các nhóm muốn linh hoạt hơn và nhận được phản hồi sớm từ người dùng.
Ngay cả những kế hoạch tốt nhất cũng thường đi chệch hướng. Và mặt trái của quá trình này về cơ bản là mặt trái của các tính năng tích cực của nó.
Đầu tiên, thiếu sự kiểm soát do bạn đang tuân theo một cấu trúc cứng nhắc và lịch trình thử nghiệm. Nếu không có thông tin đầu vào và phản hồi sớm từ người dùng, bạn vẫn có nguy cơ xây dựng sai phần mềm cho trường hợp kinh doanh của mình. Và cuối cùng, nếu bạn đang xây dựng bất cứ thứ gì ngoài một dự án nhỏ, đơn giản, thì gần như không thể tạo trước một kế hoạch phát triển đủ cụ thể.
Mô hình Spiral (Xoắn ốc)
Quy trình phát triển phần mềm Spiral kết hợp trọng tâm của quy trình hình chữ V vào kiểm tra và đánh giá rủi ro với tính chất gia tăng của quy trình tăng dần và lặp lại, và Agile.
Khi đã có kế hoạch cho một lần lặp lại hoặc một cột mốc cụ thể, bước tiếp theo là thực hiện phân tích rủi ro chuyên sâu để xác định các lỗi hoặc các khu vực có nguy cơ quá mức. Ví dụ: giả sử như một phần của kế hoạch, bạn đưa ra một tính năng chưa được khách hàng xác thực. Thay vì chỉ thêm nó vào cột mốc hiện tại của bạn, bạn có thể xây dựng một nguyên mẫu để thử nghiệm với người dùng trước khi chuyển sang giai đoạn phát triển đầy đủ. Sau khi hoàn thành mỗi cột mốc, phạm vi sẽ mở rộng ra xa hơn (giống như hình xoắn ốc) và bạn bắt đầu với việc lập kế hoạch và đánh giá rủi ro khác.
Các giai đoạn:
- Lập kế hoạch
- Đánh giá rủi ro
- Phát triển và xác nhận
- Đánh giá kết quả và lập kế hoạch cho “vòng lặp” tiếp theo
Dành cho ai: Các nhóm không thích rủi ro làm việc trong các dự án lớn.
Rõ ràng, mục đích cốt lõi của một quy trình như thế này là giảm thiểu rủi ro. Nếu bạn đang làm việc trên một dự án lớn hoặc quan trọng đòi hỏi mức độ cao của tài liệu và xác nhận trong quá trình thực hiện, thì việc đi theo một con đường như thế này có thể có ý nghĩa. Nó cũng có lợi nếu khách hàng không hoàn toàn chắc chắn về các yêu cầu và đang mong đợi những chỉnh sửa lớn trong quá trình phát triển sản phẩm.
Nó không dành cho ai: Hầu hết mọi người.
Trong khi lý thuyết là tuyệt vời, quy trình phát triển phần mềm xoắn ốc hiếm khi thực sự được đưa vào thực tế do thời gian và chi phí liên quan đến việc thực hiện một cách tiếp cận được tính toán như vậy. Thay vào đó, nó chủ yếu được sử dụng như một ví dụ về cách suy nghĩ chín chắn về cách tiếp cận lặp đi lặp lại để phát triển.
Khi bạn đang ở giai đoạn đầu của việc xây dựng một phần mềm mới, bạn có thể cảm thấy như những con đường đặt ra trước mặt bạn là vô tận. Nhưng thay vì bị choáng ngợp, hãy dành một giây và nhớ rằng mọi quy trình và phương pháp phát triển phần mềm đều tuân theo bốn nguyên tắc cơ bản:
- Hiểu nó: Biết những gì bạn muốn xây dựng và tại sao.
- Xây dựng nó: Thiết kế và phát triển phần mềm làm việc.
- Kiểm tra nó: Đưa nó cho người dùng để thử và thu thập phản hồi.
- Phát triển nó: Sử dụng phản hồi đó để làm cho nó tốt hơn.
Các bước tương tự sẽ diễn ra để chọn quy trình phát triển phần mềm phù hợp với bạn. Bắt đầu bằng cách hiểu các bước của SDLC, sau đó chọn quy trình phù hợp với bạn và nhóm của bạn, dùng thử và thu thập phản hồi từ nhóm của bạn. Và hãy nhớ, quy trình phát triển phần mềm là một vòng đời. Nếu bạn không làm đúng trong lần đầu tiên, hãy hiểu tại sao nó không hoạt động, sau đó chọn một quy trình khác và bắt đầu lại.
Hy vọng với những thông tin cung cấp trong bài viết hôm nay, các bạn đã có thêm những thông tin hữu ích về quy trình phát triển phần mềm, hiểu rõ về các giai đoạn để phát triển một phần mềm thành công, phù hợp với yêu cầu. Hẹn gặp lại các bạn trong các bài viết tiếp theo của mình nhé!
