Tài iệu công nghệ phần mềm HUCE

CÔNG NGHỆ PHẦN MỀM Các quy trình chung Phân tích yêu cầu Mô hình hóa thiết kế Kiểm tra chất lượng (SQA) Thực thi Thí nghiệm Duy trì Không chỉ xây dựng hệ thống phần mềm mà còn xây dựng chung một cách hiệu quả Trang bị cho sinh viên IT với Kiến thức cơ bản về phương pháp phát triển phần mềm Giúp sinh viên IT Phát triển phằn mềm theo nguyên tắc thông qua các phương thức thủ tục công cụ Để xây dụng phần mềm một cách hiệu quả Coder Kỹ sư phần mềm Chương 1 Phần mềm và Công nghệ phần mềm I Phần mềm 1.

CƠNG NGHỆ PHẦN MỀM Các quy trình chung: • • • • • • Phân tích u cầu Mơ hình hóa thiết kế Kiểm tra chất lượng (SQA) Thực thi Thí nghiệm Duy trì Khơng xây dựng hệ thống phần mềm mà xây dựng chung cách hiệu Trang bị cho sinh viên IT với: • Kiến thức phương pháp phát triển phần mềm Giúp sinh viên IT: • • • Phát triển phằn mềm theo nguyên tắc thông qua phương thức thủ tục công cụ Để xây dụng phần mềm cách hiệu Coder  Kỹ sư phần mềm Chương 1: Phần mềm Công nghệ phần mềm I Phần mềm Định nghĩa phần mềm • Phần mềm tập hợp câu lệnh chạy máy tính Các lệnh bảo cho máy tính phải làm Phần mềm máy tính hay gọi đơn giản phần mềm nói đến thành phần khơng hữu hình máy tính biết đến chương trình máy tính cụm từ sử dụng phần cứng máy tính tức phần vật lý hữu hình máy tính • Phần mềm gồm thành phần câu lệnh: o Các câu lệnh hay chương trình máy tính thực thi cung cấp chức hiệu mong muốn o Các cấu trúc liệu cho phép thao thác với đầy đủ thông tin o Các tài liệu mô tả hoạt động cách thức hoạt động chương trình Quá trình phát triển phần mềm • 1950 – 1960: ngày đầu máy tính • 1960 – 1970: Khủng hoảng phần mềm • Giữa 1970 – 1990: mạng, phần cứng giá rẻ • 1990 – đến nay: O-O, hệ thống chuyên gia, trí thơng minh (AI), kỹ thuật hệ thứ 4, điện thoại, … Đặc điểm phần mềm • Phầm mềm tạo cách phát triển khơng phải đơn sản xuất • Phần mềm lỗi thời khơng hao mịn • • • Phần mềm phức tạp tri phí thay đổi cho lần cao Lưu ý: o Các phần mềm xây dựng cách tùy chỉnh • Các đặc tính phần mềm tốt: o Khả bảo trì  Phần mềm trì hoạt động điều chỉnh mở rộng để thỏa mãn yêu cầu luôn thay đổi o Độ tin cậy  Phần mềm phải tin cậy, bảo mật xác o Hiệu  Phần mềm khơng sử dụng lãng phí tài nguyên hệ thống o Khả chấp nhật  Người dùng phải chấp nhận phần mềm điều có nghĩa phải dẽ hiểu sử dụng tương thích với hệ thống khác Các loại phần mềm • Phần mềm hệ thống: tập hợp chương trình cung cấp dịch vụ cho chương trình khác mức hệ thống Ví dụ trình biên dịch • Phần mềm kinh doanh • Phần mềm thời gian thực • Phần mềm khoa học cơng nghệ • Phần mềm nhúng: thiết lập rom máy tính dùng để điều khiển hệ thống sản phẩm thuộc thị trường công nghiệp sử dụng chức riêng biệt • Phần mềm trí tuệ nhân tạo: để sử dụng cơng nghệ AI giải tốn phức tạp • Các phần mềm máy tính cá nhân Những thách thức phần mềm • Khơng cung cấp tính mong muốn • Mất q nhiều t/g tiền bạc để xây dựng • Yêu cầu q nhiều tài ngun để chạy • Khơng đáp ứng thay đổi cần thiết o Kích thước sản phẩm phần mềm tăng lên theo cấp số nhân  Phần cứng nhanh hơn, nhỏ rẻ phần cứng o Phần mềm khắp nơi: từ TV đến điện thoại di động o Phần mềm nằm hệ thống quan trọng an toàn  Ơ tơ, máy bay, nhà máy điện hạt nhân o Chúng ta thấy nhiều  Hệ thống phân tán  Hệ thống nhúng  Hệ thống thời gian thực • Các loại hệ thống khó xây dựng o Yêu cầu phần mềm thay đổi  Phần mềm phát triển xây dựng Chương – Cơng Nghệ phần mềm Định nghĩa SE • Định ngĩa fritz bauner o Kỹ thuật phần mềm việc thiết lập sử dụng nguyên tác kỹ thuật hợp lý để có phần mềm kinh tế đáng tin cậy hoạt động máy thực • Định nghĩa IEEE phát triển o Kỹ thuật phần mềm: (1) Việc ấp dụng phương pháp có tính hệ thống có kỷ luật định lượng nhằm phát triển vận hành bảo trì phần mềm tức áp dụng kiến thức công nghệ vào phần mềm Why se? • Mục đích o Để tăng suất chất lượng phần mềm o Để kiểm sốt hiệu lịch trình kế hoạch phần mềm o Để giảm chi phí phát triển phần mềm o Để đạt nhu cầu yêu cầu khách hàng o Để tăng cường dẫn dắt quy trình kỹ thuật phần mềm o Để cải tiến thực hành kỹ thuật phần mềm o Để hỗ trợ hoạt động kỹ sư cách có hệ thống hiệu Cơng nghệ phần mềm bao gồm • Cơng nghệ phần mềm bao gồm nhiều lớp khác nhau: o Công cụ  Công cụ hỗ trợ tự động bán tự động cho quy trình học phương thức o Phương thức  Cung cấp thực kỹ thuật để xây dựng phần mềm  Các nhiệm vụ bao gồm truyền thơng liên lạc, phân tích liên lạc, thiết kế mơ hình hóa, xây dựng chương trình, kiểm thử hỗ trợ  Dựa tập hợp nguyên tắc chi phối lĩnh vực công nghê bao gồm hoạt độn mơ hình hóa o Quy tình  Quy trình lớp keo giữ lớp lại với tảng cho công nghệ phần mềm  Cho phép phát triển kịp thời  Tạo sở cho việc kiểm soát quản lý dự án phần mềm  Thiết lập bối cảnh mà phương pháp kỹ thuật áp dụng  Sản phầm công việc tạo  Các cột mốc quan trọng thiết lập  Chất lượng đảm bảo  Thay đổi quản lý cách • Trong tâm chất lượng o Là tảng o Bất kỳ phương pháp kỹ thuật dựa cam kết tổ chức chất lượng o Thúc đẩy văn hóa cải tiển quy trình liên tục Giai đoạn cơng nghệ phần mềm • Các cơng việc ngành công nghệ phần mềm chia thành giai đoạn tổng quát o Giai đoạn xác định Thông tin sử lý Chức hiệu suất mong muốn Hành vi hệ thống mong đợi Giao diện thiết lập Những ràng buộc thiết kế tồn Và tiêu trí xác nhận cần thiết o Giai đoạn phát triển  Cách thức liệu đc cấu trúc hóa ntn  Các chức triển khai kiến trúc phần mềm  Chi tiết thủ tục triển khai ntn  Đặc điểm giao diện ntn  Cách thiết kế dịch sang ngơn ngữ lập trình  Cách thức kiểm thử thực o Giải đoạn hỗ trợ  Sửa lỗi  Yêu cầu thích ứng môi trường phần mềm phát triển  Và thay đổi theo yêu cầu khách hàng  Có lọa thay đỏi gặp phải giai đoạn hỗ trợ: sửa chữa, thích ứng, nâng cao phịng ngừa Quy trình phát triển phần mềm 1) Mơ hình 1: Mơ hình tuyến tính • Hệ thống / kỹ thuật thông tin       Phần tích  thiết kế  coder  kiểm tra Mơ hình thác nước/ mơ hình vịng đời cổ điển/ mơ hình tuyến tính Đề xuất cách tiếp cận có hệ thống để phát triển phần mềm mức hệ thống tiến triển thơng qua phân tích thiết kế, mã hóa, kiểm thử hỗ trợ Kỹ thuật hệ thống/ thơng tin mơ hình hóa o Phần mềm ln phần hệ thống lớn nên thiết lập yêu cầu cho tất phần tử hệ thống sau sau phân bổ số tập hợp yêu cầu phần mềm o Phân tích kỹ thuật hệ thống bao gồm việc thu thập yêu cầu cấp hệ thống với lượng nhỏ cách thiết kế cấp cap Phân tinh yêu cầu phần mềm o Quá trình thu thập yêu cầu tăng cường tập trung đặc biệt vào phần mềm o kỹ sư phần mềm nhà phân tích phải hiểu miền thơng tin cho phần mềm chức yêu cầu hành vi hiệu suất giao diện yêu cầu hệ thống phần mềm ghi lại xem xét tới khách hàng Thiết kế o Thiết kế phần mềm trình nhiều bước tập chung vào thuộc tính chương trình cấu trúc liệu kiến trúc phần mềm biểu diễn giao diện chi tiết thủ tục hay thuộc tốn o o • • • Quá trình thiết kế chuyển yêu cầu thành đại diện phần mềm đánh giá chất lượng trước bắt đầu viết mã giống yêu cầu thiết kế ghi lại trở thành cấu hình phần mềm Tạo mã o Là thiết dịch sang dạng mà máy đọc o Bước tạo mã thực nhiệm vụ Nếu thiết kế thực cách chi tiết việc tạo mã thực cách học Kiểm thử o Khi mã tạo việc kiểm thử chương trình bắt đầu o Quá trình kiểm thử tập trung vào nội dung:  Logic nội phần mềm đảm bảo câu lệnh kiểm tra  Quá trình kiểm thử tập trung vào chức bên  Tiến hành thử nghiệm để phát lỗi đảm bảo đầu vào xác định tạo kết thực tế phù hợp với kết yêu cầu Hỗ trợ o Phần mềm trải qua thay đổi sau bàn giao cho khách hàng o Thay đổi sảy  Gặp lỗi  Phần mềm phải điều trỉnh để phù hợp với mơi trường bên ngồi ví dụ hệ điều hành thiết bị ngoại vi  Khách hàng yêu cầu cải tiến chức hiệu suất o Việc hỗ trợ/ bảo trì phần mềm áp dụng lại giao đoạn chương trình trước thay chương trình 2) Mơ hình thác nước – ưu điểm Mơ hình người dùng cuối khách hàng biết rõ Nõ giải vấn đề phức tạp theo cách trình tự, thực tốt cho dự án hiểu rõ cịn phức ạp Mơ hinh dễ thực việc phát triển theo trình tự Nó cung cấp cấu trúc cho nhân viên thiếu kinh nghiệm hay yếu kỹ thuật Nó làm việc tốt yêu cầu chất lượng trội yêu cầu lịch biểu chi phí Nó xác định thủ tục kiểm soát chất lượng Mỗi sản phẩm chuyển giao kiểm tra hồn tất Dễ dàng lần vết diễn tiến dự án cách dùng biểu đồ Gantt  Nhược điểm Phải đặc tả tất yêu cầu cách xác đầy dduur từ ban đầu Mơ hình có tính theo giai đoạn nên muốn quay lui hay nhiều giai đoạn để làm vấn đề hay kết thiếu sót totosn nhiều chi phí thời gian Nó khơng xử lý vấn đề thực tế chứa đựng việc lặp lặp lại giai đoạn Khó đánh giá tình trạng dự án Những vaasns đề tích hợp thực giai đoạn cuối nên trễ gặp vấn đề tích hợp Cần phải quản lý kiểm sốt chặt chẽ Khách hàng lấy hệ thống giai đoạn cuối o • • • • • • • • • • • • • • • • • • • • • Tồn delay nhóm làm việc  Khi sử dụng mơ hình thác nước Khi xác định sản phẩm ổn định vấn đề kỹ thuật biết rõ: o Nếu công ty xây dựng hệ thống kế tốn, bán hàng,… dự án xây đựng sản phẩm tương tự 3) Mơ hình tạo mẫu Mơ hình ngun mẫu o Thu tập yêu cầu: nhà phát triển khách hàng xác định mục tiêu tổng thể cho phần mềm xác định yêu cầu biết phác thảo lĩnh vực phải bắt buộc phải định nghĩa thêm o Thiết kế nhanh: tập trung vào việc trình bày khía cạnh phần mềm thị cho khách hàng dẫn đến nguyên mẫu o Nguyên mẫu đánh giá bời khách hàng hay người dùng xử dụng để o Sự lặp lại sảy nguyên mẫu điều chỉnh để đáp ứng nhu cầu khách hàng đồng thời cho phép nhà phát triển hiễu rõ cần thực  Ưu điểm: o Khách hàng tương tác sớm với hệ thống o Khách hàng người phát triển làm việc với o Người phát triển xác định xác yêu cầu o Co thể phát yêu cầu yêu cầu bất ngờ o Mơ hình cho phép thiết kế phát triển mềm dẻo qua nhiều vòng lặp  Nhược điểm: o Là phương pháp Quich-and-dirty o Những nguyên mẫu QAD thường gây khó khăn việc thiếu tư liệu hay tư liệu không phù hợp o Hệ thống xây dựng mang cấu trúc cách nghèo nàn với lựa khơng tốt hệ thống có chất lượng thấp khó bảo trì sau thời gian dài o Khách hàng hối thúc nhà phát triển hoàn thành sản phẩm thấy protype o Người phát triển rơi vào chu kỳ code and fix Mơ hình mẫu - sử dụng o Khi yêu cầu rõ, yêu cầu không ổn định, việc thông tin không đáp ứng tốt o Một vài phần hệ thống lớn tạo theo mơ hình mẫu o Khi người phát triển không chắn việc dùng giải thuật hay kiến trúc tối ưu o Trên hệ thống dựa vào phần mềm kỹ thuật cao mà yêu cầu không xác định rõ o Phù hợp với hệ thống  Hệ thống giao diện người dùng  Hệ thống tương tác trực tuýen  Sản phẩm  Hỗ trợ cho định 4) Mơ hình phát ứng dụng nhanh (RAD) • • • • • • • • Mơ hình RAD: mơ hình quy trình phát triển phần mềm gia tăng nhấn mạnh vào chu kỳ phát triển cực ngắn Mơ hình RAD thích ứng tốc độ cao mơ hình tuyến tính đạt phát triển nhanh chóng cách dụng cấu trúc dựa thành phần Nếu yêu cầu hiểu rõ phạm vi dự án giới hạn quy trình RAD cho phép nhóm phát triển tạo hệ thống đầy đủ chức khoảng thời gian ngắn khoản từ 60 đến 90 ngày Bước mơ hình nghiệp vụ Luồng thơng tin nghiệp vụ mơ hình hóa qua câu hỏi sau o Thơng tin thúc đẩy quy trình nhiệp vụ? o Thơng tin tạo ra? o Ai tạo nó? o Thơng tin đâu? o Ai sử lý nó? Mơ hình hóa liệu: Bước đặc điểm đối tượng mối quan hệ đối tượng xác định Mơ hình hóa cách xử lý: Mơ tả xử lý tạo cho việc thêm sửa đổi xóa truy xuất đối tượng liệu Tạo ứng dụng: Hệ thống thực tế tạo mã hóa thực cơng cụ tự động hóa điều chuyển đổi khái niệm tổng thể quy trình thơng tin liên quan thành đầu mong muốn thực tế đầu gọi mẫu thử nghiệm nửa chừng Kiểm tra quay vịng: thời gian chu trình tổng giảm xuống cho chu trình RAD nguyên mẫu kiểm tra độc lập sau chu trình  Điểm mạnh: o Thời gian phát triển giảm nhờ dùng cơng cụ o Chỉ cần người phát triển hơn, họ thân thiện với vấn đề o Nhanh chóng cho phép hình dung sản phẩm o Dùng hiệu framework cơng cụ đóng gói o Giảm rủi ro nhờ có tham gia khách hàng  Điểm yếu: o Thiếu tham gia tốt người dùng chu kỳ sống phần mềm o Người phát triển phải có kỹ huấn luyện tốt cho việc sử đụng công cụ thời gian phát triển nhanh o Hệ thống có khả phân tách module o Cần có đáp ứng thành phần sử dụng lại o Người phát triển khách hàng phải nỗ lực o Người quản lý phải làm việc tận tụy với nhóm phát triển khách hàng để nhah chóng  Mơ hình RAD – sửu dụng o Hệ thống dễ dàng phân chia module mở rộng o Hệ thống mà yêu cầu biết rõ hợp lý o Người dùng tham gia tốt qua tịa nbooj chu kỳ sống o Dự án thời gian phát triển ngắn, 60 ngày Những thành phần sử dụng lại có sẵ kho phần mềm Những hệ thống nhỏ, hệ thống khơng có tính nghiêm ngặt 5) Mơ hình gia tăng Mơ hình gia tăng o Mơ hình gia tăng kết hợp với mơ hình tuyến tính với triết lý tạo mẫu lặp lặp lại o Mơ hình gia tăng áp dụng trình tự tuyến tính theo kiểu so le thời gian lịch diễn Mỗi chuỗi tuyến tính tạo phần gia tăng phân phối phần mềm o Mơ hình gia tang tập trung vào việc cung cấp sản phẩm hoạt động với bước tăng dần o Lưu ý chức năng:  Các yêu cầu xác định phân loại theo độ ưu tiên, độ ưu teien cao cho chức chức có độ rủi ro cao  Phân chia yêu cầu cho vòng thiết kế kiến trúc tồn hệ thống  Vịng tạo sản phẩm lõi  Các bước sau bổ sung chức khác tích hơp vào hệ thống nhằm hoàn thiện dần sản phẩm  Mỗi chức hệ thống tích hợp phải đánh giá theo từ giai đoạn  Các yêu cầu kiến rúc toàn hệ thống dược điều chỉnh dựa vào sản phẩm phát hành theo vòng  Mơ hình gia tăng – ưu điểm o Những chức hệ thống có thứ tự ưu tiên cao (chức chính, chức rủi ro cao) thực trước, chúng kiểm thử nhiều hơn, sản phẩm hoàn thành phần sớm o Sau lần tăng vịng chuyển giao kết cho khách hàng Những kết đóng vai trị mẫu thử để giúp tìm hiểu them u cầu vịng o Có thẻ thực nhiều bước đồng thời tách nhỏ công việc nhằm dễ quản lý o Giảm rủi ro việc thất bại toàn dự án, rủi ro trải nhiều phần nhỏ o Sử dụng nhân viên giới hạn, họ thực cơng việc tương tự vịng  Mơ hình gia tăng - khuyết điểm o Xác định chức đầy đủ hoàn chỉnh trước xác định vòng gia tăng o Phải xác định rõ giao tiếp cho module mà thời gian hoàn thành cách biết nhiều o Việc kiểm tra khó khăn hệ thống hoàn chỉnh o Khách hàng thấy sản phẩm lõi nghĩ cơng việc đơn giản tốn o Địi hỏi phải có kế hoạch thiết kế tốt, phân chia cơng việc hợp lý, nhân viên phải công tác tốt  Mơ hình gia tăng – sử dụng o Khi tất yêu cầu hiểu rõ mong muốn có tiến hóa dần sản phẩm o o • Khi cần phải nhanh chóng đưa sản phẩm với chức thị trường sớm Áp dụng cho sản phẩm có thời gian phát triển dài năm 6) Mơ hình xốn ốc Mơ hình xốn ốc o Mơ hình xốn ốc loại mơ hình quy trình phần mềm tiến hóa kết hợp tính lặp lại việc tạo mẫu với khía cạnh kiểm sốt có hệ thống mơ hình tuyến tính o Nó triển khai tiềm phiên phần mềm o Sử dụng mơ hình xốn ốc phần mềm phát triển phát hành gia tăng lần lặp lại phát hành bổ sung mơ hình giấy ngun mẫu lần lặp lại sau ngày có nhiều hồn thiện so với mơ hình thiết kế o o • • • • • • • Mơ hình xốn ốc chia thành hoạt động: o Giao tiếp với khách hàng – nhiệm vụ cần thiết để thiết lập giao teiesp hiệu nhà phát triển khách hàng o Lập kế hoạch – nhiệm vụ cần thiết để xác định nguồn lực, lịch trình thơng tin khác liên quan đén dự án o Phân tích rủi ro nhiệm vụ cần thiết để đánh giá rủi ro kỹ thuật quản lý Kỹ thuât/ công nhệ xác định nhiệm vụ cần thiết để xác định hay nhiều đại diện ứng dụng Xây dựng phát hành – có nhiệm vụ cần thiết để xây dựng, kiểm thử, cài đặt, cung cấp hỗ trợ người dung ví dụ tài liệu đào tạo Đánh giá khách hàng – phản hồi khách hàng dựa đánh giá phần mềm giai đoạn kỹ nghệ thực giai đoạn cài đặt Bắt đầu từ tâm di chuyển hình xốn ốc theo chiều kim đồng hồ Vịng dẫn đến phát triển đặc tả kỹ thuật sản phẩm lần vượt qua sử dụng phát triển nguyên mẫu sau dó phát triển phần phức tạp phần mềm • • • • • Mỗi lần qua vùng quy hoạch dẫn đến điều chỉnh quy hoạch dự án chi phí lịch trình điều chỉnh dựa phản hồi khách hàng người quản lý dự án điều chỉnh số lần lặp theo kế hoạch cần thiết để hoàn thiện phần mềm Mỗi hình khối đặt dọc theo trục sử dụng đặt đầu dự án khác để làm đại diện khởi đầu Một dự án phát triển ý tưởng bắt đầu tâm vịng xốn ốc tiếp tục tồn thành phát triển ý tưởng Nếu khái niệm phát triển thành sản phẩm thực tế trình tiếp tục hình khối điểu đầu vào dự án dự án phát triển bắt đầu  Mơ hình xoắn ốc – ưu điểm o Mii hình xốn ốc phát triển hệ thống quy mô lớn phạm vi o Mơ hình xốn ốc sử dụng tạo mẫu chế giảm thiểu rủi ro cho phép nhà phát triển áp dụng phương pháp tạo mẫu cho giai đoạn trinhfh phát triển sản phẩm o Mơ hình xốn ốc u cầu xem xét rủi ro kỹ thuật tất giai đoạn dự án áp dụng cách chúng giảm thiểu rủi cho trước giảm thiểu vấn đề  Mơ hình xoắn ốc – nhược điểm o Mơ hình xốn ốc khó thuyết phục khách hàng phương pháp tiếp cận tiến hóa kiểm sốt o Địi hỏi chun môn đánh giá rủi ro dựa vào kiến thức chuyên môn để đánh giá để thành công Nếu dủi ro lớn k sử lý vấn đề xảy  Mơ hình xoắn ốc – phạm vi o Khi việc phân phối yêu cầu thường xuyên o Khi dự án lớn o Các yêu cầu không rõ ràng phức tạp o Khi yêu cầu thay đổi xảy lúc o Các dự án mà có ngân sách cao 7) Mơ hình kỹ nghệ hệ thứ Mơ hình kỹ nghệ thứ o 4GT bao gồm cơng cụ phần mềm có điểm chung: công cụ cho phép kỹ sư phần mềm xác định đặc tính phần mềm tốc độ cao sau công cụ tự tạo mã nguồn dựa đặc điểm kỹ thuật nhà phát triển mô o 4GT tập chung vào phần mềm ngôn ngữ chuyên dụng kỹ thuật đồ họa mô tả vấn đề cần giải theo khách hàng hiểu  Ưu điểm o Sử dụng 4GT cách tiếp cận khả thi cho nhiều lĩnh vực khác Cùng với công cụ kỹ thuật phần mềm hỗ trợ máy tính tạo mã, 4GT cung cấp giải pháp đáng tin cậy cho nhiều vấn đề phần mềm o Dữ liệu thu thập từ công ty sử dụng 4GT cho thấy thời gian cần thiết để sản xuất phần mềm giảm đáng kể ứng dụn nhỏ trung gian , đồng thời khối lượng thiết kế phân tích cho ứng dụng nhỏ giảm xuống  Nhược điểm: Tạo nhóm tập trung Phân tích giao diện Phỏng vấn Quan sát Mơ hình quy trình Ngun mẫu u cầu cơng trình o Hướng dẫn chi tiết việc rút yêu cầu  Đánh giá tính khả thi kinh doanh kỹ thuật choheej thống đề xuất  Xác định người giúp xác định yêu cầu hiểu thiên vị tổ chức họ  Xác định mơi trường kỹ thuật (ví dụ, kiến trúc máy tính, hệ điều hành, nhu cầu viễn thơng) mà hệ thống sản phẩm đặt vào  Xác định ràng buộc miền (nghĩa đặc điểm môi trường kinh doanh cụ thể cho miền ứng dụng) giới hạn chức hiệu suất hệ thông sản phẩm xây dựng  Xác định haowcj nhiều phương pháp khơi gợi yêu cầu (ví dụ: vấn, nhóm tập trung, họp nhóm)  Thu hút tham quan nhiều người để yêu cầu xác định theo quuan điểm khác đảm bảo xác định sở lý luận cho yêu cầu ghi lại  Xác định yêu cầu không rõ ràng ứng cử viên cho việc tạo mẫu  Tạo kịch sử dụng để giúp khách hàng/ người dùng xác định tốt yêu cầu o sản phẩm làm việc bao gồm  tuyên bố nhu cầu tính khả thi  Tuyên bố giới hạn phạm vi hệ thống  Danh sách khách hàng, người dùng bên liên quan khách tham gia vào hoạt động đưa yêu cầu  Mô tả môi trường kỹ thuật hệ thống  Danh ách yêu cầu (được xếp theo chức năng) ràng buộc miền áp dụng cho yêu cầu  Một tập hợp tình sử dụng cung ấp thơng tin chi tiết việc sử dụng hệ thống sản phẩm điều kiện hoạt động khác  Bất kỳ yêu cầu phát triển dến tốt định nghĩa nguyên mẫu Phân tích yêu cầu thương lượng o Phân tích  Phân loại yêu cầu xếp chngs thành tập liên quan  Khám phá yêu cầu mối quan hệ với người khác  Kiếm tra yêu cầu tính quán, thiếu sót, mơ hồ  Và xếp hạng yêu cầu dựa nhu cầu khách hàng/ người dùng o Các câu hỏi sau hỏi trả lời:        • Mỗi u cầu có phù hợp với mục tiêu tổng thể hệ thống/ sản phẩm không  Tất yêu cầu định mức trừu tượng thích hợp chưa? Có nghĩa số yêu cầu cung cấp mức độ chi tiết kỹ thuật không phù hợp giai đoạn  Yêu cầu có thực cần thiết hay đại diện cho tính có bổ sung khơn cần thiết mục tiêu hệ thống  Mỗi yêu cầu có giới hạn rõ ràng hay khơng?  Mơi u cầu có ghi nhận tác giả khơng? Đó là, nguồn có ghi cho yêu cầu không?  Yêu cầu xung đột với yêu cầu khác không  Mỗi yêu cầu đạt mơi trường kỹ thuật chứa hệ thống sản phaarmr không?  Môi yêu cầu kiểm tra được, thực khơng? o Một đặc điểm kỹ thuật  Một văn ‘một mơ hình đồ họa  Một mơ hình tốn học thức  Một tập hợp tình sử dụng  Một nguyên mẫu  Hoặc kết hợp củ thứ o Đối với hệ thống lớn, tài liệu viết, kết hợp mô tả ngôn ngữ tự nhiên mơ hình đồ họa cách tiếp cận tốt o Đối với hệ thống nhỏ, tình hướng sử dụng tất yêu cầu sản phẩm hệ thống nhỏ nằ mtrong môi trường kỹ thuật hiểu rõ SRS (đặc tả yêu cầu) o Đặc tả yêu cầu phần mềm sản phẩm cuối sản xuất kỹ sư hệ thống u cầu o Nó mơ tả chức hiệu suất hệ thống dựa máy tính ràng buộc chi phối phát triển Đặc điểm kỹ thuật giới hạn phần tử hệ thống phân bổ o Đặc tả hệ thống mô tả thông tin (dữ liệu điều khiển) nhập vào xuất từ hệ thống Xác thực yêu cầu o Kiểm tra đặc điểm kỹ thuật để đảm bảo  Tất yêu cầu hệ thống nêu rõ ràng  Các mâu thuẫn, thiếu sót sai sót phát sửa chữa  Và sản phẩm làm việc phù hợp với tiêu chuẩn thiết lập cho trình, dự án sản phẩm o Cơ chế xác nhạn yêu cầu xem xét kỹ thuật thức o Nhóm đánh giá bao gồm kỹ sư hệ thống, khách hàng, người dùng bên liên quan khác o Nhóm đánh giá kiểm tra đặc tả hệ thống, tìm kiếm:  Lỗi nội dung diễn giải  • • Các khu vực cần làm rõ Thiếu thơng tin Mâu thuẫn Yêu cầu mâu thuẩn Hoặc yêu cầu không thực tế (không thể đạt được) Quản lý yêu cầu o Quản lý yêu cầu 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 vafcasc thay đổi yêu cầu lúc dự án tiến hành o Mỗi yêu cầu định số dạng có dạng:      • Trong loại yêu cầu nhận giá trị F = yêu cầu chức năng, D = cầu liệu, B = yêu cầu hành vi, I = yêu cầu giao diện P = yêu cầu đầu yêu Ví dụ: yêu cầu xác định F09 yêu cầu chức định yêu cầu số Khi yêu cầu xác định, bảng xác ddinhhj nguồn gốc phát triển o Trong số nhiều bảng truy xuất nguồn gốc có bảng sau:  Tính bảng truy xuất nguồn gốc Cho biết yeu cầu liên quan đến tính quan trọng hệ thống/ sản phẩm quan sát khách hàng  Bảng truy xuất nguồn gốc Xác định nguồn yêu cầu  Bảng truy xuất nguồn gốc Xác định nguồn yêu cầu  Bảng truy xuất nguồn gốc phụ thuộc Cho biết yêu cầu có liên quan với  Bảng truy xuất nguồn gốc hệ thống Phân loại yêu cầu theo hệ thống mà chúng chi phối  Bảng truy xuất nguồn gốc giao diện Cho biết yêu cầu liên quan đến giao diện hệ thống bên bên ngồi Phân tích u cầu phần mềm o Phân tích yêu cầu cho phép kỹ sư phần mềm tinh chỉnh phân bố phần mềm xây dựng mơ hình miền liệu, chức hành vi xử lý phần mềm o Phân tích yêu cầu cung cấp cho nhà thiết kế phần mềm trình bày thơng tin, chức hành vi dịch sang liệu, kiến trúc, giao diện thiết kế cấp thành phần o Cuối cùng, đặc tả yêu cầu cung cấp cho nhà phát triển khách hàng phương tiện để đánh giá chất lượng sau phần mềm xây dựng o Phân tích yêu cầu phần mề mcos thể chia thàn năm lĩnh vực nỗ lực:  (1) nhận dạng vấn đề  (2) đánh giá tổng hợp o • (3) mơ hình hóa (4) đặc điểm kỹ thuật (5) đánh giá o Nhà phân tích phải  Xác định tất đối tượng liệu quan sát bên ngồi  Đánh giá luồng liệu nội dung thông tin  Xác định xây dựng tất chức phần mềm  Hiểu hành vi phần mềm bối cảnh kiện ảnh hưởng đến hệ thống, thiết lập đặc điểm giao diện  Và khám phá ràng buộc thiết kế bổ dung Ngyên tắc phân tích Miền thơng tin vấn đề phải biểu diễn hiểu rõ Các chức mà phần mềm thực phải xác định Hành vi phần mềm (do hệ kiện bên ngoài) phải biểu diễn Các mơ hình mơ tả thơng tinm chức hành vi phải phân vùng theo phát chi tiết theo kiểu phân lớp (hoặc phân cấp) Q trình phân tích nên chuyển từ thông tin thiết yếu sang chi tiết thực Các hướng dẫn phân tích yêu cầu: o Hiểu vấn đề trước bắt đầu phân tích o Phát triển nguyên mẫu cho phép người dùng hiểu cách tương tác người/ máy móc xảy o Ghi lại nguồn gốc lý yêu cầu o Sử dụng nguồn gốc lý yêu cầu o Sử dụng nhiều chế độ xem yêu cầu o Yêu cầu xếp hạng o Làm việc để loại bỏ mơ hồ Mơ hình phần mềm o Mơ hình chức o Mơ hình hành vi Phương pháp tiếp cận tạo mẫu o Mơ hình tạo mẫu kết thúc đóng kết thúc mở  Phương pháp kết thúc gần thường goij tạo mẫu thử nghiệm  Một cách tiếp cận mở, gọi tạo mẫu tiến hóa, sử dụng nguyên mẫu làm phần hoạt động phân tích tiếp tục thiết kế xây dựng o Cần phải xác định xem liệu hệ thống xây dựng có khả tạo mẫu ahy khơng  Khu vực ứng dụng  ứng dụng phức tạp  đặc điểm khách hàng  đặc điểm dự án o Phương thức công cụ tạo mẫu  Kỹ thuật hệ thứ  Các thành phần phần mềm mà tái sử dụng    • • • • Đặc tả thức môi trường tạo mẫu Đặc điểm kỹ thuật phần mềm o Đặc điểm kỹ thuật xem trình biểu diễn Các yêu cầu thể theo cách cuối dẫn đến việc triển khai phần mềm thành công Nguyên tác đặc điểm kỹ thuật phần mềm o Nguyên tắc đặc điểm kỹ thuật  Tách chức khỏi việc triển khai  Phát triển mo hình hành vi mong muốn hệ thống bao gồm liệu phản ứng chức hệ thống kích thích khác từ mơi trường bên ngồi  Thiết lập bối cảnh phần mềm hoạt động cách định cách thức mà thành phần hệ thống khác tương tác với phần mềm  Xác điịnh môi trường mà hệ thống hoạt động  Tạo mơ hình nhận thức mơ hình thiết kế triển khai Mơ hình nhận thức mơ tả hệ thống cộng đồng người dùng nhân thức  Nhận thức thông số kỹ thuật phải chịu khơng hồn chỉnh bổ sung Một đặc tả ln mơ hình số tình thực tế thường phức tạp Do đó, khơng ddaafy đủ tồn mức độ chi tiết  Thiết tập nội dung cấu trúc đặc tả theo cách cho phép thay đổi  • • Chương 4: Thiết kế nguyên tắc thiết kế phần mềm Mục tiêu thiết kế: • • • Là tạo mơ hình đại diện thực thể mà xây dựng sau Thiết kế hoạt động hoạt đông kỹ thuật (thiết kế, tạo mã kiểm thử) yêu cầu để xây dựng xác minh phần mềm Bước đặc tả yêu cầu thể mơ hình liệu hành vi cung cấp đầu vào cho nhiệm vụ thiết kế Thiết kế chuỗi định • • Quyết định thiết kế với thiết kế thay từ lựa chọn khác nhau: o Đường thẳng biểu diễn cho tùy chọn o Đường đậm nét tập hợp định đưa Nhiệm vụ thiết kế tạo thiết kế liệu, thiết kế kiến trúc thiết kế giao diện thiết kế thành phần o Thiết kế liệu chuyển đổi mơ hình miền thơng tin tạo q trình phân tích thành cấu trúc liệu yêu cầu để triển khai phần mềm Thiết kế kiến trúc xác định mối quan hệ yếu tố cấu trúc phần mềm mẫu thiết kế sử dụng để đạt yêu cầu o Thiết kế giao diện mô tả cách phần mềm giao tiếp bên với hệ thống tương tác với với người sử dụng o Thiết kế mức thành phần chuyển đổi yếu tố cấu trúc kiến trúc phần mềm thành mô tả thủ tục thành phần phần mềm Thiết kế cung cấp đại diện phần mềm đánh giá chất lượng Thiết kế cách để dịch cách xác yêu cầu khách hàng thành thành sản phẩm phần mềm hồn chỉnh o • • Đánh giá chất lượng thiết kế • • • Thiết kế giai đoạn mà chất lượng thấm nhuần Thiết kế đánh giá cách xem xét thức hướng dẫn Đặc điểm thiết kế tốt: Là thiết kế phải thỏa yêu cầu tường minh yêu cầu ngầm định Thiết kế phải dễ hiểu dễ đọc hỗ trợ cho việc tạo mã kiểm thử Thiết kế phải cung cấp đầy đủ hình ảnh phần mềm xác định liệu chức hành vi theo hướng thực thi Thuộc tính chất lượng FUROS • • • • • Chức năng: khả phần mềm, kèm theo tính an ninh Tiện dụng: bao gồm tính thẩm mỹ, quán tư liệu Tin cậy: tính xác, dùng The mean-time-to-failure, Khả phục hồi từ lỗi Thực thi: tốc độ xử lý, thời gian đáp ứng, sử dụng tài nguyên hiệu … Khả hỗ trợ: dễ mở rông, khả ráp nối, khả test, khả cấu hình, khả tương thích Hướng dẫn thiết kế • • • • • • • • Một thành phần thiết kế phải đuuă kiến trúc mà o (1) dùng mẫu hay kiểu kiến trúc thừa nhận o (2) gồm thành phần có đặc trưng thiết keestotos o (3) thi hành theo cách tiến hóa Thiết kế phải module hóa Thiết kế phải trình bày riêng liệu, kiến trúc, giao diện thành phần Thiết kế phải đưa cấu trúc liệu phù hợp với lớp thực thi từ mẫu liệu thừa nhận Thiết kế phải đưa thành phần mà độ lập chức Thiết kế phải đưa giao diện mà giảm phức tạp việc kết nối thành phần, mơi trường bên ngồi Thiết kế đưa từ việc dùng phương pháp lặp mà định hướng thông tin đạt suốt q trình phân tích u cầu phần mềm Thiết kế phải dùng ký hiệu hiệu cao việc thơng tin Ngun tắc thiết kế • • Thiết kế phần mềm vừa mơ hình vừa trình trình thiết kế chuỗi bước cho phép nhà thiết kế mô tả tất khía cạnh phần mềm xây dựng (kỹ sáng tạo, kinh nghiệm khứ, cảm nhận cách tạo lên phần mềm tốt) Mơ hình tiết kế bắt đầu cách đại diện biểu diễn cho tổng thể từ từ tinh chỉnh từ để cung cấp mẫu xây dựng chi tiết Nguyên tắc thiết kế phần mềm • • • • • • • • • • • • • Thiết kế khơng lên bị bó hẹp tầm nhìn nghĩa khơng tập trung vào việc hồn thành mục tiêu mà phải tập trung vào hiệu khác Có thể theo dõi mơ hình phân tích có nghĩa phải đáp ứng tất yêu cầu phần mềm để phát triển sản phẩm chất lượng cao Không nên lãng phí thời gian cơng sức vào việc tồn Giảm thiểu khoảng cách vấn đề giới thực giải pháp phần mềm cho vấn đề Thể tính đồng xác thực, thiết kế phải đồng tất q trình Tích hợp có nghĩa nên trộn kết hợp thành phần phần mềm hệ thống thành hệ thống Thiết kế phải thích ứng thay đổi tức phải điều chỉnh cách phù hợp để thích ứng thay đổi từ phía người dùng Thiết kế phải cấu trúc cho giảm cấp cách nhẹ nhangf có nghĩa hoạt động bình thường có lỗi xảy q trình thực thi Thiết kế khơng phải mã hóa Thiết kế mơ tả logic trương trình để giải vấn đề Mã hóa loại ngơn ngữ sử dụng để triển khai thiết kế Đánh giá chất lượng: o Thiết kế cần xem xét đánh giá chất lượng o Chất lượng thiết kế cần kiểm tra tập trung vào Xem xét để phát lỗi: o Thiết kế cần xem xét đánh giá tổng thể để kiểm tra xem có lỗi xuất giảm thiểu lỗi hay khơng Khái niệm thiết kế  Trừu tượng tinh chỉnh làm mịn bước • Trừu tượng hóa: o Là q trình ánh xạ vật tượng giới thực thành khái niệm logic Tính trừu tượng cho phép người ta tập trung vào vấn đề mức khái qt mà khơng cần quan tâm đến tri tiết khác không liên quan o Tinh chỉnh kỹ thuật phần mề trình tinh chỉnh yếu tố trừu tượng ngôn ngữ đại cho phép trừu tượng hóa loại trừu tượng hóa o Kiểu: liệu, phần mềm, điều khiển Tinh chỉnh làm mịn theo bước o • Tiếp cận theo hướng hướng lên xuống xây dựng chi tiết Tính trừu tượng tinh chỉnh hai tính chất bổ sung cho Tính trừu tượng ngăn chặn chi tiết cấp thấp tinh chỉnh bộc lộ điều  Tính modul hóa • Phầm mềm chia thành thành phần có tên địa phân biệt • Modul chuỗi câu lệnh trương trình liền kề mặt từ vựng giới hạn phần tử danh giới có số nhận dạng tổng hợp, modul thủ tục, chức đối tượng • Lợi ích việc modul hóa : o o o + dễ dàng cho việc xây dựng + dễ dàng cho việc xửa chữa + dễ cho việc thay đổi +tính modul tính phần mềm cho phép trương trình quản lý cách trí tuệ nhiên đừng lạm dụng nó, nhiều modul làm cho việc tích hớp trở lên phức tạp + đơi mã nguồn nguyên khối vd: phầm mềm thời gian thực phầm mềm nhúng thiết kế khơng nên + thiết kế modul hịu đảm bảo tính chất gắn kết cao nối kết thấp • Phương pháp thiết kê smodil hiệu chứng minh được: + Khả phân rã chế có tính hệ thống để giải quết vấn đề +Khả tương thích tái sử dụng modul hệ thống +Tính dễ hiểu- modul hiểu đơn vị độc lập +Tính liên tục-giảm thiếu tác dụng phụ thay đổi gây +Bảo vệ-Giamr thiểu tác dụng phụ lỗi gây  Gắn kết nối kết • Định Nghĩa tính gấn kết : +là mức độ tương tác bên modul thước đo vê sức mạnh tính + thiết kết tốt thiết kế có độ gắn kết cao • • Một số thuật ngữ + Hành động hành vi cỉa modul Vd tính tốn bậc +Logic các modul thực hành động Vd phương pháo neưton +Ngữ cảnh cách sử dụng cụ thể modul : vd tì bậc số nguyên độ xác kép Các loại gắn kết + Gắn kết ngẫu nhiên : + Thực Hiện nhiều hành động khơng liên quan đến + Có thể xảu tổ thực thi quy tắc cứng nhắc vè quy tắc modul-modul tách tời gán lại với • • +Cách cịn hệ khoogn có modul + Gắn kết logic : + nhiệm vụ modul thực thi cách logic + vd đối tượng thực thi toàn đầu vào đầu +Giao diện khó hiểu mã hóa vài thành phần đan xen + Sự Gắn kết tạm thời +Là tác vụ thực khoảng thời gian +Vd khởi tạo cấu trúc liệu + Liên kết theo thủ tục +Là hành động có liên quan đến phải thực theo thứ tự định +Gắn kết liên lạc +là hành động thực theo chuỗi liệu ảnh hưởng đến khả tái sử dụng + Gắn kết chức thông tin(Tốt nhất) +Đây gắn kết modul thực hành động +Thực số hành động vs điểm nhập riêng biệt, tấy thực cấu trúc liệu +Nó tương đương với đối tượng or kiểu liệu trừu tượng thiết kế tốt Khớp nối + mức độ tương tác modul + thước đo phụ thuộc lẫn tương đối, thiết kết tốt thiết kế có nối kết thấp Sau loại nối kết từ mức tồi đến tốt +Nối kết nội dung: +một mudul có tham chieevs trực tiếp đến nội modul khác + thay đổi modul ảnh hưởng đến modul +Kết nối chung +cả modul truy xuất đến vùng dl tổng thể +là dạng chịu tất nhược điểm dungf biến toàn cục +Nối kết điều khiển +yếu tố kiểm xoát chuyển modul +những loại modul thường có tính gắn kết logic +nỐi kết team +tồn cấu trúc dl gi, mảng, đối tượng chuyển nhiên modul gọi hoạt động phần cấu trúc dl + rủi ro vảo bật cho phép truy cập dl khơng kiểm xốt +kết nối liệu +Mọi đối số kiểu đơn giản cấu trúc liệu +all thành phầnđược sử dụng modul gọi +Bảo trì dễ dàng khả xảy lỗi nguồn quy  • • • • • • • • • • • Che giấu thông tin Được hỗ trợ thuật ngữ đặc tả Về mức độ truy suất ngơn ngữ lập trình đại Hướng đến việc nối kết thấp giảm khả tạo tác dụng phụ + hạn chết tác động tổng thể quết định cục + nhấn mạnh giao tiêps thông qua giao diện đc kiểm xốt + khơng khuyến khích việc sử dụng liệu tổng thể +kết quà phần mềm có chất lượng cao hơ Khiết kế liệu Tạo mơ hình liệu thơng tin trình bày mức độ trừu tượng cao chết độ xem liệu khách hangf hay người dung Hoạt động thiết kết liệu chuyển phần tử mơ hình u cầu thành cầu trúc liệu cấp thành phần cần thiết kiến thức sở liệu cấp ứng dụng Các đối tượng liệu xác định trình phân tích u cầu phần mềm mơ hình hóa mơ hình thực thể quan hệ Kiến trúc phần mềm Là cấu trúc hệ thôngs bao gồm thành phần phần mềm, thuộc tính nhìn thấy từ bên ngồi thành phần mối quan hệ chúng thành phần phầm mềm modul trương trình sở liệu phần trung gian cho phép cấu hình lại máy phát phát chủ 22/03/2022 Thiết kế dao diện : • Tập trung vào lĩnh vực quan tâm + thiết kế giao diện thành phần phầm mềm + thiết kế giaoao diện phần mềm đối tượng xản suất tiêu thụ thông tin người tức với thực thể bên + thiết kế giao diện người máy tính • • Thiết kế giao diện người dung quy tắc vàng : + đặt người dung vào kiểm xoát + giảm tải nhớ người dùng + làm cho giao diện quán Đặt người dùng vào kiểm xoát  Xác định chế độ tương tác theo cách không buộc người dung thực hành động không cần thiết không mong muốn Chế độ tương tác trạng thái giao diện Cung cấp tương tác linh hoạt Cho phép tương tác người dung khả dán đoạn khả hoàn tác  Họp lý hóa tương tác cấp độ kỹ nâng cao chi phép tương tác tùy chỉnh  Ẩn nội kỹ thuật khỏi người dùng bình thường  Thiết kế để tương tác trực tiếp với đối tượng thiết kế hình Giam tải nhớ người dung  Giamr nhu cầu trí nhớ ngắn hạn  Thiết lập giá trị mặc định có ỹ nghĩa  Xác định phím tắt trực quan  Bố cục trực quan giao diện phải dựa phép ẩn dụ giới thực  Tiết lộ thông thin cách liên tục làm cho giao diện quán  Cho phép người dung đặt nhiệm vụ vào ngữ cảnh có ý nhĩa  Duy trì tính qn nhóm ứng dụng Mơ hinhfh thiết kế giao diện + loại mơ hình khác phát huy tác dụng giao diện người dung đc htieets kế + kỹ sư phần mềm tạo mơ hình thiết kế + kỹ sư phần mềm thiết lập mơ hình người dung, người dung cuối phát triển hình ảnh gọi mơ hình người dung + người triển khai hệ thơng stoaj hình ảnh hệ thống Quy trình thiết kế giao diện người dung o bao gồm hoạt động khung riêng biêt:   • • + phân tích lập mơ hình người dungf, nhiệm vụ môi trường + thiết kế giao diện + xây dựng giao diện + xác thực giao diện Chương : Kiểm thử phầm mềm Mục tiêu kiểm thử o Kiểm thủ trình thực thi trương trình với mục đích tìm lỗi o kiểm thử thành công kiểm thử phát lỗi chưa phát trước Các thuộc tính kiểm thử tốt o Một kiểm thử tốt có xác suất tìm lỗi cao, tester phải hiểu hệ thống phát triển tranh tồn cảnh cách mà bị thấy bại Một kiểm thử tốt kiểm thử khơng dư thừa, kiểm thử nên có mục đích khác o Kiểm thử tốt phải giống tốt nhất, nên sử dụng kiểm thử có khả cao phát tòa lỗi o Một kiểm thử tốt không nên đơn giản cũn không nên phức tạp Nguyên lý kiểm thử phầm mềm kiểm thử phần mềm chứng minh diện lỗi : kiểm thử phầm mềm chứng minh sản phẩm có lỗi khơng thể chứng minh sản phẩm khơng lỗi kiểm thử tồn khơng khả thi: Rất khó để kiểm tra tồn modul tính năng, kết hợp với đầy vào đầu suất trình kiểm thử Kiểm thử sớm tốt: nguyên tắc cho ta thất cần phát triển bug từ bước nghiên cứu yêu cầu hay design Lỗi thường phân bố tập chung: nguyên lý phân bố lỗi rang, số modul chứa phần lớn số lỗi phát Nguyên Lý Pareto: 80-20: 80% lỗi tìm thấy 20% modul Nghịch lý thuốc trừ sâu: lặp lặp lại test case, xác xuất tìm lỗi thấp Kiểm thử phụ thuộc vào ngữ cảnh: tất phần mềm phát triển theo cách khác Cần sử dụng cách tiếp cận khác nhau, phương thức kỹ thuật test khác nhau, loại test phụ thuộc vào loại phần mềm/ ứng dụng/ website Quan niệm sau lầm việc hết lỗi Kỹ thuật kiểm thử phần mềm Kiểm thử hộp trắng: biết đupwjc hoạt động bên sản phẩm tiến hành kiểm thử để đảm bảo hoạt động bên thực theo đặc tả phần mềm, tất thành phần bên thực đầy đủ Kiểm thử hộp đen: biết chức cụ thể sản phẩm thiết kế để thực tiến hành kiểm thử để chứng minh chức hoạt động đầy đủ đồng thời tìm kiếm lỗi trức o o o o o o o • • •  Kiểm thử hộp trắng gọi kiểm thử hộp kính, sử dụng cấu trúc kiểm soát thủ tục để rút test case theo cách thức sau: o Đảm bảo rang all đường dẫn độc lập modul thực lần o Thực all quết định logic mặt sai chúng o Thực all vòng lặp danh giới chúng giới hạn hoạt động chúng o Thực cấu trúc liệu nội để đảm bảo tính hợp lệ chúng 29/03/2022  ĐƯỜNG DẪN ĐỘC LẬP • Kiểm thử theo đường dẫn sở cho phép người thiết kế test case lấy thước đo ĐỘ PHỨC TẠP LOGIC CỦA THIẾT KẾ THỦ TỤC sử dụng thước đo hướng dẫn để xác định tập hợp sở đường dẫn thực thi  Kiểm thử Black Box o Hay kiểm thử hộp đen tập chung vào yêu cầu trức phần mềm, cho phép kỹ sư phần mềm thu tập hợp đk đầu vào thực đầy đủ yêu cầu chức cho trương trình o Kiểm thử hộp đen cố gắng tìm lỗi cho danh mục sau • Các chức khơng xác or bị thiếu • Lỗi giao diện • Lỗi caus trức liệu truy cập sở liệu bên ngồi • Lỗi hành vi or lỗi hình thức • Lỗi khởi tạo or kết thúc • Phương phi kiểm thử dựa đồ thị o Bước hiểu đối tượng mơ hình hóa phần mềm mối quan hệ kết nối đối tượng o Bước xác định loạt thử nghiệm để xác minh tất các dối tượng có mối quan hệ mong đợi vs (1)=> tạo biểu đồ đối tượng quan trọng mối quan hệ chúng (2)=> đưa loạt kiểm thử bao phủ biểu đồ để đối tượng quan hệ thực lỗi phát  Phương pháp kiểm tra dựa đồ thị, o biểu đồ bao gồm nd sau: o Các nút biểu diễn cho đối tượng, liên kết biểu diễn mqh đối tượng o Trọng số nút mơ tả thuốc tính nút o Trọng số liên kết mô tả số đặc điểm liên kết  Chiến lược kiểm thử: o cung cấp sơ đồ lộ trình mơ tả bước tiến hành phần o o o o o o kiểm thử, bupwcs lập kế hoạch sau thự hiện, cần lỗ lực, thời gian nguồn lực, chiến lược kiểm thử phải kết hợp lập kế hoạch kiểm thử, thiết kết test case hay gọi trường hợp kiểm thử, thực kiểm thử, thu thập đánh giá liệu kết quả, Gồm khái niệm từ xuống từ lên Kiểm thử đơn vị tập trung vào đơn vị phần mềm, triển khai mã nguồn Kiểm thử tích hợp tập trung vào thiết kế xây dựng kiến trúc phần mềm Kiểm thử hợp lệ nơi yêu cầu thiets lập phần phân thích yêu cần phần mềm xác nhận đựa phần mềm xây dựng o Kiểm thử hệ thống phần mềm yếu tố hệ thống khác kiểm tra tổng thể Kiểm thử đơn vị • tập trng vào đơn vị nhỏ thiết kết phần mềm tức thành phần or modun phần mềm • hướng kiểm thử hộp trắng, bước tiến hành song song cho nhiều thành phần • giao diện modul kiểm tra để đảm bảo thông tin vào khỏi đơn vị chương trình kiểm tra cách xác • cấu trúc liệu cục kiểm tra để đảm bảo rang liệu lưu trữ tạm thời trì tính tồn vẹn all bước q trình thực thi thuật tốn • điều kiện biên kiểm tra để đảm bảo modul hoạt động danh giới thiết lập để giới hạn or hạn chế trình sử lý, tất đường dẫn độc lập hay đường dẫn sở thông qua cấu trúc điều khiển thực để đảm bảo tất câu lệnh modul thực thi lần • cuối tất đường dẫn sử lý lỗi kiểm tra  kiểm thử thích hợp • kỹ thuật có hệ thống để xây dựng cấu trúc trương trình, đồng thời tiến hành kiểm tra để phát lỗi có liên quan đến giao diện • mục tiêu lấy thành phần kiểm thử đơn vị xâu dựng cấu trúc trương trình nđã kiểm thử thiết kế • có cách tiếp cận từ xuống từ lên kiểm thử tích hợp từ xuống • cách tiếp cận gia tăng để xây dựng cấu trúc chương trình, • modul tích hợp cách di truyển xuống thông qua hệ thống phân cấp điều khiển, bắt đầu vs modul điều khiển trương trình main program Các modul cấp cấp cuối kết hợp vào cấu trúc điều khiển theo cách thức ưu tiên chiều sâu or chiều rộng kiểm thử tích hợp từ lên • bắt đầu xây dựng thử nghiệm với modul nguyên tử ví dụ thành phần mức thấp cấu trúc trương trình, thành phần tích hợp từ lên q trình sử lý bắt buộc đối vs thành phần mức định sẵn sàng nhu cầu sơ khai loại bỏ kiểm thử hợp lệ • xác nhận thành công chức phần mềm hoạt động theo mà khác hang mong đợi, loại kiểm thử tập trung thẩm định yêu cầu xác định cho phần mềm • kieemr thử anpha thực địa nhà phát triển khách hangf Phần mềm thực bối cảnh tự nhiên với việc nhà phát triển nhìn qua vai người dung ghi lại lỗi cố sử dụng o     • kiểm thử beta tiến hành or nhiều địa điểm khách hang người dung cuối phần mềm, nhà phát triển thường k có mặt thử nghiệm beta ứng dụng sống mơi trường mà nhà phát triển khơng thể kiểm sốt Khách hang ghi lại all vấn đề gặp phải thử nghiệm beta bào cáo vấn đề cho nhà phát triển theo định kì  kiểm thử hệ thống • kiểm thử phục hội buộc phần mềm bị lỗi theo nhiều cách khác xác minh rangwf q trình khơi phục thực cách • kiểm thử an tồn cố gắng phát minh chế bảo vệ tích hợp hệ thống, thực tế bảo khỏi sâm nhập khơng cách  kiểm thử gay cấn: thực hệ thống theo cách yêu cầu tài ngyên với số lượng, tần suất or khối lượng bất thường  kiểm thử hiệu năng: thiết kế để kiểm tra hiệu suất chyaj phần mềm bối cảnh hệ thống tích hợp  kiểm tra hiệu suất xảy xuyên xuất trình kiểm thử ... phần mềm tức áp dụng kiến thức công nghệ vào phần mềm Why se? • Mục đích o Để tăng suất chất lượng phần mềm o Để kiểm sốt hiệu lịch trình kế hoạch phần mềm o Để giảm chi phí phát triển phần mềm. .. phần mềm o Để cải tiến thực hành kỹ thuật phần mềm o Để hỗ trợ hoạt động kỹ sư cách có hệ thống hiệu Cơng nghệ phần mềm bao gồm • Cơng nghệ phần mềm bao gồm nhiều lớp khác nhau: o Công cụ  Công. .. cầu phần mềm o Phân tích yêu cầu cho phép kỹ sư phần mềm tinh chỉnh phân bố phần mềm xây dựng mơ hình miền liệu, chức hành vi xử lý phần mềm o Phân tích yêu cầu cung cấp cho nhà thiết kế phần mềm