Đang tải... (xem toàn văn)
Bài tập lớn về môn:Nhập Môn Công Nghệ Phần MềmChương 2Phân Tích:Đại Học Công Nghiệp Hà NộiTài liệu đã được dịch từ tài liệu tiếng anh.Trong tài liệu đã bao gồm các phần đầy đủ chi tiết được dịch ra.Có thêm câu hỏi trắc nghiệm cuối chương
TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI KHOA CÔNG NGHỆ THÔNG TIN BỘ MÔN CÔNG NGHỆ PHẦN MỀM Môn học: Nhập môn công nghệ phần mềm BÁO CÁO CHUYÊN ĐỀ NHÓM SỐ Tên chuyên đề: Chương 2:Phân Tích Điểm: …… Giảng viên hướng dẫn: TS Trần Tiến Dũng Những người thực chuyên đề: (Họ tên chữ ký) TT Họ tên Đơn vị Lê Công Phòng ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội Đinh Hồ Khoa ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội Đặng Văn Nam ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội Phùng Minh Tú ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội Ngô Văn Quyền ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội Chữ ký Hà Nội – 2016 MỤC LỤC LỜI NÓI ĐẦU 1.Mục đích tài liệu ● Giới thiệu môn học công nghệ phần mềm ● Hướng dẫn cách thức phân tích yêu cầu người dùng phương pháp mô hình hóa ● Hướng dẫn cách thức thiết kế phần mềm phương pháp mô hình hóa ● Hướng dẫn phương thức kiểm chứng hệ thống phần mềm ● Hướng dẫn phương thức thẩm định hệ thống phần mềm ● Hướng dẫn cách xây dựng kiểm soát kế hoạch dự án phần mềm 2.Mô tả tài liệu Chương II – Phân tích Trình bày cách thức phân tích yêu cầu người dùng phương pháp mô hình hóa UML 3.Nội Dung Phân Tích 3.1.Các nguyên tắc cốt lõi 3.1.1Hướng dẫn trình Nguyên tắc Hãy nhanh nhẹn cho dù mô hình quy trình mà bạn chọn kịp thời theo toa nhanh nhẹn, nguyên lý phát triển nhanh phối cách tiếp cận bạn Mọi khía cạnh công việc bạn làm nên nhấn mạnh kinh tế hành động giữ cách tiếp cận kỹ thuật bạn đơn giản tốt, giữ cho sản phẩm công việc bạn sản xuất ngắn gọn tốt, đưa định địa phương ❖ Nguyên tắc Tập trung vào chất lượng cho bước Các điều kiện xuất cảnh cho tiến trình hoạt động, hành động nhiệm vụ cần tập trung vào chất lượng sản phẩm công việc mà sản xuất ❖ Nguyên tắc Hãy sẵn sàng để thích nghi Quy trình kinh nghiệm tôn giáo giáo điều chỗ Khi cần thiết, điều chỉnh cách Trang / 19 ❖ ❖ ❖ ❖ ❖ tiếp cận bạn để hạn chế áp đặt vấn đề nhân dân, dự án riêng Nguyên tắc Xây dựng đội ngũ hiệu Phần mềm quy trình kỹ thuật thực hành quan trọng, điểm mấu chốt người Xây dựng đội ngũ tổ chức tự có tin tưởng lẫn tôn trọng Nguyên tắc Thiết lập chế thông tin liên lạc phối hợp Các dự án thất bại thông tin quan trọng rơi vào ngõ cụt bên liên quan không phối hợp nỗ lực họ để tạo UCT kết thúc thành công phẩm Đây vấn đề quản lý họ phải giải Nguyên tắc Quản lý thay đổi Cách tiếp cận gmail thức hay tin tức, chế phải thành lập để quản lý cách thay đổi yêu cầu, đánh giá, phê duyệt triển khai thực Nguyên tắc Đánh giá rủi ro Rất nhiều điều sai phần mềm phát triển Đó điều cần thiết mà bạn thiết lập kế hoạch dự phòng Nguyên tắc Tạo sản phẩm công việc cung cấp giá trị cho người khác Tạo sản phẩm công việc cung cấp giá trị cho hoạt động khác trình, hành động, nhiệm vụ Mỗi sản phẩm công việc mà sản xuất phần thực hành kỹ thuật phần mềm chuyển cho người khác Một danh sách chức tính cần thiết thông qua với người (người), người phát triển thiết kế, thiết kế thông qua với người tạo mã, Hãy chắn sản phẩm công việc truyền đạt thông tin cần thiết mà không mơ hồ thiếu sót 3.1.2.Hướng dẫn thực hành ❖ Nguyên tắc Chia chinh phục.Nói cách kỹ thuật, phân tích thiết kế nên luôn nhấn mạnh tách mối quan ngại vấn đề lớn dễ dàng để giải chia thành sưu tập phần tử (hoặc quan tâm) Lý tưởng nhất, mối quan tâm cung cấp chức riêng biệt mà phát triển, số trường hợp xác nhận cách độc lập mối quan tâm khác ❖ Nguyên tắc Hiểu trừu tượng Trong thực hành kỹ thuật phần mềm, bạn sử dụng nhiều cấp độ khác trừu tượng để truyền đạt ý nghĩa ,ngụ ý Trong phân tích thiết kế công việc, nhóm phần mềm thông thường bắt đầu với mô hình đại diện cho mức độ trừu tượng từ từ trau chuốt mô hình thành mức độ trừu tượng thấp Mục đích trừu tượng để loại bỏ cần thiết để giao tiếp thông tin chi tiết Nhưng đôi khi, hiệu ứng có vấn đề kết tủa chi tiết "rò rỉ" thông qua Nếu hiểu biết chi tiết, nguyên nhân vấn đề không dễ dàng chẩn đoán ❖ Nguyên tắc Phấn đấu cho quán Cho dù việc tạo mô hình yêu cầu, phát triển phần mềm thiết kế, tạo mã nguồn, tạo trường hợp Trang / 19 ❖ ❖ ❖ ❖ ❖ ❖ thử nghiệm, nguyên tắc quán cho thấy bối cảnh quen thuộc làm cho phần mềm dễ sử dụng hơn.Ví du như:thiết kế giao diện người dùng cho WebApp trí phù hợp menu tùy chọn, việc sử dụng bảng màu phù hợp, sử dụng phù hợp biểu tượng dễ nhận biết để tạo quán sản phẩm Nguyên tắc Tập trung vào việc chuyển giao thông tin Phần mềm giúp chuyển giao thông tin từ sở liệu để người dùng cuối, từ hệ thống di sản để WebApp, từ người dùng cuối vào giao diện đồ họa người dùng (GU), từ hệ điều hành cho ứng dụng, từ thành phần phần mềm để khác danh sách gần vô tận Trong trường hợp, có nhiều luồng thông tin giao diện, hệ quả, có lỗi, hay bỏ sót không xác Nguyên tắc Hãy tìm mô hình: Mục tiêu mô hình cộng đồng phần mềm tạo thể văn học để giúp nhà phát triển phần mềm giải vấn đề định kỳ gặp phải suốt tất mẫu phát triển phần mềm giúp tạo ngôn ngữ chung cho nhìn sâu sắc chương trình giải pháp họ Chính thức hệ thống hóa giải pháp mối quan hệ họ cho phép nắm bắt thành công thân thể kiến thức xác định hiểu biết kiến trúc tốt đáp ứng nhu cầu người sử dụng họ Nguyên tắc Khi có thể, đại diện cho vấn đề giải pháp từ số quan điểm khác Khi vấn đề giải pháp kiểm tra từ số quan điểm khác nhau, có nhiều khả nhìn sâu sắc hơn, lỗi thiếu sót phát Ví dụ, mô hình yêu cầu biểu diễn quan điểm đĩa liệu theo định hướng, quan điểm chức định hướng quan điểm hành vi.nó cung cấp nhìn khác vấn đề yêu cầu Nguyên tắc 7.Cần người trì phần mềm Về lâu dài, phần mềm sửa chữa ,những thiếu sót phát hiện, thích nghi môi trường thay đổi nó, tăng cường bên liên quan yêu cầu thêm khả Những hoạt động bảo trì thuận lợi thực hành kỹ thuật phần mềm rắn áp dụng suốt trình phần mềm 3.2.Các nguyên tắc hướng dẫn hoạt động khung 3.2.1.Kết nối giao tiếp Giao tiếp hiệu (vấn đề kỹ thuật, với khách hàng bên liên quan, với nhà quản lý dự án) hoạt động đầy thử thách bạn đối đầu Trong bối cảnh này, thảo luận nguyên tắc giao tiếp họ áp dụng cho giao tiếp khách hàng cần thiết Tuy nhiên, có nhiều nguyên tắc áp dụng chung cho tất hình thức truyền thông xảy dự án phần mềm là: Nguyên tắc 1: Nghe Cố gắng tập trung vào lời nói người nói, xây dựng câu trả lời bạn cho từ Yêu cầu làm rõ không rõ ràng, tránh bị gián đoạn liên tục Trang / 19 ❖ Nguyên tắc 2: Chuẩn bị trước bạn giao tiếp Hãy dành thời gian để hiểu vấn đề trước bạn gặp gỡ với người khác Nếu cần thiết, làm số nghiên cứu để hiểu thuật ngữ lĩnh vực kinh doanh.Bạn tiến hành họp chuẩn bị chương trình nghị trước họp ❖ Nguyên tắc 3: Cần có nhà lãnh đạo Mỗi buổi truyền thông cần có nhà lãnh đạo (một facilitator) để giữ cho trò chuyện theo hướng , làm trung gian xung đột xảy để đảm bảo so với nguyên tắc khác theo sau ❖ Nguyên tắc 4:Nói chuyện trực tiếp tốt Nó thường làm cho việc tốt số đại diện khác thông tin có liên quan giao tiếp cách trực quan Ví dụ, người tham gia tạo vẽ hay tài liệu phục vụ trọng tâm thảo luận ❖ Nguyên tắc 5: Ghi định tài liệu ❖ ❖ ❖ ❖ ❖ Một người tham gia vào giao tiếp nên làm công việc ghi âm viết tất điểm định quan trọng Nguyên tắc 6: Phấn đấu cho hợp tác Sự hợp tác đồng thuận xảy kiến thức tập thể thành viên nhóm sử dụng để mô tả chức sản phẩm hệ thống tính Mỗi hợp tác nhỏ phục vụ để xây dựng lòng tin thành viên nhóm tạo mục tiêu chung cho đội Nguyên tắc 7:Tập trung Sẽ có nhiều người tham gia vào việc thông tin liên lạc, nhiều khả thảo luận trả lại từ chủ đề Người điều hành nên giữ đàm thoại trả lại từ chủ đề Người điều hành nên giữ đàm thoại theo mô-đun đó, để lại chủ đề sau giải Nguyên tắc 8: Nếu không rõ ràng vẽ phác thảo Nếu giao tiếp lời nói đến mức Một phác thảo thường cung cấp rõ nét nói cách không thực công việc Nguyên tắc 9: Chuyển sang chủ đề khác cần thiết Giao tiếp hoạt động công nghệ phần mềm thời gian Thay lặp vô tận, người tham gia nên nhận nhiều chủ đề cần thảo luận chuyển sang chủ đề khác cách tốt để đạt nhanh chóng giao tiếp Nguyên tắc 10: Đàm phán thi hay trò chơi Nó hoạt động tốt hai bên có lợi Có nhiều trường hợp bạn bên liên quan phải thương lượng chức tính năng, ưu tiên, ngày giao hàng Nếu đội phối Trang / 19 ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ hợp tốt, tất bên có mục tiêu chung Vẫn đàm phán có nhu cầu thỏa hiệp từ tất bên 3.2.3.Mô hình hóa Trong phần mềm công việc kỹ thuật, hai lớp mô hình tạo là:các yêu cầu mẫu thiết kế.Một số nguyên tắc cần tuân thủ sau: Nguyên tắc Các mục tiêu nhóm phần mềm để xây dựng phần mềm, không tạo mô hình Nhanh nhẹn có nghĩa nhận phần mềm cho khách hàng thời gian nhanh Mô hình mà làm cho điều xảy giá trị tạo ra, mô hình mà làm chậm trình xuống cung cấp hiểu biết nên tránh Nguyên tắc đừng tạo thêm nhiều mẫu mô hình không cần thiết Mỗi mô hình tạo phải giữ đến thay đổi xảy ra.Quan trọng hơn, mô hình cần có thời gian, mà không chi tiêu vào xây dựng (mã hóa thử nghiệm) Vì vậy, tạo mô hình làm cho dễ dàng nhanh để xây dựng phần mềm Nguyên tắc Phấn đấu để sản xuất mô hình đơn giản để mô tả vấn đề phần mềm Mô hình đơn giản kết phần mềm đơn giản Nguyên tắc Xây dựng mô hình cách linh hoạt Giả sử mô hình bạn thay đổi, không làm cách cẩu thả Nguyên tắc Có thể nêu mục đích rõ ràng cho mô hình tạo Mỗi bạn tạo mô hình, tự hỏi bạn làm Nếu bạn cung cấp biện pháp vững cho tồn mô hình không dành nhiều thời gian vào Nguyên tắc Điều chỉnh mô hình bạn phát triển với hệ thống Nó cần thiết để thích nghi với ký hiệu mô hình hay quy tắc để áp dụng; Ví dụ, ứng dụng trò chơi video đòi hỏi kỹ thuật mô hình khác thời gian thực, nhúng phần mềm điều khiển động ô tô Nguyên tắc Cố gắng để xây dựng mô hình hữu ích, quên việc xây dựng mô hình hoàn hảo Khi xây dựng yêu cầu mô hình thiết kế, phần mềm kỹ sư cố gắng để hoàn hảo Đó là, nỗ lực cần thiết để làm cho mô hình hoàn toàn đầy đủ quán không đáng lợi ích đặc tính Nguyên tắc Đừng làm cách máy móc mô hình Mặc dù tất người nhóm phần mềm cố gắng sử dụng ký hiệu phù hợp mô hình, đặc tính quan trọng mô hình để Trang / 19 truyền đạt thông tin cho phép nhiệm vụ kỹ thuật phần mềm Nếu mô hình thực cú pháp thành công tốt,ngược lại không xác chấp nhận ❖ Nguyên tắc Nếu mô hình bạn không đúng, ổn giấy bạn có lý để lo ngại Một mô hình thiết kế phần mềm hoàn hảo,vẫn có nhiều lỗi xảy ra.Vì vậy,bạn có lý để dành thêm thời gian kiểm tra mô hình phát triển mô hình khác ❖ Nguyên tắc 10 Nhận thông tin phản hồi thời gian sớm Mỗi mô hình cần xem xét thành viên nhóm phần mềm Mục đích ý kiến để cung cấp thông tin phản hồi sử dụng để sửa mô hình sai lầm, thay đổi, hiểu nhầm, thêm tính chức mà vô tình bị bỏ qua ❖ ❖ ❖ ❖ 3.2.4.Xây dựng Các hoạt động xây dựng bao gồm mã hóa thử nghiệm công việc mà dẫn đến phần mềm hoạt động mà sẵn sàng để giao cho khách hàng người sử dụng cuối Trong công việc kỹ thuật phần mềm đại, mã hóa tạo trực tiếp mã nguồn ngôn ngữ lập trình (ví dụ, Java), (2) hệ tự động mã nguồn sử dụng đại diện thiết kế giống trung gian thành phần xây dựng, hệ tự động mã thực thi cách sử dụng "ngôn ngữ lập trình hệ thứ tư" (ví dụ, Visual C++) Các thiết lập nguyên tắc để xây dựng : Mã hóa nguyên tắc :Các nguyên tắc hướng dẫn nhiệm vụ mã hóa liên kết chặt chẽ với phong cách lập trình, ngôn ngữ lập trình, phương pháp lập trình.Tuy nhiên, có số nguyên tắc mà nói sau : Nguyên tắc chuẩn bị: Trước bạn viết dòng mã, chắn bạn : • Hiểu vấn đề bạn cố gắng để giải • Hiểu nguyên tắc thiết kế khái niệm • Chọn ngôn ngữ lập trình đáp ứng nhu cầu phần mềm để có xây dựng môi trường hoạt động • Chọn môi trường lập trình cung cấp công cụ mà làm cho bạn làm việc dễ dàng • Tạo tập hợp kiểm tra đơn vị áp dụng thành phần bạn hoàn thành Lập trình nguyên tắc: Khi bắt đầu viết mã, chắn : • Liên kết thuật toán bạn cách làm theo lập trình có cấu trúc thực hành • Xem xét việc sử dụng cặp lập trình • Chọn cấu trúc liệu mà đáp ứng nhu cầu thiết kế Trang / 19 • Hiểu kiến trúc phần mềm tạo giao diện mà phù hợp với • Giữ logic có điều kiện đơn giản tốt • Tạo vòng lặp lồng cách mà làm cho chúng dễ dàng kiểm chứng • Chọn tên biến có ý nghĩa làm theo tiêu chuẩn mã hóa địa phương khác.Viết mã số tự tài liệu • Tạo bố trí trực quan (ví dụ, thụt đầu dòng dòng trống) nhằm hỗ trợ hiểu biết ❖ Nguyên tắc xác nhận: Sau hoàn thành vượt qua mã hóa chắn : • Tiến hành hướng mã thích hợp • Thực kiểm tra đơn vị lỗi xác bạn phát • Tái cấu trúc mã ❖ Nguyên tắc kiểm tra : • Thử nghiệm trình thực chương trình với mục đích việc tìm kiếm lỗi • Một trường hợp thử nghiệm tốt có xác suất cao việc tìm kiếm lỗi • Một thử nghiệm thành công phát lỗi chưa phát ❖ Một số nguyên tắc thử nghiệm ta cần biết sau : Nguyên tắc Tất thử nghiệm nên theo dõi khách hàng Mục tiêu kiểm thử phần mềm để phát lỗi Nó sau nhiều khuyết tật nặng (từ quan điểm khách hàng xem) người gây chương trình không đáp ứng yêu cầu Nguyên tắc Các xét nghiệm cần quy hoạch dài trước thử nghiệm bắt đầu Thử nghiệm quy hoạch bắt đầu sau mô hình yêu cầu hoàn tất định nghĩa chi tiết trường hợp thử nghiệm bắt đầu sau mô hình thiết kế kiên cố hóa Vì vậy, tất kiểm tra quy hoạch thiết kế trước mã tạo Nguyên tắc Nguyên tắc Pareto áp dụng để kiểm thử phần mềm Nguyên tắc Pareto ngụ ý 80% tất lỗi phát thử nghiệm có khả theo dõi đến 20% tất thành phần chương trình Vấn đề để cô lập thành phần nghi ngờ làm để triệt để chúng Nguyên tắc Thử nghiệm nên bắt đầu nhần nhỏ cuối phần lớn Trang / 19 Các thử nghiệm lên kế hoạch thực thường tập trung thành phần riêng lẻ Khi thử nghiệm tiến triển, tập trung chuyển nỗ lực để tìm lỗi cụm tích hợp thành phần cuối toàn hệ thống Nguyên tắc Thử nghiệm đầy đủ không khả thi Các số hoán vị đường dẫn cho chương trình có quy mô vừa đặc biệt lớn.Vì lý này, thực kết hợp đường dẫn thử nghiệm Đó có thể, nhiên, để tương xứng với chương trình logic để đảm bảo tất điều kiện việc thiết kế thành phần cấp thực 3.2.5.Triển khai Các hoạt động triển khai bao gồm ba hành động: giao hàng, hỗ trợ thông tin phản hồi Một số nguyên tắc đê triển khai phần mềm : Nguyên tắc Mong muốn khách hàng phần mềm phải quản lý Thông thường, khách hàng muốn nhiều thứ cung cấp, thất vọng xảy Điều dẫn đến phản hồi mà sản xuất ảnh hưởng đến tinh thần đội Nguyên tắc Một gói giao hàng đầy đủ phải lắp ráp thử nghiệm Một đĩa CD-ROM phương tiện truyền thông chứa tất phần mềm thực thi, hỗ trợ file liệu, tài liệu hỗ trợ, thông tin khác có liên quan nên lắp ráp triệt để beta thử nghiệm với người sử dụng thực tế Tất kịch cài đặt hoạt động khác tính nên thực kỹ lưỡng nhiều tính toán khác cấu hình (ví dụ, phần cứng, hệ điều hành, thiết bị ngoại vi, xếp mạng) tốt Nguyên tắc Một chế độ hỗ trợ phải thành lập trước phần mềm giao Khách hàng mong muốn đáp ứng thông tin xác câu hỏi vấn đề phát sinh Nếu hỗ trợ không tốt khách hàng không hài lòng Hỗ trợ nên có kế hoạch, tài liệu hỗ trợ cần chuẩn bị, chế lưu trữ hồ sơ phù hợp nên thiết lập để nhóm phần mềm tiến hành đánh giá phân loại loại hỗ trợ yêu cầu Nguyên tắc :Tài liệu giảng dạy phù hợp phải cung cấp cho người dùng Nhóm nghiên cứu phần mềm cần cung cấp nhiều phần mềm riên để hỗ trợ, xử lý cố hướng dẫn cần cung cấp cách đầy đủ Nguyên tắc Buggy (các lỗi) cần cố định sửa sau Trang / 19 Dưới áp lực thời gian, số tổ chức phần mềm cung cấp gia tăng chất lượng thấp với cảnh báo với khách hàng lỗi "sẽ sửa phiên tiếp theo." ❖ ❖ ❖ ❖ ❖ ❖ 3.3.Hiểu yêu cầu 3.3.1.Kỹ thuật yêu cầu Yêu cầu kĩ thuật hàng loạt nhiệm vụ kĩ thuật dẫn đến hiểu biết yêu cầu Từ quan điểm trình phần mềm,yêu cầu kĩ thuật hành động công nghệ phần mềm mà bắt đầu suốt hoạt động truyền thông tiếp tục vào hoạt động mô hình.Nó phải phù hợp với nhu vầu trình,các dự án,sản phẩm người làm việc Sự khởi đầu: dự án phần mềm bắt đầu doanh nghiệp xác định dịch vụ Các đối tượng liên quan( ví dụ: nhà quản lý kinh doanh,tiếp thị,quản lý sản phẩm…).Tất thông tin thay đổi.Tại khởi động dự án , bạn thiết lập hiểu biết vấn đề, người muốn có giải pháp , chất giải pháp mong muốn , hiệu truyền thông sơ kết, hợp tác bên liên quan khác nhóm phần mềm Sự khám phá: Nó đơn giản đủ để yêu cầu khách hàng , người sử dụng người khác mục tiêu hệ thống sản phẩm, thực , hệ thống sản phẩm phù hợp với nhu cầu doanh nghiệp, cuối , cách hệ thống sản phẩm sử dụng sở ngày qua ngày Các vấn đề biến động : Các yêu cầu thay đổi theo thời gian Để khắc phục vấn đề , bạn phải tiếp cận yêu cầu thu thập tổ chức Xây dựng: Các thông tin thu từ khách hàng thời gian khởi động , mở rộng hoàn thiện xây dựng Nhiệm vụ tập trung vào việc phát triển mô hình yêu cầu tinh tế để xác định khía cạnh khác chức phần mềm , hành vi, thông tin Xây dựng thúc đẩy sáng tạo tinh tế ý tưởng người dùng miêu tả cách người dùng tương tác với hệ thống Sự đàm phán: khách hàng người sử dụng yêu cầu nhiều nhà sản xuất phần mềm, đưa nguồn lực kinh doanh hạn chế Nó tương đối phổ biến cho khách hàng người sử dụng để đề xuất mâu thuẫn yêu cầu , cho phiên họ " Cần thiết cho nhu cầu đặc biệt "Bạn có để hòa giải xung đột thông qua trình đàm phán Khách hàng ,người dùng, bên liên quan khác yêu cầu xếp hạng yêu cầu sau thảo luận xung đột ưu tiên Đặc điểm kĩ thuật: Trong bối cảnh máy tính dựa hệ thống (và phần mềm) , thuật ngữ đặc điểm kỹ thuật có nghĩa khác người khác Một đặc điểm kỹ thuật người viết tài liệu, tập mô hình đồ họa , mô hình toán học thức, sưu tập kịch sử dụng , nguyên mẫu , kết hợp giữ chúng Xác nhận: Các sản phẩm công việc sản xuất hệ yêu cầu kỹ thuật đánh giá chất lượng bước xác nhận Các chế yêu cầu xác nhận Trang 10 / 19 việc xem xét kỹ thuật Nhóm đánh xác nhận yêu cầu bao gồm kỹ sư phần mềm ,khách hàng , người sử dụng bên liên quan khác, người kiểm tra đặc điểm kỹ thuật tìm kiếm sai sót nội dung giải thích , làm rõ nơi yêu cầu thiếu thông tin, thiếu quán, mâu thuẫn yêu cầu, không thực tế ❖ Yêu cầu quản lý: Yêu cầu hệ thống dựa máy tính thay đổi , mong muốn thay đổi yêu cầu tiếp tục suốt đời hệ thống Yêu cầu quản lý tập hợp hoạt động giúp nhóm dự án xác định , kiểm soát theo dõi yêu cầu thay đổi để yêu cầu lúc trình dự án.Nhiều dự án hoạt động giống hệt để quản lý cấu hình phần mềm ❖ ❖ ❖ ❖ 3.3.2.Thiết lập tảng Xác định bên liên quan: Các bên liên quan có nhìn khác hệ thống, đạt lợi ích khác hệ thống phát triển thành công , mở cửa cho rủi ro khác phát triển nỗ lực thất bại Có nhiều quan điểm: Bởi nhiều bên liên quan làm việc, yêu cầu hệ thống khám phá từ nhiều quan điểm khác nhau.Mỗi người đóng góp thông tin để yêu cầu quy trình kỹ thuật Như thông tin từ nhiều quan điểm, yêu cầu không phù hợp mâu thuẫn với quan điểm khác Bạn nên phân loại tất thông tin liên quan (bao gồm không phù hợp yêu cầu mâu thuẫn) nhà sản xuất định chọn yêu cầu phù hợp với hệ thống Làm việc hướng tới hợp tác: Nếu bên liên quan tham gia vào dự án phần mềm, bạn có nhiều ý kiến khác tập hợp yêu cầu.Khách hàng (và bên liên quan khác) phải kết hợp với với học viên công nghệ phần mềm kết hệ thống hoàn thành Đặt câu hỏi :Khi lên kế hoạch cho dự án phần mềm có nhiều câu hỏi đặt ra.Những câu hỏi giúp xác định tất bên liên quan có ảnh hưởng phần mềm xây dựng Ngoài ra, câu hỏi xác định lợi ích đo lường thành công phương án để phát triển phần mềm.Những câu hỏi giúp phá vỡ vướng mắc bắt đầu tìm tiếng nói chung 3.3.3.Gợi ý yêu cầu ❖ Thu thập yêu cầu hợp tác: Có nhiều phương pháp khác để thu thập yêu cầu hợp tác đặt Mỗi phương pháp làm cho việc sử dụng kịch khác , tất áp dụng số biến thể hướng dẫn sau : • Các họp tiến hành với tham gia hai kỹ sư phần mềm bên liên quan • Các quy tắc để chuẩn bị tham gia thành lập Trang 11 / 19 • Một chương trình đề nghị đủ để trang trải tất điểm quan trọng thức đủ để khuyến khích dòng chảy tự ý tưởng • Một " người hỗ trợ " (có thể khách hàng , nhà phát triển , người ) điều khiển gặp gỡ • Một chế " định nghĩa" (có thể tờ làm việc , biểu đồ lật, dán tường bảng thông báo điện tử , phòng chat , diễn đàn ảo ) sử dụng ❖ Triển khai chất lượng chức năng: Triển khai chất lượng chức kỹ thuật quản lý chất lượng dịch vụ nhu cầu khách hàng vào yêu cầu kỹ thuật phần mềm Triển khai chất lượng chức xác định ba loại yêu cầu: yêu cầu bình thường , yêu cầu dự kiến yêu cầu khuyến khích ❖ Khám phá sản phẩm: Đối với hầu hết hệ thống ,các sản phẩm công trình bao gồm: • Một tuyên bố nhu cầu khả thi • Một tuyên bố chặn phạm vi cho hệ thống sản phẩm • Một danh sách khách hàng, người sử dụng, bên liên quan khác, người tham gia yêu cầu dự kiến • Mô tả môi trường kỹ thuật hệ thống • Một danh sách yêu cầu • Một tập hợp kịch sử dụng cung cấp nhìn sâu sắc vào việc sử dụng hệ thống sản phẩm điều kiện vận hành khác • Bất kỳ nguyên mẫu phát triển để xác định tốt yêu cầu 3.3.4.Phát triển ca sử dụng(Use-case) ❖ Bước việc viết trường hợp sử dụng để xác định tập hợp " tác nhân " tham gia vào dự án Tác nhân người khác nhau( thiết bị) sử dụng hệ thống sản phẩm bối cảnh chức hành vi mô tả.Sau xem xét cẩn thận yêu cầu, phần mềm cho máy tính điều khiển đòi hỏi bốn chế độ khác để tương tác : Chế độ lập trình, chế độ kiểm tra,chế độ giám sát, chế độ xử lý cố Do , bốn tác nhân là: trình ngữ pháp , kiểm tra , giám sát khắc phục cố Trong số trường hợp, nhà điều hành máy làm tất vai trò 3.3.5.Xây dựng mô hình yêu cầu 3.3.5.1.Xây dựng yêu cầu đại: ❖ Các yếu tố yêu cầu: Có nhiều cách khác để xem xét yêu cầu cho máy tính dựa hệ thống Một số người làm phần mềm cho tốt để chọn chế độ đại diện Trang 12 / 19 ❖ Các yếu tố dựa phạm vi hoạt động: Hệ thống mô tả từ quan điểm người sử dụng xem sử dụng cách tiếp cận dựa phạm vi hoạt động ❖ Các yếu tố hành vi: Các hành vi hệ thống dựa máy tính có hiệu tìm thấy thiết kế lựa chọn thực cách tiếp cận áp dụng Vì , mô hình yêu cầu phải cung cấp yếu tố mô hình hóa mô tả hành vi 3.3.5.2.Phân tích kiểu mẫu ❖ Bất thực yêu cầu kỹ thuật nhiều vài phần mềm dự án bắt đầu nhận thấy vấn đề định tái xuất tất dự án vòng ứng dụng cụ thể (Ví dụ, lớp, chức năng, hành vi) miền ứng dụng tái sử dụng mô hình hóa nhiều ứng dụng ❖ ❖ ❖ ❖ ❖ ❖ ❖ 3.4.Mô hình hóa yêu cầu: kịch bản, thông tin, lớp đối tượng phân tích 3.4.1.Phân tích yêu cầu Phải hiểu biểu diễn miền thông tin Định danh liệu (đối tượng, thực thể) Định nghĩa thuộc tính Thiết lập mối quan hệ liệu Khả áp dụng mẫu thiết kế thành phần phần mềm thực thi phát triển Xác định yếu tố dòng chảy định hướng đại diện cho hệ thống Giữ cho mô hình phần mềm đơn giản, thêm giá trị cho mô hình sử dụng 3.4.2.Mô hình hoá dựa kịch ❖ Khi xác định yêu cầu, nhà phát triển phần mềm dựa ý tưởng hay yêu cầu khách hàng đưa thiết kế sơ số hình giao diện tiến hành mô hay giả lập sơ số chức năng, xem bước cài đặt mẫu chuyển cho người sử dụng Bản mẫu nhằm để mô tả cách thức phần mềm hoạt động cách người sử dụng tương tác với hệ thống.Nhằm giúp cho người dùng hình dung diện mạo ban đầu yêu cầu mà họ đặt Mô hình cần có hỗ trợ kỹ sư phân tích kỹ sư thiết kế phần mềm phối hợp thực Người sử dụng xem xét mẫu đưa ý kiến đóng góp phản hồi thông tin đồng ý hay không đồng ý phương án thiết kế mẫu đưa Nếu người sử dụng đồng ý với mẫu đưa người phát triển tiến hành cài đặt thực Ngược lại hai phải quay lại giai đoạn xác định yêu cầu Công việc lặp lại liên tục người sử dụng đồng ý với mẫu nhà phát triển đưa 3.4.3.Các mô hình UML bổ sung cho use-case a Mô hình nắm bắt yều cầu hướng đối tượng UML Trang 13 / 19 • Mục đích hoạt động nắm bắt yêu cầu xây dựng mô hình hệ thống mà xây dựng cách sử dụng use-case Các điểm bắt đầu cho hoạt động đa dạng: • Từ mô hình nghiệp vụ (business model) cho ứng dụng nghiệp vụ • Từ mô hình lĩnh vực (domain model) cho ứng dụng nhúng (embeded) • Từ đặc tả yêu cầu hệ thống nhúng tạo nhóm khác dùng phương pháp đặc tả khác • Từ điểm nằm điểm xuất phát Mô hình use-case: • Actor: người/ hệ thống ngoài/ thiết bị tương tác với hệ thống • Use-case: chức có nghĩa hệ thống cung cấp cho actor luồng kiện (flow of events) yêu cầu đặc biệt use-case • Đặc tả kiến trúc • Các thiết kế mẫu giao diện người dùng b Mô hình phân tích hướng đối tượng với UML • Mục đích hoạt động phân tích yêu cầu xây dựng mô hình phân tích với đặc điểm sau: • Dùng ngôn ngữ nhà phát triển để miêu tả mô hình • Thể gốc nhìn từ bên hệ thống • Được cấu trúc từ lớp phân tích package phân tích • Được dùng chủ yếu cho nhà phát triển để hiểu cách thức tạo hình dạng hệ thống • Loại trừ chi tiết dư thừa, không quán • Phác họa thực chất bên hệ thống • Định nghĩa dẫn xuất use-case, dẫn xuất use-case cấp phân tích miêu tả phân tích use-case • Mô hình phân tích= hệ thống phân tích • Các class phân tích: lớp biên, lớp thực thể, lớp điều khiển • Các dẫn xuất use-case cấp phân tích: lược đồ lớp phân tích, lược đồ tương tác, luồng kiện, yêu cầu đặc biệt use-case • Các package phân tích • Đặc tả kiến trúc Trang 14 / 19 ❖ ❖ ❖ ❖ ❖ 3.4.5.Mô hình hóa dựa lớp đối tượng Để xây dựng mô hình phân tích, gọi phân tích hướng đối tượng, tập trung vào định nghĩa lớp cách thức mà họ hợp tác với để thực yêu cầu khách hàng UML trình thống chủ yếu hướng đối tượng.Nó dựa số khái niệm sau: Ðối tượng (Object): gồm liệu thủ tục tác động lên liệu Ðóng gói (Encapsulation): Không cho phép tác động trực tiếp lên liệu đối tượng mà phải thông qua phương pháp trung gian Lớp (Class): Tập hợp đối tượng có chung cấu trúc liệu phương pháp Kế thừa (Heritage): tính chất kế thừa đặc tính cho phép định nghĩa lớp từ lớp có cách thêm vào liệu mới, phương pháp kế thừa đặc tính lớp cũ 3.5.Mô hình hóa yêu cầu: quy trình, hành vi, hoạt động 3.5.1 Mô hình hóa quy trình - Quy trình phần mềm chế để thu nhận tri thức miền - Các quy trình yêu cầu bao gồm loạt yếu tố: kịch dựa trên, định hướng liệu, dựa lớp,lưu lượng theo định hướng Khi mô hình quy trình phát hiện, tài liệu cách mô tả "một cách rõ ràng vấn đề chung mà mô hình áp dụng, giải pháp, quy định, giả định hạn chế việc sử dụng mô hình thực tế, thường số thông tin khác mô hình quy trình, chẳng hạn động lực động lực cho việc sử dụng mô hình - Các mô hình tái sử dụng thực yêu cầu mô hình cho ứng dụng miền mẫu phân tích lưu trữ kho lưu trữ để thành viên nhóm phần mềm sử dụng phương tiện tìm kiếm để tìm tái sử dụng chúng Khi mô hình thích hợp chọn, tích hợp vào mô hình yêu cầu cách tham chiếu đến tên mẫu 3.5.2 Mô hình hành vi Các mô hình hành vi cách mà phần mềm đáp ứng với kiện bên kích thích Để tạo mô hình hành vi , bạn cần thực bước sau: Đánh giá tất trường hợp sử dụng để hiểu đầy đủ trình tự tương tác bên hệ thống Xác định điều khiển trình tự tương tác kiện liên quan đến đối tượng cụ thể Tạo chuỗi cho trường hợp sử dụng Xây dựng sơ đồ trạng thái cho hệ thống Xem lại mô hình hành vi để xác minh tính xác quán Trang 15 / 19 3.5.3.Mô hình hoạt động: Trong quy trình phần mềm gồm hoạt động Những hoạt động bao gồm: - Đặc tả: chức hệ thống ràng buộc vận hành hệ thống cần phải xác định cách đầy đủ chi tiết - Thiết kế cài đặt: phần mềm xây dựng phải thoả mãn đặc tả - Đánh giá: phần mềm phải đánh giá thẩm định để đảm bảo thoả mãn tất yêu cầu - Cải tiến: phần mềm cần phải cải tiến điều chỉnh để phù hợp với thay đổi yêu cầu hệ thống 4.DANH MỤC TÀI LIỆU THAM KHẢO No [1] Tên tài liệu SRS_VController Ngày phát hành Nguồn Ssdc Vnpt Technology 1/7/2013 Ghi – Câu hỏi: Câu 1: Nguyên tắc quan trọng nguyên tắc cốt lõi việc thực thi A Chia để trị B Trừu tượng hóa vấn đề C Hãy cố gắng giữ vũng quan điểm D Cần người trì phần mềm Đáp Án:B Câu 2: Có bước để đánh giá rủi ro dự án phần mềm A.3 B.5 C.6 Trang 16 / 19 D.2 Đáp Án:C Câu 3: Trong mô hình hóa yêu cầu nguyên tắc quan trọng ? A Cố gắng để xây dựng mô hình hữu ích, không quên việc xây dựng mô hình hoàn hảo B Các mục tiêu nhóm phần mềm để xây dựng phần mềm, không tạo mô hình C Xây dựng mô hình cách linh hoạt D Điều chỉnh mô hình bạn phát triển với hệ thống Đáp án:A Câu 4: Nguyên tắc pareto việc kiểm thử phần mềm có nghĩa gì? A 60% số lượng lỗi tìm thấy 40% tính hệ thống B 50% số lượng lỗi tìm thấy 50% tính hệ thống C 80% số lượng lỗi tìm thấy 20% tính hệ thống D 70% số lượng lỗi tìm thấy 30% tính hệ thống Đáp án:C Câu 5: Tại phần mềm phải thiết kế mở rộng hóa A Theo thời gian,yêu cầu người dùng nhiều lên khối lượng công việc tăng lên B Các vấn đề mà phần mềm xử lý ngày phức tạp tiêu tốn nhiều tài nguyên C Các doanh nghiệp hướng tới phần mềm khấu hao gấp đến 10 lần giá trị phần mềm D Tất phương án Đáp án:D Câu 6: Use-case kịch mà mô tả A Phần mềm thực tình cho trước B Những công cụ case dùng để xây dựng hệ thống C Kế hoạch xây dựng sản phẩm cho phần mềm D Những test-case cho sản phẩm phần mềm Trang 17 / 19 Đáp án:A Câu 7: Tác vụ không biểu diễn phần phân tích yêu cầu phần mềm A Định giá tổng hợp B Mô hình hóa thừa nhận vấn đề C Lập kế hoạch lịch biểu D Đặc tả xem xét Đáp án:C Câu 8: Loại mô hình đượctạo phân tích yêu cầu phần mềm A Chức hành vi B Giải thuật cấu trúc liệu C Kiến trúc cấu trúc D Tính tin cậy tính sử dụng Đáp án:A Câu 9: Biểu đồ thực thể A Đưa hình ảnh quan hệ đối tượng liệu B Đưa hình ảnh chức biến đổi liệu C Chỉ định logic chúng xuất D Chỉ tương tác hệ thống với kiện bên Đáp án:A Câu 10: Biểu đồ dịch chuyển trạng thái A Đưa hình ảnh quan hệ đối tượng liệu B Đưa chức biến đổi luồn liệu C Chỉ hình ảnh liệu biến đổi hệ thống D Chỉ tương tác hệ thống với kiện bên Đáp án:D Câu 11: Refactor(Tái cấu trúc mã nguồn) là: A Thay đổi cấu trúc bên mà không làm thay đổi hành vi với bên hệ thống B Thay đổi cấu trúc bên cải thiện hiệu suất hệ thốn Trang 18 / 19 C Thay đổi cấu trúc bên để tìm use-case để cải thiện tính hệ thống D Cả ba phương án sai Đáp án:A Câu 12: Đặc tả hệ thống mô tả ? A Chức hành vi hệ thống dựa vào máy tính B Việc thi hành thành phần hệ thống C Chi tiết giải thuật cấu trúc hệ thống D Thời gian đòi hỏi cho việc giả lập hệ thống Đáp án:A Câu 13: Thẩm định đánh giá yêu cầu người dùng giúp A Hiểu người dùng cần muốn phần mềm.Dự đoán trước thay đổi mà người dùng đưa tương lai B Gợi ý bổ sung ,cải thiện yêu cầu mà người dùng đưa để tránh việc phải vá lỗi sau C Lược bỏ tiểu tiết dư thừa yêu cầu người dùng,tránh vừa làm phức tạp hóa vấn đề mà lại không cải thiện yêu cầu D Tất phương án Đáp án:D Giảng viên Những người thực (ký ghi rõ họ tên) (ký ghi rõ họ tên) Trang 19 / 19