MÔN REQUIREMENT ENGINEERING Tìm hiểu các kĩ thuật phân tích yêu cầu phần mềm

23 832 3
MÔN REQUIREMENT ENGINEERING Tìm hiểu các kĩ thuật phân tích yêu cầu phần mềm

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ──────── * ─────── BÀI TẬP LỚN MÔN REQUIREMENT ENGINEERING Bài tập Tuần NO Tìm hiểu kĩ thuật phân tích yêu cầu phần mềm Nhóm : Giảng viên hướng dẫn : PGS.TS Huỳnh Quyết Thắng Hà Nội, tháng 02 năm 2012 Contents Câu1: Tổng hợp, đánh giá so sánh kỹ thuật phát yêu cầu phần mềm: - Interview - Workshop - Brainstorming - Storyboarding - Prototyping Về mục đích, khả áp dụng, quy trình thực mẫu văn kèm theo cho kỹ thuật InterViewing (Phỏng vấn): Interviewing việc tập hợp số lương người – thường với hai người – cho thời gian cố đinh Mục đích Interview thu nhận từ khách hàng thao tác vấn đề hệ thống hành, sách, nhu cầu mong muốn hệ thống Cuối vấn ta cho nội dung mô tả công việc người khách hàng làm dựa câu hỏi ta có Khả áp dụng: Phỏng vấn thường diễn trước trình thiết kế sử dụng hầu hết dự án Đặc điểm: - Phỏng vấn kĩ thuật đơn giản thu thông tin cách trực tiếp - Các câu hỏi phạm vi tự giúp mục đích vấn - Có thể thích hợp để tìm mảng yêu cầu chưa phát cách thăm dò tình - Một số nhu cầu thông thường khởi đầu “kho chứa yêu cầu” sử dụng suốt dự án - Một câu hỏi thăm dò ý kiến thay cho buổi vấn Các câu hỏi phạm vi tự (Context free question): Làm để tránh định kiến người sử dụng đáp ứng yêu cầu câu hỏi ? Chúng ta dùng câu hỏi vấn đề tự nhiên người sử dụng, câu hỏi chung chất dự án môi trường mà sản phẩm dùng: - Ai người sử dụng? - Ai khách hàng? - Họ có cần thay đổi? - Có thể tìm giải pháp cho vấn đề đâu? Quy trình tiến hành vấn  Tiến hành đặt hẹn phù hợp với thời gian vấn  Chuẩn bị tốt, tìm hiểu kỹ người vấn  Đúng  Có kế hoạch cho vấn - Giới thiệu thân mục đích Sử dụng câu hỏi mở để bắt đầu Luôn ý vào trả lời Có kế hoạch cho nội dung Kết hợp câu hỏi đóng mở Luôn bám sát trình bày phát triển chi tiết Luôn cung cấp thông tin phản hồi, ví dụ: “Cho phép trình bày lại điều ông vừa nói…” Hạn chế ghi chép không thấy tiện Có kế hoạch kết thúc Tóm tắt nội dung, yêu cầu hiệu chỉnh Yêu cầu làm xác, đánh giá lại ghi chép Cho biết ngày tháng họ nhận báo cáo Thống lại ngày lấy lại hiệu chỉnh Xác nhận lại lịch làm việc Những điểm lưu ý tiến hành vấn: - Chuẩn bị trước nội dung cần vấn Xem lại câu hỏi trước tiến hành vấn - Trước thực vấn, nghiên cứu kinh nghiệm nhà đầu tư công ty vấn Đừng đẩy cho người vấn câu hỏi mà bạn có câu trả lời - Ghi lại câu trả lời trình vấn (không có gắng lấy thông tin lúc này) - Tham khảo mẫu (template) trình vấn để đảm bảo đặt câu hỏi đắn Nội dung vấn mẫu văn kèm theo: Part I: Thiết lập tiểu sử người dùng hay khách hàng Name: Company: Industry: Job title: (The above information can typically be entered in advance.) What are your key responsibilities? What outputs you produce? For whom? How is success measured? Which problems interfere with your success? What, if any, trends make your jo easier or more difficult? Part II: Đi vào vấn đề For which [application type] problems you lack good solutions? What are they? (hint: keep asking, “Anything else?”) For each problem, ask the following questions: - Why does this problem exist? - How you solve it now? How would you like to solve it? Part III: Tìm hiểu môi trường người dùng Who are the users? What is their educational background? What is their computer background? Are users experienced with this type of application? Which platforms are in use? What are your plans for future platforms? Are additional applications in use that are relevant to this application? If so, let’s talk about them a bit What are your expectations for training time? What kinds of user help (for example, hard copy and online documentation) you need? Part IV: Tóm tắt lại thu You have told me: (List customer – descrbd problems in your own words.) Does this adequately represent the problems you are having with existing solution? What, if any, other problems are you expretiencing? Part V: Phân tích đầu vào vấn đề khách hàng: (Validate or invalidate assumptions.) (If not yet addressed) Which, if any, problems are associated with: (List any needs or additional problems you think should concern the customeror user.) For each suggested problem, ask the following question - Is this a real problem? - What are the reasons for this problem? - How you currently solve the problem? - How would you like to solve the problem? - How would you rank solving these problems in comparison to others you’ve mentioned? Part VI: Đi vào giải pháp (nếu thích hợp): (Summarize the key capabilities of your proposed solution.) What if you could: How would you rank the importance of these? Part VII: Đi vào hội Who in your organization needs this application? How many of these types of users would use the application? How would you value a successful solution? Part VIII: Đi vào đáng tin cậy, hiệu nhu cầu hỗ trợ What are your expectations for reliability? What are your expectations for performance? Will you support the product, or will others support it? Do you have special needs for support? What about maintenance and service access? What are the instaliation and configuration requirements? Are there special licensing requirements? How will the software be distributed? Are there labeling and packaging requirements? Part IX: Các yêu cầu khác Are there any legal, regulatory, or enviromental requirements or other standards that must be supported? Can you think of any other requirements we should know about? Part X: Bao quát lại Are there any other questions I should be asking you? If I need to ask follow-up questions, may I give you a call? Would you be willing to participate in a requirements review? Part XI: Tổng kết phân tích After the interview, and while the data is still fresh in your mind, summarize the three highestpriority needs or problems identified by this user/ custormer    Requirements Workshops (Họp nhóm): Họp nhóm việc tập hợp ba nhiều số người cho thời hạn định để thảo luân số chủ đề Họp nhóm vừa bổ sung thay vấn (Interviewing) Nó bổ sung cho vấn cách cho phép nhóm kiểm tra lại kết vấn cá nhân, cung cấp diễn đàn cho người sử dụng tìm đòi hỏi giải pháp cho ứng dụng Họp nhóm làm lãng phí thời gian Nói chung, họp nhóm lớn ý kiến trí thời gian định kéo dài Do vậy, nên có kế hoạch ban đầu cho họp nhóm Lich trình nên cung cấp trước cho thành viên Số lượng chủ đề nên giữ mức độ đến không mởi người không thích hợp để tránh lãng phí thời gian Họp nhóm nên có thời gian cố định có điểm thống cụ thể với định cần thiết Mục đích: - Gợi ý, phát tổ chức yêu cầu - Khuyến khích đồng thuận yêu cầu phần mềm nhà đầu tư thời gian ngắn, thường họp nhóm không kéo dài ngày (48 giờ) Đặc điểm: - Có lẽ kĩ thuật hiệu việc phát yêu cầu phần mềm - Tập hợp nhà đầu tư thời gian ngắn lại thu hút tập trung mạnh mẽ - Việc sử dụng người dẫn dắt chương trình bên có kinh nghiệm quản lí yêu cầu bảo đảm thành công cho buổi meeting - Brainstorming (Thảo luận, góp ý) phần quan Hội thảo Ký thuật thật thích hợp thiết lập hội thảo Nó khuyến khích tính sáng tạo bầu không khí tích cực từ tất bên liên quan Quy trình thực hiện:  Quảng bá nội dung, đảm bảo bên liên quan tham dự Chuẩn bị hậu cần tốt Khởi động vật chất (warm-up materials): gửi materials trước hội thảo để chuẩn bị tham dự để tăng hiệu hội thảo Có loại warm-up materials: thông tin cụ thể dự án Trong bao gồm phác thảo tài liệu yêu cầu, liệt kê tính đề nghị, vấn với người dùng tiềm năng, báo cáo phân tích xu hướng, thư từ, khách hàng, báo cáo lỗi hệ thống hành, thị quản lý mới, liệu marketing mới…  Chuẩn bị vai trò cho facililator (người dẫn chương trình hay chủ tọa)  Lên lịch trình cho Hội thảo  Tiến hành hội thảo Đẩy nhanh công việc Hỏi tất người xem vấn đề vừa đưa có đặc điểm cần bổ sung không trước đưa vấn đề Các yêu cầu hội thảo có nhiều điểm phải phù hợp: - Nó phải giúp đỡ xây dựng đội hiệu quả, tần tậm cho mục đích chung: thành công dự án - Tất người phát biểu - Phải tiến tới đồng thuận nhà đầu tư đội ngũ phát triển hệ thống phải làm - Trình bày, giải vấn đề gây trở ngại cho thành công dự án - Đưa định nghĩa sơ hệ thống Chuẩn bị cho hội thảo - Đưa khái niệm - Đảm bảo đóng góp người - Hậu cần - Làm nóng bầu không khí - Chọn facililator: + Đó người bên có kinh nghiệm xử lý quản lý yêu cầu thành viên nhóm đạt thành tựu định + Chứng minh kỹ xây dựng đồng lòng hay xây dựng nhóm vững + Là người thành viên nhóm nhóm tôn trọng + Có đủ vững vàng đối mặt với thách thức hội thảo Trách nhiệm facililator: • Thiết lập gặp mặt • Bắt đầu kết thúc thời gian • Thiết lập đảm bảo quy tắc họp • Giới thiệu mục đích lịch công tác họp • Quản lý họp giữ đội ngũ hướng • Sự thuận tiện trình định đồng lòng, tránh nội dung khác biệt • Đảm bảo lịch công tác hướng • Tất khác biệt nhà đầu tư phải lắng nghe • Kiểm soát hành vi gây đổ vỡ không mang lại giá trị Lên lịch trình cho Workshop Đảm bảo tất thành viên liên quan đến dự án phải nhận lịch họp Cố gắng xếp cho người Time 8:00 – 8:30 8:30 – 10:00 Agenda Introduction Context 10:00 – 12:00 12:00 – 1:00 Brainstorming Lunch 1:00 – 2:00 2:00 – 3:00 Brainstorming Feature definition 3:00 – 4:00 4:00 – 5:00 Idea reduction and priorization Wrap-up Description Review agenda, facilities, and rules Present project status, market needs, results of user interviews, and so on Brainstorm features of the application Work through lunch to avoid loss of momentum Continue branistorming Write out two – or three sentence definitions for features Prioritize features Summarize and assign action items, addresss “parking lot” items Figure 1: Mẫu chương trình hội thảo Đánh giá  Ưu điểm Workshop: • Có thể tạo định • Nhận thông tin tổng hợp chi tiết • Phương pháp tốt cho yêu cầu bên • Tập hợp nhiều người dùng liên quan…  Nhược điểm Workshop: • • • • • Nếu số đại biểu nhiều tốn thời gian cho việc định Tốn thời gian Các ngắt quãng làm phân tán ý Mời không dúng thành viên dẫn tới chậm có kết Dễ chuyển sang chủ đề không liên quan trị, thể thao… Brainstorming (Thảo luận) Mục đích: đưa nhiều ý tưởng tốt, mục đích bề rộng, chưa cần có chiều sâu Đặc điểm: - Brainstorming gồm có pha: Nêu ý tưởng thâu tóm lại ý tưởng: phân tích ý tưởng đưa ra, chọn lọc, tổ chức, đánh giá, mở rộng theo chiều sâu, tinh chỉnh chúng lại thành ý tưởng thích hợp - Ý tưởng sáng tạo thường kết hợp nhiều ý tưởng không liên quan lại với - Các kỹ thuật bỏ phiếu khác sử dụng để ưu tiên tạo ý tưởng - Mặc dù Brainstorming ưa chuộng, web-base Brainstorming thay khả thi vài trường hợp Kỹ thuật Brainstorming có lợi ích sau: - Khuyến khích thành viên tham gia Cho phép thành viên tranh luận với ý kiến đề xuất Người điều phối thư ký trì hội thảo không bị gián đoạn Diễn nhanh chóng Đưa giải pháp khả thi cho vấn đề Khuyến khích ý tưởng, suy nghĩ sáng tạo, độc đáo Người điều phối đưa quy đinh Thảo luận - Không phép tranh cãi, phê bình gay gắt: người tham gia phải từ bỏ ý kiến phê bình suốt trình tìm phát triển ý tưởng nhóm - Tự sáng tạo, tưởng tượng: ý tưởng đưa bầu không thoải mái, cởi mở Đồng thời ngừoi đề xuất ý tưởng không bị hạn chế nội dung chững minh tính chất đắn thực ý tưởng Có nhiều ý tưởng ban đầu ngớ ngẩn, khác thường thực lại đem lại kết vượt mong đợi - Đưa nhiều ý tưởng tốt: có nhiều ý tưởng có nhiều khả tìm giải pháp hữu ích - Nghiên cứu tổng hợp lại ý tưởng hay Thêm facililator phải giải thích mục tiêu cần đạt giai đoạn thảo luận Mặc dù mục tiêu rõ ràng thực tế Ngoài mục tiêu quy định ảnh hưởng tới kết buổi họp Ví dụ câu hỏi sau cách để nêu bật mục tiêu: - Tính muốn có sản phẩm? - Hệ thống nên cung cấp dịch vụ gì? - Những hội bỏ lỡ thị trường? Trong áp dụng Brainstorming tất ý tưởng xuất đầu thành viên nhóm viết hay vẽ ra, thông thường bút chì giấy trắng Người ta viết thử có đầu mặt giấy (brain dumping), không cần phải suy nghĩ ý tưởng tốt suy nghĩ thoảng qua đầu Người ta chẳng cần bận tâm đến thẩm mỹ việc trình bày Nếu cần diễn tả hình ảnh, phác học thật nhanh chóng Khi phát viết sai chẳng cần quay lại để sửa chữa, mà để suy nghĩ liên tục Phân tích kết quả: Sau kết thúc, lượt lại tất bắt đầu đánh giá câu trả lời: - Tìm ý trùng lặp hay tương tự để thu gọn lại Gộp câu trả lời có tương tự hay tương đồng nguyên tắc, nguyên lí Xóa bỏ ý kiến hoàn toàn không thích hợp Sau cô lập danh sách ý kiến, bàn thêm câu trả lời chung Đánh giá: - Brainstorming giúp tổng hợp nhiều ý tưởng từ thành viên - Phân tích kỹ vấn đề, tự xem xét tất vấn đề xảy ta liên tục đặt câu hỏi Số lượng người tham gia nhiều giúp cho phương pháp tìm lời giải nhanh hay toàn diện nhờ vào nhiều góc nhìn khác trình độ, trình tự khác người Ứng dụng : Brainstorming sử dụng công việc phát triển sản phẩm; quảng cáo; giải quết vấn đề; trình quản trị; quản trị dự án; xây dựng nhóm; xây dựng kết hoạch kinh doạnh Storyboarding Đặc điểm: - Mục đích storyboarding phát sớm tác động “Yes, but…” - Kỹ thuật bị động, chủ động kết hợp yếu tố - Storyboards xác định người tham gia, giải thích chuyện xảy với họ Tiến hàn storyboard dễ dàng thường xuyên dự án với phát triển nội dung Các loại StoryBoards: • StoryBoards dạng bị động (Passive storyboards): kể câu chuyện người sử dụng Có thể bao gồm phác thảo, tranh, ảnh chụp, hay trang thuyết trình dùng PowerPoint mẫu đầu thử nghiệm • StoryBoards dạng chủ động (Active storyboard): hoạt cảnh tự động, slide trình chiếu xếp tự động sẵn công cụ tạo hoạt cảnh hay chí phim • StoryBoards tương tác (Interactive storyboards: người dùng trải nghiệm hệ thống cách giống với thực tế Cách đòi hỏi tham gia người sử dụng để thực Storyboards tương tác giả lập tạo dựng mô hình hay nâng cao tới mức mã dùng lần (throwaway code) Figure 3: Storyboarding continuum StoryBoards làm (khả áp dụng)? Trong phần mềm, Storyboards sử dụng thường xuyên để làm việc thông qua chi tiết giao diện tương tác người máy Trong lĩnh vực này, người có ý kiến khác cách thức giao diện làm việc Storyboards cho hệ thống người dùng xử lý với yếu tố hoạt động: • • • Người tham gia ai? Điều xảy với họ? Nó xảy nào? Những ý : • Không nên đầu tư nhiều vào Storyboarding • Storyboard nên dễ chỉnh sữa • Không nên làm chi tiết, điều gây khó khăn sử dụng kỹ thuật công cụ khác cài đặt sau • Cố gắng làm cho storyboard liên hệ với nhau, tương tác với 5 Prototyping: Là kỹ thuật xác định yêu cầu cách đưa mẫu thử Người phát triển dựa vào yêu cầu khảo sát để đưa sản phẩm phác thảo ban đầu công nghệ khác với công nghệ sử dụng Sau có trao đổi với người sử dụng, từ tìm yêu cầu cách cụ thể, rõ ràng hơn, đặc biệt yêu cầu có tính “mở” Việc tạo mẫu thử sử dụng nhiều lần nhiều phần giai đoạn khác Các mẫu thử tạo có khả tái sử dụng, mẫu thử sau phát triển liên tiếp mẫu thử trước Với mục đích phân tích yêu cầu phần mềm ta xem mẫu thử yêu cầu phần mềm thực thi riêng lẻ hệ thống, nhằm mục đích giúp đỡ người phát triển, người sử dụng khách hàng hiểu cặn kẽ yêu cầu hệ thống Để xây dựng mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người phát triển phải khảo sát yêu cầu hệ thống, tiến hành trao đổi đàm phán vói khách hàng Lựa chọn công cụ thích hợp cho việc phát triển mẫu thử Dựa vào yêu cầu khảo sát tạo mẫu trao đổi với người sử dụng, với khách hàng, để phát cụ thể yêu cầu đặc biệt, yeu cầu có tính “mở” Tiến hành phát triển theo mẫu thử phê duyệt, sau bước tiếp tục tạo mẫu thử sử dụng mẫu thử có từ trước Đặc điểm: • Cực kỳ hiệu việc xác định hội chứng “Yes, but” (không chắn, không bền, không đảm bảo tình lâu dài…) “những thất bại chưa phát hiện” (rủi ro tiềm tàng) • Một tạo mẫu yêu cầu phần mềm phần thực thi phần mềm hệ thống, xây dựng để giúp cho người phát triển, người sử dụng, khách hàng hiểu tốt yêu cầu hệ thống • Thực làm mẫu yêu càu “mờ”, chưa rõ ràng: nhờ đó, điều biết “ẩn ý” chưa định nghĩa hiểu chưa rõ ràng Các mẫu phần mềm thân sớm hệ thống phần mềm, cho phần chức hệ thống Mẫu thử cho phép người dùng chạm, cảm nhận tương tác với hệ thống mẫu theo cách mà không công nghệ khác làm Các kiểu mẫu thử: Các mẫu thử 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 mà xây dựng mẫu thử khác nhau: • Architectural prototype (mẫu thử hướng kiến trúc) – cho thấy khả thực thi công nghệ • Throwaway prototype (mẫu thử dùng lần ) – sử dụng công nghệ, mô phỏng… hay để hoàn thiện kết bạn Mẫu dùng cho mục đích, sau hoàn thành, mẫu bỏ Nếu điểm yếu dự án giao diện người dùng, ngược lại bạn phát triển mẫu thử yêu cầu (requirements prototype), sử dụng công nghệ cho phép bạn làm mẫu giao diện nhanh Figure Decision tree for prototype selection: (a) Requirements prototypes (b) Arichitectural 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) thi hành cục (riêng lẻ) hệ thống phần mềm, xây dựng để giúp nhà phát triển (developers), người dùng (user) khách hàng (customer) hiểu tốt yêu cầu hệ thống Vì mcụ đích phát yêu cầu phần mềm, thường chọn cách xây dựng mẫu thử “throwaway, horizontal (rộng), user interface” prototype (mẫu thử dùng lần, mẫu thử rộng, mẫu thử người dùng) Horizontal prototypes (các mẫu thử rộng) ám thử xây dựng dải rộng chức hệ thống, ngược lại, vertical prototype xây dựng vài yêu cầu theo số phương pháp chất lượng User interface prototype ngụ ý chúng xây dựng hầu hết giao diện hệ thống để người dùng thi hành giải thuật logic xung quanh phần mềm làm mẫu thử giao diệncho hệ thống khác, thiết bị khác Khi công cụ khai thác, mẫu thử giữ vai trò theo vài cách khác nhau: • • • Được xây dựng người phát triển, chứa xác nhận khách hàng người dùng hiểu yêu cầu Được làm người phát triển, dùng xúc tác khuyến khích khách hàng nghĩ thêm yêu cầu khác Được làm khách hàng, giúp trao đổi thông tin với nhà phát triển Trong trường hợp, kết xây dựng mẫu theo phương pháp tiêu tốn tài nguyên Nếu đắt để xây dựng, có hiệu á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 đươc sử dụng sử dụng chủ yếu để nắm diện mạo giao diện hệ thống cần xây dựng Có hai lý cho việc này: • • • Có nhiều công cụ, có chi phí không đắt miễn phí hỗ trợ việc xây dựng giao diện nhanh Với hệ thống có tương tác người dùng nhiều, giao diện người dùng đươc làm mẫu khám phá nhiều yêu cầu khác, chức cung cấp tới cho người dùng, chức sẵn sàng cho người sử dụng chức chưa xuất với người dùng Tuy nhiên, cần chắn tính khả dụng công cụ không làm ảnh hưởng tới việc xây dựng mẫu thư cho phần hệ thống rủi ro cao bắt đầu Figure Contimuum of understading user needs (Well – understood requirements) hiểu rõ yêu cầu có hiển nhiên nhận thấy từ ngữ cảnh miền ứng dụng kinh nghiệm người dùng kinh nghiệm đội với hệ thống kiểu (Unknown requirements) Những yêu cầu chưa biết, rủi ro chưa phát (“Undiscovered Ruins”) mà thường mong biết đến sau Nhưng không may thay, làm mẫy này, có thể, chúng không chưa biết tới (unknown) Chính việc đặt vị trí cho việc làm mẫu thử phần “mờ” (fuzzy part) Những yêu cầu (Fuzzy) biết tới ngầm hiểu chúng thường định nghĩa nghèo nàn tiếp thu thông tin Xây dựng mẫu thử Sự lựa chọn công nghệ sử dụng xây dựng mẫu thử phụ thuộc vào định tương lai (ở phía bên phải định) Đánh giá kết (Evaluating the results): • Tính “mờ” cần hiểu rõ ràng • Thử nghiệm mẫu chắn khám phá đáp ứng “Yes, but…” từ phía người dùng, đó, nhu cầu trước chưa biết “lộ ra” (become known) Đơn giản nhìn tập hành vi giúp người dùng hiểu yêu cầu khác phải đảm đương hệ thống Trong trường hợp nào, Prototyping luôn đưa kết Do đó, bạn nên làm mẫu ứng dụng Đánh giá  Ưu điểm Prototyping: - Giảm thời gian phát triển - Giảm chi phí phát triển - Đòi hỏi tham gia người sử dụng - Nhà phát triển nhận phản hồi người dùng - Tạo điều kiện thực hệ thống người dùng biết cần có - Kết đem lại hài lòng cho người dùng - Nâng cao hệ thống tương lai  - Nhược điểm Prototyping Chỉ phân tích không đủ Người dụng mong chờ hiệu suất hệ thống giống nguyên mẫu Nhà phát triển trở nên gắn bó với nguyên mẫu họ Đôi tài liệu hướng dẫn không đầy đủ Nếu mẫu thử nghiệm tinh vi, lợi ích tiết kiệm thời gian bị So sánh kỹ thuật phát yêu cầu phần mềm: Đối tượng tham gia Nội dung chuẩn bị Interview Khách hàng, ngừoi vấn Câu hỏi Workshop Các bên liên quan Tài liệu họp Đánh giá phương pháp Trực tiếp, đơn Trực tiếp, giản chuẩn bị công phu Loại yêu cầu Tất Tất Brainstorming Storyboarding Prototyping Các bên liên Ngừoi dùng, Người phát quan người phân triển, khách tích hàng Đánh giá ý Chuẩn bị hình Chuẩn bị mẫu tưởng ảnh, phác thử, beta thảo kết cuối Trực tiếp, Trực tiếp, số Trực tiếp, qua phần liệu hình ảnh mẫu thử tổ chức đưa phải hội thảo xác Tập trung vào Tất Tất yêu cầu Câu 2: Đánh giá tiêu chí phần mềm website trường đại học Việt Nam: - http://vnu.edu.vn/home/ (Đại học Quốc gia Hà Nội) http://neu.edu.vn/ (Đại học kinh tế Quốc dân) http://hut.edu.vn/web/vi/home (Đại học Bách Khoa Hà Nội) - Các thành phần user vào website trường đại học: cán giảng viên, sinh viên, cựu sinh viên, khách tham quan ( thí sinh có mong muốn thi vào trường, người muốn tìm hiểu trường để phục vụ cho công việc …) Các tiêu chí đánh giá chất lượng phần mềm: Theo tiêu chuẩn ISO 9126 có tiêu chí để đánh giá chất lượng phần mềm, là: - Tính ( Functionality): Là khả phần mềm cung cấp chức thỏa mãn yêu cầu xác định rõ ràng yêu cầu 'không rõ ràng' phần mềm sử dụng hoàn cảnh cụ thể Bao gồm tiêu chí nhỏ: o Tính phù hợp(Suitability) o Tính xác (Accuracy) o Khả tương tác (Interoparability) o Tính bảo mật/an toàn (Security) - Tính tin (Realbility): Là khả phần mềm trì mức hiệu định rõ sử dụng điều kiện cụ thể Bao gồm tiêu chí nhỏ: o Tính hoàn thiện (Maturity) o Khả chịu lỗi (Fault tolerant) o Khả phục hồi (Recoverability) - - - - Tính khả dụng (Usability): Là khả phần mềm để hiểu được, học hỏi được, sử dụng hấp dẫn người sử dụng: o Dễ hiểu (Understandbility) o Dễ học (Learnability) o Khả vận hành (Operability) o Tính hấp dẫn (Attreactiveness) Tính hiệu (Efficiency): Là khả phần mềm cung cấp hiệu thích hợp nhằm tiết kiệm tối đa tài nguyên tăng tối đa hiệu suất công việc, điều kiện sử dụng định: o Thời gian xử lí (Time behavior) o Sử dụng tài nguyên Khả bảo trì (Maintainability): Là khả phần mềm cho phép sửa đổi, nâng cấp, bao gồm sửa chữa, cải tiến thích nghi phần mềm thay đổi cho phù hợp với môi trường, yêu cầu chức mới: o Khả phân tích (Analysability) o Khả thay đổi (Changeability) o Tính ổn định (Stability) o Khả kiểm thử (Testability) Tính khả chuyển (Portability): Là khả phần mềm chuyển từ môi trường sang môi trường khác: o Khả thích nghi (Adaptability) o Khẳ cài đặt (Installability) o Khả chung sống (Co-existence) o Khả thay (Replaceability) So sánh chất lượng website trường đại học: BKHN (hut.edu.vn) QGHN (vnu.edu.vn) KTQD (neu.edu.vn) Tính năng: Tính phù hợp ( Suitability) (Functionality) Theo template website trường học ( tra cứu mục 3) website trường đại học đáp ứng đầy đủ chức cần thiết ( Viết thêm chức vào …) Tuy nhiên đánh giá cao website trường DHQG có mục giáo trình giảng dạy, thật cần thiết cho sinh viên Tính xác (Accuracy) - Thực chức năng, nhầm lẫn chức Khả tương tác (Interoperability) Không có, người sử Cũng BKHN Các sinh viên, cán dụng khả nhân viên liên hệ với trường có account admin hay gửi yêu đăng nhập vào Tính tin cậy (Realbility) Tính khả dụng: - Dễ hiểu - Dễ học - Dễ vận hành - Tính hấp dẫn Tính hiệu (Efficiency) Khả bảo trì (Maintainability) cầu, phản hồi, đóng website trường góp ý kiến website Website trường đại học không đặt nặng vấn đề tương tác với người sử dụng mà trọng vào việc cung cấp thông tin cho họ, nên việc thiếu sót chức không quan trọng Tính bảo mật / an toàn (Security) - Khó đánh giá - Tính hoàn thiện (maturity): - Khả chịu lỗi (fault tolerant): - Khả phục hồi( recoverability): - Đối với người sử dụng, khai thác thông tin website ( người quản lí website) việc sử dụng website dễ dàng, chức (thông tin) trình bày trực quan, rõ ràng, user nhanh chóng tìm thông tin mà yêu cầu => dễ hiểu, dễ học, dễ vận hành ( tìm thêm) - Tính hấp dẫn: hấp dẫn hiểu giao diện, chức năng, cách sử dụng … có lôi user, làm họ thích thú hay không ( nhà tìm thêm)  Nhìn chung website có bố cục mục thông tin giống nhau, giao diện dễ nhìn, không gây rối, dễ thao tác  Chức cách sử dụng tương tự Có thể thị nội dung website ngôn ngữ tiếng Việt tiếng Anh - Thời gian đáp ứng: website có thời gian đáp ứng lại thao tác người dùng nhanh Chưa kiểm thử với trường hợp số người truy cập đông - Sử dụng tài nguyên: dùng trình duyệt firefox để so sánh ( không thực khách quan) vào website, hệ thống sử dụng mức tài nguyên sau:  BKHN: ram ~ 100MB  QGHN: ram ~ 120MB  KTQD: ram ~ 140MB Mức chiếm dụng cpu không đáng kể Với cấu hình pc, laptop mức chiếm dụng tài nguyên chấp nhận - Khả phân tích, khả thay đổi được, khả kiểm thử được: vấn đề thuộc quyền quản trị website, user thông thường khó đánh giá Tính ổn định: nhận thấy website hoạt động ổn định, chưa gặp lỗi Tính khả chuyển (Portability) - Website hoạt động tốt trình duyệt phổ biến firefox, chrome, ie, opera, safari Template cho website trường học: Trang chủ - Giới thiệu Trường, lịch sử hình thành phát triển - Banner, logo, sologan Trường - Hiển thị hình ảnh tổng thể Website - Liệt kê tin tức mới, tin tức bật trang chủ Giới thiệu thông tin Trường, đơn vị đào tạo - Cơ sở vật chất (Máy móc thiết bị, thư viện, phòng học ) - Trình độ chuyên môn đội ngũ cán - Quy mô đào tạo Trường - Các chương trình nghiên cứu Khoa học trường - Giới thiệu khác Trang giới thiệu cán bộ, công nhân viên Trường (Ảnh thông tin cá nhân) - Hiển thị sơ đồ tổ chức nhân Trường(Hiệu trưởng, hiệu phó, phòng ban Trường ) - Thông tin chi tiết cán Trường - Thông tin liên hệ cán Trường - Các thông tin tuyển dụng cán bộ(nếu có) Trang thông tin tổ chức đoàn thể Trường (Tổ chức Đảng, Đoàn TN, Hội SV, thư viện, ký túc xá, câu lạc sinh viên ) - Hiển thị danh sách tổ chức đoàn thể Trường - Cho phép xem thông tin chi tiết tổ chức đoàn thể - Thông tin cán phụ trách đoàn thể Trường - Thông tin liên hệ tổ chức đoàn thể Trường - Các tổ chức sinh viên, cựu sinh viên Các nội quy, quy định Trường - Quy định điều kiện - vào Trường - Các quy định sử dụng tài liệu Trường - Các quy định điều kiện sử dụng tài liệu Trường - Các quy định cấp thẻ, sử dụng thẻ(nếu có) - Quy định thời gian làm việc, học tập - Các quy định điều kiện học bổng - du học Trường - Các thông tin, thông báo Giới thiệu hệ đào tạo Trường - Thông tin hệ đào tạo quy + Giới thiệu khóa học qua + Giới thiệu khóa học + Phương hướng, kế hoạch tới + Một số thông tin khác - Thông tin hệ đào tạo chức (nếu có) + Giới thiệu khóa học qua + Giới thiệu khóa học + Phương hướng, kế hoạch tới + Một số thông tin khác - Thông hệ đào tạo sau khác + Giới thiệu khóa học qua + Giới thiệu khóa học + Phương hướng, kế hoạch tới + Một số thông tin khác - Hệ đào tạo từ xa (nếu có) + Giới thiệu khóa học qua + Giới thiệu khóa học + Phương hướng, kế hoạch tới + Một số thông tin khác - Thông tin tiêu tuyển sinh hệ đào tạo - Những điều học sinh, sinh viên sẽ, học cần biết Trường Thông tin chuyên ngành đào tạo Trường - Liệt kê danh sách cho xem thông tin chi tiết ngành Trường - Kế hoạch đào tạo chương trình đào tạo chuyên ngành Trường - Điều kiện để theo học chuyên ngành khác - Chỉ tiêu tuyển sinh, đào tạo chuyên ngành Trường Giới thiệu môn Trường (Ảnh thông tin cá nhân) - Thông tin môn - Hiển thị sơ đồ tổ chức nhân môn(Trưởng môn, giáo viên hữu ) - Thông tin chi tiết cán môn(Giáo viên thức, trợ giảng ) - Thông tin liên hệ cán môn - Hướng dẫn tìm kiếm tài liệu tham khảo môn - Các thông tin tuyển dụng cán bộ(nếu có) Các chương trình nghiên cứu Khoa học Trường - Sinh viên nghiên cứu Khoa học Trường - Các chương trình hợp tác nước quốc tế nghiên cứu Khoa học - Công bố chương trình nghiên cứu Khoa học - Thông tin hội nghị, hội thảo Khoa học Trường - Thông tin chương trình nghiên cứu Khoa học Trường trường bạn cho sinh viên tham khảo, điều kiện để đăng ký tham gia sinh viên Trường phép đăng ký tham gia 10 Quản lý quy trình giảng dạy học tập Trường (Học trực tuyến) - Ngay trình giảng dạy bôn môn, giáo viên upload tài liệu liên quan đế môn lên trang web, sinh viên download tài liệu để tham khảo phục vụ cho việc học tập - Để upload file điểm sinh viên, giáo viên phải đăng nhập hệ thống, từ upload tài liệu điểm thi sinh viên - Giáo viên môn đưa thông tin điểm sinh viên lên website để sinh viên tự xem điểm thi môn tương ứng - Khi sinh viên trúng tuyển, nhà trường cấp mã sinh viên sau đó, sinh viên cấp acount với user name (thông thường dùng mã sinh viên) mật để truy cập hệ thống - Hệ thống cho phép sinh viên đăng nhập user mật để xem điểm theo môn học - Sau đăng nhập xong, sinh viên download tài liệu tham khảo môn liên quan giáo viên môn upload lên + Lưu ý: Mỗi giáo viên môn cập nhật tài liệu liên quan đến môn acount Mỗi sinh viên xem thông tin cá nhân mình(Thông tin thân: Họ tên, quê quán Thông tin điểm, thông tin khác – có), không xem thông tin cá nhân sinh viên khác 11 Thông tin chương trình hợp tác - Các chương trình hợp tác nước - Các chương trình hợp tác quốc tế - Giới thiệu chương trình hợp tác đào tạo thực - Giới thiệu chương trình hợp tác thực - Định hướng, kế hoạch hợp tác phát triển Trường bền vững, lâu dài - Các viết nhận xét, đánh giá chương trình hợp tác cụ thể 12 Các thành tựu đạt - Giới thiệu thành công đạt - Các khen, huân chương cho tập thể cá nhân - Một số thành tựu khác 13 Các hình ảnh hoạt động Trường - Hiển thị hình ảnh hoạt động Trường - Các hình ảnh hoạt động giao lưu với Trường khác, tổ chức khác trường - Hình ảnh chương trình giao lưu, trao đổi với đơn vị ngành - Các hình ảnh hoạt động giao lưu với tổ chức khác - Hình ảnh hoạt động tổ chức Trường(Đảng, Đoàn TN, Hội SV, SV tình nguyện ) - Hình ảnh chương trình hoạt động khác 14 Tìm kiếm - tra cứu - Cho phép tìm kiếm theo nhiều tiêu chí kết hợp - Tìm kiếm theo từ khóa để có kết liệt kê - Một số tiêu chí tìm kiếm khác 15 Quản lý tin tức - Tin hoạt động Trường - Tin chuyên ngành Trường - Tin tức nước - Tin tức quốc tế 16 Thông tin liên hệ - Hiển thị thông tin liên hệ Trường - Sơ đồ địa Trường 17 Sơ đồ Website - Hiển thị sơ đồ Website, cho phép người dùng vào nhanh mục cần xem 18 Liên kết website - Liên kết đến Website tổ chức, đoàn thể - Liên kết đến Website cấp - Liên kết đến Website Trường khác trường, trường khác - Liên kết đến Website tổ chức quốc tế có liên quan - Liên kết đên Website lĩnh vực Trường học - kỹ thuật - Liên kết đến Website tin tức, thời sự, kinh tế, văn hóa 19 Xây dựng trang quản trị tin tức tài liệu, ấn phẩm - Cho phép cập nhật thông tin tin tức - Cập nhật thông tin tài liệu, ấn phẩm thuộc tính liên quan [...]... người sử dụng, từ đó tìm ra các yêu cầu một cách cụ thể, rõ ràng hơn, đặc biệt là các yêu cầu có tính “mở” Việc tạo mẫu thử có thể được sử dụng nhiều lần ở nhiều phần và giai đoạn khác nhau Các mẫu thử được tạo ra có thể có khả năng tái sử dụng, các mẫu thử sau sẽ phát triển liên tiếp trên nền các mẫu thử trước Với mục đích phân tích yêu cầu phần mềm ta xem mẫu thử yêu cầu phần mềm như là sự thực thi riêng... hàng hiểu cặn kẽ hơn về yêu cầu của hệ thống Để xây dựng các mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người phát triển phải khảo sát các yêu cầu của hệ thống, tiến hành trao đổi đàm phán vói khách hàng Lựa chọn công cụ thích hợp cho việc phát triển mẫu thử Dựa vào các yêu cầu đã khảo sát tạo bản mẫu rồi trao đổi với người sử dụng, với khách hàng, để phát hiện cụ thể hơn các yêu cầu. .. trường, những người muốn tìm hiểu về trường để phục vụ cho công việc …) 7 Các tiêu chí đánh giá chất lượng của 1 phần mềm: Theo tiêu chuẩn ISO 9126 thì có 6 tiêu chí để đánh giá chất lượng của 1 phần mềm, đó là: - Tính năng ( Functionality): Là khả năng của phần mềm cung cấp các chức năng thỏa mãn các yêu cầu được xác định rõ ràng cũng như các yêu cầu 'không rõ ràng' khi phần mềm được sử dụng trong những... 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ể Figure 1 Decision tree for prototype selection: (a) Requirements prototypes (b) Arichitectural 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... thực thi của một phần mềm hệ thống, được xây dựng để giúp cho người phát triển, người sử 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 một phần chức năng của... mềm, được xây dựng để giúp các nhà phát triển (developers), người dùng (user) và khách hàng (customer) hiểu tốt hơn về yêu cầu của hệ thống Vì mcụ đí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, horizontal (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) Horizontal prototypes (các mẫu thử rộng) ám chỉ rằng... dụng các kỹ thuật hoặc công cụ khác nhau khi cài đặt sau này • Cố gắng làm cho storyboard liên hệ với nhau, tương tác được với nhau 5 Prototyping: Là kỹ thuật xác định yêu cầu bằng cách đưa ra các mẫu thử Người phát triển sẽ dựa vào các yêu cầu khảo sát để đưa ra một sản phẩm phác thảo ban đầu có thể bằng công nghệ khác với công nghệ sẽ được sử dụng Sau đó có sự trao đổi với người sử dụng, từ đó tìm. .. Giới thiệu các thành công đã đạt được - Các bằng khen, huân chương cho các tập thể và cá nhân - Một số thành tựu khác 13 Các hình ảnh hoạt động của Trường - Hiển thị các hình ảnh hoạt động của Trường - Các hình ảnh hoạt động giao lưu với các Trường khác, các tổ chức khác trong trường - Hình ảnh các chương trình giao lưu, trao đổi với đơn vị cùng ngành - Các hình ảnh hoạt động giao lưu với các tổ chức... biệt, các yeu cầu có tính “mở” Tiến hành phát triển theo mẫu thử đã được phê duyệt, sau bước đó tiếp tục tạo các mẫu thử có thể sử dụng các mẫu thử đã có từ trước Đặc điểm: • Cực kỳ hiệu quả trong việc xác định các hội chứng “Yes, but” (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 tạo mẫu yêu cầu phần mềm là một phần thực... Đối với người sử dụng, khai thác các thông tin website ( không phải người quản lí website) thì việc sử dụng website là khá dễ dàng, các chức năng (thông tin) được trình bày trực quan, rõ ràng, user có thể nhanh chóng tìm ra các thông tin mà mình yêu cầu => dễ hiểu, dễ học, dễ vận hành ( về tìm thêm) - Tính hấp dẫn: hấp dẫn ở đây có thể hiểu là giao diện, chức năng, cách sử dụng … có lôi cuốn user, ... - Một số tiêu chí tìm kiếm khác 15 Quản lý tin tức - Tin hoạt động Trường - Tin chuyên ngành Trường - Tin tức nước - Tin tức quốc tế 16 Thông tin liên hệ - Hiển thị thông tin liên hệ Trường -. .. Prototyping: - Giảm thời gian phát triển - Giảm chi phí phát triển - Đòi hỏi tham gia người sử dụng - Nhà phát triển nhận phản hồi người dùng - Tạo điều kiện thực hệ thống người dùng biết cần có - Kết... định Trường - Quy định điều kiện - vào Trường - Các quy định sử dụng tài liệu Trường - Các quy định điều kiện sử dụng tài liệu Trường - Các quy định cấp thẻ, sử dụng thẻ(nếu có) - Quy định thời

Ngày đăng: 20/01/2016, 17:29

Từ khóa liên quan

Mục lục

  • Câu1: Tổng hợp, đánh giá và so sánh các kỹ thuật phát hiện yêu cầu phần mềm:

  • 1. InterViewing (Phỏng vấn):

  • 2. Requirements Workshops (Họp nhóm):

  • 3. Brainstorming (Thảo luận)

  • 4. Storyboarding

  • 5. Prototyping:

  • 6. So sánh các kỹ thuật phát hiện yêu cầu phần mềm:

  • Câu 2: Đánh giá các tiêu chí phần mềm của 3 website của các trường đại học Việt Nam:

  • 7. Các tiêu chí đánh giá chất lượng của 1 phần mềm:

  • 8. So sánh chất lượng của website 3 trường đại học:

  • 9. Template cho website trường học:

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

Tài liệu liên quan