Chương 2 các mô hình phát triển hệ thống

Các mô hình SDLC• Mô hình thác nước waterfall • Mô hình prototype • Mô hình RAD rapid application development • Mô hình tăng tiến incremental model • Mô hình xoắn ốc spiral model • Mô hì

Chương 2

Các Mô hình Phát triển Hệ thống

Nội dung

• Chu kỳ phát triển phần mềm (SDLC)

• Các mô hình thông dụng

Quy trình phần mềm là gì?

(Software Process)

• CNPM là công nghệ theo lớp (layered technology)

• Nền tảng của CNPM chính là lớp Process, nó là chất kết dính

Methods – Các phương pháp

Tools – Các công cụ

Quy trình phát triển phần mềm (Software development – SEP)

• Qui trình có thể hiểu là phương pháp thực hiện hoặc sản xuất

ra sản phẩm Tương tự như vậy, SEP chính là phương pháp

phát triển hay sản xuất ra sản phẩm phần mềm

• Thông thường một qui trình bao gồm những yếu tố cơ bản sau:

– Thủ tục (Procedures)

– Hướng dẫn công việc (Activity Guidelines)

– Biểu mẫu (Forms/templates)

– Danh sách kiểm định (Checklists)

– Công cụ hỗ trợ (Tools)

Quy trình phát triển phần mềm (Software development – SEP)

Chi phí của công nghệ phần mềm

Chi phí của công nghệ phần mềm

Chu kỳ phát triển phần mềm (Software Development Life Cycle - SDLC)

• Chu kỳ phần mềm (Software life cycle) là gì?

“ Là khoảng thời gian từ lúc phần mềm bắt đầu hình thành

cho đến lúc nó không còn dùng được nữa”

• Chu kỳ phần mềm thường trải qua các giai đoạn (phase) sau:

Chu kỳ phát triển phần mềm (Software Development Life Cycle - SDLC)

Các mô hình SDLC

• Mô hình thác nước (waterfall)

• Mô hình prototype

• Mô hình RAD (rapid application development)

• Mô hình tăng tiến (incremental model)

• Mô hình xoắn ốc (spiral model)

• Mô hình dựa vào thành phần (Component-Based Model)

Tùy theo mô hình áp dụng mà các bước trong mỗi giai đoạn sẽ

khác nhau: có thể từ 3 đến 30 bước

Mô hình waterfall

Giai đoạn 1

• Là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có

Giai đoạn này cần sự tham gia tích cực của khách hàng và kết

thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần

mềm” hay SRS (software requirement specification) chứa các

yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng)

• SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối

dự án

Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications)

Giai đoạn 2

• là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng được những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS Đây là chính là cầu nối giữa “đòi hỏi”

(“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó

Phân tích hệ thống và thiết kế hệ thống (System Analysis and Design):

Giai đoạn 3:

• Là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra

trong giai đoạn “Phân tích hệ thống và thiết kế”

Mã hóa và kiểm thử đơn vị (Coding and Unit Test)

Giai đoạn 4

• Giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện

thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test)

• Một khâu kiểm thử cuối cùng thường được thực hiện là

nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không

Kiểm thử tích hợp và hệ thống(Integration and System Testing)

Bất lợi của mô hình waterfall

• Các dự án thực tế ít khi tuân theo 1 cách tuần tự như mô hình

Mặc dù mô hình có thể lặp nhưng không cụ thể, rõ ràng Các

thay đổi do lặp lại có thể gây nhầm lẫn cho thành viên của đội

dự án

• Thường khách hàng khó mà phát biểu tất cả các yêu cầu 1 cách tường minh ngay lúc đầu được nhưng mô hình waterfall thì đòi hỏi phải thu thập đầy đủ yêu cầu của khách trước khi sang bước

kế tiếp

• Khách hàng cần phải kiên nhẫn đợi sản phẩm cho đến khi dự án kết thúc Nhiều lúc một lỗi nào đó của phần mềm sẽ không được phát hiện cho đến khi chương trình chính thức được duyệt

Vai trò của mô hình waterfall

• Mô hình phản ảnh thực tế công nghệ

• Là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm

- phần cứng

Mô hình chữ V

Mô hình chữ V

• Toàn bộ qui trình được chia thành hai nhóm giai đoạn tương

ứng nhau: nhóm phát triển và nhóm kiểm thử Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng

• Các hoạt động kiểm thử phải được tiến hành song song (theo

khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển

• Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ

thống có thể được thực hiện song song với các hoạt động phân tích và thiết kế hệ thống

Mô hình prototype (Mô hình làm bản mẫu)

Mô hình prototype nên dùng khi nào?

• Khi khách hàng đưa ra các mục tiêu chính của phần mềm

nhưng không xác định đuợc các yêu cầu cụ thể như thế nào

• Khi nhà phát triển không bảo đảm là giải thuật có thật sự hiệu quả hay không, khả năng đáp ứng của hệ thống thế nào, tương tác giữa người và máy nên xây dựng thế nào

Mô hình prototype

• Bắt đầu bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả hai phía nhằm định ra mục tiêu tổng thể của hệ thống đồng thời ghi

nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm

yêu cầu nào cần phải được làm rõ

• Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp

hoàn chỉnh yêu cầu cho toàn hệ thống  giúp tinh chỉnh yêu cầu, và giúp đội ngũ phát triển thông hiểu hơn những gì cần được phát triển

• Tiếp theo có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác.

Bất lợi của mô hình prototype

• Prototype thường được làm thật nhanh trong thời gian ngắn

nên không được xây dựng trên cùng môi trường và công cụ

phát triển của giai đoạn xây dựng phần mềm thực sự sau này Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó

Mô hình tiến hóa (Evolutionary)

• Cũng là một dạng mô hình mẫu (prototype), tuy nhiên có sự

khác biệt:

– Mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau

– Những phiên bản prototype trước sẽ được xây dựng với

mục tiêu có thể tái sử dụng trong những phiên bản sau

Mô hình tiến hóa (Evolutionary)

Khuyết điểm của mô hình tiến hóa

• Quá trình thì không nhìn thấy rõ được: Các nhà quản lý cần

phân phối thường xuyên các phiên bản để đo lường sự tiến bộ

Nó không kinh tế trong việc làm ra các hồ sơ cho phần mềm

• Phần mềm thường dược cấu trúc nghèo nàn: Sự thay đổi liên

tục dễ làm đổ vỡ cấu trúc của phần mềm, tạo ra sự khó khăn

và tốn phí

• Thường đòi hỏi những kỹ năng đặc biệt: chỉ có thể được tiến

hành bởi các nhóm nhỏ có kỹ năng cao cũng như các cá nhân phải năng động

Mô hình tăng trưởng và lặp (Incremental and iterative model)

• Mô hình tăng dần (Incremental): thêm chức năng vào sản

phẩm

• Mô hình lặp (Iterative): thay đổi sản phẩm

Mô hình tăng trưởng Incremental Model

Mô hình tăng trưởng

• Mô hình tăng dần kết hợp những ưu điểm của mô hình thác

nước và mô hình tiến hóa

• Ý tưởng của mô hình này là phân chia phần mềm thành những phần tăng trưởng (increments) và phát triển, bàn giao chúng

lần lượt cho khách hàng theo mức độ quan trọng

• Phần tăng trưởng nào đến lượt được phát triển thì những yêu

cầu tương ứng sẽ được phân tích Chỉ những thay đổi từ phía

khách hàng cho những phần chưa được phát triển mới được

chấp nhận

Ưu điểm của mô hình tăng trưởng

• Rút ngắn thời gian chờ đợi của khách hàng Khách hàng

không phải đợi đến khi toàn bộ hệ thống hoàn thành Những

thành phần quan trọng nhất được bàn giao sớm và mang lại lợi ích sớm hơn cho khách hàng

• Tăng chất lượng phần mềm Thành phần quan trọng nhất thì

được phát triển và hoạt động sớm nhất, bởi vậy nó được test

nhiều nhất Ý kiến của khách hàng và kinh nghiệm phát triển

các thành phần trước sẽ được áp dụng ngay lập tức cho các

thành phần sau

Ưu điểm của mô hình tăng trưởng

• Giảm bớt những yêu cầu không cần thiết từ khách hàng

Khi một tính năng chưa có mặt trong hệ thống, họ sẽ nghĩ rằng

nó sẽ được tích hợp vào ở những lần bàn giao tiếp theo!

• Tăng năng suất lao động Nhiều lập trình viên làm việc tốt

hơn trong các dự án nhỏ mà họ sớm nhìn thấy thành quả lao

động của mình

Khuyết điểm của mô hình tăng trưởng

• Không phải dự án nào cũng có thể được phân chia thành các

phần tăng trưởng nhỏ để phát triển và bàn giao tuần tự

Mô hình RAD (Rapid Application Development)

Mô hình RAD (Rapid Application Development)

• Chính là mô hình tăng trưởng với chu kỳ phát triển cực ngắn

• Để đạt được mục tiêu này, RAD dựa trên phương pháp phát

triển trên cơ sở thành phần hóa hệ thống cùng với việc tái sử

dụng các thành phần thích hợp

• RAD thích hợp cho những hệ thống quản lý thông tin

Mô hình xoắn ốc (Spiral model)

Mô hình xoắn ốc (Spiral model)

• Phát triển từ mô hình thác nước cho thấy mức độ tổng quát

hơn của các pha sản xuất của một sản phẩm

• Đặt trọng tâm phân tích rủi ro và xem xét kế hoạch để giải

quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp

liên tiếp dựa trên bản chất của mô hình lặp

• Mỗi vòng lặp đại diện cho một pha của quá trình phần mềm

Vòng trong cùng tập trung về tính khả thi, vòng kế về định

nghĩa yêu cầu, kế đến là thiết kế,

• Không có một pha nào được xem là cố định trong vòng xoắn Mỗi vòng có đủ 4 giai đoạn của chu kỳ phần mềm

Mô hình dựa vào thành phần (Component-Based Model)

Case studies

• Case study 1: page 33

• Case study 2: page 36