Ở phần này có phân tích ưu khuyết điểm của từng hướng và chọn một hướng thích hợp.
- Phương án:
+ Ngắn hạn: 3 tháng, 6 tháng.
+ Trung hạn: 2 năm
+ Dài hạn: > 2 năm.
Trong từng loại nên đề xuất cụ thể phần cứng, phần mềm tương ứng đối với mỗi phương án đề xuất để khách hàng chọn lựa, thông báo chi phí, lợi ích được gì? Trong bao lâu?
- Kế hoạch: Phân bổ việc thực hiện theo thời gian và nhân sự thực hiện.
4.4.4. Thiết lập mô hình
Trong khi phân tích các yêu cầu phần mềm, chúng ta tạo ra các mô hình về hệ thống cần xây dựng. Các mô hình tập trung vào điều hệ thống phải thực hiện, không chú ý đến cách thức nó thực hiện. Trong nhiều trường hợp, các mô hình chúng ta tạo ra có dùng kí pháp đồ hoạ mô tả cho thông tin, xử lý, hành vi hệ thống, và các đặc trưng khác thông qua các biểu tượng phân biệt và dễ nhận diện. Những phần khác của mô hình có thể thuần túy văn bản. Thông tin mô tả có thể được cung cấp bằng cách dùng một ngôn ngữ tự nhiên hay một ngôn ngữ chuyên dụng cho mô tả yêu cầu. Các mô hình được tạo ra trong khi phân tích yêu cầu còn đóng một số vai trò quan trọng:
- Mô hình trợ giúp cho người phân tích trong việc hiểu về thông tin, chức năng và hành vi của hệ thống, do đó làm cho nhiệm vụ phân tích yêu cầu được dễ dàng và hệ thống hơn.
- Mô hình trở thành tiêu điểm cho việc xem xét và do đó, trở thành phần mấu chốt cho việc xác định tính đầy đủ, nhất quán và chính xác của đặc tả.
- Mô hình trở thành nền tảng cho thiết kế, cung cấp cho người thiết kế một cách biểu diễn chủ yếu về phần mềm có thể được “ánh xạ” vào hoàn cảnh cài đặt.
Các phương pháp thường dùng khi phân tích:
- Phương pháp phân rã chức năng (Functional Decomposition)
- Phương pháp phân tích có cấu trúc (Structured Analysis)
- Phương pháp phân tích hướng đối tượng (Object Oriented Method)
- Phương pháp phân tích tạo mẫu nhanh (Rapid prototyping Method)
1) Phương pháp phân rã chức năng (Functional Decomposition)
Phương pháp phân rã chức năng là phương pháp phân tích cổ điển. Phương pháp tập trung vào việc đưa ra những tính năng hệ thống cần phải có, không quan tâm đến việc xây dựng các chức năng này như thế nào. Chức năng hệ thống được phân rã từ trên xuống dưới theo các nhóm chức năng, từng chức năng và giao diện.
2) Phương pháp phân tích có cấu trúc (Structured Analysis)
Phân tích có cấu trúc là tên của các phương pháp phân tích có sử dụng mô hình luồng dữ liệu, bao gồm: Yourdon methods, SSADM (structured system analysis and design methodology), SADT (structured analysis and design technique).
Phương pháp phân tích có cấu trúc sử dụng các công cụ sau để chỉ ra các yêu cầu đối với hệ thống phần mềm:
- DD, từ điển dữ liệu.
- Ngôn ngữ có cấu trúc.
- Bảng quyết định (Decision Table): Bảng quyết định dùng để thể hiện một quyết định của hệ thống đối với một tập hợp các điều kiện.
- Cây quyết định (Decision Tree): Cây quyết định dùng để thể hiện một quyết định của hệ thống đối với một điều kiện nào đó.
Các mô hình của phương pháp này là:
- DFD (Sơ đồ luồng dữ liệu).
- ERD (Sơ đồ quan hệ thực thể).
- FHD (Sơ đồ phân rã chức năng).
a) Sơ đồ luồng dữ liệu
Khi thông tin đi qua phần mềm nó bị thay đổi bởi một loạt các phép biến đổi. Sơ đồ luồng dữ liệu (Data Flow Diagram - DFD) là một kỹ thuật vẽ ra luồng dữ liệu di chuyển trong hệ thống và những phép biến đổi được áp dụng lên dữ liệu. Ký pháp cơ bản của sơ đồ luồng dữ liệu được minh họa như sau:
Sơ đồ tổng quát
Trong đó:
- Tác nhân gồm: Người sử dụng, thiết bị nhập, thiết bị xuất
- Kho dữ liệu gồm: Hồ sơ, sổ sách, tập tin, cơ sở dữ liệu,…
- D1, D2, D3,…là ý nghĩa từng dòng dữ liệu.
Ví dụ 1 Xét chức năng tính đạo hàm của một đa thức. Hãy lập Sơ đồ tổng quát cho chức năng tính đạo hàm
Trong đó D1: Đa thức cần tính đạo hàm P, D2: Đa thức kết quả Q
Ví dụ 2 Xét phần mềm quản lý thư viện, hãy lập sơ đồ luồng dữ liệu cho yêu cầu Lập thẻ độc giả. Biết rằng có hai loại độc giả là cán bộ, sinh viên; Tuổi độc giả từ 18 đến 55; Thẻ có giá trị 6 tháng.
Giải thích:
- D1: Thông tin về thẻ độc giả: Họ tên, Loại độc giả, Ngày sinh, Địa chỉ, E-Mail, Ngày Lập Thẻ.
- D2: Không có
- D3: Danh sách các loại độc giả, Tuổi tối thiểu, Tuổi tối đa, Thời hạn sử dụng.
- D4: D1
- D5: D4
- D6: Danh mục loại độc giả
Sơ đồ luồng dữ liệu có thể được dùng để biểu diễn cho một hệ thống hay phần mềm ở bất kì mức trừu tượng nào. Trong thực tế, DFD có thể được phân hoạch thành
nhiều mức biểu diễn cho chi tiết chức năng và luồng thông tin ngày càng tăng. Do đó phương pháp dùng DFD còn được gọi là phân tích có cấu trúc.
Một DFD mức 0, cũng còn được gọi là Sơ đồ nền tảng hay Sơ đồ ngữ cảnh hệ thống, biểu diễn cho toàn bộ phần tử phần mềm như một hình tròn với dữ liệu vào và ra được chỉ ra bởi các mũi tên tới và đi tương ứng.
Một DFD mức 1 cụ thể hóa của DFD mức 0 và có thể chứa nhiều hình tròn (chức năng) với các mũi tên (luồng dữ liệu) nối lẫn nhau. Mỗi tiến trình được biểu diễn ở mức 1 đều là chức năng con của toàn bộ hệ thống được mô tả trong Sơ đồ ngữ cảnh.
Ví dụ Xét hệ thống bán vé tầu, DFD các mức có hình vẽ như sau:
b) Sơ đồ thực thể quan hệ
Ký pháp nền tảng cho mô hình hóa dữ liệu là Sơ đồ thực thể - quan hệ (Entity - Relation Diagram-ERD). Tất cả đều xác định một tập các thành phần chủ yếu cho Sơ đồ ERD: thực thể, thuộc tính, quan hệ và nhiều chỉ báo kiểu khác nhau. Mục đích chính của Sơ đồ ERD là biểu diễn dữ liệu và mối quan hệ của các dữ liệu (thực thể).
Ký pháp của Sơ đồ ERD cũng tương đối đơn giản. Các thực thể được biểu diễn bằng các hình chữ nhật có nhãn. Mối quan hệ được chỉ ra bằng hình thoi. Các mối nối giữa sự vật dữ liệu và mối quan hệ được thiết lập bằng cách dùng nhiều đường nối đặc biệt.
Ví dụ mô hình thực thể quan hệ người - phương tiện giao thông.
c) FHD (Function Hiarachy Diagram)
FHD là mô hình chức năng của hệ thống. FHD là kết quả của việc phân tích quy trình nghiệp vụ và dữ liệu để xây dựng lên yêu cầu chức năng của hệ thống mới. Người sử dụng và cán bộ phân tích có thể dùng FHD để xác định xem những chức năng nào sẽ được đưa vào hệ thống, những chức năng nào nằm ngoài. Ngoài ra FHD là mô hình quan trọng cho quá trình thiết kế. Việc xây dựng chức năng của ứng dụng sau này chủ yếu dựa trên FHD.
Để xây dựng SRD có thể sử dụng công cụ D2K của ORACLE. Prototype có thể được xây dựng hoặc phát triển từ giai đoạn xác định yêu cầu.
3) Phương pháp phân tích hướng đối tượng (Object Oriented Analysis) Phương pháp phân tích hướng đối tượng xây dựng trên một số công việc sau:
- Xác định các lớp và đối tượng (Class & Object)
- Xác định cấu trúc (Structure)
- Xác định vấn đề (Subject)
- Xác định các thuộc tính (Attribute)
- Xác định các dịch vụ (Servirces)
Các công cụ sử dụng trong phương pháp phân tích hướng đối tượng:
- Mô hình đối tượng (Object Model).
- Mô hình động học (Dynamic Model).
- Mô hình chức năng (Functional Model).
4) Rapid Prototyping
Phương pháp rapid prototyping được sử dụng khi cần nhanh chóng xây dựng và đánh giá một loạt các prototype. Việc xây dựng hệ thống phần mềm là vòng lặp tới khi SRD được chấp nhận:
- Phân tích yêu cầu
- Tạo cơ sở dữ liệu
- Tạo giao diện NSD
- Bổ sung các chức năng
- Xem xét hoạt động của prototype cùng với người sử dụng
Sau đó trong khi phân tích các yêu cầu có thể sử dụng một trong các phương pháp phân tích nêu trên (như phương pháp phân tích có cấu trúc hay phân tích hướng đối tượng).
4.4.5. Đặc tả yêu cầu
Khi đã xác định rò bài toán thì bước tiếp theo là tìm hiểu xem hệ thống dự kiến sẽ yêu cầu làm cái gì. Điều quan trọng ở đây là phải xây dựng được danh sách các yêu cầu của người sử dụng. Dựa trên những yêu cầu của người sử dụng, người phát triển đưa ra các đặc tả cho hệ thống.
Người xây dựng hệ thống phải trả lời được các yêu cầu sau đây:
- Đầu ra của hệ thống là cái gì
- Hệ thống sẽ phải làm cái gì để có kết quả mong muốn, nghĩa là phải xử lý những cái gì
- Những tài nguyên mà hệ thống yêu cầu là gì
Do các đặc tả yêu cầu thêm các thông tin vào định nghĩa yêu cầu nên các đặc tả thường được biểu diễn cùng với các mô hình hệ thống được phát triển trong quá trình phân tích yêu cầu. Nó cần bao gồm mọi thông tin cần thiết về yêu cầu chức năng và ràng buộc của hệ thống. Phân tích yêu cầu được tiếp tục xác định và đặc tả khi các yêu cầu mới nảy sinh. Đây là tài liệu thường xuyên thay đổi và nên được kiểm soát chặt chẽ.
Các loại đặc tả yêu cầu
- Đặc tả phi hình thức (Ngôn ngữ tự nhiên)
- Đặc tả hình thức (Dựa trên kiến trúc toán học)
1) Đặc tả phi hình thức (Ngôn ngữ tự nhiên)
Đặc tả phi hình thức là đặc tả sử dụng ngôn ngữ tự nhiên. Tuy nó không được chặt chẽ bằng đặc tả hình thức nhưng được nhiều người biết và có thể dùng để trao đổi với nhau để làm chính xác hóa các điểm chưa rò, chưa thống nhất giữa các bên phát triển hệ thống.
Ngôn ngữ tự nhiên không hoàn toàn thuận tiện cho các thiết kế viên hoặc các hợp đồng giữa các khách hàng và cán bộ phát triển hệ thống vì có một số lý do như sau:
- Nhầm lẫn do cách hiểu các khái niệm khác nhau giữa hai bên.
- Đặc tả yêu cầu ngôn ngữ tự nhiên quá mềm dẻo. Một vấn đề có thể được mô tả bằng quá nhiều cách khác nhau.
- Các yêu cầu không được phân hoạch tốt, khó tìm các mối quan hệ,...
Do vậy người ta thường dùng các thay thế khác để đặc tả các yêu cầu như:
- Ngôn ngữ tự nhiên có cấu trúc,
- Ngôn ngữ mô tả thiết kế, giống ngôn ngữ lập trình nhưng có mức trừu tượng cao hơn,
- Ngôn ngữ đặc tả yêu cầu,
- Ghi chép graphic,
- Đặc tả toán học,...
2) Đặc tả hình thức (Dựa trên kiến trúc toán học)
Đặc tả hình thức là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ nghĩa được định nghĩa hình thức dựa vào toán học. Đặc tả hình thức có thể coi là một phần của hoạt động đặc tả phần mềm. Các đặc tả yêu cầu được phân tích chi tiết. Các mô tả trừu tượng của các chức năng chương trình có thể được tạo ra để làm rò yêu cầu.
Đặc tả phần mềm hình thức là một đặc tả được trình bày trên một ngôn ngữ bao gồm: từ vựng, cú pháp và ngữ nghĩa được định nghĩa. Định nghĩa ngữ nghĩa đảm bảo ngôn ngữ đặc tả không phải là ngôn ngữ tự nhiên mà dựa trên toán học. Các chức năng nhận các đầu vào trả lại các kết quả. Các chức năng có thể định ra các điều kiện tiền tố và hậu tố. Điều kiện tiền tố là điều kiện cần thỏa mãn để có dữ liệu vào, điều kiện hậu tố là điều kiện cần thỏa mãn sau khi có kết quả.
Các hướng tiếp cận đặc tả hình thức để phát triển các hệ thống tương đối phức tạp:
- Tiếp cận đại số: Hệ thống được mô tả dưới dạng các toán tử và các quan hệ.
- Tiếp cận mô hình: Mô hình hệ thống được cấu trúc sử dụng các thực thể toán học như là các tập hợp và các thứ tự.
Ưu điểm của đặc tả hình thức:
- Cho phép thấy và hiểu được bản chất bên trong của các yêu cầu, đây là cách tốt nhất để làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công việc thiết kế được thuận lợi.
- Có thể dựa vào các công cụ toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ của hệ thống.
- Sử dụng để kiểm tra hệ thống. Nhược điểm của đặc tả hình thức:
- Quản lý phần mềm có tính bảo thủ cố hữu của nó, không sẵn sàng chấp nhận các kỹ thuật mới.
- Chi phí cho việc đặc tả hình thức thường cao hơn so với các đặc tả khác (tuy phần cài đặt sẽ thấp hơn), nên khó để chứng minh rằng chi phí tương đối cao cho đặc tả sẽ làm giảm tổng chi phí dự án.
- Phần lớn, những người đặc tả hệ thống không được đào tạo một cách chính quy về việc sử dụng đặc tả hình thức cho việc đặc tả hệ thống mà dựa trên thói quen của họ.
- Thông thường, nhiều thành phần của hệ thống là khó cho việc đặc tả bằng ngôn ngữ hình thức. Thêm vào đó là khách hàng không thể hiểu được nó.
- Khách hàng không thích các đặc tả toán học.
4.4.6. Các công việc vủa cán bộ phân tích
Sau đây là các công việc chính của cán bộ phân tích các yêu cầu phần mềm
Bảng 4.6. Các công việc của cán bộ phân tích
Nhiệm vụ/Công việc | |
1. | Lập kế hoạch khảo sát và phân tích |
2. | Khảo sát và nghiên cứu sơ bộ hệ thống |
3. | Nghiên cứu lĩnh vực, phân tích nghiệp vụ và các yêu cầu người sử dụng |
4. | Viết các tài liệu đặc tả yêu cầu người sử dụng, hướng dẫn sử dụng |
5. | Ước tính nhân lực, ngân sách, lịch trình và các nguồn lực cần thiết cho dự án |
6. | Nghiên cứu tính khả thi của các dự án |
7. | Hỗ trợ các vấn đề liên quan đến khảo sát và phân tích |
8. | Báo cáo và tổng hợp kết quả khảo sát và phân tích |
9. | Lập và lưu trữ các hồ sơ liên quan đến khảo sát và phân tích |
10. | Thu thập và kiểm soát các dữ liệu liên quan đến các hoạt động khảo sát và phân tích |
11. | Tính toán và phân tích các chỉ tiêu liên quan đến các hoạt động khảo sát và phân tích |
Có thể bạn quan tâm!
- Mô Hình Xoắn Ốc Của Quy Trình Xác Định Yêu Cầu
- Mối Liên Hệ Giữa Các Kiểu Ứng Dụng Và Các Đặc Tính Dữ Liệu
- Đánh Giá Tính Phù Hợp Của Các Kỹ Thuật Thu Thập Yêu Cầu
- Công nghệ phần mềm - Phạm Hùng Phú, Nguyễn Văn Thẩm Biên soạn - 17
- Mối Liên Quan Của Giai Đoạn Thiết Kế Với Các Giai Đoạn Khác
- Kiến Trúc Của Một Thư Viện Phim Và Hình Ảnh
Xem toàn bộ 305 trang tài liệu này.
4.5. Tư liệu hóa yêu cầu phần mềm
Các yêu cầu hệ thống được trình bày trong tài liệu các yêu cầu phần mềm cho biết những thứ cán bộ phát triển hệ thống cần biết. Tài liệu này bao gồm các định nghĩa về yêu cầu và các đặc tả về các yêu cầu. Trong một số trường hợp, chúng không được trình bày riêng biệt mà được tích hợp làm một. Đôi khi, định nghĩa yêu cầu được trình bày như là một giới thiệu tới đặc tả yêu cầu. Cách tiếp cận hiệu quả nhất là trình bày các đặc tả chi tiết như là phụ lục của yêu cầu.
Tài liệu yêu cầu phần mềm không phải tài liệu đặc tả. Nó cần phải mô tả cái hệ thống cần phải làm chứ không phải làm thế nào. Tài liệu này cần dễ dàng được đặc tả và ánh xạ sang các phần tương ứng của thiết kế hệ thống. Nếu các dịch vụ, ràng buộc và các đặc tả thuộc tính trong tài liệu yêu cầu phần mềm được thỏa mãn bởi thiết kế thì thiết kế này được coi là giải pháp thích hợp với vấn đề.