CÔNG NGHỆ PHẦN MỀM
Câu 1: Tóm tắt các bước trong quá trình phát triển phần mềm?
1. Pha xác định yêu cầu
Người phát triển phần mềm sẽ tiếp thu các yêu cầu, chức năng các công việc cần
thực hiện của phần mềm mà khách hàng yêu cầu. người phát triển phần mềm cần tìm
hiểu thực chất khách hàng cần gì? Những yêu cầu về chức năng công việc, những
điều kiện về phần mềm là gì? Tuy nhiên khách hàng có thể do một vài lí do hoặc do
khách hàng k có kiến thức về máy tính nên có thể k hài lòng về phần mềm cần sửa
đổi và viết lại. Lúc này người phát triển phần mềm thường viết nhanh một phần mềm
thực hiện các yêu cầu của khách hàng. Phiên bản này được gọi là bản mẫu nhanh.
Kiểm thư pha yêu cầu: do nhóm đảm bảo chất lượng phần mềm(SQA) làm nhiệm
vụ bảo đảm rằng phần mềm hoạt động tốt và đáp ứng các yêu cầu của khách hàng.
Nhóm SQA bắt đầu thực hiện vai trò của mình ngay từ pha khởi đầu.
Tài liệu báo cáo trong pha yêu cầu: bao gồm bản mẫu và các ghi chép trong quá
trình trao đổi với khách hàng. Tài liệu này được kiểm tra bởi khách hàng và một số
người sử dụng trước khi được SQA kiểm tra kỹ lưỡng và chi tiết.
2. Pha đặc tả (đặc tả): xác định tài liệu đặc tả
Chi tiết và chính xác hóa các tài liệu của pha yêu cầu để có tài liệu của phân tích.
Tài liệu đặc tả cần chỉ rõ đầu vào và đầu ra của phần mềm
Báo cáo đặc tả là cơ sở tạo ra bản hợp đồng
Tài liệu đặc tả đóng vai trò quan trọng trong việc kiểm thử và bảo trì phần mềm
Xây dựng chi tiết và ước lượng thời gian hoàn thành và giá trị phần mềm
Phân công nhân sự cho từng giai đoạn
Kế hoạch quản lý dự án phần mềm cần được biên soạn kĩ lưỡng nhằm phản ánh
các giai đoạn khác nhau của quá trình phát triển phần mềm, những thành viên tham
gia trong từng giai đoạn và thời hạn cần hoàn thành. Thời điểm sớm nhất để xây dựng
sản phẩm phần mềm là khi phần đặc tả kết thúc.
Thành phần chính của kế hoạch là những sản phẩm chuyển giao cho khách hàng
chi phí của các sản phẩm này.
Bản kế hoạch mô tả tỷ mỷ quy trình phần mềm bao gồm mô hình vòng đời phần
mềm được sử dụng, cơ cầu tổ chức của các công ty phần mềm, mục tiêu của dự án,

Tài liệu báo cáo trong pha cài đặt là các mã nguồn của mỗi modul cùng với các lời
giải thích. Bổ sung thêm các tài liệu khác để hỗ trợ bảo trì về sau
5. Tích hợp
Các modul được tích hợp thành phần mềm và kiểm tra các chức năng của phần
mềm có hoạt động chính xác hay k? Nên thực hiện pha cài đặt và tích hợp song song
với nhau.
Kiểm thử pha tích hợp: Kiểm tra các modul có được một cách chính xác để tạo
phần mềm đúng trong các bước đặc tả k? cần chú ý đến phần giao tiếp giữa các
modul. Sauk hi kiểm tra xong, nhóm SQA chuyển sang kiểm thử. Nên đửa ra nhiều
trường hợp thử khi kết thúc phần mềm đặc tả.
Kiểm thử tính chính xác và cả tính ổn định của chương trình.
Bước cuối cùng của kiểm thử tích hợp là kiểm thử chấp nhận: chương trình được
cài đặt trên máy của khách hàng chạy với chương trình và số liệu thực
Tài liệu báo cáo trong pha tích hợp: là tài liệu hướng dẫn sử dụng, tài liệu hướng
dẫn vận hành, giải thích cơ sở dữ liệu…Tóm lại là tất cả các tài liệu cần thiết cùng
với phần mềm để chuyển giao cho khách hàng
6. Bảo trì
Khi phần mềm được chấp nhận bởi khách hàng và cài đặt trên máy của họ thì mọi
thay đổi về phần mềm từ đó được gọi là bảo trì.
Bảo trì thường có chi phí lớn hơn tất cả các pha khác, trải qua nhiều thách thức
nhất trong quá trình sản xuất
Kiểm thử trong pha bảo trì:Kiểm tra xem phần mềm có được sửa đúng theo yêu
cầu đặt ra chưa?;sau khi sửa lại một phần của phần mềm thì phần mềm còn lại có bị
ảnh hưởng k?;
Tài liệu báo cáo trong pha bảo trì: Các ghi chép và các sửa đổi đã được thực hiện
cùng với các lý do khi phần mềm được sửa đổi thì cẩn thực hiện kiểm thử hồi quy –
là một phần quan trọng trong tài liệu này.
7. Thôi sử dụng
Sự thay đổi do khách hàng đưa ra quá lớn
Sau nhiều lần thực hiện sửa đổi trên thiết kế ban đầu làm cho các phần của phần

bản đầu tiên
Hiệu chỉnh cho đến khi
khách hàng chấp nhận
Sử dụng và
bảo trì
Thôi sử dụng
Phát triển
Bảo trì
2. Mô hình thác nước (mô hình xây dựng và hiệu chỉnh, mô hình thác nước, mô
hình bản mẫu, mô hình phát triển, phát triển đồng thời, đồng bộ ổn định, mô hình
xoắn ốc)
- Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải
qua các pha yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì
- Có tính độc lập của từng pha, nghĩa là nếu trong 1 pha người ta phát hiện ra sai sót
hoặc không phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước
- Ưu điểm: Các giai đoạn được định nghĩa với đầu vào và đầu ra rõ ràng, Bảo trì
thuận lợi
- Nhược điểm: Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô
hình đề nghị. Mặc dầu mô hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết
quả là những thay đổi có thể gây ra lẫn lộn khi nhóm phát triển làm việc. Trong mô
hình này đòi hỏi 1 bản yêu cầu đầy đủ và chính xác từ phía khách hàng. Khách hàng
chỉ tham gia dự án ở giai đoạn phân tích yêu cầu và test
- Áp dụng: Mô hình này chỉ nên áp dụng khi đội dự án đã có kinh nghiệm, yêu cầu từ
khách hàng được xác định rõ ngay từ đâu và ít có khả năng thay đổi
Xác định yêu cầu
Phân tích
Thiết kế
Cài đặt
Tích hợp
Bảo trì

Bảo trì
Thôi sử dụng
Thay đổi yêu
cầu
4. Mô hình tăng dần ( mô hình xây dựng và hiệu chỉnh, mô hình thác nước, mô hình
bản mẫu, mô hình phát triển, phát triển đồng thời, đồng bộ ổn định, mô hình xoắn ốc)
- Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần
(build) tương đối độc lập nhau. Mỗi thành phần như vậy được coi như một phần mềm
nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình
thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của
khách hàng.
- Sơ đồ sau mô tả mô hình tăng dần.
- Ưu điểm
+ Thuận tiện cho bảo trì và phát triển
+ Các modul có thể thay đổi trong quá trình thiết kế và cài đặt
+ Với mô hình này, tại mỗi giai đoạn khách hàng có được sản phẩm thực hiện một
phần công việc theo yêu cầu
+ Không đòi hỏi khách hàng phải có kinh phí lớn và khách hàng có thể dừng phát
triển bất kì lúc nào
+ Khách hàng có thể tham gia đóng góp ý kiến
- Nhược điểm
+ Đòi hỏi tính chuyên nghiệp của người thiết kế
+ Khó khăn khi kết hợp build vào cấu trúc hiện thời là làm sao không phá huỷ cấu
trúc đã xây dựng. Như vậy, yêu cầu cấu trúc phải mở. Yêu cầu này là chung cho mọi
mô hình cần chọn.
+ Mô hình này uyển chuyển hơn so với các mô hình thác nước và làm bản mẫu vì
dễ thay đổi theo yêu cầu của khách hàng. Tuy nhiên, nó có thể suy biến thành mô
hình làm bản mẫu và khó điều phối chung
Câu 3:Trình bày các phương pháp khảo sát
1. Phỏng vấn

- Có thể bao hết thông tin
chưa biết
- Đòi hỏi có thực hành
Nhược
điểm
- Chi phí chuẩn bị lớn
- Tính cấu trúc có thể không
thích hợp cho mọi tình huống
- Giảm tính chủ động của người
phỏng vấn
- Lãng phí thời gian phỏng
vấn
- Người phỏng vấn có thể
định kiến với các câu hỏi
- Tốn thời gian lựa chọn và
phân tích thông tin
- Một phỏng vấn tốt
• Thu thập được tất cả hiểu biết về công việc phải làm của stakeholder( các
bên liên quan)
• Nắm rõ họ tương tác với hệ thống như thế nào
- Để phỏng vấn thành công, người phỏng vấn nên:
Cởi mở, sẵn sàng lắng nghe
Không có định kiến
Đưa ra câu hỏi gợi mở, thân thiện
- Kỹ thuật phỏng vấn:
Bước 1: Những câu hỏi căn bản, ngữ cảnh bất kì
Bước 2: nhằm hiểu sâu hơn vấn đề
Bước 3: Những câu hỏi về hiệu quả của việc gặp gỡ
- Các bước phỏng vấn:
Đặt cuộc hẹn

- Nếu số đại biểu nhiều sẽ tốn thời gian cho việc ra quyết định
- Tốn thời gian
- Các ngắt quãng làm phân tán sự chú ý
- Mời k đúng thành viên nên dẫn đến chậm có kết quả
- Dễ chuyển sang chủ đề k liên quan
3. Quan sát
Quan sát là hoạt động có thể tiến hành thủ công hoặc tự động như sau:
- Theo cách thủ công: Người quan sát ngồi tại 1 chỗ và ghi chép các hoạt động,
các bước xử lý công việc. Ghi chép or băng ghi hình được dùng để phân tích
cho các sự kiện, các mô tả động từ chính, hoặc các hoạt động chỉ rõ lý do, công
việc hoặc các thông tin về công việc
- Theo cách tự động: máy tính sẽ lưu giữ các chương trình thường trú, lưu lại vết
của các chương trình được sử dụng, email và các hoạt động khác được xử lý
bởi máy. Các file nhật kí của máy sẽ được phân tích để mô tả công việc
- Kỹ sư phần mềm có thể nhận được sự hiểu biết tốt về môi trường công tác
hiện tại và quá trình xử lý thông qua quan sát
- Kỹ sư phần mềm có thể tập trung vào vấn đề mà k bị ảnh hưởng bởi người
khác
- Các ngăn cách giữa kỹ sư phần mềm và người được phỏng vấn sẽ được vượt
qua bởi quan sát
Nhược điểm
- Thời gian của quan sát có thể không biểu diễn cho các công việc diễn ra thông
thường
- Ý nghĩ là đang bị quan sát có thể làm thay đổi thói quen hàng ngày của người
bị quan sát
- Tốn thời gian
4. Kỹ thuật dùng bảng câu hỏi
- Phải trình bày rõ:
 Mục đích của bảng câu hỏi,
 Mục đích sử dụng những thông tin trong bảng câu hỏi,

 Thường được tiến hành trước làm cơ sở chuẩn bị cho việc phỏng vấn hay
dùng bảng câu hỏi
Câu 4: Phân tích sự khác nhau giữa yêu cầu chức năng và yêu cầu phi chức
năng
- Yêu cầu chức năng:
- là danh sách các công việc sẽ được thực hiện trên máy tính cùng với các
thông tin mô tả tương ứng.
- Cho biết hệ thống sẽ làm gì, chức năng hoặc các dịch vụ của hệ thống một cách
chi tiết.
- Một số yêu cầu chức năng:
Chức năng tính toán
Chức năng lưu trữ
Chức năng tìm kiếm
Chức năng kết xuất
Chức năng backup, restore
- Yêu cầu phi chức năng
- là các yêu cầu liên quan đến chất lượng phần mềm, là sự ràng buộc cách thức
thực hiện các yêu cầu chức năng.
- Yêu cầu phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ
thống.
- Yêu cầu phi chức năng thường xác định:
Độ tin cậy, tính tiến hoá, tính tương thích, thời gian đáp ứng, các yêu cầu về lưu trữ,
bảo mật thông tin
Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình
- Các yêu cầu phi chức năng xuất hiện là do:
Yêu cầu của người sử dụng
Ràng buộc về ngân sách
Các chính sách của tổ chức sử dụng hệ thống
Yêu cầu tương thích giữa phần cứng và phần mềm
Các tác nhân ngoài khác

2. Cài đặt và tích hợp từ dưới lên
- Phương pháp cài đặt và tích hợp theo kiểu dưới lên (bottom-up) được thực hiện
ngược lại với phương pháp trên xuống. Đầu tiên các module ở mức dưới cùng
(hay đôi khi còn gọi là mức cao nhất nếu nói về chiều cao của cây) được cài
đặt và kiểm thử. Sau đó là các module ở mức phía trên được cài đặt và kiểm
thử cùng với các module ở mức dưới. Cứ như vậy cho đến khi các module ở
mức trên cùng được cài đặt và kiểm thử thì quá trình hoàn tất.
- Ưu điểm: Các modul thao tác được kiểm tra kỹ lưỡng; cô lập được lỗi
- Nhược điểm: Phát hiện sai sót thiết kế muộn
3. So sánh
Có thể thấy rằng phương pháp bottom-up có ưu điểm hơn phương pháp top-
down ở chỗ là không phải tạo cài đặt dạng stub (các module ở tầng dưới cùng
thường phải thử với các driver). Tuy nhiên nó cũng có một nhược điểm khá lớn
là: nếu lỗi phát hiện ra muộn, tức là ở các mức ở gần gốc của cây chẳng hạn,
lúc đó toàn bộ phần dưới của cây phải xem xét lại.
Câu 6:Trình bày các phương pháp kiểm thứ phần mềm
1. Kiểm thử hộp đen
- Không cần biết cấu trúc bên trong của phần mềm, chỉ quan tâm đến đầu vào
và xem kết quả đầu ra có đúng như mong muốn không.
- Còn được gọi là kiểm thử dựa trên đặc tả (specification based testing) hay kiểm
thử chức năng (functional testing): biết chức năng thực hiện ra sao, và kiễm tra
nó có thực hiện đúng như mô tả không.
– Output được tạo ra từ input là chính xác
– Truy xuất/cập nhật dữ liệu đúng
– Pass các test cases được tạo ra từ đặc tả yêu cầu
- Không thể dùng các bộ dữ liệu mang tính đại diện mà cần đủ loại dữ liệu đầu
vào/đầu ra.
- Còn sử dụng cho Integration, System and Acceptance testing.
- Mục đích của kiểm thử hộp đen: Tìm các loại sai liên quan
• Chức năng: đủ, đúng đắn

thực hiện
 Mọi cấu trúc dữ liệu nội tại được dùng để bảo đảm hiệu lực thi hành của
nó
2.3. Kỹ thuật kiểm thử
2.3.1. Kiểm thử theo lộ trình:
- Đây là khái niệm chỉ đến việc thiết kế các trượng hợp kiểm thử trên từng lệnh
trong chương trình sẽ thực hiện ít nhât một lần. Kỹ thuật này không quan tâm
đến ảnh hưởng lên các đường quyết định ( decisions path).
- Các bước để xây dựng tập hợp kiểm thử có thể theo những bước sau đây.
1. Dùng tài liệu thiết kế hay source code để vẽ ra một đồ thị mô tả
flow chart của chương trình hay hàm.
2. Xác định đồ thị V(G).
3. Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau.
4. Xây dựng những trường hợp kiểm thử dựa trên tâp đường xác
định ở bước trên.
2.3.2. Kiểm thử theo cấu trúc điều kiện
a. Kiểm thử các biểu thức điều kiện:
- Kiểm thử biểu thức điều kiện là phương pháp kiểm thử trên những điều kiện
logic của hàm hay module.
- Một điều kiện đơn giản là một biến boolean hoặc là một biểu thức quan hệ
Những lỗi phát hiện được: Lỗi do giá trị của biến ; Lỗi do dấu ngoặc; Lỗi do phép
toán quan hệ; Lỗi trong biểu thức toán học
b. Kiểm thử luồng dữ liệu
- Phương pháp kiểm thử luồng dữ liệu là chọn lựa một số đường cơ bản của
chương trình dựa vào việc cấp phát, định nghĩa, và sử dụng những biến trong
chương trình
- Phương pháp này thích hợp cho kiểm thử một chương trình mà có nhiều lệnh
if và vòng lặp nhiều cấp
c. Kiểm tra cấu trúc vòng lặp: Chúng ta cần kiểm thử 4 loại vòng lặp sau:
- Vòng lặp đơn : Các bước cần kiểm tra

- áp dụng phần mềm trong môi trường thực, không có sự kiểm soát của người
phát triển
- khách hàng sẽ báo cáo tất cả các vấn đề (thực hoặc tưởng tượng) mà họ gặp
trong quá trình kiểm thử cho người phát triển một cách định kỳ
- dựa theo báo cáo đó người phát triển tiến hành sửa đổi và chuẩn bị phân phối
bản phát hành cho toàn bộ các người đặt hàng
4. Kiểm thử chấp nhận
- Kiểm thử chấp nhận tập trung vào 4 yếu tố chính của phần mềm là: tính đúng
đắn, tính ổn định, các công việc thực hiện và tài liệu kèm theo.
- Là kiểm thử cuối cùng đối với phần mềm và được khách hàng thực hiện ( hoặc
ủy quyền cho một nhóm thứ 3 thực hiện)
- Mục đích của kiểm thử chấp nhận : Chứng minh phần mềm thỏa mãn tất cả các
yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm
Câu 7: Mục đích của bảo trì? Tóm tắt các công việc của bảo trì?
- Bảo trì phần mềm chính là hoạt động chỉnh sửa chương trình sau khi nó đã
được đưa vào sử dụng
- Bảo trì thường không bao gồm những thay đổi chính liên quan tới kiến trúc của
hệ thống. Những thay đổi trong hệ thống thường được cài đặt bằng cách điều
chỉnh những thành phần đang tồn tại và bổ sung những thành phần mới cho hệ
thống.
1. Mục đích của bảo trì
- Hiệu chỉnh: Các lỗi về đặc tả, thiết kế, tài liệu, mã nguồn
- Hoàn thiện: thay đổi nhằm hoàn thiện hiệu năng của sản phẩm. Ví dụ
như:khách hàng yêu cầu thay đổi 1 số chức năng hay sửa đổi sản phẩm để tăng
tốc độ xử lý
- Thích ứng: Các thay đổi nhằm đáp ứng những thay đổi trong môi trường mà
sản phẩm đang vận hành.
Ví dụ: thay đổi trình biên dịch, hệ điều hành, phần cứng,…
- Được xem như là dịch vụ hậu mãi, giữ khách hàng bằng cách cung cấp những
dịch vụ bảo trì tốt nhất.

vào khi yêu cầu công việc bảo trì. Nếu xuất hiện lỗi, bản mô tả đầy đủ các tình
huống dẫn đến lỗi bao gồm dữ liệu, đoạn chương trình. Nếu yêu cầu bảo trì là
tiếp hợp hay hoàn thiện thì một yêu cầu chi tiết sẽ được thảo ra. Đơn yêu cầu
bảo trì sẽ được người kiểm soát bảo trì và người quản lý hệ thống xem xét.
- Đơn yêu cầu bảo trì được thiết lập từ bên ngoài và được coi như một cơ sở để
đề ra kế hoạch của công việc bảo trì. Ngoài ra trong nội bộ cơ quan phần mềm,
một báo cáo thay đổi phần mềm cũng được tạo ra. Nó chỉ ra công sức đòi hỏi
để thỏa mãn: một đơn yêu cầu bảo trì, trạng thái ban đầu của yêu cầu sửa đổi,
mức ưu tiên yêu cầu, các dữ liệu cho việc sửa đổi.
3.3. Lưu giữ các hồ sơ
Các thông tin cần lưu giữ trong các tài liệu bảo trì thường:
- Dấu hiệu nhận biết chương trình
- Số lượng các câu lệnh trong chương trình nguồn
- Số lệnh mã máy
- Ngôn ngữ lập trình sử dụng
- Ngày tháng cài đặt chương trình
- Số lượng các chương trình chạy từ khi cài đặt
- Số các lỗi xử lý xảy ra
- Mức và dấu hiệu thay đổi chương trình
- Số câu lệnh được thêm vào chương trình nguồn khi chương trình thay đổi
- Số câu lệnh được xóa khỏi chương trình nguồn khi chương trình thay đổi
- Số giờ mỗi người sử dụng cho mỗi lần sửa đổi
- Dấu hiệu của đơn yêu cầu bảo trì
- Kiểu bảo trì
- Ngày bắt đầu và kết thúc bảo trì
- Tổng số giờ của mỗi người dùng cho việc bảo trì
3.4. Xác định giá bảo trì
Việc xác định giá bảo trì thường phức tạp do thiếu thông tin. Theo chuyên gia
thì đánh giá của việc thực hiện bải trì dựa vào:
- Số lượng trung bình các lỗi xử lý cho 1 lần chạy chương trình