Bai-tap-3

Báo cáo bài tập tuần 3 Môn : Phân tích yêu cầu phần mềm

Nhóm sinh viên thực hiện (Nhóm 10) : Nguyễn Văn Thanh (20122401)Nguyễn Anh Tuấn (20122687)Nguyễn Minh Tuấn (20122698)Đỗ Đức Minh (20122073)

Lớp : PTYCPM 20141

1Chương 7. Quản lý yêu cầu

N i dungộChương 7. Quản lý yêu cầu......................................................................................2

7.1. Nền tảng........................................................................................................2

7.2. Quản lý thay đổi............................................................................................3

7.3. Hoạt đổng quả lý yêu cầu thường xuyên......................................................7

7.4. Yêu cầu truy xuất nguồn gốc.......................................................................10

7.5. Phép đo và số liệu.......................................................................................15

7.6: Khả năng mở rộng.......................................................................................18

7.7 Tạo một quy trình quản lý yêu cầu...............................................................18

7.8. Tiết kiệm đo lường với các tiến trình RE.....................................................20

7.9 Các vấn đề về tổ chức quản lý ảnh hưởng đến các yêu cầu.........................22

7.10. Lời khuyên khi quản lý yêu cầu.................................................................27

7.11. Tóm tắt......................................................................................................29

7.12. Câu hỏi thảo luận......................................................................................29

Chương 8: Kiểm thử hệ thống hướng yêu cầu......................................................30

8.1 Nền tảng.......................................................................................................30

8.2 Đầu vào yêu cầu kỹ thuật để kiểm thử.........................................................32

8.3 Mô hinh cơ bản kiểm thử.............................................................................33

8.4 Kiểm tra hiệu suất và khả năng mở rộng các yêu cầu..................................41

8.5 Các quy tắc ngón tay cái/ thực tiễn tốt nhất................................................42

8.6 Tóm tắt.........................................................................................................45

8.7 Câu hỏi thảo luận.........................................................................................45

Phân tích yêu cầu phần mềm – Nhóm 10


Ch ng 7. Qu n lý yêu c uươ ả ầ

Chương này giới thiệu và diễn giải một số quản lý yêu cầu trong thực hành đã được sử dụng trong các dự án lớn. Yêu cầu kỹ thuật là một hoạt động diễn ra liên tục, xuyên suốt vòng đời phát triển sản phẩm, và phải được quản lý một cách hiệu quả. Nội dung đó bao gồm thực hành trong truy xuất nguồn gốc, đo lường, quan thay đổi , tính chất lượng và tính mở rộng của quản lý yêu cầu.

7.1. N n t ngề ảKhi mà một dự án phát triển lớn dần về độ phức tạp, nhiều sản phẩm mới được phát hành tới thị trường với nhiều tính năng, sự quan trọng của những thực hành tốt trong việc quản lý yêu cầu cũng lớn dần. Yêu cầu phải được xác định, phân tích, tài liệu hóa và các tác tử phát triển phải được truy xuất đến các yêu cầu và mục tiêu kinh doanh ban đầu.

Mục đích của việc quản lý yêu cầu là quản lý tất cả yêu cầu của một dự án hay một sản phẩm và để xác định sự không phù hợp giữa các yêu cầu của một kế hoạch dự án hay sản phẩm công việc.

Chúng ta thảo luận trong Chương 2 việc sử dụng các mô hình yêu cầu kỹ thuật tạo tác như một trợ giúp trong việc xác định tích hợp công cụ và cách sử dụng. Các quá trình RE ảnh hưởng nhiều nhất bởi những kế hoạch như vậy là những người mà có liên quan với yêu cầu quản lý. Yêu cầu quản lý ( RM ) bao gồm một số hoạt động chính và một số ít hơn. Hơn nữa có sự chồng chéo đáng kể giữa một số hoạt động quản lý dự án như theo dõi và giám sát và yêu cầu quản lý hoạt động cung cấp một số mức độ minh bạch thành các nhiệm vụ yêu cầu kỹ thuật khác nhau. Yêu cầu quản lý làm cho các yêu cầu kỹ thuật có thể cho các dự án lớn và giúp giảm sự hỗn loạn của dự án. Phần còn lại của chương này được tổ chức như sau : lần đầu tiên một số các hoạt động quản lý yêu cầu quan trọng được mô tả; sau đó một số vấn đề liên quan đến các hoạt động này được thảo luận. Lời khuyên cho yêu cầu quản lý cũng được cung cấp ở cuối chương.



7.2. Qu n lý thay đ iả ổThay đổi chắc chắn sẽ xảy ra vì vậy chúng tôi phải lập kế hoạch để thay đổi các yêu cầu trong quá trình của một dự án phát triển cũng như sau khi sản phẩm được phát hành cho lĩnh vực này. Vì vậy chúng ta phải thiết lập các quy trình và các công cụ để quản lý các yêu cầu thay đổi.

Quản lý yêu cầu bao gồm sự kiểm soát phiên bản của tất cả các tác tử đó là nguồn của yêu cầu hoặc các sản phẩm của quá trình quản lý yêu cầu. Ví dụ về các tác tử sẽ được kiểm soát bao gồm :

Văn bản mã nguồn, hình ảnh Ghi nhớ, lịch gặp mặt Yêu cầu và yêu cầu từ các bên liên quan Tài liệu được sản xuất từ các yêu cầu bao gồm yêu cầu thiết kế và

thông số kỹ thuật kiểm thử

Có một số lượng lớn các phiên bản kiểm soát hoặc quản lý cấu hình công cụ có sẵn mà có thể được sử dụng để kiểm soát các yêu cầu hiện vật. Ban đầu yêu cầu sẽ dễ dàng và không chắc chắn. Trong khi phát hiện yêu cầu đang diễn ra đó là rất khó khăn để tạo ra một bộ phần nào ổn định các yêu cầu. Do đó một cơ sở thường được tạo ra khi gần kết thúc của giai đoạn yêu cầu gợi mở sau khi yêu cầu các bên liên quan đã được xem xét và thiết lập ban đầu của các yêu cầu đã được tạo ra và được chấp thuận. Một yêu cầu cơ bản là tập hợp các tài liệu yêu cầu nguồn và tất cả các tài liệu có nguồn gốc từ các bộ các yêu cầu tại một điểm cụ thể trong thời gian. Tuy nhiên, nếu một nhà cung cấp được tiếp nhận các yêu cầu từ khách hàng như là một phần của một hợp đồng thương lượng, thì tập hợp các yêu cầu trong hợp đồng thường được coi là cơ sở ban đầu. Cho đến một đường cơ sở được tạo ra thay đổi để yêu cầu các bên liên quan và đánh giá của các yêu cầu tiềm năng làm cho nó khó khăn để theo dõi những thay đổi. Tuy nhiên một khi một đường cơ sở đã được thành lập, theo dõi các thay đổi đối với các yêu cầu trở thành bắt buộc.

Khái niệm “tính năng leo” được áp dụng khi có nhiều thay đổi nhỏ được phép nếu không kiểm soát hoặc xem xét chính thức. Thay đổi có thể ảnh hưởng nghiêm



trọng tới lợi nhuận và ngày giao hàng của một dự án hoặc sản phẩm. Để ngăn chặn điều này xảy ra những thay đổi được đề xuất phải được xem xét bởi một nhóm kiểm soát thường được gọi là một bảng điều khiển thay đổi (CCB). Vai trò của CCN là cung cấp một cơ chế kiểm soát để chắc chắn ràng mọi yêu cầu thay đổi đều được xem xét, phân quyền và phối hợp. thẩm quyền và phối hợp? . Các CCB xem xét các yêu cầu sửa đổi (MR) và sau khi xem xét các tác động của những thay đổi được đề xuất một số MR sẽ dẫn đến thay đổi yêu cầu hoặc các tác tử khác. Các CC B cũng tương tự với một hội đồng xét duyệt kỹ thuật (ERB) được sử dụng để xem xét đề nghị thay đổi để phù hợp với hình thức hoặc chức năng của các thành phần điện trong thiết kế và sản xuất thiết bị điện tử. Trong trường hợp này yêu cầu kỹ thuật thay đổi ( ECR) được thực hiện phân tích và một số các yêu cầu được cài đặt như một đơn đặt hàng kỹ thuật thay đổi (ECO)? Một bản tóm tắt của các thành phần ra quyết định quản lý yêu cầu thay đổi kỹ thuật được đưa ra trong Bảng 7.1.

Các mức độ của hình thức trong quản lý thay đổi , ví dụ sự hình thành của bất kỳ CCB - là một chức năng tự nhiên của các dự án, hợp động hoặc tương tự? Ví dụ, trong các dự án nghiên cứu, thay đổi thường xuyên đôi khi được dự kiến trước và do đó có thể đánh giá thường xuyên và không chính thức . Mặt khác, một số dự án đòi hỏi các phân phối các hệ thống cơ điện với các tính năng phần mềm và phần cứng được định nghĩa tốt ( ví dụ một hệ thống tín hiệu đường sắt, nơi tính năng thay đổi trái phép có thể có một tác động thảm khốc đến ngày giao hàng dự án), vậy nên các hệ thống này phải có quy trình CCB chính thức. Nhiều loại phân tích khác nhau được thực hiện bởi các thành viên của một ban kiểm soát thay đổi hoặc cán bộ quản lý dự án để hỗ trợ quản lý sự thay đổi . Chú ý rằng bất kỳ loại CCB nào cũng phân tích dựa trên cơ chế truy xuất nguồn gốc tại chỗ. Chúng sẽ được thảo luận trong phần tiếp theo. Một bản tóm tắt của các loại phân tích chủ yếu được thực hiện bởi các thành viên của CCB được đưa ra trong Bảng 7.2.

Thành phân thay đổi điều khiển ra quyết định

Mô tả

Tổng kết Quyết định xem có nên chấp nhận một đề xuất thay đổi đến hệ thống yêu cầu

Đầu vào Nhưng đề xuất thay đổi yêu cầu, bao



gồm các chỉnh sửa, bổ sungBước đi Xem xét sự va chạm của đề xuất thay

đổi, cước phí, sự phù hợpKhả năng giao hàng “Có”, “Không”, “Có” nhưng có sửa đổiTrách nhiệm Bảng kiểm soát thay đổi CCBNgười tham gia Người đề xuất và thành viên của CCBPhương thức Phân tích trao đổiCông cụ Công cụ cước phí, truy dấu, trao đổi

Bảng 7.1 Quản lý thay đổi yêu cầu kỹ thuật

Loại phân tích Mô tả Tiến trình hỗ trợPhân tích va chạm Lần sau các đường dẫn

chuyển đến, để trả lời câu hỏi : “Chuyện gì xảy ra nếu như cái này thay đổi ?”

Quản lý thay đổi

Phân tích nguồn gốc Lần theo các đường dẫn chuyển ra, để trả lời câu hỏi : “Tại sao cái này lại ở đây ?”

Phân tích sự phù hợp chi phí

Phân tích bao phủ Đếm số báo cáo có đường dẫn, để trả lời câu hỏi : “Tôi đã bao phủ mọi thứ chưa ? ”. Trong hầu hết trường hợp dùng để đo lường sự tiến triển

Kỹ thuật tổng quan, quản lý báo cáo

Bảng 7.2 Các loại phân tích RE chính sử dụng bởi một CCB

Phân tích va chạm

Mục tiêu của việc phân tích và chạm là xác định tài chính, tài nguyên và chi phí vật chất của các thay đổi yêu cầu hoặc tính năng mới. Để làm điều này, các thành viên của CCB (thường là các kiến trúc sư) hoặc phải truy vết từ các tính năng va chạm đến việc thiết kế hệ thống thật để xác định xem ý nghĩa, tầm quan trọng của bất



kỳ một thay đổi hoặc cải tiến nào, và từ đó suy ra chi phí và các mối nguy hiểm từ những sự thay đổi này.

Phân tích sự va chạm của những yêu cầu thay đổi yêu cầu việc truy dấu. Nếu như yêu cầu được phân tích là phi chức năng (ví dụ về tính hiệu suất,năng lực), thì sau đó những nỗ lực bổ sung có thể được yêu cầu để mô phỏng tác động của sự thay đổi được đề xuất để xác định xem nó có khả thi hay không.

Quản lý khách hàng và kiểm soát thay đổi

Một nhà phát triển phần mềm đã được gửi đến làm việc cài đặt trên một hệ thống điều khiển cho một dàn khoan dầu ngoài khơi. Trong khi các nhà phát triển đang ngồi tại một thiết bị đầu cuối để thực hiện cài đặt phần mềm, các đại diện khách hàng ngồi xuống bên cạnh anh ấy và hỏi một sự thay đổi cụ thể có tính khả thi. Các nhà phát triển đã trả lời rằng nó đã khả thi. Các khách hàng sau đó hỏi nó sẽ có chi phí bao nhiêu, và các nhà phát triển, không cho nó nhiều suy nghĩ, nói, "một vài ngày." Vài tuần sau đó người quản lý dự án đã nhận được thư của sự thấu hiểu từ các khách hàng nói rằng không có được thỏa thuận giữa đại diện của chúng tôi (nhà phát triển) và các khách hàng để thực hiện thay đổi không mất phí. Sau khi thực hiện một phân tích tác động, được xác định là chi phí của sự thay đổi sẽ hoàn toàn quét sạch các dự án. Các nhà phát triển hầu như không nhớ lại cuộc trò chuyện. Các cuộc thảo luận sôi nổi với các khách hàng xảy ra sau đó.

Phân tích nguồn gốc

Phân tích nguồn gốc là có liên quan với việc khám phá ra nguồn gốc của một chức năng, module, vv. Các mẫu thiết kế có liên quan được truy vết trở lại với yêu cầu ban đầu, và sau đó từ các yêu cầu đến yêu cầu của các bên liên quan (hoặc nhu cầu thị trường hoặc các mục tiêu kinh doanh) dẫn đến quyết định thêm các yêu cầu đối với sản phẩm. Ngoài ra, một thành phần sản phẩm hoặc yêu cầu thành phần được bắt nguồn từ lý do ban đầu để tạo ra nó. Nguồn gốc là cần thiết để hiểu lý do tại sao một tính năng hoặc chức năng trong một sản phẩm, mà nếu không có quyết định thông minh liên quan đến một sự thay đổi để yêu cầu không thể được thực hiện.Phân tích yêu cầu phần mềm – Nhóm 10


Phân tích bao phủ

Phân tích bao phủ đo tỷ lệ của các tính năng xác định với các tính năng trên sản phẩm thực tế. Nó được sử dụng để xác định xem các yêu cầu và tính năng có được thực hiện trong các sản phẩm hay không. Điều này được thực hiện bằng cách truy tìm từ hệ thống ban đầu (hoặc hợp đồng) yêu cầu trực tiếp với các trường hợp thử nghiệm. Lưu ý rằng các bài kiểm tra là cách tốt nhất để đo đạc hoàn chỉnh xem một thiết kế có bị bỏ xót hay không. Nếu một sản phẩm được đưa ra thị trường mà không có các tính năng được coi là quan trọng, nó có thể thất bại. Nếu sản phẩm đang được phân phối như một phần của hợp đồng, sau đó phân tích bao phủ được sử dụng để đo lường sự tuân thủ hợp đồng; ví dụ, những gì đã được thống nhất trên so với những gì hiện đang được giao. Các kiến trúc sư cũng có thể sử dụng phân tích bảo hiểm để trợ giúp việc phân tích tác động; đó là, chi phí làm cho một sự thay đổi có thể thấp hơn nếu thực hiện một tính năng sản phẩm vẫn chưa bắt đầu.

7.3. Ho t đ ng qu lý yêu c u th ng xuyênạ ổ ả ầ ườHoạt động quản lý yêu cầu thường xuyên là những hoạt động diễn ra trên hầu hết, nếu không phải là tất cả các dự án. Chúng có thể không liên quan nhiều đến những hướng dẫn nỗ lực, nhưng tùy thuộc vào tính chất của dự án, chúng có thể có vai trò rất quan trọng đến một kết quả tích cực.

Xác định các yêu cầu bất ổn

Biến động thường được đo bằng cách thu thập số liệu thống kê từ một hệ thống quản lý dữ liệu yêu cầu (RDMS). Một trong những lợi thế của một RDMS là mỗi khi một yêu cầu được thay đổi, quản lý phiên bản được mình bạch tới người dùng. Hầu hết, nếu không phải tất cả, các sản phẩm RDMS có thể cung cấp các báo cáo biến động. Nếu không, cũng không quả khó để tạo ra một báo cáo như vậy. Hai số liệu được quan tâm đặc biệt: sự biến động của các thiết lập yêu cầu tổng thể và sự biến động của các yêu cầu cá nhân. Một cơ sở thường không thể được thành lập cho đến khi biến động tổng hợp (số lượng yêu cầu thay đổi trên một đơn vị thời gian) giảm đến một giá trị đủ thấp mà các yêu cầu được coi là ổn định. Điểm mà tại đó xảy ra sẽ khác nhau với nhiều loại khác nhau của các dự án.



Hãy nhớ rằng một thước đo biến động chỉ có giá trị mà tất cả các yêu cầu phân tích đang ở mức độ tương tự (ví dụ, các yêu cầu của khách hàng ở mức cao).

Thiết lập các chính sách cho các tiến trình yêu cầu và hỗ trợ chúng những công cụ Workflow, Guidelines, Templates và Ví dụ

Một sai lầm phổ biến trong các dự án lớn là để bắt đầu thực hiện dự án mà không cần phải được xác định rõ quy trình, hướng dẫn, biểu mẫu, ví dụ, hoặc bộ công cụ tích hợp. Như đã được đề cập trong các chương trước, không có kế hoạch (hoặc thiếu sót trong kế hoăchj) có thể gây ra các vấn đề rất lớn. Ví dụ, không có ví dụ chất lượng tốt về yêu cầu và thông số kỹ thuật có thể dẫn đến các yêu cầu chất lượng thấp hơn và một số lớn ban đầu của các khuyết điểm. Hơn nữa, không có kế hoạch để tích hợp công cụ có thể dẫn đến một sự gia tăng nhanh chóng trong khối lượng công việc như số lượng các yêu cầu phát nổ trong quá trình phân tích. Tích hợp công cụ sẽ không được thảo luận chi tiết hơn ở đây, như một sự giàu có của thông tin có sẵn trong các văn bản và trên web, và việc thực hiện thực tế của chuỗi công cụ có thể được tổ chức hoặc dự án cụ thể. Chúng tôi gợi ý, ví dụ, rằng người đọc khám phá những giấy tờ trắng được công bố bởi các nhà cung cấp RDMS.

Ưu tiên yêu cầu

Ưu tiên và thứ hạng của các yêu cầu đã được thảo luận ngắn gọn trong các chương trước. Đây là một hoạt động không tầm thường đòi hỏi các quyết định như những gì các thuật toán sẽ được sử dụng, làm thế nào ưu tiên sẽ được tính toán và lưu trữ, các tác động phụ thuộc vào ưu tiên, và các vấn đề tuyên truyền (lên và xuống). Hơn nữa, bất kỳ công việc trong lĩnh vực này có thể sẽ được tên miền và tổ chức cụ thể. Nếu người đọc quan tâm đến chủ đề này, có rất nhiều tài liệu tốt có sẵn, ví dụ [Wiegers 2003].

Thiết lập và cập nhật các yêu cầu cơ bản

Như đã đề cập ở phần trên, một khi yêu cầu đã ổn định, một đường cơ sở được thành lập để thay đổi có thể được theo dõi. Hầu hết các công cụ RDMS có khả năng cho việc thiết lập đường cơ sở; Tuy nhiên, câu chuyện chưa kết thúc tại đây. Tài liệu bên ngoài, bản thiết kế, tiêu chuẩn của chính phủ, và như vậy cũng có thể Phân tích yêu cầu phần mềm – Nhóm 10


cần phải được tạo đường có sở. Ví dụ, một sự thay đổi trong một tiêu chuẩn chính phủ có thể dẫn đến một cuộc đánh giá lại các mối nguy hiểm, tiếp theo là yêu cầu giảm thiểu biến đổi hoặc bổ sung (xem Chương 11).

Tài liệu quyết định

Các tài liệu của các quyết định được yêu cầu cho cả dự án và yêu cầu quản lý. Khi có sự chồng chéo, nó có thể là cần thiết để có một chiến lược phối hợp. Đối với một ví dụ về những gì có thể xảy ra khi các quyết định không có tài liệu, xem thanh bên cạnh.

Lập kế hoạch và phân phối các yêu cầu để phát hành

Kế hoạch phát hành có thể là một hoạt động sản phẩm, dự án quản lý, tùy thuộc vào loại dự án. Trong quy hoạch, yêu cầu này được phân bổ cho các phiên bản để các phiên bản sản phẩm sẽ được phát hành một cách hiệu quả chi phí, tùy thuộc vào mục tiêu kinh doanh (ví dụ, dòng tiền dương, chặn trước sự cạnh tranh, vv). Nếu phụ thuộc yêu cầu và những dấu vết không được duy trì, lập kế hoạch có thể được khó khăn. Phân tích nguồn gốc có thể cần thiết để xác định đầu tư trở lại-trên-tiềm năng cho một tính năng, và rằng, lần lượt, đòi hỏi một chiến lược truy vết tại chỗ ổn định (xem phần tiếp theo).

Tại sao các quyết định nên được văn bản hóa

Trên một dự án nhà máy điện hạt nhân lớn trong những năm đầu thập niên 1990, một siêu máy tính đa xử lý đã được mua về. Bởi vì các tính năng dị biệt, khả năng tính toán đã bị vượt quá và một bộ xử lý phải được bổ sung thêm vào chi phí vài trăm ngàn đô la. Các khách hàng đã đồng ý trả cho sự thay đổi, thỏa thuận này đã được ghi vào biên bản cuộc họp dự án, yêu cầu thay đổi đã được ban hành để mua và cài đặt bộ xử lý bổ sung, và dự án này được tiến hành. Một năm sau đó, các khách hàng từ chối trả tiền cho các bộ vi xử lý, tuyên bố rằng các nhà cung cấp đã đồng ý trả tiền cho nó. Người quản lý dự án đã không giữ lại bản sao biên bản họp và kết quả là không thể tìm thấy một biên bản thỏa thuận. Ngay trước khi vấn đề đi đến kiện tụng, một bản sao của hợp đồng đã được tìm thấy trong một tập hợp các tập tin đã được về để được đưa ra, và khách hàng đồng ý trả toàn bộ chi phí nâng cấp.Phân tích yêu cầu phần mềm – Nhóm 10


7.4. Yêu c u truy xu t ngu n g cầ ấ ồ ốYêu cầu truy xuất nguồn gốc là khả năng mô tả và theo đuổi vòng đời của một yêu cầu, trong cả hai hướng về phía trước và phía sau; tức là, từ nguồn gốc của nó, thông qua phát triển và đặc điểm kỹ thuật của nó, để triển khai tiếp theo của nó và sử dụng, và qua những giai đoạn sàng lọc liên tục và lặp đi lặp lại trong bất kỳ các giai đoạn "[Gotel et al., 1994]. Chúng ta thảo luận về truy xuất nguồn gốc trong một số chi tiết ở đây, vì nó có thể là một công việc khó khăn, và nó có thể là quan trọng đối với sự thành công của một dự án.

Truy xuất nguồn gốc là chìa khóa đối với sự bao phủ, nguồn gốc, và phân tích tác động. Một yêu cầu có thể truy nguyên khi và chỉ khi nguồn gốc của mỗi yêu cầu thành phần của nó là rõ ràng; và liệu có một cơ chế mà làm cho nó khả thi để chỉ ra yêu cầu đó trong nỗ lực phát triển trong tương lai [IEEE 1998],

Một cách tiếp cận đề nghị để xác định một chiến lược truy xuất nguồn gốc là nhìn vào các vai trò trên các dự án và nhu cầu của họ, thực hiện cơ chế truy tìm chỉ khi cần thiết. Một số loại khác nhau của các bên liên quan được liệt kê trong Bảng 7.3, cùng với nhu cầu truy tìm của họ. Bởi vì nhu cầu thực tế khác nhau tùy thuộc vào loại hình tổ chức, nhu cầu truy tìm được định nghĩa của tổ chức, bởi vai trò.

Các dự án khác nhau sẽ có cơ chế theo dõi khác nhau vì các lý do khác nhau. Một người mua một sản phẩm hoặc dịch vụ (gọi chung là người mua) sẽ cần những dấu vết khác nhau từ người của các nhà cung cấp cung cấp các dịch vụ (gọi chung là nhà thầu). Hai bộ dấu vết lần lượt khác biệt với các loại dấu vết sử dụng bởi một tổ chức tổ phát triển để tạo ra một sản phẩm để đáp ứng mộtnhu cầu được xác định

Vai trò Nhà sản xuất Người mua Nhà thầu

Tiếp thị/Bán hàng Được phát triển thực hiện tất cả các tính năng? Những tính năng trong sản phẩm hiện tại? Trong mỗi bản phát

Có nhà thầu thực hiện hợp đồng? Có phải tất cả các tính năng sản phẩm của tôi một cách thích hợp và thực hiện hoạt

Có phải chúng ta phù hợp với hợp đồng? Từng khoản mục trong hợp đồng đã được thực hiện thành công cho mỗi trường



hành? động? hợp thử nghiệm?

Chuyên viên phân tích yêu cầu

Từng tính năng đã được khám phá đầy đủ? Những yêu cầu gì liên quan đến tính năng nào? các yêu cầu đã đủ chi tiết?

Tất cả các tính năng và các yêu cầu có liên quan trong các dấu vết RFP để hợp đồng? Liệu các nhà thầu hiểu từng tính năng? Có kế hoạch kiểm tra của nhà thầu có đúng không?

Có phải tất cả các yêu cầu trong hợp đồng khả thi và có thể kiểm chứng? Có bất kỳ trình điều khiển chi phí? Do các yêu cầu theo dõi để các trường hợp thử nghiệm? Có thử nghiệm bảo hiểm đầy đủ cho các giải pháp phân phối?

Kiến trúc sư Tại sao tính năng này cần thiết (ví dụ, ngữ cảnh là gì)? Chi phí để thay đổi một tính năng sản phẩm là gì? Có kiến trúc của các sản phẩm hỗ trợ đầy đủ tất cả các tính năng có trong phạm vi? Tác động của một tính năng hoặc thay đổi chế là gì?

Không thể áp dụng. Một người mua thường sẽ không có một kiến trúc sư.

Tất cả các yêu cầu hợp đồng theo dõi các yếu tố thiết kế phù hợp? Việc thiết kế đáp ứng đầy đủ các điều khoản của hợp đồng? Tác động của một yêu cầu thay đổi là gì?

Nhà phát triển Bối cảnh của yêu cầu này là gì? Tại sao nó là cần thiết? Làm 1 có đủ

Sản phẩm này sẽ được duy trì sau khi triển khai? Nếu cần thay đổi

Bối cảnh của yêu cầu này là gì? Tại sao nó là cần thiết? Làm 1 có đủ



thông tin để phát triển hoặc sản xuất không?

thì cơ chế dấu vết sẽ hỗ trợ việc phân tích tác động?

thông tin để phát triển hoặc sản xuất không?

Chuyên viên kiểm thử

Có phải tất cả các tính năng sản phẩm bao phủ bởi trường hợp thử nghiệm? Có phải tất cả các trường hợp kiểm thử truy nguyên các tính năng sản phẩm?

Chúng ta có thể theo dõi các yêu cầu hợp đồng để kiểm tra các trường hợp? Chúng ta có thể đảm bảo rằng chúng ta đang nhận các sản phẩm chúng tôi ký hợp đồng để nhận được? Chúng ta có thể phát hiện không tuân thủ?

Chúng ta có thể đảm bảo rằng chúng tôi có phù hợp với hợp đồng?

Các sản phẩm chuyển giao sẽ vượt qua một bài kiểm tra chấp nhận?

Bảng 7.3 Nhu cầu truy xuất nguồn gốc dựa trên vai trò và tổ chức

bằng cách tiếp thị và bán hàng. Một điển hình, đôi khi sai lầm tốn kém vào các dự án là để chờ đợi cho đến khi phân tích là cần thiết trước khi thực hiện một chiến lược dấu vết.

Truy xuất nguồn gốc dựa theo mục tiêu

Truy xuất nguồn gốc dựa trên mục tiêu bắt đầu với mục đích hay mục tiêu kinh doanh, và các dấu vết này sau đó được sử dụng để xác định các mục tiêu kinh doanh đã được đáp ứng. Trên rất nhiều các dự án mà chúng tôi đã làm việc , dấu vết dựa trên mục tiêu đôi khi bị thiếu. Tuy nhiên, không có dấu vết cho các mục tiêu ban đầu là rất khó khăn, đặc biệt là đối với các yêu cầu phi chức năng, để tạo sự cân bằng cần thiết khi ưu tiên tính năng. Mô hình mục tiêu, như mô tả trong Chương 3, có lợi thế tiềm ẩn truy tìm; có nghĩa là, khi mối quan hệ được tạo ra



giữa các mục tiêu và mục tiêu phụ, các dấu vết được ngầm định. Vấn đề có thể phát sinh do các tổ chức khác nhau xác định mục tiêu kinh doanh, tính năng sản phẩm, và yêu cầu chi tiết. Ví dụ, một hệ thống báo động xây dựng có yêu cầu cấp thấp mà báo động sẽ có ba mức nháy khác nhau. Các nhà phát triển thực hiện các yêu cầu không hiểu lý do tại sao lại có các yêu cầu đó (ví dụ, chớp hoặc không chớp nên đủ tốt, đặc biệt là với nhiều màu sắc), nhưng với các mục tiêu kinh doanh, chúng ta thấy rằng tỷ lệ chớp khác nhau là cần thiết để sản phẩm sẽ được bán tại các thị trường nơi các nhân viên an ninh có thể bị mù màu.

Các loại dấu vết

Chúng ta có thể nhóm các dấu vết thành các loại như định nghĩa trong [Jarke 1998]. Các loại này bao gồm:

Chuyển tiếp từ yêu cầu phân bổ cho các thành phần hệ thống để thiết lập trách nhiệm và thay đổi tác động hỗ trợ

Quay lại các yêu cầu xác nhận việc tuân thủ hệ thống yêu cầu, và tránh mạ vàng

Chuyển tiếp tới yêu cầu thay đổi trong nhu cầu của các bên liên quan hoặc giả định rằng có thể yêu cầu đánh giá lại triệt các yêu cầu liên quan

Quay lại từ yêu cầu cơ cấu đóng góp rất quan trọng để xác nhận yêu cầu

Các loại dấu vết đều liên quan đến phân tích; nghĩa là, phân tích nguồn gốc đòi hỏi phải truy tìm ngược, khi phân tích bảo hiểm và phân tích tác động đòi hỏi truy tìm về phía trước

Ví dụ về mô hình kỹ thuật truy tìm dựa trên dư án

Điểm bắt đầu để xác định một chiến lược truy yêu cầu là việc tạo ra một mô hình truy xuất nguồn gốc (mô hình "V") và tạo ra một mô hình siêu dự án (xem Chương 2). Mô hình "V" (xem Hình 7.1) có thể được sử dụng như một hướng dẫn để hỗ trợ trong việc xác định một chiến lược truy tìm. Một phương pháp khác



Hình 7.1 Mô hình kỹ thuật truy tìm dựa trên dự án



Truy xuất nguồn gốc không đầy đủ có thể dẫn đến sự kém hiệu quả

Trong một dự án y tế, một bác sĩ đã được yêu cầu viết một trường hợp sử dụng tài liệu giải thích làm thế nào các đơn đặt hàng đã được sử dụng để sắp xếp các hoạt động tại các bệnh viện. Sau vài tuần tạo ra các tài liệu, ông phát hiện ra rằng các trường hợp sử dụng yêu cầu đã tồn tại nhưng không có dấu vết đến hoặc từ nó, và do đó nó là "vô hình" để phân tích.

là xác định một siêu mô hình, và sau đó lấy một dấu vết chiến lược từ các siêu mô hình. Các "V" mô hình phương pháp tiếp cận để xác định nguồn gốc thường được sử dụng khi có những lo ngại pháp lý quan trọng, và hầu như luôn luôn được sử dụng khi phát triển sản phẩm được thuê ngoài. Các cách tiếp cận siêu mô hình thường được sử dụng nơi có rất nhiều nguồn khác nhau của yêu cầu hoặc các tiến trình RE là tương đối phức tạp.

Phía bên trái của mô hình "V" là có liên quan với yêu cầu, thiết kế và triển khai thực hiện và các giao dịch phía bên phải với các thử nghiệm. Ở phía trên của mô hình "V", kế hoạch yêu cầu và chấp nhận kiểm tra được kết hợp với dấu vết. Di chuyển xuống dưới mô hình "V", các dấu vết kết nối yêu cầu cấp thấp hơn (chi tiết cao hơn) với các thử nghiệm tương ứng, và ở dưới cùng, đơn vị hoặc các thành phần có liên kết đến kế hoạch kiểm tra đơn vị của chúng.

7.5. Phép đo và s li uố ệViệc áp dụng các thực tiễn đo lường để có được số liệu là một kỹ thuật để quản lý có hiệu quả việc phát triển phần mềm và bảo trì tiến trình [Jones 1991], [Moeller et al. 1993]. Nguồn gốc của phần mềm và hệ thống đo lường được căn cứ vào các biện pháp phức tạp mã [McCabe 1976], phần mềm dự toán chi phí dự án [Boehm 1981], đảm bảo chất lượng phần mềm [Moeller 1988], và cải tiến quy trình phát triển phần mềm [Basili 1980]. Năm 1987, Grady và Caswell đã viết một cuốn sách về các ứng dụng của một ban quản lý bởi các số liệu cách tiếp cận đó đã được thực hiện tại Hewlett-Packard [Grady et al. 1987]. Quy trình, sản phẩm, và số liệu chất lượng được sử dụng để giám sát và cải thiện một quy trình phát triển phần mềm và quản lý dự án phát triển phần mềm [Jones 1991].

Yêu cầu kỹ thuật có thực tiễn và các biện pháp được sử dụng để đo lường sự tiến bộ của hoạt động RE và chất lượng của các hiện vật RE. Những số liệu RE có thể được sử dụng để cung cấp hướng dẫn về việc cải thiện quá trình RE. Chúng có thể



được áp dụng trên toàn bộ vòng đời hoặc áp dụng cho giai đoạn cụ thể của sự phát triển hoặc hiện vật RE cụ thể.

Ví dụ, các phép đo có thể được sử dụng để thực hiện các phân tích đó được so sánh với các giá trị chuẩn. RE số liệu có thể được sử dụng để xác định các điểm sau:

Đã được các nhân viên RE đào tạo đầy đủ? Là đội chú ý đủ đến tiến trình RE (ví dụ, là tỷ lệ lỗi chấp nhận được)? Đã được chất lượng của các sản phẩm công việc tổng thể đầy đủ không? Là các yêu cầu theo dõi? Là sản phẩm công việc phù hợp cho a) trong nhà sản xuất / phát triển hoặc

b) gia công phần mềm?

Để sử dụng có hiệu quả các số liệu, họ cần được lên kế hoạch vào lúc bắt đầu của dự án. Nó cũng có thể có ích để có được số liệu bài dự án và sử dụng chúng cho tổng thể cải thiện quá trình tổ chức.

số liệu lỏng lẻo có thể được chia thành hai loại: dự án và chất lượng. Đo dự án, sử dụng để quản lý, hỗ trợ trong việc tìm hiểu sự tiến bộ và năng suất. Số liệu chất lượng cung cấp các thông tin về chất lượng của các sản phẩm làm việc khác nhau. Chất lượng ví dụ và dự án số liệu được mô tả chi tiết hơn trong các phần sau.

Số liệu dự án

Đo dự án được sử dụng để đánh giá ngày qua ngày của tình trạng dự án, và để xác định tính đầy đủ của một vật hoặc nhiệm vụ để kích hoạt quá trình xem xét. Quy trình, đo lường, và các công cụ cùng phụ thuộc lẫn nhau. Đó là, không có quá trình này có thể sẽ không có phép đo; mà không có các phép đo, tiến độ dự án và chất lượng sản phẩm công việc có thể không được truy cập; và không có công cụ hỗ trợ, lấy số đo sẽ rất tốn thời gian, có thể đến các điểm bị không thực tế. Bảng 7.4 liệt kê một vài số liệu dự án được đề xuất.

Số liệu chất lượng

Số liệu chất lượng là những số liệu đo lường chất lượng của các yêu cầu hiện vật (bao gồm cả các sản phẩm cuối cùng), nhưng không nhất thiết phải truyền đạt thông tin về tiến độ dự án hoặc năng suất (xem Bảng 7.5). Khi chất lượng được đo dựa trên tiêu chuẩn, tiêu chuẩn chất lượng cần phải được xác định để sử dụng số



liệu chất lượng; ví dụ, hiện các yêu cầu đặc điểm kỹ thuật đáp ứng hoặc vượt quá tiêu chuẩn cho các yêu cầu thông số kỹ thuật tốt?

Số liệu Diễn tả Tính toánĐầy đủ Một chỉ số về tiến độ dự

ánMỗi yêu cầu hoặc tính năng có một thuộc tính đầy đủ. Đối với một yêu cầu cấp cao, tính đầy đủ được đo bằng cách tập hợp tất cả các yêu cầu phát sinh hoặc yêu cầu con. Yêu cầu tiến bộ sau đó có thể được xác định bằng cách đánh giá tất cả các yêu cầu cao cấp cùng cấp và sử dụng một giá trị bình thường.

Phạm vi Cho biết phần trăm tổng thể hoàn thành dự án

Với mỗi yêu cầu, xác định xem liệu các trường hợp thử nghiệm lá bắt nguồn đã được hoàn thành. Phân tích này đòi hỏi một traversal cây xuống các yêu cầu kim tự tháp với các trường hợp thử nghiệm truy tìm.

Sự biến động Tỷ lệ thay đổi yêu cầu chuẩn hóa

Sử dụng lịch sử thay đổi yêu cầu để xác định tỷ lệ thay đổi cho các yêu cầu. Có thể được sử dụng như một chỉ số về rủi ro thực hiện cũng như tiến độ dự án. Yêu cầu thay đổi giá tiệm cận nên cách tiếp cận không như dự án đạt đến ngày hoàn thành.

BẢNG 7.4 Ví dụ số liệu dự án



Số liệu Diễn tả Tính toánNguồn gốc Tất cả các yêu cầu được

truy trở lại để yêu cầu các bên liên quan

Mỗi yêu cầu root (mẹ) cần phải theo dõi từ một tài liệu hoặc các cổ đông yêu cầu bên ngoài.

Yêu cầu chất lượng Phần trăm các yêu cầu đi qua một đánh giá đầu tiên

Tỷ lệ của các yêu cầu đó thông qua một đánh giá lần đầu tiên. Đây là một dấu hiệu cho thấy các kỹ năng của các nhà phân tích yêu cầu.

BẢNG 7.5 Ví dụ số liệu chất lượng

7.6: Kh năng m r ngả ở ộQuy trình đưa ra vào lúc bắt đầu của một dự án có thể không đi vào xem xét số lượng yêu cầu mà có thể cần phải được quản lý như yêu cầu định nghĩa tới gần hoàn thành. Ví dụ, một dự án với 50 tính năng để bắt đầu có thể không xuất hiện như một dự án lớn. Nhưng, nếu chúng ta xem xét các phản ứng không hợp lý của mỗi tính năng để 100 hoặc nhiều "cấp cao" yêu cầu, chúng ta sẽ có hơn 5000 yêu cầu cao cấp. Thêm một lớp phản ứng thêm chi tiết cần thiết để thực hiện các sản phẩm và tạo ra các trường hợp thử nghiệm (giả định một sự phản ứng của 10: 1), chúng ta sẽ thổi lên với tổng số 50.000 yêu cầu và ít nhất cùng một số dấu vết. Một số yêu cầu để quản lý và theo dõi như vậy là không hợp lý cho các dự án lớn hiện nay. Nó là vậy, bắt buộc các cơ chế theo dõi được, đến mức có thể, thực chất đến những tiến trình đó mà không có một nỗ lực hướng dẫn phiền toái. Một số kỹ thuật để giảm thiểu các vấn đề về quy mô được mô tả trong phần "thực tiễn tốt nhất" sau này trong chương này.

7.7 T o m t quy trình qu n lý yêu c uạ ộ ả ầNó rất dễ dàng để đánh giá thấp những nỗ lực cần thiết để quản lý đúng yêu cầu về một dự án. Thật không may, vấn đề quy trình có xu hướng không xuất hiện cho đến khi nó là muộn trong dự án, và nó có thể rất khó khăn và nhiều tác động để



thay đổi trong quá trình diễn ra. Do đó, điều quan trọng là lên kế hoạch sớm để xử lý một lượng lớn dữ liệu, yêu cầu cho sự thay đổi, và năng suất cao thông qua việc tự động hóa. Ví dụ, các yêu cầu, đặc biệt là các yêu cầu phi chức năng, có thể ảnh hưởng đến các yêu cầu khác, và để tìm kiếm và các cơ chế sửa đổi được tự động tốt nhất. Trong phần này, chúng ta sẽ đi qua quá trình của việc tạo ra một môi trường quản lý yêu cầu. Trong phần sau, chúng tôi sẽ cung cấp thêm chi tiết về các khía cạnh cụ thể của quản lý yêu cầu.

1. Định nghĩa của quá trình cải tiến quy trình bắt đầu với định nghĩa về sản phẩm công việc cần thiết cho tổ chức. Chúng có thể được định nghĩa trong một phân loại của một mô hình tạo tác (xem Chương 2), nhưng điều quan trọng là không để bỏ qua bất cứ điều gì mà có thể cần thiết.

2. Bước tiếp theo là phạm vi các hiện vật dựa trên nhu cầu của doanh nghiệp; ví dụ, những gì đang ở và những gì được ra ngoài.

3. Tự động hóa và chiến lược truy tìm được định nghĩa bằng cách đánh giá các mối quan hệ giữa các hiện vật và xác định nếu các dấu vết là cần thiết, nếu chúng đang có, cho dù chúng sẽ được tạo ra và duy trì bằng tay hoặc tự động.

4. Đối với mỗi vật mà cần phải được tạo ra (ví dụ, thông số kỹ thuật như một tài liệu yêu cầu của khách hàng), các mẫu cần phải được tạo ra và xem xét.

5. Nếu các hoạt động để tạo ra các hiện vật là không đúng chỗ, chúng cần phải được xác định, cùng với vai trò, tiêu chuẩn, thủ tục và đảm bảo chất lượng. Tạo các tài liệu mẫu lý tưởng hóa hay báo cáo là một cách tuyệt vời để đảm bảo chất lượng tốt.

6. Hãy chắc chắn để xác định các tiến trình giao diện để tương tác với quản lý sản phẩm, sản xuất và thử nghiệm.

7. Đừng quên bảo trì và kiểm soát phiên bản! Sau khi dự án hoàn thành, nó có thể là cần thiết để quản lý sự thay đổi cho phiên bản sản phẩm trong tương lai hoặc sửa chữa.



Một quản lý quy trình yêu cầu kĩ thuật là thường xuyên mô tả trong văn bản gọi là một kế hoạch quản lý yêu cầu kĩ thuật. Nội dung của một bảng của ví dụ REMP được cho trong hình 7.2.

7.8. Ti t ki m đo l ng v i các ti n trình REế ệ ườ ớ ếKhi ta cải thiện các yêu cầu trong một tổ chức, nó có thể không thể định lượng tiết kiệm với cách tìm kiếm các RE khi làm sản phẩm cải thiện hiệu suất sản phẩm. Thực tế, tiết kiệm có thể chỉ được xác định bằng cách tìm kiếm trong dựán một



cách toàn diện. Tuy nhiên, có thể phải thay đổi cách tư duy. Ví dụ, có một tổ chức mà chúng ta có thể thấy rằng trong suốt quá trình cải thiện các sự cố, đã dùng trong các loại “lỗi phần mềm” để dự báo các lỗi phần mềm. Sau đó phân tích nguyên nhân, có thể thấy rằng phần lớn các lỗi phần mềm đã thật sự đúng vấn đề của yêu cầu. Sau một số huấn luyện các nhân viên dùng RE đã hoàn thành công việc tốt hơn các yêu cầu viết, số lỗi giảm rõ rệt. Một số chỉ tiêu mẫu trình bày được thể hiện trong bảng 7.6.

Nguyên nhân gây ra lỗi Cách khắc phục được đề nghị

Yêu cầu nhập nhằng, không rõ nghĩa Các nhà phân tích cần rèn luyện để viết các yêu cầu rõ ràng.

Yêu cầu chưa hoàn thiện Xem xét số lượng thời gian dành cho việc phân tích. Xác định xem xét yêu cầu được thực hiện với những người tham gia phải.

Những yêu cầu có mâu thuẫn Sửa đổi các quy trình để giải quyết đầy đủ RE yêu cầu giải quyết xung đột.

Những yêu cầu không đúng Quá trình này có thể cần phải được sửa đổi để bao gồm sự tương tác bổ sung và đánh giá với các bên liên quan.

Sản phẩm làm ra không đúng với kì vọng của khách hàng

Giao tiếp với khách hàng có thể cần phải được thường xuyên hơn hay toàn diện.

Kết quả đạt được ở dưới mức kì vọng Các yêu cầu phi chức năng có thể cần phải được giải quyết sớm trong quá trình khơi gợi và/hoặc có thể các kiến trúc sư và nhà thiết kế phải được tham gia đầu đủ để làm một phân tích hiệu quả của các yêu cầu phi chức năng.

Thiếu sự cân đối giữa các yêu cầu Các kỹ thuật truy tìm có thể cần phải được cải thiện như vậy mà các nhà



thiết kế có thể hiểu bất kỳ ràng buộc pháp lý mà từ đó các yêu cầu lấy được.

7.9 Các v n đ v t ch c qu n lý nh h ng đ n các yêu c uấ ề ề ổ ứ ả ả ưở ế ầMột kế hoạch quản lý các yêu cầu kỹ thuật (REMP) không nên được tạo ra mà không có lấy một cái nhìn tổng thể về quá trình khác gắn liền với phát triển hệ thống; ví dụ, sản xuất, phát triển phần cứng, phát triển phần mềm, kiểm thử và bảo trì. Một sai lầm điển hình khi thiết lập một REMP là bỏ qua thượng nguồn và hạ lưu các quá trình. Họ rất cần thiết để hiểu được bối cảnh của bất kỳ quá trình RM đưa ra, ví dụ:

Mục tiêu kinh doanh và các chính sách như thế nào?

Nơi nào đã giữ hộ lại?

Làm thế nào chúng ta có thể duy trì dấu vết giữa các mục tiêu, chính sách, và các yêu cầu như vậy mà tác động của một sự thay đổi trong định hướng kinh doanh (ví dụ, sự thay đổi trong khung thành) có thể được đo lường.

Do những quy định kinh doanh xuất phát từ chính sách, các tác động của thay đổi chính sách phải đo lường được; ví dụ, những quy tắc nào sẽ phải thay đổi nếu thay đổi chính sách này?

Lưu ý rằng đối với các dự án nhỏ hơn, quy trình không phải là đầu nặng mà là nạc càng tốt. Quan trọng nhất, khi ra khỏi các hoạt động và các sản phẩm làm việc ra của một quá trình, là để lại họ bằng hoa hồng và không phải do thiếu sót (ví dụ, quên về họ).

Một vấn đề tổ chức là các phân phối công việc kỹ thuật (xem Chương 10). Phân phối các nỗ lực mang với nó thêm những thách thức, như thể hiện trong Bảng 7.7.

Nói chung, bất kỳ nỗ lực phân phối phải có sự lãnh đạo mạnh mẽ tại các quản lý dự án và các cấp lãnh đạo kỹ thuật, xây dựng mối quan hệ mặt đối mặt và đào tạo trước khi bắt đầu, một chuỗi rõ ràng của lệnh, xác định rõ vai trò và trách



nhiệm, một tốt xác định dự án , được hiểu rõ quá trình yêu cầu kỹ thuật, và một liên lạc tại mỗi trang web có trách nhiệm cho tất cả các hoạt động truyền thông.

Tạo một cơ sở dữ liệu các yêu cầu

Đối với các dự án nhỏ, yêu cầu có thể được quản lý bằng cách sử dụng bảng tính. Tuy nhiên, như một dự án đạt đến một kích thước tới hạn, nói 100 yêu cầu hoặc hơn, nó trở nên cần thiết để sử dụng một cơ sở dữ liệu để lưu giữ thông tin. Các hoạt động như quản lý cấu hình, quản lý truy xuất nguồn gốc, tạo ra thông số kỹ thuật, và giải nén số liệu được thực hiện với nỗ lực ít hơn nhiều bằng cách sử dụng một trong những cơ sở dữ liệu quản lý các yêu cầu kỹ thuật thương mại có sẵn.

Công cụ quản lý dữ liệu thương mại có thể làm một công việc rất tốt đẹp của các yêu cầu theo dõi thay đổi khi chúng làm điều khiển phiên bản tinh hạt. Ví dụ, chỉ cần thay đổi các ưu tiên của một yêu cầu sẽ dẫn đến một phiên bản yêu cầu mới được tạo ra cũng như một đường mòn kiểm toán, do đó, rằng lịch sử của các yêu cầu có thể được xem. Giả sử rằng một yêu cầu được lưu giữ như một hồ sơ duy nhất với một ID duy nhất, hồ sơ sẽ có các trường thuộc tính có thể được tùy chỉnh cho một tổ chức hoặc dự án. Thông thường các công cụ quản lý dữ liệu sẽ đến "off-the-shelf" với một bộ tiêu chuẩn của các thuộc tính. Những thuộc tính hầu như luôn luôn cần may và mở rộng để có ích. Một gợi ý (nhưng không nhất thiết phải toàn diện) tập các lĩnh vực để đưa vào một lược đồ quản lý dữ liệu được liệt kê trong Bảng 7.8. Lưu ý rằng không phải tất cả các lĩnh vực sẽ được liên kết với tất cả các loại yêu cầu. Ví dụ, giá trị Kano sẽ được kết hợp tốt nhất với các tính năng sản phẩm và có thể không có ý nghĩa trong bối cảnh của các loại yêu cầu khác.

Quan sát vấn đề Cách khắc phục được đề nghị

Chưa có đánh giá chéo giữa các vị trí Đánh giá hợp tác thường xuyên sử dụng web hoặc mạng lưu trữ công cụ

Phong cách tài liệu khác nhau Sẵn có của các tiêu chuẩn và các văn bản mẫu trước khi bắt đầu công việc; gặp mặt trực tiếp

Quản lý cấu hình yếu Lãnh đạo kỹ thuật mạnh mẽ; gần gũi, sự phối hợp thường xuyên giữa các



thành viên nhóm nghiên cứu tại các trang web khác nhau; sử dụng một kho lưu trữ trung ương yêu cầu

Khó khăn về giao giữa phân tích và thiết kế các tổ chức

Lãnh đạo kỹ thuật mạnh mẽ; định nghĩa quy trình trước khi bắt đầu dự án; cũng xác định chiến lược cụ

Đẩy mạnh phân tích chi tiết để tổ chức phát triển từ xa

Nếu phân tích chi tiết được đẩy lên một trang web từ xa, đẩy một nhà phân tích cao cấp của trang web cũng; điều quan trọng là đội viên không cảm thấy xa xa. Ngoài ra, nếu phân tích được thực hiện từ xa, các nhân viên từ xa sẽ cần những kỹ năng cần thiết hoặc đào tạo.

Đỗ trễ của phản hồi Quản lý kỹ thuật cần phải được đánh giá cao có thể nhìn thấy và đánh phủ giải quyết các vấn đề tiềm năng với các địa điểm phân phối trước khi vấn đề nhỏ ném tuyết vào khủng hoảng.

Yêu cầu thích hợp cho trong nhà phát triển chưa đầy đủ và khó hiểu đến các trang web từ xa

Cách tốt nhất để giảm thiểu yêu cầu không đầy đủ là để thực hiện đánh giá kỹ lưỡng. nếu đó là không khả thi, sau đó nó có thể là cần thiết để chung nhau phân tích với các nhân viên phát triển và chuyên gia vấn đề

Trong khi khả năng khó khăn để thiết lập ban đầu, một RDMS với một số lượng đầy đủ của thông tin có thể dẫn đến một sự giàu có của thông tin



Trường Miêu tảChủ nhân Các bên liên quan, người "sở hữu" các yêu

cầu.Mục hoặc đề mục con yêu cầu Tạo ra một yêu cầu kim tự tháp và sau đó sử

dụng các mức definds trong kim tự tháp như các loại yêu cầu

Hạng mục yêu cầu Thường lấy từ các nguyên tắc phân loại yêu cầu. các giá trị có sẵn trong lĩnh vực này mignt thay đổi dựa vào loại yêu cầu, hiệu suất, an ninh.

Chỉ định từ Nguồn của yêu cầu.Chỉ định đến Những tác động yêu cầuQuyền ưu tiên Đo là để xác định mức độ cao, trung bình,

thấp…Xếp hạng Xếp hạng và quyền ưu tiên là khác nhau

trong các yêu cầu có thể có quyền ưu tiên giống nhau.

Trạng thái Dự thảo, chấp nhận, lỗi thời.Trạng thái thẩm định Cho dù các yêu cầu đã được đáp ứngHạng mục Hạng mục chức năng, sản phẩm….Rủi ro Đây là rủi ro thực hiện. Nó thường xuyên

sảy ra khi các yêu cầu khác nhau.Biến động Khả năng yêu cầu sẽ thay đổi trước khi sản

phẩm đông lạnh.Giá trị Kano feilds sử dụng để đo lường giá trị tình cảm

của một yêu cầu từ khách hàng.Chi phí ước tính thực hiện Chi phí dự kiến để thực hiện một chức năngChi phí thực tế của việc thực hiện So sánh với chi phí ước tính và sau đó được

sử dụng để nâng cao Chất lượng dự toán

Đặc trưng chất lượng Xem lại kết quả của yêu cầu.Phát hành sản phẩm Sản phẩm hoặc version của yêu cầu đã từng

giao.Thành phần Thành phần cứng hoặc phần mềm hoặc

thành phần thực hiện của yêu cầu nàyBáo cáo khuyết điểm Khiếm khuyết gây ra bởi một vấn đề với yêu

cầu nàyMiêu tả dòng sản phẩm Mô tả việc một yêu cầu có liên quan đến tài

sản cốt lỏi, nền tảng trong dòng sản phẩm



Một kĩ thuật chúng tôi sử dụng là xây dựng bộ câu hỏi định kì, lấy số liệu thống kê là như thế nào điền vào bảng. Sau khi xem xét lại, lấy ví dụ, kết quả xem lại là tất cả các địa điểm với yêu cầu xem lạị….,kết quả xấu nhất sảy ra là không được hoặc chấp nhận ước định giá trị.Bằng khả năng quan sát giá trị chất lượng trong một ô trên một khoảng thời gian, tổ chức có thể cải tiến giám sát yêu cầu suy luận và phân tích.

Một kĩ thuật khác có thể được sử dung dùng lại sổ tay nỗ lực trong đặc trưng yêu cầu định nghĩa là tự động truyền giá trị thuộc tính từ nguồn gốc đến hình thành hoặc từ hình thành đến nguồn gốc. ví dụ nếu tất cả các yêu cầu được hình thành từ mục tiêu của nguồn gốc đã từng đáp ứng yêu cầu, khi các mục tiêu của nguồn gốc có thể tự động đánh dấu đáp ứng các yêu cầu. Đi theo hướng đối diện, nếu yêu cầu Corporate được đánh dấu là ưu tiên "cao", khi tất cả yêu cầu nguồn gốc của nó tự động được hưởng quyền ưu tiên đó? Nhớ rằng để nó ít rủi ro với thông tin bạn có, bạn cần công cụ quản lí dữ liệu tốt hơn.

Quản lý các yêu cầu đối với dòng sản phẩm

Dòng sản phẩm, xử lý và hiện vật được đề cập trong tài liệu [Clements et al.2001], [pohl et al.2005] (xem chương 6). Tuy nhiên, yêu cầu quản lý dòng sản phẩm là một vấn đề khó khăn mà tồn tại vài tiêu chuẩn thực hành. Mục này tìm hiểu mở rộng một RDMS của dòng sản phẩm bằng tay.

Đầu tiên, các yêu cầu hoặc cha mẹ của nó đã được đánh dấu là đến nơi mà nó thuộc về, một nền tảng, một tài sản cốt lõi của các dòng sản phẩm, hoặc một hoặc nhiều hơn các sản phẩm trong dòng sản phẩm. điều này có thể được thực hiện với một thuộc tính yêu cầu. Tuyên truyền hướng xuống sẽ thích hợp cho trường này, nếu yêu cầu của một sản phẩm trong một dong sản phẩm sau đó tất cả các yêu cầu hoặc đề nghị yêu cầu cấp độ thấp hơn đều được cập nhật vào sản phẩm.

Các khía cạnh thách thức nhất trong việc quản lý các yêu cầu dòng sản phẩm là tính chất đa chiều của một số các thuộc tính yêu cầu. Ví dụ, thay vì một yêu cầu có một ưu tiên, nó có thể bây giờ có một ưu tiên đó là một chức năng trong đó sản phẩm và phát hành sản phẩm của nó là ở. Vì yêu cầu có thể có phụ thuộc (ví dụ, tính năng "B" không thể được thực hiện cho đến khi tính năng "A "được hoàn



thành), xác định các yêu cầu đặt ra cho một bản phát hành của một sản phẩm có thể đòi hỏi một mức độ tối ưu hóa. Đánh dấu Denne và Jane Cleland-Huang trong văn bản, phần mềm by Numbers, xác định một chiến lược phát hành dựa trên dòng tiền và các phép đo của đầu tư trở lại-on-(ROI) mà một tính năng sản phẩm có thể cung cấp [Denne et al. 2003]. Một thuật toán như sau đó sẽ trở nên phức tạp bởi thực tế là các tính năng tương tự có thể có giá trị khác nhau trong hai sản phẩm khác nhau trong một dòng sản phẩm. Ví dụ, trong khi cung cấp một nội thất da trong một kết thúc xe nhập thấp có thể tăng thị phần của mình, sản phẩm có nội thất da cùng trong một chiếc xe cao cấp có thể không làm tăng thị phần ở tất cả. Một bản tóm tắt của một số sự khác biệt lớn giữa việc quản lý các yêu cầu cho một sản phẩm và dòng sản phẩm được trình bày trong Bảng 7.9.

Chủ đề Sản phẩm Dòng sản phẩmBan kiểm soát thay đổi Cần thiết chỉ một Khi nhiều hơn một hoặc

một nền hoặc nhân xử lí với một sản phẩm.

Ưu tiên hoặc thứ hạng yêu cầu

Một yêu cầu Hai thuộc tính , yêu cầu có thể có những chính sách sản phẩm khác nhau

Đặc trưng yêu cầu Đặc chưng tiêu chuẩn Cần một vài đặc tính đặc biệt cho mỗi yêu cầu trên dòng sản phẩm

Phân phát Chỉ một có thể đa chiều cho yêu cầu một sản phẩm.

Hạng mục các bên liên quan

Đơn giản có thể phức tạp bởi các động lực đằng sau các dòng sản phẩm của khu vực các bên liên quan

Chỉ định sợi đơn từ tính năng để thử nghiệm

có thể phức tạp bởi regionalzation hoặc các yếu tố tin tức khác

7.10. L i khuyên khi qu n lý yêu c uờ ả ầBảng 7.10 diễn tả một vài lời khuyên quan trọng của xử lí quản lí yêu cầu.

Thực hành tốt nhất



Một vấn đề với một vài kĩ sư khi xử lí yêu cầu là họ không mở rộng tốt. Một qua trình xử lý công việc với 100 yêu cầu có thể mở rộng với 10000. Theo bài thực hành có thể giúp dự án medium-to large-scale:

Phân cấp yêu cầu nên được phân chia (trong mối quan hệ cha con trên từng cấp đăc trưng hay yêu cầu). Sự thiếu tạo cấp bậc (theo cấu trúc cây) thể hiện trong trong một bảng kích thước N*N với 2 thuộc tính, khi N là số yêu cầu kết hợp với chỉ định, sau hàng nghìn các yêu cầu, chỉ định là không nhiều hoặc không sử dụng được. Các kĩ thuật được đính kèm với phân cấp yêu cầu trong cơ sở dữ liệu làm dữ liệu cho những chỉ định sau này.

Vấn đề Gợi ýChỉ có thể xem xét 4/10 yêu cầu trong một giờ

Xem lại các yêu cầu ở mức độ caao nhất. Yêu cầu nên có một vài thực hành .

Bộ công cụ không được tích hợp Tạo dầy đủ một metamodel của môi trường. sử dụng metamodel làm kế hoạch và nền tảng cho công cụ

Chuyển hướng của tài liệu văn bản Sử dụng một trang web với đường dẫn. tài liệu với các từ khóa. Sử dụng các mông cụ như Wikipedia hoặc là web based.

Chỉ định quản lí khác nhau Sử dụng metamodel để xác định chức năng.

Quá rộng, sản phẩm đa dạng Sử dụng kĩ thuật model. Số lượng các văn bản được giữ bằng file text

Đảm bảo chất lượng của yêu cầu Đảm bảo chất lượng trong cơ sở dữ liệu.

Quản lí yêu cầu chức năng khác nhau Sử dụng goals model NFRs và mối quan hệ.

Hiểu về mở rộng yêu cầu khác nhau Sử dụng thẩm định các mô hình với tiêu chuẩn xác định chính xác các đặc trưng được đưa ra bởi khác hàng.

Bị mất việc làm lại do sự khác biệt lớn Chắc chắn để làm một phân tích nguyên nhân gốc rễ về sự khác biệt thiết lập.

Khác nhau bởi vì nền tảng tài liệu Sử dụng kĩ thuật máy ảo và xem các công cụ online trên web.

Một vài tài liệu use case, chỉ định khác Sử dụng kĩ thuật kiểm tra tự động yêu



nhau cầu từ use caseSố lượng yêu cầu quá lớn Sử dụng yêu cầu đặc trưng trong cơ sở

dữ liệu.

Tạo một bảng chú giải của các điều khoản và sử dụng phù hợp các điều khoản trong dự án. Sự thiếu bảng chú giải của các điều khoản có thể dẫn đến kết quả khác nhau khi sử dụng trong trường hợp nghĩa giống nhau và làm cho mối quan hệ phân cấp trở nên trễ ngày.

Tạo một dự án metamodel hoặc mô hình giả tượng lucs bắt đầu dự án. Tạo một phần của mô hình sẽ làm lộ tất cả các quyền tự động chỉ định.

Kế hoạch của các cơ sở điều hướng. Khi một dự án rất lớn, khối lượng của tài liệu liên kết với dự án có thể khó sử dụng làm tài liệu quản lí. Ví dụ, vấn đề xảy ra nếu yêu cầu được thay bằng một yêu cầu khác? Điều hướng kĩ thuật sẽ giúp quản lí các thông tin quan trọng không bị mất và không mất nỗ lực làm lại.

Sắp xếp các yêu cầu trong cơ sở dữ liệu. Yêu cầu trong cơ sở dữ liệu là mã nguồn tốt nhất cho dự án, nhưng các câu hỏi chỉ là tốt nhất nếu được xây dựng và xử lý trong hồ sơ.

Các mục đích của doanh nghiệp và chính sách thay đổi quản lí, xác định rõ yêu cầu của doanh nghiệp có thể theo chính sách của tổ chức.

7.11. Tóm t tắTrong chương này chúng tôi đã giới thiệu về một vài phương pháp thực hành sử dụng quản lí các yêu cầu. Một vài phương pháp rất quan trong trong những dự án lớn. Yêu cầu và RE phải được điều chỉnh và lưu lại. Khi thay đổi mục đích, quá trình xử lí phải sử dụng phân tích tác động để thay đổi.

7.12. Câu h i th o lu nỏ ả ậXem lại bài thực hành trong chương, hãy thảo luận về các câu hỏi sau:

1. Làm thế nào để đo chất lượng của một văn bản yêu cầu?2. Làm thế nào để đo được tính hoàn chỉnh của một văn bản yêu cầu?3. Làm thế nào để quyết định nếu thay đổi yêu cầu?4. Các câu hỏi trọng tâm mà cố gắng để trả lời là gì?



Ch ng 8: Ki m th h th ng h ng yêu c uươ ể ử ệ ố ướ ầ

Chương này đề cập đến hệ thống kiểm tra mà dựa trên các yêu cầu. Nó giới thiệu các khái niệm và thảo luận về kỹ thuật có thể được sử dụng thành công để tạo ra các trường hợp thử nghiệm bằng cách sử dụng một số các hiện vật RE. Nó thảo luận thử nghiệm dựa trên mô hình (MBT) tập trung vào các loại mô hình RE và thông số kỹ thuật hữu ích cho các kỹ sư thử nghiệm

8.1 N n t ngề ảkiểm thử phần mềm là quá trình thực hiện phần mềm với mục đích tìm kiếm các lỗi [Myers 1979], và về cơ bản hỗ trợ các hoạt động xác thực và xác nhận. CMMI () hướng dẫn mô tả xác nhận là các hoạt động đó chứng tỏ nếu một sản phẩm sẽ đáp ứng mục đích sử dụng của nó, và xác minh là hoạt động để đảm bảo rằng các sản phẩm đáp ứng yêu cầu quy định. Xác minh được chủ yếu được thực hiện bởi nhóm phát triển và thử nghiệm, và nó thường bao gồm các kỹ thuật không xét nghiệm dựa trên khác như đánh giá kỹ lưỡng, kiểm tra và gỡ lỗi. Mặt khác, các hoạt động xác thực dựa trên các yêu cầu quy định, và các kỹ sư yêu cầu được tham gia rất nhiều. Như vậy, có các kỹ sư phải hiểu được yêu cầu để họ có thể xác nhận rằng hành vi của hệ thống nó như vậy mà nó đáp ứng các yêu cầu. Các hoạt động xác nhận có thể dựa trên cả hai yêu cầu chức năng và phi chức năng

Vai trò của kiểm tra để yêu cầu xác nhận có thể được nhìn thấy trong các mô hình vòng đời khác nhau như mô hình "V". Thử nghiệm được thực hiện để xác nhận hiện vật vòng đời được tạo ra bởi các yêu cầu kỹ thuật và thiết kế. Ví dụ, xét nghiệm sẽ sử dụng một yêu cầu đặc điểm kỹ thuật như là điểm khởi đầu cho việc xác định đặc tả yêu cầu của họ như là điểm khởi đầu cho việc xác định bộ kiểm tra chấp nhận của họ. Lý tưởng nhất, họ nên có một bộ kiểm tra hệ thống chạy trên hệ thống mục tiêu thực tế như vậy mà mỗi yêu cầu có thể được đáp ứng. Khi các hành vi hệ thống không đáp ứng các yêu cầu, báo cáo lỗi được viết bởi các xét nghiệm như vậy mà các nhà phát triển có thể sửa chữa những thiếu sót trước khi sản phẩm được phát hành cho khách hàng



Hệ thống kiểm tra là một quá trình công nghiệp được xác định rõ; trong nhiều trường hợp. Tuy nhiên, nó vẫn còn là một quá trình thủ công. Thông thường, các kỹ sư kiểm tra lấy được dữ liệu thử nghiệm của mình, đó là, đầu vào của họ yêu cầu hệ thống và thông tin sản lượng dự kiến, từ nhiều nguồn khác nhau, bao gồm cả văn bản, sử dụng kỹ thuật trường và các quy tắc kinh doanh. Sau đó, họ tạo ra một tập hợp các thủ tục kiểm tra bao gồm các bước thử nghiệm cá nhân, có thể được thực hiện bằng tay đối với Chấp hành thử nghiệm đối với hệ thống theo thử nghiệm có sẵn, kiểm tra được dịch sang kịch bản thử nghiệm thực thi. Quá trình này thường xảy ra trong giai đoạn cuối của quá trình phát triển trong thời gian đó thử nghiệm hệ thống phấn đấu để khám phá như nhiều khiếm khuyết càng tốt (.. không có sự phù hợp với các yêu cầu quy định) trước khi sản phẩm được đưa ra thị trường

Khi thử nghiệm hệ thống là tương đối đắt tiền và xảy ra trong thời gian trở lại vào cuối của quá trình phát triển, các đội kiểm tra thường là lớn và làm việc quá sức. Đối với nhiều hệ thống mà người dùng cuối phát hiện các khiếm khuyết có thể có những hậu quả tài chính hoặc sự an toàn đáng kể và thử nghiệm hồi quy là cần thiết, thực hiện các bài kiểm tra thường xuyên nếu có tăng cường thêm công cụ tự động, .. các công cụ được sử dụng để kích thích sự SUT, khám phá, và tài liệu khiếm khuyết. Các thế hệ tự động của các trường hợp thử nghiệm có thể được thực hiện bằng cách sử dụng thử nghiệm dựa trên mô hình (MBT) phương pháp tiếp cận, được mô tả trong chương này

Các khiếm khuyết trong các yêu cầuMặc dù chương này là tập trung vào thử nghiệm hệ thống, mô hình "V" đã hình dung ra nhiều giai đoạn thử nghiệm, xem xét, kiểm tra và sử dụng để phát hiện các khiếm khuyết, trong nhiều trường hợp, khiếm khuyết trong yêu cầu này sẽ được phát hiện trong các hoạt động này V & V ở hạ lưu. Capters Jones cho biết rằng: 1) yêu cầu trong các dự án của Mỹ dường như có khoảng 1-1,2 các khiếm khuyết (lỗi) cho mỗi chức năng điểm [Jones 2008] và 2) hầu hết các hình thức kiểm tra, chỉ có khoảng 35 phần trăm hiệu quả trong việc tìm kiếm các khiếm khuyết, vì vậy một số yêu cầu về các khiếm khuyết vẫn sẽ có mặt ngay cả khi giao hàng của khách hàng. Ngoài ra, thậm chí yêu cầu tốt sẽ không đầy đủ, do đó, sẽ có những khoảng trống mà không thể được kiểm tra, vì nhu cầu đang bị thiếu. Khoảng 7 phần trăm nỗ lực để khắc phục các khiếm khuyết yêu cầu, một khi họ đã



được xác định, vô tình sẽ bao gồm các khiếm khuyết mới như một phần của việc sửa lỗi này

8.2 Đ u vào yêu c u kỹ thu t đ ki m thầ ầ ậ ể ể ửTrong chương 1, chúng ta đã thảo luận rằng một yêu cầu được gọi là "tốt" phải được kiểm chứng như vậy mà các sản phẩm hoàn thiện có thể được kiểm tra để đảm bảo rằng nó đáp ứng các yêu cầu. Điều này có nghĩa rằng các yêu cầu phải được định lượng và dễ dàng kiểm tra. Ngoài ra, đối với thế hệ tự động kiểm tra, yêu cầu phải được mô tả trong một dạng có thể được hiểu bởi máy tính hoặc thiết bị kiểm tra chuyên ngành hoặc các đồ tạo tác yêu cầu kỹ thuật phải được dễ dàng dịch sang một hình thức phải. Điều này ngụ ý rằng các yêu cầu mô tả như là mô hình sẽ làm cho công việc của tester dễ dàng hơn

Khi các tester có quyền truy cập vào các yêu cầu thông số kỹ thuật có thể kiểm chứng được, đầy đủ, rõ ràng, và như vậy (xem Phần 1.7), họ sẽ có thể hiểu được những gì mà hệ thống dự định nên làm gì và làm thế nào cần được thực hiện. Với một sự hiểu biết rõ ràng về các chức năng và hiệu suất của hệ thống dự định, họ sẽ có thể viết "tốt" các trường hợp thử nghiệm

Ngoài các yêu cầu hoặc thông số kỹ thuật hệ thống, hiện vật khác mà có ích để thử nghiệm các kỹ sư bao gồm hướng dẫn sử dụng và nguyên mẫu (xem Chương 9). Vì hầu hết các hệ thống thử nghiệm thường được thực hiện thông qua giao diện người dùng, RE và thiết kế một đồ tạo tác mô tả các hoạt động của giao diện người dùng (... người sử dụng giao diện đặc điểm kỹ thuật thiết kế) sẽ hữu ích cho các tester. Đối với trường hợp kiểm thử tự động tạo ra và thực hiện những bài kiểm tra, hiện vật có chứa mô hình sẽ rất hữu ích. Một kịch bản mà nó có thể tạo ra các trường hợp kiểm tra tự động từ một đặc tả yêu cầu là: (i) yêu cầu các kỹ sư tạo ra mô hình mô tả các yêu cầu đối với hệ thống theo thử nghiệm, và sau đó (ii) các kỹ sư kiểm thử sử dụng những mô hình như là đầu vào cho một model- công cụ kiểm tra dựa, có thể tự động tạo ra một tập hợp các bài kiểm tra. Thông thường những bài kiểm tra là "trừu tượng", nhưng họ cung cấp tài liệu hướng dẫn kiểm tra sớm và một kế hoạch thử nghiệm có thể hướng dẫn tạo thử nghiệm trong tương lai



8.3 Mô hinh c b n ki m thơ ả ể ử Thử nghiệm dựa trên mô hình cố gắng để lấy được các trường hợp kiểm tra từ một mô hình cho các hệ thống theo thử nghiệm (SUT) bằng cách sử dụng một loạt các tiêu chí lựa chọn thử nghiệm. Một mô hình là một cái nhìn trừu tượng của hệ thống và xác định thường là (một phần) các hành vi của hệ thống trong điều khoản của kiểm soát dòng chảy của nó và / hoặc lưu lượng dữ liệu. Ba loại khác nhau của các mô hình điển hình có thể được tạo ra

Yêu cầu các mô hình xác định hành vi dự định của hệ thống Mô hình sử dụng các phản ánh hành vi của một người sử dụng tiềm năng Mô hình được xây dựng từ mã nguồn trực tiếp (trong đó hệ thống được

thử nghiệm cho chúng ta một sản phẩm phần mềm)

Các phương pháp kiểm tra nguồn gốc áp dụng trên các loại mô hình khác nhau đôi khi được phân loại thành các thử nghiệm dựa trên đặc điểm (hoặc kiểm tra hộp đen) nếu chúng được dựa trên yêu cầu của mô hình, và thử nghiệm theo chương trình (hoặc kiểm tra hộp trắng) nếu mã nguồn được sử dụng là mô hình cơ bản

Trong những năm gần đây, MNT trở nên quan trọng trong kết nối với các kiến trúc hướng mô hình (MDA) sáng kiến của Object Management Group (OMG) và khái niệm về phát triển thử nghiệm điều khiển cho các sản phẩm phần mềm. Tiến bộ khác trong phần mềm và hệ thống kỹ thuật, giống như việc sử dụng các thực thi ngôn ngữ đặc tả, phát hiện dựa trên mô hình của các lỗi trong mã nguồn, hoặc suy luận về hành vi chương trình từ những quan sát thời gian chạy, đóng góp cho sự hồi sinh của phương pháp tiếp cận CBT, mặc dù nguồn gốc của MBT quay trở lại sự khởi đầu sớm của khoa học máy tính

Để áp dụng thành công trong các dự án MBT phát triển phần mềm công nghiệp ngày nay, điều quan trọng là để tự động thực hiện các bài kiểm tra được tạo ra. Ngày nay, một loạt các giải pháp kiểm thử tự động của việc thay đổi mức độ trừu tượng tồn tại, tùy thuộc vào các miền ứng dụng thực tế và đối tượng lịch sử

Từ quan điểm của việc sử dụng thực tế hiện tại của họ, MBT phương pháp tiếp cận dựa trên yêu cầu của mô hình và tiêu chuẩn bảo hiểm thích hợp chiếm ưu thế. Họ có thể dễ dàng thực hiện bằng cách sử dụng các kỹ thuật đặc điểm kỹ



thuật đồ họa như UML, và UML 2.0 Testing Profile. Đặc biệt, các phương pháp này được hưởng lợi từ phương pháp để phát triển thử nghiệm điều khiển hiện đang thịnh hành. Họ cũng phá vỡ các vấn đề kiểm tra tính đầy đủ liên quan đến việc kiểm tra nguồn gốc từ các mô hình thiết kế xảy ra nếu mã sản xuất từ cùng một mô hình được tạo tự động

Chúng tôi đã thảo luận làm thế nào các sơ đồ UML có thể được sử dụng để mô tả các yêu cầu mô hình trong chương 4 và 5. Đối với thử nghiệm dựa trên mô hình, kiểm tra các kỹ sư có thể sử dụng các sơ đồ sau: sơ đồ use case, sơ đồ gói, biểu đồ hoạt động, sơ đồ trình tự, sơ đồ máy trạng thái và sơ đồ lớp. Theo kinh nghiệm của chúng tôi, mô hình use case và biểu đồ hoạt động đặc biệt hiệu quả vì họ yêu cầu cầu để kiểm tra hệ thống, và chúng có thể được tạo ra dựa trên các yêu cầu hệ thống và cũng là trường hợp giới thiệu sử dụng được tạo ra như một phần của các yêu cầu hệ thống

Các trường hợp sử dụng để thử nghiệm có thể được phát triển sớm trong vòng đời dự án ngay sau khi yêu cầu có sẵn. Trong giai đoạn đầu của dự án, các trường hợp sử dụng là hơi trừu tượng. Trong giai đoạn sau, các trường hợp sử dụng được dân cư với đầy đủ thông tin để tạo ra các bài kiểm tra hệ thống thực thi. Một cách tiếp cận để sử dụng mô hình cho thế hệ thử nghiệm được mô tả như sau:

1. Sơ đồ ca (use-case) sử dụng được sử dụng để xác định các kịch bản sử dụng của hệ thống. Trường hợp sử dụng trừu tượng đại diện cho các bộ sưu tập có liên quan của các trường hợp sử dụng, và các trường hợp sử dụng cụ thể là cơ sở cho thế hệ thử nghiệm

2. Sơ đồ gói được áp dụng để cung cấp một hệ thống cấp bậc để phân chia một mô hình lớn để điều hướng dễ dàng hơn, và họ cũng có thể được sử dụng để chia một mô hình lớn thành nhiều file để hỗ trợ nhiều người dùng

3. Sơ đồ hoạt động được sử dụng để hiển thị thông tin chi tiết của từng trường hợp sử dụng liên quan đến các bước trên bằng cách sử dụng hệ thống. Các hoạt động được sử dụng không chỉ để hiển thị các bước kiểm tra, nhưng cũng cho thấy kết quả dự kiến hoặc các bước xác nhận. Làn bơi được sử dụng để phân biệt giữa



các bước thử nghiệm và các bước xác nhận. Các hoạt động có thể được chú thích bằng tài sản để cung cấp thông tin được sử dụng trong thế hệ thử nghiệm

4. Các sơ đồ lớp được sử dụng để xác định các lớp tương đương để đại diện cho các biến dữ liệu được sử dụng trong thử nghiệm. Các biến được mô tả như ghi chú trong một biểu đồ hoạt động để tham chiếu một lớp tương đương của các biến dữ liệu được định nghĩa trong một sơ đồ lớp

Trong cách tiếp cận này, mô hình use case đề cập đến một mô hình mô tả các use case từ quan điểm của một tester. Mỗi use case mô tả làm thế nào để kiểm tra các kịch bản khác nhau. Điều này khác với các trường hợp sử dụng để mô tả việc thực hiện của hệ thống. Trường hợp sử dụng của tester không mô tả làm thế nào để thực hiện từng trường hợp sử dụng, nhưng mô tả làm thế nào để kiểm tra từng use case bằng cách mô tả các yếu tố đầu vào và kết quả dự kiến

Trường hợp kiểm tra có thể được tự động tạo ra (với sự hỗ trợ công cụ) bằng cách sử dụng phương pháp tiếp cận MBT này. Mỗi thử nghiệm được thể hiện bằng hàng loạt các bước kiểm tra. Mỗi bước thử nghiệm được thể hiện bằng một hoạt động. Quyết định điểm trong biểu đồ hoạt động đại diện cho các kịch bản sử dụng thay thế. Điều kiện bảo vệ vào quá trình chuyển đổi cung cấp một cách để hạn chế các kịch bản thử nghiệm không khả thi. Hình 8.1, 8.2, và 8.3 cho thấy ví dụ về use case và hoạt động sơ đồ mà có thể được sử dụng để hỗ trợ thử nghiệm dựa trên mô hình







Hình 8.1 thể hiện một use case trừu tượng mà được mở rộng bằng cách sử dụng các trường hợp cụ thể khác nhau mà mô tả các hoạt động có thể có của các use case trừu tượng được mô hình hóa. Một use case trừu tượng thường có một biểu đồ hoạt động tạo ra, như thể hiện trong hình 8.2, trong đó một cách rõ ràng mô hình thực tế là có một số cách độc lập thay thế để kiểm tra các use case trừu tượng

Hình 8.3 là một ví dụ về một use case cụ thể cho thấy con đường thi thay thế các kịch bản khác nhau để kiểm tra một trường hợp sử dụng cụ thể . Lưu ý có một số hoạt động chung cho mỗi bài kiểm tra khác nhau và đường dẫn thi thay thế. Ví dụ ở hình 8.3 cũng giới thiệu một biến thử nghiệm như một lưu ý UML để khai báo các biến dữ liệu. Trong trường hợp này có hai biến được khai báo. Một biến đại diện cho các đối tượng "patient" và các biến khác đại diện cho các đối tượng "image" để được sử dụng. Mỗi khả năng của một patient hoặc image trong các lớp tương đương kết quả trong một trường hợp thử nghiệm khác nhau. Một hạn chế trong lưu ý phản ánh mối quan hệ giữa các image được chọn và patient được lựa chọn

Một sự chuyển tiếp trong sơ đồ hoạt động có chứa một ràng buộc trên các dữ liệu cho một trong những con đường thử nghiệm. Trong ví dụ này xác định rằng con đường thử nghiệm nên sử dụng một hình ảnh dữ liệu thử nghiệm với chất lượng hình ảnh kém. Các ngôn ngữ hạn chế là một Object Constraint Language (OCl), tập hợp với toán tử logic 'and', 'or' 'implies' và ‘xor', toán tử đơn 'not' và toán tử quan hệ '<>' và ‘=’ ; sử dụng thuật ngữ nghĩa và ngữ biến. Trong thế hệ kiểm tra, biến này được liên kết với một sự lựa chọn của một lớp tương đương thuộc vào tất cả các khó khăn trong con đường thử nghiệm tạo ra.

Mỗi hoạt động trong mô hình được chú thích với một mô tả và kết quả mong đợi và yêu cầu bên ngoài cũng liên quan. Những chú thích có thể được quy định trong sơ đồ như ghi chú hay chỉ định như các thuộc tính bằng cách sử dụng một trình soạn thảo tài sản gắn liền với từng hoạt động. Hình 8.4 cho thấy một ví dụ về thuộc tính của một trình soạn thảo hiển thị mô tả và thuộc tính kết quả mong đợi của một hoạt động. Các tính chất của sự lựa chọn biến và tính chất của các hoạt động có thể được thay thế vào các mô tả và kết quả dự kiến sẽ tạo ra các bước



thử nghiệm tạo ra. Sơ đồ hoạt động thể hiện trong hình 8.3 tạo ra chín con đường thử nghiệm để kiểm tra các use case. Mỗi con đường thử nghiệm có thể được nhân rộng để tạo các xét nghiệm khác nhau với dữ liệu patient và hình ảnh khác nhau. Ví dụ, đây là một trong những con đường thử nghiệm:

1. Hiện thị danh sách công việc2. Lựa chọn các giao thức mong muốn3. Nhìn vào các hình ảnh ${image} đến ${patient}4. Chất lượng hình ảnh không được cải thiện5. Thiết lập trạng thái chưa tối ưu

Ví dụ phức tạp hơn sẽ bao gồm nhiều điểm quyết định, hoặc các điểm quyết định có tham gia trở lại và chia cho các quyết định khác

Hình 8.4 Chỉnh sửa thuộc tính của hoạt động được lựa chọn



Các hoạt động cũng có thể tham khảo các trường hợp sử dụng khác, có thể được sử dụng để phá vỡ sơ đồ lớn hơn hoặc để đạt được tái sử dụng các mô hình hoạt động

Sử dụng mô hình use case để thử nghiệm dựa trên mô hình có nghĩa là chúng ta đang giải thích các mô hình use case cho các mục đích của thế hệ thử nghiệm. Điều này có nghĩa rằng các sai sót trong các mô hình có thể ngăn chặn khả năng tạo ra các thử nghiệm. Vì vậy, trước khi tạo kiểm tra, chúng tôi kiểm tra các mô hình cho các lỗi mà sẽ ngăn chặn các thế hệ của một thử nghiệm chính xác. Chúng ta kiểm tra các lỗi như: trường hợp sử dụng mà không có sơ đồ hoạt động, hoạt động không có hiệu ứng chuyển tiếp, những hạn chế bất hợp pháp, cấu trúc bất hợp pháp trong tờ khai ghi chú, và thiếu trạng thái start / stop

8.4 Ki m tra hi u su t và kh năng m r ng các yêu c uể ệ ấ ả ở ộ ầChúng ta mô tả ở đây một cách tiếp cận để xây dựng hiệu quả mô hình mô phỏng tối ưu hóa bằng cách sử dụng sơ đồ UML [Avritzer et at.2008] mà có thể được sử dụng để hỗ trợ việc thực hiện thử nghiệm và khả năng mở rộng các yêu cầu. Chúng ta chú thích các mô hình sơ đồ triển khai và các mô hình sơ đồ trình tự với lãi xuất và giá khởi hành, và tự động tạo ra các kịch bản mô hình hiệu suất từ các sơ đồ này. Các mô hình UML được sử dụng để xác định các luồng thông giữa các đối tượng cũng như tỷ lệ đến và đi. Ngoài ra, chúng tôi sử dụng một thư viện của các loại nút tối ưu hóa cho giải pháp mô phỏng. Một chế độ nền tảng trên các mô hình UML sơ đồ triển khai được kết hợp với một loại nút đó đã được thực hiện bởi một kỹ sư hoạt động chuyên môn

Sử dụng các mô hình UML được tạo ra bởi các kỹ sư yêu cầu xác định sơ đồ hoạt động phức tạp có tiềm năng tạo ra mô hình hiệu suất không được tối ưu hóa cho giải pháp, vì các quan điểm của các yêu cầu kỹ sư và kỹ sư thực hiện là khác nhau đáng kể. Trong khi các kỹ sư yêu cầu tập trung vào gợi ý càng nhiều chi tiết theo yêu cầu để xác định một cách chính xác một tính năng hệ thống nhất định, trọng tâm của các kỹ sư thực hiện là dựa trên mô hình tài nguyên nút cổ chai đến một giải pháp hiệu quả của các mô hình hiệu suất. Chúng tôi đề nghị rằng các kỹ sư yêu cầu tập trung nỗ lực vào việc phát triển sơ đồ trình tự tốt bằng cách hiểu được hành vi của ứng dụng, trong khi các kỹ sư thực hiện tập trung vào việc tìm



hiểu cách tốt nhất để mô hình các nút trên đó các ứng dụng được thực thi. Vì vậy, các kỹ sư hoạt động xây dựng các thư viện của các loại ghi chú. Kiến trúc sư phần mềm có thể sử dụng các thư viện của các loại nút khi phát triển các sơ đồ triển khai để thực hiện một ánh xạ giữa các thành phần phần mềm được sử dụng trong các trình tự sơ đồ mô hình và các loại nút

Sơ đồ hoạt động được sử dụng để xác định hành vi hoàn toàn hệ thống ở mức mô hình UML. Các sơ đồ hoạt động UML mô hình tiếp cận được thiết kế để được sử dụng bởi các yêu cầu kỹ sư và rất phù hợp với công việc yêu cầu kỹ thuật. Tuy nhiên, đối với các hệ thống công nghiệp lớn, đặc điểm kỹ thuật mô hình hoạt động dựa trên sơ đồ có thể không thích hợp để áp dụng cho những chuyển đổi mô hình đó nên kết quả trong một mô hình mô phỏng hiệu quả. Ví dụ, trong khi chúng tôi đã gặp phải những hạn chế để mô hình hành vi của thuật toán cân bằng tải năng động bằng cách sử dụng mô hình biểu đồ hoạt động UML, chúng ta có thể dễ dàng mô hình hóa các thuật toán sử dụng các phương pháp sau đây:

1. Xây dựng một thư viện các loại nút2. Xác định các mục tiêu của phân tích, và phát triển một tập hợp các trường

hợp sử dụng để mô tả các luồng thông báo3. Xây dựng các sơ đồ triển khai và lựa chọn những kiểu nút thích hợp4. Tạo ra các mô hình hiệu quả5. Đánh giá kết quả thu được từ mô hình hiệu quả để phân tích nếu các yêu

cầu của hệ thống được đáp ứng

8.5 Các quy t c ngón tay cái/ th c ti n t t nh tắ ự ễ ố ấTheo kinh nghiệm của chúng tôi, chúng tôi thấy một số lợi thế của việc sử dụng mô hình use case làm cơ sở cho mô hình dựa trên hệ thống thử nghiệm

Xem xét lại các mô hình

Chúng ta đã tìm thấy nó dễ dàng hơn cho các chuyên gia và các bên liên quan miền khác để xem xét các mô hình như sơ đồ use case hơn để xem xét thông số kỹ thuật kiểm tra. Một mô hình use case được viết từ quan điểm của người sử dụng cuối cùng, và điều này là quan điểm hiểu rõ nhất bởi các bên liên quan sản phẩm. xem xét lại các mô hình use case không chỉ tìm thấy những khoảng trống



trong các thử nghiệm, nhưng cũng phát hiện ra những lỗ hổng trong các yêu cầu, do đó, các mô hình có nhiều lợi ích

Các sơ đồ hoạt động mô tả các kịch bản chỉ định các xét nghiệm mong muốn trong cùng một cách như là một bộ kiểm tra, nhưng các sơ đồ được dễ dàng hơn để xem xét rằng, nói, 500 trang chi tiết kỹ thuật kiểm tra viết trong văn bản gốc. Có sơ đồ hoạt động ít hơn so với trường hợp kiểm tra, kể từ khi một biểu đồ hoạt động có thể đại diện cho nhiều trường hợp thử nghiệm vì các điểm quyết định và các biến thể được mô tả trong sơ đồ hoạt động

Chúng ta cũng đã quan sát thấy rằng sự phát triển của các mô hình use case lực lượng các yêu cầu để có sự không rõ ràng có thể kiểm chứng và các tài liệu về yêu cầu. Khi yêu cầu này không thể kiểm chứng hoặc không rõ ràng, hoặc yêu cầu được viết lại hoặc mô tả use case tài liệu một cách giải thích có thể kiểm chứng của yêu cầu

Cải thiện phạm vi thử nghiệm

Tạo bài kiểm tra từ sơ đồ hoạt động cho phép chúng ta xác định một cơ sở cho việc kiểm tra bảo hiểm. Chúng ta có thể chọn để tạo ra các xét nghiệm cho mỗi đường dẫn trong sơ đồ hoạt động hoặc mỗi chuyển tiếp trong sơ đồ, và chúng tôi có thể yên tâm rằng chúng tôi đã tạo ra các trường hợp thử nghiệm cho mỗi trường hợp này. Thiếu trường hợp thử nghiệm chỉ là một kết quả của các mô hình không đầy đủ, và các mô hình cung cấp minh bạch với những gì đang được thử nghiệm và những gì không được thử nghiệm

Lần theo yêu cầu

Các xét nghiệm hệ thống được yêu cầu để được ngược trở lại các yêu cầu để chứng minh việc xác minh các yêu cầu. Khi mô hình use case được sử dụng làm cơ sở để thử nghiệm dựa trên mô hình, lập bản đồ trở lại các yêu cầu là tự nhiên hơn với các loại mô hình như máy trạng thái, mà thường được kết hợp với các thành phần thực hiện



Từ trường hợp sử dụng có thể dễ dàng kết hợp với các yêu cầu thử nghiệm được tạo ra cũng có thể được dễ dàng hơn kết hợp với các yêu cầu. Khi nhiệm vụ được tạo ra, nó cũng có thể tự động tạo ra các dấu vết trở lại các yêu cầu liên quan

Bắt đầu sớm trong vòng đời phát triển

Đối với hầu hết các dự án chúng tôi làm việc trên, trường hợp mô hình sử dụng cho kiểm tra tự động được phát triển trong giai đoạn thử nghiệm hệ thống của dự án. Tuy nhiên, lại khuyên bạn nên bắt đầu từ sự phát triển của các mô hình use case càng sớm càng tốt trong dự án để các nhóm thử nghiệm có thể thực hiện việc định nghĩa các yêu cầu sớm trong tiến trình để đảm bảo rằng các yêu cầu có thể kiểm chứng được quy định

Như mô hình use case xảy ra sớm trong quá trình phát triển, chúng tôi mong đợi để xem nhiều cải tiến được mong đợi:

Cải thiện chất lượng tổng thể của các trường hợp sử dụng khách hàng nói chung độ chi tiết và các biến thể

Giảm trong nỗ lực xác nhận tổng thể cho thử nghiệm hệ thống Cải thiện giao tiếp với tất cả các bên liên quan về các yêu cầu vấn đề mà kết

quả từ việc phát triển các trường hợp sử dụng thử nghiệm Tìm lỗi càng sớm càng tốt vì bạn có thể thảo luận về mâu thuẫn và tác động

đến các mô hình quy trình làm việc khi nó được định nghĩa và phát hành

Cải thiện hiệu suất

Trong thử nghiệm truyền thống, thách thức là làm thế nào để tạo ra hiệu quả các bài kiểm tra. Trong thử nghiệm dựa trên mô hình, ngược lại, các vấn đề thường là làm thế nào để không tạo ra quá nhiều xét nghiệm. Các công cụ kiểm tra tạo mà chúng tôi sử dụng có tính năng cắt tỉa số lượng đường đi kiểm tra thông qua các mô hình đến các số hợp lý trong khi vẫn còn bao gồm tất cả các hoạt động hoặc tất cả các quá trình chuyển đổi thông qua các mô hình. Nó là dễ dàng hơn để tạo ra một số lượng lớn các thử nghiệm bằng cách sử dụng kỹ thuật này vì sử dụng phương pháp kiểm tra truyền thống [et al.1988 Ostrand]. Điều này tạo ra sự cần thiết cho một số loại chương trình ưu tiên để quyết định về các bài kiểm tra được tạo ra có ưu tiên cao hơn và cần được thực hiện đầu tiên. Mặc dù hiện tại chúng Phân tích yêu cầu phần mềm – Nhóm 10


tôi có thể quản lý số lượng các thử nghiệm, chúng tôi làm việc với nó sẽ là mong muốn để có thể gán độ ưu tiên cho các bài kiểm tra, Nhiều yếu tố ảnh hưởng đến các ưu tiên; Ví dụ, ưu tiên thời gian gần đây đã thay đổi mã, ưu tiên cho các kịch bản với những hậu quả nghiêm trọng hơn nếu thất bại. Cũng như chúng ta có thể mô hình các kịch bản thử nghiệm, nó có thể để thêm các tính năng để thực hiện thử nghiệm dựa trên rủi ro cũng

Chúng ta đã sử dụng sơ đồ hoạt động để mô tả sơ đồ use case, và chúng tôi đã khám phá bằng cách sử dụng sơ đồ trình tự để mô tả các kịch bản thử nghiệm. Điều này làm việc đầy đủ, nhưng chúng ta cũng có thể giống như để có thể sử dụng UML 2.0 ngữ nghĩa với những mảnh kết hợp để đại diện cho điều kiện thực hiện các trình tự. Trong một số trường hợp, biểu đồ trình tự có thể là một đại diện hiệu quả hơn các kịch bản

8.6 Tóm t tắTrong chương này, chúng tôi đã thảo luận về mối quan hệ giữa các yêu cầu kỹ thuật và thử nghiệm hệ thống. Yêu cầu các kỹ sư tạo ra các trường hợp sử dụng là cơ sở cho các mô hình được sử dụng bởi các kỹ sư kiểm tra để tạo ra các trường hợp thử nghiệm. Yêu cầu tốt là cần thiết cho việc áp dụng các phương pháp thử nghiệm dựa trên mô hình. Có kỹ sư thử nghiệm phát triển các mô hình và các xét nghiệm sớm trong dự án phát triển giúp để xem xét và làm rõ các yêu cầu

8.7 Câu h i th o lu nỏ ả ậ1. Một số hiện vật yêu cầu kỹ thuật xét nghiệm kiểm tra các kỹ sư sử dụng để phát triển thử nghiệm hệ thống là gì?

2. Những loại mô hình nào được sử dụng bởi các kỹ sư thử nghiệm để phát triển các bài kiểm tra?

3. Làm thế nào các kỹ sư có thể làm việc với các mô hình được tạo ra bởi các yêu cầu kỹ thuật để kiểm tra hiệu suất và khả năng mở rộng?


Documents

Bai-tap-3