Tài liệu giảng dạy môn Công nghệ phần mềm - Nguyễn Khắc Quốc

136 trang Gia Huy 17/05/2022 3620

Download

Bạn đang xem 20 trang mẫu của tài liệu "Tài liệu giảng dạy môn Công nghệ phần mềm - Nguyễn Khắc Quốc", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

tai_lieu_giang_day_mon_cong_nghe_phan_mem_nguyen_khac_quoc.pdf

Nội dung text: Tài liệu giảng dạy môn Công nghệ phần mềm - Nguyễn Khắc Quốc

Phụ lục 5 TRƯỜNG ĐẠI HỌC TRÀ VINH KHOA KỸ THUẬT VÀ CÔNG NGHỆ TÀI LIỆU GIẢNG DẠY MÔN CÔNG NGHỆ PHẦN MỀM GV biên soạn: Nguyễn Khắc Quốc Trà Vinh, 5/2015 Lưu hành nội bộ
KHoA rY ruuAT vA cCxc NGHE ^A BO h,{ON CONG NGIIE TX{OI{G TTN A^\^ TRANG PF{E DUY&T TAI LIEU GIANG DAY - TOn tai iiQu giAng dpy: CONG NGI{B' PHA.N MEM - ltlgdy hoin chinh: Th6ng 612015 -1ac gia bidn soan: NG1IYEN rcfAC QUOC - Eon vi c6ng t6c: B0 m6n COng nghQ Thdng tin - Dia chi li0n l4c: B0 m6n C6ng nghQ Th6ng tin Trd Vinh, ngdy l0 thdng 6 ndm 2015 PHE DUYET CUA BQ MON D6ng y su dpng tai liQu staqs a+v ftg- vilt"{:, tk*) wrD't : do i,q.6i Nirr- \'!-.,nlr:::.'- . bien soan dd giang day [rqtl A .4. tJ. /' r\- .,r- mdn tit:'.I. .[Jt6r,-. .ncf-zn. JJ"l(r+. Trit Vinh, ng\, ./,3 thang ( nitm 2015 TR.UCITqG TTO N{ON -f6#furaW*g PHE DUYET CUA KIIOA lra Vinlt3gay 1 {, rlnng .[ . nay 2A t5 rnr.roNc K-r-{q /'? .t 96Qfi"W"@i$*
MỤC LỤC Chương 1 PHẦN MỀM VÀ CÔNG NGHỆ PHẦN MỀM 1 1.1 Phần mềm máy tính 1 1.1.1 Khái niệm 1 1.1.2 Đặc điểm 1 1.1.3 Phân loại 2 1.1.4 Kiến trúc phần mềm 3 1.1.5 Quá trình tạo phần mềm 4 1.2 Công nghệ phần mềm 4 1.2.1 Lịch sử ra đời 4 1.2.2 Định nghĩa 5 1.2.3 Mục tiêu nghiên cứu 6 1.2.4 Đối tượng nghiên cứu 7 1.3 Qui trình phát triển phần mềm 7 1.3.1 Mô hình vòng đời cổ điển (mô hình thác nước) (Waterfall Model) 7 1.3.2 Mô hình làm bản mẫu (Prototype) 12 1.3.3 Mô hình xoắn ốc 13 1.3.4 Kỹ thuật thế hệ thứ tư 14 1.3.5 Mô hình lập trình cực đoan 15 1.3.6 Tổ hợp các mô hình 16 1.3.7 Tính khả thị của quá trình 17 1.3.8 Vấn đề giảm kích cỡ của phần mềm 18 1.4 Cái nhìn chung về công nghệ phần mềm 18 1.5 Một số phương pháp xây dựng phần mềm 20 1.5.1 Khái niệm 20 1.5.2 Phân loại 20 1.5.3 Cách tiếp cận 20 1.5.4 Cách tiến hành 21 1.6 Công cụ và môi trường phát triển phần mềm 23 1.6.1 Khái niệm 23 1.6.2 Phần mềm hỗ trợ phân tích 23 1.6.3 Phần mềm hỗ trợ thiết kế 24 1.6.4 Phần mềm hỗ trợ lập trình 24 1.6.5 Phần mềm hỗ trợ kiểm chứng 24 Tài liệu giảng dạy môn: Công nghệ phần mềm i
1.6.6 Phần mềm xây dựng phương án 24 Chương 2 PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 26 2.1 Đại cương về phân tích và đặc tả 26 2.2 Quá trình phân tích 28 2.2.1 Phân tích phạm vi dự án phần mềm 28 2.2.2 Nghiên cứu khả thi 28 2.2.3 Phân tích mở rộng yêu cầu nghiệp vụ 30 2.2.4 Phân tích yêu cầu bảo mật 31 2.2.5 Phân tích yêu cầu tốc độ 33 2.2.6 Phân tích yêu cầu vận hành 34 2.2.7 Phân tích khả năng mở rộng yêu cầu 34 2.2.8 Phân tích những yêu cầu sẵn có 35 2.2.9 Phân tích yêu tố con người 35 2.2.10 Phân tích yêu cầu tích hợp 36 2.2.11 Phân tích thực tiễn nghiệp vụ tồn tại 36 2.2.12 Phân tích yêu cầu khả năng quy mô 36 2.3 Người phân tích 37 2.4 Xác định và đặc tả yêu cầu 37 2.4.1 Xác định yêu cầu 37 2.4.2 Các bước xác định yêu cầu 38 2.5 Mô hình hóa yêu cầu hệ thống 40 2.5.1 Các nguyên lý mô hình hóa 41 2.5.2 Sơ đồ phân rã chức năng 41 2.5.3 Sơ đồ luồng dữ liệu 42 2.5.4 Mô hình bản mẫu (protoype) 42 2.5.5 Mô hình hướng đối tượng 42 2.5.6 Đặc tả yêu cầu 44 2.5.7 Thẩm định yêu cầu 44 2.5.8 Định dạng đặc tả yêu cầu 45 Chương 3 THIẾT KẾ PHẦN MỀM 49 3.1 Tổng quan về thiết kế phần mềm 49 3.1.1 Khái niệm 49 3.1.2 Tầm quan trọng 49 3.1.3 Quá trình thiết kế 50 Tài liệu giảng dạy môn: Công nghệ phần mềm ii
3.1.4 Các hoạt động thiết kế chính trong một hệ thống phần mềm lớn 51 3.1.5 Cơ sở của thiết kế 51 3.1.6 Mô tả thiết kế 52 3.1.7 Chất lượng thiết kế 54 3.2 Kỹ thuật thiết kế 56 3.2.1 Thiết kế trên xuống (Top-down) 56 3.2.2 Thiết kế từ dưới lên (Bottom–up) 57 3.2.3 Thiết kế hệ thống 57 3.2.4 Thiết kế bản mẫu (prototype) 57 3.2.5 Phân rã thiết kế 57 3.2.6 Phương pháp phân loại phân rã 57 3.3 Thiết kế dữ liệu 62 3.3.1 Cách tiếp cận hướng đối tượng 62 3.3.2 Ba đặc trưng của thiết kế hướng đối tượng 62 3.3.3 Cơ sở của thiết kế hướng đối tượng 63 3.3.4 Các bước thiết kế 64 3.3.5 Ưu nhược điểm của thiết kế hướng đối tượng 64 3.3.6 Quan hệ giữa thiết kế và lập trình hướng đối tượng 65 3.3.7 Quan hệ giữa thiết kế hướng đối tượng và hướng chức năng 65 3.4 Thiết kế giao diện người sử dụng 65 3.4.1 Một số vấn đề thiết kế 68 3.4.2 Một số hướng dẫn thiết kế 68 3.4.3 Kết quả thiết kế 69 3.4.4 Phân loại màn hình giao diện 70 3.4.5 Quá trình thiết kế 71 Chương 4 LẬP TRÌNH 79 4.1 Ngôn ngữ lập trình 79 4.1.1 Đặc trưng của ngôn ngữ lập trình 79 4.1.2 Lựa chọn ngôn ngữ lập trình 81 4.1.3 Môi trường lập trình 81 4.1.4 Chất lượng đòi hỏi cho một ngôn ngữ lập trình 82 4.1.5 Khả năng Module hóa của ngôn ngữ lập trình 82 4.1.6 Ngôn ngữ lập trình và sự ảnh hưởng tới công nghệ phần mềm 82 4.2 Phong cách lập trình 83 Tài liệu giảng dạy môn: Công nghệ phần mềm iii
4.2.1 Tài liệu chương trình 83 4.2.2 Khai báo dữ liệu 84 4.2.3 Xây dựng câu lệnh 84 4.2.4 Vào/ra 85 4.2.5 Các yếu tố quan trọng nhất của phong cách lập trình tốt 85 4.3 Lập trình tránh lỗi 86 4.3.1 Lập trình thứ lỗi 87 4.3.2 Lập trình phòng thủ 88 4.4 Lập trình hướng hiệu quả thực hiện 89 4.4.1 Tính hiệu quả chương trình 89 4.4.2 Hiệu quả bộ nhớ 89 4.4.3 Hiệu quả vào/ra 89 4.4 Đánh giá chất lượng công việc 90 4.4.1 Hiện thực tăng cường 90 4.4.2 Đánh giá lại thiết kế và chương trình 91 Chương 5 XÁC MINH VÀ THẨM ĐỊNH 93 5.1 Đại cương 93 5.2 Khái niệm về phép thử 95 5.3 Kiểm thử chức năng và kiểm thử cấu trúc 95 5.3.1 Kiểm thử hộp đen - Kiểm thử chức năng 95 5.3.2 Kiểm thử hộp trắng - Kiểm thử cấu trúc 98 5.3.3 Kiểm thử dựa trên đặc điểm kỹ thuật 99 5.3.4 Kiểm thử trực quan 99 5.4 Quá trình kiểm thử 100 5.5 Chiến lược kiểm thử 103 5.5.1 Kiểm thử dưới lên 103 5.5.2 Kiểm thử trên xuống 103 5.5.3 Một chu kỳ kiểm thử mẫu 103 5.5.4 Đảm bảo chất lượng phần mềm 104 Chương 6 SƯU LIỆU PHẦN MỀM 106 6.1 Tổng quan 106 6.2 Sưu liệu người dùng 106 6.2.1 Mô tả chức năng 107 6.2.2 Bảng Giới thiệu 107 Tài liệu giảng dạy môn: Công nghệ phần mềm iv
6.2.3 Bảng tham khảo 107 6.2.4 Sưu liệu cài đặt 107 6.3 Sưu liệu hệ thống 108 6.4 Chất lượng của sưu liệu 109 6.5 Bảo trì sưu liệu 109 Chương 7 QUẢN LÝ DỰ ÁN PHẦN MỀM 111 7.1 Khái niệm dự án, dự án CNTT 111 7.1.1 Khái niệm dự án 111 7.1.2 Dự án Công nghệ thông tin 112 7.1.3 Đặc trưng của một dự án 112 7.1.4 Mục tiêu của dự án 112 7.2 Quy trình quản lý dự án 112 7.2.1 Khởi tạo dự án 113 7.2.2 Lập kế hoạch dự án 113 7.2.3 Triển khai 113 7.2.4 Giám sát và kiểm soát 113 7.2.5 Kết thúc 113 7.2.6 Các hoạt động chính trong quản lý dự án phần mềm 113 7.2.7 Mục đích của quản lý dự án 115 7.2.8 Phương pháp luận và kỹ thuật quản lý dự án 116 7.2.9 Nguyên nhân khiến dự án thất bại 116 7.3 Các nhiệm vụ trong các hoạt động QLDA. 118 7.3.1 Quản lý thời gian của dự án 118 7.3.2 Quản lý kinh phí của dự án 118 7.3.3 Quản lý nguồn nhân lực của dự án 118 7.3.4 Quản lý các kết quả chuyển giao của dự án 118 7.4 Phân loại dự án 118 7.5 Ước lượng 119 7.6 Quản lý nhân sự 120 7.7 Quản lý cấu hình 121 7.8 Quản lý rủi ro 122 Tài liệu giảng dạy môn: Công nghệ phần mềm v
Chương 1 PHẦN MỀM VÀ CÔNG NGHỆ PHẦN MỀM  Mục tiêu học tập: Sau khi học xong chương này người có thể: - Trình bày tổng quan về phần mềm và công nghệ phần mềm - Vận dụng các qui trình vào xây dựng các dự án phần mềm Tóm tắt chương Trong chương này, tài liệu sẽ cung cấp cho sinh viên một số khái niệm liên quan đến việc xây dựng một phần mềm. Đồng thời còn cung cấp cho sinh viên biết cách chọn lựa những giải pháp với chi phí hợp lý cho các bài toán thực tế bằng cách áp dụng kiến thức về công nghệ để xây dựng những hệ thống phần mềm có chất lượng 1.1 Phần mềm máy tính 1.1.1 Khái niệm Phần mềm máy tính (Computer Software) hay gọi tắt là Phần mềm (Software) là một tập hợp những câu lệnh hoặc chỉ thị được viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải quyết một vấn đề cụ thể nào đó. Phần mềm thực hiện các chức năng của nó bằng cách gửi các chỉ thị trực tiếp đến phần cứng máy tính (Computer Hardware) hoặc bằng cách cung cấp dữ liệu để phục vụ các chương trình hay phần mềm khác. Một phần mềm mới có thể được tạo ra bằng cách phát triển các chương trình mới, thay đổi và điều chỉnh hoặc tái sử dụng lại các phần mềm đã tồn tại. 1.1.2 Đặc điểm Trước đây, để tạo ra chương trình máy tính người ta phải làm việc trực tiếp với các con số 0 hoặc 1 (sử dụng hệ số nhị phân), hay còn gọi là ngôn ngữ máy. Công việc này vô cùng khó khăn, mất nhiều thời gian, công sức và đặc biệt dễ gây ra lỗi. Để khắc phục nhược điểm này, người ta đề xuất ra hợp ngữ, một ngôn ngữ cho phép thay thế dãy 0 hoặc 1 này bởi các từ gợi nhớ bằng tiếng Anh. Tuy nhiên, cải tiến này vẫn còn chưa thật sự thích hợp với đa số người dùng máy tính, những người luôn mong muốn các lệnh chính là ý nghĩa của các thao tác mà nó mô tả. Vì vậy, ngay từ những năm của thập niên 50, người ta đã xây dựng những ngôn ngữ lập trình mà câu lệnh của nó gần với ngôn ngữ tự nhiên. Các ngôn ngữ này được gọi là ngôn ngữ lập trình bậc cao. Chương trình máy tính thường được tạo ra bởi con người, những người này được gọi là Tài liệu giảng dạy môn: Công nghệ phần mềm 1
lập trình viên, tuy nhiên cũng tồn tại những chương trình được sinh ra bởi các chương trình khác. 1.1.3 Phân loại a. Theo phương thức hoạt động Phần mềm hệ thống: Dùng để vận hành máy tính và các phần cứng máy tính, ví dụ như các hệ điều hành máy tính Windows, Linux, Unix, các thư viện động hay còn gọi là thư viện liên kết động (Dynamic Linked Library - DLL) của hệ điều hành, các trình điều khiển (Driver), phần sụn (Firmware) và hệ thống xuất nhập cơ bản (Basic Input/Output System - BIOS). Đây là các loại phần mềm mà hệ điều hành liên lạc với chúng để điều khiển và quản lý các thiết bị phần cứng. Phần mềm ứng dụng: Dùng để người sử dụng có thể hoàn thành một hay nhiều công việc nào đó, ví dụ như các phần mềm hỗ trợ công tác văn phòng (Microsoft Office, OpenOffice ), phần mềm doanh nghiệp, phần mềm quản lý nguồn nhân lực, phần mềm giáo dục, cơ sở dữ liệu, phần mềm trò chơi, chương trình tiện ích, hay các loại phần mềm độc hại. Các phần mềm dịch mã: Bao gồm trình biên dịch và trình thông dịch: các loại chương trình này sẽ đọc các câu lệnh từ mã nguồn được viết bởi các lập trình viên theo một ngôn ngữ lập trình và dịch nó sang dạng ngôn ngữ máy mà máy tính có thể hiểu đươc, hay dịch nó sang một dạng khác như là tập tin đối tượng (object file) và các tập tin thư viện (library file) mà các phần mềm khác (như hệ điều hành chẳng hạn) có thể hiểu để vận hành máy tính thực thi các lệnh. b. Theo khả năng ứng dụng Những phần mềm không phụ thuộc: Nó có thể được bán cho bất kỳ khách hàng nào trên thị trường tự do. Ví dụ: phần mềm về cơ sở dữ liệu như Oracle, Phtoshop, Corel Draw, MS Office Ưu điểm: Thông thường đây là những phần mềm có khả năng ứng dụng rộng rãi cho nhiều nhóm người sử dụng. Hạn chế: Thiếu tính uyển chuyển, tùy biến. Những phần mềm được viết theo đơn đặt hàng: Đây là dạng phần mềm được thực hiện theo đơn đặt hàng hay hợp đồng của một khách hàng cụ thể nào đó (một công ty, bệnh viện, trường học ). Ưu điểm: Có tính uyển chuyển, tùy biến cao để đáp ứng được nhu cầu của một nhóm người sử dụng nào đó. Hạn chế: Thông thường đây là những phần mềm ứng dụng cho một chuyên ngành hẹp. Tài liệu giảng dạy môn: Công nghệ phần mềm 2
c. Các loại khác Cũng là một loại phần mềm, nhưng virus máy tính là các phần mềm có hại được viết để chạy với những mục đích riêng của một nhóm người nhằm lừa đảo, quảng cáo, ăn cắp, phá hoại thông tin, phá hoại phần cứng hoặc chỉ là để trêu chọc người dùng. 1.1.4 Kiến trúc phần mềm Sau khi đã có các khái niệm cơ bản nhất về phần mềm, tiếp sau đây chúng ta sẽ đi sâu vào tìm hiểu cấu trúc chi tiết các thành phần bên trong phần mềm. Phần mềm bao gồm 3 thành phần chính: a. Thành phần giao tiếp (giao diện) Cho phép tiếp nhận các yêu cầu về việc muốn thực hiện và cung cấp các dữ liệu nguồn liên quan đến công việc đó hoặc từ các thiết bị thu thập dữ liệu. Cho phép trình bày các kết quả của việc thực hiện các yêu cầu cho người dùng (kết quả của công việc khi thực hiện trên máy tính) hoặc điều khiển họat động các thiết bị điều khiển. Một cách tổng quát, thành phần giao tiếp là hệ thống các hàm chuyên về việc nhập/xuất dữ liệu (hàm nhập/xuất) cùng với hình thức trình bày và tổ chức lưu trữ dữ liệu tương ứng, mục tiêu chính của các hàm này là đưa dữ liệu từ thế giới bên ngoài phần mềm vào bên trong hoặc ngược lại. Trong tài liệu này chỉ giới hạn xét đến giao tiếp với người sử dụng phần mềm và khi đó có tên gọi cụ thể hơn là thành phần giao diện. b. Thành phần dữ liệu Cho phép lưu trữ lại (hàm ghi) các kết quả đã xử lý trên bộ nhớ phụ với tổ chức lưu trữ được xác định trước (tập tin có cấu trúc, tập tin nhị phân, cơ sở dữ liệu). Cho phép truy xuất lại (hàm đọc) các dữ liệu đã lưu trữ phục vụ cho các hàm xử lý tương ứng. Một cách tổng quát thành phần dữ liệu là hệ thống các hàm chuyên về đọc ghi dữ liệu (hàm đọc/ghi) cùng với mô hình tổ chức dữ liệu tương ứng. Mục tiêu chính của các hàm này là chuyển đổi dữ liệu giữa bộ nhớ chính và bộ nhớ phụ. c. Thành phần xử lý Kiểm tra tính hợp lệ của các dữ liệu nguồn được cung cấp từ người dùng theo các qui trình ràng buộc trong thế giới thực. Tiến hành xử lý cho ra kết quả mong đợi theo qui định tính toán có sẵn trong thế giới thực hoặc theo thuật toán đã tự đề xuất. Việc xử lý dựa trên dữ liệu nguồn từ người sử dụng cung cấp hoặc dữ liệu lưu trữ đã có sẵn hoặc cả hai tùy vào xử lý cụ thể. Tương tự, việc xử lý cho ra kết quả có thể dùng để xuất cho người dùng xem qua thành phần giao diện, hay cũng Tài liệu giảng dạy môn: Công nghệ phần mềm 3
có thể lưu trữ lại qua thành phần dữ lịêu. Một cách tổng quát, thành phần xử lý là hệ thống các hàm chuyên về xử lý tính toán, biến đổi dữ liệu. Các hàm này sẽ dùng dữ liệu nguồn từ các hàm trong thành phần giao diện (hàm nhập) hay thành phần dữ liệu (hàm đọc dữ liệu) kiểm tra tính hợp lệ (hàm kiểm tra) và sau đó tiến hành xử lý (hàm xử lý) nếu cần thiết để cho ra kết quả mà sẽ được trình bày cho người dùng xem qua các hàm trong thành phần giao diện (hàm xuất) hoặc lưu trữ lại qua các hàm trong thành phần dữ liệu (hàm ghi). 1.1.5 Quá trình tạo phần mềm a. Về mặt thiết kế Tùy theo mức độ phức tạp của phần mềm, người thiết kế phần mềm sẽ ít nhiều dùng đến các phương tiện để tạo ra mẫu thiết kế theo ý muốn (chẳng hạn như là các sơ đồ khối, các lưu đồ, các thuật toán và các mã giả), sau đó mẫu này được mã hoá bằng các ngôn ngữ lập trình và được các trình dịch chuyển thành các khối lệnh (module) hay/và các tệp khả thi. Tập hợp các tệp khả thi và các khối lệnh đó tạo thành một phần mềm. Thường khi một phần mềm được tạo thành, để cho hoàn hảo thì phần mềm đó phải được điều chỉnh hay sửa chữa từ khâu thiết kế cho đến khâu tạo thành phiên bản phần mềm một số lần. Một phần mềm thông thường sẽ tương thích với một hay vài hệ điều hành, tùy theo cách thiết kế, cách viết mã nguồn và ngôn ngữ lập trình được dùng. b. Sản xuất và phát triển Việc phát triển và đưa ra thị trường một phần mềm là đối tượng nghiên cứu của bộ môn kỹ nghệ phần mềm hay còn gọi là công nghệ phần mềm (Software Engineering). Bộ môn này nghiên cứu các phương pháp tổ chức, cách thức sử dụng nguồn tài nguyên, qui trình sản xuất, cùng với các mối liên hệ với thị trường, cũng như liên hệ giữa các yếu tố này với nhau. Tối ưu hoá qui trình sản xuất phần mềm cũng là đối tượng được ưu tiên xem xét của bộ môn. 1.2 Công nghệ phần mềm 1.2.1 Lịch sử ra đời Vào những năm 1950, khi máy tính ra đời chính thức (không chỉ được dùng trong các phòng thí nghiệm mà bắt đầu ứng dụng trong họat động xã hội) các phần mềm đầu tiên cũng được ra đời với số lượng còn rất ít và chủ yếu phục vụ cho lĩnh vực tính toán (đặc biệt trong quốc phòng). Đến những năm 1960, trãi qua 10 năm phát triển số lượng các phần mềm đã tăng lên rất nhiều và được ứng dụng rộng rãi trong nhiều lĩnh vực. Vào thời điểm này phát sinh một vấn đề mà các chuyên gia gọi là “cuộc khủng hoảng phần mềm”. Cuộc khủng hoảng phần mềm Tài liệu giảng dạy môn: Công nghệ phần mềm 4
thể hiện 2 yếu tố chính: - Số lượng các phần mềm tăng vọt (do sự phát triển của phần cứng: tăng khả năng, giá thành hạ) - Có quá nhiều hạn chế trong các phần mềm được dùng trong xã hội + Thực hiện không đúng yêu cầu (tính toán sai, không ổn định ) + Thời gian bảo trì, nâng cấp quá lâu, tốn chi phí cao, hiệu quả thấp. + Khó sử dụng + Thực hiện chậm + Khó chuyển đổi dữ liệu giữa các phần mềm - Việc tăng vọt của số lượng phần mềm là điều hợp lý và điều này sẽ còn tiếp diễn. - Các hạn chế của phần mềm có nguồn gốc chính từ phương pháp, cách thức tiến hành xây dựng phần mềm: + Cảm tính: Mỗi người theo một phương pháp riêng. + Thô sơ, đơn giản: Chỉ tập trung vào việc lập trình mà ít quan tâm đến các công việc cần làm khác trước khi lập trình (khảo sát hiện trạng, phân tích yêu cầu, thiết kế ). + Thủ công: Công cụ hỗ trợ chính khi xây dựng phần mềm chỉ là trình biên dịch. Với các kết luận như trên, hội nghị đã đề xuất khai sinh một ngành khoa học mới đó là Công nghệ phần mềm với nhiệm vụ chính là nghiên cứu về các phương pháp tiến hành xây dựng phần mềm. 1.2.2 Định nghĩa 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 phục vụ cho việc thiết kế, cài đặt các sản phấm phần mềm đạt được đầy đủ các yêu cầu về chất lượng phần mềm. Do quá trình tiến hóa của ngành công nghệ phần mềm nên các khái niệm về nó cũng thay đổi theo thời gian. Hơn nữa nó là một lĩnh vực mới nên phụ thuộc rất nhiều vào quan điểm chủ quan của mỗi người khác nhau: - Bauer (1969) Việc thiết lập và sử dụng các nguyên lý công nghệ đúng đắn để thu được phần mềm một cách kinh tế vừa tin cậy vừa hiệu quả trên các máy thực. - Ghezzi (1991) Là một lĩnh vực của khoa học máy tính liên quan đến việc xây dựng các phần mềm vừa lớn vừa phức tạp bởi một hay một nhóm kỹ sư. - IEEE (1993) Việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và lượng hóa trong phát triển, vận hành và bảo trì phần mềm. - Sommervile (1995) Là lĩnh vực liên quan đến lý thuyết, phương pháp và công cụ dùng cho phát triển phần mềm. Tài liệu giảng dạy môn: Công nghệ phần mềm 5
- Pressman (1995) Là bộ môn tích hợp cả qui trình, các phương pháp, các công cụ để phát triển phần mềm máy tính. Có thể định nghĩa tóm tắt về công nghệ phần mềm như sau: “công nghệ phần mềm là một ngành khoa học nghiên cứu về việc xây dựng các phần mềm có chất lượng trong khoảng thời gian và chi phí hợp lý”. 1.2.3 Mục tiêu nghiên cứu Mục tiêu nghiên cứu của Công nghệ phần mềm là tìm ra phương pháp, công cụ nhằm xây dựng phần mềm có chất lượng, trong thời gian và chi phí hợp lý. Công nghệ phần mềm là một quá trình gồm một loạt các bước chứa đựng 3 yếu tố chủ chốt: - Phương pháp - Công cụ - Thủ tục Các yếu tố này giúp người quản lý kiểm soát được tiến trình phát triển phần mềm, cung cấp cho người kỹ sư phần mềm một nền tảng để xây dựng phần mềm chất lượng cao theo một cách thức hiệu quả, trong những giới hạn nhất định. a. Các phương pháp Chỉ ra cách làm về mặt kỹ thuật để xây dựng phần mềm, được sử dụng trong các bước: Lập kế hoạch, ước lượng dự án, phân tích yêu cầu hệ thống và phần mềm, thiết kế cấu trúc dữ liệu, kiến trúc chương trình các thủ tục và thuật toán, mã hóa, kiểm thử và bảo trì Các phương pháp cho công nghệ phần mềm thường dùng các ký pháp đồ họa hay hướng ngôn ngữ đặc biệt, cách thức thực hiện và một tập các tiêu chuẩn về chất lượng của sản phẩm phần mềm. b. Các công cụ Cung cấp sự hỗ trợ tự động hay bán tự động để phát triển phần mềm theo từng phương pháp khác nhau. Khi các công cụ được tích hợp đến mức các thông tin do chúng tạo ra có thể được dùng cho các công cụ khác thì hệ thống hỗ trợ phát triển phần mềm đã được thiết lập và còn được gọi là công nghệ phần mềm có máy tính hỗ trợ (CASE - Computer Aided Software Engineering). c. Các thủ tục Các thủ tục là sự kết nối các phương pháp và công cụ lại với nhau làm cho chúng được sử dụng hợp lý và đúng hạn trong quá trình phát triển phần mềm. Các thủ tục bao gồm: - Xác định trình tự các phương pháp sẽ được áp dụng cho mỗi dự án. - Tạo ra sản phẩm cần bàn giao (tài liệu báo cáo, bản mẫu, ) cần cho việc kiểm soát để Tài liệu giảng dạy môn: Công nghệ phần mềm 6
đảm bảo chất lượng và điều hòa thay đổi. - Xác định những cột mốc mà tại thời điểm đó có các sản phẩm nhất định được bàn giao để cho người quản lý phần mềm nắm được tiến độ và kiểm soát được kết quả. 1.2.4 Đối tượng nghiên cứu Hướng đến việc xây dựng các phần mềm có chất lượng như đã nêu, ngành công nghệ phần mềm đưa ra 3 đối tượng nghiên cứu chính: Qui trình công nghệ, Phương pháp phát triển, Công cụ và môi trường phát triển phần mềm. - Qui trình công nghệ phần mềm: Hệ thống các giai đoạn mà quá trình phát triển phần mềm phải trải qua. Với mỗi giai đoạn cần xác định rõ mục tiêu, kết quả nhận được từ giai đoạn trước đó cũng chính là kết quả chuyển giao cho giai đoạn kế tiếp. - Phương pháp phát triển phần mềm: Hệ thống các hướng dẫn cho phép từng bước thực hiện một giai đoạn nào đó trong qui trình công nghệ phần mềm. - Công cụ và môi trường phát triển phần mềm: Hệ thống các phần mềm trợ giúp chính trong lĩnh vực xây dựng phần mềm. Các phần mềm này sẽ hỗ trợ các kỹ sư tin học trong các bước xây dựng phần mềm theo một phương pháp nào đó với một qui trình được chọn trước. 1.3 Qui trình phát triển phần mềm Để xây dựng được phần mềm có chất lượng quá trình phát triển phải trãi qua rất nhiều giai đoạn. Mỗi giai đoạn có mục tiêu và kết quả chuyển giao xác định. Trình tự thực hiện các giai đoạn này chính là chu kỳ sống của một phần mềm. Nói cách khác, chu kỳ sống của một phần mềm là khoảng thời gian mà trong đó một sản phẩm phần mềm được phát triển, sử dụng và mở rộng cho đến khi sản phẩm phần mềm đó không còn được sử dụng nữa. Chu kỳ sống của phần mềm được phân chia được phân chia thành các pha chính như: Xác định, phát triển, kiểm thử, bảo trì (vận hành). Phạm vi và thứ tự các pha khác nhau tùy theo từng mô hình cụ thể. Có nhiều mô hình tiếp cận khác nhau để triển khai các bước cơ bản trong quá trình phát triển phần mềm. Mỗi mô hình sẽ chia vòng đời của phần mềm theo một cách khác nhau nhằm đảm bảo qui trình phát triển phần mềm sẽ dẫn đến thành công. Sau đây, chúng ta sẽ xem xét một số cách tiếp cận (còn gọi là mô hình hay khuôn cảnh) cơ bản trong tiến trình phát triển phần mềm. 1.3.1 Mô hình vòng đời cổ điển (mô hình thác nước) (Waterfall Model) Vào năm 1970 trong bài báo của mình, Royce đã mô tả ở dạng khái niệm cái mà ngày nay được công nhận với tên gọi “mô hình thác nước”. Mô hình thác nước là một trong những mô hình đầu tiên và phổ biến được áp dụng trong quá trình phát triển phần mềm. Mô hình này Tài liệu giảng dạy môn: Công nghệ phần mềm 7
chia quá trình phát triển phần mềm thành những giai đoạn tuần tự nối tiếp nhau. Qui trình phát triển này giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt. Mỗi giai đoạn sẽ có một mục đích nhất định. Kết quả cuả giai đoạn trước sẽ là thông tin đầu vào cho giai đoạn tiếp theo. Tùy theo qui mô của phần mềm cần phát triển mà mô hình thác nước sẽ có những biến thể khác nhau như sau: * Qui trình 2 giai đoạn: Là qui trình đơn giản nhất. Theo qui trình này việc phát triển phần mềm chỉ trãi qua 2 giai đoạn: i) Xác định yêu cầu: Được tiến hành ngay khi có yêu cầu về việc xây dựng phần mềm. + Mục tiêu: Xác định chính xác các yêu cầu đặt ra cho phần mềm sẽ xây dựng. + Kết quả nhận: Thông tin về hoạt động của thế giới thực. + Kết quả chuyển giao: Danh sách các yêu cầu (công việc sẽ thực hiện trên máy tính) cùng với các thông tin miêu tả chi tiết về các yêu cầu (cách thức thực hiện trong thế giới thực). ii) Lập trình (cài đặt): Được tiến hành ngay sau khi kết thúc việc xác định yêu cầu. + Mục tiêu: Tạo lập phần mềm mong muốn theo yêu cầu. + Kết quả nhận: Danh sách các yêu cầu cùng các thông tin có liên quan. + Kết quả chuyển giao: Chương trình nguồn của phần mềm với cấu trúc cơ sở dữ liệu tương ứng (nếu cần thiết) và chương trình thực hiện được trên máy tính (chương trình nguồn đã được biên dịch) * Qui trình 3 giai đoạn: Là qui trình cải tiến của qui trình 2 giai đoạn bằng cách bổ sung thêm một giai đoạn trung gian mới giữa xác định yêu cầu và lập trình (có sửa đổi) i) Xác định yêu cầu: Được tiến hành ngay khi có yêu cầu về việc xây dựng phần mềm. + Mục tiêu: Xác định chính xác các yêu cầu đặt ra cho phần mềm sẽ xây dựng. + Kết quả nhận: Thông tin về hoạt động của thế giới thực. + Kết quả chuyển giao: Danh sách các yêu cầu (công việc sẽ thực hiện trên máy tính) cùng với các thông tin miêu tả chi tiết về các yêu cầu (cách thức thực hiện trong thế giới thực) ii) Thiết kế: Được tiến hành ngay sau khi kết thúc việc xác định yêu cầu + Mục tiêu: Mô tả các thành phần của phần mềm (mô hình của phần mềm) trước khi tiến hành cài đặt. + Kết quả nhận: Danh sách các yêu cầu và thông tin liên quan. + Kết quả chuyển giao: Mô tả thành phần giao diện: Các hàm nhập/xuất, cấu trúc dữ liệu nhập/xuất. Mô tả thành phần xử lý: Các hàm kiểm tra xử lý. Mô tả thành phần dữ liệu: Các hàm đọc/ ghi, tổ chức lưu trữ trên bộ nhớ phụ. Tài liệu giảng dạy môn: Công nghệ phần mềm 8
iii) Lập trình (cài đặt): Được tiến hành ngay sau khi kết thúc việc thiết kế. + Mục tiêu: Tạo lập phần mềm theo yêu cầu. + Kết quả nhận: Mô hình phần mềm + Kết quả chuyển giao: Chương trình nguồn của phần mềm với cấu trúc cơ sở dữ liệu tương ứng (nếu cần thiết) và chương trình thực hiện được trên máy tính (chương trình nguồn đã được biên dịch) * Qui trình 4 giai đoạn: Là qui trình cải tiến của qui trình phía trước bằng cách bổ sung thêm một giai đoạn mới giữa xác định yêu cầu và thiết kế (có sửa đổi) i) Xác định yêu cầu: Được tiến hành ngay khi có yêu cầu về việc xây dựng phần mềm. + Mục tiêu: Xác định chính xác các yêu cầu đặt ra cho phần mềm sẽ xây dựng. + Kết quả nhận: Thông tin về hoạt động của thế giới thực. + Kết quả chuyển giao: Danh sách các yêu cầu (công việc sẽ thực hiện trên máy tính) cùng với các thông tin miêu tả chi tiết về các yêu cầu (cách thức thực hiện trong thế giới thực) ii) Phân tích: Được tiến hành ngay sau khi kết thúc việc xác định yêu cầu. + Mục tiêu: Mô tả lại thế giới thực thông qua các mô hình (mô hình thế giới thực) trước khi thiết kế. + Kết quả nhận: Danh sách các yêu cầu cùng các thông tin có liên quan. + Kết quả chuyển giao: Mô hình xử lý (hệ thống các công việc trong thế giới thực cùng với quan hệ giữa chúng) Mô hình dữ liệu (hệ thống các loại thông tin được sử dụng trong thế giới thực cùng với quan hệ giữa chúng) Các mô hình khác (không gian, thời gian, con người ) nếu cần thiết. iii) Thiết kế: Được tiến hành ngay sau khi kết thúc việc phân tích. + Mục tiêu: Mô tả các thành phần của phần mềm (mô hình của phần mềm) trước khi tiến hành cài đặt. + Kết quả nhận: Mô hình thế giới thực. + Kết quả chuyển giao: Mô tả thành phần giao diện: Các hàm nhập/xuất, cấu trúc dữ liệu nhập/xuất. Mô tả thành phần xử lý: Các hàm kiểm tra xử lý. Mô tả thành phần dữ liệu: Các hàm đọc/ghi, tổ chức lưu trữ trên bộ nhớ phụ. iv) Lập trình (cài đặt): Được tiến hành ngay sau khi kết thúc việc thiết kế. + Mục tiêu: Tạo lập phần mềm theo yêu cầu + Kết quả nhận: Mô hình phần mềm Tài liệu giảng dạy môn: Công nghệ phần mềm 9
+ Kết quả chuyển giao: Chương trình nguồn của phần mềm với cấu trúc cơ sở dữ liệu tương ứng (nếu cần thiết) và chương trình thực hiện được trên máy tính (chương trình nguồn đã được biên dịch) * Qui trình 5 giai đoạn: Qui trình này gộp giai đoạn xác định và phân tích thành 1 giai đoạn. Cải tiến lại qui trình phía trước bằng cách bổ sung thêm một giai đoạn mới sau giai đoạn lập trình nhằm tăng cường độ tin cậy của phần mềm. i) Xác định yêu cầu: Được tiến hành ngay khi có nhu cầu về việc xây dựng phần mềm. + Mục tiêu: Xác định chính xác các yêu cầu đặt ra cho phần mềm sẽ xây dựng. + Kết quả nhận: Thông tin về hoạt động của thế giới thực. + Kết quả chuyển giao: Danh sách các yêu cầu (công việc sẽ thực hiện trên máy tính) cùng với các thông tin miêu tả chi tiết về các yêu cầu (cách thức thực hiện trong thế giới thực) ii) Phân tích: Được tiến hành ngay sau khi kết thúc việc xác định yêu cầu. + Mục tiêu: Mô tả lại thế giới thực thông qua các mô hình (mô hình thế giới thực) trước khi thiết kế. + Kết quả nhận: Danh sách các yêu cầu cùng các thông tin có liên quan. + Kết quả chuyển giao: Mô hình xử lý (hệ thống các công việc trong thế giới thực cùng với quan hệ giữa chúng) Mô hình dữ liệu (hệ thống các loại thông tin được sử dụng trong thế giới thực cùng với quan hệ giữa chúng) Các mô hình khác (không gian, thời gian, con người ) nếu cần thiết. iii) Thiết kế: Được tiến hành ngay sau khi kết thúc việc phân tích. + Mục tiêu: Mô tả các thành phần của phần mềm (mô hình của phần mềm) trước khi tiến hành cài đặt. + Kết quả nhận: Mô hình thế giới thực. + Kết quả chuyển giao: Mô tả thành phần giao diện: Các hàm nhập/xuất, cấu trúc dữ liệu nhập/xuất. Mô tả thành phần xử lý: Các hàm kiểm tra xử lý. Mô tả thành phần dữ liệu: Các hàm đọc/ ghi, tổ chức lưu trữ trên bộ nhớ phụ. iv)Lập trình (cài đặt): Được tiến hành ngay sau khi kết thúc việc thiết kế. + Mục tiêu: Tạo lập phần mềm theo yêu cầu. + Kết quả nhận: Mô hình phần mềm. + Kết quả chuyển giao: Chương trình nguồn của phần mềm với cấu trúc cơ sở dữ liệu tương ứng (nếu cần thiết) và chương trình thực hiện được trên máy tính (chương trình nguồn Tài liệu giảng dạy môn: Công nghệ phần mềm 10
đã được biên dịch). v)Kiểm thử: Được tiến hành ngay sau khi đã có kết quả (từng phần) của việc lập trình. + Mục tiêu: Tăng độ tin cậy của phần mềm. + Kết quả nhận: Danh sách yêu cầu. Mô hình phần mềm. Phần mềm. + Kết quả chuyển giao: Phần mềm với độ tin cậy cao (đã tìm và sửa lỗi). vi) Bảo trì và phát triển: Công việc của giai đoạn bao gồm việc cài đặt và vận hành phần mềm trong thực tế. + Mục tiêu: Đảm bảo phần mềm vận hành tốt. + Kết quả nhận: Phần mềm đã hoàn thành. + Kết quả chuyển giao: Các phản ánh của khách hàng trong quá trình sử dụng phần mềm. Phân tích Thiết kế Mã hóa Kiểm thử Bảo trì và phát triển Hình 1.1: Mô hình thác nước (vòng đời cổ điển). * Nhận xét: Mô hình thác nước giúp chúng ta có thể dễ dàng phân chia quá trình xây dựng phần mềm thành những giai đoạn hoàn toàn độc lập nhau. Tuy nhiên, các dự án lớn hiếm khi tuân theo dòng chảy tuần tự của mô hình vì thường phải lặp lại các bước để nâng cao chất lượng. Hơn nữa, khách hàng hiếm khi phát biểu hết các yêu cầu trong giai đoạn phân tích. Mô hình này cũng có một hạn chế là chúng ta rất khó thực hiện các thay đổi một khi đã thực hiện xong một giại đoạn nào đó. Điều này làm cho việc xây dựng phần mềm rất khó thay đổi các yêu cầu theo ý muốn của khách hàng. Do đó, phương pháp này chỉ thích hợp cho những trường hợp mà chúng ta đã hiểu rất rõ các yêu cầu của khách hàng. Tài liệu giảng dạy môn: Công nghệ phần mềm 11
Chú ý: Mô hình thác nước có thể được cải tiến bằng cách cho phép quay lui khi phát hiện lỗi trong giai đoạn phía trước. Tuy nhiên, càng đến giai đoạn cuối mà phát hiện lỗi xuất phát từ những giai đoạn đầu thì chi phí và thời gian khắc phục, sửa đổi rất tốn kém. Chính vì vậy, chúng ta cần thực hiện chính xác, đầy đủ từ giai đoạn đầu. 1.3.2 Mô hình làm bản mẫu (Prototype) Cách tiếp cận làm bản mẫu là cách tiếp cận tốt nhất khi: - Mục tiêu tổng quát cho phần mềm đã xác định, nhưng chưa xác định được rõ được đầu vào (Input) và đầu ra (Output). - Người phát triển chưa chắc chắn về hiệu quả của thuật toán, về tính thích nghi với hệ điều hành hay giao diện người - máy cần có. Khi đã có bản mẫu, người phát triển có thể dùng chương trình đã có hay các công cụ phần mềm trợ giúp để sinh ra chương trình làm việc. Làm bản mẫu là tạo ra một mô hình cho phần mềm cần xây dựng. Mô hình có thể có 3 dạng: 1. Bản mẫu trên giấy hay trên máy tính, mô tả giao diện người-máy nhằm mục đích làm cho người dùng hiểu được cách các tương tác xuất hiện. 2. Bản mẫu cài đặt chỉ một tập con chức năng của phần mềm mong đợi. 3. Bản mẫu là một chương trình có thể thực hiện một phần hay tất cả chức năng mong muốn nhưng ở mức sơ lược và cần cải tiến thêm các tính năng khác tùy theo khả năng phát triển. Trước hết người phát triển và khách hàng gặp nhau và xác định mục tiêu tổng thể cho phần mềm, xác định các yêu cầu đã biết, các miền cần khảo sát thêm. Tiếp theo là giai đoạn thiết kế nhanh, tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng (input và output), và xây dựng một bản mẫu. Người dùng đánh giá và làm mịn các yêu cầu cho phần mềm. Tiến trình này lặp đi lặp lại cho đến khi bản mẫu thoả mãn yêu cầu của khách hàng, đồng thời giúp người phát triển hiểu kỹ hơn nhu cầu nào cần phải thực hiện (hình 1.2). Một biến thể của mô hình này là mô hình thăm dò, trong đó các yêu cầu được cập nhật liên tục và bản mẫu được tiến hóa liên tục để trở thành sản phẩm cuối cùng. Mô hình làm bản mẫu có một số vấn đề như: • Do sự hoàn thiện dần (tiến hóa) của bản mẫu, phần mềm nhiều khi có tính cấu trúc không cao, dẫn đến khó kiểm soát, khó bảo trì. • Khách hàng nhiều khi thất vọng với việc phát triển phần mềm do họ nhầm tưởng bản mẫu là sản phẩm cuối cùng hướng tới người sử dụng. Khách hàng cũng có thể không dành Tài liệu giảng dạy môn: Công nghệ phần mềm 12
nhiều thời gian và công sức vào việc đánh giá bản mẫu. Kết thúc Bắt đầu Sản phẩm Tổng hợp cuối cùng yêu cầu Thiết kế Làm mịn nhanh yêu cầu Xây dựng Đánh giá bản mẫu của khách hàng Hình 1.2: Mô hình làm bản mẫu. 1.3.3 Mô hình xoắn ốc Mô hình xoắn ốc được Boehm đưa ra năm 1988. Mô hình này đưa thêm vào việc phân tích yếu tố rủi ro. Quá trình phát triển được chia thành nhiều bước lặp lại, mỗi bước bắt đầu bằng việc phân tích rủi ro rồi tạo bản mẫu, cải tạo và phát triển bản mẫu, duyệt lại, và cứ thế tiếp tục (hình 1.3). Nội dung một bước gồm bốn hoạt động chính: - Lập kế hoạch: Xác định mục tiêu, các giải pháp và ràng buộc - Phân tích rủi ro: Phân tích các phương án và xác định/giải quyết rủi ro - Kỹ nghệ: Phát triển sản phẩm “mức tiếp theo” - Đánh giá: Đánh giá của khách hàng về kết quả của kỹ nghệ Với mỗi lần lặp xoắn ốc (bắt đầu từ tâm), các phiên bản được hoàn thiện dần. Nếu phân tích rủi ro chỉ ra rằng yêu cầu không chắc chắn thì bản mẫu có thể được sử dụng trong giai đoạn kỹ nghệ; các mô hình và các mô phỏng khác cũng được dùng để làm rõ hơn vấn đề và làm mịn yêu cầu. Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến quyết định “tiếp tục hay dừng”. Nếu rủi ro quá lớn thì có thể dừng dự án. Mô hình xoắn ốc cũng có một số vấn đề như khó thuyết phục những khách hàng lớn rằng cách tiếp cận tiến hóa là kiểm soát được. Nó đòi hỏi tri thức của chuyên gia đánh giá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạt được thành công. Mô hình xoắn ốc đòi hỏi năng lực quản lý cao, nếu không quản lý tốt thì rất dễ rơi vào trạng thái sửa đổi cục bộ Tài liệu giảng dạy môn: Công nghệ phần mềm 13
không có kế hoạch của mô hình làm bản mẫu (thăm dò). Hình 1.3: Mô hình xoắn ốc. 1.3.4 Kỹ thuật thế hệ thứ tư Thuật ngữ kỹ thuật thế hệ thứ tư (4GT - Fourth Generation Technology) bao gồm một phạm vi rộng các công cụ phần mềm, có các điểm chung sau: 1. Cho phép người phát triển xác định một số đặc trưng của phần mềm ở mức cao. 2. Tự động sinh ra mã chương trình gốc theo nhu cầu của người phát triển. Hiển nhiên là phần mềm được biểu diễn ở mức trừu tượng càng cao thì chương trình có thể được xây dựng càng nhanh hơn. Mô hình 4GT đối với kỹ nghệ phần mềm tập trung vào khả năng xác định phần mềm đối với một máy ở mức độ gần với ngôn ngữ tự nhiên hay dùng một ký pháp khác đem lại chức năng có ý nghĩa. Hiện tại, một môi trường phát triển phần mềm hỗ trợ cho khuôn cảnh 4GT bao gồm một số hay tất cả các công cụ sau: 1. Ngôn ngữ phi thủ tục để truy vấn cơ sở dữ liệu. 2. Bộ sinh báo cáo. 3. Bộ thao tác dữ liệu. 4. Bộ tương tác và xác định màn hình. 5. Bộ sinh chương trình. 6. Khả năng đồ họa mức cao. 7. Khả năng làm trang tính. 8. Khả năng tạo tài liệu. Tài liệu giảng dạy môn: Công nghệ phần mềm 14
Mỗi một trong những công cụ này đã tồn tại, nhưng chỉ cho vài lĩnh vực ứng dụng đặc thù. Ví dụ như các tính năng macro trong các phần mềm bảng tính, cơ sở dữ liệu, khả năng tự sinh mã trong các công cụ thiết kế giao diện “kéo - thả” Với những ứng dụng nhỏ, có thể chuyển trực tiếp từ bước thu thập yêu cầu sang cài đặt bằng công cụ 4GT. Tuy nhiên với những hệ thống lớn, cần phải có một chiến lược thiết kế. Việc dùng 4GT thiếu thiết kế (với các dự án lớn) sẽ gây ra những khó khăn như chất lượng kém, khó bảo trì khiến cho người dùng khó chấp nhận. Vẫn còn nhiều tranh cãi xung quanh việc dùng khuôn cảnh 4GT: - Người ủng hộ cho rằng mô hình 4GT làm giảm đáng kể thời gian phát triển phần mềm và làm tăng rất nhiều hiệu suất của người xây dựng phần mềm. - Những người phản đối cho rằng các công cụ của mô hình 4GT hiện tại không phải tất cả đều dễ dùng hơn các ngôn ngữ lập trình, chương trình gốc do các công cụ này tạo ra là không hiệu quả, và việc bảo trì các hệ thống phần mềm lớn được phát triển bằng cách dùng 4GT lại mở ra vấn đề mới. Có thể tóm tắt hiện trạng của cách tiếp cận 4GT như sau: 1. Lĩnh vực ứng dụng hiện tại cho 4GT mới chỉ giới hạn vào các ứng dụng hệ thông tin nghiệp vụ, đặc biệt, việc phân tích thông tin và làm báo cáo là nhân tố chủ chốt cho các cơ sở dữ liệu lớn. Tuy nhiên, cũng đã xuất hiện các công cụ CASE mới hỗ trợ cho việc dùng 4GT để tự động sinh ra khung chương trình. 2. Đối với các ứng dụng vừa và nhỏ: Thời gian cần cho việc tạo ra phần mềm được giảm đáng kể và khối lượng phân tích/thiết kế cũng được rút bớt. 3. Đối với ứng dụng lớn: Các hoạt động phân tích, thiết kế và kiểm thử chiếm phần lớn thời gian và việc loại bỏ bớt lập trình bằng cách dùng 4GT nhiều khi đem lại hiệu quả không đáng kể so với tính rườm rà, kém hiệu quả của phần mềm xây dựng bằng phương pháp này. Tóm lại, 4GT đã trở thành một phần quan trọng của việc phát triển phần mềm nghiệp vụ và rất có thể sẽ được sử dụng rộng rãi trong các miền ứng dụng khác trong thời gian tới. 1.3.5 Mô hình lập trình cực đoan Lập trình cực đoan (XP - eXtreme Programming) do Kent Beck đề xuất là một phương pháp tiếp cận mới cho phát triển phần mềm. XP đưa ra nhiều hướng dẫn mới, đôi khi trái ngược lại với các cách thức phát triển phần mềm được đề xuất từ trước đến nay. Hai khái niệm độc đáo mới và quan trọng hàng đầu trong XP là “tạo các ca thử nghiệm trước” và “lập trình đôi” a. Tạo các ca thử nghiệm trước Thông thường, thử nghiệm (và trước đó là tạo ca thử nghiệm) được tiến hành vào giai Tài liệu giảng dạy môn: Công nghệ phần mềm 15
đoạn cuối của quá trình phát triển, khi đã có mã nguồn và chuyển sang kiểm chứng tính đúng đắn của nó. Nhiều trường hợp việc kiểm thử không được coi trọng và chỉ được tiến hành khi còn thời gian và kinh phí. XP thay đổi quan niệm này bằng cách đặt cho kiểm thử một tầm quan trọng ngang bằng (có thể là lớn hơn) việc viết mã. Các ca kiểm thử được thiết kế trước khi viết mã và phải được thực hiện thành công mỗi khi chương trình đích được tạo ra. Tạo ca thử nghiệm trước đem lại nhiều lợi thế. Thứ nhất, nó giúp chúng ta xác định một cách rõ ràng giao diện của module. Hơn thế, để tạo được ca thử nghiệm, chúng ta cần phải hiểu rõ chức năng của nó. Tức là, XP yêu cầu chúng ta phải hiểu một cách rõ ràng các yêu cầu của modun trước khi chúng ta bắt tay vào phát triển nó. b. Lập trình đôi (Pair Programming) XP đưa ra khái niệm mang tính cách mạng (và trái ngược lại quan niệm từ trước đến nay) là mã nguồn của một module phải được viết bởi 2 lập trình viên dùng chung một máy tính. Giá trị của lập trình đôi là trong khi một người viết mã thì người thứ hai nghĩ về nó. Người thứ hai này sẽ có trong đầu một bức tranh tổng thể về vấn đề cần giải quyết, chứ không chỉ là giải pháp của đoạn mã lúc đó. Điều này sẽ gián tiếp đảm bảo một chất lượng tốt hơn và dẫn tới một giải pháp mang tính tổng thể hơn. Đồng thời, điều này giúp cho họ theo được các chỉ dẫn của XP, đặc biệt là việc “tạo ca thử nghiệm trước”. Nếu chỉ một người lập trình, họ sẽ rất dễ từ bỏ việc này, nhưng với hai người lập trình cùng làm việc thì họ có thể thay đổi cho nhau và giữ được các nguyên tắc của XP. 1.3.6 Tổ hợp các mô hình Chúng ta đã xem xét các mô hình kỹ nghệ phần mềm như là các cách tiếp cận khác nhau tới kỹ nghệ phần mềm chứ không phải là các cách tiếp cận bổ sung cho nhau. Tuy nhiên trong nhiều trường hợp chúng ta có thể và cũng nên tổ hợp các khuôn cảnh để đạt được sức mạnh của từng khuôn cảnh cho một dự án riêng lẻ. Ví dụ, khuôn cảnh xoắn ốc thực hiện điều này một cách trực tiếp, tổ hợp cả làm bản mẫu và các yếu tố của vòng đời cổ điển trong một cách tiếp cận tiến hóa tới kỹ nghệ phần mềm. Các kỹ thuật thế hệ thứ tự có thể được dùng để cài đặt bản mẫu hay cài đặt hệ thống sản xuất trong bước mã hóa của vòng đời cổ điển. Chúng ta có thể làm bản mẫu trong bước phân tích của mô hình vòng đời cổ điển. Kết luận ở đây là chúng ta không nên bị lệ thuộc với bất cứ khuôn cảnh cụ thể nào. Tính chất và qui mô của phần mềm cần phát triển sẽ là yếu tố quyết định tới chọn khuôn cảnh. Mỗi cách tiếp cận đều có ưu điểm riêng và bằng cách tổ hợp khéo léo các cách tiếp cận thì chúng Tài liệu giảng dạy môn: Công nghệ phần mềm 16
ta sẽ có một phương pháp hỗn hợp ưu việt hơn các phương pháp được dùng độc lập. Tổng hợp yêu cầu ban đầu Phân tích Làm bản 4GT Mô hình yêu cầu mẫu xoắn ốc 4GT Thiết kế Bản mẫu: Vòng thứ n Mô hình: Vòng thứ n Mã hóa 4GT Kiểm thử Hệ thống hoạt động Bảo trì Hình 1.4: Tổ hợp các mô hình 1.3.7 Tính khả thị của quá trình Do đặc điểm là các phần tử logic nên quá trình phát triển phần mềm rất khó kiểm soát. Người ta tìm cách khắc phục vấn đề này bằng cách làm cho quá trình phát triển trở nên “nhìn thấy được”, tức là ở mỗi bước (hoạt động) trong tiến trình phát triển phải tạo ra bằng một sản phẩm hay tài liệu tương ứng. Người quản lý dự án và cả khách hàng sẽ tiến hành xét duyệt các tài liệu này. Các tài liệu sẽ trở nên rất hữu ích cho công đoạn kiểm thử và nâng cấp phần mềm. Ví dụ, đối với hoạt động phân tích chúng ta có các tài liệu như: Báo cáo nghiên cứu khả thi, mô hình hệ thống, phác họa yêu cầu, đặc tả yêu cầu Chúng ta hãy so sánh tính khả thị của các khuôn cảnh đã biết: - Vòng đời cổ điển có tính khả thị cao do các bước phát triển tường minh, mô hình xoắn ốc cũng có tính khả thị tốt. - Đối với mô hình làm bản mẫu, nếu tần số sửa chữa lớn thì tính khả thị kém và việc tạo ra tài liệu là không hiệu quả. - 4GT thì mới chỉ được dùng với những ứng dụng nghiệp vụ đặc thù nên khó phát biểu Tài liệu giảng dạy môn: Công nghệ phần mềm 17
gì về tính khả thị của nó. Việc xây dựng tài liệu cũng có những vấn đề như: - Tạo ra các chi phí phụ làm chậm tiến trình phát triển - Khi phát hiện vấn đề về thiết kế, nhiều khi do không muốn thay đổi các tài liệu đã được xét duyệt, người phát triển có xu hướng dùng các giải pháp cục bộ không hiệu quả. Các mô hình phát triển truyền thống thường chú trọng tới khâu lập tài liệu để nâng cao tính khả thị. Ngược lại, mô hình lập trình cực đoan (XP) lại không khuyến khích việc tạo nhiều tài liệu. 1.3.8 Vấn đề giảm kích cỡ của phần mềm Như chúng ta đã biết, phần mềm hiện nay càng lớn, càng phức tạp. Một mặt, năng lực của nhóm lập trình không phải là tuyến tính so với năng lực của từng cá nhân. Độ phức tạp cũng tăng theo cấp số nhân, kéo theo chi phí cũng tăng theo cấp số nhân so với kích cỡ của chương trình cần phát triển. Do đó, việc tìm cách giảm kích cỡ, độ phức tạp của chương trình là ưu tiên hàng đầu của công nghệ phần mềm. Tại các bước phân tích thiết kế, giảm kích cỡ được thực hiện thông qua áp dụng chiến lược “chia để trị”. Tức là chúng ta chia phần mềm thành các module con có tính độc lập cao. Độ phức tạp của từng module sẽ nhỏ hơn nhiều so với cả hệ thống, các module con cũng có thể được phát triển song song. Tại giai đoạn mã hóa, giảm kích cỡ có thể thực hiện được thông qua các phương thức như: - Dùng lại: Dùng lại các thư viện đã phát triển, các thư viện thương mại - Tự sinh mã: Sử dụng các công cụ tự động hỗ trợ kỹ nghệ phần mềm (visual modeling tools, GUI builders, CASE tools ) - Kỹ thuật hướng đối tượng: Kỹ thuật hướng đối tượng hỗ trợ phát triển module có tính dùng lại cao nhờ có cơ chế che dấu thông tin và khả năng kế thừa. - Dùng các ngôn ngữ bậc cao (các ngôn ngữ có cấu trúc và năng lực biểu diễn cao) 1.4 Cái nhìn chung về công nghệ phần mềm Tiến trình phát triển công nghệ phần mềm chứa ba giai đoạn chính bất kể mô hình công nghệ phần mềm nào được chọn lựa. Ba giai đoạn này là xác định, phát triển và bảo trì, được gặp phải trong mọi dự án phát triển phần mềm, bất kể tới miền ứng dụng, kích cỡ và độ phức tạp. Giai đoạn xác định tập trung vào khái niệm cái gì. Tức là trong khi xác định, người phát triển phần mềm cố gắng tập trung vào xác định thông tin nào cần được xử lý, chức năng và hiệu năng nào là cần có, giao diện nào cần được thiết lập, ràng buộc thiết kế nào hiện có và tiêu Tài liệu giảng dạy môn: Công nghệ phần mềm 18
chuẩn hợp lệ nào cần có để xác định ra một hệ thống thành công. Yêu cầu chủ chốt của hệ thống và phần mềm cũng được xác định. Mặc dù các phương pháp được áp dụng trong giai đoạn xác định thay đổi tùy theo mô hình công nghệ phần mềm (hay tổ hợp các mô hình) được áp dụng, có ba bước riêng vẫn xuất hiện dưới dạng: 1. Phân tích hệ thống: Phân tích hệ thống xác định ra vai trò của từng phần tử trong một hệ thống dựa trên máy tính, tức là vạch ra vai trò mà phần mềm (cần phát triển) sẽ giữ. 2. Lập kế hoạch dự án phần mềm: Một khi vai trò của phần mềm đã được thiết lập, rủi ro đã được phân tích, tài nguyên đã được cấp phát, chi phí đã được ước lượng thì phải xác định cụ thể các công việc cần thực hiện và lập lịch thực hiện chúng. 3. Phân tích yêu cầu: Trong bước phân tích hệ thống chúng ta chỉ xác định được vai trò chung của phần mềm. Sau khi đã chính thức quyết định phát triển phần mềm, chúng ta cần phải phân tích để xác định chi tiết lĩnh vực thông tin, các chức năng cũng như các ràng buộc khi vận hành của phần mềm. Phân tích yêu cầu là khâu kỹ thuật quan trọng đầu tiên để đảm bảo chất lượng (tính đáng tin cậy) của phần mềm. Nếu xác định sai yêu cầu thì các bước kỹ thuật khác có tốt đến đâu thì phần mềm cũng sẽ không được đưa vào sử dụng. Giai đoạn phát triển tập trung vào khái niệm thế nào. Tức là, trong giai đoạn này người phát triển phần mềm từng bước xác định cách cấu trúc dữ liệu và kiến trúc phần mềm cần xây dựng, cách các chi tiết thủ tục được cài đặt, cách dịch thiết kế vào ngôn ngữ lập trình (hay ngôn ngữ phi thủ tục) và cách thực hiện kiểm thử. Phương pháp được áp dụng trong giai đoạn phát triển sẽ thay đổi tùy theo mô hình nhưng có ba bước đặc thù bao giờ cũng xuất hiện dưới dạng: 1. Thiết kế phần mềm: Là quá trình “dịch” các yêu cầu phần mềm thành một tập các biểu diễn (dựa trên đồ họa, bảng, hay ngôn ngữ), mô tả cho cấu trúc dữ liệu, kiến trúc, thủ tục thuật toán và đặc trưng giao diện. 2. Mã hóa: Các biểu diễn thiết kế phải được biểu diễn bởi một (hay một vài) ngôn ngữ nhân tạo (ngôn ngữ lập trình qui ước hay ngôn ngữ phi thủ tục được dùng trong khuôn cảnh 4GT) mà sẽ tạo ra kết quả là các lệnh thực hiện được trên máy tính. 3. Kiểm thử phần mềm: Một khi phần mềm đã được cài đặt dưới dạng máy thực hiện được, cần phải kiểm thử nó để phát hiện các lỗi phân tích, thiết kế, cài đặt và đánh giá tính hiệu quả. Giai đoạn bảo trì tập trung vào những thay đổi gắn với việc sửa lỗi, thích ứng khi môi trường phần mềm tiến hóa và sự nâng cao gây ra bởi sự thay đổi yêu cầu của người dùng. Giai đoạn bảo trì áp dụng lại các bước của giai đoạn xác định và phát triển, nhưng là việc thực hiện trong hoàn cảnh phần mềm hiện có. Có ba kiểu thay đổi gặp phải trong giai đoạn bảo trì: Tài liệu giảng dạy môn: Công nghệ phần mềm 19
1. Sửa đổi: Cho dù có các hoạt động bảo đảm chất lượng tốt nhất, vẫn có thể là khách hàng sẽ phát hiện ra khiếm khuyết trong phần mềm. Bảo trì sửa đổi làm thay đổi phần mềm để sửa các khiếm khuyết (lỗi lập trình, thuật toán, thiết kế ). 2. Thích nghi: Qua thời gian, môi trường ban đầu (như CPU, hệ điều hành, thiết bị ngoại vi) để phát triển phần mềm có thể sẽ thay đổi. Bảo trì thích nghi thực hiện việc sửa đổi phần mềm để thích hợp với những thay đổi môi trường ngoài. 3. Nâng cao: Khi phần mềm được dùng, khách hàng/người dùng sẽ nhận ra những chức năng phụ sẽ có lợi. Bảo trì hoàn thiện mở rộng phần mềm ra ngoài các yêu cầu chức năng gốc của nó. 1.5 Một số phương pháp xây dựng phần mềm 1.5.1 Khái niệm Để tiến hành xây dựng một phần mềm, chúng ta có thể áp dụng nhiều phương pháp khác nhau. Mỗi phương pháp có những ưu điểm và hạn chế riêng và phù hợp với từng loại phần mềm cụ thể. Mỗi phương pháp sẽ có những hướng dẫn cụ thể các công việc cần phải thực hiện trong từng giai đoạn trong qui trình xây dựng phần mềm. Bên cạnh đó, mỗi phương pháp cũng sẽ qui định những cách thức khác nhau để trình bày các kết quả thu được trong quá trình xây dựng phần mềm. Những qui định này có tính chất như là ngôn ngữ thống nhất để các thành viên tham gia xây dựng phần mềm có thể trao đổi thông tin trong việc xây dựng phần mềm. 1.5.2 Phân loại Các phương pháp xây dựng phần mềm được chia làm 02 nhóm khác nhau dựa vào tính chất của công việc cần thực hiện. Phương pháp xây dựng: • Phương pháp hướng chức năng; • Phương pháp hướng dữ liệu; • Phương pháp hướng đối tượng. Phương pháp tổ chức quản lý: • Xây dựng phương án; • Tổ chức nhân sự; • Ước lượng rủi ro, chi phí; • Lập lịch và theo dõi kế hoạch triển khai. 1.5.3 Cách tiếp cận a) Từ trên xuống Tài liệu giảng dạy môn: Công nghệ phần mềm 20
Đây là cách giải quyết vấn đề theo hướng phân tích. Khi tiến hành xây dựng phần mềm theo cách này, chúng ta bắt đầu với những thành phần chính của hệ thống. Sau đó, các thành phần này sẽ được phân tích thành các thành phần chi tiết và cụ thể hơn. Quá trình phân tích này sẽ kết thúc khi các kết quả thu được có mức độ phức tạp đúng với ý muốn của nhà xây dựng phần mềm. b) Từ dưới lên Ngược lại với phương pháp từ trên xuống, phương pháp từ dưới lên là cách giải quyết vấn đề theo hướng tổng hợp. Với phương pháp này, chúng ta tiến hành xây dựng những thành phần chi tiết, cụ thể mà chúng ta dự tính là sẽ có trong hệ thống. Sau đó, các nhà phát triển phần mềm sẽ tiến hành kết hợp các thành phần chi tiết này lại với nhau để tạo nên các thành phần chính mà hệ thống cần phải có. 1.5.4 Cách tiến hành a) Phương pháp hướng chức năng Với phương pháp này công việc xây dựng phần mềm được thực hiện dựa trên các chức năng mà hệ thống cần thực hiện. Hay nói cách khác chúng ta chú trọng đến thành phần xử lý của hệ thống: • Các thao tác tính toán • Các thao tác phát sinh • Các thao tác biến đổi . Phương pháp chung để giải quyết vấn đề là áp dụng nguyên lý “chia để trị”. Khi tiến hành xây dựng phần mềm theo phương pháp này, chúng ta sẽ chia các công việc lớn mà hệ thống cần thực hiện thành các công việc nhỏ hơn độc lập nhau. Việc phân chia các công việc được tiến hành cho đến khi các công việc thu được đủ nhỏ để chúng ta có thể tiến hành xây dựng hoàn chỉnh. Phương pháp hướng chức năng chú trọng đến cách để giải quyết vấn đề nhưng không có khả năng che dấu các thông tin trạng thái của hệ thống. Điều này dẫn đến việc các chức năng của hệ thống không tương thích với nhau trong việc thực hiện thay đổi các thông tin trong hệ thống. Chính vì vậy mà cách tiếp cận này chỉ thích hợp khi trong hệ thống có rất ít thông tin cần phải quản lý và chia sẻ giữa các chức năng với nhau. Để mô hình hóa cách xử lý thông tin trong hệ thống dùng lược đồ dòng dữ liệu (Data Flow Diagrams). DFD là một công cụ đơn giản và hữu ích để miêu tả cách thức hoạt động của hệ thống. b) Phương pháp hướng dữ liệu Ngược lại với phương pháp hướng chức năng, phương pháp hướng dữ liệu chú trọng nhiều đến thành phần dữ liệu cần phải xử lý trong hệ thống: Tài liệu giảng dạy môn: Công nghệ phần mềm 21
• Tổ chức dữ liệu • Khối lượng lưu trữ • Tốc độ truy xuất Khi tiến hành thiết kế theo phương pháp hướng dữ liệu chúng ta bắt đầu với việc thiết kế các cấu trúc dữ liệu cần thiết có trong bài toán, sau đó mới tiến hành thiết kế các thao tác để vận hành trên các cấu trúc dữ liệu đã thiết kế. Phương pháp này đặc biệt chỉ thích hợp trong các loại phần mềm chỉ có chức năng chính là lưu trữ và thao tác trên các loại dữ liệu. Hạn chế của nó là không quan tâm đến các chức năng mà hệ thống cần phải đáp ứng. Điều này dẫn đến việc có khả năng hệ thống sau khi thiết kế không có đầy đủ các chức năng cần thiết. Kết quả thu được sau khi thiết kế theo phương pháp hướng dữ liệu là mô hình thực thể kết hợp (Entity Relationship Diagram). Một mô hình thực thể kết hợp điển hình gồm có 2 thành phần cơ bản là các thực thể và các mối kết hợp. • Một thực thể là một đối tượng trong thế giới thực mà hệ thống có quan hệ, hoặc tương tác qua lại. • Mối kết hợp biểu diễn sự kết hợp giữa hai hay nhiều thực thể. c) Phương pháp hướng đối tượng Phương pháp thiết kế hướng đối tượng là sự kết hợp của phương pháp hướng dữ liệu và phương pháp hướng chức năng. Phương pháp này chú trọng đến cả thành phần dữ liệu và chức năng của hệ thống. Theo phương pháp hướng đối tượng thì một hệ thống phần mềm là một tập hợp các đối tượng có khả năng tương tác với nhau. Các đối tượng chính là các sự vật và hiện tượng vật lý cũng như trừu tượng mà chúng ta có trong thế giới thực. Mỗi đối tượng có dữ liệu riêng được che dấu với thế giới bên ngoài và các thao tác mà đối tượng có thể thực hiện trên các thành phần dữ liệu của đối tượng. Các đối tượng liên lạc, trao đổi thông tin với nhau bằng cách gửi các thông điệp cho nhau. Các thông điệp mà mỗi đối tượng có thể xử lý được gọi là giao diện của đối tượng. Khi đó mọi thao tác liên quan đến các đối tượng phải được thực hiện thông qua giao diện của đối tượng. Điều này giúp chúng ta đảm bảo rằng các thông tin bên trong các đối tượng đưọc bảo vệ một cách chắc chắn. Chúng ta có thể sử dụng nhiều hệ thống ký hiệu khác nhau để mô tả các đối tượng của hệ thống cũng như mối liên hệ giữa chúng. Một trong số các hệ thống ký hiệu phổ biến hiện nay là hệ thống ký hiệu UML (Unified Modeling Language - Ngôn ngữ mô hình hóa thống nhất). Tài liệu giảng dạy môn: Công nghệ phần mềm 22
UML sử dụng một hệ thống ký hiệu thống nhất biểu diễn các Phần tử mô hình (Model Elements). Tập hợp các phần tử mô hình tạo thành các sơ đồ UML (UML diagrams). Có các loại sơ đồ UML chủ yếu sau: - Sơ đồ lớp (Class Diagram); - Sơ đồ đối tượng (Object Diagram); - Sơ đồ tình huống sử dụng (Use Cases Diagram); - Sơ đồ tuần tự (Sequence Diagram); - Sơ đồ cộng tác (Collaboration Diagram hay là Composite Structure Diagram); - Sơ đồ trạng thái (State Machine Diagram); - Sơ đồ thành phần (Component Diagram); - Sơ đồ hoạt động (Activity Diagram); - Sơ đồ triển khai (Deployment Diagram); - Sơ đồ gói (Package Diagram); - Sơ đồ liên lạc (Communication Diagram); - Sơ đồ tương tác (Interaction Overview Diagram - UML 2.0); - Sơ đồ phối hợp thời gian (Timing Diagram - UML 2.0). 1.6 Công cụ và môi trường phát triển phần mềm 1.6.1 Khái niệm Các công cụ và môi trường phát triển phần mềm là các phần mềm hỗ trợ chính người phát triển trong quá trình xây dựng phần mềm. Các phần mềm này có tên gọi chung là CASE (Computer Aided Software Engineering) tools. Trong quá trình phát triển phần mềm theo các qui trình trên, các CASE tools có thể hỗ trợ cụ thể cho một giai đoạn nào đó hay cũng có thể hỗ trợ một số giai đoạn, trong trường hợp này tên gọi chung thường là môi trường phát triển phần mềm - SDE (Software Development Environment). Việc hỗ trợ của các CASE tools trong một giai đoạn bao gồm 2 hình thức chính: - Cho phép lưu trữ, cập nhật trên kết quả chuyển giao với một phương pháp nào đó. - Cho phép phát sinh ra kết quả chuyển giao cho giao đoạn kế tiếp. 1.6.2 Phần mềm hỗ trợ phân tích - Công việc hỗ trợ chính • Soạn thảo các mô hình thế giới thực; • Ánh xạ vào mô hình logic. - Các phần mềm: WinA&D, Analyst Pro, Tài liệu giảng dạy môn: Công nghệ phần mềm 23
1.6.3 Phần mềm hỗ trợ thiết kế - Công việc hỗ trợ chính • Soạn thảo các mô hình logic; • Ánh xạ vào mô hình vật lý. - Các phần mềm: QuickUML, Power Designer, Oracle Designer 1.6.4 Phần mềm hỗ trợ lập trình - Công việc hỗ trợ chính • Quản lý các phiên bản (Dữ liệu, chương trình nguồn, giao diện); • Biên dịch. - Các phần mềm: Microsoft Visual Studio, Jbuider, NetBeen, Macro Dreamweaver 1.6.5 Phần mềm hỗ trợ kiểm chứng - Công việc hỗ trợ chính • Phát sinh tự động các bộ dữ liệu thử nghiệm; • Phát hiện lỗi. - Các phần mềm: WinRuner 1.6.6 Phần mềm xây dựng phương án - Công việc hỗ trợ chính • Xác định các công việc; • Phân công; • Lập lịch biểu; • Theo dõi thực hiện; • Tạo lập phương án; • Dự đoán rủi ro; • Tính chi phí. - Các phần mềm: Microsoft Project, Microsoft Visio Kết chương Phần mềm đã trở thành phần tử chủ chốt của các hệ thống máy tính. Phát triển phần mềm đã tiến hóa từ xây dựng một công cụ xử lý thông tin thành một ngành công nghiệp. Phần mềm là phần tử logic cho nên việc kiểm soát nó khó hơn nhiều so với phần tử vật lý. Khó có thể tối ưu hóa đồng thời các tính năng cần có của phần mềm. Ví dụ, các tính năng như giao diện đồ họa dễ sử dụng và sự hoạt động hiệu quả, tiết kiệm tài nguyên hệ thống trong hầu hết các trường hợp là loại trừ lẫn nhau. Thách thức lớn đối với việc phát triển phần mềm là chúng ta phải xây dựng phần mềm tốt theo một lịch trình và kinh phí định trước. Tài liệu giảng dạy môn: Công nghệ phần mềm 24
Công nghệ phần mềm là một bộ môn tích hợp cả các phương pháp, công cụ và thủ tục để phát triển phần mềm máy tính. Có một số mô hình khác nhau cho công nghệ phần mềm, mỗi mô hình đều có những điểm mạnh và điểm yếu, nhưng nói chung tất cả đều có một dãy các giai đoạn cơ bản là: Xác định, phát triển và bảo trì.  Câu hỏi và bài tập củng cố: 1) Nêu khái niệm, đặc điểm và phân loại phần mềm? 2) Phân biệt phần mềm và công nghệ phần mềm? 3) Trình bày các mô hình phát triển phần mềm? Nêu những ưu điểm và hạn chế của từng mô hình? 4) Trình bày sự khác biệt của giai đoạn thiết kế trong các qui trình khác nhau? 5) Trình bày sự khác biệt của giai đoạn lập trình trong các qui trình khác nhau? 6) Khi tiến hành thực hiện phần mềm qua các giai đoạn (trong qui trình 5 giai đoạn) có thể phát sinh lỗi trong một giai đoạn nào đó (kết quả chuyển giao không chính xác, thiếu sót ). Theo các anh chị lỗi (nếu phát sinh) của giai đoạn nào là nghiêm trọng nhất? Vì sao? 7) Theo các anh chị trong các giai đoạn của qui trình công nghệ phần mềm: - Giai đoạn nào là quan trọng nhất (tại sao) - Giai đoạn nào dễ thực hiện nhất (tại sao) - Giai đoạn nào là tốn nhiều thời gian và chi phí nhất (tại sao) - Giai đoạn nào là có thể bỏ qua (trong trường hợp nào và tại sao) Tài liệu giảng dạy môn: Công nghệ phần mềm 25
Chương 2 PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU  Mục tiêu học tập: Sau khi học xong chương này người học có thể: - Mô tả yêu cầu phần mềm - Phân loại yêu cầu - Xác định các bước đặc tả yêu cầu, phân tích yêu cầu - Viết đặc tả yêu cầu phần mềm Tóm tắt chương Trong các ngành kỹ thuật hệ thống và kỹ nghệ phần mềm, phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi, dựa trên cơ sở là các yêu cầu mà những người có vai trò quan trọng đối với hệ thống, chẳng hạn người sử dụng, đưa ra. Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án. Việc phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (Requirements Engineering). Đôi khi nó còn được gọi bằng những cái tên như thu thập yêu cầu (Requirements Gathering, Requirements Capture), hoặc đặc tả yêu cầu (Requirements Specification). Các yêu cầu phải có tính đo được, kiểm thử được, có liên quan đến các nhu cầu hoặc cơ hội doanh nghiệp đã được xác định, và các yêu cầu phải được định nghĩa ở một mức độ chi tiết đủ cho việc thiết kế hệ thống. 2.1 Đại cương về phân tích và đặc tả Phân tích và định rõ yêu cầu là bước kỹ thuật đầu tiên trong tiến trình của công nghệ phần mềm. Công việc ở bước này là tìm hiểu xem chúng ta phải phát triển cái gì, chứ không phải là phát triển như thế nào. Đích cuối cùng của khâu phân tích là tạo ra tài liệu đặc tả yêu cầu, đây là tài liệu ràng buộc giữa khách hàng và người phát triển, và đó cũng là cơ sở của hợp đồng. Hoạt động phân tích là hoạt động phối hợp giữa khách hàng và người phân tích (bên phát triển). Khách hàng phát biểu các yêu cầu của hệ thống cần phát triển. Người phân tích cần hiểu rõ, cụ thể hóa và biểu diễn lại yêu cầu. Hoạt động phân tích giữ một vai trò đặc biệt quan trọng trong phát triển phần mềm, giúp cho đảm bảo chất lượng của phần mềm (phần mềm đáng tin cậy - có nghĩa là phải thực hiện được chính xác, đầy đủ yêu cầu của người sử dụng. Nếu phân tích không tốt dẫn đến hiểu lầm yêu cầu thì việc sửa chữa sẽ trở nên rất tốn Tài liệu giảng dạy môn: Công nghệ phần mềm 26
kém. Chi phí để sửa chữa sai sót về yêu cầu sẽ tăng lên gấp bội nếu như sai sót đó được phát hiện muộn. Việc phân tích, nắm bắt yêu cầu thường gặp các khó khăn như: - Các yêu cầu thường mang tính đặc thù riêng của một tổ chức, do đó nó thường khó hiểu, khó định nghĩa và đôi khi không có chuẩn để biểu diễn. - Các hệ thống thông tin lớn có nhiều người sử dụng thì các yêu cầu thường rất đa dạng và có các mức ưu tiên khác nhau, đôi khi mâu thuẫn lẫn nhau. - Người đặt hàng nhiều khi là các nhà quản lý, không phải là người dùng thực sự do đó việc phát biểu yêu cầu thường không đầy đủ và chính xác. Trong phân tích cần phân biệt giữa yêu cầu và mục tiêu của hệ thống. Yêu cầu là một đòi hỏi mà chúng ta có thể kiểm tra được còn mục tiêu là cái trừu tượng hơn mà chúng ta hướng tới. Ví dụ, giao diện của hệ thống phải thân thiện với người sử dụng là một mục tiêu và nó tương đối không khách quan và khó kiểm tra. Có nghĩa là với một phát biểu chung chung như vậy thì khách hàng và nhà phát triển khó định ra được một ranh giới rõ ràng để nói rằng phần mềm đã thỏa mãn được đòi hỏi đó. Với một mục tiêu như vậy, một yêu cầu cho nhà phát triển có thể là giao diện đồ họa mà các lệnh phải được chọn bằng menu Mục đích của giai đoạn phân tích là xác định rõ các yêu cầu của phần mềm cần phát triển. Tài liệu yêu cầu nên dễ hiểu với người dùng, đồng thời phải chặt chẽ để làm cơ sở cho hợp đồng và cho người phát triển dựa vào đó để xây dựng phần mềm. Do đó yêu cầu thường được mô tả ở nhiều mức chi tiết khác nhau phục vụ cho các đối tượng đọc khác nhau. Các mức đó có thể là: • Định nghĩa (xác định) yêu cầu: Mô tả một cách dễ hiểu, vắn tắt về yêu cầu, hướng vào đối tượng người đọc là người sử dụng, người quản lý • Đặc tả yêu cầu: Mô tả chi tiết về các yêu cầu, các ràng buộc của hệ thống, phải chính xác, sao cho người đọc không hiểu nhầm yêu cầu, hướng vào đối tượng người đọc là các nhà xây dựng phần mềm (người phát triển), các nhà quản trị hệ thống (sẽ làm việc bảo trì) Các tài liệu yêu cầu cần được thẩm định để đảm bảo thỏa mãn nhu cầu người dùng. Đây là công việc bắt buộc để đảm bảo chất lượng phần mềm. Đôi khi việc xác định đầy đủ các yêu cầu trước khi phát triển hệ thống là không thực tế và khi đó việc xây dựng các bản mẫu để nắm bắt yêu cầu là cần thiết. Tài liệu giảng dạy môn: Công nghệ phần mềm 27
Nghiên cứu Phân tích khả thi yêu cầu Xác định yêu cầu Đặc tả Báo cáo yêu cầu Mô hình khả thi Tài liệu hệ thống định nghĩa yêu cầu Tài liệu Tài liệu Yêu cầu đặc tả yêu cầu Hình 2.1: Quá trình hình thành các yêu cầu. 2.2 Quá trình phân tích 2.2.1 Phân tích phạm vi dự án phần mềm Người phân tích hệ thống dùng thuật ngữ phạm vi để chỉ trách nhiệm dự án phải thực thi. Ngược lại, phạm vi dự án là nhiệm vụ lớn và phức tạp được thực hiện bởi chương trình. Để xác định phạm vi dự án, bằng xác định quá trình nghiệp vụ ứng dụng sẽ đối đầu. Đó là những phạm vi vấn đề của ứng dụng. Nói chung, có hai phần đối với bất kỳ giải pháp nghiệp vụ là phần triển khai ứng dụng và phần thực hiện bởi con người hay chương trình. Định ra ranh giới ứng dụng tức là xác định qui trình trách nhiệm. Một khi đã định nghĩa trách nhiệm của dự án cần: • Chia trách nhiệm thành những nhiệm vụ con để đưa ra ý tưởng cho chính mình về bao nhiêu module chương trình khác nhau yêu cầu? • Xác định bao nhiêu vùng địa lý liên quan (chi nhánh văn phòng). • Ước lượng số người dùng ứng dụng và thời gian ứng dụng được duy trì. • Tính chính xác. • Cuối cùng, hiểu khách hàng mong đợi gì ở dự án khi được triển khai. Tại thời điểm này, chúng ta có ý tưởng phạm vi dự án. Cân nhắc độ lớn dự án đối với thời gian và ràng buộc ngân sách. Nếu dự án quá lớn về thời gian và tiền bạc cho chi trả thì bàn bạc vấn đề với khách hàng để đưa ra quyết định thương lượng cho thõa đáng. Chúng ta phải chọn lựa hoặc nhiều thời gian hơn, hoặc nhiều tiền hơn hoặc cả hai. Hoặc chúng ta phải giảm phạm vi dự án xuống. Phân tích tất cả những tình huống ở giai đoạn đầu của dự án sẽ làm cho dự án thành công nhiều hơn. 2.2.2 Nghiên cứu khả thi Đây là giai đoạn có tầm quan trọng đặc biệt, vì nó liên quan đến việc lựa chọn giải Tài liệu giảng dạy môn: Công nghệ phần mềm 28
pháp. Trong giai đoạn này người phân tích phải làm rõ được các điểm mạnh và điểm yếu của hệ thống cũ (nếu có), đánh giá được mức độ, tầm quan trọng của từng vấn đề, định ra các vấn đề cần phải giải quyết (ví dụ: những dịch vụ mới, thời hạn đáp ứng, hiệu quả kinh tế ). Sau đó người phân tích phải định ra một vài giải pháp có thể (sơ bộ) và so sánh, cân nhắc những ưu điểm, những hạn chế của các giải pháp đó (như tính năng của hệ thống, giá thành, bảo trì, đào tạo người sử dụng ). Đó chính là việc tìm ra một điểm cân bằng giữa nhu cầu và khả năng đáp ứng. Mọi dự án đều khả thi khi nguồn tài nguyên vô hạn và thời gian vô hạn. Nhưng việc xây dựng hệ thống lại phải làm với sự hạn hẹp về tài nguyên và khó (nếu không phải là không hiện thực) bảo đảm đúng ngày bàn giao. Phân tích khả thi và rủi ro có liên quan với nhau theo nhiều cách. Nếu rủi ro của dự án là lớn thì tính khả thi của việc chế tạo phần mềm có chất lượng sẽ bị giảm đi. Trong giai đoạn nghiên cứu khả thi, chúng ta tập trung vào bốn lĩnh vực quan trọng như: 1. Khả thi về kinh tế: Chi phí phát triển cần phải cân xứng với lợi ích mà hệ thống được xây dựng đem lại. Tính khả thi về kinh tế thể hiện trên các nội dung sau: - Khả năng tài chính của tổ chức cho phép thực hiện dự án. - Lợi ích mà dự án phát triển HTTT mang lại đủ bù đắp chi phí phải bỏ để ra xây dựng nó. - Tổ chức chấp nhận được những chi phí thường xuyên khi hệ thống hoạt động. Một thuật ngữ hay dùng để chỉ tài liệu nghiên cứu khả thi về kinh tế là luận chứng kinh tế. Luận chứng kinh tế nói chung được xem như nền tảng cho hầu hết các hệ thống (các ngoại lệ là hệ thống quốc phòng, hệ thống luật, các hệ thống phục vụ cho các nghiên cứu đặc biệt). Luận chứng kinh tế bao gồm: - Các mối quan tâm, nhất là phân tích chi phí/lợi ích - Chiến lược phát triển dài hạn của công ty, đơn vị - Sự ảnh hưởng tới các sản phẩm lợi nhuận khác - Chi phí tài nguyên cần cho việc xây dựng và phát triển thị trường tiềm năng 2. Khả thi về kỹ thuật: Khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng tới khả năng đạt tới một hệ thống chấp nhận được. Nói cách khác, khả thi kỹ thuật là xem xét khả năng kỹ thuật hiện tại có đủ đảm bảo thực hiện giải pháp công nghệ dự định áp dụng hay không. Khả thi kỹ thuật thường là lĩnh vực khó thâm nhập nhất tại giai đoạn phân tích. Điều thực chất là tiến trình phân tích và xác định nhu cầu cần được tiến hành song song Tài liệu giảng dạy môn: Công nghệ phần mềm 29
với việc xác nhận tính khả thi kỹ thuật. Các xem xét thường được gắn với tính khả thi kỹ thuật bao gồm: Rủi ro xây dựng: Liệu các phần tử hệ thống có thể được thiết kế sao cho đạt được chức năng và hiệu suất cần thiết thỏa mãn những ràng buộc trong khi phân tích không? Có sẵn tài nguyên: Có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang xét không? Các tài nguyên cần thiết khác (phần cứng và phần mềm) có sẵn cho việc xây dựng hệ thống không? Công nghệ: Công nghệ liên quan đã đạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống chưa? 3. Khả thi về pháp lý: Nghiên cứu và đưa ra phán quyết về có hay không sự xâm phạm, vi phạm pháp luật hay khó khăn pháp lý từ việc xây dựng và vận hành hệ thống? Tính khả thi pháp lý bao gồm một phạm vi rộng các mối quan tâm kể cả hợp đồng, nghĩa vụ pháp lý, sự vi phạm và vô số các bẫy pháp lý khác mà thường là các nhân viên kỹ thuật không biết tới. Trong nước, vấn đề khả thi về pháp lý vẫn chưa được coi trọng một cách đúng mức mặc dù đã có một số luật liên quan đến CNTT và bảo hộ bản quyền 4. Tính khả thi về hoạt động: Đánh giá tính khả thi của việc vận hành hệ thống. Trong mỗi phương án người ta cần xem xét hệ thống có thể vận hành thuận lợi hay không trong khuôn khổ tổ chức và điều kiện quản lý mà tổ chức đó (người dùng, khách hàng) có. Mức độ các phương án được xem xét tới trong nghiên cứu khả thi thường bị giới hạn bởi các ràng buộc về chi phí và thời gian. 2.2.3 Phân tích mở rộng yêu cầu nghiệp vụ a. Xác định yêu cầu nghiệp vụ Mỗi dự án sẽ có một hay nhiều yêu cầu nghiệp vụ. Mỗi yêu cầu nghiệp vụ là một mô tả tác vụ cụ thể trong nghiệp vụ của khách hàng. Một tác vụ cần chia nhỏ thành những phần chắc chắn cho đến khi mỗi phần đủ để mô tả công việc chính xác. Khi mức độ của thành phần chia nhỏ dưới mức tối thiểu, xác định lại trình tự thành phần. Mỗi tác vụ được gọi là yêu cầu nghiệp vụ hay quy tắc nghiệp vụ. Quy tắc doanh nghiệp được viết theo ngôn ngữ được hiểu bởi những người không chuyên máy tính sao cho người dùng có thể kiểm tra một cách chính xác. b. Xác định yêu cầu chất lượng khách hàng Mỗi dự án phần mềm có thể yêu cầu nhanh, bảo mật, phụ thuộc, dễ dùng. Trong thế giới thực, thời gian và ràng buộc tài chính làm cho không thể tạo ra những chương trình dự án Tài liệu giảng dạy môn: Công nghệ phần mềm 30
hoàn chỉnh. Thay vào đó, điều quan trọng để quyết định dựa trên mức độ chấp nhận của chất lượng thõa mãn khách hàng. c. Phân tích hạ tầng cơ sở hiện hành Phần quan trọng trong thiết kế giải pháp là phân tích kỹ thuật thay thế. Điển hình, giải pháp phần mềm được đưa vào hơn là thay thế hệ thống hiện hành. Dự án cần làm việc trên phần cứng và phần mềm mà người dùng hiện có. Biết được hệ điều hành khách hàng đang dùng, loại mạng đang sử dụng, và nếu người dùng đang chạy phần mềm không tương thích với chương trình mới hơn. Nên bỏ thời gian tìm hiểu máy chủ hiện hành, hệ điều hành, phần mềm đang chạy. Khi đưa giải pháp, nhớ rằng cơ sở hạ tầng hiện hành đảm bảo giải pháp của chúng ta có thể tương thích. d. Phân tích ảnh hưởng kỹ thuật Nếu cần mở rộng chức năng cho hệ thống hiện hành, chúng ta mong ước thay đổi hệ thống cũ cả việc cải thiện hệ thống cũ và tích hợp dễ dàng hơn hệ thống mới. Việc suy nghĩ trước sẽ tiết kiệm thời gian sau đó: Trãi qua thời gian tìm hiểu sự khác biệt về giao tác, bảo mật, và những chức năng khác giữa kỹ thuật cũ và giải pháp mới. Chúng ta nên tìm hiểu thủ tục chuyển đổi dữ liệu từ kỹ thuật cũ sang kỹ thuật mới. Đảm bảo được phép thực nghiệm những thủ tục này, và có kế hoạch bảo lưu trong trường hợp thực hiện vấn đề này bị lỗi. Đảm bảo chắc chắn những tác động chuyển đổi trên mọi thành phần của hệ thống, không chỉ phần tử gần nhất thay đổi. 2.2.4 Phân tích yêu cầu bảo mật Khi hệ thống lưu trữ, truy xuất dữ liệu cá nhân như thông tin nhân sự, thẻ tín dụng, doanh số bán hàng hay thông tin riêng tư Chúng ta cần có biện pháp đảm bảo an toàn những dữ liệu này. a. Xác định vai trò Toàn bộ ứng dụng không chỉ có 1 mức độ bảo mật. Người dùng cuối chỉ cần quyền truy xuất giới hạn vào hệ thống. Quản trị hệ thống, người thao tác viên cập nhật, và người dùng có quyền truy cập cao hơn ở mọi cấp độ. Bảo mật dựa trên vai trò là kỹ thuật dùng để cấp quyền mức độ bảo mật khác nhau tương ứng quyền hạn và độ chuyên nghiệp của mỗi người dùng trong hệ thống. Lưu ý: Nhận biết những lớp chính của những người dùng cần truy cập đến ứng dụng của chúng ta. Gán tên vai trò cho mỗi lớp người dùng. Cuối cùng, gán mức độ tối thiểu có thể truy xuất đến mỗi vai trò. Mỗi lớp người dùng nên có đủ quyền truy xuất đến công việc của họ, và không nhiều hơn. b. Xác định môi trường bảo mật ứng dụng Tài liệu giảng dạy môn: Công nghệ phần mềm 31
Độ bảo mật không bị giới hạn người dùng hệ thống. Chỉ người dùng đăng nhập vào ứng dụng để kiểm soát tài nguyên chia sẻ như tập tin, dịch vụ hệ thống, cơ sở dữ liệu. Mức độ kiểm soát của ứng dụng được gọi là ngữ cảnh bảo mật. Chúng ta cần phải làm việc với nhiều người dùng khác như quản trị mạng, cấp quyền truy xuất phù hợp ứng dụng để chia sẻ tài nguyên. c. Xác định ảnh hưởng bảo mật Nếu công ty có sẵn cơ chế bảo mật thay vào đó hệ thống của chúng ta nên điều chỉnh cho phù hợp với cơ chế đã có. Nếu chúng ta đang thực thi hệ thống bảo mật mới hay một hệ thống khác, cần phải phân tích tác động của hệ thống trên hệ thống hiện tại: • Hệ thống mới có làm hỏng chức năng của phần mềm hiện tại? • Hệ thống đòi hỏi phải hỗ trợ thêm một phần người dùng – đăng nhập mở rộng? • Hệ thống sẽ khóa một vài người dùng trên những tập tin hay những tài nguyên mà họ được quyền truy cập trước đây. d. Kế hoạch vận hành Khi tổ chức phát triển và thay đổi, người dùng mới được thêm vào, người cũ được cập nhật và bỏ đi. Những thao tác này đòi hỏi thay đổi cơ sở dữ liệu bảo mật, đó là nơi thông tin người dùng và quyền hạn truy cập của họ được lưu. Những thông tin này được lưu trữ hiện thời. Nếu người dùng có vị trí địa lý khác nhau, ở văn phòng khác nhau, chúng ta cần lên kế hoạch tái tạo cơ sở dữ liệu bảo mật. Sự tái tạo là sự thay đổi hệ thống dữ liệu tại nơi này sao chép đến nơi khác sao cho tất cả thông tin bảo mật được lưu giữ mỗi nơi. Thuận lợi cho việc tạo bản sao là người dùng có thể đăng nhập dùng thông tin được lưu ở vị trí gần hơn so với vị trí địa lý. Nếu hệ thống mạng bị ngừng hoạt động, ví dụ người dùng vẫn có thể đăng nhập. Việc tạo bản sao cần được lên kế hoạch và vận hành. e. Kế hoạch kiểm soát và đăng nhập Một hệ thống bảo mật tốt không là cơ chế thụ động. Thay vào đó, chứa chức năng trợ giúp kiểm soát hoạt động của hệ thống cho vấn đề bảo mật. Vấn đề chung của chức năng này là nhật ký. Toàn bộ thao tác của hệ thống có thể được ghi nhận hầu như toàn bộ sự kiện liên quan đến bảo mật hệ thống. Có thể ghi nhận mỗi khi đăng nhập, truy xuất đến mọi tài nguyên nhưng điều này hiếm khi hiệu qủa; thường chúng ta sẽ ghi nhận một số tập thông tin này như việc cố gắng đăng nhập lỗi. Lưu ý: Nhật ký hệ thống tự nó thì không có ý nghĩa; chúng ta phải kế hoạch kiểm soát thường xuyên bởi ta có thể phát hiện những nghi ngờ những mẫu nhật ký hoạt động. Người kiểm soát được huấn luyện nên phân tích nhật ký trên cơ sở thường xuyên, đưa ra những đề Tài liệu giảng dạy môn: Công nghệ phần mềm 32
nghị nếu có bất kỳ điều nghi ngờ. f. Xác định mức độ yêu cầu bảo mật Bảo mật cũng giống như những phần khác trong thiết kế ứng dụng, là sự cân nhắc giữa hiệu quả và chi phí. Nếu hệ thống không lưu giữ những dữ liệu có tính nhạy cảm cao, cách tốt nhất để triển khai hệ thống đó là “giữ sự xác thực của người dùng” đòi hỏi lưu trữ. Nếu chúng ta lưu trữ thông tin cần cho bảo mật, chi phí cho bảo mật thông tin đặc biệt phải được kiểm chứng. Không có hệ thống nào bảo mật 100%. Chúng ta phải xác định mức độ rủi ro bảo mật có thể chấp nhận được. Độ rủi ro bảo mật diễn tả tỉ lệ phần trăm tương xứng khả năng mà bảo mật hệ thống không bao giờ đạt đến. Điều đó là có thể, nhưng phí tổn để xây dựng hệ thống bảo mật 99%. Chúng ta hay khách hàng phải xác định mức độ rủi ro có thể chấp nhận được dựa trên dữ liệu nhạy cảm của hệ thống. g. Rà soát bảo mật hiện tại Chúng ta nên trung thành ý tưởng của yêu cầu bảo mật của ứng dụng. Ở thời điểm phân tích chính sách bảo mật hiện tại của công ty để xác định bảo mật có đạt đến những nhu cầu của hệ thống hay không. Nếu không, thảo luận vấn đề với người gách vác hệ thống bảo mật ở công ty để tìm ra giải pháp mang lại lợi ích để triển khai mở rộng bảo mật. 2.2.5 Phân tích yêu cầu tốc độ Tốc độ của ứng dụng có thể đòi hỏi khó. Đối với người dùng, ứng dụng sẽ hầu như chạy quá chậm nhưng muốn có một ứng dụng chạy nhanh cần phải có một thiết kế tốt mới có thể mang lại giá trị cao. Lưu ý: Việc chạy nhanh một ứng dụng thiết kế kém thì dễ, nhiều ứng dụng có thể chạy chậm bởi thiết kế thiếu sót, những không bởi không tương thích giữa phần ứng và các yếu tố bên ngoài. Chúng ta nên nhận thức yêu cầu tốc độ ứng dụng trước khi bắt đầu qui trình thiết kế. Yêu cầu tốc độ dựa theo các mục sau: Mỗi phút giao dịch: Cung cấp dịch vụ phụ thuộc vào số lượng lớn người dùng, ứng dụng phân tán dùng những giao tác. Số giao tác mỗi phút là độ đo tốc độ hệ thống cơ sở dữ liệu. Băng thông: Ứng dụng phân tán làm nghẽn việc sử dụng mạng. Sự phản hồi của ứng dụng xác định định băng thông mạng (độ rộng của đường truyền mạng). Băng thông thường được đo bằng megabit/s. Khả năng chứa: Lượng lưu trữ - cả bộ nhớ chính và phụ - sẵn sàng đối với ứng dụng là vấn đề lưu tâm quan trọng cho tốc độ chung của ứng dụng. Bộ nhớ RAM đòi hỏi của ứng Tài liệu giảng dạy môn: Công nghệ phần mềm 33
dụng gây ra những khác biệt lớn cho tốc độ của ứng dụng. Nút thắt: Trong mỗi hệ thống, có phần giới hạn tốc độ hệ thống nói chung. Ví dụ CPU tốc độ nhanh cũng không cải thiện gì mấy nếu phải chờ dữ liệu từ một ổ cứng quá chậm. Trong trường hợp này, ổ cứng sẽ là nút thắt của toàn bộ hệ thống. Không thể tăng tốc độ trừ khi nút thắc được nhận biết, bởi vì chỉ có cải thiện nút thắt mới làm nâng tốc độ phù hợp. Thuật ngữ tốc độ thường dùng đồng nghĩa với sự phản hồi - số lượng thời gian chiếm giữ để phản hồi lại hành động của người dùng. Có thể làm cho ứng dụng xuất hiện phản hồi mà không cần tăng tốc độ. Tuy nhiên, thời gian phản hồi trung bình của ứng dụng là đặc tính quan trọng, chúng ta phải kết hợp chặt chẽ những mục tiêu thời gian phản hồi đối vời yêu cầu chung thiết kế. Không thể nói về tốc độ trong những ứng dụng phân tán mà không phân biệt quan trọng là giữa nhu cầu cao và trung bình. Tại một số thời điểm - tối hay cuối tuần – có lẽ ứng dụng sẽ phục vụ với số lượng nhỏ người dùng, thì tốc độ nó sẽ trên trung bình. Ở thời điểm khác, số lượng người dùng sẽ cao hơn và tốc độ ứng dụng đủ cho phép. Mục tiêu tốc độ bao gồm cả mục tiêu tốc độ trung bình và cao. 2.2.6 Phân tích yêu cầu vận hành Chúng ta có thể giảm bớt chi phí vận hành theo nhiều cách. Cách tốt nhất để giảm chi phí vận hành là đảm bảo chương trình được kiểm thử và chạy sửa lỗi trước khi đưa vào triển khai. Chi phí triển khai có thể được giảm bớt bởi phân phối trực tuyến hay những thủ tục tự động cài đặt, và qui trình vận hành có thể tự động bằng các qui trình tin học. Mức vị trí và huấn luyện đội ngũ là vấn đề xem xét quan trọng: Đội ngũ nhân viên càng được huấn luyện kỹ và sâu thì vấn đề càng nhanh chóng được sửa đổi. Trong trường hợp phần cứng, phần mềm là thành phần được mua chứ không được phát triển, chúng ta có thể nhận sự chấp thuận vận hành từ nhà xưởng hay người ủy thác của sản phẩm. Vận hành sản phẩm trung gian tiết kiệm cho chúng ta chi phí thuê mướn nhân viên mới hay huấn luyện lại những nhân viên cũ để duy trì một hay nhiều thành phần của hệ thống. Giảm chi phí vận hành đòi hỏi sự tự thõa mãn lợi nhuận trong thời ngắn đối với những lợi ích trong tương lai. Giảm chi phí vận hành lâu dài thường đòi hỏi đầu tư đón đầu trong tự động hóa phần cứng và phần mềm. 2.2.7 Phân tích khả năng mở rộng yêu cầu Qua thời gian, những yêu cầu giải pháp sẽ thay đổi. Người dùng cần những chức năng mới, các quy luật đặt ra sẽ bị sửa đổi, và phần cứng phần mềm nền mới thay đổi theo. Ứng dụng thiết kế tốt là có khả năng mở rộng được – nó có thể uyển chuyển cải thiện mà không phải viết lại hoàn toàn. Khả năng mở rộng của ứng dụng bị đảo ngược so với lượng công việc Tài liệu giảng dạy môn: Công nghệ phần mềm 34
cần hoàn thành để thêm những đặc trưng mới. Khả năng mở rộng có thể đạt được thông qua những ý nghĩa khác nhau. Để đạt những khả năng hạn định là lưu trữ thông tin, qui luật đặt ra trong cơ sở dữ liệu hơn là lập trình chúng trong đối tượng nghiệp vụ. Theo cách đó, yếu tố quan trong hay thủ tục thay đổi, nó có thể thay đổi trong cơ sở dữ liệu mà không thay đổi mã nguồn. Cách khác là đặt mã nguồn vào trong đoạn script được làm rõ hơn khi biên dịch chương trình; đoạn script có thể bị thay đổi một cách dễ dàng không đòi hỏi bất kỳ biên dịch hay cài đặt lại tập tin nhị phân. Lưu ý: Cách tốt nhất để đạt được khả năng mở rộng là ngắt ứng dụng thành những đối tượng thành phần, mỗi thành phần hoàn thành một nhiệm vụ riêng lẻ. Nếu những yêu cầu của những nhiệm vụ đặc biệt thay đổi, đối tượng tương ứng có thể bị thay đổi và biên dịch lại mà không gây ảnh hưởng bất kỳ đối tượng khác. Những đối tượng được thêm vào dễ dàng. Đối tượng nghiệp vụ có những thuận lợi được làm hiệu quả hơn những phương pháp khác trong khi vẫn đảm bảo tốt khả năng mở rộng. 2.2.8 Phân tích những yêu cầu sẵn có Những ứng dụng phân tán được thiết kế để chạy mỗi ngày. Nó cần thiết cho sự thành công của doanh nghiệp. Như vậy, chúng có mức độ sẵn sàng cao nên tránh thường bảo trì, sửa chữa, phát sinh không theo kế hoạch. Rõ ràng, đối với những ứng dụng mang tính sẵn sàng, nó không được gây ra lỗi. Nhưng không có ứng dụng nào là không có lỗi, vì vậy ứng dụng phải được bảo lưu để chúng có thể hoạt động thậm chí khi lỗi xảy ra trong một phần của chương trình. Ví dụ, nếu người dùng gây ra lỗi cho chương trình thì chỉ một phần chương trình phục vụ cho người dùng đó bị hỏng, không ảnh hưởng người dùng còn lại đang nối kết. Bất kỳ thành phần ứng dụng nào hỏng hay không sẵn sàng thì nên khởi động lại ngay khi có thể. Việc bảo trì có kế hoạch cũng tác động đến tính sẵn sàng. Một máy chủ chứa ứng dụng lý tưởng luôn có bản sao lưu có thể khởi động khi máy chủ bảo trì. Ứng dụng có mức độ sẵn sàng cao có cách luân phiên để kết nối mạng trong trường hợp mạng ngưng hoạt động. Lưu ý: Tính sẵn sàng liên quan đến nghiệp vụ. Tính sẵn sàng của ứng dụng càng cao thì giá trị của ứng dụng càng cao. Chúng ta phải xác định bao nhiêu giờ trong ngày ứng dụng cần được thao tác; giờ nào là quan trọng so với các giờ trong ngày. Cân nhắc giá trị của việc tăng tính sẵn sàng đối với giá trị dự án của thời gian tải ứng dụng. 2.2.9 Phân tích yêu tố con người Thiết kế ứng dụng được giám sát bởi nhiều người lập trình là phần quan trọng của yếu tố con người. Chúng ta nên xác định những kinh nghiệm nào mà người dùng cần có. Với bất kỳ ứng dụng nào, kinh nghiệm người dùng càng tốt thì chi phí càng cao. Tài liệu giảng dạy môn: Công nghệ phần mềm 35
Bắt đầu định nghĩa mục tiêu của người dùng. Xác định người dùng với những nhu cầu đặc biệt như thế nào. Chúng ta cần điều tiết người dùng qua việc điều tiết nghe và nhìn. Phụ thuộc vào vị trí địa lý của người sử dụng. Chúng ta cần sửa đổi ứng dụng thích ứng theo vị trí địa lý. Cần điều chỉnh nhu cầu lướt qua của người dùng, người không cần sự nối kết chắc chắn hay khả năng trả lời lại. 2.2.10 Phân tích yêu cầu tích hợp Nếu giải pháp giao tiếp với ứng dụng kế thừa, việc truy xuất cơ sở dữ liệu tồn tại, hay việc chuyển đổi dữ liệu cũ sang khuôn dạng mới, chúng ta cần phải đưa kế hoạch tích hợp ứng dụng với phần mềm cũ. Điều này được làm thông qua kết nối của hãng trung gian như trình điều khiển thiết bị kết nối cơ sở dữ liệu, nhưng chúng ta cũng cần viết kết nối và những tiện ích chuyển đổi. Khi phát sinh nhu cầu lớn hơn, cơ sở dữ liệu phải thiết kế lại. Những cải tiến phải được xây dựng cẩn thận bởi chúng phá vở tất cả mã nguồn cơ sở dữ liệu hiện tại. Trước khi cải tiến khung dữ liệu, đảm bảo những phần mã nguồn hiện tại có thể truy xuất đến CSDL. Tất cả mã nguồn hiện tại phải được soát lại, có thể viết lại. 2.2.11 Phân tích thực tiễn nghiệp vụ tồn tại Phần định nghĩa trong qui tắc nghiệp vụ liên quan đến sự hiểu biết ngữ cảnh trong những qui tắc thao tác. Hiểu được những thực tế nghiệp vụ của doanh nghiệp có thể giúp chúng ta tránh được sai sót thậm chí giúp tìm cách tốt hơn, hiệu quả hơn của tự động hóa tiến trình nghiệp vụ. Có được ứng dụng từ giai đoạn phát triển đến sản phẩm đòi hỏi sự hiểu biết về hạ tầng mạng và chính sách hạ tầng của công ty. Biết được ai là người chịu trách nhiệm bảo trì, bảo mật, tính toàn vẹn, khả năng phản hồi tương tác trên mạng. Học những tiến trình và chính sách liên quan chạy trên ứng dụng mới. Tìm ra loại kiểm soát chất lượng và dịch vụ kiểm thử sẵn sàng trong khi chúng ta kiểm thử trên chính phần mềm, ta có thể tự động tài nguyên hay dành cho bộ phận kiểm tra chất lượng tùy ý sử dụng. Chúng ta có thể yêu cầu phương pháp thiết kế đặc biệt hay triển khai thực tế. Cuối cùng, giữ những nguyên tắc cốt lỏi: Học nhu cầu khách hàng, cố gắng thực hiện chúng. Điều này có thể trở nên khó khi khách hàng không biết nhu cầu của họ là gì, nhưng đó là cách dẫn đến ứng dụng thành công. 2.2.12 Phân tích yêu cầu khả năng quy mô Nếu ứng dụng thành công sẽ hấp dẫn người dùng hơn. Đặc biệt, nếu ứng dụng chạy trên môi trường Internet thì sự thành công đồng nghĩa với tăng nhu cầu. Ứng dụng phải được thiết kế có quy mô, nó phải có khả năng hỗ trợ nâng cấp cho phép phục vụ nhiều người hơn. Tài liệu giảng dạy môn: Công nghệ phần mềm 36
Một cách đơn giản để nâng cao ứng dụng là mua CPU nhanh hơn, nhiều RAM, kết nối mạng tốt hơn. Tuy nhiên việc tăng cường máy đơn chạy nhanh hơn. Thực sự những ứng dụng có thể nâng cấp phải thêm vào nhiều dịch vụ phía máy chủ. Điều này có nghĩa ứng dụng có thể chạy trên nhiều máy tính cùng một lúc, sự phân phối việc tải xuống của người dùng và xử lý thời gian qua nhiều máy chủ. Điều này sẽ gia tăng đáng kể tính phức tạp, vì vậy một lần nữa tính thuận tiện khả năng quy mô phải được cân nhắc đối với giá trị cung cấp. Tuy nhiên, ứng dụng như Miscrosoft Transaction Server giảm đáng kể chi phí phát triển ứng dụng phân tán bởi quản lý về mặt logic của phân tán tự động. 2.3 Người phân tích Người phân tích đóng vai trò đặc biệt quan trọng trong tiến trình phân tích. Ngoài kinh nghiệm, một người phân tích tốt cần có các khả năng sau: - Khả năng hiểu được các khái niệm trừu tượng, có khả năng tổ chức lại thành các phân tích logic và tổng hợp các giải pháp dựa trên từng dải phân chia. - Khả năng rút ra các sự kiện từ các nguồn thông tin mâu thuẫn. - Khả năng hiểu được môi trường người dùng/khách hàng. - Khả năng áp dụng các phần tử hệ thống phần cứng và/hoặc phần mềm vào môi trường người sử dụng/khách hàng. - Khả năng giao tiếp tốt ở dạng viết và nói. - Khả năng trừu tượng hóa/tổng hợp vấn đề từ các sự kiện riêng lẻ 2.4 Xác định và đặc tả yêu cầu 2.4.1 Xác định yêu cầu Xác định yêu cầu là mô tả trừu tượng về các dịch vụ mà hệ thống cần cung cấp và các ràng buộc mà hệ thống cần tuân thủ khi vận hành. Nó chỉ mô tả các hành vi bên ngoài của hệ thống mà không liên quan tới các chi tiết thiết kế. Yêu cầu nên được viết sao cho có thể hiểu mà không cần một kiến thức chuyên môn đặc biệt nào. Các yêu cầu được chia thành hai loại: 1) Các yêu cầu chức năng: Các dịch vụ mà hệ thống cần cung cấp. 2) Các yêu cầu phi chức năng: Các ràng buộc mà hệ thống cần tuân thủ. Các yêu cầu phi chức năng có thể chia làm 3 kiểu: i) Yêu cầu sản phẩm: Các yêu cầu về tốc độ, bộ nhớ, độ tin cậy, về tính khả chuyển và tái sử dụng ii) Yêu cầu về quá trình: yêu cầu đối với quá trình xây dựng sản phẩm như các chuẩn phải tuân theo, các phương pháp thiết kế, ngôn ngữ lập trình iii) Yêu cầu khác: các yêu cầu không thuộc hai nhóm trên như về tính pháp lý, về chi Tài liệu giảng dạy môn: Công nghệ phần mềm 37
phí, về thành viên nhóm phát triển Các yêu cầu phi chức năng thường rất đặc thù với từng khách hàng và do đó khó phân tích và đặc tả một cách đầy đủ và chính xác. Về nguyên tắc, yêu cầu của hệ thống phải vừa đầy đủ vừa không được mâu thuẫn nhau. Đối với các hệ thống lớn phức tạp thì chúng ta khó đạt được hai yếu tố này trong các bước phân tích đầu. Trong các bước duyệt lại yêu cầu cần phải bổ sung, chỉnh lý tư liệu yêu cầu. 2.4.2 Các bước xác định yêu cầu Quá trình thực hiện xác định yêu cầu gồm 2 bước chính như sau: Bước 1: Khảo sát hiện trạng, kết quả nhận được là các báo cáo về hiện trạng. Bước 2: Lập danh sách các yêu cầu, kết quả nhận được là danh sách các yêu cầu sẽ được thực hiện trên máy tính. Đối tượng tham gia xác định yêu cầu gồm 2 nhóm người: Chuyên viên tin học: Những người hiểu rõ về khả năng của máy tính. Họ phải tìm hiểu thật chi tiết về công việc của nhà chuyên môn nhằm tránh sự hiểu nhầm cho những bước phân tích sau này. Nhà chuyên môn: Những người hiểu rõ về công việc của mình. Họ cần lắng nghe ý kiến của các chuyên viên tin học để đảm bảo các yêu cầu của họ là có thể thực hiện được với chi phí và thời gian hợp lý. Hai nhóm người này cần phải phối hợp thật chặt chẽ để có thể xác định đầy đủ và chính xác các yêu cầu. Khảo sát hiện trạng Các chuyên viên tin học sẽ tìm hiểu hiện trạng về các công việc của các nhà chuyên môn. a. Các hình thức thực hiện phổ biến: - Quan sát: Theo dõi các hoạt động đang diễn ra ở thế giới thực có liên quan, có thể tiến hành ghi âm, ghi hình đối với những tình huống mang tính phức tạp, quan trọng, cần sự chính xác cao. - Phỏng vấn trực tiếp: Tổ chức phỏng vấn bắt đầu từ cấp lãnh đạo dần xuống các vị trí công việc. Có thể sử dụng các bảng câu hỏi có sẵn các câu trả lời cho đối tượng được phỏng vấn lựa chọn - Thu thập thông tin, tài liệu: Các công thức tính toán, quy định; các bảng biểu, mẫu giấy tờ có liên quan. b.Quy trình thực hiện: Tìm hiểu tổng quan về thế giới thực: bao gồm Tài liệu giảng dạy môn: Công nghệ phần mềm 38
Quy mô hoạt động. Các hoạt động mà đơn vị có tham gia. Tìm hiểu hiện trạng tổ chức (cơ cấu tổ chức) Người tiến hành khảo sát hiện trạng cần hiểu rõ cơ cấu tổ chức các bộ phận của thế giới thực, đặc biệt là 2 yếu tố trách nhiệm và quyền hạn. Sự hiểu rõ cơ cấu tổ chức giúp xác định bộ phận nào sẽ sử dụng phần mềm để có thể lên kế hoạch tiếp tục khảo sát chi tiết hơn bộ phận đó. Cơ cấu tổ chức bao gồm: Đối nội. Đối ngoại. Các chức danh. Sử dụng các đồ hình để vẽ lại cơ cấu tổ chức. Tìm hiểu hiện trạng nghiệp vụ Thường diễn ra tại các vị trí công việc. Với bộ phận được chọn khảo sát chi tiết, người thực hiện khảo sát cần lập danh sách các công việc mà bộ phận này phụ trách, sau đó tìm hiểu các thông tin chi tiết cho từng công việc. Việc tìm hiểu dựa trên các ý sau: Thông tin đầu vào. Quá trình xử lý. Thông tin kết xuất. Sau đó tiến hành xếp loại các nghiệp vụ vào 4 loại sau nhằm tránh thiếu xót khi tìm hiểu các thông tin: Nghiệp vụ lưu trữ. Nghiệp vụ tra cứu. Nghiệp vụ tính toán. Nghiệp vụ tổng hợp, thống kê Lập danh sách các yêu cầu Để có được danh sách đầy đủ và chính xác các, quá trình lập danh sách các yêu cầu cần theo các bước sau: - Xác định yêu cầu chức năng nghiệp vụ - Xác định yêu cầu chức năng hệ thống - Xác định yêu cầu phi chức năng a. Xác định yêu cầu chức năng nghiệp vụ. Cách tiến hành: Nhà chuyên môn đề xuất và chuyên viên tin học sẽ xem xét lại. Bước Tài liệu giảng dạy môn: Công nghệ phần mềm 39
tiến hành: 1. Xác định bộ phận (người dùng) sẽ sử dụng phần mềm 2. Xác định các công việc mà người dùng sẽ thực hiện trên phần mềm theo từng loại công việc sau: - Lưu trữ - Tra cứu - Tính toán - Kết xuất Lần lượt lập bảng yêu cầu chức năng nghiệp vụ, bảng quy định/công thức và các biểu mẫu cần được mô tả chi tiết. b. Xác định yêu cầu chức năng hệ thống và yêu cầu chất lượng Cách tiến hành: Chuyên viên tin học và nhà chuyên môn cùng đề xuất và cùng xem xét lại các yêu cầu. Bước tiến hành: Bước 1: Xem xét các yêu cầu chức năng hệ thống cơ bản, thông dụng (yêu cầu phát sinh thêm do thực hiện các công việc trên máy tính): Phân quyền, sao lưu, phục hồi, định cấu hình hệ thống Bước 2: Xem xét các yêu cầu chức năng hệ thống chuyên biệt (yêu cầu về các công việc mới, chỉ có thể tiến hành khi thực hiện trên máy tính. Bước 3: Xem xét các yêu cầu về chất lượng theo từng loại tiêu chuẩn sau: - Tiến hóa - Tiện dụng - Hiệu quả - Tương thích Sau đó lập bảng yêu cầu tương ứng. 2.5 Mô hình hóa yêu cầu hệ thống Các mô tả yêu cầu trong giai đoạn xác định yêu cầu chỉ mô tả chủ yếu các thông tin liên quan đến việc thực hiện các nghiệp vụ trong thế giới thực và chưa thể hiện rõ nét việc thực hiện các nghiệp vụ này trên máy tính. Mô tả thông qua các văn bản dễ gây ra nhầm lẫn và không trực quan. Mục tiêu của mô hình hóa: Cho phép chúng ta hiểu một cách chi tiết hơn về ngữ cảnh vấn đề cần giải quyết một cách trực quan và bản chất nhất (thông tin cốt lõi) yêu cầu. Kết quả: Cho một mô hình mô tả lại toàn bộ hoạt động của hệ thống thực. Mỗi phương pháp phân tích đưa ra một kiểu sơ đồ hay mô hình để xây dựng hệ thống. Tài liệu giảng dạy môn: Công nghệ phần mềm 40
Kỹ thuật phân tích là cách tiến hành sao cho thu thập được những yêu cầu của người sử dụng, từ đó trình bày lại nhu cầu đó trên mô hình, chi tiết hóa sơ đồ hay mô hình bằng đặc tả chức năng, đặc tả dữ liệu thông qua phân tích gốc nhìn, phân tích đối tượng, phân tích dữ liệu thu thập được ở các bước trên. Trước khi đi vào tìm hiểu các phương pháp biểu diễn bằng mô hình, chúng ta hãy xem qua một số nguyên lý phân tích. 2.5.1 Các nguyên lý mô hình hóa a. Mô hình hóa miền thông tin (nguyên lý phân tích 1) Phải hiểu và biểu diễn được miền thông tin - Định danh dữ liệu (đối tượng, thực thể) - Định nghĩa các thuộc tính - Thiết lập các mối quan hệ giữa các dữ liệu b. Mô hình hóa chức năng (nguyên lý phân tích 2) Bản chất của phần mềm là biến đổi thông tin - Định danh các chức năng (biến đối thông tin) - Xác định cách thức dữ liệu (thông tin) di chuyển trong hệ thống - Xác định các tác nhân tạo dữ liệu và tác nhân tiêu thụ dữ liệu c. Mô hình hóa hành vi (nguyên lý phân tích 3) Phần mềm (hệ thống) có trạng thái (hành vi) - Xác định các trạng thái hệ thống. Ví dụ giao diện đồ họa, section trong ứng dụng web. - Xác định các dữ liệu làm thay đổi hành vi hệ thống. Ví dụ bàn phím, chuột, các cổng thông tin d. Phân hoạch các mô hình (Nguyên lý phân tích 4) Làm mịn, phân hoạch và biểu diễn các mô hình ở các mức khác nhau - Làm mịn các mô hình dữ liệu - Tạo cây (mô hình) phân rã chức năng - Biểu diễn hành vi ở các mức chi tiết khác nhau e. Tìm hiểu vấn đề bản chất (Nguyên lý phân tích 5) - Nhìn nhận bản chất của yêu cầu - Không quan tâm đến cách thức cài đặt 2.5.2 Sơ đồ phân rã chức năng Sơ đồ phân rã chức năng FDD (Function Decomposition Diagram): Nêu lên các chức năng thông qua việc mô tả các tính chất của đầu vào và đầu ra. - Xác định phạm vi của hệ thống Tài liệu giảng dạy môn: Công nghệ phần mềm 41
- Phân hoạch chức năng - Tạo nền tảng cho thiết kế kiến trúc hệ thống 2.5.3 Sơ đồ luồng dữ liệu Sơ đồ luồng dữ liệu DFD (Data Flow Diagram) Đây là mô hình cho phép xem toàn bộ sơ đồ luồng dữ liệu bên trong hệ thống. Cách thức dữ liệu được xử lý bên trong hệ thống. Có nhiều mức chi tiết khác nhau. Có nhiều biến thể mở rộng khác nhau. 2.5.4 Mô hình bản mẫu (protoype) Khi xác định yêu cầu, nhà phát triển phần mềm dựa trên các ý tưởng hay yêu cầu của khách hàng đưa ra một bản thiết kế sơ bộ một số màn hình giao diện và tiến hành mô phỏng hay giả lập sơ bộ một số chức năng. Có thể xem đây là bước cài đặt bản mẫu đầu tiên và chuyển cho người sử dụng. Bản mẫu này chỉ nhằm để mô tả cách thức phần mềm hoạt động cũng như cách người sử dụng tương tác với hệ thống. Nhằm giúp cho người dùng hình dung được diện mạo ban đầu của yêu cầu mà họ đặt ra. Mô hình này cũng cần có sự hỗ trợ giữa kỹ sư phân tích và kỹ sư thiết kế phần mềm phối hợp thực hiện. Người sử dụng khi xem xét bản mẫu sẽ đưa ra ý kiến đóng góp và phản hồi thông tin đồng ý hay không đồng ý phương án thiết kế của bản mẫu đã đưa ra. Nếu người sử dụng đồng ý với bản mẫu đã đưa thì người phát triển sẽ tiến hành cài đặt thực sự. Ngược lại cả hai phải quay lại giai đoạn xác định yêu cầu. Công việc này được lặp lại liên tục cho đến khi người sử dụng đồng ý với các bản mẫu do nhà phát triển đưa ra. 2.5.5 Mô hình hướng đối tượng Phương pháp phân tích hướng đối tượng hình thành giữa thập niên 80 dựa trên ý tưởng lập trình hướng đối tượng. Phương pháp này đã phát triển, hoàn thiện và hiện nay rất phổ dụng. Nó dựa trên một số khái niệm cơ bản sau: - Ðối tượng (Object): Gồm dữ liệu và thủ tục tác động lên dữ liệu này. - Ðóng gói (Encapsulation): Không cho phép tác động trực tiếp lên dữ liệu của đối tượng mà phải thông qua các phương pháp trung gian. - Lớp (Class): Tập hợp các đối tượng có chung một cấu trúc dữ liệu và cùng một phương pháp. - Kế thừa (Inherrit): Tính chất kế thừa là đặc tính cho phép định nghĩa một lớp mới từ các lớp đã có bằng cách thêm vào đó những dữ liệu mới, các phương pháp mới có thể kế thừa những đặc tính của lớp cũ. a. Mô hình nắm bắt yêu cầu hướng đối tượng bằng UML Mục đích của hoạt động nắm bắt yêu cầu là xây dựng mô hình hệ thống mà sẽ được Tài liệu giảng dạy môn: Công nghệ phần mềm 42
xây dựng bằng cách sử dụng các use-case. Các điểm bắt đầu cho hoạt động này khá đa dạng: - Từ mô hình nghiệp vụ (business model) cho các ứng dụng nghiệp vụ. - Từ mô hình lĩnh vực (domain model) cho các ứng dụng nhúng (embeded) - Từ đặc tả yêu cầu của hệ thống nhúng được tạo bởi nhóm khác hoặc dùng các phương pháp đặc tả khác. - Từ điểm nào đó nằm giữa các điểm xuất phát trên. Mô hình use-case: - Actor: người/ hệ thống ngoài/ thiết bị ngoài tương tác với hệ thống - Use-case: các chức năng có nghĩa của hệ thống cung cấp cho các actor Luồng các sự kiện (flow of events) Các yêu cầu đặc biệt của use-case - Đặc tả kiến trúc - Các thiết kế mẫu giao diện người dùng b. Mô hình phân tích hướng đối tượng với UML Mục đích của hoạt động phân tích yêu cầu là xây dựng mô hình phân tích với các đặc điểm sau: - Dùng ngôn ngữ của nhà phát triển để miêu tả mô hình - Thể hiện gốc nhìn từ bên trong hệ thống - Được cấu trúc từ các lớp phân tích và các gói (package) phân tích - Được dùng chủ yếu cho các nhà phát triển để hiểu cách thức tạo hệ thống. - Loại trừ mọi chi tiết dư thừa, không nhất quán - Phát họa hiện thực các chức năng bên trong hệ thống - Định nghĩa các dẫn xuất use-case, mỗi dẫn xuất use-case cấp phân tích miêu tả sự phân tích 1 use-case. Mô hình phân tích = hệ thống phân tích - Các class phân tích: Lớp biên, lớp thực thể, lớp điều khiển - Các dẫn xuất use-case cấp phân tích: Các lược đồ lớp phân tích, các lược đồ tương tác, luồng sự kiện, các yêu cầu đặc biệt của use-case - Các package phân tích - Đặc tả kiến trúc Lưu ý: Các mô hình hướng đối tượng cho từng giai đoạn phát triển phần mềm được trình bày ở giáo trình khác. Xem chi tiết cụ thể ở giáo trình môn Phân tích thiết kế hướng đối tượng với UML. Tài liệu giảng dạy môn: Công nghệ phần mềm 43
2.5.6 Đặc tả yêu cầu Tài liệu xác định yêu cầu là mô tả hướng khách hàng và được viết bởi ngôn ngữ của khách hàng. Khi đó có thể dùng ngôn ngữ tự nhiên và các khái niệm trừu tượng. Tài liệu đặc tả yêu cầu (đặc tả chức năng) là mô tả hướng người phát triển, là cơ sở của hợp đồng làm phần mềm. Nó không được phép mơ hồ, nếu không sẽ dẫn đến sự hiểu nhầm bởi khách hàng hoặc người phát triển. Chi phí để sửa chữa các sai sót trong phát biểu yêu cầu là rất lớn, đặc biệt là khi các sai sót này được phát hiện khi đã bắt đầu xây dựng hệ thống. Theo một số thống kê thì 85% mã phải viết lại do thay đổi yêu cầu và 12% lỗi phát hiện trong 3 năm đầu sử dụng là do đặc tả yêu cầu không chính xác. Do đó, việc đặc tả chính xác yêu cầu là mối quan tâm được đặt lên hàng đầu. Có hai phương pháp đặc tả là: 1. Đặc tả phi hình thức: Là cách đặc tả bằng ngôn ngữ tự nhiên 2. Đặc tả hình thức: Là cách đặc tả bằng các ngôn ngữ nhân tạo (ngôn ngữ đặc tả), các công thức và biểu đồ. Đặc tả phi hình thức (ngôn ngữ tự nhiên) thuận tiện cho việc xác định yêu cầu nhưng nhiều khi không thích hợp với đặc tả yêu cầu vì: i) Không phải lúc nào người đọc và người viết đặc tả bằng ngôn ngữ tự nhiên cũng hiểu các từ như nhau. ii) Ngôn ngữ tự nhiên quá mềm dẻo do đó các yêu cầu liên quan đến nhau có thể được biểu diễn bằng các hình thức hoàn toàn khác nhau và người phát triển không nhận ra các mối liên quan này. iii) Các yêu cầu khó được phân hoạch một cách hữu hiệu do đó hiệu quả của việc đổi thay chỉ có thể xác định được bằng cách kiểm tra tất cả các yêu cầu chứ không phải một nhóm các yêu cầu liên quan. Các ngôn ngữ đặc tả (đặc tả hình thức) khắc phục được các hạn chế trên, tuy nhiên đa số khách hàng lại không thông thạo các ngôn ngữ này. Hơn nữa mỗi ngôn ngữ đặc tả hình thức thường chỉ phục vụ cho một nhóm lĩnh vực riêng biệt và việc đặc tả hình thức là một công việc tốn kém thời gian. Một cách tiếp cận là bên cạnh các đặc tả hình thức người ta viết các chú giải bằng ngôn ngữ tự nhiên để giúp khách hàng dễ hiểu. 2.5.7 Thẩm định yêu cầu Một khi các yêu cầu đã được thiết lập thì cần thẩm định xem chúng có thỏa mãn các nhu cầu của khách hàng hay không. Nếu thẩm định không được tiến hành chặt chẽ thì các sai Tài liệu giảng dạy môn: Công nghệ phần mềm 44