Một số mô hình xây dựng phần mềm

Đôi lúc còn được gọi là mô hình kinh điển (classic model) hay mô hình thác nước (waterfall model). Mô hình này xem quá trình xây dựng một sản phẩm phần mềm bao gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thì chuyển đến giai đoạn sau.

Có hai hoạt động phổ biến được thực hiện trong mỗi giai đoạn là: kiểm tra - phê chuẩn và quản lý cấu hình. Tổng kết mỗi giai đoạn là sự kiểm tra, phê chuẩn và quản lý cấu hình đây chính là mục tiêu của sản phẩm. Việc kiểm tra đưa ra khuôn mẫu đúng đắn tương ứng giữa sản phẩm phần mềm và các đặc tính của nó. Sự phê chuẩn đưa ra chuẩn mực về sự phù hợp hay chất lượng của sản phẩm phần mềm đối với mục đích của quá trình hoạt động.

Tuy vậy, thường thì các dự án có hàng ngàn trang tài liệu mà không ai ngoại trừ tác giả đọc đến nó. Thông tin ứng dụng chỉ nằm trong đầu mọi người và việc trao đổi thông tin là một trở ngại lớn để có được thành công của hệ thống. Kết luận là văn bản không phải là một phương tiện tốt để mô tả các yêu cầu phức tạp của ứng dụng. Thêm vào đó, mô hình bộc lộ một số nhược điểm quan trọng như:

 Mối qua hệ giữa các giai đoạn không được thể hiện

Hệ thống phải được kết thúc ở từng giai đoạn do vậy rất khó thực hiện được đầy đủ những yêu cầu của khách hàng...

Mô hình này được tóm tắt như sau:

Thông thường, khách hàng sẽ đưa ra mục tiêu của họ một cách chung chung mà họ không biết hoặc không đưa ra một cách cụ thể những cái vào, cái ra và các tiến trình xử lý chúng. Thêm vào đó, chúng ta cũng không thể không quan tâm đến thuật toán sử dụng, tính tương thích của sản phẩm phần mềm với môi trường của nó như: phần cứng, hệ điều hành...Trong trường hợp này, mô hình mẫu có thể là sự lựa chọn tốt hơn cho người lập trình.

Những điểm chính của mô hình mẫu được tóm tắt theo sơ đồ sau:

Mô hình này được Boehm đưa ra nên đôi lúc còn được gọi là mô hình Boehm's

(The Boehm's spiral model). Nó có thể xem là sự kết hợp giữa mô hình thác nước và mô hình mẫu và đồng thời thêm một thành phần mới - phân tích rủi ro. Bao gồm bốn hoạt động chính:

 Planning: Xác định mục tiêu, tương tác và ràng buộc.

 Risk analysis: Phân tích các lựa chọn và các chỉ định/giải quyết rủi ro.

 Engineering : Phát triển sản phẩm

 Customer evaluation: Đánh giá kết quả xây dựng.

Mô hình được tóm tắt như sau:

Trong vòng đầu tiên của xoáy ốc, mục đích, lựa chọn, các ràng buộc được định nghĩa và các nguy cơ được xác định và phân tích. Nếu phân tích các lỗi chỉ ra rằng có một vài yêu cầu không chắc chắn, tạo mẫu có thể dược tiến hành để giúp đỡ nhà phát triển và khách hàng. Mô phỏng và các mô hình khác có thể được sử dụng để xác định vấn đề và làm mịn các yêu cầu.

Khách hàng đánh giá công việc và đưa ra các gợi ý. Trên cơ sở ý kiến đó, phần tiếp theo của lập kế hoạch và phân tích lỗi xuất hiện.

Mô hình xoáy ốc hiện nay là mô hình hướng tiếp cận hiện thực nhất để phát triển các hệ thống lớn. Nó sử dụng mô hình mẫu như là cơ chế loại trừ lỗi, cho phép nhà phát triển áp dụng mô hình mẫu tại mỗi chu trình phát triển. Nó kế thừa cách tiếp cận hệ thống từng bước từ chu kỳ sống cổ điển nhưng kết hợp với quá trình lặp lại phù hợp với thực tế.

Giống như các quy trình khác, mô hình xoáy ốc không phải là công cụ vạn năng. Đối với những hệ thống lớn, khó có thể điều khiển sự tiến hóa của phần mềm. Nó đòi hỏi phải có kỹ năng đánh giá lỗi. Cuối cùng là cần phải có thêm thời gian để kiểm nghiệm phương pháp mới này.

Đây là mô hình của cách tiếp cận hướng đối tượng, hệ thống được xem như là một hệ thống các thực thể tác động qua lại để đạt được một mục đích nào đó. Mô hình này tương ứng với mô hình thác nước trong cách tiếp cận hướng thủ tục ở trên. Ở đây, ta thấy trong có những phần lặp và giao nhau giữa các bước phân tích, thiết kế và cài đặt.

Các điểm chính của mô hình được tóm tắt như sau:

Xuất phát từ quan điểm: "Buy do not build", tư tưởng của phát triển dựa trên thành phần là lắp ráp hệ thống từ những thành phần đã có. Do vậy, kiến trúc phần mềm của hệ thống dựa vào kiến trúc phần mềm của các thành phần phần mềm tiêu chuẩn nên hệ thống đạt chất lượng cao hơn.

Phương pháp phát triển dựa trên thành phần gần tương tự như phương pháp phát triển hướng đối tượng. Hoạt động công nghệ bắt đầu với sự chỉ ra các lớp tham dự để phát triển hệ thống. Nếu các lớp này được tìm thấy trong thư viện và sự thích nghi là tốt, chúng sẽ được lấy ra và phát triển hệ thống. Ngược lại, chúng sẽ được phát triển để sử dụng và bổ sung vào thư viện sử dụng lại.

Thành phần phần mềm được sử dụng lại có độ chính xác cao và có thể nói là không chứa lỗi. Mặc dầu không thường xuyên được chứng minh về mặt hình thức nhưng với việc sử dụng lại, lỗi được tìm thấy và loại trừ; chất lượng của thành phần được cải thiện như là một kết quả.

Khi những thành phần sử dụng lại được ứng dụng thông qua tiến trình phần mềm, chúng ta ít tốn thời gian để tạo ra kế hoạch, mô hình, tài liệu, mã và dữ liệu mà chúng là cần thiết để tạo ra hệ thống. Thêm vào, chức năng cùng mức được phân phối cho người sử dụng với đầu vào ít công sức hơn, do vậy, hiệu suất phần mềm được cải thiện.

Những điểm chính của mô hình được tóm tắt như sau: