Requirement Engineering

bản. Kịch bản là một thể hiện của những những gí sẽ xảy ra khi một tác nhân tương tác với hệ thống. Ví dụ một kịch bản trong hệ thống khám bệnh ƒ Một bệnh nhân gọi đến một phòng khám cho việc kiểm tra sức khỏe định kỳ ƒ Người tiếp nhận tìm trong sổ hẹn thơi gian còn trống ƒ Người tiếp nhận lập lịch cho thơi gian trống đó cho người gọi ™ Use case là một sự tổng kết cho những nhiệm vụ đơn hay là những đích (goal). Một actor là một vai trò mà những người hay các đối tương thực hiện. Actor kích hoạt sự kiện 36 Thu nhận yêu cầu Use case và actor 37 Use case khám bệnh 38 myriam.lewkowicz@utt.fr 39 Thu nhận yêu cầu Giải thích ™ Hệ thống có biên (boundary) hình chữ nhật phân tách hệ thống khám bệnh với những actor bên ngoài ™ Một sự tổng quát hóa (generalization) use case cho biết một một use case la một một loại đặc biệt của một use case khác theo quan hệ cha con ™ Quan hệ include phân tách một use case thành 2 use khá h ó hữ dù khi hâ tá hcaes c n au, n u ng p n c ra use case dùng chung ™ Một quan hệ extend chỉ ra một use case là một mức biến đổi của một use case khác. Điểm mở rộng (extension point) xác định khi nào use case mở rộng 40 là thích hợp myriam.lewkowicz@utt.fr 41 Thu nhận yêu cầu Lợi ích khi dùng biểu đồ use case ™ Xác định các đặc trưng (yêu cầu). Những use case ới thườ t hữ ê ầ ới khi hệm ng ạo ra n ng y u c u m thống được phân tích và hình thành thiết kế ™ T ền thông ới khá h hàng dễ dàngruy v c ™ Hỗ trợ việc tạo test case. Các kịch bản cho use case có thể giúp cho việc tạo ra bộ test case (test suite) cho những kịch bản này 42 myriam.lewkowicz@utt.fr 43 44 Update Benefits description myriam.lewkowicz@utt.fr 45 Thu nhận yêu cầu Mô hình động: Sequence Diagram ™ Biểu đồ trình tự (Sequence Diagram) ƒ Hình ảnh của sự tương tác giữa những đối tượng qua những giai đoạn thời gian xác định ™ Sự hoạt động (Activation) ƒ Đối tượng thực hiện một hoạt động trong một khoảng thời gian ™ Thông điệp (Messages) ƒ Là những thông tin mà các đối tượng truyền thông với nhau 46 myriam.lewkowicz@utt.fr 47 48 Thu nhận yêu cầu Giải thích ™ Thời gian sống (lifeline) ™ Lặp (iteration) giao tiếp với chính nó ™ [ ] là một điều kiện ™ Chú thích 49 Thu nhận yêu cầu Biểu đồ cộng tác ™ Biểu đồ cộng tác (Collaboration diagrams) còn gọi là biể đồ tươ tá (i t ti di ) u ng c n erac on agrams . Chúng truyền đạt cùng thông tin như biểu đồ tuần tự nhưng nó tập trung vào vai trò của đối tượng thay vì thời gian mà thông điệp được gởi ™ Mỗi thông điệp có một số trình tự (sequence number) 50 Biểu đồ cộng tác 51 Thu nhận yêu cầu Biểu đồ trạng thái ™ Biểu đồ trạng thái (Statecharts diagram) ™ Các đối tượng có hành vi và trạng thái. Trạng thái của đối tượng phụ thuộc vào tình trạng hay hoạt động hiện thời của nó. Một biểu đồ trạng thái chỉ ra trạng thái có thể của đối tượng và sự dịch chuyển mà gây ra biến đổi trạng thái ™ Trạng thái (State) ƒ Một tình trạng diễn ra trong đời sống của một đối tượng, nó thỏa mãn vài điều kiện, thực hiện vài hoạt động hay chờ đợi vài sự kiện ™ Dịch chuyển trạng thái (State Transition ƒ Biến đổi thuộc tính của một đối tượng hay là liên kết của một đối tượng với những đối tượng khác ƒ Điều kiện cổng (guard condition) và hoạt động (action) ™ Sự kiện (Event) ƒ Một điểu gì đó diễn ra ở thời điểm xác định 52 Thu nhận yêu cầu Example ™ Our example diagram models the login part of an online banking system . ƒ Logging in consists of entering a valid social security number and personal id number, then submitting the information for validation. ƒ Logging in can be factored into four non-overlapping states: Getting SSN, Getting PIN, Validating, and Rejecting. ƒ From each state comes a complete set of transitions that d h betermine t e su sequent state. 53 54 Thu nhận yêu cầu Biểu đồ hoạt động ™ Biểu đồ hoạt động (activity diagram) diễn tả luồng hoạt động. ™ Biểu đồ hoạt động và biểu đồ trạng thái (statechart diagram) Biể đồ t thái tậ t à ột đối tượƒ u rạng p rung v o m ng ƒ Biểu đồ hoạt động tập trung vào luông những hoạt động trong một quá trình đơn. Nó chỉ ra những hoạt động này phụ th ộ à ột h t độ khá hư thế àu c v o m oạ ng c n n o ™ Ví dụ: rút tiền từ tài khoản nhà băng qua một ATM ƒ Các actor: khách hàng, ATM, nhà băng 55 myriam.lewkowicz@utt.fr 56 Thu nhận yêu cầu Biểu đồ lớp ™ Biểu đồ lớp cho một cái nhìn tổng quát về một hệ thố bă á lớ à hệ iữ húng ng c c p v quan g a c ng ™ Biểu đồ lớp là biểu đồ tĩnh chúng thể hiện những tương tá nhưng hỉ những gì ả khi húng c c ra x y ra c tương tác 57 Thu nhận yêu cầu Class notations myriam.lewkowicz@utt.fr 58 Mẫu của class (Class stereotypes) myriam.lewkowicz@utt.fr 59 Thu nhận yêu cầu Ví dụ ™ Mô hình lớp đơn hàng cho cửa hàng bán lẻ ƒ Lớp trung tâm là lớp Order ƒ Kết hớp với nó là lớp Customer mua và bán • Thanh toán thoe 3 loại: Cash Check hay Credit , , . • Order chứa OrderDetails kết hớp với Item. 60 61 Thu nhận yêu cầu Biểu diễn kết hợp (Association) ™ Kết hợp (Association) ƒ Quan hệ giữa các lớp đối tượng ƒ Bậc (unary, binary, ternary hay cao hơn) ƒ Depicted as a solid line between participating classes ™ Vai trò kết hợp (Association Role) ƒ Ghi ở cuối của mỗi kết hợp ƒ Vai trò có lượng số (multiplicity) xác dịnh bao nhiêu đối tượng tham gia trong một quan hệ kết hợp đã cho 62 63 Thu nhận yêu cầu Biểu diễn tổng quát hóa ™ Tổn quát hóa (Generalization) ƒ Là sự trừu tượng những đặc trưng chung của nhiều lớp cũng như quan hệ của chúng thành một lớp tổng quát ™ Lớp con (Subclass) ƒ Một lớp mà được tổng quát hóa ™ Lớ h (S l )p c a uperc ass ƒ Lớp tổng quát hóa từ những subclass 64 Thu nhận yêu cầu Biểu diễn tổng quát hóa ™ Một bộ phân biệt (Discriminator) Nhữ th ộ tí h dù để hâ biệt á lớƒ ng u c n ng p n c c p con trong quan hệ tổng quát hóa ™ Thừa kế (Inheritance) ộ ấ à ớ ừ ế ữ ặƒ M t tinh ch t m l p con th a k nh ng đ c trưng từ lớp cha ™ Lớp trừu tượng (Abstract Class) ể™ Lớp cụ th (Concrete Class) 65 66 67 Thu nhận yêu cầu Biểu diễn kết tập ™ Kết tập (Aggregation) ƒ Quan hệ “một phần của” giữa một đối tượng thành phần và một đối tượng kết hợp Example: Personal computerƒ • Composed of CPU, Monitor, Keyboard, etc myriam.lewkowicz@utt.fr 68 Thu nhận yêu cầu Kết cấu (Composition) ™ Một đối tượng là một phần của toàn bộ trong kết hợp gọi là kết tập (aggregation). ™ Kết cấu (Composition) là một kết hợp mạnh, một phần có thể chỉ thuộc duy nhât một toàn bộ trong mối kết hớp đó ƒ Một phần không thể tồn tại mà không có toàn bộ. ™ The following diagram shows that a BoxOffice belongs to exactly one MovieTheater. Destroy the MovieTheater d h ffian t e BoxO ce goes away! ƒ The collection of Movies is not so closely bound to the MovieTheater. 69 70 Thu nhận yêu cầu Phụ thuộc và ràng buộc ™ Phụ thuộc (dependency) là quan hệ giữa 2 lớp khi iến đổi lớp này thì thay đổi lớp khác (biểu diễn băng mũi tên đứt nét) ƒ Co_op phụ thuộc vào Company ộ à ộ à ộ ề ệ à ệ ệ™ M t r ng bu c l m t đi u ki n m vi c hi n thực thiết kế phải thỏa ({ }) 71 72 Thu nhận yêu cầu Gói (Package) ™ Có thể nhóm các lớp thành những gói ™ Môt ói là ột tậ hợ ề ặt l i hữ thà h g m p p v m og c n ng n phần UML liên quan ƒ Gói có quan hệ phụ thuộc 73 myriam.lewkowicz@utt.fr 74 Thu nhận yêu cầu Biểu đồ đối tượng ™ Biểu đồ đối tượng chỉ ra thể hiện của lớp. Chúng hữ d t iệ iải thí h hữ ẩ hỏ ớiu ụng rong v c g c n ng m u n v quan hệ phức tạp, như quan hệ đệ qui 75 76 Thu nhận yêu cầu Biểu đồ đối tượng ™ Biểu đồ đối tượng (Object Diagram) ể ểƒ Còn gọi là bi u đồ th hiện (instance) ™ Tác vụ Operation ƒ Một chức năng hay một dịch vụ mà được tất cả các thể hiện của lớp cung cấp ™ Đóng gói (Encapsulation) ƒ Kỹ thuật che dấu việc thực thi 77 Ký hiệu 78 myriam.lewkowicz@utt.fr 79 myriam.lewkowicz@utt.fr 80 Thu nhận yêu cầu Chuyển sang thiết kế ™ Bắt đầu những mô hình phân tích tồn tại ™ Dầ dầ ộ thê á hi tiết kỹ th ậtn n c ng m c c c u ™ Mô hình thiết kế phải chi tiết hơn mô hình phân tích ™ Biểu đồ thành phần (Component diagram) ƒ Biểu đồ chỉ ra những thành phần phần mềm hay các module và những phụ thuộc của chúng ™ Biểu đồ triển khai (Deployment Diagram) ƒ Biểu đồ chỉ cách thức những thành phần phần mềm, i t ì h hữ đối tượ đượ t iể kh i thà h kiếqu r n , n ng ng c r n a n n trúc va6t lý của hệ thống 81 Thu nhận yêu cầu Biểu đồ thành phần và biểu đồ triển khai ™ Một thành phần là một module m㠙 Biể đồ t iể kh i hỉ ấ hì h ật lý ủ hầu r n a c ra c u n v c a p n mềm và phần cứng ™ Phần cứng được hợp thành bởi các node Mỗi . thành phần thuộc về node 82 83 CHƯƠNG VI Thẩm định yêu cầu Thu nhận yêu cầu TNYC 1 Thu nhận yêu cầu Nội dung ™ Thẩm định ẩ™ Kỹ thuật th m định ƒ Kiểm tra ngoài ểƒ Ki m thử yêu cầu ƒ Tiêu chuẩn chấp nhận 2 Thu nhận yêu cầu Thẩm định yêu cầu ™ Là đánh giá các yêu cầu có phù hợp với yêu cầu ười dù không ng ng ™ Kiểm tra (Verification) và thẩm định (Validation)? 3 Thu nhận yêu cầu Một vài thống kê ™ Có thể chi phí gấp 100 lần để sửa sai 1 khiếm kh ết (d f t) ủ hươ t ì h ới iệ ửuy e ec c a c ng r n so v v c s a sai 1 lỗi (error) trong giai đoạn thu thập yêu cầu (Grady 1999) ™ Mất 30 phút để sửa lỗi được phát hiện trong giai đoạn yêu cầu nhưng phải mất từ 5 – 17 giờ để sửa chữa khiếm khuyết (defect) trong giai đoạn thử nghiệm hệ thống. (Kelly, Sherif, and Hops 1992) 4 Thu nhận yêu cầu Mô hình chữ V 5 Thu nhận yêu cầu Kỹ thuật yêu cầu 6 Thu nhận yêu cầu Thẩm định: mục tiêu ™ SRS mô tả đúng các khả năng và đặc tính của hệ thố thỏ ã h ầ ủ á t k h ldng a m n n u c u c a c c s a e o er khác nhau ™ Yêu cầu phần mềm được suy dẫn đúng từ yêu cầu hệ thống và các quy tắc nghiệp vụ. ™ Yêu cầu có tính toàn diện và chất lượng cao . ™ Tất cả các yêu cầu đều tương thích với nhau. ™ Yêu cầu cung cấp nến tảng cần thiết cho quy trình thiết kế và xây dựng 7 Thu nhận yêu cầu Out put của thẩm tra yêu cầu 8 Thu nhận yêu cầu Lợi ích của thẩm định yêu cầu ™ Giảm việc phải làm lại (rework) do xác định yêu cầu sai ™ Tăng tốc việc tích hợp và kiểm thử hệ thống ™ Yêu cầu tốt hơn sẽ cho sản phẩm chất lượng hơn và thỏa mãn nhu cầu khách hàng cao hơn. ™ Giảm chi phí bảo trì mở rộng , . 9 Thu nhận yêu cầu 2. Kỹ thuật thẩm tra ™ Kiểm tra ngoài (Peer review) ể™ Ki m thử yêu cầu ™ Tiêu chuẩn chấp nhận 10 Thu nhận yêu cầu 2.1 Kiểm tra ngoài ™ Kiểm tra ngoài thực hiện do người không phải là người của đội phát triển dự án xem xét sản phẩm để xác định lỗi. ™ Việc khảo sát tài liệu SRS là 1 kỹ thuật rất hiệu quả để ƒ Tìm xem yêu cầu nào còn mơ hồ hay không thể xác minh được ƒ Yêu cầu nào chưa đủ rõ cho việc chuyển sang thiết kế à ó á ấ đề liê khá v c c c v n n quan c. ™ Hai loại Kiểm tra ngoài: Kiể t khô hí h i (I f l i )ƒ m ra ng c n qu n orma rev ew ƒ Kiểm tra chính qui (Formal review) Thu nhận yêu cầu Kiểm tra không chính qui ™ Peer deskcheck: khi nhờ 1 đồng nghiệp xem qua ả hẩ ủ ì hs n p m c a m n . ™ Passaround: mời nhiều đồng nghiệp cùng xem xét thành phẩm ủ mình c a ™ Walkthrough: tác giả mô tả thành phẩm của mình và đưa ra các chú giải về nó . 12 Thu nhận yêu cầu Kiểm tra chính qui ™ Sau khi đánh giá phải đưa ra báo cáo kết quả đá h iá à kết l ậ ủ đội ét d ệt ản g v u n c a x uy xem s n phẩm có thể chấp nhận được không. ™ Báo áo hỉ õ á khiếm kh ết đượ tìm à c c r c c uy c v các vấn đề phát sinh. Thành viên của đội chịu trách nhiệm về chất lượng của việc kiểm tra , mặc dù người tạo ra sản phẩm phải là người cuối cùng chịu trách nhiệm về chất lượng. ™ Formal peer review còn được gọi là inspection 13 Thu nhận yêu cầu Kiểm tra chính qui ™ Bất kỳ một sản phẩm phần mềm nào cũng đều có thể kiểm tra bao gồm tài liệu về yêu cầu và thiết , kế, mã nguồn, tài liệu kiểm thử, và cả kế hoạch chung của dự án. ™ Kiểm tra chính qui là 1 quy trình nhiều giai đoạn. Nó liên quan đến 1 đội nhỏ các thành viên đã qua đà t ó t á h hiệ kiể t ẩ thậ áo ạo c r c n m m ra c n n c c khuyết điểm sản phẩm và các cơ hội cải thiện. ™ Kiểm tra chính qui là cửa ngõ mà các tài liệu cần phải đi qua trước khi nó trở thành tuyến cơ sở (baseline) 14 Thu nhận yêu cầu Thành viên 1. Tác giả (author) hay đồng tác giả của sản phẩm 2 Tá iả ủ bất kỳ ả hẩ à liê đế iệ. c g c a s n p m n o n quan n v c kiểm tra đánh giá (phải bao gồm cả đại diện khách hàng) 3. Những người sẽ tiến hành các công việc tiếp theo dựa vào các đề mục đang được kiểm tra, có thể là người ể ểphát tri n, người ki m thử, người quản lý dự án, và người viết tài liệu cho người dùng 4 Những người có t ách nhiệm ới sản phẩm q an tâm. r v , u đến việc thay đổi yêu cầu và ảnh hương của sự thay đổi này với các hệ thống ngoài (hiêu ứng sóng - ripple) 15 Thu nhận yêu cầu Lưu ý ™ Nên giới hạn đội ít hơn 6 người, có nghĩa là 1 vài lĩ h ự ẽ khô ó ười t đội đ i diện v c s ng c ng rong ạ n. ™ Các đội lớn sẽ dễ bị sa lầy vào các cuộc bàn luận ngoài lề lo giải q ết ấn đề à t nh ải em ái , uy v v ra c x c gì thật sự lỗi Î dẫn đến là giảm tốc độ duyệt tài liệu và tăng chi phí tìm lỗi . 16 Thu nhận yêu cầu Các vai trò trong kiểm tra ™ Tác giả ™ Người điều hành (Moderator) ™ Người đọc ™ Người ghi biên bàn 17 Thu nhận yêu cầu Tác giả ™ Tác giả là người tạo ra sản phẩm cần kiểm tra. ™ Tác giả của SRS thường là người phân tích, người thu thập yêu cầu và viết đặc tả. ƒ Trong kiểm tra không chính thức thì tác giả thường điều khiển cuộc thảo luận. T kiể t tá iả iữ i t ò th độ hơƒ rong m ra, c g g va r ụ ng n. Tác giả có thể lằng nghe các diễn giải từ các nhà kiểm tra khác, trả lời nhưng không tranh cải. Tác giả cũng thường phát hiện lỗi mà các người kiểm tra khác không nhìn thấy. 18 Thu nhận yêu cầu Người điều hành (Moderator) ™ Còn gọi là inspection leader, lên kế hoạch kiểm tra cùng với tác giả, điều phối các hoạt động, và tổ chức cuộc họp. Người điều hành phân phát tài liệu cho các thành viên nhiều ngày trước cuộc họp. ™ Trách nhiệm của người điều hành bao gồm ƒ Giữ cuộc họp theo lịch biểu ƒ Động viên mọi thành viên góp ý ƒ Giữ cho cuộc họp tập trung việc tìm khuyết điểm mà không ần phải tìm á h giải q ết c c c uy ƒ Báo cáo kết quả kiểm tra với ban quản lý, ƒ Theo dõi các thay đổi cùng với tác giả để bảo đảm phát hiện được lỗi và các vấn đề phát sinh Thu nhận yêu cầu Người đọc (Reader) ™ Trong các cuộc họp kiểm tra, người sẽ đọc từng ê ầ ột t SRS á thà h iê khá ẽy u c u m rong , c c n v n c s chỉ ra các khiếm khuyết và vấn đề cần xem xét 20 Thu nhận yêu cầu Người ghi biên bản (Recorder) ™ Người ghi biên bản sử dụng các mẫu tiêu chuẩn để iết á ấ đề à khiế kh ết đượ tì thấ v c c v n v m uy c m y trong cuộc họp. ™ Người ghi biên bản nên em l i những đã iết để x ạ v xác định sự chính xác. Những người kiểm tra khác nên giúp người ghi biên bản nắm bắt được điểm chính yếu của mỗi vấn đề theo cách thức có thể dễ dàng trao đổi với tác giả 21 Thu nhận yêu cầu Các giai đoạn của inspection 22 Thu nhận yêu cầu Các giai đoạn kiểm tra ™ Mỗi người kiểm tra sẽ tự làm việc với tài liệu cần thẩ t t i i đ h ẩ bị Đâ là i im ra rong g a oạn c u n . y g a đoạn để phát hiện các vấn đề. ™ T ong ốt ộ họp á người kiểm t ẽ thảor su cu c , c c ra s luận các vấn đề đã phát hiện được và cố gắng phát hiện thêm các vấn đề mới . 23 Thu nhận yêu cầu Họp kiểm tra ™ Trong cuộc họp, người đọc sẽ hướng dẫn những người kiểm tra khác khi duyệt SRS, mỗi lần 1 yêu cầu. Khi những người kiểm tra đưa ra các lỗi và các vấn đề liên quan, người ghi biên bản sẽ ẫ ểghi lại theo m u đ tạo thành 1 danh mục. ™ Mục đích của cuộc họp nhằm xác định các lỗi í à ệ ê ầch nh trong t i li u y u c u. ™ Cuộc họp không nên kéo dài hơn 2 giờ vì khi mọi ười ệt ỏi ẽ là iệ khô ó hiệ ảng m m s m v c ng c n u qu . Nếu cần thêm thời gian thì nên lên kế hoạch cho 1 cuộc họp khác . 24 Thu nhận yêu cầu Họp kiểm tra ™ Cuối cuộc họp, đội sẽ quyết định xem có chấp hậ tài liệ ề ê ầ h khô ? H hấn n u v y u c u ay ng ay c p nhận nhưng cần chỉnh sửa, nếu chỉnh sửa thì ít hay nhiều 25 Thu nhận yêu cầu Kỹ thuật đọc ™ Ad-hoc ™ Checklist-based ™ Defect-based ™ Perspective-based ™ Scenario-based ™ Pattern-based 26 Thu nhận yêu cầu Các tiêu chuẩn ™ Điều kiện tiên quyết mà tài liệu về các yêu cầu ầ hải thỏ ã t ướ khi bắt đầ thẩ tc n p a m n r c u m ra được gọi là tiêu chuẩn vào (Entry criteria) ™ Cá tiê h ẩn ần phải đượ thỏ mãn t ướ khic u c u c c a r c người điều khiển tuyên bố kiểm tra đã hoàn tất: tiêu chuẩn kết thúc (Exit criteria) 27 Thu nhận yêu cầu Tiêu chuẩn vào ƒ Là 1 tập các qui tắc mà tác giả cần tuân theo trong lúc chuẩn bị buổi kiểm tra ƒ Giúp đội kiểm tra không mất thời gian vào các vấn đề mà có thể giải quyết được dễ dàng trước khi bắt đầu kiểm tra ƒ Người điểu khiển cần sử dụng tiêu chuẩn vào như một bảng kiểm (checklist) trước khi quyết định có nên tiến hành buổi kiểm tra không 1. Tài liệu phải phù hợp với các mẫu phù hợp với tiêu chuẩn 2. Tài liệu phải được kiểm tra lỗi chính tả 28 Thu nhận yêu cầu Tiêu chuẩn vào 6. Tác giả phải kiểm tra các lỗi trình bày trong tài liệu. 7. Các tài liệu tham khảo phải luôn sẵn sàng 8. Số dòng được in trong tài liệu để dễ tham chiếu đến các vị trí thích hợp khi họp. 9. Tất cả các vấn đề mở cần phải đánh dấu như TBD (to be determined). 10.Người điều khiển không tìm được nhiều hơn 3 lỗi t t ộ khả át h h 10 quan rọng rong cu c o s n an phút một tài liệu mẫu tiêu biểu. 29 Thu nhận yêu cầu Tiêu chuẩn kết thúc 1. Tất cả các vấn đề xuất hiện trong lúc kiểm tra đã được giải quyết 2. Bất kỳ thay đổi nào trong tài liệu đều đã được sửa đổi cẩn thận . 3. Tài liệu chỉnh sửa đã được kiểm tra chính tả. 4 Tài liệu đã được kiểm tra để đưa vào hệ. thống quản lý cấu hình của dự án 30 Thu nhận yêu cầu Bảng kiểm khiếm khuyết (defect checklist) ™ Để giúp người kiểm tra tìm kiếm các loại lỗi, nên t 1 bả kiể khiế kh ết h ỗi l i tài liệạo ng m m uy c o m oạ u yêu cầu. ™ Ví d he k li t ho e e he k li t ho SRS ụ: c c s c us cas , c c s c 31 Thu nhận yêu cầu Defect checklist for use-case ™ Is the use case a stand-alone, discrete task? ™ Is the goal or measurable value of the use case clear? , , ™ Is it clear which actor or actors benefit from the use case? ™ Is the use case written at the essential level, free of unnecessary design and implementation details? ™ A ll i i d l i d d?re a ant c pate a ternat ve courses ocumente ™ Are all know exception conditions documented? ™ Are there any common action sequences that could be split into separate use cases? 32 Thu nhận yêu cầu Defect checklist for use-case ™ Are the steps for each course clearly written, bi d l t ?unam guous, an comp e e ™ Is each actor and step in the use case pertinent to pe fo ming th t t k? r r a as ™ Is each altemative course defined in the use case feasible and verifiable? ™ Do the preconditions and postconditions properly frame the use case? 33 Thu nhận yêu cầu Những thách thức ™ Kiểm tra ngoài là một hoạt động vừa mang tính kỹ th ật ừ tí h ã hộiu v a mang n x ™ Một công ty phần mềm phải mất nhiều thời gian để biến Kiểm t ngoài thành đặ t ưng ủ ông ra c r c a c ty ™ Những thách thức mà một tổ chức phải đương đầu khi duyệt các tài liệu về yêu cầu. ƒ Tài liệu yêu cầu lớn ƒ Nhóm kiểm tra lớn ƒ Những người kiểm ra cách biệt về địa lý 34 Thu nhận yêu cầu 2.2 Kiểm thử yêu cầu ™ Khó hình dung hệ thống sẽ vận hành thế nào nếu chỉ đọc SRS nên cần phải xem xét việc kiểm thử yêu cầu ™ Tạo những test case dựa vào yêu cầu chức năng hay suy diễn từ yêu cầu người dùng ™ Các test case thiết kế đơn giản cũng giúp phát hiện nhiều vấn đề về yêu cầu ngay cả khi không thực hiện các kiểm thử trên hệ thống hoạt động 35 Thu nhận yêu cầu Kiểm thử yêu cầu ™ Nếu bắt đầu xây dựng các test case sớm ngay khi 1 số yêu cầu đã ổn định có thể tìm ra các , vấn đề giúp sửa sai mà không quá tốn kém 36 Thu nhận yêu cầu 37 Thu nhận yêu cầu Các test case khái niệm ™ Tạo ra các test case khái niệm từ các use case h từ á đ i diệ ê ầ ười dù từay c c ạ n y u c u ng ng ngay đầu . ™ Cá te t e khái niệm đượ dùng để đánh giác s cas c các yêu cầu, mô hình phân tích và các nguyên mẫu (prototype) - nên bao trùm ngữ cảnh thông thường và các ngoại lệ trong kịch bản use case. ™ Các test case khái niệm độc lập với thực thi. 38 Thu nhận yêu cầu Ví dụ ™ Khảo sát use case "View Order" của hệ thống Ch i l T kiem ca rac ng. 39 Thu nhận yêu cầu Ví dụ các test case khái niệm ™ User enters order number to view, order exists, user placed the order. Expected result: show order details. ™ User enters order number to view, order doesn't exist. Expected result: Display message "Sorry I can't find that order ", . ™ User enters order number to view, order exists, user didn't place the order Expected result: . Display message "Sorry, that's not your order." 40 Thu nhận yêu cầu Tạo test case cho use case ™ Test case để kiểm thử use case: vì mỗi use case ó 1 kị h bả hí h à á kị h bả h ác c n c n v c c c n p ụ, c c ngoại lệ (exception) nên có nhiều đường thực thi (execution path)Î tạo các test case khác nhau để kiểm thử ™ Các test case này đều trừu tượng độc lập với , thực thi, chỉ đến khi chuyển sang thiết kế giao diện các test case trừu tượng này sẽ thành các thủ tục kiểm thử (test procedure) cụ thể. 41 Thu nhận yêu cầu Ví dụ ™ Xét yêu cầu nghiệp vụ sau: ƒ This system will save the company 25% on chemical costs in the first year of use by allowing the company to fully exploit chemicals that are already available within the company…. ™ Use case trên là "Request a Chemical“. Use case này cho phép người dùng yêu cầu 1 lọ hóa chất nào đó hiện vẫn còn trong kho hóa chất của công ty 42 Thu nhận yêu cầu Use case ”Request a Chemical” 43 Thu nhận yêu cầu 44 Thu nhận yêu cầu Yêu cầu chức năng ™ If the stockroom has containers of the chemical b i t d th t h ll di l li t fe ng reques e , e sys em s a sp ay a s o the available containers ™ The e h ll eithe ele t one of the di pl ed us r s a r s c s ay containers or ask to place an order for a new container from a vendor . 45 Thu nhận yêu cầu Sơ đồ đối thoại ™ Có nhiều Execution path trong use case Î Có nhiều Execution path cần kiểm thử 46 Thu nhận yêu cầu Test case mẫu 1 ™ Tạo Test case cho “the available containers in th h i l t k ”e c em ca s oc room ƒ At dialog box DB40, enter a valid chemical ID; the chemical stockroom has two containers of this chemical. ƒ Dialog box DB50 appears, showing the two containers. Select the second container. ƒ DB50 closes and container 2 is added to the bottom of the Current Chemical Request List in dialog box DB70 47 Thu nhận yêu cầu Kiểm thử yêu cầu chức năng ™ Ánh xạ mỗi test case với các yêu cầu chức năng để bả đả ỗi t t đề ó thể đượ thự o m m es case u c c c thi bởi 1 tập các yêu cầu chức năng. ™ Bảo đảm là mỗi ê ầ hứ năng phải ó ít nhất y u c u c c c 1 test case 48 Thu nhận yêu cầu Kiểm thử yêu cầu chức năng ™ Dùng bút đánh dấu các đường thực thi tương ứng ới ỗi t t t ơ đồ đối th iv m es case rong s oạ Î Nhờ đó có thể phát hiện được các yêu cầu bị thiếu hay không đúng Æ sửa lỗi và tinh chỉnh lại test case cho phù hợp. 49 Thu nhận yêu cầu Đường thực thi 50 Thu nhận yêu cầu Test case không đúng/bị thiếu ™ Giả sử sau khi thực thi tất cả test cases và đã dù bút đá h dấ à ơ đồ đối th i thì hátng n u v o s oạ p hiện thấy đường có nhãn "order new container" đi từ DB50 đến DB60 không được đánh dấu . Î Có thể hiểu theo 2 cách: 51 Thu nhận yêu cầu Phân tích 1. Đường nối từ DB50 đến DB60 không phải là hà h i hệ thố ( t b h i )n v ng sys em e av or Æ Analyst cần xóa nó khỏi dialog map. Nếu SRS có hứ ê ầ liên q n đến thì ê ầ nà ũngc a y u c u ua y u c u y c phải loại bỏ 2. Đường nối này là 1 hành vi hệ thống (system behavior) hợp lệ Æ Thiếu test case mô tả hành vi này, cần bổ sung thêm. 52 Thu nhận yêu cầu Test case mẫu 2 ™ Thử tạo test case cho trường hợp “the user can t k ti t di tl f di l ba e some ac on o move rec y rom a og ox DB40 to DB70” ™ T ong ơ đồ đối tho i không ó đường thự thir s ạ c c nào nối từ DB40 đến DB70 vì vậy test case này không thể thực thi được . 53 Thu nhận yêu cầu Lý do test case bị sai ™ Việc chuyển từ hộp thoại DB40 đến DB70 không hải là hà h i hệ thố ( t b h i ) ì ập n v ng sys em e av or v v y test case bị sai. ™ Việc chuyển từ DB40 đến DB70 là chức năng hợp lệ nhưng dialog map và có thể cả SRS thiếu 1 yêu cầu nào đó cho phép thực thi test case này. 54 Thu nhận yêu cầu Test case và use case ™ Nếu các use case đầy đủ, chính xác và rõ ràng thì iệ đư t t dễ dà v c a ra es case ng ™ Nếu các test case không tốt thì việc quan tâm đư á te t e ẽ giúp ho iệ ử hữa ra c c s cas s c v c s a c a các use case 55 Thu nhận yêu cầu Kiểm thử khái niệm và kiểm thử chấp nhận ™ Kiểm thử khái niệm (Conceptual testing) là 1 kỹ th ật ất hiệ ả để kiể át hi hí à thờiu r u qu m so c p v gian của dự án qua việc phát hiện những yêu cầu mơ hồ hay có lỗi ngay từ giai đoạn đầu ™ Kiểm thử chấp nhận (Acceptance testing) là để xác định xem hệ thống có thỏa mãn các tiêu chuẩn có thể chấp nhận được của khách hàng hay không? 56 Thu nhận yêu cầu 2.3 Tiêu chuẩn chấp nhận ™ Kiểm thử chấp nhận được thực hiện khi hệ thống đã h à tất à d ười dù thự hiệ o n v o ng ng c n ™ Để người dùng đề ra các kiểm thử chấp nhận là 1 hiến lượ phát t iển ê ầ ó hiệ q ả Ngườic c r y u c u c u u . dùng viết ra các kiểm thử càng sớm thì họ càng sớm phát hiện được các khiếm khuyết trong yêu cầu. ™ Những người phát triển sẽ đưa ra các kiểm thử này từ SRS đã phê duyệt của hệ thống 57 Thu nhận yêu cầu Tiêu chuẩn ™ Nên tập trung vào khung hướng sử dụng phần mềm như thế nào ™ Người dùng chính nên xem xét use case nào được sử dụng nhiều nhất và quan trọng nhất khi quyết định về khả năng chấp nhận phần mềm ™ Nên tập trung vào các trường hợp thông thường của use case, không nên để ý quá đến các trường hợp ít thông dụng, hay vào quản lý mọi ngoại lệ 58 Thu nhận yêu cầu Tiêu chuẩn ™ Nên kiểm thử tự động khi có thể. ể ử ấ ậ ũ ê é ả á ê ầ™ Ki m th ch p nh n c ng n n x t c c c y u c u phi chức năng, bảo đảm mục tiêu có thể thực thi trên mọi platform hệ thống phù hợp với các tiêu chuẩn và tất, , cả mọi yêu cầu đã cam kết đều được thực thi ™ Viết ra yêu cầu không chưa đủ, mà cần phải bảo đảm là yêu cầu phải đúng và đủ chi tiết để dùng cho thiết kế, xây dựng, kiểm thử và quản lý dự án. ậ ế ể ử à á é™ L p k hoạch cho ki m th , r so t lại SRS, xem x t các kỹ thuật kiểm thử yêu cầu sẽ giúp xây dựng hệ thống chất lượng nhanh hơn và ít đắt hơn những dự , án trước đó 59 CHƯƠNG VII Quản lý yêu cầu Thu nhận yêu cầu TNYC 1 Thu nhận yêu cầu Nội dung ™ Tuyến cơ sở của yêu cầu (Requirement baseline) ™ Quản lý yêu cầu (Requirement Management - RM) ™ Công cụ (Tool) 2 Thu nhận yêu cầu Biểu đồ RE 3 Thu nhận yêu cầu 1. Tuyến cơ sở ™ Là tập hợp các yêu cầu chức năng và phi chức ă à đội hát t iể đã kết để thự thin ng m p r n cam c trong hệ thống. ™ Xá định t ến ơ ở (b eline) giúp t keholdec uy c s as s a r hiểu được khả năng và đặc trưng mà họ có thể mong thấy được trong phần mềm sẽ phát hành . 4 Thu nhận yêu cầu Tuyến cơ sở ™ Sau khi yêu cầu được phê duyệt chính thức sẽ trở thà h t ế ơ ở (b li ) từ lú à t ở đi án uy n c s ase ne c n y r c c yêu cầu được đặt dưới sự quản lý cấu hình ™ Tài liệ nà là ơ ở ho mọi ho t động đượ thự u y c s c ạ c c thi tiếp theo của dự án. ™ Các thay đổi sau đó chỉ có thể được thực hiện thông qua quy trình kiểm soát biến đổi 5 Thu nhận yêu cầu Đối tượng quản lý/sử dụng baseline ™ Quản lý yêu cầu /quản lý dự án: là người có hiệ ả lý á ê ầ từ lú t ở thà hn m vụ qu n c c y u c u c r n baseline và tất cả các phiên bản chỉnh sửa được duyệt sau đó ™ Mọi stakeholder đều có quyền sử dụng 6 Thu nhận yêu cầu Vai trò của người quản lý yêu cầu ™ Người phân tích yêu cầu (requirement analyst) ủ dự á thườ là ười ả lý ê ầ óc a n ng ng qu n y u c u, c nhiệm vụ: Xác lập cơ chế lưu trữ yêu cầuƒ ƒ Xác định các thuộc tính yêu cầu ƒ Quản lý trạng thái yêu cầu và cập nhật dữ liệu theo dõi trạng thái ƒ Xuất ra các báo cáo về hoạt động liên quan đến thay đổi 7 Thu nhận yêu cầu 2. Quản lý yêu cầu ™ Baseline là cầu nối giữa phát triển yêu cầu và ả lý ê ầqu n y u c u ™ Quản lý yêu cầu bao gồm tất cả hoạt động nhằm d t ì tính toàn ẹn (integ it ) độ hính áuy r v r y , c x c (accuracy) và tính hợp thời của baseline. 8 Thu nhận yêu cầu Lập kế hoạch quản lý yêu cầu ™Kế hoạch quản lý yêu cầu là 1 phần trong kế hoạch quản lý dự án tổng thể. ™Nội dung của kế hoạch RM bao gồm: ƒ Giới thiệu về RM ƒ Phạm vi của tài liệu ƒ Các vấn đề làm ảnh hưởng đến việc thực thi kế hoạch. ƒ Các tài liệu có thể áp dụng trong RE như các chính sách , tiều chuẩn ƒ Các phương pháp và công cụ được dùng trong quá trình RM. ƒ Quyền hạn và trách nhiệm của những người tham gia ƒ Các chiến lược để hoàn thành chất lượng yêu cầu bao , gồm traceability và change control Thu nhận yêu cầu CCB (Change Control Board) ™ CCB thực hiện rất nhiều phân tích khác nhau t á t ì h kiể át th đổirong qu r n m so ay 10 Thu nhận yêu cầu Phân tích ảnh hưởng ™ Liên quan đến việc phát hiện ra chức năng cơ bản h hợ lý Từ thiết kế hợ lý iú dò tì ượay p . p g p m ng c về lại yêu cầu ban đầu và từ yêu cầu này dò tìm ra được yêu cầu của stakeholder Æ dẫn đến quyết định là có nên bổ sung yêu cầu này vào sản phẩm hay không? 11 Thu nhận yêu cầu Phân tích phái sinh (Derivation analysis) ™ Mục tiêu: xác định tài chính, tài nguyên hay chi hí t thời hát i h d ê ầ bị th đổi hp ạm p s n o y u c u ay ay phát sinh tính chất mới. ™ Thành iên ủ CCB phải á định bất kỳ ử đổi v c a x c s a hay mở rộng nào sẽ ảnh hưởng đến hệ thống để suy ra chi phí và rủi ro của sửa đổi đó . 12 Thu nhận yêu cầu Phân tích sự bao phủ (Coverage Analysis) ™ Đo lường tỷ lệ giữa các tính năng của sản phẩm dự kiế à ả hẩ thự để á đị h ê n v s n p m c, x c n xem y u cầu có được thực thi trong sản phẩm hay không? ™ Phân tí h nà đượ thự hiện bằng á h theo dõi c y c c c c từ các yêu cầu hệ thống lúc đầu đến các test case. ™ Test là cách tốt nhất để đo lường mức đồ tuân thủ theo thiết kế. 13 Thu nhận yêu cầu 14 Thu nhận yêu cầu Các hoạt động quản lý yêu cầu ` Identifying volatile requirements ` E t bli hi P li i f i ts a s ng o c es or requ remen s processes and supporting them with workflow tools, guidelines templates and examples, , ` Prioritizing Requirements ` Establishing and updating the requirements baseline `Documenting Decisions ` Planning releases and allocating requirement to releases Thu nhận yêu cầu 2.1 Kiểm soát thay đổi (Change Control) ™ Các yêu cầu trong baseline phải phân biệt với các ê ầ đã đượ đề ất hư khô đượ hấy u c u c xu n ng ng c c p nhận. ™ Tài liệ SRS đã đượ b eline hỉ nên hứ á u c as c c a c c yêu cầu đã được lên kế hoạch cho phiên bản cụ thể nào đó nó khác với các phiên bản nháp trước , đó khi chưa được phê duyệt. 16 Thu nhận yêu cầu Các Thách thức về thay đổi ™Chấp nhận các thay đổi yêu cầu vừa được đề xuất có thể không hoàn thành lịch biểu và các cam kết về chất lượng của dự án. ™Người quản lý dự án phải thỏa thuận với khách hà ề hữ h đổ ớ kế b đầng v n ng t ay i so v i cam t an u. ™Khi các yêu cầu bị thay đổi theo các cách sau dự án cần: ƒ Trì hoãn lại các yêu cầu có độ ưu tiên mức thấp ƒ Thêm nhân viên ƒ Buộc làm thêm giờ, trả thêm tiền trong 1 khoảng thời gian ngắn Kéo dài thời gian để thêm chức năng mớiƒ ƒ Chất lượng bị đặt trước áp lực thời gian17 Thu nhận yêu cầu Sử dụng thủ tục và công cụ ™ Vì thay đổi là không tránh khỏi nên cần phải lập kế hoạch thay đổi cho các yêu cầu trong quá trình phát triển dự án, ngay cả khi hệ thống đã bàn giao ƒ Cần xây dựng quy trình và tool để quản lý các yêu cầu bị thay đổi. Procedures Tools 18 Thu nhận yêu cầu Thủ tục ™ Cần xác định các hoạt động mà đội dự án phải thự hiệ để ả lý ê ầc n qu n y u c u. ™ Lưu trữ lại các hoạt động này và tập huấn các thành iên thự thi á ho t động một á h thống v c c c ạ c c nhất và hiệu quả. 19 Thu nhận yêu cầu Thông tin cần quản lý ™ Có thể đưa tất cả thông tin này vào 1 quy trình ả lý ê ầ h h ặ ó thể iết thà h áqu n y u c u c ung, o c c v n c c quy trình riêng lẻ như change-control, impact- analysis và status-tracking, ™ Các thủ tục này nên áp dụng cho cả tổ chức vì chúng là các chức năng thông dụng mà mỗi đội dự án nên tuân theo 20 Thu nhận yêu cầu Thông tin cần quản lý ™ Các công cụ, kỹ thuật và quy ước để kiểm soát các phiên bản khác nhau của tài liệu về yêu cầu. ™ Ccáh thức để tạo baseline ™ Các trạng thái yêu cầu và ai có thể làm nó thay đổi ™ Các thủ tục theo dõi trạng thái yêu cầu. ™ Cách thức mà các yêu cầu và thay đổi mới được đề xuất, xử lý, thỏa thuận và được chuyển đến tất cả các stakeholder quan trọng à ế à ể â í ả ở ủ ổ™ L m th n o đ ph n t ch nh hư ng c a thay đ i ™ Làm thế nào để kế hoạch và cam kết của dự án phản ánh được các thay đổi của yêu cầu 21 Thu nhận yêu cầu Lỗ hổng đặc trưng (Feature creep) ™ Lỗ hổng đặc trưng dùng để chỉ hiện tượng nhiều thay đổi nhỏ được thông qua mà không cần đánh giá xét duyệt. ™ Hậu quả: làm ảnh hưởng nghiêm trọng đến lợi nhuận và ngày hoàn thành sản phẩm. ổ™ Cách khắc phục: mọi yêu cầu thay đ i cần được phê duyệt bởi hội đồng kiểm soát biến đổi CCB (Change Control Board) . 22 Thu nhận yêu cầu 2.2 Kiểm soát phiên bản (Version control) ™ Kiểm soát phiên bản là 1 trong các điểm chính ế t ả lý ê ầy u rong qu n y u c u. ™ Mỗi phiên bản của tài liệu yêu cầu phải được xác định d nhất Mỗi thành iên ủ đội ó thể t uy . v c a c ruy xuất vào phiên bản hiện hành của yêu cầu và các thay đổi phải được lưu trữ lại 1 cách rõ ràng và được gửi đến mọi người có liên quan. 23 Thu nhận yêu cầu Kiểm soát phiên bản ™ Để giảm thiểu nhầm lẫn, mâu thuẫn và sai lệch thô ti hỉ h hé 1 ài á hâ đượ ềng n, c c o p p v c n n c quy n cập nhật yêu cầu và bảo đảm là mã phiên bản thay đổi khi yêu cầu thay đổi . ™ Mỗi phiên bản hiện hành cũng nên chứa phần (revision history): xác định đã có những thay đổi gì, ngày của mỗi thay đổi, ai đã gây ra thay đổi, lý do cho mỗi thay đổi, cộng thêm số phiên bản, thường số phiên bản sẽ tăng mỗi khi có yêu cầu thay đổi. 24 Thu nhận yêu cầu Kỹ thuật kiểm soát phiên bản ™ Cơ chế kiểm soát phiên bản đơn giản nhất là tự đặt tê ỗi lầ d ệt SRS th ướ h ẩ n m n uy eo quy c c u n ™ Ví dụ: phiên bản đầu tiên "Version 1.0 draft 1.“, phiên bản kế tiếp là "Ve ion 1 0 d ft 2” Số rs . ra phiên bản sẽ tăng cho đến khi tài liệu được phê duyệt và baseline Sau đó nhãn sẽ thay đổi thành . "Version 1.0 approved.“, các phiên bản kế tiếp là "Version 1.1 draft 1" nếu sửa đổi nhỏ hay "Version 2.0 draft 1" nếu sửa đổi lớn. 25 Thu nhận yêu cầu Các hạn chế 1. Khó giữ cho tài liệu đồng bộ khi có thay đổi ổ2. Khó truyền đạt kịp thời thay đ i đến các đội thực hiện ó ă ệ ô ổ ề3. Kh kh n trong vi c lưu trữ th ng tin b sung v mỗi yêu cầu 4 Khó á đị h đượ liê kết iữ ê ầ hứ. x c n c n g a y u c u c c năng với các phần tử khác của hệ thống. 5 Khó khă khi th dõi tì h t ủ ê ầ. n eo n rạng c a y u c u Thu nhận yêu cầu Các hạn chế 6. Khó quản lý đồng thời các tập yêu cầu cho những phiên bản khác nhau hay sản phẩm có liên quan. Khi 1 yêu cầu tham chiếu đến 1 phiên bản khác, người phân tích cần chuyển theo cả yêu cầu đó. Sử d l ê ầ ó hĩ là hà hâ í h hả7. ụng ại y u c u c ng a n p n t c p i tự sao chép văn bản từ SRS gốc đến SRS dùng cho hệ thống khác . 8. Khó khăn khi có nhiều người cùng tham gia sửa đổi yêu cầu 9. Không có chỗ thích hợp để lưu trữ lại các yêu cầu bị loại bỏ hay bị xóa khỏi baseline 27 Thu nhận yêu cầu 2.3 Traceability ™ Một yêu cầu có thể được theo dõi nếu và chỉ nếu ê ầ à từ đầ đượ á đị h õ ày u c u n y ngay u c x c n r r ng, có cơ chế làm cho nó khả thi trong quá trình phát triền phần mềm ™ Chiến lược theo dõi là dựa vào vai trò của thành viên dự án và nhu cầu của họ . 28 Thu nhận yêu cầu Các vai trò 29 30 Thu nhận yêu cầu Ma trận lần vết ™ Mục đích của ma trận lần vết (REQUIREMENTS TRACEABILITY MATRIX RTM) là để bả đả á - o m c c mục tiêu của yêu cầu phải phù hợp với yêu cầu bằng cách kết hợp mỗi yêu cầu với mục tiêu thông qua ma trận theo dõi. ™ Requirements traceability is concerned with documenting the life of a requirement. 31 Thu nhận yêu cầu Ma trận lần vết ™ Forward trace: ma trận theo dõi được dùng để kiể t tất ả á ê ầ ó đượ đư à ám ra c c c y u c u c c a v o c c thành phần của hệ thống hay các sản phẩm chuyển giao hay không ™ Backward trace: ma trận được dùng để xác định các nguồn của yêu cầu . Thu nhận yêu cầu Ma trận lần vết ™ Lần vết yêu cầu cũng bao gồm việc theo dõi hữ iệ khá ũ hằ để thỏ ã ê ần ng v c c c ng n m a m n y u c u (capabilities, design elements, manual operations, tests ), …. ™ Ma trận lần vết cũng được dùng để bảo đảm tất cả yêu cầu khi thay đổi cũng vẫn được đưa vào các thành phần của hệ thống. Nhờ đó, ảnh hưởng của những yêu cầu bị thay đổi đến hệ thống có thể xác định được. 33 Thu nhận yêu cầu Ví dụ: Ma trận lần vết 34 Thu nhận yêu cầu Ví dụ ™ “U” chỉ yêu cầu người dùng ™ “S” chỉ yêu cầu hệ thống. ™ Theo dõi S12 khi trỏ đến nguồn của nó thỉ thấy rõ à ê ầ à ả ỏ ế ầr ng y u c u n y sai: ph i loại b , vi t lại hay c n sửa lại việc theo dõi này. 35 Thu nhận yêu cầu 36 Thu nhận yêu cầu 3. Công cụ quản lý yêu cầu ™ Công cụ sẽ giúp lưu trữ thông tin trong CSDL đa ười dù iú iải ết đượ á h hế khing ng g p g quy c c c ạn c quản lý yêu cầu bằng văn bản thông thường. ™ Cá dự án nhỏ ó thể dùng bảng tínhc c (spreadsheet) hay CSDL đơn giản để quản lý yêu cầu. ™ Các dự án lớn nên dùng công cụ quản lý yêu cầu tự động. 37 Thu nhận yêu cầu Chức năng của công cụ ™ Create and view requirements as entities and ti di tl i th d lproper es rec y n e mo e ™ Collate the requirements in an external CSV file nd then impo t them into o modela r y ur ™ Detail use cases and scenarios directly in the model ™ Enter standard attributes (properties) for each requirement such as difficulty status and type, , , and define your own attributes (properties) 38 Thu nhận yêu cầu Chức năng của công cụ ™ Trace requirements to Use Cases, business rules, t t d l i tif t ( i fes cases an ana ys s ar ac s us ng, or example, the Relationship Matrix) ™ T e nd ie the imp t of h nge onrac a v w ac c a s requirements (through, for example, the Traceability window) and review the changes themselves ™ Create customer-quality MS Word and HTML reports on requirements. 39 Thu nhận yêu cầu 40 Thu nhận yêu cầu Một vài công cụ quản lý yêu cầu ™ Rational DOORS của IBM ™ Enterprise Architecture (www.sparxsystems.com) ™ CaliberRM của Borland ™ … 41 CHƯƠNG VIII Yêu cầu phần mềm và quản lý rủi ro Thu nhận yêu cầu TNYC 1 Thu nhận yêu cầu Nội dụng ™ Quản lý rủi ro ™ Quản lý những rủi ro về yêu cầu ™ Yêu cầu và hệ thống an toàn cao 2 Thu nhận yêu cầu 1. Quản lý rủi ro ™ Là công việc chính trong quản lý dự án ™ Trong kỹ thuật yêu cầu cần xem xét những rủi ro về yêu cầu ả ý ê ầ ả ỗ ệ ả ý ủ™ Qu n l y u c u ph i h trợ cho vi c qu n l r i ro của dự án ™ Đối ới hữ ả hẩ hiê ặt ề ứ khỏ v n ng s n p m ng m ng v s c e của con người cũng như về kinh tế, an ninh thì việc quản lý những rủi ro liên quan tới vấn đề này là hết sức quan trọng, rất cần sự hỗ trợ của quản lý yêu cầu 3 Thu nhận yêu cầu Quản lý rủi ro ™ Quản lý rủi ro có thể kiểm soát các rủi ro thông ự hợ tá ới khá h hà h đ i diệ ủqua s p c v c ng ay ạ n c a họ, lưu trữ lại các rủi ro và kế hoạch giảm nhẹ rủi ro. ™ Với dự án lớn, lập kế hoạch quản lý rủi ro là yêu tố chính quyết định sự thành công của dự án 4 Thu nhận yêu cầu Các thành phần của quản lý rủi ro 5 Thu nhận yêu cầu Thu nhận yêu cầu Mô tả rủi ro ™ Sử dụng dạng condition-consequence để mô tả rủi ro. ™ Thường các rủi ro được phát biểu dưới dạng: Chỉ ó điề kiệ (" h d 'ƒ c u n t e customers on t agree on the product requirements") ƒ Hay chỉ có hậu quả ("we can satisfy only one of our major customers“) ™Nên đặt các phát biểu này cũng nhau theo ấ údạng c u tr c condition-consequence: "The customers don't agree on the product requirements so we will only be able to, satisfy one of our major customers." Thu nhận yêu cầu Mô tả rủi ro ™ Một điều kiện có thể dẫn đến nhiều hậu quả, và hiề điề kiệ ó thể hỉ t 1 hậ ản u u n c c ạo ra u qu . 8 Thu nhận yêu cầu 2. Quản lý rủi ro yêu cầu ™ Vì yêu cầu đóng vai trò trung tâm trong các dự án hầ ề ười ả lý dự á thậ t êp n m m, ng qu n n n rọng n n nhận biết các rủi ro có liên quan đến yêu cầu sớm và kiểm soát chúng liên tục 9 Rủi ro và phòng chống ™ Scope creep ™ Thời i dự á ấ út ™ Viết sớm vision and scope ™ Lưu trữ lại nỗ lực và thời g an n g p r gây áp lực cho người quản lý và khách hàng Æ gian thu thập yêu cầu của các dự án trước đó (chiếm íbỏ qua giai đoạn yêu cầu 10 – 15% chi ph nhưng giúp dự án tốt hơn) để chứng minh cho các dự án trong tương lai 10 Rủi ro và phòng chống ™ Đặc tả yêu cầu không đúng và đầy đủ ™ Dùng kỹ thuật use cae và đặc tả use case; viết test ™ Thiếu yêu cầu phi chức năng case và đưa đại diện khách hàng vào đội ™ Một vài khách hàng không hài lòng với hệ thống đang phát triển inspection ™ Viết yêu cầu phi chức năng và tiêu chuẩn kiểm thử trong SRS ™ Xác định primary customer. Dùng phương pháp product champion để chọn đại diện khách hàng 11 Rủi ro và phòng chống ™ Các yêu cầu tuy không được nói ra nhưng là ` Cố đưa ra các giả định và dùng câu hỏi đóng mở để mong đợi ngầm định của khách hàng chia sẻ suy nghĩ, mong muốn của khách hàng ™ Sử dụng sản phẩm hiện có làm nguồn tài nguyên cho yêu cầu của hệ thống ` Công nghệ đảo ngược không phải là cách hiệu quả để khám phá yêu cầu mới (dùng công nghệ đảo ngược - reverse i i ) . Nếu dùng kỹ thuật này thì cần viết thành tài liệu đặc tả à ầ kiể teng neer ng v c n m ra 12 Rủi ro và phòng chống ™ Người dùng đề nghị giải pháp cho hệ thống nhưng ™ Analyst phải cố tìm hiểu được mục đích từ giải , giải pháp che giấu nhu cầu thực sự của khách à pháp khách hàng đề nghị h ng Æ developer tạo ra thiết kế không đúng 13 Rủi ro và phòng chống ` Khi đánh giá tính khả thi của các yêu cầu phát hiện ` Sử dụng phương pháp theo dõi trạng thái dự án , 1 số yêu cầu có thể mất nhiều thời gian thực thi ế để sớm phát hiện yêu cầu nào chậm hơn tiến độ thực ệ à ộ ửhơn dự ki n ` Đòi hỏi sử dụng công nghệ tool phương pháp hi n Æ h nh đ ng s a sai càng sớm càng tốt. ` Không nên đánh giá thấp, , và ngôn ngữ lập trình mới việc phải học làm quen, tăng tốc sử dụng công hệ à ô ữ ớing v ng n ng m , phải cho phép có đủ thời gian để bắt đầu 14 Rủi ro và phòng chống ™ Khách hàng và người phát triển hiểu yêu cầu theo ™ SRS cần phải được thẩm tra đội thẩm tra nên có các khác nhau. , cả khách hàng. Nhà phân tích và người viết SRS ả ó ệ êph i c kinh nghi m. N n tạo mô hình và nguyên mẫu cho những yêu cầu còn mơ hồ 15 Rủi ro và phòng chống ™ Đưa thiết kế vào SRS làm phát sinh các ràng buộc ` SRS cần được kiểm tra để bảo đảm trong SRS chỉ không cần thiết Æ trở ngại trong việc đưa ra ế ế ố chứa “what”, không chứa “how” thi t k t i ưu ™ Một số yêu cầu không được thực thi ` Dùng ma trận lần vết (traceability matrix) sẽ tránh được việc bỏ sót các yêu cầu trong mỗi giai đoạn phát triển 16 Thu nhận yêu cầu 3. Yêu cầu và hệ thống an toàn cao ™ Các yêu cầu trong 1 miền nghiệp vụ nào đó đượ là f t iti l ầ hải ó ác xem sa e y cr ca c n p c c c thuộc tính đặc biệt ƒ Is the requirement part of a safety critical system? - ƒ Has this requirement been checked to see if a hazard analysis needs to be performed? ƒ If so, is the requirement associated with a hazard analysis (hyperlink to hazard analysis)? h d (ƒ Does t e requirement nee mitigation traces to mitigating requirements)? 17 Thu nhận yêu cầu Tình huống 1 ™ Giả sử yêu cầu được tổ chức tốt thành 3 mức: ƒ Business requirements ƒ Customer requirements ƒ System requirements. ệ h dõ ữ ê ầ h ệ ó ủ hệ hố™ Vi c t eo i gi a y u c u i n c c a t ng với các yêu cầu khách hàng cần liên hệ chặt chẽ đến kiến trúc ban đầu . 18 Thu nhận yêu cầu Tình huống 2 ™ Giả sử tỷ lệ 1:10 giữa yêu cầu khách hàng và yêu ầ hệ thố ó hĩ là 10 ê ầ hệ thố ẽc u ng, c ng a y u c u ng s tương ứng với 1 yêu cầu của khách hàng. ™ Giả sử có 500 yêu cầu khách hàng Æ sẽ có 5000 yêu cầu hệ thống. Để phân tích rủi ro, cần phân tích 500 yêu cầu khách hàng nếu việc phân tích , mỗi yêu cầu khách hàng đòi hỏi 1 giờngười thì sẽ cần tới 500 giờngười 19 Thu nhận yêu cầu Tình huống 2 ™ Giả sử các yêu cầu được sắp xếp không tốt, được liệt kê lộ ộ thườ khô đượ th dõi à hỉ n x n, ng ng c eo v c có 1 số yêu cầu được liên hệ với kiến trúc ban đầu. ™ Giả sử có 500 yêu cầu khách hàng và 5000 yêu cầu hệ thống thì cần phân tích toàn bộ 5500 yêu cầu vì không biết yêu cầu nào thuộc mức nào, do đó cần 5500 giờngười để thực thi việc phân tích rủi ro. 20 Thu nhận yêu cầu Phân tích rủi ro và CSDL ™ Các hoạt động phân tích rủi ro thường được phản á h t CSDL ê ầ khi ầ ó 1 hà h độn rong y u c u c n c n ng giảm nhẹ rủi ro nào đó. 21 Thu nhận yêu cầu 22 Thu nhận yêu cầu Ví dụ ™ Cửa xe lửa có thể làm kẹt hành khách gây thương tí h d đó để t á h ủi ầ thê 1 ê ầ àc , o r n r ro c n m y u c u v o CSDL để tránh hiểm họa này cần có các cảm biến (sensor) lắp ở cửa để phát hiện vật cản và tránh đóng cửa ™ Quy trình này được thực hiện bằng cách tạo các vết từ 1 rủi ro cần tránh với 1 yêu cầu giảm nhẹ 23 Thu nhận yêu cầu Ví dụ 24 Thu nhận yêu cầu Tạo mô hình mối đe dọa và MDRE ™ Công cụ MDRE cần bổ sung thêm 1 vài ký hiệu và ối hệ để hỗ t ợ t ô hì h ối đ dm quan r ạo m n m e ọa 25 Thu nhận yêu cầu Các phương pháp ™ Attacker-Centric ™ Software-Centric ™ Asset-Centric 26 Thu nhận yêu cầu Attacker-Centric ™ Attacker-centric threat modeling starts with an tt k d l t th i l d h tha ac er, an eva ua es e r goa s, an ow ey might achieve them. Attacker's motivations are often considered for example "The NSA wants to , , read this email, “or“ Jon wants to copy this DVD and share it with his friends. This approach usually starts from either entry points or assets 27 Thu nhận yêu cầu Software-Centric ™ Also called • 'system-centric,' • 'design-centric,‘ 'architecture centric‘• - ™ Starts from the design of the system, and attempts to step through a model of the system , looking for types of attacks against each element of the model. This approach is used in threat modeling in Microsoft's Security Development Lifecycle. 28 Thu nhận yêu cầu Asset-Centric ™ Asset-centric threat modeling involves starting f t t t d t t hrom asse s en rus e o a sys em, suc as a collection of sensitive personal information. 29 Thu nhận yêu cầu Mục tiêu của threat modeling ™ Kể từ 2004, threat modeling đã chuyển từ quan điể đối đầ ( d i l) hò thủm u a versar a sang p ng (defensive) 30 Thu nhận yêu cầu Ví dụ về quan điểm đối đầu ™ Phân tích các software applications để tìm ra các lỗ hỗ (h l ) t hầ ề đó à tì á h ng o e rong p n m m v m c c khai thác lỗ hồng đó. ™ Kỹ th ật thường đượ dùng là kiểm thử âm nhập u c x (penetration testing), và code review. Nhược điểm: chỉ có thễ sử dụng kỹ thuật này khi phần mềm đã viết xong. 31 Thu nhận yêu cầu Ví dụ về quan điểm phòng thủ ™ Các mối đe dọa sẽ được nhận biết ngay trong giai đoạn thiết kế trước khi mã được viết. Sau khi nhận dạng được mối đe dọa, chúng sẽ được xem xét và tìm cách đối phó (countermeasure) hay giảm nhẹ (mitigations), ™ Lợi điểm của phương pháp này: ƒ Tiết kiệm chi phí ƒ Nâng cao được ý thức bảo mật của đội phát triển. ™ Bất lợi: ểƒ Không th nhận biết được mọi đe dọa. ƒ Gây ngộ nhận cho đội phát triển khi nghĩ mã luôn an toàn 32 Thu nhận yêu cầu Sáu bước phòng thủ 1. Define the application requirements: Identify business objectives user roles data use , , , cases 2 Model the application architecture: Model the. components of the application, service roles, external dependencies, data store for each use case 3. Identify any threats to the confidentiality, availability and integrity of the data and the application based on the data access control imatr x 33 Thu nhận yêu cầu Các bước phòng thủ threat 4. Assign risk values and determine the risk responses (ảnh hưởng của rủi ro) 5. Determine the countermeasures to implement based on your chosen risk responses 6. Continually update the threat model based on th i it l d (t à ả he emerg ng secur y an scape o n c n an ninh vừa phát sinh) 34 Thu nhận yêu cầu Yêu cầu và Tạo mô hình ™ Tạo mô hình mối đe dọa (Threat modeling) đượ hâ biệt ới h d l i là ơi ó ảc p n v azar ana ys s n n x y ra trong chu kỳ phần mềm Phân tích hiểm họa (Hazard analysis) có khuynhƒ hướng xảy ra sau khi phần lớn các phân tích yêu cầu mức cao đã hoàn tất ƒ Tạo mô hình mối đe dọa thường xảy ra song song với quá trình nhận diện và phân tích yêu ầc u (elicitation & analysis) ™ Có nhiều phương pháp để mô hình hóa, thông d hất là ử d kị h bảụng n s ụng c n. 35