Tổng quan về Quy trình Phát triển Phần mềm (SDLC)

Table of Contents hide

2.5 Mô hình dựa trên thành phần

2.6 Phương pháp nguyên mẫu

2.7 Phương pháp XP

2.8 Phương pháp Quy trình thống nhất (UP)

2.9 Tìm hiểu thêm

Chu trình phát triển phần mềm cung cấp cho các tổ chức một phương pháp có hệ thống, từng bước để phát triển phần mềm thành công bằng cách thu thập các yêu cầu ban đầu cho các sản phẩm mới. Đây là một quy trình có hệ thống để xây dựng phần mềm nhằm đảm bảo chất lượng và độ chính xác của phần mềm được xây dựng và đáp ứng mong đợi của khách hàng.

Các mô hình phát triển chính bao gồm mô hình thác nước, mô hình gia tăng, mô hình xoắn ốc, mô hình phun, mô hình thông minh, mô hình V, mô hình RAD, mô hình CBSD, phương pháp nguyên mẫu, phương pháp XP, phương pháp RUP, v.v.

Mô hình thác nước

Mô hình thác nước, còn được gọi là phương pháp chu trình, là mô hình phát triển được sử dụng phổ biến nhất trong phương pháp chu trình. Nó chia quy trình phát triển phần mềm thành sáu giai đoạn: lập kế hoạch phần mềm, phân tích yêu cầu, thiết kế phần mềm, mã hóa chương trình, kiểm tra phần mềm và vận hành bảo trì. Để đạt được thứ tự cố định từ trên xuống dưới, giống như một thác nước, chúng rơi xuống từng bước.

Kế hoạch phần mềm: Chủ yếu xác định các mục tiêu phát triển và tính khả thi của phần mềm.
Phân tích yêu cầu: Sau khi xác nhận rằng việc phát triển phần mềm là khả thi, thực hiện phân tích chi tiết các chức năng mà phần mềm cần đạt được. Giai đoạn phân tích yêu cầu là một giai đoạn rất quan trọng. Làm tốt công việc ở giai đoạn này sẽ tạo nền tảng vững chắc cho sự thành công của toàn bộ dự án phát triển phần mềm.
Thiết kế phần mềm: Thiết kế toàn bộ hệ thống phần mềm, chẳng hạn như thiết kế khung hệ thống, thiết kế cơ sở dữ liệu, v.v., dựa trên kết quả phân tích yêu cầu. Thiết kế phần mềm thường được chia thành thiết kế tổng thể (thiết kế phác thảo) và thiết kế chi tiết.
Mã chương trình: Chuyển đổi kết quả thiết kế phần mềm thành mã chương trình có thể được máy tính chạy. Trong quá trình lập trình, cần phải xây dựng một quy định lập trình thống nhất và tuân thủ tiêu chuẩn để đảm bảo tính dễ đọc của chương trình, dễ bảo trì và cải thiện hiệu suất hoạt động của chương trình.
Kiểm tra phần mềm: Sau khi hoàn thành thiết kế phần mềm, nó phải trải qua kiểm tra nghiêm ngặt để tìm và sửa chữa các vấn đề trong phần mềm trong suốt quá trình thiết kế. Trong quá trình kiểm tra, cần phải thiết lập một kế hoạch kiểm tra chi tiết và thực hiện kiểm tra theo đúng kế hoạch kiểm tra để giảm thiểu tính tùy tiện của việc kiểm tra. Bảo trì phần mềm:
Bảo trì phần mềmlà giai đoạn dài nhất trong chu trình sống của phần mềm. Sau khi phần mềm được phát triển và đưa vào sử dụng, do nhiều lý do khác nhau, phần mềm không thể tiếp tục đáp ứng yêu cầu của người dùng. Để kéo dài tuổi thọ của phần mềm, phần mềm phải được bảo trì.

Mô hình chuyển đổi

Mô hình chuyển đổi (mô hình tiến hóa) dựa trên sự phát triển nhanh chóng của một nguyên mẫu. Theo phản hồi và đề xuất được đưa ra bởi người dùng trong quá trình gọi nguyên mẫu, nguyên mẫu được cải tiến để có được một phiên bản mới của nguyên mẫu, và quá trình này được lặp lại cho đến khi nó tiến hóa thành sản phẩm phần mềm cuối cùng.

Mô hình xoắn ốc

Mô hình xoắn ốc kết hợp mô hình thác nước và mô hình chuyển đổi. Nó kết hợp những ưu điểm của cả hai và thêm phân tích rủi ro. Nó dựa trên nguyên mẫu và quay từ trong ra ngoài theo hình xoắn ốc. Mỗi vòng quay yêu cầu lập kế hoạch, phân tích rủi ro, kỹ thuật thực hiện, đánh giá khách hàng và các hoạt động khác, và một phiên bản mới của nguyên mẫu được phát triển. Sau vài vòng xoắn, hệ thống cuối cùng được thu được.

Mô hình phun

Mô hình phun cung cấp hỗ trợ cho việc tái sử dụng phần mềm và tích hợp nhiều hoạt động phát triển trong chu trình sống, và chủ yếu hỗ trợ các phương pháp phát triển hướng đối tượng. Thuật ngữ “phun” tự nó thể hiện các đặc điểm của sự lặp lại và không có khoảng trống. Một phần nhất định của hệ thống thường lặp lại công việc nhiều lần, và các chức năng liên quan được thêm vào hệ thống đã tiến hóa trong mỗi lần lặp. Khoảng trống không có nghĩa là không có ranh giới rõ ràng giữa phân tích, thiết kế và mã hóa trong các hoạt động phát triển.

Mô hình V

Trong mô hình phát triển, kiểm tra thường được sử dụng như một suy nghĩ sau để khắc phục tình hình, nhưng cũng có một mô hình phát triển tập trung vào kiểm tra, đó là mô hình V. Mô hình V chỉ được công nhận mơ hồ trong ngành công nghiệp phần mềm. Mô hình V khẳng định rằng kiểm tra không phải là một suy nghĩ sau, mà là một quy trình quan trọng như quy trình phát triển.

Mô hình V mô tả một số cấp độ kiểm tra khác nhau và giải thích các giai đoạn khác nhau trong chu trình sống tương ứng với các cấp độ này. Trong hình, sự giảm xuống bên trái là các giai đoạn khác nhau của quy trình phát triển, và các phần tương ứng là các phần tăng lên bên phải, tức là các giai đoạn khác nhau của quy trình kiểm tra.

Xin lưu ý rằng việc đặt tên cho giai đoạn kiểm tra có thể khác nhau ở các tổ chức khác nhau. Giá trị của mô hình V là nó cho thấy rõ các cấp độ khác nhau tồn tại trong quy trình kiểm tra, và mô tả rõ ràng sự tương ứng giữa các giai đoạn kiểm tra này và các giai đoạn khác nhau trong quy trình phát triển:

Mục đích chính của kiểm tra đơn vị là xử lý các lỗi khác nhau có thể tồn tại trong quá trình mã hóa. Ví dụ: người dùng nhập một lỗi trong giá trị biên trong quá trình xác minh.
Mục đích chính của kiểm tra tích hợp là giải quyết các vấn đề có thể xảy ra trong thiết kế chi tiết, đặc biệt là kiểm tra các lỗi có thể xảy ra trong giao diện giữa mỗi đơn vị và các phần chương trình khác.
Kiểm tra hệ thống chủ yếu dành cho thiết kế tổng thể, kiểm tra xem hệ thống nói chung có hoạt động hiệu quả hay không. Ví dụ: Liệu hiệu suất cao mong đợi có đạt được trong các cài đặt sản phẩm hay không.
Kiểm tra chấp nhận thường được thực hiện bởi các chuyên gia kinh doanh hoặc người dùng để xác nhận rằng sản phẩm có thể thực sự đáp ứng nhu cầu kinh doanh của người dùng.

Mô hình gia tăng

Các mô hình gia tăng, giống như các mô hình thực hiện nguyên mẫu và các phương pháp tiến hóa khác, về cơ bản là lặp lại. Nhưng không giống như việc thực hiện nguyên mẫu, mô hình gia tăng nhấn mạnh rằng mỗi gia tăng phát hành một sản phẩm có thể hoạt động. Các gia tăng sớm là phiên bản “có thể tách rời” của sản phẩm cuối cùng, nhưng chúng cung cấp các chức năng phục vụ người dùng và cung cấp một nền tảng để người dùng đánh giá.

Đặc điểm của mô hình gia tăng là việc giới thiệu khái niệm gói gia tăng. Bạn không cần phải chờ đợi cho đến khi tất cả các yêu cầu được đưa ra, chỉ cần các gói gia tăng của một yêu cầu nhất định được đưa ra, bạn có thể bắt đầu phát triển. Mặc dù một gói gia tăng nhất định có thể cần được điều chỉnh thêm để phù hợp với nhu cầu của khách hàng và cần phải thay đổi, miễn là gói gia tăng đủ nhỏ, tác động của nó có thể chịu đựng được cho toàn bộ dự án.

Mô hình RAD Mô hình Phát triển Ứng dụng Nhanh (RAD) là một mô hình quy trình phát triển phần mềm gia tăng nhấn mạnh chu trình phát triển rất ngắn.

Mô hình RAD là một biến thể “tốc độ cao” của mô hình thác nước, đạt được phát triển nhanh chóng thông qua việc sử dụng rộng rãi các thành phần tái sử dụng và phương pháp xây dựng dựa trên thành phần. Nếu các yêu cầu được hiểu rõ và phạm vi của dự án được hạn chế, mô hình này có thể được sử dụng để nhanh chóng tạo ra một “hệ thống thông tin” hoàn chỉnh.

Quá trình bắt đầu với mô hình hóa kinh doanh, tiếp theo là mô hình hóa dữ liệu, mô hình hóa quy trình, tạo ứng dụng, kiểm tra và lặp lại. Quy trình phần mềm sử dụng mô hình RAD được hiển thị trong hình dưới đây.

Các nhiệm vụ cần hoàn thành trong mỗi giai đoạn hoạt động của mô hình RAD như sau.

Mô hình hóa kinh doanh: Thông tin nào thúc đẩy hoạt động của quy trình kinh doanh? Thông tin nào sẽ được tạo ra? Ai đã tạo ra nó? Dòng thông tin sẽ đi đâu? Ai sẽ xử lý nó? Có thể được bổ sung bằng các sơ đồ dòng dữ liệu.

Mô hình hóa dữ liệu: Để hỗ trợ dòng dữ liệu của quy trình kinh doanh, tìm tập hợp các đối tượng dữ liệu, xác định các thuộc tính của các đối tượng dữ liệu, và hình thành mô hình dữ liệu với mối quan hệ với các đối tượng dữ liệu khác, có thể được bổ sung bằng các sơ đồ ER.

Mô hình hóa quy trình: cho phép các đối tượng dữ liệu hoàn thành các chức năng kinh doanh khác nhau trong dòng thông tin. Quy trình tạo ra mô tả việc thêm, sửa đổi, xóa và tìm kiếm các đối tượng dữ liệu, tức là sự tinh chỉnh của hộp xử lý trong sơ đồ dòng dữ liệu.

Tạo chương trình ứng dụng: Sử dụng ngôn ngữ thế hệ thứ tư (4GL) để viết chương trình xử lý, tái sử dụng các thành phần hiện có hoặc tạo ra các thành phần tái sử dụng mới, và sử dụng các công cụ do môi trường cung cấp để tự động tạo ra và xây dựng toàn bộ hệ thống ứng dụng.

Kiểm tra và giao hàng, do một lượng lớn tái sử dụng, thường chỉ thực hiện kiểm tra tổng thể, nhưng các thành phần mới tạo ra vẫn cần được kiểm tra.

Mô hình dựa trên thành phần

Thành phần (Component) là một đơn vị phần mềm có giá trị tái sử dụng và chức năng tương đối độc lập. Mô hình Phát triển Phần mềm Dựa trên Thành phần (CBSD) là sử dụng một phương pháp mô-đun để mô-đun hóa toàn bộ hệ thống, và với sự hỗ trợ của một mô hình thành phần nhất định, tái sử dụng một hoặc nhiều thành phần phần mềm trong thư viện thành phần, thông qua quá trình kết hợp để xây dựng các hệ thống phần mềm ứng dụng với hiệu suất cao và chất lượng cao.

Mô hình phát triển dựa trên thành phần kết hợp nhiều đặc điểm của mô hình xoắn ốc, và về cơ bản là tiến hóa, và quy trình phát triển là lặp lại. Mô hình phát triển dựa trên thành phần bao gồm năm giai đoạn: phân tích và định nghĩa yêu cầu phần mềm, thiết kế kiến trúc, thiết lập thư viện thành phần, xây dựng phần mềm ứng dụng, kiểm tra và phát hành.

Phương pháp nguyên mẫu

Nguyên mẫu phần mềm là sự hiện thực hóa một phần của sản phẩm mới được đề xuất. Mục đích chính của việc thiết lập nguyên mẫu là giải quyết vấn đề nhu cầu không chắc chắn trong giai đoạn đầu của phát triển sản phẩm. Mục đích của nó là làm rõ và cải thiện các yêu cầu, khám phá các tùy chọn thiết kế, và phát triển thành sản phẩm cuối cùng.

Có nhiều cách để phân loại nguyên mẫu. Từ góc độ liệu nguyên mẫu có hiện thực hóa các chức năng của nó hay không, nguyên mẫu phần mềm có thể được chia thành hai loại: nguyên mẫu ngang và nguyên mẫu dọc.

Nguyên mẫu ngang còn được gọi là nguyên mẫu hành vi, được sử dụng để khám phá một số hành vi cụ thể của hệ thống mong đợi và đạt được mục đích tinh chỉnh các yêu cầu. Nguyên mẫu ngang thường chỉ là điều hướng các chức năng, nhưng chúng không thực sự thực hiện các chức năng. Nguyên mẫu ngang chủ yếu được sử dụng trên giao diện.

Các mẫu thử nghiệm dọc còn được gọi là mẫu thử nghiệm có cấu trúc, thực hiện một phần chức năng của chúng. Các mẫu thử nghiệm dọc chủ yếu được sử dụng trong việc hiện thực hóa các thuật toán phức tạp.

Phương pháp XP

XP là một phương pháp phát triển phần mềm nhẹ (linh hoạt), hiệu quả, rủi ro thấp, linh hoạt, có thể dự đoán, khoa học và thú vị. So với các phương pháp khác, sự khác biệt lớn nhất nằm ở:

Cung cấp phản hồi cụ thể và liên tục sớm hơn trong một khoảng thời gian ngắn hơn.
Lập kế hoạch lặp đi lặp lại, đầu tiên tạo ra một kế hoạch tổng thể nhanh chóng ngay từ đầu, và sau đó liên tục phát triển nó trong suốt quá trình phát triển dự án.
Dựa vào các quy trình kiểm tra tự động để theo dõi tiến độ phát triển và phát hiện lỗi sớm.
Dựa vào giao tiếp bằng lời nói, kiểm tra và giao tiếp chương trình nguồn.
Khuyến khích thiết kế tiến hóa liên tục.
Dựa vào sự hợp tác chặt chẽ trong nhóm phát triển.
Cố gắng cân bằng lợi ích ngắn hạn của lập trình viên và lợi ích dài hạn của dự án càng nhiều càng tốt.

Phương pháp Quy trình thống nhất (UP)

Quy trình thống nhất là một khung quy trình tổng quát có thể đối phó với nhiều loại hệ thống phần mềm, các lĩnh vực ứng dụng khác nhau, các loại tổ chức khác nhau, các mức hiệu suất khác nhau và các quy mô dự án khác nhau. UP dựa trên thành phần, có nghĩa là hệ thống phần mềm được phát triển bởi nó được cấu thành từ các thành phần, và các thành phần được kết nối với nhau thông qua các giao diện được xác định rõ ràng. Khi chuẩn bị tất cả các bản thiết kế của hệ thống phần mềm, UP sử dụng ngôn ngữ mô hình thống nhất UML.

So với các quy trình phần mềm khác, UP có ba đặc điểm nổi bật: dựa trên trường hợp sử dụng, tập trung vào kiến trúc cơ bản, lặp lại và gia tăng. Quy trình phần mềm trong Quy trình thống nhất hợp lý được chia thành bốn giai đoạn liên tiếp theo thời gian, đó là giai đoạn ban đầu, giai đoạn tinh chỉnh, giai đoạn xây dựng và giai đoạn giao hàng. Vào cuối mỗi giai đoạn, một cuộc đánh giá kỹ thuật phải được sắp xếp để xác định xem các mục tiêu của giai đoạn này đã được đáp ứng hay chưa. Nếu kết quả của cuộc đánh giá là hài lòng, dự án có thể được phép chuyển sang giai đoạn tiếp theo.

Tìm hiểu thêm

This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.