Đề cương ôn tập môn công nghệ phần mềm có đáp án

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,

các kĩ thuật, các công cụ CASE được sử dụng, lịch trình làm việc chi phí
Kiểm thử pha đặc tả: Nhóm SQA cần kiểm tra tài liệu đặc tả một cách kĩ lưỡng,
tính khả thi của tài liệu đặc tả. Tài liệu đặc tả phải có thể kiểm thử được các phần, các
mục được đánh số tương ứng tài liệu xác định yêu cầu để tiện theo dõi. Cách tốt nhất
để kiểm tra tài liệu đặc tả là xem xét. Đại diện nhóm đặc tả và nhóm khách hàng cùng
ngồi xem xét kỹ lưỡng bản đặc tả, phát hiện những sai sót hoặc những điều chưa
chính xác dưới sự chủ tọa của các thành viên nhóm SQA
Tài liệu báo cáo trong pha đặc tả gồm: bản báo cáo đặc tả và bản kế hoạch quản lý
dự án phần mềm(SPMP)
3. Giai đoạn thiết kế
Nhóm thiết kế xác định cấu trúc bên trong của phần mềm. Họ phân chia phần
mềm thành các modul. Sau khi chia các modul là thiết kế chi tiết cho các modul. Mỗi
modul cần chọn các thuật toán và cấu trúc dữ liệu thích hợp. Trong quá trình thiết kế
chia các modul nên ghi chép lại các bước quy định là lí do lựa chọn để khi công việc
bế tắc quay lại dễ hơn,thuận tiện cho công tác bảo trì.
Kiểm thử pha thiết kế: Bản thiết kế mang tính chuyên nghiệp kiểm tra bản thiết
kế thì thường khách hàng k có mặt. Công việc xem xét này được nhóm SQA thực
hiện. Có thể gặp các lỗi logic, giao tiếp, thiếu xử lý các trường hợp ngoại lệ, k tương
thích với báo cáo đặc tả. Có thể gặp lỗi ở các pha trước mà chưa được phát hiện
Tài liệu báo cáo trong pha thiết kế: Sản phẩm chính trong pha này là bản thiết kế
kiến trúc và chi tiết. Các bản thiết kế chi tiết được chuyển cho lập trình viên để thực
hiện công việc lập trình
4. Cài đặt
Lập trình viên viên viết chương trình cho các modul theo thiết kế chi tiết
Kiểm thử pha cài đặt:mỗi modul cần kiểm thử trong quá trình thực thi và sau khi
hoàn thành do lập trình viên thực hiện. Sau đó nhóm SQA sử dụng một số phương
pháp đã có để thử lại các modul. Cùng với việc chạy thử các số liệu mẫu, việc xem
xét các mã nguồn cũng là một cách kiểm thử hiệu quả tìm ra lỗi lập trình. Người lập
trình sẽ giới thiệu các dòng lệnh, cách hoạt động của các modul. Nhóm xem xét mã
nguồn cần có đại diện của nhóm SQA. Các hoạt động kiểm thử cần ghi chép lại

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

mềm trở nên quá phụ thuộc lẫn nhau ảnh hưởng đến phần mềm, bảo trì khó khăn
làm phần mềm mới
Sau nhiều lần sửa đổi nhưng các tài liệu lại k cập nhật đầy đủ nên k kiểm soát
được các lỗi hồi quy
Câu 2: Hãy nêu các mô hình phát triển phần mềm?Vẽ mô hình và trình bày đặc
điểm, ưu nhược điểm của mỗi mô hình .
1. mô hình xây dựng và hiệu chỉnh
2. mô hình thác nước
3. mô hình bản mẫu
4. mô hình phát triển
5. mô hình phát triển đồng thời
6. mô hình đồng bộ ốn định
7. mô hình xoắn ốc
1. Mô hình xây dựng và hiệu chỉnh
- Trong mô hình này không có các pha phân tích thiết kế. Phần mềm được xây dựng
như sau: Người phát triển sau khi trao đổi với khách hàng sẽ viết phiên bản đầu tiên.
Tiếp theo, phần mềm được chạy thử với sự quan sát của khách hàng và liên tục được
hiệu chỉnh cho đến khi khách hàng vừa ý (tức là đáp ứng được yêu cầu của khách
hàng). Sau khi được khách hàng chấp nhận, phần mềm được đưa vào sử dụng và bảo
trì.
- Mô hình này có thể biểu diễn trong sơ đồ sau:
- Nhược điểm của mô hình thể hiện rõ trong giai đoạn bảo trì. Công việc bảo trì
thường là sửa lỗi và cập nhật. Nếu phần mềm vừa mới được đưa vào sử dụng và tác
giả vẫn còn chịu trách nhiệm công việc này thì không có vấn đề gì lắm. Tuy nhiên
nếu phần mềm đã được sử dụng sau một thời gian dài, khiến cho chính người viết
chương trình cũng quên đi ý nghĩa các dòng lệnh; hoặc việc bảo trì lại do một người
khác thực hiện thì sẽ rất khó khăn
- Mô hình xây dựng-và-hiệu chỉnh chỉ thích nghi cho phần mềm nhỏ, một người viết
và ít khả năng phải sửa đổi trong quá trình sử dụng.
Xây dựng phiê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ì

Thôi sử dụng
Thay đổi yêu cầu
3. Mô hình bản mẫu ( 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)
- Mô hình bản mẫu xây dựng dựa trên ý tưởng xây dựng 1 mẫu thử ban đầ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 tới
khi thỏa mãn yêu cầu người sử dụng thì dừng lại
- Mẫu thử ban đầu như là một cơ chế nhận chính xác yêu cầu của khách hàng
- 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 cũng là lúc chúng ta xây dựng xong hệ thống
- Mẫu thử ban đầu có thể loại bỏ, mẫu thử chỉ có tác dụng làm sáng tỏ yêu cầu của
người sử dụng
- Mô hình
- Ưu điểm: Người sử dụng sớm hình dung ra chức năng và đặc điểm của hệ thống
Cải thiện sự liên lạc giữa các nhà phát triển và người sử dụng
- Nhược điểm: Khi bản mẫu không chuyển tải hết các chức năng, đặc điểm của hệ
thống phần mềm thì người sử dụng có thể thất vọng và mất đi sự quan tâm đến hệ
thống sẽ được phát triển
Bản mẫu thường được làm nhanh, thậm chí vội vàng theo kiểu “hiện
thực – sửa” và có thể thiếu sự phân tích đánh giá một cách cẩn thận tất cả các khía
cạnh liên quan đến hệ thống cuối cùng.
- Áp dụng: Mô hình bản mẫu được áp dụng cho:
+ Những hệ thống tương tác ơ mức độ nhỏ và vừa
+ Hệ thống chủ yếu dựa trên giao diện nguời dùng
+ Hệ thống có thời gian chu kì ngắn
Bản mẫu
Phân tích
Thiết kế
Cài đặt
Tích hợp

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

Phát triển
Bảo trì
Xác định yêu cầu
Phân tích
Thiết kế kiến trúc
Với mỗi build thực hiện:
Thiết kế chi tiết, lập trình, tích hợp,
kiểm thử rồi chuyển giao cho khách
hàng
Bảo trì
Thôi sử dụng
• Phỏng vấn là việc tập hợp một số lượng ít người cho 1 thời gian cố định với
1 mục đích cụ thể. Trong quá trình phỏng vấn, các câu hỏi có thể được thay
đổi
• Phỏng vấn được chia 2 loại: phỏng vấn có cấu trúc(câu hỏi đóng và được
chuẩn bị trước) và phỏng vấn có không có cấu trúc ( câu hỏi có tính mở: tất
cả các vấn đề không được xác định trước và stakeholder phải tự giải thích
và phát biểu theo quan điểm của mình)
Phỏng vấn có cấu trúc Phỏng vấn không có cấu
trúc
Ưu điểm - Dùng dạng chuẩn cho nhiều
câu hỏi
- Dễ quản lý và đánh giá
- Đánh giá được nhiều mục đích
- Không cần đào tạo nhiều
- Có kết quả trong các phỏng
vấn
- Có khả năng mềm dẻo nhất
- Cần chăm chỉ nghe và có
kỹ năng mở rộng câu hỏi

- 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

Chuẩn bị tốt, hiểu kỹ về đối tượng
Đúng giờ và có kế hoạch mở đầu
- Ưu điểm:
Phỏng vấn thích hợp cho việc nhận các thông tin bảo đảm cả số lượng và chất
lượng
Các kiểu thông tịnh định tính là các ý kiến, niềm tin, thói quen, chính sách, và
mô tả
Các kiểu về thông tin định lượng bao gồm tần suất, số lượng, định lượng các
mục được dùng trong ứng dụng
- Nhược điểm:
Phỏng vấn và các dạng khác của thu thập dữ liệu có thể làm bạn lạc lối, thiếu
chính xác hoặc thông tin k liên quan, k thích hợp
Bạn cần học cách đọc ngôn ngữ cử chỉ và thói quen để quyết định được các
điều cần thiết cho cùng 1 thông tin
Đòi hỏi kỹ năng
Có thể có kết quả thiên vị
Đòi hỏi 3 người để kiểm tra kết quả và thường k thích hợp với số lượng lớn
người
2. Họp nhóm
Họp nhóm là việc tập hợp nhiều hơn ba hoặc 1 số người cho một thời hạn nhất
định để thảo luận một số chủ đề. Họp nhóm có thể vừa bổ sung và thay thế
phỏng vấn.Nó bổ sung phỏng vấn bằng việc cho phép nhóm kiểm tra lại các
p/vấn cá nhân. Nó thay thế cho phỏng vấn bằng cách cung cấp một diễn đàn
cho mọi người sử dụng cùng ra các đòi hỏi và các giải pháp cho ứng dụng
Ưu điểm:
- Có thể tạo ra quyết định
- Nhận được cả thông tin tổng hợp và chi tiết
- Phương pháp tốt cho các yêu cầu bên ngoài
- Tập hợp được nhiều người dùng liên quan
Nhược điểm:

- 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,

 Tính bảo mật thông tin trả lời (không tiết lộ ai là người cung cấp thông
tin, không để lộ ra ngoài tổ chức…)
- Hướng dẫn cách điền: rất cần thiết, cần lưu ý để tránh hiểu nhầm
- Thời hạn trả về:
 Cần nhắc khi gần đến thời hạn
- Câu hỏi trình bày rõ ràng
- Hình thức bảng câu hỏi phải dễ dàng để xử lý tự động
- Cần để dành chỗ để ghi câu trả lời.
 Thêm chỗ cho lời bình
 Không phải chỉ ở cuối trang, hay cuối bảng câu hỏi,
 Nên dự kiến những câu hỏi nào sẽ có ý kiến thêm thì nên có sẵn chỗ để
ghi lời bình ngay dưới câu hỏi đó)
- Ưu điểm:
Có thể tiến hành với nhiều người
Thích hợp với các câu hỏi đóng và hữu hạn
- Hạn chế:
Các câu hỏi k có trả lời nghĩa là k thu được thông tin
Thực hiện và đánh giá có thể chậm
Các câu hỏi có thể khó hiệu
Không thể thêm các thông tin khi đã tiến hành công việc
Thông tin thu được hạn chế trong một phạm vi hẹp
Chỉ dùng nó như một biện pháp bổ sung
5. Nghiên cứu tài liệu
 Các tài liệu (có thể tìm hiểu những văn bản chung)
 Những quy định nội bộ, Các báo cáo liên quan
 Những quy định về quy trình nghiệp vụ
 Rất khó có đầy đủ văn bản quy định về quy trình nghiệp vụ
 Đơn vị đạt chuẩn ISO?
 Những quy định “bất thành văn”
 Thường dễ hơn kỹ thuật phỏng vấn hay 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

- Phân loại các yêu cầu phi chức năng
Các yêu cầu về sản phẩm: hiệu năng, khả năng sử dụng, độ tin cậy
Các yêu cầu của tổ chức sử dụng hệ thống: thời gian bàn giao, yêu cầu phù hợp với
hệ thống cũ
Các yêu cầu ngoài được xác định từ các tác nhân bên ngoài như yêu cầu về luật pháp,
yêu cầu tôn trọng tính riêng tư
Câu 5: Trình bày phương pháp cài đặt và tích hợp từ trên xuống (Top-down) và
dưới lên (Bottom up). So sánh ưu nhược điểm
1. Cài đặt và tích hợp từ trên xuống
Trong phương pháp cài đặt và tích hợp theo kiểu trên xuống (top-down
implementation and integration), nếu module A có lời gọi đến module B thì
A được cài đặt và kiểm thử trước B. Để kiểm thử A thì B cần được cài đặt
dưới dạng stub. Sau khi A được kiểm thử thì cài đặt stub của B được mở rộng
thành cài đặt thực sự
- Trong sơ đồ ở trên thì thứ tự cài đặt và kiểm thử là: a, b, c, d, e, f, g, h, i, j, k, l,
m. Trước hết a được cài đặt. Sau đó b, c, d được cài đặt dưới dạng stub và a
được kiểm thử. Sau khi kiểm thử a thì đến lượt stub của b, c và d được mở
rộng thành cài đặt thực sự. e, f và g được cài đặt dưới dạng stub. Cứ như vậy,
khi cài đặt các module ở mức k trong sơ đồ hình cây thì ta cần cài đặt các
module ở mức k+1 dưới dạng stub. Quá trình kiểm thử dừng lại khi tất cả các
module đều được cài đặt và kiểm thử.
- Ưu điểm:
Dễ cô lập lỗi
Không phí stub : stub được mở rộng thành modul
Phát hiện sớm được sai sót trong thiết kế:
Các modul logic:Liên kết các dòng của sản phẩm. Các modul nằm ở kề
gốc của biểu đồ: a,b,c,d,g,j
Các modul thao tác: Tiến hành các thao tác thực sự: e, f, h, i, k, l, m
- Nhược điểm: Modul sử dụng lại có thể không được kiểm thử đầy đủ, đặc biết
là modul cài đặt và tích hợp cuối cùng

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

• Giao diện: vào, ra: đủ, phù hợp, đúng, tiện lợi
• Cấu trúc truy cập dữ liệu: thông suốt, đúng đắn
• Thực thi: trôi chảy, kịp thời, chịu lỗi phục hồi được
• Khởi đầu, kết thúc: mỗi tiến trình bình thường
- Kỹ thuật kiểm thử hộp đen
 Phân hoạch cân bằng: Mục đích của phương pháp này là tối thiểu các
trường hợp kiểm tra cho trước, các mục dữ liệu vào được chia thành các
nhóm dữ liệu có vai trò cân bằng nhau, mỗi nhóm đại diện cho một tập
dữ liệu. Nguyên tắc là bằng cách kiểm tra triệt để một mục của mỗi tập
hợp, chúng ta có thể chấp nhận tất cả các mục tương đương khác của tập
hợp đó cũng sẽ được kiểm tra một cách kỹ càng
 Phân tích cực biên: Phân tích giá trị cực biên là một dạng nghiêm ngặt
của phân hoạch cân bằng có sử dụng các giá trị biên hơn là bất cứ giá trị
nào trong tập cân bằng. Ví dụ: miền giá trị của tháng là 1 – 12 và ngoài là
0 và 13. Thì 4 kiểm tra ứng với bốn trường hợp sẽ được kiểm tra phân
tích cực biên thường xuyên được dùng tại các mức modul để xác định
các mục dữ liệu đặc trưng cho testing.
 Đoán lỗi: Dựa trên cơ sở trực giác và kinh nghiệm, các chuyên gia có thể
dễ dàng kiểm tra các điều kiện lỗi bằng cách đoán cái nào dễ xảy ra nhất.
Ví dụ, chia 0, nếu modul có phép chia, nên dùng phép chia 0. Vì dựa trên
trực giác, nên phép thử này khó tìm hết các lỗi.
2. Kiểm thử hộp trắng
2.1. Kiểm thử hộp trắng :
 là kiểm tra cấu trúc logic và phần mềm theo mục tiêu (trong trường hợp
này yêu cầu người kiểm thử phải biết số ngôn ngữ lập trình)
 Kiểm tra trạng thái của chương trình tại nhiều điểm của chương trình
2.2. Yêu cầu kiểm thử hộp trắng:
 Mọi con đường độc lập trong 1 module cần thực hiện ít nhất 1 lần
 Mọi ràng buộc logic được thực hiện cả 2 phía đúng và phía sai
 Tất cả các vòng lặp ở biên của nó và cả các biên vận hành phải được

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

• Bỏ qua vòng lặp
• Lặp 1 lần
• Lặp hai lần
• Lặp m lần với m<n
• Lặp n-1;n; n+1 lần
Trong đó n là số lần lặp tối đa của vòng lặp
- Vòng lặp lồng nhau :Các bước cần kiểm tra
• Khởi đầu với vòng lặp trong nhất. Thiết lập các tham số lặp
cho các
vòng lặp bên ngoài về giá trị min.
• Kiểm tra với min+1 giá trị tiêu biểu, max-1, max cho vòng lặp trong
nhất, tham số lặp của các vòng lặp bên ngoài là nhỏ nhất

•
Tiếp tục
với các vòng lặp liền ngoài tiếp theo đến khi tất cả vòng lặp bên
ngoài được kiểm tra

- Vòng lặp móc nối
•
Nếu các
vòng lặp độc lập: kiểm tra như trường hợp các vòng lặp dạng
đơn

• Nếu không: kiểm tra như trường hợp các vòng lặp lồng nhau

- Vòng lặp không có cấu trúc
3. Kiểm thử Belta
- được một hay nhiều người đặt hàng tiến hành
- không hiện diện người phát triển

- á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.

2. Phân loại bảo trì
- Bảo trì hiệu chỉnh: là quá trình phân tích và hiệu chỉnh một hay nhiều lỗi của
chương trình
- Bảo trì tiếp hợp: là hoạt động sửa đổi phần mềm để thích ứng được với những
thay đổi của môi trường
- Bảo trì hoàn thiện: nhằm thỏa mãn các yêu cầu của người sử dụng
- Bảo trì phòng ngừa: là hoạt động bảo trì được diễn ra khi phần mềm được thay
đổi để hoàn thiện tính năng bảo trì hay độ tin cậy trong tương lai hoặc để cung
cấp một nền tảng tốt hơn cho mở rộng sau này
3. Các công việc của bảo trì
Những nhiệm vụ liên quan tới việc bảo trì gồm: các tổ chức bảo trì được thiết
lập; các thủ tục ghi nhận và đánh giá được miêu tả ; và một loạt thứ tự chuẩn
cho các bước cho mỗi yêu cầu bảo trì được định nghĩa. Thêm vào đó, một thủ
tục lưu trữ các hồ sơ cho các hoạt động bảo trì được thiết lập và bảng tiêu
chuẩn những đánh giá được vạch rõ
3.1. Cơ cấu bảo trì
- Mặc dù những tổ chức bảo trì chuẩn k được thiếp lập nhưng sự ủy thác trách
nhiệm là rất cần thiết kể cả cho các tổ chức phát triển phần mèm nhỏ. Những
yêu cầu bảo trì được chuyển qua cho người kiểm soát công việc bảo trì và từ
đây chuyển tiếp yêu cầu tới người quản lý hệ thống để đánh giá. Người quản lý
hệ thống là thành viên của nhóm kỹ thuật. Những nhân viên này là một phần
nhỏ của chương trình sản phẩm. Khi một yêu cầu được đánh giá, người ủy
quyền quản lý việc thay đổi phải quyết định hành động nào được thực hiện tiếp
- Cơ cấu được miêu tả ở trên phục vụ cho viêc thiết lập các phạm vi trách nhiệm
với công việc bảo trì. Người kiểm soát và người ủy quyền quản lý việc thay đổi
có thể là 1 người hay một nhóm quản lý và chuyên gia kỹ thuật cao cấp
3.2. Báo cáo
- Tất cả các yêu cầu về việc bảo trì phần mềm cần được trình bày theo 1 tiêu
chuẩn. Người phát triển phần mềm thường cung cấp 1 đơn yêu cầu bảo trì còn
được gọi là báo cáo các lỗi phần mềm. Báo cáo này được người sử dụng điền

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

- Tổng số giờ của mỗi người dùng cho việc bảo trì
- Số lượng trung bình các thay đổi theo chương trình, theo ngôn ngữ lập trình,
theo kiểu bảo trì
- Số giờ trung bình của mỗi người cho 1 dòng lệnh thêm vào và xóa đi
- Số giờ trung bình của mỗi người cho một ngôn ngữ lập trình
- Thời gian trung bình cho 1 yêu cầu bảo trì cho đơn yêu cầu bảo trì
- Tỷ lệ phần trăm của mỗi kiểu bảo trì