Bài giảng đảm bảo chất lượng phần mềm vấn đề quản lý chất lượng trong công nghệ phần mềm PGS TS trần cao đệ

Đảm bảo chất lượng phần mềm
Software Quality Assurance

VẤN ĐỀ QUẢN LÍ CHẤT LƯỢNG
TRONG CÔNG NGHỆ PHẦN MỀM
PGS. TS. Trần Cao Đệ
Bộ môn Công nghệ phần mềm
Khoa CNTT&TT – Đại học Cần Thơ
Năm 2013


CÔNG NGHỆ PHẦN MỀM là gì?


PHẦN MỀM
•

Phần mềm là gì?
-

-

-

-

•

Là hệ thống gồm có chương trình máy tính, tài liệu, dữ
liệu và qui trình vận hành các chương trình đó để vận
hành hệ thống máy tính

Phần mềm không chỉ là các chương trình máy tính mà
còn bao gồm cả các tài liệu cần thiết cho việc phát triển
và bảo trì các chương trình đó.
Ngày nay các phần mềm là phần không thể thiếu trong
hệ thống tác nghiệp tại các cơ quan, xí nghiệp
Phần mềm có mặt khắp nơi: điện thoại di động, máy
lạnh, máy giặt, đồ chơi,…

Chất lượng phần mềm như thế nào? Phần mềm kém
chất lượng có tác hại gì?
3


Lỗi phần mềm

4


Lỗi phần mềm (tt)
•

Hình ảnh tên lửa Ariane 5 nổ
tung ngày 4/6/1996 sau vài
giây được phóng lên, thiệt hại
500.000.000$US.

•

Image source: European
Space Agency

5


Lỗi phần mềm (tt)

Therac – 25

•

Máy xạ trị chế tạo bởi
Canada + Pháp.

•

1985-1987: Ở
Washington DC, KTV
thao tác lỗi, máy hào
phóng cho quá liều bình
thường ít nhất với 6
bệnh nhân.

•

Kết quả:
– Chết 3
– Số còn lại ngoắc ngoải!
6

Lỗi phần mềm (tt)
•
•

•
•

Sân bay Denver (USA), 1994
Bugs trong hệ thống quản lí hành lí (Baggage Handling
System) đã làm cho hệ thống chậm tiến độ 16 tháng,
thiệt hại mỗi ngày 1.000.000 $US.
Tổng số thiệt hại > số tiền đầu tư cho dự án (234M)
Nếu tính tổng số tiền phải chi để thao tác bằng tay, thiệt
hại lên đến hơn 3G $US

7


Lỗi phần mềm (tt)
•

Ở VN:
-

Chưa nghe nói có phần mềm nào kém chất lượng
SV có thể thêm ví dụ vào đây

8

Tại sao phần mềm kém chất lượng?
•

Câu hỏi thảo luận: nêu 10 nguyên nhân dẫn đến phần
mềm kém chất lượng

•

Sắp xếp 10 nguyên nhân đó theo thứ tự: quan trọng
nhất  ít quan trọng nhất

•

Tổng hợp của cả lớp để chọn ra 10 nguyên nhân chung
nhất

9


Các nguyên nhân gây lỗi phần mềm
• Faulty requirement definition.
•

Client-developer communication failures.

•

Deliberate deviations from software requirements.

•

Logical design errors.

•

Coding errors.

•

Non-compliance with documentation and coding instructions.

•

Shortcomings of the testing process.

•

User interface and procedure errors.

•

Documentation errors.

10


CÔNG NGHỆ PHẦN MỀM
•

Thuật ngữ Software Engineering

•

CNPM là: (1) áp dụng cách tiếp cận có hệ thống, khoa
học và định lượng vào phát triển, vận hành và bảo trì
phần mềm; (2) nghiên cứu các cách tiếp cận nêu trên
[IEEE93].

•

CNPM là việc thiết và dùng các nguyên tắc công nghệ
đúng đắn để thu được phần mềm một cách kinh tế nhất
và chạy hiệu quả trên các máy thật [NATO68].

11


CÔNG NGHỆ PHẦN MỀM (tt)
•

•

CNPM tập trung vào các chương trình lớn, phức tạp,
yêu cầu cao về chất lượng
CNPM tập trung vào PP luận và nguyên tắc thực hành
để phát triển phần mềm chuyên nghiệp
-

•
•

Làm việc có tổ chức khoa học
Đội ngũ KS/lập trình viên đông, chuyên môn hóa
Tác phong chuyên nghiệp

Phát triển mềm không phải là chế tạo, lắp ráp
Sản phẩm phần mềm
-

Sản phẩm trí tuệ
Vô hình
Thời gian dài, kinh phí lớn, outsource, third party.
Không ngừng tiến triển
12


Vấn đề quản lí trong CNPM
•

Mục tiêu: thỏa mãn yêu cầu của khách hàng
-

•

Giao hàng (phần mềm) đúng hạn
Sản phẩm có chất lượng
Chi phí trong khung ngân sách đã dự kiến

Quản lí dự án phát triển phần mềm
-

Lập kế hoạch phát triển phần mềm







-

Qui trình phần mềm/chu trình sống
Yêu cầu phần mềm
Kế hoạch nhân sự
Kế hoạch chất lượng
Ước lượng giá thành
Quản lí rủi ro

Kiểm soát kế hoạch phát triển phần mềm
13


Phạm vi của CNPM
•

Theo Pressman
-

Điều hành và theo dõi dự án phần mềm
Qui trình phần mềm

Xem xét các kỹ thuật hình thức
Đảm bảo chất lượng phần mềm
Công tác tài liệu
Sử dụng lại
Đo lường phần mềm
Quản lí rủi ro dự án phần mềm

14


Qui trình phần mềm
•

Qui trình phần mềm
-

•

Các bước chính trong tiến trình phát triển phần mềm
-

•

Các bước tiến hành một phần mềm
Mô hình tiến trình
Tìm hiểu yêu cầu
Phân tích-thiết kế
Cài đặt
Kiểm thử

Các mô hình về tiến trình
-

Mô hình xây dựng và hiệu chỉnh
Mô hình thác nước
Mô hình định khung nhanh
Mô hình xoắn ốc
Mô hình hướng đối tượng,…
15


Kế hoạch về nhân sự/nhân lực

xác định yêu
cầu, 10%
đặc tả, 10%
kiểm thử, 45%
thiết kế, 15%

cài đặt, 20%

16


Đặc tả yêu cầu phần mềm
•

Các yêu cầu của người dùng về hệ thống tương lai
-

•

Nội dung đặc tả
-

•

Chỉ tập trung vào what và bỏ qua how
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
Yêu cầu chức năng
Yêu cầu không chức năng: hiệu quả của hệ thống, độ tin cậy, tài liệu
người dùng, tập huấn, giá thành,…

Kết quả của đặc tả: tài liệu đặc tả yêu cầu
-

-

Phản ánh sự hiểu biết chung về vấn đề cần giải quyết giữa người
phân tích và khách hàng.
Cơ sở để nghiên cứu khả thi.
Cơ sở để kiểm thử-chấp nhận.

17


Ba bước trong đặc tả yêu cầu
User feedback

user
User requirements

Models to be validated
by user

Requirements model

knowledge

elicitation

specification
Request more knowledge

validation
validation results

Domain knowledge
Domain knowledge

Problem
domain
18


Phân tích (Analyze)
•

Phân tích là bước trung gian giữa đặc tả và thiết kế:

-

•

Mục đích:
-

•

Giai đoạn cuối của đặc tả
Giai đoạn đầu của thiết kế
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)

Kết quả của phân tích: xây dựng mô hình hệ thống
-

ERD
DFD
State diagram…
19


Kết quả của quá trình phân tích yêu cầu
Một ví dụ: kết quả theo phân tích truyền thống 
Mô hình thực thể quan hệ

20

Thiết kế (Design)
•

•

•

Thiết kế là giai đoạn chuyển từ đặc tả yêu cầu sang xây
dựng
Là quá trình chia nhỏ hệ thống thành các thành phần,
xác lập quan hệ giữa các thành phần và mô tả chi tiết
từng thành phần ở mức có thể xây dựng được
Thiết kế = chỉ ra giải pháp để xây dựng
-

•
•

Có thể không phải tốt nhất
Có thể không phải duy nhất
NHƯNG: NÓ LÀ CÁI TỐI ƯU NHẤT - CÂN BẰNG CÁC
YÊU CẦU ĐỐI LẬP NHAU.

Thiết kế kiến trúc (software architecture
design)
Design
pattern:
dùng lại ý tưởng
Thiết kế chi tiết (detailed design)

& các mẫu thiết kế
21


Thiết kế kiến trúc
Requirements

(from customer)
Conceptual

System

Analysis

Arch. Breakdown

Req 1
Req 2
…
Req n

Req 1..i

Subsys. 1

Req i..j

Subsys. 2

Req j..n

Subsys. 3

22


Thiết kế chi tiết
•
•
•

Module
Giao diện người dùng
Giải thuật

23


OOD
•

UML Diagrams
-

Class
Use Case
Collaboration
Sequence
Statechart

Component
Activity

24


Cài đặt
•

Cài đặt
-

•

Viết code
Kiểm thử đơn vị

Viết code
-

Ngôn ngữ lập trình
Sử dụng thư viện / Nguồn mở
Hình thức chuẩn của code
Refactoring



Cải tiến thiết kế và code đã có một cách an toàn
Viết lại source code để cải tiến thiết kế và tính dễ đọc

25