Giáo trình Nhập môn Công nghệ phần mềm (Phần 1)

131 trang hapham 1880

Download

Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Nhập môn Công nghệ phần mềm (Phần 1)", để 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:

giao_trinh_nhap_mon_cong_nghe_phan_mem_phan_1.pdf

Nội dung text: Giáo trình Nhập môn Công nghệ phần mềm (Phần 1)

Chương 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 1. CÁC KHÁI NIỆM CƠ BẢN 1.1. Phần mềm 1.1.1. Các khái niệm Chương trình máy tính là một trình tự các chỉ thị để hướng dẫn máy tính làm việc nhằm hoàn thành một công việc nào đó do con người yêu cầu. Phần mềm là một hệ thống các chương trình có thể thực hiện trên máy tính nhằm hỗ trợ các nhà chuyên môn trong từng lĩnh vực chuyên ngành thực hiện tốt nhất các thao tác nghiệp vụ của mình. Nhiệm vụ chính yếu của phần mềm là cho phép các nhà chuyên môn thực hiện các công việc của họ trên máy tính dễ dàng và nhanh chóng hơn so với khi thực hiện cùng công việc đó trong thế giới thực. Hoạt động của mọi phần mềm là sự mô phỏng lại các họat động của thế giới thực trong một góc độ thu hẹp nào đó trên máy tính. Quá trình sử dụng một phần mềm chính là quá trình người dùng thực hiện các công việc trên máy tính để hoàn tất một công việc tương đương trong thế giới thực. Lớp phần mềm là hệ thống các phần mềm trên cùng lĩnh vực họat động nào đó. Do cùng lĩnh vực họat động nên các phần mềm này thường có cấu trúc và chức năng (công việc mà người dùng thực hiện trên máy tính) tương tự nhau. Mục tiêu của ngành công nghệ phần mềm là hướng đến không những xây dựng được các phần mềm có chất lượng mà còn cho phép - 1 -
xây dựng dễ dàng một phần mềm mới từ các phần mềm đã có sẵn trong cùng kĩnh vực (thậm chí trong các lĩnh vực khác). STT Lớp phần mềm Các phần mềm 1 Hỗ trợ giải bài tập lượng giác, hình học, giải tích, số học, 2 Trò chơi cờ carô, cờ tướng, cờ vua, xếp hình, 3 Xếp lịch biểu thi đấu, thời khóa biểu, hội nghị, 4 Xét tuyển nhân sự, học sinh lớp 10 5 Bình chọn Sản phẩm, cầu thủ, 6 Quản lý học sinh Mầm non, trung học, trung tâm 7 Bán hàng thuốc tây, vật liệu xây dựng, máy tính 8 Quản lý thuê bao điện, điện thoại, nước, 9 Cho mượn sách, truyện, phim, Bảng 1.1: Các phần mềm và lớp phần mềm tương ứng 1.1.2. Phân loại Phần mềm hệ thống là những phần mềm đảm nhận công việc tích hợp và điều khiển các thiết bị phần cứng đồng thời tạo ra môi trường thuận lợi để các phần mềm khác và người sử dụng có thể thao tác trên đó như một khối thống nhất mà không cần phải quan tâm đến những chi tiết kỹ thuật phức tạp bên dưới như cách thức trao đổi dữ liệu giữa bộ nhớ chính và đĩa, cách hiển thị văn bản lên màn hình, Phần mềm ứng dụng là những phần mềm được dùng để thực hiện một công việc xác định nào đó. Phần mềm ứng dụng có thể chỉ gồm một chương trình đơn giản như chương trình - 2 -
xem ảnh, hoặc một nhóm các chương trình cùng tương tác với nhau để thực hiện một công vịệc nào đó như chương trình xử lý bản tính, chương trình xử lý văn bản, 1.1.3. 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 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: 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 (cân, đo nhiệt độ, tế bào quang học, ) 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 (đóng mở cửa, bật mở máy ) 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 phạm vi giáo trình 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ý (việc mượn sách đã được kiểm tra hợp lệ, bảng lương tháng đã được - 3 -
tính) 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 quy trình ràng buộc trong thế giới thực (chỉ cho mượn tối đa 3 quyển sách, mỗi lớp học có tối đa 50 học sinh, ) Tiến hành xử lý cho ra kết quả mong đợi theo quy định tính toán có sẵn trong thế giới thực (quy tắc tính tiền phạt khi trả sách trễ, quy tắc tính tiền điện, quy tắc trả góp khi mua nhà ) hoặc theo thuật giải tự đề xuất (xếp thời khóa biểu tự động, nén ảnh ) Việc xử lý dựa trên dữ liệu nguồn từ người sử dụng cung cấp (tính nghiệm phương trình bậc 2 dựa trên các hệ số đã nhập) hoặc dữ liệu lưu trữ đã có sẵn (tính tồn kho tháng dựa trên các phiếu nhập xuất đã lưu trữ ) hoặc cả hai (tính tiền phạt dựa trên ngày trả sách được nhập vào và thông tin về loại sách đã được lưu trữ ) 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 (trình bày nghiệm, xuất tiền phạt), hay cùng có thể lưu trữ lại qua thành phần dữ lịêu (sổ sách - 4 -
hiện đang được mượn của một độc giả ) hoặc cả hai (bảng lương, bảng tồn kho ) 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). Bảng 1.2: Danh sách các hàm cùng ý nghĩa tương ứng STT Thành Hàm Ý nghĩa Ghi chú phần 1 Thành Hàm nhập Nhập yêu cầu, Cần xác định phần dữ liệu nguồn. hình thức nhập/ giao Hàm xuất Xuất kết quả xuất và tổ chức diện đã xử lý dữ liệu tương ứng 2 Thành Hàm kiểm Kiểm tra tính Sử dụng hàm phần xử tra hợp lệ của dữ nhập, hàm đọc. lý Hàm xử lý liệu. Sử dụng hàm Xử lý tính nhập, hàm đọc, toán, phát hàm xuất, hàm sinh, biến đổi ghi trên dữ liệu 3 Thành Hàm đọc Đọc dữ liệu từ Cần xác định phần dữ Hàm ghi bộ nhớ phụ cáchh thức tổ liệu vào bộ nhớ chức lưu trữ dữ chính. liệu Ghi dữ liệu từ bộ nhớ chính - 5 -
vào bộ nhớ phụ 1.2. Chất lượng phần mềm 1.2.1. Tính đúng đắn Tính đúng đắn của phần mềm được thể hiện ở chổ sản phẩm đó thực hiện đầy đủ và chính xác các yêu cầu của người dùng. Tính đúng đắn ở đây cần phải hiểu theo nghĩa rộng là chương trình cần phải thực hiện được trong cả những trường hợp mà dữ liệu đầu vào là không hợp lệ. Ví dụ, nếu một trong số các chức năng của phần mềm là sắp xếp một tập tin có số lượng mẫu tin tùy ý theo một cột tùy ý theo chiều tăng hoặc giảm thì những trường hợp sau là vi phạm tính đúng đắn của chương trình: . Không thể thực hiện được (treo máy) khi tập tin rỗng (không có mẫu tin nào). . Không thể thực hiện hoặc thực hiện nhưng cho kết quả sai khi các mẫu tin có hơn 100 cột hoặc có quá nhiều mẫu tin. . Không thể thực hiện hoặc cho kết quả sai khi các cột có chiều dài lớn hơn 125 bytes. . Không thể sắp xếp theo chiều tăng dần . Tính đúng đắn của một sản phẩm phần mềm được xác minh qua các căn cứ sau đây: . Tính đúng đắn của thuật toán. . Tính tương đương của chương trình với thuật toán. Thuật toán có thể đúng nhưng chương trình lập ra không tương đương với thuật toán nên khi thực hiện sẽ cho kết quả sai. . Tính đúng đắn của chương trình có thể được chứng minh trực tiếp trong văn bản của chương trình. - 6 -
. Tính đúng đắn cũng có thể được khẳng định dần qua việc kiểm thử, việc áp dụng chương trình trong một khoảng thời gian dài trên diện rộng và với tần suất sử dụng cao. 1.2.2. Tính tiến hóa Cho phép người dùng có thể khai báo các thay đổi về qui định với phần mềm tùy theo các thay đổi trong thế giới thực liên quan (thay qui định về số sách mượn tối đa, công thức tính tiền phạt, công thức tính tiền điện ) Sản phẩm có thể mở rộng, tăng cường về mặt chức năng một cách dễ dàng. 1.2.3. Tính hiệu quả Tính hiệu quả của một sản phẩm phần mềm được xác định qua các tiêu chuẩn sau: . Hiệu quả kinh tế hoặc ý nghĩa, giá trị thu được do áp dụng sản phẩm đó. . Tốc độ xử lý của phần mềm (v) tính bằng tỉ lệ giữa khối lượng đối tượng cần phải xử lý (m) và tổng thời gian (t) cần thiết để xử lý các đối tượng đó. . Sử dụng tối ưu tài nguyên của máy tính (CPU, bộ nhớ ) 1.2.4. Tính tiện dụng Sản phẩm phải tính đến những yếu tố tâm lý sau đây của người dùng: . Dễ học, có giao diện trực quan tự nhiên. . Dễ thao tác, - 7 -
1.2.5. Tính tương thích Trao đổi dữ liệu với các phần mềm khác có liên quan (nhận danh mục sách từ tập tin Excel, gửi báo cáo tổng kết năm học đến phần mềm WinFax, ) . Giao tiếp nội bộ . Giao tiếp bên ngoài 1.2.6. Tính tái sử dụng Sản phẩm phần mềm có thể áp dụng cho nhiều lĩnh vực theo nhiều chế độ làm việc khác nhau. . Các phần mềm cùng lớp . Các phần mềm khác lớp 1.3. Công nghệ phần mềm 1.3.1. 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 ỏi 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 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 khuyết điểm trong các phần mềm được dùng trong xã hội - 8 -
o Thực hiện không đúng yêu cầu (tính toán sai, không ổn định ) o Thời gian bảo trì, nâng cấp quá lâu, tốn chi phí cao, hiệu quả thấp. o Khó sử dụng o Thực hiện chậm o Khó chuyển đổi dữ liệu giữa các phần mềm o Để giải quyết vấn đề trên một hội nghị đã được triệu tập đề bàn về cách giải quyết. Hội nghị đã tiến hành xem xét, phân tích và xác định nguyên nhân gây ra cuộc khủng hoảng phần mềm. Kết luận như sau: - 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 khuyết điểm 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: o Cảm tính: mỗi người theo một phương pháp riêng. o 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ế ). o 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: 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.3.2. Định nghĩa Công nghệ phần mềm là một 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 - 9 -
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 khái niệm về nó cũng thay đổi theo thời gian. Hơn nữa do đây là một lĩnh vực mới nên các khái niệm vẫn còn phụ thuộc rẩt nhiều vào quan điểm chủ quan của từng người khác nhau. Cụ thể như sau: - 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 làm việc 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 số nhóm kỹ sư. - IEEE[1993]: 1. Việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và được lượng hóa trong phát triển, vận hành và bảo trì phần mềm. 2. Nghiên cứu các phương pháp tiếp cận được dùng trong (1). - 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. - Kawamura[1995]: là lĩnh vực học vấn về các kỹ thuật, phương pháp luận công nghệ học (lý luận và kỹ thuật được hiện thực hóa trên các nguyên lý, nguyên tắc xác định) trong toàn bộ quy trình phát triển phần mềm nhằm nâng cao cả chất và lượng của sản xuất phần mềm. - 10 -
- 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 nghà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ý. Mục tiêu nghiên cứu được chia thành 2 phần rõ nét: 1. Xây dựng phần mềm có chất lượng. 2. Xây dựng phần mềm trong thời gian và chi phí hợp lý. 1.3.3. Đố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 từ giai đoạn trước đó cũng chính là kết quả chuyển giao cho giai đoạn kết 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 chuyên viên 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. - 11 -
2. QUI TRÌNH CÔNG NGHỆ PHẦN MỀM Như đã nói để 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ể. 2.1. Các bước cơ bản trong xây dựng phần mềm 2.1.1. Xác định Đây là bước hình thành bài toán hoặc đề tài. Ở bước này thiết kế trưởng hoặc phân tích viên hệ thống phải biết được vai trò của phần mềm cần phát triển trong hệ thống, đồng thời phải ước lượng công việc, lập lịch biểu và phân công công việc. Bên cạnh đó chúng ta phải biết người đặt hàng muốn gì. Các yêu cầu cần phải được thu thập đầy đủ và được phân tích theo chiều ngang (rộng) và chiều dọc (sâu). Công cụ sử dụng chủ yếu ở giai đoạn này là các lược đồ, sơ đồ phản ánh rõ các thành phần của hệ thống và mối liên quan giữa chúng với nhau. - 12 -
2.1.2. Phát triển Dựa vào các nội dung đã xác định được, nhóm phát triển phần mềm dùng ngôn ngữ đặc tả hình thức (dựa trên các kiến trúc toán học) hoặc phi hình thức (tựa ngôn ngữ tự nhiên) hoặc kết hợp cả hai để mô tả những yếu tố sau đây của chương trình: . Giá trị nhập, giá trị xuất. . Các phép biến đổi . Các yêu cầu cần đạt được ở mỗi điểm của chương trình. Phần đặc tả chỉ quan tâm chủ yếu đến giá trị vào, ra chứ không quan tâm đến cấu trúc và nội dung các thao tác cần thực hiện. Sau bước thiết kế là bước triển khai các đặc tả chương trình thành một sản phẩm phần mềm dựa trên một ngôn ngữ lập trình cụ thể. Trong giai đoạn này các lập trình viên sẽ tiến hành cài đặt các thao tác cần thiết để thực hiện đúng các yêu cầu đã được đặc tả. Công việc cuối cùng của giai đoạn phát triển là chúng ta cần phải chứng minh tính đúng đắn của chương trình sau khi đã tiến hành cài đặt. Tuy nhiên thông thường ở bước này chúng ta coi các chương trình như những hộp đen. Vấn đề đặt ra là xây dựng một cách có chủ đích các tập dữ liệu nhập khác nhau để giao cho chương trình thực hiện rồi dựa vào kết quả thu được để đánh giá chương trình. Công việc như trên được gọi là kiểm thử chương trình. Công việc kiểm thử nhằm vào các mục tiêu sau: . Kiểm tra để phát hiện lỗi của chương trình. Lưu ý rằng kiểm thử không đảm bảo tuyệt đối tính đúng - 13 -
đắn của chương trình do bản chất quy nạp không hoàn toàn của cách làm. . Kiểm tra tính ổn định, hiệu quả cũng như khả năng tối đa của chương trình. Tùy theo mục đích mà người ta thiết kế các tập dữ liệu thử sao cho có thể phủ hết các trường hợp cần quan tâm. 2.1.3. Bảo trì (Vận hành) Công việc quản lý việc triển khai và sử dụng phần mềm cũng là một vấn đề cần được quan tâm trong qui trình phát triển phần mềm. Trong quá trình xây dựng phần mềm, toàn bộ các kết quả phần tích, thiết kế, cài đặt và hồ sơ liên quan cần phải được lưu trữ và quản lý cẩn thận nhằm đảm bảo cho công việc được tiến hành một cách hiệu quả nhất và phục vụ cho công việc bảo trì phần mềm về sau. Như vậy công việc quản lý không chỉ dừng lại trong quá trình xây dựng phần mềm mà trái lại còn phải được tiến hành liên tục trong suốt quá trình sống của nó. 2.2. Một số mô hình triển khai xây dựng phần mềm Có nhiều mô hình 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. Trong phần tiếp theo của giáo trình chúng ta sẽ tìm hiểu qua các mô hình phát triển phần mềm tiêu biểu nhất đang được áp dụng. 2.2.1. 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 chia quá trình phát triển phần mềm thành - 14 -
những giai đoạn tuần tự nối tiếp nhau. 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 sau. 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: o 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). o 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 - 15 -
trung gian mới giữa xác định yêu cầu và lập trình (có sửa đổi) o 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) o 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ụ. o 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 - 16 -
- 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) o 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) o 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) - 17 -
. 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. o 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ụ. o 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 5 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 - 18 -
sau giai đoạn lập trình nhằm tăng cường độ tin cậy của phần mềm. o 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) o 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. o Thiết kế: Được tiến hành ngay sau khi kết thúc việc phân tích. - 19 -
- 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ụ. o 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). o 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). o Bảo trì: 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ế. - 20 -
- 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àng - 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. 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 tuyên bố 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. 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. - 21 -
2.2.2. Mô hình bản mẫu phần mềm Tương tự như mô hình thác nước với bổ sung vào các giai đoạn thực hiện phần mềm mẫu ngay khi xác định yêu cầu nhằm mục tiêu phát hiện nhanh các sai sót về yêu cầu. Các giai đoạn trong mô hình bản mẫu phần mềm có thể tiến hành lặp đi lặp lại chứ không nhất thiết phải theo trình tự nhất định. Ngay sau khi giai đoạn xác định yêu cầu, nhà phát triển phần mềm đưa ra ngay một bản thiết kế sơ bộ và tiến hành 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 để miêu 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. Người sử dụng sau khi xem xét sẽ phản hồi thông tin cần thiết lại cho nhà phát triển. 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. Như vậy đây là một hướng tiếp cận tốt khi các yêu cầu chưa rõ ràng và khó đánh giá được tính hiệu quả của các thuật toán. Tuy nhiên, mô hình này cũng có nhược điểm là tính cấu trúc không cao do đó khách hàng dễ mất tin tưởng. - 22 -
2.2.3. Mô hình xoắn ốc Mô hình này chính là sự kết hợp của mô hình bản mẫu thiết kế và mô hình thác nước được lặp lại nhiều lần. Ở lần lặp tiếp theo hệ thống sẽ được tìm hiểu và xây dựng hoàn thiện hơn ở lần lặp trước đó. Ở mỗi lần lặp các yêu cầu của người sử dụng sẽ được hiểu ngày càng rõ ràng hơn và các bản mẫu phần mềm cũng ngày một hoàn thiện hơn. Ngoài ra ở cuối mỗi lần lặp sẽ có thêm công đoạn phân tích mức độ rủi ro để quyết định xem có nên đi tiếp theo hướng này nữa hay không. - 23 -
Mô hình này phù hợpvới các hệ thống phần mềm lớn do có khả năng kiểm soát rủi ro ở từng bước tiến hóa. Tuy nhiên vẫn chưa được sử dụng rộng rãi như mô hình thác nước hoặc bản mẫu do đòi hỏi năng lực quản lý, năng lực phân tích rủi ro cao. 3. CÁC PHƯƠNG PHÁP XÂY DỰNG PHẦN MỀM 3.1. Tổng quan 3.1.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 và khuyết điểm riêng và phù hợp với từng loại phần mềm cụ thể. - 24 -
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 quy trình xây dựng phần mềm. Bên cạnh đó mỗi phương pháp cũng sẽ quy đị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 quy đị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. 3.1.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 và theo dõi kế hoạch triển khai. Trong phần tiếp theo của giáo trình này, chúng ta chỉ quan tâm đến các phương pháp xây dựng. Về phương pháp tổ chức quản lý chúng ta có thể tham khảo trong giáo trình “Quản lý dự án xây dựng các hệ thống thông tin”. - 25 -
3.2. Các phương pháp xây dựng phần mềm 3.2.1. Cách tiếp cận a) Từ trên xuống Đâ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 đạ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à 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ó. 3.2.2. 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 . - 26 -
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 hà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. Hình dưới: Minh họa cách tiếp cận theo hướng chức năng. 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 trong 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). - 27 -
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. DFD sử dụng các ký hiệu sau để mô tả hệ thống: Ô vuông có góc tròn được dùng để biểu diễn các chức năng của hệ thống. Ô vuông dùng để biểu diễn thành phần dữ liệu trong hệ thống. Hình tròn dùng để biểu diễn các thành phần bên ngoài có giao tiếp với hệ thống. Dấu mũi tên dùng để biểu diễn hướng di chuyển của dữ liệu. Các từ khóa “and” và “or” dùng để liên kết các dòng dữ liệu khi cần thiết. 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: - 28 -
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ết 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: 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. Các thực thể được biểu diễn trong sơ đồ bằng các - 29 -
hình vuông cùng với tên và có thể có thêm các thuộc tính của thực thể. Mối kết hợp biểu diễn sự kết hợp giữa hai hay nhiều thực thể. Mỗi mối kết hợp gồm có ba thành phần cơ bản: . Mối kết hợp giữa các thực thể được biểu diễn băng một đường thẳng nối giữa hai thực thể. . Tên của môi liên hệ dùng để miêu tả ý nghĩa của mối liên hệ. . Bản số ở hai đầu của mối kết hợp dùng để xác định con số tối đa và tối thiểu các thực thể liên quan đến mối kết hợp. 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 được phải thực hiện thông qua giao diện của đối tượng. Điều này giúp chúng ta - 30 -
đả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ốnng ký hiệu UML. 4. CÔNG CỤ VÀ MÔI TRƯỜNG PHÁT TRIỂN PHẦN MỀM 4.1. Mở đầu 4.1.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 quy 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. 4.2. Phần mềm hỗ trợ thực hiện các giai đoạn 4.2.1. Phần mềm hỗ trợ phân tích - Công việc hỗ trợ chính - 31 -
o Soạn thảo các mô hình thế giới thực o Ánh xạ vào mô hình logic - Các phần mềm: WinA&D, Analyst Pro, 4.2.2. Phần mềm hỗ trợ thiết kế - Công việc hỗ trợ chính o Soạn thảo các mô hình logic o Ánh xạ vào mô hình vật lý - Các phần mềm: QuickUML, Power Designer, Oracle Designer 4.2.3. Phần mềm hỗ trợ lập trình - Công việc hỗ trợ chính o Quản lý các phiên bản (Dữ liệu, chương trình nguồn, giao diện) o Biên dịch - Các phần mềm: Visual Studio, Visual Basic, Visual C++ 4.2.4. Phần mềm hỗ trợ kiểm chứng - Công việc hỗ trợ chính o Phát sinh tự động các bộ dữ liệu thử nghiệm o Phát hiện lỗi - Các phần mềm: WinRuner 4.3. Phần mềm hỗ trợ tổ chức, quản lý việc triễn khai 4.3.1. Xây dựng phương án - Công việc hỗ trợ chính o Tạo lập phương án o Dự đoán rủi ro o Tính chi phí - Các phần mềm: MS Project, Visio 4.3.2. Lập kế hoạch - Công việc hỗ trợ chính o Xác định các công việc - 32 -
o Phân công o Lập lịch biểu o Theo dõi thực hiện - Các phần mềm: MS Project, Visio - 33 -
Chương 2: PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 1. Tổng quan Phân tích yêu cầu là khâu kỹ thuật đầu tiên gồm nhiều bước nhỏ: nghiên cứu khả thi, phân tích mô hình hóa, đặc tả thẩm định yêu cầu. Gia đoạn này được tiến hành phối hợp giữa bên phát triển và khách hàng và nó có vai trò đặc biệt quan trọng trong tiến trình phát triển phần mềm. Đây là bước hình thành bài toán hoặc đề tài. Ở bước này trưởng nhóm thiết kế và người phân tích hệ thống phải biết được người đặt hàng muốn gì. Các yêu cầu phải được thu thập đầy đủ và được phân tích theo chiều ngang (rộng) và dọc (sâu). Công cụ sử dụng chủ yếu ở giai đoạn này là các lược đồ, sơ đồ phản ánh rõ các đối tượng của hệ thống: lưu đồ (Flowchart), sơ đồ dòng dữ liệu (Data Flow diagram DFD), mạng thực thể-quan hệ (Entity-Relationship Network), sơ đồ cấu trúc phân cấp (Structural hierarchical schemes), mạng ngữ nghĩa (Semantic Network) 1.1 Quá trình phân tích 1.1.1 Phân tích phạm vi dự án 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 - 34 -
nghiệp vụ: 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: 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 mô đun 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 dự án đượ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. 1.1.2 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 nhiệm cụ thể trong nghiệp vụ của khách hàng. Ví dụ. lưu vết quá trình đầu tư.Một tác vụ như kiểm soát đầu tư 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 - 35 -
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 luật 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, hay bug-free. 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 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. Ví dụ: khi khách hàng quyết định ứng dụng phải sẵn sàng 23 giờ trong ngày, bỏ qua thời gian vận hành không giảm. Chất lượng khác bao gồm số người dùng truy cập hiện hành, thời gian tối đa phải chờ để hoàn thành công việc trong ứng dụng (sự phản hồi), độ bảo mật ứng dụng, hay hơn nữa. 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 đang được cài trên máy của người 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 - 36 -
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. Ví dụ, chức năng của chương trình kế toán lưu trữ dữ liệu nhỏ như CSDL hướng đến tập tin Access. Để tạo dữ liệu truy xuất hiệu quả hơn và thõa mãn yêu cầu của giải pháp mới, chúng ta mới chuyển toàn bộ dữ liệu sang hệ quản trị csdl SQL Server. 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. 1.1.3.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 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. - 37 -
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 Độ 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, ứng dụnng phải “login” để 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 - 38 -
này đòi hỏi thay đổi CSDL 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 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 mạng WAN 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. Lưu ý: Chúng ta lên kế hoạch cho điều kiện khẩn cấp – phải làm gì nếu csdl bảo mật bị ngắt hay nếu việc tạo bản sao bị hỏng. Đối với hệ thống bảo mật bị hỏng, chúng ta cũng nên có cả hai kế hoạch khẩn cấp và thủ tục tự động chú ý đến những vấn đề chung như mạng bị hỏng. d. 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 - 39 -
cơ sở thường xuyên, đưa ra những đề nghị nếu có bất kỳ điều nghi ngờ. e. 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 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 đó 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. f. 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. 1.1.4.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 chạy nhanh ứng dụng thiết kế tốt có thể mang lại giá trị 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, - 40 -
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 (TPM) 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 mỗi giây. Khả năng chứa:Lượng lưu trữ- cả 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. RAM đòi hỏi của ứng 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 làm nâng tốc độ phù hợp. Chúng ta có thể nhận biết nút thắt bằng cách sử dụng công cụ báo cáo hệ thống như Màn hình điều khiển tốc độ trên Window NT (Windows NT Performance Monitor). 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 - 41 -
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: 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. 1.1.5 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 debug 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. - 42 -
1.1.6 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 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. Một cách đạt những khả năng hạn định là lưu trữ thông tin quy 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 đó, nếu số quan trong hay thủ tục thay đổi, nó có thể thay đổi trong CSDL 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 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. 1.1.7. 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. - 43 -
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. Không có ứng dụng nào là không có lỗi, ứng dụng phải được bảo lưu để chúng có thể hoạt động thậm chí khi bug xảy ra trong một phần của chương trình. Thí 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 WAN, LAN 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, 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 down ứng dụng. Những hệ thống trọng yếu, giá trị đối với công ty ở bất kỳ thời điểm down nào hoàn toàn điều chỉnh chi phí thiết kế 100 % ứng dụng sẵn sàng. Ứng dụng khác đơn giản cần trở nên sẵn sàng hầu hết mọi lúc. 1.1.8. 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 kinh nghiệm gì mà chúng ta muốn người dùng có. Với bất cứ ứng dụng nào khác, kinh nghiệm người dùng càng tốt thì chi phí càng cao. 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 - 44 -
cần điều tiết người dùng qua việc điều tiết nghe và nhìn, hay người dùng nói tiếng nước ngoài. 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. Xem xét mức độ chuyên nghiệp giữa người dùng. Với chuyên viên học nhanh hơn với giao diện thiết kế tốt và trợ giúp trực tuyến Help online. Người dùng với kỹ năng kém hơn để tăng tốc qua sử dụng wizard, trợ giúp online, hay chỉ dẫn. Huấn luyện khách hàng trong ứng dụng cũng nên cân nhắc chọn lựa. 1.1.9. 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 CSDL tồn tại, hay việc chuyển đổi dữ liệu cũ sang khuôn dạng mới, bạn 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 csdl (ODBC), 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. Kỹ thuật dữ liệu mới hay vậ lý đưa nhu cầu cải thiện CSDL bên dưới ứng dụng. Những cải tiến phải được cẩn thận bởi chúng phá vở tất cả mã nguồn CSDL 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. 1.1.10. 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 - 45 -
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ụ. Hiểu được vấn đề hợp lệ dưới mỗi tiến trình có thể ngăn bạn gây ra lỗi một cách ngây ngô dẫn đến tranh chấp. Hiểu được cấu trúc tổ chức và sơ đồ làm việc nghiệp vụ là quyết định. Không hiểu rõ ràng sơ đồ tổ chức, không thể đem lại sự chấp thuận phù hợp cho thiết kế ứng dụng của chúng ta hay thông tin theo kíp trên thiết kế hay những vấn đề triển khai. Đồ hình tổ chức cũng giúp cho tìm kiếm thông tin người ẩn danh phản hồi lại chức năng của ứng dụng mà không dùng bất của chính họ. 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 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ế. Chúng at cũng đòi hỏi chắc chắn kế hoạch được kết chặt với ngân sách 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. 1.1.11.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 web như Internet thì sự thành công đồng nghĩa với tăng nhu cầu. Ứng dụng phải - 46 -
được thiết kế có quy mô- nó phải hỗ trợ nâng cấp cho phép phục vụ nhiều người hơn. 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. 1.2 Xác định yêu cầu Mục tiêu của việc xác định yêu cầu: Xác định thật chính xác và đầy đủ các yêu cầu đặt ra cho phần mềm sẽ được xây dựng. Kết quả nhận được sau giai đoạn xác định yêu cầu: 1. Danh sách các công việc sẽ được thực hiện trên máy tính 2. Những mô tả chi tiết về các công việc này khi được thực hiện trong thế giới thực. Qua đó bước đầu hình thành thông tin khái quát về các hoạt động trong thế giới thực. - 47 -
1.2.1 Yêu cầu và mô tả yêu cầu . Yêu cầu (hay yêu cầu phần mềm) là công việc muốn thực hiện trên máy tính. Những công việc này phải xuất phát từ thực tế chứ không thuần túy tin học . Mô tả yêu cầu là mô tả đầy đủ các thông tin liên quan đến công việc tương ứng. Các mô tả này dùng làm cơ sở để nghiệm thu và đánh giá phần mềm khi được chuyển giao. Các yêu cầu của phần mềm cần được mô tả thật rõ ràng, cụ thể, đầy đủ và chính xác các thông tin liên quan đến công việc tương ứng. Việc mô tả sơ sài, mơ hồ yêu cầu phần mềm sẽ dẫn đến việc hiểu nhầm giữa chuyên viên tin học (người thực hiện phần mềm) và khách hàng (người đặt hàng thực hiện phần mềm). Nhiều công sức và chi phí phải hao tốn do các hiểu nhầm như thế. Các loại thông tin chính cần được quan tâm khi xác định yêu cầu phần mềm: . Tên công việc ứng với từng yêu cầu . Người hoặc bộ phận sẽ thực hiện công việc . Địa điểm thực hiện công việc . Thời gian thực hiện công việc . Cách thức tiến hành công việc cùng với các quy định liên quan Sau đây, từng loại thông tin sẽ lần lượt được xem xét chi tiết: a. Tên công việc. Cần xác định cụ thể, tránh dùng các tên chung chung, mơ hồ Ví dụ: xét một số tên công việc sau: - 48 -
Quản lý độc giả: chung chung, mơ hồ; cụ thể như việc đăng ký mượn sách, gia hạn thẻ độc giả, trả sách Quản lý sách: chung chung, mơ hồ; cụ thể như nhập sách vào kho, tra cứu sách, cho mượn sách, nhận trả sách, thanh lý sách. b. Người thực hiện. Cần xác định chính xác người hoặc bộ phận sẽ thực hiện công việc trên máy tính (còn gọi là người dùng phần mềm hay người dùng). Những người dùng có vai trò và công việc thực hiện tương tự như nhau sẽ được xếp vào cùng một loại người dùng (thông thường một loại người dùng sẽ tương ứng với một bộ phận trong thế giới thực). Cùng một công việc có thể có nhiều loại người dùng khác nhau thực hiện và ngược lại, một loại người dùng có thể thực hiện nhiều công việc khác nhau. c. Thời gian, địa điểm. Cần xác định chính xác địa điểm, thời điểm tiến hành công việc. Các thông tin này sẽ có ý nghĩa nhất định trong một số trường hợp đặc thù. d. Cách thức tiến hành và các quy định liên quan. Đây là phần chính yếu khi tiến hành mô tả yêu cầu. Đối với loại thông tin này cần đặc biệt quan tâm đến một số yếu tố sau: i. Các quy định cần kiểm tra khi thực hiện công việc ghi nhận thông tin Ví dụ: Quy định về việc mượn sách khi cho độc giả mượn sách: chỉ cho mượn sách đối với những độc giả có thẻ - 49 -
độc giả còn hạn, số sách đang mượn chưa đến 2 và không có sách mượn quá hạn. Ví dụ: Quy định tính hợp lệ của phân số trong việc ghi nhận đề bài của giáo viên và bài giải của học sinh: phân số phải có mẫu số khác 0 ii. Các quy định, công thức tính toán khi thực hiện công việc tính toán Ví dụ: Quy định tính tiền phạt trả sách trễ khi thực hiện việc trả sách: mỗi ngày trả trễ phạt 1500 đồng/ngày. Từ ngày trả trễ thứ 10 trở đi sẽ phạt 5000 đồng/ngày và thu hồi thẻ độc giả 2 tuần. Ví dụ: Quy định tiền lương khi thực hiện công việc tính lương nhân viên cho 1 công ty *Lương của nhân viên thuộc bộ phận văn phòng được tính theo công thức: Tiền_Lương = (Số_Ngày * Mức_Lương )/22 + Tiền_Thưởng + Tiền_Phạt mỗi ngày làm thêm thưởng 30.000 mỗi ngày nghỉ việc phạt 50.000 *Lương của nhân viên thuộc bộ phận sản xuất được tính theo công thức: Tiền_Lương = Số_Sản_Phẩm * Đơn_Giá Biết rằng một sản phẩm phải trải qua 3 công đoạn sản xuất: công đoạn 1: 200 đồng/sản phẩm công đoạn 2: 400 đồng/sản phẩm công đoạn 3: 300 đồng/sản phẩm 1.2.2 Phân loại yêu cầu - 50 -
Sơ đồ cây phân loại yêu cầu : YÊU CẦU (1) (2) Yêu cầu chức năng Yêu cầu phi chức năng (3) (4) (5) (6) Yêu cầu chức Yêu cầu chức Liên quan đến Liên quan đến năng nghiệp vụ năng hệ thống người dùng chuyên viên tin học (7) Lưu trữ (11) Môi trường (16) Tính tiến hóa (20) Tính tái sử dụng (8) Tra cứu (12) Mô phỏng (17) Tính tiện dụng (21) Tính bảo trì (9) Tính toán (13) Tự động (18) Tính hiệu quả (10) Kết xuất (14) Phân quyền (19) Tính tương thích (15) Sao lưu 51
Đặc tả chi tiết từng loại yêu cầu: (1) Yêu cầu chức năng là danh sách các công việc sẽ được thực hiện trên máy tính cùng với các thông tin mô tả tương ứng. (2) Yêu cầu phi chức năng là các yêu cầu liên quan đến chất lượng phần mềm, là sự ràng buộc cách thức thực hiện các yêu cầu chức năng. (3) Yêu cầu chức năng nghiệp vụ là các chức năng của phần mềm tương ứng với công việc có thật trong thế giới thực. (4) Yêu cầu chức năng hệ thống là các chức năng phần mềm được phát sinh thêm khi thực hiện công việc trên máy tính thay vì trong thế giới thực hoặc các chức năng không tương ứng với bất kỳ công việc nào trong thế giới thực. (5) Chức năng lưu trữ: Tương ứng với công việc ghi chép thông tin trên sổ sách (kèm theo các quy định khi ghi chép). Ví dụ: - Ghi nhận việc cho mượn sách của một thư viện theo quy định mượn. - Ghi nhận bài giải bài tập về phân số theo quy định về phân số,cách biến đổi phân số tương đương, các phép tính trên phân số, (6) Chức năng tra cứu: Tương ứng với công việc tìm kiếm, theo dõi hoạt động và xem thông tin về một đối tượng. Ví dụ: - Tìm tài khoản và xem tình hình gửi rút. - Tìm sách và xem tình trạng sách - Tìm hàng hóa và xem tình trạng của hàng hóa (số lượng tồn kho, lượng nhập, thời gian nhập,). - Tìm bài giảng lý thuyết về phương trình, bất phương trình và xem nội dung tương ứng. 52
(7) Chức năng tính toán: Tương ứng với công việc tính toán (theo quy định và công thức cho trước). Ví dụ: - Tính điểm trung bình môn học của học sinh theo quy định hệ số cho các đợt kiểm tra. - Xếp thứ hạng cho các đội bóng sau một lượt thi đấu theo quy định của ban tổ chức giải. - Tính tiền phạt trả sách trễ theo quy định phạt của thư viện. - Tìm nghiệm của phương trình bậc hai theo phương pháp giải phương trình bậc hai. (8) Chức năng kết xuất : Tương ứng với công việc lập báo cáo (theo biểu mẫu cho trước) Ví dụ: - Lập bảng xếp hạng các đội bóng sau một lượt đấu. - Lập báo cáo thống kê về số lượt mượn sách theo từng thể loại trong năm. - Lập báo cáo thống kê về tỷ lệ xếp loại học sinh theo từng lớp, từng khối. (9) Chức năng môi trường : Định cấu hình thiết bị, ngày giờ, số người làm việc, Ví dụ: Số lượng người làm việc, chọn loại máy in, khổ giấy, niên khóa hiện hành, (10) Chức năng mô phỏng: Mô phỏng hoạt động của thế giới thực Ví dụ: - Mô phỏng một tai nạn máy bay, xe ô tô, trận động đất (11) Chức năng tự động: Tự động thông báo, nhắc nhở người dùng. Ví dụ: 53
- Nhắc nhở thủ thư gửi giấy báo đòi sách khi có độc giả mượn quá hạn. - Báo động khi khách hàng thiếu nợ quá lâu hay số tiền nợ quá lớn. (12) Chức năng phân quyền : Phân quyền sử dụng giữa các loại người dùng. Ví dụ: Phân quyền cho 3 loại người sử dụng trong phần mềm quản lý thư viện: + Quản trị hệ thống: có quyền sử dụng tất cả các chức năng. + Thủ thư: chỉ sử dụng các chức năng liên quan đến việc cho mượn và trả sách. + Độc giả: chỉ sử dụng chức năng tra cứu. Trong phần mềm quản lý bán hàng, việc phân chia khả năng truy cập dữ liệu nhập xuất cho từng nhóm người sử dụng sẽ tránh việc điều chỉnh số liệu không thuộc phạm vi quản lý của người sử dụng như nhân viên thu ngân chỉ được phép lập và điều chỉnh các hóa đơn bán hàng trong ca làm việc của mình. Ca trưởng và bộ phận quản lý quầy có thể tham khảo lượng hàng tồn kho nhưng không được phép điều chỉnh lượng hàng nhập, không được tham khảo vốn hàng xuất, kết quả kinh doanh, (13) Chức năng sao lưu : Sao lưu, phục hồi dữ liệu. Ví dụ: Sao lưu thông tin về các học sinh đã ra trường và chỉ phục hồi lại khi cần thiết (14) Tính tiến hóa: đây là các yêu cầu liên quan đến việc cho phép người dùng thay đổi lại cách mô tả của một yêu cầu chức năng (các quy định, quy tắc tính toán), một biểu mẫu nào đó khi đang dùng phần mềm đã được chuyển giao. Điều này đòi hỏi phải có dự kiến về các thay đổi trên thành phần dữ liệu và xử lý. 54
Ví dụ: - Cho phép thay đổi quy định về số sách cho mượn tối đa, hay mức phạt khi trả trễ. - Cho phép thay đổi các biên trong quy định về xếp loại học sinh. (15) Tính tiện dụng: là các yêu cầu liên quan đến hình thức giao diện của phần mềm, thể hiện ở sự tự nhiên, dễ sử dụng, dễ học, đầy đủ thông tin, Ví dụ: - Giao diện nhập hóa đơn bán hàng dạng form, dòng nhập thể hiện bằng ô sáng và báo lỗi khi số liệu nhập làm số lượng tồn kho âm (phần mềm quản lý hàng hóa). (16) Tính hiệu quả : đây là yêu cầu liên quan đến thời gian thực hiện các chức năng phần mềm, dung lượng lưu trữ, chi phí sử dụng tài nguyên hệ thống như sử dụng tối ưu các không gian, thao tác thực hiện nhanh Ví dụ: Thời gian tra cứu sách, tra cứu độc giả không quá 10 giây. (17) Tính tương thích: là các yêu cầu liên quan đến việc chuyển đổi dữ liệu giữa phần mềm đang xét và các phần mềm khác, sự nhất quán giữa các màn hình trong hệ thống. Ví dụ: - Cho phép chuyển tất cả các báo cáo sang định dạng file Excel - Cho phép nhập thông tin sách mới từ tập tin Excel hay từ thiết bị đọc mã vạch. - Cho phép thực hiện chức năng bằng giọng nói. (18) Tính tái sử dụng: (do chuyên viên tin học đảm trách) 55
(19) Tính bảo trì: (do chuyên viên tin học đảm trách) là các yêu cầu cho phép thay đổi mà không làm ảnh hưởng đến phần mềm 56
1.2.3 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 hai 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 hai 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ý. 57
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. Sau đây, chúng ta sẽ phân tích chi tiết từng bước quy trình thực hiện. 1.2.3.1 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. Ví dụ: - Ghi hình quá trình giao dịch của một nhân viên ngân hàng với khách hàng tại một ngân hàng X. - Quan sát thao tác cho mượn sách của một thủ thư tại một thư viện Y  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ó ít nhiều liên quan. Ví dụ: - Mẫu hóa đơn và các quy định lập hóa đơn bán hàng tại một cửa hàng Y. - Phiếu mượn sách tại thư viện của trường đại học Z. b.Quy trình thực hiện: . Tìm hiểu tổng quan về thế giới thực: bao gồm 58
- 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 (Ví dụ: nhân viên nhập liệu, thủ thư, nhân viên bán hàng, ). 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 (thông tin mô tả yêu cầu phần mềm). 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. 59
- Nghiệp vụ tổng hợp, thống kê 1.2.3.2 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ầu 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 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 mô tả chi tiết – như sau: *Mẫu 1:Bảng yêu cầu chức năng nghiệp vụ Bộ phận (người thực hiện): Mã số: 60
S Công Loại Quy định/ Biểu mẫu Ghi T việc công Công thức liên quan chú T việc liên quan 1 2 *Mẫu 2:Bảng Quy định/ Công thức liên quan stt Mã số Tên Quy định/ Mô tả chi tiết Ghi chú Công thức 1 QĐ 1 2 QĐ 2 * Các biểu mẫu được mô tả chi tiết ngay sau bảng quy định/Công thức 61
Ví dụ: Xét phần mềm quản lý thư viện Bộ phận: Thủ thư. Mã số: TT stt Công việc Loại công Quy định/Công thức liên quan Biểu mẫu Ghi việc liên quan chú 1 Cho mượn Lưu trữ TT_QĐ 1 TT_BM 1 sách 2 Nhận trả Lưu trữ Chỉ nhận lại những sách đã cho mượn TT_BM 1 sách 3 Tính tiền Tính toán Mỗi ngày trả trễ phạt : phạt - 1000 đồng/ngày : từ ngày thứ nhất đến ngày thứ 5 - 3000 đồng/ngày : từ ngày thứ 6 trở đi. 4 Tính tiền đền Tính toán Tiền đền cho sách bị mất dựa trên giá thị trường tại thời điểm hiện hành. 62
5. Tra cứu sách Tra cứu Việc tìm sách dựa trên các thông tin : tên sách, tên tác giả, nhà xuất bản, năm xuất bản 6. Gửi giấy báo Kết xuất Sách mượn quá hạn 3 ngày sẽ tự động gửi TT_BM 2 đòi sách giấy báo cho đến khi sách được trả hoặc đã tính xong tiền đền sách Bảng yêu cầu chức năng nghiệp vụ stt Mã số Tên Quy Mô tả chi tiết Ghi chú định/ Công thức 1 QĐ 1 Quy định cho Chỉ cho mượn sách khi : Độc giả mượn sách sẽ phải mượn sách - Thẻ độc giả còn hạn gửi lại thẻ độc giả tại bộ - Độc giả chưa mượn hết số sách phận bạn đọc, nhận phiếu quy định mượn sách (TT_BM 1, tìm - Độc giả không có sách mượn kiếm mã số sách mượn và quá hạn điền các sách cần mượn vào - Sách hiện không có người mượn phiếu, xong gửi cho thủ thư. 63
Bảng Quy định/ Công thức liên quan TT_BM 1: PHIẾU MƯỢN SÁCH Số thẻ: Số phiếu mượn: Họ và tên: Ngày mượn: []Mượn về nhà [] Đọc tại chỗ STT Mã sách Tên sách Tác giả Mã loại 1 2 Ngày tháng năm TT_BM 2: GIẤY BÁO MƯỢN SÁCH QUÁ HẠN Thân gửi: ___ Địa chỉ: ___ Chúng tôi xin thông báo rằng, anh (chị) đã mượn của thư viện chúng tôi những quyển sách sau: STT Mã sách Tên sách Ngày mượn Đến hôm nay đã quá hạn 1 2 Vậy thông báo anh(chị) vui lòng đem sách đến trả. Và mang theo số tiền ___ đồng để trả phí sách trễ. 64
Bộ phận: Độc giả. Mã số: ĐG stt Công việc Loại Quy định/ Công thức Biểu mẫu liên Ghi chú công liên quan quan việc 1 Tìm sách Tra cứu Việc tìm sách dựa trên các thông tin: tên sách, tên tác giả, nhà xuất bản, năm xuất bản 2 Đăng ký Lưu trữ Độc giả phải có thẻ TT_BM 1 Mọi độc giả có thẻ mượn mượn độc giả. sách đều có thể đăng ký sách mượn sách. Tuy nhiên, hệ thống sẽ thông báo khi thẻ mượn sách của độc giả đã hết hạn sử dụng. Bộ phận: Quản lý độc giả. Mã số : QLĐG 65
stt Công Loại Quy định/ Công thức liên Biểu mẫu Ghi chú việc việc quan liên quan 1 Làm thẻ Lưu Chỉ cấp thẻ độc giả có độ QLDG_B Độc giả có yêu cầu làm thẻ độc giả trữ tuổi từ 18 trở lên và có M 1 mượn sách sẽ được nhận mới chứng minh thư. QLDG_B phiếu đăng ký để điền Lệ phí làm thẻ độc giả là M 2 thông tin vào (QLDG_BM 5000 đồng/thẻ. 1), sau đó bộ phận quản lý độc giả tiến hành cấp thẻ Một số chứng minh thư chỉ và thu lệ phí theo quy định có thể có duy nhất một thẻ (QLDG_BM 2) độc giả 2 Gia hạn Lưu Gia hạn thẻ theo yêu cầu của thẻ độc trữ độc giả và thời gian quá hạn giả không được quá 3 tháng. Sau thời gian 3 tháng, những thẻ hết hạn sẽ bị hủy. 3 Huỷ thẻ Lưu Hủy bỏ các thẻ độc giả đã độc giả trữ quá hạn đăng ký 3 tháng. 66
QLDG_BM 1: PHIẾU ĐĂNG KÝ LÀM THẺ MƯỢN SÁCH Họ và tên: ___ Năm sinh: ___ Địa chỉ thường trú: ___ Nghề nghiệp: ___ Ngày đăng ký: ___ QLDG_BM 2: THẺ ĐỘC GIẢ Họ và tên: ___ Trường: ___ Lớp: ___ Địa chỉ: ___ Ngày ___ tháng ___ năm ___ 67
Bộ phận: Quản lý sách. Mã số: QLS stt Công việc Loại Quy định/ Công Biểu mẫu Ghi chú thức liên quan liên quan 1. Nhận sách mới Lưu trữ QLS_BM 1 Khi có sách mới nhập về, bộ vào kho sách. phận quản lý sách có trách nhiệm rà xét xem số sách đó đã có hay chưa, nếu chưa thì lập thẻ quản lý sách và định mã số sách mới. Nếu có rồi thì gọi lại thẻ cũ để cập nhật bổ sung số lượng. 2. Thanh lý sách cũ Lưu trữ Các sách hư, không đọc được 3. Lập báo cáo các Kết xuất QLS_BM 2 sách cần thanh lý 4. Lập báo cáo sách Kết xuất QLS_BM 3 mượn 68
QLS_BM 1: THẺ QUẢN LÝ SÁCH Tên sách: ___ Tập: ___ Số trang: ___ Số lượng: ___ Năm xuất bản: ___ Mã ngôn ngữ: ___ Ngôn ngữ: ___ Mã nhà xuất bản: ___ Nhà xuất bản: ___ Mã phân loại: ___ Phân loại: ___ Mã tác giả: ___ Tác giả: ___ Mã vị trí: ___ Khu: ___ Kệ: ___ Ngăn: ___ QLS_BM 2: DANH SÁCH CÁC SÁCH CẦN THANH LÝ stt Mã Tên Tác Năm Ngày Tình sách sách giả sản xuất nhập kho trạng 1 2 Ngày lập báo cáo: Người lập: QLS_BM 3: BÁO CÁO THỐNG KÊ SÁCH MƯỢN Từ ngày ___ Đến ngày ___ 69
stt Mã sách Tên sách Tác giả Số lượt mượn 1. 2. Ngày lập báo cáo: Người lập: 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 theo mẫu sau: 70
STT Nội dung Mô tả chi tiết Ghi chú 1. 2. Mẫu 3: Bảng yêu cầu chức năng hệ thống. STT Nội dung Tiêu chuẩn Mô tả Ghi chú chi tiết 1. 2. Mẫu 4: Bảng yêu cầu về chất lượng. Ví dụ: Xét phần mềm quản lý thư viện (giả sử phần mềm được xây dựng nhằm phục vụ cho 4 bộ phận là: độc giả, thủ thư, ban giám đốc và quản trị hệ thống ). Bảng yêu cầu chức năng hệ thống: ST Nội Mô tả chi tiết Ghi T dun chú g 1 Phân - Người quản trị: được phép sử dụng tất cả quyề các chức năng n sử - Độc giả: chỉ tra cứu sách và đăng ký dụng mượn sách - Ban giám đốc: chỉ tra cứu sách và lập các báo cáo thống kê - Thủ thư: tất cả các chức năng, ngoại trừ chức năng phân quyền, sao lưu và phục hồi dữ liệu 71
BẢNG YÊU CẦU VỀ CHẤT LƯỢNG HỆ THỐNG ST NỘI DUNG TIÊU MÔ TẢ CHI TIẾT GHI T CHUẨN CHÚ 1 Cho phép thay đổi quy định Tiến hóa Người dùng phần mềm có thể thay đổi tính tiền phạt đơn giá phạt và biên các mức phạt. 2 Hình thức tra cứu thật tiện Tiện dụng Hỗ trợ khả năng tra cứu gần đúng, tra dụng, tự nhiên, trực quan. cứu theo nội dung, Dễ sử dụng cho cả những người không chuyên tin học. 3 Cho phép nhập sách mới từ Tương Có thể nhập trực tiếp danh sách các tập tin Excel có sẵn. thích sách mới có trước trên tập tin Excel Các màn hình có sự nhất với cấu trúc hợp lý. quán chung 4 Tốc độ thực hiện việc cho Hiệu quả Tối đa 30 giây cho mỗi phiếu mượn mượn và tra cứu sách nhanh sách. Hỗ trợ thiết bị đọc mã vạch. Tối đa 10 giây phải có kết quả tra cứu. 72
1.2.4 Khảo sát một số phần mềm tiêu biểu minh họa cho giai đoạn xác định yêu cầu. A. Phần mềm hỗ trợ giải bài tập phân số. Bộ phận: Giáo viên. Mã số: GV ST Công việc Loại công Quy định/Công Biểu mẫu liên Ghi chú T việc thức liên quan quan 1 Soạn tóm tắt lý thuyết Lưu trữ và ví dụ minh họa 2 Soạn đề bài tập Lưu trữ GV_QĐ 2 GV_BM 2 3 Soạn đáp án Lưu trữ GV_QĐ 3 GV_BM 3 4 Chấm điểm Tính toán GV_QĐ 4 73
ST Mã số Tên Quy định/ Mô tả chi tiết Ghi T Công thức chú 1. GV_QĐ2 Quy định soạn Đề bài được giới hạn chỉ là biểu thức các phép đề bài tập toán trên phân số với tối đa 4 phân số thành phần. Có 3 mức bài tập: 1. Chỉ gồm 2 phân số và 1 phép toán. 2. Chỉ gồm 3 phân số và 2 phép toán. 3. Hỗn hợp nhiều phân số ( tối đa 4 phân số ) với nhiều phép toán Có 4 loại phép toán : + - */ 2. GV_QĐ3 Quy định soạn Mỗi bước giải chỉ được phép rút gọn biểu thức bằng đáp án bài tập các thực hiện phép tính trên 2 phân số. (cũng là quy Thứ tự thực hiện phép tính theo quy tắc độ ưu tiên định soạn bài như sau : giải của học sinh) Ưu tiên 1 : nhân chia cao hơn công trừ. Ưu tiên 2 : bài toán ưu tiên bên phải Riêng đối với bài giải của học sinh cho phép bỏ qua các bước trung gian. 74
3. GV_QĐ4 Quy định chấm Có đáp án cuối cùng đúng điểm  Thực hiện hơn hoặc bằng 50% các bước so với đáp án : o Đã rút gọn : 10 o Chưa rút gọn : 8  Thực hiện dưới 50% các bước so với đáp án : o Đã rút gọn : 9 o Chưa rút gọn : 7 Có đáp án cuối cùng sai  Thực hiện hơn hoặc bằng 70% các bước so với đáp án : 5  Thực hiện từ 50% đến dưới 70% các bước so với đáp án : 3  Thực hiện từ 50% các bước so với đáp án : 0 75
GV_BM 2: Đề bài tập của giáo viên. Thực hiện các phép tính trên biểu thức các phân số : [phép toán] [phép toán] GV_BM 3: Đáp án của giáo viên ( bài giải của học sinh ) Đề bài: ___ Các bước biến đổi tương đương : Bước 1: Bước 2: Bước 3: Đáp số: Bộ phận: Học sinh. Mã số: HS s Công việc Loại Quy định Biểu mẫu Ghi t công liên quan liên quan chú t việc 1 Chọn bài Tra cứu GV_QĐ 2 GV_BM 2 tập 2 Giải bài tập Lưu trữ GV_QĐ 3 GV_BM 3 3 Xem tóm tắt Kết xuất lý thuyết 4 Xem đánh Kết xuất GV_QĐ 3 GV_BM 3 giá và đáp GV_QĐ 4 án 76
2. 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 chưa 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. Ví dụ: Xét yêu cầu lập hóa đơn bán sách, yêu cầu này chỉ mô tả biểu mẫu về hóa đơn, qui định lập hóa đơn và chưa thể hiện cách thức lập hóa đơn trên máy tính Mục tiêu của mô hình hóa: Cho phép ta hiểu 1 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. 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.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 77
. Đị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.3 Sơ đồ phân rã chức năng Sơ đồ phân rã chức năng - Function Decomposition Diagram - FDD: 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 . 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 Ví dụ: Sơ đồ phân rã chức năng 78
2.3 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 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ằn 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.4 Sơ đồ luồng dữ liệu Sơ đồ luồng dữ liệu - Data flow diagram – DFD Đâ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ở 79
rộng khác nhau. Xem chi tiết ở chương kế tiếp thiết kế phần mềm. Ngoài ra còn có mô hình thực thể kết hợp được trình bày trong hầu hết các cuốn sách Cơ sở dữ liệu hoặc Thiết kế CSDL. 2.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 (Heritage): 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 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 và hoặc dùng các phương pháp đặc tả khác (thí dụ hướng cấu trúc. 80
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 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ình dạng 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ất 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 81
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. 2. 6 Ví dụ minh họa từ yêu cầu sang mô hình hóa Ví dụ 1: Xét phần mềm quản lý thư viện với 4 yêu cầu - Lập thẻ độc giả - Nhận sách - Cho mượn sách - Trả sách Giai đoạn 2 : Mô hình hóa yêu cầu . Sơ đồ luồng dữ liệu cho công việc lập thẻ độc giả Quản lý độc giả D1 Máy in D5 Lập thẻ độc giả D4 D1: Thông tin về thẻ độc giả cần nhập D4: Thông tin về thẻ độc giả cần lưu trữ trên bộ nhớ phụ D5: Thông tin trên thẻ độc giả (trong thế giới thực) Xử lý thẻ độc giả: Kiểm tra tính hợp lệ của thẻ trước ghi nhận và in . Sơ đồ luồng dữ liệu cho công việc nhận sách 82
Quản lý sách D1 Nhận sách D4 D1: Thông tin về thẻ sách cần nhập D4: Thông tin về sách cần lưu trữ trên bộ nhớ phụ Xử lý nhập sách: Kiểm tra tính hớp lệ của sách trước khi ghi nhận trên bộ nhớ phụ . Sơ đồ luồng dữ liệu cho công việc cho mượn sách Thủ thư D1 Cho mượn sách D3 D4 D1: Thông tin về độc giả và sách muốn mượn D3: Thông tin được sử dụng cho việc kiểm tra qui định mượn sách D4: Thông tin về việc mượn sách Xử lý cho mượn sách: Kiểm tra tính hợp lệ của việc mượn sách ghi nhận trên bộ nhớ phụ . Sơ đồ luồng dữ liệu cho công việc trả sách 83
Thủ thư D1 Trả sách D3 D4 D1: Thông tin về độc giả và sách trả D3: Thông tin sử dụng cho việc kiểm tra qui định trả sách D4: Thông tin về việc trả sách Xử lý trả sách: Kiểm tra tính hợp lệ của việc trả sách ghi nhận trên bộ nhớ. 84
Chương 3: THIẾT KẾ PHẦN MỀM 1. Tổng quan về thiết kế Trong thiết kế, chúng ta định hình hệ thống và tìm dạng thức của nó (kể cả kiến trúc) mà đáp ứng được mọi yêu cầu, cả yêu cầu phi chức năng và các ràng buộc khác - được đặt ra cho hệ thống đó. Một đầu vào cơ bản cho thiết kế là kết quả thu được từ phần tích, đó là mô hình phân tích. Xét một cách chi tiết mục đích của thiết kế là: . Thu được sự hiểu biết sâu về các yêu cầu phi chức năg và các ràng buộc có liên quan tới ngôn ngữ lập trình, sử dụng lại thành phần, các hệ điều hành, các công nghệ phân tán, các công nghệ cơ sở dữ liệu, các công nghệ giao diện người dùng, các công nghệ quản lý các giao dịch. . Tạo ra một đầu vào thích hợp và xuất phát điểm cho các hoạt động cài đặt tiếp theo sau bằng cách nắm bắt các yêu cầu về mỗi hệ thống cụ thể, các giao diện, và các lớp. . Có khả năng phân rã việc cài đặt thành các mẩu nhỏ dễ quản lý hơn được nhiều đội phát triển khác nhau xử lý và có thể tiến hành đồng thời. Điều này sẽ có ích trong các trường hợp khi mà không thể tiến hành sự phân rã giữa các kết quả thu được từ nắm bắt các yêu cầu hoặc phân tích. . Nắm bắt sớm các giao diện chủ yếu giữa các hệ thống con trong vòng đời của phần mềm. Điều này sẽ có ích khi chúng ta suy luận về kiến trúc và khi chúng ta sử dụng các giao diện như những công cụ đồng bộ các đội phát triển khác nhau 85
. Trực quan hóa và suy luận thiết kế bằng cách sử dụng một hệ thống các ký pháp chung. . Tạo ra một sự trừu tượng hóa liên tục của việc cài đặt của hệ thống, tức là cài đặt sự làm mịn dần thiết kế bằng cách đắp “thịt” vào khung xương nhưng không thay đổi cấu trúc của nó. Mục tiêu của phần này là giới thiệu một số phương pháp và kỹ thuật chính trong thiết kế, đối với việc triển khai một hệ thống thành nhiều hệ thống con và hệ thống con thành nhiều thành phần (components), và quản lý những vấn đề liên quan đến cấu trúc nội tại của những thành phần hệ thống. Đầu tiên chúng ta xem qua vài kỹ thuật thiết kế. Kế đến chúng ta sẽ xét qua một vài kỹ thuất thiết kế và phương pháp nền tảng một cách chi tiết và một số ví dụ minh họa. Thêm vào đó, chúng ta bàn qua những khía cạnh thiết kế như thiết kế giao diện người dùng và mô đun hóa. 1.1 Kỹ thuật thiết kế Thiết kế đặc tả đi đến kỹ thuật cốt lõi của tiến trình của công nghệ phần mềm. Thiết kế đặc tả được cung cấp xem xét những mô hình của tiến trình phần mềm được sử dụng. Thiết kế phần mềm là bước đầu tiên trong ba hoạt động kỹ thuật - thiết kế, phát sinh mã nguồn, và thử nghiệm – đó là những yêu cầu trong xây dựng và phát triển phần mềm. Một trong những điểm mấu chốt chính đối với độ phức tạp của hệ thống phần mềm là sự trừu tượng. Có hai phương pháp chính: thiết kế Top-down và thiết kế bottom-up 1.1.1 Thiết kế trên xuống (Top-down) -Thiết kế bắt đầu với việc phân tích những định nghĩa yêu cầu và không nên xem xét việc thực hiện chi tiết đầu tiên. 86
- Một dự án được triển khai thành những dự án nhỏ, thủ tục này phải được lặp lại cho đến khi những nhiệm vụ con trở nên đơn giản sao cho một thuật toán được tính toán và giải quyết. 1.1.2 Thiết kế từ dưới lên (Bottom–up) Ý tưởng nền tảng: Hiểu được phần cứng và tầng trên của nó như một cơ chế trừu tượng. Kỹ thuật: Thiết kế từ dưới lên bắt đầu được cho bởi máy cụ thể và liên tiếp phát triển một máy trừu tượng sau khi những máy khác được thêm vào những thuộc tính cần thiết cho đến khi một máy đã đạt được kết quả mà cung cấp những chức năng người dùng yêu cầu. 1.1.3 Thiết kế hệ thống Trong hệ thống lớn, tiến trình thiết kế bao gồm một yếu tố thiết kế hệ thống mà chức năng được phân chia thành những chức năng phần mềm và phần cứng. Những thuận lợi của chức năng thực hiện trong phần cứng là thành phần phần cứng phân phối thực hiện tốt hơn đơn vị phần cứng. Nút thắt của hệ thống được xác định và thay thế bởi thành phần của phần cứng, như thế việc tối ưu phần mềm là hết sức tốn kém. Cung cấp tốc độ phần cứng có nghĩa là thiết kế phần mềm có thể được cấu trúc cho khả năng thích ứng và khả năng xem xét thực thi cả chức năng. 1.1.4 Thiết kế bản mẫu (prototype) Thiết kế bản mẫu nghĩa là đưa ra các màn hình giao diện sơ bộ, hay các bản thiết kế phác thảo nháp cho người dùng tham khảo trước khi đi vào thiết kế chi tiết, hay chức năng cụ thể. Các bản thiết kế này được soạn thảo dưới dạng sưu liệu hoặc một số phần mềm có khả năng thiết kế nhanh giao diện, các kỹ 87
sư thiết kế có thể sử dùng một số phần mềm chuyên dụng để soạn thảo nhanh như MS Visual Basic, Visual C++, MS Visual Studio với trang web thì có thể dùng Front Page, MS Visual Interdev chỉ với những đoạn chương trình đơn giản được cài đặt. Đây cũng có thể coi là bước đệm cơ bản trước khi đi vào cài đặt chi tiết cho từng chương trình con hay môđun con v.v. 1.1.5 Phân rã thiết kế Tiến trình thiết kế không chỉ ảnh hưởng đến phương pháp thiết kế mà còn ảnh hướng đến tiêu chuẩn được sử dụng để phân rã hệ thống. Phần lớn những yếu tố cơ bản của phân rã được đề ra. Phương pháp phân loại phân rã 1.1.5.1 Phân rã hướng chức năng - Khía cạnh của hệ thống hướng chức năng tạo nên cốt lõi của thiết kế - Dựa trên những yêu cầu chức năng chứa trong những định nghĩa yêu cầu, phân rã hướng đến tác nhiệm của toàn bộ hệ thống được tổ chức Sơ đồ phân rã chức năng - Function Decomposition Diagram - FDD: 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 . 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 88
Ví dụ: Sơ đồ phân rã chức năng 1.1.5.2 Phân rã hướng dữ liệu Tiến trình thiết kế tập trung trên khía cạnh hệ thống hướng đến dữ liệu. Chiến lược thiết kế hướng đến chính dữ liệu đựơc thực hiện. Phân rã những bộ phận hệ thống từ việc phân tích dữ liệu 1. Sơ đồ luồng dữ liệu Sơ đồ luồng dữ liệu - Data flow diagram - DFD 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 89
a. Khái niệm và ký hiệu Tác nhân ngoài: đối tượng bên ngoài hệ thống, nguồn phát sinh hay thu nhận dữ liệu Tiến trình: Thao tác đối với thông tin hay khối dữ liệu Luồng dữ liệu: luồng thông tin di chuyển trong hệ thống Kho dữ liệu:nơi lưu trữ dữ liệu Các ký hiệu: b. Các nguyên tắc và bước xây dựng mô hình DFD Các bước xây dựng DFD: . Phân rã chức năng hệ thống . Liệt kê các tác nhân, các khoản mục dữ liệu . Vẽ DFD cho các mức Nguyên tắc: . Các tiến trình phải có luồng vào luồng ra . Không có luồng dữ liệu trực tiếp giữa các tác nhân với tác nhân và kho dữ liệu . Luồng dữ liệu không quay lại nơi xuất phát . Bắt đầu bằng DFD mức 0, liệt kê các tác nhân ngoài ở mức 0 . Các mức(cấp) sơ đồ: 90
o mức 0: Toàn bộ phần mềm là khối xử lý o mức 1: Sơ đồ mức 0 có thể phân rã thành nhiều sơ đồ mức 1, các sơ đồ mức 1này phải đảm bảo thể hiện đầy đủ ý nghĩa sơ đồ mức 0 (tác nhân, thiết bị, luồng dữ liệu, xử lý, bộ nhớ phụ) o mức 2: Mỗi sơ đồ mức 1 có thể phân rã thành nhiều sơ đồ mức 2 tương ứng như việc phân rã của sơ đồ mức 0 o Trình bày sơ đồ: Trong mỗi cấp có 2 hình thức trình bày sơ đồ - Dạng tổng hợp : Chỉ có một khối xử lý chung, tất cả các luồng dữ liệu chỉ tập trung liên quan đến khối xử lý chung này - Dạng chi tiết: Bao gồm nhiều khối xử lý với luồng dữ liệu riêng biệt cho từng khối xử lý Ví dụ: biểu diễn các mức của DFD Ví dụ DFD hệ thống bán vé mức 0: 91
mức 1: DFD mức 1 2. Các hướng tiếp cận lập sơ đồ luồng dữ liệu . Có nhiều hướng tiếp cận để tạo lập các sơ đồ luồng dữ liệu. Giáo trình này giới hạn xem xét 3 cách tiếp cận chính + Hướng tiếp cận từ trên xuống dưới (topdown) + Hướng tiếp cận từ dưới lên trên (bottomup) + Hướng tiếp cận phối hợp . Tiếp cận từ trên xuống: Quá trình thực hiện theo hướng tiếp cần này như sau: 92
- Lập sơ đồ luồng dữ liệu cấp 0 (xem xét tất cả các luồng dữ liệu nhập xuất, tất cả các yêu cầu xử lý của phần mềm - Phân rã sơ đồ luồng dữ liệu cấp 0 thành nhiều sơ đồ luồng dữ liệu cấp 1. Có 2 cách phân rã: + Phân rã các xử lý của phần mềm thành nhiều xử lý con và quyết định các luồng dữ liệu tương ứng trên các xử lý con này. + Phân rã các luồng dữ liệu nhập xuất thành nhiều luồng dữ liệu con và quyết định các xử lý tương ứng với các luồng dữ liệu con này. - Quá trình kết thúc khi đạt đến các sơ đồ không thể tiếp tục phân rã được (sơ đồ lá). Thông thường đây là sơ đồ tương ứng với công việc cụ thể của một nhà chuyên môn trong thế giới thực. Đánh giá - Tiếp cận này thích hợp với các phần mềm có số lượng người dùng, số lượng các yêu cầu ít (nếu ngược lại sơ đồ cấp 0 sẽ rất phức tạp và khó lập chính xác). - Tiếp cận này đặc biệt thích hợp với các loại phần mềm mà vì lý do nào đó các hệ thống yêu cầu chưa được xác định rõ ngay từ đầu (ví dụ các phần mềm hệ thống). - Thông thường cách tiếp cận này ít đựơc sử dụng. . Hướng tiếp cận từ dưới lên (bottomup) Quá trình thực hiện theo hướng tiếp cận này như sau - Lập sơ đồ luồng dữ liệu ở mức cao nhất. Các sơ đồ này sẽ không được tiến hành phân rã thành các sơ đồ có cấp lớn hơn (thông thường đây là sơ đồ ứng với một công việc cụ thể của một người dùng nào đó trong thế giới thực) + Tích hợp các sơ đồ này để tạo lập các sơ đồ có cấp nhỏ hơn (thông thường các sơ đồ được chọn tích hợp 93
theo một tiêu chí cụ thể: cùng một người sử dụng, cùng một loại yêu cầu, v.v). Có 2 cách tích hợp: + Tích hợp các xử lý của các sơ đồ cấp k vào sơ đồ cấp k-1 và giữ nguyên các luồng dữ liệu của các sơ đồ cấp k + Tích hợp đồng thời các xử lý và các luồng dữ liệu của các sơ đồ cấp k để tạo lập sơ đồ cấp k-1. - Quá trình kết thúc khi đạt đến các sơ đồ cấp 0 Đánh giá - Tiếp cận này rất thích hợp với các phần mềm có hệ thống yêu cầu chi tiết, cụ thể và có qui mô yêu cầu (số lượng người dùng, số lượng yêu cầu) thuộc mức trung bình (các đồ án môn học - Tiếp cận này sẽ khó khăn nếu qui mô yêu cầu lớn và chưa thật rõ ràng chi tiết - Cách tiếp cận này sẽ được sử dụng trong giáo trình với các đồ án môn học và các ví dụ minh họa . Hướng tiếp cận phối hợp: Quá trình thực hiện theo hướng tiếp cận này như sau: - Lập sơ đồ luồng dữ liệu cấp k theo một tiêu chí xác định (sơ đồ cho từng người dùng, sơ đồ cho một bộ phận, sơ đồ cho một loại yêu cầu, v.v) - Phân rã sơ đồ cấp k thành nhiều sơ đồ cấp k+1 tiếp tục cho đến khi đạt được các sơ đồ lá - Tích hợp các sơ đồ cấp k thành các sơ đồ cấp k-1 tiếp tục cho đến khi đạt được sơ đồ cấp 0 Đánh giá - Tiếp cận này thích hợp cho các phần mềm có qui mô yêu cầu lớn, phức tạp - Tiếp cận này được sử dụng rất thường xuyên trong thực tế. 3. Lập sơ đồ luồng dữ liệu cho từng công việc 94
. Do các giới hạn đã nêu phía trên việc lập các sơ đồ luồng dữ liệu toàn bộ phần mềm chỉ qui về lập sơ đồ luồng dữ liệu cho từng công việc (sau đó chỉ thực hiện đơn giản một bước tích hợp để có sơ đồ cấp 0) . Quá trình lập sơ đồ luồng dữ liệu cho một công việc được tiến hành qua các bước như sau - Bước 1: Xác định dữ liệu nhập - Bước 2: Xác định dữ liệu xuất - Bước 3: Mô tả xử lý . Bước 1: Xác định dữ liệu nhập - Dữ liệu nhập từ người dùng sử dụng đựơc xác định dựa vào biểu mẫu có liên quan với các lưu ý sau: + Không nhập vào các dữ liệu có thể tính toán được dựa trên qui định hay công thức đã có. + Không nhập vào các dữ liệu đã được lưu trữ trước đó (qua một công việc khác). - Dữ liệu nhập từ thiết bị nhập (khác bàn phím) chỉ được xem xét khi có yêu cầu đặc biệt trong một số ứng dụng đặc biệt (hệ thống thời gian thực, hệ thống bản đồ, nhập thông qua sử dụng điện thoại tổng đài điện thoại trong quản lý khách sạn, v.v). - Dữ liệu nhập (đọc) từ bộ nhớ phụ được xác định dựa trên các qui định công thức liên quan với một số lưu ý: + Chỉ đọc dữ liệu thật sự cần thiết cho việc thực hiện xử lý tương ứng (thông tin nhập chưa đủ để xử lý). + Để cải tiến chất lượng phần mềm(đặc biệt tính tiến hóa) có thể đọc thêm các tham số phục vụ cho việc xử lý từ bộ nhớ phụ (bảng qui định đơn giá phạt khi trả sách trễ hạn, bảng định mức và đơn giá tiền điện, v,v). Tuy nhiên trong giai đoạn này chỉ nên tập trung vào tính đúng đắn (các chất lượng khác sẽ được xem xét chi tiết trong giai đoạn thiết kế). 95