8.

2 Tài liệu phát triển

Mỗi giai đoạn SDLC tạo ra tài liệu hướng phát triển. Những tài liệu này là những tuyên bố về giải
pháp ngày càng hoàn thiện cho nhu cầu của người dùng khi quá trình phát triển tiếp tục. Tài liệu
phát triểna - bao gồm SDLC và theo dõi phần mềm từ các yêu cầu phát triển từ giai đoạn khám phá
khái niệm thông qua giai đoạn cài đặt.

Loạt tài liệu này, mỗi tài liệu đóng vai trò là cơ sở cho cấp độ tiếp theo,cho phép người sản xuất
xác định khi nào họ đã hoàn thành nhiệm vụ và người kiểm tra để xác định xem liệu phần mềm có
tuân thủ các yêu cầu.

Các tài liệu phát triển chính như sau:

• Yêu cầu kỹ thuật;

• Thiết kế sơ bộ;

• Thiết kế chi tiết (xây dựng đến);

• Bản mô tả thiết kế (như đã xây dựng);

• (Các) đặc tả cơ sở dữ liệu;

• (Các) đặc điểm kỹ thuật giao diện.

Có nhiều định dạng cho mỗi tài liệu phát triển cơ bản.

Định dạng cho mỗi tài liệu SLC cơ bản ít quan trọng hơn định dạng

lều của tài liệu. Hơn nữa, sự cần thiết của một số tài liệu cụ thể

phụ thuộc vào quy mô và độ phức tạp của dự án cụ thể. Trong vài trường hợp,

thông tin cần thiết có thể được cung cấp trong một tài liệu cấp cao hơn.

Do đó, định dạng thực tế và thông số kỹ thuật nội dung sẽ là một chức năng của tổ chức cá nhân
và các tiêu chuẩn tài liệu đã đạt được .

Tài liệu yêu cầu nhằm xác định đầy đủ chức năng tổng thể- được thực hiện hoặc vấn đề cần được
giải quyết. Đây là một tài liệu bắt buộc, mà không có dự án này thậm chí không nên được bắt đầu.
Cho đến khi khách hàng hoặc người dùng đã nêu rõ những gì sẽ được cung cấp, nhà sản xuất không
thông tin đầy đủ để bắt đầu công việc. Không có một tuyên bố rõ ràng về phần mềm muốn những
gì, không có cách nào để xác định sự hoàn thành hoặc hoàn thành như thế nào để đạt được.

Tài liệu thiết kế, cả sơ bộ và chi tiết, mô tả chi tiết từng bước phương pháp mà vấn đề hoặc chức
năng đang được giải quyết.Trước khi viết mã, thiết kế phải sao cho người viết mã không cần đưa ra
bất kỳ quyết định nào "Tôi nghĩ họ có ý này". Sau khi mã hóa và thử nghiệm, tài liệu thiết kế cuối
cùng nên được xuất bản, đó là tài liệu "như đã xây dựng "đề cập rằng sẽ được sử dụng bởi những
người bảo trì phần mềm sau khi cài đặt.

8.2.1 Đặc tả yêu cầu

Đặc tả yêu cầu là nền tảng của tất cả các tài liệu phần mềm. Nó là tuyên bố về những gì hệ thống
phần mềm sẽ cung cấp. Nó ghi lại vấn đề cần giải quyết, bất kỳ hạn chế hoặc ràng buộc nào đối với
hiệu suất hoặc môi trường, hạn chế về thời gian và kích thước, các yêu cầu cụ thể đánh vào đầu vào
và đầu ra, và bất kỳ thông tin nào khác cần thiết cho đặc điểm kỹ thuật hoàn chỉnh của vấn đề hoặc
chức năng. Không có đặc điểm kỹ thuật hoàn chỉnh này về những gì phần mềm sẽ đạt được, chuyên
gia được đặt vào vị trí phải đưa ra các quyết định về yêu cầu như tiến độ thiết kế. Điều đó loại bỏ
một số quyền kiểm soát của hệ thống khỏi khách hàng và có thể dẫn đến việc khách hàng không
nhận được những gì đã chết. Nhìn theo một cách khác, nhà sản xuất cũng ở vị trí không thể cung
cấp bất cứ điều gì có thể chấp nhận được cho khách hàng nói, "Đó là không phải những gì tôi yêu cầu
”. Phụ lục D hiển thị một định dạng chung cho một tài liệu yêu cầu.

Có nhiều cách mà lỗi hoặc các yêu cầu bị lỗi len lỏi vào tài liệu yêu cầu. Vai trò của người thực
hành chất lượng phần mềm là xem xét cẩn thận tài liệu yêu cầu, cả về việc tuân thủ các tiêu chuẩn
cơ bản cho tài liệu và tính đúng đắn của nội dung. Các sau này có thể đặt ra vấn đề đối với một số
người hành nghề không có chuyên môn tư nhân được phê duyệt để xem xét đầy đủ tài liệu về nội
dung kỹ thuật. Trong những trường hợp đó, người đánh giá bên ngoài có thể được sử dụng hoặc
nhóm phát triển có thể được kêu gọi để cung cấp đánh giá các yêu cầu trước khi họ thực hiện nhiệm
vụ phát triển.

Ngoài việc chính xác, các yêu cầu phải đáp ứng ít nhất năm các tiêu chí quan trọng: chúng phải cần
thiết, đầy đủ, có thể đo lường, rõ ràng và nhất quán (cả bên trong và với các giao diện bên ngoài).

Tính đúng đắn

Tính đúng đắn của các yêu cầu là mối quan tâm hàng đầu, đối với cả nhà sản xuất và nhà sản xuất.
Mô tả về những gì được mong muốn và các nhu cầu và ràng buộc tăng lên phải được nêu một cách
chính xác nếu sự phát triển là để tạo ra một sản phẩm có thể chấp nhận được. Việc sử dụng một
phương trình không phải là trực tiếp cho tình huống hoặc giải quyết một quy định của chính phủ
không chính xác sẽ dẫn đến hệ thống không đáp ứng được nhu cầu của khách hàng, thậm chí mặc dù
nó có thể tuân thủ các yêu cầu như đã nêu.

Sự cần thiết

Một yêu cầu đặt ra các hạn chế hoặc yêu cầu không cần thiết đối với hệ thống phần mềm cũng
làm tăng chi phí về thời gian và tiền bạc mà không có lợi cho hệ thống. Những thứ như thời gian quá
nghiêm ngặt, độ chính xác không cần thiết trong cal-culations, hạn chế bộ nhớ chặt chẽ một cách vô
cớ, khả năng xử lý quá mức và những thứ tương tự, đôi khi đi vào yêu cầu. Họ có thể nghe đẹp hoặc
có vẻ cần thiết ngay từ đầu, nhưng những yêu cầu không cần thiết có thể gây ra tình trạng kém phát
triển sau này. Yêu cầu đối với việc xử lý séc khả năng 200.000 mỗi ngày nghe có vẻ ổn, nhưng nếu
đó là đối với một ngân hàng nhỏ thực sự chỉ cần xử lý 50.000 lần kiểm tra mỗi ngày, nó sẽ bổ sung
một cách không cần thiết vào chi phí của hệ thống và cung cấp khả năng sẽ không đã sử dụng.

Sự hoàn chỉnh

Sự hoàn chỉnh có vẻ là một tiêu chí hiển nhiên cho các yêu cầu, nhưng nó là không kém quan trọng
cho điều đó. Khi một tài liệu yêu cầu được xuất bản không đề cập đến toàn bộ vấn đề cần giải quyết,
nhà phát triển thường ở trong cửa hàng để gây bất ngờ. Một tình huống sẽ phát sinh trong quá
trình thiết kế hoặc mã hóa điều đó không có cơ sở trong các yêu cầu, hoặc khách hàng có thể hỏi vị
trí của tính năng loại bỏ sàng lọc sau khi nhà sản xuất cho rằng công việc đã hoàn thành. Ít nhất, nhà
sản xuất có thể bị đặt vào tình thế phải thêm hoặc sửa đổi các yêu cầu lại, các hành động mà khách
hàng phải chịu trách nhiệm.

Khả năng đo lường

 Khả năng đo lường là chìa khóa để kiểm tra. Một yêu cầu không thể đo lường được không thể
được chứng minh bằng chương trình thử nghiệm. Ví dụ, một yêu cầu đối với "thời gian phản hồi
nhanh" rõ ràng là bị lỗi. Chính xác thì "nhanh" là gì nghĩa là? Một ví dụ khác là yêu cầu “xử lý nhiều
mục tiêu”."Nhiều" là không xác định và do đó không thể đo lường hoặc bị quỷ ám. Các yêu cầu
không thể đo lường được tạo ra các cơ hội xung đột tại tất cả các điểm trong SDLC, đặc biệt là ở
phần trình diễn hệ thống và thời gian nghiệm thu.

Thời gian phản hồi hai giây dường như đủ “nhanh” đối với thiết bị khử khóa dán có thể chậm đến
mức không thể chấp nhận được trong mắt khách hàng. "Nhiều" có thể có nghĩa là 20 đối với nhà
phát triển nhưng chỉ có 10 đối với khách hàng, những người không muốn trả tiền cho khả năng bổ
sung.

Rõ ràng

Yêu cầu rõ ràng không để lại gì cho trí tưởng tượng của các pro-ducer. Không cần phải đoán xem
khách hàng thực sự muốn nói gì hoặc muốn. Yêu cầu thời gian phản hồi không quá hai giây nghe có
vẻ như là một yêu cầu tốt, có thể đo lường được. Tuy nhiên, nó không rõ ràng trong rằng nó không
nêu thời điểm mà tại đó số đo của hai giây là để bắt đầu hoặc kết thúc. Một nguồn mơ hồ chính là
sự quen thuộc với chủ đề mà một người quên rằng những người khác có thể không biết tất cả các
biệt ngữ hoặc có thông tin nội bộ. Đôi khi người viết yêu cầu giả định rằng “ai đó biết điều đó.” Một
nguồn mơ hồ khác là từ ngữ yếu.

Yêu cầu phải được diễn đạt theo nghĩa của động từ mệnh lệnh sẽ. Các động từ như nên, có thể,
hoặc thậm chí sẽ thể hiện mong muốn, nhưng chúng không làm mất ý định. Để nói rằng một hệ
thống "nên" tính căn bậc hai của 3 ngụ ý rằng nó có thể không.

Tính nhất quán

Cuối cùng, tiêu chí về tính nhất quán phải được xem xét. Các yêu cầu phải phù hợp với
bản thân và cả với thế giới bên ngoài với mà họ phải giao diện. Ví dụ: yêu cầu trong một
phần khác xử lý 1.000 séc mỗi giờ không phù hợp với yêu cầu trong một phần-khác yêu cầu
10.000 séc trong một ngày tám giờ. Và cả hai những yêu cầu đó không phù hợp với thế giới
bên ngoài nếu máy móc sử dụng séc chỉ có khả năng xử lý 900 séc mỗi giờ.

8.2.2 Đặc điểm thiết kế

Các thông số kỹ thuật thiết kế sơ bộ và chi tiết mô tả cách phần mềm tiếp cận và đáp ứng
từng yêu cầu. Thiết kế chi tiết thông số kỹ thuật có hai loại. Đặc điểm kỹ thuật thiết kế cuối
cùng trước khi mã hóa có thể được coi là thiết kế "xây dựng". Nó trình bày những gì các nhà
thiết kế tin là giải pháp chính xác và đáp ứng các yêu cầu đã được phê duyệt. Mô tả thiết kế,
phản ánh phần mềm như nó đang hoạt động- đồng minh đã hoàn thành, thường được gọi là
thiết kế "như đã xây dựng".

Cũng như các yêu cầu, thiết kế phải thể hiện các tiêu chí tính đúng đắn, cần thiết, đầy đủ,
khả năng đo lường và khả năng kiểm tra, thiếu sự mơ hồ và nhất quán. Hơn nữa, thiết kế
phải được truy nguyên trở lại các yêu cầu. Mỗi yếu tố của thiết kế phải có thể được hiển thị
như đáp ứng một số phần của các yêu cầu. Đổi lại, mỗi yêu cầu phải có thể được truy nguyên
vào thiết kế. Bằng cách đó, có thể tin chắc rằng các nhà thiết kế đã không thêm hoặc bỏ sót
bất kỳ điều gì trong quá trình quá trình thiết kế.

Đánh giá chính thức và không chính thức thường xuyên về thiết kế khi nó đang tiến triển
được tổ chức để đảm bảo rằng thiết kế không sai lệch so với các yêu cầu. Các bài đánh giá
cũng nhằm cho thấy rằng thiết kế phù hợp và tuân thủ các tiêu chí khác nhau. Người thực
hành chất lượng phần mềm chơi một công cụ vai trò trong các cuộc đánh giá này bằng cách
đảm bảo trước hết là chúng được tổ chức. Những người hành nghề chất lượng phần mềm
không nhất thiết phải tham dự những buổi xem lại không chính thức, chẳng hạn như những
đánh giá đồng cấp, nhưng những người hành nghề phải chắc chắn rằng đánh giá đang diễn ra
và có kết quả trong việc tìm kiếm các lỗi thiết kế.

Đánh giá chính thức có thể được chủ trì bởi quản lý chất lượng phần mềm, mặc dù một số
tổ chức thấy tốt hơn nếu có người từ dự án làm chủ tịch. Những người thực hiện chất lượng
phần mềm có trách nhiệm tham dự các cuộc đánh giá chính thức và báo cáo về các hành động
của họ. Người kiểm tra chất lượng phần mềm cũng chịu trách nhiệm đảm bảo rằng bất kỳ và
tất cả các mục hành động phản ánh từ các đánh giá được giải quyết đầy đủ và đóng lại và báo
cáo đầy đủ được nộp cho ban quản lý để thực hiện bất kỳ hành động quản lý nào có thể cần
thiết.

Đặc điểm kỹ thuật thiết kế sơ bộ

Thiết kế sơ bộ (đôi khi được gọi là chức năng, kiến trúc hoặc thiết kế bên ngoài) cung cấp
phân tích ban đầu của các yêu cầu thành nhóm chức năng cho những nỗ lực thiết kế hơn nữa.
Mỗi nhóm chức năng trình bày lại một phần chính của hệ thống phần mềm tổng thể. Sơ bộ
thiết kế phải chỉ rõ cách tiếp cận được thực hiện để thực hiện chức năng, yêu cầu cơ sở dữ
liệu và giao diện với các nhóm chức năng khác trong hệ thống. Nó cũng phải chỉ định các
giao diện với thế giới ngoại lai, chẳng hạn như thiết bị đầu cuối, máy tính khác, hệ thống
phần mềm khác, và kể từ đó trở đi. Phụ lục E trình bày định dạng mẫu của thiết kế sơ bộ tài
liệu.

Xây dựng để thiết kế

Thiết kế chi tiết là một tuyên bố cụ thể về cách từng phần của thiết kế sơ bộ sẽ được thực
hiện trong mã. Các thiết kế chi tiết thường được gọi là đặc tả xây dựng, vì nó là đầu vào cho
chương trình nhân viên dịch sang ngôn ngữ biên dịch để thực hiện trên máy tính mục tiêu.
Tài liệu này phải mô tả hoàn toàn thiết kế để rằng các lập trình viên không ở vào vị trí phải
đưa ra các quyết định thiết kế khi họ thực hiện bản dịch sang ngôn ngữ trình biên dịch. Một
ví dụ về một định dạng cho một tài liệu thiết kế chi tiết được nêu trong Phụ lục F.

Thiết kế như xây dựng

Một phiên bản cuối cùng của tài liệu thiết kế chi tiết cần được chuẩn bị sau khi việc hoàn
thành các quá trình mã hóa và thử nghiệm. Điều này thường được gọi là thiết kế đã xây dựng
hoặc mô tả thiết kế và đại diện cho tuyên bố của thiết kế đã thực sự được dịch thành mã. Đây
là một tài liệu quan trọng cho những người bảo trì hệ thống phần mềm trong tương lai. Nó
đóng vai trò là đường cơ sở sản xuất mà từ đó mọi thay đổi sẽ được thực hiện để sửa chữa các
khuyết tật được tìm thấy trong hoạt động của hệ thống và để bổ sung các cải tiến cho phần
mềm khi chúng trở nên cần thiết.

8.2.3 Các tài liệu phát triển khác

Hệ thống càng lớn thì càng có nhiều tài liệu phù hợp. Cơ sở dữ liệu tài liệu thiết kế và
thiết kế giao diện có thể cần thiết.

Một số tài liệu không phải lúc nào cũng được yêu cầu dưới dạng các thực thể riêng biệt.
Nội dung tái diễn của thiết kế cơ sở dữ liệu và tài liệu thiết kế giao diện có thể được đưa vào
các tài liệu thiết kế sơ bộ và chi tiết cho các hệ thống nhỏ hoặc không đơn giản.

Vai trò của người thực hành chất lượng phần mềm rất giống nhau cho dù cơ sở dữ liệu
hoặc các cuộc thảo luận về giao diện là một phần của các tài liệu lớn hơn hoặc các tập tin đối
với chính nó. Những người thực hành chất lượng phần mềm vẫn phải chắc chắn đáp ứng các
tiêu chuẩn về định dạng và nội dung. Họ cũng sẽ đảm bảo rằng tiêu chí tài liệu được đáp ứng
và thông tin phù hợp với chính nó và giữa các tài liệu.

Sẽ có những dự án cần tài liệu đặc biệt. Hai điều thường nảy sinh nhất là những dự án có
sự liên kết giữa con người hoặc phức tạp khuôn mặt và những khuôn mặt liên quan đến sự
phát triển hoặc tương tác quan trọng với một cơ sở dữ liệu. Khi các giao diện của hệ thống,
trong hệ thống phần mềm hoặc với thế giới bên ngoài, nhiều hoặc phức tạp, cần xem xét
chuẩn bị trước các yêu cầu về giao diện và đặc điểm thiết kế giao diện. Các thông số kỹ thuật
này có thể loại bỏ sự hiểu lầm về các giao diện phát sinh khi mỗi giao diện được mô tả từ một
phía trong một tài liệu và các mặt khác trong tài liệu khác. Bằng cách kết hợp tất cả các khía
cạnh của mỗi giao diện ở một nơi duy nhất, tất cả các bên đều có thể xem toàn bộ mô tả của
các mặt.

Thông số kỹ thuật cơ sở dữ liệu là cần thiết khi hệ thống đang phát triển sáng tạo hoặc gây
ra sửa đổi đáng kể cho (các) cơ sở dữ liệu. Thậm chí, một cơ sở dữ liệu mới hoặc sửa đổi có
độ biến đổi cao không phải là trường hợp, sự tương tự đáng kể với (các) cơ sở dữ liệu hiện tại
có thể được hưởng lợi từ một tài liệu cơ sở dữ liệu chuyên biệt.

Cần nhớ rằng mục đích của tài liệu là để ghi lại cách đáp ứng các yêu cầu của người dùng
hoặc khách hàng và để đảm bảo rằng giải pháp chính xác đang được phát triển và triển khai.

8.3 Tài liệu kiểm tra

Tài liệu kiểm tra bao gồm tất cả các tài liệu chương trình kiểm tra từ tổng thể kế hoạch thử
nghiệm thông qua báo cáo thử nghiệm cuối cùng. Tài liệu kiểm tra là một song song nỗ lực,
như trong Hình 8.1. Nó bắt đầu với trạng thái yêu cầu ban đầu, giống như tài liệu phát triển.
Trên cơ sở các yêu cầu, kế hoạch kiểm tra, trường hợp, kịch bản, thủ tục, dữ liệu và tài liệu
kết quả được tạo ra khi SDLC tiến triển. (Chương 4 bổ sung cho chủ đề của tài liệu kiểm tra
một cách đầy đủ hơn). Kiểm tra là tài liệu- được đề cập thông qua một loạt các tài liệu ngày
càng cụ thể, bắt đầu bằng kế hoạch thử nghiệm và bao gồm các trường hợp thử nghiệm, kịch
bản thử nghiệm, quy trình thử nghiệm chi tiết, dữ liệu thử nghiệm và kết quả thử nghiệm. Tài
liệu kiểm tra mô tả chuỗi sự kiện mà qua đó, phần mềm được chứng minh sự tuân thủ cuối
cùng với các yêu cầu của nó.
Hình 8.1Kiểm tra phần mềm phát triển.

Người thực hành chất lượng phần mềm đóng một vai trò quan trọng trong toàn bộ quá trình
kiểm tra quá trình. Trên thực tế, họ có thể thực sự tiến hành thử nghiệm khi chấp nhận cấp
độ. Tuy nhiên, người kiểm tra chất lượng phần mềm phải xem xét cẩn thận tất cả chương
trình thử nghiệm để đảm bảo rằng nó đủ để thực hiện phần mềm trong một cách sẽ tối đa hóa
khả năng tìm ra khiếm khuyết của các bài kiểm tra. Thành viên lại rằng mục tiêu của kiểm
tra là tìm ra các khuyết tật. Chất lượng phần mềm các học viên phải chắc chắn rằng mục tiêu
đang được đáp ứng. Mục tiêu thứ hai là chứng minh rằng phần mềm hoạt động như các yêu
cầu đã được phê duyệt sự ủy thác. Những người thực hành chất lượng phần mềm, cùng với
người dùng hoặc khách hàng, phải xem xét kiểm tra và chắc chắn liệu phần mềm có hoạt
động như cần thiết. Khi các thiếu sót được phát hiện, trong các bài kiểm tra hoặc trong kết
quả,người kiểm tra chất lượng phần mềm có trách nhiệm đảm bảo rằng ban quản lý nhận ra
những khiếm khuyết để thực hiện hành động thích hợp.

8.3.1 Kế hoạch thử nghiệm

Như thể hiện trong Hình 8.1 (và trong Hình 4.3), tài liệu kiểm tra bắt đầu với kế hoạch thử
nghiệm (xem Phụ lục G), dựa trên các yêu cầu ban đầu. Trên thực tế, việc lập kế hoạch thử
nghiệm ban đầu được thực hiện trong giai đoạn yêu cầu. Điều đó không chỉ giúp các hoạt
động thử nghiệm bắt đầu sớm mà còn giúp đảm bảo khả năng đo lường và khả năng kiểm tra
của các yêu cầu bản thân. Kế hoạch kiểm tra sẽ phát triển và phát triển, giống như các yêu
cầu ngày càng tăng và phát triển, trong suốt vòng đời phát triển, nhưng điều quan trọng là
phải-gin vào thời điểm này để bắt kịp với sự phát triển của mã. Kế hoạch là được tạo ra cho
các công cụ kiểm tra dự kiến, trình tạo dữ liệu, trình mô phỏng, v.v...được dự đoán là cần
thiết.

8.3.2 Kiểm tra thử nghiệm

Khi thiết kế bắt đầu hoàn thiện và các chức năng được xác định, các trường hợp thử
nghiệm (xem Phụ lục H) được xác định tương ứng. Những nhóm cá nhân này các bài kiểm
tra sẽ được áp dụng cho các phần chính của phần mềm. Họ thường dựa trên các nhóm yêu
cầu hợp lý giống như cách thiết kế chức năng được tiếp cận. Các kịch bản thử nghiệm là tập
hợp con tùy chọn của các trường hợp thử nghiệm. Chúng cung cấp cho việc đơn giản hóa các
trường hợp thử nghiệm.

8.3.3 Dữ liệu thử nghiệm

 Các yêu cầu về dữ liệu thử nghiệm ban đầu cũng được xác định tại thời điểm này. Dữ liệu
kiểm tra phải được cung cấp, không phải để cho thấy rằng phần mềm hoạt động như khi nó
được viết, nhưng nó hoạt động như dự định của các yêu cầu. Điều đó có nghĩa là dữ liệu thử
nghiệm phải bao gồm một loạt các giá trị cả hợp pháp và bất hợp pháp càng rộng càng
tốt.Các giá trị danh nghĩa, như được quy định trong các tài liệu thiết kế khác nhau, sẽ chỉ hiển
thị rằng phần mềm đáp ứng các điều kiện danh nghĩa. Đối tượng của thử nghiệm- à để phát
hiện ra các khiếm khuyết trong phần mềm, vì vậy dữ liệu kiểm tra phải được cẩn thận được
chọn để trình bày các đầu vào bất thường và không chính xác cũng như các đầu vào dự kiến
để xác định phản ứng của phần mềm đối với điều kiện sai lầm.

8.3.4 Quy trình thử nghiệm

Khi tiến trình thiết kế và mã hóa, các thủ tục kiểm tra (xem Hình 4.4) được thực hiện trước
ngang ngửa. Các thủ tục kiểm tra là các hành động từng bước được thực hiện trong mỗi bài
kiểm tra. Mọi hành động của nhà điều hành, mọi mục nhập dữ liệu và mọi hành động dự kiến
tài trợ được chỉ định trong một trình tự các bước cho một bài kiểm tra nhất định. Theo cách
đó, điều kiện chính xác của thử nghiệm được kiểm soát, và mỗi đầu ra thực tế hoặc tài trợ của
phần mềm có thể được so sánh với kết quả mong đợi. Mỗi sự khác biệt giữa kết quả dự kiến
và kết quả thực tế được ghi lại như một xác suất khiếm khuyết có thể xảy ra và được phân
tích để xác định xem phần mềm có đang hoạt động hay không theo yêu cầu.

8.3.5 Báo cáo thử nghiệm

Các báo cáo thử nghiệm (xem Phụ lục I) ghi lại những gì thực sự xảy ra trong mỗi bài
kiểm tra. Họ chỉ rõ các kết quả mong đợi và thực tế và kết luận rút ra từ các kết quả. Sự bất
thường và sự sắp xếp cuối cùng của những lời nói dối anoma được ghi lại. Báo cáo thử
nghiệm là yếu tố quan trọng để xác định thời điểm thử nghiệm đạt được kết luận có lợi.

8.4 Tài liệu người dùng

Phần mềm tốt nhất sẽ không hữu ích nếu người dùng cuối không biết cách sử dụng nó. Tài
liệu hướng dẫn sử dụng có thể bao gồm, ngoài các hướng dẫn sử dụng, bảo trì, nhà điều hành,
đào tạo, và các tài liệu dành riêng cho dự án khác, chẳng hạn như tài liệu mô tả phiên bản.
Tài liệu người dùng cung cấp hướng dẫn-đối với người dùng cuối của hệ thống phần mềm.
Nó giải quyết việc chuẩn bị thích hợp- và trình bày các đầu vào, hướng dẫn vận hành và
hướng dẫn cho việc giải thích dữ liệu đầu ra. Nó cũng có thể trình bày các hướng dẫn vận
hành, nhu cầu đào tạo, mô tả về sự khác biệt giữa một phiên bản với tiếp theo, và thông tin
bảo trì.Tài liệu người dùng hiển thị và cho người dùng biết cách sử dụng hệ thống phần mềm.
Nó sẽ thảo luận về hệ thống, xác định định dạng và lều của các đầu vào và mô tả các đầu ra là
kết quả của hệ thống chế biến.

Người hành nghề chất lượng phần mềm phải đóng vai trò tích cực trong việc xem xét và
đánh giá tài liệu người dùng. Nếu phần mềm không thể được sử dụng một cách dễ dàng, thì
điều quan trọng là nó có phải là một sản phẩm “chất lượng” hay không. Tài liệu người dùng
phải sử dụng đúng cách có thể. Người hành nghề chất lượng phần mềm nên chạy thử hướng
dẫn sử dụng để xem hướng dẫn có làm được không có thể thực sự sử dụng hệ thống như nó
đã được sử dụng. Việc đó có thể đôi khi được thực hiện là một phần của thử nghiệm nghiệm
thu hoặc trình diễn cuối cùng hoặc có thể là một bài tập được tiến hành riêng lẻ. Điều quan
trọng là hoàn thành là xác minh rằng tài liệu người dùng thực hiện vận hành và sử dụng phần
mềm đúng cách có thể.

8.4.1 Yêu cầu đầu vào

Đối với đầu vào, tài liệu người dùng sẽ cho người dùng biết hệ thống yêu cầu thông tin gì.
Nó sẽ trình bày các định dạng dữ liệu, phạm vi pháp lý giá trị, lịch trình của đầu vào và thông
tin khác liên quan đến đầu vào dữ liệu. Những thứ như phương thức nhập (ví dụ: thanh ghi
phần cứng, bàn phím mục nhập, dữ liệu từ các hệ thống khác), nơi dữ liệu sẽ được gửi (ví dụ:
nhập công việc từ xa, thông qua một thiết bị đầu cuối), khi đầu vào là bắt buộc (ví dụ: thứ
Năm hàng tuần, khi được nhắc) và các thông tin thích hợp khác cụ thể cho hệ thống cụ thể
phải có sẵn cho người dùng trong hướng dẫn sử dụng.

8.4.2 Mô tả đầu ra

Một phần quan trọng khác của tài liệu người dùng là hướng dẫn về cách để diễn giải kết
quả của quá trình xử lý. Mô tả đầy đủ của tất cả các đầu ra là cần thiết. Tất nhiên, tài liệu
phải có hướng dẫn về làm thế nào để hiểu các màn hình hoặc bản in được tạo ra. Ngoài ra,
nó phải cung cấp một mô tả đầy đủ và dễ hiểu về tất cả các kết quả đầu ra không chuẩn,
chẳng hạn như thông báo lỗi, tạm dừng bất thường, mất hệ thống , v.v. Mỗi tình huống hoặc
kết quả đầu ra này sẽ được mô tả và câu trả lời thích hợp được viết ra. Nếu hệ thống đang
chạy trong một trung tâm dữ liệu trung tâm hoặc trung tâm, các hướng dẫn về việc phân phối
đầu ra bản in cứng sẽ được cung cấp.

8.4.3 Hướng dẫn vận hành

 Tài liệu người dùng cũng nên bao gồm các hướng dẫn vận hành như thông tin người dùng
thuần túy; nghĩa là, nó phải chứa chi tiết về cách hành động đồng minh làm cho hệ thống
hoạt động. Thông tin như cách tải hệ thống, phương tiện lưu trữ nào được yêu cầu, các thiết
bị ngoại vi đặc biệt như tốc độ cao máy in hoặc thiết bị lưu trữ lớn sẽ trực tuyến và cách đưa
hệ thống ngừng hoạt động khi quá trình xử lý hoàn tất có thể được đưa vào hoạt động- của
người hướng dẫn. Cho dù thông tin này có trong hướng dẫn sử dụng hay trong một tài liệu
riêng biệt thường là một chức năng về kích thước của hệ thống và nơi nó được chạy (ví dụ:
trên máy tính để bàn hoặc trong trung tâm dữ liệu trung tâm). Một số cài đặt có thể có các
tiêu chuẩn tài liệu chỉ định nơi này trong- sự hình thành sẽ được cung cấp.

Tài liệu hướng dẫn vận hành hoặc tài liệu tương tự thường cần thiết cho các hệ thống tuân
thủ yêu cầu sự tham gia của nhân viên trung tâm máy tính. Sự tham gia này có thể là việc gắn
băng và gói đĩa, xử lý các biểu mẫu hoặc báo cáo đầu ra, trình tự của một số hệ thống thành
lệnh thi hành, và như vậy. Nhiều hệ thống tự cung tự cấp một khi chúng được bắt đầu. Trong
những trường hợp đó, có thể có ít hoặc không có hướng dẫn về người vận hành. Tuy nhiên,
các hệ thống lớn hơn có thể biện minh cho một sổ tay vận hành riêng để cung cấp thông tin
chi tiết liên quan đến hoạt động của hệ thống phần mềm.

Người kiểm tra chất lượng phần mềm có trách nhiệm xem xét các tài liệu của người điều
hành về định dạng và nội dung yêu cầu cả ở lần phát hành đầu tiên và trong các giai đoạn vận
hành và bảo trì của SLC.

8.4.4 Bảo trì

Tài liệu bảo trì tốt giúp phần mềm tiếp tục chạy và cập nhật. Công cụ chính của người bảo
trì phần mềm là phần thân của tài liệu phần mềm. Nếu không có tài liệu rõ ràng và đầy đủ về
phần mềm, người bảo trì phải tạo lại dữ liệu mà họ sẽ làm cơ sở cho các hành động khởi
động và sửa chữa. Tất nhiên, điều quan trọng nhất tài liệu là danh sách mã nguồn và mã đối
tượng tương ứng của phần mềm. Nếu không có điều đó, người bảo trì phải làm việc ngược
lại từ mã đối tượng để tạo lại mã nguồn hoặc làm việc trong chính mã đối tượng.

Tài liệu quan trọng nhất tiếp theo là mô tả thiết kế cuối cùng (hoặc như - được xây dựng)
tài liệu. Tài liệu này, hoặc tài liệu tương đương, cùng với các yêu cầu cập nhật và lưu đồ hoặc
sơ đồ xử lý, giải thích người bảo trì chính xác những gì phần mềm phải chứa và nó được cấu
tạo như thế nào. Chính với các tài liệu này mà các nhà bảo trì nghiên cứu các báo cáo và yêu
cầu cải tiến hệ thống. Các sơ đồ dòng chảy (trong bất kỳ hình thức nào là tiêu chuẩn cho cài
đặt cụ thể) và tài liệu thiết kế trình bày thiết kế và triển khai hệ thống phần mềm và mô tả
những gì nó làm và như thế nào. Các yêu cầu mô tả toàn bộ môi trường mà thay đổi phải phù
hợp.

Phần bảo trì của tài liệu người dùng chứa thông tin tầm quan trọng đối với những người
hoặc những người phải duy trì hệ thống kho bãi. Phần này thường chứa thông tin thiết kế
hoàn thiện, mô tả về các sửa đổi triển khai theo từng giai đoạn được thực hiện và đang chờ xử
lý, hồ sơ về những thay đổi phần mềm được thực hiện kể từ khi triển khai và những thứ
tương tự. Bất kì- điều đó sẽ làm cho công việc của người bảo trì phần mềm dễ dàng hơn là
phù hợp để đưa vào phần bảo trì của tài liệu người dùng.

Trong việc đánh giá tài liệu bảo trì, chất lượng phần mềm người hành nghề phải nhạy cảm
với môi trường của người bảo trì và các tài liệu cần liên quan. Việc xem xét tài liệu bảo trì
cần có sự tham gia và chịu ảnh hưởng của các đại diện của tổ chức bảo trì. Khi đó, những
khiếm khuyết được ghi nhận trong tài liệu bảo trì sẽ được đưa ra cho ban giám đốc để độ
phân giải.

8.5 Tài liệu đào tạo

Tài liệu đào tạo, khi được yêu cầu, sẽ đề cập đến cả nhà phát triển và đào tạo người dùng.
Hệ thống càng trở nên phức tạp và liên quan, nhiều khả năng là sẽ có những người làm việc
với nó, những người không có kinh nghiệm trước đây trong một hoặc nhiều khía cạnh của
nhiệm vụ của họ. Ngôn ngữ, chương trình- môi trường giao phối và các môn kỹ thuật là tất cả
các lĩnh vực, những người phát triển có thể cần giáo dục và đào tạo mới hoặc cao hơn. Tương
tự như vậy, khách hàng hoặc người sử dụng hệ thống có thể cần được đào tạo.

Tài liệu đào tạo nên được chuẩn bị bất cứ lúc nào có nhu cầu để đào tạo chính thức hoặc
không chính thức rộng rãi. Định dạng và nội dung của tài liệu sẽ thay đổi tùy theo nhu cầu và
ứng dụng. Người thực hành chất lượng phần mềm nên đánh giá nhà phát triển và người dùng
nhu cầu đào tạo và đảm bảo rằng tài liệu đào tạo phù hợp, được cung cấp, được xem xét, tuân
thủ các tiêu chuẩn hiện hành và áp dụng cho dự án. Những người hành nghề chất lượng phần
mềm có thể sẽ không thực hiện việc đào tạo hoặc viết các tài liệu, nhưng họ phải làm cho ban
quản lý biết về bất kỳ nhu cầu đào tạo.

8.6 Documentation standards

Có rất nhiều tiêu chuẩn tài liệu. Trong nhiều tổ chức và công ty so sánh, điều đầu tiên được
tiêu chuẩn hóa là tài liệu. Đó có thể là do tài liệu là hoạt động ít được yêu thích nhất hầu hết
các nhà phát triển phần mềm. Nó là sản phẩm duy nhất được sản xuất bởi một phần lớn SLC
và thường là đối tượng của hầu hết các khiếu nại về hệ thống. Hoặc có lẽ nó là cách dễ dàng
nhất để chuẩn hóa vì có rất nhiều các ví dụ tiêu chuẩn để lựa chọn.

Các tổ chức trong ngành đã xuất bản hoặc đang phát triển các tiêu chuẩn cho tài liệu,
không chỉ trong lĩnh vực phần mềm mà còn (và lâu hơn nữa thời gian) trong lĩnh vực phần
cứng. Ví dụ, IEEE có các tiêu chuẩn cho một số tài liệu phát triển phần mềm (xem Bảng 2.1).
Các tiêu chuẩn này đại diện cho sự đồng thuận của một phần lớn ngành công nghiệp máy
tính. Các DoD và các cơ quan chính phủ khác, chẳng hạn như NIST, đã ban hành các tiêu
chuẩn tài liệu hướng dẫn cho các ứng dụng chung và để sử dụng trong các tình huống cụ thể
hoặc môi trường máy tính đặc biệt.

Trong một số trường hợp, các chất chuẩn được chuẩn bị bên ngoài có thể được sử dụng
trực tiếp. Ngoài ra, chúng có thể được sửa đổi để phù hợp với nhu cầu của một tổ chức cá
nhân. Một số tiêu chuẩn thường bao gồm nội dung và hướng dẫn định dạng rất cụ thể, do đó
rất ít để lại cho tác giả ngoại trừ thông tin được lập thành tài liệu. Những người khác cung
cấp các yêu cầu hoặc hướng dẫn chung về m ột tổ chức có thể xây dựng. Một số công ty sẵn
sàng chia sẻ các tiêu chuẩn cố vấn tài liệu của họ hoặc ít nhất là đưa ra hướng dẫn trong lĩnh
vực này.

Như trong trường hợp của các tiêu chuẩn nói chung (xem Phần 2.2), mỗi công ty hoặc tổ
chức phải phát triển hoặc điều chỉnh các tiêu chuẩn tài liệu để đáp ứng nhu cầu cụ thể của
riêng mình. Các tiêu chuẩn tài liệu, giống như bất kỳ thứ gì khác, phải phục vụ người dùng
các tiêu chuẩn đó, nếu không họ sẽ tuân theo một cách không phù hợp hoặc cùng nhau bỏ qua
tất cả. Cơ quan quản lý chất lượng phần mềm có trách nhiệm xem xét các tiêu chuẩn tài liệu
theo định kỳ để đảm bảo chúng được cập nhật và phù hợp với tổ chức. Khi chúng trở nên
không phù hợp hoặc không phù hợp, người hành nghề nên nhắc người điều phối tiêu chuẩn
thực hiện các biện pháp để cải thiện chúng.

8.7 Tóm tắt

Tài liệu phần mềm bao gồm quản lý, phát triển, kiểm tra, và tài liệu người dùng. Nó được
thiết kế để theo dõi sự phát triển của phần mềm- khi nó tiến triển thông qua SLC. Mỗi giai
đoạn SDLC có một sản phẩm hoặc sản phẩm, là tuyên bố của giải pháp ngày càng hoàn thiện
cho nhu cầu của người dùng khi quá trình phát triển tiếp tục.

Tài liệu giống như các điểm đánh dấu dọc theo đường cao tốc. Nhìn về phía trước, nó
cung cấp một con đường để đi theo hướng đến đích. Nhìn lại, nó cung cấp một kỷ lục về
chuyến đi cho đến nay. Mỗi giai đoạn của SDLC chuẩn bị “chỉ thị” cho giai đoạn tiếp theo
dưới dạng một số loại tài liệu. Những các tài liệu tương tự là bản ghi lại những gì đã xảy ra
trong giai đoạn chính nó.

SDP là tài liệu đưa ra cách tiếp cận quản lý đối với dự án phần mềm. Ở dạng cơ bản nhất,
nó sẽ bao gồm lịch trình và nhu cầu tài nguyên cho dự án. Các phương pháp, yêu cầu đánh
vào nhà sản xuất, các yêu cầu theo hợp đồng và các công cụ được sử dụng cho CM phần
mềm cần được xác định và giải thích. SQSP giải quyết các hoạt động được thực hiện trên dự
án trong hỗ trợ nhiệm vụ cho phần mềm chất lượng. Tất cả các hoạt động được hoàn thành
trong lĩnh vực chất lượng phần mềm nên nhận được cùng một nhân sự, tài nguyên, và lên lịch
thảo luận như trong SDP tổng thể. Dù định dạng của SQSP, điều quan trọng là tài liệu này
(hoặc thông tin của nó nếu ở tài liệu) hoàn chỉnh và được phê duyệt bởi ban quản lý và các
nhà phát triển.

Tài liệu yêu cầu là nền tảng của tất cả tài liệu phần mềm. Các tài liệu thiết kế sơ bộ và chi
tiết mô tả cách phần mềm tiếp cận và đáp ứng từng yêu cầu. Sơ bộ thiết kế cung cấp sự phân
tích ban đầu của các yêu cầu thành chức năng các nhóm nỗ lực thiết kế hơn nữa. Thiết kế chi
tiết thường được gọi là đặc điểm kỹ thuật xây dựng. Nó là đầu vào cho nhân viên lập trình để
chuyển đổi sang ngôn ngữ trình biên dịch để thực hiện trên máy tính đích. Phiên bản cuối
cùng của thiết kế chi tiết đôi khi được gọi là tài liệu, vì nó mô tả phần mềm như nó thực sự đã
được phân phối.

Tài liệu kiểm tra bao gồm tất cả tài liệu chương trình kiểm tra từ kế hoạch kiểm tra tổng
thể thông qua báo cáo kiểm tra cuối cùng.

Tài liệu hướng dẫn người dùng cho người dùng biết cách sử dụng hệ thống phần mềm.
Tài liệu người dùng có thể bao gồm các hướng dẫn của người vận hành như cũng như thông
tin hướng tới người dùng nghiêm ngặt.

Hệ thống càng lớn thì càng có nhiều tài liệu phù hợp. Dữ liệu-tài liệu thiết kế cơ sở và
thiết kế giao diện có thể cần thiết. Bảo trì và đào tạo có thể xứng đáng được đối xử riêng biệt
và rộng rãi. Cuối cùng, ở đó có thể cần một sổ tay hướng dẫn vận hành riêng biệt.

8.8 Bước tiếp theo

Rất ít văn bản đã được viết về tài liệu phần mềm như một phụ cho chính nó. Tuy nhiên,
vì tất cả các quy trình phát triển phần mềm, kiểm tra và quản lý chính phụ thuộc vào các yêu
cầu, bạn có thể bắt đầu với Phần mềm. Yêu cầu: Phân tích và đặc điểm kỹ thuật của Alan M.
Davis (Englewood Vách đá, NJ: Prentice-Hall, 1990).

Đọc thêm

 Buckley, F. J., Triển khai Thực hành Kỹ thuật Phần mềm, New York:John Wiley &
Sons, 1989.
 Hướng dẫn Quốc tế, Yêu cầu Chất lượng — GPP 217, Hướng dẫn:Quốc tế, Chicago,
IL, 1989.
 Hatley, Pirbhai, Chiến lược cho đặc điểm hệ thống thời gian thực, New York:Nhà
Dorset, 1987.
 Shumate, Ken và Marilyn Keller, Đặc điểm kỹ thuật và thiết kế phần mềm: Phương
pháp tiếp cận có kỷ luật cho các hệ thống thời gian thực, New York: John Wiley &
Các con trai, 1992.
 Vincent, James, Albert Waters và John Sinclair, Chất lượng phần mềm
 Đảm bảo: Tập 1, Thực hành và Thực hiện, Vách đá Englewood, NJ: Prentice-Hall,
1988.