Qui trình phát triển phần mềm

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM
MÔN HỌC

CÔNG NGHỆ PHẦN MỀM

Chương 2

Qui trình phát triển phần mềm

CNPM/NN

1


Chương 2 : Qui trình phát triển phần mềm
1.
2.

Qui trình (process).
Mô hình phát triển phần mềm.
1.
2.
3.
4.
5.

3.

Mô hình thác nước.
Mô hình phát triển gia tăng.
Mô hình RAD.

Mô hình bản mẫu.
Mô hình xoắn ốc.

Một số vấn đề khác.
1.
2.
3.
4.

CNPM/NN

Phát triển dựa vào thành phần.
Kỹ thuật thế hệ thứ 4.
Qui trình RUP.
Phương pháp phát triển phần mềm linh hoạt (PTPMLH - Agile
software development).

2


Yêu cầu
„
„

„

Hiểu rõ một số qui trình phát triển cơ bản .
Trong thực tế người ta thường áp dụng những qui trình tổng
hợp kết hợp nhiều qui trình.
Những qui trình giới thiệu là những qui trình cơ bản có tính

nghiêm ngặt, hiện nay người ta áp dụng những qui trình mới
có tính linh hoạt cao, tạo sự thoải mái cho người làm việc và
phát huy tính sáng tạo nhưng vẫn phải tuân thủ các nguyên
tắc.

CNPM/NN

3


1. Qui trình trong công nghệ phần mềm
Software Engineering
tools
methods
process model
a “quality” focus

CNPM/NN

4


Qui trình
„

„
„

Qui trình phần mềm bao gồm một tập hợp các hoạt động
được tổ chức mà mục đích của nó là xây dựng và phát triển

phần mềm.
Qui trình: Phải thực hiện những công việc gì?
Phương pháp: Chỉ ra cách thực hiện những công việc cụ thể
(“how to”).

CNPM/NN

5


Khung tiến trình (Process framework)
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

CNPM/NN

6


Khung tiến trình
„
„
„
„
„

Truyền thông
Lập kế hoạch
Mô hình hóa
Xây dựng
Triển khai

„
„
„

Communication
Planning
Modeling
„
„

„

Construction
„
„

„

CNPM/NN

Analysis of requirements
Design
Code generation

Testing

Deployment

7


Các hoạt động khung (Framework activities)
Liên quan đến
„
„
„

„

CNPM/NN

Công việc (Work tasks)
Sản phẩm (Work products)
Mốc thời gian và thành quả chuyển giao (Milestones &
deliverables)
Thời điểm kiểm tra chất lượng (QA checkpoints)

8


Hoạt động hỗ trợ
„
„
„

„
„

„
„
„

Quản lý dự án.
Kiểm tra kỹ thuật hình thức.
Bảo đảm chất lượng phần
mềm.
Quản lý cấu hình phần mềm.
Tạo và chuẩn bị những sản
phẩm công tác.
Quản lý sử dụng lại.
Đo lường.
Quản lý rủi ro.

CNPM/NN

„
„
„
„

„

„
„

„

Software project management
Formal technical reviews
Software quality assurance
Software configuration
management
Work product preparation and
production
Reusability management
Measurement
Risk management

9


2. Mô hình phát triển phần mềm
„

„

Mô hình phát triển phần mềm là một thể hiện trừu tượng của
quy trình phần mềm.
Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ
thể, do đó, nó chỉ cung cấp một phần thông tin về quy trình
phần mềm.

CNPM/NN

10

Lựa chọn mô hình phát triển dựa vào:
„

Bản chất của dự án và ứng dụng.
„
„
„

„
„

CNPM/NN

Nhận thức rủi ro.
Sự hiểu biết và kỹ năng của các kỹ sư.
Kiến thức miền ứng dụng của người phát triển.

Phương pháp và công cụ được dùng.
Cách thức kiểm soát và các kết quả chuyển giao được
yêu cầu.

11


Năm mô hình phát triển phần mềm
„
„

Mô hình Thác nước (Waterfall Model).
Mô hình Xử lý tăng dần (Incremental Process Models).
„
„

„

Mô hình tăng dần (Incremental Model).
Mô hình RAD (Rapid Application Development Model).

Mô hình Qui trình tiến hóa (Evolutionary Process models).
„
„

CNPM/NN

Mô hình Tạo bản mẫu (Prototyping Model).
Mô hình Xoắn ốc (Spiral Model).

12


Không có qui trình?
Inputs

„

„

Outputs

Không thể biết khi nào hoàn thành do không có phân tích và
thiết kế chính thức
Không có cách đánh giá các yêu cầu, và tiêu chuẩn chất
lượng có được thỏa mãn hay không

CNPM/NN

13


2.1. Mô hình thác nước (Waterfall Model)
„

„

Mô hình thác nước [Winston Royce] đưa ra vào năm 1970
nhằm thay thế cho phương pháp “code-and-fix”.
Lần đầu tiên đưa ra chính thức một khung mẫu gồm các giai
đoạn phát triển phần mềm dựa vào các yêu cầu đã xác định
và được tạo tài liệu trong giai đoạn đầu.

CNPM/NN

14


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

CNPM/NN

15


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

„

„

Phát triển theo trình tự các bước. Mỗi giai đoạn xác định tiêu
chuẩn vào và ra. Mô hình dễ hiểu và dễ thực hiện đối với mọi
người liên quan. Nó cung cấp một cấu trúc rõ ràng cho những
nhân viên thiếu kinh nghiệm hay yếu về kỹ thuật.
Việc chuyển từ một giai đoạn này tới giai đoạn kế tiếp được
thực hiện khi thỏa một kiểm tra (review) chính thức, xác định
một sự đồng thuận giữa những thành viên dự án và khách
hàng.
Áp dụng cho những phần mềm chất lượng cao, khi yêu cầu
chất lượng nổi trội hơn những yêu cầu về lịch biểu và chi phí

CNPM/NN

16


Mô hình thác nước – nhược điểm
„

„

„
„

Mô hình có tính tuần tự theo 5 giai đoạn nên khi muốn quay lui
để làm đúng một vấn đề hay một kết quả thì sẽ tốn kém nhiều
chi phí và thời gian. Do đó cần phải quản lý chặt chẽ các hoạt
động, phải đặc tả tất cả yêu cầu một cách chính xác và đầy đủ
ngay từ ban đầu.
Khó đánh giá tình trạng của dự án, đánh giá kết quả của dự
án ở thời điểm kiểm tra do việc tích hợp chỉ thực hiện ở giai
đoạn cuối.
Tồn tại việc phải chờ (“delay”) trong nhóm làm việc.
Việc thực hiện trình tự không tự nhiên, tính lặp thường diễn ra
trong thực tế.

CNPM/NN

17


Khi nào sử dụng mô hình thác nước
„

Khi xác định sản phẩm ổn định và những vấn đề về kỹ thuật
đã biết rõ:
„

„

CNPM/NN

Nếu một công đã xây dựng một hệ thống như kế toán, bán
hàng… thì những dự án xây dựng những sản phẩm tương tự có
thể sử dụng mô hình thác nước.
Tạo một phiên bản mới của một sản phẩm đang tồn tại trong đó
những thay đổi (change) được xác định và kiểm soát

18


2.2. Mô hình tăng dần (Incremental Model)

CNPM/NN

19


Mô hình 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.
Hệ thống tích hợp phải được kiểm tra đánh giá thường xuyên
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.

CNPM/NN

20


Mô hình tăng dần – ưu điểm
„

„

„

Những chức năng của hệ thống có thứ tự ưu tiên càng cao
(chức năng chính, chức năng rủi ro cao) sẽ được thực hiện
trước, do đó chúng sẽ được kiểm thử nhiều hơn, sản phẩm
hoàn thành phần sớm phần cơ bản.

Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả cho
khách hàng. Những kết quả này đóng vai trò là mẫu thử để
giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.
Có thể thực hiện nhiều bước đồng thời. Nhân viên có thể thực
hiện những công việc tương tự ở các vòng một cách liên tục.

CNPM/NN

21


Mô hình tăng dần – 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 (thác nước?).
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ý, các nhân viên phải cộng tác tốt.

CNPM/NN

22


Mô hình tăng dần– khi nào sử dụng
„

„

„

Khi tất cả yêu cầu được hiểu khá rõ nhưng mong muốn có sự
tiến hóa dần của sản phẩm.
Khi cần phải nhanh chóng đưa sản phẩm với chức năng cơ
bản ra thị trường sớm.
Áp dụng cho những sản phẩm có thời gian phát triển dài hơn
1 năm.

CNPM/NN

23


2.3. Mô hình RAD (Rapid Application Development Models)
„

„

„

Mô hình này được đưa ra bởi IBM vào những năm 1980,
qua sách của James Martin.
Rapid Application Development một mô hình tiến trình phần
mềm gia tăng với chu kỳ phát triển ngắn (60-90 ngày).
Mô hình RAD dựa vào sử dụng thành phần (component) và
sử dụng các ứng dụng tạo mã tự động.

CNPM/NN

24


Mô hình RAD

CNPM/NN

25