Tài liệu phân tích quy trình phát triển phần mềm qua vòng đời phát triển phần mềm (SDLC) và các mô hình liên quan, bao gồm mô hình tuyến tính, mô hình lặp và mô hình xoắn ốc. Nó cũng đề cập đến tầm quan trọng của việc xác định và kiểm tra yêu cầu phần mềm trong quá trình phát triển, cùng với các yếu tố thành công và thách thức trong các dự án. Cuối cùng, ví dụ về các yêu cầu và trường hợp kiểm thử minh họa cách thực hiện các nguyên tắc trên trong thực tế.

1. Phân tích yêu cầu

2. 2
Nội dung
 Vòng đời phát triển phần mềm (SDLC)
 Giai đoạn phát triển phần mềm
 Yêu cầu
 Kiểm thử và các yêu cầu
 Học suy nghĩ như một tester
 Một số ví dụ
 Viết yêu cầu kiểm thử

3. 3
Vòng đời phát triển phần mềm
Software Development Life Cycle
(SDLC)

4. 4
Vòng đời phát triển phần mềm
(SDLC)
 SDLC là một cách tiếp cận có kỷ luật và có hệ
thống phân chia quá trình phát triển phần mềm
thành các giai đoạn khác nhau, chẳng hạn như
thiết kế, yêu cầu, và mã hóa
 Quá trình phát triển phần mềm theo các giai đoạn
giúp bạn theo dõi tiến độ, chi phí và chất lượng
của các dự án phần mềm

5. 5
Vòng đời phần mềm(SDLC)
 Có sáu giai đoạn của SDLC:
 Giai đoạn phân tích tính khả thi bao gồm việc phân tích các yêu
cầu dự án.
 Giai đoạn phân tích và đặc tả yêu cầu bao gồm thu thập, phân
tích, thẩm định, và đặc tả yêu cầu.
 Giai đoạn thiết kế bao gồm việc biên dịch các yêu cầu xác định
trong SRS thành một cấu trúc logic mà có thể được thực hiện
trong một ngôn ngữ lập trình.
 Giai đoạn mã hóa bao gồm việc cài đặt thiết kế đặc tả trong các
tài liệu thiết kế thành mã thực thi trên một ngôn ngữ lập trình cụ
thể.
 Giai đoạn kiểm thử bao gồm phát hiện lỗi trong phần mềm.
 Giai đoạn bảo trì bao gồm thực hiện các thay đổi và yêu cầu mới
trong phần mềm tại vị trí của khách hàng.

6. 6
Các mô hình SDLC
 Là một hình thức phù hợp của các giai đoạn
SDLC.
 Cung cấp một cơ sở để phân loại và kiểm
soát các hoạt động khác nhau cần thiết để
phát triển và bảo trì hệ thống phần mềm
 Loại điển hình của mô hình SDLC
 Mô hình tuyến tính
 Mô hình lặp

7. 7
Mô hình tuyến tính
 Mô hình tuyến tính phù hợp cho các dự án
mà tất cả các yêu cầu được xác định và hiểu
rõ trước khi thiết kế của phần mềm bắt đầu.
 Hai loại mô hình tuyến tính là:
 mô hình thác nước
 mô hình nguyên mẫu

8. 8
Mô hình thác nước
 Mô tả quá trình phát triển phần mềm theo luồng
trình tự tuyến tính.
 Xác định quá trình phát triển phần mềm trong
bảy giai đoạn:
 Khái niệm
 bắt đầu
 Phân tích
 Thiết kế
 Xây dựng
 Tích hợp và kiểm thử
 Triển khai và bảo trì

9. 9
Waterfall model

10. 10
Mô hình nguyên mẫu
 Là một cài đặt mẫu của hệ thống cho thấy
hạn chế và khả năng chức năng chính của
hệ thống được đề xuất.
Giúp khách hàng xác định các tính năng này
sẽ hoạt động trong các phần mềm cuối cùng.

11. 11
Prototyping model

12. 12
Mô hình lặp
 Mô hình lặp được sử dụng khi yêu cầu cho
phần mềm có khả năng phát triển trong suốt
quá trình phát triển.
 Các loại khác nhau của mô hình lặp
 Mô hình xoắn ốc
 Mô hình phát triển dựa trên thành phần
 Quy trình hợp nhất

13. 13
Mô hình xoắn ốc
 Bao gồm các tính chất lặp đi lặp lại của mô hình
nguyên mẫu và tính chất tuyến tính của mô hình
thác nước.
 Lý tưởng cho phát triển phần mềm được phát
hành trong các phiên bản khác nhau.
 Sáu giai đoạn của mô hình xoắn ốc là:
 Giao tiếp khách hàng
 Lập kế hoạch
 Phân tích rủi ro
 Kỹ thuật
 Xây dựng và phát hành
 khách hàng đánh giá

14. 14
Spiral model

15. 15
Mô hình phát triển dựa trên
thành phần
 Trong một mô hình phát triển dựa trên thành
phần:
 Các thành phần được tái sử dụng và kết hợp với các
thành phần khác trong cùng một máy tính khác hoặc
trong máy tính khác trong một mạng lưới phân phối
để tạo thành một ứng dụng.
 Tất cả các mô-đun có liên quan hình thành nên một
thành phần được kiểm tra để đảm bảo rằng họ làm
việc cùng nhau

16. 16
Ưu điểm: Các mô hình tuyến
tính
 Yêu cầu là trong tay của các kiểm thử viên
sớm
 Dự án được thiết kế tốt hơn, tập trung tốt
hơn
 Thay đổi muộn cho các yêu cầu hoặc thiết kế
được giới hạn
 Nhiệm vụ kiểm tra lịch biểu, lập kế hoạch, vv,
được thực hiện dễ dàng hơn

17. 17
Ưu điểm: Mô hình lặp
 Một sản phẩm có thể bản giao là sớm sẵn
sàng
 Tiến độ ("chúng ta đang ở đâu?") Là dễ theo
dõi
 Nhiều cơ hội để thẩm định lại các yêu cầu
hoặc xem xét lại thiết kế
 Dễ dàng bỏ qua các tính năng

18. 18
Nhược điểm: Mô hình tuyến
tính
 Quyết định lớn phải được thực hiện sớm
 Không biết những gì sẽ là khó khăn để thực
hiện
 Thay đổi một đặc điểm kỹ thuật ảnh hưởng
đến tất cả mọi người
 Áp lực lớn cho các kiểm thử viên để chứng
minh rằng sản phẩm là không sẵn sàng cho
phát hành

19. 19
Nhược điểm: Mô hình lặp
 Sản phẩm thiết kế có thể trở thành một nút cổ chai
 Sản phẩm thường phân phối với một nửa các tính năng
thiếu
 Sự cám dỗ lớn cho các nhà phát triển viết mã mới chứ
không phải là sửa chữa những gì bị hỏng
 Thiếu quy hoạch sớm có thể gây ra vấn đề khi các tính
năng sau được thêm vào
 Làm thế nào để tiếp thị sản phẩm?
 Liên tục thực thi lại cùng các kiểm thử
 Vòng đời sản phẩm dài

20. 20
Ảnh hưởng trên kiểm thử: Mô
hình tuyến tính
 Các yêu cầu phải được xem xét sớm
 Kế hoạch kiểm thử có thể được viết sớm
 Khi kiểm thử hệ thống bắt đầu, bạn đang trên
đường dẫn tới hạn

21. 21
Ảnh hưởng trên kiểm thử: Mô
hình lặp
 Kiểm thử bắt đầu ngay sau khi mức độ đầu
tiên của chức năng đạt được
 Kế hoạch thử nghiệm được viết như cách
bạn đi
 Yêu cầu thay đổi thiết kế có thể được dễ
dàng hơn

22. 22
Các giai đoạn phát triển phần mềm
Các yêu cầu

23. 23
Các giai đoạn phát triển phần
mềm
 Kế hoạch dự án / sản phẩm
 Yêu cầu và thiết kế
 mã hoá và tài liệu
 Kiểm thử và sửa lỗi
 Bảo trì và nâng cao

24. 24
Tại sao dự án bị hủy bỏ
Nhân tố khiếm khuyết % của Responses
1. Không đầy đủ yêu cầu 13,1%
2. Thiếu sự tham gia người dùng 12,4%
3. Thiếu Tài nguyên 10,6%
4. Kỳ vọng không thực tế 9,9%
5. Thiếu Hỗ trợ thực thi 9,3%
6. Thay đổi Yêu cầu & đặc tả 8,7%
7. Thiếu kế hoạch 8,1%
8. Không cần nó dài hơn 7,5%
9. Thiếu quản lý CNTT 6,2%
10. Thiếu Công nghệ 4.3%
Loại khác 9,9%

25. 25
Tại sao dự án bị thách thức?
Nhân tố thách thức của dự án % of Responses
1.Thiếu đầu vào của người dùng 12,8%
2. Yêu cầu và đặc tả không đầy đủ 12,3%
3. Thay đổi Yêu cầu & đặc tả 11,8%
4. Thiếu Hỗ trợ thực thi 7,5%
5. Thiếu năng lực về công nghệ 7,0%
6. Thiếu Tài nguyên 6,4%
7. Kỳ vọng không thực tế 5,9%
8. Mục tiêu không rõ ràng 5,3%
9. Khung Thời gian không thực tế 4,3%
10. Công nghệ mới 3,7%
Loại khác 23,0%

26. 26
Tại sao dự án hoàn thành
Project Success Factors % of Responses
1. Người sử dụng sự tham gia 15,9%
2. Hỗ trợ quản lý thực thi 13,9%
3. Phát biểu Yêu cầu rõ ràng 13,0%
4. Kế hoạch hợp lí 9,6%
5. Kỳ vọng thực tế 8,2%
6. Mốc dự án nhỏ hơn 7,7%
7. Nhân viên giỏi 7,2%
8. Quyền sở hữu 5,3%
9. Tầm nhìn & Mục tiêu rõ ràng 2,9%
10. Làm việc chăm chỉ, nhân viên tập trung 2,4%
Loại khác 13,9%

27. 27
Các yêu cầu phần mềm
 Theo lý thuyết công nghệ phần mềm, các yêu
cầu phần mềm chứa một danh sách hữu hạn
các hành vi và các tính năng, và mỗi yêu cầu
phải được kiểm chứng.
Với một danh sách hữu hạn các yêu cầu và
tập ràng buộc, kiểm thử dựa trên yêu cầu trở
thành một qui trình có tính khả thi.

28. 28
Các yêu cầu đặc trưng
 Chức năng - làm những gì tôi cần?
 Khả dụng - nó dễ dàng để làm những gì tôi
cần?
 Độ tin cậy - có thể làm những gì tôi cần khi
tôi cần nó?
 Hiệu suất - làm những gì tôi cần trong một
khoảng thời gian hợp lý?
 Supportability – hỗ trợ cái gì nếu KHÔNG
làm những gì tôi cần?

29. 29
Yêu cầu chức năng
 chính xác
 Mức độ mà một chương trình đáp ứng các chi tiết
kỹ thuật của nó và đáp ứng mong đợi của khách
hàng
 Tính năng / khả năng
 Tổng quát
 an ninh
Mức độ truy cập vào phần mềm hoặc dữ
liệu của người trái phép có thể được kiểm
soát

30. 30
Yêu cầu khả dụng
 Dễ sử dụng
 Các biện pháp nỗ lực cần thiết để tìm hiểu, vận
hành, chuẩn bị đầu vào, và giải thích đầu ra của
một chương trình
 "Trực quan”
 Nhân tố con người
 Tính nhất quán
 Tài liệu

31. 31
Yêu cầu độ tin cậy
 Tần số và mức độ nghiêm trọng của thất bại
– MTBF
 khả năng phục hồi
 Khả năng dự đoán
 Độ chính xác

32. 32
Yêu cầu hiệu năng
 Tốc độ
 Hiệu quả
 tài nguyên tiêu thụ
 thông lượng
 Thời gian đáp ứng

33. 33
Yêu cầu hỗ trợ
 Khả năng kiểm thử
 Khả năng thích nghi
 Bảo trì
 Nỗ lực cần thiết để xác định vị trí và sửa chữa
các lỗi
 Khả năng giúp đỡ
 Nỗ lực cần thiết để sửa đổi / cập nhật một
chương trình
 Khả năng cài đặt
 Khả chuyển

34. 34
Nội dung
Kiểm thử và các yêu cầu
Học suy nghĩ như một tester

35. 35
Các yêu cầu kiểm thử
 Thông thường thực hiện bằng cách xem xét
 Có hoàn thành?
 Có hợp lý không?
 Có thể được kiểm tra?

36. 36
Kiểm thử các yêu cầu
 Xác định tất cả các yêu cầu có thể kiểm thử
 Xác định tất cả các yêu cầu không thể kiểm
thử được
 Viết và thực hiện các bài kiểm thử

37. 37
Xét duyệt các yêu cầu phần
mềm
 Tìm hiểu để nhận ra những gì chưa được
quy định (giới hạn, hậu quả)
 Tìm hiểu để nhận ra những gì là mơ hồ hoặc
không rõ ràng ("đôi khi", "nhanh hơn“)
 Là một kiểm thử viên:
 Hãy chắc chắn rằng các kiểm thử viên được bao
gồm trong các ý kiến​​!
 Nỗ lực để có được yêu cầu làm rõ
 Hãy luôn suy nghĩ "tôi sẽ thử điều này như thế
nào ?“

38. 38
Xét duyệt thiết kế
 Giúp xác định làm thế nào để kiểm tra
 Cho thấy những gì cần tìm
 Bạn cần phải đọc mã không?

39. 39
Một số ví dụ
 Một số phát biểu yêu cầu
 Một số ví dụ “Test Cases”

40. 40
Ví dụ yêu cầu 1
 Sau khi nhiệt độ cao được phát hiện, báo
động phải được nâng lên một cách nhanh
chóng

41. 41
Các yêu cầu có thể kiểm thử:
VD. 1
 Nếu nhiệt độ ngưỡng đã đạt được, cảnh báo
được kích hoạt.
 Nếu là nhiệt độ vẫn dưới ngưỡng nhiệt độ,
cảnh báo không được kích hoạt.
 Nếu nhiệt độ xuống dưới ngưỡng (đã ở trên
nó), cảnh báo ngừng / không ngừng.

42. 42
Ví dụ yêu cầu 2
 người dùng chưa thành thạo sẽ có thể tìm
hiểu giao diện với huấn luyện nhỏ
Khi nghĩ về một thử nghiệm cho vấn đề này,
hãy tự hỏi: Điều gì sẽ là tiêu chí để nói rằng
các kiểm thử thông qua? thất bại?

43. 43
Ví dụ yêu cầu 3
Có một yêu cầu "ẩn“ trong tính năng thay đổi
này:
"Tùy chọn trình đơn '6. Utilities | 1. Security‟
sẽ hiển thị một menu con mới chứ không
phải là một hộp thoại bảo mật. Trình đơn phụ
sẽ có 3 mục - '1. CSM ', '2. CIS, '3. Options '.
“

44. 44
Ví dụ yêu cầu 4
Có bao nhiêu yêu cầu có thể kiểm chứng được
ở đây?
“Sự lựa chọn Access Profile cho '2. CIS 'và
'3. Options„ sẽ được chuyển sang màu xám
trừ khi những tùy chọn đã được mua và cài
đặt. “

45. 45
Yêu cầu có thể kiểm thử cho
VD. 4
 Sự lựa chọn Access Profile cho CIS có sẵn
nếu và chỉ nếu các tính năng CIS đã được
cài đặt.
Sự lựa chọn Access Profile cho Options có
sẵn nếu và chỉ nếu các tính năng Options đã
được cài đặt.

46. 46
Một vài testcase cho VD. 4
1. Nếu tùy chọn 'CIS được cài đặt, lựa chọn
Access Profile sẽ được sẵn sàng cho' CIS „
2. Nếu tùy chọn 'Options' được cài đặt, lựa
chọn Access Profile sẽ được sẵn sàng cho
'Options‟
3. Nếu tùy chọn 'CIS không được cài đặt, các
lựa chọn Access Profile cho' CIS sẽ không
có sẵn
4. Nếu tùy chọn 'Options' là không được cài
đặt, sự lựa chọn Access Profile cho
'Options' sẽ không có sẵn

47. 47
Ví dụ các yêu cầu 5
Một hệ thống bảo mật nâng cấp đã được cài
đặt với mật khẩu bảo vệ tăng cường. Dưới
đây là một yêu cầu:
"Mật khẩu hiện tại không phù hợp với các
hạn chế mới sẽ được thiết lập lại User ID, và
một danh sách của những người dùng có
mật khẩu đã thiết lập lại sẽ được tạo ra.”

48. 48
Ví dụ các yêu cầu 6
Phát hiện các yêu cầu không kiểm thử được
"Số cố gắng không hợp lệ trước khi một
người dùng bị đình chỉ: số này được thiết lập
lại khi đăng nhập thành công là hoàn thành
cho người sử dụng. Mặc định rằng người
dùng sẽ không bao giờ bị đình chỉ. Phạm vi
hợp lệ là từ 0 (không bao giờ) đến 10 lần. “

49. 49
Yêu cầu có thể kiểm thử cho
VD. 6
Yêu cầu: Số lượng của những nỗ lực không hợp lệ trước
khi đình chỉ có thể được thiết lập là 2
Trường hợp kiểm thử1: Sau 2 lần cố gắng 'xấu„ đăng nhập
vào, USERID của người dùng bị đình chỉ.
Trường hợp Kiểm thử 2: Một cố gắng 'xấu', theo sau là một
nỗ lực tốt, sau đó có thể được theo sau bởi 2 'xấu' cố
gắng một lần nữa trước khi đình chỉ.
Áp dụng tương tự cho 1, 3-10
Yêu cầu: Số lượng của những nỗ lực không hợp lệ trước
khi đình chỉ có thể được thiết lập đến 11
Trường hợp kiểm thử 3: Cố gắng để thiết lập những nỗ lực
không hợp lệ đến 11, hoặc xác minh nó không thể được
thực hiện.

50. 50
Ví dụ yêu cầu 7
Sự mơ hồ trong các khác nhau:
"Module Advanced Color sẽ cải thiện chất
lượng in của mô-đun".
“ Mô-đun Advanced Color sẽ làm tăng số
lượng các sắc thái màu sắc trên mỗi bảng từ
4-9 màu thành 25 - 30 sắc thái"
Module Advanced Color sẽ làm giảm hiệu
ứng ốp lát kết hợp với các mô-đun trước. “

51. 51
Ví dụ yêu cầu 8
Rất nhiều trường hợp thử nghiệm từ một câu:
"Tất cả các màn hình mới và được sửa đổi
sẽ cung cấp trợ giúp trực tuyến.”

52. 52
Ví dụ 9
3.3.1.3.2. User Name và Password quy tắc
Tên có tối đa 24 ký tự. Các kí tự với các giá trị ASCII 0
đến 31, kí tự trống, '*', và ',' là không hợp lệ.
Mật khẩu có tối đa 24 ký tự. Mật khẩu là chữ số. Dấu
chấm câu không được cho phép. Quản trị có thể thiết
lập các tùy chọn để tiếp tục hạn chế việc xây dựng mật
khẩu, xem Tùy chọn User / Password.
Tất cả các ký tự mở rộng trên ASCII 255 có sẵn cho các
tên người dùng và mật khẩu. Điều này bao gồm tất cả
các ký tự double-byte.
Tên người dùng và mật khẩu là trường hợp nhạy cảm.
Tên Người dùng sẽ luôn luôn được hiển thị dạng chữ
hoa

53. 53
Ví dụ 10
 Giao diện người sử dụng phải được dễ dàng
sử dụng.
Trong trường hợp thất bại, hệ thống phải
được dễ dàng để phục hồi và phải chịu tổn
thất tối thiểu của dữ liệu quan trọng.

54. 54
Bài học
 Theo dõi các từ như "luôn luôn", „không bao giờ
',' tất cả ',.. Chúng rất khó để xác minh.
 Những từ như "phải", "nên", "phải", "sẽ", “cần
phải",... tín hiệu yêu cầu tiềm năng.
 Quan sát các yêu cầu ẩn hoặc không được nhắc
đến.
 Watch cho các yêu cầu mơ hồ: "cao", "nhanh
chóng", "tốt hơn", "nhanh", "sẽ có thể đến“.
 Đối với thử nghiệm tiêu cực, hãy hỏi "Điều gì sẽ
xảy ra nếu các trường hợp thử nghiệm không
thành công?”
 Hãy tự hỏi mình câu hỏi: "Làm sao tôi biết nếu
yêu cầu không được đáp ứng?”