Bài giảng Kỹ nghệ phần mềm - Nguyễn Quốc Toản

cũng tuân theo một nguyên lý t−ơng tự cho việc truy cập dữ liệu hệ 
thống. Mỗi thành phần ch−ơng trình chỉ đ−ợc phép truy cập đến dữ liệu nào cần thiết để thực hiện 
chức năng của nó. 
Ưu điểm của việc che dấu thông tin là các thông tin bị che dấu không thể bị sập đổ bởi 
các thành phần ch−ơng trình mà đ−ợc xem rằng không dùng thông tin đó. Biểu diễn dữ liệu có thể 
đ−ợc thay đổi mà không phải thay đổi các thành phần khác có sử dụng thông tin đó. 
B) Thứ lỗi 
 Ngay với một hệ vô lỗi thì vẫn cần một tiện ích thứ lỗi: đó là vì có thể có các lỗi đặc tả. Một 
tiện ích thứ lỗi là cần thiết cho một hệ thống đáng tin. 
Có bốn hoạt động cần phải tiến hành nếu hệ thống là thứ lỗi: 
i) Phát hiện lỗi. 
ii) Định ra mức độ thiệt hại. 
iii) Hồi phục sau khi gặp lỗi. Hệ thống phải hồi phục về trạng thái mà nó biết là an toàn. 
 Ch−ơng IV - 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi – Lê Đình Phùng 
104
Cũng có thể là chỉnh lý trạng thái bị huỷ hoại (hồi phục tiến), cũng có thể là lui về một trạng thái 
tr−ớc mà an toàn (hồi phục lùi). 
iv) Chữa lỗi: Cải tiến hệ thống để cho lỗi đó không xuất hiện nữa. trong nhiều tr−ờng 
hợp sự thất bại của phần mềm là tàng hình và gây ra bởi một tổ hợp của thông tin vào. 
C) Xử lý bất th−ờng 
Một sai lầm nào đó hoặc một sự cố bất ngờ xuất hiện đ−ợc gọi là một bất th−ờng. Các bất 
th−ờng có thể do phần cứng cũng có thể do phần mềm. Khi mà một bất th−ờng không đ−ợc dự đoán 
thì bộ điều khiển sẽ chuyển cho cơ chế xử lý hệ thống bất th−ờng. Nếu một bất th−ờng đã đ−ợc dự 
đoán thì mã phải baogồm cả việc phát hiện và xử lý bất th−ờng đó. 
Hầu hết các ngôn ngữ lập trình là không có các tiện ích để phát hiện và xử lý bất th−ờng. 
Các bất th−ờng có thể đ−ợc ghi lại bằng cách dùng một biến Bool nhằm chỉ ra rằng có một bất 
th−ờng đã xuất hiện. 
D) Lập trình phòng thủ 
Lập trình phòng thủ là cách phát triển ch−ơng trình mà ng−ời lập trình giả định rằng các 
mâu thuẫn hoặc các lỗi ch−a đ−ợc phát hiện có thể tồn tại trong ch−ơng trình. Phải có phần mềm 
kiểm tra trạng thái hệ thống sau khi biến đổi và phải đảm bảo rằng sự biến đổi trạng thái là kiên 
định. Nếu phát hiện một mâu thuẫn thì việc biến đổi trạng thái là phải rút lại và trạng thái phải trở về 
trạng thái đúng đắn tr−ớc đó. 
Lập trình phòng thủ là một cách thứ lỗi, mà đ−ợc tiến hành không cần bộ điều khiển thứ 
lỗi. Về cơ bản quá trình vẫn là: phát hiện lỗi, đánh giá lỗi và phục hồi sau lỗi. 
Nói chung một lỗi gây ra một sự sụp đổ trạng thái: các biến trạng thái đ−ợc gán các trị 
không hợp luật. Ngôn ngữ lập trình nh− Ada cho phép phát hiện ra các lỗi đó ngay trong thời gian 
biên dịch. Tuy nhiên việc kiểm tra biên dịch chỉ hạn chế cho các giá trị tĩnh và một vài phép kiểm 
tra thời gian thực là không thể tránh đ−ợc. Một cách để phát hiện lỗi trong ch−ơng trình Ada là dùng 
cơ chế xử lý bất th−ờng kết hợp với đặc tả miền trị. 
Hồi phục lỗi là một quá trình cải biên không gian trạng thái của hệ thống sao cho hiệu 
ứng của lỗi là nhỏ nhất và hệ thống có thể tiếp tục vận hành, có lẽ là trong một mức suy giảm. Hồi 
phục tiến liên quan đến việc cố gắng chỉnh lại trạng thái hệ thống. Hồi phục lùi liên quan đến việc 
l−u trạng thái của hệ thống ở một trạng thái đúng đã biết. 
Hồi phục tiến th−ờng là một chuyên biệt ứng dụng. Có hai tình thế chung mà khi đó hồi 
phục tiến có thể thành công: 
1) Khi dữ liệu mã bị sụp. Việc sử dụng kỹ thuật mã hoá thích hợp bằng cách thêm các 
dữ liệu d− thừa vào dữ liệu cho phép sửa sai khi phát hiện lỗi. 
2) Khi cấu trúc nối bị sụp. Nếu các con trỏ tiến và lùi đã có trong cấu trúc dữ liệu thì 
cấu trúc đó có thể tái tạo nếu nh− còn đủ các con trỏ ch−a bị sụp. Kỹ thuật này th−ờng đ−ợc dùng 
cho việc sửa chữa hệ thống tệp và cơ sở dữ liệu. 
Hồi phục lùi là một kỹ thuật đơn giản liên quan đến việc duy trì các chi tiết của trạng thái 
an toàn và cất giữ trạng thái đó khi mà sai lầm đã bị phát hiện. Hầu hết các hệ quản trị cơ sở dữ liệu 
đều có bộ hồi phục lỗi. CSDL chỉ cập nhật dữ liệu một khi giao dịch đã hoàn tất và không phát hiện 
đ−ợc vấn đề gì. Nếu giao dịch thất bại thì CSDL không đ−ợc cập nhật. 
Một kỹ thuật khác là thiết lập các điểm kiểm tra th−ờng kỳ mà chúng là các bản sao của 
trạng thái hệ thống. Khi mà một lỗi đ−ợc phát hiện thì trạng thái an toàn đó đ−ợc tái l−u kho từ điểm 
kiểm tra gần nhất. 
Tr−ờng hợp hệ thống dính líu tới nhiều quá trình hợp tác thì dãy các giao tiếp có thể là 
các điểm kiểm tra của các quá trình đó không đồng bộ và để hồi phục thì mỗi quá trình phải trở lại 
trạng thái ban đầu của nó. 
 Ch−ơng IV - 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi – Lê Đình Phùng 
105
E) Sử dụng lại 
 Một đặc tr−ng của công trình học là sử dụng cách tiếp cận thiết kế hệ thống mà nó sử 
dụng tối đa các thành phần đã tồn tại. Ng−ời kỹ s− thiết kế không đặc tả một thiết kế mà trong đó 
mỗi thành phần đã đ−ợc chế tạo nh−ng dựa vào thiết kế các thành phần đã đ−ợc nghiên cứu hoặc thử 
nghiệm trong các hệ thống khác. 
Ch−a có một cơ sở chung nào về việc dùng lại các thành phần phần mềm với t− liệu đ−ợc 
phổ biến rộng rãi đ−ợc dùng để thiết kế phần mềm. Tuy vậy, chúng ta cần quan tâm đến những vấn 
đề sau đây: 
• Phân loại thành phần dùng lại đ−ợc 
i) Các hệ ứng dụng. 
ii) Các hệ con. Thí dụ hệ đọ mẫu đ−ợc phát triển nh− là một phần của hệ xử lý văn bản 
có thể đ−ợc dùng lại trong một hệ quản trị cơ sở dữ liệu. 
iii) Các mô đun hoặc các đối t−ợng. 
iv) Các hàm. 
• Phát triển phần mềm để dùng lại đ−ợc 
Việc sử dụng lại một cách hệ thống đòi hỏi một cơ sở t− liệu đ−ợc xếp theo danh mục của 
các thành phần dùng lại đ−ợc. Quan niệm sai lầm là các thành phần này đã sẵn có trong các hệ đang 
tồn tại và một th− viện các thành phần có thể đ−ợc tạo ra một cách kinh tế bằng cách trích chúng ra 
và viết t− liệu cho chúng. 
Sự thật các thành phần đ−ợc tạo ra nh− là một phần của một ứng dụng là không chắc sẽ dùng 
lại đ−ợc. Các thành phần này h−ớng về phục vụ các yêu cầu của hệ thống mà thành phần ấy thuộc 
về. Để dùng lại đ−ợc một cách có hiệu quả, nó phải đ−ợc sinh ra để thoả mãn một phổ rộng các yêu 
cầu. 
Việc phát triển các thành phần khái quát là đắt hơn việc phát triển các thành phần cho một 
mục đích chuyên biệt và do đó nó làm tăng chi phí dự án. 
Để phát triển các thành phần dùng lại đ−ợc cần phải có một quyết định chính sách có tổ chức 
là tăng chi phí ngắn hạn giúp cho các mục tiêu lâu dài. Chính tổ chức chứ không phải cá nhân các 
nhà quản lý phải ra quyết định nh− vậy. Các nhà quản lý cấp trên th−ờng miễn c−ỡng ủng hộ chi phí 
để dùng laị vì các khó khăn trong định l−ợng các −u điểm trong t−ơng lai của một th− viện các thành 
phần dùng lại đ−ợc. 
Để đánh giá độ dùng lại đ−ợc cần phải đặt ra hai câu hỏi sau đây: 
i) Thành phần này biểu diễn một sự khái quát lĩnh vực ứng dụng tốt nh− thế nào?. 
ii) Thành phần đã đ−ợc viết ra có là khái quát và thích nghi đ−ợc hay không ?. 
• Phát triển phần mềm có thành phần dùng lại đ−ợc 
 Phát triển phần mềm có thành phần tái sử dụng là giảm đ−ợc chi phí và ngoài ra còn có 5 
−u điểm nữa: 
i) Độ tin cậy của hệ thống đ−ợc tăng lên. 
ii) Các rủi ro là giảm đi. 
iii) Sử dụng hiệu quả các chuyên gia ứng dụng. 
iv) Các chuẩn tổ chức có thể đ−ợc bao gồm trong các thành phần dùng lại đ−ợc . 
v) Thời gian phát triển phần mềm có thể đ−ợc rút gọn. 
IV.4.2.Độ tin cậy của phần mềm 
A) Khái niệm về độ tin cậy: 
 Độ tin cậy của một hệ phần mềm là độ đo về mức độ tốt của các dịch vụ mà hệ cung 
cấp cho máy tính. 
Ng−ời dùng không xem rằng các dịch vụ là quan trọng nh− nhau: chẳng hạn một hệ điều khiển 
 Ch−ơng IV - 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi – Lê Đình Phùng 
106
máy bay có thể rất, rất hiếm thất bại. Nh−ng nếu chúng có thất bại gây ra tai nạn máy bay thì những 
ng−ời bị nạn và các thân nhân ng−ời bị nạn không thể xem hệ đó là đáng tin. 
Độ tin cậy là một đặc tr−ng động của hệ thống, nó là một hàm của số các thất bại phần mềm. 
Một thất bại phần mềm là một sự kiện thi hành mà khi đó phần mềm x 
ử lý không nh− ng−ời ta mong đợi. Chú ý rằng một thất bại phần mềm (failure) khác một h− 
hỏng (fault) phần mềm. H− hỏng phần mềm là một đặc tr−ng tĩnh, và nó sẽ gây ra thất bại phần 
mềm khi mà mã lỗi đ−ợc thi hành với một tập hợp đặc biệt các thông tin vào. Các h− hỏng không 
phải luôn luôn xuất đầu lộ diện, bởi vậy độ tin cậy phụ thuộc vào việc sử dụng hệ thống nh− thế nào. 
Không thể đ−a ra một phát biểu đơn giản và khái quát về độ tin cậy phần mềm. 
Các h− hỏng phần mềm không phải là các khuyết tật (defect) của ch−ơng trình. Một hành xử bất 
ngờ có thể xảy ra khi mà phần mềm phù hợp với các yêu cầu của nó, nh−ng mà chính các yêu cầu 
đó lại không đầy đủ. Các sai sót trong các t− liệu phần mềm cũng có thể dẫn đến các hành vi bất ngờ 
mặc dầu rằng phần mềm không có khiếm khuyết. 
Có công trình nghiên cứu đã chỉ ra rằng có thể rút bỏ 60% các khiếm khuyết mà chỉ cải thiện 
đ−ợc có 3% độ tin cậy. Cũng có ng−ời đã chú ý rằng nhiều khiếm khuyết trong sản phẩm chỉ là kết 
quả của hàng trăm hoặc hàng nghìn tháng sử dụng. 
B) Đo độ tin cậy: 
 Có một vài cách đo độ tin cậy nh− sau: 
1) Xác suất thất bại tính theo đòi hỏi. 
2) Tỷ lệ xuất hiện thất bại. 
3) Thời gian trung bình giữa hai thất bại kế tiếp nhau. 
4) Độ đo mức sẵn sàng hoạt động của hệ. 
C) Đặc tả độ tin cậy phần mềm. 
 Các b−ớc đặc tả độ tin cậy phần mềm là: 
1) Phân tích hệ quả của các thất bại. 
2) Chia các thất bại thành các nhóm khác nhau. 
3) Thiết lập các yêu cầu về độ tin cậy bằng cách sử dụng các độ đo thích hợp cho từng loại. 
D) Thử nghiệm tĩnh. 
Mục tiêu chủ yếu của phần mềm tĩnh là xác định độ tin cậy của phần mềm chứ không phải 
là xác định các h− hỏng phần mềm. Quá trình thử nghiệm tĩnh liên quan đến 4 b−ớc sau: 
i) Xác định trắc đồ thao tác của phần mềm. Trắc đồ thao tác là một mẫu sử dụng phần 
mềm và xác định mẫu đó liên quan đến việc phát hiện các lớp thông tin vào của 
ch−ơng trình và −ớc tính xác suất của chúng. 
ii) Chọn hoặc sinh ra một tập các dữ liệu thử t−ơng ứng với trắc đồ đó. 
iii) áp dụng các tr−ờng hợp thử ch−ơng trình, ghi lại độ dài thời gian thi hành giữa mỗi cặp 
thất bại quan sát đ−ợc, thích hợp hơn là dùng thời gian thô, với đơn vị thời gian thích 
hợp cho độ đo mức tin cậy. 
iv) Tính toán độ đo mức tin cậy sau một số đáng kể (về mặt thông kê) các thất bại đã quan 
sát đ−ợc. 
E) An toàn hệ thống. 
 Có những hệ thống mà thất bại của nó có thể gây ra một mối đe doạ tính mạng con 
ng−ời. Ví dụ về hệ thống an toàn sinh mệnh nh− vậy là hệ thống điều khiển máy bay. Có hai lớp 
phần mềm an toàn sinh mệnh: 
i) Các phần mềm an toàn sinh mệnh sơ cấp: là các phần mềm lồng nhúng trong một hệ 
phần cứng dùng để điều khiển quá trình khác mà sự làm việc sai sót của nó có thể trực tiếp gây ra 
 Ch−ơng IV - 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi – Lê Đình Phùng 
107
th−ơng vong hoặc phá huỷ môi tr−ờng sống của con ng−ời. 
ii) Các phần mềm an toàn sinh mệnh thứ cấp: là các phần mềm có thể gián tiếp gây ra 
th−ơng vong. Ví dụ hệ thống phần mềm trợ giúp thiết kế kỹ thuật, hệ thống CSDL y tế liên quan đến 
các chất độc bảng A. 
 F) Thử nghiệm khiếm khuyết. 
 Thử nghiệm ch−ơng trình có hai mục đích: thứ nhất là chỉ ra rằng hệ thống là phù 
hợp với các đặc tả của nó. Thứ hai là thực hành hệ thống theo một cách sao cho các khuyết tật đ−ợc 
phơi ra. Các thử nghiệm với mục đích thứ nhất chính là các thẩm định, nó là các thử nghiệm để chấp 
nhận. Các thử nghiệm cho mục đích thứ hai lại khác hẳn: thử nghiệm thành công nhất là thử nghiệm 
phơi ra đ−ợc nhiều khuyết tật nhất. Các thử nghiệm có thể đ−ợc phát triển song song với việc thiết 
kế và thực hiện bởi những ng−ời không dính dáng tới việc thiết kế. 
IV.4.3.Tính di chuyển đ−ợc của hệ ứng dụng 
Tốc độ thay đổi công nghệ phần cứng nhanh đến mức mà máy tính là bị lỗi thời tr−ớc cá 
ch−ơng trình thi hành trên cái máy tính đó. Vậy là các hệ thống ứng dụng phải di chuyển đ−ợc sang 
các máy tính khác, trên môi tr−ờng khác. Độ di chuyển đ−ợc của một ứng dụng là tỷ lệ với khối 
l−ợng công việc cần phải tiến hành để ứng dụng đó thi hành đ−ợc trong một môi tr−ờng mới. Tính di 
chuyển đ−ợc có hai khía cạnh: 
-Tính vận chuyển: sự hoạt động của mã ch−ơng trình và dữ liệu kết hợp đ−ợc chuyển từ một 
môi tr−ờng này sang một môi tr−ờng khác. 
-Tính thích nghi; những thay đổi ch−ơng trình cần thiết để ch−ơng trình hoạt động trong một 
môi tr−ờng mới. 
IV.4.4.Một vài h−ớng dẫn lập trình h−ớng hiệu quả 
1.Tính hiệu quả ch−ơng trình. 
Tính hiệu quả của ch−ơng trình gốc có liên hệ trực tiếp với tính hiệu quả của thuật toán 
đ−ợc xác định trong thiết kế chi tiết. Tuy nhiên, phong cách lập trình có thể có một tác động đến tốc 
độ thực hiện và yêu cầu bộ nhớ. Tập hợp các h−ớng dẫn sau đây bao giờ cũng có thể áp dụng đ−ợc 
khi thiết kế chi tiết đ−ợc dịch thành ch−ơng trình: 
• Đơn giản hoá các biểu thức số học và lôgic tr−ớc khi đi vào lập trình. 
• Tính cẩn thận từng chu kì lồng nhau để xác định liệu các câu lệnh hay biểu thức có thể đ−ợc 
chuyển ra ngoài hay không. 
• Khi có thể, hãy tránh dùng mảng nhiều chiều 
• Khi có thể hãy tránh việc dùng con trỏ và danh sách phức tạp. 
• Dùng các phép toán số học “nhanh”. 
• Không trộn lẫn các kiểu dữ liệu, cho dù ngôn ngữ có cho phép điều đó. 
• Dùng các biểu thức số học và logic bất kì khi nào có thể đ−ợc. 
Nhiều trình biên dịch có tính năng tối −u tự động sinh ra ch−ơng trình hiệu quả bằng cách 
dồn nén các biểu thức lặp,thực hiện tính chu trình,dùng số học nhanh và áp dụng các thuật toán có 
hiệu quả liên quan khác. Với những ứng dụng trong đó tính hiệu quả có ý nghĩa quan trọng, những 
trình biên dịch nh− thế là công cụ lập trình không thể thiếu đ−ợc. 
2.Hiệu quả bộ nhớ 
Tính hiệu quả bộ nhớ phải đ−ợc tính vào đặc tr−ng “phân trang“ của hệ điều hành.Nói 
chung, tính cục bộ của ch−ơng trình hay việc bảo trì lĩnh vực chức năng qua các kết cấu có cấu trúc 
là một ph−ơng pháp tuyệt vời làm giảm việc phân trang và do đó làm tăng tính hiệu quả. 
 Ch−ơng IV - 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi – Lê Đình Phùng 
108
Hạn chế bộ nhớ trong thế giới bộ vi xử lí nhúng là mối quan tâm rất thực tế,mặc dầu bộ 
nhớ giá thấp, mật độ cao vẫn đang tiến hoá nhanh chóng. Nếu yêu cầu hệ thống cần tới bộ nhớ tối 
thiểu (nh− sản phẩm giá thấp, khối l−ợng lớn) thì trình biên dịch ngôn ngữ cấp cao phải đ−ợc trù 
tính cẩn thận với tính năng nén bộ nhớ, hay nh− một ph−ơng kế cuối cùng, có thể phải dùng tới hợp 
ngữ. 
Không giống nh− nhiều đặc tr−ng hệ thống khác phải trả giá lẫn nhau, các kĩ thuật cho 
hiệu quả về thời gian thực hiện đôi khi có thể dẫn tới hiệu quả bộ nhớ. Chẳng hạn, giới hạn việc 
dùng các mảng ba hay bốn chiều làm nảy sinh thuật toán thâm nhập phần tử đơn, thuật toán nhanh 
và ngắn nhất. Lần nữa, chìa khoá cho tính hiệu quả bộ nhớ là “giữ cho đơn giản“. 
3.Hiệu quả vào / ra. 
Cái vào do ng−ời dùng cung cấp và cái ra đ−ợc tạo ra cho ng−ời dùng là hiệu quả khi 
thông tin có thể đ−ợc cung cấp hay đ−ợc hiêủ với một mức độ tiết kiệm nỗ lực trí tuệ. 
Một số h−ớng dẫn đơn giản để tăng c−ờng hiệu quả vào/ra: 
• Số các yêu cầu vào/ra nên giữ mức tối thiểu 
• Mọi việc vào /ra nên qua bộ đệm để làm giảm phí tổn liên lạc. 
• Với bộ nhớ phụ (nh− đĩa) nên lựa chọn và dùng ph−ơng pháp thâm nhập đơn giản nhất chấp 
nhận đ−ợc. 
• Nên xếp khối vào/ra với các thiết bị bộ nhớ phụ. 
• Việc vào/ ra với thiết bị cuối hay máy in nên nhận diện các tính năng của thiết bị có thể cải 
tiến chất l−ợng hay tốc độ. 
• Hãy nhớ rằng “siêu hiệu quả” của vào/ra là vô nghĩa nếu nó không đ−ợc hiểu rõ. 
Thiết kế vào/ra lập nên phong cách và cuối cùng chi phối tính hiệu quả. Những h−ớng 
dẫn trình bày trên đây là áp dụng đ−ợc cho cả các b−ớc thiết kế và lập trình cho tiến trình kĩ nghệ 
phần mềm. 
IV.5.Thẩm định và xác minh 
IV.5.1 Đại c−ơng về việc thẩm định và xác minh 
Xác minh và thẩm định một hệ phần mềm là quá trình liên tục xuyên suốt mọi giai đoạn 
của quá trình phần mềm. Xác minh và thẩm định mang tính quá trình nhằm đảm bảo phần mềm thoả 
mãn các yêu cầu của khách hàng. 
Xác minh và thẩm định là một quá trình kéo dài suốt vòng đời. Nó bắt đầu khi duyệt xét 
yêu cầu. Xác minh và thẩm định có hai mục tiêu: 
i) Phát hiện các khuyết tật trong hệ thống. 
ii) Đánh giá xem hệ thống có dùng đ−ợc hay không ?. 
Sự khác nhau giữa xác minh và thẩm định là: 
i) Thẩm định: xét xem cái đ−ợc xây dựng có là sản phẩm đúng không ? 
ii) Xác minh: Xét xem cái đ−ợc xây dựng có đúng là sản phẩm không ? 
 Nh− vậy xác minh là kiểm tra xem ch−ơng trình có phù hợp với đặc tả hay không. Còn thẩm 
định là kiểm tra xem ch−ơng trình có đ−ợc nh− mong đợi của ng−ời dùng hay không . 
Có hai loại phép thử: 
i) Phép thử thống kê: để phản ánh tần suất các input của ng−ời dùng thực và sau khi vận 
hành máy có thể cho ra một đánh giá độ tin cậy thao tác của hệ thống. 
ii) Phép thử khuyết tật: để bộc lộ các khuyết tật trong hệ thống. 
IV.5.2 Sơ l−ợc về tiến trình thử nghiệm 
 *Quá trình thử nghiệm: 
Trừ các hệ nhỏ, nói chung không nên thử hệ thống nguyên cả khối. Quá trình thử có thể chia 
 Ch−ơng IV - 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi – Lê Đình Phùng 
109
làm 5 giai đoạn: 
1) Thử đơn vị. 
2) Thử modul ( chức năng ). 
3) Thử hệ con. 
4) Thử hệ thống. 
5) Thử sau l−ng (alpha) và thử điều tra (beta). 
 *Kế hoạch thử nghiệm. 
Thử hệ thống là rất đắt, đối với một vài hệ thời gian thực có các ràng buộc thời gian phức tạp 
thì việc thử có thể ngốn hết khoảng nửa tổng chi phí phát triển. Vì thế mà phải lập kế hoạch thử và 
khống chế chi phí thử. 
Việc thử liên quan nhiều đến việc thiết lập ra các mẫu cho quá trình thử nhiều hơn là mô tả 
các phép thử. 
 *Chiến l−ợc thử nghiệm. 
Có các chiến l−ợc thử nh− sau: 
1) Thử từ - trên - xuống: nên dùng cho các phát triển từ - trên - xuống. 
2) Thử từ d−ới lên: việc thử từ d−ới lên luôn luôn là cần thiết cho các thành phần hệ thống 
mức thấp. 
3) Thử luồn sợi: dùng cho các hệ thời gian thực. 
4) Thử gay cấn (áp lực): cho những hệ thống có giới hạn tải, và phép thử tăng dần tải cho 
tới khi hệ thống sập đổ để xác định độ chịu tải thực sự. 
Tóm tắt 
B−ớc lập trình của kĩ nghệ phần mềm là một tiến trình dịch/chuyển hoá. Thiết kế chi tiết 
đ−ợc dịch sang một ngôn ngữ lập trình mà cuối cùng đ−ợc biến đổi thành các lệnh mã máy thực hiện 
đ−ợc. Các đặc tr−ng tâm lí và kĩ thuật của ngôn ngữ lập trình có ảnh h−ởng lớn đến quá trình dịch và 
kiểm thử cũng nh− bảo trì phần mềm. Các đặc tr−ng này có thể đ−ợc áp dụng vào ngôn ngữ lập trình 
thuộc một trong 4 thế hệ ngôn ngữ. 
Phong cách là một đặc tính quan trọng của ch−ơng trình gốc và có thể xác định ra tính dễ 
đọc của ch−ơng trình.Các yếu tố của phong cách bao gồm việc làm tài liệu bên trong, ph−ơng pháp 
khai báo dữ liệu, thủ tục xây dựng câu lệnh, và kĩ thuật lập trình vào/ra.Trong mọi tr−ờng hợp, tính 
đơn giản và rõ ràng là các đặc tr−ng chính. Một nhân tố của phong cách lập trình là thời gian thực 
hiện và/hoặc tính hiệu quả bộ nhớ cần đạt tới. Mặc dầu tính hiệu quả có thể là yêu cầu cực kì quan 
trọng, chúng ta nên nhớ rằng một ch−ơng trình “hiệu quả” mà lại không dễ đọc thì cũng mang một 
giá trị đáng hoài nghi. 
Lập trình là cốt lõi của tiến trình phần mềm. Các b−ớc quan trọng chủ chốt phải hoàn 
tất r−ớc lập trình nh− phân tích, xác định yêu cầu và đặc tả thiết kế chi tiết. 
? Củng cố 
 Ch−ơng IV - 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi – Lê Đình Phùng 
110
1. Tóm l−ợc các đặc tr−ng của ngôn ngữ lập trình? 
2. Nền tảng của ngôn ngữ lập trình? (định kiểu dữ liệu , cơ chế ch−ơng trình con, cấu trúc điều 
khiển và cách tiếp cận h−ớng đối t−ợng) 
3. Sơ l−ợc về các yếu tố trong phong cách lập trình? 
4. Sơ l−ợc về kỹ thuật lập trình h−ớng hiệu quả? 
5. Sơ l−ợc về những nội dung quan trọng về độ tin cậy phần mềm ? 
6. Nêu ra một vài h−ớng dẫn lập trình h−ớng hiệu quả? 
7. Mục tiêu, ý nghĩa, vai trò và nội dung của việc thẩm định và xác minh? 
8. Sơ l−ợc về tiến trình thử nghiệm ?(quá trình, kế hoạch, chiến l−ợc)