Giáo trình tóm tắt Công nghệ phần mềm

Nội dung text: Giáo trình tóm tắt Công nghệ phần mềm

1. Giáo trình tóm tắt Công Nghệ Phần Mềm Giáo trình tóm tắt Công nghệ phần mềm 1
2. Giáo trình tóm tắt Công Nghệ Phần Mềm MỤC LỤC MỞ ĐẦU 6 CHƯƠNG 1. PHẦN MỀM VÀ KỸ NGHỆ PHẦN MỀM 7 1. Phần mềm 7 1.1 Khái niệm phần mềm 7 1.2 Quá trình tiến hoá của phần mềm 7 1.3 Các đặc trưng của phần mềm 8 1.4 Phân loại phần mềm 9 1.5 Các thành phần của phần mềm 10 1.6 Việc ứng dụng phần mềm 16 1.7 Các thách thức đối với phần mềm máy tính 17 2. Kỹ nghệ phần mềm 18 2.1 Định nghĩa 18 2.2 Cách tiếp cận 1: Mô hình vòng đời cổ điển 18 2.3 Cách tiếp cận 2: Mô hình làm bản mẫu 20 2.4 Cách tiếp cận 3: Mô hình xoắn ốc 21 2.5 Cách tiếp cận 4: Kỹ thuật thế hệ thứ tư 22 2.6 Cách tiếp cận 5: Tổ hợp các khuôn cảnh 24 3. Các giai đoạn trong tiến trình kỹ nghệ phần mềm 25 3.1 Giai đoạn xác định: 25 3.2 Giai đoạn phát triển 25 3.3 Giai đoạn bảo trì 25 CHƯƠNG 2. PHÂN TÍCH YÊU CẦU VÀ ĐẶC TẢ PHẦN MỀM 27 1. Người phân tích 27 2. Nhiệm vụ phân tích yêu cầu 27 3. Việc hình thành các yêu cầu Error! Bookmark not defined. 4. Xác định các yêu cầu 30 5. Đặc tả phần mềm 30 5.1 Cách đặc tả và biểu diễn 31 5.1.1 Đặc tả 31 5.1.2 Biểu diễn 31 5.2 Các nguyên lý đặc tả 32 5.3 Các mức trừu tượng của đặc tả 35 5.4 Đặc tả yêu cầu 35 5.4.1 Những hạn chế của việc đặc tả bằng ngôn ngữ tự nhiên 36 5.4.2 Các yêu cầu phi chức năng 36 5.4.3 Khó khăn của việc xác định đặc tả yêu cầu 36 5.4.4 Thẩm định yêu cầu 37 5.5 Dàn bài đặc tả yêu cầu phần mềm 37 5.6 Xét duyệt đặc tả 38 2
3. Giáo trình tóm tắt Công Nghệ Phần Mềm 5.6.1 Mức vĩ mô 38 5.6.2 Mức chi tiết 39 6. Kỹ nghệ hệ thống và tạo nguyên mẫu 40 6.1 Kỹ nghệ hệ thống 40 6.1.1 Các hoạt động cơ bản trong tiến trình phân tích hệ thống 40 6.1.2 Đặc tả hệ thống 42 6.2 Tạo nguyên mẫu (prototype) 45 6.2.1 Lợi ích của việc phát triển nguyên mẫu 45 6.2.2 Các giai đoạn trong việc phát triển nguyên mẫu 46 6.2.3 Tạo nguyên mẫu trong tiến trình phần mềm 46 6.2.4 Hạn chế của cách tiếp cận tạo nguyên mẫu 47 6.2.5 Các bước tiến hành làm nguyên mẫu phần mềm 48 6.2.6 Các phương pháp và công cụ làm nguyên mẫu 49 CHƯƠNG 3. THIẾT KẾ PHẦN MỀM 51 1.Thiết kế phần mềm 51 1.1 Thiết kế phần mềm trong kỹ nghệ phần mềm 51 1.2 Các giai đoạn trong thiết kế phần mềm 52 1.3 Quá trình thiết kế 52 I.3.1 Các hoạt động thiết kế 52 1.3.2 Việc mô tả thiết kế 54 1.4 Phương pháp thiết kế 55 1.4.1 Phương pháp thiết kế 55 1.4.2 Các khái niệm nền tảng cho thiết kế 56 1.4.3 Các chiến lược thiết kế 64 1.4.3.1 Thiết kế chức năng 64 1.4.3.2 Thiết kế hướng đối tượng 64 1.4.4 Chất lượng thiết kế 65 1.4.4.1 Sự kết dính (Cohension) 65 1.4.4.2 Sự ghép nối (Coupling) 66 1.4.4.3 Sự hiểu được (Understandability) 66 1.4.4.4 Sự thích nghi được (Adaptability) 67 2. Thiết kế hướng đối tượng (Object Oriented Design) 67 2.1 Cách tiếp cận hướng đối tượng 67 2.2 Đặc trưng của thiết kế hướng đối tượng 68 2.3 Các ưu nhược điểm của thiết kế hướng đối tượng 68 2.4 Phân biệt giữa thiết kế hướng đối tượng và lập trình hướng đối tượng 68 3. Thiết kế hướng cấu trúc 68 3.1 Cách tiếp cận hướng cấu trúc 68 3.2 Biểu đồ luồng dữ liệu 69 3.3 Lược đồ cấu trúc 70 3
4. Giáo trình tóm tắt Công Nghệ Phần Mềm 3.4 Từ điển dữ liệu 70 4. Giao diện người sử dụng 71 4.1 Nhân tố con người và tương tác người máy 71 4.2 Thiết kế giao diện người - máy 72 4.2.1. Mô hình thiết kế giao diện 72 4.2.2. Phân tích và mô hình hóa nhiệm vụ trong thiết kế giao diện 73 4.2.3. Các vấn đề trong thiết kế giao diện 73 4.2.3.1 Thời gian hệ thống đáp ứng 73 4.2.3.2 Tiện nghi giúp đỡ người dùng 74 4.2.3.3 Giải quyết thông tin lỗi 74 4.2.3.4 Gắn nhãn chỉ lệnh 75 4.2.4. Công cụ cài đặt 75 4.2.5. Tiến hóa thiết kế 76 4.3. Hướng dẫn thiết kế giao diện 77 4.3.1 Tương tác chung 77 4.3.2 Hiển thị thông tin 78 4.3.3 Vào dữ liệu 79 4.4 Chuẩn giao diện 79 5. Tài liệu thiết kế phần mềm 80 CHƯƠNG 4. ĐẢM BẢO, KIỂM THỬ VÀ BẢO TRÌ PHẦN MỀM 84 1. Đảm bảo chất lượng phần mềm 84 1.1 Các nhân tố chất lượng phần mềm 84 1.2 Độ đo chất lượng phần mềm 86 1.2.1 Chỉ số chất lượng phần mềm 86 1.2.2 Khoa học phần mềm của HALSTEAD 87 1.2.3 Đo độ phức tạp của Thomas McCabe 89 1.3 Độ tin cậy phần mềm 90 1.4 Cách tiếp cận bảo đảm chất lượng phần mềm 91 1.4.1 Xem xét nhu cầu cho SQA 91 1.4.2 Lập kế hoạch SQA và các chuẩn 92 2. Kiểm thử phần mềm 93 2.1 Nền tảng của kiểm thử phần mềm 93 2.1.1 Mục đích kiểm thử 93 2.1.2 Luồng thông tin kiểm thử 94 2.2 Chiến lược kiểm thử phần mềm 94 2.2.1 Cách tiếp cận chiến lược tới kiểm thử phần mềm 94 2.2.2 Chiến lược kiểm thử phần mềm 95 2.2.3 Tổ chức việc kiểm thử phần mềm 96 2.2.3.1 Kiểm thử đơn vị 96 2.2.3.2 Kiểm thử tích hợp 97 4
5. Giáo trình tóm tắt Công Nghệ Phần Mềm 2.2.3.3 Kiểm thử hợp lệ 100 2.2.3.4 Kiểm thử hệ thống (System Test) 101 3. Bảo trì phần mềm 102 3.1 Định nghĩa về bảo trì phần mềm 102 3.2 Các đặc trưng bảo trì 103 3.2.1 Bảo trì có cấu trúc so với phi cấu trúc 103 3.2.2 Chi phí bảo trì 104 3.3 Tổ chức bảo trì 105 3.4 Luồng sự kiện 105 3.5 Bảo trì chương trình xa lạ 107 CHƯƠNG 5. LẬP TRÌNH HIỆU QUẢ 110 1. Các đặc trưng ngôn ngữ lập trình 110 1.1 Đặc trưng tâm lý của ngôn ngữ lập trình 110 1.2 Mô hình cú pháp và ngữ nghĩa 111 1.3 Hướng quan điểm kỹ nghệ 111 1.4 Việc chọn ngôn ngữ 112 1.5 Ngôn ngữ lập trình và kỹ nghệ phần mềm 113 2. Nền tảng của ngôn ngữ lập trình 114 2.1 Kiểu dữ liệu và định kiểu dữ liệu 114 2.2 Chương trình con 114 2.3 Cấu trúc điều khiển 115 2.4 Cách tiếp cận hướng đối tượng 115 2.5 Các lớp ngôn ngữ 115 2.6 Các công cụ lập trình 116 2.6.1 Công trình phần mềm có máy tính hỗ trợ 116 2.6.2 Môi trường phát triển phần mềm 117 3 Phong cách lập trình 118 3.1 Tài liệu chương trình 118 3.2 Khai báo dữ liệu 119 3.3 Xây dựng câu lệnh 120 3.4 Vào/ra 120 4 Tính hiệu quả 121 4.1 Kỹ thuật lập trình hướng hiệu qủa 121 4.2 Một vài hướng dẫn lập trình hướng hiệu quả 124 5 Thẩm định và xác minh 125 5.1 Đại cương về việc thẩm định và xác minh 125 5.2 Sơ lược về tiến trình kiểm thử phần mềm 126 TÀI LIỆU THAM KHẢO 1 5
6. Giáo trình tóm tắt Công Nghệ Phần Mềm MỞ ĐẦU Sau gần nửa thế kỷ phát triển, ngành kỹ nghệ phần mềm (SE – Software Engineering) đến nay đã được thừa nhận là một bộ môn chính thống. Các phương pháp, thủ tục và công cụ kỹ nghệ phần mềm đã được chấp nhận và ứng dụng thành công trong rất nhiều lĩnh vực công nghiệp. Các nhà quản lý và chuyên gia công nghệ thông tin đều nhận ra nhu cầu về cách tiếp cận có nguyên tắc hơn tới việc phát triển phần mềm. Mục đích của ngành kỹ nghệ phần mềm không phải là việc sản sinh ra phần mềm cụ thể mà là việc sản sinh ra các sản phẩm một cách hiệu quả với hạn chế về nguồn lực và thời gian. Giáo trình Nhập môn Kỹ nghệ phần mềm trang bị cho sinh viên khoa Công nghệ thông tin những khái niệm cơ bản về phần mềm và cách chế tạo phần mềm; giúp sinh viên tiếp cận có nguyên tắc hơn tới việc phát triển phần mềm thông qua các phương pháp, thủ tục và công cụ của kỹ nghệ phần mềm và cuối cùng là xây dựng phần mềm một cách hiệu quả. 6
7. Giáo trình tóm tắt Công Nghệ Phần Mềm CHƯƠNG 1 PHẦN MỀM VÀ KỸ NGHỆ PHẦN MỀM 0.Đối tượng nghiên cứu của môn học Mục đích của môn học “Công nghệ phần mềm” không phải là để sản sinh ra phần mềm cụ thể mà nó liên quan đến việc sản sinh ra sản phẩm một cách hiệu quả. Môn học trang bị cho học viên :  những khái niệm cơ bản về phần mềm  cách chế tạo phần mềm;  các phương pháp, các thủ tục và công cụ phát triển phần mềm để xây dựng phần mềm một cách hiệu quả. I. Phần mềm- Software 1.1 Khái niệm phần mềm Phần mềm là một sản phẩm có 3 thành phần chính : - Các mã lệnh, khi được thực hiện trên máy tính thì thực thi các hoạt động và đưa ra các kết quả mong muốn - Các cấu trúc dữ liệu hoặc cơ sở dữ liệu mà các mã lệnh sẽ thực thi trên chúng; - Các tài liệu mô tả thao tác và cách dùng phần mềm. 1.2 Quá trình tiến hoá của phần mềm 1.Những năm đầu (1950-1960) Trong những năm đầu của việc phát triển hệ thống máy tính, việc lập trình được coi là một "nghệ thuật" theo bản năng, chưa có phương pháp luận phát triển phần mềm. Phần mềm được thiết kế theo đơn đặt hàng cho từng ứng dụng. Môi trường phần mềm có tính cá nhân, việc thiết kế là một tiến trình thường được thực hiện trong đầu người lập trình và thường là không có tài liệu. 2.Giai đọan thứ hai (1960 - giữa những năm 1970) Các hệ thống đa chương trình(multi-programming) và đa nhiệm (multi-tasking) đã đưa ra những khái niệm mới về tương tác người – máy(Interactive Man-Machine), mở ra một thế giới mới cho các ứng dụng và các mức độ mới về độ tinh vi cho cả phần cứng và phần mềm. Các hệ thống thời gian thực có thể thu thập, phân tích và biến đổi dữ liệu từ nhiều nguồn khác nhau, do đó kiểm soát được các tiến trình và sản xuất ra "output" trong phần nghìn giây thay vì nhiều phút. Những tiến bộ trong lưu trữ trực tuyến dẫn tới thế hệ đầu tiên của các hệ quản trị cơ sở dữ liệu. Phần mềm đã được phát triển để phân phối theo quy mô rộng trong một thị trường nhiều bên tham dự. Khi số lượng các hệ thống dựa trên máy tính tăng lên thì thư viện phần mềm cũng bắt đầu mở rộng, hàng chục ngàn câu lệnh gốc chương trình được bổ sung hàng ngày. Một cuộc khủng hoảng phần mềm đã bắt đầu “ló dạng ở chân trời”: Tất cả những câu lệnh gốc này, những 7
8. Giáo trình tóm tắt Công Nghệ Phần Mềm chương trình này đều phải sửa lại khi người ta phát hiện ra lỗi, hoặc phải được sửa lại khi yêu cầu người dùng thay đổi, hoặc phải thích nghi với phần cứng vừa mua (gọi chung là bảo trì phần mềm); tuy nhiên, bản chất cá nhân của nhiều phần mềm làm cho chúng thực tế không thể bảo trì được. 3.Giai đọan thứ ba (giữa những năm 1970 - 1990) Xuất hiện hệ thống phân tán (là hệ thống nhiều máy tính, mỗi máy thực hiện một chức năng tương tranh và liên lạc với những máy khác) làm tăng dần độ phức tạp của hệ thống dựa trên máy tính. Mạng toàn cục(WAN), mạng cục bộ(LAN), các liên lạc số giải thông cao, và nhu cầu thâm nhập dữ liệu "lập tức" đã đặt ra những yêu cầu rất lớn cho người lập trình. Sự tiến bộ và sự phổ cập sử dụng các bộ vi xử lý, máy tính cá nhân và các máy trạm để bàn khá mạnh. Phần cứng giá rẻ nhanh chóng trở thành hàng hoá tiêu dùng. Chi phí cho phần mếm có khuynh hướng tăng lên so với chi phí mua phần cứng. 4.Giai đọan thứ tư (1990 đến nay) Kỹ nghệ hướng đối tượng (Object oriented) đang nhanh chóng thay thế nhiều cách tiếp cận phát triển phần mềm truyền thống trong các lĩnh vực ứng dụng. Xuất hiện các kỹ thuật mới làm thay đổi cách thức phát triển phần mềm, một trong các hướng đó là xây dựng phần mềm có khả năng tạo ra phần mềm. Hệ chuyên gia và phần mềm trí tuệ nhân tạo cuối cùng đã đưa vào ứng dụng thực tế. Phần mềm mạng nơ ron nhân tạo đã mở ra những khả năng nhận dạng và thực hiện những khả năng xử lý thông tin kiểu con người. 1.3 Các đặc trưng của phần mềm Phần mềm là sản phẩm của quá trình tư duy logic do đó nó có những đặc trưng khác biệt đáng kể so với phần cứng. 1. Phần mềm được phát triển hay được kỹ nghệ hoá, nó không được chế tạo theo nghĩa cổ điển. Chi phí phần mềm tập trung vào kỹ nghệ, nghĩa là các dự án phần mềm dường như là các dự án chế tạo. Vài thập kỷ qua, khái niệm "xưởng phần mềm" đã được đề cập nhiều, khái niệm này khuyến cáo về việc sử dụng các công cụ tự động hoá cho việc phát triển phần mềm. 2. Phần mềm không hỏng đi mà có thể bị lỗi thời Tuy nhiên, rõ ràng rằng, phần mềm không mòn cũ đi nhưng nó lại bị lạc hậu. Thực tế, phần mềm sẽ trải qua sự thay đổi và bảo trì. Khi thay đổi được thực hiện có thể phát sinh một số khiếm khuyết mới, có thể phần mềm bị thoái hoá do sự thay đổi. Khi một yếu tố của phần cứng mòn đi sẽ có "vật tư thay thế". Mọi hỏng hóc trong phần mềm đều chỉ ra lỗi trong quá trình thiết kế. Do vậy, việc bảo trì phần mềm bao gồm thêm độ phức tạp phụ đáng kể so với phần cứng. 3. Phần lớn phần mềm đều được xây dựng theo đơn đặt hàng, chứ ít khi được lắp ráp từ những thành phần có sẵn 8
9. Giáo trình tóm tắt Công Nghệ Phần Mềm Đối với phần mềm, nhìn chung các danh mục các thành phần phần mềm là không có sẵn. Có thể đặt hàng một đơn vị phần mềm hoàn chỉnh, chứ không phải là những thành phần có thể lắp ráp thành một chương trình mới. (Tuy nhiên điều này đang thay đổi nhanh chóng) 1.4 Phân loại phần mềm Nhóm 1: Các hệ điều hành - Các driver (chương trình điều khiển) - Các Monitor - Các hệ quản lý tệp - Các hệ thống quản lý thư viện chương trình và chương trình dịch - Các hệ thống quản lý mạng máy tính Nhóm 2: Các ngôn ngữ lập trình như PASCAL, C, C++, Visual Basic,FORTRAN, ADA v.v. Nhóm 3: Các phần mềm hệ thống - Các chương trình soạn thảo văn bản - Các chương trình điều khiển các thiết bị ngoại vi - Các chương trình mở rộng chức năng quản lý tệp: sắp xếp, sao chép, cập nhật . . . - Các chương trình đồ hoạ - Các giao diện thân thiện giữa người sử dụng và hệ điều hành Nhóm 4: Các hệ quản trị cơ sở dữ liệu, quản lý tri thức và các chương trình mở rộng tương ứng. Nhóm 5: Các phần mềm ứng dụng - Các chương trình xử lý dữ liệu đa năng - Các bộ chương trình phục vụ cho các yêu cầu tính toán cơ sở - Các chương trình tối ưu hoá - Các hệ chuyên gia và các hệ tương tự - Các hệ mô phỏng - Các lớp ngôn ngữ dữ liệu và tri thức phục vụ cho việc khai thác các cơ sở dữ liệu và tri thức. - Các hệ tự động hoá quản lý chương trình - Các hệ tự động hoá thiết kế - Các hệ thống dạy học - Các hệ thống tự học - Các hệ thống tự động phát sinh chương trình kiểm thử và sửa chương trình - Các hệ chương trình nhận dạng, phân tích và tổng hợp tiếng nói, hình ảnh, tín hiệu, - Các hệ chương trình điều khiển qui trình và các thiết bị công nghiệp Nhóm 6: Các chương trình tiện ích –Utilities và trò chơi Games - Các chương trình xử lý bảng tính điện tử 9
10. Giáo trình tóm tắt Công Nghệ Phần Mềm - Các chương trình chuyển đổi (tiền dịch) ngông ngữ, dịch chéo, khôi phục - Các chương trình chống và diệt virus máy tính - Các chương trình trò chơi giải trí 1.5 Các Các ngôn ngữ lập trình Phần mềm máy tính là thông tin tồn tại dưới hai dạng cơ bản: các thành phần máy không thực hiện được và các thành phần máy thực hiện được. Ta xét thành phần phần mềm được xây dựng bằng cách dùng một ngôn ngữ nhân tạo với vốn từ vựng hạn chế, một văn phạm xác định rõ cùng các quy tắc chặt chẽ về cú pháp, ngữ nghĩa. Các thuộc tính này là ngôn ngữ cho việc dịch thành mã máy. Các dạng ngôn ngữ đã và đang dùng hiện nay là: a) Ngôn ngữ máy : Ngôn ngữ máy (còn được gọi máy ngữ hay mã máy; tiếng Anh là machine language hay machine code) là một loại ngôn ngữ lập trình trong đó, mọi chỉ thị đều được biểu diễn bằng các con số nhị phân 0 và 1. Đây là ngôn ngữ lập trình thế hệ đầu tiên. Tuy khó đọc và khó sử dụng, nhưng ngôn ngữ máy là ngôn ngữ duy nhất mà bộ vi xử lí có thể nhận biết và thực hiện một cách trực tiếp (tức không cần dịch sang bất kì ngôn ngữ nào khác). Ngôn ngữ máy (mã máy) là ngôn ngữ nền tảng của bộ vi xử lý. Các chương trình được viết trong tất cả các loại ngôn ngữ khác cuối cùng đều được chuyển thành ngôn ngữ máy trước khi chương trình đó được thi hành. Lợi điểm của viết chương trình bằng ngôn ngữ máy là lập trình viên có thể điều khiển máy tính trực tiếp và đạt được chính xác điều mình muốn làm. Do đó, các chương trình ngôn ngữ máy được viết tốt là những chương trình rất hiệu quả (tốc độ thi hành nhanh, kích thước nhỏ). Bất lợi của chương trình ngôn ngữ máy là thông thường sẽ mất rất nhiều thời gian để viết, rất khó đọc, theo dõi để tìm lỗi. Thêm vào đó, bởi vì chương trình được viết bằng tập lệnh phụ thuộc vào từng bộ vi xử lý nên chương trình chỉ chạy được trên những máy tính có cùng bộ vi xử lý mà thôi. Ngôn ngữ máy cũng được gọi là ngôn ngữ cấp thấp (low-level language) Nếu phần mềm được viết tốt, bảo trì được và có tư liệu tốt thì ngôn ngữ máy có thể làm cho việc sử dụng bộ nhớ và tối ưu tốc độ thực hiện chương trình rất hiệu quả. Ví dụ tập lệnh của ngôn ngữ máy Minsk-32: 10 1000 1002 11 1000 1002 12 13 b).Hợp ngữ Assembler Hợp ngữ được phát triển nhằm giúp các lập trình viên dễ nhớ các chỉ thị của chương trình hơn. Hợp ngữ tương tự như ngôn ngữ máy nhưng lại sử dụng các ký hiệu gợi nhớ (mnemonics hay mã lệnh hình thức - symbolic operation code) để biểu diễn cho các mã lệnh của máy. Một đặc điểm khác nữa là hợp ngữ thông thường cho phép định địa chỉ hình thức (symbolic addressing), nghĩa là một vị trí bộ nhớ trong máy tính có thể được tham chiếu tới thông qua một cái tên hoặc ký hiệu, chẳng hạn như TOTAL thay vì phải sử dụng địa chỉ thực sự của nó (bằng con số nhị phân) trong ngôn ngữ máy. Các chương trình hợp ngữ còn bao gồm các chỉ thị vĩ mô (macro instruction) có thể tạo ra nhiều lệnh mã máy. Các chương trình hợp ngữ được chuyển sang mã máy thông qua một chương trình đặc biệt gọi là trình hợp dịch (assembler). Mặc dù hợp ngữ tương đối dễ dùng hơn mã máy nhưng hợp ngữ vẫn được xem là ngôn ngữ cấp thấp bởi vì nó vẫn còn rất gần với từng thiết kế của máy tính. Ví dụ một đọan lệnh assembler WRITE_HEX PROC NEAR 10
11. Giáo trình tóm tắt Công Nghệ Phần Mềm PUSH CX PUSH DX MOV DH,DL MOV CX,04 SHR DL,CL CALL WRITE_HEX_DIGIT MOV DL,DH AND DL,0Fh CALL WRITE_HEX_DIGIT POP DX POP CX RET WRITE_HEX ENOP PUBLIC WRITE_HEX_DIGIT c).Ngôn ngữ ký hiệu Ngôn ngữ AvtoCode- tương tự như Assembler d)Ngôn ngữ lập trình bậc cao: cho phép người lập trình viết chương trình theo ngôn ngữ gần giống với ngôn ngữ thông thường, không phụ thuộc vào từng máy tính cụ thể. Ngôn ngữ cấp cao gần gũi hơn với ý niệm ngôn ngữ mà hầu hết mọi người đều biết, nó bao gồm các danh từ, động từ, ký hiệu toán học, liên hệ và các thao tác luận lý. Các yếu tố này có thể được phối hợp, liên kết với nhau tạo thành một hình thức của câu. Các "câu" này được gọi là các mệnh đề của chương trình (program statement). Chính vì những đặc điểm này, các lập trình viên dễ dàng đọc và dễ học ngôn ngữ cấp cao hơn so với ngôn ngữ máy hoặc hợp ngữ. Một lợi điểm quan trọng là ngôn ngữ cấp cao thông thường không phụ thuộc vào máy tính, nghĩa là các chương trình viết bằng ngôn ngữ cấp cao có thể chạy trên các loại máy tính khác nhau (sử dụng các bộ vi xử lý khác nhau). cTuy đã có hàng trăm ngôn ngữ lập trình nhưng chỉ có một số trong số đó được dùng phổ biến, ví dụ: COBOL-kinh tế, FORTRAN-kỹ thuật, PASCAL,ALGOL(Algorithm Language), C, ADA, ngôn ngữ hướng đối tượng: C++, OBJECT PASCAL, EIFFEL, ngôn ngữ đặc thù: APL, LISP, OPS5, PROLOG, và các ngôn ngữ mô tả trong mạng nơ ron nhân tạo Mã máy, hợp ngữ, các ngôn ngữ lập trình cấp cao thường được coi là "3 thế hệ đầu" của ngôn ngữ máy tính. Với những ngôn ngữ này bản thân người lập trình phải quan tâm đến cả việc đặc tả cấu trúc thông tin lẫn điều khiển chương trình. Do vậy, các ngôn ngữ trong ba thế hệ đầu này còn được gọi là ngôn ngữ thủ tục. Với ngôn ngữ phi thủ tục, thay vì phải yêu cầu người lập trình xác định chi tiết thủ tục thì các ngôn ngữ phi thủ tục đưa đến một chương trình bằng cách xác định kết quả mong muốn, thay vì xác định hành động cần để đạt được kết quả đó". Phần mềm hỗ trợ sẽ dịch đặc tả thành 11
12. Giáo trình tóm tắt Công Nghệ Phần Mềm chương trình máy thực hiện được. Ngày nay các ngôn ngữ thế hệ thứ tư này đang được dùng trong các ứng dụng CSDL và các lĩnh vực xử lý dữ liệu nghiệp vụ khác. e)Ngôn ngữ trực quan- Visual Các ngôn ngữ lập trình thông dụng Mặc dù đã có hàng trăm ngôn ngữ lập trình được sinh ra, chỉ có một số ít là được sử dụng rộng rãi và được xem là một chuẩn công nghiệp. Các ngôn ngữ này đều có thể được sử dụng trên nhiều loại máy tính khác nhau. BASIC, viết tắt của cụm từ Beginner's All-Purpose Symbolic Instruction Code, được phát triển bởi John Kermeny và Thomas Kurtz vào năm 1964 tại trường đại học Dartmouth. Ban đầu, họ thiết kế BASIC là một ngôn ngữ lập trình đơn giản, có tính tương tác để các sinh viên học tập và sử dụng. BASIC đã trở thành một trong những ngôn ngữ lập trình thông dụng nhất được sử dụng trên các máy vi tính và máy tính mini ngày nay. ví dụ một đọan mã BASIC : 10 INPUT “DV A,B,C :”;A,B,C 20 D=B^2 – 4*A*C 30 IF D<0 THEN 80 40 X1=(-B+SQR(D))/(2*A) 50 X2=(-B-SQR(D))/(2*A) 60 PRINT “X1=”;X1;” X2=”;X2 70 END 80 ?”KHONG CO NGHIEM THUC” 90 END COBOL, viết tắt của COmmon Business Oriented Language, được giới thiệu vào năm 1960. Ðược hỗ trợ bởi bộ quốc phòng Hoa Kỳ, COBOL được phát triển bởi một hội đồng bao gồm các đại diện từ phía chính phủ và công nghiệp. Grace M.Hopper là người chính yếu trong hội đồng và được xem là nhà phát triển chính của ngôn ngữ COBOL. COBOL đã từng là một trong những ngôn ngữ được dùng rộng rãi nhất cho các ứng dụng thương mại. Bằng cách dùng một hình thức tựa tiếng Anh, các câu lệnh của COBOL được sắp xếp vào trong các câu và nhóm lại thành từng đoạn (paragraph). Hình thức tiếng Anh giúp COBOL dễ viết và đọc nhưng cũng làm cho chương trình nguồn dài hơn. COBOL rất tốt trong việc xử lý các tập tin lớn và thực hiện nhưng phép tính thương mại tương đối đơn giản. C, được phát triển bởi tác giả Dennis Ritchie tại phòng thí nghiệm Bell vào năm 1972. Ban đầu, C được thiết kế như là một ngôn ngữ để viết các phần mềm hệ thống, nhưng ngày nay, nó được xem là một ngôn ngữ công dụng chung. C là một ngôn ngữ lập trình mạnh mẽ đòi hỏi kỹ năng lập trình chuyên nghiệp mới có thể sử dụng hiệu quả được. Nhu cầu dùng C để phát triển nhiều loại phần mềm kể cả các ứng thương mại đang gia tăng. Các chương trình C thường được dùng với hệ điều hành Unix (phần lớn hệ điều hành Unix được viết bằng C). FORTRAN, viết tắt của FORmula TRANslator được phát triển bởi một nhóm lập trình viên của công ty IBM dưới sự lãnh đạo của John Backus. Công bố vào năm 1957, FORTRAN được thiết kế như là một ngôn ngữ lập trình dành cho các nhà khoa học, kỹ sư và toán học. FORTRAN được xem như là ngôn ngữ lập trình cấp cao đầu tiên và được chú ý bởi khả năng của nó cho phép dễ dàng diễn đạt và tính toán các phương trình toán học. 12
13. Giáo trình tóm tắt Công Nghệ Phần Mềm INTEGER A(10) DATA IMP/4/’thiết bị đưa ra DO 20 I=1,10 DO 10 J=1,10 10 A(I,J)=I*J 20 WRITE(IMP,30)A ‘đưa ra mảng 30 FORMAT1015/) ‘ định dạng cách dòng STOP END PASCAL, ngôn ngữ sẽ được sử dụng để giảng dạy trong giáo trình này, được phát triển vào năm 1968 bởi Niklaus Wirth, một nhà khoa học máy tính tại Zurich, Thụy Sĩ. Pascal được phát triển để giảng dạy lập trình. Tên Pascal không phải là từ viết tắt, đó là tên của một nhà toán học, Blaise Pascal (1623 - 1662) người đầu tiên tạo ra máy tính. Pascal, dùng trong cả máy tính cá nhân và máy tính lớn là một trong những ngôn ngữ lập trình đầu tiên được phát triển trong đó khuyến khích phương pháp lập trình cấu trúc. Các loại ngôn ngữ lập trình khác ALGOL (ALGOrithmetic Language). Ngôn ngữ lập trình cấu trúc dùng cho các ứng dụng khoa học và toán học. APL(A Programming Language). Một ngôn ngữ mạnh mẽ, dễ dùng, rất tốt trong việc xử lý dữ liệu được lưu dưới dạng bảng (ma trận) FORTH, tương tự như C, tạo ra các mã chương trình nhanh và hiệu quả. Ban đầu được phát triển để điều khiển kính viễn vọng không gian. LISP, LISt Processing, ngôn ngữ trí tuệ nhân tạo thông dụng. AutoLISP – dùng trong tự động hóa thiết kế 13
14. Giáo trình tóm tắt Công Nghệ Phần Mềm LOGO, chủ yếu được biết đến như là một công cụ để dạy khả năng giải quyết vấn đề. MODULA-3, tương tự như PASCAL. Dùng chủ yếu để phát triển các phần mềm hệ thống. PILOT, Programmed Inquiry Learning Or Teaching, dùng bởi các nhà giáo dục để viết các chương trình hướng dẫn CAD. PL/I, Programming Language/ One. Ngôn ngữ thương mại và khoa học phối hợp nhiều chức năng của FORTRAN và COBOL. PROLOG, PROgramming LOgic. Dùng trong trí tuệ nhân tạo. RPG, Report Program Generator. Dùng các mẫu đặc biệt để giúp người dùng xác định dữ liệu vào, dữ liệu ra và các yêu cầu tính toán của một chương trình. ADA, lấy tên của Augusta Ada Bryon, người được xem là đã viết chương trình đầu tiên, được thiết kế để phục vụ cho việc viết, bảo trì các chương trình lớn trong một khoảng thời gian dài. VISUAL BASIC Ví dụ : For i = 1 To 15 iArray(i) = i ^ 2 Next Dim FullMsg As String = "" For i = 1 To 15 FullMsg = FullMsg & "Phần tử thứ (" & CStr(i) & ")=" & CStr(iArray(i)) & vbCrLf Next txtArray.text = FullMsg Khái niệm về Trình thông dịch-Interpreter và biên dịch-compiler 14
15. Giáo trình tóm tắt Công Nghệ Phần Mềm Mọi chương trình được viết bằng các ngôn ngữ không phải là ngôn ngữ máy cuối cùng đều phải được chuyển đổi sang ngôn ngữ máy trước khi được thi hành. Chương trình ngôn ngữ cấp cao được dịch sang ngôn ngữ máy bằng một trong hai cách : bằng trình biên dịch (compiler) hoặc trình thông dịch (interpreter). Trình biên dịch (ví dụ ngôn ngữ VISUAL BASIC): Sẽ chuyển đổi toàn bộ chương trình sang mã máy, rồi chứa kết quả vào dĩa để có thể thi hành về sau. Chương trình ngôn ngữ cấp cao được chuyển đổi được gọi là chương trình nguồn (source program) và chương trình ngôn ngữ máy được tạo ra được gọi là chương trình đối tượng (object program) hoặc mã đối tượng (object code). Khi người dùng muốn chạy chương trình, chương trình đối tượng sẽ được nạp lên bộ nhớ chính của CPU và các chỉ thị của chương trình sẽ được thi hành. Khi được hướng dẫn bởi các chỉ thị của chương trình, CPU sẽ truy xuất dữ liệu và tạo ra các kết quả. Trình biên dịch sẽ kiểm tra cú pháp chương trình, thực hiện các phép kiểm tra logic và đảm bảo các dữ liệu sắp được sử dụng trong các phép so sánh, tính toán đã được định nghĩa một cách hợp lý ở một nơi nào đó trong chương trình. Một chức năng quan trọng của trình biên dịch là nó sẽ tạo ra một danh sách lỗi của tất cả mệnh đề trong chương trình vi phạm cú pháp của ngôn ngữ. Danh sách này giúp lập trình viên dễ dàng sửa đổi chương trình. Do ngôn ngữ máy phụ thuộc vào bộ vi xử lý nên các máy tính khác nhau sẽ cần có các trình biên dịch khác nhau đối với cùng một ngôn ngữ cấp cao. Ví dụ, một máy mainframe, máy mini và máy tính cá nhân cần có các trình biên dịch khác nhau để biên dịch cùng một chương trình nguồn sang mã máy của từng loại máy này. Trình thông dịch(ví dụ ngôn ngữ BASIC) : Thay vì chuyển đổi toàn bộ chương trình nguồn như trình biên dịch, trình thông dịch chỉ chuyển đổi một mệnh đề của chương trình và thực hiện đoạn mã kết quả ngay, sau đó nó tiếp tục chuyển đổi mệnh đề thứ 2 rồi thi hành đoạn mã kết quả thứ 2 và cứ thế. Khi sử dụng trình thông dịch, mỗi lần chạy chương trình là mỗi lần chương trình nguồn được thông dịch sang ngôn ngữ máy. Không có chương trình đối tượng nào được tạo ra. Các trình thông dịch thường được dùng trên các máy tính cá nhân không có đủ bộ nhớ hoặc sức mạnh tính toán cần thiết để dùng trình biên dịch. Lợi điểm của trình thông dịch là lập trình viên vẫn có thể chạy một chương trình vẫn còn lỗi cú pháp. Chỉ đến lúc thông dịch đến câu lệnh có lỗi cú pháp, quá trình thi hành chương trình mới bị ngừng lại và trình thông dịch sẽ thông báo lỗi. Ðiểm bất lợi là các chương trình thông dịch chạy không nhanh bằng các chương trình được biên dịch vì quá trình chuyển đổi sang ngôn ngữ máy được thực hiện cùng với quá trình thi hành chương trình. Vì lý do này, ngày nay, đa số các ngôn ngữ cấp cao đều dùng trình biên dịch. 15
16. Giáo trình tóm tắt Công Nghệ Phần Mềm 1.6 Việc ứng dụng phần mềm Phần mềm có thể được áp dụng khi đã có một tập các bước thủ tục (như một thuật toán) đã được xác định trước (trừ phần mềm chuyên gia và phần mềm mạng nơ ron). Nội dung thông tin và tính tất định là các nhân tố quan trọng trong việc xác định bản chất của ứng dụng phần mềm: - nội dung thông tin nói tới ý nghĩa và hình dạng của thông tin vào ra. - tính tất định thông tin nói tới việc tiên đoán trước trật tự và thời gian của thông tin. Có 7 loại phần mềm ứng dụng: 1. Phần mềm hệ thống: là một tập hợp các chương trình được viết để phục vụ các chương trình khác . Ví dụ như: trình biên dịch, trình soạn thảo, tiện ích quản lý tệp Phần mềm hệ thống xử lý cấu trúc thông tin phức tạp nhưng xác định. Nó được đặc trưng bởi tương tác chủ yếu tới phần cứng của máy tính, phục vụ nhiều người dùng, thao tác tương tranh, dùng chung tài nguyên, các quản lý tiến trình phức tạp, cấu trúc dữ liệu phức tạp và nhiều giao diện ngoài. 2. Phần mềm thời gian thực- Real Time: là phần mềm điều phối, phân tích, kiểm soát các sự kiện thế giới thực ngay khi chúng xuất hiện. Phần mềm thời gian thực bao gồm các yếu tố: một thành phần thu thập dữ liệu để thu và định dạng thông tin từ ngoài, một thành phần phân tích để biến đổi thông tin theo yêu cầu của ứng dụng, một thành phần kiểm soát hoặc đưa ra đáp ứng môi trường ngoài, một thành phần điều phối để điều hoà các thành phần khác sao cho có thể duy trì việc đáp ứng thời gian thực. Hệ thống thời gian thực phải đáp ứng trong những ràng buộc thời gian chặt chẽ. 3. Phần mềm nghiệp vụ: Xử lý thông tin nghiệp vụ là lĩnh vực ứng dụng phần mềm lớn nhất. Các hệ thống rời rạc như tính lương, kế toán, quản lý đã tiến hoá thành các hệ phần mềm quản lý thông tin (Management Information System). Những ứng dụng trong lĩnh vực này đã cấu trúc lại dữ liệu theo cách thuận tiện cho các thao tác nghiệp vụ. Ngoài ra phần mềm này còn bao gồm cả tính toán tương tác như xử lý giao tác cho các điểm bán hàng. 4. Phần mềm khoa học và công nghệ: Phần mềm này được đặc trưng bởi các thuật toán "máy nghiền số". Có các ứng dụng phức tạp: thiên văn, núi lửa, biến động quỹ đạo tàu con thoi, sinh học phân tử Thiết kế có máy tính trợ giúp (CAD – Computer Aided Design), mô phỏng hệ thống và những ứng dụng tương tác khác đã bắt đầu kế tục các đặc trưng thời gian thực và thậm chí cả phần mềm hệ thống. 5. Phần mềm nhúng: Nằm sâu trong các bộ nhớ chỉ đọc và được dùng để điều khiển các sản phẩm và hệ thống người tiêu dùng và thị trường công nghiệp. Phần mềm nhúng thực hiện các chức năng giới hạn và huyền bí như điều khiển bàn phím cho lò vi sóng, hoặc đưa ra các khả năng điều khiển vận hành có ý nghĩa như chức năng số hoá trong ô tô, kiểm soát xăng 6. Phần mềm máy tính cá nhân: Thị trường này đã bùng nổ trong suốt một thập kỷ qua: xử lý văn bản, trang tính, đồ hoạ, quản trị cơ sở dữ liệu (CSDL), v.v. Phần mềm máy tính cá nhân biều thị cho một số thiết kế giao diện người - máy được cải tiến nhiều nhất. 7. Phần mềm trí tuệ nhân tạo (AI - Artificial intelligence): Phần mềm AI dùng các thuật toán phi số để giải quyết các vấn đề phức tạp mà tính toán trực tiếp không thể giải quyết nổi. Hiện nay, mạnh nhất là các hệ chuyên gia (hay còn gọi là hệ cơ sở tri thức). Các ứng dụng khác như: nhận dạng, chứng minh định lý, trò chơi ; Hiện nay con có mạng nơ 16
17. Giáo trình tóm tắt Công Nghệ Phần Mềm ron nhân tạo đã phát triển, nó mô phỏng cấu trúc việc xử lý trong bộ óc để tạo ra một lớp phần mềm có thể nhận dạng các mẫu phức tạp. 1.7 Các thách thức đối với phần mềm máy tính - Sự tinh vi của phần cứng luôn đi trước khả năng xây dựng phần mềm đạt tới tiềm năng của phần cứng. - Khả năng xây dựng các chương trình mới không thể giữ cùng nhịp với các nhu cầu có chương trình mới. - Khả năng bảo trì cho các chương trình bị đe doạ bởi những bản thiết kế nghèo nàn và tài nguyên không thích hợp Để đáp ứng lại các vấn đề trên, việc thực hành kỹ nghệ phần mềm - chủ đề mà giáo trình này tập trung vào - đang được chấp nhận trong ngành công nghiệp phần mềm. 17
18. Giáo trình tóm tắt Công Nghệ Phần Mềm II. Kỹ nghệ phần mềm 2.0.Đối tượng môn học Kỹ nghệ phần mềm là việc thiết lập và sử dụng các nguyên lý công nghệ đúng đắn để thu được phần mềm một cách kinh tế vừa tin cậy, vừa làm việc hiệu quả trên các máy thực. 2.1 Định nghĩa Kỹ nghệ phần mềm gồm một tập ba yếu tố chủ chốt: - Phương pháp - Methods - Công cụ - Tools - Thủ tục – Procedures Các yếu tố này giúp người quản lý kiểm soát được tiến trình phát triển phần mềm, đồng thời cung cấp cho người hành nghề một nền tảng để xây dựng được một phần mềm chất lượng cao theo một cách thức hiệu quả. Chúng ta cùng xem xét tóm tắt từng yếu tố đó. 1. Các phương pháp kỹ nghệ phần mềm đưa ra các “cách làm” về mặt kỹ thuật để xây dựng phần mềm. Các phương pháp bao gồm các nhiệm vụ: lập kế hoạch và ước lượng dự án, phân tích yêu cầu hệ thống và phần mềm, thiết kế cấu trúc dữ liệu, kiến trúc chương trình và thủ tục thuật toán, mã hóa, kiểm thử và bảo trì; Các phương pháp kỹ nghệ phần mềm thường đưa ra các ký pháp đồ họa hay hướng ngôn ngữ đặc biệt và đưa ra một tập các tiêu chuẩn về chất lượng phần mềm. 2. Các công cụ kỹ nghệ phần mềm cung cấp sự hỗ trợ tự động hay bán tự động cho từng phương pháp nêu trên. Khi các công cụ được tích hợp đến mức có thể được dùng cho các công cụ khác de phát triển phần mềm - được gọi là Kỹ nghệ phần mềm có máy tính hỗ trợ (CASE - Computer Aided Software Engineering). 3. Các thủ tục kỹ nghệ phần mềm xác định: - trình tự các phương pháp sẽ được sử dụng - sản phẩm cần bàn giao (tài liệu, báo cáo, bản mẫu ) - các mốc thời gian để người làm phần mềm nắm được tiến độ 2.2. bốn cách tiếp cận cơ bản trong tiến trình phát triển phần mềm. Cách tiếp cận 1: Mô hình vòng đời cổ điển Hình 1.4 minh họa cho Mô hìnhvòng đời cổ điển (hay Khuôn cảnh vòng đời cổ điển) đối với kỹ nghệ phần mềm. Có tên gọi là “mô hình thác nước”, khuôn cảnh vòng đời yêu cầu một cách tiếp cận tuần tự đối với việc phát triển phần mềm. Nó bắt đầu ở mức hệ thống và tiến dần xuống phân tích, thiết kế, mã hóa, kiểm thử và bảo trì. Như vậy khuôn cảnh vòng đời bao gồm các hoạt động trong mô hình thác nước sau: 18
19. Giáo trình tóm tắt Công Nghệ Phần Mềm Kỹ nghệ hệ thống Phân tích và định rõ yêu cầu Thiết kế hệ thống và thiết kế phần mềm Mã hoá Kiểm thử đơn vị/ tích hợp /hệ thống Vận hành và bảo trì H1.4 Vòng đời cổ điển 1. Kỹ nghệ và phân tích hệ thống: Phần mềm là một phần của hệ thống ứng dụng nên công việc phải bắt đầu từ việc thiết lập yêu cầu cho tất cả các phần tử của hệ thống. Kỹ nghệ và phân tích hệ thống bao gồm việc thu thập yêu cầu ở mức hệ thống với một thiết kế sơ bộ và phân tích mức đỉnh. 2. Phân tích yêu cầu phần mềm: Tiến trình thu thập yêu cầu được tập trung và làm mạnh đặc biệt vào phần mềm. Các kỹ sư phần mềm cần phải diễn đạt ra được các yêu cầu đối với phần mềm dưới dạng các chức năng cần có, hiệu năng và giao diện. Cần lập tư liệu về các yêu cầu cho cả hệ thống và phần mềm, và được khách hàng duyệt lại. 3. Thiết kế: Thiết kế phần mềm là một tiến trình nhiều bước tập trung vào bốn thuộc tính phân biệt của chương trình: - thiêt kế cấu trúc dữ liệu - kiến trúc phần mềm (các chức năng của chương trình) - chi tiết các thủ tục, thuật tóan - thiết kế giao diện Tiến trình thiết kế chuyển hóa các yêu cầu thành một biểu diễn của phần mềm có thể khẳng định về chất lượng trước khi giai đoạn mã hóa bắt đầu. Việc thiết kế phải được lập tư liệu và trở thành một phần của cấu hình phần mềm. 4. Mã hóa: dùng một ngôn ngữ lập trình cụ thể viết chương trình.Đây là khâu quan trọng và tốn kém nhất về thời gian và chất xám của cán bộ lập trình – chuyên gia phần mềm. 5. Kiểm thử: Việc kiểm thử bắt đầu sau khi đã sinh ra mã, tập trung vào phần logic bên trong chương trình, đảm bảo rằng tất cả các câu lệnh đều được kiểm thử. Về phần chức năng bên ngoài cần đảm bảo việc tiến hành kiểm thử phát hiện ra các lỗi và đảm bảo những cái vào xác định sẽ tạo ra kết quả thực tế thống nhất với kết quả muốn có. Việc kiểm thử luôn đi liền với việc viết mã, xong một thủ tục phải thử ngay để sửa lỗi. 19
20. Giáo trình tóm tắt Công Nghệ Phần Mềm 6. Bảo trì: Phần mềm chắc chắn sẽ có những thay đổi sau khi được bàn giao cho khách hàng (ngoại lệ là những phần mềm nhúng). Nguyên nhân có thể là lỗi do phần mềm, phải thích ứng với môi trường bên ngoài (hệ điều hành mới, thiết bị ngoại vi mới ), hoặc do khách hàng yêu cầu nâng cao chức năng hay hiệu năng Việc bảo trì phần mềm phải áp dụng lại các bước vòng đời nói trên. Vòng đời cổ điển ra đời sớm nhất và được sử dụng rộng rãi nhất cho kỹ nghệ phần mềm. Tuy nhiên có một số vấn đề hay gặp phải : - Các dự án hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề ra. Việc lặp lại bao giờ cũng xuất hiện và gây ra vấn đề. - Khách hàng khó phát biểu hết mọi yêu cầu một cách tường minh khi mới triển khai dự án và thường xẩy ra mâu thuẫn giữa thực tế với khả năng đáp ứng của phần mềm. Cách tiếp cận 2: Mô hình làm bản mẫu Thông thường khách hàng đã xác định được mục tiêu tổng quát của phần mềm, nhưng chưa xác định được dữ liệu nào cần nhập vào, xử lý ra sao hay dữ liệu xuất ra như thế nào; người phân tích chưa hiểu rõ nhu cầu của khách hàng. Ngoài ra, người phát triển có thể không chắc về tính hiệu quả của một thuật toán hay giải pháp, việc thích nghi hệ điều hành hay dạng giao diện người máy (HCI – Human Computer Interface) cần có. Trong những trường hợp này và nhiều trường hợp khác cách tiếp cận làm bản mẫu cho kỹ nghệ phần mềm là tốt nhất. Làm bản mẫu là một tiến trình có khả năng tạo ra một mô hình cho phần mềm cần phải xây dựng. Mô hình có thể ở trong 3 dạng: (1) bản mẫu trên giấy hay mô hình dựa trên máy PC mô tả giao diện người máy dưới dạng làm cho người dùng hiểu được cách các tương tác xuất hiện (2) bản mẫu làm việc cài đặt một tập con các chức năng của phần mềm mong muốn (3) một chương trình đã có thực hiện một phần hay tất cả các chức năng mong muốn nhưng cần phải cải tiến thêm các tính năng khác tùy theo khả năng phát triển. 20
21. Giáo trình tóm tắt Công Nghệ Phần Mềm Dãy các sự kiện của khuôn cảnh làm bản mẫu được minh họa `trong hình sau: Bắt đầu Tập hơp yêu cầu & làm mịn, xác định mục tiêu tổng thể, khảo sát thêm Kết thúc để định rõ yêu Thiết kế cầu nhanh Sản phẩm (inpu, out put) Vi chỉnh Bản Mẫu Xây dựng Làm mịn bản mẫu bản mẫu Đánh giá của khách hàng về bảnH1.5 mẫu Làm bản mẫu Giống như các mọi cách tiếp cận cho việc phát triển phần mềm, việc làm bản mẫu bắt đầu với việc thu thập yêu cầu. Người phát triển và khách hàng gặp nhau, xác định các mục tiêu tổng thể cho phần mềm, xác định các yêu cầu nào đã biết, miền nào bắt buộc phải xác định thêm. Rồi đến việc “thiết kế nhanh” để xây dựng một bản mẫu. Bản mẫu được người dùng đánh giá và được dùng để làm mịn các yêu cầu đối với phần mềm cần phát triển. Tiến trình lặp đi lặp lại xảy ra để cho bản mẫu được “vi chỉnh” thỏa mãn nhu cầu của khách hàng, đồng thời giúp người phát triển hiểu kỹ hơn cần phải thực hiện nhu cầu nào. Giống như vòng đời cổ điển, việc làm bản mẫu tựa như một khuôn cảnh cho kỹ nghệ phần mềm có thể trở thành có vấn đề. Cách tiếp cận 3: Mô hình xoắn ốc Mô hình xoắn ốc bao gồm các tính năng tốt nhất của cả vòng đời cổ điển lẫn làm bản mẫu, trong khi còn bổ xung yếu tố mới là phân tích rủi ro – cái còn thiếu trong các mô hình này. Mô hình này được biểu diễn theo đường xoắn ốc, xác định ra bốn hoạt động chính: (1) Lập kế hoạch: xác định mục tiêu, giải pháp và ràng buộc (2) Phân tích rủi ro: phân tích các phương án và xác định, giải quyết rủi ro. (3) Kỹ nghệ: phát triển sản phẩm “mức tiếp” (4)Đánh giá của khách hàng: khẳng định kết quả của kỹ nghệ 21
22. Giáo trình tóm tắt Công Nghệ Phần Mềm KÕ ho¹ch Ph©n tÝch rñi ro (I) (II) TËp hîp yªu cÇu Ph©n tÝch rñi ro ban ®Çu vµ dùa trªn yªu cÇu lập kÕ ho¹ch dù ¸n ban ®Çu Ph©n tÝch rñi ro dùa trªn ph¶n øng cña kh¸ch hµng KÕ ho¹ch dùa trªn ý kiÕn (QuyÕt ®Þnh tiÕp hay kh«ng) kh¸ch hµng H­íng tíi hÖ thèng hoµn chØnh §¸nh gi¸ cña B¶n mÉu ban ®Çu kh¸ch hµng B¶n mÉu tÇng tiÕp theo (IV) Bản mẫu n (III) H1.6 Mô hình xoắn ốc Cách tiếp cận thực tế nhất cho việc phát triển phần mềm của các hệ thống có quy mô lớn Mỗi lần lặp xung quanh xoắn ốc (từ tâm đi ra ngoài) người ta lại xây dựng thêm các phiên bản được hoàn thiện dần của phần mềm. Trong mạch xoắn thứ nhất, các mục tiêu, phương pháp, ràng buộc, các rủi ro được định rõ và phân tích. Nếu phân tích rủi ro chỉ ra rằng, không chắc chắn trong các yêu cầu thì việc làm bản mẫu có thể được sử dụng trong góc phần tư kỹ nghệ. Các mô phỏng và các mô hình khác cũng có thể được dùng để xác định rõ thêm vấn để và làm mịn yêu cầu. Khách hàng đánh giá công việc kỹ nghệ và đưa ra gợi ý về những thay đổi (góc phần tư đánh giá của khách hàng), giai đoạn tiếp của việc lập kế hoạch và phân tích rủi ro sẽ được tiến hành. Tại mỗi vòng xung quanh xoắn ốc, cao điểm của việc phân tích rủi ro là “tiến hành hay không tiến hành”, nếu rủi ro quá lớn có thể đình chỉ dự án. Mọi mạch đi xung quanh xoắn ốc đều đòi hỏi kỹ nghệ (góc phần tư phía dưới bên phải) có thể được thực hiện bằng cách tiếp cận vòng đời và làm bản mẫu. Tất nhiên số các hoạt động phát triển xuất hiện trong góc phần tư phía dưới bên phải tăng lên khi các hoạt động chuyển xa hơn ra khỏi trung tâm xoắn ốc. Khuôn cảnh mô hình xoắn ốc đối với kỹ nghệ phần mềm hiện tại là cách tiếp cận thực tế nhất đến việc phát triển cho các hệ thống và phần mềm quy mô lớn. Trong đó người ta dùng cách làm bản mẫu như một cơ chế làm giảm bới rủi ro. Mô hình này tương đối mới và còn chưa được sử dụng rộng rãi như vòng đời, làm bản mẫu. Cách tiếp cận 4: Kỹ thuật thế hệ thứ tư Thuật ngữ “kỹ thuật thế hệ thứ tư” (4GT - The Fourth Generation Technology) bao gồm một phạm vi rộng các công cụ phần mềm có một điểm chung: Mỗi công cụ đều cho phép người lập trình xác định một số đặc trưng của phần mềm ở mức cao. Công cụ đó tự động sinh ra mã chương trình gốc theo nhu cầu của người phát triển. Khuôn cảnh 4GT tập trung vào khả năng xác định phần mềm đối với một máy ở mức độ gần với ngôn ngữ tự nhiên hay dùng một ký pháp đem lại chức năng có ý nghĩa. 22
23. Giáo trình tóm tắt Công Nghệ Phần Mềm Một môi trường phát triển phần mềm hỗ trợ cho khuôn cảnh 4GT bao gồm một số hoặc tất cả các công cụ sau: ngôn ngữ phi thủ tục để truy vấn CSDL, bộ sinh báo cáo, bộ thao tác dữ liệu, bộ tương tác và xác định màn hình, bộ sinh chương trình, khả năng đồ họa mức cao, khả năng làm trang tính. Khuôn cảnh 4GT cho kỹ nghệ phần mềm được thể hiện trên sơ đồ: Tập hợp các yêu cầu Chiến lược thiết kế Cài dặt sử dụng 4GL Kiểm thử H1.7 Các kỹ thuật thế hệ thứ tư Việc dùng khuôn cảnh 4GT còn có nhiều tranh cãi: - Người ủng hộ cho rằng 4GT làm giảm đáng kể thời gian phát triển phần mềm, tăng hiệu suất của người lập trình. - Người phản đối cho rằng các công cụ 4GT hiện tại không phải tất cả đều dễ dùng hơn các ngôn ngữ lập trình, các chương trình gốc do các công cụ này tạo ra là “không hiệu quả”, và việc bảo trì các hệ thống phần mềm lớn được phát triển bằng cách dùng 4 GT sẽ sinh ra nhiều vấn đề mới. Ta tóm tắt trạng thái hiện tại của cách tiếp cận 4 GT như sau: -Đối với CSDL lớn, 4 GT chỉ mới giới hạn vào các ứng dụng hệ thông tin nghiệp vụ, đặc biệt, việc phân tích thông tin và làm báo cáo (là nhân tố chủ chốt cho các CSDL lớn) -Đối với các ứng dụng vừa và nhỏ, thời gian thu thập dữ liệu sơ bộ cần để tạo phần mềm được giảm đáng kể. Khối lượng thiết kế cho các ứng dụng nhỏ cũng được rút bớt. -Để phát triển phần mềm lớn, đòi hỏi tập trung nhiều vào phân tích, thiết kế và kiểm thử để đạt tới việc tiết kiệm thời gian là chủ yếu. Tóm lại, các kỹ thuật thế hệ thứ tư đã trở thành một phần quan trọng của việc phát triển phần mềm trong lĩnh vực áp dụng công nghệ thông tin. Hình dưới đây minh họa nhu cầu phần mềm sẽ tiếp tục leo thang, nhưng phần mềm được áp dụng các phương pháp và khuôn cảnh quy ước thì sẽ đóng góp ngày càng ít, kỹ thuật thế hệ thứ tư sẽ lấp lỗ hổng này. 23
24. Giáo trình tóm tắt Công Nghệ Phần Mềm 2.6 Cách tiếp cận 5: Tổ hợp các khuôn cảnh Các khuôn cảnh đề cập ở trên được mô tả như các cách tiếp cận khác nhau đối với kỹ nghệ phần mềm chứ không phải là cách tiếp cận bổ xung cho nhau, tuy nhiên trong nhiều trường hợp có thể và cũng nên tổ hợp các khuôn cảnh để đạt sức mạnh của từng khuôn cảnh cho một dự án riêng lẻ. Hình 1.9 minh họa cách tổ hợp các khuôn cảnh kỹ nghệ phần mềm, trong mọi trường hợp, công việc bắt đầu với mọi khuôn cảnh là việc xác định mục tiêu, phương án và các ràng buộc (hay thu thập yêu cầu sơ bộ). Từ điểm này, bất kỳ một con đường nào trên hình 1.9 đều có thể được chọn. Phân tích yêu cầu Tập hợp các yêu cầu ban đầu Thiết kế Làm bản mẫu 4GT Mô hình xoắn ốc Mã hoá Bản mẫu: vòng 4GT thứ n Mô hình xoắn ốc: vòng thứ n Kiểm thử 4GT Hệ thống hoạt dộng Bảo trì H1.9 Tổ hợp các khuôn cảnh Chẳng hạn, nếu có thể xác định được hoàn toàn hệ thống ngay từ đầu, có thể đi theo bước vòng đời cổ điển, nếu các yêu cầu còn chưa được chắc chắn thì có thể sử dụng bản mẫu như một bản hướng dẫn, người phát triển có thể trở lại các bước của vòng đời cổ điển (thiết kế, mã hóa, kiểm thử). Bản mẫu có thể tiến hóa thành hệ thống sản xuất, với việc quay trở về khuôn cảnh vòng đời để kiểm thử. Các kỹ thuật thứ tư có thể dùng để cài đặt bản mẫu hay cài đặt hệ thống sản xuất trong bước mã hóa của vòng đời. 4GT có thể được dùng kèm với mô hình xoắn ốc cho các bước làm bản mẫu hay mã hóa. 24
25. Giáo trình tóm tắt Công Nghệ Phần Mềm Không nên cứng nhắc trong việc chọn khuôn cảnh cho kỹ nghệ phần mềm. Dựa vào bản chất của ứng dụng mà ấn định ra cách tiếp cận cần được chọn bằng cách tổ hợp các cách tiếp cận thì ích lợi một tổng thể sẽ còn lớn hơn là tổng thể của từng phần. 3. Các giai đoạn trong tiến trình kỹ nghệ phần mềm Tiến trình kỹ nghệ phần mềm chứa ba giai đoạn chính bất kể với khuôn cảnh kỹ nghệ phần mềm nào được lựa chọn, bao gồm: giai đoạn xác định, phát triển, và bảo trì. 3.1 Giai đoạn xác định làm cái gì ? Giai đoạn xác định làm cái gì bao gồm 3 bước: Phân tích ở mức hệ thống: xác định vai trò ,chức năng của từng phần tử trong hệ thống mà phần mềm cần được tạo ra để phục vụ nó, chỉ ra vai trò của phần mềm phải làm những công việc gì để phục vụ hệ thống. Trong quá trình phân tích,cần tập trung vào xác định thông tin nào cần được xử lý, chức năng nào là cấn có, giao diện nào cần được thiết lập, ràng buộc thiết kế nào là hiện có, và tiêu chuẩn hợp lệ nào cần có để xác định ra một hệ thống thành công. Lập kế hoạch dự án phần mềm: sau khi đã được xác định được nhiệm vụ của phần mềm, phân tích được các rủi ro , xác định được chi phí và tài nguyên được cấp phát, thì phải xác định nhiệm vụ công việc và lâp lịch, lên kế họach. Phân tích yêu cầu: Nhiệm vụ của phân tích yêu cầu là tiến hành khảo sát, khám phá, mô tả lại các yêu cầu một cách rõ ràng,mạch lạc,đầy đủ, là mô hình hóa và đặc tả phần mềm. Trong quá trình phân tích,cần tập trung vào xác định thông tin nào cần được xử lý, chức năng nào là cấn có, giao diện nào cần được thiết lập, ràng buộc thiết kế nào là hiện có, và tiêu chuẩn hợp lệ nào cần có để xác định ra một hệ thống thành công. 3.2 Giai đoạn phát triển – làm như thế nào ? Giai đoạn phát triển bao gồm 3 bước: Thiết kế phần mềm: diễn đạt các yêu cầu về phần mềm thành các sơ đồ hoặc bảng, hoặc bằng ngôn ngữ , xây dựng các thuật toán , các thủ tục xử lý tính tóan và thủ tục xử lý dữ liệu, mô tả cấu trúc dữ liệu, mô tả các đặc trưng giao diện. Mã hóa: sử dụng ngôn ngữ lập trình để viết chương trình cho các thuật toán, các thủ tục , tạo các giao diện, cài đặt dữ liệu như đã thiết kế ở bước trước đó. Kiểm thử phần mềm: sau khi phần mềm đã được cài đặt dưới dạng máy thực hiện được, cần kiểm thử để phát hiện ra các lỗi, khiếm khuyết . Cần kiểm thử với dữ liệu giả định và dữ liệu thật để so sánh kết quả, đánh giá độ chính xác của phần mềm. 3.3 Giai đoạn bảo trì Sau khi phần mềm đã kiểm tra đạt yêu cầu mới đưa vào khai thác sử dụng và chuyển sang giai đọan bảo trì. Nhiệm vụ của giai đoạn bảo trì là nhằm bảo đảm cho phần mềm vận hành tốt, thực hiện tốt các yêu cầu của khách hàng đặt ra từ đầu. Trong Giai đoạn bảo trì có thể phải : Sửa đổi một số chỗ của phần mềm để khắc phục các khiếm khuyết Sửa đổi bổ sung một số chỗ của phần mềm để thích nghi với hiện trạng nơi sử dụng hay mở rộng hoàn thiện phần mềm hơn để đáp ứng những yêu cầu mới. 25
26. Giáo trình tóm tắt Công Nghệ Phần Mềm Củng cố 1. Môn học kỹ nghệ phần mềm (SE) phục vụ cho ai là chính, tại sao lại cần nó? 2. Các chủ đề cần quan tâm trong SE? 3. Các thành phần phần mềm được xây dựng bằng cách nào? 4. Phần mềm ứng dụng được phân loại theo những chủ đề nào? 5. Phần mềm và kỹ nghệ phần mềm được anh (chị) hiểu như thế nào? 6. So sánh các cách tiếp cận cơ bản trong tiến trình phát triển phần mềm? 7. Ý nghĩa của việc tổ hợp các khuôn cảnh? 8. Nêu và phân tích các bước tổng quát trong tiến trình SE? 26
27. Giáo trình tóm tắt Công Nghệ Phần Mềm CHƯƠNG 2 PHÂN TÍCH YÊU CẦU VÀ ĐẶC TẢ PHẦN MỀM Việc hiểu biết đầy đủ về các yêu cầu phần mềm sẽ quyết định sự thành công của phần mềm. Nhiệm vụ của phân tích yêu cầu là một tiến trình khám phá, làm mịn, mô hình hóa và đặc tả. Cả người phát triển và khách hàng đều đóng vai trò quan trọng trong việc phân tích và đặc tả yêu cầu. 1. Những kỹ năng cần có ở Người phân tích(kỹ sư hệ thống) Trong giai đoạn phân tích, Kỹ sư phân tích cần có kỹ năng : Tiến hành theo phương thức "Top-Down" nghĩa là đi từ cái tổng quát tới chi tiết, các chức năng, giao diện và thông tin chủ yếu phải được hiểu hoàn toàn rõ trước khi xác định chi tiết các tầng lớp kế tiếp. Người phân tích cũng phải hiểu từng khuôn cảnh phần mềm và đánh giá được các bước kỹ nghệ phần mềm tổng quát, áp dụng được bất kể khuôn cảnh nào cần dùng. 2. Nhiệm vụ phân tích yêu cầu Việc phân tích yêu cầu phần mềm có thể chia thành 5 bước: a) Nhận thức vấn đề b) Đánh giá vấn đề và tổng hợp các giải pháp c) Mô hình hóa d) Đặc tả e) Xét duyệt,thẩm định Ta xét khái quát 5 bước được tiến hành như sau: Trước hết tiến hành nghiên cứu bản Phân tích hệ thống và bản Kế hoạch dự án phần mềm(nếu có), hiểu phần mềm trong toàn cảnh hệ thống và xem xét phạm vi phần mềm được dùng để ước lượng quy mô công việc và lên kế hoạch. Bước thứ 2 là trao đổi giữa các bên để nhận thức ra vấn đề cần giải quyết. Ta hình dung : bên A là khách hàng, đặt làm phần mềm, bên B là đơn vị làm phần mềm.Bên B có 3 loại cán bộ : người quản lý dự án,người phân tích,người phát triển phần mềm sau công đoạn phân tích. Người quản lý dự án phải điều phối, thiết lập qua hệ để Người phân tích có thể trao đổi , tiếp xúc với các cấp quản lý và nhân viên kỹ thuật của phía khách hàng và người phát triển phần mềm. Kết quả ở đây là khách hàng và người phân tích đi đến thống nhất phải làm ra một sản phẩm phần mềm có những thành phần,chức năng như thế nào. Bước thứ 3 là đánh giá vấn đề và tổng hợp các giải pháp, cần thực hiện các côgn việc : + Xác định các luồng tin và nội dung thông tin trong từng luồng + Xác định và soạn thảo các chức năng phần mềm +Dự báo được phần mềm sẽ thực thi như thế nào theo tình huống của các sự kiện ảnh hưởng tới hệ thống +Thiết lập các đặc trưng giao diện 27
28. Giáo trình tóm tắt Công Nghệ Phần Mềm +Vạch ra được những hạn chế Một khi hiểu được khách hàng muốn gì thì người phân tích mới xác định được hệ thống mới cần phải tạo ra thông tin nào và dữ liệu nào cần được cung cấp cho hệ thống. Một khi đánh giá được các vấn đề hiện tại và thông tin mong muốn, người phân tích mới xác định được giải pháp và xác định những bước phát triển kế tiếp. Bước thứ tư là mô hình hóa. Thông qua ước lượng và tổng hợp giải pháp, người phân tích tạo ra các mô hình hệ thống nhằm hiểu rõ hơn luồng dữ liệu và điều khiển xử lý chức năng, thao tác hành vi và nội dung thông tin. Mô hình này được lấy làm nền tảng cho thiết kế phần mềm Bước cuối cùng là tạo ra một đặc tả phần mềm. Kết quả của công việc phân tích yêu cầu là bản đặc tả yêu cầu phần mềm. Đó là tư liệu chính thức đầu tiên được tạo ra trong quy trình xây dựng phần mềm. 28
29. Giáo trình tóm tắt Công Nghệ Phần Mềm 3.Việc hình thành các yêu cầu như thế nào ? Phân tích và định rõ yêu cầu là hướng tới đặc tả yêu cầu phần mềm được thể hiện trong các khuôn cảnh như sau: Thiết Nghiên Mô lập cứu hình nhu khả thi hoá cầu hệ hệ thống Xác thống định yêu cầu Đặc tả yêu cầu Đặc tả thiết (đặc kế hệ Báo cáo nhu tả thống và cầu (tài liệu chức phần mềm quan niệm năng) (mô tả trừu về hệ thống) tượng cho Báo Mô Yêu cầu phần mềm) cáo hình đã qua khả hệ thẩm thi thống định Tư liệu Tài liệu Tài liệu đặc tả yêu cầu đặc tả thiết kế (tài yêu cầu liêu đặc tả các yêu cầu hệ thống vầ phần mềm) 29
30. Giáo trình tóm tắt Công Nghệ Phần Mềm Việc phân tích và nắm bắt yêu cầu là giai đoạn đầu của quá trình thiết lập các dịch vụ (mà hệ thống phải giải quyết) và các ràng buộc (mà hệ thống phải tuân theo). Các thông tin của vấn đề cần giải quyết phải được thu thập, phân tích và phải được xác định một cách rõ ràng. Khi đó thì giải pháp phần mềm mới có thể được thiết kế và thực thi. Để giải quyết vấn đề này người ta phải thực hiện các bước đầu tiên của tiến trình phân tích hệ thống như xác định nhu cầu, mô hình hóa hệ thống (giai đoạn tiền khả thi). - Phân tích yêu cầu là một tiến trình khám phá, làm mịn, mô hình hóa và đặc tả. Phạm vi phần mềm, ban đầu do người phân tích thiết lập sơ bộ sau đó sẽ được chi tiết thêm các phần : Các mô hình thông tin cần tới Luồng thông tin Hành vi vận hành Nội dung dữ liệu được tạo ra Người cân bộ tin tọc làm công tác phân tích yêu cầu phải có khả năng nghe và hiểu được khách hàng muốn cái gì, yêu cầu cái gì, từ những phát biểu có thể là tản mạn,không ăn khớp nhau của khách hàng phải biết xâu chuỗi, ghép nối, hình thành nên những yêu cầu rõ ràng,cụ thể mà máy tính điện tử có thể giải quyết được. 4.Việc xác định các yêu cầu 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 tả tính chất bên ngoài của hệ thống mà không hề 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 chia làm hai loại: 1. 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 2. Các yêu cầu phi chức năng: các ràng buộc mà hệ thống phải tuân theo Xác định yêu cầu thường được viết bằng ngôn ngữ tự nhiên cộng thêm việc dùng các bảng, các biểu đồ để cho người dùng dễ hiểu (xem như người dùng không biết các khái niệm chuyên môn). Chú ý: Vì việc xác định yêu cầu khó hoàn thiện trước khi bắt đầu phát triển hệ thống nên việc áp dụng mô hình bản mẫu sẽ thích hợp hơn là mô hình thác nước. Các báo cáo về yêu cầu phần mềm phải viết như thế nào ? 1. Chỉ đặc tả tính chất bên ngoài của hệ thống 2. Đặc tả các ràng buộc về sự thực hiện 3. Phải là dễ thay đổi,có khả năng thích nghi với các thay đổi sẽ diễn ra 4. Phải được dùng làm công cụ tham khảo cho người bảo trì hệ thống 5. Phải báo cáo dự tính trước về vòng đời của hệ thống Cấu trúc của một tư liệu yêu cầu được gợi ý theo kết cấu sau: 1. Phần dẫn nhập 2. Phần mô hình hệ thống 3. Phần tiến triển của hệ thống 30
31. Giáo trình tóm tắt Công Nghệ Phần Mềm 4. Phần các yêu cầu chức năng 5. Phần từ điển thuật ngữ 5. Đặc tả phần mềm 5.1 Cách đặc tả và biểu diễn 5.1.1 Khái niệm Đặc tả - specification Đặc tả một vấn đề là mô tả các đặc trưng của vấn đề đó. Vấn đề có thể là đối tượng, khái niệm hoặc một thủ tục nào đó, Yêu cầu đầu tiên của đặc tả là tính chính xác Các đặc tả thường mang tính trừu tượng. Càng ở mức cao (những mức đầu tiên của quá trình làm mịn hoặc chính xác hóa) đặc tả càng trừu tượng,khái quát . Càng xuống các mức thấp, đặc tả càng tiếp cận dần tới cụ thể - tức là tới một thể hiện trên một máy tính cụ thể với một ngôn ngữ lập trình cụ thể. - Đặc tả hình thức: là những đặc tả chính xác tức là không thể dẫn tới những cách hiểu khác nhau. Đặc tả hình thức sử dụng công cụ chủ yếu là đại số và logic (formal) - Đặc tả phi hình thức: diễn đạt bằng những ngôn ngữ, tuy không chặt chẽ nhưng được nhiều người biết và có thể trao đổi với nhau để chính xác hoá những điểm chưa rõ, những khái niệm mơ hồ - Đặc tả hỗn hợp: phối hợp hai kiểu đặt tả trên Trong thực tế, có nhiều loại hình đặc tả, ví dụ như: Đặc tả cấu trúc dữ liệu (mô tả các thành phần của dữ liệu ), đặc tả chức năng (mô tả chức năng thông qua việc mô tả tính chất của input, output ), đặc tả đối tượng (bao gồm đặc tả cấu trúc và đặc tả chức năng ), đặc tả thao tác (mô tả các thao tác cần thực hiện ), đặc tả cú pháp (mô tả cách lắp ghép các kí hiệu, các từ lại thành chương trình ), đặc tả xử lý, đặc tả thuật toán Kiểu đặc tả cần phù hợp với giải pháp. Các yêu cầu phần mềm có thể được phân tích theo một số cách khác nhau. Các kỹ thuật phân tích có thể dẫn tới những đặc tả trên giấy hay trên máy tính (được xây dựng nhờ dùng CASE) có chứa các mô tả ngôn ngữ đồ họa và tự nhiên cho yêu cầu phần mềm. Việc làm bản mẫu đã giúp đặc tả thực hiện được, tức là bản mẫu thể hiện một biểu diễn của các yêu cầu phần mềm. Các ngôn ngữ đặc tả hình thức dẫn tới biểu diễn hình thức. 5.1.2 Biểu diễn Các yêu cầu phần mềm có thể được biểu diễn theo nhiều cách. Các biểu diễn tốt nên tuân theo hướng dẫn sau: Định dạng và nội dung biểu diễn theo hướng liên quan tới vấn đề: - Theo một dàn bài chung cho nội dung của bản đặc tả các yêu cầu phần mềm. - Dạng biểu diễn có trong bản đặc tả có thể thay đổi theo lĩnh vực ứng dụng. (Chẳng hạn, đặc tả cho hệ thống tự động hóa chế tạo sẽ dùng cách kí hiệu khác, biểu đồ và ngôn ngữ khác với đặc tả cho trình biên dịch ngôn ngữ lập trình) Thông tin chứa trong bản đặc tả nên được lồng nhau: - Các biểu diễn nên làm lộ ra các tầng thông tin sao cho độc giả có thể di chuyển tới mức chi tiết mình mong muốn. - Đoạn và các sơ đồ đánh dấu nên chỉ ra mức độ chi tiết đang được trình bày. Đôi khi cũng nên trình bày cùng một thông tin ở các mức trừu tượng khác nhau để hiểu tốt hơn. 31
32. Giáo trình tóm tắt Công Nghệ Phần Mềm Các biểu đồ và các dạng kí pháp khác nên giảm thiểu và nhất quán trong sử dụng: Chẳng hạn, cách kí hiệu như sau có thể hiểu theo nhiều cách: có thể giải thích ít nhất ba (hoặc 5 hay 6) cách khác nhau. Lẫn lộn hay không nhất quán trong kí pháp, dù là đồ họa hay kí hiệu cũng đề làm suy giảm việc hiểu và làm phát sinh lỗi. Biểu diễn nên thường được xem lại: Nội dung của đặc tả sẽ thay đổi. Vì vậy biểu diễn nên thường được xem lại để đảm bảo tính thống nhất. Một cách lý tưởng, các công cụ CASE nên có sẵn để cập nhật tất cả các biểu diễn bị ảnh hưởng bởi từng thay đổi. Nên sử dụng các kí hiệu, sơ đồ quen thuộc nhưng có chọn lọc: Nguời ta đã tiến hành nhiều cuộc điều tra về nhân tố con người liên quan đến đặc tả. Dường như ít có hoài nghi rằng cách kí hiệu và thu xếp có ảnh hưởng tới việc hiểu. Tuy nhiên các kỹ sư thích các dạng ký hiệu, các sơ đồ riêng biệt. Sự quen thuộc thường thuận cho mọi người, nhưng các nhân tố chọn lọc như cách bố trí không gian, các mẫu hình dễ nhận thức và mức hợp lý của hình thức sẽ giúp cho việc đặc tả có lợi về sau. 5.2 Các nguyên lý đặc tả Đặc tả có thể được xem như một tiến trình biểu diễn. Mục đích cuối cùng của đặc tả các yêu cầu được biểu thị sao cho dẫn tới việc cài đặt phần mềm thành công. Balzer và Goldman đề nghị 8 nguyên lý đặc tả tốt: Nguyên lý 1: Phân biệt chức năng với cài đặt- phân biệt giữa cái gì(what) – chứ kg phải làm như thế nào(how) Trước hết, theo định nghĩa, đặt tả là một mô tả về điều mong muốn, chứ không phải là cách thực hiện nó (cài đặt). Đặc tả có thể chấp nhận hai dạng hoàn toàn khác nhau. Dạng thứ nhất là dạng của các hàm toán học: với một tập cái vào đã cho, tạo ra một tập cái ra đặc biệt. Dạng tổng quát của những đặc tả như thế là tìm ra một hoặc tất cả những kết quả ứng với P (cái vào), với P biểu thị một tân từ bất kỳ. Trong những đặc tả như thế, kết quả cần thu được phải hoàn toàn được diễn đạt cái gì 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 Xét tình huống trong đó 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 đó. Hành vi của nó không thể biểu diễn được ở dạng hàm toán học của cái vào. Thay vì thế, cần phải sử dụng cách biểu diễn khác: cách mô tả hướng tiến trình, trong đó đặc tả cái gì đạt được bằng cách xác định một mô hình hành vi mong muốn của hệ thống dưới dạng các đáp ứng chức năng đối với các kích thước khác nhau từ môi trường. Những đặt tả hướng tiến trình như vậy: 1. Trình bày một mô hình về hành vi hệ thống 2. Thông thường không thuộc ngôn ngữ đặc tả hình thức 3. Lột tả được bản chất của nhiều tình huống phức tạp cần phải đặc tả 4. Trong những tình huống cần tự động hóa, cả tiến trình lẫn môi trường tồn tại của nó đều phải được mô tả một cách hình thức. Muốn vậy, toàn bộ hệ thống các bộ phận tương tác phải được đặc tả chứ không chỉ đặc tả một thành phần 32
33. Giáo trình tóm tắt Công Nghệ Phần Mềm Nguyên lý 3: Đặc tả phải bao gồm hệ thống trong đó phần mềm là một thành phần(đảm bảo tính hệ thống, thể hiện mối liên kết giữa phần mềm cần xây dựng với các thành phần khác). Một hệ thống bao gồm các thành phần tương tác 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 riêng mới có thể được xác định. Nói chung, một hệ thống được mô hình hóa như một tập hợp các mối quan hệ giữa các thụ động. Những sự vật này có liên quan lẫn nhau và qua thời gian dẫn đến mối quan hệ giữa các sự vật thay đổi. Mối quan hệ động này đưa ra sự kích thích cho các sự vật tích cực, còn gọi là các tác nhân, đáp ứng. Sự đáp ứng có thể gây ra những thay đổi thêm nữa, và do đó, tạo ra thêm kích thích để cho các tác nhân có thể đáp ứng lại. Nguyên lý 4: Đặc tả bao gồm cả môi trường mà hệ thống vận hành(có xét đến môi trường xung quanh) Môi trường trong đó hệ thống vận hành và các tương tác phải được xác định. Bản thân môi trường cũng là một hệ thống bao gồm các sự vật tương tác, cả tích cực lẫn thụ động, mà trong hệ thống chúng chỉ là một tác nhân. Các tác nhân khác, theo định nghĩa là không thay đổi bởi vì chúng là một phần của môi trường, giới hạn phạm vi của việc thiết kế và cài đặt về sau. Trong thực tế, sự khác nhau duy nhất giữa hệ thống và môi trường của nó là ở chỗ nỗ lực thiết kế và cài đặt về sau sẽ vận hành chỉ trong đặc tả cho hệ thống. Đặc tả môi trường làm cho "giao diện" của hệ thống được xác định theo cùng cách như bản thân hệ thống chứ không đưa vào cách hình thức hóa khác. Đặc tả hệ thống chính là bức tranh của tập hợp các tác nhân xoắn xuýt nhau cao độ, phản ứng lại những kích thích trong môi trường (thay đổi các sự vật). Chỉ có thông qua những hành động điều phối của tác nhân mà hệ thống mới đạt được các mục tiêu của nó. Thiết kế tuân theo đặc tả và quan tâm đến việc phân rã một đặc tả thành các mẩu gần tách biệt để chuẩn bị cho cài đặt. Tuy nhiên đặc tả phải vẽ lại chính xác bức chân dung của hệ thống và môi trường của nó như cộng đồng người dùng cảm nhận tới mức chi tiết, phục vụ cho các giai đoạn thiết kế và cài đặt. Vì mức độ chi tiết cần thiết này là khó thấy trước, nếu không nói là không thể, nên đặc tả, thiết kế và cài đặt phải được thừa nhận như một hoạt động tương tác. Do đó, điều mấu chốt là công nghệ cần bao quát thật nhiều các hoạt động này khi bản đặc tả được soạn thảo và thay đổi (trong cả hai giai đoạn phát triển khởi đầu và bảo trì về sau) Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức- nghĩa là ngừơi đọc phải hiểu được vấn đề thông qua đặc tả - Đặc tả hệ thống phải là một mô hình nhận thức chứ không phải là một mô hình thiết kế hay cài đặt - Mô tả một hệ thống sao cho đạt được sự cảm nhận của cộng đồng người sử dụng. 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 được mô hình hóa cho các cá nhân, tổ chức và trang thiết bị trong lĩnh vực đó; còn các hành động họ thực hiện thì phải được mô hình hóa cho những hoạt động thực tế xuất hiện trong lĩnh vực - Phải có khả năng tổ hợp vào trong đặc tả những quy tắc hay luật bao trùm các sự vật thuộc lĩnh vực: Một trong những luật này bài trừ những trạng thái nào đó của hệ thống (như "hai sự vật không thể đồng thời cùng một chỗ và vào cùng một lúc") và do đó giới hạn hành vi của các tác nhân hay chỉ ra nhu cầu bổ trợ để ngăn cản những trạng thái khỏi nảy sinh. Nguyên lý 6: Đặc tả phải thể hiện tính vận hành- nghĩa là đọc tài liệu đặc tả hình dung ra được sự vận hành của phần mềm. 33
34. Giáo trình tóm tắt Công Nghệ Phần Mềm Đặc tả phải đầy đủ và mang tính hình thức để có thể được dùng trong việc xác định rằng liệu một cài đặt được đề nghị có thỏa mãn đặc tả cho những trường hợp kiểm thử tùy ý không. Tức là, với kết quả của việc cài đặt trên một tập dữ liệu được chọn một cách tùy ý, phải có thể dùng đặc tả để xác định tính hợp lệ cho những kết quả đó. Điều này kéo theo rằng đặc tả, mặc dầu không phải là một đặc tả hoàn toàn về cách thức, vẫn có thể hành động như một bộ sinh các hành vi. Do đó theo nghĩa mở rộng, đặc tả này phải thể hiện tính vận hành Quá trình cài đặt Kết qủa cài đặt Xác định kiểm tính hợp lệ chứng đặc đặc đặc đặc đặc tả tả tả tả tả H 2.4 Quá trình cài đặt Nguyên lý 7: có khả năng update Đặc tả hệ thống chấp nhận dung sai về tính không đầy đủ và vì vậy có tính nâng cao Không đặc tả nào có thể là đầy đủ hoàn toàn. Môi trường mà hệ thống tồn tại trong đó quá phức tạp. Một đặc tả bao giờ cũng là một mô hình - một sự trừu tượng hóa - của một tình huống thực (hay được mường tượng) nào đó. Do đó nó sẽ không đầy đủ. Hơn thế nữa, nó 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 đặc tả và kiểm thử đặc tả phải có khả năng xử lý với tính không đầy đủ. Nguyên lý 8: Đặc tả phải được cục bộ hóa và có khả năng lắp ghép- xuất phát từ lập trình hướng đối tượng. Các nguyên lý trước xử lý đặc tả như một thực thể tĩnh. Nguyên lý này nảy sinh từ tính động của đặc tả. Cần phải thừa nhận rằng mặc dầu mục tiêu chính của một đặc tả là dùng làm cơ sở cho thiết kế và cài đặt một hệ thống nào đó, nó không phải là một sự vật tĩnh dựng sẵn mà là một vật động đang trải qua thay đổi đáng kể. Việc thay đổi (động) của đặc tả xuất hiện trong 3 hoạt động chính: - phát biểu: khi một đặc tả ban đầu đang được tạo ra - phát triển: khi đặc tả được soạn thảo trong quá trình thiết kế - lặp: để phản ánh môi trường đã thay đổi và/hoặc các yêu cầu chức năng phụ. Với nhiều thay đổi xuất hiện đối với đặc tả, điều mấu chốt là nội dung và cấu trúc của đặc tả được chọn để làm phù hợp thay đổi này. Yêu cầu chính cho sự phù hợp đó là ở chỗ: - thông tin bên trong đặc tả phải được cục bộ hóa sao cho chỉ một phần nhỏ (một cách lý tưởng) cần phải sửa đổi khi thông tin thay đổi. - đặc tả cần được cấu trúc (ghép) một cách lỏng lẻo cho từng phần có thể được thêm vào hay loại bỏ một cách dễ dàng, và cấu trúc được điều chỉnh một cách tự động. 34
35. Giáo trình tóm tắt Công Nghệ Phần Mềm 5.3 Các mức trừu tượng của đặc tả Các đặc tả được thể hiện ở vài mức trừu tượng khác nhau cùng với mối tương quan giữa các mức ấy. Mỗi mức nhắm đến các đối tượng đọc khác nhau mà họ có quyền quyết định về việc mua sắm và thực hiện. Các mức đó là: Định ra yêu cầu: - thể hiện bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ thống sẽ phải cung cấp - phải được viết sao cho dễ hiểu đối với khách hàng và người quản lý hợp đồng, người sẽ mua sắm sẽ sử dụng Đặc tả yêu cầu: - tài liệu nêu ra các dịch vụ một cách chi tiết hơn. Tài liệu này (thường được gọi là đặc tả chức năng) - đòi hỏi chính xác tới mức nó có thể làm cơ sở cho hợp đồng giữa người mua sắm hệ thống và người phát triển phần mềm. - được viết dễ hiểu đối với các nhân viên kĩ thuật ở cả nơi mua lẫn nơi phát triển - kỹ thuật đặc tả hình thức hẳn là thích hợp cho các đặc tả kiểu như vậy, nhưng nó cũng tùy thuộc ở trình độ kiến thức cơ bản của người mua sắm hệ thống. Đặc tả phần mềm/ đặc tả thiết kế (đây là một mô tả trừu tượng cho phần mềm): - dùng làm cơ sở cho việc thiết kế và thực thi - thể hiện một quan hệ rõ ràng giữa tư liệu này và đặc tả yêu cầu. - đối tượng đọc ở đây chủ yếu là các kĩ sư phần mềm chứ không phải là người sử dụng hoặc người quản lý - sử dụng kĩ thuật đặc tả hình thức là thích hợp cho tư liệu này. 5.4 Đặc tả yêu cầu Việc định yêu cầu là việc đặc tả hướng khách hàng và được viết bởi ngôn ngữ của khách hàng. Khi đó có thể dùng các khái niệm không chính xác, ngôn ngữ tự nhiên và các biểu đồ. Đặc tả yêu cầu (được gọi là đặc tả chức năng) là cơ sở cho hợp đồng làm hệ thống nó phải không được mơ hồ, mà mơ hồ đó có thể dẫn tới sự hiểu lầm bởi khách hàng hoặc bởi người ký hợp đồng. Rất nhiều vấn đề của kỹ nghệ phần mềm là khó khăn đối với đặc tả yêu cầu. Với một yêu cầu mơ hồ thì người phát triển sẽ thực hiện nó sao cho rẻ nhất. Trong khi đó khách hàng lại không muốn như vậy. Sau các cuộc đấu khẩu kéo dài thì các yêu cầu mới sẽ được thiết lập và có các đổi thay đối với hệ thống. Dĩ nhiên việc đó làm trì hoàn ngày phân phát hệ thống và làm tăng chi phí. Chi phí do các sai sót trong việc phát biểu các yêu cầu có thể là rất cao, đặc biệt là nếu các sai sót này còn vẫn chưa được phát hiện khi hệ thống được thực hiện. Bochm báo cáo rằng trong một vài hệ thống lớn thì có đến 95% các mã đã phải viết lại để thỏa mãn cá yêu cầu của người dùng đã thay đổi và 12% các lỗi được phát hiện trong quá trình ba năm đầu sử dụng là các lỗi do đặc tả yêu cầu không đúng đắn. Chi phí do thay đổi một yêu cầu là đắt hơn nhiều so với chi phí sửa chữa thiết kế hoặc do lỗi mã. 35
36. Giáo trình tóm tắt Công Nghệ Phần Mềm 5.4.1 Những hạn chế của việc đặc tả bằng ngôn ngữ tự nhiên 1. Người đọc và người viết đặc tả bằng ngôn ngữ tự nhiên buộc phải hiểu mỗi từ theo cùng một khái niệm. Điều đó là không thể được do sự mơ hồ và bản tính cố hữu của ngôn ngữ tự nhiên và cũng vì không có một từ điển thuật ngữ máy tính chuẩn mực. 2. Một đặc tả bằng ngôn ngữ tự nhiên là quá mềm dẻo: nó cho phép các yêu cầu liên quan được biểu thị trong các cách hoàn toàn khác nhau. 3. Các yêu cầu là không phân hoạch được một cách hữu hiệu: hiệu quả của việc đổi thay chỉ có thể được xác định bởi toàn bộ các yêu cầu chứ không phải là một nhóm các yêu cầu liên quan Có người đề nghị rằng các ngôn ngữ đặc tả hình thức toán học nên được dùng để biểu thị các yêu cầu hệ thống. Nhưng đa số các khách hàng lại không hiểu đặc tả hình thức toán học. Hall (1990) đề xuất con đường để đi vòng qua khó khăn đó là viết thêm các chú giải dài dòng ngay bên cạnh cho người dùng dễ hiểu. Khi nào người dùng trở nên quen thuộc hơn với những ưu điểm của đặc tả hình thức và các kỹ sư phần mềm không còn miễn cưỡng dùng các phương pháp hình thức thì sẽ có nhiều cách đặc tả yêu cầu sẽ dựa trên các mô hình hình thức của chức năng hệ thống 5.4.2 Các yêu cầu phi chức năng Một yêu cầu phi chức năng của hệ thống là một hạn chế hoặc ràng buộc về các dịch vụ của hệ thống. Các yêu cầu đó có thể được đưa ra: - vì nhu cầu của người dùng - vì hạn chế của kinh phí - vì chính sách của tổ chức - vì sự cần thiết tương tác giữa các phần cứng và phần mềm hoặc - vì các nhân tố bên ngoài như các quy tắc an toàn, luật lệ bí mật riêng tư, Có 3 kiểu yêu cầu phi chức năng chính: 1. Các yêu cầu sản phẩm: đây là các yêu cầu về hệ thống được phát triển, chẳng hạn yêu cầu về tốc độ, về bộ nhớ, về độ tin cậy, về tính di chuyển được và về tính dùng lại được 2. Các yêu cầu về quá trình: đây là các yêu cầu về quá trình phát triển, chẳng hạn như các chuẩn cần phải theo, các yêu cầu về sự thức hiện như các ngôn ngữ lập trình, phương pháp thiết kế, yêu cầu về phân phát 3. Các yêu cầu ngoại lai: tức là các yêu cầu không phải về sản phẩm cũng không phải về quá trình phát triển; chẳng hạn như về giao tiếp với các hệ thống khác, về pháp lý, về chi phí, về nhóm những người phát triển và Tùy theo các tổ chức cụ thể, đặc tả yêu cầu có thể được thể hiện bằng các cách khác nhau kể từ mức phát biểu bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ cần cung cấp đến mức đặc tả hệ thống một cách hình thức kiểu toán học. Ranh giới giữa các yêu cầu và đặc tả hình thức là một thứ rất tinh tế và các thuật ngữ này lại còn có thể được dùng theo nghĩa như nhau. 5.4.3 Khó khăn của việc xác định đặc tả yêu cầu 1. Các hệ phần mềm lớn thường được yêu cầu cải thiện dựa trên nguyên trạng: hoặc không có hệ thống nào hoặc có một hệ thống không đầy đủ. Mặc dầu có thể biết các khó khăn của hệ thống hiện có nhưng lại rất khó dự đoán được hiệu quả của hệ thống đã được cải thiện đối với tổ chức đó. 36
37. Giáo trình tóm tắt Công Nghệ Phần Mềm 2. Các hệ thống lớn thường có một cộng đồng người sử dụng đa dạng, ho có những yêu cầu và ưu tiên khác nhau, thậm chí là mâu thuẫn với nhau. Cuối cùng thì các yêu cầu hệ thống cũng không thể tránh được sự thỏa hiệp. 3. Những người bỏ tiền ra mua sắm hệ thống và những người sử dụng hệ thống hiếm khi lại là một. Những người mua sắm hệ thống đặt ra các yêu cầu theo những ràng buộc của tổ chức cơ quan và của ngân sách. Những cái đó lại thường mâu thuẫn với các yêu cầu thực sự của người dùng. 5.4.4 Thẩm định yêu cầu Một khi đã thiết lập các yêu cầu thì phải thẩm định xem chúng có thỏa mãn các nhu cầu của người mua hệ thống không. Nếu việc thẩm định không phù hợp thì các sai lầm có thể lan truyền sang các giai đoạn thiết kế và thực hiện. Khi đó có thể cần đến các sự nâng cấp hệ thống rất tốn kém để làm cho nó đúng đắn, cần xác minh những vấn đề sau: Có 4 vấn đề liên quan đến việc thẩm định yêu cầu, 1. Phải chỉ ra rằng các nhu cầu của người dùng là được thỏa mãn 2. Các yêu cầu phải không gây ra mâu thuẫn nhau 3. Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà người dùng đã nhắm đến 4. Các yêu cầu phải là hiện thực. 5.5 Dàn bài đặc tả yêu cầu phần mềm Bản đặc tả các yêu cầu phần mềm được tạo ra tại đỉnh cao của nhiệm vụ phân tích Chức năng và hiệu năng được cấp phát cho phần mềm xem như một phần của kỹ nghệ hệ thống thường được làm mịn bằng cách thiết lập phần mô tả thông tin đầy đủ như mô tả chức năng chi tiết, chỉ báo về các yêu cầu hiệu năng và những ràng buộc thiết kế, các tiêu chuẩn hợp lệ thích hợp và những dữ liệu khác thường cần tới. Cơ quan tiêu chuẩn quốc gia, IEEE và Bộ quốc phòng Mỹ đề nghị các định dạng cho các đặc tả yêu cầu phần mềm. Dàn bài đơn giản hóa được trình bày trong bảng sau: Dàn bài đặc tả yêu cầu phần mềm I. Giới thiệu A. Đại cương về hệ thống (mục tiêu, mục đích) B. Mô tả chung (cấu trúc) C. Các ràng buộc dự án phần mềm (phạm vi) II. Mô tả thông tin (chi tiết) A. Biểu diễn luồng thông tin (dựa vào cấu trúc thông tin) 1. Luồng dữ liệu 2. Luồng điều khiển (đặc biệt chú ý đến khi xét các hệ thời gian thực) B. Biểu diễn nội dung thông tin C. Mô tả giao diện hệ thống (cho từng chức năng) III. Mô tả chức năng 37
38. Giáo trình tóm tắt Công Nghệ Phần Mềm A. Phân hoạch chức năng (cho từng chức năng) B. Mô tả chức năng (lời giải thích) 1. Tường thuật về cách xử lý 2. Hạn chế/giới hạn (về các mặt kinh tế, xã hội, kỹ thuật, chi phí, thời gian) 3. Yêu cầu hiệu năng (theo từng modul) 4. Ràng buộc thiết kế (có luận giải) 5. Biểu đồ trợ giúp (cấu trúc tổng thể, tương quan với các phần tử hệ thống khác) C. Mô tả điều khiển 1. Đặc tả điều khiển (có luận giải) 2. Ràng buộc thiết kế (xem xét vận hành của phần mềm) IV. Mô tả hành vi (xem xét vận hành của phần mềm) A. Trạng thái hệ thống (mức toàn cảnh, mức đỉnh) B. Sự kiện và hành động (mức cụ thể, bộ phận) V. Tiêu chuẩn hợp lệ A. Giới hạn hiệu năng B. Lớp các kiểm thử C. Đáp ứng phần mềm trông đợi (tiêu chuẩn hướng tới (lý tưởng)) D. Các xem xét đặc biệt VI. Sách tham khảo (tài liệu kỹ nghệ phần mềm khác, tham khảo kỹ thuật, ) VII. Phụ lục (Danh sách các nhà cung cấp, các chuẩn, ) Trong nhiều trường hợp bản đặc tả yêu cầu phần mềm còn có thể kèm theo một tài liệu sơ bộ của người dùng trình bày số liệu cần đưa vào và kết quả cần đưa ra 5.6 Xét duyệt đặc tả Việc xét duyệt bản đặc tả các yêu cầu phần mềm (và hoặc bản mẫu) do cả người phát triển phần mềm và khách hàng cùng tiến hành. Bởi vì đặc tả tạo nên nền tảng cho giai đoạn phát triển nên cần phải rất thận trọng khi tiến hành cuộc họp xét duyệt. Có 2 mức xét duyệt. 5.6.1 Mức vĩ mô Việc xét duyệt truớc hết được tiến hành ở mức vĩ mô. Tại mức này, người xét duyệt cố gắng đảm bảo rằng bản đặc tả được đầy đủ, nhất quán và chính xác. Cần đề cập tới các câu hỏi sau: Các mục tiêu và mục đích được thiết lập cho phần mềm có nhất quán với mục tiêu và mục đích của hệ thống hay không? Những giao diện quan trọng với mọi phần tử hệ thống đã được mô tả chưa? Luồng và cấu trúc thông tin đã được mô tả thích hợp cho lĩnh vực vấn đề chưa? 38
39. Giáo trình tóm tắt Công Nghệ Phần Mềm Các biểu đồ có rõ ràng không? Liệu mỗi biểu đồ có thể đứng riêng không cần lời giải thích không? Các chức năng chính có còn bên trong phạm vi và đã được mô tả thích hợp chưa? Liệu hành vi của phần mềm có nhất quá với thông tin nó phải xử lý và chức năng nó phải thực hiện hay không? Các ràng buộc thiết kế có thực tế không. Rủi ro công nghệ phát triển là gì? Các yêu cầu phần mềm khác đã được xem xét đến chưa? Các tiêu chuẩn hợp lệ đã được phát biểu chi tiết chưa? Liệu có sự không nhất quán, bỏ sót hay dư thừa nào không? Việc tiếp xúc với khách hàng có đầy đủ không? Người dùng đã xét duyệt bản Tài liệu sơ bộ của người dùng hay bản mẫu chưa? Các ước lượng về Kế hoạch dự án phần mềm bị ảnh hưởng thế nào? 5.6.2 Mức chi tiết Để đưa ra câu trả lời cho nhiều câu hỏi trên, việc xét duyệt có thể tập trung vào mức chi tiết. Tại đây, mối quan tâm tập trung vào từ ngữ của bản đặc tả. Việc xét duyệt chi tiết bản đặc tả có những gợi ý sau: Phải quan sát các từ nối có sức thuyết phục (như "chắc chắn", "do đó", "rõ ràng", "hiển nhiên", "từ đó suy ra rằng") và hỏi "tại sao chúng lại có ở đó?" Theo dõi những thuật ngữ mung lung (như "một số", "đôi khi", "thường", "thông thường", "bình thường", "phần lớn", "đa số"); để yêu cầu làm sáng tỏ Khi có nêu danh sách, nhưng không đầy đủ thì phải đảm bảo mọi khoản mục đề được hiểu rõ. Chú ý vào các từ như "vân vân", "cứ như thế", "cứ tiếp tục như thế", "sao cho", Phải chắc chắn phát biểu phạm vi không chứa những giả thiết không được nói rõ (như "mã hợp lệ trong khoảng 10 tới 100". Đó là số nguyên, số thực hay số hệ 16?) Phải nhận biết về các động từ mơ hồ như "xử lý", "loại bỏ". Có thể có nhiều cách hiểu về nó. Phải nhận biết các đại từ "vu vơ" (như "modul vào/ra liên lạc với modul kiểm tra tính hợp lệ dữ liệu và đặt cờ báo kiểm soát của nó") Tìm các câu có chứa sự chắc chắn (như "bao giờ", "mọi", "tất cả", "không một", "không bao giờ") rồi yêu cầu bằng chứng. Khi một thuật ngữ được định nghĩa tường minh tại một chỗ thì hãy thử thay thế định nghĩa này vào chỗ xuất hiện của nó Khi một cấu trúc được mô tả theo lời thì hãy vẽ ra bức tranh để giúp hiểu được nó Khi một tính toán được xác định thì hãy thử với ít nhất 2 ví dụ 39
40. Giáo trình tóm tắt Công Nghệ Phần Mềm Một khi việc xét duyệt đã hoàn tất thì bản đặc tả các yêu cầu phần mềm sẽ được cả khách hàng lẫn người phát triển "ký tắt". Bản đặc tả trở thành "hợp đồng" cho việc phát triển phần mềm. Những thay đổi trong yêu cầu được nêu ra sau khi bản đặc tả đã hoàn thành sẽ không bị loại bỏ, nhưng khách hàng phải lưu ý rằng từng thay đổi sau khi ký đều là một mở rộng của phạm vi phần mềm và do đó có thể làm tăng thêm chi phí và/hoặc kéo dài lịch biểu. Bản đặc tả rất khó "kiểm thử" theo một cách có nghĩa, do đó sự không nhất quán hay thiếu sót có thể bị bỏ qua không chú ý tới. Trong khi xét duyệt, người ta có thể khuyến cáo những thay đổi cho bản đặc tả. Có thể sẽ khó khăn để định lượng tác động toàn cục của thay đổi, tức là làm sao việc thay đổi trong một chức năng lại ảnh hưởng tới các yêu cầu cho chức năng khác? Người ta đã phát triển các công cụ đặc tả tự động hóa để giúp giải quyết vấn đề này. 6. Kỹ nghệ hệ thống và tạo nguyên mẫu 6.1 Kỹ nghệ hệ thống – system engineering 6.1.1 Các hoạt động cơ bản trong tiến trình phân tích hệ thống Bước 1: Xác định nhu cầu Bước đầu tiên của tiến trình phân tích hệ thống bao gồm việc xác định nhu cầu. Để bắt đầu, người phân tích giúp cho khách hàng trong việc xác định các mục tiêu của hệ thống (sản phẩm): thông tin nào cần phải tạo ra? thông tin nào cần được cung cấp? cần những chức năng và hiệu suất nào? Người phân tích phải phân biệt được giữa "nhu cầu" của khác hàng (những tính năng chủ chốt cho sự thành công của hệ thống) và "điều mong muốn" của khác hàng (những tính năng tốt nên có nhưng không bản chất) Một khi các mục tiêu tổng thể đã được xác định thì nhà phân tích chuyển sang việc đánh giá các thông tin phụ: Liệu có công nghệ để xây dựng hệ thống không? Cần có những tài nguyên chế tạo và phát triển đặc biệt nào? Cần phải đặt giới hạn nào về chi phí và lịch biểu? Nếu hệ thống mới thực tế là một sản phẩm để bán cho nhiều khách hàng thì nên có những câu hỏi sau: Đâu là thị trường tiềm năng cho sản phẩm này? Sản phẩm này so với các sản phầm cạnh tranh khác như thế nào? Sản phẩm này sẽ giữ vị trí nào trong tuyến sản phầm của cả công ty? Thông tin thu được trong bước xác định nhu cầu được kết tinh trong Tài liệu khái quát về hệ thống. Tài liệu khái quát nguyên bản đôi khi được khách hàng chuẩn bị trước cuộc gặp gỡ với người phân tích. Sự trao đổi thường xuyên giữa khách hàng - người phân tích tạo ra những thay đổi cho tài liệu này. Bước 2: Nghiên cứu khả thi Mọi dự án đều phải làm với sự hạn hẹp về tài nguyên và bảo đảm đúng ngày bàn giao. Cho nên cần phải thận trọng trong đánh giá tính khả thi của dự án từ thời điểm sớm nhất có thể được. 40
41. Giáo trình tóm tắt Công Nghệ Phần Mềm Phân tích khả thi và rủi ro có liên quan với nhau theo nhiều cách. Nếu rủi ro của dự án là lớn, thì tính khả thi của việc chế tạo phần mềm chất lượng sẽ bị giảm đi. Trong kỹ nghệ hệ thống, chúng ta tập trung vào bốn lĩnh vực quan tâm chính: 1. Khả thi về kinh tế: đánh giá về chi phí phát triển cần phải cân xứng với lợi tức cuối cùng hay lợi ích mà hệ thống được xây dựng đem lại. 2. Khả thi về kỹ thuật: khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng tới khả năng đạt tới một hệ thống chấp nhận được. 3. Khả thi về pháp lý: quy định của pháp luật về sự xâm phạm, vi phạm hay khó khăn nào có thể gây ra từ việc xây dựng hệ thống. 4. Khả thi về phương án: đánh giá tính khả thi của phương án đã xác định để tiếp cận tới việc xây dựng hệ thống. Luận chứng kinh tế nói chung là xem xét "nền tảng" cho hầu hết các hệ thống (các ngoại lệ là hệ thống quốc phòng, hệ thống luật, các ứng dụng công nghệ cao như chương trình không gian vũ trụ) Luận chứng kinh tế bao gồm: các mối quan tâm kể cả phân tích chi phí - lợi ích, chiến lược lợi tức dài hạn của công ty, ảnh hưởng tới các trung tâm hay sản phẩm lợi nhuận khác, chi phí cho tài nguyên cần cho việc xây dựng và phát triển thị trường tiềm năng Khả thi kĩ thuật thường là lĩnh vực khó thâm nhập nhất tại giai đoạn này trong tiến trình phát triển hệ thống. Điều thực chất là tiến trình phân tích và xác định nhu cầu cần được tiến hành song song với việc xác định chúng. Các xem xét thường được gắn với tính khả thi kĩ thuật bao gồm: Rủi ro xây dựng: Liệu các phần tử hệ thống có thể được thiết kế sao cho chức năng và hiệu suất cần thiết làm lộ rõ những ràng buộc trong khi phân tích không? Có sẵn tài nguyên: có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang xét không? Các tài nguyên cần thiết khác (phần cứng và phần mềm) có sẵn cho việc xây dựng hệ thống không? Công nghệ: công nghệ liên quan đã đạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống chưa? Người phát triển các hệ thống về bản chất đều lạc quan. Tuy nhiên, trong đánh giá tính khả thi kỹ thuật, việc đánh giá sai trong giai đoạn này cũng có thể là một thảm họa Tính khả thi pháp lý bao gồm một phạm vi rộng các mối quan tâm kể cả hợp đồng, nghĩa vụ pháp lý, việc đánh giá sai trong giai đoạn này cũng có thể là một thảm họa. Mức độ các phương án được xem xét tới thường bị giới hạn bởi ràng buộc chi phí và thời gian. Có thể soạn tư liệu về nghiên cứu khả thi thành một báo cáo riêng cho cấp quản lý trên và đính kèm như phụ lục cho đặc tả hệ thống. Mặc dầu định dạng của báo cáo khả thi có thể thay đổi nhưng bản đại cương dưới đây đã bao quát được hầu hết những điểm quan trọng: Bản đại cương về nghiên cứu khả thi I. Giới thiệu A. Phát biểu vấn đề 41
42. Giáo trình tóm tắt Công Nghệ Phần Mềm B. Môi trường thực hiện C. Ràng buộc II. Tóm tắt quản lý và khuyến cáo A. Những tóm lược quan trọng B. Bình luận C. Khuyến cáo D. Tác động III. Các phương án A. Các cấu hình hệ thống theo phương án B. Các tiêu chuẩn được dùng trong chọn lựa cách tiếp cận cuối cùng IV. Mô tả hệ thống A. Phát biểu vắn tắt về phạm vi B. Tính khả thi của các phần tử trong hệ thống V. Phân tích chi phí - lợi ích VI. Đánh giá rủi rõ kỹ thuật VII. Các chi nhánh pháp lý VIII. Các chủ đề khác chuyên cho dự án IX. Kết luận Bản nghiên cứu khả thi trước tiên được cấp quản lý dự án xem xét (để đánh giá độ tin cậy nội dung) rồi đến cấp quản lý cao hơn (để đánh giá trạng thái dự án). Bản nghiên cứu phải đề xuất quyết định "tiến hành/không tiến hành". Cũng cần chú ý rằng các quyết định tiến hành hay không tiến hành sẽ được đưa ra trong các bước lập kế hoạch, đặc tả và xây dựng cho cả công nghệ phần mềm và phân cứng. Bước 3: Mô hình hóa hệ thống -modeling Việc mô hình hóa và mô phỏng hệ thống được sử dụng để loại bỏ những điều bất ngờ khi xây dựng hệ thống. Những công cụ CASE được áp dụng trong các tiến trình kỹ nghệ hệ thống. Vai trò của công cụ mô hình hóa và mô phỏng được tóm tắt như sau: - Cung cấp một phương án cho tiến trình thiết kế, cài đặt và kiểm thử; thông qua việc tiếp cận các công cụ mô hình hoá (một công cụ mô hình hóa và mô phỏng) - Cho phép xây dựng một mô hình đề cập tới tất cả các vấn đề luồng chức năng và dữ liệu thông thường đồng thời còn bao quát cả các khía cạnh hành động, hành vi của hệ thống. Có thể kiểm thử mô hình này bằng các công cụ phục vụ giám định và gỡ lỗi cho đặc tả và tìm kiếm thông tin. - Dùng để "kiểm thử sự hoạt động" của đặc tả hệ thống: bằng cách kiểm thử mô hình (đặc tả), người kỹ sư hệ thống có thể hình dung được cách thức mà hệ thống sẽ hành xử ra sao khi được cài đặt. Người ta có thể sử dụng câu hỏi cái gì xẩy ra nếu đi theo các kịch bản; xác định, kiểm tra rằng những tình huống mong muốn nào đó có xuất hiện hay không, và các tình huống không mong muốn khác sẽ không xuất hiện hay lại xuất hiện. 6.1.2 Đặc tả hệ thống Bản Đặc tả hệ thống: 42
43. Giáo trình tóm tắt Công Nghệ Phần Mềm là một tài liệu làm nền tảng cho kỹ nghệ phần cứng, kỹ nghệ phần mềm, kỹ nghệ cơ sở dữ liệu và kỹ nghệ con người. mô tả về chức năng và hiệu suất của hệ thống và những ràng buộc hệ thống. quy định cả giới hạn cho từng phần tử hệ thống. Chẳng hạn, chỉ dẫn về vai trò của phần mềm trong hệ thống và các hệ thống con người khác nhau được mô tả trong biểu đồ luồng kiến trúc mô tả thông tin (dữ liệu và điều khiển) vào/ ra khỏi hệ thống Dàn bài về bản đặc tả hệ thống sẽ được trình bày sau đây. Tuy nhiên cần lưu ý rằng đây chỉ là một trong nhiều dàn bài có thể được dùng để định nghĩa một tài liệu mô tả hệ thống. Định dạng và nội dung thực tế có thể còn tùy vào các chuẩn kỹ nghệ hệ thống hay phần mềm. Nó được điều chỉnh theo yêu cầu và tính ưa chuộng của người dùng. Dàn bài đặc tả hệ thống I. Giới thiệu A. Phạm vi và mục tiêu của dự án B. Tổng quan 1. Mục tiêu 2. Ràng buộc II. Mô tả chức năng và dữ liệu A. Kiến trúc hệ thống 1. Biểu đồ ngữ cảnh kiến trúc 2. Mô tả về biểu đồ ngữ cảnh hệ thống III. Mô tả các hệ thống con A. Đặc tả biểu đồ kiến trúc cho hệ con n 1. Biểu đồ luồng kiến trúc 2. Chú giải modul hệ thống 3. Vấn đề về hiệu suất 4. Ràng buộc thiết kế 5. Cách tạo các thành phần hệ thống B. Từ điển kiến trúc C. Biểu đồ và mô tả liên nối hệ thống IV. Các kết quả mô hình hóa và mô phỏng A. Mô hình hệ thống được dùng cho mô hệ thống phỏng B. Kết quả mô phỏng C. Vấn đề hiệu suất đặc biệt V. Vấn đề dự án A. Chi phí xây dựng dự phòng B. Lịch biểu dự phòng VI. Phụ lục Xét duyệt đặc tả hệ thống Cuộc họp xét duyệt đặc tả hệ thống đánh giá tính đúng đắn của định nghĩa chứa trong bản đặc tả hệ thống: Cuộc họp được cả người phát triển và khách hàng đảm bảo rằng: 1. Phạm vi của dự án đã được vạch ra đúng 2. Các chức năng, hiệu suất và giao diện đã được định nghĩa đúng 43
44. Giáo trình tóm tắt Công Nghệ Phần Mềm 3. Phân tích rủi ro môi trường và tính khả triển của dự án 4. Người phát triển và khách hàng có cùng cảm nhận về mục tiêu hệ thống Cuộc họp đặc tả hệ thống được tiến hành trong giai đoạn đưa ra những quan điểm quản lý áp dụng cho hệ thống tiến hành đánh giá kỹ thuật về các phần tử và chức năng hệ thống Về khía cạnh quản lý, đặc tả hệ thống cần phải thỏa mãn những câu hỏi sau: Nhu cầu kinh doanh của hãng đã được thiết lập chưa? Luận chứng hệ thống có nghĩa không? Có cần môi trường (hay thị trường) riêng cho hệ thống đã được mô tả hay không? Những phương án nào đã được xem xét? Rủi ro phát triển cho từng phần tử hệ thống là gì? Các tài nguyên đã có sẵn cho việc xây dựng hệ thống chưa? Các giới hạn chi phí và lịch biểu có ý nghĩa gì không? Các câu hỏi trên nên được đặt ra và trả lời một cách đều đặn trong nhiệm vụ phân tích. Một câu hỏi nên được xem xét lại tại giai đoạn đánh giá kỹ thuật. Mức độ chi tiết trong giai đoạn đánh giá kỹ thuật (họp xét duyệt hệ thống) phụ thuộc vào mức độ chi tiết trong nhiệm vụ xác định ban đầu. Việc xét duyệt nên bao gồm các vấn đề sau: Về chức năng của hệ thống: có phù hợp với những định giá về rủi ro phát triển, chi phí và lịch biểu hay không? Các chức năng được xác định đã đủ chi tiết chưa? Giao diện giữa các phần tử hệ thống và với môi trường đã được xác định đủ chi tiết chưa? Các vấn đề độ tin cậy, hiệu suất và bảo trì đã được đề cập tới trong bản đặc tả chưa? Liệu bản đặc tả hệ thống có cung cấp đủ nền tảng cho các bước kỹ nghệ phần cứng và phần mềm tiếp sau không? Kết luận: Sau cuộc họp xét duyệt, tiến hành các tiến trình kỹ nghệ tương ứng với các phần tử hệ thống chủ chốt như phần mềm, phần cứng, con người và CSDL. Các phần tử phần cứng, con người và CSDL của hệ thốn được đề cập tới như phần tương ứng của các tiến trình kỹ nghệ Tại bước phân tích hệ thống người phân tích xác định ra nhu cầu của khách hàng, xác định tính khả thi kinh tế - kỹ thuật, xác định chức năng và hiệu suất cho các phần tử hệ thống chủ chốt (phần mềm, phần cứng, con người và CSDL) Bản đặc tả hệ thống (tài liệu nền tảng cho toàn bộ công việc kỹ nghệ tiếp sau đó) được coi là đỉnh cao của nhiệm vụ kỹ nghệ hệ thống Phải đảm bảo việc trao đổi liên lạc đều đặn giữa khách hàng và nhà phân tích vì nếu trao đổi giữa nhà phân tích và khách hàng bị gián đoạn tại giai đoạn này thì sự thành công của toàn bộ dự án sẽ bị đe dọa Khó khăn là ở chỗ phải lập các tư liệu hệ thống sao cho: 44
45. Giáo trình tóm tắt Công Nghệ Phần Mềm Dễ hiểu cho người sử dụng Tạo ra bản đặc tả hệ thống (cùng với đặc tả yêu cầu, được dùng làm cơ sở cho một hợp đồng giữa người mua và người cung cấp phần mềm đó). Nói chung, người dùng ưa thích một môt tả hệ thống trừu tượng chứ không thích một đặc tả chi tiết. 6.2 Tạo nguyên mẫu (prototype) Duyệt lại là một phần của quá trình thẩm định yêu cầu. Từ đặc tả yêu cầu ta có thể tưởng tượng hệ thống sẽ được sử dụng như thế nào. Một chức năng được mô tả trong một đặc tả là hữu ích và đã được xác định tốt nhưng thực tế việc sử dụng chức năng đó kết hợp với các chức năng khác lại để lộ ra rằng cái nhìn ban đầu của người sử dụng đã không đúng và không đầy đủ. Một cách giải quyết khó khăn đó là phát triển một nguyên mẫu hệ thống cho phép người sử dụng thí nghiệm trên nguyên mẫu đó. Các yêu cầu của hệ thống được thẩm định và người dùng sẽ phát hiện ra các sai sót. Sự khác biệt giữa nguyên mẫu phần mềm với nguyên mẫu phần cứng: Nguyên mẫu phần mềm hoàn toàn khác với nguyên mẫu phần cứng. Khi phát triển các hệ thống phần cứng, thì thực tế người ta phát triển một nguyên mẫu hệ thống để thẩm định thiết kế hệ thống. Một nguyên mẫu hệ thống điện tử có thể được thực hiện và được thử nghiệm bằng cách dùng các thành phần chưa được ráp vao vỏ trước khi đầu tư vào các mạch tích hợp chuyên dụng đắt tiền để thực hiện một đời sản phẩm mới của hệ thống. Một nguyên mẫu phần mềm là không phải nhằm vào việc thẩm định thiết kế (thiết kế của nó thường là hoàn toàn khác với hệ thống đã phát triển cuối cùng), mà là để thẩm định yêu cầu của người sử dụng phần mềm. 6.2.1 Lợi ích của việc phát triển nguyên mẫu Việc phát triển nguyên mẫu ngay từ sớm trong quá trình phát triển phần mềm là: 1. Sự hiểu lầm giữa những người phát triển phần mềm và những người sử dụng phần mềm có thể được nhận thấy rõ khi các chức năng của hệ thống được trình diễn 2. Sự thiếu hụt các dịch vụ người dùng có thể được phát hiện 3. Sự khó sử dụng hoặc sự nhầm lẫn các dịch vụ người dùng có thể được thấy rõ và được sửa sang lại 4. Đội ngũ phát triển phần mềm có thể tìm ra được các yêu cầu không đầy đủ hoặc không kiên định khi họ phát triển nguyên mẫu. 5. Một hệ thống hoạt động được (mặc dầu là hạn chế) là bằng chứng thuyết minh cho tính khả thi và tính hữu ích của ứng dụng đó cho các nhà quản lý 6. Nguyên mẫu đó được dùng làm cơ sở cho việc viết đặc tả cho sản phẩm Mặc dù mục tiêu chủ yếu của việc tạo nguyên mẫu là thẩm định các yêu cầu phần mềm cũng nên chỉ ra rằng một nguyên mẫu phần mềm cũng có các ứng dụng khác: 1. Dùng để huấn luyện người sử dụng ngay từ trước khi hệ thống được phân phối 2. Dùng trong quá trình thử nghiệm hệ thống. Điều đó nghĩa là cùng các trường hợp thử như nhau vừa dùng cho thử nguyên mẫu vừa cho thử hệ thống. Kết quả khác nhau có nghĩa là có sai sót. Tạo nguyên mẫu là một kỹ thuật giảm bớt rủi ro. Một rủi ro lớn trong việc phát triển phần mềm là các sai sót mà đến giai đoạn cuối mới phát hiện và chỉnh sửa là rất tốn kém. Kinh 45
46. Giáo trình tóm tắt Công Nghệ Phần Mềm nghiệm cho thấy rằng việc tạo nguyên mẫu sẽ giảm bớt số các vấn đề của đặc tả yêu cầu và tổng chi phí của việc phát triển có thể là thấp hơn nếu ta phát triển nguyên mẫu. 6.2.2 Các giai đoạn trong việc phát triển nguyên mẫu 1. Thiết lập các mục tiêu của việc tạo nguyên mẫu, chọn input, output cho nguyên mẫu. 2. Chọn các chức năng cho việc tạo nguyên mẫu và quyết định những đặc tả phi chức năng nào cần có trong nguyên mẫu 3. Phát triển nguyên mẫu 4. Đánh giá hệ nguyên mẫu Cần phải làm rõ ràng các mục tiêu tạo nguyên mẫu trước khi bắt đầu công việc. Mục tiêu đó có thể là phát triển một hệ thống liên quan chủ yếu đến tạo nguyên mẫu giao diện người dùng; nó cũng có thể là việc phát triển một hệ thống thẩm định các yêu cầu hệ thống chức năng, nó cũng có thể là phát triển một hệ thống để trình diễn tính khả thi của ứng dụng cho các nhà quản lý xem xét, CÙng một nguyên mẫu không thể đạt được tất cả các mục tiêu. Nếu mục tiêu còn chưa rõ ràng thì người quản lý hoặc người sử dụng có thể hiểu nhầm chức năng của nguyên mẫu và không đạt được lợi ích thiết thực đầy đủ của việc tạo nguyên mẫu. Giai đoạn tiếp theo trong quá trình này là quyết định xem cái gì được đưa vào và cái gì được lấy ra từ hệ nguyên mẫu đó. Nguyên mẫu của phần mềm là đắt nến nó được thực hiện bằng cách dùng cùng các công cụ và các chuẩn y như cho chính hệ thống cuối cùng Bởi vậy, có thể quyết định tạo nguyên mẫu cho tất cả các chức năng của hệ thống nhưng ở mức thu gọn. Cũng có thể chỉ một số chức năng hệ thống được tạo mẫu. Bình thường trong thực tế người ta hay bỏ bớt các yêu cầu phi chức năng chẳng hạn như yêu cầu về tốc độ, về không gian nhớ. Việc sử lý sai sót và việc quản trị có thể được bỏ qua và có thể là thừa khi mục tiêu của việc tạo mẫu là thiết lập một giao diện người máy. Các chuẩn của độ tin cậy và của chất lượng chương trình cũng có thể chưa tính đến. Giai đoạn cuối cùng của quá trình này là đánh giá nguyên mẫu. Có người cho rằng đây là giai đoạn quan trọng nhất của việc tạo nguyên mẫu. Phải dự tính cho việc huấn luyện người sử dụng trong giai đoạn này và các mục tiêu của việc tạo mẫu hẳn là nên dẫn ra một kế hoạch đánh giá. Phải có đủ thời gian cho người sử dụng trở nên dễ chịu với hệ thống và thiết lập mẫu sử dụng chuẩn tắc và bởi vậy phát hiện được các sai sót yêu cầu Việc tạo nguyên mẫu là kỹ thuật chính trong mô hình quá trình xoắn ốc hỗ trợ định giá rủi ro. 6.2.3 Tạo nguyên mẫu trong tiến trình phần mềm Vấn đề cơ bản là khó đánh giá phần mềm mới được xây dựng có ảnh hưởng thế nào tới công việc của người dùng. Đối với các hệ thống mới, đặc biệt là đối với các hệ thống lớn và phức tạp thì có lẽ là không thể đánh giá được trước khi hệ thống được xây dựng xong và đưa vào ứng dụng. Một cách để vượt qua khó khăn là sử dụng cách tiếp cận thăm dò để phát triển hệ thống. Điều này có nghĩa là trình bày cho người dùng một hệ thống chưa đầy đủ và rồi cải biên nó tăng cường hệ thống đó khi mà các yêu cầu thực của người dùng trở nên trong suốt. Sau khi đánh giá nguyên mẫu đó sẽ bị loại và một hệ chất lượng tốt hơn sẽ được xây dựng. Thiết lập đặc tả, thiết lập nguyên tắc chung Phát triển nguyên mẫu Đánh giá nguyên mẫu Đặc tả hệ thống Thiết kế và thực thi hệ thống 46 Thẩm định hệ thống
47. Giáo trình tóm tắt Công Nghệ Phần Mềm H2.5 Việc tạo nguyên mẫu tromg quá trình phần mềm Sự khác biệt của hai cách tiếp cận: 1. Lập trình thăm dò: Bắt đầu với một hiểu biết mơ hồ về yêu cầu hệ thống và hệ thống sẽ được tăng cường một khi các yêu cầu mới được phát hiện. Chẳng có gì giống như một đặc tả hệ thống và sự thật hệ thống được phát triển theo cách tiếp cận này thì không thể đặc tả được (ví dụ: một vài hệ trí tuệ nhân tạo là không thể đặc tả được) 2. Cách tiếp cận tạo nguyên mẫu: nhằm phát hiện ra đặc tả hệ thống và kết quả của giai đoạn phát triển nguyên mẫu là bản đặc tả đó mở rộng quá trình phân tích yêu cầu nhằm rút bớt tổng chi phí cho toàn bộ vòng đời phần mềm làm sáng tỏ các yêu cầu cung cấp các thông tin phụ cho người quản lý để họ đánh giá các rủi ro của dự án Sau khi đánh giá, nguyên mẫu đó không dùng để phát triển hệ thống nữa. Thay thế cho việc dẫn xuất ra đặc tả từ nguyên mẫu, đôi khi người ta đề xuất là đặc tả hệ thống chính là sự thực hiện nguyên mẫu đó. Chỉ dẫn này giúp người ký hợp đồng chỉ đơn giản là hãy viết một hệ thống kiểu như thế này. 6.2.4 Hạn chế của cách tiếp cận tạo nguyên mẫu 1. Các đặc điểm hệ thống quan trọng có thể nằm ngoài nguyên mẫu để đơn giản hóa việc thực hiện nhanh. Sự thực là không thể tạo nguyên mẫu cho một vài phần quan trong nhất của hệ thống như các đặc điểm về sự an toàn/ nguy kịch. 2. Các yêu cầu phi chức năng như các yêu cầu liên quan đến độ tin cậy, tính mâu thuẫn và độ an toàn là không thể biểu thị đầy đủ trong khi thực hiện nguyên mẫu. 3. Người dùng có thể không dùng nguyên mẫu y như cách dùng một hệ đang hoạt động Có một vài lý do dẫn tới việc tái tạo nguyên mẫu khi một hệ thống lớn và tuổi thọ cao được phát triển 1. Các đặc trưng hệ thống quan trọng chẳng hạn như sự thực thi, an ninh, tính không mâu thuẫn, độ tin cậy có thể được lờ đi khi tạo nguyên mẫu để cho có thể thực thi nhanh nguyên mẫu. Bản chất của nguyên mẫu có thể lại là những đặc trưng đó không thể thêm vào nguyên mẫu. 2. Trong quá trình phát triển nguyên mẫu thì nguyên mẫu sẽ bị thay đổi để phản ánh các nhu cầu của người dùng và dường như các thay đổi đó sẽ được tiến hành theo một cách không thể không chế được. 3. Các thay đổi trong quá trình phát triển nguyên mẫu sẽ có thể làm giảm sút cấu trúc hệ thống đến mức mà do yêu cầu bảo trì nên các thay đổi tiếp theo càng ngày càng trở nên khó khăn hơn Phát triển nguyên mẫu là dễ quản lý hơn lập trình thăm do vì các chuẩn quá trình phần mềm là được tuân theo. Các kế hoạch và các tư liệu có thể viết thêm cho mỗi phần thêm vào. 6.2.5 Các bước tiến hành làm nguyên mẫu phần mềm Bước 1: Đánh giá yêu cầu phần mềm và xác định liệu phần mềm cần xây dựng có xứng đáng để làm nguyên mẫu không 47
48. Giáo trình tóm tắt Công Nghệ Phần Mềm Không phải tất cả các phần mềm đều có thể đưa tới làm nguyên mẫu. Ta có thể xác định một nhân tố làm nguyên mẫu: lĩnh vực ứng dụng, độ phức tạp ứng dụng, đặc trưng khách hàng và đặc trưng dự án. Nói chung, bất kỳ ứng dụng nào tạo ra việc hiển thị trực quan động, tương tác nhiều với người, hay yêu cầu các thuật toán hay việc xử lý tổ hợp mà cần phải được xây dựng theo một cách tiến hóa thì đều có thể làm nguyên mẫu. Tuy nhiên, những lĩnh vực ứng dụng này phải được cân nhắc dựa trên độ phức tạp của ứng dụng. Nếu một ứng dụng yêu cầu xây dựng tới 10 ngàn dòng mã lệnh thì phần chắc là nó quá phức tạp không thể làm nguyên mẫu được. Tuy nhiên nếu ta có thể phân hoạch độ phức tạp thì vẫn có thể làm nguyên mẫu cho từng phần của phần mềm. Để đảm bảo tính tương tác giữa khách hàng với nguyên mẫu cần: 1. Khách hàng phải cam kết dùng tài nguyên để đánh giá và làm mịn nguyên mẫu 2. Khách hàng phải có khả năng đưa ra những quyết định về yêu cầu một cách kịp thời. Bản chất của dự án quyết định tính hiệu quả của làm nguyên mẫu. Bước 2: Với một dự án chấp thuận được người phân tích xây dựng một biểu diễn vắn tắt các yêu cầu Trước khi có thể bắt đầu xây dựng một nguyên mẫu, người phân tích phải biểu diễn miền thông tin và các lĩnh vực hành vi và chức năng của vấn đề rồi xây dựng một cách tiếp cận hợp lý tới việc phân hoạch. Có thể ứng dụng các nguyên lý phân tích nền tảng (trên xuống) và các phương pháp phân tích yêu cầu. Bước 3: Sau khi đã duyệt mô hình và yêu cầu, tạo ra một đặc tả thiết kế vắn tắt cho nguyên mẫu Việc thiết kế phải xuất hiện trước khi bắt đầu làm nguyên mẫu. Tuy nhiên phải thiết kế tập trung chủ yếu vào các vấn đề thiết kế dữ liệu và kiến trúc mức đỉnh chứ không phải tập trung vào thiết kế thủ tục chi tiết. Bước 4: Phần mềm nguyên mẫu được tạo ra, kiểm thử và làm mịn Một cách lý tưởng, các khối xây dựng phần mềm hiện có được dùng để tạo ra nguyên mẫu một cách nhanh chóng. Bước 5: Một khi đã kiểm thử song nguyên mẫu thì có thể trình bày nó cho khách hàng Khách hàng sẽ kiểm thử ứng dụng và gợi ý những thay đổi. Bước này cốt lõi của cách tiếp cận làm nguyên mẫu. Chính ở đây mà khách hàng có thể xem xét cách biểu diễn được cài đặt cho yêu cầu phần mềm, gợi ý những thay đổi làm cho phần mềm đáp ứng tốt hơn với các nhu cầu thực tế. Bước 6: Lặp lại các bước 4 và 5 cho tới khi tất cả các yêu cầu đã được hình thức hóa hay cho tới khi nguyên mẫu đã tiến hóa thành một hệ thống sản phẩm cuối cùng. Khuôn mẫu làm nguyên mẫu có thể được tiến hành với một trong 2 mục tiêu: 1. Mục tiêu của việc làm nguyên mẫu là thiết lập một tập hợp các yêu cầu hình thức có thể được dịch thành phần mềm (sản xuất bằng các phương pháp và kỹ thuật của kỹ nghệ phần mềm) 2. Mục tiêu của việc làm nguyên mẫu là cung cấp động lực liên tục thúc đẩy phát triển tiến hóa phần mềm. 6.2.6 Các phương pháp và công cụ làm nguyên mẫu Để việc làm nguyên mẫu phần mềm được hiệu quả, phải xây dựng nhanh chóng nguyên mẫu sao cho khách hàng có thể định giá được kết quả và khuyến cáo những thay đổi. 48