Kĩ thuật trong EA giúp phân tích yêu cầu phần mềm

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG –˜&™— MÔN PHÂN TÍCH YÊU CẦU PHẦN MỀM BÀI THU HOẠCH CÁ NHÂN Giảng Viên Hướng Dẫn PGS.TS Huỳnh Quyết Thắng Sinh Viên Thực Hiện Bùi Song Toàn 20072929 Hà Nội 11/2010 Phần 1 : Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm Giới thiệu Mục đích Đưa ra các kĩ thuật phát hiện và tổng hợp các yêu cầu phần mềm. Phạm vi Trong các dự án phần mềm Tài liệu tham khảo Managing Software RequirementsDean Leffingwell - Don Widrig Các kỹ thuật phát hiện và tổng hợp phần mềm Kỹ thuật Phỏng vấn Những điểm chính Phỏng vấn là một kĩ thuật đơn giản và trực tiếp Các câu hỏi về phạm vi tự do sẽ giúp đạt được xu hướng của cuộc vấn Nó có thể thích hợp để tìm ra những yêu cầu chưa được phát hiện Sự hội tụ trong một vài yêu cầu phổ biến sẽ tạo ra một kho các yêu cầu sử dụng trong suốt dự án. Một sự nghi ngờ sẽ không được thay thế cho 1 cuộc phỏng vấn. Các câu hỏi phạm vi tự do Làm sao để tránh sự định kiến của người sử dụng khi đáp ứng yêu cầu của các câu hỏi? Chúng ta dùng các câu hỏi về các vấn đề tự nhiên của người sử dụng mà không liên quan đến bất cứ phạm vi công việc nào. ví dụng như: Ai là người sử dụng? Ai là khách hàng? Họ có cần một sự thay đổi? Ở đâu khác có thể tìm một giải pháp cho vấn đề này? Tạo thêm nội dung câu hỏi Trong quá trình tìm kiếm mà các yêu cầu chưa được phát hiện, chúng ta cũng có thể chuyển câu hỏi sang chủ đề khác , không nhất thiết bó buộc nội dung câu hỏi.Hãy tạo cảm giác thoải mái, cởi mở khi nói chuyện. Một vài lời khuyên khi phỏng vấn Một vài lời khuyên cho một cuộc phỏng vấn thành công: Sửa chữa các cuộc phỏng vấn tự do, và ghi nó vào một cuốn sách. Trước khi phỏng vấn, tìm kiếm lại các tổ chức của nhà đầu tư và công ty được phỏng vấn. Đừng làm phiền người được phỏng vấn. Nên ghi lại các câu trả lời vào trong sách. Tham khảo các template trong suốt quá trình phỏng vấn. Biên soạn lại các dữ liệu cần thiết Chú ý vào những sự đáng ngờ Kỹ thuật Hội thảo Tổng quát Những yêu câu hội thảo có lẽ là một kĩ thuật mạnh mẽ nhất để có thể phát hiện ra yêu cầu. Nó tập hợp lại tất cả các nhà đầu tư chính cùng nhau trong một khoảng thời gian ngắn nhưng lại là giai đoạn tập trung nhất. Sử dụng một tài liệu bên ngoài có kinh nghiệm trong việc quản lý yêu cầu và giúp đỡ cho một hội thảo thành công. Thảo luận, góp ý là phần quan trọng nhất của hội thảo Đẩy nhanh quá trình giải quyết Hỏi tất cả mọi người xem vấn đề chúng ta vừa đưa ra có đặc điểm nào cần bổ sung không trước khi đưa ra vấn đề tiếp theo. Các yêu cầu của một hội thảo có rất nhiều điểm phải phù hợp Nó phải giúp đỡ xây dựng một đội hiệu quả, tận tâm cho một mục đích chung: thành công trong dự án này. Tất cả mọi người đều được phát biểu. Phải tiến tới một sự đồng thuận giữa nhà đầu tư và đội ngũ phát triển về việc ứng dụng này phải làm gì. Có thể trình bày và giải quyết các vấn đề có thể gây trở ngại cho dự án thành công. Đưa ra định nghĩa sơ bộ cho hệ thống. Sửa chữa cho hội thảo Đưa ra các khái niệm Đảm bảo sự đóng góp của mọi người. Hậu cần Làm nóng bầu không khí. Vai trò của sự thuận tiện Để đảm bảo thành công, chúng ta cần lời khuyên của những người bên ngoài, những người đã có kinh nghiệm trong quá trình quản lý các yêu cầu. Một vài điểm liên quan đến các sự thuận tiện: Thiết lập một cuộc gặp mặt Bắt đầu và kết thục đúng thời gian. Thiết lập và đảm bảo quy tắc của cuộc họp. Giới thiệu mục đích và lịch công tác của cuộc họp Quản lý cuộc họp và giữ đội ngũ đi đúng hướng. Sự thuận tiện trong quá trình quyết định và sự đồng lòng, tránh các nội dung khác biệt. Đảm bảo lịch công tác đúng hướng. Tất cả sự khác biệt giữa các nhà đầu tư phải được lắng nghe. Kiểm soát các hành vi gây đổ vỡ và không mang lại giá trị. Thiết lập nhật kí công tác Đảm bảo rằng tất cả thành viên liên quan đến dự án phải được nhận được lịch họp. Cố gắng sắp xếp sao cho mọi người có thể đến được. Bắt đầu hội thảo - Thảo luận góp ý và các ý tưởng đưa ra. - Đưa ra các vấn đề và theo sau đó. Kỹ thuật BrainStorming Giới thiệu Brainstorming là một phương pháp đặc sắc dùng để phát triển nhiều giải pháp sáng tạo cho một vấn đề đặt ra. Ban đầu brainstroming được tạo ra để tìm ý tưởng trong làm việc theo nhóm. Alex F. Osborn đưa ra kỹ thuật này lần đầu tiên năm 1941, trong cuốn sách Applied Imagination.Alex F. Osborn đã miêu tả động não như là Một kĩ thuật hội ý bao gồm một nhóm người nhằm tìm ra lời giải cho vấn đề đặc trưng bằng cách góp nhặt tất cả ý kiến của nhóm người đó nảy sinh trong cùng một thời gian theo một nguyên tắc nhất định.Ngày nay phương pháp này đã được sử dụng rất phổ biến trong giảng dạy và sản xuất. Máy tính và các phần mềm hỗ trợ cũng được sử dụng cho brainstroming được hữu hiệu hơn. Áp dụng Định nghĩa vấn đề Vấn đề muốn giải quyết phải được xác định thật rõ ràng phải đưa ra được các chuẩn mực cần đạt được của một lời giải đáp. Tập trung vào vấn đề Tránh các ý kiến hay các điều kiện bên ngoài có thể làm lạc hướng buổi làm việc. Trong giai đoạn này người ta thu thập tất cả các ý kiến và ngay cả các từ chuyên môn có liên quan trực tiếp đến vấn đề cần giải quyết (thường có thể viết lên giấy hoặc bảng tất cả). Những ý kiến này đều được xem là có vai trò ngang nhau không phân biệt chi tiết lớn nhỏ. Việc ghi chép ra bảng cũng không nhất thiết phải liệt kê hay sắp xếp theo trình tự nào hết. Không được phép đưa bất kì một bình luận hay phê phán gì về các ý kiến trong lúc thu thập. Những ý tưởng thoáng qua trong đầu nếu bị các thành kiến hay phê bình sẽ dễ bị gạt bỏ và như thế sẽ làm mất sự tổng quan . Khuyến khích tình thần tích cực Mỗi thành viên đều cố gắng dóng góp và phát triển các ý kiến tùy theo trình độ, khía cạnh nhìn thấy riêng và không giới hạn cách nhìn của mỗi thành viên. Đưa ra càng nhiều ý càng tốt về mọi mặt của vấn đề kể cả những ý kiến không thực tiễn, ý kiến hoàn toàn lạ lẫm hay sáng tạo Tiến hành Trong nhóm lựa ra một người đầu nhóm và một người thư kí để ghi lại tất cả ý kiến (cả hai công việc có thể do cùng một người thực hiện nếu tiện). Xác định vấn đề hay ý kiến .Phải làm cho mọi thành viên hiểu thấu đáo về đề tài sẽ được tìm hiểu. Thiết lập các quy định cho buổi họp,bao gồm: Người đầu nhóm có nhiệm vụ điều khiển buổi làm việc. Không một thành viên nào có quyền đòi hỏi hay cản trở, đánh giá, phê bình hay thêm bớt vào ý kiến, từ vựng nêu ra, hay giải đáp của thành viên khác. Cần xác định rằng không có câu trả lời nào là sai! Tất cả câu trả lời, các ý, các cụm từ, ngoại trừ nó đã được lập lại đều sẽ được thu thập ghi lại (cách ghi có thể tóm gọn trong một chữ hay một câu cho mỗi ý riêng rẽ). Vạch định thời gian cho buổi làm việc và ngưng khi hết giờ. Bắt đầu brainstroming: Người lãnh đạo chỉ định hay lựa chọn thành viện chia sẻ ý kiến trả lời .Người thư kí phải viết xuống tất cả các câu trả lời, nếu có thể công khai hóa cho mọi người thấy (viết lên bảng chẳng hạn). Không cho phép bất kì một ý kiến đánh giá hay bình luận nào về bất kì câu trả lời nào cho đến khi chấm dứt buổi thảo luận. Sau khi kết thúc, hãy lượt lại tất cả và bắt đầu đánh giá các câu trả lời. Một số lưu ý về chất lượng câu trả lời bao gồm: Tìm những câu ý trùng lặp hay tương tự để thu gọn lại. Góp các câu trả lời có sư tương tự hay tương đồng về nguyên tắc hay nguyên lí.Xóa bỏ những ý kiến hoàn toàn không thích hợp. Sau khi đã cô lập được danh sách các ý kiến, hãy bàn cãi thêm về câu trả lời chung. Trong khi áp dụng brainstroming tất cả các ý tưởng xuất hiện trong đầu của các thành viên trong nhóm sẽ được viết hay vẽ ra, thông thường là bút chì và giấy trắng. Người ta viết bất cứ thứ gì có trong đầu ra mặt giấy (brain dumping), không cần phải suy nghĩ nó là một ý tưởng tốt hay chỉ là một suy nghĩ thoảng qua trong đầu. Người ta cũng chẳng cần bận tâm đến việc thẩm mỹ của việc trình bày đó. Nếu cần diễn tả một hình ảnh, nó sẽ được phác họa thật nhanh chóng. Khi phát hiện ra mình viết sai thì cũng chẳng cần phải quay lại để sửa chữa, mà sẽ để suy nghĩ của mình được liên tục. Brainstroming không suy nghĩ về chỉ 1 thứ mà suy nghĩ đến tất cả những thứ có liên quan đến nó. Người ta cứ viết hay vẽ mà không cần dừng bút để suy nghĩ. Nếu bạn dừng bút trong khoảng thời gian dài hơn 10 giây, điều đó có nghĩa là bạn đã khai thác quá nhiều về ý tưởng đó, hãy lập tức bỏ qua một bên và quay sang những thứ liên quan khác, và rồi sẽ quay lại với nó ở giai đoạn sau. Mục đích của quá trình Brainstorming không phải là tìm được chính xác một ý tưởng hoàn thiện mà là đưa ra được càng nhiều ý tưởng càng tốt, do đó không nên e ngại khi viết ra những điều mà bình thường bạn nghĩ.Ngoài việc đưa ra thật nhiều ý tưởng, brainstorming còn giúp ta phân tích kỹ vấn đề, tự xem xét tất cả vấn đề có thể xảy ra khi trong khi ta liên tục đặt ra những câu hỏi. Ứng dụng: Brainstorming được sử dụng trong các công việc sau đây như phát triển sản phẩm mới; quảng cáo; giải quyết vấn đề; quá trình quản trị; quản trị dự án; xây dựng nhóm; xây dựng kế hoạch kinh doanh. Một vài nhận xét Phương pháp này có thể tiến hành bởi một hay nhiều người. Số lượng người tham gia nhiều sẽ giúp cho phương pháp tìm ra lời giải được nhanh hơn hay toàn diện hơn nhờ vào nhiều góc nhìn khác nhau bởi các trình độ, trình tự khác nhau của mỗi người.Ngày nay, người ta có thể tiến hành bằng cách nối các máy tính cá nhân vào chung một mạng làm cùng tiến hành brainstroming. Bằng cách này những người ở xa nhau cùng có thể tham gia và brainstroming còn được giúp đỡ bởi các phương tiện và tài nguyên hiện đại Kỹ thuật StoryBoarding Những điểm chính Mục đích là đưa ra các phản ứng sớm “yes, but” Kỹ thuật này có thể là thụ động, chủ động hay là kết hợp cả 2 yếu tố trên. Kỹ thụât này nhận diện người chơi, giải thích những gì xảy ra với họ, xảy ra như thế nào Tạo ra storyboard sơ sài, dễ sửa chữa. 4.2 Các loại StoryBoards Storyboards dạng thụ động: là dạng storyboard để kể cho người dùng một kịch bản. Chúng có thể bao gồm các bản phác thảo, tranh ảnh, hình chụp màn hình, bản thuyết trình powerpoint, hoặc các mẫu đầu ra thử nghiệm. Storyboards dạng chủ động: Storyboards chủ động là các hoạt cảnh hoặc tự động, có thể bằng một slide trình chiếu được sắp xếp tự dộng sẵn hoặc một công cụ tạo hoạt cảnh hay thậm chí là cả một thước phim. Storyboards tương tác: để cho người dùng trải nghiệm hệ thống trong một cách thức giống với thực tế. Cách này đỏi hỏi phải có sự tham gia của người sử dụng để thực hiện được. Storyboards tương tác có thể giả lập hoặc tạo dựng mô hình hay có thể nâng cao tới mức mã dùng một lần (throwaway code). StoryBoards làm những gì? Trong phần mềm, Storyboards được sử dụng thường xuyên để làm việc thông qua các chi tiết của giao diện tương người máy. Trong Lĩnh vực này, mỗi người có thể có ý kiến khác nhau về cách thức giao diện làm việc. Storyboards cho hệ thống người dùng xử lý với ba yêu tố của hoạt động Người chơi là ai? Điều gì xảy ra với họ? Nó xảy ra như thế nào? Công cụ và kỹ thuật cho StoryBoarding Kỹ thuật Use Case Use cases là một biểu diễn UML cho các yêu cầu của một hệ thống. Để ghi nhận các yêu cầu cho hệ thống, use cases phát triển trong quá trình phát hiện sẽ có giá trị hơn nữa ngay cả trong quá trình phân tích và thiết kế. Phương pháp use-case rất mạnh mẽ trong suốt quá trình phát triển phần mềm, ví dụ như use cases đóng một vai trò quan trọng trong quá trình kiểm thử.Use cases miêu tả sự tương tác giữa user và hệ thống, và tập trung vào những gìhệ thống tương tác với user. Hơn nữa, khi các hành động được miêu tả theo một trình tự nối tiếp, sẽ là dễ dàng để theo dõi hành động và thu thập được sự hiểu biết về những gì hệ thống tương tác với user. Trong biểu đồ UML, use case được biểu diễn bằng một hình oval chứa tên của use case. Xây dựng Use Case Mô hình use-case cho một hệ thống bao gồm tất cả actor của hệ thống và tất cả các use cases khác nhau mà theo đó các actor tương tác với hệ thống, theo cách đó miêu tả một cách toàn bộ hành vi chức năng của hệ thống. Mô hình use-case cũng biểu diễn mối quan hệ giữa các use cases, mà nằm ngoài sự hiểu biết của chúng ta về hệ thống. Đầu tiên là tạo biểu đồ mô tả ranh giới hệ thống và xác định các actor của hệ thống. Việc này tiến hành song song với việc xác định stakeholders và ranh giới hệ thống. Ví dụ một hệ thống quản lý kho hàng có thể có ranh giới hệ thống như hình sau: Hệ thống kho hành ban đầu với các actor được xác định.Việc phân tích hệ thống sâu hơn xác định những luồng nhất định của hành vi hệ thống là cần cho việc hỗ trợ nhu cầu người dùng. Những luồng này là các use cases, hoặc những trình tự cụ thể mà users tương tác với hệ thống để thực hiện một mục tiêu cụ thể. Các ví dụ của use cases cho hệ thống này có thể bao gồm: • Phân phối thủ công các mục trong kho hàng. • Nhập một mục mới trong kho hàng. • Kiểm tra các mục trong kho hàng. Áp dụng Use Case vào phân tích yêu cầu phần mềm Use cases được viết theo ngôn ngữ tự nhiên của user nên rất dễ dàng để miêu tả vàlàm tài liệu. Use cases cung cấp một định dạng đơn giản và có cấu trúc xoay quanh việc nhóm phát triển và user có thể làm việc cùng nhau để mô tả hành vi của một hệ thống có sẵn hoặc định nghĩa hành vi của một hệ thống mới. Và mỗi user độc lập sẽ tự nhiên tập trung vào những khả năng hệ thống cần để thực hiện công việc tốt hơn. Ngoài ra, nếu các hành vi được phát hiện đầy đủ với tất cả các user tiềm năng, nhóm làm việc đã đi được một đường dài hướng tới mục tiêu của sự hiểu biết đầy đủ của các hành vi mong muốn. Ở đây có thể có một vài chức năng chưa được khám phá ở cuối quá trình. Chúng ta cũng phải hiểu rằng users của hệ thống chỉ biểu diễn một lớp của stakeholders, và chúng ta có thể cần phải áp dụng các kĩ thuật khác để thu thập yêu cầu từ những stakeholder khác như các khách hàng không phải người dùng, quản lý, nhà thầu phụ … Ngoài ra, use cases không hữu ích trong việc xác định các khía cạnh phi chức năng của yêu cầu hệ thống, như yêu cầu cho tính khả dụng, tính tin cậy, hiệu năng và tương tự. Chúng ta cần những kĩ thuật khác để giải quyết những vấn đề này. Sau khi tất cả use cases, actors và objects trong hệ thống được xác định, bước tiếp theo là cải tiến hành vi chức năng chi tiết của mỗi use-case. Đặc tả use-case này bao gồm miêu tả bằng văn bản và đồ họa của use-case, được viết từ góc nhìn của user. Đặc tả này có thể xem như là một container miêu tả một chuỗi các sự kiện lien quan, do đó có thể được dùng để bao hàm các yêu cầu khác sẽ được phát triển hơn nữa vào thời gian sau.Vì use cases định nghĩa tương tác hệ thống với user, đây là thời điểm thích hợp để định nghĩa, ít nhất là ở mức khái niệm, màn hình, các hiển thị, front panels … mà tương tác với user. Các thiết kế đồ họa chi tiết có thể để tới bước tiếp theo. Đặc tả use-case cho “Phân phối thủ công các mục trong kho hàng” Role Playing Mặc dùng đúng là việc quan sát và đặt câu hỏi giúp chúng ta hiểu, nhưng sẽ là không đầy đủ nếu cho rằng, chỉ thông qua việc quan sát, các nhà phát triển và phân tích có thể đạt được một sự hiểu biết đúng đắn và sâu sắc của vấn đề được giải quyết, do đó, một sự hiểu biết rõ ràng về các yêu cầu của một hệ thống có thể giải quyết vấn đề này. Chúng ta cần hiểu rằng rất nhiều người dùng không thể hiểu rõ các thủ tục họ làm theo hoặc yêu cầu cần được giải quyết. Rất nhiều user không có tự do để thừa nhận rằng họ không theo những thủ tục được quy định, do đó những gì họ nói có thể không phải những gì họ thực sự làm. Các cá nhân có những mẫu của hoạt động công việc đã ăn sâu và áp dụng cách giải quyết hoặc con đường duy nhất của việc thực thi công việc đó có thể che đậy vấn đề thực từ người quan sát. Là không thể cho bất kì người phát triển nào để đự đoán tất cả các câu hỏi cần được hỏi hoặc cho bất kì user nào biết câu trả lời cho các câu hỏi của nhà phát triển. Để giải quyết các nguyên nhân riêng biệt này, một hoạt động đơn giản “role playing” có thể có hiệu quả mạnh mẽ. How to Role Play Trong dạng đơn giản nhất của role playing, các nhà phát triển, nhà phân tích và có thể mọi thành viên của nhóm phát triển đơn giản là đảm nhiệm vị trí của user và thực thi hoạt động công việc của khách hàng. Có ít nhất hai cách để tìm thấy nguyên nhân cốt lõi: Sử dụng kĩ thuật fishbone, cùng với phỏng vấn khách hàng, và phân tích các đơn đặt hàng có lỗi. Định lượng lỗi theo loại và giải quyết những lỗi có số lượng cao nhất trong thiết kế của hệ thống mới. Việc này có thể cung cấp một sự hiểu biết có định lượng cho vấn đề và có lẽ là khá hiệu quả.Tuy vậy, nếu không hiệu quả, bạn nên thay đổi cả quan điểm của bạn và chiến lược giải pháp của bạn. Để làm được điều đó, nên có một cách đơn giản và hiệu quả hơn để hiểu một cách rõ ràng về vấn đề. Nhà phát triển, phân tích có thể trải nghiệm vấn đề và sai sót cố hữu trong hệ thống bằng việc thâm nhập vào một vài đơn hàng thực. Các kĩ thuật khác tương tự Kỹ thuật Prototyping Các điểm chính Prototyping (làm mẫu) cực kỳ hiệu quả trong việc xác định vị trí các hội chứng “Có,nhưng” (không chắc chắn, không bền, không đảm bảo tính lâu dài ...) và “những thất bại vẫn chưa được phát hiện” (rủi ro tiềm tàng). Một mẫu các yêu cầu phần mềm là một sự thi hành riêng lẻ của hệ thống phần mềm, được xây dựng để giúp đỡ các developers, người dùng và khách hàng hiểu tốt hơn về yêu cầu hệ thống. Thực hiện làm mẫu các yêu cầu còn “mờ”, còn chưa rõ ràng: nhờ đó, mặc dù những điều đã biết hoặc còn “ẩn ý” vẫn chưa được định nghĩa hoặc còn được hiểu chưa rõ ràng. Các mẫu phần mềm là hiện thân sớm của hệ thống phần mềm, cho chúng ta ta một phần chức năng của một hệ thống mới.Mẫu thử cho phép người dùng có thể chạm, cảm nhận và tương tác với một hệ thống mẫu theo cách mà không một công nghệ nào khác có thể làm được. Các kiểu mẫu thử Các mẫu thử có thể được phân loại theo nhiều cách (throwaway, evolutionary, operational, vertical, horizonal, userinterface algorithmic ...). Tùy vào vấn đề cần giải quyết mà chúng ta xây dựng các mấu thử khác nhau. Architectural prototype (mẫu thử hướng kiến trúc) – cho chúng ta thấy khả năng có thể thực thi được của công nghệ. Throwaway prototype (mẫu thử dùng một lần) – sử dụng bất cứ công nghệ, sự mô phỏng ... hay bất cứ cái gì để hoàn thiện kết quả của bạn. Mẫu chỉ dùng cho một mục đích, sau khi hoàn thành, mẫu sẽ được bỏ đi Nếu điểm yếu của dự án là giao diện người dùng, ngược lại bạn sẽ phát triển một mẫu thử yêu cầu (requirements prototype), sử dụng bất cứ công nghệ gì cho phép bạn làm mẫu giao diện nhanh nhất có thể. Sử dụng cây quyết định để chọn loại mẫu thử tốt nhất cho hệ thống phần mềm. Figure 1 Decision tree for prototype selection: (a) requirements prototypes; (b) architectural prototypes Requirements Prototypes – Các mẫu thử yêu cầu Mẫu thử yêu cầu phần mềm (software requirements prototype) là sự thi hành cục bộ (riêng lẻ) của hệ thống phần mềm, được xây dựng để giúp các nhà phát triển (developers), người dùng (users) và khách hàng (customers) hiểu tốt hơn về yêu cầu của hệ thống. Vì mục đích phát hiện ra các yêu cầu phần mềm, chúng ta thường chọn cách xây dựng các mẫu thử như “throwaway, horizonal(rộng), user interface” prototype (mẫu thử dùng một lần, mẫu thử rộng, mẫu thử người dùng). Horizonal prototypes (các mẫu thử rộng) ám chỉ rằng chúng ta sẽ thử xây dựng một dải khá rộng chức năng của hệ thống, ngược lại, vertical prototype xây dựng chỉ một vài yêu cầu nhưng theo một số phương pháp khá chất lượng. User interface prototype ngụ ý rằng chúng ta sẽ xây dựng hầu hết các giao diện của hệ thống hơn là để người dùng thi hành các giải thuật và các logic xung quanh phần mềm hoặc làm cả mẫu thử giao diện cho các hệ thống khác, thiết bị khác. Khi là một công cụ khai thác, một mẫu thử giữ vai trò của nó theo vài cách khác nhau : Được xây dựng bởi người phát triển, nó có thể chứa sự xác nhận của khách hàng rằng người dùng đã hiểu yêu cầu. Được làm bởi người phát triển, nó có thể được dùng như xúc tác khuyến khích khách hàng nghĩ thêm các yêu cầu khác. Được làm bởi khách hàng, nó có thể giúp trao đổi thông tin với nhà phát triển. Trong cả ba trường hợp, kết quả sẽ là xây dựng mẫu theo phương pháp tiêu tốn ít tài nguyên nhất. Nếu nó quá đắt để xây dựng, nó có thể có hiệu quả hơn khi áp dụng vào hệ thống thật. Nhiều mẫu thử phần mềm xoay sang hướng mẫu thử yêu cầu và được sử dụng chủ yếu để nắm được diện mạo của giao diện hệ thống cần xây dựng. Có hai lý do cho việc này : Có nhiều công cụ, có chi phí không quá đắt và đôi khi là miễn phí hỗ trợ việc xây dựng giao diện rất nhanh. Với các hệ thống có tương tác người dùng khá nhiều, một giao diện người dùng được làm mẫu sẽ khám phá ra rất nhiều các yêu cầu khác, như các chức năng đã được cung cấp tới cho người dùng, khi nào các chức năng sẵn sàng cho người sử dụng và khi nào các chức năng chưa xuất hiện với người dùng. Tuy nhiên, chúng ta cần chắc chắn rằng tính khả dụng của những công cụ này không làm ảnh hưởng tới việc xây dựng mẫu thử cho các phần của hệ thống không có rủi ro cao nhất khi bắt đầu. Làm mẫu thử cho cái gì (What to prototype): Trong một tình huống cụ thể, chúng ta hiểu về những nhu cầu của người dùng sẽ có phạm vi từ hiễu rõ và dễ dàng diễn đạt tới không hiểu gì: Figure 2 Continuum of understanding user needs (Well-understood requirements) Hiểu rõ yêu cầu có hiển nhiên nhận thấy được từ ngữ cảnh của miền ứng dụng và kinh nghiệm của người dùng và kinh nghiệm của đội với một hệ thống cũng kiểu. (Unknown requirements)Những yêu cầu chưa biết, mặc dù, là những rủi ro chưa được phát hiện (“Undiscovered Ruins”) mà chúng ta thường mong là sẽ biết đến sau đó. Nhưng không may thay,chúng ta không thể làm những mẫu thế này, nếu có thể, chúng sẽ không còn là chưa biết tới nữa (unknown). Chính việc này đã đặt vị trí cho việc làm mẫu thử các phần “mờ” (fuzzy part) ở giữa. Những yêu cầu này (Fuzzy) có thể được biết tới hoặc được ngầm hiểu nhưng chúng thường được định nghĩa khá nghèo nàn và tiếp thu được rất ít thông tin. Xây dựng mẫu thử Sự lựa chọn công nghệ sử dụng trong khi xây dựng mẫu thử phụ thuộc vào các quyết định trong tương lai (ở phía bên phải cây quyết định). Đánh giá kết quả (Evaluating the results): Kết quả của chu trình làm mẫu có thể gói gọn trong hai ý : Tính “mờ” cần được hiểu rõ ràng hơn. Thử nghiệm mẫu chắc chắn sẽ khám phá ra một đáp ứng “Có, nhưng ...” từ phía người dùng, do đó, những nhu cầu trước kia chưa biết sẽ “lộ ra” (become known). Đơn giản nhìn một tập các hành vi sẽ giúp người dùng hiểu những yêu cầu khác phải được đảm đương trong hệ thống. Trong bất cứ trường hợp nào, Prototyping luôn luôn đưa ra được kết quả. Do đó, bạn nên làm mẫu bất cứ ứng dụng mới nào. Sử dụng EA trong phát hiện và Tổng hợp yêu cầu Sử dụng EA với kĩ thuật BrainStorming Sử dụng Mind Mapping Diagram để phát triển các ý tưởng trong những lần BrainStorming Sử dụng EA với kĩ thuật Prototyping (Mẫu : GUI) Ví dụ một số mẫu GUI Xây dựng một số mẫu GUI có sẵn lấy ý kiến người dùng hay kiếm tra yêu cầu của các chức năng Sử dụng EA với kĩ thuật Use Case Phần 2 : Các kỹ thuật phân tích các yêu cầu phần mềm Giới thiệu chung Mục đích Mục đích của phần báo cáo này là giúp người đọc hiểu được các kỹ thuật phân tích yêu cầu và sử dụng EA trong phân tích yêu cầu. Phát hiện và giải quyết xung đột giữa các yêu cầu. Phát hiện ra phạm vi của phần mềm và và nó phải tương tác như thế nào với môi trường. Yêu cầu hệ thống phức tạp bắt nguồn từ các yêu cầu phần mềm Phạm vi Phạm vi trong các dự án phần mềm Tài liệu tham khảo Các kỹ thuật phân tích yêu cầu phần mềm Requirement Classification Giới thiệu Function Requirements Yêu cầu chức năng nói rõ hành hệ thống hoạt động như tế nào. Những yêu cầu thường hướng hành động Non-Function Requirements Tính khả dụng Độ tin cậy Hiệu năng Hỗ trợ Design Contraints Hạn chế tối thiểu trên thiết kế của hệ thống hoặc quy trình chúng tôi sử dụng để xây dựng hệ thống. Conceptual Modeling Mô hình phát triển của một vấn đề thực là chia khóa đến phân tích yêu cầu phần mềm. Mục đích của chúng là giúp đỡ trong việc hiểu vấn đề hơn là thực thi thiết kế giải pháp. Sau đây khái niệm mô hình bao gồm mô hình thực thi từ vẫn đề cấu hình tên miền đến phản ánh các mỗi liên hệ trong thế giới thực và sự phụ thuộc. Một số loại mô hình có thể được phát triển, chúng bao gồm dữ liệu và các luồng điều khiển, trạng thái của mô hình, sự kiện rằng buộc, tương tác giữa các user, các mô hình đối tượng, các mô hình dữ liệu và nhiều cái khác. Một vài mô hình có thể được phát triển. Nhân tố ảnh hưởng lựa chọn mô hình bao gồm : Vấn đề tự nhiên. Một vài kiểu nhu cầu phần mềm mà khía cạnh chắc chắn được phân tích chính xác các phần. Sự thành thạo của kĩ sư phần mềm. nó thường tạo ra nhiều hơn chấp nhận lời giải thích mô hình hoặc phương thức với những kĩ sư phần mềm có kinh nghiệm. Các yêu cầu quy trình của khách hành Những phương thức và công cụ có giá trị. Architectural Design and Requirements Allocation ở vài điểm này, kiến trúc của giải pháp phải được suy ra . thiết kế kiến trúc là điểm mà ở đó các yêu cầu tiến triển chồng lên nhau với phần mềm hoặc thiết kế các hệ thống và minh họa nó có thể xóa sự tách biệt của hai nhiệm vụ. Có nhiều lựa chọn, kĩ sư phần mềm hành động như kiến trúc phần mềm bởi quy trình của phân tích và dàn dựng các yêu cầu theo yêu cầu cái mà thành phần của chúng sẽ chịu trách nhiệm nhận biết các yêu cầu an toàn. Đây là yêu cầu cấp phát- sự phân công các thành phần có trách nhiệm đáp ứng các yêu cầu. Phân bỏ rất quan trọng cho việc phân tích chi tiết các yêu cầu. Sau đây cho ví dụ một bộ các yêu cầu được chỉ định các thành phần, các yêu cầu cá nhân có thể được tiếp tục phân tích để khám phá thêm các yêu cầu trên các thành phần cần tương tác với các thành phần khác như thế nào để đáp ứng được sự phân bố các yêu cầu. trong một dự án lớn, sự phân bố khuyến khích một vòng lớn của phân tích các hệ thống con. Lặp lại yêu cầu và thiết kế. Sử dụng các yêu cầu Parent-Child để tăng tính đặc trưng Thiết kế kiến trúc được xác định chặt chẽ với khái niệm mô hình hóa. Việc ánh xạ từ đên miền thực thể trọng thế giới thực đến thành phần phần mềm không phải luôn luôn rõ ràng, vì vậy thiết kế kiến trúc được xác định là một chủ đề riêng biệt. các yêu cầu kí hiệu và các phương thức được rộng rãi như cả hai khái niệm mô hình và thiết kế kiến trúc. Requirements Negotiation Một thuật ngữ khác được sử dụng cho chủ đề này là “ conflict resolution” . Điều quan tâm này giải quyết vẫn đề với các yêu cầu mà sự xung đột xảy ra giữa hai yêu cầu của các bên liên quan cùng các tính năng không tương thích , giữa các yêu cầu và nguồn lực hoặc giữa yêu cầu chức năng và yêu cầu phi chức năng. Trong tất cả các trường hợp , nó không thận trọng cho các kĩ sư phần mềm làm các quyết định đơn phương và do đó nó cần thiết tham khảo từ các bên liên quan để đạt được một sự đồng thuận trên sự thỏa hiệp thích hợp. Sử dụng Use Cases Để hỗ trợ các hoạt động thiết kế và mã hóa, các Use Case phát triển trong các hoạt động suy luận hơn là xây dựng đầy đủ. Các Use Cases thích hợp nhất khi hệ thống giàu chức năng và phải hỗ trợ các loại người dùng khác nhau. Các Use Case không có hiệu quả khi áp dụng đến hệ thống với một vài hoặc không có giao diện người dùng tối thiểu, chủ yếu là những yêu cầu phi chức năng và những hạn chế khi thiết kế. Kĩ thuật trong EA giúp phân tích yêu cầu phần mềm Xem xét cấu trúc phân cáp và cài đặt của yêu cầu phần mềm Sử dụng cửa sổ Hierachy. Khi lựa chọn 1 Requirement, ta sẽ xem được các thông tin về: Quan hệ phân cấp của Requirement: cho biết nó là con của các Requirement nào, cha của các Reqiurement nào, quan hệ thuộc loại nào (sở hữu hay kết tập) … Quan hệ về cài đặt của Requirement: nó được cài đạt bởi các Element nào. Nếu Requirement có các Requirement con, EA có thể chi tiết việc cài đặt của từng Requirement con đó. Phân tích sự phụ thộc của yêu cầu Sử dụng ma trận quan hệ (Relationship Matrix): thông qua cửa sổ Relationship Matrix. Cho biết quan hệ giữa các đối tượng trong 2 package Quản lý thay đổi Sử dụng cửa sổ Audit View: ghi chép lại các thay đổi đã thực hiện. Kích hoạt Audit View: Mở cửa sổ Audit View Chọn Audit Settings Enable Auditing Lập báo cáo Sử dụng menu Project | Documentation Lập các báo cáo đặc tả thông thường : thông tin về Requirement và các Requirement con tương ứng. Có nhiều định dạng văn bản khác nhau như: Rich Text Format, HTML,… Báo cáo quan hệ cài đặt Báo cáo quan hệ phụ thuộc Phần 3 : Xây dựng tài liệu đặc tả yêu cầu phần mềm Giới thiệu chung Mục đích Mục đích của phần báo cáo này nói rõ cách đặc tả yêu cầu phần mềm Tài liệu tham khảo Requirements Management in Enterprise Architect Slide môn Xây Dựng và Thiết Kế Phần Mềm Của thầy Huỳnh Quyết Thắng Managing Software Requirement Đặc tả các yêu cầu phần mềm Giới thiệu Không phụ thuộc các yêu cầu phần mềm được tìm ra , được xây dựng như thế nào, cuối cùng bao giờ chúng ta cũng phải đặc tả các yêu cầu này. Các tiêu thức để đánh giá một đặc tả: Tính nhất quán Tính thân thiện Dễ sử dụng Trong đặc tả phải nêu được cả Business Requirement, phạm vi ứng dụng, giới hạn của ứng dụng. Trong đặc tả phải nêu được đầy đủ các User Requirement, sử dụng các mẫu (template) của các trường hợp sử dụng của từng yêu cầu. Các điểm lưu ý khi đặc tả yêu cầu phần mềm Làm theo và sử dụng các mẫu đặc tả : nên quy định một mẫu đặc tả chung trong tổ chức của chúng ta, sử dụng một số mẫu (template) nào đó: IEEE 830 – 1998. Lưu ý rằng hoàn toàn có quyền sửa đổi , quy định lại các biểu mẫu nếu như điều đó là cần thiết. Xác đinh rõ nguồngốccủayêucầuphầnmềm trongđặc tả: để có thể tấtcả biết đượctạisaolại phát sinhcác yêu cầuphầnmềm này, chúng ta nên chỉ rõ tạisaonólạicó-từ NSD, yêu cầuchứcnăng hệ thống, do quy chế, hay do các nguồn khác. Đặt nhãn (label) cho từng yêu cầuphầnmềm: chúng ta nên thống nhất quy ướccách đặt nhãn (tên) chocác yêu cầu - nên đặt nhãn làm sao nhãn củacácyêu cầu mang càng nhiều các thông tin về các yêucầu đó càng tốt. Ghi lại các nguyên tắccủa công việc (business rule): các nguyên lý hoạt động củahệ thống, của các thaotác, công việccần đượcmiêutả. Nên tạorama trận theo dõi các yêu cầuphầnmềm (requirements traceability matrix): điều này rấtcóíchtrong quá trình phân tích các yêu cầu, quá trình thiếtkế, lập trình và kiểmthử các chứcnăng củahệthống. Ma trậnnàycũng rất có ích giúp cho chúng taliên kếtcácchứcnăng vớicácyêucầuphầnmềmliên quan. Nên sử dụng thường xuyên ma trận trongsuốt thời gian phát triển phần mềm Ghi lại các nguyên tắc của công việc Khi NSD miêu tả cho chúng ta mộthoạt động nào đó chỉđượcthựchiện trong những diềukiệnnhất định, donhững tác nhân nhất định, v.v. tức là chúng ta đãcómột nguyên tắc công việc. Nguyên tắc côngviệclàtậphợp các các nguyên tắc hoạt động của quá trình thựchiện công việc. Chúng ta có nghĩ vụ phải xây dựng các yêu cầuhệthống về mặtchứcnăng để đáp ứng các nguyên tắccông việc này - tuy nhiên không nền đồng nhấtyêucầuchứcnăng với nguyên tắc công việc. Trong SRS nên tậphợpvà đặctả tấtcả các nguyên tắc của công việcvàomộtmục riêng. Đặc tả yêu cầu phần mềm theo mẫu Có thể nó đặctả yêu cầuphầnmềm (SRS) được coi như: đặctả chứcnăng hệ thống, sự thoả thuậnvề chứcnăng, đặctả hệ thống. SRS là cơ sở cho mọihoạt động củadự án: phân tích, thiếtkế, lậpkế hoạch, viếtmã, kiểmthử, v.v. Khi đặctả yêu cầuphầnmềmcóthể sử dụng các công cụ: Vănbản (textual document) Mô hình đồ hoạ (graphical models) Các ngôn ngữđặctả hình thức Các điểmlưuý: Tấtcả các yêu cầuphầnmềmphải được đua vào đặctả. SRS đượcxâydựng trước khi phân tích và xây dựng phầnmềm Gán nhãn các yêu cầu phần mềm Để có đượcmột đặctả tốt, có thể theo dõi mối liên quan giữacácyêucầu, quá trình phát sinh rachúng, v.v. chúng ta cầncómột quy định gánnhãn các yêu cầu một cách khoa học. Có một số phương pháp thông dụng: Gánnhãnliêntiếp (sequence number): UR - xxxx Gán nhãn theo thứ bậc (Hierarchical numbering): UR 3.2.1 (phương pháp này đượcsủdụng rộngrãi nhất) Gán nhãn theo tên thẻ thứ bậc (Hierarchical texttual tags):Print.Copies.Confirm Đánh dấu những điểm chưa rõ ràng trong đặc tả Đôi khi chúng ta thiếumộtsố các thông tin về các yêu cầuphầnmềm, chúng ta cầnthảoluậnvớiNSD để biếtchi tiếthơn, v.v. Tấtcả những chỗnhư vây nên được đánh dấubằng “To be determined’ - TBD. Như vậy chúng ta đã phânđịnh rõ những điểmthiếu (gaps) trong đặctảđểcầnlàsángtỏ. Tấtcả các TBD này phải được giải quyếttrướckhi bắt đầu quá trình phân tích và xây dựng phầnmềm. Mỗi liên quan giữa đặc tả và giao diện người sử dụng Sự kếthợpgiữathiếtkế giao diện trong SRS có cảưu điểmvànhược điểm: Nhược điểm: Các yêu cầuvề giao diệnthựcchấtchỉ là các giải pháp màkhông phảilàcácyêucầuphầnmềm. Quá trình xây dựng các yêu cầusẽ kéo dài NSD, khách hàng có thể tốnrất nhiềuthờigianvớigiaodiệnmà quên đi nhiệmvụ chính củahọ là giúp chúng ta xâydựng các yêu cầuphầnmềm Các giao diệnxâydựng ở giai đoạn này chỉ mang tính chấtđịnh hướng Ưu điểm: Có khả năng trau chuốtcácyêucầuphầnmềm, xây dựngcác tương tác trở nên hữuhìnhvàdễ hiểuhơnchocảkhách hàng và cả các PTV Trợ giúp tốthơnchoviệclậpkế hoạch và đánh giá khốilượng công việc. Kếtluận ở đây là nên sử dụng mộtsố giao diệnchuẩnhoặc các mô hình giao diệnở mức độ vừaphải để đưavào đặctả: mô hình chung của các giao diệnnhậpliệu, các giao diện-mànhình xửlý, giao diện-mànhinhhiểnthị, các hộpthoại, v.v. Các mẫu đặc tả yêu cầu phần mềm Một số phiên bản của SRS template được khuyến nghị nên sử dụng: • Robertson and Robertson 1999 • IEEE 830-1998 Template SRS IEEE 830 -1998 IEEE 830-1998 Adapted and Extended Template: Introduction Purpose of this document Document Convention Intended Audience and Reading Suggestion Product Scope References Overall Description Product perspective Product Functions User Characteristics Operating Environment Design and Implementation Constraints Assumptions and Dependencies External Interface Requirement User Interface Hardware Interface Software Interface Communication Interface System Features System Feature X Description and Priority Stimulus/Response Sequences Functional Requirement Other Non-Functional Requirement Performance Requirement Safety Requirement Security Requirement Software Quality Attributes Business Rules User Documentation Other Requirement Appendix A: Glossary Appendix B: Analysis Model Appendix C: To - Be - Determined List Phương thức kỹ thuật cho đặc tả yêu cầu Phương thức kỹ thuật cho đặc tả các yêu cầu là thích hợp khi mô tả các yêu cầu là không quá phức tạp với ngôn ngữ tự nhiên hoặc nếu bạn không có đủ khả năng có đặc tả dễ hiểu. Phương thức kỹ thuật bao gồm mã giả, máy trạng thái hữu hạn, cây quyết định, biểu đồ hoạt động, mô hình thực thể liên kết, phân tích hướng đối tượng và phân tích cấu trúc. Chúng ta lựa chọn từ một vài phương thức đặc tả kỹ thuật: mã giả, máy trạng thái hữu hạn, cây quyế định, biểu đồ hoạt động, mô hình thực thể liên kết, phân tích hướng đối tượng và phân tích cấu trúc Chức năng EA hỗ trợ đặc tả yêu cầu phần mềm Tạo các yêu cầu ngoài (External Requirements) Kích chuột trái Custom Button trong UML Toolbox để mở một bảng tùy chọn Kích và chọn thành phần Requirement từ tùy chọn trên biểu đồ EA cho phép bạn đặc tả một vài thuộc tính của yêu cầu Trường Short Description sẽ được hiện thị trên biểu đò Nhìn thấy các thuộc tính External Requirement ở dưới cho nhiều thông tin hơn Kích nút ok để hoàn thành Một vài thuộc tính có thể được Edit Hình 1 : Create Project Hình 2: Chọn Model Requirements Function Requirements and Non-Function Requirements Hình 3: Requirement Model Thêm một Function Requirement là Manage Category Hình 4: Create Manage Category Hình 5: Thêm yêu cầu “Thêm Thể Loại” Hoặc có thể tạo trong Package Tạo Package Chọn Add -> New Requirement Lựa chọn các thông tin khác -> OK Thuộc tính của yêu cầu ngoài Hình 7: Một số thuộc tích của Yêu cầu thiết lập trang thái của yêu cầu Tạo các yêu cầu bên trong từ một thành phần khác (Internal Requirement) Ta có thể tạo ra các yêu cầu phần mềm bên trong 1 Element khác như Usecase, Class,… để chỉ ra rằng Element đó có nhiệm vụ cài đặt các yêu cầu đã nêu. Để thực hiện việc này, ta thực hiện như sau: Mở hộp thoại Properties của Element. Chọn Tab Require Nhập tên Requirement và các thuộc tính của nó. Bấm Save để lưu Requirement lại Nếu muốn, bấm New để tạo tiếp Internal Requirement khác cho Element, cũng hoặc thực hiện các thao tác quản lý khác ( sắp xếp, sửa, xóa ) Bấm OK để đóng hộp thoại Chuyển các Internal Requirement thành External Requirement Mở hộp thoại Properties của Element. Chọn Tab Require Chọn Requirement cần chuyển. Bấm Move External Trong hộp thoại mở ra, chọn package để lưu External Requirement Quản lý các thuộc tính cơ bản của yêu cầu Các thuộc tính cơ bản của yêu cầu được quản lý trong EA: Tên Trạng thái thực hiện (đề xuất, đã phê chuẩn, đang cài đặt, bắt buộc, đã kiểm tra) Độ khó Độ ưu tiên Loại yêu cầu ( Chức năng, hiển thị, báo cáo, kiểm thử , …) Ghi chú Các thông tin khác Ghi chú các thông tin bổ sung Sử dụng thuộc tính Note Sử dụng đối tượng chú thích Note Sử dụng Tagged Values (lựa chọn, mở cửa sổ Tagged Values, tạo ra các cặp Key – Value lưu trữ các thông tin bổ sung cho yêu cầu ) Hình 8: thêm các thuộc tính ngoài Hình 9: Thêm Tagged Value Xóa , Sắp xếp các yêu cầu Thực hiện trong cửa sổ Project Browser, thông qua các button trên toolbox hoặc menu ngữ cảnh. Tạo cấu trúc phân cấp cho yêu cầu Khi muốn chuyển 1 Requirement thành con của 1 Requirement khác, trong cửa sổ Project Browser, ta rê rồi thả Requirement-con vào Requirement-cha.Với chức năng này, ta có thể xây dựng được cấu trúc phân cấp cho Requirement: 1 requirement lớn có thể bao gồm nhiều Reqiurement nhỏ hơn. Đánh số cho các Requirement Nháy phải vào package, chọn Show Level Numbering Khi chưa đanh số Đánh số Sau khi đánh số Kết xuất thành văn bản Lựa chọn Requirement cần kết xuất Vào menu, chọn Project | Documentation Lựa chọn loại báo cáo phù hợp ( Rich Text Format, HTML,…) Trong hộp thoại mở ra, nhập các thông số cần thiết. Chú ý chọn Use template là requirement template Phần 4: Các thuật ngữ và các chữ viết tắt STT Tên Viết Tắt Ý Nghĩa 1 SRS Software Requirement Specification 2 NSD Người Sử Dụng 3 IEEE Institute of Electrical and Electronics Engineers 4 HTML HyperText Markup Language 5 EA Enterprise Architect 6 GUI Graphic User Interface