Đề cương môn học phân tích thiết kế phần mềm

Nội dung text: Đề cương môn học phân tích thiết kế phần mềm

1. TRƢỜNG ĐẠI HỌC SƢ PHẠ M KỸ THUẬT HƢNG YÊN KHOA CÔNG NGHỆ THÔNG TIN ĐỀ CƢƠNG MÔN HỌC PHÂN TÍCH THIẾT KẾ PHẦN MỀM Trình độ đào tạo: Cao đẳng Ngàng đào tạo: Công nghệ Thông tin Hƣng Yên – Tháng 1 năm 2011 1
2. LỜI MỞ ĐẦU Ngày nay, công nghệ phần mềm đã đi tới một kỷ nguyên mới, tên gọi công việc "kỹ sư phần mềm" đã thay thế cho "người lập trình". Việc đặc tả các yêu cầu, phát triển phần mềm, quản lý, bảo trì phần mềm là các hoạt động của công nghệ phần mềm để tạo nên các sản phẩm phần mềm cho người sử dụng. Mục đích của cuốn đề cương Phân tích thiết kế phần mềm nhằm cung cấp cho sinh viên công nghệ thông tin các kiến thức cơ bản về: nguyên tắc, phương pháp luận, quy trình và các kỹ thuật để xây dựng cũng như bảo trì các sản phẩm phần mềm. Do vậy, cuốn đề cương cung cấp các kiến thức cơ bản về: xác định yêu cầu phần mềm, đặc tả yêu cầu, phân tích, thiết kế, cài đặt phần mềm, kiểm thử phần mềm, bảo trì và quản lý thay đổi phần mềm. Để tiếp thu tốt kiến thức trong cuốn đề cương này, sinh viên cần nắm được các kiến thức cơ bản đã được trang bị ở năm thứ nhất và thứ hai như: Cở sở kỹ thuật lập trình, cơ sở dữ liệu quan hệ, cấu trúc dữ liệu và giải thuật và một số môn cơ sở khác. Mặc dầu có cố gắng song bản thân còn nhiều hạn chế nên cuốn đề cương không tránh khỏi những thiếu sót, rất mong nhận được các ý kiến đóng góp của bạn đọc. Giáo trình có sử dụng tư liệu của các đồng nghiệp, tài liệu của Công ty cổ phần điện tử tin học Việt Nam FSC. 2
3. MỤC LỤC LỜI MỞ ĐẦU 2 MỤC LỤC 3 CHƢƠNG 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 8 1.1. Một số khái niệm 8 1.2. Nhân tố con người và phân loại nghề nghiệp 10 1.2.1. Nhân tố con người trong ngành công nghiệp phần mềm 10 1.2.2. Phân loại nghề nghiệp 10 1.3. Sản phẩm phần mềm – đặc tính và phần loại 16 1.3.1. Các đặc tính phần mềm 17 1.3.2. Phân loại phần mềm 18 1.4. Một số mô hình xây dựng phần mềm 21 1.4.1. Mô hình tuyến tính (The linear sequential model) 21 1.4.2. Mô hình mẫu (Prototyping model) 22 1.4.3. Mô hình xoắn ốc (The spiral model) 23 1.4.4. Mô hình thác nước 24 1.4.5. Mô hình phát triển dựa trên thành phần 25 1.5. Phương pháp phát triển phần mềm 25 1.6. Vai trò của người dùng trong giai đoạn phát triển phần mềm 26 1.7. Tiêu chuẩn của sản phẩm phần mềm 27 1.7.1. Tính đúng 27 1.7.2. Tính khoa học 28 1.7.3. Tính tin cậy 28 1.7.4. Tính kiểm thử được 28 1.7.5. Tính hữu hiệu 28 1.7.6. Tính sáng tạo 28 1.7.7. Tính an toàn 29 1.7.8. Tính toàn vẹn 29 1.7.9. Tính đối xứng và đầy đủ chức năng 29 1.7.10. Tính tiêu chuẩn và tính chuẩn 29 1.7.11. Tính độc lập 30 1.7.12. Tính dễ phát triển, hoàn thiện 30 3
4. 1.7.13. Một số tính chất khác 30 1.8. Quản lý dự án phần mềm 30 1.8.1. Các hoạt động chuẩn bị dự án 30 1.8.2. Lập kế hoạch dự án 31 1.8.3. Nghiên cứu tính khả thi dự án 32 1.8.4. Lựa chọn giải pháp 33 1.8.5. Giám sát và kiểm soát 35 1.8.6. Quản lý nhân sự 40 1.9. Hồ sơ của sản phẩm phần mềm 40 CHƢƠNG 2: KHẢO SÁT - PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 41 2.1. Tìm hiểu – xác định yêu cầu 41 2.1.1. Khảo sát, tìm hiểu yêu cầu 41 2.1.2. Đánh giá các yêu cầu 43 2.2. Phân tích yêu cầu 44 2.3. Đặc tả yêu cầu 46 2.3.1. Đặc tả yêu cầu 46 2.3.2. Nguyên lý đặc tả 48 2.4. Tư liệu hóa yêu cầu của phần mềm 49 2.5. Đặc tính dữ liệu và các kỹ thuật để thu thập dữ liệu 51 2.5.1. Đặc tính dữ liệu 51 2.5.2. Các kỹ thuật để thu thập dữ liệu cho ứng dụng 54 CHƢƠNG 3: THIẾT KẾ PHẦN MỀM 64 3.1. Đặc điểm của quá trình thiết kế phần mềm 64 3.2. Các hoạt động của quá trình thiết kế phần mềm 66 3.3. Nền tảng thiết kế phần mềm 69 3.3.1. Trừu tượng (abstraction) 69 3.3.2. Làm mịn (Refinement) 70 3.3.3. Tính module 70 3.3.4. Kiến trúc phần mềm 70 3.3.5. Che dấu thông tin 72 3.3.6. Thiết kế module 73 3.4. Chất lượng thiết kế 73 4
5. 3.4.1. Sự kết dính 73 3.4.2. Sự ghép nối 74 3.4.3. Sự hiểu được 74 3.4.4. Sự thích nghi được 75 3.4.5. Một số yêu cầu thiết kế 76 3.5. Chiến lược thiết kế 77 3.5.1. Thiết kế hướng chức năng 78 3.5.2. Thiết kế hướng đối tượng 79 3.6. Thiết kế kiến trúc cho ứng dụng và các mô hình cho thiết kế ứng dụng 80 3.6.1. Thiết kế kiến trúc ứng dụng 80 3.6.2. Các mô hình thiết kế ứng dụng 81 3.7. Thiết kế giao diện người dùng 84 3.7.1. Nhân tố con người 84 3.7.2. Phong cách tương tác người - máy 85 3.7.3. Thiết kế giao diện người - máy 85 3.7.4. Hướng dẫn thiết kế giao diện 87 CHƢƠNG 4: CÀI ĐẶT PHẦN MỀM 90 4.1. Phong cách cài đặt chương trình 90 4.1.1. Tài liệu chương trình 90 4.1.2. Khai báo dữ liệu 92 4.1.3. Xây dựng câu lệnh 92 4.1.4. Vào và ra 92 4.2. Nền tảng của ngôn ngữ lập trình 93 4.2.1. Kiểu dữ liệu, định nghĩa kiểu dữ liệu và kiểm tra kiểu dữ liệu 93 4.2.2. Chương trình con 94 4.2.3. Cấu trúc điều khiển 95 4.2.4. Vào và ra dữ liệu 96 4.2.5. Quản lý bộ nhớ 97 4.2.6. Quản lý lỗi 97 4.3. Các đặc trưng của ngôn ngữ cài đặt 97 4.4. Hiệu quả của chương trình và tầm quan trọng 98 4.5. Một số vấn đề trong cải tiến hiệu suất 99 5
6. 4.5.1. Tốc độ xử lý 99 4.5.2. Không gian bộ nhớ 99 4.5.3. Lựa chọn hệ thống và phần cứng 100 4.6. Công cụ trợ giúp và phân loại 100 4.6.1. Công cụ CASE 100 4.6.2. Phân loại các công cụ CASE 103 CHƢƠNG 5: KIỂM TRA CHẤT LƢỢNG PHẦN MỀM 111 5.1. Độ tin cậy của phần mềm 111 5.1.1. Chất lượng phần mềm và việc đảm bảo chất lượng phần mềm 111 5.1.2. Độ tin cậy của phần mềm 113 5.2. Kiểm tra và các chiến lược kiểm tra phần mềm 117 5.2.1. Đặc điểm của kiểm tra phần mềm 117 5.2.2. Chiến lược kiểm tra phần mềm 120 5.3. Kỹ thuật kiểm thử phần mềm và đặc điểm 124 5.3.1. Khái niệm 124 5.3.2. Đặc điểm của kiểm thử 124 5.3.3. Kế hoạch thử nghiệm 126 5.3.4. Phân loại một số công cụ kiểm thử tự động 126 CHƢƠNG 6: BẢO TRÌ PHẦN MỀM VÀ QUẢN LÝ THAY ĐỔI PHẦN MỀM 128 6.1. Hoạt động bảo trì phần mềm và phân loại 128 6.1.1. Bảo trì hiệu chỉnh 128 6.1.2. Bảo trì tiếp hợp 128 6.1.3. Bảo trì hoàn thiện 128 6.1.4. Bảo trì phòng ngừa 129 6.2. Đặc điểm của bảo trì phần mềm 129 6.2.1. Bảo trì có cấu trúc đối với bảo trì không cấu trúc. 129 6.2.2. Giá thành bảo trì 130 6.2.3. Một số vấn đề khác 131 6.3. Công việc bảo trì phần mềm và một số hiệu ứng lề 132 6.3.1. Khả năng bảo trì 132 6.3.2. Các công việc bảo trì 133 6
7. 6.3.3. Một số hiệu ứng lề của công việc bảo trì 135 6.4. Một số hình thức bảo trì phần mềm 137 6.4.1. Bảo trì mã chương trình xa lạ 137 6.4.2. Công nghệ phản hồi và công nghệ tái sử dụng 137 6.4.3. Bảo trì phòng ngừa 138 6.4.4. Chiến lược phần mềm thành phần 139 6.5. Quản lý thay đổi phần mềm 139 6.5.1. Các thủ tục quản lý thay đổi 139 6.5.2. Ghi quyết định theo thời gian 142 6.5.3. Quản lý thay đổi tài liệu 142 TÀI LIỆU THAM KHẢO 143 7
8. CHƢƠNG 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM Công nghệ phần mềm - Software Engineering - là các hoạt động bao gồm: phát triển, đưa vào hoạt động, bảo trì, và loại bỏ phần mềm một cách có hệ thống. Các kỹ sư phần mềm sẽ được cung cấp với các kỹ thuật, công cụ cơ bản nhằm phát triển các hệ thống phần mềm. Như vậy, công nghệ phần mềm là lĩnh vực nghiên cứu của tin học, nhằm đề xuất các nguyên lý, phương pháp, công cụ, cách tiếp cận và phương tiện phục vụ cho việc thiết kế và cài đặt các sản phẩm phần mềm có chất lượng. Ngày nay, sự phát triển phần mềm ngày càng thực sự khó kiểm soát được; các dự án phần mềm thường kéo dài và vượt quá chi phí cho phép. Những nhà lập trình chuyên nghiệp phải cố gắng hoàn thành các dự án phần mềm một cách có chất lượng, đúng hạn trong chi phí cho phép. Mục đích của chương này là đưa ra những nhận định cơ bản và tạo nên một bức tranh cơ sở về những phương pháp tiếp cận khác nhau của công việc tạo nên công nghệ phần mềm. Các vấn đề cần làm rõ, chi tiết thêm sẽ được trình bày ở các chương tiếp sau của giáo trình. 1.1. Một số khái niệm Mục tiêu của công nghệ phần mềm là tạo ra những phần mềm tốt, giảm đến tối thiểu những may rủi có thể gây cho các người liên quan. Trong quá trình đề cập, chúng ta sử dụng các thuật ngữ: Phần mềm (software): là một tập hợp các câu lệnh được viết bằng một hoặc nhiều ngôn ngữ lập trình, nhằm tự động thực hiện một số các chức năng giải quyết một bài toán nào đó. Công nghệ (engineering): là cách sử dụng các công cụ, các kỹ thuật trong cách giải quyết một vấn đề nào đó. Công nghệ phần mềm (software engineering): là việc áp dụng các công cụ, các kỹ thuật một cách hệ thống trong việc phát triển các ứng dụng dựa trên máy tính. Đó chính là việc áp dụng các quan điểm, các tiến trình có kỷ luật và lượng hoá được, có bài bản và hệ thống để phát triển, vận hành và bảo trì phần mềm. Theo quan điểm của nhiều nhà nghiên cứu, có thể nhìn công nghệ phần mềm là một mô hình được phân theo ba tầng mà tất cả các tầng này đều nhằm tới mục tiêu chất lượng, chi phí, thời hạn phát triển phần mềm. 8
9. Mô hình được phân theo ba tầng của công nghệ phần mềm được mô tả như sau: Ở đây tầng quy trình (process) liên quan tới vấn đề quản trị phát triển phần mềm như lập kế hoạch, quản trị chất lượng, tiến độ, chi phí, mua bán sản phẩm phụ, cấu hình phần mềm, quản trị sự thay đổi, quản trị nhân sự (trong môi trường làm việc nhóm), việc chuyển giao, đào tạo, tài liệu; Tầng phương pháp (methods) hay cách thức, công nghệ, kỹ thuật để làm phần mềm: liên quan đến tất cả các công đoạn phát triển hệ thống như nghiên cứu yêu cầu, thiết kế, lập trình, kiểm thử và bảo trì. Phương pháp dựa trên những nguyên lý cơ bản nhất cho tất cả các lĩnh vực công nghệ kể cả các hoạt động mô hình hoá và kỹ thuật mô tả. Tầng công cụ (tools) liên quan đến việc cung cấp các phương tiện hỗ trợ tự động hay bán tự động cho các tầng quá trình và phương pháp (công nghệ). Qua sơ đồ trên, ta thấy rõ công nghệ phần mềm là một khái niệm đề cập không chỉ tới các công nghệ và công cụ phần mềm mà còn tới cả cách thức phối hợp công nghệ, phương pháp và công cụ theo các quy trình nghiêm ngặt để làm ra sản phẩm cóchất lượng. Kỹ sư phần mềm (software engineer): là một người biết cách áp dụng rộng rãi những kiến thức về cách phát triển ứng dụng vào việc tổ chức phát triển một cách có hệ thống các ứng dụng. Công việc của người kỹ sư phần mềm là: đánh giá, lựa chọn, sử dụng những cách tiếp cận có tính hệ thống, chuyên biệt, rõ ràng trong việc phát triển, đưa vào ứng dụng, bảo trì, và thay thế phần mềm. Do đặc điểm nghề nghiệp, người kỹ sư phần mềm phải có những kỹ năng cơ bản như: . Định danh, đánh giá, cài đặt, lựa chọn một phương pháp luận thích hợp và các công cụ CASE. . Biết cách sử dụng các mẫu phần mềm (prototyping). . Biết cách lựa chọn ngôn ngữ, phần cứng, phần mềm. . Quản lý cấu hình, lập sơ đồ và kiểm soát việc phát triển của các tiến trình. . Lựa chọn ngôn ngữ máy tính và phát triển chương trình máy tính. . Đánh giá và quyết định khi nào loại bỏ và nâng cấp các ứng dụng. 9
10. Mục tiêu của kỹ sư phần mềm là sản xuất ra các sản phẩm có chất lượng cao và phù hợp với các quy trình phát triển chuẩn mực. Việc phát triển (development): được bắt đầu từ khi quyết định phát triển sản phẩm phần mềm và kết thúc khi sản phẩm phần mềm được chuyển giao cho người sử dụng. Việc sử dụng (operations): là việc xử lý, vận hành hằng ngày sản phẩm phần mềm. Việc bảo trì (maintenance): thực hiện những thay đổi mang tính logic đối với hệ thống và chương trình để chữa những lỗi cố định, cung cấp những thay đổi về công việc, hoặc làm cho phần mềm được hiệu quả hơn. Việc loại bỏ (retirement): thường là việc thay thế các ứng dụng hiện thời bởi các ứng dụng mới. 1.2. Nhân tố con ngƣời và phân loại nghề nghiệp 1.2.1. Nhân tố con ngƣời trong ngành công nghiệp phần mềm Đối với một sản phẩn phần mềm, một người không thể hoàn thành mà là kết quả lao động của một nhóm người-ta gọi là nhóm phát triển phần mềm. Mỗi thành viên trong nhóm không được vị kỷ, thành quả lao động của nhóm được xen như là thành quả chung và phải tuyệt đối trung thành với nhóm. Như vậy, một nhóm phát triển phần mềm như thế nào gọi là một nhóm hợp lý? Sau đây là một vài yếu tố cần xem xét: . Nhóm có bao nhiêu thành viên . Nhóm được tổ chức như thế nào . Tình hình thực tế của mỗi thành viên trong nhóm . Môi trường, điều kiện mà nhóm đang làm việc, Mỗi thành viên trong nhóm phải có một số kiến thức cần thiết tuỳ thuộc vào vai trò trong nhóm để phát triển phần mềm. 1.2.2. Phân loại nghề nghiệp Yêu cầu hiện nay của sự phát triển Công nghệ Thông tin (CNTT) ở Việt nam đòi hỏi cần có những người lao động trong tất cả các ngành kinh tế biết sử dụng hữu hiệu CNTT trong công việc của mình, và đồng thời cần có những người trực tiếp tham gia vào sản xuất, kinh doanh, vận hành về CNTT. Do vậy cần có những lớp người lao động sau: . Những người biết vận dụng sáng tạo CNTT vào nghiệp vụ chuyên môn. . Những người tham gia quản lí và vận hành các hệ thống CNTT . Những người tham gia trực tiếp vào việc phát triển và xây dựng ra các sản phẩm CNTT, 10
11. Việc phân loại nghề nghiệp trong các hệ thống thông tin có thể được phân chia dựa vào các tiêu chuẩn như: mức độ kinh nghiệm, loại hình công việc 1.2.2.1. Mức độ công việc . Sơ cấp Nhân viên cán bộ ở mức độ sơ đẳng nhất trực tiếp được giám sát chặt chẽ, nhưng họ sẽ được làm những công việc đúng chuyên môn và đây là cấp độ tối thiểu. Những cán bộ ở mức độ sơ đẳng có những kỹ năng, khả năng cơ bản để tìm ra những thông tin để mở rộng, thúc đẩy những thông tin đó. Thường thì phải mất khoảng hai năm để thực hiện các công việc đẳng cấp này. . Trung cấp Những cán bộ có trình độ trung cấp hầu hết làm việc độc lập, yêu cầu trực tiếp một số các hoạt động. Những người bắt đầu ở mức độ trung cấp có 2 đến 4 năm kinh nghiệm. Thời gian trung bình ở cấp độ này từ 2 – 5 năm. . Cao cấp Các cán bộ ở mức độ này có một trình độ nhất định về công việc và kinh nghiệm kỹ thuật đào tạo, huấn luyện người khác. Những nhân viên này giám sát người khác, phụ thuộc vào quy mô, sự phức tạp của các dự án, họ thường xuyên có điều kiện tiên quyết để lãnh đạo. Những cán bộ có từ 5 – 7 năm kinh nghiệm và có ít nhất là 3 năm để học các kỹ năng. Rất nhiều người đã kết thúc sự nghiệp học vấn của họ ở cấp độ này và lưu lại một vài năm nữa để hoàn thành dự án, trở thành chuyên gia cả về công nghệ và ứng dụng. . Lãnh đạo Những nhà lãnh đạo làm việc một mình. Họ kiêm tất cả các nhiệm vụ giám sát. Một người lãnh đạo thường được gọi là những chuyên gia phụ trách các dự án. Những chuyên gia này có kinh nghiệm, kỹ năng cả ở trình độ đại học và có mong muốn được quản lý các vị trí. . Chuyên gia kỹ thuật Chuyên gia kỹ thuật là người có kinh nghiệm rộng rãi trong nhiều lĩnh vực. Kinh nghiệm của một chuyên gia bao gồm phát triển ứng dụng, mạng, cơ sở dữ liệu và hệ điều hành. Các chuyên gia cũng có trình độ quản lý, có bổn phận và năng lực giống nhau mà không phải chịu trách nhiệm quản lý một dự án. Các chuyên gia có thể làm việc trong các vị trí của hệ thống thông tin trong khoảng 10 năm hoặc có thể lâu hơn và cũng có thể duy trì lâu dài ở cấp độ này. . Nhà quản lý Công việc quản lý một cách độc lập, thể hiện giá trị của riêng từng cá nhân, mục tiêu tiến hành bản báo cáo, tường trình và quản lý dự án. Các nhà quản lý có thể hoặc không thể trở thành chuyên gia kỹ thuật theo định hướng nhưng họ có kinh nghiệm làm việc và hầu hết họ đều có trách nhiệm trong cách quản lý. Đối với các nhà 11
12. quản lý kỹ thuật việc phân chia các đặc điểm công việc là các kế hoạch mục tiêu, giám sát, quản lý cá nhân, các hoạt động liên lạc trong hoạt động quản lý dự án. Sơ đồ về mối liên hệ sau được thể hiện như sau: Mối liên hệ của con đường nghề nghiệp cho các mức khác nhau. 1.2.2.2. Loại hình công việc Ở đây, các loại hình công việc được bàn luận đến dựa vào cách phân loại gồm: phát triển ứng dụng, hỗ trợ ứng dụng, chuyên ngành kỹ thuật, nhân viên và những vấn đề khác. . Phát triển ứng dụng Lập trình viên: Các lập trình viên chuyển đổi những đồ án chi tiết kỹ thuật sang các module mã và tự kiểm tra các đơn vị. Các lập trình viên có thể luân phiên chịu trách nhiệm giữa phát triển ứng dụng và bảo trì. Những chuyên gia lập trình ở trình độ đại học thực hiện những nhiệm vụ bên ngoài việc lập trình. Kỹ sư phần mềm: Một kỹ sư phần mềm thực hiện những chức năng của các nhà phân tích, các nhà thiết kế và các lập trình viên. Các phân tích gia ở trình độ đại học luôn luôn tham gia vào tổ chức có cấp độ IS để lập kế hoạch và nghiên cứu khả thi. Các kỹ sư phần mềm có thể làm cả ba việc – phân tích, thiết kế và lập trình cũng như đứng ra lãnh đạo dự án hoặc quản lý dự án. Một kỹ sư quản lý phần mềm sơ cấp thường dành nhiều thời gian lập trình trong khi một kỹ sư có trình độ cao cấp lại tập trung vào việc lập kế hoạch, nghiên cứu khả thi, phân tích và thiết kế. Kỹ sư tri thức (KE): Các kỹ sư tri thức suy luận ra những mô hình ngữ nghĩa từ các chuyên gia để từ đó xây dựng những hệ chuyên gia và trí tuệ nhân tạo. Các kỹ sư tri thức tương tự như các kỹ sư phần mềm nhưng được chuyên môn hoá các kỹ năng để áp dụng vào các vấn đề trí tuệ nhân tạo. Việc phát triển các mô hình và các chương trình của cấu trúc trí tuệ đòi hỏi khả năng quan sát, kỹ năng phỏng vấn sâu sắc, khả 12
13. năng trừu tượng hoá những vấn đề không phải của chuyên môn cá nhân để tạo ra những ý thức lập luận và thông tin cần thiết và khả năng phát triển những dự đoán về thông tin và tính chính xác với các chuyên gia. . Hỗ trợ ứng dụng Chuyên gia ứng dụng: Chuyên gia ứng dụng có những vùng vấn đề được chuyên môn hoá cho phép họ tham khảo ý kiến của các đội dự án về một loại ứng dụng cụ thể. Ví dụ một nhà phân tích cao cấp về chuyển tiền thời gian thực có thể phân chia được thời gian giữa các dự án chuyển tiền trong nước và quốc tế, biết trước được những quy tắc, luật lệ phải tuân theo của ngân hàng dự trữ liên bang cũng như của các tổ chức chuyển tiền khác. Quản trị dữ liệu: Người quản lý dữ liệu quản lý thông tin như một nguồn thống nhất. Với chức năng này, bộ phận quản lý dữ liệu giúp cho người sử dụng xác định được tất cả dữ liệu được sử dụng, các dữ liệu có ý nghĩa trong quá trình thực hiện chức năng của công ty. Những người quản lý dữ liệu thiết lập và bảo lưu những chuẩn mực để thống nhất dữ liệu. Khi dữ liệu đã được xác định, người quản lý dữ liệu sẽ làm việc để định dạng và xác định cấu trúc cơ sở dữ liệu để sử dụng với ứng dụng. Với việc phát triển ứng dụng mới, những người quản lý dữ liệu làm việc với bộ phận phát triển ứng dụng để định vị những số liệu đã được tự động và với bộ phận quản trị CSDL để cung cấp những nhóm ứng dụng dễ dàng truy nhập những cơ sở dữ liệu đã được tự động hoá. Quản trị cơ sở dữ liệu (DBA): Những người quản lý cơ sở dữ liệu quản lý môi trường dữ liệu vật lý của một tổ chức. DBA phân tích, thiết kế, xây dựng và bảo lưu cơ sở dữ liệu cũng như môi trường phần mềm cơ sở dữ liệu. Làm việc cùng với những người quản lý dữ liệu xác định dữ liệu. DBA xác định các cơ sở dữ liệu vật lý và nạp thông tin thực tế vào chúng. Một người quản lý cơ sở dữ liệu làm việc với các nhóm phát triển ứng dụng để cung cấp truy nhập đến dữ liệu tự động và để định nghĩa rõ ràng cơ sở dữ liệu cần thiết cho thông tin được tự động. Kỹ sư trí tuệ nhân tạo: Các kỹ sư trí tuệ nhân tạo làm việc như cố vấn giúp các đội dự án xác định, thiết kế và cài đặt trí tuệ vào các ứng dụng. Kỹ sư trí tuệ nhân tạo cùng với các kỹ sư tri thức dịch và kiểm tra những vấn đề miền dữ liệu và thông tin lập luận bằng một ngôn ngữ của trí tuệ nhân tạo. Các kỹ sư trí tuệ nhân tạo đạt được trình độ chuyên môn cao hơn các kỹ sư tri thức. Nhà tư vấn: Người tư vấn thì biết mọi vấn đề và thực hành được tất cả. Số năm kinh nghiệm càng cao thì kiến thức có được càng nhiều. Lĩnh vực chuyên môn có thể bao gồm một vài loại công việc được đề cập đến trong phần này. Người tư vấn được nhờ đến trong hầu hết các trường hợp lắp đặt hệ thống và cung cấp những kỹ năng bên ngoài không sẵn có. Bởi vậy họ thường đào tạo đội ngũ bên trong trong suốt quá trình thực hiện công việc. Khi được nhờ đến, người tư vấn được mong chờ có những kỹ năng chuyên biệt và sẽ áp dụng những kỹ năng này trong việc thực hiện tư vấn. 13
14. . Chuyên ngành kỹ thuật Nhà phân tích và kỹ sư truyền thông: Các nhà phân tích và kỹ sư truyền thông phân tích, thiết kế, đàm phán và/ hoặc cài đặt các thiết bị và phần mềm truyền thông. Họ đòi hỏi liên quan chặt chẽ tới kỹ thuật truyền thông và có thể làm việc trên mainframe hoặc các mạng truyền thông dựa vào PC. Để bắt đầu ở mức xuất phát thì nền tảng kiến thức phải có là điện tử, kỹ thuật, các ứng dụng, khoa học máy tính và truyền thông. Chuyên gia về mạng cục bộ: Các chuyên gia mạng cục bộ đặt kế hoạch, lắp đặt, quản lý và duy trì những khả năng của mạng cục bộ. Điểm khác nhau duy nhất giữa các chuyên gia mạng cục bộ và các chuyên gia truyền thông là phạm vi. Các chuyên gia truyền thông làm việc với nhiều mạng kể cả mainframe; còn chuyên gia mạng cục bộ chỉ làm việc trên những mạng có giới hạn về mặt địa lý và được cấu thành bởi nhiều máy tính cá nhân. Những người quản lý mạng cục bộ là vị trí đầu tiên trong nhiều công ty. Một người quản lý mạng cục bộ tạo ra người sử dụng mới, thực hiện hoặc thay đổi mức hoặc mã bảo mật, cài đặt những version mới của phần mềm điều hành mạng cục bộ, cài đặt những version mới của cơ sở dữ liệu hoặc phần mềm cơ sở mạng cục bộ khác. Giám sát tài nguyên cung cấp qua mạng cục bộ, cung cấp bản sao và khả năng phục hồi cho mạng cục bộ, và quản lý cấu hình mạng cục bộ. Lập trình viên hệ thống: Các lập trình viên hệ thống cài đặt và bảo dưỡng hệ điều hành và ứng dụng hỗ trợ phần mềm. Định giá những đặc điểm mới và xem xét chúng có cần thiết ở một thời điểm nào đó không là một kỹ năng mà lập trình viên hệ thống cần phát triển. Giám sát hàng trăm ứng dụng để xem xét những rắc rối của nó có liên quan đến vấn đề của hệ thống hay không là một nhiệm vụ quan trọng. Chuyên gia hỗ trợ phần mềm (SSP): Hỗ trợ phần mềm ứng dụng tương tự nhưng khác với lập trình viên hệ thống. SSP cài đặt và bảo dưỡng gói phần mềm sử dụng bởi cả các nhà phát triển ứng dụng và người sử dụng. Chúng có thể là cơ sở dữ liệu, ngôn ngữ hỏi đáp, sao lưu và phục hồi, bảng tính, quản lý khoảng trống đĩa, giao diện, truyền thông. . Nhân viên Chuyên gia về bảo mật: Một chuyên gia bảo mật chịu trách nhiệm bảo mật và sẵn sàng phục hồi thảm hoạ. Để bảo mật, một chuyên gia phải thiết lập các chuẩn cho bảo mật dữ liệu, giúp đỡ các đội dự án trong việc quyết định các yêu cầu bảo mật và thiết lập các chuẩn cho trung tâm bảo mật dữ liệu. Tương tự để phục hồi thảm hoạ, chuyên gia bảo mật giúp đỡ những người quản lý và các đội dự án trong việc xác định các dữ liệu nguy cấp cần thiết cho tổ chức. Sau đó chuyên gia giúp trung tâm dữ liệu và các đội dự án trong việc phát triển và thử nghiệm các kế hoạch phục hồi thảm hoạ. Nghiên cứu của IBM và các tổ chức khác cho thấy các công ty không có bất kỳ kế hoạch sao lưu và phục hồi sẽ bị phá sản khi xẩy ra thảm hoạ. Nghiên cứu được tiến hành ở nhiều vùng địa lý khác nhau, với nhiều loại thảm hoạ khác nhau và trong nhiều năm. 14
15. Kiểm soát viên (EDP): Các kiểm soát viên EDP thực hiện việc kiểm tra khả năng tin cậy của những thiết kế ứng dụng. Bất kỳ ứng dụng nào duy trì những quy định hợp pháp, trách nhiệm hoặc dùng bản hướng dẫn của công ty cũng có thể bị tạo lại bất kỳ giao dịch nào và phát hiện ra tiến trình của nó. Các kiểm soát viên EDP đảm bảo rằng những mất mát của công ty là nhỏ nhất qua việc thiết kế những ứng dụng tốt. Những khía cạnh thiết kế được các kiểm soát viên đánh giá là rãnh kiểm soát, khả năng phục hồi và bảo mật. Đào tạo: Một người đào tạo kỹ thuật học công nghệ mới, các sản phẩm đại lý, những đặc điểm ngôn ngữ mới, sau đó dạy những người khác trong tổ chức sử dụng. Đào tạo có thể thực hiện trong nội bộ tổ chức những cũng có thể do một công ty đào tạo có chuyên môn đảm nhận. Người viết các chuẩn và kỹ thuật: Những người phát triển chuẩn làm việc với những người quản lý để định ra những mặt công việc họ muốn chuẩn hoá và để tiêu chuẩn hoá những yêu cầu thành những chính sách và thủ tục chuẩn hoá cho tổ chức. Những kỹ năng quan trọng nhất đối với người phát triển chuẩn là ngôn ngữ và chữ viết truyền thông. Phát triển tiêu chuẩn và việc viết kỹ thuật là các hoạt động có liên quan với nhau. Người viết kỹ thuật lấy thông tin và sản phẩm phần mềm, ứng dụng hoặc những sản phẩm công nghệ thông tin khác và viết tài liệu để mô tả những đặc điểm, chức năng, công dụng của chúng. Người viết kỹ thuật phải có kỹ năng giao tiếp tốt trong cả lĩnh vực kỹ thuật và phi kỹ thuật. Người viết dùng các kỹ năng giao tiếp kỹ thuật để nói và phát triển sự hiểu biết về sản phẩm được giới thiệu. Đảm bảo chất lượng (QA): Các dạng kiểm tra khác nhau tuỳ thuộc vào sản phẩm được duyệt. Một phân tích đảm bảo chất lượng thường được thực hiện với một kế hoạch phát triển khi nó bắt đầu. Anh ta hay cô ta cần phải tham gia đến khi sản phẩm đầu tiên của nhóm phát triển xuất hiện. Sau đó khi mà tài liệu đã có, người phân tích đảm bảo chất lượng phải xem xét sự thống nhất, hoàn thiện, chính xác uyển chuyển linh động của nó. Bất cứ vấn đề nào xuất hiện trong quá trình xem xét phải được ghi lại để trình lên người quản lý dự án. Những người phân tích đảm bảo chất lượng phải có kỹ năng giao tiếp, kỹ năng giải quyết vấn đề để thực hiện công việc kiểm tra chất lượng. Họ cần phải có kinh nghiệm trong tất cả các khía cạnh phát triển của dự án để biết nên làm cái gì và vấn đề nảy sinh từ đâu. Đồng thời sự nhạy cảm và khả năng phát hiện ra những vấn đề cần phê bình cũng rất quan trọng. Không ai muốn bị nói trước công chúng là mình có lỗi mặc dù về mặt lý trí họ đều biết rằng công việc dự án sẽ có lợi từ những phê bình đó. Nhân viên đảm bảo chất lượng cần phải nhạy cảm với cả những chính sách và vấn đề được phát hiện. Lập kế hoạch công nghệ: Các chuyên gia giám sát sự phát triển công nghệ xác định các xu hướng, lựa chọn các công nghệ thích hợp để thử nghiệm trong tổ chức và cuối cùng chạy đua trong thực hiện các kỹ thuật mới trong tổ chức. Những nhân viên cao cấp là cầu nối giữa thế giới bên ngoài và cộng đồng các đại lý với công ty. Đội ngũ 15
16. nhân viên sơ cấp có thể làm việc với nhân viên cao cấp để tìm ra những chỉ dẫn trong hợp tác và quản lý công nghệ. . Những vấn đề khác Hỗ trợ sản phẩm: Nhân viên hỗ trợ sản phẩm làm việc cho nhóm người dùng cuối hoặc bán hàng để cung cấp những chuyên môn kỹ thuật liên quan đến sản phẩm hoặc những hỗ trợ trên đường dây nóng khác. Ngoài những kiến thức kỹ thuật về sản phẩm, các cá nhân trong công việc này còn phải có kỹ năng trả lời điện thoại tốt và phải nói bằng ngôn ngữ không chuyên đối với người sử dụng về các vấn đề. Tiếp thị sản phẩm: Nhân viên hỗ trợ tiếp thị làm việc cho nhà bán hàng để cung cấp những thông tin kỹ thuật cho đại diện bán hàng trong các tình huống tiếp thị. Loại công việc này đòi hỏi khả năng giao tiếp và kỹ năng giao tiếp tốt với một vài kiến thức về tiếp thị, chẳng hạn như thu hẹp phạm vi giao tiếp, đề cập đến các kỹ thuật để giới thiệu một cách hiệu quả với người đại diện bán hàng. Tất cả các công ty tư vấn và phần cứng, phần mềm đều có người để làm những công việc này. Thông thường nó được các nhân viên cao cấp thực hiện nhưng nếu bạn có trình độ chuyên môn ở những lĩnh vực cần thiết thì bạn cũng có thể làm được mà không cần là nhân viên cao cấp. Chuyên gia người sử dụng cuối: Chuyên gia người dùng cuối là người chuyển những yêu cầu sử dụng thành những ngôn ngữ kỹ thuật cho nhóm phát triển sử dụng. Trong một vài tổ chức, đây là chức năng của người phân tích hệ thống hoặc là kỹ sư phần mềm. Ở các công ty khác, có những môi giới giữa người sử dụng cuối với bộ phận sử dụng để thực hiện chức năng này. Tóm lại mọi công ty đều phải có sự kết hợp của những đặc điểm công việc khác nhau ở tất cả các bộ phận. 1.3. Sản phẩm phần mềm – đặc tính và phần loại Xây dựng phần mềm là một hoạt động chính của công nghệ phần mềm.Một phần mềm gồm một hay nhiều ứng dụng (application) - là một tập hợp các chương trình thực hiện tự động hóa một số các nhiệm vụ nghiệp vụ. Nghiệp vụ (Business) bao gồm tập hợp các chức năng như: tìm hiểu thị trường, kiểm toán, sản xuất và quản lý nhân sự Mỗi chức năng có thể được chia nhỏ ra thành những tiến trình thực hiện nó. Ví dụ: tìm hiểu thị trường là sự tìm hiểu về bán hàng, quảng cáo, và đưa ra các sản phẩm mới. Mỗi tiến trình lại có thể được phân chia theo những nhiệm vụ đặc thù của chúng. Ví dụ: việc bán hàng phải duy trì được mối quan hệ với khách hàng, làm việc theo trình tự và các phục vụ dành cho khách hàng. Các ứng dụng có thể hỗ trợ cho từng nhiệm vụ một cách đơn lẻ. Trái lại một ứng dụng tìm hiểu thị trường có các đặc điểm riêng, có các chức năng riêng, ngoài ra nó còn cung cấp một số thông tin chung nhằm hoàn thiện tất cả các nhiệm vụ. Mọi ứng dụng đều có một số đặc điểm chung (tương đồng) và một số đặc điểm riêng. Các đặc điểm chung của ứng dụng thường được đề cập là: đặc tính (characteristics) , tính đáp ứng (responsiveness) và loại (type) của ứng dụng. 16
17. 1.3.1. Các đặc tính phần mềm Các đặc tính phần mềm là tất cả các điểm chung cho mọi ứng dụng: dữ liệu, các tiến trình, các ràng buộc, và các giao diện. 1.3.1.1. Dữ liệu Đầu vào: Dữ liệu vào là dữ liệu ở bên ngoài máy tính, và chúng được đưa vào bằng cách sử dụng một thiết bị đầu vào. Thiết bị đầu vào được sử dụng để đưa dữ liệu vào máy tính có thể là: bàn phím, máy quét, hoặc được truyền từ một máy tính khác. Đầu ra: Dữ liệu ra ngược lại so với dữ liệu vào ở chỗ, đầu ra là các dữ liệu được đưa ra ngoài máy tính. Một số các thiết bị đầu ra như máy in, màn hình hiển thị, một máy tính khác Sự lưu trữ dữ liệu và sự tìm kiếm dữ liệu: Dữ liệu được mô tả ở dạng vật lý, trong một máy có thể đọc được các khuôn dạng dữ liệu. Việc tìm kiếm dữ liệu được hiểu là bạn có thể truy nhập vào dữ liệu ở dạng lưu trữ của nó. Việc lưu trữ và tìm kiếm luôn đi cùng với nhau (cả ở mức quan niệm lẫn trong các chương trình phần mềm). Việc lưu trữ dữ liệu đòi hỏi hai kiểu định nghĩa dữ liệu là kiểu vật lý và kiểu logic. 1.3.1.2. Xử lý Xử lý bao gồm một chuỗi các lệnh hoặc các sự kiện có liên quan với nhau làm việc với các dữ liệu. Kết quả của một xử lý có thể là: làm thay đổi cơ sở dữ liệu, đưa dữ liệu trả lời ra thiết bị đầu cuối, máy in hoặc in ra giấy, có thể là những yêu cầu về các trang thiết bị, sản sinh những chương trình, hoặc lưu trữ những luật, những thông tin mới, được suy diễn ra về các tình huống, các phần tử. 1.3.1.3. Ràng buộc Ràng buộc bao gồm: ràng buộc thứ tự trước, ràng buộc thứ tự sau, ràng buộc thời gian, ràng buộc cấu trúc, ràng buộc điều khiển và cả ràng buộc về tham chiếu. . Ràng buộc về thứ tự trước (Prerequisite Constraint): Bắt buộc về thứ tự trước là điều kiện đầu tiên phải được đáp ứng để có thể bắt đầu quá trình xử lý. . Ràng buộc về thứ tự sau (Postrequisite Constraint): Ràng buộc loại này là điều kiện cần phải thỏa mãn để quá trình xử lý có thể hoàn thành được. Cụm câu lệnh này được đưa vào cuối quá trình xử lý. . Ràng buộc về thời gian (Time Constraint): Bao gồm ràng buộc về thời gian xử lý, thời gian phân chia cho một quá trình xử lý, thời gian yêu cầu đối với các quá trình xử lý bên ngoài, thời gian xử lý đồng bộ, thời gian trả lời cho quá trình xử lý với giao diện ngoài. . Ràng buộc về mặt cấu trúc: Có thể hiểu là bao gồm việc xác định loại đầu vào và đầu ra của dữ liệu nào được cho phép, quá trình xử lý được thực hiện như thế nào và mối quan hệ giữa các quá trình với nhau. 17
18. . Ràng buộc về điều khiển: Liên quan đến việc duy trì mối quan hệ về dữ liệu. . Ràng buộc về suy diễn: Đó là những khả năng có thể xảy ra từ một ứng dụng, dựa vào các kết quả trước đó, hoặc có thể dựa vào các quan hệ về dữ liệu, ta có thể dẫn đến một kết quả khác. 1.3.1.4. Giao diện Quan trọng nhất là giao diện người sử dụng - là phương tiện giao tiếp giữa người sử dụng và chương trình. Sau đó là giao diện thủ công - là các mẫu báo cáo và một số giao diện đã được chuẩn hóa như giao diện về mạng LAN của Institue of Electrical and Electronic Engineers, chuẩn OSI (Open System Interface) của International Standards Organization 1.3.1.5. Tính đáp ứng Tính đáp ứng của ứng dụng là thời gian sử dụng và đáp ứng yêu cầu từ người dùng của ứng dụng. Nó được định nghĩa bởi sự định hướng thời gian mà ứng dụng xử lý như: xử lý theo lô, xử lý theo kiểu trực tuyến hay xử lý theo thời gian thực. . Xử lý theo lô Ứng dụng xử lý theo lô là ứng dụng mà các phiên giao dịch (transactions) được gom lại theo thời gian và thực hiện theo nhóm. Tại mỗi thời điểm xác định, công việc được xếp thành lô và đưa vào xử lý. . Xử lý theo kiểu trực tuyến Ứng dụng trực tuyến được định vị trực tiếp trong bộ nhớ và được sử dụng một cách tuần tự bởi các phiên giao dịch hoặc sự kiện mà không cần phải nạp lại ứng dụng vào bộ nhớ. . Xử lý theo thời gian thực Ứng dụng thời gian thực xử lý phiên giao dịch và sự kiện dựa trên thời gian thực tế mà quá trình xử lý xảy ra. Sau đó, kết quả ở trạng thái sẵn sàng để phục vụ hoặc điều khiển một tiến trình vật lý nào đó. Những thay đổi thu được từ một quá trình xử lý thời gian thực có thể được khôi phục lại trạng thái ban đầu. Để ý rằng các chương trình xử lý theo thời gian thực có thể xử lý nhiều giao dịch một cách tương tranh - trong quá trình xử lý song song tương tranh là tất cả giao dịch cùng hoạt động tại một thời điểm còn trong xử lý tuần tự thì tương tranh được hiểu là tất cả các giao dịch đều ở cùng tiến trình nhưng chỉ có một giao dịch được thực hiện tại một thời điểm. 1.3.2. Phân loại phần mềm Phân loại phần mềm được định nghĩa như sự định hướng các công việc của một ứng dụng, ví dụ như theo kiểu hướng giao dịch, hỏi đáp, trợ giúp quyết định, 1.3.2.1. Ứng dụng hƣớng giao dịch Ứng dụng hướng giao dịch còn có tên là hệ thống xử lý giao dịch (TPS – Transaction Processing Systems) được sử dụng nhằm hỗ trợ các hoạt động hằng ngày 18
19. của một công việc, bao gồm: xử lý đơn hàng, quản lý kiểm kê, ghi quỹ, Chúng được đặc trưng như là các ứng dụng mà trong đó các yêu cầu, các dữ liệu và quá trình xử lý được biết rõ và có cấu trúc tốt. Theo nghĩa được biết rõ, chức năng đó phải có tính lập lại, thân thiện và rõ ràng. Theo nghĩa cấu trúc tốt, vấn đề đó phải có thể được xác định một cách đầy đủ và rõ ràng. Các yêu cầu có thể được định danh bởi đội ngũ xây dựng phần mềm. 1.3.2.2. Ứng dụng cơ sơ dữ liệu Ứng dụng cơ sở dữ liệu được sử dụng như một ứng dụng xử lý câu hỏi về dữ liệu. Ngôn ngữ truy vấn dữ liệu chuẩn SQL cho phép người sử dụng đặt câu hỏi dưới dạng: họ biết họ cần gì nhưng không biết làm cách nào để lấy được dữ liệu đó. Các phần mềm máy tính đưa ra các phương pháp xử lý và truy cập tối ưu để thực hiện các thao tác đó. Ở đây, có ba loại câu hỏi chính: . Tương tác: dữ liệu sử dụng xong là không cần nữa? . Dữ liệu được lưu trữ để sử dụng lại và thay đổi trong tương lai? . Dữ liệu được lưu trữ để sử dụng thường xuyên trong một số quá trình lập lại? Ứng dụng truy vấn hỗ trợ một khái niệm là kho chứa dữ liệu (data warehouse). Đó là một sơ đồ lưu trữ xây dựng trên quan điểm: hầu hết dữ liệu cần phải giữ lại cho các truy nhập truy vấn trực tuyến. Tại đây lưu lại các phiên bản cũ của phần lớn các phần tử trong cơ sở dữ liệu, các lần vào ra giao dịch và các bản ghi liên quan đến một số quá trình hoạt động. 1.3.2.3. Ứng dụng hỗ trợ quyết định (Decision Supports System - DSS) DSS làm nhiệm vụ xác định và giải quyết bài toán. Khác với một ứng dụng truy vấn mà những người chuyên nghiệp và các nhà quản lý sử dụng để tìm kiếm và tổng hợp các dữ liệu về một quá trình hoạt động (như ở ví dụ trên), với ứng dụng hỗ trợ quyết định, họ phân tích, xác định các xu hướng, thực hiện các phân tích dữ liệu về mặt thống kê hay toán học từ đó giải các bài toán không cấu trúc. Dữ liệu dùng cho DSS thường lấy từ các ứng dụng sử dụng giao dịch. Vì thông tin thường không đầy đủ, trong DSS thường giải bài toán bằng phương pháp lặp, áp dụng mô hình toán học hoặc thống kê để đi tới quyết định. Dữ liệu hỗ trợ và/hoặc hiệu chỉnh thường được đưa trở lại quá trình mô hình hoá để làm mịn các phân tích. Ta thường gặp một số hệ thống được xem là một sản phẩm phụ của DSS như: . Hệ thống thông tin thi hành (Excutive Information System - EIS) là một sản phẩm phụ của DSS. EIS hỗ trợ quyết định thực hiện và cung cấp khả năng tìm kiếm trong các môi trường một cách tự động. Các hệ thi hành hàng đầu phải xử lý được các vấn đề với thông tin không đầy đủ, không chính xác, không rõ 19
20. ràng và có liên quan đến tương lai. EIS tích hợp thông tin từ cơ sở dữ liệu bên ngoài với ứng dụng nội bộ . Để tạo ra khả năng mô hình hoá và tìm kiếm thông tin tự động. Sự khác nhau cơ bản của EIS với DSS là ở đây dữ liệu không hoàn chỉnh, không rõ ràng và thậm chí không chính xác. . Hệ thống hỗ trợ quyết định theo nhóm (Group DSS - GDSS) là một dạng đặc biệt của ứng dụng DSS. GDSS có một nhật ký ghi lại quá trình xây dựng một quyết định để hỗ trợ một nhóm những người có trách nhiệm ra quyết định (decision maker). GDSS tập trung chủ yếu vào các quá trình tương tác có ít hoặc không có phân tích thống kê hoặc mô hình hoá dữ liệu trong nhóm. Các phần mềm cơ sở dữ liệu trong GDSS có xu hướng ít được xây dựng hơn đối với DSS, nhưng có thể bao gồm một số bảng tính và các thủ tục biểu diễn tổng kết về các bên tham gia dưới dạng số hoặc đồ thị. Các chức năng điển hình của GDSS là: - Ghi lại các ý kiến vô danh. - Tuyển cử dân chủ bầu các nhà lãnh đạo. - Thảo luận và bầu cử để đạt được một sự thoả thuận nào đó trong nhóm. 1.3.2.4. Hệ chuyên gia (Expert Systems - ES) Các ứng dụng hệ chuyên gia là các ứng dụng tin học tự động hoá tri thức và khả năng lập luận của một hoặc nhiều chuyên gia trong một lĩnh vực cụ thể nào đó. ES phân tích các đặc trưng của một tình huống để đưa ra một lời khuyên, một khuyến nghị hoặc phác hoạ một kết luận bằng các quá trình lập luận tự động. Một hệ ES bao gồm bốn thành phần chính: hệ thống thu thập tri thức, cơ sở tri thức, mô tơ suy diễn (còn gọi là cơ sở luật) và hệ thống diễn giải. . Hệ thống thu thập tri thức là phương tiện xây dựng cơ sở tri thức. Nói chung, càng nhiều tri thức thì hệ thống càng “thông minh” hơn. Hệ thống thu thập tri thức phải cung cấp các sự kiện khởi đầu, các quy tắc mẹo mực (heuristic rules of thumb) và có thể dễ dàng bổ sung tri thức mới. . Thông thường, chúng ta lập luận mà không biết làm cách nào để đi tới phương án. Từ phân tích quá trình con người suy nghĩ khi phân tích một vấn đề có thể áp dụng để xây dựng một ứng dụng. Tại sao ta lại làm việc đó? Đó là cả một quá trình suy diễn nội tâm và rất khó diễn giải. Khó khăn này không của riêng ai. Suy luận thông tin từ tri thức của các chuyên gia là khó khăn cơ bản để xây dựng một hệ chuyên gia có hiệu quả. . Cơ sở tri thức là một phiên bản tự động hệ thống hoá tri thức chuyên gia cộng với các mẹo áp dụng tri thức đó. Thiết kế cơ sở tri thức cũng khó như suy luận thông tin vì dù nó được thiết kế như thế nào thì cũng bị giới hạn bởi hệ thống cài đặt nó. Vì vậy, một ngôn ngữ đặt biệt cho ES đã được thiết kế, nó cho 20
21. phép xác định mối quan hệ giữa các mẩu thông tin và sử dụng một cách mềm dẻo các thông tin đó trong lập luận. . Vì mục đích của lập luận là tìm một giải pháp khả dĩ nhất cho một tình huống, ES sử dụng lập luận và suy diễn để xây dựng nhiều giải pháp có thể cho một tình huống cho trước. Một vài giải pháp có thể được đưa ra khi thông tin không hoàn chỉnh hoặc khi mới lập luận một phần. Xác suất chính xác của giải pháp do hệ thống đưa ra thường được đo bằng mức độ hữu ích của giải pháp đó. Các vấn đề liên quan đến quy tắc hoặc đạo đức thường được xét đến trong các ES hơn so với trong các ứng dụng khác. . Thành phần quan trọng cuối cùng của một ES là khả năng diễn giải các lập luận cho người sử dụng. Tìm lại quá trình suy diễn là điều rất quan trọng giúp người sử dụng có được kinh nghiệm sử dụng hệ thống và xác định mức độ tin cậy vào kết quả do ES đưa ra. 1.3.2.5. Các hệ thống nhúng (Embedded systems) Đây là các ứng dụng vốn là một phần của hệ thống lớn hơn. Thường, bản thân ứng dụng thì rất đơn giản nhưng sự phức tạp của chúng là ở giao diện để tạo ra một độ chính xác hoàn hảo, tính theo thời gian thực (real - time) trong phạm vi đời sống của hệ thống lớn hơn. Việc phát triển các ứng dụng kết hợp này là địa phận của các nhà thiết kế theo học ngành khoa học máy tính hơn là những nhà thiết kế hệ thống thông tin. 1.4. Một số mô hình xây dựng phần mềm 1.4.1. Mô hình tuyến tính (The linear sequential model) Đôi lúc còn được gọi là mô hình kinh điển (classic model) hay mô hình thác nước (waterfall model). Mô hình này xem quá trình xây dựng một sản phẩm phần mềm bao gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thì chuyển đến giai đoạn sau. Có hai hoạt động phổ biến được thực hiện trong mỗi giai đoạn là: kiểm tra - phê chuẩn và quản lý cấu hình. Tổng kết mỗi giai đoạn là sự kiểm tra, phê chuẩn và quản lý cấu hình đây chính là mục tiêu của sản phẩm. Việc kiểm tra đưa ra khuôn mẫu đúng đắn tương ứng giữa sản phẩm phần mềm và các đặc tính của nó. Sự phê chuẩn đưa ra chuẩn mực về sự phù hợp hay chất lượng của sản phẩm phần mềm đối với mục đích của quá trình hoạt động. Tuy vậy, thường thì các dự án có hàng ngàn trang tài liệu mà không ai ngoại trừ tác giả đọc đến nó. Thông tin ứng dụng chỉ nằm trong đầu mọi người và việc trao đổi thông tin là một trở ngại lớn để có được thành công của hệ thống. Kết luận là văn bản không phải là một phương tiện tốt để mô tả các yêu cầu phức tạp của ứng dụng. Thêm vào đó, mô hình bộc lộ một số nhược điểm quan trọng như: . Mối qua hệ giữa các giai đoạn không được thể hiện 21
22. . Hệ thống phải được kết thúc ở từng giai đoạn do vậy rất khó thực hiện được đầy đủ những yêu cầu của khách hàng Mô hình này được tóm tắt như sau: Phân tích yêu cầu ` Thiết kế Cài đặt và thử nghiệm đơn lẻ Thử nghiệm tổng thể Bảo trì và phát triển 1.4.2. Mô hình mẫu (Prototyping model) Thông thường, khách hàng sẽ đưa ra mục tiêu của họ một cách chung chung mà họ không biết hoặc không đưa ra một cách cụ thể những cái vào, cái ra và các tiến trình xử lý chúng. Thêm vào đó, chúng ta cũng không thể không quan tâm đến thuật toán sử dụng, tính tương thích của sản phẩm phần mềm với môi trường của nó như: phần cứng, hệ điều hành Trong trường hợp này, mô hình mẫu có thể là sự lựa chọn tốt hơn cho người lập trình. Những điểm chính của mô hình mẫu được tóm tắt theo sơ đồ sau: Mô hình mẫu là một cách để phá vỡ sự khắt khe, cứng nhắc trong chu trình tuần tự của dự án. Tuy vậy, trong mô hình mẫu, sử dụng sai làm hỏng phân tích và thiết kế, không bao giờ hoàn thiện được mẫu thành các ứng dụng thực sự là các vấn đề cần 22
23. quan tâm. Thêm vào đó là hệ thống có thể không bao giờ được chuẩn hóa, chi tiết của việc xử lý, việc kiểm tra tính hợp lệ của dữ liệu và các đòi hỏi kiểm toán có thể bị bỏ quên trong việc đưa mẫu vào sản xuất. Trong tương lai, tạo mẫu thích hợp với đánh giá thiết kế, cải tiến cách dùng phần cứng và phần mềm mới. Tạo mẫu thường đi đôi với các ngôn ngữ lập trình bậc cao và ngày càng có nhiều công cụ đặt mẫu sẽ được tích hợp với CASE. 1.4.3. Mô hình xoắn ốc (The spiral model) Mô hình này được Boehm đưa ra nên đôi lúc còn được gọi là mô hình Boehm's (The Boehm's spiral model). Nó có thể xem là sự kết hợp giữa mô hình thác nước và mô hình mẫu và đồng thời thêm một thành phần mới - phân tích rủi ro. Bao gồm bốn hoạt động chính: . Planning: Xác định mục tiêu, tương tác và ràng buộc. . Risk analysis: Phân tích các lựa chọn và các chỉ định/giải quyết rủi ro. . Engineering : Phát triển sản phẩm . Customer evaluation: Đánh giá kết quả xây dựng. Mô hình được tóm tắt như sau: Mô hình soắn ốc Trong vòng đầu tiên của xoáy ốc, mục đích, lựa chọn, các ràng buộc được định nghĩa và các nguy cơ được xác định và phân tích. Nếu phân tích các lỗi chỉ ra rằng có một vài yêu cầu không chắc chắn, tạo mẫu có thể dược tiến hành để giúp đỡ nhà phát triển và khách hàng. Mô phỏng và các mô hình khác có thể được sử dụng để xác định vấn đề và làm mịn các yêu cầu. 23
24. Khách hàng đánh giá công việc và đưa ra các gợi ý. Trên cơ sở ý kiến đó, phần tiếp theo của lập kế hoạch và phân tích lỗi xuất hiện. Mô hình xoáy ốc hiện nay là mô hình hướng tiếp cận hiện thực nhất để phát triển các hệ thống lớn. Nó sử dụng mô hình mẫu như là cơ chế loại trừ lỗi, cho phép nhà phát triển áp dụng mô hình mẫu tại mỗi chu trình phát triển. Nó kế thừa cách tiếp cận hệ thống từng bước từ chu kỳ sống cổ điển nhưng kết hợp với quá trình lặp lại phù hợp với thực tế. Giống như các quy trình khác, mô hình xoáy ốc không phải là công cụ vạn năng. Đối với những hệ thống lớn, khó có thể điều khiển sự tiến hóa của phần mềm. Nó đòi hỏi phải có kỹ năng đánh giá lỗi. Cuối cùng là cần phải có thêm thời gian để kiểm nghiệm phương pháp mới này. 1.4.4. Mô hình thác nƣớc Đây là mô hình của cách tiếp cận hướng đối tượng, hệ thống được xem như là một hệ thống các thực thể tác động qua lại để đạt được một mục đích nào đó. Mô hình này tương ứng với mô hình thác nước trong cách tiếp cận hướng thủ tục ở trên. Ở đây, ta thấy trong có những phần lặp và giao nhau giữa các bước phân tích, thiết kế và cài đặt. Các điểm chính của mô hình được tóm tắt như sau: 24
25. 1.4.5. Mô hình phát triển dựa trên thành phần Xuất phát từ quan điểm: "Buy do not build", tư tưởng của phát triển dựa trên thành phần là lắp ráp hệ thống từ những thành phần đã có. Do vậy, kiến trúc phần mềm của hệ thống dựa vào kiến trúc phần mềm của các thành phần phần mềm tiêu chuẩn nên hệ thống đạt chất lượng cao hơn. Phương pháp phát triển dựa trên thành phần gần tương tự như phương pháp phát triển hướng đối tượng. Hoạt động công nghệ bắt đầu với sự chỉ ra các lớp tham dự để phát triển hệ thống. Nếu các lớp này được tìm thấy trong thư viện và sự thích nghi là tốt, chúng sẽ được lấy ra và phát triển hệ thống. Ngược lại, chúng sẽ được phát triển để sử dụng và bổ sung vào thư viện sử dụng lại. Thành phần phần mềm được sử dụng lại có độ chính xác cao và có thể nói là không chứa lỗi. Mặc dầu không thường xuyên được chứng minh về mặt hình thức nhưng với việc sử dụng lại, lỗi được tìm thấy và loại trừ; chất lượng của thành phần được cải thiện như là một kết quả. Khi những thành phần sử dụng lại được ứng dụng thông qua tiến trình phần mềm, chúng ta ít tốn thời gian để tạo ra kế hoạch, mô hình, tài liệu, mã và dữ liệu mà chúng là cần thiết để tạo ra hệ thống. Thêm vào, chức năng cùng mức được phân phối cho người sử dụng với đầu vào ít công sức hơn, do vậy, hiệu suất phần mềm được cải thiện. 1.5. Phƣơng pháp phát triển phần mềm Khác với thời kỳ đầu của tin học, các chương trình phụ thuộc nhiều vào thiết bị và người ta chỉ quan tâm đến các "mẹo vặt" lập trình, thì ngày nay người ta quan tâm đến nguyên lý và phương pháp để phát triển phần mềm. Các nguyên lý và phương pháp được đề xuất nhằm nâng cao năng suất lao động cho nhóm phát triển phần mềm. 25
26. Năng suất ở đây bao gồm tính đúng đắn của sản phẩm, tính dễ đọc, dễ sửa đổi, dễ thực hiện, tận dụng được tối đa khả năng của thiết bị mà vẫn không bị phụ thuộc vào thiết bị. Có nhiều phương pháp được đề cập như: phương pháp hướng chức năng, phương pháp hướng đối tượng, phương pháp ngữ nghĩa Và thậm chí là không phương pháp để phát triển phần mềm. Bên cạnh các phương pháp để chỉ định cho việc tạo một bản phân tích và thiết kế, người ta còn chú ý đến phương pháp làm thế nào để đưa người dùng tham gia vào quy trình gọi là phương pháp luận xã hội. 1.6. Vai trò của ngƣời dùng trong giai đoạn phát triển phần mềm Trong những ứng dụng trước kia được xây dựng thường xuyên không có sự bàn bạc với người sử dụng, sự cô lập của các công nghệ phần mềm đối với người dùng dẫn đến những hệ thống có khả năng làm việc về mặt kỹ thuật, nhưng thông thường không đáp ứng được nhu cầu của người sử dụng, và thường xuyên làm gián đoạn quá trình làm việc. Để có sự tham gia của người sử dụng trong quá trình phát triển ứng dụng, phương thức này đòi hỏi những cuộc họp ngoài lề của tất cả những người sử dụng có liên quan và những người trong hệ thống - thường những người gặp nhau trong từ 5 đến 10 ngày để phát triển một mô tả chức năng chi tiết của những yêu cầu ứng dụng. Các cuộc họp ban ngày được sử dụng về những phân tích mới, những cuộc họp ban đêm lập tài liệu về những kết quả ban ngày để xem xét lại và tiếp tục chắt lọc trong ngày tiếp theo. Có rất nhiều lợi ích từ việc tham gia của người sử dụng trong phát triển ứng dụng. . Trước tiên nó xây dựng sự cam kết của những người sử dụng - những người đương nhiên đảm nhiệm quyền sở hữu của hệ thống. . Thứ hai, những người sử dụng là những chuyên gia thực sự của những công việc đang được tự động - lại được đại diện hoàn toàn thông qua sự phát triển. . Thứ ba, những nhiệm vụ được người sử dụng thực hiện bao gồm việc thiết kế màn hình, các mẫu, các báo cáo, sự phát triển tài liệu của người sử dụng, sự phát triển và tiến hành của các cuộc kiểm tra công nhận Sự tham gia của người sử dụng không chỉ là ước muốn mà còn là một mệnh lệnh đối với tiến trình và sản phẩm phát triển ứng dụng hoàn toàn hiệu quả. Khía cạnh quan trọng nhất của sự tham gia của người sử dụng là nó phải có ý nghĩa. Người sử dụng phải là những người quyết định và là những người mong muốn tham gia vào quá trình phát triển. Sử dụng đội ngũ nhân viên ở cấp thấp hoặc chỉ định các nhà quản lý mở rộng không phải là cách để kéo người sử dụng vào các ứng dụng phát triển. Mục tiêu của việc tham gia của người sử dụng là cho những người phát triển hệ thống và không phát triển hệ thống làm việc cùng với nhau như những đối tác chứ không phải như những kẻ thù. Khi những người sử dụng tham gia thì họ sẽ tạo ra những quy định không mang tính kỹ thuật. Những kỹ sư phần mềm giải thích và 26
27. hướng dẫn người sử dụng tạo ra những quy định nữa kỹ thuật, ví dụ như việc thiết kế màn hình, và giải thích cả những tác động và suy luận của các quy định kỹ thuật chính yếu. 1.7. Tiêu chuẩn của sản phẩm phần mềm Mục tiêu của công nghệ phần mềm là sản xuất ra những phần mềm tốt, có chất lượng cao. Các nhân tố ảnh hưởng đến chất lượng phần mềm có thể được phân thành hai nhóm chính: các nhân tố có thể đo trực tiếp và các nhân tố chỉ có thể đo gián tiếp. Tuỳ theo công dụng của sản phẩm và nhu cầu thực tế của người sử dụng, các chuẩn của quốc gia, quốc tế, nền văn minh của cộng đồng, thời điểm, mà các tiêu chuẩn để lượng hoá phần mềm có thể thay đổi. Phần này nhằm tìm hiểu các tiêu chuẩn hiện nay được dùng để đánh giá một sản phẩm phần mềm. Để đánh giá được sản phẩm của một nền công nghệ là tốt hay xấu, chúng ta phải nghiên cứu để đưa ra được những tiêu chuẩn đánh giá chúng. Chất lượng của sản phẩm phần mềm bao gồm nhiều yếu tố dựa trên các tiêu chuẩn đã được tổng kết. 1.7.1. Tính đúng Một sản phẩm thực hiện được gọi là đúng nếu nó thực hiện chính xác những chức năng đã đặc tả và thỏa mãn các mục đích công việc của khách hàng. 27
28. Như vậy, một sản phẩm phải được so sánh chuẩn đặt ra để kiểm tra tính đúng và điều này dẫn đến có nhiều bậc thang về tính đúng. Liệt kê theo thang giảm dần, tính đúng của phần mềm có thể: . Tuyệt đối đúng, . Đúng , . Có lỗi, . Có nhiều lỗi, Ví dụ: Một hệ thống xử lý dữ liệu không chạy được khi file cơ sở dữ liệu rỗng hoặc có quá 104 bảng ghi, là những hệ thống vi phạm tính đúng. 1.7.2. Tính khoa học Tính khoa học của phần mềm được thể hiện qua các mặt . Khoa học về cấu trúc. . Khoa học về nội dung. . Khoa học về hình thức thao tác. 1.7.3. Tính tin cậy Tính tin cậy của sản phẩm phần mềm thể hiện ở sản phẩm được trông chờ thực hiện các chức năng dự kiến của nó với độ chính xác được yêu cầu. 1.7.4. Tính kiểm thử đƣợc Phần mềm có thể kiểm thử được là phần mềm mà nó có cách dễ dàng để có thể kiểm tra được. Đảm bảo rằng nó thực hiện đúng các chức năng dự định. 1.7.5. Tính hữu hiệu Tính hữu hiệu của phần mềm được xác định qua các tiêu chuẩn sau: . Hiệu quả kinh tế hoặc ý nghĩa; giá trị thu được do áp dụng sản phẩm đó. . Tốc độ xử lý sản phẩm. . Giới hạn tối đa của sản phẩm hoặc miền xác định của chương trình được xác định qua khối lượng tối đa của các đối tượng mà sản phẩm đó quản lý. 1.7.6. Tính sáng tạo Một sản phẩm phần mềm có tính sáng tạo khi nó thảo mãn một trong các tính chất sau: . Sản phẩm được thiết kế và cài đặt đầu tiên. . Sản phẩm được phục vụ cho những đặc thù riêng. . Sản phẩm có những đặc điểm khác về mặt nguyên lý so với các sản phẩm hiện hành. 28
29. . Sản phẩm có những ưu thế nổi bậc so với sản phẩm hiện hành. 1.7.7. Tính an toàn Tính an toàn của sản phẩm phần mềm được đánh giá thông qua: . Có cơ chế bảo mật và bảo vệ các đối tượng do hệ thống phát sinh hoặc quản lý. . Bản thân sản phẩm được đặt trong một cơ chế bảo mật nhằm chống sao chép trộm hoặc làm biến dạng sản phẩm đó. 1.7.8. Tính toàn vẹn Sản phẩm phần mềm có tính toàn vẹn khi nó: . Có cơ chế ngăn ngừa việc thâm nhập bất hợp pháp vào phần mềm hay dữ liệu và ngăn ngừa việc phát sinh ra những đối tượng (dữ liệu, đơn thể ) sai quy cách hoặc mâu thuẩn với các đối tượng sẳn có. . Không gây ra nhập nhằng trong thao tác. Đảm bảo nhất quán về cú pháp. . Có cơ chế phục hồi lại toàn bộ hoặc một phần những đối tượng thuộc toàn bộ hoặc một phần những đối tượng thuộc diện quản lý của sản phẩm trong trường hợp có sự cố như hỏng máy, mất điện đột ngột. 1.7.9. Tính đối xứng và đầy đủ chức năng Sản phẩm cung cấp đủ các chức năng cho người sử dụng và các chức năng của sản phẩm có các cặp loại trừ lẫn nhau, ví dụ các chức năng đối xứng thường gặp: . Tạo lập - Hủy bỏ, . Thêm - Bớt (xem - xóa), . Tăng - Giảm, . Dịch chuyển lên - xuống; phải - trái, . Quay xuôi - ngược chiều kim đồng hồ 1.7.10. Tính tiêu chuẩn và tính chuẩn Sản phẩm phần mềm cần đạt được một số tiêu chuẩn tối thiểu được thừa nhận trong thị trường hoặc trong khoa học, và có thể chuyển đổi dạng cấu trúc dữ liệu riêng của hệ thống sang chuẩn và ngược lại. Tính chuẩn của phần mềm thể hiện ở sản phẩm đó phù hợp với các chuẩn quốc gia hoặc quốc tế. Trong khi xây dựng phần mềm, cần tuân theo nguyên tắc chuẩn hoá sau: . Chỉ thiết kế và xây dựng phần mềm sau khi đã xác định được chuẩn. 29
30. . Mọi thành phần của phần mềm phải được thiết kế và cài đặt theo cùng một chuẩn (tối tiểu thì các chuẩn phải tương thích nhau). 1.7.11. Tính độc lập Phần mềm cần và nên đảm bảo được tính độc lập với các đối tượng sau: . Độc lập với thiết bị, . Độc lập với cấu trúc của đối tượng mà sản phẩm đó quản lý, . Độc lập với nội dung của đối tượng mà sản phẩm đó quản lý. 1.7.12. Tính dễ phát triển, hoàn thiện Thể hiện ở phần mềm có thể mở rộng cho các phương án khác hoặc mở rộng, tăng cường về mặt chức năng một cách rõ ràng. 1.7.13. Một số tính chất khác Ngoài các tính chất trên, tuỳ theo công dụng mà sản phẩm phần mềm cần phải được bổ sung các tính chất sau: . Tính phổ dụng: có thể áp dụng cho nhiều lĩnh vực theo nhiều chế độ làm việc khác nhau. . Tính đơn giản: mang những yếu tố tâm lý: dễ thao tác, dễ học, dễ hoàn thiện kỹ năng khai thác sản phẩm, trong sáng, dễ hiểu, dễ nhớ . Tính liên tác: là tính chất cần có để có thể gắn hệ thống này với hệ thống khác. . Tính súc tích: là độ gọn của chương trình tính theo số mã dòng lệnh. . Tính dung thứ sai lầm: tức là những hỏng hóc xuất hiện khi chương trình gặp phải lỗi được chấp nhận. . Tính module: là sự độc lập chức năng của các thành phần trong chương trình. . Tính đầy đủ hồ sơ: hệ thống phải có đầy đủ hồ sơ pháp lý khi xây dựng. . Tính theo dõi được, tính dễ vận hành, 1.8. Quản lý dự án phần mềm 1.8.1. Các hoạt động chuẩn bị dự án Lựa chọn phương án để phát triển hệ thống là một quyết định hệ trọng. Sơ đồ lựa chọn phương án cho một dự án phần mềm được trình bày như sau: 30
31. Trước khi lập kế hoạch dự án, cần phải thiết lập các mục tiêu và phạm vi của dự án. Người quản trị dự án và kỹ sư phần mềm lên kế hoạch điều khiển dự án, đăng ký đội ngũ nhân viên làm nhiệm vụ sau đó tiến hành lựa chọn giải pháp, phương án. Nếu không có những thông tin này thì không thể xác định được những ước lược hợp lý và chính xác về chi phí, không thể tiến hành chia nhỏ các nhiệm vụ thực tế và không thể xác định được thời gian biểu cho dự án. Khi các mục tiêu và phạm vi đã được hiểu rõ thì xem xét tới các giải pháp khác, những ràng buộc khác như: hạn giao hàng, khả năng nhân sự, ràng buộc ngân sách, giao diện kỹ thuật, để lựa chọn phương án phát triển hệ thống. 1.8.2. Lập kế hoạch dự án Người quản trị dự án và kỹ sư phần mềm xác định nhân tố con người, máy tính và các tài nguyên tổ chức yêu cầu để phát triển ứng dụng. Kế hoạch dự án chính là sơ đồ các nhiệm vụ, thời gian và các mối quan hệ giữa chúng. Việc lên kế hoạch, nói chung, thường gồm các bước sau: . Liệt kê các nhiệm vụ: gồm các nhiệm vụ phát triển ứng dụng, các nhiệm vụ đặc trưng của dự án, các nhiệm vụ về tổ chức giao diện, sự xem xét lại và các việc phê chuẩn. . Định danh phụ thuộc giữa các công việc. 31
32. . Xác định nhân viên dựa vào kỹ năng và kinh nghiệm. . Ấn định thời gian hoàn thành cho mỗi công việc bằng các tính toán thời gian hợp lý nhất cho mỗi công việc. . Định danh hướng đi tới hạn. . Xem xét lại các tài liệu theo khía cạnh đầy đủ, nội dung, độ tin cậy và độ chắc . Thương lượng, thỏa thuận và cam kết ngày bắt đầu và kết thúc công việc . Xác định các giao diện giữa các ứng dụng cần thiết, đặt kế hoạch cho việc thiết kế giao diện chi tiết. Các nhiệm vụ trong lập kế hoạch dự án thường bao gồm: . Do tất cả các tài liệu, kế họach và công việc của nhóm là phụ thuộc vào người sử dụng, do vậy tổ chức này bao gồm người quản lý, người sử dụng, kiểm toán, phải đưa các kiến thức chuyên ngành của mình vào những tài liệu ứng dụng một cách thích hợp. . Cần đạt được sự đồng ý, cam kết từ các ngành, phòng ban bên ngoài trong quá trình cung cấp tài liệu. Bên cạnh đó, bộ phận đảm bảo chất lượng phải xem xét để tìm ra các sai sót và không đồng nhất của tài liệu và tất cả các hoạt động này đều phải đạt kế hoạch. . Xác định các đòi hỏi về giao diện ứng dụng. . Đánh giá khối lượng công việc. Thời gian cho mỗi công việc phụ thuộc vào tính phức tạp và mục tiêu của nó - có ba loại thời gian cần tính đến: thời gian bi quan (P), thời gian thực tế (R), thời gian lạc quan (O). Thời gian lịch trình được tính = (O+2R+P)/4 . Vấn đề tiếp theo là xác định kỹ năng và kinh nghiệm cần có của người thi hành nhiệm vụ để xác định dùng bao nhiêu người và có kỹ năng gì cho dự án. Sau đó xác định lịch trình làm việc và người quản trị dự án xác định ngân sách. Ở đây cần có sự trao đổi để hạn chế các trục trặc có thể xảy ra. . Sau khi hoàn tất, kế hoạch, lịch trình và dự toán ngân sách được đưa cho người sử dụng và người quản lý hệ thống để bổ sung hoặc thông qua.  Chú ý: Bản kế hoạch không nên đóng cứng, nó có thể thay đổi khi công đoạn nào đó có sự cố xảy ra hoặc thời hạn tỏ ra không phù hợp hay có những thay đổi quan trọng trong mục tiêu của dự án. 1.8.3. Nghiên cứu tính khả thi dự án 1.8.3.1. Đề cƣơng nghiên cứu: . Giới thiệu - Phát biểu bài toán 32
33. - Môi trường thực hiện - Các ràng buộc . Tóm tắt về quản lý và khuyến cáo - Yêu cầu của quản lý - Bình luận, nhận xét - Khuyến cáo - Tác động . Các phương án - Cấu hình của hệ thống - Các tiêu chuẩn để lựa chọn phương án . Mô tả hệ thống - Mô tả phạm vi hoạt động của hệ thống - Mô tả tính khả thi . Phân tích các phí tổn và các lợi ích . Đánh giá về rủi ro - mức độ rủi ro về kỹ thuật . Những vấn đề khác 1.8.3.2. Thuật toán nghiên cứu tính khả thi của một số dự án tin học . Tổ chức nhóm nghiên cứu tính khả thi: giai đoạn 1 . Tìm kiếm lời giải: giai đoạn 2 . Phân tích tính khả thi: giai đoạn 3 . Lựa chọn lời giải: giai đoạn 4 1.8.4. Lựa chọn giải pháp Mọi ứng dụng đều phải có chiến lược cài đặt, môi trường cài đặt và phương pháp luận. Người quản trị dự án và kỹ sư phần mềm phải lựa chọn giải pháp tốt nhất cho hệ thống. 1.8.4.1. Chiến lƣợc cài đặt Đây là việc lựa chọn giữa lập trình theo lô, trực tuyến, thời gian thực hay trộn lẫn giữa chúng. Việc quyết định lựa chọn phương pháp nào dựa trên sự phối hợp các yêu cầu của người sử dụng về sự chính xác của dữ liệu, dung lượng giao dịch mỗi ngày, số người làm việc trong ứng dụng vào mỗi thời điểm. Tất cả các số liệu này được đánh giá trong giai đoạn lập kế hoạch của ứng dụng, và có thể thay đổi. 33
34. Để ý rằng việc quyết định chiến lược cũng có thể thay đổi và sau đây là bảng tham khảo lựa chọn chiến lược dựa vào thời gian dữ liệu lưu hành (tính trên đơn vị giờ) và dung lượng giao dịch (tính trên đơn vị phút) 1.8.4.2. Môi trƣờng cài đặt Môi trường cài đặt bao gồm phần cứng, ngôn ngữ, phần mềm và các công cụ trợ giúp máy tính được sử dụng khi phát triển và triển khai ứng dụng. Quyết định không kết thúc ở giai đoạn thực hiện và lập kế hoạch, mà có các lựa chọn và một quyết định có khả năng nhất được xác định. Các đường lối được giải quyết để xác định một quyết định cuối cùng. Thường quyết định dựa trên kinh nghiệm của các quản trị viên dự án, kỹ sư hệ thống, và khả năng của các thành viên trong dự án. Nguyên tắc chỉ đạo khi lựa chọn môi trường cài đặt là phải xuất phát từ người sử dụng. Họ đã có các trang thiết bị mà họ muốn sử dụng hay chưa? Chúng được cấu hình như thế nào? Trang thiết bị có các phần mềm hay ứng dụng gì? Người sử dụng có khả năng thay đổi cấu hình để thích hợp với ứng dụng mới không? 1.8.4.3. Phƣơng pháp luận Giải pháp cuối cùng được thử nghiệm quyết định là dùng phương pháp luận gì và quy trình sản xuất như thế nào? Người quản lý phải biết rằng không phải tất cả các dự án đều giống nhau, do đó cách triển khai các dự án cũng không thể giống nhau. Với giả thiết không có yêu cầu cài đặt đặc biệt nào cả, ứng dụng tự nó phải là nhân tố cơ bản để quyết định phương pháp luận. . Trong môi trường kinh doanh, các quy luật cơ bản để lựa chọn phương pháp luận nhằm đánh giá sự phức tạp của ứng dụng một cách tốt nhất, . Nếu sự phức tạp là trong thủ tục, một phương pháp hướng xử lý là tốt nhất, . Nếu sự phức tạp là trong liên kết dữ liệu, một phương pháp luận hướng dữ liệu là tốt nhất, . Nếu bài toán dễ dàng chia nhỏ ra thành một chuỗi các bài toán nhỏ, một . phương pháp đối tượng sẽ là tốt nhất, 34
35. . Nếu dự án là nhằm xử lý trí tuệ nhân tạo hoặc bao gồm suy diễn, một phương pháp luận ngữ nghĩa là tốt nhất, Vấn đề lựa chọn chu kỳ tồn tại cũng đòi hỏi một số quyết định về kiểu gì và có bao nhiêu người sử dụng. Các ứng dụng phức tạp với các yêu cầu được biết thường đi kèm theo một quy trình thác nước. Nếu một số tỷ lệ của ứng dụng - yêu cầu, phần mềm, ngôn ngữ - là mới và chưa được kiểm nghiệm, kiểu tạo mẫu sẽ được sử dụng. Kỹ thuật hướng đối tượng đảm bảo kiểu mẫu và lặp. Nếu vấn đề là duy nhất, một phần trong vấn đề trước đây chưa bao giờ được tự động hóa, ngay cả một kiểu mẫu học để sử dụng hoặc một chu kỳ vòng sống sản phẩm kiểu lặp có thể được sử dụng. 1.8.5. Giám sát và kiểm soát Khi xây dựng dự án, các thành viên của nhóm phải báo cáo việc sử dụng thời gian cho mỗi hoạt động ở các giai đoạn. Hơn nữa, mỗi cá nhân phải viết một báo cáo ngắn về tiến bộ của bản thân. Báo cáo này sẽ tóm lược chất lượng công việc, những vấn đề còn tồn tại và các sai sót hoặc các mâu thuẫn khác có thể làm trì hoãn công việc. Nếu một công việc bị chậm so với kế hoạch, thì anh ta phải giải trình về sự chậm trễ. Quản trị viên dự án và kỹ sư hệ thống phải xem xét báo cáo và thời gian biểu để xem liệu có cần bổ sung thêm gì không. Cả kỹ sư phần mềm và quản trị viên dự án phải vạch ra các tiến bộ thật sự của các cá nhân so với thời gian biểu dự kiến. Khi sự tiến triển có vẻ chậm lại, quản trị viên dự án cần phải hỏi anh ta về các tồn tại cụ thể. Liệu đã đủ tiềm lực, hoặc liệu anh ta có nghĩ anh ta có thể đáp ứng được các hoạch định không. Nếu công việc đã bị đánh giá thấp, kế hoạch phải được kiểm tra lại để xem việc phân chia thời gian có làm chậm trễ công việc hay không, ảnh hưởng tích lũy của sự thay đổi phải được kiểm tra để xem công việc có được hoàn tất không. Nếu không, quản trị viên dự án cần thảo luận vấn đề với người quản lý của anh ta và họ sẽ quyết định các hành động cần thiết phải làm. Cần chú rằng phải sớm chỉ ra các vấn đề tiềm tàng trước khi chúng trở thành những vấn đề lớn. Nếu một người không thể hoàn thành công việc chỉ vì anh ta được phân quá nhiều công việc, phải phân công lại cho một người khác. Nếu họ không có đủ thời gian kiểm định, phải thu xếp để có thêm thời gian. Sự quản lý tích cực sẽ ngăn chặn được nhiều vấn đề. Vấn đề tiếp theo là tính kỹ luật và lao động ảnh hưởng lên kế hoạch các công việc thay thế, điều chỉnh kế hoạch khi cần thiết và tiếp tục kiểm soát các vấn đề cho đến khi chúng được giải quyết. Khi cần thiềt, phải nói cho khách hàng biết về các vấn đề có thể không giải quyết được do vậy họ sẽ được chuẩn bị cho sự chậm trễ nếu điều đó là không tránh khỏi. Khi sự thay đổi là cần thiết, cho khách hàng biết về sự thay đổi về ngày giờ kếhoạch thậm chí khi ngày hoàn tất công việc không thay đổi. Có nhiều dạng vấn đề tồn đọng có thể xảy ra và quản trị viên dự án phải giám sát, thay đổi trong suốt quá trình phát triển của dự án. . Trong việc xác định phạm vi dự án, quản trị viên dự án phải xem xét các điều sau: 35
36. - Khách hàng có hợp tác không? - Tất cả các đối tác có nhìn nhận và quan tâm? - Những người sử dụng được phỏng vấn có đưa ra những thông tin đầy đủ và chính xác? - Những người sử dụng có tham gia như mong đợi? - Liệu có vấn đề chính sách bên ngoài nào được nêu ra? - Quy mô, các công việc được xác định đã hợp lý chưa? - Bằng việc phân tích, quản trị viên dự án biết hầu hết người sử dụng và họ làm việc thế nào, cần chỉ ra những vấn đề chính sách tiềm tàng và giải quyết chúng và nên hài lòng với quy mô dự án. . Các hoạt động được giao cho các ban liên quan: - Liệu tất cả các nhà phân tích có biết quy mô hoạt động và làm việc trong khuôn khổ đó? - Công việc phân tích nhấn mạnh vào cái gì và như thế nào? - Liệu mọi người có quan tâm và thích thú với công việc? - Liệu có va chạm giữa các nhân viên của ban hoặc giữa những người sử dụng? - Liệu mọi người có biết họ đang làm gì không? - Có sự phản hồi liên tục được người sử dụng sửa đúng lại, trong kết quả phỏng vấn? - Các thành viên của ban có bắt đầu hiểu công việc và tình hình của người sử dụng? - Các thành viên của ban dự án có khách quan và không ép người sử dụng theo những ý tưởng của họ. - Các tài liệu viết ra đã hoàn thiện? Người sử dụng có đồng ý? - Việc phân tích có chỉ đúng ra các vấn đề tồn tại của người sử dụng? Các nhân viên có phân tích và mô tả chính xác các việc cần làm mà không thêm thắt? - Việc đánh máy, in ấn, sao chụp và các hỗ trợ biên chép khác là có thể chấp nhận? - Sự giao tiếp giữa các ban và giữa các ban và người sử dụng có đáng hài lòng không? - Dự án có đúng thời hạn? Tình trạng đường lối phê bình? Có thay đổi nếu công việc kết thúc sớm? - Tồn tại lớn nhất hiện tại ở đâu? Làm thế nào để làm nhẹ bớt các vấn đề tồn tại? - Điều gì chúng ta không biết có thể làm thiệt hại đến công việc? 36
37. . Các yêu cầu chức năng là kết quả từ việc phân tích cần mô tả ứng dụng nào sẽ được áp dụng, và phải luôn cẩn thận trước các yêu cầu của người sử dụng. Một vấn đề mà nhiều dự án gặp phải là người sử dụng muốn một ứng dụng chức năng đơn thuần nhưng các nhà phân tích lại tạo ra một ứng dụng giá cao với các chức năng của người sử dụng nhưng có nhiều đặc tính không cần thiết. Vấn đề này, nếu xảy ra, phải được giải quyết trước khi việc phân tích kết thúc hoặc các chức năng phụ thêm sẽ được đưa vào ứng dụng kết quả. Khi vấn đề thiết kế quá mức nảy sinh, điều quan trọng là phải cố gắng truy cập đến các phân tích cụ thể để tái huấn luyện. Do vậy, quản trị viên dự án quan tâm đến: - Các nhà phân tích có biết đến các ứng dụng? - Việc chuyển dịch sang môi trường hoạt động có đúng và hoàn tất? - Những người sử dụng có tham gia như mong đợi? Những người sử dụng có quan tâm đúng mức đến việc thiết kế màn hình chạy thử và chấp nhận các phê bình? - Mọi người có quan tâm và thích thú công việc? - Có sự va chạm giữa các nhân viên hoặc giữa nhân viên và người sử dụng? - Mọi người có biết họ đang làm gì? - Các nhân viên có chú ý tới sự thay đổi trách nhiệm của họ và họ có cảm thấy thoải mái để có thể tiếp tục công việc? - Sự giao tiếp giữa các ban dự án và người sử dụng có hài lòng? - Dự án diễn biến đúng kế hoạch? Tình trạng phê bình thế nào? Có thay đổi do công việc hoàn thành sớm không? - Vấn đề lớn nhất bây giờ là gì? Có thể làm gì để giảm nhẹ các vấn đề? - Điều có thể gây nguy hại cho chúng ta mà không biết? Môi trường thực hiện có thích hợp cho ứng dụng? - Phần mềm quản lý dữ liệu có thể phù hợp với ứng dụng này không? . Do sự phát triển của chương trình nên số các thành viên dự án có thể thường xuyên tăng thêm ngày càng nhiều. Sự trao đổi các thông tin là cần thiết để nắm bắt được vị trí của mọi thành viên dự án và các thành viên cũng nắm bắt được sự phát triển của dự án. Nên quá trình viết và kiểm thử chương trình sẽ được điều chỉnh trong quá trình trao đổi thông tin và chạy chương trình. Để đáp ứng được, phải quan tâm: - Các thành viên dự án có biết được vai trò phần việc của họ trong dự án hay không? Họ có đánh giá được phần việc của mình hay không? Các thành viên hiện tham gia dự án có đảm đương được công việc mà họ và các thành viên đang làm không? 37
38. - Thời gian kiểm thử chương trình đã đủ chưa? Thông tin truy cập đã đầy đủ chưa? - Các thành viên dự án có đủ hiểu biết về các công nghệ họ đang sử dụng để làm việc độc lập được không? - Các thành viên mới có đủ trình độ để làm việc với các cố vấn có kinh nghiệm hay không? - Người sử dụng có yêu cầu thêm những thay đổi hay không? - Người sử dụng có tham gia vào quá trình kiểm thử thiết kế, có dùng các tài liệu về phát triển, nâng cấp, hướng dẫn hay không? - Các thành phần sữa chữa phản hồi có gây cho khách hàng các nghi ngờ chương trình có lỗi hay không? - Các giao thức sẽ được sử dụng ngày càng nhiều có thể hiện được ứng dụng hoạt động như thế nào hay không? - Qua từng bước thực hiện chương trình, có phát sinh ra lỗi không? Những lỗi này có thể điều chỉnh được không? . Trong suốt quá trình thực hiện chương trình cũng như trong quá trình thực hiện các bước kiểm thử, các kiểm tra về sự thích ứng của chương trình và về các mức hệ thống liên quan sẽ tăng dần. Các cơ sở dữ liệu được thiết lập và hoàn chỉnh dần. Môi trường điều hành được chuẩn bị. . Các cơ cấu liên quan được đưa ra từ ứng dụng được thực hiện dưới dạng mã làm cho nó được thực thi một cách chính xác. Các dạng câu hỏi đặt ra cho người quản lý có thể có các dạng sau: - Các thành viên hiện tại của dự án có đảm nhiệm được phần công việc của mình hay không? Mọi thành viên có hiểu được công việc họ đang làm hay không? - Thời gian kiểm thử chương trình đã đủ chưa? Thông tin truy cập đã đầy đủ chưa? - Người sử dụng có yêu cầu thêm những thay đổi hay không? Người sử dụng có tham gia vào quá trình kiểm thử hay không? - Các thành phần sửa chữa phản hồi có gây cho khách hàng các nghi ngờ chương trình có lỗi hay không? - Qua từng bước thực hiện chương trình, có phát sinh ra lỗi không? Những lỗi này có thể điều chỉnh được không? - Quá trình kiểm tra ở mức độ hệ thống có thể hiện được các chức năng như đã đặt ra hay không? - Quá trình kiểm tra sự thích ứng có xác thực được tất cả các liên kết trung gian hay không? Nó có tác dụng như thế nào tới việc chứng tỏ độ tin cậy của các liên kết này trong suốt quá trình kiểm thử hệ thống. 38
39. - Chúng ta không biết những gì về môi trường điều hành mà nó có thể ảnh hưởng tới dự án? - Phần mềm cơ sử dữ liệu làm việc có hoàn hảo không? Quy trình phục hồi và lưu trữ dữ liệu có đầy đủ cho quá trình kiểm thử hay không? - Chúng ta có thể sử dụng các kiểm tra về sự thích ứng của chương trình và về hệ thống như thế nào để phát triển các giai đoạn kiểm tra hồi quy. - Các thông tin đã hoàn tất chưa? Các thành viên dự án đã làm việc đúng khả năng chưa? Chúng ta có thể đưa các thành viên trong dự án đến thực hiện các dự án khác được không? Nếu chúng ta cho phép họ đi, thì ai sẽ thay thế vị trí họ khi có các vấn đề xảy ra? . Khi quá trình kiểm thử kết thúc, các phần của ứng dụng đã thực sự sẵn sàng cho sử dụng. Nên có một sơ đồ cho ứng dụng điều hành thực tế, điều đó sẽ dễ dàng cho người sử dụng trong việc dùng chương trình để tránh có quá nhiều hỏng hóc. Sự dễ dàng trong quá trình sử dụng này sẽ tạo cho người lập dự án có thời gian cố định những lỗi sai đã phát hiện trong quá trình viết chương trình mà không có áp lực giám sát nào. Vấn đề hiện tại là tập trung vào việc đưa ra ứng dụng làm việc trong môi trường đã được định hướng cho người sử dụng nó. Các câu hỏi liên quan sẽ bao gồm: - Vị trí đã được chuẩn bị đầy đủ chưa? Điều kiện về không gian đã đầy đủ? Thiết kế về ánh sáng và môi trường làm việc đã đầy đủ? - Người sử dụng đã được đào tạo hoàn hảo và đã sẵn sàng làm việc? - Chu trình làm việc và đánh giá kết quả đã được chỉ ra đầy đủ cho phép việc tiến hành và kiểm tra các kết quả đạt được. - Khi tìm ra lỗi chúng có thể điều chỉnh được không? - Người sử dụng có nắm bắt được công việc như dự kiến? - Các thành viên hiện tại của dự án có thể đảm nhiệm được phần việc của họ? Tất cả mọi người có đủ công việc để làm không? Họ có thời gian rỗi để tham gia các dự án khác không? - Thông tin trao đổi giữa các nhóm với nhau và giữa các nhóm với người sử dụng có xuất hiện phù hợp không? Người sử dụng có thể nói bất kỳ khi nào có vấn đề xảy ra không? Họ có tham gia vào quá trình lập nên các quy định cho vấn đề sửa chữa lỗi hay không? Các câu hỏi trên là những vấn đề kỹ thuật và nên được trình lên cho chủ dự án. Quản trị viên dự án là người nắm bắt và quan tâm đến tất cả các vấn đề. Việc biên dịch các báo cáo về tiến trình hoạt động cá nhân và tiến trình hoạt động dự án trong một dự án cho phép người quản lý và bất kỳ nhân viên nào đều có thể xem xét lại những quyết định, các vấn đề xuất hiện trong quá trình tiến hành. 39
40. 1.8.6. Quản lý nhân sự Đây chính là hoạt động để bảo đảm nhân sự cho dự án. Bao gồm các giai đoạn: . Thuê mướn nhân sự, . Thẩm định, đáng giá khả năng, . Đào tạo, huấn luyện, . Tạo môi trường làm việc, . Sa thải. 1.9. Hồ sơ của sản phẩm phần mềm Bao gồm các thành phần liệt kê sau: tuy nhiên theo yêu cầu quản lý và bản quyền của tác giả phần mềm có thể bỏ bớt hay bổ sung thêm một số thành phần khi cần thiết: . Đặc tả hệ thống. . Kế hoạch dự án phần mềm. - Đặc tả yêu cầu phần mềm. - Bản mẫu thực hiện được hay "trên giấy". . Tài liệu người dùng sơ bộ . Đặc tả thiết kế. - Mô tả thiết kế dữ liệu. - Mô tả thiết kế kiến trúc. - Mô tả thiết kế module. - Mô tả thiết kế giao diện. - Mô tả sự vật (nếu kỹ thuật hướng sự vật được dùng). . Bản in chương trình gốc. - Chương trình nguồn. - Bản in chương trình nguồn (listing). - Bản mô tả thuật toán tương ứng với chương trình nguồn. - Kế hoạch và thủ tục kiểm thử. - Các trường hợp kiểm thử và kết quả ghi lại. . Tài liệu vận hành và cài đặt. - Bản liệt kê các lỗi và cách xử lý. - Bản liệt kê các thông số đặc trưng của hệ thống. . Chương trình thực hiện được. 40
41. - Các module mã - thực hiện được. - Các module móc nối. - Chương trình đích lưu trữ trên vật mang tin. . Mô tả cơ sở dữ liệu. - Sơ đồ và cấu trúc tệp. - Nội dung ban đầu. . Tài liệu người sử dụng đã xây dựng. - Bản hướng dẫn sử dụng chi tiết. - Bản tóm tắt hướng dẫn sử dụng. - Các chương trình trợ giúp có liên quan. . Tài liệu bảo trì. - Báo cáo vấn đề phần mềm. - Yêu cầu bảo trì. - Trình tự thay đổi kỹ nghệ. . Các chuẩn và thủ tục cho kỹ thuật phần mềm . . Các tư liệu khác: hợp đồng, phiên bản, tài liệu pháp lý, CHƢƠNG 2: KHẢO SÁT - PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU Với sản phẩm phần mềm được xây dựng, việc hiểu đầy đủ các đặc điểm của nó là điều không dễ. Quá trình xác định các chức năng và các ràng buộc của hệ thống gọi là tìm hiểu và xác định yêu cầu. Để có được điều này thì cần phải trả lời câu hỏi "cái gì- what" chứ không phải là "như thế nào-how". Tìm hiểu, xác định và phân tích yêu cầu là bước hình thành bài toán, do vậy các yêu cầu của bài toán cần phải được tìm hiểu và phân tích theo chiều rộng (ngang) và theo chiều sâu (dọc). 2.1. Tìm hiểu – xác định yêu cầu 2.1.1. Khảo sát, tìm hiểu yêu cầu Khi một công ty muốn ký một hợp đồng cho một dự án phát triển một phần mềm, công ty sẽ phát biểu các yêu cầu ở mức trừu tượng để không bắt buộc định nghĩa trước các giải pháp. Các yêu cầu phải được viết sao cho các nhà phát triển phần mềm có thể đưa ra các giải pháp khác nhau. Sau khi đã trúng thầu và ký hợp đồng, yêu cầu phải được làm rõ hơn để khách hàng có thể hiểu và đánh giá được phần mềm. Cả hai tài liệu nói trên đều gọi là tài liệu yêu cầu người dùng. Theo mức độ chi tiết có thể chia ra các loại tài liệu yêu cầu: . Xác định yêu cầu: đây là một khẳng định, bằng ngôn ngữ tự nhiên hơn là các sơ đồ, về các dịch vụ hệ thống cần cung cấp và các ràng buộc mà hệ thống 41
42. phải tuân theo. Tài liệu này cung cấp cho các thành phần: người quản lý của bên khách hàng, người dùng cuối của hệ thống, kỹ sư của khách hàng, người quản lý ký kết hợp đồng, các kiến trúc sư hệ thống. . Đặc tả yêu cầu: là tài liệu được cấu trúc mô tả hệ thống các dịch vụ chi tiết hơn. Đôi khi tài liệu này được gọi là đặc tả chức năng. Đây có thể coi là hợp đồng ký kết giữa người mua và kẻ bán phần mềm. Tài liệu này cung cấp cho các thành phần: người dùng cuối của hệ thống, kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển phần mềm. . Đặc tả phần mềm: là mô tả trừu tượng hơn của phần mềm làm cơ sở cho thiết kế và triển khai. Tài liệu này cung cấp cho các thành phần: kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển phần mềm. Xác định yêu cầu: là mô tả trừu tượng các dịch vụ mà hệ thống được mong đợi phải cung cấp và các ràng buộc mà hệ thống phải tuân thủ khi vận hành. Nó chỉ có các đặc tả phẩm hạnh bên ngoài của hệ thống mà không liên quan đến các đặc tính thiết kế. Nó phải được viết sao cho người ta có thể hiểu được mà không cần một kiến thức chuyên môn đặc biệt nào. Các yêu cầu của phần mềm được chia thành hai loại: Các yêu cầu hệ thống chức năng: các dịch vụ mà hệ thống phải cung cấp. Các yêu cầu không chức năng: các ràng buộc mà hệ thống phải tuân theo. Về nguyên tắc các yêu cầu của một hệ thống phải là vừa đầy đủ, vừa tráng kiện. Đầy đủ có nghĩa là mọi yêu cầu đều phải được đặc tả. Tráng kiện có nghĩa là các yêu cầu không gây ra mâu thuẫn. Thực tế đối với các hệ lớn và phức tạp thì thực là không thể đạt được tính đầy đủ và tính tráng kiện cho phiên bản đầu của tư liệu yêu cầu phần mềm. Vấn đề là khi duyệt lại hoặc trong các pha sau này của vòng đời phần mềm, người ta phát hiện ra các sự không thỏa mãn đó thì tư liệu yêu cầu phải được chỉnh lý lại. Về bản chất, chúng ta phải hiểu và xác định rõ những yêu cầu của khách hàng. Tuy nhiên, thường bài toán được khách hàng phát biểu bằng ngôn ngữ tự nhiên cộng thêm với việc dùng các bảng các biểu đồ cho các người dùng dễ hiểu (xem là người dùng không biết các khái niệm chuyên môn công nghệ thông tin). Không may là ngôn ngữ được dùng này lại thường là không chính xác và mơ hồ, đôi khi có sự lầm lẫn giữa các biểu thị khái niệm và các biểu thị chi tiết làm cho việc mô tả chứa các thông tin hổ lốn được biểu diễn ở nhiều mức chi tiết khác nhau. Ở đây, chúng ta cần chú ý rằng người đặt hàng có thể vì không hiểu biết gì về tin học nên họ không thể phát biểu chính xác và đầy đủ các yêu cầu của họ, đôi lúc thì những cái mà người sử dụng yêu cầu và những cái mà họ cần là không giống nhau. Thêm vào đó, chúng ta lại không hiểu biết đầy đủ về đối tượng, địa bàn cho nên không thể thu thập đầy đủ và chính xác các thông tin của đối tượng và đây chính là một trong những mâu thuẩn giữa khách hàng và chúng ta. Vì vậy, trong thực tế, đối với các hệ 42
43. thống lớn và phức tạp, rất khó có thể đạt được tính đầy đủ và thống nhất của tài liệu yêu cầu. Các yêu cầu được tìm hiểu còn chứa các mâu thuẩn: Thiếu rõ ràng: Rất khó sử dụng ngôn ngữ tự nhiên mô tả chính xác không nhầm lẫn mà không làm khó khăn cho người đọc. Nhầm lẫn yêu cầu: Các yêu cầu chức năng, các ràng buộc, mục đích của hệ thống và các thông tin thiết kế không được phân biệt rõ ràng. Trộn lẫn yêu cầu: Một số các yêu cầu khác nhau có thể được thể hiện như là một yêu cầu đơn. Giải quyết mâu thuẩn này, chúng ta phải: trên cơ sở nghiên cứu kỹ lĩnh vực ứng dụng và thảo luận với người sử dụng để định nghĩa chính xác các yêu cầu của bài toán. Xác định rõ và đầy đủ bài toán là yếu tố quan trọng góp phần đảm bảo thành công của dự án. Nhiệm vụ của giai đoạn này là xây dựng được các hồ sơ mô tả chi tiết về các yêu cầu, nhiệm vụ, chức năng của hệ thống dự kiến. 2.1.2. Đánh giá các yêu cầu Đánh giá các yêu cầu phần mềm liên quan với việc cho biết các yêu cầu thực sự định nghĩa hệ thống đáp ứng đòi hỏi của khách hàng. Nếu việc đánh giá này không chính xác, các lỗi trong phần yêu cầu sẽ truyền tới thiết kế hệ thống và triển khai hệ thống. Chi phí sửa chữa lỗi sẽ rất lớn. Sự thay đổi về yêu cầu ngụ ý rằng việc thiết kế và triển khai cũng phải thay đổi theo. Một số khía cạnh của yêu cầu cần phải kiểm chứng: . Giá trị: người dùng có thể nghĩ rằng hệ thống cần một số chức năng, tuy nhiên sau một số phân tích, có thể xác định các chức năng khác cần được đưa vào. Do hệ thống có nhiều loại người sử dụng nên có các yêu cầu khác nhau và không thể tránh khỏi sự thỏa hiệp các nhu cầu đó. . Chắc chắn: mọi yêu cầu không được mâu thuẫn với các yêu cầu khác . Hoàn chỉnh: định nghĩa cần phải bao gồm mọi chức năng và các ràng buộc . Hiện thực: không có các yêu cầu đặc biệt đến mức phi hiện thực. Có thể dự đoán trước các phát triển phần cứng, tuy nhiên phát triển phần mềm thì khó dự đoán hơn. . Mẫu: là một mô hình chạy được của hệ thống được trình bày với người sử dụng. Đây là một kỹ thuật đánh giá yêu cầu hiệu quả. Nó cho phép người dùng thử nghiệm với hệ thống. Việc đánh giá lại yêu cầu không nên được coi là công việc tiếp theo của tư liệu hóa yêu cầu sau khi đã hoàn thành. Các xem xét về yêu cầu định kỳ liên quan với người dùng và kỹ sư phần mềm luôn cần thiết. Các xem xét yêu cầu có thể là hình thức hoặc phi hình thức. Xem xét phi hình thức liên quan việc các người ký hợp đồng thảo luận các yêu cầu với khách hàng. Nhiều vấn đề có thể được giải quyết dễ dàng bất ngờ khi tham khảo trực tiếp với khách hàng. 43
44. Đối với yêu cầu xem xét chính thức, đội phát triển phải dẫn dắt khách hàng thông qua các yêu cầu hệ thống, giải thích các triển khai của mỗi yêu cầu. Nhóm rà soát phải kiểm tra mỗi yêu cầu về độ thống nhất, hoàn chỉnh cho toàn bộ tài liệu. Họ có thể phải kiểm tra: . Có khả năng kiểm tra: tài liệu có thể kiểm tra thực tế được không? . Khả năng hiểu biết: tài liệu có được khách hàng hiểu biết thấu đáo hay không? . Lưu vết: nguồn gốc của tài liệu có được xác định rõ ràng hay không? Rất có thể phải quay lại nguồn gốc ban đầu để đánh giá ảnh hưởng của sự thay đổi. . Tính thích hợp: các yêu cầu đã phù hợp hay chưa? Có thể thay đổi các yêu cầu mà không làm ảnh hưởng lớn đến toàn bộ hệ thống không. 2.2. Phân tích yêu cầu Nghiên cứu kỹ các yêu cầu của người sử dụng và của hệ thống phần mềm để xây dựng các đặc tả về hệ thống là cần thiết, nó sẽ xác định hành vi của hệ thống. Nhiệm vụ của giai đọan này là phải trả lời được các câu hỏi sau: . Đầu vào của hệ thống là gì . Những quá trình cần xử lý trong hệ thống, hay hệ thống phần mềm sẽ phải xử lý những cái gì. . Đầu ra: kết quả xử lý của hệ thống là gì . Những ràng buộc trong hệ thống, chủ yếu là mối quan hệ giữa đầu vào và đầu ra như thế nào. Trả lời được câu hỏi trên, nghĩa là phải xác định được chi tiết các yêu cầu làm cơ sở để đặc tả hệ thống. Đó là kết quả của sự trao đổi, thống nhất giữa người đầu tư, người sử dụng với người xây dựng hệ thống. Mục tiêu là xây dựng các hồ sơ mô tả chi tiết các yêu cầu của bài toán nhằm nêu bật được hành vi, chức năng cần thực hiện của hệ thống dự kiến. Như vậy, phân tích yêu cầu là quá trình suy luận các yêu cầu hệ thống thông qua quan sát hệ thống hiện tại, thảo luận với các người sử dụng, phân tích công việc. Việc này có thể liên quan với việc tạo một hay nhiều mô hình khác nhau. Nó giúp các phân tích viên hiểu biết hệ thống. Các mẫu hệ thống cũng có thể được phát triển để mô tả các yêu cầu. Ta có quy trình để có các chức năng của hệ thống: 44
45. Trong quá trình phân tích cần lưu ý đến tính khả thi của dự án. . Khả thi về kinh tế: chi phí phát triển phải cân xứng với lợi ích mà hệ thống đem lại, gồm có: Chi phí: - Mua sắm: thiết bị, vật tư (phần cứng), tư vấn, cài đặt thiết bị, quản lý và phục vụ, - Chi phí cho khởi công: phần mềm phục vụ cho hệ thống, hệ thống liên lạc (truyền dữ liệu), nhân sự ban đầu: đào tạo - huấn luyện, cải tổ tổ chức cho phù hợp, - Chi phí liên quan: chi phí nhân công phục vụ thu nhập dữ liệu, sửa đổi, cập nhật hệ thống, chuẩn bị tài liệu, - Chi phí liên tục là tốn kém nhất, gồm: bảo trì, thuê bao, khấu hao phần cứng, chi phí phục vụ cho vận hành, Lợi nhuận do sử dụng hệ thống: - Nhiệm vụ xử lý thông tin: giảm chi phí do xử lý tự động, tăng độ chính xác và kết quả tốt hơn, thời gian trả lời rút ngắn, - Có được từ hệ thống: thu thập và lưu trữ dữ liệu tự động, đầy đủ, dữ liệu được chuẩn hóa, bảo đảm an toàn và an ninh dữ liệu, tương thích và chuyển đổi giữa các bộ phận, truy cập và tìm kiếm nhanh, kết nối và trao đổi diện rộng, . Khả thi về kỹ thuật: đây là vấn đề cần lưu ý vì các mục tiêu, chức năng và hiệu suất của hệ thống theo một cách nào đó là còn "mơ hồ" do vậy xét: - Rủi ro xây dựng: các phần tử hệ thống (chức năng, hiệu suất) khi thiết kế và phân tích có tương đương hay không? 45
46. - Có sẵn tài nguyên: có sẵn con người và tài nguyên cần thiết để phát triển hệ thống? - Công nghệ: các công nghệ liên quan cho việc phát triển hệ thống đã có sẵn hay chưa? . Khả thi về hợp pháp: có sự xâm phạm, vi phạm hay khó khăn nào gây ra khi xây dựng hệ thống hay không. . Các phƣơng án: đánh giá về phương án tiếp cận đến việc xây dựng hệ thống. 2.3. Đặc tả yêu cầu 2.3.1. Đặc tả yêu cầu Khi đã xác định rõ bài toán thì bước tiếp theo là tìm hiểu xem hệ thống dự kiến sẽ yêu cầu làm cái gì. Điều quan trọng ở đây là phải xây dựng được danh sách các yêu cầu của người sử dụng. Dựa trên những yêu cầu của người sử dụng, người phát triển đưa ra các đặc tả cho hệ thống. Người xây dựng hệ thống phải trả lời được các yêu cầu sau đây: . Đầu ra của hệ thống là cái gì? . Hệ thống sẽ phải làm cái gì để có kết quả mong muốn, nghĩa là phải xử lý những cái gì? . Những tài nguyên mà hệ thống yêu cầu là gì? Hiểu rõ nguồn gốc, các dạng thông tin cần cung cấp cho hệ thống hoạt động. Hệ thống sẽ phải giải quyết những vấn đề gì, những kết quả cần phải có là gì? Xác định được mối quan hệ giữa cái vào và cái ra cho quá trình hoạt động của hệ thống. Các đặc tả chi tiết phục vụ cho việc xây dựng và trắc nghiệm về hệ thống để kiểm tra xem những nhiệm vụ đã đặt ra có hoàn tất được hay không. Ở đây, chúng ta cần chú ý là trong một số trường hợp, sẽ nảy sinh những yêu cầu mới mà có thể là ta phải xây dựng lại hệ thống, tất nhiên điều này sẽ làm chậm tiến trình xây dựng và làm tăng giá thành do một vài lý do để không thể hoàn chỉnh các đặc tả đối với các hệ thống như: . Các hệ thống phần mềm lớn luôn đòi hỏi cải tiến từ hiện trạng. Mặc dù các khó khăn của hệ thống hiện tại có thể xác định được nhưng các ảnh hưởng và hiệu ứng của hệ thống mới khó có thể dự đoán trước được. . Hệ thống lớn thường có nhiều cộng đồng sử dụng khác nhau. Họ có các yêu cầu và ưu tiên khác nhau. Các yêu cầu hệ thống cuối cùng không tránh khỏi các thỏa hiệp. . Người trả tiền cho hệ thống và người sử dụng thường khác nhau. Các yêu cầu đưa ra do ràng buộc của các tổ chức và tài chính có thể tranh chấp với yêu cầu của người sử dụng. 46
47. Do các đặc tả yêu cầu thêm các thông tin vào định nghĩa yêu cầu nên các đặc tả thường được biểu diễn cùng với các mô hình hệ thống được phát triển trong quá trình phân tích yêu cầu. Nó cần bao gồm mọi thông tin cần thiết về yêu cầu chức năng và ràng buộc của hệ thống. Phân tích yêu cầu được tiếp tục xác định và đặc tả khi các yêu cầu mới nảy sinh. Đây là tài liệu thường xuyên thay đổi và nên được kiểm soát chặt chẽ. Ngôn ngữ tự nhiên không hoàn toàn thuận tiện cho các thiết kế viên hoặc các hợp đồng giữa các khách hàng và cán bộ phát triển hệ thống vì có một số lý do như sau: . Nhầm lẫn do cách hiểu các khái niệm khác nhau giữa hai bên. . Đặc tả yêu cầu ngôn ngữ tự nhiên quá mềm dẻo. Một vấn đề có thể được mô tả bằng quá nhiều cách khác nhau. . Các yêu cầu không được phân hoạch tốt, khó tìm các mối quan hệ, Do vậy người ta thường dùng các thay thế khác để đặc tả các yêu cầu như: . Ngôn ngữ tự nhiên có cấu trúc, . Ngôn ngữ mô tả thiết kế, giống ngôn ngữ lập trình nhưng có mức trừu tượng cao hơn, . Ngôn ngữ đặc tả yêu cầu, . Ghi chép graphic, . Đặc tả toán học, Có thể chia đặc tả yêu cầu ra làm hai loại: đặc tả phi hình thức (ngôn ngữ tự nhiên) và đặc tả hình thức (dựa trên kiến trúc toán học). 2.3.1.1. Đặc tả phi hình thức Đặc tả phi hình thức là đặc tả sử dụng ngôn ngữ tự nhiên. Tuy nó không được chặt chẽ bằng đặc tả hình thức nhưng được nhiều người biết và có thể dùng để trao đổi với nhau để làm chính xác hóa các điểm chưa rõ, chưa thống nhất giữa các bên phát triển hệ thống. 2.3.1.2. Đặc tả hình thức Đặc tả hình thức là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ nghĩa được định nghĩa hình thức dựa vào toán học. Đặc tả hình thức có thể coi là một phần của hoạt động đặc tả phần mềm. Các đặc tả yêu cầu được phân tích chi tiết. Các mô tả trừu tượng của các chức năng chương trình có thể được tạo ra để làm rõ yêu cầu. Đặc tả phần mềm hình thức là một đặc tả được trình bày trên một ngôn ngữ bao gồm: từ vựng, cú pháp và ngữ nghĩa được định nghĩa. Định nghĩa ngữ nghĩa đảm bảo ngôn ngữ đặc tả không phải là ngôn ngữ tự nhiên mà dựa trên toán học. Các chức năng nhận các đầu vào trả lại các kết quả. Các chức năng có thể định ra các điều kiện tiền tố và hậu tố. Điều kiện tiền tố là điều kiện cần thỏa mãn để có dữ liệu vào, điều kiện hậu tố là điều kiện cần thỏa mãn sau khi có kết quả. 47
48. Có hai hướng tiếp cận đặc tả hình thức để phát triển các hệ thống tương đối phức tạp. - Tiếp cận đại số, hệ thống được mô tả dưới dạng các toán tử và các quan hệ. - Tiếp cận mô hình, mô hình hệ thống được câú trúc sử dụng các thực thể toán học như là các tập hợp và các thứ tự. Sử dụng đặc tả hình thức, ta có các thuận lợi: - Cho phép chúng ta thấy và hiểu được bản chất bên trong của các yêu cầu, đây là cách tốt nhất để làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công việc thiết kế được thuận lợi. - Do chúng ta sử dụng toán học cho việc đặc tả nên có thể dựa vào các công cụ toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ của hệ thống. - Đặc tả hình thức, bản thân nó cho chúng ta một cách thức cho việc kiểm tra hệ thống sau này. Tuy vậy, đặc tả hình thức cũng bộc lộ một vài khó khăn: - Quản lý phần mềm có tính bảo thủ cố hữu của nó, không sẵn sàng chấp nhận các kỹ thuật mới. - Chi phí cho việc đặc tả hình thức thường cao hơn so với các đặc tả khác (tuy phần cài đặt sẽ thấp hơn), nên khó để chứng minh rằng chi phí tương đối cao cho đặc tả sẽ làm giảm tổng chi phí dự án. - Phần lớn, những người đặc tả hệ thống không được đào tạo một cách chính quy về việc sử dụng đặc tả hình thức cho việc đặc tả hệ thống mà dựa trên thói quen của họ. - Thông thường, nhiều thành phần của hệ thống là khó cho việc đặc tả bằng ngôn ngữ hình thức. Thêm vào đó là khách hàng không thể hiểu được nó. - Khách hàng không thích các đặc tả toán học. 2.3.2. Nguyên lý đặc tả Nguyên lý 1: Phân tách chức năng với cài đặt: đặc tả là mô tả điều mong muốn chứ không phải cách thức thực hiện (cài đặt). Kết quả thu được theo dạng cái gì chứ không phải là thế nào. Nguyên lý 2: Cần tới ngôn ngữ đặc tả hệ thống hướng tiến trình: cần thiết đặc biệt trong trường hợp môi trường là động và sự thay đổi của nó ảnh hưởng tới hành vi của thực thể nào đó tương tác với môi trường nào đó. Nguyên lý 3: Đặc tả phải bao gồm hệ thống có phần mềm là một thành phần: vì hệ thống bao gồm các thành phần tương tác với nhau, chỉ bên trong hoàn cảnh của toàn bộ hệ thống và tương tác giữa các thành phần của nó thì hành vi của một thành phần mới có thể xác định. 48
49. Nguyên lý 4: Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành. Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức: không phải là mô hình thiết kế hay cài đặt. Nó phải mô tả một hệ thống như cộng đồng người sử dụng cảm nhận thấy. (Các sự vật mà nó thao tác phải tương ứng với các sự vật của lĩnh vực đó; các tác nhân phải mô hình cho các cá nhân, tổ chức, trang thiết bị; các hành động họ thực hiện thì mô hình cho những hoạt động thực tế xuất hiện trong lĩnh vực; ) Nguyên lý 6: Đặc tả phải vận hành: phải đầy đủ và hình thức để có thể được dùng trong việc xác định liệu một cài đặt được đề nghị có thỏa mãn đặc tả trong những trường hợp kiểm thử tùy ý hay không. Nguyên lý 7: Đặc tả hệ thống phải dung sai về tính không đầy đủ và tính nâng cao. Đặc tả không thể hoàn toàn đầy đủ do môi trường phức tạp: . Đặc tả là mô hình - sự trừu tượng hóa - của tình huống thực nên không đầy đủ. . Đặc tả sẽ tồn tại ở nhiều mức chi tiết. . Các công cụ phân tích được sử dụng để giúp cho đặc tả và kiểm thử đặc tả phải có khả năng xử lý với tính không đầy đủ. Nguyên lý 8: Đặc tả phải được cục bộ hóa và được ghép lỏng lẻo: Đặc tả làm cơ sở cho thiết kế và cài đặt, không phải tĩnh mà là một sự vật động, đang trải qua thay đổi đáng kể nên nội dung và cấu trúc phải phù hợp. Sự thay đổi khi cần sửa đổi là tối thiểu, chỉ một phần nhỏ các thành phần có thể thâm vào hay loại bớt một cách dễ dàng. 2.4. Tƣ liệu hóa yêu cầu của phần mềm Các yêu cầu hệ thống được trình bày trong tài liệu các yêu cầu phần mềm cho biết những thứ cán bộ phát triển hệ thống cần biết. Tài liệu này bao gồm các định nghĩa về yêu cầu và các đặc tả về các yêu cầu. Trong một số trường hợp, chúng không được trình bày riêng biệt mà được tích hợp làm một. Đôi khi, định nghĩa yêu cầu được trình bày như là một giới thiệu tới đặc tả yêu cầu. Cách tiếp cận hiệu quả nhất là trình bày các đặc tả chi tiết như là phụ lục của yêu cầu. Tài liệu yêu cầu phần mềm không phải tài liệu đặc tả. Nó cần phải mô tả cái hệ thống cần phải làm chứ không phải làm thế nào. Tài liệu này cần dễ dàng được đặc tả và ánh xạ sang các phần tương ứng của thiết kế hệ thống. Nếu các dịch vụ, ràng buộc và các đặc tả thuộc tính trong tài liệu yêu cầu phần mềm được thỏa mãn bởi thiết kế thì thiết kế này được coi là giải pháp thích hợp với vấn đề. Về nguyên tắc, các yêu cầu cần được hoàn chỉnh và chắc chắn. Mọi chức năng hệ thống cần được đặc tả và các yêu cầu không được mâu thuẫn. Tuy nhiên các thiếu sót là không thể tránh khỏi, do vậy tài liệu nên được cấu trúc dễ cho việc thay đổi. Nội dung nên được chia thành các chương. Sáu yêu cầu cần được thỏa mãn là: 49
50. . Nó cần mô tả các hành vi hệ thống bên ngoài . Nó cần mô tả các ràng buộc về thực hiện . Nó cần phải dễ thay đổi . Nó phải là công cụ tham chiếu cho người bảo trì hệ thống . Nó cần ghi được vòng đời của hệ thống . Nó cần biểu thị được các đáp ứng chấp nhận được với các sự kiện không dự kiến Cấu trúc chung của tài liệu yêu cầu phần mềm gồm các phần như sau: . Giới thiệu: mô tả sự cần thiết của hệ thống. Nó cần sự mô tả sơ lược các chức năng của mình và giải thích cách làm việc với các hệ thống khác. Nó cũng cần mô tả làm thế nào hệ thống đáp ứng được toàn bộ các mục tiêu chiến lược và nghiệp vụ. . Thuật ngữ: nó cần định nghĩa các khái niệm kỹ thuật được sử dụng trong tài liệu này. Không được giả định người đọc đã có kinh nghiệm. . Mô hình hệ thống: phần này lập một hoặc nhiều mô hình hệ thống cho biết các quan hệ giữa các cấu thành hệ thống với hệ thống và môi trường của nó. Nó cần bao gồm các mô hình đối tượng, mô hình luồng dữ liệu và ngữ nghĩa dữ liệu. . Định nghĩa yêu cầu chức năng: các dịch vụ cung cấp cho người dùng cần được mô tả trong mục này. Mô tả có thể dùng ngôn ngữ tự nhiên, sơ đồ hoặc các dạng ghi chép khác cho phép khách hàng có thể hiểu được. . Định nghĩa yêu cầu phi chức năng: các ràng buộc về phần mềm và các hạn chế đối với thiết kế cần phải được mô tả trong phần này. Nó có thể bao gồm các chi tiết của biểu diễn dữ liệu, thời gian đáp ứng và yêu cầu bộ nhớ, Các tiêu chuẩn về sản phẩm và quy trình cần tuân thủ cũng được mô tả. . Tiến triển hệ thống: phần này mô tả các giả thiết căn bản làm cơ sở cho hệ thống và dự đoán các thay đổi về phát triển phần cứng, yêu cầu người dùng Đặc tả yêu cầu: mô tả các yêu cầu cơ bản chi tiết hơn. Nếu cần các chi tiết hơn có thể được thêm vào các yêu cầu phi chức năng, ví dụ giao diện với các hệ thống có thể được định nghĩa. Ngoài ra, tài liệu yêu cầu phần mềm có thể bao gồm thêm các phần sau: . Phần cứng: nếu hệ thống được phát triển trên một phần cứng đặc biệt, phần cứng này và giao diện cần được mô tả. Nếu phần cứng bán sẵn được sử dụng, các cấu hình cực tiểu và cực đại phải được mô tả. . Yêu cầu dữ liệu: tổ chức logic của dữ liệu được sử dụng bởi hệ thống và các quan hệ giữa chúng được mô tả, có thể dùng sơ đồ thực thể liên kết. 50
51. . Chỉ mục có thể đƣợc cung cấp: Ví dụ chỉ mục theo chữ cái, chỉ mục theo chương, theo chức năng Do hệ thống được vận hành trong thời gian dài, nên môi trường hệ thống và mục đích nghiệp vụ có thể thay đổi. Khi đó tài liệu yêu cầu cũng cần phải thay đổi. Với mục đích tiến triển, tài liệu yêu cầu thường được chia theo hai phân loại: Các yêu cầu ổn định: được suy dẫn từ các hoạt động cốt lõi của tổ chức tương đối liên quan trực tiếp tới miền hệ thống. Các yêu cầu bất thƣờng: các yêu cầu có thể thay đổi khi phát triển hệ thống sau này như: các yêu cầu xuất hiện như là sự hiểu biết của khách hàng về sự phát triển của hệ thống trong quá trình xây dựng hệ thống, các yêu cầu được sinh ra do sự xuất hiện của việc tin học hóa làm thay đổi các quy trình nghiệp vụ, 2.5. Đặc tính dữ liệu và các kỹ thuật để thu thập dữ liệu 2.5.1. Đặc tính dữ liệu Một ứng dụng thành công là một ứng dụng đáp ứng được đầy đủ các yêu cầu của người sử dụng. Trong quá trình xác định yêu cầu, các dữ liệu thu được của bài toán chứa một số tính chất mà ta gọi là đặc tính dữ liệu như: . Tính định hướng thời gian, . Tính cấu trúc, . Tính đầy đủ, . Nhập nhằng, . Ngữ nghĩa, . Độ lớn của dữ liệu, Mỗi yếu tố trên đều quan trọng trong việc xác định các đặc tả của ứng dụng bởi vì chúng mang đến các chỉ dẫn cho kỹ sư phần mềm biết số lượng và kiểu thông tin nên được chọn. Cũng vậy, các kiểu dữ liệu khác nhau có liên quan tới các loại ứng dụng khác nhau và đòi hỏi các kỹ thuật khai thác thông tin khác nhau. Không chú ý tới các đặc tính dữ liệu sẽ gây lỗi phân tích và thiết kế. Mối liên hệ giữa các kiểu ứng dụng và các đặc tính dữ liệu của nó được thể hiện ở bảng sau: 51
52. Hệ xử lý giao dịch bao gồm kiến thức định trước, thông tin đầy đủ, có cấu trúc, hiện thời. Do hệ xử lý giao dịch là các ứng dụng thao tác của công ty nên để điều khiển và bảo trì các bản ghi của thao tác hiện thời, bạn phải có thông tin đầy đủ, hiện thời. Các ứng dụng hỏi đáp có đặc tính tương tự hệ xử lý giao dịch với đặc điểm khác mà chúng có thể tập trung vào các thông tin lịch sử thêm vào thông tin hiện tại. Truy vấn là các câu hỏi được đặt ra bởi dữ liệu để tìm thấy các vấn đề và giải pháp, để phân tích, tổng kết và báo cáo trên dữ liệu. Để tạo tổng kết và báo cáo với sự tin tưởng, dữ liệu phải có cấu trúc, đầy đủ và được diễn giải không nhầm lẫn và có ngữ nghĩa nhất định Hệ hỗ trợ quyết định là các công cụ phân tích thống kê cho phép phát triển các thông tin giúp đỡ việc ra quyết định. Kiểu dữ liệu xác định hệ hỗ trợ quyết định luôn có thể được biểu diễn lại, có thể chưa hoàn chỉnh, nhập nhằng, có ngữ nghĩa thay đổi từ trung bình tới nhiều về độ lớn. Hệ hỗ trợ quyết định theo nhóm là công cụ hỗ trợ họp nhóm cho nhóm người. Các công cụ hệ hỗ trợ quyết định theo nhóm thao tác có cấu trúc trên đầy đủ và còn các nhập nhằng về ngữ nghĩa. Bản thân các công cụ thì đầy đủ, không nhập nhằng và mạnh nhưng các thông tin họp nhóm mà nó thực hiện thì lại không như vậy. Hệ thông tin điều hành là các ứng dụng hướng tương lai cho phép duyệt qua môi trường và xác định khuynh hướng, cơ hội kinh doanh, hoặc các hoạt động công nghiệp khác ảnh hưởng tới hoạt động của công ty. Hệ thông tin điều hành giải quyết phần lớn với các dữ liệu “hỗn độn” không có cấu trúc, không đầy đủ, nhập nhằng, và chứa ngữ nghĩa thay đổi. 52