Software Process

Software Process

.Mô hình Waterfall (Waterfall model)

.Mô hình lặp và tăng dần (Iterative and

Incremental)

.Mô hình bản mẫu (Prototype)

.Mô hình phát triển ứng dụng nhanh (RAD)

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

1 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”

 Xác định các mốc thời gian trong thực hiện

và sản phẩm thu được ứng với mỗi mốc thời gian

Systems analysis

Phân tích hệ thống

 Xác định yêu cầu hệ thống (người dùng

mong được gì từ hệ thống được đề nghị)

 Xác định những yêu cầu, cấu trúc không còn phù hợp để loại bỏ

 Xây dựng thiết kế mới

 So sánh, đánh giá thiết kế để chọn phương

án tối ưu (giá, nhân công, cấp độ kỹ thuật…)

Thiết kế mọi diện mạo của hệ thống từ nhập vào và xuất ra của màn hình đến máy in, cơ sở

dữ liệu, và các xử lý tính toán;

Systems implemention and operation

Thực hiện và vận hành hệ thống

Thực hiện mã hóa, chạy thử và cài đặt

Mã hóa, lập trình viên lập các chương trình tạo nên hệ thống

Chạy thử, lập trình viên và phân tích viên kiểm tra từng chương trình rồi toàn bộ hệ thống để tìm

và sửa lỗi

Cài đặt

Vận hành: người lập trình tạo sự thay đổi mà người

sử dụng yêu cầu và sửa đổi hệ thống

2 Các mô hình SDLC

 Mô hình Waterfall (Waterfall model)

 Mô hình lặp và tăng dần (Iterative and Incremental)

 Mô hình bản mẫu (Prototype)

 Mô hình phát triển ứng dụng nhanh (RAD)

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

 Mô hình chữ V (V-model)

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

 Mô hình dựa trên các thành phần (Component)

 Các mô hình nhiều phiên bản (Multi-version models)

 …

Waterfall Model

- Ra đời vào khoảng những năm 70

- Là kết quả của sự kết hợp các mô hình sản

xuất từ các ngành kỹ thuật khác áp dụng cho

công nghệ phần mềm

Mô Hình Thác N ướ c ( Waterfall )

Ưu điểm của mô hình Waterfall

ràng nên dễ phân công công việc, phân bổ chi phí, giám sát công việc

dự án có ít thay đổi

- Giảm thiểu các lỗi mắc phải trong giai đoạn thiết kế

Nhược điểm của mô hình Waterfall

 Mối quan hệ giữa các giai đoạn (pha) không được thể hiện

 Thời gian thực hiện lâu

 Quy trình sửa lỗi khó khăn và tốn nhiều chi phí

- Chỉ tiếp xúc với khách hàng ở giai đoạn đầu để

lấy yêu cầu nên hầu hết không đáp ứng được yêu cầu của khách hàng.

Những dự án nên tiến hành theo mô hình

waterfall

Mô hình waterfall chỉ nên sử dụng khi mà đội dự án

đã có kinh nghiệm làm việc

Waterfall hợp với những dự án mà khách hàng xác định được yêu cầu cụ thể, chính xác ngay từ đầu và ít

có khả năng thay đổi

Đối với những khách hàng lớn mà phong cách làm

việc của họ chủ yếu theo mô hình truyền thống

(waterfall) hoặc những khách hàng lo ngại có nhiều thay đổi trong dự án

Itera tive &

Incr ement

al

Mô hình lặp và tăng dần

 Mô hình lặp và tăng dần có lúc được hiểu

là một

 Hai mô hình này đều có điểm giống nhau :

hóa

làm việc mà không cần chờ cho đến khi toàn

bộ hệ thống được hoàn thành

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 lặp và tăng dần

∗ Các yêu cầu được xác định và phân loại theo độ

ưu tiên, độ ưu tiên cao cho những chức năng chính

và những chức năng có độ rủi ro cao.

∗ Phân chia các yêu cầu cho các vòng và thiết kế kiến trúc của toàn bộ hệ thống

∗ Vòng đầu tiên tạo ra sản phẩm lõi (core product)

∗ Các bước sau bổ sung các chức năng khác và tích hợp vào hệ thống nhằm hoàn thiện dần sản phẩm

∗ Mỗi chức năng cũng như hệ thống tích hợp phải được đánh giá theo từng giai đoạn

∗ Các yêu cầu và kiến trúc của toàn bộ hệ

thống sẽ được điều chỉnh dựa vào những sản phẩm phát hành theo từng vòng.

 Giảm rủi ro trong việc thất bại của toàn bộ dự án.

 Rủi ro trải ra nhiều phần nhỏ

 Sử dụng nhân viên giới hạn, họ có thể thực hiện những công việc tương tự ở các vòng.

Khuyết điểm

 Phải xác định chức năng đầy đủ và hoàn chỉnh trước khi xác định các vòng gia tăng

 Phải xác định rõ các giao tiếp (interface) cho các module

mà thời gian hoàn thành cách biệt nhiều

 Việc kiểm tra khó khăn hơn trên một hệ thống hoàn

chỉnh

 Khách hàng khi thấy sản phẩm lõi có thể nghĩ là công

việc đơn giản ít tốn kém

 Đòi hỏi phải có kế hoạch và thiết kế tốt phân chia công việc hợp lý.

Prot otyp

Mô hình nguyên m u (Prototyping model) ẫ

1 M c đích và xây d ng : ụ ự

• Thu c mô hình tuy n tính ộ ế

• Xu t hi n t năm 1970 thay th ph ấ ệ ừ ế ươ ng pháp code – and - fix

• Xem xét yêu c u ng ầ ườ ử ụ i s d ng giai đo n đ u ở ạ ầ

• Gi m r i ro và không ch c ch n ả ủ ắ ắ

• Ki m ch ng thi t k và th c thi ể ứ ế ế ự

• Sau khi nguyên m u đẫ ược hoàn thi n thì s ệ ẽ

ti p t c các giai đo n gi ng nh mô hình ế ụ ạ ố ư ởthác nước hay cũng có th là mô hình khác.ể

2 u đi m c a mô hình nguyên m u : Ư ể ủ ẫ

4.Nh ượ c đi m c a mô hình nguyên m u : ể ủ ẫ

∗ Là ph ươ ng pháp Quick – and – dirty

∗ Nh ng nguyên m u th ữ ẫ ườ ng gây ra khó khăn trong

vi c thi u t li u hay t li u không phù h p ệ ế ư ệ ư ệ ợ

∗ H th ng xây d ng có th mang c u trúc m t ệ ố ự ể ấ ộ

cách nghèo nàn v i nh ng l a ch n không t t ớ ữ ự ọ ố

H th ng s có ch t l ệ ố ẽ ấ ượ ng th p và khó b o trì ấ ả sau m t th i gian dài ộ ờ

 Khách hàng có th cho r ng nguyên m u ể ằ ẫ

là h th ng th c và d n đ n mong đ i ệ ố ự ẫ ế ợ không th c t v ti n tri n c a d án ự ế ề ế ể ủ ự

 Ng ườ i phát tri n có s ch n l a không ể ự ọ ự

t t : Phù h p cho nguyên m u, nh ng ố ợ ẫ ư

không phù h p cho h th ng th c R i ợ ệ ố ự ơ vào tr ng thái code – and – fix ạ

 Nguyên m u không gi ng hoàn toàn h ẫ ố ệ

th ng cu i cùng d n đ n khác hàng s ố ố ẫ ế ẽ

có các ph n ng khác nhau ả ứ

Nh ượ c đi m (tt) ể

5 Mô hình nguyên m u th ẫ ườ ng đ ượ c s d ng khi : ử ụ

 Khi ng ườ i phát tri n không ch c ch n vi c dùng gi i ể ắ ắ ệ ả

thu t hay ki n trúc là t i u ậ ế ố ư

 Khi m i rõ m c đích chung chung c a ph n m m, ch a ớ ụ ủ ầ ề ư

rõ chi ti t đ u vào hay x lý ra sao ho c ch a rõ yêu ế ầ ử ặ ư

c u đ u ra ầ ầ

 Dùng nh “ h s khai” đ thu nh p yêu c u ng ư ệ ơ ể ậ ầ ườ i

dùng qua các thi t k nhanh ế ế

 Các gi i thu t, k thu t dùng làm b n m u có th ch a ả ậ ỹ ậ ả ẫ ể ư nhanh, ch a t t, mi n là có m u đ th o lu n g i yêu ư ố ễ ẫ ề ả ậ ợ

c u c a ng ầ ủ ườ i dùng.

Rapi d Ap

• Xây dựng dựa trên hướng thành phần (Component-based construction) với khả năng tái sử dụng (reuse).

Sơ đồ chu kì của mô hình RAD

Business modeling

Luồng thông tin được mô hình hóa để trả lời các câu hỏi:

• Thông tin nào điều khiển xử lý nghiệp vụ ?

• Thông tin gì được sinh ra ?

• Ai sinh ra nó ?

• Thông tin đi đến đâu ?

• Ai xử lý chúng ?

Data and Process modeling

• Data modeling: Các đối tượng dữ liệu cần để hỗ

trợ nghiệp vụ (business) Định nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng

• Process modeling: Các đối tượng dữ liệu được

chuyển sang luồng thông tin thực hiện chức năng nghiệp vụ Tạo mô tả xử lý để cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu

Appl Generation and Testing

• Application Generation: Dùng các kỹ thuật để

tạo phần mềm từ các thành phần có sẵn hoặc tạo ra các thành phần có thể tái dụng lại sau này Dùng các công cụ tự động để xây dựng phần mềm

• Testing and Turnover: Kiểm thử các thành phần

mới và kiểm chứng mọi giao diện - interface (các thành phần cũ đã được kiểm thử và dùng lại)

Ưu điểm

CSDL và có nhiều giao diện người dùng hay tích

hợp các thành phần có sẵn  Thời gian phát triển ngắn nhờ dùng công cụ.

(off-the-shelf tools and frameworks).

thử.

•Yêu cầu hai bên giao kèo trong thời gian ngắn

phải có phần mềm hoàn chỉnh, thiếu trách nhiệm của một bên dễ làm dự án đổ vỡ  Người phát

triển và khách hàng phải gắn bó và nỗ lực cao

 Khó có sự nhất quán giữa những thành

phần được phát triển bởi các nhóm khác nhau

 RAD không phải tốt cho mọi ứng dụng, nhất là

với ứng dụng không thể môđun hóa hoặc đòi hỏi tính năng cao

 Không phù hợp cho những ứng dụng đòi hỏi

hiệu suất vì thường phụ thuộc vào sự hỗ trợ của môi trường phát triển và ngôn ngữ cấp

cao

Nhược điểm (tt)

Ứng dụng:

• Hệ thống mà những yêu cầu được biết rõ và hợp lý.

• Hệ thống dễ dàng phân chia module và có thể mở rộng.

• Hệ thống quản lý thông tin kiểu những ứng dụng

dựa trên GUI và SDLC.

• Có sự hỗ trợ của công cụ hay sử dụng ngôn ngữ cấp cao.

 Người dùng có thể tham gia tốt qua toàn bộ

chu kỳ sống (life cycle)

 Dự án thời gian phát triển ngắn, dưới 60

ngày

 Những thành phần sử dụng lại có sẵn trong

kho phần mềm

 Những hệ thống nhỏ, những hệ thống không

có tính nghiêm ngặt, yêu cầu khắc khe về

hiệu suất (critical)…

Ứng dụng (tt):

Spira l Mo

del

Mô hình xoắn ốc

 Được đề nghị bởi Berry Boehm, 1988

 Tương tự như mô hình gia tăng, với hơn

nhấn mạnh vào phân tích rủi ro

 Mỗi vòng lặp biểu diễn một gia đoạn

trong chu trình

 Mỗi chu kỳ có 4 tầng, mỗi tầng ¼ cung

Mô hình xoắn ốc

Đánh giá

Phân tích rủi ro

Kĩ thuật Lập kế hoạch

Lập kế hoạch : Xác lập tài nguyên , thời hạn và những thông tin khác

Phân tích rủi ro: Xem xét mạo hiểm kĩ thuật

và mạo hiểm quản lý

Kĩ thuật : Xây dựng một hay một số tính

năng của phần mềm, kiểm thử, cài đặt và

cung cấp hỗ trợ người dùng

Đánh giá : Nhận các phản hồi của người sử

dụng về biểu diễn phần mềm trong quá trình

xây dựng và cài đặt

Ưu điểm của mô hình xoắn ốc:

Mức độ tránh rủi ro cao

Tốt cho các dự án lớn và quan trọng

Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa

Phần mềm được sản xuất sớm trong vòng đời phần mềm

…

Nhược điểm của mô hình xoắn ốc:

 Có thể là một mô hình tốn kém để sử dụng

 Phân tích rủi ro đòi hỏi chuyên môn rất cụ thể

 Sự thành công của dự án phụ thuộc nhiều vào

giai đoạn phân tích rủi ro

 Không làm việc tốt cho các dự án nhỏ hơn

Khi sử dụng mô hình xoắn ốc:

 Khi chi phí và đánh giá rủi ro là quan trọng

 Cam kết dự án dài hạn không khôn ngoan vì

những thay đổi tiềm năng để ưu tiên kinh tế

 Người sử dụng không chắc chắn về nhu cầu của

Our presentation here is finish

Thanks for your attention !!