Top 4 # Xem Nhiều Nhất Yêu Cầu Phi Chức Năng Của Phần Mềm Là Gì Mới Nhất 3/2023 # Top Like

Đã có một câu trả lời tuyệt vời của Aaronaught, nhưng vì đã có những câu trả lời khác, hiện đã bị xóa, hoàn toàn sai về yêu cầu phi chức năng là gì, tôi nghĩ sẽ hữu ích khi thêm một vài lời giải thích để tránh những sai lầm về những gì yêu cầu phi chức năng là.

Yêu cầu phi chức năng là “chất lượng hoặc tài sản mà sản phẩm phải có” . James Taylor nói rằng một yêu cầu phi chức năng “[…] dù sao cũng là một yêu cầu và điều quan trọng đối với khách hàng, đôi khi còn quan trọng hơn cả yêu cầu chức năng” . Sau đó, ông đưa ra hai ví dụ: logo của sản phẩm, độ chính xác và độ tin cậy của thiết bị. Cả hai ví dụ cho thấy rất rõ rằng:

Các yêu cầu phi chức năng không phải là một jibber-jabber tiếp thị như: “Internet ngày nay rất quan trọng và chúng tôi muốn có một trang web”.

Các yêu cầu phi chức năng là hoàn toàn khách quan.

Điểm cuối cùng là cần thiết. Nếu yêu cầu là chủ quan, nó không có gì để làm trong danh sách các yêu cầu. Không thể xây dựng các bài kiểm tra xác nhận từ một cái gì đó chủ quan . Mục đích duy nhất của danh sách các yêu cầu là liệt kê những kỳ vọng không mơ hồ của khách hàng. “Tôi muốn hình vuông này có màu đỏ” là một yêu cầu. “Tôi muốn hình vuông này có màu sắc đẹp” là một điều ước cần có lời giải thích.

Hãy nhớ rằng danh sách các yêu cầu giống như một hợp đồng (và trong hầu hết các trường hợp là một phần của hợp đồng). Nó được ký bởi khách hàng và công ty phát triển, và trong trường hợp kiện tụng, nó sẽ được sử dụng hợp pháp để xác định xem bạn đã thực hiện đúng công việc của mình chưa. Điều gì sẽ xảy ra nếu tôi đặt hàng cho bạn một sản phẩm phần mềm, xác định rằng “sản phẩm phải tuyệt vời” và từ chối thanh toán khi sản phẩm được hoàn thành, bởi vì đối với tôi, những gì bạn thực sự đã làm không phải là một sản phẩm tuyệt vời ?

Vì vậy, hãy xem một số ví dụ.

1. Sản phẩm phần mềm đáp ứng cho người dùng cuối.

Đây không phải là một yêu cầu. Không phải là một chức năng. Không phải là một chức năng. Nó không phải là một yêu cầu. Ở tất cả. Nó có giá trị bằng không. Bạn không thể kiểm tra xem hệ thống phần mềm có đáp ứng yêu cầu này trong quá trình kiểm tra xác nhận hay không. Không phải bạn – bộ phận QA, cũng không phải khách hàng.

2. Việc tải lại số liệu thống kê người dùng thực hiện 90% thời gian dưới 100 ms. khi được thử nghiệm trên máy với hiệu suất được chỉ định trong phụ lục G phần 2 và tải dưới 10% cho CPU, dưới 50% cho bộ nhớ và không có hoạt động đĩa R / W hoạt động.

Đó là một yêu cầu. Nếu phụ lục G phần 2 đủ chính xác, tôi có thể lấy máy có phần cứng tương tự và thực hiện kiểm tra xác nhận trong bộ phận QA và tôi sẽ luôn nhận được kết quả nhị phân: đã vượt qua hoặc thất bại.

Đây có phải là một yêu cầu chức năng? Không. Nó không chỉ định những gì hệ thống phải làm. Có thể có một yêu cầu chức năng trước đó, xác định rằng ứng dụng phần mềm phải có thể tải lại số liệu thống kê người dùng.

Đây có phải là một yêu cầu phi chức năng? Nó là. Nó chỉ định một thuộc tính mà sản phẩm phải có, tức là thời gian phản hồi tối đa / trung bình, được đưa ra ngưỡng phần trăm.

4. Cơ sở mã C # của sản phẩm tuân theo Quy tắc khuyến nghị tối thiểu của Microsoft và Quy tắc toàn cầu hóa của Microsoft.

Đây là một điều kỳ lạ. Cá nhân, tôi không muốn gọi nó là một yêu cầu, và đưa nó vào một tài liệu riêng quy định các tiêu chuẩn và thực tiễn tốt nhất.

5. Cửa sổ chính của ứng dụng có viền 10px màu xanh lam (# 00f) với các vòng tròn được tô màu hồng (#fcc), các vòng tròn đó được đặt ở cạnh trong của đường viền và có đường kính 3px, cách nhau 20px.

Đây là một yêu cầu, và không có chức năng. Nó chỉ định một cái gì đó chúng tôi có thể kiểm tra trong quá trình kiểm tra xác thực và nó chỉ định một thuộc tính của sản phẩm, chứ không phải những gì sản phẩm dự định làm.

6. Hệ thống theo dõi xe đo tốc độ với độ chính xác ± 0,016 dặm / giờ.

Cũng là một yêu cầu phi chức năng. Nó đưa ra một ngưỡng có thể đo lường được về độ chính xác của hệ thống. Nó không cho biết hệ thống phải làm gì, nhưng cho biết chính xác thì nó hoạt động như thế nào. Nhưng còn chờ gì nữa? Nó nói rằng hệ thống theo dõi xe đo tốc độ, phải không? Vì vậy, đó là một yêu cầu chức năng quá? Chà, không, vì chúng tôi nhấn mạnh vào độ chính xác của phép đo, chứ không phải trên thực tế là phép đo được thực hiện.

7. Hệ thống theo dõi xe đo tốc độ của xe.

Bây giờ nó là một yêu cầu chức năng. Nó không cho biết hệ thống hoạt động như thế nào, nhưng nó đang làm gì. Thông qua các yêu cầu chức năng, chúng ta có thể biết rằng hệ thống theo dõi xe đo tốc độ, năng lượng pin, áp suất của tôi không biết đèn nào sáng và có bật hay không.

8. Các trang của trang web mất 850 ms. để tải.

Đây không phải là một yêu cầu. Là cố gắng là một, nhưng hoàn toàn không hợp lệ. Làm thế nào bạn có tài sản này? Những trang nào? Tất cả các? Đã thử nghiệm qua mạng 1Gbps cục bộ trên máy khách lõi tứ và máy chủ tám lõi với SSD được sử dụng ở mức 2% hoặc qua modem của máy tính xách tay cũ và xảo quyệt trong khi trang web được lưu trữ bởi một máy chủ nhỏ được sử dụng ở mức 99% ? “Tải” nghĩa là gì? Có nghĩa là tải xuống trang? Tải về và hiển thị nó? Gửi yêu cầu POST với một số dữ liệu lớn, sau đó tải phản hồi và hiển thị nó?

Để kết luận, một yêu cầu phi chức năng luôn là một yêu cầu, có nghĩa là nó mô tả một cái gì đó là hoàn toàn khách quan và có thể được kiểm tra thông qua một bài kiểm tra xác nhận tự động hoặc bằng tay, nhưng thay vì nói những gì hệ thống đang làm, nó giải thích cách hệ thống đang làm một cái gì đó hoặc làm thế nào hệ thống là chính nó .

Quản lý các dự án công nghệ thông tin: Áp dụng các chiến lược quản lý dự án cho các sáng kiến ​​tích hợp phần cứng, phần cứng và tích hợp, James Taylor, ISBN: 0814408117.

1.1. Kiến thức cơ bản

Tổng quan

Định nghĩa

Yêu cầu cho 1 phần mềm cụ thể là tổng hợp những yêu cầu từ nhiều người khác nhau về tổ chức, mức độ chuyên môn và mức độ tham gia, tương tác với phần mềm trong môi trường hoạt động của nó.

Có thể kiểm chứng một cách riêng rẽ ở mức chức năng(yêu cầu chức năng) hoặc mức hệ thống(yêu cầu phi chức năng)

Cung cấp các chỉ số đánh giá độ ưu tiên về các mặt khi cân nhắc về nguồn tài nguyên.

Cung cấp các giá trị trạng thái để theo dõi tiến độ của dự án.

Phân loại

Theo sản phẩm và tiến trình

Yêu cầu sản phẩm: là những đòi hỏi hay ràng buộc mà phần mềm phải thực hiện.

Ví dụ: Trong Project 1:

Yêu cầu sản phẩm là xây dựng trang web Trường học điện tử với các tính năng như Giáo viên quản lý câu hỏi, đề thi; Học sinh tham gia làm bài; Admin duyệt câu hỏi của giáo viên trước khi đăng,…

Yêu cầu tiến trình: Phải thực hiện theo mô hình Agile. Sản phẩm cuối cùng bao gồm cả sản phẩm và backlog cho từng Sprint.

Theo chức năng

Yêu cầu chức năng: đặc tả các chức năng mà phần mềm phải thực hiện.

Yêu cầu phi chức năng: là các ràng buộc về giải pháp và chất lượng(hiệu năng, việc bảo trì, độ an toàn, bảo mật,…).

Yêu cầu đặc tả các thuộc tính nổi bật: là các đặc tả cho các thuộc tính phụ thuộc vào sự vận hành,… đặc biệt là kiến trúc hệ thống. Các thuộc tính này không thể xác định được cho từng thành phần đơn lẻ.

Theo tính kiểm định

Mơ hồ, không thể kiểm định

Rõ ràng, định lượng và có thể kiểm định được.

Theo phạm vi đặc tả

Yêu cầu hệ thống: đặc tả các cấu hình, cơ sở hạ tầng, phần cứng, phần mềm, con người, kỹ thuật,… của toàn bộ hệ thống.

Yêu cầu phần mềm: đặc tả các chức năng, giao diện,… của các cấu phần phần mềm.

1.2. Tiến trình yêu cầu phần mềm

Vị trí trong mô hình tiến trình

Xuất phát từ giai đoạn khởi tạo dự án, cho tới khi hoàn thiện các tiến trình trong vòng đời phát triển của phần mềm. Không chỉ là các hoạt động bề nổi nhìn thấy được.

Được nhận biết như phần cấu hình của mọi việc, và được quản lí như việc quản lí các cấu hình; hoặc là sản phẩm của các quá trình trong vòng đời phát triển.

Được thiết kế theo từng tổ chức và hoàn cảnh của từng dự án.

Các nhân tố tham gia

Người dùng: vận hành phần mềm.

Khách hàng: gồm những người được hưởng mục tiêu cuối cùng của phần mềm, những giá trị thương mại mà phần mềm hướng đến.

Nhà phân tích thị trường: phân tích nhu cầu thị trường và tương tác với bên đại diện khách hàng.

Đại diện pháp lý: kiểm soát việc tuân thủ quy định, quy ước chung, quy định pháp lý.

Kỹ sư phần mềm: thu lợi nhuận hợp pháp từ việc phát triển phần mềm.

Quản lý và Hỗ trợ quy trình

Quản lí nguồn tài nguyên được sử dụng trong các tiến trình.

Cân đối nguồn nhân lực, tài chính, đào tạo và công cụ.

Chất lượng và cải tiến

Xác định vai trò của tiến trình xây dựng yêu cầu về các mặt chi phí, thời gian và sự thoả mãn của khách hàng với sản phẩm.

Định hướng tiến trình theo các chuẩn chất lượng và xây dựng mô hình cải tiến cho phần mềm và hệ thống.

Bao gồm:

Độ bao phủ theo các mô hình và chuẩn cải tiến.

Việc đo đạc và đánh giá tiến trình.

Việc thực hiện và lên kế hoạch cải tiến.

Việc cài đặt và lên kế hoạch cho an ninh.

1.3. Thu thập yêu cầu

Tạo được niềm tin của khách hàng khi họ được tham gia vào giai đoạn thu thập yêu cầu.

Giảm việc phải làm lại trong quá trình phát triển

Quá trình phát triển sẽ nhanh hơn, giảm được những chi phí cho những yêu cầu không cần thiết.

Hạn chế phạm vi hệ thống bị phình rộng.

1.3.1. Nguồn yêu cầu – Requirements Sources

Các yêu cầu có rất nhiều nguồn trong đặc thù phần mềm và điều quan trọng là tất cả các nguồn tiềm năng cần được xác minh và đánh giá. Phần này nhằm nâng cao nhận thức của các nguồn khác nhau của yêu cầu phần mềm và những framework để quản lý chúng. Những điểm chính của nguồn yêu cầu bao gồm:

Mục tiêu – Goal. Các mục tiêu về giá trị và giá thành thường mơ hồ, không rõ ràng. Kĩ sư phần mềm cần chú ý để xác định rõ các mục tiêu đó. Nghiên cứu tính khả thi là sẽ giúp giảm giá thành của quá trình phát triển. Ví dụ kỹ sư phần mềm cần xác định chi phí xây dựng server với chi phí đi mua cái nào sẽ tối ưu hơn để lựa chọn.

Hiểu biết về các lĩnh vực. Các kỹ sư phần mềm cần có kiến thức về các lĩnh vực như: mua sắm, ngân hàng, chăm sóc sức khỏe,… lĩnh vực mà phần mềm được sử dụng. Việc hiểu biết về các lĩnh vực sẽ giúp cho người thu thập yêu cầu thu thập được những thông tin chính xác cao.

Nguyên tắc kinh doanh. Là những điều kiện hoặc các ràng buộc được xác định để các doanh nghiệp hoạt động được. “Một sinh viên không thể đăng ký vào các khóa học học kỳ tiếp theo nếu vẫn còn một số môn chưa thanh toán học phí” sẽ là một ví dụ của nguyên tắc kinh doanh đó cho các phần mềm đăng ký môn học của trường đại học.

Môi trường vận hành. Các yêu cầu sẽ được bắt nguồn từ môi trường mà trong đó phần mềm sẽ được thực thi. Ví dụ như ràng buộc thời gian trong phần mềm thời gian thực hoặc ràng buộc hiệu năng trong môi trường kinh doanh.

Môi trường tổ chức. Phần mềm thường có thể bị ràng buộc bởi cấu trúc, văn hóa và tổ chức chính trị. Các kỹ sư phần mềm cần phải hiểu biết về chúng, phần mềm không nên ép buộc thay đổi ngoài ý muốn trong quá trình kinh doanh.

1.3.2. Kỹ thuật thu thập- Elicitation Techniques

Phỏng vấn. Phỏng vấn là cách truyền thống để thu thập yêu cầu. Ưu điểm: Thu thập được được những thông tin trực tiếp các thông tin có chất lượng cao, tính chân thực và độ tin cậy có thể kiểm nghiệm được trong quá trình phỏng vấn. Nhược điểm: Đòi hỏi người phỏng vấn phải có trình độ cao, am hiểu, có kỹ năng xử lý các tình huống. Khó triển khai được trên quy mô rộng. Tiếp cận khách hàng là việc tương đối khó vì cần hẹn trước.

Kịch bản. Kỹ sư phần mềm cung cấp một hệ thống các câu hỏi bằng việc sử sụng các câu hỏi như “What if” và “How is this done”. Các loại kịch bản phổ biến được sử dụng là mô tả các trường hợp sử dụng. Ví dụ: Điều gì sẽ xảy ra với phần mềm khi bị mất kết nối mạng,…

Các bản mẫu. Kỹ thuật này sẽ làm rõ các yêu cầu không rõ ràng. Có thể sử dụng mockup hoặc màn hình thiết kế hoặc các bản thử nghiệm để xác minh những yêu cầu từ khách hàng. Ví dụ: Thu thập các yêu cầu về thiết kế hoặc chức năng của phần mềm.

Cuộc hội họp. Một nhóm người sẽ mang lại nhiều cái nhìn sâu sắc hơn vào các yêu cầu phần mềm. Mọi người sẽ cùng suy nghĩ, tinh chỉnh các yêu cầu. Lợi thế của phương pháp này là các yêu cầu mâu thuẫn sẽ dễ dàng xử lý hơn.

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

Nhằm mục đích:

Phát hiện và giải quyết xung đột giữa các yêu cầu

Tìm ra những giới hạn của phần mềm và cách phần mềm tương tác với tổ chức và môi trường hoạt động của nó.

Nghiên cứu các yêu cầu hệ thống để lấy được các yêu cầu phần mềm.

1.4.1. Mô hình hóa khái niệm

Xây dựng các mô hình trong một vấn đề thực tế là chìa khóa của phân tích yêu cầu phần mềm. Mục đích của nó là để hiểu rõ về những vấn đề xảy ra cũng như miêu tả được giải pháp của vấn đề. Do dó mô hình khái niệm báo gồm các mô hình của các thực thể từ miền vấn đề, cấu hình để phản ánh các mối quan hệ trong thế giới thực và ràng buộc. Có rất nhiều loại mô hình có thể được phát triển bao gồm biểu đồ use case, mô hình luồng dữ liệu, mô hình trạng thái, mô hình dựa trên mục tiêu, tương tác người dùng, mô hình dữ liệu, mô hình đối tượng… Các yếu tố ảnh hưởng đến sự lựa chọn mô hình bao gồm:

Vấn đề tự nhiên. Một số loại phần mềm đòi hỏi một số khía cạnh được phân tích đặc biệt nghiêm ngặt. ví dụ mô hình trạng thái và mô hình tham số của phần mềm thời gian thực quan trọng hơn so với hệ thống thông tin.

Sự thành thạo của kỹ sư phần mềm. Kỹ sư phần mềm có kinh nghiệm sẽ lựa chọn các mô hình hay phương pháp để được kết quả tốt hơn.

Các yêu cầu về quy trình của khách hàng. Khách hàng có thể áp đặt các ký hiệu ưa thích của họ hoặc phương pháp hoặc ngăn cản bất cứ cái gì mà họ thấy không quen thuộc. Nhân tố này có thể xung đột với các nhân tố trước đó.

1.4.2. Thiết kế kiến trúc và phân bổ yêu cầu

Thiết kế kiến trúc là điểm mà tại đó quá trình yêu cầu trùng lặp với phần mềm hoặc các hệ thống thiết kế. Trong nhiều trường hợp, các hành vi kỹ sư phần mềm như là kiến trúc sư phần mềm bởi vì quá trình phân tích và xây dựng các yêu cầu đòi hỏi rằng các thành phần kiến trúc / thiết kế đó sẽ chịu trách nhiệm đáp ứng các yêu cầu được xác định. Phân bổ là quan trọng để cho phép phân tích chi tiết các yêu cầu. Do đó, ví dụ, khi một bộ các yêu cầu đã được phân bổ cho một thành phần, các yêu cầu cá nhân có thể được phân tích thêm để khám phá thêm các yêu cầu về cách thành phần tương tác với thành phần khác để đáp ứng các yêu cầu được giao. Trong các dự án lớn, phân bổ thúc đẩy một vòng mới của phân tích cho mỗi hệ thống. Thiết kế kiến trúc được xác định chặt chẽ với các mô hình khái niệm.

1.4.3. Đàm phán, giải quyết các xung đột giữa các yêu cầu

1.4.4. Phân tích hình thức – Formal Analysis

Formal Analysis đã có một tác động trên một số lĩnh vực ứng dụng, đặc biệt là các hệ thống toàn vẹn cao. Các hình thức thể hiện của các yêu cầu đòi hỏi một ngôn ngữ với ngữ nghĩa định nghĩa chính thức(vd: Ngôn ngữ Z). Việc sử dụng một phân tích hình thức cho các yêu cầu biểu hiện có hai lợi ích. Đầu tiên, nó cho phép các yêu cầu thể hiện bằng ngôn ngữ được xác định một cách chính xác và rõ ràng, do vậy tránh được khả năng hiểu sai. Thứ hai, yêu cầu có thể được lý giải trên, cho phép đặc tính mong muốn của phần mềm cụ thể để chứng minh. Phân tích hình thức nhất là tập trung vào giai đoạn khá muộn của phân tích yêu cầu.

1.5. Đặc tả yêu cầu

Đặc tả yêu cầu là một mô tả của hệ thống phần mềm được phát triển, đưa ra các yêu cầu chức năng và phi chức năng, và có thể bao gồm một tập hợp các ca sử dụng (use cases) để mô tả tương tác giữa người dùng với phần mềm. Đặc tả yêu cầu tạo cơ sở cho một thỏa thuận giữa khác hàng và nhà cung cấp về những gì phần mềm đã làm được tốt cũng như những gì chưa được như mong đợi. Nó cũng cung cấp một cơ sở thực tế để ước tính giá thành sản phẩm, rủi ro và lịch trình. Đối với các hệ thống phức tạp có 3 loại tài liệu được tạo ra là: định nghĩa hệ thống, yêu cầu hệ thống và các yêu cầu phần mềm. Đối với sản phẩm phần mềm đơn giản chỉ cần 1 trong 3 tài liệu.

1.5.1. Tài liệu đặc tả hệ thống.

Còn được biết như là tài liệu yêu cầu người dùng hay là tài liệu vận hành ghi lại những yêu cầu hệ thống. Nó xác định yêu cầu hệ thống ở mức cao với cách nhìn từ domain. Độc giả của tài liệu bao gồm hệ thống người dùng hoặc khác hàng. Vì vậy nội dung của nó phải được diễn đạt bằng những từ ngữ của những lĩnh vực riêng. Tài liệu sẽ liệt kê các yêu cầu hệ thống cùng với các thông tin cơ bản về đối tượng hệ thống, môi trường mục tiêu của nó, giả định và các yêu cầu phi chức năng. Nó có thể bao gồm mô hình khái niệm được thiết kế để minh họa cho ngữ cảnh hệ thống, sử dụng kịch bản, và các miền thực thể chính, cũng như luồng công việc.

1.5.2. Đặc tả yêu cầu hệ thống

Người phát triển những dự án phần mềm có những thành phần thuần túy là software và những phần non-software – ví dụ như máy bay hiện đại thường tách biệt yêu cầu hệ thống với yêu cầu phần mềm. Theo quan điểm này, yêu cầu hệ thống được quy định, các yêu cầu phần mềm có nguồn gốc từ các yêu cầu hệ thống, và sau đó các yêu cầu đối với các thành phần phần mềm được xác định.

1.5.3. Đặc tả yêu cầu phần mềm

1.6. Thẩm định yêu cầu

Tất cả tài liệu yêu cầu cần được thông qua quá trình thẩm định và kiểm duyệt. Vậy Thẩm định yêu cầu là j?

Khái niệm

Thẩm định yêu cầu quan tâm đến việc chứng tở rằng các yêu cầu định nghĩa được hệ thống mà khách hàng thực sự muốn. Các yêu cầu phải được thẩm định để đảm bảo rằng người thực thi, người lập trình hiểu được yêu cầu.

Việc thẩm định phải đảm bảo dễ hiểu, nhất quán và hoàn thiện

Thẩm định yêu cầu được quan tâm đến quá trình kiểm tra tài liệu yêu cầu có đảm bảo đầu ra là 1 phần mềm hoàn chỉnh, đúng đắn.

Các kĩ thuật thẩm định yêu cầu

xem lại yêu cầu

sử dụng phiên bản mẫu, thử nghiệm

thầm định mô hình

kiểm thử chấp thuận

1.6.1. Xem lại yêu cầu

Có lẽ phương tiện phổ biến nhất của việc thẩm định là sự kiểm tra hoặc xem lại các tài liệu yêu cầu. Một nhóm người được giao nhiệm vụ tìm các lỗi, sai sót, thiếu sự rõ ràng, và độ lệch so với tiêu chuẩn. Thành phần của nhóm này đặc biệt quan trọng (ít nhất cần có đại diện khách hàng để có được định hướng đúng đắn), và họ có thể cung cấp sự hướng dẫn trong việc tìm kiếm thông tin chuẩn xác. Việc nhận xét có thể được thành lập sau khi hoàn thành các tài liệu định nghĩa hệ thống, các tài liệu đặc tả hệ thống, đặc tả cơ bản cho 1 phiên bản mới sắp phát hành, hoặc bất kì bước nào khác trong quá trình làm yêu cầu. Ví dụ. Công ty đưa ra 1 tiêu chuẩn chung khi làm tài liệu, các kí hiệu, mô hình đối tượng, cần phải được thống nhất, Nhưng 1 nhân viên mới vào chưa nắm rõ được các tiêu chuẩn này nên làm sai 1 số chỗ. Phương pháp xem lại yêu cầu sẽ giúp tìm ra sai sót này giúp đồng nhất trong quá trình viết tài liệu.

1.6.2. Sử dụng phiên bản mẫu, thử nghiệm

1.6.3. Thẩm định mô hình

Thẩm định model là thẩm định lại chất lượng các model(information model, behavior model, structure model) đã được phát triển trong suốt quá trình phân tích. Ví dụ trong mô hình đối tượng, chúng ta phải kiểm tra xem liên kết giữa các đối tượng, giữa sự trao đổi dữ liệu giữa các đối tượng có chuẩn xác không. Các model phải đủ các tiêu chí: Hoàn thiện, nhất quán và chuẩn xác.

1.6.4. Kiểm thử chấp thuận

Một đặc điểm quan trọng của yêu cầu phần mềm là nó có thể kiểm định rằng sản phẩm cuối cùng phải thỏa mãn các yêu cầu. Viết các testcase dành cho các yêu cầu để kiểm tra khả năng đáp ứng được các yêu cầu end-user. Sản phẩm cuối cùng phải thỏa mãn các testcase

1.7. Khảo sát hiện trạng

Thực trạng có rất nhiều thay đổi, do đó quản lí những thay đổi và duy trì những yêu cầu là chìa khóa quyết định sự thành công của phần mềm. Ví dụ : không phải tổ chức nào cũng có thói quen làm tài liệu cũng như quản lý yêu cầu đặc biệt với những công ty mới thành lập hoặc những công ty có nguồn nhân lực hạn chế. Khi những công ty này mở rộng, số lượng khách hàng trở lên lớn hơn, sản phẩm của họ bắt đầu phát triển, thì lúc này việc tìm lại những yêu cầu và thúc đẩy thêm nhiều tính năng để đáp ứng nhu cầu thị trường và sự thay đổi của môi trường là rất cần thiết. Do đó, tài liệu yêu cầu và quản lí những thay đổi là chìa khóa cho sự thành công của bất kì quá trình yêu cầu nào.

1.7.1. Quản lý thay đổi

1.7.2. Định danh yêu cầu

Đinh danh yêu cầu cần được định nghĩa, ghi nhân và cập nhật như phần phần mềm trong quá trình phát triển và bảo trì.

Bao gồm:

việc phân loại yêu cầu Ví dụ: functional requirement and non-functional requirement

phương pháp xác minh Ví dụ: . xác minh bằng cách xem lại yêu cầu . xác minh bằng sử dụng phiên bản mẫu, thử nghiệm

thầm định mô hình

kiểm thử chấp thuận

kế hoạch kiểm thử

thuộc tính duy nhất để thuận tiện cho việc tham chiếu giữa các yêu cầu và lần vết. Ví dụ: thông tin của yêu cầu duy nhất để tiện cho việc thêm và chỉnh sửa sau khi có sự thay đổi.

1.7.3. Lần vết yêu cầu

Truy vết để thực hiện phân tích những ảnh hưởng khi yêu cầu thay đổi.

Ngược lại. một yêu cầu nên được truy đến những yêu cầu khác nhằm thỏa mãn nó(ví dụ: từ yêu cầu hệ thống đến yêu cầu phần mềm)

1.7.4. Ðánh giá yêu cầu

Đánh giá kích thước của sự thay đổi yêu cầu.

Ví dụ: đánh giá độ khó khăn của việc triển khai thay đổi yêu cầu, đánh giá xem nó ảnh hưởng tới những phân hệ nào trong hệ thống.

Đánh giá chi phí cho việc phát triển hoặc duy trì 1 yêu cầu

Ví dụ: đánh giá nguồn lực, chi phí, mandate cho việc thay đổi yêu cầu.

1.8. Công cụ sử dụng trong việc làm yêu cầu phần mềm

Công cụ cho việc vẽ model (CASE tool , starUML )

Testing được chia thành 2 loại:

Kiểm thử chức năng

Kiểm thử phi chức năng

Kiểm thử chức năng là gì?

Kiểm thử chức năng, như tên cho thấy, là xác nhận tất cả các chức năng của hệ thống. Nó đánh giá ứng dụng và xác nhận liệu ứng dụng có đang hoạt động theo yêu cầu hay không.

Các loại Kiểm thử chức năng bao gồm:

Kiểm thử đơn vị (Unit Testing)

Kiểm thử khói (Smoke Testing – check nhanh xem hệ thống có khởi động được hay không)

Kiểm thử độ tỉnh táo (Sanity Testing – check nhanh xem sau khi sửa đổi thì function có hoạt động như mong muốn hay không)

Kiểm thử giao diện (Interface Testing)

Kiểm thử tích hợp (Integration Testing)

Kiểm thử hệ thống (Systems Testing)

Kiểm thử hồi quy (Regression Testing)

Kiểm thử chấp nhận (Acceptance testing)

Kiểm thử phi chức năng là gì?

Ứng dụng làm việc trong điều kiện bình thường như thế nào?

Ứng dụng hành xử như thế nào khi quá nhiều người dùng đăng nhập đồng thời?

Ứng dụng có thể chịu được tải lớn không?

Ứng dụng bảo mật tới mức nào?

Ứng dụng có thể phục hồi từ bất kì sự cố nào hay không?

Ứng dụng có thể hành xử đồng nhất trong nhiều môi trường hay OS khác nhau không?

Đưa ứng dụng lên hệ thống khác nhau có dễ dàng không?

Tài liệu/Hướng dẫn sử dụng được cung cấp kèm ứng dụng có dễ hiểu hay không?

2. Kiểm thử tải lượng: Đánh giá xem liệu hiệu suất của hệ thống có được như mong đợi trong điều kiện bình thường và điều kiện thử nghiệm hay không. Những điểm mấu chốt là:

3. Kiểm thử áp lực: Đánh giá xem liệu hiệu suất của hệ thống có được như mong đợi sử dụng hết tài nguyên hay không. Những điểm mấu chốt là:

Áp dụng một lượng lớn dữ liệu và kiểm tra giới hạn nơi các phần mềm bị lỗi.

Kích thước cơ sở dữ liệu tối đa được tạo ra và nhiều truy vấn của khách hàng vào cơ sở dữ liệu hoặc tạo báo cáo lớn hơn.

Ví dụ: Nếu ứng dụng đang xử lý cơ sở dữ liệu để tạo ra một báo cáo, một bài kiểm thử quy mô sẽ thường là sử dụng một tập kết quả lớn và kiểm tra báo cáo được in một cách chính xác hay không.

5. Kiểm thử tính khả dụng: Xem xét tính dễ sử dụng cho người dùng. Những điểm mấu chốt là:

6. Kiểm thử giao diện người dùng: Đánh giá GUI. Những điểm mấu chốt là:

7. Kiểm thử tính tương thích: Đánh giá xem ứng dụng có tương thích với phần cứng/phần mềm khác mà có cấu hình tối thiểu hoặc tối đa hay không. Những điểm mấu chốt là:

Ngắt điện ở máy khách trong khi ứng dụng đang làm việc.

Con trỏ và khóa trong cơ sở dữ liệu không hợp lệ.

Tiến trình Cơ sở dữ liệu bị hủy bỏ hoặc chấm dứt trước khi hoàn thành.

Con trỏ, các trường và giá trị của Cơ sở dữ liệu bị phá hoại thủ công và trực tiếp từ server.

Ngắt kết nối dây mạng, tắt bật các router và máy chủ mạng.

9. Kiểm tra tính ổn định: Đánh giá và xác nhận rằng phần mềm được cài đặt và tháo gỡ một cách chính xác. Những điểm mấu chốt là:

Xác nhận rằng các thành phần hệ thống được cài đặt đúng trên phần cứng được chỉ định.

Xác nhận có thể điều hướng trên máy tính mới, cập nhật các bản cài đặt hiện có và các phiên bản cũ.

Xác nhận rằng nếu thiếu không gian đĩa thì cũng không xảy ra hành vi khó chấp nhận.

10. Kiểm tra tài liệu: Đánh giá các tài liệu và hướng dẫn sử dụng.

Xác nhận rằng các tài liệu được tuyên bố có sẵn trong sản phẩm.

Xác nhận tất cả những gì hướng dẫn sử dụng, hướng dẫn cài đặt, file ghi chú, thay đổi cập nhật và trợ giúp trực tuyến đều sẵn sàng.

Kết luận:

Kiểm thử phi chức năng là khía cạnh rất quan trọng của việc đảm bảo chất lượng và giống như Kiểm thử chức năng, Kiểm thử phi chức năng cũng đòi hỏi chiến lược và lập kế hoạch. Chúng ta có thể bao gồm thông tin chi tiết về Kiểm thử phi chức năng trong kế hoạch kiểm thử hoặc có thể viết ra một chiến lược riêng biệt và lên kế hoạch cho nó. Trong cả hai trường hợp, mục tiêu là để có thể bao quát được tất cả các khía cạnh phi chức năng của phần mềm.

All Rights Reserved

Trong nhiệm vụ chung là bảo vệ cơ thể, mỗi loại bạch cầu có một cấu trúc gắn liền với tính năng và nhiệm vụ khác nhau:

Bạch cầu hạt trung tính: Tạo ra hàng rào đầu tiên bảo vệ cơ thể chống lại sự xâm nhập của các vi khuẩn sinh mủ do bạch cầu trung tính có khả năng vận động và thực bào rất mạnh.

Bạch cầu hạt ưa acid: Chức năng chủ yếu là khử độc các protein và các chất lạ do trong các lysosome chứa các enzyme như oxidase, peroxidase và phosphatase.

Bạch cầu hạt ưa base: là loại ít gặp nhất trong các loại bạch cầu, đóng vai trò quan trọng trong một số phản ứng dị ứng.

Bạch cầu lympho: Có hai loại là bạch cầu lympho T và bạch cầu lympho B.

Bạch cầu lympho T : bạch cầu Lympho T sau khi được hoạt hóa sẽ tấn công các kháng nguyên xâm nhập vào cơ thể bằng cách tấn công trực tiếp hoặc giải phóng một chất gọi là lymphokin. Lymphokin sẽ thu hút bạch cầu hạt đến xâm nhập, tấn công kháng nguyên.

Bạch cầu lympho B có vai trò sản xuất ra kháng thể.

Bạch cầu mono: có kích thước lớn, tại mô liên kết của các cơ quan sẽ phát triển thành các đại thực bào. Các đại thực bào này sẽ ăn các phân tử các phân tử có kích thước lớn, các mô hoại tử, do đó có tác dụng dọn sạch các vùng mô tổn thương. Bên cạnh đó, bạch cầu mono còn đóng vai trò quan trọng trong khởi động quá trình sản xuất kháng thể.

Chỉ số WBC là gì?

Chỉ số Wbc (White Blood Cell) là chỉ số thể hiện số lượng bạch cầu trong một thể tích máu. Giá trị này bình thường trong khoảng 4.000- 10.000 tế bào/mm3. Nếu số lượng bạch cầu cao hơn khoảng trên gọi là tình trạng tăng bạch cầu, thấp hơn khoảng trên là tình trạng giảm bạch cầu. Đây là một chỉ số quan trọng, dựa vào chỉ số này tăng hoặc giảm thầy thuốc có thể tiên lượng được tình trạng sức khỏe của người bệnh.