Cmpm chuong 9-14 12-2009

PHẦN 2:
Chu trình sống của phần mềm /
Tiến trình phát triển phần mềm

TS. TRẦN CAO ĐỆ
NĂM 2010

Các bước chính trong tiến trình PM
Bài toán

Tìm hiểu yêu cầu
Đặc tả yêu cầu

Thiết kế
Đặc tả chương trình

Cài đặt
Chương trình

Kiểm thử
Chương trình làm việc

Bảo trì

CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 2

Chương 9:
Đặc tả yêu cầu

Requirement Engineering

1. Khái niệm đặc tả yêu cầu
• The hardest single part of • Nội dung đặc tả
building a system is – Yêu cầu chức năng
deciding what to build – Yêu cầu không chức năng:
hiệu quả của hệ thống, độ tin
• Đặc tả yêu cầu phần cậy, tài liệu người dùng, tập
mềm huấn, giá thành,…

– Bước đầu tiên trong tiến • Kết quả của đặc tả: tài liệu đặc
trình phần mềm tả yêu cầu
– Các yêu cầu của người – Phản ánh sự hiểu biết
dùng về hệ thống tương lai chung về vấn đề cần giải
phải được thu thập và tài quyết giữa người phân tích
liệu hóa. Chỉ tập trung vào và khách hàng.
what và bỏ qua how – Cơ sở để nghiên cứu khả
thi.
• Đặc tả yêu cầu khác với
– Cơ sở để kiểm thử-chấp
phân tích yêu cầu và đặc nhận.
tả hệ thống.

2. Yêu cầu về tài liệu đặc tả yêu cầu
• Tài liệu đặc tả phải đáp ứng:
– rõ ràng và dễ hiểu đối với khách hàng (dễ thuyết phục).
– đầy đủ và chi tiết vì đây là nguồn thông tin duy nhất dành cho
nhóm phân tích & thiết kế.

• Đặc điểm:
– Các lỗi xảy ra trong giai đoạn này sẽ ảnh hưởng đến các giai
đoạn còn lại của toàn bộ tiến trình.
– Là hợp đồng (contract) giữa khách hàng và nhà phát triển.
– Phải bao gồm các ràng buộc mà sản phẩm phải đáp ứng
– Đặc tả yêu cầu rất khó độc lập với phân tích, thiết kế.

• Loại đặc tả
– Client – driven
– Market – driven


3. Nội dung đặc tả
• Phần mềm: • Con người: các lớp
– Môi trường làm việc của người dùng, trình độ
phần mềm: OS, DBMS – người dùng
– Các phần mềm giao tiếp – người quản trị…
với phần mềm muốn phát
triển: • Tài liệu
• Các hệ thống đang tồn tại – Các yêu cầu về tài liệu
• Dữ liệu: nguồn dữ liệu, – Các biểu mẫu
format, dùng lại CSDL cũ.
• Thủ tục
• Giải thuật
– Qui trình nghiệp vụ
• Phần cứng: khả năng của
phần cứng. • Chức năng
– Các chức năng theo từng
– Khả năng lưu trữ nhóm người dùng
– Khả năng đáp ứng một tác
vụ … • Chất lượng
– Yêu cầu chất lượng
– Giá thành
– Thời gian đáp ứng


4. Hình thức đặc tả
• Dùng ngôn ngữ tự nhiên
– Ngữ nghĩa không rõ ràng, thường có nhiều lỗi
xảy ra
– Ngôn ngữ tự nhiên không phải là phương
cách tốt để đặc tả sản phẩm
• Dùng ngôn ngữ qui ước
– Bán hình thức/ đồ họa
• Phân tích theo cấu trúc
• Mô hình thực thể quan hệ
• OOP
– Ngôn ngữ hình thức
• Z, VDM, Petri net.

Case study - Thảo luận
• Viết đặc tả yêu cầu cho “hệ thống QL thư
viện”
– Nhóm các user
• Người thủ thư
• Đọc giả
• Người quản lí
• Người quản trị hệ thống
– Nhóm các yêu cầu theo
• Chức năng
• Chất lượng
• Công nghệ: DB, bộ nhớ, phần cứng


5. Ba bước chính trong đặc tả yêu cầu
User
• Nắm bắt yêu cầu user feedback
(requirement User Models to be
elicitation): hiểu các requirements validated by
user
yêu cầu knowledge Requirements
– Nhà phân tích # chuyên model
gia của lĩnh vực. elicitation specification validation
• Đặc tả các yêu cầu: Request more validation
mô tả các yêu cầu Domain
knowledge results

tài liệu hóa knowledge Domain
knowledge
• Kiểm tra và xác nhận : Problem
– Kiểm tra (verification): domain
yêu cầu được phát biểu
đúng.
– Kiểm tra – xác nhận
(validation): yêu cầu
đúng đã được phát biểu
và tài liệu hóa.


6. Phát biểu yêu cầu
• Các yêu cầu phải được phát • Vai trò người phân tích:
biểu tường minh và tài liệu hóa – Phân tích bài toán
• Mô hình hóa: một phần của thế – Thương thảo các yêu cầu
giới thực được quan tâm:
universe of discourse (UoD) • Các yêu cầu về hệ thống
• Mỗi người lên quan trong UoD phải được phát biểu
đều có một mô hình riêng, chính xác và đầy đủ
không tường minh về thế giới – Nhiều người liên quan
đó.
– Trình độ khác nhau
• Phát biểu yêu cầu
(requirements elicitation) là – Tầm nhìn khác nhau
phát biểu tường minh về mô • Các điểm cần lưu ý
hình không tường minh đó. – Con người thường có
thành kiến với phỏng vấn
– Con người thường không
có suy nghĩ logic nhất quán
– Người ta thường không thể
chính xác hóa cái mình
muốn


7. Các kỹ thuật dùng để phát biểu yêu cầu


8. Tài liệu đặc tả yêu cầu
• Tài liệu đặc tả: là sp cuối cùng – Thay đổi được
của bước đặc tả, là đầu vào – Lần vết được
của bước phân tích-thiết kế hệ • Chuẩn cho tài liệu đặc tả:
thống để có đặc tả hệ thống IEEE 830
(kiến trúc hệ thống) • Dàn ý cho một tài liệu đặc tả
• Tài liệu đặc tả phải (theo IEEE 830)
– Dễ đọc
– Dễ hiểu
– Đúng đắn (xác nhận bởi user)
– Không “mù mờ”
– Đầy đủ (chức năng, chất
lượng…)
– Nhất quán: các yêu cầu không
mâu thuẫn nhau.
– Có thứ tự: quan trọng ít
quan trọng
– Kiểm tra được: các đặc tả
phải định lượng để có thể test


Tài liệu đặc tả yêu cầu (tt)
• Phần 3 “specific requirements”
là phần dài nhất trong tài liệu,
bao trùm nhiều khía cạnh:
– Mode: chế độ vận hành (thử
nghiệm, thí điểm, dùng)
– User class: nhóm người dùng
– Objects: các đối tượng trong
thế giới thực
– Response: trả lời (đầu ra)
– Functional hierarchy: tổ chức
phân cấp các chức năng.
(tham khảo một tài liệu đặc tả
trang 228-229)


9. Kỹ thuật đặc tả yêu cầu
• Tài liệu đặc tả yêu cầu phục vụ • Mô hình thực thể quan hệ
cho:
– Người dùng
– Người thiết kế
• Tài liệu thường được viết bằng
NN tự nhiên và NN của người • Máy trạng thái hữu hạn
dùng:
– Nhiễu (noise): dư thừa nhiều
thông tin không cần thiết
– Im lặng (silence): cái chính lại
không được đề cập
– Đặc tả thừa: đề cập đến cách
giải quyết hơn là vấn đề phải
giải quyết
– Mâu thuẫn: 1 vấn đề đặc tả
nhiều lần không nhất quán • SADT
– Nhập nhằng
• Các sơ đồ UML
– Tham khảo về phía sau – Use case
– Mơ mộng (wishful thingking): – Class
– State
mô tả siêu thực – Cooperation
– …


Ví dụ về bộ điều khiển an toàn (két sắt)
• J = {Khóa an toàn, A, B, Không khóa an toàn, Chuông báo động }
• K = {1T, 1P, 2T, 2P, 3T, 3P}
• T = như hình vẽ
• S = {Khóa an toàn}
• F = {Không khóa an toàn, Chuông báo động}


Phân tích
• Phân tích là bước trung gian giữa • Kết quả của giai đoạn phân
đặc tả và thiết kế tích MÔ HÌNH PHÂN TÍCH
• Mục đích:
– Làm rõ thêm các yêu cầu
– Trình bày các yêu cầu bằng các
mô hình phân tích
– Định nghĩa rõ các thuật ngữ (từ
điển dữ liệu)
• Phân tích = xây dựng mô hình hệ
thống
– ERD
– DFD
– State diagram


10. Đặc tả các yêu cầu phi chức năng
• Yêu cầu phi chức năng (non- • Các yêu cầu phi chức năng đôi khi
functional requirements) còn được xem như yêu cầu về
– Giao diện với ht khác( External chất lượng
interface) – Phải xác định và test được
– Yêu cầu về hiệu quả vd: 80% giao dịch được đáp ứng
– Ràng buộc về thiết kế trong 1s; 20% còn lại đáp ứng
– Các đặc tính của hệ thống trong 3s.
• Giao diện với ht khác và ràng • Lưu ý:
buộc về thiết kế được xem như là
– Các yêu cầu phi chức năng
những yêu cầu bắt buộc, ví dụ:
có giá để thực hiện
– Phần cứng, phần mềm và giao
tiếp giữa chúng phải khả thi trong sự cân
– Giao diện người dùng theo chuẩn bằng với ngân sách.
của công ty.
Phải khả thi trên thực tế
– Format của tài liệu, báo cáo
– Ràng buộc về qui trình (vd ISO
Nếu cần thiết phải nghiên
9000) cứu khả thi trước.
– Giới hạn của phần cứng


11. kiểm tra (verification) và
kiểm tra-xác nhận (validation)
• Tài liệu đặc tả phải được: • Bằng việc kiểm tra tài liệu
– Kiểm tra (verification): đúng đặc tả yêu cầu
đắn, đầy đủ, nhất quán.
Nghĩa là tài liệu đặc tả có – Thiết lập test plan
chất lượng. – Xác định nguồn lực, pp để
– Kiểm tra-xác nhận kiểm thử trong quá trình
(validation): tài liệu đặc tả phát triển.
mô tả đúng đắn yêu cầu – Xác định kế hoạch kiểm
của khách hàng. Xác nhận thử bàn giao (acceptance
có hiệu lực/ giá trị.
test)
• Đối chiếu lại tài liệu đặc tả
với một danh sách kiểm
tra (checklist). Ví dụ:
– đã chỉ rõ các tài nguyên
phần cứng?
– đã chỉ rõ các tiêu chuẩn
chấp thuận ?


Tổng kết chương
• Đặc tả yêu cầu: • Công cụ để mô tả vấn đề:
– Làm rõ yêu cầu của bài – Ngôn ngữ tự nhiên
toán – Ngôn ngữ bán hình thức:
– Làm rõ các ràng buộc trong hình ảnh, biểu đồ
giải pháp – Ngôn ngữ hình thức
– Xác định cụ thể chức năng • Tài liệu đặc tả phải mô tả:
phải bàn giao và các yêu
cầu bắt buộc về môi – Yêu cầu chức năng
trường hoạt động – Yêu cầu phi chức năng
• Đặc tả yêu cầu là quá • Tài liệu đặc tả phải được
trình lặp của ba hoạt kiểm tra, xác nhận, phê
động chính: chuẩn.
– Requirement elicitation: để – Làm cơ sở cho kế hoạch
hiểu vấn đề kiểm thử & kiểm thử
– Requirement specification: – Làm cơ sở cho hợp đồng &
để mô tả vấn đề bàn giao sản phẩm.
– Requirement validation: để
thống nhất về vấn đề.


Chương 10:
Kiến trúc phần mềm

Software architecture

1. Thiết kế kiến trúc
• Xây dựng PM = xây dựng hệ thống có thiết
kế kiến trúc pm.
• Kiến trúc = thiết kế
– Quá trình xác định các hệ thống con trong hệ thống
và khung cho giao tiếp và điều khiển các hệ thống
con gọi là TKKT
– Sản phẩm của quá trình TKKT là kiến trúc PM.
– Kiến trúc của một xác định các thành phần tính toán
và tương tác giữa chúng trong hệ thống (Shaw,95)
– Kiến trúc pm (của một ct hoặc một ht tính toán) là cấu
trúc của hệ thống, bao gồm các thành phần, các tính
chất nhìn thấy được của các thành phần và quan hệ
giữa chúng.

Ví dụ một hệ thống máy (robot) đóng gói


Yêu cầu của một thiết kế
• Một thiết kế tốt
– Dễ đọc, hiểu
– Tin cậy
– Dễ phát triển
– bao trùm tất cả các yêu cầu tường minh
– Cung cấp hình ảnh tồng quan về pm
• Kiến trúc PM phục vụ:
– Trừu tượng hóa về hệ thống.
– Trao đổi, thương thảo giữa các bên liên quan.
– Trợ giúp quyết định.

Đặc trưng của KTPM
• Kiến trúc PM ảnh hưởng bởi:
– nhà phát triển.
– kiến thức và kinh nghiệm của người phân tích.
– Môi trường kỹ thuật và tổ chức.
• Một kiến trúc có thể gồm nhiều thành phần có
cấu trúc. Mỗi thành phần có cấu trúc có thể xem
xét riêng biệt còn gọi là khung nhìn (view)
– Conceptual/logical view
– Implementation view
– Process view
– Deployment view.


2. Mô hình kiến trúc
• Dùng để tài liệu hóa một kiến trúc.
• Mô hình cấu trúc tĩnh: các thành phần
chính của HT.
• Mô hình cấu trúc động: cấu trúc của tiến
trình trong HT.
• Mô hình giao diện: giao tiếp giữa các HT
con.
• Mô hình quan hệ: quan hệ giữa các HT
con.


3. Kiểu kiến trúc
• Kiến trúc là một sự xếp – Các kiểu kết nối
đặt hình thức các phần • Procedure call
tử kiến trúc. • Dataflow
• Implicit invocation: internal
• Một kiểu kiến trúc là sự events
xếp đặt có luật lệ các • Message passing
phần tử kiến trúc • Shared data
• Instantiation
• Kiến trúc phần mềm dựa
• Chương trình chính-ct con
trên:
• Kiểu dữ liệu tt
– Các kiểu thành phần • Implicit invocation
(components)
• Pipe and filter
• Computational
• Repository
• Memory
• Layered
• Manager
• Controller • Một HT lớn có thể bao
gồm nhiều kiểu kiến trúc

Ba kiểu kiến trúc thông dụng
– Data repository (kho dữ liệu);
– Shared services and servers;
– Abstract machine or layered.


Mô hình kho dữ liệu (repository)
• Các HT con trao đổi
(khối lượng lớn) dữ
liệu
• Hai kiểu trao đổi
– CSDL tập trung hoặc
kho DL (repository):
truy cập bởi tất cả HT
con
Ví dụ về kiến trúc của
– Mỗi HT con lưu trữ dữ một CASE toolset
liệu của riêng mình và (Rational Rose chẳng
hạn)
truyền dữ liệu tường
minh cho các HT khác


Đặc trưng của mô hình kho dữ liệu
• Thuận lợi
– Hiệu quả để chia sẻ một lượng lớn dữ liệu;
– Các HT con không không cần quan tâm đến dữ liệu
được quản lí thế nào (cập nhật, bảo mật,…).
– Lược đồ kho dữ liệu phải được chia sẻ.
• Hạn chế
– Các HT con phải thống nhất trên mô hình kho dữ liệu,
tức là phải có “cam kết và nhất trí”;
– Dữ liệu phát triển khó khăn và bảo trì đắt;
– Khó khăn khi phải giải quyết các chính sách đặc thù;
– Khó phân tán một cách hiệu quả.


Khách - chủ (Client – server)
• Hệ thống phân tán:
dữ liệu và xử lí được
phân bố phân tán
trong các thành phần.
• Tập hợp các máy chủ
chuyên biệt cung cấp
các dịch vụ.
• Các máy con gọi đến
các dịch vụ
• Mạng cho phép truy
cập các máy chủ.


Khách - chủ (Client – server)
• Thuận lợi
– Phân tán dữ liệu trực tiếp, tường minh.
– Sử dụng hiệu quả mạng. Dùng chung tài nguyên
– Dễ thêm máy chủ và nâng cấp máy chủ.
• Bất lợi
– Không chia sẻ mô hình dữ liệu các hệ thống con
dùng dữ liệu khác nhau. Trao đổi dữ liệu khó khăn,
không hiệu quả
– Quản lí dư thừa trên các máy chủ;
– Không có lưu trữ tập trung tên và dịch vụ khó tìm
một dịch vụ, cùng với một máy chủ sẳn sàng.


Mô hình phân tầng (layered)
• Dùng để mô hình tương
tác giữa các hệ thống con
• Tổ chức hệ thống thành
tập hợp các tầng (layer)
hoặc máy ảo (abstract
machines); mỗi tầng cung
cấp một số dịch vụ.
• Hỗ trợ phát triển theo mô
hình tăng trưởng các hệ
thống con trong các
tầng. Khi có thay đổi chỉ
có tầng liền kề bị ảnh
hương.
• Mô hình phân tầng chỉ là
kiến trúc nhân tạo.

4. Các mẫu thiết kế (design patterns)
• Một mẫu thiết kế là một cấu • Các tính chất của các mẫu
trúc lặp lại của các thành phần thiết kế:
tương tác với nhau để giải – Một mẫu có thể coi là dùng lại
quyết một vấn đề nào đó trong ý tưởng thiết kế. Nó thực chất
một ngữ cảnh cụ thể. là lặp lại ý tưởng thiết kế trong
• Mỗi mẫu thường chứa đựng một hoàn cảnh cụ thể
nhiều thành phần đơn lẻ. – Một mẫu phải cân nhắc các
yêu cầu đối lập; các tính chất
• Một mẫu thiết kế điển hình là của bài toán phải được tính
Model – view – controller đến trong giải pháp
(MVC). MVC gồm 3 thành – Các mẫu là những thiết kế tốt
phần đã biết. Nó chứa đựng nhiều
– Model: gồm dữ liệu và thao thành phần đơn lẻ nhưng đã
tác dữ liệu được biết rõ. Ví dụ: quicksort,
– View: cách thức hiển thị dữ FFT,…
liệu – Các mẫu là phương tiện để tài
– Controller: là cách thức xử lí liệu hóa phần mềm
của một view; cách thức điều (documentation). Nó còn là
khiển các hành vi từ dữ liệu chuẩn phải tuân theo.
đầu vào. Ví dụ update.

Các mẫu thiết kế (tt)
– Các mẫu không diễn tả một • CGI / ASP / JSP / PHP …
số yêu cầu không chức
năng như: tính mềm dẽo • Cache
tính thay đổi được và giao • Proxy
diện người dùng.
• Ví dụ về mẫu thiết kế
– Hệ thống quản lí thư viện
cho phép độc giả tìm kiếm
tài liệu (search) và đặt
mượn từ xa.
– Với yêu cầu này người
thiết kế có thể nghĩ ngay
đến kiến trúc client-server
(một mẫu kiến trúc)
Trong mẫu (pattern) này có
nhiều thành phần:
- Application trên máy chủ
- Application trên máy client
- Phương thức giao tiếp
(TCP/IP)

4. Kiểm tra và xác nhận
• Kiến trúc phần mềm đưa ra các quyết định về thiết kế.
Nó ảnh hưởng đến toàn bộ quá trình phát triển về sau
kiểm tra cẩn thận & phải được phê duyệt.
• Xét duyệt (review) và thanh tra (inspections) có thể được
dùng
• Đánh giá kiến trúc qua các tiêu chí chất lượng
• Đánh giá dựa trên đặc tả


• Kiến trúc phần mềm mô tả các phần tử trong hệ thống và tương tác
giữa chúng
• Các mẫu thiết kế (design patterns)
– định hướng cho thiết kế, tức là dàn xếp các phần tử trong hệ thống
– dùng lại ý tưởng thiết kế: áp dụng cấu trúc các thành phần đã biết vào
một hoàn cảnh cụ thể.
– Là phương tiện giao tiếp “chuẩn” trong thảo luận thiết kế

• Kiến trúc phần mềm đóng vai trò quan trọng
– Nó trình bày một thiết kế của phần mềm. Là sự tích hợp công nghệ vào
giải pháp cho bài toán
– nó giúp xác định, mô tả, phân loại các thành phần trong hệ thống ở
mức trừu tượng
– Nó thể hiện các quyết định về thiết kế để có thể xem xét, thảo luận
đánh giá giữa/bởi các bên có liên quan
– Nó thể hiện sự tương tự với các sp cùng họ trợ giúp quyết định dùng
lại (reuse)


Chương 11:
Thiết kế phần mềm

Software Design

1. Thiết kế phần mềm

• Từ mô hình phân tích thiết kế

Entity-
Relationship Procedural
Data Flow
Diagram design
Diagram
Data Dictionary Interface
design

State-Transition Architectural design
Diagram

Data design


2. Nguyên tắc thiết kế
• Chia hệ thống thành các hệ
thống con và đơn thể
– hệ thống con (sub-system):
bao gồm các phép toán và
dịch vụ/chức năng độc lập
– Đơn thể (module): là một
thành phần cung cấp dịch vụ
cho các thành phần khác
nhưng không phải là một hệ
thống độc lập
• Nguyên tắc module hóa
– Trừu tượng hóa:
• Proceduce: một chức
năng được mô hình hóa
• Data: Một đối tượng được
mô hình hóa bằng cách
thuộc tính phù hợp và cần
thiết
– Mịn dần


Phân tách chức năng (functional decomposition)

• Chia để trị (devide and • Hướng dẫn của Parnas:
conquer) – Xác định các hệ thống con.
• Mịn từng bước (stepwise Bắt đầu với tập hợp đơn giản
refinement) nhất. Không thể thu được hình
ảnh hoàn hảo của hệ thống
– Top-down: từ chức năng
ngay từ đầu
chính các chức năng cơ
bản – Áp dụng nguyên tắc che thông
tin/bao gói
– Bottom-up: các chức năng cơ
bản chức năng chính – Từng bước chia nhỏ các hệ
thống con đồng thời thêm các
• Cả top-down và bottom up đều chức năng mới vào hệ thống
được dùng trong quá trình thiết (mở rộng).
kế. – Áp dụng use-relation để thiết
lập cấu trúc phân cấp.


3. Các khái niệm trong thiết kế
• Abstraction
• Refinement
• Modularity
• Software Architecture
• Control Hierarchy
• Structural Partitioning
• Data Structure
• Software Procedure
• Information Hiding

4. Đánh giá thiết kế
• Tối ưu về giá (cost)
– Cost/module
– Cost tích hợp
– Total cost
• Đánh giá bằng fan-in,
fan-out: Tránh high fan-
out; cố gắng xây dựng
M
cấu trúc phân cấp Fan-out
• Đánh giá module hóa a b c
– Độc lập chức năng Depth
d e f g h
– Hợp nhất (cohesion)
Fan-in
– Gắn kết (coupling) i
– Nguyên tắc: High
Width
cohesion-low coupling


Tính hợp nhất (cohesion)
• Tính hợp nhất: là mức độ • Hợp nhất logic: module làm nhiều
chức năng có liên quan logic với
gắn kết giữa các phần nhau. VD module chứa tất cả các
trong một module thành phần input.
• Hợp nhất theo thời gian: Các
– Một thiết kế tốt thì module thành phần khác nhau cùng được
đơn nhất, tức là các thành khởi tạo vào 1 thời điểm.
phần gắn kết chặt chẽ • Hợp nhất thủ tục: nhiều thành
nhau để tạo nên chức năng phần độc lập thực hiện theo trình
đơn nhất của module tự.
• Hợp nhất giao tiếp: nhiều thành
– Đánh giá theo 7 cấp độ phần độc lập thực hiện trên cùng
(Yourdon) một dữ liệu.
• Hợp nhất ngẫu nhiên: các • Hợp nhất tuần tự: nhiều thành
phần độc lập thực hiện theo trình
thành phần không liên
tự, cái này làm đầu vào cho cái
quan với nhau kia.
• Hợp nhất chức năng: các thành
phần gắn kết nhau tạo nên chức
nằng đơn nhất của module.


Độ gắn kết (coupling)
• Độ gắn kết chỉ mức độ – gắn kết nhãn: hai module
phụ thuộc giữa các chia sẽ cùng CTDL.
module – Gắn kết dữ liệu: dữ liệu
được chuyển từ 1 module
• 6 mức độ gắn kết sang 1 module khác.
(Yourdon) • Tính hợp nhất & độ gắn
– Gắn kết nội dung: module kết là hai tính chất song
này làm thay đổi dữ liệu
của module khác. hành: nếu tính hợp nhất
– Gắn kết chung: chia sẽ dữ trong một module cao
liệu (tốt) thì độ gắn kết giữa
– Gắn kết ngoài: hai module các module sẽ thấp (tốt)
trao đổi dữ liệu thông qua
một media (vd file)
– Gắn kết điều khiển: module
chuyển điều khiển thực
hiện cho module khác
–

5. Độ phức tạp (complexity)
• Độ phức tạp của một bài • Đo độ phức tạp
toán là mức độ nỗ lực đòi – Nội module: đo dựa trên
hỏi để giải bài toán các thuộc tính bên trong 1
module đơn lẻ
• Độ phức tạp của PM là
– Ngoại module: đo dựa trên
mức độ nỗ lực để PTPM các thuộc tính của hệ
hoặc bảo trì PM. thống (tức là tập hợp các
module)
– Đo dựa trên kích thước
(size-based)
– Đo dựa trên cấu trúc
(structure-based)


Đo độ phức tạp theo size
• Số dòng lệnh (LOC) • Độ lớn chương trình (program volume)
V= Nlog2n (diễn dịch là số bits tối
– Số dòng lệnh lý tưởng thiểu)
30LOC/module (Weiberg,71) • Cấp độ chương trình (program level):
• Có những dòng lệnh “khó L=V*/V; V* là biểu diễn Compact nhất
của giải thuật đang xét. L được xấp xỉ
hơn” những dòng khác bởi L’=(2/n1)(n2/N2)
– i:=1; • Công sức viết chương trình
– While p^.next<>nil do p:=p^.next; E=V/L
• Software science (Halstead) • Thời gian viết chương trình
– n1: số toán tử phân biệt T=E/18 s
– n2: số toán hạng phân biệt • Halstead ước lượng N bởi
N’=n1log2n1+n2log2n2
– N1: tổng số toán tử
– N2: tổng số toán hạng
– Các độ đo:
• n=n1+n2 : số từ vựng
• N= N1+N2: độ dài chương
trình (program length).


Ví dụ
1. Procedure sort(var x:array; operator operand
n:integer); Procedure 1 X 7
2. Var i,j,save:integer; Sort() 1 N 2
3. Begin Var 2 I 6
4. for i:=2 to n do : 3 J 5
5. for j:=1 to i do Array 1 Save 3
6. if x[i]<x[j] then begin ; 6 “2” 1
7. save:=x[i]; Integer 2 “1” 1
8. x[i]:=x[j]; , 2
9. x[j]:=save Begin end 2
10. end For do 2
11. End; If then 1
:= 5
< 1
[] 6
n1=14 n2=7
N1=35 N2=25


• Áp dụng công thức tính
– Size of vocabulary: n=21
– Program length: N=60
– Estimated program length N’=73
– Program volume V=264
– Level of abstraction L=0.044
– Estimated level of abstraction L’=0.040
– Programming effort E=6000
– Time T=333s


Đo độ phức tạp theo cấu trúc
• Cyclomatic complexity • Ví dụ: thủ tục sort ở trang 34
(McCabe) có đồ thị như sau:
– Dùng một đồ thị có hướng để
biểu diễn các dòng điều khiển
chương trình
– Trong trường hợp tổng quát
thì đồ thị gồm nhiều thành
phần liên thông.
• Giả sử một thủ tục hoặc một
ct chính có một lối vào (start)
và một lối ra (end), thì đồ thị
là liên thông (chỉ có 1 thành
phần liên thông)
– Độ phức tạp của chương trình
= độ phức tạp của đồ thị:
C=e–n+p+1
e: là số cạnh; n: số nút
p: số thành phần liên thông Độ phức tạp: C=13-11+1+1=4


• Cyclomatic complexity có thể • Phản biện về độ đo
xem là số đường đi độc lập – Chương trình chứa các IF
trong đồ thị. tuần tự là “dễ” hơn các IF lồng
• Cách tính khác nhau. Độ đo của McCabe
C = D+1 không thể hiện ngữ cảnh các
IF lồng nhau không thỏa
D là số nút điều kiện (phân
điều kiện biểu diễn.
nhánh)
– Độ đo của Halstead không
C= 3+1=4
tính đến các dòng điều khiển.
• Khuyến cáo của McCabe
– Cyclomatic complexity của
một module không nên quá
10.
– Có thể dùng độ đo này
trong test: tính số đường đi
độ lập số test case
– Đo độ khó của chương
trình= mật độ IF: C/LOC.


Cấu trúc của hệ thống- Call Graph
• Kiến trúc của hệ thống có thể xem • Call graph
như một đồ thị: – Đồ thị có hướng
– Một nút: một module
– Có thể có chu trình
– Một cạnh: quan hệ giữa 2 module
• Nếu Call graph không có chu
• Các mối quan hệ giữa hai module:
trình ta gọi là cấu trúc phân
– A chứa B
– A theo sau là B
cấp và có thể phân chia thành
– A cung cấp dữ liệu cho B
các lớp sao cho mỗi module
– A dùng B
trong một lớp chỉ gọi đến các
• Call graph: đồ thị biểu diễn mối
modules trong các lớp dưới
quan hệ “A dùng B” • Các độ đo trên call graph
– Size: số nút, số cạnh
– Depth: đường đi dài nhất từ
nút gốc tới nút lá (trong đồ thị
không có chu trình)
– Width: số nút lớn nhất tại một
mức.


Cấu trúc hệ thống-Call graph
• Cấu trúc tốt-đơn giản nhất: call • M(G) cho biết độ phức tạp
graph hình cây. trong cấu trúc của hệ thống =
– Cây có n nút sẽ có số cạnh tối độ phức tạp trong quan hệ
đa là (n-1) giữa các module.
• Cấu trúc không tốt-phức tạp:
call graph có chu trình.
– Phức tạp nhất là đồ thị mà mỗi
căp nút đều nối với nhau, lúc
đó số cạnh sẽ là n(n-1)/2
• Đo độ phức tạp của call graph
(một đồ thị liên thông) tính
bằng
M(G)=2(e-n+1)/(n-1)(n-2)
M(G) biến thiên từ 0 đến 1
M(G)=0 call graph hình cây
M(G) = 1 call graph có các đỉnh
là nối kết đầy đủ.

Cấu trúc hệ thống-fan
• Độ phức tạp trong cấu trúc còn • Độ đo của Shepperd: độ phức
được đo bằng độ phức tạp tạp của module M là:
trong luồng thông tin giữa các Complexity(M)=
module: (fan-in(M)xfan-out(M))2
– Luồng cục bộ (local flow) từ A
đến B: ví dụ:
• A gọi B và truyền tham số complexity(A)=complexity(E)=0
• B gọi A và A trả về một giá trị
complexity(B)=complexity(C)=1
– Luồng toàn cục từ A đến B: A
cập nhật dữ liệu toàn cục và B complexity(D)=9
truy cập vào dữ liệu đó.
• Fan –in: tất cả các luồng ra
• Fan-out: tất cả các luồng vào

Fan-in(A)=0
Fan-out(A)=3


5. Phương pháp thiết kế
• Bảng quyết định
• ER
• Dòng dữ liệu (Flowchart)
• Phân tích cấu trúc (Structure Analysis/Structure
Design)
• SADT (structured analysis and Design technique)
• OOD (object oriented design)
• FSM (finite state machine)
• …


6. Tài liệu thiết kế
• 7 vai trò của tài liệu thiết kế • 10 thuộc tính của tài liệu thiết kế
1. Cho người quản lí: biết các 1. Định danh: tên
thành phần, chức năng ước
lượng chi phí 2. Kiểu: kiểu của thành phần
2. Người quản lí cấu hình: thông 3. Mục đích
tin về ráp nối các thành phần 4. Chức năng
và kiểm soát thay đổi 5. Hỗ trợ: thực thể hợp thành từ
3. Người thiết kế: chức năng và những thành phần nào
thành phần của hệ thống, quan 6. Phụ thuộc
hệ giữa các thành phần 7. Giao diện: với thành phần khác
4. Programmer: giải thuật, CTDL, 8. Nguồn lực cần thiết
tương tác giữa các thành phần
9. Xử lí: giải thuật, khởi tạo, quản lí
5. Người kiểm tra đơn vị (unit ngoại lệ.
tester): thông tin về thành
phần, giải thuật được dùng và 10. Dữ liệu: mô tả, formart, ý nghĩa
dữ liệu cần thiết Chuẩn IEEE 1016
6. Người kiểm tra tích hợp: quan
hệ giữa các thành phần, chức
năng và các thành phần có liên
quan
7. Người lập trình bảo trì: các
thành phần, cách hiện thức hóa
các yêu cầu người dùng


Tài liệu thiết kế (tt)
• IEEE 1016 nhóm 10 thuộc tính trên vào 4 nhóm sao cho
mỗi vai trò người dùng (user role) chỉ dùng 1 nhóm
– Mô tả phân tách
– Mô tả phụ thuộc
– Mô tả giao diện
– Mô tả chi tiết


• Nguyên tắc: • Các độ đo độ phức tạp
– thiết kế là phân chia hệ thống của module
thành các thành phần nhỏ, ít
phức tạp – Halstead
– Bên trong một module phải có – McCabe
tính kết hợp cao – Shepperd
– Giữa các modules phải có độ – Độ phức tạp của call graph
phụ thuộc thấp
– Mỗi module phải che dấu • Phương pháp thiết kế
thông tin theo cấu trúc
– Cấu trúc của hệ thống là phân – Phân tách chức năng
cấp (hình cây)
– Thiết kế dòng dữ liêu
• Một số độ đo chất lượng – Thiết kế cấu trúc dữ liệu,…
– Cohesion
– Coupling • Bài tập: 1 11
trang 346 và 347

Chương 12: Phân tích & Thiết kế
hướng đối tượng (OOAD)

Khái niệm về đối tượng
BOOK
• Đối tượng (object) -------------------
– Là một mô hình quan niệm về author: string
một phần thế giới thực hoặc Title: string
tưởng tượng ISBN: number
• Có một ID để phân biệt với --------------------
các đối tượng khác Archive()
• Có tính chất để giữ thông tin Borrow (Client)
về đối tượng Return()
– Object=identity + variables + Dispose()
operations
– Object= identity + state +
behavior • Giữa các đối tượng có mối
– Theo quan điểm SE: đối quan hệ với nhau:
tượng là sự TTH dữ liệu, bao
– Tổng quát hóa/ĐB hóa, is-a
gói dữ liệu và các thao tác
trên dữ liệu đó • Book is a Document
– Whole-part, has
• Book has Ttitle
– Member-of, has
• Library has Member


Phương pháp phân tích và TK HĐT
• Dựa vào đặc tả
– Xác định đối tượng
– Xác định thuộc tính
– Xác định quan hệ giữa các đối tượng
• Dùng phương pháp phân tích HĐT
– Booch
– OMT
– UML UML
2.0
2004
OMT UML
(Rumbaugh et al.) 1.4
May 2000
1996
UML
Booch UML 1.1
0.9 Nov. 1997

OOSE
(Jacobson et al.)


Các sơ đồ UML

State
State
Class
Diagrams
Use Case Diagrams
Use Case Diagrams State
Use Case Use Case
Diagrams State
Use Case Diagrams Diagrams
Object
Sequence
Diagrams Diagrams Diagrams
Diagrams Diagrams
Diagrams

Scenario State
Scenario State
Diagrams
Collaboration Component
Diagrams
Diagrams Models Diagrams
Diagrams Diagrams

Scenario Component
Scenario Component
Deployment
Diagrams
Statechart
Diagrams Diagrams
Diagrams Diagrams
Diagrams Activity
Diagrams


Performance
Engineer

Database
Administrator
Release
Engineer
Project
Leader

Analyst Designer / Tester
Developer


Các khái niệm trong OOAD
• OOAD dùng các ký hiệu đồ họa để vẽ mô hình
– Trường hợp sử dụng (use case)
– Sơ đồ lớp: mô hình tĩnh về phân chia hệ thống
– Sơ đồ trạng thái: hành vi động của đối tượng
– Sơ đồ tương tác
• Tuần tự (Sequence)
• Colaboration (hợp tác)
– CRC (class – responsibility – collaborators)


Trường hợp sử dụng
• Mô tả chức năng hệ thống
• Mô tả chi tiết từng chức năng
bằng các kịch bản (senario)

Ret urn of i tem

Librarian

Lend item
<<uses>>

Remove Reservation

Borrower
Make re servati on


Sơ đồ lớp
• Biểu diễn mối quan hệ giữa các
lớp • Bản số (multiplicity)
– Tổng quát hóa • Vai trò (role)
– Kết hợp (association)
– Kết tập (aggregation)
– Hợp thành (composition)


Sơ đồ đối tượng


Sơ đồ trạng thái
• Sơ đồ trạng thái tương tự như FSM.
• Biểu diễn hành vi của một đối tượng
– Một đối tượng có thể có nhiều trạng thái khác nhau
– Các trạng thái được chuyển lẫn nhau

Add student[ count < 10 ]
Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10 ]

Canceled
do: Notify registered students
Closed
Cancel do: Finalize course

Sơ đồ trạng thái của
một “lớp học”

Sơ đồ hoạt động
• Mô tả chi tiết cách thức
hoạt động của hệ thống:
– các hoạt động để tạo ra
một chức năng nào đó
– chi tiết hóa một use case


Sơ đồ tuần tự, hợp tác
• Biểu diễn sự hợp tác giữa các Sơ đồ hợp tác : Giống như
đối tượng (theo thời gian) để sơ đồ tuần tự nhưng không
thực hiện một tác vụ nhấn mạnh vào tính tuần tự
• Các đối tượng hợp tác bằng theo thời gian của thông điệp
cách “truyền thông điệp”

: Maint enance : Borrower
: Librarian
Window information 1: create borrower ( )
1: create borrower ( )

2: create (String, String) : Librarian
: Maintenance
Window

2: create (String, String)

: Borrower
information


Sơ đồ thành phần components


Sơ đồ triển khai


Rational Rose
• Công cụ hỗ trợ
– Qui trình RUP
– Phân tích & thiết kế theo UML


• Đối tượng
• Nguyên tắc PT & TK HĐT
• PP phân tích và TK HĐT: UML
– Các sơ đồ UML
– Rational Rose

• Bài tập: dùng Rational Rose để PT và thiết kế PM “đăng kí môn học”
(có tài liệu đặc tả)


Chương 13: Kiểm thử phần mềm
Software testing

Kiểm thử phần mềm là gì
• Test: – 60% lỗi thiết kế
– Thường được nghĩ như là – 40% lỗi cài đặt
thực hiện chương trình và • Kinh nghiệm cho thấy
kiểm tra xem output có – Càng phát hiện lỗi muộn giá
đúng không. sửa lỗi càng cao
– Các hoạt động kiểm thử – Không thể test được mọi
nhằm để đảm bảo tính trường hợp:
đúng đắn của chương trình • số test case rất lớn
• Chi phí test cao
• Có thể tạo ra phần mềm không
lỗi?
– 30-85 lỗi/KLOC
– Quá trình test phát hiện
0.5-3 lỗi/KLOC
• Hầu hết các lỗi xuất phát từ
các giai đoạn rất sớm trong qui
trình phần mềm [Boemh].

Các chiến lược kiểm thử
• Kiểm thử bao trùm (coverage-based testing)
• Kiểm thử lỗi (fault-based testing): dựa trên kỹ thuật phát
hiện lỗi.
• Kiểm thử sai lầm (error-based testing): dựa trên các
lỗi/sai lầm hay mắc phải
• Kiểm thử hộp đen (black-box testing) hay kiểm thử chức
năng
• Kiểm thử hộp trắng (white-box testing) hay kiểm thử cấu
trúc

• Kiểm thử đơn vị (unit testing)
• Kiểm thử hệ thống (integration testing).


Mục đích kiểm thử
• Các khái niệm • Verification và validation
– Error: một hành động của [IEEE]
con người dẫn đến kết quả – Verification: là quá trình
sai; kết quả là chương trình đánh giá một hệ thống
chứa lỗi (fault) hoặc một thành phần để
– Fault: một thể hiện của lỗi xác định rằng nó thỏa mãn
trong chương trình. Fault các điều kiện áp đặt tại giai
có thể đưa đến cái không đoạn bắt đầu.
mong đợi (failure) Have we build the system
• Failure có nguyên nhân là right?
fault; fault bắt nguồn từ – Validation: là quá trình
error của con người. đánh giá một hệ thống
hoặc một thành phần trong
– Failure có thể bắt nguồn từ hoặc sau quá trình phát
nhiều fault triển để xác định rằng nó
– Fault có thể dẫn đến nhiều đúng đặc tả
failure. Have we build the right
system?

Qui trình kiểm thử

• Vấn đề: chọn tập hợp con của input để test (test cases). Test cases
nhằm mục đích phát hiện lỗi.
• Kỹ thuật test: xác định các test cases một cách có hệ thống
– Chia miền dữ liệu của input làm các lớp
• Mục đích test: làm xuất hiện các lỗi (fault)


Hoạt động kiểm thử trong tiến trình phần mềm
• Hoạt động test diễn ra – Cài đặt
trong suốt quá trình phát • Kiểm tra sự phù hợp giữa
cài đặt với thiết kế
triển phần mềm
• Cài đặt test
– Giai đoạn đặc tả • Sinh ra dữ liệu test chức
• Xác định chiến lược năng và kiến trúc
• Đặc tả kiểm thử • Thực hiện test
• Sinh dữ liệu test chức – Bảo trì
năng
• Lặp lại các test trên trong
– Thiết kế quá trình phát triển lại
• Kiểm tra sự phù hợp giữa
thiết kế & đặc tả
• Đánh giá kiến trúc
• Kiểm thử kiến trúc
• Sinh ra dữ liệu test chức
năng và cấu trúc


Các giai đoạn test
• Mô hình chử V • System test
• Unit test – Test tích hợp các module
(integration testing) hay test
– Test từng module
chấp nhận (acceptance test)
• Test từ dưới lên
– Thường là test tính dùng
• Test từ trên xuống
được của hệ thống hơn là test
– Test từng module nhằm xác định
tính đúng đắn của từng module,
sự đúng đắn của code với đặc
tức là chất lượng của code tả
– Test tích hợp có thể bao gồm
cả test cài đặt
– Test tích hợp còn nhằm kiểm
tra độ tin cậy của hệ thống


Testing Tools


Kế hoạch kiểm thử & tài liệu
• Như các công đoạn khác trong
tiến trình phần mềm, kiểm thử
phải có kế hoạch và tài liệu
• Tài liệu bao gồm [IEEE,83]
– Test plan: Chuẩn IEEE 1012
– Test design
– Test cases: Mỗi test case mô
tả
• Input
• Output mong đợi
• Các điều kiện thực hiện
– Test procedure: Đặc tả chuỗi
các hoạt động để thực hiện
test
– Test report: Cung cấp thông
tin về việc thực hiện test
Test plan theo IEEE 1012

Các kỹ thuật test thủ công
• Đọc (reading) – Các thành viên inspection
– Đọc, đọc đi đọc lại sẽ đọc code thành từng
• Đặc tả yêu cầu,
cụm (chunk) và phân tích
tìm lỗi:
• Design
Lỗi dùng dữ liệu: biến
– Peer review không khởi tạo, vượt chỉ
• Đọc và đánh giá code lẫn số mảng, con trỏ nguy
nhau hiểm
• Nặc danh Lỗi khai báo: không khai
• inspections báo, hoặc khai báo cùng
tên trong các khối lồng
– Kiểm tra thực hiện bởi một đội nhau
(thường là 4 người) Lỗi tính toán: chia 0, tràn
– Mỗi người nhận tài liệu và số
code Lỗi trong phép toán quan
– Sau vài ngày nghiên cứu, cả 4 hệ: dùng > thay vì >=; thứ
ngồi lại để inspection tự ưu tiên.
Lỗi trong dòng điều khiển:
– Tác giả code có mặt nhưng lặp (n+1) lần thay vì n lần!
không phát biểu, chỉ trả lời Lỗi giao tiếp: tham số
câu hỏi (nếu có) truyền sai kiểu, sai số
tham số…

Các kỹ thuật test thủ công(tt)
– Quá trình inspection để phát • Đánh giá kịch bản
hiện lỗi, không sửa.
– Dựa trên các use case và
• Walkthroughs senario (mô tả use case)
– Trong quá trình test có thể
dùng dữ liệu đơn giản để chỉ • Chứng minh tính đúng
lỗi. đắn: {P} S {Q}
– Giả lập bằng tay
• Trừu tượng hóa từng
– Walkthroughs và inspection có
thể thực hiện ở bất kỳ giai buớc
đoạn nào của tiến trình phần – Ngược lại với stepwise
mềm miễn là tài liệu rõ ràng refinement (top-down)
và test được.
– TTH từng buớc áp dụng
– Khuyết điểm của PP: với bottom-up: từ cụ thể
• Người tham gia có kiến thức tổng quá hóa lên cái trừu
nông cạn
tượng
• Không đủ kiến thức về lĩnh
vực đang xét


Kỹ thuật kiểm thử bao trùm
(coverage-based testing)
• Kiểm thử bao trùm
– Số chỉ thị
– Số đường đi / nhánh chương trình
• Chương trình mô hình hóa bởi đồ thị
– Control graph: mô hình hóa các dòng điều khiển
– Data flow: mô hình hóa dòng xử lí từ khai báo 1 biến
tới kết quả
– Mô hình hóa đặc tả yêu cầu bởi đồ thị: mô hình dòng
dữ liệu (DFD)
• Dùng độ đo McCabe để tính số test case
– V(G) = số nhánh độc lập = số nút đk + 1


Ví dụ về control graph
1. Procedure sort(var x:array;
n:integer);
2. Var i,j,save:integer;
3. Begin
4. for i:=2 to n do
5. for j:=1 to i do
6. if x[i]<x[j] then begin
7. save:=x[i];
8. x[i]:=x[j];
9. x[j]:=save
10. end
11. End;

Số đường đi độc lập: V(G)=4
- 1-2-3-4-11
- 1-2-3-4-5-6-7-8-9-10-4-11
- 1-2-3-4-5-6-10-4-11
- 1-2-3-4-5-4-11


Kỹ thuật test dựa trên lỗi (fault)
• Seed fault – Một số nguyên tắc thay thế:
– Cài một số lỗi vào module • Thay hằng bởi hằng khác
– Kiểm thử để phát hiện lỗi • Thay biến bởi biến khác
• Thay hằng bởi biến
– Trong quá trình kiểm thử phát
hiện lỗi “cài cắm vào” sẽ phát • Thay phép toán số học bằng
phép toán số học khác
hiện ra một số lỗi “thật”
• Thay phép toán logic bằng
• Kiểm tra bằng cách thay thế phép toán logic khác
– Giả sử có chương trình P cần • Thêm phép toán một ngôi
kiểm thử. P sinh ra kết quả • Xóa một dòng lệnh
đúng với một số test case (vd – Ví dụ
T1 và T2) • If x<4.5 then
– Sửa P tại 1 chổ nào đó P’ Có thể thay thế bởi:
– Kiểm thử P’ với T1 và T2 • If x>4.5 then
– Giả sử P’(T1)=P(T1) và • If x=4.5 then
P’(T2)=P(T2) • If x<4.6 then
– T1 có ý nghĩa trong test vì nó • If x<4.4 then
có thể cho biết có sai sót trong • …
P hoặc P’


Kỹ thuật test dựa trên sai lầm (error)
• Test các giá trị biên • Vd:
– ON point: điểm nằm trên biên – Đặc tả
của một miền con • Nếu 80%<Tỉ lệ <=100%
– OFF point: điểm nằm cạnh “chắc chắn”
biên (trong hoặc ngoài) • Nếu 50<= tỉ lệ <= 80%
“khá chắc chắn”
• Nếu 0<= tỉ lệ <50% “không
chắc chắn
– Các test case

– Nếu có n miền con Di, i=1..n
• Test n ON point Tỉ lệ =0% (ON) Tỉ lệ = 70% (OFF)
• Test ít nhất 1 OFF point cho Tỉ lệ = -1 % (OFF) Tỉ lệ = 80% (ON)
Tỉ lệ = 1% (OFF) Tỉ lệ = 99% (OFF)
mỗi biên
Tỉ lệ =49% (OFF) Tỉ lệ = 100% (ON)
– Lưu ý: các miền có thể có ON Tỉ lệ = 50% (ON) Tỉ lệ = 1000% (OFF)
point chung hoặc OFF point
chung.


Các nghiên cứu thực nghiệm
• Meyer, 88
– 85% lỗi được phát hiện trong quá trình inspection ở
các giai đoạn đặc tả, thiết kế, code review
– Inspection là tốt hơn walkthroughs
• Collofello,89
– Phân tích 700000 dòng code phát triển bởi 400 người
phát hiện 676 lỗi, trong đó
• 54% phát hiện bởi xem xét thiết kế
• 33% phát hiện bởi xem xét code
• 38% phát hiện bởi test


• Test thủ công • Bài tập: 1 14 trang
– Peer review 442,443
– Inspection
– Walkthroughs
• 3 kỹ thuật
– Test bao trùm
– Test dựa trên lỗi
– Test dựa trên sai lầm


Chương 14: Bảo trì phần mềm
Chương 19: Công cụ phần mềm

Tự đọc thêm

Cmpm chuong 9-14 12-2009

Recommended

Recommended

More Related Content

Similar to Cmpm chuong 9-14 12-2009

Similar to Cmpm chuong 9-14 12-2009 (20)

Cmpm chuong 9-14 12-2009