ĐÁP ÁN ĐỀ CƯƠNG MÔN CÔNG NGHỆ PHẦN MỀM

ĐÁP ÁN ĐỀ CƯƠNG MÔN CÔNG NGHỆ PHẦN MỀM
Người Soạn: Nguyễn Huy Hoàng
CĐ5.2 – K3 – CNTT
DĐ: 01234.321.989 & 01689.989.359
Câu 1: Phân tích mơ hình thác nước. Liên hệ với bài tập lớn em đã làm
Trả Lời:

Mơ hình thác nước xem quá trình xây dựng một sản phẩm phần mềm bao
gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thì chuyển đến
giai đoạn sau
+) Ưu Điểm:
- Dễ quản lí
- Ước lượng thời gian và chi phí rất chính xác
+) Nhược Điểm:
- Rủi ro cao
- Địi hỏi khách hàng đưa ra yêu cầu chính xác ngay từ đầu
+) Ứng Dụng:
- Khách hàng đưa ra yêu cầu ngay từ đầu
- Nhà phát triển hiểu hệ thống
So với bài tập lớn em đã làm thì em áp dụng mơ hình thác nước trong suốt
quá trình làm bài tập lớn. Theo đúng cách hồn thành xong giai đoạn này thì
chuyển sang giai đoạn khác
Câu 2: Phân tích mơ hình xoắn ốc, liên hệ với bài tập lớn em đã làm


Trả Lời:
Mơ hình xoắn ốc có thể xem là sự kết hợp giữa mơ hình thác nước và mơ
hình mẫu và đồng thời thêm một thành phần mới – Phân tích rủi ro. Bao
gồm 4 hoạt động chính
1. Planning: Xác định mục tiêu, tương tác và ràng buộc
2. Riskanalysis: Phân tích các lựa chọn và chỉ định / giải quyết rủi ro

3. Engineering: Phát triển sản phẩm
4. Customerevaluation: Đánh giá kết quả xây dựng
+) Ưu Điểm:
- Loại bỏ được khoảng cách giữa nhà sản xuất và khách hàng
- Khắc phục được nhược điểm của mơ hình khác
- Sử dụng mơ hình mẫu + phân tích rủi ro
- Sử dụng mơ hình thác nước + mơ hình lặp
+) Khuyết điểm:
- Mơ hình mới
- Địi hỏi khách hàng có kĩ năng đánh giá tốt và việc phân tích
rủi ro cũng phải tốt
Câu 3: So sánh mơ hình mẫu và mơ hình tiến hoá
Trả Lời :
+) Giống nhau:
- Rút ngắn khoảng cách giữa khách hàng và người phát triển
hệ thống
- Hệ thống dễ kết cấu kém
- Khách hàng không hiểu rõ về hệ thống
+) Khác nhau:
Mơ Hình Mẫu
Mơ Hình Tiến Hố
- Khách hàng có thể biết được hệ
- Khơng lãng phí các bản mẫu
thống ngay từ ban đầu
- Nhà sản xuất không hiểu biết về
- Mơ hình này dễ thất bại
cơng nghệ
- Người sản xuất hiểu được hệ thống - Khách hàng không thể biết được hệ
- Người sản xuất không chắc về hiệu thống từ ban đầu
quả giao diện

Câu 4 : So Sánh mơ hình lặp và mơ hình tăng dần
Trả Lời :
+) Giống nhau: Giống mơ hình tiến hố nhưng mà mẫu thì được đưa vào sử
dụng
- Phiên bản mẫu đầu tiên thì phải có được 1 số chức năng
chính cốt lõi, phần mềm
+) Khác Nhau :


Mơ Hình Lặp
-Có đầy đủ các chức năng ở phiên
bản đầu -> tiếp tục lặp và phát triển
các phiên bản sau
- Đội ngũ phát triển quen thuộc với
lĩnh vực dự án nhưng khơng có nhiều
kinh nghiệm, nhất là về cơng nghệ
được dùng phát triển dự án.
- Khách hàng không hiểu rõ về hệ
thống
- Có nhiều rủi ro về mặt kĩ thuật

Mơ Hình Tăng Dần
- Phiên bản đầu khơng đầy đủ các
chức năng mà là do phiên bản thứ 2
bổ xung vào các chức năng đó riêng
khi chu trình thứ 2 thì khơng bắt
buộc phải làm như khúc đầu mà có
thể áp dụng ở mơ hình khác
- Đội ngũ phát triển quen thuộc với
lĩnh vực của dự án và có nhiều kinh

nghiệm.
- Hệ thống lớn được phát triển trong
thời gian dài, khách hàng cần triển
khai sớm một số phần của hệ thống.

Câu 5: Mô tả sơ lược các kĩ thuật thu thập yêu cầu
Trả Lời:
PP1: Phỏng vấn
+) Lúc ban đầu
- Chào hỏi, giới thiệu
- Đặt câu hỏi dễ, mang tính bao quát
- Chú ý tới câu trả lời để dẫn dắt phần tiếp theo
- Chú ý tới thái độ, trung thực của người phỏng vấn
+) Đoạn giữa:
- Vấn đề chính
- Với những vấn đề quan trọng, không được trả lời rõ ràng thì
chúng ta nên gợi ý
+) Kết thúc: Tổng quát-> khách hàng
Ưu điểm: Cơ bản lấy được đầy đủ thông tin
Nhược điểm: Không thu thập được nhiều ý kiến
PP2: Phương pháp họp nhóm :
Ba người trở lên
o Chuẩn bị nội dung : Lịch trình từ trước
o Cung cấp nội dung, lịch trình trước cho người tham gia
o Tập trung để lấy những thông tin: Tổng quát, chi tiết nhất
Ưu điểm:
- Lấy được thông tin , tổng quát, chi tiết
- Lấy được thông tin từ nhiều người
Nhược điểm: Gây nhiều tranh cãi

PP3: Phương pháp quan sát thủ công
+) Thủ công : Quan sát , ghi chép lại, những hoạt động xử lí
+) Tự động : Hoạt động xử lí trong máy tính
Tiến trình
- Hỏi ý kiến người bị quan sát
- Chọn vị trí thích hợp
- Chọn lọc thơng tin theo chủ đề định trước
+) Điều tra qua bảng câu hỏi
Điều tra qua câu hỏi là xây dựng các câu hỏi để phỏng vấn trên giấy hoặc
máy tính. Các câu hỏi được dùng để nhận các thông tin từ số lượng lớn
người sử dụng và thường ở dạng khả năng lựa chọn, người trả lời chỉ việc
đánh dấu. Các mục câu hỏi, như là phỏng vấn, có thể là câu hỏi mở hoặc câu
hỏi đóng nhưng khơng chỉ rõ tên, dẫn đến các câu trả lời trung thực hơn
nhiều phỏng vấn.
Ưu điểm :
 Các trả lời không cần biết tên nên quan điểm và cảm nhận thu được là
trung thực
 Có thể tiến hành với nhiều người
Hạn chế :
 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
 Khó tiến hành
 Chỉ dùng nó như một phương pháp bổ sung,...
PP4: Xem xét tài liệu
Qui định, qui chế , phiếu, bảng biểu
Lấy những thơng tin chi tiết, qui trình
 Thơng tin qui trình CSDL -> đưa ra những câu hỏi
Hệ thống cũ lấy những thơng tin về q trình, chức năng, lấy những
thông tin cần bổ xung, nâng cấp ở phần mềm trước

Câu 6: Nêu cấu trúc của bản đặc tả yêu cầu
Trả lời:
Bản đặc tả yêu cầu gồm các phần
1. Giới thiệu mơ tả mục đích khái qt, chức năng, thuật ngữ, từ viết
tắt, từ chuyên ngành,
Mô tả về mơ hình chung cho hệ thống


•
•
•
•
•
•
•
•
•

Mô tả chức năng hay phi chức năng
Những yêu cầu chức năng
Những yêu cầu phi chức năng
Hướng phát triển của hệ thống : làm được gì, giới hạn,
định hướng
Đặc tả chi tiết các yêu cầu
Có thể có các thành phần
Nêu ra các phần cứng
Mục lục
Yêu cầu về cơ sở dữ liệu

Tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE

1. Giới thiệu
1.1. Mục đích của tài liệu yêu cầu
1.2. Phạm vi của sản phẩm
1.3. Các định nghĩa, từ viết tắt
1.4. Các tham chiếu
1.5. Tổng quan về tài liệu yêu cầu
2. Mô tả chung
2.1. Giới thiệu chung về sản phẩm
2.2. Các chức năng của sản phẩm
2.3. Đặc điểm của người sử dụng
2.4. Các ràng buộc
2.5. Giả thiết và các phụ thuộc
3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền ứng
dụng và giao diện.
4. Phụ lục
5. Chỉ mục
4. Đánh giá các yêu cầu
Đánh giá yêu cầu phần mềm liên quan tới việc cho biết các yêu cầu đã
được định nghĩa có đáp ứng được các địi hỏi của khách hàng khơng. Nếu
việc đánh giá này khơng chính xác thì việc thiết kế hệ thống và triển khai hệ
thống cũng bị ảnh hưởng. Chi phí sửa chữa lỗi sẽ rất lớn.


Một số vấn đề của yêu cầu cần được đánh giá là:
 Giá trị: người dùng có thể nghĩ rằng hệ thống cần một số chức năng,
tuy nhiên sau một số phân tích, có thể xác định các chức năng khác cần được
đưa vào. Vì vậy cần xác định đầy đủ các yêu cầu.
 Chắc chắn: mọi yêu cầu không được mâu thuẫn với các yêu cầu khác
 Hoàn chỉnh: định nghĩa cần phải bao gồm mọi chức năng và các ràng
buộc,

 Hiện thực: khơng có các u cầu đặc biệt đến mức phi hiện thực.
Các xem xét yêu cầu có thể là hình thức hoặc phi hình thức. Xem xét
phi hình thức liên quan tới việc các người ký hợp đồng thảo luận các yêu cầu
với khách hàng. Nhiều vấn đề có thể được giải quyết dễ dàng khi thảo luận
trực tiếp với khách hàng. Đối với các yêu cầu xem xét hình thức, đội phát
triển phải dẫn dắt khách hàng thông qua các yêu cầu hệ thống, giải thích các
triển khai của mỗi yêu cầu.
Câu 7: Nêu cấu trúc phân cấp của 1 phần mềm và 1 số yêu cầu thiết
kế khi thiết kế kiến trúc phần mềm
Trả Lời:
Một số chỉ số của bản cấu trúc phân cấp thủ tục:
 Chiều rộng: độ trải rộng của toàn bộ cấu trúc phân cấp
 Chiều sâu: độ cao của cấu trúc phân cấp
 Số module ra của một module: số các module trực tiếp bị điều
khiển của module đó
 Số module vào của một module: số các module trực tiếp điều khiển
module đó
 Thượng cấp: là module điều khiển module khác
 Thuộc cấp: là module bị module khác điều khiển
Cấu trúc một chương trình và các chỉ số được minh họa như hình dưới đây:


Một số yêu cầu thiết kế khi thiết kế kiến trúc phần mềm là:
Yêu cầu:
• Vạch ra các thành phần của phần mềm
• Mơ hình của phần mềm
• Giải thích, đặc tả về mơ hình
• Dễ hiểu và dễ đọc
• Linh hoạt với những u cầu thay đổi
• Giảm kích thước của mơ hình

• Giảm chiều rộng
• Giảm chiều sâu
• Chỉ rõ các module chưa làm được
• Giả sử giao diện của modunle

Câu 8: Nêu các yêu cầu thiết kế giao diện phần mềm, phân biệt sự khác
nhau giữa yêu cầu người dùng và yêu cầu hệ thống
Trả Lời :


Các yêu cầu khi thiết kế giao diện phần mềm :
• Đảm bảo sự quen thuộc của người dùng
• Giao diện phải có tính thống nhất
• Đảm bảo khả năng phục hồi
• Giao diện phải có tính đa dạng

u Cầu Người Dùng

u Cầu Hệ Thống

• Khơng quan tâm đến cấu truc
bên trong

• Chú trọng cấu trúc bên trong
của hệ thống

• Đánh giá và cảm nhận qua
giao diện tương tác

• Đánh giá hệ thống qua các

chức năng và cấu trúc của nó

Câu 10: Nêu sơ lược các bước trong một qui trình kiểm thử phần mềm
Trả Lời :
Quy trình kiểm thử phần mềm bao gồm các bước
• Lập kế hoạch kiểm tra
• Thiết kế test case
• Phát triển test script
• Thực hiện test
• Đánh giá kết quả test
+) Lập kế hoạch : Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển
khai và thực hiện. Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch
KTPM bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho
đến thời gian và phân định lực lượng kiểm tra viên
+) Thiết kế test: Nhằm chỉ định các test case và các bước kiểm tra chi tiết
cho mỗi phiên PM. Giai đoạn thiết kế test là hết sức quan trọng, hết sức quan
trọng , nó đảm bảo tất cả các tình huống kiểm tra hết tất cả các yêu cầu
Các bước thiết kế test
• Xác định và mơ tả test cây
• Mơ tả các bước chi tiết để kiếm tra


• Xem xét và khảo sát độ bao phủ của việc kiểm tra
• Xem xét test case và các bước kiểm tra
+) Phát triển test Script: Bước này thường không bắt buộc trong các loại và
mức kiểm tra, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo
ra các test script có khả năng chạy trên máy tính giúp tự động hố việc thực
thi các bước kiểm tra đã định nghĩa ở các bước thiết kế test
+) Thực hiện test
Mục đích thực hiện các bước kiểm tra đã thiết kế và ghi nhận kết quả

+) Đánh giá test
Mục đích: Đánh giá tồn bộ q trình kiểm tra bao gồm xem xét và đánh giá
kết quả kiểm tra lỗi, chỉ định các yêu cầu thay đổi và tính tốn số liệu liên
quan, đến q trình kiểm tra
Câu 11: Nêu sơ lược các mức độ kiểm thử phần mềm
Trả Lời :
1. Kiểm thử đơn vị :là tiến trình kiểm thử tập trung vào các đơn vị nhỏ
nhất của thiết kế phần mềm đó là hàm, các lớp, các thủ tục hoặc các phương
thức. Kiểm thử đơn vị bao giờ cũng hướng theo hộp trắng và bước này có
thể được tiến hành song song cho nhiều môđun.
Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng
hoạt động đơn giản nên khơng khó khăn gì trong việc tổ chức, kiểm tra, ghi
nhận và phân tích kết quả. Nếu phát hiện lỗi, việc xác định nguyên nhân và
khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng một đơn thể đơn vị
đang kiểm tra. Thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết
kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức độ
kiểm tra sau đó.
Unit Test thường do lập trình viên thực hiện. Cơng đoạn này được thực
hiện cùng với giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm.
Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị
trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ
dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case
và script này nên được giữ lại để tái sử dụng.
2.2. Kiểm thử tích hợp (Integration Test)
Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm
tra như một ứng dụng đã hoàn thành. Kiểm thử mức đơn vị là kiểm tra các


thành phần, các đơn vị riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với
nhau và kiểm tra sự giao tiếp giữa chúng.

Integration Test có 2 mục tiêu chính:
 Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
 Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ, và cuối cùng là
nguyên hệ thống hoàn chỉnh để chuẩn bị kiểm tra ở mức hệ thống.
Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên Unit đã
được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã
được sửa chữa. Với các Unit đã qua giai đoạn Unit test với các giao tiếp giả
lập thì vẫn cần thiết phải thực hiện Itegration Test nữa. Thực tế việc tích hợp
giữa các Unit dẫn đến nhiều tình huống khác với giả lập giao tiếp.
2.3. Kiểm thử mức hệ thống (System Test)
Mục đích của kiểm tra hệ thống là kiểm tra thiết kế và tồn bộ hệ thống
sau khi tích hợp có thỏa mãn u cầu đặt ra hay khơng.
Có 2 cách :
• Kiểm thử Alpha
- Được bên phát triển tiến hành
- Phần mềm sẽ được dùng trong bối cảnh tự nhiên để người phát triển
đứng vào vai trò người sử dụng và báo cáo các sai và các vấn đề sử
dụng
- Được tiến hành trong một môi trường được điều khiển (theo kế hoạch
của người phát triển)
• Kiểm thử Beta
- Được một hay nhiều người đặt hàng tiến hành
- Không có sự 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 số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 đề 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

2.4. Kiểm thử chấp nhận phần mềm (Acceptance Test)
Kiểm thử chấp nhận được khách hàng thực hiện. Mục đích của kiểm
thử chấp nhận là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của
khách hàng và khách hàng chấp nhận sản phẩm chưa.
Kiểm thử chấp nhận có ý nghĩa quan trọng, mặc dù hầu hết mọi trường
hợp, các phép kiểm tra của kiểm thử hệ thống và kiểm thử chấp nhận gần
tương tự như nhau, nhưng bản chất và cách thức thực hiện lại rất khác biệt.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia
vào quá trình phát triển phần mềm thì kết quả của kiểm thử chấp nhận sẽ sai
lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm tra trước đó. Sự
sai lệch này liên quan đến việc hiểu sai yêu cầu và sự mong chờ của khách
hàng
2.5. Kiểm thử hồi quy (Regression Test)
Kiểm thử hồi quy không phải là một mức kiểm tra như các mức khác
nói trên. Nó đơn thuần kiểm tra lại phần mềm sau khi có một sự thay đổi xảy
ra, để bảo đảm phiên bản phần mềm mới thực hiện tốt các chức năng như
phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng đã
hoạt động tốt. Kiểm thử hồi quy có thể thực hiện tại mọi mức kiểm tra.