Giáo trình Công nghệ phần mềm - Trình độ: Cao đẳng, Trung cấp - Trường Cao đẳng cơ giới Ninh Bình

Nội dung text: Giáo trình Công nghệ phần mềm - Trình độ: Cao đẳng, Trung cấp - Trường Cao đẳng cơ giới Ninh Bình

1. BỘ NÔNG NGHIỆP VÀ PHÁT TRIỂN NÔNG THÔN TRƯỜNG CAO ĐẲNG CƠ GIỚI NINH BÌNH GIÁO TRÌNH MÔN HỌC: CÔNG NGHỆ PHẦN MỀM NGHỀ: LẬP TRÌNH MÁY TÍNH TRÌNH ĐỘ: CAO ĐẲNG / TRUNG CẤP Ban hành kèm theo Quyết định số: /QĐ- ngày .tháng .năm 2018 của Trường Cao đẳng Cơ giới Ninh Bình Ninh Bình, năm 2018
2. TUYÊN BỐ BẢN QUYỀN Tài liệu này thuộc loại sách giáo trình nên các nguồn thông tin có thể được phép dùng nguyên bản hoặc trích dùng cho các mục đích về đào tạo và tham khảo. Mọi mục đích khác mang tính lệch lạc hoặc sử dụng với mục đích kinh doanh thiếu lành mạnh sẽ bị nghiêm cấm.
3. LỜI GIỚI THIỆU Trong hệ thống kiến thức chuyên ngành trang bị cho sinh viên nghề Lập trình máy tính, môn học góp phần cung cấp những nội dung liên quan đến việc xây dựng các ứng dụng về phân tích xây dựng phần mềm ứng dụng. Các nội dung chính được trình bày trong tài liệu này gồm các bài: - Đặc trưng của phần mềm - Vai trò của phần mềm - Các yếu tố cơ bản của kỹ nghệ phần mềm - Vai trò của người phân tích yêu cầu - Xem xét phần mềm - Một số vấn đề thiết kế Mặc dù có rất nhiều cố gắng, nhưng không tránh khỏi những khiếm khuyết, rất mong nhận được sự đóng góp ý kiến của độc giả để giáo trình được hoàn thiện hơn. Ninh Bình, ngày .tháng . năm 2018 Tham gia biên soạn 1. Chủ biên – Th.S Nguyễn Anh Văn 2. Th.S Nguyễn Trung Cương 3. Th.S Nguyễn Xuân Khôi
4. MỤC LỤC Giáo trình 1 Lời giới thiệu 2 Bài 1. Phần mềm và kỹ nghệ phần mềm 7 1.1. Một số khái niệm chung 7 1.2. Nhân 9 1.3. Phương pháp phát triển phần mềm 13 Bài 2. Tiến trình phần mềm 16 2.1. Tiêu chuẩn của sản phẩm phần mềm 16 2.2. Quản lý dự án phần mềm 19 2.3. Lập kế hoạch dự án 20 2.4. Phương pháp luận 23 Bài 3. Phân tích đặc tả yêu cầu 25 3.1. Tìm hiểu, xác định yêu cầu 25 3.2. Phân tích yêu cầu 28 3.3. Đặc tả yêu cầu 30 3.4. Tư liệu hóa yêu cầu phần mềm 35 3.5. Đặc tính dữ liệu và các kỹ thuật để thu thập dữ liệu 37 Bài 4. Lập trình hiệu quả 42 4.1. Đặc điểm của quá trình thiết kế phần mềm 42 4.2. Các hoạt động của quá trình thiết kế phần mềm 44 4.3. Nền tảng thiết kế 45 Bài 5. Kiểm thử và bảo trì phần mềm 51 5.1. Độ tin cậy của phần mềm 51 5.2. Kiểm tra và các chiến lược kiểm tra phần mềm 59 5.3. Kỹ thuật kiểm thử phần mềm và đặc điểm 67 5.4. Chứng minh toán học tính đúng đắn của chương trình 72
5. CHƯƠNG TRÌNH MÔ ĐUN CÔNG NGHỆ PHẦN MỀM Mã số môm học: Mh 25 Thời gian môm học: 60 h; (Lý thuyết: 36 h; Thực hành: 24 h) I. VỊ TRÍ, TÍNH CHẤT CỦA MÔ ĐUN - Môn học này được học sau khi học xong các môn học lập trình và các hệ quản trị cơ sở dữ liệu. - Để học tốt mô đun này cần học qua các môn học Tin học căn bản, Lập trình căn bản, cơ sở toán cho tin học, cấu trúc dữ liệu và giải thuật, lập trình hướng đối tượng. II. MỤC TIÊU MÔ ĐUN Học xong mô đun này sinh viên có khả năng: - Trình bày được các khái niệm cơ bản về công nghệ phần mềm: Phần mềm, công nghệ phần mềm, quy trình làm phần mềm. - Thực hiện được mô hình làm phần mềm: phù hợp cho yêu cầu của hệ thống cụ thể; - Trình bày được các yêu cầu của phần mềm, xác định phạm vi, hạn chế của phần mềm; - Trình bày được sản phẩm và hướng dẫn sử dụng phần mềm; - Có thái độ nghiêm túc và tích cực trong học tập đảm bảo an toàn cho người và thiết bị. III. NỘI DUNG MÔ ĐUN 1. Nội dung tổng quát và phân phối thời gian: Số Tên các bài trong mô đun Tổng Lý Thực TT Kiểm tra* số thuyết hành 1 Phần mềm và kỹ nghệ phần mềm 5 5 2 Tiến trình phần mềm 10 6 4 3 Phân tích đặc tả yêu cầu 11 5 4 2
6. 4 Lập trình hiệu quả 9 5 4 5 Kiểm thử và bảo trì phần mềm 25 11 12 2 Cộng: 60 36 20 4 *Ghi chú: Thời gian kiểm tra được tích hợp giữa lý thuyết với thực hành được tính vào giờ thực hành IV. ĐIỀU KIỆN THỰC HIỆN MÔ ĐUN Sinh viên cần học trước các môn học: - Cơ sở toán cho tin học. - Lập trình căn bản. - Cấu trúc dữ liệu và giải thuật. - Hệ quản trị cơ sở dữ liệu. - Lập trình hướng đối tượng. * Vật liệu: - Xưởng thực hành đạt chuẩn. - Các mô hình trên giấy in hoặc trên power point. * Dụng cụ: - Máy tính, máy chiếu. - Bài giảng soạn trên phần mềm dạy học.
7. Bài 1. PHẦN MỀM VÀ KỸ NGHỆ PHẦN MỀM A. MỤC TIÊU CỦA BÀI - Hiểu được định nghĩa công nghệ phần mềm -Software Engineering;. - Sử dụng được phương pháp, công cụ, cách tiếp cận và phương tiện phục vụ cho việc thiết kế và cài đặt các sản phẩm phần mềm; B. NỘI DUNG 1.1. Một số khái niệm chung Mục tiêu của công nghệ phần mềm là tạo ra những phần mềm tốt, giảm đến tối thiểu những may rủi có thể gây cho các người liên quan. Trong quá trình đề cập, chúng ta sử dụng các thuật ngữ: Phần mềm (software): là một tập hợp các câu lệnh được viết bằng một hoặc nhiều ngôn ngữ lập trình, nhằm tự động thực hiện một số các chức năng giải quyết một bài toán nào đó. Công nghệ (engineering): là cách sử dụng các công cụ, các kỹ thuật trong cách giải quyết một vấn đề nào đó. Công nghệ phần mềm (software engineering): là việc áp dụng các công cụ, các kỹ thuật một cách hệ thống trong việc phát triển các ứng dụng dựa trên máy tính. Đó chính là việc áp dụng các quan điểm, các tiến trình có kỷ luật và lượng hoá được, có bài bản và hệ thống để phát triển, vận hành và bảo trì phần mềm. Theo quan điểm của nhiều nhà nghiên cứu, có thể nhìn công nghệ phần mềm là một mô hình được phân theo ba tầng mà tất cả các tầng này đều nhằm tới mục tiêu chất lượng, chi phí, thời hạn phát triển phần mềm. Mô hình được phân theo ba tầng của công nghệ phần mềm được mô tả như sau: Công cụ Phương pháp Quy trình
8. Ở đây tầng quy trình (process) liên quan tới vấn đề quản trị phát triển phần mềm như lập kế hoạch, quản trị chất lượng, tiến độ, chi phí, mua bán sản phẩm phụ, cấu hình phần mềm, quản trị sự thay đổi, quản trị nhân sự (trong môi trường làm việc nhóm), việc chuyển giao, đào tạo, tài liệu; Tầng phương pháp (methods) hay cách thức, công nghệ, kỹ thuật để làm phần mềm: liên quan đến tất cả các công đoạn phát triển hệ thống như nghiên cứu yêu cầu, thiết kế, lập trình, kiểm thử và bảo trì. Phương pháp dựa trên những nguyên lý cơ bản nhất cho tất cả các lĩnh vực công nghệ kể cả các hoạt động mô hình hoá và kỹ thuật mô tả. Tầng công cụ (tools) liên quan đến việc cung cấp các phương tiện hỗ trợ tự động hay bán tự động cho các tầng quá trình và phương pháp (công nghệ). Qua sơ đồ trên, ta thấy rõ công nghệ phần mềm là một khái niệm đề cập không chỉ tới các công nghệ và công cụ phần mềm mà còn tới cả cách thức phối hợp công nghệ, phương pháp và công cụ theo các quy trình nghiêm ngặt để làm ra sản phẩm có chất lượng. Kỹ sư phần mềm (software engineer): là một người biết cách áp dụng rộng rãi những kiến thức về cách phát triển ứng dụng vào việc tổ chức phát triển một cách có hệ thống các ứng dụng. Công việc của người kỹ sư phần mềm là: đánh giá, lựa chọn, sử dụng những cách tiếp cận có tính hệ thống, chuyên biệt, rõ ràng trong việc phát triển, đưa vào ứng dụng, bảo trì, và thay thế phần mềm. Do đặc điểm nghề nghiệp, người kỹ sư phần mềm phải có những kỹ năng cơ bản như: Định danh, đánh giá, cài đặt, lựa chọn một phương pháp luận thích hợp và các công cụ CASE. Biết cách sử dụng các mẫu phần mềm (prototyping). Biết cách lựa chọn ngôn ngữ, phần cứng, phần mềm. Quản lý cấu hình, lập sơ đồ và kiểm soát việc phát triển của các tiến trình. Lựa chọn ngôn ngữ máy tính và phát triển chương trình máy tính. Đánh giá và quyết định khi nào loại bỏ và nâng cấp các ứng dụng.
9. Mục tiêu của kỹ sư phần mềm là sản xuất ra các sản phẩm có chất lượng cao và phù hợp với các quy trình phát triển chuẩn mực. Việc phát triển (development): được bắt đầu từ khi quyết định phát triển sản phẩm phần mềm và kết thúc khi sản phẩm phần mềm được chuyển giao cho người sử dụng. Việc sử dụng (operations): là việc xử lý, vận hành hằng ngày sản phẩm phần mềm Việc bảo trì (maintenance): thực hiện những thay đổi mang tính logic đối với hệ thống và chương trình để chữa những lỗi cố định, cung cấp những thay đổi về công việc, hoặc làm cho phần mềm được hiệu quả hơn. Việc loại bỏ (retirement): thường là việc thay thế các ứng dụng hiện thời bởi các ứng dụng mới. 1.2. Nhân 1.2.1. Nhân tố con người trong ngành công nghiệp phần mềm Đối với một sản phẩn phần mềm, một người không thể hoàn thành mà là kết quả lao động của một nhóm người-ta gọi là nhóm phát triển phần mềm. Mỗi thành viên trong nhóm không được vị kỷ, thành quả lao động của nhóm được xen như là thành quả chung và phải tuyệt đối trung thành với nhóm. Như vậy, một nhóm phát triển phần mềm như thế nào gọi là một nhóm hợp lý? Sau đây là một vài yếu tố cần xem xét: Nhóm có bao nhiêu thành viên, Nhóm được tổ chức như thế nào, Tình hình thực tế của mỗi thành viên trong nhóm, Môi trường, điều kiện mà nhóm đang làm việc, Mỗi thành viên trong nhóm phải có một số kiến thức cần thiết tuỳ thuộc vào vai trò trong nhóm để phát triển phần mềm. 1.2.2. Phân loại nghề nghiệp Yêu cầu hiện nay của sự phát triển Công nghệ Thông tin (CNTT) ở Việt nam đòi hỏi cần có những người lao động trong tất cả các ngành kinh tế biết sử dụng hữu hiệu CNTT trong công việc của mình, và đồng thời cần có những
10. người trực tiếp tham gia vào sản xuất, kinh doanh, vận hành về CNTT. Do vậy cần có những lớp người lao động sau: Những người biết vận dụng sáng tạo CNTT vào nghiệp vụ chuyên môn. Những người tham gia quản lí và vận hành các hệ thống CNTT Những người tham gia trực tiếp vào việc phát triển và xây dựng ra các sản phẩm CNTT, Việc phân loại nghề nghiệp trong các hệ thống thông tin có thể được phân chia dựa vào các tiêu chuẩn như: mức độ kinh nghiệm, loại hình công việc, Loại hình công việc Ở đây, các loại hình công việc được bàn luận đến dựa vào cách phân loại gồm: phát triển ứng dụng, hỗ trợ ứng dụng, chuyên ngành kỹ thuật, nhân viên và những vấn đề khác. Phát triển ứng dụng Lập trình viên: Các lập trình viên chuyển đổi những đồ án chi tiết kỹ thuật sang các module mã và tự kiểm tra các đơn vị. Các lập trình viên có thể luân phiên chịu trách nhiệm giữa phát triển ứng dụng và bảo trì. Những chuyên gia lập trình ở trình độ đại học thực hiện những nhiệm vụ bên ngoài việc lập trình. Kỹ sư phần mềm: Một kỹ sư phần mềm thực hiện những chức năng của các nhà phân tích, các nhà thiết kế và các lập trình viên. Các phân tích gia ở trình độ đại học luôn luôn tham gia vào tổ chức có cấp độ IS để lập kế hoạch và nghiên cứu khả thi. Các kỹ sư phần mềm có thể làm cả ba việc – phân tích, thiết kế và lập trình cũng như đứng ra lãnh đạo dự án hoặc quản lý dự án. Một kỹ sư quản lý phần mềm sơ cấp thường dành nhiều thời gian lập trình trong khi một kỹ sư có trình độ cao cấp lại tập trung vào việc lập kế hoạch, nghiên cứu khả thi, phân tích và thiết kế. Kỹ sư tri thức (KE): Các kỹ sư tri thức suy luận ra những mô hình ngữ nghĩa từ các chuyên gia để từ đó xây dựng những hệ chuyên gia và trí tuệ nhân tạo. Các kỹ sư tri thức tương tự như các kỹ sư phần mềm nhưng được chuyên môn hoá các kỹ năng để áp dụng vào các vấn đề trí tuệ nhân tạo. Việc phát triển các mô hình và các chương trình của cấu trúc trí tuệ đòi hỏi khả năng quan sát,
11. kỹ năng phỏng vấn sâu sắc, khả năng trừu tượng hoá những vấn đề không phải của chuyên môn cá nhân để tạo ra những ý thức lập luận và thông tin cần thiết và khả năng phát triển những dự đoán về thông tin và tính chính xác với các chuyên gia. Hỗ trợ ứng dụng Chuyên gia ứng dụng: Chuyên gia ứng dụng có những vùng vấn đề được chuyên môn hoá cho phép họ tham khảo ý kiến của các đội dự án về một loại ứng dụng cụ thể. Ví dụ một nhà phân tích cao cấp về chuyển tiền thời gian thực có thể phân chia được thời gian giữa các dự án chuyển tiền trong nước và quốc tế, biết trước được những quy tắc, luật lệ phải tuân theo của ngân hàng dự trữ liên bang cũng như của các tổ chức chuyển tiền khác. Quản trị dữ liệu: Người quản lý dữ liệu quản lý thông tin như một nguồn thống nhất. Với chức năng này, bộ phận quản lý dữ liệu giúp cho người sử dụng xác định được tất cả dữ liệu được sử dụng, các dữ liệu có ý nghĩa trong quá trình thực hiện chức năng của công ty. Những người quản lý dữ liệu thiết lập và bảo lưu những chuẩn mực để thống nhất dữ liệu. Khi dữ liệu đã được xác định, người quản lý dữ liệu sẽ làm việc để định dạng và xác định cấu trúc cơ sở dữ liệu để sử dụng với ứng dụng. Với việc phát triển ứng dụng mới, những người quản lý dữ liệu làm việc với bộ phận phát triển ứng dụng để định vị những số liệu đã được tự động và với bộ phận quản trị CSDL để cung cấp những nhóm ứng dụng dễ dàng truy nhập những cơ sở dữ liệu đã được tự động hoá. Quản trị cơ sở dữ liệu (DBA): Những người quản lý cơ sở dữ liệu quản lý môi trường dữ liệu vật lý của một tổ chức. DBA phân tích, thiết kế, xây dựng và bảo lưu cơ sở dữ liệu cũng như môi trường phần mềm cơ sở dữ liệu. Làm việc cùng với những người quản lý dữ liệu xác định dữ liệu. DBA xác định các cơ sở dữ liệu vật lý và nạp thông tin thực tế vào chúng. Một người quản lý cơ sở dữ liệu làm việc với các nhóm phát triển ứng dụng để cung cấp truy nhập đến dữ liệu tự động và để định nghĩa rõ ràng cơ sở dữ liệu cần thiết cho thông tin được tự động.
12. Kỹ sư trí tuệ nhân tạo: Các kỹ sư trí tuệ nhân tạo làm việc như cố vấn giúp các đội dự án xác định, thiết kế và cài đặt trí tuệ vào các ứng dụng. Kỹ sư trí tuệ nhân tạo cùng với các kỹ sư tri thức dịch và kiểm tra những vấn đề miền dữ liệu và thông tin lập luận bằng một ngôn ngữ của trí tuệ nhân tạo. Các kỹ sư trí tuệ nhân tạo đạt được trình độ chuyên môn cao hơn các kỹ sư tri thức. Nhà tư vấn: Người tư vấn thì biết mọi vấn đề và thực hành được tất cả. Số năm kinh nghiệm càng cao thì kiến thức có được càng nhiều. Lĩnh vực chuyên môn có thể bao gồm một vài loại công việc được đề cập đến trong phần này. Người tư vấn được nhờ đến trong hầu hết các trường hợp lắp đặt hệ thống và cung cấp những kỹ năng bên ngoài không sẵn có. Bởi vậy họ thường đào tạo đội ngũ bên trong trong suốt quá trình thực hiện công việc. Khi được nhờ đến, người tư vấn được mong chờ có những kỹ năng chuyên biệt và sẽ áp dụng những kỹ năng này trong việc thực hiện tư vấn. Chuyên ngành kỹ thuật Nhà phân tích và kỹ sư truyền thông: Các nhà phân tích và kỹ sư truyền thông phân tích, thiết kế, đàm phán và/ hoặc cài đặt các thiết bị và phần mềm truyền thông. Họ đòi hỏi liên quan chặt chẽ tới kỹ thuật truyền thông và có thể làm việc trên mainframe hoặc các mạng truyền thông dựa vào PC. Để bắt đầu ở mức xuất phát thì nền tảng kiến thức phải có là điện tử, kỹ thuật, các ứng dụng, khoa học máy tính và truyền thông. Chuyên gia về mạng cục bộ: Các chuyên gia mạng cục bộ đặt kế hoạch, lắp đặt, quản lý và duy trì những khả năng của mạng cục bộ. Điểm khác nhau duy nhất giữa các chuyên gia mạng cục bộ và các chuyên gia truyền thông là phạm vi. Các chuyên gia truyền thông làm việc với nhiều mạng kể cả mainframe; còn chuyên gia mạng cục bộ chỉ làm việc trên những mạng có giới hạn về mặt địa lý và được cấu thành bởi nhiều máy tính cá nhân. Những người quản lý mạng cục bộ là vị trí đầu tiên trong nhiều công ty. Một người quản lý mạng cục bộ tạo ra người sử dụng mới, thực hiện hoặc thay đổi mức hoặc mã bảo mật, cài đặt những version mới của phần mềm điều hành mạng cục bộ, cài đặt những version mới của cơ sở dữ liệu hoặc phần mềm cơ sở
13. mạng cục bộ khác. Giám sát tài nguyên cung cấp qua mạng cục bộ, cung cấp bản sao và khả năng phục hồi cho mạng cục bộ, và quản lý cấu hình mạng cục bộ. Lập trình viên hệ thống: Các lập trình viên hệ thống cài đặt và bảo dưỡng hệ điều hành và ứng dụng hỗ trợ phần mềm. Định giá những đặc điểm mới và xem xét chúng có cần thiết ở một thời điểm nào đó không là một kỹ năng mà lập trình viên hệ thống cần phát triển. Giám sát hàng trăm ứng dụng để xem xét những rắc rối của nó có liên quan đến vấn đề của hệ thống hay không là một nhiệm vụ quan trọng. Chuyên gia hỗ trợ phần mềm (SSP): Hỗ trợ phần mềm ứng dụng tương tự nhưng khác với lập trình viên hệ thống. SSP cài đặt và bảo dưỡng gói phần mềm sử dụng bởi cả các nhà phát triển ứng dụng và người sử dụng. Chúng có thể là cơ sở dữ liệu, ngôn ngữ hỏi đáp, sao lưu và phục hồi, bảng tính, quản lý khoảng trống đĩa, giao diện, truyền thông. 1.3. Phương pháp phát triển phần mềm Khác với thời kỳ đầu của tin học, các chương trình phụ thuộc nhiều vào thiết bị và người ta chỉ quan tâm đến các "mẹo vặt" lập trình, thì ngày nay người ta quan tâm đến nguyên lý và phương pháp để phát triển phần mềm. Các nguyên lý và phương pháp được đề xuất nhằm nâng cao năng suất lao động cho nhóm phát triển phần mềm. Năng suất ở đây bao gồm tính đúng đắn của sản phẩm, tính dễ đọc, dễ sửa đổi, dễ thực hiện, tận dụng được tối đa khả năng của thiết bị mà vẫn không bị phụ thuộc vào thiết bị. Có nhiều phương pháp được đề cập như: phương pháp hướng chức năng, phương pháp hướng đối tượng, phương pháp ngữ nghĩa, Và thậm chí là không phương pháp để phát triển phần mềm. Bên cạnh các phương pháp để chỉ định cho việc tạo một bản phân tích và thiết kế, người ta còn chú ý đến phương pháp làm thế nào để đưa người dùng tham gia vào quy trình gọi là phương pháp luận xã hội. Vai trò của người dùng trong giai đoạn phát triển phần mềm
14. Trong những ứng dụng trước kia được xây dựng thường xuyên không có sự bàn bạc với người sử dụng, sự cô lập của các công nghệ phần mềm đối với người dùng dẫn đến những hệ thống có khả năng làm việc về mặt kỹ thuật, nhưng thông thường không đáp ứng được nhu cầu của người sử dụng, và thường xuyên làm gián đoạn quá trình làm việc. Để có sự tham gia của người sử dụng trong quá trình phát triển ứng dụng, phương thức này đòi hỏi những cuộc họp ngoài lề của tất cả những người sử dụng có liên quan và những người trong hệ thống - thường những người gặp nhau trong từ 5 đến 10 ngày để phát triển một mô tả chức năng chi tiết của những yêu cầu ứng dụng. Các cuộc họp ban ngày được sử dụng về những phân tích mới, những cuộc họp ban đêm lập tài liệu về những kết quả ban ngày để xem xét lại và tiếp tục chắt lọc trong ngày tiếp theo. Có rất nhiều lợi ích từ việc tham gia của người sử dụng trong phát triển ứng dụng. Trước tiên nó xây dựng sự cam kết của những người sử dụng - những người đương nhiên đảm nhiệm quyền sở hữu của hệ thống. Thứ hai, những người sử dụng là những chuyên gia thực sự của những công việc đang được tự động - lại được đại diện hoàn toàn thông qua sự phát triển. Thứ ba, những nhiệm vụ được người sử dụng thực hiện bao gồm việc thiết kế màn hình, các mẫu, các báo cáo, sự phát triển tài liệu của người sử dụng, sự phát triển và tiến hành của các cuộc kiểm tra công nhận, Sự tham gia của người sử dụng không chỉ là ước muốn mà còn là một mệnh lệnh đối với tiến trình và sản phẩm phát triển ứng dụng hoàn toàn hiệu quả. Khía cạnh quan trọng nhất của sự tham gia của người sử dụng là nó phải có ý nghĩa. Người sử dụng phải là những người quyết định và là những người mong muốn tham gia vào quá trình phát triển. Sử dụng đội ngũ nhân viên ở cấp thấp hoặc chỉ định các nhà quản lý mở rộng không phải là cách để kéo người sử dụng vào các ứng dụng phát triển.
15. Mục tiêu của việc tham gia của người sử dụng là cho những người phát triển hệ thống và không phát triển hệ thống làm việc cùng với nhau như những đối tác chứ không phải như những kẻ thù. Khi những người sử dụng tham gia thì họ sẽ tạo ra những quy định không mang tính kỹ thuật. Những kỹ sư phần mềm giải thích và hướng dẫn người sử dụng tạo ra những quy định nữa kỹ thuật, ví dụ như việc thiết kế màn hình, và giải thích cả những tác động và suy luận của các quy định kỹ thuật chính yếu. Việc tham gia của người sử dụng có nghĩa là người sử dụng sẽ điều khiển dự án, tạo nên phần lớn quy định và có tính quyết định cuối cùng đối với tất cả các quyết định lớn. Các kỹ sư phần mềm và các nhân viên của các hệ thống quản lý thông tin khác hoạt động như những kỹ thuật viên phục vụ, như là những chức năng của họ.
16. Bài 2. TIẾN TRÌNH PHẦN MỀM A. MỤC TIÊU CỦA BÀI - Mục tiêu của công nghệ phần mềm là sản xuất ra những phần mềm tốt, có chất lượng cao. Các nhân tố ảnh hưởng đến chất lượng phần mềm có thể được phân thành hai nhóm chính: các nhân tố có thể đo trực tiếp và các nhân tố chỉ có thể đo gián tiếp.;. - Tuỳ theo công dụng của sản phẩm và nhu cầu thực tế của người sử dụng, các chuẩn của quốc gia, quốc tế, nền văn minh của cộng đồng, thời điểm, mà các tiêu chuẩn để lượng hoá phần mềm có thể thay đổi; B. NỘI DUNG 2.1. Tiêu chuẩn của sản phẩm phần mềm Để đánh giá được sản phẩm của một nền công nghệ là tốt hay xấu, chúng ta phải nghiên cứu để đưa ra được những tiêu chuẩn đánh giá chúng. Chất lượng của sản phẩm phần mềm bao gồm nhiều yếu tố dựa trên các tiêu chuẩn đã được tổng kết. 2.1.1. Tính đúng Một sản phẩm thực hiện được gọi là đúng nếu nó thực hiện chính xác những chức năng đã đặc tả và thỏa mãn các mục đích công việc của khách hàng. Như vậy, một sản phẩm phải được so sánh chuẩn đặt ra để kiểm tra tính đúng và điều này dẫn đến có nhiều bậc thang về tính đúng. Liệt kê theo thang giảm dần, tính đúng của phần mềm có thể: + Tuyệt đối đúng, + Đúng , + Có lỗi, + Có nhiều lỗi, Ví dụ: Một hệ thống xử lý dữ liệu không chạy được khi file cơ sở dữ liệu rỗng hoặc có quá 104 bảng ghi, là những hệ thống vi phạm tính đúng. 2.1.2. Tính khoa học Tính khoa học của phần mềm được thể hiện qua các mặt
17. Khoa học về cấu trúc. Khoa học về nội dung. Khoa học về hình thức thao tác. 2.1.3. Tính tin cậy Tính tin cậy của sản phẩm phần mềm thể hiện ở sản phẩm được trông chờ thực hiện các chức năng dự kiến của nó với độ chính xác được yêu cầu. 2.1.4. Tính kiểm thử được Phần mềm có thể kiểm thử được là phần mềm mà nó có cách dễ dàng để có thể kiểm tra được. Đảm bảo rằng nó thực hiện đúng các chức năng dự định. 2.1.5. Tính hữu hiệu Tính hữu hiệu của phần mềm được xác định qua các tiêu chuẩn sau: Hiệu quả kinh tế hoặc ý nghĩa; giá trị thu được do áp dụng sản phẩm đó. Tốc độ xử lý sản phẩm. Giới hạn tối đa của sản phẩm hoặc miền xác định của chương trình được xác định qua khối lượng tối đa của các đối tượng mà sản phẩm đó quản lý. 2.1.6. Tính sáng tạo Một sản phẩm phần mềm có tính sáng tạo khi nó thảo mãn một trong các tính chất sau: Sản phẩm được thiết kế và cài đặt đầu tiên. Sản phẩm được phục vụ cho những đặc thù riêng. Sản phẩm có những đặc điểm khác về mặt nguyên lý so với các sản phẩm hiện hành. Sản phẩm có những ưu thế nổi bậc so với sản phẩm hiện hành. 2.1.7. Tính an toàn Tính an toàn của sản phẩm phần mềm được đánh giá thông qua: Có cơ chế bảo mật và bảo vệ các đối tượng do hệ thống phát sinh hoặc quản lý. Bản thân sản phẩm được đặt trong một cơ chế bảo mật nhằm chống sao chép trộm hoặc làm biến dạng sản phẩm đó. 2.1.8. Tính toàn vẹn Sản phẩm phần mềm có tính toàn vẹn khi nó:
18. Có cơ chế ngăn ngừa việc thâm nhập bất hợp pháp vào phần mềm hay dữ liệu và ngăn ngừa việc phát sinh ra những đối tượng (dữ liệu, đơn thể ) sai quy cách hoặc mâu thuẩn với các đối tượng sẳn có. Không gây ra nhập nhằng trong thao tác. Đảm bảo nhất quán về cú pháp. Có cơ chế phục hồi lại toàn bộ hoặc một phần những đối tượng thuộc toàn bộ hoặc một phần những đối tượng thuộc diện quản lý của sản phẩm trong trường hợp có sự cố như hỏng máy, mất điện đột ngột. 2.1.9. Tính đối xứng và đầy đủ chức năng Sản phẩm cung cấp đủ các chức năng cho người sử dụng và các chức năng của sản phẩm có các cặp loại trừ lẫn nhau, ví dụ các chức năng đối xứng thường gặp: + Tạo lập - Hủy bỏ, + Thêm - Bớt (xem - xóa), + Tăng - Giảm, + Dịch chuyển lên - xuống; phải - trái, + Quay xuôi - ngược chiều kim đồng hồ, 2.1.10. Tính tiêu chuẩn và tính chuẩn Sản phẩm phần mềm cần đạt được một số tiêu chuẩn tối thiểu được thừa nhận trong thị trường hoặc trong khoa học, và có thể chuyển đổi dạng cấu trúc dữ liệu riêng của hệ thống sang chuẩn và ngược lại. Tính chuẩn của phần mềm thể hiện ở sản phẩm đó phù hợp với các chuẩn quốc gia hoặc quốc tế. Trong khi xây dựng phần mềm, cần tuân theo nguyên tắc chuẩn hoá sau: + Chỉ thiết kế và xây dựng phần mềm sau khi đã xác định được chuẩn. + Mọi thành phần của phần mềm phải được thiết kế và cài đặt theo cùng một chuẩn (tối tiểu thì các chuẩn phải tương thích nhau). 2.1.11. Tính độc lập Phần mềm cần và nên đảm bảo được tính độc lập với các đối tượng sau: độc lập với thiết bị, độc lập với cấu trúc của đối tượng mà sản phẩm đó quản lý,
19. độc lập với nội dung của đối tượng mà sản phẩm đó quản lý. Tính dễ phát triển, hoàn thiện Thể hiện ở phần mềm có thể mở rộng cho các phương án khác hoặc mở rộng, tăng cường về mặt chức năng một cách rõ ràng. 2.2. Quản lý dự án phần mềm Các hoạt động chuẩn bị dự án Lựa chọn phương án để phát triển hệ thống là một quyết định hệ trọng. Sơ đồ lựa chọn phương án cho một dự án phần mềm được trình bày như sau: Tham biến hệ thống được cấp phát Cách tiếp cận khác Phương án Phương án Phương án Phương án 1 2 3 n Đánh giá các phương án + Chọn tiêu chuẩn đánh giá: hiệu năng, hiệu quả, chi phí vòng đời + Áp dụng các công nghệ phân tích + Sinh dữ liệu + Kết quả đánh giá + Phân tích nhạy cảm + Xác định rủi ro và không chắc chắn Chọn Cách tiếp cận được chọn phương án khác Không Cách tiếp cận có Có khả thi không Định nghĩa và tổng hợp hệ thống
20. Trước khi lập kế hoạch dự án, cần phải thiết lập các mục tiêu và phạm vi của dự án. Người quản trị dự án và kỹ sư phần mềm lên kế hoạch điều khiển dự án, đăng ký đội ngũ nhân viên làm nhiệm vụ sau đó tiến hành lựa chọn giải pháp, phương án. Nếu không có những thông tin này thì không thể xác định được những ước lược hợp lý và chính xác về chi phí, không thể tiến hành chia nhỏ các nhiệm vụ thực tế và không thể xác định được thời gian biểu cho dự án. Khi các mục tiêu và phạm vi đã được hiểu rõ thì xem xét tới các giải pháp khác, những ràng buộc khác như: hạn giao hàng, khả năng nhân sự, ràng buộc ngân sách, giao diện kỹ thuật, để lựa chọn phương án phát triển hệ thống. 2.3. Lập kế hoạch dự án Người quản trị dự án và kỹ sư phần mềm xác định nhân tố con người, máy tính và các tài nguyên tổ chức yêu cầu để phát triển ứng dụng. Kế hoạch dự án chính là sơ đồ các nhiệm vụ, thời gian và các mối quan hệ giữa chúng. Việc lên kế hoạch, nói chung, thường gồm các bước sau: + Liệt kê các nhiệm vụ: gồm các nhiệm vụ phát triển ứng dụng, các nhiệm vụ đặc trưng của dự án, các nhiệm vụ về tổ chức giao diện, sự xem xét lại và các việc phê chuẩn. + Định danh phụ thuộc giữa các công việc. + Xác định nhân viên dựa vào kỹ năng và kinh nghiệm. + Ấn định thời gian hoàn thành cho mỗi công việc bằng các tính toán thời gian hợp lý nhất cho mỗi công việc. + Định danh hướng đi tới hạn. + Xem xét lại các tài liệu theo khía cạnh đầy đủ, nội dung, độ tin cậy và độ chắc chắn. + Thương lượng, thỏa thuận và cam kết ngày bắt đầu và kết thúc công việc. + Xác định các giao diện giữa các ứng dụng cần thiết, đặt kế hoạch cho việc thiết kế giao diện chi tiết. 2.3.1. Các nhiệm vụ trong lập kế hoạch dự án thường bao gồm:
21. Do tất cả các tài liệu, kế họach và công việc của nhóm là phụ thuộc vào người sử dụng, do vậy tổ chức này bao gồm người quản lý, người sử dụng, kiểm toán, phải đưa các kiến thức chuyên ngành của mình vào những tài liệu ứng dụng một cách thích hợp. Cần đạt được sự đồng ý, cam kết từ các ngành, phòng ban bên ngoài trong quá trình cung cấp tài liệu. Bên cạnh đó, bộ phận đảm bảo chất lượng phải xem xét để tìm ra các sai sót và không đồng nhất của tài liệu và tất cả các hoạt động này đều phải đạt kế hoạch. 2.3.2. Xác định các đòi hỏi về giao diện ứng dụng. Đánh giá khối lượng công việc. Thời gian cho mỗi công việc phụ thuộc vào tính phức tạp và mục tiêu của nó - có ba loại thời gian cần tính đến: thời gian bi quan (P), thời gian thực tế (R), thời gian lạc quan (O). Thời gian lịch trình được tính = (O+2R+P)/4 Vấn đề tiếp theo là xác định kỹ năng và kinh nghiệm cần có của người thi hành nhiệm vụ để xác định dùng bao nhiêu người và có kỹ năng gì cho dự án. Sau đó xác định lịch trình làm việc và người quản trị dự án xác định ngân sách. Ở đây cần có sự trao đổi để hạn chế các trục trặc có thể xảy ra. Sau khi hoàn tất, kế hoạch, lịch trình và dự toán ngân sách được đưa cho người sử dụng và người quản lý hệ thống để bổ sung hoặc thông qua. Chú ý rằng bản kế hoạch không nên đóng cứng, nó có thể thay đổi khi công đoạn nào đó có sự cố xảy ra hoặc thời hạn tỏ ra không phù hợp hay có những thay đổi quan trọng trong mục tiêu của dự án. 2.3.3. Lựa chọn giải pháp Mọi ứng dụng đều phải có chiến lược cài đặt, môi trường cài đặt và phương pháp luận. Người quản trị dự án và kỹ sư phần mềm phải lựa chọn giải pháp tốt nhất cho hệ thống. Đây là việc lựa chọn giữa lập trình theo lô, trực tuyến, thời gian thực hay trộn lẫn giữa chúng. Việc quyết định lựa chọn phương pháp nào dựa trên sự phối hợp các yêu cầu của người sử dụng về sự chính xác của dữ liệu, dung lượng giao dịch mỗi ngày, số người làm việc trong ứng dụng vào mỗi thời điểm. Tất cả các
22. số liệu này được đánh giá trong giai đoạn lập kế hoạch của ứng dụng, và có thể thay đổi. Để ý rằng việc quyết định chiến lược cũng có thể thay đổi và sau đây là bảng tham khảo lựa chọn chiến lược dựa vào thời gian dữ liệu lưu hành (tính trên đơn vị giờ) và dung lượng giao dịch (tính trên đơn vị phút). Thời gian lưu hành 60 lần/phút - N N Y N N Y Lựa chọn ứng dụng ứng dụng theo lô X X ứng dụng trực tuyến X X X X X ứng dụng thời gian thực X X X X 3.3.4. Môi trường cài đặt Môi trường cài đặt bao gồm phần cứng, ngôn ngữ, phần mềm và các công cụ trợ giúp máy tính được sử dụng khi phát triển và triển khai ứng dụng. Quyết định không kết thúc ở giai đoạn thực hiện và lập kế hoạch, mà có các lựa chọn và một quyết định có khả năng nhất được xác định. Các đường lối được giải quyết để xác định một quyết định cuối cùng. Thường quyết định dựa trên kinh
23. nghiệm của các quản trị viên dự án, kỹ sư hệ thống, và khả năng của các thành viên trong dự án. Nguyên tắc chỉ đạo khi lựa chọn môi trường cài đặt là phải xuất phát từ người sử dụng. Họ đã có các trang thiết bị mà họ muốn sử dụng hay chưa? Chúng được cấu hình như thế nào? Trang thiết bị có các phần mềm hay ứng dụng gì? Người sử dụng có khả năng thay đổi cấu hình để thích hợp với ứng dụng mới không? 2.4. Phương pháp luận Giải pháp cuối cùng được thử nghiệm quyết định là dùng phương pháp luận gì và quy trình sản xuất như thế nào? Người quản lý phải biết rằng không phải tất cả các dự án đều giống nhau, do đó cách triển khai các dự án cũng không thể giống nhau. Với giả thiết không có yêu cầu cài đặt đặc biệt nào cả, ứng dụng tự nó phải là nhân tố cơ bản để quyết định phương pháp luận. + Trong môi trường kinh doanh, các quy luật cơ bản để lựa chọn phương pháp luận nhằm đánh giá sự phức tạp của ứng dụng một cách tốt nhất, + Nếu sự phức tạp là trong thủ tục, một phương pháp hướng xử lý là tốt nhất, + Nếu sự phức tạp là trong liên kết dữ liệu, một phương pháp luận hướng dữ liệu là tốt nhất, + Nếu bài toán dễ dàng chia nhỏ ra thành một chuỗi các bài toán nhỏ, một phương pháp đối tượng sẽ là tốt nhất, + Nếu dự án là nhằm xử lý trí tuệ nhân tạo hoặc bao gồm suy diễn, một phương pháp luận ngữ nghĩa là tốt nhất, Vấn đề lựa chọn chu kỳ tồn tại cũng đòi hỏi một số quyết định về kiểu gì và có bao nhiêu người sử dụng. Các ứng dụng phức tạp với các yêu cầu được biết thường đi kèm theo một quy trình thác nước. Nếu một số tỷ lệ của ứng dụng - yêu cầu, phần mềm, ngôn ngữ - là mới và chưa được kiểm nghiệm, kiểu tạo mẫu sẽ được sử dụng. Kỹ thuật hướng đối tượng đảm bảo kiểu mẫu và lặp. Nếu vấn đề là duy nhất, một phần trong vấn đề trước đây chưa bao giờ được tự động hóa,
24. ngay cả một kiểu mẫu học để sử dụng hoặc một chu kỳ vòng sống sản phẩm kiểu lặp có thể được sử dụng.
25. Bài 3. PHÂN TÍCH ĐẶC TẢ YÊU CẦU A. MỤC TIÊU CỦA BÀI - Hiểu được quá trình xác định các chức năng và các ràng buộc của hệ thống gọi là tìm hiểu và xác định yêu cầu;. - xác định và phân tích yêu cầu là bước hình thành bài toán, do vậy các yêu cầu của bài toán cần phải được tìm hiểu và phân tích theo chiều rộng (ngang) và theo chiều sâu (dọc); B. NỘI DUNG 3.1. Tìm hiểu, xác định yêu cầu 3.1.1. Khảo sát, tìm hiểu yêu cầu Khi một công ty muốn ký một hợp đồng cho một dự án phát triển một phần mềm, công ty sẽ phát biểu các yêu cầu ở mức trừu tượng để không bắt buộc định nghĩa trước các giải pháp. Các yêu cầu phải được viết sao cho các nhà phát triển phần mềm có thể đưa ra các giải pháp khác nhau. Sau khi đã trúng thầu và ký hợp đồng, yêu cầu phải được làm rõ hơn để khách hàng có thể hiểu và đánh giá được phần mềm. Cả hai tài liệu nói trên đều gọi là tài liệu yêu cầu người dùng. Theo mức độ chi tiết có thể chia ra các loại tài liệu yêu cầu: + Xác định yêu cầu: đây là một khẳng định, bằng ngôn ngữ tự nhiên hơn là các sơ đồ, về các dịch vụ hệ thống cần cung cấp và các ràng buộc mà hệ thống phải tuân theo. Tài liệu này cung cấp cho các thành phần: người quản lý của bên khách hàng, người dùng cuối của hệ thống, kỹ sư của khách hàng, người quản lý ký kết hợp đồng, các kiến trúc sư hệ thống. + Đặc tả yêu cầu: là tài liệu được cấu trúc mô tả hệ thống các dịch vụ chi tiết hơn. Đôi khi tài liệu này được gọi là đặc tả chức năng. Đây có thể coi là hợp đồng ký kết giữa người mua và kẻ bán phần mềm. Tài liệu này cung cấp cho các thành phần: người dùng cuối của hệ thống, kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển phần mềm.
26. + Đặc tả phần mềm: là mô tả trừu tượng hơn của phần mềm làm cơ sở cho thiết kế và triển khai. Tài liệu này cung cấp cho các thành phần: kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển phần mềm. Xác định yêu cầu: là mô tả trừu tượng các dịch vụ mà hệ thống được mong đợi phải cung cấp và các ràng buộc mà hệ thống phải tuân thủ khi vận hành. Nó chỉ có các đặc tả phẩm hạnh bên ngoài của hệ thống mà không liên quan đến các đặc tính thiết kế. Nó phải được viết sao cho người ta có thể hiểu được mà không cần một kiến thức chuyên môn đặc biệt nào. *Các yêu cầu của phần mềm được chia thành hai loại: Các yêu cầu hệ thống chức năng: các dịch vụ mà hệ thống phải cung cấp. Các yêu cầu không chức năng: các ràng buộc mà hệ thống phải tuân theo. Về nguyên tắc các yêu cầu của một hệ thống phải là vừa đầy đủ, vừa tráng kiện. Đầy đủ có nghĩa là mọi yêu cầu đều phải được đặc tả. Tráng kiện có nghĩa là các yêu cầu không gây ra mâu thuẫn. Thực tế đối với các hệ lớn và phức tạp thì thực là không thể đạt được tính đầy đủ và tính tráng kiện cho phiên bản đầu của tư liệu yêu cầu phần mềm. Vấn đề là khi duyệt lại hoặc trong các pha sau này của vòng đời phần mềm, người ta phát hiện ra các sự không thỏa mãn đó thì tư liệu yêu cầu phải được chỉnh lý lại. Về bản chất, chúng ta phải hiểu và xác định rõ những yêu cầu của khách hàng. Tuy nhiên, thường bài toán được khách hàng phát biểu bằng ngôn ngữ tự nhiên cộng thêm với việc dùng các bảng các biểu đồ cho các người dùng dễ hiểu (xem là người dùng không biết các khái niệm chuyên môn công nghệ thông tin). Không may là ngôn ngữ được dùng này lại thường là không chính xác và mơ hồ, đôi khi có sự lầm lẫn giữa các biểu thị khái niệm và các biểu thị chi tiết làm cho việc mô tả chứa các thông tin hổ lốn được biểu diễn ở nhiều mức chi tiết khác nhau. Ở đây, chúng ta cần chú ý rằng người đặt hàng có thể vì không hiểu biết gì về tin học nên họ không thể phát biểu chính xác và đầy đủ các yêu cầu của họ, đôi lúc thì những cái mà người sử dụng yêu cầu và những cái mà họ cần là không giống nhau. Thêm vào đó, chúng ta lại không hiểu biết đầy đủ về đối
27. tượng, địa bàn cho nên không thể thu thập đầy đủ và chính xác các thông tin của đối tượng và đây chính là một trong những mâu thuẩn giữa khách hàng và chúng ta. Vì vậy, trong thực tế, đối với các hệ thống lớn và phức tạp, rất khó có thể đạt được tính đầy đủ và thống nhất của tài liệu yêu cầu. *Các yêu cầu được tìm hiểu còn chứa các mâu thuẩn: Thiếu rõ ràng: Rất khó sử dụng ngôn ngữ tự nhiên mô tả chính xác không nhầm lẫn mà không làm khó khăn cho người đọc. Nhầm lẫn yêu cầu: Các yêu cầu chức năng, các ràng buộc, mục đích của hệ thống và các thông tin thiết kế không được phân biệt rõ ràng. Trộn lẫn yêu cầu: Một số các yêu cầu khác nhau có thể được thể hiện như là một yêu cầu đơn. Giải quyết mâu thuẩn này, chúng ta phải: trên cơ sở nghiên cứu kỹ lĩnh vực ứng dụng và thảo luận với người sử dụng để định nghĩa chính xác các yêu cầu của bài toán. Xác định rõ và đầy đủ bài toán là yếu tố quan trọng góp phần đảm bảo thành công của dự án. Nhiệm vụ của giai đoạn này là xây dựng được các hồ sơ mô tả chi tiết về các yêu cầu, nhiệm vụ, chức năng của hệ thống dự kiến. 3.1.2. Đánh giá các yêu cầu Đánh giá các yêu cầu phần mềm liên quan với việc cho biết các yêu cầu thực sự định nghĩa hệ thống đáp ứng đòi hỏi của khách hàng. Nếu việc đánh giá này không chính xác, các lỗi trong phần yêu cầu sẽ truyền tới thiết kế hệ thống và triển khai hệ thống. Chi phí sửa chữa lỗi sẽ rất lớn. Sự thay đổi về yêu cầu ngụ ý rằng việc thiết kế và triển khai cũng phải thay đổi theo. Một số khía cạnh của yêu cầu cần phải kiểm chứng: Giá trị: người dùng có thể nghĩ rằng hệ thống cần một số chức năng, tuy nhiên sau một số phân tích, có thể xác định các chức năng khác cần được đưa vào. Do hệ thống có nhiều loại người sử dụng nên có các yêu cầu khác nhau và không thể tránh khỏi sự thỏa hiệp các nhu cầu đó. Chắc chắn: mọi yêu cầu không được mâu thuẫn với các yêu cầu khác Hoàn chỉnh: định nghĩa cần phải bao gồm mọi chức năng và các ràng buộc
28. Hiện thực: không có các yêu cầu đặc biệt đến mức phi hiện thực. Có thể dự đoán trước các phát triển phần cứng, tuy nhiên phát triển phần mềm thì khó dự đoán hơn. Mẫu: là một mô hình chạy được của hệ thống được trình bày với người sử dụng. Đây là một kỹ thuật đánh giá yêu cầu hiệu quả. Nó cho phép người dùng thử nghiệm với hệ thống. Việc đánh giá lại yêu cầu không nên được coi là công việc tiếp theo của tư liệu hóa yêu cầu sau khi đã hoàn thành. Các xem xét về yêu cầu định kỳ liên quan với người dùng và kỹ sư phần mềm luôn cần thiết. Các xem xét yêu cầu có thể là hình thức hoặc phi hình thức. Xem xét phi hình thức liên quan việc các người ký hợp đồng thảo luận các yêu cầu với khách hàng. Nhiều vấn đề có thể được giải quyết dễ dàng bất ngờ khi tham khảo trực tiếp với khách hàng. Đối với yêu cầu xem xét chính thức, đội phát triển phải dẫn dắt khách hàng thông qua các yêu cầu hệ thống, giải thích các triển khai của mỗi yêu cầu. Nhóm rà soát phải kiểm tra mỗi yêu cầu về độ thống nhất, hoàn chỉnh cho toàn bộ tài liệu. Họ có thể phải kiểm tra: Có khả năng kiểm tra: tài liệu có thể kiểm tra thực tế được không? Khả năng hiểu biết: tài liệu có được khách hàng hiểu biết thấu đáo hay không? Lưu vết: nguồn gốc của tài liệu có được xác định rõ ràng hay không? Rất có thể phải quay lại nguồn gốc ban đầu để đánh giá ảnh hưởng của sự thay đổi. Tính thích hợp: các yêu cầu đã phù hợp hay chưa? Có thể thay đổi các yêu cầu mà không làm ảnh hưởng lớn đến toàn bộ hệ thống không. 3.2. Phân tích yêu cầu Nghiên cứu kỹ các yêu cầu của người sử dụng và của hệ thống phần mềm để xây dựng các đặc tả về hệ thống là cần thiết, nó sẽ xác định hành vi của hệ thống. Nhiệm vụ của giai đọan này là phải trả lời được các câu hỏi sau: Đầu vào của hệ thống là gì Những quá trình cần xử lý trong hệ thống, hay hệ thống phần mềm sẽ phải xử lý những cái gì. Đầu ra: kết quả xử lý của hệ thống là gì
29. Những ràng buộc trong hệ thống, chủ yếu là mối quan hệ giữa đầu vào và đầu ra như thế nào. Trả lời được câu hỏi trên, nghĩa là phải xác định được chi tiết các yêu cầu làm cơ sở để đặc tả hệ thống. Đó là kết quả của sự trao đổi, thống nhất giữa người đầu tư, người sử dụng với người xây dựng hệ thống. Mục tiêu là xây dựng các hồ sơ mô tả chi tiết các yêu cầu của bài toán nhằm nêu bật được hành vi, chức năng cần thực hiện của hệ thống dự kiến. Như vậy, phân tích yêu cầu là quá trình suy luận các yêu cầu hệ thống thông qua quan sát hệ thống hiện tại, thảo luận với các người sử dụng, phân tích công việc. Việc này có thể liên quan với việc tạo một hay nhiều mô hình khác nhau. Nó giúp các phân tích viên hiểu biết hệ thống. Các mẫu hệ thống cũng có thể được phát triển để mô tả các yêu cầu. Ta có quy trình để có các chức năng của hệ thống: Nghiên cứu Phân tích Xác định Đặc tả yêu khả thi các yêu cầu cầu yêu cầu Báo cáo Các mô hình Định nghĩa khả thi hệ thống các yêu cầu Tài liệu yêu Đặc tả các yêu cầu cầu Trong quá trình phân tích cần lưu ý đến tính khả thi của dự án. + Khả thi về kinh tế: chi phí phát triển phải cân xứng với lợi ích mà hệ thống đem lại, gồm có: Chi phí: Mua sắm: thiết bị, vật tư (phần cứng), tư vấn, cài đặt thiết bị, quản lý và phục vụ,
30. Chi phí cho khởi công: phần mềm phục vụ cho hệ thống, hệ thống liên lạc (truyền dữ liệu), nhân sự ban đầu: đào tạo - huấn luyện, cải tổ tổ chức cho phù hợp, Chi phí liên quan: chi phí nhân công phục vụ thu nhập dữ liệu, sửa đổi, cập nhật hệ thống, chuẩn bị tài liệu, Chi phí liên tục là tốn kém nhất, gồm: bảo trì, thuê bao, khấu hao phần cứng, chi phí phục vụ cho vận hành, Lợi nhuận do sử dụng hệ thống Nhiệm vụ xử lý thông tin: giảm chi phí do xử lý tự động, tăng độ chính xác và kết quả tốt hơn, thời gian trả lời rút ngắn, Có được từ hệ thống: thu thập và lưu trữ dữ liệu tự động, đầy đủ, dữ liệu được chuẩn hóa, bảo đảm an toàn và an ninh dữ liệu, tương thích và chuyển đổi giữa các bộ phận, truy cập và tìm kiếm nhanh, kết nối và trao đổi diện rộng, + Khả thi về kỹ thuật: đây là vấn đề cần lưu ý vì các mục tiêu, chức năng và hiệu suất của hệ thống theo một cách nào đó là còn "mơ hồ" do vậy xét: Rủi ro xây dựng: các phần tử hệ thống (chức năng, hiệu suất) khi thiết kế và phân tích có tương đương hay không? Có sẵn tài nguyên: có sẵn con người và tài nguyên cần thiết để phát triển hệ thống? Công nghệ: các công nghệ liên quan cho việc phát triển hệ thống đã có sẵn hay chưa? + Khả thi về hợp pháp: có sự xâm phạm, vi phạm hay khó khăn nào gây ra khi xây dựng hệ thống hay không. + Các phương án: đánh giá về phương án tiếp cận đến việc xây dựng hệ thống. 3.3. Đặc tả yêu cầu 3.3.1. Đặc tả yêu cầu Khi đã xác định rõ bài toán thì bước tiếp theo là tìm hiểu xem hệ thống dự kiến sẽ yêu cầu làm cái gì. Điều quan trọng ở đây là phải xây dựng được danh sách các yêu cầu của người sử dụng. Dựa trên những yêu cầu của người sử dụng, người phát triển đưa ra các đặc tả cho hệ thống.
31. Người xây dựng hệ thống phải trả lời được các yêu cầu sau đây: Đầu ra của hệ thống là cái gì Hệ thống sẽ phải làm cái gì để có kết quả mong muốn, nghĩa là phải xử lý những cái gì Những tài nguyên mà hệ thống yêu cầu là gì Hiểu rõ nguồn gốc, các dạng thông tin cần cung cấp cho hệ thống hoạt động. Hệ thống sẽ phải giải quyết những vấn đề gì, những kết quả cần phải có là gì. Xác định được mối quan hệ giữa cái vào và cái ra cho quá trình hoạt động của hệ thống. Các đặc tả chi tiết phục vụ cho việc xây dựng và trắc nghiệm về hệ thống để kiểm tra xem những nhiệm vụ đã đặt ra có hoàn tất được hay không. Ở đây, chúng ta cần chú ý là trong một số trường hợp, sẽ nảy sinh những yêu cầu mới mà có thể là ta phải xây dựng lại hệ thống, tất nhiên điều này sẽ làm chậm tiến trình xây dựng và làm tăng giá thành do một vài lý do để không thể hoàn chỉnh các đặc tả đối với các hệ thống như: Các hệ thống phần mềm lớn luôn đòi hỏi cải tiến từ hiện trạng. Mặc dù các khó khăn của hệ thống hiện tại có thể xác định được nhưng các ảnh hưởng và hiệu ứng của hệ thống mới khó có thể dự đoán trước được. Hệ thống lớn thường có nhiều cộng đồng sử dụng khác nhau. Họ có các yêu cầu và ưu tiên khác nhau. Các yêu cầu hệ thống cuối cùng không tránh khỏi các thỏa hiệp. Người trả tiền cho hệ thống và người sử dụng thường khác nhau. Các yêu cầu đưa ra do ràng buộc của các tổ chức và tài chính có thể tranh chấp với yêu cầu của người sử dụng. Do các đặc tả yêu cầu thêm các thông tin vào định nghĩa yêu cầu nên các đặc tả thường được biểu diễn cùng với các mô hình hệ thống được phát triển trong quá trình phân tích yêu cầu. Nó cần bao gồm mọi thông tin cần thiết về yêu cầu chức năng và ràng buộc của hệ thống. Phân tích yêu cầu được tiếp tục xác định và đặc tả khi các yêu cầu mới nảy sinh. Đây là tài liệu thường xuyên thay đổi và nên được kiểm soát chặt chẽ.
32. Ngôn ngữ tự nhiên không hoàn toàn thuận tiện cho các thiết kế viên hoặc các hợp đồng giữa các khách hàng và cán bộ phát triển hệ thống vì có một số lý do như sau: Nhầm lẫn do cách hiểu các khái niệm khác nhau giữa hai bên. Đặc tả yêu cầu ngôn ngữ tự nhiên quá mềm dẻo. Một vấn đề có thể được mô tả bằng quá nhiều cách khác nhau. Các yêu cầu không được phân hoạch tốt, khó tìm các mối quan hệ, Do vậy người ta thường dùng các thay thế khác để đặc tả các yêu cầu như: Ngôn ngữ tự nhiên có cấu trúc, Ngôn ngữ mô tả thiết kế, giống ngôn ngữ lập trình nhưng có mức trừu tượng cao hơn, Ngôn ngữ đặc tả yêu cầu, Ghi chép graphic, Đặc tả toán học, Có thể chia đặc tả yêu cầu ra làm hai loại: đặc tả phi hình thức (ngôn ngữ tự nhiên) và đặc tả hình thức (dựa trên kiến trúc toán học). Đặc tả phi hình thức Đặc tả phi hình thức là đặc tả sử dụng ngôn ngữ tự nhiên. Tuy nó không được chặt chẽ bằng đặc tả hình thức nhưng được nhiều người biết và có thể dùng để trao đổi với nhau để làm chính xác hóa các điểm chưa rõ, chưa thống nhất giữa các bên phát triển hệ thống. Đặc tả hình thức Đặc tả hình thức là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ nghĩa được định nghĩa hình thức dựa vào toán học. Đặc tả hình thức có thể coi là một phần của hoạt động đặc tả phần mềm. Các đặc tả yêu cầu được phân tích chi tiết. Các mô tả trừu tượng của các chức năng chương trình có thể được tạo ra để làm rõ yêu cầu.
33. Đặc tả phần mềm hình thức là một đặc tả được trình bày trên một ngôn ngữ bao gồm: từ vựng, cú pháp và ngữ nghĩa được định nghĩa. Định nghĩa ngữ nghĩa đảm bảo ngôn ngữ đặc tả không phải là ngôn ngữ tự nhiên mà dựa trên toán học. Các chức năng nhận các đầu vào trả lại các kết quả. Các chức năng có thể định ra các điều kiện tiền tố và hậu tố. Điều kiện tiền tố là điều kiện cần thỏa mãn để có dữ liệu vào, điều kiện hậu tố là điều kiện cần thỏa mãn sau khi có kết quả. Có hai hướng tiếp cận đặc tả hình thức để phát triển các hệ thống tương đối phức tạp. + Tiếp cận đại số, hệ thống được mô tả dưới dạng các toán tử và các quan hệ. + Tiếp cận mô hình, mô hình hệ thống được câú trúc sử dụng các thực thể toán học như là các tập hợp và các thứ tự. Sử dụng đặc tả hình thức, ta có các thuận lợi: Cho phép chúng ta thấy và hiểu được bản chất bên trong của các yêu cầu, đây là cách tốt nhất để làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công việc thiết kế được thuận lợi. Do chúng ta sử dụng toán học cho việc đặc tả nên có thể dựa vào các công cụ toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ của hệ thống. Đặc tả hình thức, bản thân nó cho chúng ta một cách thức cho việc kiểm tra hệ thống sau này. Tuy vậy, đặc tả hình thức cũng bộc lộ một vài khó khăn: Quản lý phần mềm có tính bảo thủ cố hữu của nó, không sẵn sàng chấp nhận các kỹ thuật mới. Chi phí cho việc đặc tả hình thức thường cao hơn so với các đặc tả khác (tuy phần cài đặt sẽ thấp hơn), nên khó để chứng minh rằng chi phí tương đối cao cho đặc tả sẽ làm giảm tổng chi phí dự án. Phần lớn, những người đặc tả hệ thống không được đào tạo một cách chính quy về việc sử dụng đặc tả hình thức cho việc đặc tả hệ thống mà dựa trên thói quen của họ.
34. Thông thường, nhiều thành phần của hệ thống là khó cho việc đặc tả bằng ngôn ngữ hình thức. Thêm vào đó là khách hàng không thể hiểu được nó. Khách hàng không thích các đặc tả toán học. 3.3.2. Nguyên lý đặc tả Nguyên lý 1: Phân tách chức năng với cài đặt: đặc tả là mô tả điều mong muốn chứ không phải cách thức thực hiện (cài đặt). Kết quả thu được theo dạng cái gì chứ không phải là thế nào. Nguyên lý 2: Cần tới ngôn ngữ đặc tả hệ thống hướng tiến trình: cần thiết đặc biệt trong trường hợp môi trường là động và sự thay đổi của nó ảnh hưởng tới hành vi của thực thể nào đó tương tác với môi trường nào đó. Nguyên lý 3: Đặc tả phải bao gồm hệ thống có phần mềm là một thành phần: vì hệ thống bao gồm các thành phần tương tác với nhau, chỉ bên trong hoàn cảnh của toàn bộ hệ thống và tương tác giữa các thành phần của nó thì hành vi của một thành phần mới có thể xác định. Nguyên lý 4: Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành. Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức: không phải là mô hình thiết kế hay cài đặt. Nó phải mô tả một hệ thống như cộng đồng người sử dụng cảm nhận thấy. (Các sự vật mà nó thao tác phải tương ứng với các sự vật của lĩnh vực đó; các tác nhân phải mô hình cho các cá nhân, tổ chức, trang thiết bị; các hành động họ thực hiện thì mô hình cho những hoạt động thực tế xuất hiện trong lĩnh vực; ) Nguyên lý 6: Đặc tả phải vận hành: phải đầy đủ và hình thức để có thể được dùng trong việc xác định liệu một cài đặt được đề nghị có thỏa mãn đặc tả trong những trường hợp kiểm thử tùy ý hay không. Nguyên lý 7: Đặc tả hệ thống phải dung sai về tính không đầy đủ và tính nâng cao. Đặc tả không thể hoàn toàn đầy đủ do môi trường phức tạp + Đặc tả là mô hình - sự trừu tượng hóa - của tình huống thực nên không đầy đủ. + Đặc tả sẽ tồn tại ở nhiều mức chi tiết + Các công cụ phân tích được sử dụng để giúp cho đặc tả và kiểm thử đặc tả phải có khả năng xử lý với tính không đầy đủ.
35. Nguyên lý 8: Đặc tả phải được cục bộ hóa và được ghép lỏng lẻo: Đặc tả làm cơ sở cho thiết kế và cài đặt, không phải tĩnh mà là một sự vật động, đang trải qua thay đổi đáng kể nên nội dung và cấu trúc phải phù hợp. Sự thay đổi khi cần sửa đổi là tối thiểu, chỉ một phần nhỏ các thành phần có thể thâm vào hay loại bớt một cách dễ dàng. 3.4. Tư liệu hóa yêu cầu phần mềm Các yêu cầu hệ thống được trình bày trong tài liệu các yêu cầu phần mềm cho biết những thứ cán bộ phát triển hệ thống cần biết. Tài liệu này bao gồm các định nghĩa về yêu cầu và các đặc tả về các yêu cầu. Trong một số trường hợp, chúng không được trình bày riêng biệt mà được tích hợp làm một. Đôi khi, định nghĩa yêu cầu được trình bày như là một giới thiệu tới đặc tả yêu cầu. Cách tiếp cận hiệu quả nhất là trình bày các đặc tả chi tiết như là phụ lục của yêu cầu. Tài liệu yêu cầu phần mềm không phải tài liệu đặc tả. Nó cần phải mô tả cái hệ thống cần phải làm chứ không phải làm thế nào. Tài liệu này cần dễ dàng được đặc tả và ánh xạ sang các phần tương ứng của thiết kế hệ thống. Nếu các dịch vụ, ràng buộc và các đặc tả thuộc tính trong tài liệu yêu cầu phần mềm được thỏa mãn bởi thiết kế thì thiết kế này được coi là giải pháp thích hợp với vấn đề. Về nguyên tắc, các yêu cầu cần được hoàn chỉnh và chắc chắn. Mọi chức năng hệ thống cần được đặc tả và các yêu cầu không được mâu thuẫn. Tuy nhiên các thiếu sót là không thể tránh khỏi, do vậy tài liệu nên được cấu trúc dễ cho việc thay đổi. Nội dung nên được chia thành các chương. Sáu yêu cầu cần được thỏa mãn là: Nó cần mô tả các hành vi hệ thống bên ngoài Nó cần mô tả các ràng buộc về thực hiện Nó cần phải dễ thay đổi Nó phải là công cụ tham chiếu cho người bảo trì hệ thống Nó cần ghi được vòng đời của hệ thống Nó cần biểu thị được các đáp ứng chấp nhận được với các sự kiện không dự kiến Cấu trúc chung của tài liệu yêu cầu phần mềm gồm các phần như sau:
36. + Giới thiệu: mô tả sự cần thiết của hệ thống. Nó cần sự mô tả sơ lược các chức năng của mình và giải thích cách làm việc với các hệ thống khác. Nó cũng cần mô tả làm thế nào hệ thống đáp ứng được toàn bộ các mục tiêu chiến lược và nghiệp vụ. + Thuật ngữ: nó cần định nghĩa các khái niệm kỹ thuật được sử dụng trong tài liệu này. Không được giả định người đọc đã có kinh nghiệm. + Mô hình hệ thống: phần này lập một hoặc nhiều mô hình hệ thống cho biết các quan hệ giữa các cấu thành hệ thống với hệ thống và môi trường của nó. Nó cần bao gồm các mô hình đối tượng, mô hình luồng dữ liệu và ngữ nghĩa dữ liệu. + Định nghĩa yêu cầu chức năng: các dịch vụ cung cấp cho người dùng cần được mô tả trong mục này. Mô tả có thể dùng ngôn ngữ tự nhiên, sơ đồ hoặc các dạng ghi chép khác cho phép khách hàng có thể hiểu được. Các dịch vụ cung cấp cho người dùng cần được mô tả trong mục này. Mô tả có thể dùng ngôn ngữ tự nhiên, sơ đồ hoặc các dạng ghi chép khác cho phép khách hàng có thể hiểu được. + Định nghĩa yêu cầu phi chức năng: các ràng buộc về phần mềm và các hạn chế đối với thiết kế cần phải được mô tả trong phần này. Nó có thể bao gồm các chi tiết của biểu diễn dữ liệu, thời gian đáp ứng và yêu cầu bộ nhớ, Các tiêu chuẩn về sản phẩm và quy trình cần tuân thủ cũng được mô tả. + Tiến triển hệ thống: phần này mô tả các giả thiết căn bản làm cơ sở cho hệ thống và dự đoán các thay đổi về phát triển phần cứng, yêu cầu người dùng + Đặc tả yêu cầu: mô tả các yêu cầu cơ bản chi tiết hơn. Nếu cần các chi tiết hơn có thể được thêm vào các yêu cầu phi chức năng, ví dụ giao diện với các hệ thống có thể được định nghĩa. + Ngoài ra, tài liệu yêu cầu phần mềm có thể bao gồm thêm các phần sau: - Phần cứng: nếu hệ thống được phát triển trên một phần cứng đặc biệt, phần cứng này và giao diện cần được mô tả. Nếu phần cứng bán sẵn được sử dụng, các cấu hình cực tiểu và cực đại phải được mô tả. - Yêu cầu dữ liệu: tổ chức logic của dữ liệu được sử dụng bởi hệ thống và các quan hệ giữa chúng được mô tả, có thể dùng sơ đồ thực thể liên kết.
37. - Chỉ mục có thể được cung cấp. Ví dụ chỉ mục theo chữ cái, chỉ mục theo chương, theo chức năng Do hệ thống được vận hành trong thời gian dài, nên môi trường hệ thống và mục đích nghiệp vụ có thể thay đổi. Khi đó tài liệu yêu cầu cũng cần phải thay đổi. Với mục đích tiến triển, tài liệu yêu cầu thường được chia theo hai phân loại: Các yêu cầu ổn định: được suy dẫn từ các hoạt động cốt lõi của tổ chức tương đối liên quan trực tiếp tới miền hệ thống. Các yêu cầu bất thường: các yêu cầu có thể thay đổi khi phát triển hệ thống sau này như: các yêu cầu xuất hiện như là sự hiểu biết của khách hàng về sự phát triển của hệ thống trong quá trình xây dựng hệ thống, các yêu cầu được sinh ra do sự xuất hiện của việc tin học hóa làm thay đổi các quy trình nghiệp vụ, 3.5. Đặc tính dữ liệu và các kỹ thuật để thu thập dữ liệu 3.5.1. Đặc tính dữ liệu Một ứng dụng thành công là một ứng dụng đáp ứng được đầy đủ các yêu cầu của người sử dụng. Trong quá trình xác định yêu cầu, các dữ liệu thu được của bài toán chứa một số tính chất mà ta gọi là đặc tính dữ liệu như: Tính định hướng thời gian, Tính cấu trúc, Tính đầy đủ, Nhập nhằng, Ngữ nghĩa, Độ lớn của dữ liệu, Mỗi yếu tố trên đều quan trọng trong việc xác định các đặc tả của ứng dụng bởi vì chúng mang đến các chỉ dẫn cho kỹ sư phần mềm biết số lượng và kiểu thông tin nên được chọn. Cũng vậy, các kiểu dữ liệu khác nhau có liên quan tới các loại ứng dụng khác nhau và đòi hỏi các kỹ thuật khai thác thông tin khác nhau. Không chú ý tới các đặc tính dữ liệu sẽ gây lỗi phân tích và thiết kế. Mối liên hệ giữa các kiểu ứng dụng và các đặc tính dữ liệu của nó được thể hiện ở bảng sau:
38. Đặc tính dữ liệu Tính thời Mức Nhập Ngữ Độ Cấu trúc Loại gian đầy đủ nhằng nghĩa lớn ứng dụng TPS Hiện tại Cấu trúc Đầy đủ Thấp Cố định Các loại CSDL Quá khứ Cấu trúc Đầy đủ Thấp Cố định Các loại hiện tại DSS Các loại Cấu trúc Thay đổi Thấp, Thay đổi Trungbìn trungbìn h cao GDSS Hiện tại Phi cấu Không hTrungbìn Thay đổi Thấp tương lai trúc đầy đủ hcao EIS Tươnglai Phi cấu Không Trungbìn Thay đổi Thấp trúc đầy đủ h cao trung ES Hiện tại Báncấu Không Trungbìn Thay đổi bìnhThấp (dựaquá trúc đầy đủ h cao khứ) Hệ xử lý giao dịch bao gồm kiến thức định trước, thông tin đầy đủ, có cấu trúc, hiện thời. Do hệ xử lý giao dịch là các ứng dụng thao tác của công ty nên để điều khiển và bảo trì các bản ghi của thao tác hiện thời, bạn phải có thông tin đầy đủ, hiện thời. Các ứng dụng hỏi đáp có đặc tính tương tự hệ xử lý giao dịch với đặc điểm khác mà chúng có thể tập trung vào các thông tin lịch sử thêm vào thông tin hiện tại. Truy vấn là các câu hỏi được đặt ra bởi dữ liệu để tìm thấy các vấn đề và giải pháp, để phân tích, tổng kết và báo cáo trên dữ liệu. Để tạo tổng kết và báo cáo với sự tin tưởng, dữ liệu phải có cấu trúc, đầy đủ và được diễn giải không nhầm lẫn và có ngữ nghĩa nhất định. Hệ hỗ trợ quyết định là các công cụ phân tích thống kê cho phép phát triển các thông tin giúp đỡ việc ra quyết định. Kiểu dữ liệu xác định hệ hỗ trợ quyết định luôn có thể được biểu diễn lại, có thể chưa hoàn chỉnh, nhập nhằng, có ngữ nghĩa thay đổi từ trung bình tới nhiều về độ lớn.
39. Hệ hỗ trợ quyết định theo nhóm là công cụ hỗ trợ họp nhóm cho nhóm người. Các công cụ hệ hỗ trợ quyết định theo nhóm thao tác có cấu trúc trên đầy đủ và còn các nhập nhằng về ngữ nghĩa. Bản thân các công cụ thì đầy đủ, không nhập nhằng và mạnh nhưng các thông tin họp nhóm mà nó thực hiện thì lại không như vậy. Hệ thông tin điều hành là các ứng dụng hướng tương lai cho phép duyệt qua môi trường và xác định khuynh hướng, cơ hội kinh doanh, hoặc các hoạt động công nghiệp khác ảnh hưởng tới hoạt động của công ty. Hệ thông tin điều hành giải quyết phần lớn với các dữ liệu “hỗn độn” không có cấu trúc, không đầy đủ, nhập nhằng, và chứa ngữ nghĩa thay đổi. Hệ chuyên gia quản lý và suy luận thông qua các dữ liệu bán cấu trúc, không đầy đủ, nhập nhằng và ngữ nghĩa thay đổi. Các chuyên gia lấy các thông tin ngẫu nhiên và không cấu trúc sau đó tạo cấu trúc cho nó. Họ suy luận bằng cách làm thế nào diễn đạt dữ liệu để loại trừ mức độ nhập nhằng và cố định ngữ nghĩa. Do đó, mặc dù các dữ liệu đầu vào ứng dụng có các đặc tính mờ, quá trình xử lý dữ liệu phải thực sự được cấu trúc cao. 3.5.1.1. Tính định hướng thời gian Tính hướng thời gian của dữ liệu đề cập tới quá khứ, hiện tại hoặc các đòi hỏi tương lai của ứng dụng đã đề ra. Các dữ liệu quá khứ: có thể mô tả công việc đã được biến đổi thế nào qua thời gian, các quy định ảnh hưởng thế nào tới nhiệm vụ, vị trí của nó trong tổ chức và nhiệm vụ. Các thông tin quá khứ là chính xác, đầy đủ và xác đáng. Các thông tin hiện tại: là các thông tin về cái gì đang xảy ra. Ví dụ, thông tin ứng dụng hiện tại liên quan tới quá trình hoạt động của công ty, số lượng của các lệnh được thực hiện trong ngày hoặc số lượng các hàng hoá được sản xuất, các chính sách, sản phẩm, đòi hỏi nghiệp vụ, yêu cầu pháp quy hiện tại hoặc các ràng buộc khác cũng rất cần thiết cho phát triển ứng dụng. Các thông tin hiện tại nên được tư liệu hoá theo cách thích hợp với đội ngũ phát triển để tăng trí thức của họ về ứng dụng và phạm vi bài toán.
40. Các đòi hỏi trong tương lai: liên quan tới các sự thay đổi sẽ xảy ra, chúng không chính xác và rất khó kiểm tra. Ví dụ: các dự đoán kinh tế, khuynh hướng tiếp thị, bán hàng, 3.5.1.2. Tính cấu trúc Cấu trúc của thông tin định hướng về phần mở rộng theo đó thông tin có thể được phân loại theo cách nào đó. Cấu trúc có thể tham chiếu tới các hàm, môi trường hoặc dạng dữ liệu hay dạng xử lý. Các thông tin thay đổi từ phi cấu trúc cho tới cấu trúc mà phần cấu trúc được xác định bởi kỹ sư phần mềm. Cấu trúc là đặc biệt quan trọng bởi vì thiếu nó ta có thể tạo ứng dụng sai. 3.5.1.3. Tính đầy đủ Tính đầy đủ thể hiện ở chổ các thông tin cần thiết phải được biểu diễn. Một kiểu ứng dụng đòi hỏi một mức độ đầy đủ khác nhau. Các hệ thống xử lý giao dịch luôn tiếp cận các thông tin đầy đủ và chính xác, trong khi các hệ hỗ trợ quyết định đòi hỏi thông tin ít đầy đủ hơn. Các hệ thông tin điều hành, hệ chuyên gia, hoặc là các ứng dụng trí tuệ nhân tạo có mức độ cao nhất về tính không đầy đủ trong phạm vi của ứng dụng. Đối với các ứng dụng phải giải quyết các thông tin không đầy đủ, một thách đố đối với nhóm phát triển là phải quyết định thông tin đã đủ để sử dụng hay chưa. Đôi khi quyết định này được tiến hành từ phía người dùng, đôi khi nó được tiến hành bên trong ứng dụng và cần phải có luật để xác định mức độ đầy đủ. 3.5.1.4. Nhập nhằng Tính nhập nhằng là một thuộc tính của dữ liệu, thể hiện ở chổ không trong sáng về nghĩa hoặc có nhiều nghĩa một cách hữu ý. Tính này liên quan nhiều đến mức độ ngữ nghĩa. Vấn đề này nảy sinh khi gặp một vấn đề có thể được hiểu theo nhiều cách - ví dụ câu phát biểu: "Ông cụ già đi mau quá!". Để giải quyết tính nhập nhằng cần căn cứ vào ngữ cảnh. 3.5.1.5. Ngữ nghĩa
41. Ngữ nghĩa là một tập hợp các định nghĩa được chia sẻ cho biết các thuật ngữ, chính sách hoặc các hành động được hiểu như thế nào cho mọi người trong một tổ chức nào đó. Ngữ nghĩa rất quan trọng trong phát triển ứng dụng và đối với bản thân ứng dụng. Nếu mọi người dùng chung một thuật ngữ nhưng có quan niệm khác nhau sẽ xuất hiện sự không hiểu và không trao đổi thông tin được. Đối với bản thân ứng dụng nếu dữ liệu bị nhập nhằng về ý nghĩa có thể sẽ không bao giờ được xử lý cho đến khi người sử dụng hiểu được ý nghĩa của dữ liệu. Các ứng dụng sẽ có ngữ nghĩa cố định với các mục dữ liệu được định tính thông qua việc đào tạo và quá trình sử dụng lâu dài. Khi đánh mất ngữ nghĩa của thông tin có thể gây tổn thất rất lớn đối với các bên liên quan. 3.5.1.6. Độ lớn của dữ liệu Độ lớn của dữ liệu là số lượng các sự kiện nghiệp vụ hệ thống phải tiến hành trong vài chu kỳ nào đó. Độ lớn của tạo mới hoặc thay đổi khách hàng được tiến hành theo tháng hoặc năm, trong khi độ lớn của giao dịch nghiệp vụ được tiến hành theo ngày hoặc giờ và độ lớn tối đa. Độ lớn tối đa là số lượng các giao dịch hoặc các sự kiện nghiệp vụ được xử lý trong thời kỳ bận nhất. Thời kỳ cao điểm có thể theo năm hoặc cuối vài tháng, ví dụ chuẩn bị cho báo cáo nộp thuế. Độ lớn của dữ liệu là một nguồn thông tin phức tạp bởi vì số lượng thời gian cần thiết xử lý một giao dịch đơn có thể trở thành rất quan trọng đối với lượng lớn dữ liệu cần xử lý. 3.5.2. Các kỹ thuật để thu thập dữ liệu cho ứng dụng Do mỗi giai đoạn phát triển hệ thống đều đòi hỏi có sự trao đổi giữa nhà phát triển và người dùng để nhận được thông tin có ích. Mỗi giai đoạn cần tìm kiếm một dải rộng các câu hỏi về ứng dụng. Khi phân tích tính khả thi, các câu hỏi tương đối rộng và tổng quát như: đâu là phạm vi của vấn đề, cách tốt nhất để tự động hoá là gì, công ty có cố gắng phát triển ứng dụng này không, công ty có thể hổ trợ việc phát triển ứng dụng không? thì khi phân tích yêu cầu chúng ta tìm hiểu các thông tin liên quan ứng dụng là gì, như: các dữ liệu cần thiết là gì, các xử lý nào được tiến hành và các thông tin chi tiết liên quan?
42. Bài 4. LẬP TRÌNH HIỆU QUẢ A. MỤC TIÊU CỦA BÀI - Xác định cách thức thực hiện những gì đã được đặt ra ở phần phân tíc;. - Chuyển đổi những yêu cầu của hệ thống (kết quả của quá trình phân tích) sang dạng biểu diễn của hệ thống phần mềm; B. NỘI DUNG 4.1. Đặc điểm của quá trình thiết kế phần mềm Nhiệm vụ của thiết kế là chuyển đổi những yêu cầu của hệ thống (kết quả của quá trình phân tích) sang dạng biểu diễn của hệ thống phần mềm. Tầm quan trọng của thiết kế được thể hiện qua hình sau: Bảo trì Bảo trì Kiểm thử Kiểm thử Cài đặt Cài đặt Thiết kế Có thiết kế Không có thiết kế Mối liên quan của thiết kế phần mềm với công nghệ phần mềm được thể hiện qua sơ đồ sau: Mô hình Mô hình thông tin chức năng Thiết kế Mô hình dữ liệu hành vi Thiết kế Thiết kế cấu trúc Các yêu cầu khác Lập trình Thiết kế thủ tục Module Kiểm thử chương trình Phần mềm đã tích hợp và kiểm thử
43. Thiết kế phần mềm là hoạt động được xác lập dựa trên hai mặt: quản lý và kỹ thuật, chúng đan xen với nhau. Mối quan hệ giữa hai khía cạnh kỹ thuật và quản lý được thể hiện qua sơ đồ: Khía cạnh quản lý Thiết kế sơ bộ Thiết kế chi tiết Thiết kế dữ liệu Khía Thiết kế kiến trúc cạnh kỹ Thiết kế thủ tục thuật Thiết kế đối tượng Thiết kế giao diện Trong quan điểm quản lý: thiết kế phần mềm được tiến hành 2 bước: + Thiết kế sơ bộ: quan tâm đến việc dịch các yêu cầu thành các kiến trúc dữ liệu và phần mềm. + Thiết kế chi tiết: tập trung vào việc làm mịn biểu diễn kiến trúc để dẫn đến cấu trúc dữ liệu chi tiết và biểu diễn thuật toán cho phần mềm. Trong tiến trình thiết kế, mô hình để biểu diễn công việc thiết kế là đồ thị. Các đỉnh của đồ thị dùng để biểu diễn các thực thể (các tiến trình, các chức năng, các kiểu ) và các cạnh là các mối liên hệ giữa chúng. Tiến trình thiết kế được chỉ ra ở sơ đồ sau: Thiết kế Thiết kế phi Thiết kế hình Phát thảo hình thếc thếc hoàn thiết kế phi chỉnh hình thức
44. 4.2. Các hoạt động của quá trình thiết kế phần mềm Như trên đã nói, phân tích nhằm xác định ứng dụng sẽ thực hiện cái gì còn thiết kế nhằm để trả lời câu hỏi phần mềm cụ thể sẽ như thế nào? Trong thực tế, không có sự tách biệt giữa hai giai đoạn này mà là hai hoạt động được tiến hành song song và chúng bổ sung lẫn nhau. Các hoạt động phải thực hiện trong quá trình này gồm: định danh, suy diễn, tổng hợp lại, xem xét lại và tạo tài tiệu. Định danh: chính là tìm kiếm những gì quan trọng có liên quan, như việc tìm các thực thể, các đối tượng, các mối quan hệ, các chức năng, các tiến trình và các ràng buộc của hệ thống. Thiết kế là việc tham chiếu các yêu cầu logic sẽ làm việc như thế nào trong môi trường tính toán đích. Điều này có nghĩa là chúng ta định danh cấu trúc thiết kế hệ thống, nó là phương hướng thiết kế nền tảng. Các phương hướng có thể bao gồm: Xử lý theo lô, trực tuyến hoặc thời gian thực. Các hàm chức năng nào được kết nối với nhau và ứng dụng sẽ làm việc trong môi trường sản phẩm như thế nào. Các giao diện người sử dụng chung như điều khiển menu, cửa sổ – biểu tượng – menu – con trỏ, điều khiển lệnh, Kiểu thao tác, người sử dụng là chuyên gia, tập sự hay bình thường. Suy diễn: Xác định các chi tiết của những gì đã được định danh. Về mặt thể hiện, một yêu cầu có thể được cung cấp bản kê khai thống nhất của khách hàng cho báo cáo đặc biệt. Trong quá trình xem xét, ta sẽ tìm câu trả lời cho các câu hỏi như: Thông tin nào có thể đảm bảo chắc chắn về người sử dụng? Nó có đang tồn tại? Điều gì đặc biệt đối với người sử dụng? Kiểu của các Query người sử dụng đang hỏi? Các dạng câu hỏi nào người sử dụng muốn hỏi mà họ không thể trả lời? Kiểu dữ liệu phân tích nào người sử dụng cần? Các form (như màn hình hiển thị hay giấy) được đưa ra? Các người sử dụng đặt câu hỏi ở đâu (vật lý)?
45. Dữ liệu đang ở đâu (tập trung/ phân tán/ nữa tập trung)? Và nó có thể ở đâu? Mỗi yêu cầu từ quá trình phân tích được khai triển thành chi tiết lớn hơn trong thiết kế và được tham chiếu tới phần cứng, phần mềm thuộc cấu trúc thiết kế hệ thống. Ở đây, các vấn đề liên quan đến cần giải quyết như: Cơ sở dữ liệu thiết kế có thể được thiết kế để cung cấp như thế nào, về mặt thể hiện là thời gian đáp ứng tốt nhất với hiệu quả cao nhất? Các chương trình có thể được đóng gói như thế nào để đáp ứng các ràng buộc tiến trình? Các hoạt động xem xét khác được quyết định bao gồm các công việc thông thường chung cho các tiến trình sử dụng thông thường. Về mặt thể hiện, tiến trình hiển thị sẽ được thực hiện như thế nào? Các lập trình viên sẽ viết giao diện hiển thị riêng hay sẽ có các module chung cho các thao tác hiển thị? Phần thân và các chi tiết của hệ thống các chương trình tiện ích được tất cả các lập trình viên sử dụng. Hoạt động xem xét chính cuối cùng là kiểm tra các ràng buộc của ứng dụng. Chúng ta chắc chắn rằng mỗi ràng buộc đều được bảo toàn trong thiết kế và quá trình đó nằm trong các giới hạn quy định. Tổng hợp lại: xây dựng một khung nhìn thống nhất của ứng dụng, điều hoà các phần không thích hợp và biểu diễn các yêu cầu trên form đồ thị. Sự biểu diễn có thể là thủ công hoặc tự động, sử dụng các công cụ tính toán cơ sở. 4.3. Nền tảng thiết kế Mặc dầu có nhiều phương pháp thiết kế phần mềm nhưng trong quá trình thiết kế, chúng ta đều sử dụng một số khái niệm làm nền tảng. Chúng được gọi là nền tảng thiết kế. 4.3.1. Trừu tượng (abstraction) Khái niệm trừu tượng là sự cho phép tập trung vào vấn đề ở mức tổng quát nào đó, không xét tới các chi tiết mức thấp hơn không liên quan. Việc dùng trừu tượng hoá cho phép ta làm việc với khái niệm và thuật ngữ quen thuộc trong
46. môi trường vấn đề mà không phải biến đổi chúng thành một cấu trúc không quen thuộc. Khi xét vấn đề cho việc tìm ra giải pháp module, chúng ta có thể đặt ra nhiều mức độ trừu tượng. Tại mức trừu tượng cao nhất: phát biểu bằng ngôn ngữ môi trường của vấn đề. Tại mức trừu tượng thấp hơn, thường lấy khuynh hướng thủ tục; tại mức thấp nhất, giải pháp được phát biểu theo cách có thể cài đặt trực tiếp. Trong mỗi bước của tiến trình đều là sự làm mịn cho một mức trừu tượng của giải pháp. Khi chuyển qua các mức trừu tượng khác nhau, chúng ta làm việc để tạo ra các trừu tượng thủ tục, trừu tượng dữ liệu và trừu tượng điều khiển. Trừu tượng thủ tục: là một dãy các lệnh có tên, có một chức năng xác định và giới hạn. Trừu tượng dữ liệu: là tập hợp các dữ liệu có tên mô tả cho một sự vật dữ liệu. Đối tượng dữ liệu này thực chất là một tập hợp nhiều mẫu thông tin khác nhau và ta có thể tham khảo tới bằng cách nói tên của trừu tượng dữ liệu. Trừu tượng dữ liệu làm cho người thiết kế có thể xác định một sự vật dữ liệu trong hoàn cảnh các thao tác (thủ tục) có thể áp dụng vào nó. Trừu tượng điều khiển: áp dụng cho cơ chế điều khiển chương trình mà không xác định các chi tiết bên trong. 4.3.2. Làm mịn (Refinement) Làm mịn là chiến lược thiết kế trên xuống. Kiến trúc của một chương trình được phát triển bằng cách các mức làm mịn liên tiếp các thủ tục. Trong mỗi bước, một hay nhiều lệnh của chương trình đã cho được phân rã thành những lệnh chi tiết hơn. Việc phân rã hay làm mịn liên tiếp các đặc tả này kết thúc khi tất cả các lệnh đã được diễn đạt dưới dạng bất kỳ ngôn ngữ lập trình hay ngôn ngữ máy tính nền tảng nào. Khi các nhiệm vụ đã được làm mịn thì dữ liệu cũng phải được làm mịn, được phân rã hay cấu trúc lại.
47. Cần chú ý là mọi bước làm mịn đều kéo theo những quyết định thiết kế nào đó. Người lập trình cần nhận biết các tiêu chuẩn nền tảng cho quyết định thiết kế và sự tồn tại của các giải pháp khác. 4.3.3. Tính module Phần mềm được chia thành các phần có tên riêng biệt và định địa chỉ được, gọi là các module. Các module được tích hợp để thỏa mãn yêu cầu của vấn đề. Gọi C(x) là hàm xác định độ phức tạp cảm nhận được của vấn đề x, và E(x) là hàm xác định nổ lực cần có để giải quyết vấn đề x. Với hai vấn đề p, q ta có Nếu C(p)>C(q) thì tổng quát ta suy ra E(p)>E(q) vì phải mất nhiều nổ lực hơn để giải quyết vấn đề khó hơn. Một đặc trưng được chỉ qua thực nghiệm là: C(p+q)>C(p)+C(q) Như thế, độ phức tạp cảm nhận của vấn đề tổ hợp p và q là lớn hơn độ phức tạp cảm nhận được khi tách biệt từng vấn đề p và q để xem xét. Kết hợp ta có E(p+q)>E(p)+E(q). Điều này dẫn đến kết luận chia để trị cho việc giải quyết các vấn đề phức tạp. Đây là một luận cứ cho tính module. Theo lập luận trên, liệu chúng ta chia phần mềm một cách không xác định thì nổ lực cần để phát triển nó sẽ trở thành nhỏ đến mức có thể bỏ qua được? Không may, câu trả lời là không vì lúc này sẽ xuất hiện các các lực khác như chi phí kết nối các module, chi phí xây dựng giao diện, làm tăng chi phí nổ lực để giải quyết vấn đề. 4.3.4. Kiến trúc phần mềm Kiến trúc phần mềm được suy dẫn ra qua tiến trình phân hoạch đặt mối quan hệ giữa các phần tử của giải pháp phần mềm với các bộ phận của thế giới thực được xác định không tường minh trong phân tích yêu cầu. Kiến trúc phần mềm gồm có hai đặc trưng quan trọng i. Cấu trúc phân cấp của các thành phần thủ tục (module): cấp bậc cây điều khiển. ii. Cấu trúc dữ liệu. Cấp bậc điều khiển
48. Cấp bậc điều khiển còn gọi là cấu trúc chương trình. Nó biểu thị cho cách tổ chức của các thành phần module. Một số chỉ số trên cây điều khiển được quan tâm: + Chiều rộng: độ trải rộng toàn bộ của điều khiển. + Độ sâu: chỉ báo về số mới điều khiển + Số module ra: là độ đo số các module trực tiếp bị điều khiển của một module khác. + Số module vào: số module trực tiếp điều khiển một module đã cho. + Thượng cấp: module điều khiển một module khác. + Thuộc cấp: một module bị module khác điều khiển. + Tính thấy được. + Tính nối được. + Tính cố kết, Cấu trúc dữ liệu Cấu trúc dữ liệu biểu diễn cho mối quan hệ logic giữa các phần dữ liệu riêng lẻ, một số cấu trúc dữ liệu thường sử dụng như: khoảng mục vô hướng, vector tuần tự, danh sách móc nối, không gian n chiều, cây cấp bậc, Ta xét phần mềm P cần giải quyết qua phần mềm và giải pháp phần mềm S được chọn như hình sau: S1 S2 P1 P2 P3 S3 P5 P4 S4 S5 Vấn đề P cần giải Giải pháp phần mềm quyết qua phần mềm S
49. Rõ ràng, khi giải quyết một vấn đề, chúng ta có nhiều giải pháp phần mềm. Mỗi giải pháp Si ta có một cấu trúc khác nhau. Xét bài toán P được cho như sau Bài toánP S2 S1 S2 S3 S1 S4 S3 S4 S1 S2 S3 S4 S5 S5 S5 Cấu trúc 1 Cấu trúc 3 Cấu trúc 2 Ta thấy, mỗi cấu trúc dựa trên nền tảng khác nhau về khái niệm thiết kế "tốt" và câu hỏi "cái nào tốt nhất" chúng ta rất khó để trả lời nếu không muốn nói là không trả lời được. Chi tiết của vần đề này được bàn chi tiết ở mục 4.6. 4.3.5. Che dấu thông tin Che dấu thông tin là khái niệm các module nên được đặc trưng bởi những quyết định thiết kế mà ẩn kín với mọi module khác, thông tin chứa trong module này không thể thâm nhập tới được từ các module khác không cần đến những thông tin đó. Che dấu thông tin kéo theo việc xác định một tập module độc lập mà trao đổi giữa các module chỉ là các thông tin thật sự cần thiết cho việc vận hành phần mềm. Che dấu thông tin là một tiêu chuẩn thiết kế đối với hệ thống module vì những lợi ích mà nó mang lại. Khi có sai sót xảy ra, sự thay đổi sẽ ít có khả năng lan truyền sang những vị trí khác bên trong phần mềm. Thiết kế module
50. Sự trừu tượng hóa và che dấu thông tin được dùng để thiết kế module. Bên trong cấu trúc chương trình, các module có thể được phân loại: + Module tuần tự: được tham khảo và thực hiện không bị ngắt + Module tăng trưởng: có thể bị ngắt trước khi hoàn tất và sau đó chạy lại tại thời điểm ngắt. + Module song song: thực hiện đồng thời với module khác. Với mỗi module cần có: + tính độc lập chức năng, + tính cố kết, + tính gắn nối,
51. Bài 5. KIỂM THỬ VÀ BẢO TRÌ PHẦN MỀM A. MỤC TIÊU CỦA BÀI - Hiểu được kiểm tra là quá trình tìm lỗi và nó là một đánh giá cuối cùng về các đặc tả, thiết kế và mã hoá;. - Thảo luận các chiến lược kiểm tra phần mềm và các kỹ thuật, phương pháp hiệu quả cho mỗi mức độ kiểm tra; B. NỘI DUNG 5.1. Độ tin cậy của phần mềm 5.1.1. Chất lượng phần mềm và việc đảm bảo chất lượng phần mềm Kiểm tra chất lượng phần mềm là một hoạt động khó khăn để chấp nhận về mặt ý thức vì chúng ta đang cân nhắc công việc của chúng ta hoặc của đồng nghiệp để tìm lỗi. Sau quá trình làm việc trong nhóm và trở thành thành viên, chúng ta ngại tìm ra lỗi và không phát hiện được ra chúng thông qua kiểm tra. Khi một người nào đó tiến hành kiểm tra lại không phải là thành viên của dự án, ví dụ một chuyên gia kiểm tra, họ được nhìn nhận như là một kẻ thù. Thêm vào đó, kiểm tra chất lượng phần mềm lại là một hoạt động khó được chấp nhận đối với việc quản lý vì nó tốn kém, mất thời gian và hiếm khi phát hiện được lỗi. Kết quả là phần lớn các ứng dụng không được kiểm tra đầy đủ và được phát hành với lỗi tiềm ẩn. Tuy vậy, chất lượng phần mềm cao là một mục tiêu quan trọng của nhóm phát triển phần mềm. Do vậy, cần và phải đảm bảo các tiêu chuẩn của phần mềm như đã đề cập ở chương 2. Đảm bảo chất lượng phần mềm là một hoạt động có hệ thống và kế hoạch. Nó bao gồm nhiều nhiệm vụ liên kết với các hoạt động chính sau: + Áp dụng các phương pháp kỹ thuật, + Tiến hành các cuộc xét duyệt kỹ thuật chính thức, + Kiểm thử phần mềm, + Buộc tôn trọng các chuẩn, + Kiểm soat thay đổi,
52. + Đo chất lượng, + Báo cáo, lưu giữ kết quả. Theo chuẩn ANSI/IEEE, kế hoạch đảm bảo chất lượng phần mềm như sau: Mục đích của kế hoạch Tham khảo Quản lý Tổ chức Nhiệm vụ Trách nhiệm Tài liệu Mục đích Tài liệu công nghệ phần mềm cần thiết Các tài liệu khác Chuẩn, thực hành và quy ước Mục đích Quy ước Xét duyệt và kiểm toán Mục đích Các yêu cầu xét duyệt Xét duyệt yêu cầu phần mềm Xét duyệt thiết kế Kiểm chứng phần mềm và xét duyệt hợp lệ Kiểm toán chức năng Kiểm toán vật lý Kiểm toán trong tiến trình Xét duyệt quản lý Quản lý cấu hình phần mềm Báo cáo vấn đề và cách sửa chữa Công cụ, kỹ thuật và phương pháp luận Kiểm soát mã
53. Kiểm soát phương tiện Kiểm soát người cung cấp Thu thập bảo trì và ghi nhớ báo cáo Việc đảm bảo chất lượng phần mềm là một hoạt động bản chất cho bất kỳ nhóm phát triển phần mềm nào sản xuất ra phần mềm cho người sử dụng. 5.1.2. Độ tin cậy của phần mềm 5.1.2.1. Các lỗi thường gặp Khi phân tích chất lượng, phần mềm thường gặp một số lỗi như: + Lỗi chiến lược: ý đồ thiết kế sai + Phân tích các yêu cầu không đầy đủ hoặc lệch lạc + Hiểu sai về các chức năng + Vi phạm nguyên lý đối tượng + Lỗi tại các thủ tục chịu tải, đây là những lỗi nặng. + Lỗi lây lan: lỗi được truyền từ chương trình này sang chương trình khác + Lỗi cú pháp: viết sai quy định của ngôn ngữ. + Hiệu ứng phụ: lỗi xảy ra khi một đơn vị chương trình làm thay đổi giá trị của một biến ngoài ý kiến của lập trình viên. Các lỗi của phần mềm tuân theo nguyên lý mức độ lỗi: Mức chịu tải tăng theo chiều đi xuống: lỗi phát ra ở mức dưới được xem là nặng hơn ở mức trên. Lỗi nặng nhất nằm ở mức cao nhất (ý đồ thiết kế ) và ở mức thấp nhất (thủ tục chịu tải lớn nhất) Do vậy, khi phát triển phần mềm, cần đảm bảo nguyên lý an toàn là: Mọi lỗi dù nhỏ lớn đều phải được phát hiện ở một bước nào đó của chương trình, trước khi lỗi đó hoành hành. 5.1.2.2. Độ tin cậy của phần mềm Độ tin cậy của một hệ phần mềm là độ đo về mức độ tốt của các dịch vụ mà hệ cung cấp cho máy tính. Cần chú ý là người dùng không xét rằng các dịch vụ là quạn trọng như nhau: chẳng hạn một hệ điều khiển máy bay có thể rất, rất
54. hiếm khi thất bại, nhưng nếu chúng có thất bại gây ra tai nạn máy bay thì các người bị nạn và thân nhân người bị nạn không thể xem hệ đó là đáng tin. Độ tin cậy là một đặc trưng động của hệ thống, nó là một hàm của số các thất bại phần mềm. Một thất bại phần mềm là một sự kiện thi hành mà khi đó phần mềm hành xử không như người ta mong đợi. Chú ý rằng một thất bại phần mềm khác nột hư hỏng phần mềm. Hư hỏng phần mềm là một đặc trưng tĩnh, và nó sẽ gây ra thất bại phần mềm khi mà mã lỗi được thi hành với một tập hợp đặc biệt các thông tin vào. Các hư hỏng không phải luôn luôn xuất đầu lộ diện, vì vậy đọ tin cậy phụ thuộc vào việc sử dụng hệ thống như thế nào. Không thể đưa ra một phát biểu đơn giản và khái quát về độ tin cậy phần mềm. Các hư hỏng phần mềm không phải là các khuyết tật của chương trình. Một hành xử bất ngờ có thể xảy ra khi mà phần mềm phù hợp với các yêu cầu của nó, nhưng mà chính các yếu tố đó lại không đầy đủ. Các sai sót trong các tư liệu phần mềm cũng có thể dẫn đến các hành vi bất ngờ mặc dầu rằng phần mềm không có khiếm khuyết. Có công trình nghiên cứu đã chỉ ra rằng có thể rút bỏ 60% các khiếm khuyết mà chỉ có thể cải tạo được 3% độ tin cậy. Cũng có người đã chú ý rằng nhiều khiếm khuyết trong sản phẩm chỉ là kết quả của hàng trăm hoặc hàng nghìn tháng sử dụng. 5.1.2.3. Một số đánh giá vì độ tin cậy Đặc tả độ tin cậy phần mềm: gồm các bước + Phân tích hệ quả của các thất bại. + Chia các thất bại thành các nhóm khác nhau. + Thiết lập các yêu cầu về độ tin cậy bằng cách sử dụng các độ đo thích hợp cho từng loại. Đo độ tin cậy: theo một vài cách đo như sau + Xác suất thất bại tính theo đòi hỏi. + Tỷ lệ xuất hiện thất bại + Thời gian trung bình giữa hai thất bại kế tiếp nhau. + Độ đo mức sẵn sàng hoạt động của hệ.
55. Thử nghiệm tĩnh Mục tiêu chủ yếu của thử nghiệm tĩnh là xác định độ tin cậy của phần mềm chứ không phải là xác định các hư hỏng phần mềm. Quá trình thử nghiệm tĩnh liên quan đến 4 bước sau: i) Xác định độ đo thao tác phần mềm. Độ đo thao tác là một mẫu sử dụng phần mềm và xác định mẫu đó liên quan đến việc phát hiện các lớp thông tin vào của chương trình và ước tính xác suất của chúng. ii) Chọn ra hoặc sinh ra một tập các dữ liệu thử tương ứng với độ đo đó. iii) Áp dụng các trường hợp thử chương trình, ghi lại độ dài thời gian thi hành giữa mỗi cặp thất bại quan sát được. Thích hợp hơn là dùng thời gian thô, với đơn vị thời gian thích hợp cho độ đo mức tin cậy. iv) Tính toán độ đo mức tin cậy sau một số đáng kể (về mặt thống kê) các thất bại đã quan sát được. An toàn phần mềm Có những hệ thống mà thất bại của nó có thể gây ra một mối đe dọa tính mạng con người. Thí dụ về hệ thống an toàn sinh mệnh như vậy là hệ thống điều khiển máy bay. Có hai lớp phần mềm an toàn sinh mệnh. i) Các phần mềm an toàn sinh mệnh sơ cấp: các phần mềm lồng nhúng trong một hệ phần cứng dùng để điều khiển quá trình khác mà sự làm việc sai sót của nó có thể trực tiếp gây ra thương vong hoặc phá hủy môi trường sống của con người. ii) Các phần mềm an toàn sinh mệnh thứ cấp: các phần mềm có thể gián tiếp gây ra thương vong. Thí dụ hệ thống phần mềm trợ giúp thiết kế kỹ thuật, hệ thống cơ sở dữ liệu y tế liên quan đến các chất độc bảng A. Thử nghiệm khiếm khuyết Thử nghiệm chương trình có hai mục đích: thứ nhất là chỉ ra rằng hệ thống là phù hợp với các đặc tả của nó, thứ hai là thực hành hệ thống theo một cách sao cho các khuyêt tật được phơi ra. Các thử nghiệm với mục đích thứ nhất
56. chính là các thẩm định, nó là các thử nghiệm để chấp nhận. Các thử nghiệm cho mục đích thứ hai lại khác hẳn: thử nghiệm thành công nhất là thử nghiệm phơi ra được nhiều khuyết tật nhất. Các thử nghiệm có thể được phát triển song song với việc thiết kế và thực hiện bởi những người không dính dáng tới việc thiết kế. 5.1.2.4. Lập trình vì độ tin cậy Lập trình là một là một công đoạn phụ thuộc nhiều vào kỹ xảo cá nhân, sự chú ý đến các chi tiết và kiến thức về việc làm như thế nào để sử dụng các công cụ sẵn có theo cách thức tốt nhất. Nhu cầu các hệ thống đáng tin là đang tăng lên vì vậy cần có các kỹ thuật chuyên biệt nhằm đạt được một hệ thống tin cậy được. Hiện nay, có hai kỹ thuật để tăng độ tin cậy phần mềm khi viết các chương trình ứng dụng là: tránh lỗi và tha thứ lỗi. 1. Tránh lỗi Tất cả các kỹ sư phần mềm hẳn đều muốn sản ra các phần mềm không có lỗi. Một quá trình phát triển dựa vào việc phát hiện lỗi và trừ khử lỗi chứ không phải là tránh lỗi là một quá trình kém cõi và lỗi thời. Phần mềm không có lỗi ở đây là phần mềm tuân theo đúng đặc tả. Nói chung, nó có thể có lỗi trong đặc tả hoặc có thể không phản ánh đúng các nhu cầu của người sử dụng vậy là phần mềm không có lỗi không nhất thiết là các phần mềm luôn luôn hành xử như người dùng dự đoán. Việc phát triển phần mềm không có lỗi là một việc rất đắt đỏ, và khi mà một số lỗi đã được tháo khỏi chương trình thì giá cả cho việc tìm và tháo lỗi còn lại có xu hướng tăng theo hàm số mũ. Do đó một tổ chức có thể quyết định chấp nhận một vài lỗi còn lưu lại. Tính về mặt giá cả thì thà rằng chịu tiền chi trả cho các thất bại của hệ thống do các lỗi đó gây ra còn hơn là đi phát hiện tháo gỡ các lỗi đó trước khi phân phối. Tránh lỗi và phát triển phần mềm vô lỗi dựa trên: + Sản phẩm của một đặc tả hệ thống chính xác. + Chấp nhận một cách tiếp cận thiết kế phần mềm dựa trên việc che dấu thông tin và bao gói thông tin.
57. + Tăng cường việc duyệt lại trong quá trình phát triển và thẩm định hệ phần mềm. + Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình phát triển phần mềm. + Việc lập kế hoạch cẩn thận cho việc thử nghiệm hệ thống để trưng ra các lỗi mà các lỗi này chưa được phát hiện trong quá trình duyệt lại và để định lượng độ tin cậy của hệ thống. 2. Thứ lỗi Ngay với một hệ vô lỗi thì vẫn cần một tiện ích thứ lỗi: đó là vì có thể có các lỗi đặc tả. Một tiện ích thứ lỗi là cần thiết cho một hệ thống đáng tin cậy. Có bốn hoạt động cần phải tiến hành nếu hệ thống phải là thứ lỗi: + Phát hiện lỗi + Định ra mức độ thiệt hại + Hồi phục sau khi gặp lỗi. Hệ thống phải hồi phục về trạng thái mà nó biết là an toàn. Cũng có thể là chỉnh lý trạng thái bị hủy hoại (hồi phục tiến), cũng có thể là lui về một trạng thái trước mà an toàn (hồi phục lùi). + Chữa lỗi. Cải tiến hệ thống để cho lỗi đó không xuất hiện nữa. Trong nhiều trường hợp sự thất bại của phần mềm là tàng hình và gây ra bởi một tổ hợp đặc biệt của thông tin vào. 3. Xử lý bất thường Một sai loại nào đó hoặc một sự cố bất ngờ xuất hiện thì ta gọi chúng là một bất thường. Các bất thường có thể do phần cứng cũng có thể do phần mềm. Khi mà một bất thường không được dự đoán thì bộ điều khiển sẽ chuyển cho cơ chế xử lý bất thường hệ thống. Nếu một bất thường đã được dự đoán thì mã phải bao gồm cả việc phát hiện và việc xử lý bất thường đó. Hầu hết các ngôn ngữ lập trình là không có các tiện ích để phát hiện và xử lý bất thường. Các bất thường có thể được ghi lại bằng cách dùng một biến Logic nhằm chỉ ra rằng có một bất thường đã xuất hiện.
58. 4. Lập trình phòng thủ Lập trình phòng thủ là cách phát triển chương trình mà người lập trình giả định rằng các mâu thuẫn hoặc các lỗi chưa được phát hiện có thể tồn tại trong chương trình. Mã sẽ có phần kiểm tra trạng thái hệ thống sau khi biến đổi và phải đảm bảo rằng sự biến đổi trạng thái là kiên định. nếu phát hiện một mâu thuẫn thì việc biến đổi trạng thái là phải rút lại và trạng thái phải trở về trạng thái đúng đắn trước đó. Lập trình phòng thủ là một cách thứ lỗi, mà được tiến hành không cần bộ điều khiển thứ lỗi. Về cơ bản quá trình vẫn là: phát hiện lỗi, đánh giá lỗi, và phục hồi sau lỗi. Nói chung một lỗi gây ra một sự sụp đổ trạng thái: các biến trạng thái được gắn các trị không hợp luật. Ngôn ngữ lập trình như Ada cho phép phát hiện các lỗi đó ngay trong thời gian biên dịch. Tuy nhiên việc kiểm tra biên dịch chỉ hạn chế cho các giá trị tĩnh và một vài phép kiểm tra thời gian thực là không thể tránh được. Một cách để phát hiện lỗi trong chương trình Ada là dùng cơ chế xử lý bất thường kết hợp với đặc tả miền trị. Hồi phục lỗi là một quá trình cải biên không gian trạng thái của hệ thống sao cho hiệu ứng của lỗi là nhỏ nhất và hệ thống có thể tiếp tục vận hành, có lẽ là trong một mức suy giảm. Hồi phục tiến liên quan đến việc cố gắng chỉnh lại trạng thái hệ thống. Hồi phục lùi liên quan đến việc lưu trạng thái của hệ thống ở một trạng thái đúng đã biết. Hồi phục tiến thường là một chuyên biệt ứng dụng, mà kiến thức miền được sử dụng để tính ra các sự chỉnh lý có thể. Tuy nhiên có hai tình thế chung mà khi đó hồi phục tiến có thể thành công: 1) Khi dữ liệu mã đã bị sụp. Việc sử dụng mã hóa thích hợp bằng cách thêm các dữ liệu dư thừa vào dữ liệu cho phép sửa sai khi phát hiện lỗi. 2) Khi cấu trúc nối bị sụp. Nếu các con trỏ tiến và lùi đã có trong cấu trúc dữ liệu thì cấu trúc đó có thể tái tạo nếu như còn đủ các con trỏ chưa bị sụp. Hồi phục lùi là một kỹ thuật đơn giản liên quan đến việc duy trì các chi tiết của trạng thái an toàn và cất giữ trạng thái đó khi mà một sai đã bị phát hiện.
59. Hầu hết các hệ quản trị cơ sở dữ liệu đều có bộ phục hồi lỗi. Cơ sở dữ liệu chỉ cập nhật dữ liệu một khi giao dịch đã hoàn tất và không phát hiện được vấn đề gì. Nếu giao dịch thất bại thì cơ sở dữ liệu không được cập nhật. Một kỹ thuật khác là thiết lập các điểm kiểm tra thường kỳ mà chúng là các bản sao của trạng thái hệ thống. Khi mà một lỗi được phát hiện thì trạng thái an toàn đó được tái lưu kho từ điểm kiểm tra gần nhất. Không may là khi hệ thống dính líu tới nhiều quá trình hợp tác thì dãy các thao tác có thể là các điểm kiểm tra của các quá trình đó là không đồng bộ và để phục hồi thì mỗi quá trình phải lần trở lại trạng thái ban đầu của nó. 5.2. Kiểm tra và các chiến lược kiểm tra phần mềm 5.2.1. Đặc điểm của kiểm tra phần mềm Xác minh và thẩm định một hệ phần mềm là một quá trình liên tục xuyên suốt mọi giai đoạn của quá trình phần mềm. Xác minh và thẩm định là từ chung cho các quá trình kiểm tra để đảm bảo rằng phần mềm thỏa mãn các yêu cầu của chúng và các yêu cầu đó thỏa mãn các nhu cầu của người sắm phần mềm. Xác minh và thẩm định là một quá trình kéo dài suốt vòng đời. Nó bắt đầu khi duyệt xét yêu cầu. Xác minh và thẩm định có hai mục tiêu: i) Phát hiện các khuyết tật trong hệ thống. ii) Đánh giá xem hệ thống liệu có dùng được hay không? Sự khác nhau giữa xác minh và thẩm định là: i) Thẩm định: Xem xét cái được xây dựng có là sản phẩm đúng không? Tức là kiểm tra xem chương trình có được như mong đợi của người dùng hay không. ii) Xác minh: Xem xét cái được xây dựng có đúng là sản phẩm không? Như thế, xác minh là kiểm tra chương trình có phù hợp với đặc tả hay không. Như trên, kiểm tra là một quá trình của tìm kiếm lỗi. Một kiểm tra tốt có khả năng cao tìm kiếm các lỗi chưa được phát hiện. Một kiểm tra thành công là kiểm tra tìm ra các lỗi mới, một kiểm tra tồi là kiểm tra mà không tìm được lỗi. Có hai kiểu lỗi trong ứng dụng và các kiểm tra tốt sẽ xác định cả hai loại đó. Cụ thể:
60. Không làm những điều cần phải làm: lỗi bỏ sót thường xuất hiện đối với ứng dụng mới được phát triển. Làm những điều không cần làm: lỗi của lệnh đã cư trú trước trong các ứng dụng bảo trì. Các kiểm tra có mặt tại các mức khác nhau và được tiến hành bởi các cá nhân khác nhau trong quá trình phát triển ứng dụng. Các kiểm tra được tiến hành bởi đội ngũ dự án và kiểm tra được tiến hành bởi các cơ quan bên ngoài để chấp nhận ứng dụng. Các kiểm tra của đội dự án được gọi là kiểm tra phát triển (Development test). Kiểm tra phát triển bao gồm kiểm tra đơn vị, kiểm tra hệ thống con, kiểm tra tích hợp và các kiểm tra hệ thống. Kiểm tra đơn vị (Unit test) được tiến hành cho mỗi đơn vị mã nhỏ nhất. Kiểm tra tích hợp (Subsystem integration test) kiểm tra mặt logic và xử lý cho phù hợp của các khối, kiểm tra việc truyền tin giữa chúng. Kiểm tra hệ thống (System test) đánh giá các đặc tả chức năng có được đáp ứng, các thao tác giao diện người có giống thiết kế không, và các công việc của ứng dụng trong môi trường thao tác mong muốn, đối với các ràng buộc. Các kiểm tra bởi các cơ quan bên ngoài được gọi là đảm bảo chất lượng (Quality assurance-QA) và kiểm tra chấp nhận (Acceptance test). Người ngoài có thể là người sử dụng hoặc đại diện người dùng, nó tạo một mục đích, đánh giá khách quan về ứng dụng và cơ quan bên ngoài được coi là có mục đích hơn các thành viên nhóm. Kiểm tra đảm bảo chất lượng tương tự các kiểm tra hệ thống về mặt mục đích và tiến hành, nhưng nó khác là họ nằm ngoài sự điều khiển của dự án trưởng. Các báo cáo kiểm tra đảm bảo chất lượng được gửi thường xuyên tới nhóm phát triển và quản lý dự án. Các kiểm tra viên đảm bảo chất lượng lập kế hoạch cho chiến lược của mình và tiến hành kiểm tra để đảm bảo các ứng dụng thực hiện tất cả các chức năng cần thiết. Kiểm tra đảm bảo chất lượng là kiểm tra cuối cùng được làm trước khi ứng dụng được đưa sản xuất đại trà.
61. Quan hệ giữa các mức kiểm tra và các giai đoạn trong vòng đời của chương trình được trình bày như sau: Các giai đoạn phát triển ứng Các kiểu kiểm tra dụng Phạm vi và mục tiêu QA/Kiểm tra chấp thuận Yêu cầu chức năng/Thiết kế Kiểm tra hệ thống logic Thiết kế vật lý Kiểm tra tích hợp Đặc tả mô hình cấu trúc chương Kiểm tra đơn vị trình Mã hoá module/chương trình Mỗi mức kiểm tra đòi hỏi xác định chiến lược kiểm tra. Chiến lược kiểm tra hộp trắng hoặc kiểm tra hộp đen. Dữ liệu vào được tạo theo thiết kế để sinh ra các dữ liệu ra khác nhau mà không chú ý tới các chức năng logic thực hiện thế nào. Các kết quả được dự đoán và so sánh với các kết quả thực tế để đánh giá mức độ thành công. Chiến lược White-box mở hộp và nhìn vào các logic đặc tả của ứng dụng để kiểm tra nó làm thế nào. Kiểm tra sử dụng các đặc tả logic để tạo ra các xử lý khác nhau và dự đoán các kết quả ra. Các kết quả trung gian và đầu ra cuối cùng có thể dự đoán và định lượng nhờ kiểm tra white-box. Chiến lược kiểm tra top–down hay bottom–up: xác định các kiểm tra và phát triển mã sẽ được tiến hành như thế nào: Kiểm tra top–down cho rằng mã điều khiển tới hạn và các chức năng sẽ được phát triển và kiểm tra đầu tiên. Tiếp theo là các chức năng thứ cấp và các hàm hỗ trợ. Lý thuyết là càng có nhiều module tới hạn được kiểm tra, thì càng ổn định về chương trình.
62. Kiểm tra bottom–up cho rằng càng ít thay đổi trong các module khả năng sinh lỗi càng ít. Toàn bộ các module được mã và đơn vị được kiểm tra. Sau đó kiểm tra được tiến hành ở mức độ tích hợp. Các chiến lược kiểm tra không loại trừ lẫn nhau, chúng có thể được sử dụng đơn lẻ hoặc đồng thời. Lý tưởng là kiểm tra cho một ứng dụng bao gồm nhiều chiến lược để phát hiện được hết các lỗi. Sau khi chiến lược đã được xác định, nó được áp dụng để tạo các trường hợp kiểm tra cụ thể. Test case: là các giao dịch riêng biệt hoặc các bản ghi dữ liệu tạo các logic được kiểm tra. Cho mọi trường hợp kiểm tra tất cả các kết quả của xử lý được dự đoán. Đối với ứng dụng on-line và off-line tài liệu hoá, test scripts các hội thoại tạo ra giữa người dùng và ứng dụng và các thay đổi từ hội thoại. Test plan: tư liệu hoá các chiến lược, kiểu, các trường hợp và mô tả cho kiểm tra vài khối ứng dụng. Tất cả các kế hoạch tạo thành kế hoạch tổng thể cho ứng dụng. Kiểm tra được lặp lại cho đến khi không còn lỗi, hoặc đạt được mức độ chấp nhận. Bước đầu tiên của xử lý kiểm tra, đầu vào kiểm tra, cấu hình và mã ứng dụng được đòi hỏi để tạo các kiểm tra. Bước thứ hai là so sánh các kết quả kiểm tra với kết quả dự tính và định lượng sự khác biệt. Bước tiếp theo là loại trừ các lỗi, hoặc gỡ rối mã. Khi việc mã hoá lại hoàn thành, kiểm tra lại được tiến hành. Quá trình tiến hành kiểm tra bắt đầu từ khi thiết kế. Cộng tác viên thực hiện việc kiểm tra nên có khả năng của phân tích viên và lập trình viên để có thể hiểu các đòi hỏi của ứng dụng và kiểu cách tiến hành kiểm tra. Chương trình càng lớn và phức tạp thì càng cần người có kinh nghiệm, đôi khi cần có một đội ngũ kiểm tra. Đội ngũ kiểm tra sử dụng yêu cầu chức năng từ giai đoạn phân tích và đặc tả chương trình, đặc tả thiết kế từ giai đoạn thiết kế như là đầu vào để phát triển chiến lược kiểm tra hệ thống. Khi chiến lược đã được hoàn tất, các buổi thảo luận được tiến hành để kiểm tra lại chiến lược và thông báo tới toàn thể đội. Các
63. nhiệm vụ tại các mức sẽ được ấn định. Thời gian được ước lượng. Đội ngũ kiểm tra làm việc độc lập và song song với đội ngũ lập trình. Họ làm việc với quản trị CSDL để phát triển cơ sở dữ liệu mà có thể hỗ trợ tất cả các mức kiểm tra. Đối với kiểm tra đơn vị, đội kiểm tra kiểm tra kết quả, các chấp nhận các module và chương trình cho kiểm tra tích hợp (integration test). Đội ngũ kiểm tra tiến hành và định lượng các kiểm tra tích hợp và kiểm tra hệ thống. 5.2.2. Chiến lược kiểm tra phần mềm Như đã nói ở trên, có hai kiểu chiến lược kiểm tra. Kiểu thứ nhất liên quan logic được kiểm tra thế nào trong ứng dụng. Chiến lược kiểm tra logic có thể là black-box hoặc white-box. Chiến lược kiểm tra black-box cho ràng module của chương trình hoặc hệ thống liên quan tới đầu vào và đầu ra. Các chi tiết logic chi tiết được che dấu và không cần phân tích. Chiến lược black-box có tính hướng dữ liệu. White-box hướng tới việc cho rằng logic đặc trưng là quan trọng và cần phải kiểm tra. White-box đánh giá một vài hoặc tất cả mặt logic để kiểm tra được tính đúng đắn của chức năng. White-box hướng về logic - giải thuật. Kiểu thứ hai liên quan tới việc kiểm tra được tiến hành thế nào, không quan tâm chiến lược kiểm tra logic. Nó là top-down hoặc bottom-up. Top-down coi chương trình chính là quan trọng nhất nên cần phải phát triển và kiểm tra trước và tiếp tục trong quá trình phát triển. Bottom-up cho rằng các module và chương trình riêng sẽ được phát triển hoàn toàn như standalone. Vậy chúng được kiểm tra riêng rẽ sau đó được kết hợp thành kiểm tra tổ hợp. 5.2.2.1. Kiểm tra Black-box Kiểm tra hộp đen, black-box, coi xử lý kết quả như là minh chứng bởi dữ liệu. Khái niệm kiểm tra là black-box không quan tâm logic. Khuynh hướng này hiệu quả đối với các modul chức năng đơn và các hệ thống cấp cao. Ba phương pháp chính là: Phân hoạch cân bằng: Mục đích của phương pháp này là tối thiểu các trường hợp kiểm tra cho trước, các mục dữ liệu vào được chia thành các nhóm dữ liệu có vai trò cân bằng nhau, mỗi nhóm đại diện cho một tập dữ liệu. Nguyên tắc là bằng cách kiểm tra triệt để một mục của mỗi tập hợp, chúng ta có
64. thể chấp nhận tất cả các mục tương đương khác của tập hợp đó cũng sẽ được kiểm tra một cách kỹ càng. Phân tích cực biên: Phân tích giá trị cực biên là một dạng nghiêm ngặt của phân hoạch cân bằng có sử dụng các giá trị biên hơn là bất cứ giá trị nào trong tập cân bằng. Ví dụ: miền giá trị của tháng là 1 – 12 và ngoài là 0 và 13. Thì 4 kiểm tra ứng với bốn trường hợp sẽ được kiểm tra phân tích cực biên thường xuyên được dùng tại các mức modul để xác định các mục dữ liệu đặc trưng cho testing. Đoán lỗi: Dựa trên cơ sở trực giác và kinh nghiệm, các chuyên gia có thể dễ dàng kiểm tra các điều kiện lỗi bằng cách đoán cái nào dễ xảy ra nhất. Ví dụ, chia 0, nếu modul có phép chia, nên dùng phép chia 0. Vì dựa trên trực giác, nên phép thử này khó tìm hết các lỗi. Một nhược điểm của phân hoạch cân bằng và phân tích cực biên là tổ hợp của các miền hợp không được xác định. Để bổ sung, người ta dùng sơ đồ nguyên nhân – kết quả (Cause – Effect Graphing). Sơ đồ nguyên nhân – kết quả chỉ ra các đầu ra và thông tin di chuyển như là hệ quả và các đầu vào gây ra hệ quả trên. Các ký hiệu graphic xác định tương tác, lựa chọn, logic và các điều kiện tương đương. Một vòng đại diện một dãy các thao tác không có điểm quyết định hoặc điều khiển. Mỗi dòng biểu diễn một lớp cân bằng của dữ liệu và các điều kiện sử dụng nó. Mỗi lần graph được thực hiện thì ít nhất một giá trị có nghĩa và một không có nghĩa cho mỗi tập được thử. 5.2.2.2. White-box testing Có ba loại kiểm tra hộp trắng là kiểm tra logic -logic test, chứng minh toán học - mathematical proof và Cleanroom testing. 1. Logic test Logic test có thể được chi tiết đến mức lệnh. Trong khi thực hiện của mọi lệnh là mục đích đáng khen ngợi, nó có thể không kiểm tra tất cả các điều kiện thuộc chương trình. Ví dụ, ít nhất 2 kiểm tra cho một kiểm tra 2 điều kiện (1 đúng và 1 sai). Cố gắng kiểm tra tất cả các điều kiện lẽ dĩ nhiên là không thể thực hiện
65. được về thực tiễn. Ví dụ trong 1 module có 10 thao tác qua 4 vòng lặp thì có 5,5 triệu trường hợp kiểm tra. Do đó phải có phương pháp lựa chọn. Logic kiểm tra nhìn vào mỗi quyết định trong module và sản sinh các dữ liệu để tạo tất cả các kết quả ra có thể. Có một vấn đề với logic test tại mức này là chúng không test tình trạng của module đối với đặc tả. Nếu kiểm tra được phát triển dựa trên đặc tả, mà đặc tả được dịch khác nhau bởi người lập trình thì kiểm tra sẽ không đúng. Giải pháp là đòi hỏi đặc tả chương trình đủ chi tiết và logic. Điều này có thể phù hợp với ngôn ngữ thế hệ 1 và 2. Các kiểm tra nhiều điều kiện tạo mỗi kết quả ra của tiêu chuẩn đa quyết định và nhiều điểm vào module. Các kiểm tra đòi hỏi việc phân tích xác định được bên quyết định đa tiêu chuẩn. Nếu các biên được xác định không chính xác, thì kiểm tra không hiệu quả. Khi được thiết kế phù hợp, test logic đa điều kiện có thể tối thiểu hoá các trường hợp kiểm tra để kiểm tra nhiều nhất các điều kiện. Sự sử dụng kỹ thuật này đòi hỏi luyện tập và kỹ năng. 2. Chứng minh bằng toán học Một phương pháp theo cách tiếp cận giảm thiếu sót về 0 là áp dụng suy diễn toán học cho đòi hỏi logic, chứng minh tính đúng đắn của chương trình. Phương pháp này đòi hỏi đặc tả ngôn ngữ dạng hình thức. Kỹ thuật chứng minh tính đúng đắn của chương trình được đề cập ở 6.4. 3. Cleanroom testing Cleanroom testing là mở rộng của phương pháp chứng minh bằng toán học. Lý thuyết của kỹ thuật này là bằng cách ngăn chặn các lỗi tại các đầu vào của quá trình xử lý, giá thành sẽ giảm, độ tin cậy tăng lên và tiệm cận tới không có lỗi. Phương pháp này được phát triển tại IBM đầu những năm 1980 bởi Mills, Dyer, Linger. Các đặc tả hình thức được dùng và việc kiểm tra thủ công được tiến hành bởi các đội kiểm tra. Các chương trình khó đọc sẽ được viết lại và kiểm tra hoàn toàn trên giấy. Cleanroom testing là kỹ thuật kiểm tra toán học hình thức và hội ý (walkthrough). Mục đích là phân tích mọi module thành các chức năng và liên