Bài giảng Công nghệ phần mềm - Chương 2: Qui trình phát triển phần mềm

c 
hợp lý, các nhân viên phải cộng tác tốt.
23CNPM/NN
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.
24CNPM/NN
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.
25CNPM/NN
Mô hình RAD
26CNPM/NN
Mô hình RAD – điểm yếu
„ Người phát triển phải có kỹ năng và được huấn luyện tốt cho 
việc sử dụng công cụ và cho việc phát triển nhanh.
„ Hệ thống có khả năng phân tách module rõ ràng.
„ Cần các thành phần sử dụng lại.
„ Người phát triển và khách hàng cần phải nỗ lực cộng tác.
27CNPM/NN
Mô hình RAD – khi nào sử dụng
„ Hệ thống dễ dàng phân chia module và có thể mở rộng.
„ 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, 60-90 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 (critical)…
28CNPM/NN
2.4. Mô hình Tạo bản mẫu (Prototyping)
listen
to
customer
build
mock-up (mẫu)
customer
test-drives
mock-up
Prototyping
29CNPM/NN
Mô hình tạo bản mẫu
„ Mô hình bản mẫu dựa trên ý tưởng xây dựng một mẫu thử ban đầu 
(Prototype – nguyên mẫu) và đưa cho người sử dụng xem xét; sau 
đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thỏa mãn 
yêu cầu của người sử dụng thì dừng lại.
„ Mẫu thử ban đầu như là một cơ chế để nhận diện chính xác yêu 
cầu của khách hàng (Throwaway Prototyping)
„ Mẫu thử ban đầu có thể trở thành sản phẩm. Khi các yêu cầu của 
người sử dụng được thỏa mãn thì cũng là lúc chúng ta đã xây dựng 
xong hệ thống (Evolutionary Prototyping)
30CNPM/NN
Mô hình tạo bản mẫu – ưu điểm
„ Khách hàng tương tác sớm với hệ thống.Khách hàng và 
người phát triển dễ dàng trao đổi.
„ Người phát triển có thể xác định nhanh chóng và chính xác 
được yêu cầu nhờ vào nguyên mẫu.
„ Có thể phát hiện những yêu cầu mới hoặc những yêu cầu bất 
ngờ.
31CNPM/NN
Mô hình tạo bản mẫu - Nhược điểm
„ Là phương pháp Quick-and-dirty thường thiếu tư liệu hay tư 
liệu không phù hợp. Người phát triển có thể rơi vào chu kỳ 
code-and-fix.
„ Hệ thống được 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 này 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 hối thúc nhà phát triển hoàn thành sản phẩm một 
khi thấy được các nguyên mẫu (prototype) đầu tiên.
32CNPM/NN
Mô hình Tạo bản mẫu – khi nào sử dụng
„ Khi yêu cầu không được biết rõ, khi các yêu cầu không ổn 
định, việc thông tin không được đáp ứng tốt.
„ 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 nào là tối ưu. Trên những hệ thống dựa vào kỹ thuật 
mới mà những yêu cầu khó xác định rõ.
„ Một vài phần của hệ thống lớn có thể thích hợp cho mô hình 
bản mẫu (giao diện người dùng).
„ Phù hợp với những hệ thống:
„ user-interface intensive systems.
„ interactive online systems. 
„ first-of-a-kind products.
„ decision support systems…
33
2.5. Mô hình xoắn ốc (Spiral Model)…
34CNPM/NN
Mô hình xoắn ốc…
Risk
analys is
Risk
analys is
Risk
analys is
Risk
analysis Proto-
type1
Prototyp e
2
Prototype
3
Opera-
tional
protoype
Concept o f
Operation
Simulations, models, b enchmarks
S/W
requi rements
Requirement
valid ation
Design
V&V
Product
design Detailed
design
Code
Uni t tes t
Integr ation
testAccep tance
testServ ice
Integration
and test p lan
Development
plan
Requirements plan
Life-cycle plan
REVIEW
Progress 
through 
steps
Commulative Cost
Determine Objectives, 
alternatives, 
constraints
Evaluate alternatives, 
Identify, resolve risks
Develop, verify next-
level product
Plan next phases
Commitment 
Ratio
35CNPM/NN
Mô hình xoắn ốc…
„ Đề nghị bởi Berry Boehm, 1988.
„ Mô hình xoắn ốc có thể xem là siêu mô hình (metamodel) do 
nó có thể xem là các mô hình khác trong những tình huống 
thích hợp.
„ Mỗi vòng lặp đều có phân tích rủi ro, chỉ báo sớm những rủi ro 
không thể khắc phục với phí tổn không cao.
36CNPM/NN
Mô hình xoắn ốc – nhược điểm
„ Cần kiến thức đánh giá rủi ro chuyên sâu. Việc đánh giá rủi ro 
tốn nhiều chi phí, không không thích hợp cho những dự án rủi 
ro thấp hay nhỏ.
„ Mô hình phức tạp, khó sử dụng.
„ Khó quản lý tiến trình và thuyết phục khách hàng.
37CNPM/NN
3. Các vấn đề khác: Dùng thành phần
„ Phát triển dựa vào thành phần (component): xây dựng hệ 
thống từ việc tích hợp các thành phần đang có hoặc các 
thành phần thương mại COTS (Commercial-off-the-shelf).
„ Dùng thành phần giảm 70% thời gian và 84% chi phí.
38CNPM/NN
Kỹ thuật thế hệ thứ 4
„ 4GT (fourth generation technique) là kỹ thuật dựa vào công cụ 
phần mềm, có thể đặc tả phần mềm ở mức khái niệm cao 
theo một cách thức định trước công cụ sẽ tự động sinh mã.
„ 4GT thích hợp cho ứng dụng vừa và nhỏ.
„ 4GT tăng năng suất đáng kể.
„ Một số ý kiến cho rằng:
„ Một số công cụ khó sử dụng.
„ Chương trình tạo ra cồng kềnh.
„ Việc bảo trì cho các hệ thống lớn là một vấn đề.
„ 4GT + dùng thành phần là hướng phát triển rất mạnh hiện 
nay.
39CNPM/NN
Qui trình RUP
„ Qui trình phát triển phần mềm thống nhất RUP (Rational 
Unified Process) là một trong những mô hình phát triển dựa 
trên thành phần dùng Ngôn ngữ mô hình thống nhất (UML-
Unified modeling language).
„ RUP là qui trình do hãng Rational phát triển.
40CNPM/NN
Các vấn đề về phần mềm
41CNPM/NN
Nguyên nhân
42CNPM/NN
Qui trình RUP (Rational Unified Process)
„ Giải quyết
„ Phát triển theo vòng lặp.
„ Quản lý yêu cầu.
„ Sử dụng thành phần.
„ Mô hình trực quan.
„ Thẩm định chất lượng.
„ Kiểm soát thay đổi.
43CNPM/NN
Các giai đoạn RUP
• Khởi tạo.
• Hình thành.
• Xây dựng.
• Chuyển giao.
44CNPM/NN
Phát triển lặp
45CNPM/NN
Qui trình RUP
„ Giai đoạn 1 (Inception): khởi tạo.
„ Xác định phạm vi dự án, yêu cầu người dùng và các ràng 
buộc.
„ Xác định Yêu cầu nghiệp vụ, phân tích rủi ro, lập kế hoạch 
dự án (phân công, chi phí).
„ Thiết kế kiến trúc hệ thống (quan tâm đến chi phí, lịch biểu, 
tài nguyên).
„ Cấu hình môi trường làm việc, công cụ.
46CNPM/NN
Qui trình RUP
„ Giai đoạn 2 (Elaboration): Hình thành.
„ Tinh chỉnh tài liệu.
„ Hoạch định những bước lặp.
„ Kế hoạch phát triển: qui trình, công cụ CASE.
„ Tinh chỉnh kiến trúc và chọn thành phần (component).
47CNPM/NN
Qui trình RUP
„ Giai đoạn 3 (Construction): Xây dựng.
„ Quản lý tiến trình tạo sản phẩm: tăng năng suất, đảm bảo 
chất lượng.
„ Tạo sản phẩm (alpha, beta, các phiên bản test khác).
„ Kế hoạch triển khai ứng dụng: chuẩn bị phần mềm, huấn 
luyện người sử dụng, các biện pháp hỗ trợ…
48CNPM/NN
Qui trình RUP
„ Giai đoạn 4 (Transition): Chuyển giao.
„ Tạo sản phẩm xuất xưởng.
„ Kiểm tra sản phẩm, thu thập thông tin phản hồi.
49CNPM/NN
UP Work Products
Incept ion phase
Elaborat ion phase
Const ruct ion phase
Transit ion phase
V ision document
Init ial use-case model
Init ial project g lossary
Init ial business case
Init ial risk assessment .
Pro ject plan,
phases and it erat ions.
Business model,
if necessary .
One or more prot ot y pes
I ncept i o
n
Use-case model
Supplement ary requirement s
including non-funct ional
Analy sis model
Sof t ware arch it ect ure
Descrip t ion.
Execut able arch it ect ural
prot ot y pe.
Pre liminary design model
Rev ised risk list
Pro ject p lan including
it erat ion plan
adapt ed workf lows
milest ones
t echnical work product s
Pre liminary user manual
Design model
Sof t ware component s
Int egrat ed sof t ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descrip t ion of current
increment
Deliv ered sof t ware increment
Bet a t est report s
General user feedback
50CNPM/NN
PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOẠT
PPPTPMLH (Agile software development)
„ Khác biệt dễ nhận thấy của PPPTPMLH đó là lượng giấy tờ 
tài liệu ít hơn và có thể nói là tập trung vào việc lập trình 
hơn. Nhưng ẩn đằng sau đó là hai khác biệt nền tảng quan 
trọng: “thích ứng thay vì dự đoán” và “hướng đến con người 
thay vì qui trình”.
„ PPPTPMLH đề cao tính chủ động và sáng tạo của các cá 
nhân tham gia, và đặc biệt là việc trao đổi thông tin giữa các 
thành viên.
„ PPPTPMLH không khước từ sự tổ chức nhưng nó cố gắng 
cân bằng giữa sự tổ chức và sự linh hoạt, cân bằng giữa 
việc không có qui trình nào cả và qui trình quá chi li và cứng 
nhắc.
51CNPM/NN
Phương pháp Agile: Scrum
„ Schwaber và Beedle
„ Đặc trưng
„ Chia công việc thành những packet.
„ Test và tư liệu khi sản phẩm đang được xây dựng.
„ “product backlog” và “sprint backlog”.
„ Gặp gỡ ngắn.
„ “demo” được chuyển tới khách hàng.
52CNPM/NN
Scrum
53CNPM/NN
Extreme Programming (XP)
„ Là qui trình Agile được dùng rộng rãi nhất (Kent Beck)
„ XP Planning:
„ Tạo “user stories”.
„ Đánh giá câu chuyện và gán một chi phí.
„ Gom các câu chuyện thành một phần gia tăng có thể chuyển 
giao (deliverable increment).
„ Một cam kết về thời gian chuyển giao. 
„ Xác định thời gian cho các phần gia tăng khác.
54CNPM/NN
Extreme Programming
„ XP Design:
„ Nguyên lý KIS (Keep It Simple).
„ Dùng thẻ CRC (Class Responsibility Collaborator).
„ Nếu gặp trở ngại về thiết kế dùng nguyên mẫu (prototype).
„ Phân tách lại (refactoring).
„ XP Coding:
„ Xây dựng kiểm thử đơn vị trước.
„ Lập trình “pair programming”.
„ XP Testing:
„ Tất cả các đơn vị được kiểm thử hàng ngày, tích hợp liên tục.
„ Thực hiện kiểm thử chấp nhận (Acceptance tests).
55CNPM/NN
Class-Responsibility-collaborator (CRC)