MÔ HÌNH PHÁT TRIỂN PHẦN mềm

Mô hình phát triển phần mềm là thể hiện trừu tượng của quy trình phần mềm, dùng để diễn tả các đặc tả về quy trình từ những khía cạnh cụ thể. Có rất nhiều mô hình phát triển, nhưng phổ biến nhất là: mô hình thác nước (waterfall), mô hình phát triển tiến hóa (evolutionary development), mô hình xoắn ốc (spiral model), mô hình phát triển lặp lại tăng thêm (incremental delivery) và mô hình công nghệ phần mềm dựa thành phần (reuseoriented development)

MÔ HÌNH PHÁT TRIỂN PHẦN MỀM – PHẦN 1

Hôm nay, chúng ta cùng thào luận về chủ đề mô hình phát triển phần mềm Mô hình phát triển phần mềm là gì? Và có bao nhiêu mô hình phát triển phần mềm?

Mô hình phát triển phần mềm là thể hiện trừu tượng của quy trình phần mềm, dùng để diễn tả các

đặc tả về quy trình từ những khía cạnh cụ thể Có rất nhiều mô hình phát triển, nhưng phổ biến nhất

là: mô hình thác nước (waterfall), mô hình phát triển tiến hóa (evolutionary development), mô hình xoắn ốc (spiral model), mô hình phát triển lặp lại & tăng thêm (incremental delivery) và mô hình công nghệ phần mềm dựa thành phần (reuse-oriented development)

Đầu tiên, không thể không đề cập đến mô hình thác nước (waterfall), mô hình này bao gồm 5 pha (phase): định nghĩa yêu cầu (requirements definition), thiết kế (System and software design), cài đặt và kiểm thử đơn vị (implementation and unit testing), tích hợp và kiểm thử hệ thống

(integration and system testing), vận hành và bảo trì (Operation and Maintenance)

 Định nghĩa yêu cầu (requirements definition): bao gồm các dịch vụ, ràng buộc, chức năng

mà khách hàng yêu cầu Nói cách đơn giản là đi gặp đối tác để bàn thảo các thông tin cụ thể

 Thiết kế (System and software design):bao gồm cả phần cứng và phần mềm

 Cài đặt và kiểm thử đơn vị (implementation and unit testing): code code và code, sau đó sẽ

là test, nhưng mà chỉ ở dạng unit testing để đảm bảo rằng các method hoạt động tốt và thỏa tài liệu đặc tả

 Tích hợp và kiểm thử hệ thống (integration and system testing): các chương trình con, các

phương thức sẽ được tích hợp lại, tạo thành hệ thống hoàn chỉnh Sau đó kiểm thử xem coi

hệ thống có các chức năng thỏa bản đặc tả hay không, và có tồn tại lỗi nào không Một vấn

đề dễ hiểu là, càng ít lỗi càng tốt, “thà cực khổ lúc tìm lỗi, còn hơn phải mang gánh nặng về sau” Sau giai đoạn này, phần mềm sẽ được bàn giao cho khách hàng

 Vận hành và bảo trì (Operation and maintenance): Hệ thống sau khi đã được xây dựng xong

sẽ bàn giao cho khách hàng Tuy nhiên, không phải bàn giao là khách hàng sẽ dùng được

ngay, mà ta cần phải tiến hành hướng dẫn cài đặt và tiến hành training họ sử dụng phần

mềm Sau một thời gian sử dụng, khách hàng có những nhu cầu mở rộng tính năng, hoặc là phản hồi lại những lỗi mà đôi khi không được tìm thấy trong quá trình kiểm thử, lúc này ta

sẽ đem sản phẩm đi mở rộng, cải tiến chức năng và tiến hành kiểm lỗi theo yêu cầu khách hàng

Đối với mô hình này, các giai đoạn phải được thực hiện một cách tuần tự Do đó, nếu như một giai đoạn nào đó không được thực hiện, hoặc giai đoạn nào trước đó không hoàn thành tốt, hoặc là yêu cầu khách hàng có sự thay đổi, thì có thể ta phải thực hiện lại quy trình từ đầu đến cuối Đó là chưa

kể đến vấn đề khách hàng phải kiên nhẫn chờ đợi một thời gian dài để biết được phần mềm của mình ra sao

Chính vì thế, đối với những dự án có yêu cầu rõ ràng, ít bị thay đổi trong suốt quá trình thiết kế, và đội ngũ phát triển chuyên nghiệp thì mô hình này là một sự lựa chọn hợp lý

MÔ HÌNH PHÁT TRIỂN PHẦN MỀM – PHẦN 2

Tiếp sau mô hình thác nước (waterfall), tôi sẽ đề cập đến mô hình xoắn ốc (spiral model) Trong mô

hình này, quy trình phát triển phần mềm được biểu diễn như một hình xoắn ốc Các pha bao gồm:

 Thiết lập mục tiêu (Objective setting): xác định mục tiêu cho từng pha (phase) trong dự án Như vậy thì mục tiêu ở đây là gì? Đó là các ràng buộc (constraint) & các yêu cầu

(requirement) được xác định rõ ràng, bản kế hoạch chi tiết cũng được đề ra, những rủi ro (risk) cũng cần phải được dự đoán trước Và với mỗi rủi ro (risk) đó thì liệu là chiến lược thay thế (alternative strategy) sẽ được đề ra như thế nào

 Đánh giá và giảm thiểu rủi ro (risk assessment and reduction): đánh giá những rủi ro có thể

xảy ra trong dự án, và đề xuất ra cách thức để giảm thiểu rủi ro

 Phát triển và đánh giá (development and validation): Sau khi đánh giá rủi ro tiềm ẩn trong

hệ thống, một mô hình phát triển sẽ được chọn Chẳng hạn như, nếu rủi ro (risk) chính là việc tích hợp (integration) các hệ thống con (sub - system) lại với nhau, thì mô hình tốt nhất

để xây dựng dự án sẽ là mô hình waterfall

 Lập kế hoạch (planning): đánh giá và đưa ra quyết định xem có nên thực hiện bước tiếp theo trong mô hình hay không Nếu quyết định là tiếp tục thực hiện, pha (phase) tiếp theo sẽ

được lập kế hoạch

MÔ HÌNH PHÁT TRIỂN PHẦN MỀM – PHẦN 3

Mô hình tiếp theo mà tôi muốn đề cập ở trong phần này là mô hình phát triển tiến hóa

(evolutionary development) Mô hình này dựa trên ý tưởng là xây dựng một phiên bản thử nghiệm

ban đầu, sau đó đem cho khách hàng xem, rồi đem về tinh chỉnh lại Quá trình này được thực hiện cho đến khi nào thỏa mãn yêu cầu khách hàng thì dừng lại Mô hình phát triển này phù hợp với một

vài lĩnh vực như: kinh doanh (business), thương mại điện tử (e-commerce), các hệ thống cá nhân (personal system),v.v…

Trong mô hình này có 2 phương pháp chính:

 Phát triển thăm dò: làm việc với khách hàng, sau đó lấy những đặc tả sơ bộ ban đầu và xây dựng hệ thống Đầu tiên, tìm hiểu rõ ràng các yêu cầu từ khách hàng, sau đó bổ sung thêm những yêu cầu mới được khách hàng đề xuất Cuối cùng, khi thỏa mãn các yêu cầu của khách hàng cũng là lúc hệ thống đã được xây dựng hoàn chỉnh

 Loại bỏ mẫu thử: tìm hiểu các yêu cầu của hệ thống Bắt đầu với những yêu cầu chưa rõ ràng

hoặc quá ít thông tin Các mẫu thử (sample) được xây dựng và chuyển giao đến cho khách

hàng Từ đó, ta có thể biết được mẫu thử nào là cần thiết cho hệ thống Do đó, mẫu thử có tác dụng làm sáng tỏ yêu cầu của khách hàng

Với mô hình này, ta có 3 lợi ích chính:

 Chi phí cho việc chạy theo những yêu cầu của khách hàng sẽ được cắt giảm đáng kể Tổng phí cho cả quá trình tái phân tích và tài liệu đặc tả cũng được thu giảm đáng kể

 Dễ dàng lấy phản hồi từ phía khách hàng trong quá trình phát triển Khách hàng sẽ được thấy “mặt mũi” của hệ thống, cách thức nó hoạt động ra sao

 Quá trình chuyển giao và training sẽ nhanh hơn, khách hàng sẽ không mất quá nhiều thời gian để học cách sử dụng chương trình

Có lợi ích thì chắc hẳn phải có nhược điểm, mô hình này cũng có vài nhược điểm đáng được lưu tâm:

 Quy trình phát triển là không rõ ràng, nói một cách đơn giản là, người quản lý sẽ không thể nào thấy được cả một quy trình

 Cấu trúc hệ thống có xu hướng thoái hóa khi thêm vài chức năng Chi phí và mức độ khó khăn cũng tăng dần khi kết hợp các sự thay đổi lại với nhau

Do đó, mô hình này chỉ thích hợp với các dự án có chu kì tồn tại ngắn, một phần của hệ thống lớn hoặc những hệ thống có mức độ tương tác vừa hoặc nhỏ

MÔ HÌNH PHÁT TRIỀN PHẦN MỀM – PHẦN 4

Phần này, tôi xin giới thiệu khái quát 2 mô hình, là mô hình công nghệ phần mềm dựa thành phần

(reuse – oriented software engineering) và mô hình phát triển lặp lại & tăng thêm (incremental

delivery).

Đầu tiên là mô hình công nghệ phần mềm dựa thành phần (reuse – oriented software engineering)

Mô hình này dựa trên kĩ thuật tái sử dụng (reuse) một cách có hệ thống, các hệ thống này có thể được tích hợp từ nhiều thành phần có sẵn, hoặc các thành phần thương mại COTS(Commercial off

the shelf) Mô hình này bao gồm:

 Phân tích thành phần sẵn có (component analysis)

 Điều chỉnh yêu cầu (requirement modification)

 Thiết kế hệ thống với kĩ thuật tái sử dụng (system design with reuse)

 Xây dựng và tích hợp hệ thống (development and integration)

Tiếp tục với mô hình phát triển lặp lại & tăng thêm (incremental delivery) Mô hình này được chia

thành nhiều vòng, tăng dần Mỗi vòng là một phần kết quả chức năng được khách hàng yêu cầu Các yêu cầu theo thứ tự ưu tiên, yêu cầu nào có độ ưu tiên cao hơn thì được phát triển sớm hơn

Đối với mô hình này có một số ưu điểm:

 Các yêu cầu có độ ưu tiên cao sẽ được kiểm thử (testing) kĩ hơn

 Sau mỗi lần tăng vòng thì ta có thể chuyển giao kết quả cho khách hàng

 Các vòng trước có thể làm mẫu thử giúp tìm hiểu các yêu cầu ở vòng tiếp theo