Phần I

Câu 1: Khái niệm về công nghệ Phần mềm và các đặc điểm của nó?

- Công nghệ Phần mềm hay kỹ nghệ Phần mềm là sự áp dụng một cách tiếp cận, có hệ thống, có kỷ luật và định lượng được cho phát triển, hoạt động và bảo trì Phần mềm.

- Các đặc điểm của CNPM: có 4 đặc điểm

+ Khả năng được chấp nhận: Phần mềm nên có một giao diện tương đối dẽ cho người dùng và có đầy đủ hồ sơ về Phần mềm điều đó  có nghĩa là nó phải dễ hiểu, sử dụng được và tương thích với các hệ thống khác.

          + Độ hữu hiệu: Phần mềm không thể phí phạm các nguồn tài nguyên như là bộ nhớ và các chu kỳ vi xử lý.

          + Khả năng tin cậy: Khả năng tin cậy của Phần mềm bao gồm 1 loạt các đặc tính như là độ tin cậy, an toàn và bảo mật. Phần mềm tin cậy không thể tạo ra các thiệt hại vật chất hay kinh tế trong trường hợp hư hỏng.

          + Khả năng bảo trì: Nó có khả năng thực hành những tiến triển để thoả mãn yêu cầu của khách hàng.

Câu 2: Có mấy mô hình phát triển Phần mềm và đặc điểm của từng loại

          Mô hình phát triển Phần mềm là một thể hiện trừu tượng của quy trình Phần mềm. Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ thể, do  đó, nó chỉ cung cấp một phần thông tin về quy trình Phần mềm.

          Phần sau đây sẽ trình bày năm mô hình phát triển Phần mềm phổ biến thường được sử dụng:

-       Mô hình thác nước

-       Mô hình xây dựng tiến triển

-       Công nghệ Phần mềm dựa thành phần

-       Mô hình phát triển lặp lại, tăng thêm

-       Mô hình xoắn ốc

a) Mô hình thác nước

- Các pha của mô hình thác nước bao gồm:

+ Phân tích và xác định các yêu cầu

+ Thiết kế hệ thống và Phần mềm

+Cài đặt và kiểm thử đơn vị

+ Tích hợp và kiểm thử hệ thống

+ Vận hành và bảo trì

- Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự, kết thúc pha trước, rồi mới được thực hiện pha tiếp theo. Do đó, nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện. Giả sử, pha phân tích và xác định yêu cầu đã  hoàn tất và chuyển sang pha kế tiếp, nhưng lúc này lại có sự thay đổi yêu cầu của người sử dụng, thì chỉ còn cách là phải thực hiện lại từ đầu.

- Cho nên, mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế. Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định.

Hình 1: Mô hình thác nước

b) Mô hình xây dựng tiến triển (mô hình làm bản mẫu)

- Mô hình xây dựng tiến triển dựa trên  ý tưởng xây dựng một mẫu thử ban đầu và đưa cho người sử dụng xem xét; sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thoả mãn yêu cầu của người sử dụng thì dừng lại.

- Có hai phương pháp để thực hiện mô hình này:

+ Phát triển thăm dò: Mục đích của nó là để làm việc với khách hàng và để đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu. Phương pháp này thường bắt đầu thực hiẹn với những yêu cầu được tìm hiểu rõ ràng và sau đó, bổ sung những đặc điểm mới được đề xuất bởi khách hàng. Cuối cùng, khi các yêu cầu của người sử dụng được thoả mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống.

+ Loại bỏ mẫu thử:  Mục đích là để tìm hiểu các yêu cầu của hệ thống. Phương pháp này thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử dụng. Từ đó, ta có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này mẫu thử không còn cần thiết nữa. Như vậy,  mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng.

Hình 2

Hình 2: Mô hình xây dựng tiến triển

- Tuy nhiên, nhược điểm của mô hình xây dựng tiến triển là: Thiếu tầm nhìn của cả quy trình; cả hệ thống thường hướng cấu trúc nghèo nàn; yêu cầu các kỹ năng đặc biệt (ví dụ: Các ngôn ngữ để tạo ra mẫu thử nhanh chóng).

- Mô hình xây dựng tiến triển chỉ nên áp dụng với những hệ thống có tương tác ở mức độ nhỏ hoặc vừa, trên một phần của những hệ thống lớn; Hoặc những hệ thống có thời gian chu kỳ tồn tại ngắn.

c) Mô hình công nghệ Phần mềm dựa thành phần

- Mô hình này dựa trên kỹ thuật tái sử dụng một cách có hệ thống; trong đó hệ thống được tích hợp từ nhiều thành phần đang tồn tại hoặc các thành phần thương mại COTS (Commercial – off- the- shelf).

- Các trạng thái chính của quy trình bao gồm:

+ Phân tích thành phần sẵn có

+ Điều chỉnh yêu cầu

+ Thiết kế hệ thống với kỹ thuật tái sử dụng

+ Xây dựng và tích hợp hệ thống

Hình 3:

Hình 3: Công nghệ Phần mềm hướng thành phần

d) Mô hình phát triển lặp lại, tăng thêm

- Mô hình này được đề xuất dựa trên ý tưởng thay vì phải xây dựng và chuyển giao hệ thống một lần thì sẽ được chia thành nhiều vòng, tăng dần. Mỗi vòng là một phần kết quả của một chức năng được yêu cầu.

- Các yêu cầu của người sử dụng được đánh thứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiên càng cao thì càng ở trong những vòng phát triển sớm hơn.

Hình 4:

Hình 4: kết quả tăng dần

- Từ đó, chúng ta có thể thấy rõ một số ưu điểm của mô hình phát triển tăng vòng:

+ Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả thực hiện được cho khách hàng nên các chức năng của hệ thống có thể nhìn thấy sớm hơn.

+ Các vòng trước đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.

+ Những chức năng của hệ thống có thứ tự ưu tiên càng cao thì sẽ được kiểm thử càng kỹ.

e) Mô hình xoắn ốc

- Trong mô hình xoắn ốc, quy trình phát triển Phần mềm được biểu diễn như một vòng xoắn ốc. Các pha trong quy trình phát triển xoắn ốc bao gồm:

+ Thiết lập mục tiêu: Xác định mục tiêu cho từng pha của dự án

+ Đánh giá và giảm thiểu rủi ro: Rủi ro được đánh giá và thực hiện các hành động để giảm thiểu rủi ro

+ Phát triển và đánh giá: Sau khi đánh giá rủi ro, một mô hình xây dựng hệ thống sẽ được lựa chọn từ những mô hình chung

+ Lập kế hoạch: Đánh giá dự án và các pha tiếp theo của mô hình xoắn ốc sẽ được lập kế hoạch.

Hình 5:

Hình 5: Mô hình xoắn ốc

Câu 3: Khái niệm yêu cầu hệ thống? Có mấy loại yêu cầu và đặc điểm của từng loại?

          Yêu cầu hệ thống được chia làm ba loại: Yêu cầu chức năng, yêu cầu phi chức năng, yêu cầu miền ứng dụng hệ thống.

          + Yêu cầu chức năng: Mô tả hệ thống sẽ làm gì và mô tả chi tiết các chức năng và dịch vụ của hệ thống. Yêu cầu chức năng có đặc điểm: Tính  mập mờ không rõ ràng , khi yêu cầu Phần mềm không được xác định, có tính thống nhất và hoàn thiện. Các đặc điểm này nó chứa đựng tất cả mô tả chi tiết không xung đột yêu cầu.

          + Yêu cầu phi chức năng: không đề cập trực tiếp các chức năng một cách cụ thể tổng hợp. Chất lượng chương trình đó là các thuộc tính: độ tin cậy, độ tin cậy rất rộng, tính mềm dẻo, về thời gian đáp ứng…đưa ra các ràng buộc bên trong hệ thống và giữa hệ thống bên ngoài: thiết bị vào ra dữ liệu, giao diện người sử dụng…

          Liên quan đến qúa trình xây dựng hệ thống . Yêu cầu phi chức năng có thể hạn chế yêu cầu chức năng, nhưng trong trường hợp nếu không có thì khó sử dụng được.

          Chủ yếu xuất phát do người sử dụng như: ngân sách, chính sách…

          Phân loại các yêu cầu phi chức năng:

          Tổ chức sử dụng – sản phẩm: Xác định chức năng ứng xử sản phẩm: hiệu năng khả năng độ tin cậy

Yêu cầu tổ chức sản phẩm: chức năng sản phẩm.

Câu 4: Tài liệu đặc tả yêu cầu hệ thống phải có đặc điểm gì?

          Tài liệu đặc tả yêu cầu là những yêu cầu chi thức (đã được thể hiện bằng văn bản) về những gì mà cần phải thực hịên bởi người phát triển hệ thống.

          Tài liệu bao gồm tất cả các định nghĩa yêu cầu người sử dụng và đặc tả yêu cầu hệ thống.

          Đây không phải là tài liệu thiết kế của hệ thống mà nó chỉ thích hợp những yêu cầu mà hệ thống phải làm, chứ không phải mô tả rõ ràng hệ thống phải làm như thế nào?

Mỗi một tài liệu đặc tả yêu cầu nên có cấu trúc rõ ràng.

Tài liệu đặc tả yêu cầu gồm 5 phần:

-       Giới thiệu

+ Mục tiêu tài liệu

+ Phạm vi sản phẩm

+Định nghĩa, ký hiệu, từ viết tắt

+ Tài liệu tham khảo

+Mô tả tổng quan tài liệu

-       Mô tả chung

+ Đặc điểm sản phẩm

+ Mục tiêu sản phẩm (chức năng)

+ Đặc trưng người dùng ràng buộc chung

+ Các giả định và sự phụ thuộc sản phẩm

-       Đưa ra các yêu cầu cụ thể và chi tiết cho từng thành phẩm

-       Các phụ lục

-       Chỉ số chỉ dẫn

Ngoài ra có thể thêm các phần hoặc các chương liên quan đến các thông tin về kiến trúc chung hệ thống (đặc biệt phần cứng) các vấn đề liên quan đến CSDL và các chỉ dẫn.

+ Tài liệu này được sử dụng như 1 công cụ tham khảo cho hệ thống và cho quá trình xây dựng.

+ Tài liệu này tổ hợp của tài liệu xây dựng yêu cầu và đặc tả yêu cầu

+ Tài liệu đặc tả yêu cầu phải mô tả trực quan, đầy đủ ngắn gọn.

Câu 5: Nêu quy trình phát hiện và phân tích yêu cầu. Có mấy cách phat hiện và phân tích?

Quy trình phát hiện và phân tích yêu cầu

          + Domain understanding: Phân tích phát triển hiểu biết của mình về miền ứng dụng.

          + Requirements collection: Quá trình trao đổi với các đối tác để khám phá yêu cầu của họ. Hiểu biết về miền (DU) hiển nhiên sẽ giúp đỡ hoạt động này.

          + Classification: Hoạt động này thu nhập các yêu cầu không có cấu trúc và sau đó phân loại.

          + Conflie resolution: Các đối tác khác nhau thuộc khách hàng không thể tránh khỏi các mâu thuẫn, hoạt động này sẽ giải quyết các mâu thuẫn đó.

          + Priorization: Trong tập hợp các yêu cầu, giai đoạn này cần trao đổi với khách hàng để xếp hạng ưu tiên.

          + Requirements validation: Các yêu cầu được kiểm tra lại xem có đủ tiêu chuẩn hay không, có đúng với mô tả của khách hàng không.

Có mấy cách phát hiện và phân tích:

Phân tích có thể tiến hành theo hai cách như sau:

Phân tích hướng quan điểm:

          Đối với các hệ thống cỡ trung và lớn, có các người dùng cuối khác nhau. Do vậy có nhiều quan điểm khác nhau về cùng một hệ thống, quan điểm quan trọng cần được xác định làm cơ sở cho việc cấu trúc các phân tích yêu cầu.

Phân tích hương phương pháp:

          Phân tích hướng phương pháp có thể được coi là cách tiếp cận phổ biến nhất. Kết quả phương pháp được biểu diễn bởi một số phương pháp cấu trúc để mô hình hoá. Các phương pháp cấu trúc thường bao gồm các đặc tính sau:

          + Mô hình xử lý: mô hình này định nghĩa các hoạt động của phương pháp, ví dụ: phân tích luồng dữ liệu. Xác định kịch bản điều khiển.

          + Mô tả mô hình  hệ thống: Các mô tả này có thể bằng sơ đồ, chuẩn hoá hoặc theo ngôn ngữ. Ví dụ: sơ đồ luông dữ liệu, sơ đồ thực thể liên kết, sơ đồ cấu trúc đối tượng.

          + Các luật áp dụng cho mô hình: Các luật có thể được giữ trong mô hình đơn hoặc các mô hình có tham chiếu đến nhau.

          + Các hướng dẫn thiết kế.

          + Các mẫu báo cáo: Các định nghĩa trình bày thông tin thu thập được. Nó có thể kèm theo các sơ đồ.

Câu 6: Đánh giá yêu cầu hệ thống và người sử dụng phải dựa vào những yếu tố nào?

          Đánh giá các yêu cầu Phần mềm liên quan với việc cho biết các yêu cầu thực sự định nghĩa hệ thống đáp ứng đòi hỏi của khách hàng. Nếu việc định giá này không chính xác, các lỗi trong phần yêu cầu sẽ truyền tới thiết kế hệ thống và triển khai hệ thống. Chi phí sửa chữa lỗi sẽ rất lớn. Sự thay đổi về yêu cầu ngụ ý rằng việc thiết kế và triển khai cũg phải thay đổi theo. Một số khía cạnh của yêu cầu cần phải kiểm chứng và người sử dụng những yếu tố sau để đánh giá:

          + Giá trị: Người sử dụng có thể nghĩ rằng hệ thống cần một số chức năng, tuy nhiên sau một số phân tích, có thể xác định các chức năng khác cần được vào. Do hệ thống có nhiều loại người sử dụng nên có các yêu cầu khác nhau và không thể tránh khỏi sự thoả hiệp các nhu cầu đó.

          + Chắc chắn: Mọi yêu cầu không được mâu thuẫn với các yêu cầu khác.

          + Hoàn chỉnh: Định nghĩa cần phải bao gồm mọi chức năng và các ràng buộc.

          + Hiện thực: Không có các yêu cầu đặc biệt đến mức phi hiện thực. Có thể dự đoán trước các phát triển phần cứng, ty nhiên phát triển Phần mềm thí khó dự đoán hơn.

          + Mẫu: Là một mô hình chạy được của hệ thống được trình bày với người sử dụng. Đây là một kỹ thuật đánh giá yêu cầu hiệu qủa. Nó cho phép người thử nghiệm với hệ thống. Việc đánh giá lại yêu cầu không nên được coi là công việ tiếp theo của tư liệu hoá yêu cầu sau khi đã hoàn thành. Các xem xét yêu cầu có thể là hình thức hoặc phi hình thức. Xem xét phi hình thức liên quan việc các người ký hợp đồng thảo luận các yêu cầu với khách hàng. Nhiều vấn đề có thể được giải quyết dễ dàng bất ngờ khi tham khảo trực tiếp với khách hàng. Đối với yêu cầu xem xét chính thức, đội phát triển phải dẫn dắt khách hàng thông qua các yêu cầu hệ thống, giải thích các triển khai của mỗi yêu cầu. Nhóm rà soát phải kiểm tra mỗi yêu cầu về độ thống nhất, hoàn chỉnh cho toàn bộ tài liệu. Họ có thể phải kiểm tra:

          + Cókhả năng kiểm tra: Tài liệu có thể kiểm tra thực tế được không?

          + Khả năng, hiểu biết: Tài liệu có được khách hàng hiểu biết thấu đáo hay không?

          + Lưu vết: Nguồn gốc của tài liệu được xác định rõ ràng hay không? Rất cỏ thể phải quay lại nguồn gốc ban đầu để đánh giá ảnh hưởng của sự thay đổi.

          + Tính thích hợp: Các yêu cầu đã phù hợp hay chưa? Có thể thay đổi các yêu cầu mà không làm ảnh hưởng lớn đến toàn bộ hệ thống không?

Câu 7: Thiết kế kiến trúc là gì? Có mấy cách tổ chức và phân rã hệ thống? Đặc điểm của từng loại?

* Thiêt kế kiến trúc: Quy trình xác định rõ hệ thống con cấu tạo nên hệ thống đề xuất và nền tảng giúp điều khiển các hệ thống con và giao tiếp giữa chúng.

* Tổ chức và phân rã hệ thống gồm:

          a) Tổ chức hệ thống:

          Có 3 cách tổ chức hệ thống: Kho dữ liệu dùng chung, tổ chức hệ thống Client server và phân lớp máy trừu tượng.

          - Kho dữ liệu dùng chung: Các hệ thống con trao đổi dữ liệu theo hai cách:

+ Dữ liệu được lưu trữ và chia sẻ cơ sở dữ liệu ở trung tâm và tất cả các hệ

thống con đều dùng.

          + Mỗi hệ thống con duy trì dữ liệu của riêng nó và truyền dữ liệu theo các hệ thống con khác một cách tưởng minh.

          Ưu điểm: Là phương pháp tốt để chia sẻ một số lượng dữ liệu lớn. Các hệ thống con không cần quan tâm tới các hoạt động sao lưu, bảo mật… Vì đã có bộ phận quản lý trung tâm.

          Nhược điểm:

          + Cải tiến dữ liệu kém

          + Các hệ thống con phải chấp nhận mô hình dữ liệu của hệ thống.

          + Khó phân tán một cách hiệu quả.

          + Không giới hạn cho các chính sách cụ thể.

* Mô hình Client server:

          - Bao gồm một tập hợp các Server cung cấp các dịch vụ và các Client truy nhập SD các dịch vụ đó.

          - Ba thành phần chính:

          + Tập hợp các Server cung cấp dịch vụ như: Quản trị dữ liệu, in ấn…

          + Tập hợp các Client truy nhập vào các Server để dung cấp các dịch vụ.

          + Hệ thống mạng cho phép Client truy cập tới các dịch vụ mà Server cung cấp.

          Ưu điểm:

          + Phân tán dữ liệu đối với Client

          + Chi phí một hệ thống mạng rẻ hơn.

          + Dễ bổ dung hoặc nâng cấp Server.

          Nhược điểm:

          + Quản lý tên các Server và độ dư thừa là không thống nhất.

          + Do không dùng chung mô hình dữ liệu nên việc trao đổi là không hiệu quả.

* Mô hình phân lớp máy trừu tượng:

          Hệ thống được tổ chức thanh nhiều lớp, mỗi lớp cung cấp một dịch vụ và các lớp ấy được coi như một máy trừu tượng mà ngôn ngữ của máy được định nghĩa bởi các dịch vụ mà lớp đó cung cấp.

          b) Phân rã hệ thống:

          Hệ thống con là một hệ thống có thẻ vận hành độc lập được, có thể sử dụng dịch vụ mà hệ thống con khác cung cấp hoặc cung cấp các dịch vụ cho các hệ thống con khác sử dụng.

          - Một modul là một thành phần của hệ thống mà thành phần này sẽ cung cấp dịch vụ cho các thành phần khác nhưng nó thường không đứng độc lập.

          - Có hai cách phân rã hệ thống con -> thành modul:

          + Phân rã hướng đối tượng: Hệ thống được phân chia thành các đối tượng tương tác với nó.

          + Phân rã hướng chức năng: Hệ thống được phân ra thành các hướng chức năng, chuyển thông tin đầu vào -> thông tin đầu ra. Mỗi chức năng -> modul.

          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.

Câu 8: Thế nào là thiết kế CSDL? Thiết kế CSDL phải đảm bảo các yêu cầu gì?

a) Thiết kế CSDL là: Là mô tả cách thức lưu trữ các dữ liệu của Phần mềm. Có hai loại lưu trữ chính là người thiết kế cần phải cân nhắc và lựa chọn:

          + Lưu trữ dưới dạng tập tin

          + Lưu trữ dưới dạng CSDL

b) Thiết kế CSDL phải đảm bào các yêu cầu:

          Đảm bảo tính bảo mật, ví dụ như khi truy xuất dữ liệu cá nhân như thông tin nhân sự, thẻ tín dụng, doanh số bán hàng hay thông tin riêng tư chúng ta cần có biện pháp đảm bảo an toàn những dữ liệu nay. Bảo mật dựa trênvai 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 của mỗi người trong hệ thống. Có thể kiểm soát được hoạt động của hệ thống, toàn bộ các thao tác của hệ thống có thể được ghi nhận, có thể ghi nhận mỗi khi đăng nhập, truy xuất.

          Đảm bảo yêu cầu tốc độ cho chương trình. Đối với một chương trình thì tốc độ rất quan trọng người dùng không thể mất quá nhiều thời gian chờ đợi để xử lý một thao tác dó đó khi thiết kế thì việc tối ưu tốc độ truy vấn trong CSDL là rất quan trọng.

          Đảm bảo hiệu quả lưu trữ (Nðu như việc thiết kế không tối ưu thì theo thời gian sử dụng dung lượng của CSDL sẽ tăng lên rất nhanh).

          Đảm bảo khả năng mở rộng: Qua thời gian những yêu cầu giải pháp sẽ thay đổi. NHững người dùng cần những chức năng mới, các quy luật đặt ra sẽ bị thay đổi. Việc thiết kế CSDL tốt là có khả năng mở rộng được.

          Đảm bảo được tính rằng buộc dữ liệu.

Câu 9: Thiết kế giao diện người dùng thường gặp phải các vấn đề gì? Nêu các hướng dẫn chung khi thiết kế giao diện?

          Các vấn đề gặp phải khi thiết kế giao diện người dùng: 4 vấn đề

          a) Thời gian hệ thống đáp ứng: Thời gian hệ thống đáp ứng là phân nàn chính cho nhiều hệ thống tương tác (Đặc biệt là những ứng dụng phân thời có dùng máy tính lớn tập trung). Nó được đo từ điểm tại đó người dùng thực hiện hành động điều khiển nào đó cho tới khi Phần mềm đáp ứng với cái ra hay hành động mong muốn. Thời gian hệ thống đáp ứng có 2 yếu tố quan trọng là: độ dài và độ biến thiên.

          b) Tiện nghi giúp đỡ người dùng: Thường có hai cách là tiện nghi trợ giúp tích hợp và tiện gnhi trợ giúp phụ thêm.

          Tiện nghi trợ giúp tích hợp: Được thiết kế trong Phần mềm ngay từ đầu. Nó thường cảm ngữ cảnh, làm cho người dùng lựa được các chủ đề có liên quan tới hàn động đang được thực hiện. Điều này rút gọn thời gian cần để người dùng thu được sự trợ giúp và tạo ra sự thân thiện của giao diện.

          Tiện nghi trợ giúp phụ thêm: Được thêm vào cho Phần mềm sau khi hệ thống đã được xây dựng. Nó thực sự là một tài liệu người dùng trực tiếp truyền với một khả năng hơi hạn chế. Người dùng có thể phải tìm kiếm qua một danh sách hàng trăm chủ đề để tìm ta hướng dẫn thích hợp, thoàng nhiều lần bắt đầu sai và nhận được thông tin không liên quan.

          c) Giải quyết thông tin lỗi: Thông báo lỗi và cảnh báo là tin dữ trao người dùng hệ thống tương tác khi một điều gì đó chạy không đúng. Tất nhiên thì thông báo lỗi và lời cảnh báo truyền đạt thông tin vô dụng và hiểu sai và chỉ làm tăng thêm nỗi chán nản của người dùng.

          Nói chùng, mọi thông báo lỗi hay cảnh báo do hệ thống tương tác ra nên có các đặc trưng sau:

          + Thông báo nên mô tả vấn đề theo lối nói người dùng có thể hiểu được.       + Thông báo nên đưa ra những lời khuyên có tính xây dựng đê phục từ lỗi.

          + Thông báo nên chỉ ra bất kỳ hậu quả lỗi tiêu cực nào (như tệp dữ liệu có thể bị hỏng) để cho người dùng có thể kiểm tra đảmbảo rằng chúng không xuất hiện.

          + Thông báo nên đi kèm với tín hiệu nghe được hay thấy được. Tức là một tiếng bíp có thể được sinh ra đi kèm với việc hiển thị thông báo, hay thông báo có thể nhấp nháy chốc lát hay được hiển thị theo mẫu dễ nhận ra như mẫu lỗi.

          + Thông báo nên có tính chât phi đánh giá: Tức là lời đưa ra đừng hàm ý trách móc người dùng.

          d) Gẵn nhãn chỉ lệnh: Chỉ lệnh cần gõ vào máy đã có thời là mốt tương tác thông dụng nhất giữa người dùng và Phần mềm hệ thống và được dùng rất phổ biến cho mọi kiểu ứng dụng. Ngày nay, việc dùng giao diện hướng cửa sổ, chỉ và chọn đã làm giảm bớt việc đưa vào chỉ lệnh gõ vào, nhưng nhiều người dùng vẫn tiếp tục ưa thích mốt tương tác theo chỉ lệnh.

Các hướng dẫn thiết kế giao diện người dùng

          Hướng dẫn về tương tácchung: Giao diện phải

          + Nhất quán

          + Cho thông tin phản hồi có nghĩa

          + Yêu cầu kiêm chứng mọi hành động phá huỷ không tầm thường

          + Cho phép dễ dàng lần ngược nhiều hành động

          + Tìm kiếm tính hiệu quả trong đối thoại, vận động và có ý nghĩa

          + Dung thứ cho sai lầm

          + Phân loại các hoạt động theo chức năng và tổ chức màn hình hài hoà theo vùng

          + Cung cấp tiện nghi trợ giúp làm ngữ cảnh

          + Dùngcác động từ giản đơn hay cụm từ ngắn để đặt tên chỉ lệnh,..

          Hướng dẫn về hiển thị thông tin

          + Chỉ thị thông tin có liên quan đến ngữ cảnh hiện tại

          + Đừng chôn vùi người dùng dưới dữ liệu hãy dùng định dạng trình bày cho phép hấp thụ nhanh chóng thông tin.

          + Dùng nhãn nhất quán, cách viết tắt chuẩn và mầu sắc dự kiến trước được

          + Cho phép người dùng duy trì ngữ cảnh trực quan

          + Đưa ra các thông báo lỗi có nghĩa

          + Dùng chữ hoa, chữ thường, thụt cấp và gộp nhóm văn bản để trợ giúp cho việc hiểu

          + Sử dụng cửa sổ để đóng khung các kiểu thông tin khác nhau

          + Dùng cách hiển thị “Tương tự” để bỉeu diễn thông tin dễ hấp thụ hơn với dạng biểu diễn này

          + Xem xét vùng hiển thị có sẵn trên màn hình và dùng nó một cách có hiệu quả…

          Hướng dẫn về vào dữ liệu

          + Tối thiểu số hành động đưa vào mà người sửdụng thực hiện

          + Duy trì sự nhất quán giữa hiển thị thông tin và cài vào dữ liệu

          + Cho phép người dùng làm phù hợp cái vào

          + Tương tác ên mềm dẻo và hài hoà với mode đưa vào ưa thích

          + Khử kích hợp các lệnh không phù hợp hiện tại

          + Để cho người dùng kiểm soát luông tương tác

          + Cung cấp trợ giúp cho mọi hành động đưa vào,…

Câu 10: Có mây phương pháp bảo trì Phần mềm, nêu đặc điểm của từng loại?

          Bảo trì Phần mềm là phức tạp và chúng ta có thể chia hoạt động bả trì ra làm bốn hoạt động như sau:

a)    Bảo trì hiệu chỉnh

Công việc bảo trì đầu tiên cần phải thực hiện là do việc kiểm tra chương trình không thể tránh được mỗi lỗi ẩn chứa bên trong một hệ Phần mềm lớn. Trong khi sử dụng bất kỹ một chương trình lớn nào, các lỗi sẽ được bảo vệ lại cho người phát triển.

Bảo trì hiệu chỉnh chính là quá tình phân tích và hiệu chinh một hay nhiều lỗi của chương trình.

b)    Bảo trì tiếp hợp

Hoạt động thứ hai diễn ra bởi sự thay đổi thường xuyên môi trường. Những thế hệ phân cứng mới dường như được công bố theo chu trình 24 tháng một lần. Những hệ điều hành mới hay phiên bản mới của các các hệ cũ đều đặn xuất hiện; thiết bị ngoại vi và các thành phần hệ thống khác liên tục được nâng cấp và thay đổi. Thời gian hữu dụng của một Phần mềm ứng dụng mặt khác lại dễ dang vượt qua thời hạn mười năm, lâu hơn môi trường hệ thống đã phát triển nó đầu tiên.

Bảo trì tiến hợp là hoạt động sửađổi Phần mềm để thích ứng được với những thay đổi của môi trường.

c)     Bảo trì hoàn thiện

Hoạt động thứ ba diễn ra khi một Phần mềm đã được hoàn tất thành công. Hoạt động này chiếm hầu hết các công sức tiêu tốn cho việc bảo trì Phần mềm. Lúc sử dụng, các yêu cầu về những khả năng mới, các thay đổi những chức năng đã có, và các mở rộng tổng quát được người dùng gửi đến.

Để thoả mãn những yêu cầu phát triển của người sửdụng, ta tiến hành bảo trì hoàn thiện.

d)    Bảo trì phòng ngừa

Bảo trì phòng ngừa là hoạt động bảo trì diễn ra khi Phần mềm được thay đổi để cải thiện tính năng bảo trì hay độ tin cậy trong tương lai hoặc để cung cấp một nền tẳng tốt hơn cho những mở rộng sau này. bảo trì phòng ngừa, hoạt động này vẫn còn nhiều xa lạ trong thế giới Phần mềm hiện nay.

Các thuật ngữ dùng để mô tả ba hoạt động bảo trì đầu tiên là do Swanson đề xướng. Thuật ngữ thứ tư thưòng được dùng trong việc bảo trì phần cứng hay các hệ thống vật lý khác. Tuy nhiên cần chú ý rằng những điểm tương tự giữabt Phần mềm và bảo trì phần cứng có thể gây nhầm lẫn. Phần mềm khác với phần cứng, không thể tận dụng được, vì vậy hoạt động bảo trì phần cứng chủ yếu – thay thế các bộ phận bị hỏng hóc hay gãy vỡ – không được kể đến.

Trong thực tế của hoạt động bảo trì, các nhiệm vụ được làm như một phần của bảo trì tiếp hợp và bảo trì hoàn thiện cũng giống như các nhiệm vụ cần làm trong giai đoạn phát triển của một chu trình Phần mềm. Để tiếp hợp hay hoàn  thiện, chúng ta đều phải xác định yêu cầu, thiết kế lại, tạo mã và kiểm tra Phần mềm có được. Thông thường các nhiệm vụ đó đã được gọi là bảo trì rồi.

Câu 11: Thế nào là kiểm thử Phần mềm. Nêu quy trình kiểm thử và đặc điểm của từng pha.

          Thế nào là kiểm thử Phần mềm: kiểm thử Phần mềm là tiến hành thí nghiệm đẻ so sánh kết quả thực tế với lý thuyết nhằm mục đích phát hiện lỗi.

Quy rình kiểm thử và đặc điểm của từng pha:

Kiểm thử thành phần:

Kiểm thử từng phần riêng biệt. Do người xây dựng thành phần tự thực hiện. Việc kiểm thử được kế thừa từ kinh nghiệm của người xây dựng nó.

Kiểm thử hệ thống:

Kiểm thử một tập các thành phần được tích hợp vớinhau để tạo ra hệ thống hoặc hệ thống con. Thông thường do một đội kiểm thử độc lập thực hiện. Việc kiểm thử dựa trên tài liệu đặc tả hệ thống.

1.     Kiểm thử hệ thống

Kiểm thử hệ thống bao gồm tích hợp các thành phần tạo ra hệ thống con; sau đó, kiểm thử hệ thống đã được tích hợp. Kiểm thử hệ thống gồm 2 pha:

+ Kiểm thử tích hợp: Đội kiểm thử truy nhập vào mã lệnh của hệ thống. Hệ thống cần kiểm thử được coi như các thành phần tích hợp với nhau

+ Kiểm thử độc lập: Đội kiểm thử sẽ kiểm thử hệ thống đầyđủ để chuyển giao, coi hệ thống như một hộp đen.

            Kiểm thử tích hợp

Kiểm thử tích hợp bao gồm việc xây dựng hệ thống từ những thành phần của nó và kiểm tra xem có vấn đề gì xảy ra từ các tương tác giữa các thành phần. Có hai cách tích hợp hệ thống đó là tích hợp từ trên xuống và tích hợp từ dưới lên.

            Tích hợp từ trên xuống (Top – Down)

Phương pháp tích hợp từ trên xuống cần một mã ngoài, được hiểu như là một bộ phận khung để gắn các chức năng gốc, các modul, và các phần khác của ứng dụng. Bộ khung này thường bắt đầu với ngôn ngữ điều khiển công việc là logic chính của ứng dụng. Logic chính được kiểm tra và lập khung theo các hệ thống phân rã. Đầu tiên chỉ có các thủ tục thiết yếu và các logic điều khiển được kiểm tra.

Khi các modul thiết yếu nhất đã được kiểm tra và chạy tốt thì mã của các modul ít quan trọng hơn sẽ được gắnvào khung và tiếp tục kiểm tra. Về lý thuyết thì, tích hợp từ trên xuống sẽ tìm thấy các lỗi thiết kế sớm hơn trong kiểm tra thao tác (Testing process) hơn các khuynh hướng khác. Phương pháp này ít hiệu quả trong việc cải thiện chất lượng của các Phần mềm chuyển giao vì bản chất tương tác của kiểm tra.

Tích hợp từ trên xuống dễ dàng hỗ trợ giao diện người dùng và thiết kế màn hình. Trong các ứng dụng tương tác, thường là bộ điều khiển màn hình được kiểm tra đầu tiên. Người dùng có thể kiểm tra sự điều khiển thông qua màn hình với các phát triển tạo mẫu.

  Tích hợp từ dưới lên (Bôttm – Up)

Nguyên tắc của tích hợp từ dưới lên là kiểm tra mọi thay đổi tại module có thể ảnh hưởng tới chức năng của nó. Trong kiểm tra từ dưới lên, toànbộ khối là đơn vị để đánh giá. Tất cả các module được mã hoá và kiểm tra riêng rẽ.

Các trường hợp kiểm tra: Các trường hợp kiểm tra là dữ liệu vào được tạo để thể hiẹn từng khối và toàn bộ hệ thống thoả mãn tất cả các yêu cầu thiết kế.

Mỗi trường hợp kiểm tra nên được phát triển để kiểm tra nghiệm các đòi hỏi thiết kế đặc trưng, thiết kế chức năng, hoặc mã đã được thoả mãn. Hơn nữa các trường hợp kiểm tra cần dự đoán các output.

Mối đơn nguyên của từng ứngdụng (Ví dụ: module, subroutine, prỏgam, utility,…) phải được kiểm tra với ít nhất hai trường hợp kiểm tra; một trường hợp chạy tốt và một trường hợp không chạy. Trong trường hợp chạy sai hệ phải đưa được thông báo, quay lại (rollback) được trạng thái ban đầu của giao dịch.

Để chắc chắn rằng các trường hợp được toà diện nhất, người ta thường dung ma trận. Chúng được dùng cho:

+ Kiểm tra đơn khối để định nhánh logic, điều kiện logic, các phần dữ liệu hoặc biên dữ liệu để kiểm tra trên cơ sở đặc tả chương trinh.

+ Kiểm tra tổ hợp để định ra yêu cầu về dữ liệu và quan hệ trong số các tương tác.

+ Kiểm tra hệ thống để xác định yêu cầu về người dùng và hệ thống từ các yêu cầu chức năng và các yêu cầu chấp nhận.

+ Phối hợp các kiểm tra trong một chiến lược; mục đích của các nhà kiểm tra là tìm ra sự cân bằng của các chiến lược cho phép họ chứng minh được ứng dụng chạy tốt mà tối thiểu hoáchi phí máy tính và nhân lực. Sử dụng duy nhất một chiến lược là rất nguy hiểm. Không có nào là duy nhất đúng. Nếu chỉ có hộp trắng (White – box) thì tài nguyên nhân lực và máy là rất tốn kém, nếu chỉ có hộp đen (Black – box) các vấn đề logic đặc trưng có thể chưa được khám phá.

Để đơn giản hoá việc xác định lõi: hệ thống nên được tích hợp tăng vong.

Các phương pháp kiểm thử tích hợp:

+ Đánh giá kiến trúc: Kiểm thử tích hợp từ trên xuống thích hợp đẻ phát hiện ra các lỗi trong kiến trúc hệ thống.

+ Minh hoạ hệ thống: Kiểm thử tích hợp từ trên xuống cho phép biểu hiện hệ thống một cách giới hạn ở những pha ban đầu của quá trìnhf xây dựng hệ thống

+ Kiểm thử cài đặt: Dễ dàng hơn với kiểm thử tích hợp từ dưới lên.

+ Kiểm thử quan sát: Các vấn đề của tất cả các phương pháp: Có thể bổ sung thêm các mã lệnh để quan sát các mãu thử.

  Kiểm thử độc lập

  Kiểm thử hộp đen (Black – box)

Kiểm thử hộp đen (Black – box) coi xử lý kết quả như là minh chứng bởi dữ liệu. Khái niệm kiểm tra là Black – box không quan tâm logic. Khuynh hướng này hiệu quả đối với các modul chức năng đơn và các hệ thống cao cấp. Ba phương pháp chính là:

+ Phân hoạch cân bằng: Mục đích của phương pháp này là tối thiểu các trường hợp kiểm tra cho trước, các mục dữ liệu vào được chia thành các nhóm dữ liệu có vai trò cân bằng nhau, mỗi nhóm đại diện cho mỗi tập dữ liệu. Nguyên tắc là bằng cách kiểm tra triệt để một mục của mỗi tập hợp, chúng ta có thể chấp nhận tất cả các mục tương đương khác của tập hợp đó cũng sẽ được kiểm tra một cách lkỹ càng.

+ Phân tích cực biên: Phân tích giá trị cực biên là một dạng nghiêm ngặt của phân hoạch cân bằng có sử dụng các giá trị biên hơn là bất cứ giá trị nào trong tập cân bằng. Ví dụ: Miền giá trị của tháng là 1 – 12 và là 0 và 13. Thì 4 kiểm tra ứng với bốn trường hợp sẽ được kiểm tra phân tích cực biên thường xuyên được dùng tại các mức modul để xác định các mục dữ liệu đặc trưng cho testing.

+ Đoán lỗi: Dựa trên cơ sở trực giác và kinh nghiệm, các chuyên gia cso thể dễ dàng kiểm tra các điều kiện lỗi bằng cách đoán cái nào dễ xảy ra nhất. Ví dụ: Chia 0, nếu modul có phép chia, nên dùng phép chia 0. Vì dựa trên trực giác, nên phép thử này khó tìm hết các lỗi.

Một nhược điểm của phân hoạch cân bằng và phân tích cực biên là tổng hợp của các miền hợp không được xác định. Để bổ sung, người ta dùng sơ đồ nguyên nhân – kết quả (Cause – Effect Graphing). Sơ đồ nguyên nhân – kết quả chỉ ra các đầu ra và thông tin di chuyền như là hệ quả và các đầu vào gây ra hậu quả trên. Cácký hiệu graphic xác định tương tác, lựa chọn, logic và các điều kiện tương đương. Một vòng đại diện một dãy các thao tác không có điểm quyết định hoặc điều khiển. Mỗi dòng biểu diễn một lớp cân bằng của dữ liệu và các điều kiện sử dụng nó. Mỗi lần graph được thực hiện ít nhất một giá trị có nghĩa và một không có nghĩa cho mỗi tập được thử.

Ví dụ: Kiểm thử hộp đen chúng ta có thể đưa ra các hướng dẫn kiểm thử cho đội kiểm thử. Hướng dẫn kiểm thử giúp họ lựa chọn mẫu thử nhằm phát hiện ra khiếm khuyết của hệ thống.

Hình 3                                                        

+ Lựa chọn các đầu vào sao cho hệ thống có thể đưa ra tất cả các thông báo lỗi.

+ Thiết kế đầu vào sao cho vùng nhớ đệm bị tràn.

+ Lặp lại nhiều lần cùng một đầu vào hoặc một chuỗi các đầu vào.

+ ép hệ thống tạo ra những kết quả không hợp lệ.

+ Buộc cho các kết quả tính phải quá lớn hoặc quá nhỏ.

Ngoài ra, chúng ta có thể sử dụng ca sử dụng hoặc biểu đồ tuần tự để hỗ trợ cho quá trình kiểm thử. Ca sử dụng có thể là phàn cơp bản để đưa ra những mẫu thử hệ thống. Nó giúp xác định các thao tác để kiểm thử và giúp thiết kế các ca sử dụng được yêu cầu. Kèm theo biểu đồ tuần tự tương ứng, chúng ta sẽ srư dụng các đầu ra và đầu vao của nó để tạo ra các mẵủth.

Kiểm thử độc lập có thể bao gồm kiểm thử các thuộc tính rõ nét của hệ thống như hiệu năng và độ tin cậy.

Kiểm thử hiệu năng bao gồm việc lập kế hoạch cho một tập hợp các mẫu thử và tải  trọng của nó có thể tăng lên nhanh chóng cho đến khi hiệu năng của hệ thống là không thể chấp nhận được.

Kiểm thử áp lực thử nghiệm hệ thống trên tải trọng thiết kế tối đa củanó. áp lực hệ thống thường gây ra những khiếm khuyết của hệ thống.

Kiểm thử áp lực hệ thống xác định những ứng xử lỗi, giúp kiểm tra những lỗi không thể chấp nhận được của các dịch vụ hoặc dữ liệu. Kiểm thử áp lực thích hợp với những hệ thống phân tán.

2.     Kiểm thử thành phần

            Kiểm thử lớp đối tượng

Kiểm thử lớp đối tượng nhằm kiểm tra mức độ hoàn thiện của lớp, bao gồm:

+ Kiểm thử tất cả các thao tác được gắn với đối tượng

+ Thiết lập và kiểm tra tất cả các thuộc tính của đối tượng

+ Thực nghiệm tất cả các trạng thái có thể của đối tượng

Kỹ thuật thừa kế gây khó khăn cho việc thiết kế kiểm thử lớp đối tượng vì thông tin được kiểm thử không được hạn chế.

Trong quá trình kiểm thử lớp đối tượng, chúng ta cần phải xác định các trường hợp kiểm thử đối với tất cả các phương thức của đối tượng. Đồng thời, sử dụng mô hình trạng thái để xác định chuỗi dịch chuyển trạng thái và chuỗi các sự kiện gây ra sự dịch chuyển đó.

            Kiểm thử giao diện

Mục đích của kiểm thử giao diện là để phát hiện các lỗi của giao diện hoặc những giả thiết không hợp lý về giao diện. Kiểm thử giao diện đặc biệt quan trọng trong phát triển hướng đối tượng khi các đối tượng được định nghĩa bởi giao diện của nó.

Hình 4

Hình 4: Kiểm thử giao diện

Giao diện gồm các loại sau:

+ Giao diện tham số: Dữ liệu được truyền tưg thủ tục này tới thủ tục khác.

+ Giao diện bộ nhớ dùng chung: Các thủ tục hoặc hàm sử dụng chung khối bộ nhớ.

+ Giao diện thủ tục: Hệ thống con chưa một tập các thủ tục để các hệ thống con khác gọi tới.

+ Giao diện truyền thông điệp: Các hệ thống con yêu cầu các dịch vụ từ những hệ thống con khác. Các loại lỗi thường xảy ra đối với giao diện bao gồm:

- Lạm dụng giao diện: Một thành phần gọi tới các thành phần khác và gây ra các lỗi trong khi sử dụng giao diện của nó.

- Không hiểu rõ giao diện: Thành phần được gắn với các giả thiết về ứng xử của nó với thành phần được gọi, nhưng thành phần này lại sai.

- Lỗi về thời gian: Các thành phần gọi và thành phần được gọi thao tác với tốc độ khác nhau và nhnwgx dữ liệu cũ lại được truy cập.

Hướng dẫn kiểm thử thành phần:

+ Thiết kế các mẫu thử với những tham số gửi tới thủ tục được gọi có giá trị cận biên.

+ Luôn luôn kiểm thử các tham số con trỏ với con trỏ null.

+ Thiết kế những mẫu tử sao cho có thể gây ra lỗi trên thành phần.

+ Thiết kế kiểm thử áp lực trên các hệ thống truyền thông điệp.

+ Trong những hệ thống có bộ nhớ làm chung, nên biến đổi thứ tự mà trong đó các thành phần tương tác với nhau.

Phần II

Câu 1: Phần mềm là gì? Các đặc trưng của nó? Phân loại phần mềm và nội dung cơ bản của mỗi loại?

TL:

* Khái niệm phần mềm:

Phần mềm được hiểu là chương trình, tài liệu mô tả chương trình, tài liệu hỗ trợ, nội dung thông tin số hoá.

Trong đó:

Chương trình là tập các lệnh khi thực hiện sẽ cho hoạt động và kết quả mong muốn.

 Tài liệu mô tả Chương trình là các đặc tả yêu cầu, đặc tả thiết kế hệ thống và phần mềm.

 Tài liệu hỗ trợ là Tài liệu hướng dẫn sử dụng, hướng dẫn bảo trì và các tài liệu khác

Nội dung thông tin số hoá là CSDL, các chương trình tiện ích, phần mềm sử dụng hay phụ trợ.

* Các đặc trưng của phần mềm

Phần mềm là phần tử hệ thống logic chưa không phải là hệ thống vật lý. Do đó phần mềm có đặc trưng khác biệt đáng kể với các đặc trưng của phằn cứng.

1) Phần mềm được phát triển hay được kỹ nghệ hoá, nó không được chế tạo theo nghĩa cổ điển:

          Hai quá trình này phụ thuộc vào con người

          Chi phí phần mềm tập trung vào kỹ nghệ -> khái niệm xưởng phần mềm   -> khuyến cáo sử dụng công cụ tự động.

2) Phần mềm không “Hỏng đi”

          Phần mềm  không cảm ứng đối với những khiếm khuyết môi trường vốn gây cho phần cứng bị  mòn cũ đi

Thực tế, phần mềm  sẽ trải qua sự thay đổi (bảo trì). Khi thay đổi được thực hiện có thể là một số khiếm khuyết mới sẽ được đưa vào, gây ra cho đường cong tỷ lệ hỏng hóc trở thành có đầu nhọn như trong hình vẽ dưới đây. Trước khi đường cong đó có thể trở về tỷ lệ hỏng hóc ổn định ban đầu thì một thay đổi khác lại được yêu cầu, lại gây ra đường cong phát sinh đỉnh nhọn một lần nữa. Dần dần, mức tỷ lệ hỏng hóc tối thiểu bắt đầu nâng lên – phần mềm bị thoái hoá  do sự thay đổi.

Nhận  xét:

          Phần cứng hỏng hóc “vật tư thay thế”, nhưng không có phần mềm thay thế cho phần mềm. Mọi hỏng hóc phần mềm đều chỉ ra lỗi trong thiết kế hay trong tiến trình chuyển thiết kế thành mã máy thực hiện được. Do đó, việc bảo trì phần mềm bao gồm độ phức tạp phụ thêm đáng kể so với bảo trì phần cứng.

3) Phần lớn phần mềm đều được xây dựng theo đơn đặt hàng, chứ ít khi được lắp giáp từ các thành phần có sẵn.

          Các thiết kế và xây dựng phần cứng điều khiển cho 1 sản phẩm dựa trên bộ vi xử lý: Vẽ sơ đồ mạch số -> thực hiện phân tích để đảm bảo chức năng đúng -> phân loại các danh mục thành phần -> gắn với mỗi mạch tích hợp (thường gọi là “IC” hay “Chip”) một số hiệu một chức năng đã định hợp lệ một giao diện đã xác định rõ, một tập các tích hợp chuẩn hoá.

          Phần mềm:

          + Không có danh mục các thành phần

          + Đặt hàng với đơn vị hoàn chỉnh, không phải là những thành phần có thể được lắp giáp lại thành chương trình mới.

          * Phân loại phần mềm và nội dung cơ bản của mỗi loại (7 loại).

          - Phần mềm hệ thống:

          + Là một tập hợp các chương trình  được viết để phục vụ cho các chương trình khác.

          + Xử lý cấu trúc thông tin phức tạp nhưng xác định (trình biên dịch, trình biên soạn, tiện ích quản lý tệp).

          + Đặc trưng bởi tương tác chủ yếu với phần cứng máy tính

          + Phục vụ nhiều người dùng

          + Cấu trúc dữ liệu phức tạp và nhiều giao diện ngoài

          - Phần mềm thời gian thực:

          Phần mềm điều phối hoặc phân tích hoặc kiểm soát các sự kiện thế giới thực ngay khi chúng xuất hiện được gọi là phần mềm thời gian thực.

          Phần mềm thời gian thực bao gồm các yếu tố:

          + Một thành phần thu thập dữ  liệu để thu và định dạng thông tin từ ngoài

          + Một thành phần phân tích để biến đổi thông tin theo yêu cầu của ứng dụng

          + Một thành phần kiểm soát hoặc đưa ra đáp ứng môi trường ngoài

          + Một thành phần điều phối để điều hoà các thành phần khác sao cho có thể duy trì việc đáp ứng thời gian thực.

          Hệ thống thời gian thực phải đáp ứng trong những ràng buộc thời gian chặt chẽ.

          - Phần mềm nghiệp vụ

          + Xử ly thông tin nghiệp vụ và là lĩnh vực ứng dụng phần mềm lớn nhất

          + Các hệ thống rời rạc: Hệ thống tin quản lý

          + Các ứng dụng phần mềm nghiệp vụ còn bao gồm cả tính toán tương tác (Như sử lý giao tác cho các điểm bán hàng) ngoài ứng dụng xử lý dữ liệu

          - Phần mềm khoa học và công nghệ

          + Được đặc trưng bởi các thuật toán

          + Trong ứng dụng mới, thiết kế có máy trợ giúp (CAD), có chú ý đến các đặc trưng thời gian thực và cả Phần mềm hệ thống

          - Phần mềm nhúng

          + Nằm trong bộ nhớ chỉ đọc và được dùng để điều khiển các sản phẩm và hệ thống chó người dùng và thị trường công nghiệp

          + Có thể thực hiện các chức năng rất giới hạn và huyền bí (Điều khiển bàn phím cho lò vi sóng), hay đưa ra các khả năng điều khiển và vận hành (Chức năng số hoá ở ôtô, kiểm sót xăng, biểu thị bảng đồng hồ, hệ thống phanh)

          - Phần mềm máy tính cá nhân

          + Bùng nổ trong hơn thập kỷ qua (Xử lý văn bản, trang tính, đồ hoạ, quản trị CSDL)

          + Tiếp tục biểu thị thiết kế giao diện người – máy: Được cải tiến nhiều nhất

          - Phần mềm trí tuệ nhân tạo

          + Dùng các thuật toán phi số để giải quyết các vấn đề phức tạp m tính toán hay phân tích trực tiếp không quản lý nổi

          + Hoạt động mạnh nhất là hệ chuyên gia (Hệ cơ sở tri thức)

          + Lĩnh vực nhận dạng (Hình ảnh và tiếng nói)

          + Chứng minh định lý và chơi trò chơi

          + Phát triển mạnh nơ ron nhân tạo: Mô phỏng cấu trúc xử lý trong bộ óc.

Câu 2: Định nghĩa CNPM? Các yếu tố chủ chốt trong CNPM là gì? Hiểu và nêu các phương pháp CNPM? Các thành phần chính trong của một phương pháp?

TL:

Khái niệm công nghệ Phần mềm:

          Là lĩnh vực nghiên cứu của tin hoc nhầm đề xuất các nguyên lý, phương pháp, công cụ.

          Cách tiếp cận & phương tiện phục vụ cho việc thiết kế & cài đặt các sản phẩm 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 máy tính thật. Nó là phát triển cảu công nghệ phần cứng & hệ thống. Nó bào gồm là 1 tập các bước chứa đựng 3 yếu tố chủ chốt.

(1)   Phương pháp

(2)   Công cụ

(3)   Thủ tục

Các yếu tố chủ chốt của công nghệ Phần mềm:

          Công nghệ Phần mềm có 3 yếu tố chủ chốt:

Phương pháp:  (Đưa ra các cách làm về mặt kỹ thuật và xây dựng Phần mềm)

          Các phương pháp bầòhm trong nhiệm vụ: Lập kế hoạch, ước lượng dự án, phân tích yêu cầu Phần mềm, thiết kế cấu trúc DL kiến trúc CT  và thủ tục thuật toán, mã hoá và kiểm thử và bảo trì.

          Các phương pháp cho công nghệ Phần mềm thường đưa ra các ký pháp đồ hoạ hay hướng tới ngôn ngữ đặc biệt, đưa ra các tiêu chuẩn về mặt chất lượng sản phẩm Phần mềm.

Công cụ: (Cung cấp hỗ trợ tự động hay bán tự động cho từng phương pháp)

          Khi các công cụ tích hợp đến mức thành thông tin cho chúng tạo ta các công cụ khác thì hệ thống hỗ trợ cho việc phát triển Phần mềm đã được thiết lập.

Thủ tục:

          + Xác định ra trình tự đưa ra các phương pháp được sử dụng

          + Tạo sản phẩm cần bàn giao: Tài liệu báo cáo, bản mẫu,… Cần cho việc kiểm soát dễ đảm bảo chất lượng và điều hoà thay đổi.

          + Xác định cột mốc để cho người quản lý Phần mềm nắm bắt được tiến độ.

Câu 3: Công cụ cho CNPM là cái gì? Nêu các loại công cụ? Trình bày hiểu biết về CASE?

Công cụ Phần mềm là:  Những gì liên quan đến việc cung cấp các phương tiện hỗ trợ tự động hay bán tự động cho các tầng quá trình và phương pháp của công nghệ Phần mềm.

Các loại công cụ: Có rất nhiều loại công cụ cho CNPM, nhưng công cụ chính cho CNOM là công cụ trợ giúp. Có hai loại công cụ trợ giúp:

          + Công cụ Case.

          + Một số công cụ được cung cấp tự động cho việc sinh mã.

Case:

          Case là các hệ thống thương được sử dụng để hỗ trợ trong quy trình xây dựng Phần mềm. Nó bao gồm cócác loại ICASE, Upper CASE và Lower CASE, ICASE nghĩalà “Intergrated” CASE haylà CASE tích hợp, “Upper” nghĩa là công cụ ý tưởng hay chỉ là thiết kế logic, “Lower” nghĩalà công cụ chỉ hỗ trợ lập trình.

          Môi trường CASE chuẩn bao gồm một kho chứa, các công cụ đồ hoạ, Phần mềm sạon thảo văn bản, Phần mềm giao diện kho chứa, Phần mềm đánh giá, và giao diện người sử dụng.

Một kho chứa là một từ điển dữ liệu hỗ trợ định nghĩa về các kiểu đối tượng khác nhau và quan hệ giữa các đối tượng đó. Các công cụ đồ hoạ hỗ trộch việc phát triển dạng sơ đồ và đánh gía sự hoàn chỉnh của sơ đồ đã được xác định trước. Phần mềm văn bản cho phép định dnạg dữ liệu đựoc dùng (Đồ hoạ hoặc văn bản). Phần mềm đánh giá là trí tụê của CASE. Phần mềm này phân tích các đầu vào của sơ đồ hoặc kho chứa và xác định xem chúng có cú pháp hoàn chỉnh hay không (Ví dụ có thoả mãn các định nghĩa của kiểu dữ liệu thành phần không), và chúng có tương thích với các đối tượng tồn tại khác trong ứng dụng hay không. Giao diện người dùng cung cấp các màn hình và các báo cáo để xử lý tương tác và gián tiếp.

          CASE lý tưởng phải cung cấp đầy đủ hỗ trợ tự động cho toàn bộ chu kỳ tồn tại của dự án, bắt đầu bằng việc phân tích ở mức xí ngiệp, duy trì công việc và kết thúc. CASE lý tưởng do đó trở thành tiêu điểm của mọi công việc nằm trong công nghệ Phần mềm, và công việc của kỹ sư hệ thống tập trung vào khía cạnh logic của thiết kế. Công cụ CASE lý tưởng cũng có thể cung cấp về mặt kỹ thuật, dữ liệu và thực hiện thiết kế của tổ chức, lập dự án và kiểm tra nhóm làm việc trong các ứng dụng, chuyển hoá dữ liệu, sơ đồ xây dựng cơ sở dữ liệu, xây dựng mã đơn giản bằng ngôn ngữ người sử dụng lựa chọn, tự động kiểm tra mã sinh ra đề phòng các lỗi logic và đánh giá sự hoàn chỉnh và đúng đắn trong quá trình làm việc một cách thông minh. Công cụ CASE thực hiện sự tiên tiến phải nhận ra các thành phần đữ có trong kho chứa sử dụng lại việc phân tích, thiết kế và mã nguồn.

          Kho chứa của CASE xác định đồng thời cái gì được hỗ trợ và trong phạm vi nào đó, có thể là hỗ trợ được bào nhiêu. Kho chứa là một siêu từ điển có thể nhập và lưu trữ siêu dữ liệu. Chẳng hạn, một phần tử dữ liệu trong một ứng dụng là dữ liệu, các thuộc tính của nó tạo thành dữ liệu trao đổi có thể lưu trữ trong từ điển. Các thuộc tính của một phần tử bao gồm kiểu dữ liệu, kích thước, dung lượng, tần suất thay đổi và tiêu chuẩn soạn thảo. Một kho chứa CASE hoạt động như là một hệ quản trị cơ sở dữ liệu phục vụ cho hoạt động kỹ sư, cung cấp khả năng mở rộng lưu giữ dữ liệu trao đổi và duy trì tất cả các thành phần và mối liên hệ qua lại với chúng.

          Sự thông minh trong CASE thể hiện ở hai dạng chính: Thông minh của giao diện và thông minh của sản phẩm CASE. Giao diện phải cung cấp cả kiểu thao tác cho người mới tập sự và cho người đã có kinh nghiệm. Nóphải cho phép khả năng một công việc được lưu giữ và tiếp tục lại. Công cụ này có thể được thay đổi theo yêu cầu cá nhân của người sử dụng. Ví dụ, nếu tôi in màu vàng trên nền xanh, tôi sẽ gọi một lược đồ dòng dữ liệu, và tôi phải được phép thay đổi giá trị ngầm định và dùng các thuật ngữ và dạng của mình.

          Các dạng biến đổi các giá trị đưa vào phải được phán ánh thông qua các tập sơ đồ. Điều này có nghĩa là nếu người dùng đưa các thực thể và các thuộc tính vào một kho chứa. Khi anh ta di chuyển để triển khai một lược đồ đồ hoạ quan hệ thực thể, thông tin trong kho chứa phải được phản ánh trên lược đồ.

          Trí tụê của sản phẩm CASE bao gồm việc phân tích bên trong và giữa các kiểu lược đồ mà đầu vào kho chứa. Trong trường hợp lý tưởng yêu cầu của ứng dụng A nếu xung đột với mục tiêu cuả xí nghiệp Z, sẽ phải được bật cơ báo để xem ý kiến của người quản lý.

          CASE lý tưởng phải cho phép người sử dụng phân tách và tích hợp các ứng dụng khác nhau một cách dễ dàng. Ví dụ, một Công ty có thể muốn tư liệu hoá tất cả ứng dụng đã sử dụng và bắt đầu quản lý điện tử chúng. Khi ngươpì sử dụng xác định một ứng dụng mới có thể muốn tích hợp nó với một ứng dụng cũ, họ phải được phép để tạo ra một định nghĩa thứ 3 để làm sáng tỏ sự chồng chéo dư thừa không chắc chắn và các vấn đề khác mà các tích hợp gặp phải.

Theo quy luật 40 – 20 – 40 của việc triển khai hệ thống, 40% thời gian cảu dự án được dùng phân tích và thiết kế, 20% dành cho lập trình và 40% còn lại để chạy thử. Hướng hiện tại của các nhà bán sản phẩm là giảm bớt mã, do đó giảm đi 20% phát triển. Như CASE lý tưởng sẽ còn có thể giảm được 40% thời gian chạy thử. Các công cụ kiểm tra CASE không cần thiết bằng các vấn đề khác (Chẳng hạn cho sản phẩm làm việc tự do lỗi).

Câu 4: Các thủ tục trong CNPM? ý nghĩa của nó?

Các thủ tục trong CNPM: là chất keo dán các phương pháp và công cụ của CNPM, làm cho chúng được sử dụng hợp lý và đúng hạn trong quá trìh phát triển Phần mềm.

ý nghĩa:

+ Xác định ra trình tự các phương pháp sẽ được áp dụng

+ Tạo sản phẩm cần bàn giao (tài liệu báo cáo, bản mẫu,…) cần cho việc kiểm soát để đảm bảo chất lượng và điều hoà thay đổi.

+ Xác định những cột mốc để cho người quản lý Phần mềm nắm được tiến độ.

Câu 5: Tiến trình Phần mềm là gì? mô hình tiến trình Phần mềm là gì? Trình bày mô hình của một số tiến trình cơ bản?

1. Tiến trình Phần mềm là một tập hợp các hành động mà mục đích của nó là xây dựng và phát triển  Phần mềm. Những hành động thường được thực hiện trong các tiến trình Phần mềm bao gồm:

+Đặc tả: Đặc tả những gì hệ thống phải làm và các ràng buộc trong quá trình xây dựng hệ thống.

+Phát triển: Xây dựng hệ thống Phần mềm

+ Kiểm thử: Kiểm tra xem liệu Phần mềm tương ứng với sự thay đổi yêu cầu

+Mở rộng: Điều chỉnh và thay đổi Phần mềm tương ứng với sự thay đổi yêu cầu

- Những loại hệ thống khác nhau sẽ cần những quy trình phát triển khác nhau. Ví dụ, hệ thống thời gian thực yêu cầu phải hoàn thành đặc tả hệ thống trước khi chuyển sang giai đoạn xây dựng nó. Nhưng với hệ thống thương mại điện tử, chúng ta có thể vừa đặc tả vừa xây dựng chương trình một cách đồng thời.

- Tuy nhiên, nếu chúng ta không sử dụng một quy trình phát triển hệ thống thích hợp thì có thể làm giảm chất lượng của hệ thống và tăng chi phí xây dựng.

2. Mô hình tiến trình phát triển Phần mềm là một thể hiện đơn giản của một tiến trình Phần mềm, và nó được biểu diễn từ một góc độ cụ thể.

3. Một số mô hình phát triển Phần mềm phổ biến thường được sử dụng:

- Mô hình thác nước

- Mô hình xây dựng tiến triển

- Công nghệ Phần mềm dựa thành phần

- Mô hình phát triển lặp lại, tăng thêm

- Mô hình xoắn ốc

a) Mô hình thác nước

- Các pha của mô hình thác nước bao gồm:

+ Phân tích và xác định các yêu cầu

+ Thiết kế hệ thống và Phần mềm

+Cài đặt và kiểm thử đơn vị

+ Tích hợp và kiểm thử hệ thống

+ Vận hành và bảo trì

- Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự, kết thúc pha trước, rồi mới được thực hiện pha tiếp theo. Do đó, nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện. Giả sử, pha phân tích và xác định yêu cầu đã  hoàn tất và chuyển sang pha kế tiếp, nhưng lúc này lại có sự thay đổi yêu cầu của người sử dụng, thì chỉ còn cách là phải thực hiện lại từ đầu.

- Cho nên, mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế. Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định.

Hình 1: Mô hình thác nước

b) Mô hình xây dựng tiến triển (mô hình làm bản mẫu)

- Mô hình xây dựng tiến triển dựa trên  ý tưởng xây dựng một mẫu thử ban đầu và đưa cho người sử dụng xem xét; sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thoả mãn yêu cầu của người sử dụng thì dừng lại.

- Có hai phương pháp để thực hiện mô hình này:

+ Phát triển thăm dò: Mục đích của nó là để làm việc với khách hàng và để đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu. Phương pháp này thường bắt đầu thực hiẹn với những yêu cầu được tìm hiểu rõ ràng và sau đó, bổ sung những đặc điểm mới được đề xuất bởi khách hàng. Cuối cùng, khi các yêu cầu của người sử dụng được thoả mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống.

+ Loại bỏ mẫu thử:  Mục đích là để tìm hiểu các yêu cầu của hệ thống. Phương pháp này thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử dụng. Từ đó, ta có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này mẫu thử không còn cần thiết nữa. Như vậy,  mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng.

                            Hình 2: Mô hình xây dựng tiến triển

- Tuy nhiên, nhược điểm của mô hình xây dựng tiến triển là: Thiếu tầm nhìn của cả quy trình; cả hệ thống thường hướng cấu trúc nghèo nàn; yêu cầu các kỹ năng đặc biệt (ví dụ: Các ngôn ngữ để tạo ra mẫu thử nhanh chóng).

- Mô hình xây dựng tiến triển chỉ nên áp dụng với những hệ thống có tương tác ở mức độ nhỏ hoặc vừa, trên một phần của những hệ thống lớn; Hoặc những hệ thống có thời gian chu kỳ tồn tại ngắn.

c) Mô hình công nghệ Phần mềm dựa thành phần

- Mô hình này dựa trên kỹ thuật tái sử dụng một cách có hệ thống; trong đó hệ thống được tích hợp từ nhiều thành phần đang tồn tại hoặc các thành phần thương mại COTS (Commercial – off- the- shelf).

- Các trạng thái chính của quy trình bao gồm:

+ Phân tích thành phần sẵn có

+ Điều chỉnh yêu cầu

+ Thiết kế hệ thống với kỹ thuật tái sử dụng

+ Xây dựng và tích hợp hệ thống

Hình 3:

Hình 3: Công nghệ Phần mềm hướng thành phần

d) Mô hình phát triển lặp lại, tăng thêm

- Mô hình này được đề xuất dựa trên ý tưởng thay vì phải xây dựng và chuyển giao hệ thống một lần thì sẽ được chia thành nhiều vòng, tăng dần. Mỗi vòng là một phần kết quả của một chức năng được yêu cầu.

- Các yêu cầu của người sử dụng được đánh thứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiên càng cao thì càng ở trong những vòng phát triển sớm hơn.

Hình 4: kết quả tăng dần

- Từ đó, chúng ta có thể thấy rõ một số ưu điểm của mô hình phát triển tăng vòng:

+ Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả thực hiện được cho khách hàng nên các chức năng của hệ thống có thể nhìn thấy sớm hơn.

+ Các vòng trước đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.

+ Những chức năng của hệ thống có thứ tự ưu tiên càng cao thì sẽ được kiểm thử càng kỹ.

e) Mô hình xoắn ốc

- Trong mô hình xoắn ốc, quy trình phát triển Phần mềm được biểu diễn như một vòng xoắn ốc. Các pha trong quy trình phát triển xoắn ốc bao gồm:

+ Thiết lập mục tiêu: Xác định mục tiêu cho từng pha của dự án

+ Đánh giá và giảm thiểu rủi ro: Rủi ro được đánh giá và thực hiện các hành động để giảm thiểu rủi ro

+ Phát triển và đánh giá: Sau khi đánh giá rủi ro, một mô hình xây dựng hệ thống sẽ được lựa chọn từ những mô hình chung

+ Lập kế hoạch: Đánh giá dự án và các pha tiếp theo của mô hình xoắn ốc sẽ được lập kế hoạch.

Hình 5: Mô hình xoắn ốc

Câu 6: Yêu cầu Phần mềm là gì? Phân biệt yêu cầu và nhu cầu? Cho ví dụ minh hoạ? Phân loại yêu cầu Phần mềm và trình bày nội dung và lấy ví dụ minh hoạ về các loại đó?

TL:

1. Yêu cầu hệ thống là bản đặc tả các dịch vụ mà hệ thống cung cấp và các ràng buộc để xây dựng và vận hành hệ thống

- Quá trình tìm kiếm, phân tích, tư liệu hoá, và kiểm tra các dịch vụ và các ràng buộc của hệ thống được gọi là kỹ thuật xác định yêu cầu (Requirements Engineering – RE).

- Chúng ta cần phải viết các yêu cầu ở các mức chi tiết khác nhau vì có nhiều người sử dụng khác nhau  sử dụng chúng theo những cách khác nhau.

- Mục tiêu:

+ Phân loại được các yêu cầu khác nhau và đặc điểm của từng loại

+ Có kỹ năng đặc tả các loại yêu cầu khác nhau

+ Nắm được cấu trúc của một tài liệu đặc tả yêu cầu

- Ví dụ: Hệ thống thư viện (LIBSYS) cung cấp một giao diện đơn giản để lưu CSDL về các bào báo trên các thư viện khác nhau. Người sử dụgn có thể tìm kiếm, dowload và in những tài liệu này.

2. Phân loại yêu cầu

Các yêu cầu của hệ thống Phần mềm thường được chia thành ba loại: Yêu cầu chức năng, yêu cầu phi chức năng và yêu cầu miền ứng dụng. Tuy nhiên, trong thực tế chúng ta rất khó phân biệt ba loại yêu cầu này một cách rõ ràng.

a) Yêu cầu chức năng

- Đặt vấn đề:

+ Để xây dựng một hệ thống có thể dùng được thực sự, trước hết nó phải đạt được yêu cầu gì?

+ Yêu cầu  chức năng có phải là quan trọng nhất không?

+ Nếu ta không xác định đầy đủ, rõ ràng các yêu cầu chức năng thì sẽ xảy ra  chuyện gì?

- Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các chức năng hoặc các dịch vụ của hệ thống  một cách chi tiết.

- Đặc điểm của yêu cầu chức năng:

+ Tính mập mờ, không rõ ràng của các yêu cầu: Vấn đề này xảy ra khi các yêu cầu không được xác định một cách cẩn thận. Các yêu cầu mập mờ có thể được xây dựng và người sử dụng hiểu theo nhiều cách khác nhau.

+ Tính hoàn thiện và nhất quán: Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi tiết và không có sự xung đột hoặc đối ngược giữa các yêu cầu. Tuy nhiên, trong thực tế rất khó có thể đạt được điều này.

-Ví dụ: Các yêu cầu chức năng của LYBSYS

+ Người sử dụng có thể tìm kiếm tất cả CSDL hoặc một tập con của CSDL

+ Hệ thống  sẽ cung cấp những giao diện thích hợp để người sử dụng đọc tài liệu

+ Tất cả những hoá đơn mà người sử dụng đăng ký để in sao tài liệu có một mã duy nhất

b) Yêu cầu phi chức năng

- Đặt vấn đề:

+ Nếu hệ thống chỉ thoả mãn những yêu cầu chức năng thì đã đủ chưa?

+ Ví dụ hệ thống không tiện dụng đối với người sử dụng thì sao?

+ Yêu cầu phi chức năng bao gồm những vấn đề gì?

- Yêu cầu phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ thống. Yêu cầu phi chức năng thường định nghĩa các thuộc tính như: Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ…và các ràng buộc của hệ thống như: Khả năng của thiết bị vào/ra, giao diện…

- Một số yêu cầu phi chức năng còn có liên quan đến quy trình xây dựng hệ thống. Ví dụ: các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ  lập trình….

- Các yêu cầu phi chức năng có thể là hạn chế hơn những yêu cầu chức năng. Nhưng nếu nó không được thoả mãn thì hệ thống sẽ không sử dụng được.

- Các yêu cầu phi chức năng xuất hiện làdo yêu cầu của người sử dụng, ràng buộc về ngân sách, các chính sách của tổ chức sử dụng hệ thống, yêu cầu tương thích giữa phần cứng và Phần mềm và các tác nhân ngoài khác. Do đó, chúng ta có thể phân loại các yêu cầu phi chức năng như sau:

+ Các yêu cầu về sản phẩm xác định ứng  xử của sản phẩm như: hiệu năng, khả năng sử dụng, độ tin cậy…của sản phẩm.

+ Các yêu cầu về tổ chức: Các yêu cầu này được lấy từ những chính sách và quy tắc của khách hàng hoặc tổ chức sử dụng hệ thống

+ Các yêu cầu ngoài: được xác định từ các tác nhân ngoài của hệ thống

Hình: Phân loại các yêu cầu phi chức năng

- Ví dụ: Các yêu cầu phi chức năng của LIBSYS

+ Yêu cầu về sản phẩm: LIBSYS phải được cài đặt bằng HTML mà khôn có frame hoặc java applets.

+ Yêu cầu về mặt tổ chức: Quy trình xây dựng hệ thống và các tài liệu chuyển giao phải thoả mãn các quy tắc đã được định nghĩa trong XYZCo-SP-STAN-95

+ Yêu cầu ngoài: Hệ thống không được để lộ các thông tin cá nhân của khách hàng.

- Nói chung, chúng ta rất khó xác định chính xác và rất khó  thẩm tra những yêu cầu phi chức năng mập mờ. Do đó, trong tài liệu đặc tả yêu cầu, người ta thường bổ sung các mục tiêu. Mục tiêu rất hữu ích đối với người phát triển hệ thống khi nó truyền tải được những mong muốn của người sử dụng hệ thống. Còn với những yêu cầu phi chức năng có thể thẩm định được là những yêu cầu chức năng có thể thẩm định được là những yêu cầu có thể kiểm thử một cách khách quan.

Tuy nhiên, trong nhiều trường hợp thường xảy ra xung đột giữa các yêu cầu phi chức năng đối với những hệ thống phức tạp.

- Vídụ: Các mục tiêu và yêu cầu phi chức năng có thể thẩm định được của LIBSYS

+ Mục tiêu của hệ thống là dễ sử dụng đối với những người sử dụng có kinh nghiệm và được tổ chức để sao cho tối thiểu hoá được lỗi.

+ Các yêu cầu phi chức năng có thể thẩm định được: Những người sử dụng có kinh nghiệm có thể sử dụng được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập huấn. Sau khoá huấn luyện này, số lỗi chương trình gây ra bởi những người sử dụng là không quá hai lỗi một ngày.

c)Yêu cầu miền ứng dụng

- Đặt vấn đề:

+ Yêu cầu đối với đội phát triển hệ thống?

+ Các yêu cầu về lĩnh vực ứng dụng của hệ thống thì thuộc vào loại nào trong hai loại trên đã trình bày.

- Yêu cầu miền ứng dụng được xác định từ miền ứng dụng của hệ thống và phản ánh các thuộc tính và ràng buộc của miền ứng dụng. Nó có thể là yêu cầu chức năng hoặc phi chức năng.

- Nếu yêu cầu miền ứng dụng không được thoả mãn thì có thể hệ thống sẽ không làm việc được.

- Sau đây là một số vấn đề liên quan đến yêu cầu miền ứng dụng:

+Khả năng có thể hiểu được: các yêu cầu được biểu diễn dưới ngôn ngữ của lĩnh vực ứng dụng.

+ ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng họ không biết cách xây dựng những yêu cầu miền ứng dụng một cách rõ ràng, mang tính kỹ thuật.

- Ví dụ: Yêu cầu về miền ứng dụng của LIBSYS

+ Giao diện người dùng chuẩn cho tất cả các CSDL đều dựa trên chuẩn Z39.50

+ Vì vấn đề bản quyền nên một số tài liệu phải xoá ngay khi vừa chuyển đến.

+ Phụ thuộc vào yêu cầu của người sử dụng, những tài liệu đó có thể được in ngay trên server và chuyển đến cho người sử dụng hoặc gửi đến cho máy in mạng.

Câu 7: Trình bày  tiến trình kỹ nghệ yêu cầu? Nội dung nghiên cứu khải thi?

TL:

1. Tìm hiểu, xác định yêu cầu

1.1 Khảo sát, tìm hiểu yêu cầu

- Theo mức độ chi tiết có thể chia các loại tài liệu yêu cầu:

+ Xác định yêu cầu: Đây là một khẳng định, bằng ngôn ngữ tự nhiên hơn là các sơ đồ, vè các dịch vụ hệ thống cần cung cấp và các ràng buộc mà hệ thống phải tuân theo. Tài liệu này cung cấp cho các thành phần: người quản lý  của bên khách hàng, người dùng cuối của hệ thống, kỹ sư của khách hàng, người quản lý ký kết hợp đồng, các kiến trúc sư hệ thống.

+ Đặc tả yêu cầu: Là tài liệu được cấu trúc mô tả hệ thống các dịch vụ chi tiết hơn. Đôi khi tài liệu này được gọi là đặc tả chức năng. Đây có thể coi là hợp đồng ký kết giữa người mua và kẻ bán Phần mềm. Tài liệu này cung cấp cho các thành phần: người dùng cuối của hệ thống, kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển Phần mềm.

+ Đặc tả Phần mềm: Là mô tả trừu tượng hơn của Phần mềm làm cở sở cho thiết kế và triển khai. Tài liệu này cung cấp cho các thành phần: Kỹ sư của khách hàng, các kỹ trúc sư hệ thống, người phát triển Phần mềm.

Xác định yêu cầu: Là mô tr trừu tượng các dịch vụ mà hệ thống được mong đợi phải cung cấp và các ràng buộc mà hệ thống phải tuân thủ khi vận hành. Nóchỉ có đặc tả phẩm hạnh bên ngoài của hệ thống mà không liên quan đến các đặc tính thiết kế. Nó phải được viết sao cho người ta có thể hiểu được mà không cần một kiến trúc chuyên môn đặc biệt nào.

          Các yêu cầu của Phần mềm được chia thành hai loại:

          Các yêu cầu hệ thống chức năng: Các dịch vụ mà hệ thống phải cung cấp

          Các yêu cầu không chức năng: Các ràng buộc mà hệ thống phải tuân theo.

          Về nguyên tắc các yêu cầu của một hệ thống phải là vừa đầy đủ, vừa tráng kiện. Đầy đủ có nghĩa là mọi yêu cầu đều phải được đặc tả. Tráng kiện có nghĩa là các yêu cầu không gây ra mâu thuẫn. Thực tế đối với các hệ lớn và phức tạp thì thực là không thể đạt được tính đầy đủ và tính tráng kiện cho phiên bản đầu của tư liệu yêu cầu Phần mềm. Vấn đề là khi duyệt lại hoặc trong các pha sau này của vòng đời Phần mềm, người ta phát hiện ra các sự không thoả mãn đó thì tư liệu yêu cầu phải được chỉnh lại.

          Về bản chất, chúng ta phải hiểu và xác định rõ những yêu cầu của khách hàng. Tuy nhiên, thường bài toán được khách hàng phát biểu bằng ngôn ngữ tự nhiên cộng thêmvới việc dùng các bảng các biểu đồ cho các người dùng dễ hiểu (xem là người dùng không biết các khái niệm chuyên môn công nghệ thông tin). Không may là ngôn ngữ được dùng này lại thường không chính xác và mơ hồ, đôi khi có sự lầm lẫn giữa các biểu thị khái niệm và các biểu thị chi tiết làm cho công việc mô tả chứa các thông tin hổ lốn được biểu diễn ở nhiều mức chi tiết khác nhau.

          ở đây, chúng ta cần chú ý rằng người đặt hàng có thể vì không hiểu biết gì về tin học nên họ không thể phát biểu chính xác và đầy đủ các yêu cầu của họ, đôi lúc thì  những cái mà người sử dụng yêu cầu và những cái mà họ cần là không giống nhau. Thêm vào đó, chúng ta lại không hiểu biết đầy đủ về đối tượng, địa bàn cho nên không thể thu thập đầy đủ và chính xác các thông tin của đối tượng và đây chính là một trong những mâu thuẫn giữa khách hàng và chúng ta. Vì vậy, trong thực tế, đối với các hệ thống lớn và phức tạp, râqts khó có vthể đạt được tính đầy đủ và thống nhất của tài liệu yêu cầu.

          Các yêu cầu được tìm hiểu còn chứa các mâu thuẫn:

          + Thiếu rõ ràng: Rât khó sử dụng ngôn ngữ tự nhiên mô tả chính xác không nhầm lẫn mà không làm khó khăn người đọc.

          + Nhầm lẫn yêu cầu: Các yêu cầu chức năng, các rnàg buô9cj, mụcđích của hệ thống và các thông tin thiết kế không được phân biệt rõ ràng.

          + Trộn lẫn yêu câu: Một số các yêu cầu khác nhau có thể được thể hiện như là một yêu cầu đơn.

          Giải quyết mâu thuẫn này, chúng ta phải: trên cơ sở nghiên cứu kỹ lĩnh vực ứng dụng và thảo luận với người sử dụng để định nghĩa chính xác các yêu của bài toán. Xác định rõ và đầy đủ bài toán là yếu tố quan trọng góp phần đảm bảo thành công của dự án. Nhiệm vụ của giai đoạn này là xây dựng được hồ sơ mô tả chi tiết về các yêu cầu, nhiệm vụ, chức năng của hệ thống dự kiến.

1.2. Đánh giá các yêu cầu

          Đánh giá các yêu cầu Phần mềm liên quan với việc cho biết các yêu cầu thực sự định nghĩa hệ thống đáp ứng đòi hỏi của khách hàng. Nếu việc đánh giá này không chính xác, các lỗi trong phần yêu cầu sẽ truyền tới thiết kế hệ thống và triển khai hệ thống. Chi phí sửa chữa lỗi sẽ rất lớn. Sự thay đổi về yêu cầu ngụ ý rằng việc thiết kế và triển khai cúng phải thay đổi theo. Một số khía cạnh của yêu cầu cần phải kiểm chứng:

          + Giá trị: Người dùng có thể nghĩ rằng hệ thống cần một số chức năng, tuy nhiên sau một số phân tích, có thể xác định các chức năng khác cần được đưa vào. Do hệ thống có nhiều loại người sử dụng nên có các yêu cầu khác nhau và không thể tránh khỏi sự thoả hiệp các nhu cầu đó.

          + Chắc chăn: Mọi yêu cầu không được mâu thuẫn với các yêu cầu khác.

          + Hoàn chỉnh: Định nghĩa cần phải bao gồm mọi chức năng và các ràng buộc.

          + Hiện thực: Không có các yêu cầu đặc biệt đến mức phi hiện thực. Có thể dự đoán trước các phát triển phần cứng,  tuy nhiên phát triển Phần mềm thì khó dự đoán hơn.

          + Mẫu: là một mô hình chạy được của hê thống được trình bày với người sử dụng. Đây là một kỹ thuật đánh giá yêu cầu hiệu quả. Nó cho phép người dùng thử nghiệm với hệ thống. Việc đánh giá lại yêu cầu không nên được coi là công việc tiếp theo của tư liệu hoá yêu câu sau khi đã hoàn thành. Các xem xét về yêu cầu định kỳ liên quan với người dùng và kỹ sư Phần mềm luôn cần thiết.

          Các xem xét yêu cầu có thể là hình thức hoặc phi hình thức. Xem xét phi hình thức liên quan việc các người ký hợp đồng thảo luận các yêu cầu với khách hàng. Nhiều lần vấn đề có thể được giải quyết dễ dàng bât ngờ khi tham khảo trực tiếp với khách hàng. Đối với yêu cầu xem xét chính thức, đội phát triển phải dẫn dắt khách hàng thông qua các yêu cầu hệ thống, giải thích các triển khai cảu mỗi yêu cầu. Nhóm rà soát phải kiểm tra mỗi yêu cầu về độ thống nhất, hoàn chỉnh cho toàn bộ tài liệu. Họ có thể phải kiểm tra:

          + Có khả năng kiểm tra: Tài liệu có  thể kiểm tra thực tế được không?

          + Khả năng hiểu biết: Tài liệu có được khách hàng hiểu biết thấu đáo hay không?

          + Lưu viết: Nguồn gốc của tài liệu có được xác định rõ ràng hay không? Rất có thể phải quay lại nguồn gốc ban đầu để đánh giá ảnh hưởng của sự thay đổi.

          + Tính thích hợp: Các yêu cầu đã phù hợp hay chưa? Có thể thay đổi các yêu cầu mà không làm ảnh hưởng lớn đến toàn bộ hệ thống không.

2. phân tích yêu cầu

          Nghiên cứu kỹ các yêu cầu của người sử dụng và của hệ thống Phần mềm để xây dựng các đặc tả về hệ thống là cần thiết, nó se xác định hành vi của hệ thống. Nhiệm vụ của giai đoạn này là phải trả lời được các câu hỏi sau:

+ Đầu vào của hệ thống là gì

+ Những quá trình cần sử lý trong hệ thống, hay hệ thống Phần mềm sẽ phải xử lý những cái gì

+ Đầu ra: Kết quả xử lý của hệ thống là gì

+ Những ràng buộc trong hệ thống, chủ yếu là mối quan hệ giữa đầu ra như thế nào

          + Trả lời được câu hỏi trên, nghãi là pahỉ xác định được chi tiết các yêu cầu làm cơ sở để đặt tả hệ thống. Đó là kết quả của sự trao đổi, thống nhất giữa người đầu tư, người sử dụng với người xây dựng hệ thống. Mục tiêu là xây dựng các hồ sơ mô tả chi tiết các yêu cầu của bài toán nhằm nêu bật được hành vi, chức năng cần thực hiện của hệ thống dự kiến.

          Như vậy, phân tích yêu cầu là qú trình suy luận các yêu cầu hệ thống thông qua quan sát hệ  thống hiện tại, thảo luận với các người sử dụng, phân tích các công việc. Việc này có thể liên quan với việc mô tạo một hay nhiều mô hình khác nhau. Nó giúp các phân tích viên hiểu biết hệ thống. Các mẫu hệ thống cũng có thể được phát triển để mô tả các yêu cầu. Ta có quy trình để có các chức năng của hệ thống

          Trong quá trình phân tích cần lưu ý đến tính khả thi cảu dự án.

          + Khả thi về kinh tế: Chi phí phát triển phải cân xứng với lợi ích mà hệ thống đem lại, gồm có: Chi phí:

          + Mua sắm: Thiết bọ, vật tư (phần cứng), tư vấn, cài đặt thiết bị, quản lý và phục vụ…

          + Chi phí cho khởi công: Phần mềm phục vụ cho hệ thống, hệ thống liên lạc (truyền dữ liệu), nhân sự ban đầu: đào tạo – huấn luyện, cải tổ tổ chức cho phù hợp,…

          + Chi phí liên quan: Chi phí nhân công phục vụ thu thập dữ liệu, sửa đổi, cập nhật hệ thống, chuẩn bị tài liệu…

          + Chi phí liên tục là tốn kém nhất, gồm: bảo trì, thuê bao, khấu hao phần cứng, chi phí phục vụ cho vận hành….

          + Lợi nhuận do sử dụng hệ thống

          + Nhiệm vụ xử lý thông tin: Giảm chi phí do xử lý tự động chính xác và két quả tốt hơn, thời gian trả lời rút ngắn,…

          + Có được từ hệ thống: Thu thập và lưu trữu dữ liệu tự động, đầy đủ, dữ liệu được chuẩn hóa, đảm bảo an toàn và an ninh dữ liệu, tương thích và chuyển đổi giữa các bộ phận, truy cập và tìm kiếm nhanh, kết nối và trao đổi diện rộng,..

          + Khả thi về kỹ thuật: Đây là vấn đề cần lưu ý vì các mục tiêu, chức năng và hiệu suất của hệ thống theo một cách nào đó là còn “mơ hồ” do vậy xét:

·       Rủi ro xây dựng: các phần từ hệ thống (Chứ năng, hiệu suất) khi thiết

kế và phân tích có tương đương hay không?

·       Có sẵn tài nguyên: Có sẵn con người và tài nguyên cần thiết để phát

triển hệ thống

·          Công nghệ: Các công nghệ liên quan cho việc phát triển hệ thống đã

có săn hay chưa?

          + Khả thhi về hợp pháp: Có sự xâm phạm, vi phạm khó khăn nào gây ra khi xây dựng hệ thống hay không.

          + Các phương án: Đánh giá về phương án tiếp cận đến việc xây dựng hệ thống.

3. đặc tả yêu cầu

3.1. Đặc tả yêu cầu

          Khi đã xác định rõ bài toàn thì bước tiếp theo là tìm hiểu xem hệ thống dự kiến sẽ yêu cầu làm cái gì. Điều quan trọng ở đây là phải xây dựng được danh sách các yêu cầu của người sử dụng. Dựa trên những yêu cầu của người sử dụng, người phát triển đưa ra các đặc tả cho hệ thống.

          Người xây dựng hệ thống phải trả lời được các câu hỏi sau:

+ Đầu ra của hệ thống là gì

          + Hệ thống sẽ phải làm cái gì để có kết quả mong muốn, nghĩa là phải xử lý những cái gì

          + Những tài nguyên mà hệ thống yêu cầu là gì

          Hiểu rõ nguồn gốc, các dạng thông tin cầncung cấp cho hệ thống hoạt động. Hệ thống sẽ phải giải quyết những vấn đề gì, những kết quả cần phải có là gì. Xác định được mối quan hệ giữa cái vào và cái ra cho quá trình hoạt động của hệ thống. Các đặc tả chi tiết phục vụ cho việc xây dựng và trắc nghiệm về hệ thống để kiểm tra xem những nhiệm vụ đã đặt ra có hoàn tất được hay không.

          ở đây, chúng ta cần chú ý là trong một số trường hợp, sẽ nảy sinh những yêu cầu mới màchỉ có thể là ta phải xây dựng lại hệ thống, tất nhiên điều này sẽ làm chậm tiến trình xây dựng và làm tăng giá thành do một vài lý do để không thể hoàn chỉnh các đặc tả đối với các hệ thống như:

          + Các hệ thống Phần mềm lớn luôn đòi hỏi cải tiến từ hiện trạng. Mặc dù các khó khăn của hệ thống hiện tại có thể xác định được nhưng các ảnh hưởng và hiệu ứng của hệ thống mớ khó có thể dự đoán trước được.

          + Hệ thống lớn thường có nhiều cộng đồng sử dụng khác nhau. Họ có yêu cầu và ưu tiên khác nhau. Các yêu cầu hệ thống cuối cùng không tránh khỏi các thoả hiệp.

          + Người trả tiền cho hệ thống và người sử dụng thường khác nhau. Các yêu cầu đưa ra do ràng buộc của các tổ chức và tài chính có thể tranh chấp với các yêu cầu của người sử dụng.

          Do 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ứcnăng và ràng buộc của hệ thống. Phân tích yêu cầu được tiếp tục xác định và đặc tả khi các yêu cầu mới nảy sinh. Đây là tài liệu thường xuyên thay đổi và nên được kiểm soát chặt chẽ.

          Ngôn ngữ tự nhiên không hoàn toàn thuận tiện cho các thiết kế viên hoặc các hợp đồng giữa các khách hàng và cán bộ phát triển hệ thống vì có một số lý do như sau:

          - Nhầm lẫn do cách hiểu các kháiniệm khác nhau giữa hai bên.

          - Đặc tả yeu 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á trình nhiều cách khác nhau.

          - Các yêu cầu không được phân hoạch tốt, khó tìm các mối quan hệ,…

          Do vậy người ta thường dùng các thay thế khác để đặc tả các yêu cầu như:

          - Ngôn ngữ tự nhiên có cấu trúc

          - Ngôn ngữ mô tả thiết kế, giống ngôn ngữ lập trình nhưng có mức trừu tượng cao hơn.

          - Ngôn ngữ đặc tả yêu cầu

          - Ghi chép graphic,

          - Đặc tả toán học,…

          Có thể chia đặc tả yêu cầu ra làm hai loại: Đặc tả phi hình thức (ngôn ngữ tự nhiên) và đặc tả hình thức (dựa trên kiến trúc toán học).

          1. Đặc tả phi hình thức

          Đặc tả phi hình thức là đặc tả sử dụng ngôn ngữ tự nhiên. Tuy nhiên 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 hoá các đặc điểm chưa rõ, chưa thống nhất giữa các bên phát triển hệ thống.

2. Đặc tả hình thức

Đặc tả hình thứ là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ gnhĩ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ứ 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 thoả mãn để có dữ liệu vào, điều kiện hậu tố là điều kiện cần thoả mãn sau khi có kết quả.

Có hai hướng tiếp cận đặc tả hình thức để phát triển các hệ thống tương đối phức tạp.

+ Tiếp cận đại số, hệ thống được mô tả dưới dạng các toán tử và các quan hệ.

+ Tiếp cận mô hình, mô hình hệ thống được cấ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ự.

Sử dụng đặc tả hình thức, ta có các thuận lợi:

+ Cho phép chúng ta thấy và hiểu được bản chất bên trong của các yêu cầu, đây là cách tốt nhất làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công việc thiết kế được thuận lợi.

+ Do chúng ta sử dụng toán học cho việc đặc tả nên có thể dựa vào các công cụ toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ của hệ thống.

+ Đặc tả hình thức, bản thân nó cho chúng ta một cách thức cho việc kiểm tra hệ thống sau này.

Tuy vây, đặc tả hình thức cũng bộc lộ một vài khó khăn:

+ Qunả 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.

3.2. Nguyên lý đặc tả

Nguyên lý 1: Phân tích chức năng với cài đặt: đặc tả là mô tả điều mong muốn chứ không phải cách thức thực hiện (cài đặt). Kết quả thu được theo dạng cái gì chứ không phải là thế nào.

Nguyên lý 2:  Cần tới ngôn ngữ đặc tả hệ thống hướng tiến trình: cần thiết đặc biệt trong trường hợp môi trường là động và sự thay đổi của nó ảnh hưởng tới hành vi của thực thể nào đó tương tác với môi trường nào đó.

Nguyên lý 3: Đặc tả phải bao gồm h có Phần mềm là một thành phàn: vì hệ thống bao gồm các thành phần tương tác với nhau, chỉ bên trong hoàn cảnh của toàn bộ hệ thống và tương tác giữa các thành phần của nó thì hành vi của một thành phần mới có thể xác định.

Nguyên lý 4: Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành.

Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức: không phải là một mô hình thiết kế hay cài đặt. Nó phải mô tả một hệ thống như cộng đồng người sử dụng cảm nhận thấy. (Các sự vật mà nó thao tác phải tương ứng với các sự vật của lĩnh vực đo; các tác nhân phải mô hình cho các cá nhân, tổ chức, trang thiết bị; các hành động họ thực hiện thì mô hình cho những hoạt động thực tế xuất hiện trong lĩnh vực;…)

Nguyên lý 6: Đặc tả phải vận hành: phải đầy đủ và hình thức để có thể được dùng trong việc xác định liệu một cài đặt được đề nghị có thoả mãn đặc tả trong những trường hợp kiểm thử tuỳ ý hay không.

Nguyên lý 7: Đặc tả hệ thống phải dung sai về tính không đầy đủ và tính nâng cao. Đặc tả không thể hoàn toàn đầy đủ do môi trường phức tạp.

+ Đặc tả là mô hình – sự trừu tượng hoá - của tình huống thực nên không đầy đủ.

+ Đặc tả sẽ tồn tại ở nhiều mức chi tiết.

+ Các công cụ phân tích được sử dụng để giúp cho  đặc tả  và kiểm thử đặc tả phải có khả năng xử lý với tính không đầy đủ.

Nguyên lý 8: Đặc tả phải được cục bộ hoá và được ghép lỏng lẻo: Đặc tả làm cơ sở cho thiết kế và cài đặt, không phải tĩnh mà là một sự vận động, đang trải qua thay đổi đáng kể nên nội dung và cấu trúc phải phù hợp. Sự thay đổi khi cần sửa đổi là tối thiểu, chỉ một phần nhỏ các thành phần có thể thâm vào hay loại bớt một cách dễ dàng.

Câu 8: Đối tượng chính của tài liệu yêu cầu là ai? Các yêu cầu  của tài liệu yêu cầu.

TL:

          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 thoả mãn bởi thiết kế thì thiết kế này được coi là giải pháp thích hợp với vấn đề.

          Về nguyên tắc, các yêu cầu cần được hoàn chỉnh và chắc chắn. Mọi chức năng hệ thống cần được đặc tả và các yêu cầu không được mâu thuẫn. Tuy nhiên các thiếu sót là không thể tránh khỏi, do vậy tài liệu nên được cấu trúc dễ cho việc thay đổi. Nội dung nên được chia thành các chương. Sáu yêu cầu cần được thoả mãn là:

+ Nó cần mô tả các hành vi hệ thống bên ngoài

+ Nó cần mô tả các ràng buộc về thực hiện

+ Nó cần phải dễ thay đổi

+ Nó phải là công cụ tham chiếu cho người bảo trì hệ thống

+ Nó cần ghi được vòng đời của hệ thống

+ Nó cần biểu thị được các đáp ứng chấp nhận được với các sự kiện không dự kiến

Cấu trúc chung của tài liệu yêu cầu Phần mềm gồm các phần như sau:

+ Giới thiệu: mô tả sự cần thiết của hệ thống. Nó cần sự mô tả sơ lược các chức năng của mình và giải thích cách làm việc với các hệ thống khác. Nó cũng cần mô tả làm thế nào hệ thống đáp ứng được toàn bộ các mục tiêu chiến lược và nghiệp vụ.

+ Thuật ngữ: Nó cần định nghĩa các khái niệm kỹ thuật được sử dụng trong tài liệu này. Không được giả định người đọc đã có kinh nghiệm.

+ Mô hình hệ thống: Phần này lập 1 hoặc nhiều mô hình hệ thống cho biết các quan hệ giữa các cấu thành hệ thống với hệ thống và môi trường của nó. Nó cần bao gồm các mô hình đối tượng , mô hình luồng dữ liệu  và ngữ  nghĩa dữ liệu.

+ Định nghĩa yêu cầu chức năng: Các dịch vụ cung cấp cho người dùng cần được mô tả trong mục này. Mô tả có thể dùng ngôn ngữ tự nhiên, sản phẩmư đồ hoặc có dạng ghi chép cho phép khách hàng có thể hiểu  được. Các dịch vụ cung cấp cho người dùng cần được mô tả trong mục này: Mô tả có thể dùng ngôn ngữ tự nhiên, sơ đồ hoặc các dạng ghi chép khác cho phép khách hàng có thể hiểu được.

+ Định nghĩa yêu cầu phi chức năng: các ràng buộc về Phần mềm  và các hạn chế đối với thiết kế cần phải được mô tả trong phần này. Nó có thể bao gồm các chi tiết của biểu diễn dữ liệu, thời gian đáp ứng và yêu cầu bộ nhớ….các tiêu chuẩn về sản phẩm và quy trình cần tuân thủ cũng được miêu tả.

+ Tiến triển hệ thống: phần này mô tả các giả thiết căn bản làm cơ sở cho hệ thống và dự đoán các thay đổi về phát triển phần cứng, yêu cầu của người dùng.

+ Đặc tả yêu cầu: mô tả các yêu cầu cơ bản chi tiết hơn. Nếu cần các chi tiết hơn có thể thêm vào các yêu cầu phi chức năng, ví dụ giao diện với các hệ thống có thể được định nghĩa.

+ Ngoài ra, tài liệu yêu cầu Phần mềm có thể bao gồm thêm các phần sau:

- Phần cứng: nếu hệ thống được phát triển trên một phần cứng đặc biệt, phần cứng này và giao diện cần được mô tả. Nếu phần cứng bán sẵn được sử dụng, các cấu hình cực tiểu và cực đại phải được mô tả.

- Yêu cầu dữ liệu: tổ chức lôgic của dữ liệu được sử dụng bởi hệ thống và các quan hệ giữa chúng được mô tả, có thể dùng sơ đồ thực thể liên kết.

- Chỉ mục có thể được cung cấp. Ví dụ mục theo chữ cái,chỉ mục theo chương, theo chức năng…

Do  hệ thống được vận hành trong thời gian dài, nên môi trường hệ thống và mục đích nghiệp vụ có thể thay đổi. Khi đó tài liệu yêu cầu cũng  cần phải thay đổi.Với mục đích tiến triển, tài liệu yêu cầu thường được chia theo hai phân loại:

+ Các yêu cầu ổn định: được suy dẫn từ các hoạt động cốt lõi  của tổ chức tương đối liên quan trực tiếp tới miền hệ thống.

+ Các yêu cầu bất thường: các yêu cầu có thể thay đổi khi phát triển hệ thống sau này như: các yêu cầu xuất hiện như là sự hiểu biết của khách hàng về sự phát triển của hệ thống trong quá trình xây dựng hệ thống, các yêu cầu được sinh ra do sự xuất hiện của việc tin học hoá làm thay đổi các quy trình nghiệp vụ…

Câu 9: Trình bầy các bước tiến trình phát hiện và phân tích yêu cầu? Trình bày các kỹ thuật để nhận biết và phân tích yêu cầu.

TL:

- Khảo sát, tìm hiểu yêu cầu

+ Xác định yêu cầu: đây là một khẳng định, bằng ngôn ngữ tự nhiên hơn là các sơ đồ, về các dịch vụ hệ thống cần cung cấp và các ràng buộc mà hệ thống phải tuân theo.

+ Đặc tả yêu cầu: là tài liệu được cấu trúc mô tả hệ thống các dịch vụ chi tiết hơn. Đôi khi tài liệu này được gọi là đặc tả chức năng. Đây có thể coi là hợp đồng ký kết giữa người mua và kẻ bán Phần mềm.

+ Đặc tả Phần mềm: là mô tả trừu tượng hơn của Phần mềm làm cơ sở cho thiết kế và triển khai

- Đánh giá các yêu cầu:

          Đánh giá các yêu cầu Phần mềm liên quan với việc cho biết các yêu cầu thực sự định nghĩa hệ thống đáp ứng đòi hỏi của khách hàng. Nếu việc đánh giá này không chính xác, các lỗi trong phần yêu cầu sẽ truyền tới thiết kế hệ thống và triển khai hệ thống. Chi phí sửa chữa lỗi sẽ rất lớn. Sự thay  đổi  về yêu cầu cần phải kiểm chứng:

+ Giá trị: người dùng có thể nghĩ rằng hệ thống cần một số chức năng, tuy nhiên sau mỗi số phân tích, có thể xác định các chức năng khác cần được đưa vào. Do hệ thống có nhiều loại người sử dụng nên có các yêu cầu khác nhau và không thể tránh khỏi sự thoả hiệp các nhu cầu đó.

+ Chắc chắn: mọi yêu cầu không được mâu thuẫn với các yêu cầu khác

+ Hoàn chỉnh: định nghĩa cần phải bao gồm mọi chức năng và các ràng buộc

+ Hiện thực: Không có các yêu cầu đặc biệt đến mức phi hiện thực. Có thể dự đoán trước các phát triển phần cứng, tuy nhiên phát triển Phần mềm thì khó dự đoán hơn.

+ Mẫu: là một mô hình chạy được của hệ thống được trình bày với người sử dụng. Đây là một kỹ thuật đánh giá yêu cầu hiệu quả. Nó cho phép người dùng thử nghiệm với hệ thống. Việc đánh giá lại yêu cầu không nên được coi là công việc tiếp theo của tư liệu hoá yêu cầu sau khi đã hoàn thành. Các xem xét về yêu cầu định kỳ liên quan với người dùng và kỹ sư Phần mềm luôn cần thiết.

- Phân tích các yêu cầu

          Nghiên cứu các yêu cầu của người sử dụng và của hệ thống Phần mềm để xây dựng các đặc tả về hệ thống là cần thiết, nó sẽ xác định hành vi của hệ thống. Nhiệm vụ của giai đoạn này là phải trả lời được các câu hỏi  sau:

          Đầu vào của hệ thống là gì?

          Những quá trình cần xử lý trong hệ thống, hay hệ thống Phần mềm sẽ phải xử lý những cái gì?

          Đầu ra: Kết quả xử lý của hệ thống là gì?

          Những ràng buộc trong hệ thống, chủ yếu là mối quan hệ giữa đầu vào và đầu ra như thế nào?

* Các kỹ thuật để nhận biết và phân tích yêu cầu:

- Phát hiện yêu cầu: tiếp xúc với các stakeholder ( người tham gia dự án) để phát hiện ra các yêu cầu của họ. Các yêu cầu miền ứng dụng cũng được phát hiện ở bước này.

- Phân loại và sắp xếp yêu cầu: nhóm các yêu cầu có liên quan lẫn nhau và tổ chức chúng thành những nhóm gắn kết với nhau.

- Sắp thứ tự ưu tiên và điều chỉnh các yêu cầu xung đột: đôi khi có nhiều stakeholder thì các yêu cầu của họ càng có nhiều xung đột. Hoạt động này nhằm đánh thứ tự ưu tiên của các yêu cầu, phát hiện và giải quyết xung đột giữa các yêu cầu.

- Tư liệu hoá yêu cầu: yêu cầu được tư liệu hóa và là đầu vào của vòng kế tiếp trong mô hình xoắn ốc.

Câu 10: Các kỹ thuật xác định phân tích yêu cầu.  Người ta thường sử dụng mô hình xoắn ốc trong quy trình phát hiện và phân tích yêu cầu.

TL:

            Hình: Quy trình phát hiện và phân tích yêu cầu

- Phát hiện yêu cầu: tiếp xúc với các khách hàng, người sử dụng hoặc các đối tác để phát hiện ra các yêu cầu của họ. Các yêu cầu miền ứng dụng cũng được phát hiện ở bước này. Sau khi phát hiện ra yêu cầu nhà sản xuất Phần mềm (cụ thể là kỹ sư khảo sát) phải viết lên tài liệu mô tả những yêu cầu và các chức năng của Phần mềm. Tài liệu đó mô tả trừu tượng các dịch vụ mà hệ thống được mong đợi phải cung cấp và các ràng buộc mà hệ thống phải tuân thủ khi vận hành. Nó chỉ có các đặc tả phẩm hạnh bên ngoài của hệ thống mà không liên quan đến các đặc tính thiêt kế. Nó phải được viết sao cho người ta có thể hiểu được mà không cần một kiến thức chuyên môn đặc biệt nào.

- Phân loại và sắp xếp yêu cầu: nhóm các yêu cầu có liên quan lẫn nhau và tổ chức chúng thành những nhóm gắn kết với nhau.

          Đây là giai đoạn nghiên cứu và phân tích lại những yêu cầu, từ đó đi đến việc nhóm chúng lại theo từng nhóm mà các yêu cầu trong nhóm đó có chức năng thực hiện công việc tương tự nhau hay các công việc có liên quan đến nhau.

- Sắp xếp thứ tự ưu tiên và điều chỉnh các yêu cầu xung đột: khi có nhiều người sử dụng thì các yêu cầu của họ càng có nhiều xung đột. Hoạt động này nhằm đánh thứ tự ưu tiên của các yêu cầu, phát hiện và giải quyết xung đột giữa các yêu cầu.

          Việc xây dựng một Phần mềm nhằm giải quyết một khối lượng công việc đồ xộ của nhiều người, nhiều bộ phận, thậm chí là nhiều công ty vì vậy không thể tránh được chồng chéo nhau hoặc  xung đột nhau. Vì vậy việc sắp xếp các thứ tự ưu tiên hay điều hoà các mối xung đột là một công đoạn rất cần thiết trong quá trình phát hiện và phân tích yêu cầu.

- Đặc tả yêu cầu:

          Khi đã xác định rõ bài toán thì bước tiếp theo là tìm kiếm xem hệ thống dự kiến sẽ yêu cầu làm cái gì. Điều quan trọng ở đây là phải xây dựng được danh sách các yêu cầu của người sử  dụng. Dựa trên những yêu cầu của người sử dụng, người phát triển đưa ra các đặc tả cho hệ thống.

          Người xây dựng hệ thống phải trả lời được các yêu cầu sau đây:

          Đầu ra của hệ thống là cái gì

          Hệ thống sẽ phải làm cái gì để có kết quả mong muốn, nghĩa là phải xử lý những cái gì

          Những tài nguyên mà hệ thống  yêu cầu là gì?

          Hiểu rõ nguồn gốc, các dạng thông tin  cần cung cấp cho hệ thống hoạt động. Hệ thống sẽ phải giải quyết những vấn đề gì, những kết qủa cần phải có là gì. Xác định được mối quan hệ giữa cái vào và cái ra cho quá trình hoạt động của hệ thống. Các đặc tả chi tiết phục vụ cho việc xây dựng và trắc nghiệm về hệ thống để kiểm tra xem những nhiệm vụ đã đặt ra có hoàn tất được hay không.

- Tư liệu hoá yêu cầu: yêu cầu được tư liệu hoá là đầu vào của vòng kế tiếp  trong mô hình xoắn ốc.

          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 thoả 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 đề.

Câu 11: Đặc tả yêu cầu Phần mềm là gì?

TL:

          - Đặc tả yêu cầu là đưa thêm các thông tin vào bản xác định yêu cầu. Đặc tả yêu cầu thường được dùng với các mô hình hệ thống, phát triển trong suốt quá trình phân tích yêu cầu. Đặc tả cùng và mô hình sẽ được mô tả trong hệ thống để thiết kế và thực hiện. Nó cũng bao gồm tất cả những  thông tin cần thiết mà hệ thống phải thực hiện.

          - Ngôn ngữ tự nhiện thường được dùng để đặc tả yêu cầu. Tuy nhiên, đặc tả bằng ngôn ngữ tự nhiên không phải là cơ sở tốt cho một thiết kế hoặc cho một hợp đồng giữa khách hàng và người phát triển hệ thống. Sau đây là một vài lý do:

          + Ngôn ngữ tự nhiên có thể hiểu được là dựa vào việc đọc bản đặc tả và khi viết sử dụng những từ giống nhau  cho những khái niệm giống nhau. Điều này rất khó hiểu bởi các từ trong ngôn ngữ tự nhiên đôi khi rất mơ hồ.

          + Một bản đặc tả yêu cầu bằng ngôn ngữ tự nhiên rất linh hoạt, bạn có thể nói về cùng một vấn đề bằng những cách khác nhau, nó làm cho những người đọc khó tìm ra những yêu cầu giống nhau, đó là lỗi nghiêng về phía tiến trình.

          + Các yêu cầu không được phân chia một cách có hiệu quả bằng ngôn ngữ đó, do đó khó tìm ra được các yêu cầu quan hệ. Để khám phá ra một sự thay đổi bạn phải xem xét tất cả các yêu cầu, chứ không chỉ trong nhóm các yêu cầu

quan hệ.

          - Bởi tất cả các lý do trên, đặc tả yêu cầu được viết bằng ngôn ngữ  tự nhiên có thể bị hiểu sai, điều này thường không được phát hiện cho đến giai đoạn thiết kế hoặc thực hiện các giai đoạn của tiến trình phần mềm. Vì vậy có một cách tốt hơn là dùng luân phiên các ký hiệu để đánh một vài vấn đề về không hạn chế được bằng ngôn ngữ tự nhiên, đó là đưa cấu trúc vào đặc tả. Sau đây là một số phương pháp:

          + Ngôn ngữ tự nhiên có cấu trúc: Cách tiếp cận này dựa trên việc định nghĩa các chuẩn mẫu hoặc các chuẩn tạm thời để xây dựng đặc tả yêu cầu.

          + Ngôn ngữ mô tả thiết kế: Cách tiếp cận nàydựa vào việc sử dụng các ngôn ngữ giống như ngôn ngữ lập trình nhưng có nhiều điểm trìu tượng hơn để phân loại yêu cầu bằng việc đưa ra một mô hình có thể thực hiện được của hệ thống.

          + Ngôn ng đặc tả yêu cầu: Một số ngôn ngữ được thiết kế cho những mục đích đặc biệt để xây dựng các yêu cầu Phần mềm. Ví dụ như: PSL/PSA (Tiechrow và Hershey, 1977) và RSL (Alford, 1977; Bell et at.1977; Alford, 1985). Những tiến bộ của cách tiếp cận này là việc cung cấp các công cụ cómục đích đặc biệt được phát triển.

          + Các ký hiệu đò hoạ: Hệ thống ký hiệu đồ hoạ tốt nhất có lẽ là SADT (Ross, 1977; Schoman và Ross, 1977). SADT có một bộ ký hiệu đồ hoạ quen thuộc, vì vậy chủ yếu được các nhà đầu tư sử dụng. Nó trở nên thân thiện trong việc sửdụng để phân tích và đặc tả các yêu cầu.

          + Đặc tả toán học: Dùng các kỹ thuật dựa trên các khái niệm toán học có cơ sở như: tập hợp, máy hỗn hợp trạng thái hoặc lưới để đặc tả yêu cầu.

          Ưu điểm: Loại bỏ hoàn toàn tính mơ hồ trong đặc tả.

          Nhược điểm: Khó khăn cho bên khách hàng bởi họ không hiểu được các ký hiệu toán học.

          Khác phục: Thêm những chú giải bằng ngôn ngữ thử nghiệm ở những chỗ thích hợp .

          Tính dò theo được: Khi viết ra các đặc tả yêu cầu, một điểm quan trọng là các yêu cầu có liên quan với nhau phải tham khảo chéo nhau được. Dò theo được là một thuộc tính của đặc tả yêu cầu phản ánh tính dễ tìm ra các yêu cầu có liên quan.

          Davis (1990) đã tóm tắt và so sánh một vài cách tiếp cận khác nhau để đặc tả yêu cầu. Trong hai cách tiếp cận đầu, chủ yếu là ngôn ngữ thử nghiệm có cấu trúc và ngôn ngữ mô tả thiết kế. Việc làm thích ứng các ngôn ngữ yêu cầu không được biết hay sử dụng rộng rãi. Các ký hiệu đồ hoạ tương tự như các ký hiệu được sử dụng để xây dựng các mô hình hệ thống.

          Khi viết đặc tả yêu cầu một điều rất quan trọng là các yêu cầu quan hệ phải phù hợp khi thay đổi các yêu cầu hoặc các yêu cầu khác được tìm thấy. Một vài mối quan hệ giữa các yêu cầu là rất tế nhi. Đó là lý do mà ta không thể vạch ra cụ thể các yêu cầu. Tuy nhiên, có một vài phương thức đơn giản có thể áp dụng cho việc xác định và đặc tả yêu cầu.

          + Tất cả các yêu cầu nên được phân chia.

          + Các yêu cầu cần phải xác định rõ quan hệ.

          + Mỗi tài liệu yêu cầu phải chứa một ma trận để chỉ ra các yêu cầu quan hệ.

Các ma trận khác nhau có thể được phát triển cho các loại quan hệ khác nhau.

Một lỹ thuật đơn giản là các công cụ CASE được sử dụng để cung cấp các phân tích và đặc tả yêu cầu. Một vài công cụ có các tiện ích đơn giản như tìm các yêu cầu sử dụng trong cùng thời kỳ, kết nối các tiện ích từ một yêu cầu đến một yêu cầu có quan hệ khác có thể được cung cấp.

Các yêu cầu được chia làm hai loại:

1. Các yêu cầu hệ thống chức năng: Các dịch vụ mà hệ thống phải cung cấp.

2. Các yêu cầu không chức năng: Các ràng buộc mà hệ thống phải tuân theo.

Về nguyên tắc, các yêu cầu của hệ thống  phải là vừa đầy đủ, vừa không gây ra mâu thuẫn. Thực tế đối với các hệ lớn và phức tạp thì thực khó đạt được tính đầy đủ và tính không mâu  thuẫn cho phiên bản đầu của tài liệu yêu cầu Phần mềm. Vấn đề là khi duyệt lại hoặc trong các pha sau này của vòng đời Phần mềm người ta phát hiện ra các sự không thoả mãn đó thì tài liệu  yêu cầu phải được chỉnh lý lại.

Xác định yêu cầu thường được viết bằng ngôn ngữ tự nhiên cộng thêm việc dùng các bảng, các biểu đồ để cho người dùng dễ hiểu (xem như người dùng không biết các khái niệm chuyên môn). Ngôn ngữ được dùng trong việc xác định yêu cầu thường là không chính xác và mơ hồ. Sự lầm lẫn giữa các biểu thị chi tiết đòi hỏi việcmô tả thông tin cần được biểu diễn ở nhiều mức chi tiết khác nhau.

Chú ý:

+ Vì việc xác định yêu cầu chưa hoàn hảo trước khi bắt đầu phát triển hệ thống tạo nên việc vận dụng mô hình quá trình dựa trên việc tạo mẫu hệ thống sẽ thích hợp hơn là mô hình thác nước.

+ Cần phân biệt giữa mục tiêu của hệ thống và yêu cầu của hệ thống: Yêu cầu là một cái gì đó có thể kiểm tra được. Mục tiêu lại là một đặc trưng khái quát hơn mà hệ thống phải thể hiện. Chẳng hạn mục tiêu của hệ thống có thể là thân thiện với người sử dụng. Nhưng sự thân thiện với người sử dụng lại không phải là một thuộc tính khách quan.

Tư liệu các yêu cầu Phần mềm

Heninger đòi hỏi 6 yêu cầu cho tư liệu các yêu cầu Phần mềm:

1.     Chỉ đặc tả phẩm hạnh bên ngoài của hệ thống

2.     Đặc tả các ràng buộc về sự thực hiện

3.     Phải là dễ thay đổi

4.     Phải được dùng làm công cụ tham khảo cho người bảo trì hệ thống

5.     Phải báo cáo dự tính trước về vòng đời của hệ thống

6.     Phải đặc trưng hoá các  đáp ứng chấp nhận được cho các sự kiện bất ngờ

Cấu trúc của một tư liệu yêu cầu

Cấu trúc của một tư liệu yêu cầu được gợi ý theo kết cấu sau:

1.     Phần dẫn nhập

2.     Phần mô hình hệ thống

3.     Phần tiến triển của hệ thống

4.     Phần các yêu cầu chức năng

5.     Phần tự điển thuật ngữ

 * Đặc tả yêu cầu

          Việc  xác định yêu cầu là việc đặc tả hướng khách hàng  và được viết bởi ngôn ngữ của khách hàng. Khi đó có thể dùng các khái niệm không chính xác, ngôn ngữ tự nhiên và các biểu đồ. Đặc tả yêu cầu (được gọi là đặc tả chức năng) là cơ sở cho hợp đồng làm hệ thống: nó phải không được mơ hồ, mà mơ hồ đó có thể dẫn tới sự hiểu lầm bởi khách hàng hoặc bởi người ký hợp đồng.

          Rất nhiều vần đề của kỹ nghệ Phần mềm là khó khăn đối với  đặc tả yêu cầu. Với một yêu cầu mơ hồ thì người phát triển sẽ thực hiện nó sao cho rẻ nhất. Trong khi đo khách hàng lại không muốn như vậy. Sau các cuộc đấu khẩu kéo dài thì các yêu cầu mới sẽ được thiết lập và có các đổi thay đổi với hệ thống. Dĩ nhiên việc đó làm trì hoãn ngày phân phát hệ thống và làm tăng chi phí.

          Chi phí do các sai sót trong việc phát biểu các yêu cầu có thể là rất cao, đặc biệt là nếu các sai này còn vẫn chưa được phát hiện trước khi hệ thống được thực hiện. Boehm báo cáo rằng trong một vài hệ thống lớn thì có đến 95% các mã đã phải viết lại để thoả mãn các yêu cầu của người dùng đã đổi thay và 12% các lỗi được phát hiện trong quá trình ba năm đầu sử dụng là các lỗi do đặc tả yêu cầu không đúng đắn.

          Chi phí do thay đổi một yêu cầu là đắt hơn nhiều so với chi phí sửa chữa thiết kế hoặc do lỗi mã.

Việc đặc tả bằng ngôn ngữ tự nhiên có những hạn chế sau:

1. Người đọc và người viết đặc tả bằng ngôn ngữ tự nhiên buộc phải hiểu mỗi từ theo  cùng một khái niệm. Điều đó là không thể được do sự mơ hồ là bản tính cố hữu của ngôn ngữ tự nhiên và cũng vì không có một từ điển thuật ngữ máy tính chuẩn mực.

2. Một đặc tả bằng ngôn ngữ tự nhiên là quá mềm dẻo: nó cho phép các yêu cầu liên quan được biểu thị trong các cách hoàn toàn khác nhau.

3. Các yêu cầu là không phân hoạch được một cách hữu hiệu: hiệu quả của việc thay đổi chỉ có thể được xác định bởi toàn bộ cac yêu cầu chứ không phải là một nhóm các yêu cầu liên quan.

Có người đề nghị rằng các ngôn ngữ đặc tả hình thức toán học nên được dùng để biểu thị các yêu cầu hệ thống. Nhưng đa số các khách hàng lại không hiểu đặc tả hình thức toán học. Hall (1990) đề xuất con đường để đi vòng qua khó khăn đó là viết thêm các chú giải dài dòng ngay bên cạnh cho người dùng dễ hiểu. Khi nào người dùng trở nên quen thuộc hơn với những ưu điểm của đặc tả hình thức và các kỹ sư phần mềm không còn miễn cưỡng dùng các phương pháp hình thức thì sẽ có nhiều các đặc tả yêu cầu sẽ dựa trên các mô hình hình thức của chức năng hệ thống.

          Các yêu cầu phi chức năng:

          Một yêu cầu phi chức năng của hệ thống là một hạn chế hoặc ràng buộc về các dịch vụ của hệ thống. Các yêu cầu đó có thể được đưa ra:

-       Vì nhu cầu của người dùng

-       Vì  hạn chế của kinh phí

-       Vì chính sách của tổ chức

-       Vì sự cần thiết tương tác giữa các phần cứng và phần mềm hoặc

-       Vì các nhân tố bên ngoài như các quy tắc an toàn, luật lệ bí mật riêng tư,...

Có 3 kiểu yêu cầu phi chức năng chính:

1. Các yêu cầu sản phẩm: đây là các yêu cầu về hệ thống được phát triển, chẳng hạn yêu cầu về tốc độ, về bộ nhớ, về độ tin cậy, về tính di chuyển được và về tính dùng lại được.

2.Các yêu cầu về quá trình: đây là các yêu cầu về quá trình phát triển, chẳng hạn như các chuẩn cần phải theo, các yêu cầu về sự thực hiện như là các ngôn ngữ lập trình, phương pháp thiết kế, yêu cầu về phân phát.

3. Các yêu cầu ngoại lai: tức là các yêu cầu không phải về sản phẩm cũng không phải về qúa trình phát triển: chẳng hạn như về giao tiếp với các hệ thống khác, về pháp lý, về chi phí, về nhóm những người phát triển và….

          Tuỳ theo các tổ chức cụ thể, đặc tả yêu cầu  có thể được thể hiện bằng cá c cách khác nhau kể từ mức phát biểu bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ cần cung cấp đến mức đặc tả hệ thống một cách hình thức kiểu toán học. Danh giới giữa các yêu cầu và đặc tả hình thức là một thứ rất tinh tê và các thuật ngữ này lại còn có thể được dùng theo nghĩa như nhau.

          Việc xác định đặc tả yêu cầu là khó khăn vì những lý do sau:

1. Các hệ Phần mềm lớn thường được yêu cầu cải thiện dựa trên nguyên trạng: hoặc không có hệ thống nào hoặc có một hệ thống không đầy đủ. Mặc dầu  có thể biết các khó khăn của hệ thống hiện có nhưng lại rất khó dự đoán được hiệu quả của hệ thống đã được cải thiện đối với tổ chức đó.

2. Các hệ thống lớn thường có một cộng đồng người sử dụng đa dạng, họ có những yêu cầu và ưu tiên khác nhau, thậm chí là mâu thuẫn với nhau. Cuối cùng thì các yêu cầu hệ thống cũng không thể tránh được sự thoả hiệp.

3. Những người bỏ tiền ra mua sắm hệ thống và những người sử dụng hệ thống hiếm khi lại là một. Những ngườimua sắm hệ thống đặt ra các yêu cầu theo những ràng buộc của tổ chức cơ quan và của ngân sác. Những cái đó lại thường mâu thuẫn với các yêu cầu thực sự của người dùng.

Câu 12: Thẩm định yêu cầu

          Một khi đã thiết lập các yêu cầu thì thẩm định xem chúng có thoả mãn các nhu cầu của người mua hệ thống hay không. Nếu việc thẩm định không phù hợp thì các sai lầm có thể lan truyền sang các giai đoạn thiết kế và thực hiện . Khi đó có thể cần đến các sự cải biên hệ thống tốn kém để làm cho nó đúng đắn.

          Có 4 bước liên quan đến việc thẩm định yêu cầu:

          1. Phải chỉ ra rằng các nhu cầu của người dùng là thoả mãn

          2. Các yêu cầu phải  không gây ra mâu thuẫn nhau

          3. Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà người dùng đã nhằm đến.

          4. Các yêu cầu phải hiện thực

Câu 13: Trình bày tiến trình làm bàn mẫu Phần mềm? Các KT được sử dụng để làm bản mẫu?

          Tiến trình làm bản mẫu Phần mềm gồm 4 bước:

1.     Thiết lập cho các mục tiêu của việc tạo bản mẫu.

2.     Chọn các chức năng cho việc tạo bản mẫu và quyết định những đặc tả

phi chức năng nào cần phải tạo bản mẫu.

3.      Phát triển bẩn mẫu

4.     Đánh giá bản mẫu

Đầu tiên phải làm rõ các mục tiêu của bản mẫu.Mục tiêu đó có thể là phát

triển hệ thống chỉ liêm quan đến tạo bản mẫu giao diện người sử dụng; cũng có thể là để thẩm định các yêu cầu hệ thống, để trình diễn tính khả thi của ứng dụn cho nhà quản lý xem xét… Nếu mục tiêu chưa rõ ràng thì người quản lý hoặc người sử dụng có thể hiểu nhầm chức năng khi thử bản mẫu và như vậy không thể đạt được kết quả mong muốn.

          Tiếp theo là quyết định xem cái gì được đưa vào và cái gì được lấy ra từ bản mẫu đó. Bởi vậy, có thể tạo bản mẫu với tất cả các chức năng của hệ thống nhưng ở mức thu gọn. Cũng có thể chỉ một số chức năng hệ thống được làm mẫu.

          Giai đoạn cuối cùng là đánh giá bản mẫu. Cần huấn luyện người sử dụng từ các mục tiêu của việc tạo mẫu và đưa ra một kế hoạch đánh giá. Phải có đủ thời gian cho người sử dụng làm quen với hệ thống và thiết lập một cách sử dụng mẫu chuẩn tắc, nhờ vậy mà phát hiện được các sai sót.

          Các kỹ thuật được sử dụng để chế tạo bản mẫu hệ thống là:

          + Sử dụng ngôn ngữ đặc tả thi hành được

          + Sử dụng ngôn  ngữ bậc rất cao

          + Sử dụng ngôn ngữ bậc cao hướng ứng dụng (ngôn ngữ thế hệ thứ tự)

          + Lắp ghép từ các thành phần dùng lại được

          Ngôn ngữ đặc tả thi hành được:  Ưu điểm của phương pháp này là giá của việc sản ra một đặc tả là không đáng kể. Nhưng nó lại khó hiểu với người dùng và đặc tả cần có kiến thức và kỹ năng tonà học. Và có 3 vấn đề đối với việc hpaast triển bản mẫu theo phương pháp này:

-       Không thể dùng kỹ thuật này để tạo bản mẫu cho giao diện đồ hoạ

-       Phát triển bản mẫu không đặc biệt thành

-       Hệ thi hành thường hoạt động chậm chạp và không hiệu quả

Các ngôn ngữ bậc rất cao:  Là các ngôn ngữ lập trình thừa kế các cấu trúc

dữ liệu và các đặc điểm bậc cao như khả năng quaylùi. Ví dụ: LISP, PROLOG, Smalltalk, APL, SETL. Chúng là các ngôn ngữ tạo bản mẫu có ích vì có thể phát triển hệ thống nhanh. Nhưng chúng không được dùng rộng rãi vì cần một hệ thống trợ giúp vận hành lớn.

          Các ngôn ngữ thế hệ thứ 4: Dựa trên việc sử dụng lại Phần mềm, ở đó các chương trình con được cung cấp để truy cấp một dữ liệu và để sản ra các báo cáo và người sử dụng chỉ cần mô tả làm thế nào để điều khiển các mô đun đó.

          Lắp ghép từ các thành phần dùng lại được: Người ta lắp rắp bản mẫu từ các thành phần có sẵn thành hệ thống có thể vận hành được.

Câu 14: Trình bày tổng quan về bước thiết kế Phần mềm? Các giai đoạn cần trải qua?

          Các bước thiết kế Phần mềm

          Trong quan điểm quản lý: Thiết kế Phần mềm được tiến hành 2 bước:

          + Thiết kế sơ bộ: Quan tâm đến việc dịch các yêu cầu thành các kiến trúc dữ liệu và Phần mềm.

          + Thiết kế chi tiết: Tập trung vào việc làm mịn biểu diễn kiến trúc để dẫn đến cấu trúc dữ liệu chi tiết và biểu diễn thuật toán cho Phần mềm.

          Đối với khía cạnh kỹ thuật, xuất hiện một số hoạt động thiết kế như:

          + Thiết kế kiến trúc

          + Thiết kế dữ liệu

          + Thiết kế giao diện

          + Thiết kế đối tượng

          + Thiết kế thủ tục

          Các giai đoạn thiết kế:

          Theo quan điểm quản lý, thiết kế chia thành giai đoạn thiết kế sơ bộ và thiét kế chi tiét. Thiết kế sơ bộ là thiết kế kiến trúc tổng thể. Giai đoạn tiếp theo trải qua hai giai đoạn:

          + Thiết kế logic: Xác định cấu trúc thiết kế logic mô tả các thành phần cảu hệ thống và các mối quan hệ giữa chúng mà không gắn với bất kỳ một phương diện vật lý nào.

          + Thiết kế vật lý: Chọn các giải pháp công nghệ hiện hữu để thực hiện các cấu trúc logic đãcho phù hợp với điều kiện của môi trường đích dự kién của hệ thống Phần mềm. Giai đoạn này đôi khi được gọi là thiết kế chi tiết và đôi khi là lập trình.

Câu 15: Phân biệt về góc nhìn về thiết kế Phần mềm? Các giai đoạn cần trải qua?

          1. Các góc nhìn về thiết kế Phần mềm.

          Tuy có nhiều phương pháp thiết kế khác nhau nhưng chúng ta có nhiều điểm chung và thường được trợ giúp từ một số cách nhìn nhận sau:

          Cách nhìn cấu trúc: Cho cái nhìn tổng thể thông qua lược đồ cấu trúc hệ thống. Hệ thống  gồm các thànhphần và mối quan hệ giữa chúng.

          Cách nhìn quan hệ thực thể: Mô tả các cấu trúc dữ liệu logic được dùng, nó liên qua đến đặc tả dữ liệu nhờ mô hình thực thể và quan hệ của chúg.

          Cách nhìn luồng dữ liệu: Lược đồ luồng dữ liệu thể hiện quá trình vận động của dữ liệu và sự biến đổi của nó xảy ra ở mỗi chức năng mà nó được xử lý.

          Cách nhìn vận động: Lược đồ chuyển trạng thái để bổ sung cho các phương pháp trên để nhìn một hệ thống diễn ra theo thời gian thực.

          Như vậy, mỗi phương pháp thiết kế Phần mềm đều đượ vào những cách nhìn nhận trực cảm và bộ ký pháp duy nhất để thể hiện cũng như một cách nhìn riêng nào đó về những đặc trưng cho chất lượng thiết kế. Tuy vậy, các phương pháp thiết kế cũng thường có những đặc trừng chung như sau.

          Một cơ chế chuyển hoá từ biểu diễn miền thông tin (của đặc tả) thành biểu diễn miền thiết kế.

          Các ký pháp để biểu diễn thành phần chức năng và giao diện của chúng.

          Cách trực cảm pjhân hoạch và làm mịn vấn đề.

          Có thể nhìn nhận tiến trình thiết kế Phần mềm theo những cách nhìn khác nhau: theo người quản lý, theo nhà phát triển, theo mức độ hình thức hoá.

Phân biệt:

2. Các giai đoạn trải qua.

Theo quan điểm quản lý,thiết kế chia thành giai đoạn thiết kế sơ bộ và thiết kế chi tiết. Thiết kế sơ bộ là thiết kế kiến trú tổng thể . Giai đoạn tiếp theo là thiết kế chi tiết trải qua hai giai đoạn:

+ Thiết kế logic: Xác định cấu trúc thiết kế logic mô tả các thành phần cảu hệ thống và các mối quan hệ giữa chúng mà không gắn với bất kỳ một phương diện vật lý nào. Nhờ loại bỏ các yếu tố vật lý, nhà thiết kế có thể vận dụng các nguyên tắc thiết kế và sự sáng tạo củam ình để “ vẽ” lên một hệ thống Phần mềm “lý tưởng” đáp ứng được các yêu cầu đề ra.

+ Thiết kế vật lý: Chọn các giải pháp công nghệ hiện hữu để thực hiện các cấu trúc logic đãcho phù hợp với điều kiện của môi trường đích dự kién của hệ thống Phần mềm. Giai đoạn này đôi khi được gọi là thiết kế chi tiết, đôi khi được là lập trình.  Lúc này đòi hỏi nhà thiết kế phải có khả năng lựa chọn các giải pháp kỹ thuật và các phương tiện thích hợp trong điều kiện hiện hữu để thực hiện các chức năng của hệ thống nhằm đáp ứng tốt nhất yêu cầu người dùng.

Câu 16: Trình bày các bước thiết kế: Kiến trúc, giao diện, dữ liệu

TL:

1. Các bước thiết kế kiến trúc

          Một hệ thống lớn luôn có thể phân rã thành cac hệ con độc lập tương đối với nhau. Tiến trình xác định các hệ thống con của một hệ thống và thiết lập một khung làm việc co việc điều khiển và giao tiếp giữa chúng gọi là thiết kế kiến trúc. Kết quả của hoạt động này là một tài liệu thiết kế kiến trúc, nó mô tả một kiến trúc Phần mềm. Thiết kế kiến trúc chủ yếu tập trung vào việc biểu diễn cấu trúc các thành phần Phần mềm, các thuộc tính của nó và tương tác giữa chúng. Các nhà thiết kế khác nhau có thể tiếp cận tiến trình thiết kế kiến trúc theo cách khác nhau. Tuy nhiên, những hoạt động sau đây là chung cho mọi tiến trình.:

a)     Cấu trúc hệ thống: một hệ thống được cấu trúc thành một số hệ thống con.

b)    Mô hình hoá điều khiển: thiết lập mô hình chung mô tả mối quan hệ điều khiển giữa các thành phần trong  hệ thống

c)     Phân rã các modul: mỗi hệ thống con  được phân rã thành các modul. Kiến trúc này cần chỉ ra các loại modul và liên kết giữa chúng.

Thiết kế kiến trúc có thể dựa trên một hoặc một số mô hình kiến trúc cụ thể như đã trình bày ở trên. Để sử dụng chúng, việc nhận biết được các mô hình, những mặt mạnh, những mặt yếu của chúng là rất quan trọng. Trên thực tế các hệ thống lớn không phù hợp với mô hình kiến trúc đơn. Các thành phần của nó có thể được thiết kế từ các mô hình kiến trúc khác nhau.

2. Thiết kế dữ liệu

a. Thíêt kế dữ liệu logic: Đầu vào của thiết kế dữ liệu logic là mô hình thực thể mối quan hệ. Tiến trình thiết kế dữ liệu logic được mô tả ở hình:

b. Thiết kế cơ sở dữ liệu vật lý: Trên cơ sở mô hình quan hệ nhận được, lựa chọn hệ quản trị CSDL, tiến hành phi chuẩn hoá để được số các quan hệ ít nhất nhưng vẫn đủ thông tin và có cấu trúc tốt (ít nhất chuẩn 3). Tiếp theo cần chọn hệ quản trị cơ sở dữ liệu và các thiết kế tệp, trong đó các tệp chính (master file) nhận được từ các quan hệ đã phi chuẩn hoá. Sau khi phi chuẩn hoá các quan hệ trên ta được các quan hệ chính.

3. Tiến trình thiết kế giao diện.

Tiến trình thiết kế bao gồm một số hoạt động:

- Bắt đầu với việc tạo ra các mô hình khác nhau về chức năng hệ thống.

- Phác hoạ ra các nhiệm vụ hướng con người và máy tính để đạt tới chức năng hệ thống (tiến trình tương tác).

- Xem xét các giải pháp thiết kế được áp dụng cho mọi thiết kế giao diện

- Sử dụng các công cụ làm bản mẫu

- Cài đặt cho mô hình thiết kế và đánh giá kết quả về chất lượng.

* Các nguyên tắc thiết kế giao diện

+ Tính quen thuộc với người sử dụng: giao diện nên sử dụng các thuật ngữ và các khái niệm gần gũi được rút ra từ kinh nghiệm của những người sử dụng nhiều các hệ thống.

+ Tính nhất quán: giao diện nên nhất quán ở chỗ những so sánh nên được kích hoạt theo cùng một cách.

+ Làm ngạc nhiên nhỏ nhất: Các hoạt động của hệ thống không nên làm cho người sử dụng phải ngạc nhiên.

+ Có khả năng phục hồi: giao diện nên có các cơ chế cho phép người dùng phục hồi lại trạng thái trước đó mỗi khi gặp lỗi.

+ Hướng dẫn người sử dụng: giao diện cần cung cấp các thông tin phản hồi có ý nghĩa và cung cấp các tiện ích trợ giúp người sử dụng theo những từn ngữ cảnh nhạy cảm.

+ Đa dạng người dùng: giao diện cần cung cấp các tiện ích tương tác tích hợp với nhiều loại người dùng khác nhau.

Câu 17: Phương pháp thiết kế Phần mềm: Hướng cấu trúc, hướng đối tượng?

TL:

Gần đây người ta thường sử dụng các chiến lược thiết kế dựa trên việc phân tích bản thiết kế thành các thành phần chức năng với hệ thống thông tin quản lý trong 1 vùng dữ liệu được chia sẻ. Although Parnas (1972) đã gợi ý 1 chiến lược xen lẫn vào  đầu những năm 70 và chỉ đến  cuối năm 80 chiến lược thiết kế hướng đối tượng mới được chấp nhận.

1. Thiết kế chức năng: hệ thống được thiết kế từ quan điểm hướng chức năng bắt đầu ở tầm nhìn mức cao sau đó được cải tiến dần thành bản thiết kế chi tiết hơn. Cách thức hệ thống được tập trung hay bị chia sẻ giữa các thao tác trong cách thức đó. Chiến lược này được minh hoạ bởi bản thiết kế cấu trúc (của Constantune và Jourdon, 1979) SSADM (Cutts, 1988; Werver, 1993)… các phương thức như Jackson Structured Programming (Jackson, 1975) và Warnier-on methord (Warnier, 1977) là các công nghệ phân tích chức năng, các cấu trúc dữ liệu được sử dụng để quyết định cấu trúc chức năng được sử dụng để  xử lý dữ liệu.

2. Thiết kế hướng đối tượng: hệ thống được coi như tập hợp các đối tượng, là chức năng. Thiết kế hướng đối tượng dựa trên ý kiến về che dấu thông tin Parnas, 1972)và được mô tả bởi Muyer (1988), Booch (1994), Jacobsen et at (1993) và nhiều người khác. ISD (Jackson, 1983) là một phương thức thiết kế kết hợp giữa thiết kế hướng chức năng và thiết kế hướng đối tượng.

Trong 1 bản thiết kế hướng đối tượng cách thức của hệ thống là phân quyền và mỗi đối tượng điều khiển trạng thái thông tin của chính nó. Các đối tượng có 1 tập thuộc tính để xác định cách thức và các thao tác của hoạt động dựa trên các đặc tính đó. Các đối tượng thường là thành viên của 1 lớp đối tượng có chung các thuộc tính và thao tác. Những điều này có thể được kế thừa từ một hoặc nhiều lớp vì vậy một định nghĩa lớp chỉ cần nêu ra sự khác giữa các lớp. Theo quan niệm, các đối tượng truyền các thông điệp trao đổi. Trên thực tế, hầu hết các đối tượng truyền thông được hoàn thành do 1 đối tượng gọi là 1 thủ tục kết giao với đối tượng khác. Hình vẽ trên đã minh hoạ điều này.

Để minh hoạ cho sự khác nhau giữa cách tiếp cận hướng chức năng và hướng đối tượng trong thiết kế Phần mềm, ta hãy xem cấu trúc của 1 bộ dịch. Nó có thể coi như 1 tập hợp  các truyền thông chung với các thông tin kết nối từ 1 đơn vị xử lý tới đơn vị khác.

Các thành phần chủ yếu trong khung cảnh chức năng được xem như các hoạt động: “Scan”, “Build”, “Analyse”, “Generate”,… một sự xen kẽ các hình ảnh hướng đối tượng của hệ thống được chỉ ra trong hình vẽ sau:

Các đối tượng được kết nối bởi bộ dịc. Là trung tâm của các thao tác được kết giao với mỗi đối tượng. Trong trường hợp này, các thành phần chính được định nghĩa như là các thực thể: “Token Stream”, “Syntax Tree”…

Những người quan tâm đến kỹ thuật thiết kế đôi khi cho rằng kỹ thuật mà họ yêu thích có thể áp dụng cho tất cả các ứng dụng. Điều đó là nguy hiểm bởi họ đã quá đơn giản hoá các vấn đề trong thiết kế. Qua kinh nghiệm, sự thất vọng của những người sử dụng trong công nghệ riêng lẻ có thể bác bỏ tính hoàn thiện mặc dù nó được áp dụng tốt trong 1 vài lĩnh vực ứng dụng.

Nó không phải là 1 chiến lược thiết kế tốt nhất mà nó phù hợp cho tất cả các dự án và cho tất cả các loại ứng dụng, các cách tiếp cận hướng đối tượng và hướng chức năng thường bổ sung cho nhau chứ không đối lập nhau. Trên thực tế các kỹ sư  phần mềm chọn cách tiếp cận thích hợp nhất cho mỗi bước trong tiến trình thiết kế, các hệ thống phần mềm lớn rất phức tạp nên cần phải sử dụng các cách tiếp cận khác nhau trong thiết kế cho từng phần của hệ thống.

Để minh hoạ cho điều này ta lấy ví dụ hệ thống Phần mềm là 1 phần của máy bay dân sự hiện đại. Đứng ở mức độ tổng quát chúng ta xem xét Phần mềm này như  là 1 tập các hệ thống con hoặc các đối tượng. Chúng ta sử dụng các kỹ nghệ khác nhau sao cho phù hợp. Chúng ta nói đó là “The Navigation System”, “The Engine Control System”….tại mức thiết kế trừu tượng này, cách tiếp cận hướng đối tượng là xu thế tự nhiên, khi hệ thống được giám sát chi tiết hơn, sự mô tả tự nhiên của nó được coi như 1 bộ các chức năng tích hợp hơn là các đối tượng. Một vài chức năng có thể là:

Hiển thị dấu vết (Radar Sub-System)

Đối trọng tốc độ gió (Navigation Sub-System)

Giảm năng lượng (sức mạnh – Power) (Engine Control Sub-System)

Dấu hiệu hỏng máy móc (Instrument Sub-System)

Lock- Onta Frequency (Communication Sub-System)

Hình ảnh các chức năng này bắt nguốn từ quá trình xác định yêu cầu. Điều này có thể được chuyển đổi sang 1 bản thiết kế hướng đối tượng. Tuy nhiên khi đó tính hiện thực của hệ thống không cao bởi không có 1 sự phù hợp giữa các thành phần thiết kế và định nghĩa yêu cầu. Một chức năng logic đơn giản trong định nghĩa yêu cầu  có thể thực hiện như 1 thứ tự tích hợp đối tượng.

Khi thiết kế hệ thống, điều quan trọng là phải phân tích, một hình ảnh hướng  đối tượng lại có thể biểu thị 1 cách tự nhiên. Tại bước thiết kế chi tiết, các đối tượng được kết nối có thể là: trạng thái máy móc (The engine Status); vị trí máy bay (The Aircraft-Position), đồng hồ đo độ cao (The – Artimetar), sóng báo hiệu (The Radio Beacen)…theo cách này, một phương thức tiếp cận hướng đối tượng  được áp dụng để giảm các mức trong thiết kế hệ thống là có hiệu quả.

Tóm lại cách tiếp cận hướng đối tượng để thiết kế Phần mềm  dường như là tự nhiên trong thiết kế hệ thống ở mức cao nhất và thấp nhất. Trên thực tế, tất nhiên sử dụng các cách tiếp cận khác nhau để thiết kế có thể đòi hỏi người thiết kế chuyển đổi bản thiết kế của họ từ 1 mô hình này sang mô hình khác. Nhiều người thiết kế không kết hợp các cách tiếp cận mà thích sử dụng thiết kế hướng đối tượng hoặc hướng chức năng.

Câu 18: Ví dụ về Máy rút tiền tự động (Automated Teller Machine)

Yêu cầu: Xây dựng Phần mềm hỗ trợ mạng lưới gửi/ rút tiền của ngân hàng (Banking Network) gồm nhân viên thu ngân (Cashier) và các máy rút tiền tự động (ATM) được dùng chung bởi 1 liên hiệp (Consortium) của các nhà băng (Bank). Mỗi nhà băng có các máy tính (Bank Computer) riêng để lưu trữ các tài khoản (Account) của mình và để thực hiện các giao dịch (Transaction) trên các tài khoản đó. Mỗi trạm gửi/rút tiền (Cashier Station) thuộc sở hữu của 1 nhà băng và có thể liên lạc trực tiếp với các máy tính của nhà băng đó. Các nhân viên thu ngân nhập dữ liệu về tài khoản (Account Data) và các giao dịch. ATM liên lạc với máy tính trung tâm (Central Computer) để thực hiện giao dịch với nhà băng thích hợp. Một ATM nhận 1 thẻ rút tiền (Cash_Card), tương tác với người dùng. Liên lạc với hệ thống trung tâm để thực hiện giao dịch, trả tiền. Hệ thống (System) đòi hỏi lưu trữ dự phòng (Recordkeeping Provision) và bảo mật dự phòng (Security Provision). Hệ thống phải xử lý các truy cập đồng thời vào cùng 1 tài khoản 1 cách đúng đắn. Các nhà băng tự cung cấp Phần mềm cho máy tính của họ. Bạn cần thiết kế Phần mềm cho các ATM và mạng. Chi phí (Cost) của hệ thống dùng chung sẽ được chia giữa các nhà băng theo số khách hàng (Customer) sử dụng thẻ rút tiền tại ATM.

Mô hình đối tượng

Bước 1: Xác định các đối tượng

          Bước đầu tiền khi xây dựng mô hình đối tượng là việc xác định các lớp đối tượng có liên quan. Các đối tượng có thể là các đối tượng vật lý (nhà, nhân viên, máy,…) hoặc các khái niệm chẳng hạn các các xếp chỗ trên máy bay, lịch trả nợ…

          Một đối tượng đều phải có ý nghĩa đối với bài toán cần mô hình; tránh các cấu trúc cài đặt thí dụ danh sách liên kết, chương trình con… không phải mọi đối tượng đều được nêu trực tiếp trong phát biểu cảu bài toàn, một số được ẩn trong miền ứng dụng và tri thức cơ bản.

          Không nên lo lắng quá mức về các lớp ở mức trừu tượng cao và các quan hệ thừa kế, trước hết hãy chỉ ra các lớp cụ thể một cách đúng đắn. Ví dụ, nếu bạn mô hình hệ thống cho mượn tài liệu ở thư viện, trước hết chỉ các loại tài liệu khác nhau chẳng hạn sách, tạp chí, băng Video, báo… sau đó mới quan tâm đến những đặc điểm chung và các đặc điểm riêng để nhóm thành các loại rộng hơn.

          Ví dụ ATM: Xem xét các danh từ trong phát biểu của bài toán ATM trong hình 8.3 cho ra các lớp dự kiến trong hình 8.5. Hình 8.6: Các lớp được đưa thêm. Các lớp này không có mặt trực tiếp trong phát biểu bài toán nhưng có thể được chỉ ra từ kiến thức của ta về Domain của bài toán.

Bước 2: Giữ lại các lớp thích hợp

          Bây giờ, loại bỏ các lớp sai và không cần thiết (Xem hình 8.7 về ví dụ ATM) dựa theo các tiêu chí sau:

          Các lớp thừa:

          Nếu hai lớp biểu diễn cùng một thông tin, lớp nào có tính mô tả cao hơn thì giữ lại. Ví dụ ATM: Customer và User: bỏ User vì Customer mô tả tốt hơn.

          Các lớp không liên quan.

          Nếu một lớp không có liên quan hoặc có liên quan rất ít đến bài toán, cần loại bỏ lớp đó. Ví dụ, việc phân chia chi phí (Cost) nằm ngoài phạm vi của Phần mềm giao dịch ATM nên loại bỏ lớp Cost.

          Các lớp mập mờ

          Mỗi lớp đều phải cụ thể. Một số lớp dự tính có thể có ranh giới không được xác định rõ ràng hoặc nằm trong phạm vi quá lớn. Ví dụ Recordkeeping Provision là mù mờ. Trong bài toán ATM, nó là một phần của Transaction.

          Là thuộc tính.

          Những các tên mô tả các đối tượng cụ thể nên được coi là các thuộc tính. Ví dụ tên, tuổi, địa chỉ… thường là thuộc tính. Account data chưa được xác định rõ ràng, nhưng trong trường hợp này nó cũng mô tả một tài khoản cụ thể . Một ATM cho rút tiền và in ra hoá đơn. Ngoài ra, tiền và hoá đơn không gây thêm ảnh hưởng gì cho hệ thống. Do đó, Cash và Receipt nên được coi là thuộc tính.

          Là thao tác

          Nếu một cái tên mô tả một thao tác áp dụng cho các lớp khác không trên danh nghĩa của chính nó, thì đó không phải là một lớp. Ví dụ, một cú gọi điện thoại, nếu ta mô hình máy điện thoại, Telephone Call là một chuỗi hành động liên quan đến máy gọi và mạng điện thoại. Khi đó, Call chỉ là một phần trong mô hình động, không phải là một đối tượng.

          Tuy nhiên, một thao tác có các đặc tính riêng của chính nó cần được coi là một lớp. Ví dụ, trong Phần mềm tích cước điện thoại, Call sẽ là một lớp đối tượng quan trọng với các thuộc tính như ngày giờ, nơi gọi đến, thời gian gọi…

          Là vai trò

          Tên của lớp phải phản ánh bản chất của lớp đó, không phải vai trò của nó trong một quan hệ nào đó. Ví dụ trong chương trình quản lý cho thuê ôtô, chủ – xe là một tên lớp tồi, nếu xét đến chuyện một người chủ xe có thể lái xe và thuê xe. Tên lớp hợp lý là người (hoặc có thể là khách_hàng). Các đối tượng thuộc lớp này có thể giữ nhiều vai trò chẳng hạnchủ xe, người thuê xe, lái xe.

          Là các cấu trúc cài đặt

          Các cấu trúc xa lại với thế giớ thực cần được loại bỏ ra mô hình phân tích. Chúng có thể được dùng đến trong giai đoạn thiết kế nhưng không phải trong giai đoạn này. Ví dụ CPU, thủ tục, tiến trình, thuật toán… là các cấu trúc cài đặt cho phần lớn ứng dụng, cho dù chúng là các lớp hợp lý cho mô hình hệ điều hành. Các cấu trúc dữ liệu như danh sách, cây, mảng, bảng… hầu như luôn luôn là cấu trúc cài đặt.

          Một số lớp dự tính của ATM cũng là cấu trúc cài đặt. Transaction log chỉ đơn giản là một tập các giao dịch; biểu diễn chính xác của nó là một việc thuộc phần thiết kế. Các kết nối liên lạc (Communication Link) có thể được coi là các quan hệ. Communication Line chỉ đơn giản là cài đặt vật lý của một kết nối liên lạc đó.

Bứơc 3: Tạo từ điển dữ liệu

          Chú trọng vào mô tả, giải nghĩa tên lớp, các thuộc tính, phương thức có thể bỏ qua ở giai đoạn này.

Bước 4: Xác đinh các quan hệ liên hiệp (Association)

          Mỗi sự phụ thuộc giữa hai lớp trở lên là một quan hệ liên hợp.

Một Reference từ một lớp đến một lớp khác: Đó là một quan hệ liên hợp

Ví dụ, không nên có thuộc tính Employer trong lớp Person. Hãy liên kết lớp Person với lớp Company bằng quan hệ Works – For.

Các quan hệ liên hợp có thể được cài đặt bằng nhiều cách, các quyết định đo không được có mặt trong mô hình phân tích để bảo vệ sự do cho pha thiết kế.

Các quan hệ liên hợp thường ứng với một động từ hoặc một ngữ động từ. Gồm có các kiểu:

          + Vị trí vật lý (Next to, Part of, Contained in…)

          + Hành động định hướng (Drives…)

          + Liên lạc (Talks to)

          + Sở hữu (Has, Part of…

          + Hoặc, thoả mãn điều kiện (Works for, Married to, Manages)

Liệt kê ra giấy mọi quan hệ có thể tách ra từ phát biểu bài toán. Xem ví dụ hình 8.9. Phần lớn được lấy trực tiếp từ các ngữ động từ trong phát biểu bài toán. Một số khác được dựa vào kiến thức về thực tế ứng dụng và giả thiết – những quan hệ này cần được kiểm tra lại bởi người đặt hàng.

Đừng dùng nhiều thời gian để phân biệt giữa quan hệ bao gồm và quan hệ liên hợp. Quan hệ bao gồm thực ra chỉ là một quan hệ liên hợp với nghĩa mở rộng.

Bước 5: Giữ lại các quan hệ đúng đắn

          Loại bỏ các quan hệ không cần thiết và không đúng đắn theo các tiêu chí sau:

          Quan hệ giữa các lớp đã bị loại bỏ (ở bước 2)

          Các quan hệ không liên quan và các quan hệ thuộc về cài đặtư

          Thí dụ “Hệ thống xử lý các truy nhập đồng thời” là quan hệ thuộc về cài đặt.

          Hành động

          Một quan hệ phải mô tả một đặc điểm về mặt cấu trúc của Domain cả ứng dụng chứ không mô tả một sự kiện nhất thời. Thí dụ “ATM nhận thẻ rút tiền” mô tả một phần của chu kỳ tương tác giữa ATM và một khách hàng, đó không phải là một quan hệ lâu dài giữa các ATM và các thẻ rút tiền. Ta cũng có thể loại bỏ “ATM tương tác với người dùng”.

          Đôi khi, một yêu cầu mô tả dưới dạng một hành động lại gợi ý về một quan hệ về cấu trúc được ẩn trong đó. Ví dụ, “Máy tính trung tâm thực hiện giao dịch với nhà băng” mô tả một hành động gợi ý quan hệ cấu trúc “Máy tính trung tâm kliên lạc với nhà băng”.

          Các quan hệ tam phân

          Phần lớn các quan hệ giữa từ 3 lớp trở lên có thể được phân rã thành các quan hệ đôi hoặc một quan hệ liên hợp được qualified. Ví dụ, “Nhân viên giao dịch của một tài khoản” có thể được tách thành “Nhân viên nhạp giao dịch” và “Giao dịch liên quan đến tài khoản”.

          Nếu một trong các lớp có liên quan trong quan hệ chỉ là mô tả thuần tuý không có các thuộc tính hoặc thao tác của riêng nó thì có thể chuyển lớp đó thành một thuộc tính của liên kết trong một quan hệ liên hợp đôi. Quan hệ “Công ty trả lương cho nhân viên” có thể được chuyển thành một quan hệ đôi “Công ty thuê nhân viên” với một giá trị lương cho mỗi liên kết Công ty – nhân viên.

          Một số quan hệ tam phân là không thể tránh được. “Thầy giáo dạy một môn học cho một lớp” không thể phân rã mà không bị mất thông tin.

          Các quan hệ dân xuất

          Loại bỏ các quan hệ xác định theo ác quan hệ khác. Ví dụ, loại bỏ Grandparent of vì nó có thể được xác định bởi 2 quan hệ Parent of. Loại bỏ young than vì nó mô tả điều kiện giữa ngày sinh của hai người, không thêm được thông tin mới.

          Lưu ý, quan hệ “Máy tính thuộc quyền sử dụng của người” không được dânxuaats từ “người làm thuê cho Công ty” và “Công ty có máy tính”

          + Chỉ rõ ngữ nghĩa của các quan hệ sau

          + Đạt lại tên của các quan hệ cho hợp lý

          + Xác đinh lực lượng cho các vai trò

          + Thêm các quan hệ còn thiếu

          Ví dụ ATM, xem hình 8.11

          Lớp Transaction đã được tách thành hai lớp Remote transaction và cashier transaction để đáp ứng với các quan hệ khác nhau giữa hai loại. Môt số quyết định phân tíchcó thể được làm thành theo cách khác. Điều đó là bình thường, có nhiều mô hình đúng cho cho một bài toán.

Bước 6: Xác định các thuộc tính

          Các thuộc tính là các đặc điểm của từng đối cụ thể, chẳng hạn tên, khối lượng, vận tốc… Không dùng đối tượng làm thuộc tính; thay vào đó, hãydùng quan hệ liên hợp để mô tả mối quan hệ giữa hai đối tượng.

          Các thuộc tính dẫn xuất nên bị loại bỏ hoặc được chú thích rõ. Thí dụ, tuổi có thể tính được từ ngày sinh và thời gin hiện tại.

          Các thuộc tính của các liên kêt cũng cần được chỉ rõ

Bước 7: Giữ các thuộc tính đúng đắn

          Loại bỏ các thuộc tính không liên quan và không hợp lý (tự đọc 8.4.7 Rumbaugh)

          Chú ý các trường hợp sau:

          Các thuộc tính nên chuyển thành đối tượng

          Thuộc tính liên kết (Link attributes): Chuyển các thuộc tính chỉ phụ thuộc liên kết thành các thuộc tính liên kết các gía trị nội bộ (các đối tượng khác không nhìn thấy được) -> không đưa vào mô hình.

          Lưu ý: Bài toán ATM chỉ là một ví dụ, không phải là một ứng dụng đầy đủ. Trong ứngdụng thực, số thuộc tính của mỗi lớp thường lớn hơn rất nhiều so với trong ví dụ.

Bước 8: Làm mịn mô hình bằng quan hệ thừa kế

          Sử dụng thừa kế, tổ chức các lớp để chia sẻ cấu trúc. Thừa kế có thẻ được sử dụng theo hai hướng: Tổng quát hoá các khía cạnh chung của các lớp đã có thàn một siêu – lớp (từ dưới lên), hoặc làm min các lớp có sẵn thành các lớp con chuyên biệt hơn (từ trên xuống).

          Ví dụ, Remote trasaction (giao dịch từ xa qua ATM) và Cashier transaction (giao dịch tại quầy) tương tự nhua trừ nơi bắt nguồn của giao dịch, do vậy có thể được tonge quát hoá bằng Trasaction. Mặt khác, Central computer (máy tính trung tâm) và Bank computer ( Máy tính ngân hàng) có ít điểm chung nếu xét mục đích của ví dụ ATM. Một số thuộc tính hoặc lớp có thể phải được định nghĩa lại để phù hợp với cấu trúc tổng quát. Điều này là chấp nhận được. Nhưng dừng cố gắng quá nếu nó không phù hợp, vì bạn có thể đã tổng quát sai.

          Việc chuyên biệt hoá (từ trên xuống) thường dễ thấy trong phạm vi của bài toán. Ví dụ menu gồm nhiều loại: pop-up menu, fixed menu, sliding menu… tránh phân quá mịn. Cần xem xét xem việc chuyên biệt đó có ý nghĩa với bài toán cần giải quyết hay không. Ví dụ. Có nhiều loại tài khoản nhà băng, việc chuyên biệt hoá thành các lớp tài khoản riêng có thể có ý nghĩa cho các bài toán khác, nhưng trong ví dụ ATM, loại tài khoản, nếu cần chỉ là một thuộc tính của lớp Account.

          Có thể sử dụng đa thừa kế nhưng chỉ những khi thật cần thiết vì nó sẽ làm tăng độ phức tạp về khái niệm và cài đặt.

Bước 9: Kiểm tra các đường truy nhập

          Lần bước các đường truy nhập qua mô hình đối tượng để xem đường đó có cho ra kết quả hợp lý hay không?

          Khi một kết quả duy nhất được yêu cầu, đường truy nhập đó có cho ra kết quả duy nhất hay không?

          Với các lực lượng >1, có cách nào để lấy ra các giá trị duy nhất khi cần hay không?

          Nghĩ xem ta có thể đặt ra câu hỏi gì cho chương trình. Câu hỏi có ích mà không trả lời được? Nếu có, đó là dấu hiệu của thông tin còn thiếu.

          Nếu có gì có vẻ đơn giản trong thực tế nhưng trong mô hình lại rất phức tạp, bạn có thể đã hiểu, bạn có thể đã thiếu hoặc làm sai cái gì đó.

          Kiểm tra từng yêu cầu xem đã được thể hiện trong mô hình hay chưa?

Câu 19: Nêu mục đích và tầm quan trọng của xác minh và thẩm định, phân biệt chúng?

Thẩm định yêu cầu: Một khi đã thiết lập các yêu cầu thì phải thẩm định xem chúng có thoả mãn các nhu cầu của người mua hệ thống hay không. Nếu việc thẩm định không phù hợp thì các sai lầm có thể lan truyền sang các giai đoạn thiết kế và thực hiện. Khi đó có thể cần đến các sự cải biên hệ thống tốn kém để làm cho nó đúng đắn.

Có 4 bước liên quan đến việc thẩm định yêu cầu:

-       Chỉ ra các nhu cầu của người dùng là được thoả mãn

-       Các yêu cầu phải không gây ra mâu thuẫn nhau

-       Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc của người dùng đã nhắm đến

-       Các yêu cầu phải là hiện thực

Câu 20: Trình bày về các giai đoạn kiểm thử, các kỹ thuật kiểm thử?

          - Khái niệm: Kiểm thử 1 sản phẩm Phần mềm là xây dựng 1 cách có chủ định những tập dữ liệu và dãy thao tác nhằm đánh giá một số hoặc toàn bộ các tiêu chuẩn của sản phẩm Phần mềm đó.

          - Các giai đoạn kiểm thử: trừ hệ thống nhỏ, nói chung không nên kiểm thử nguyên cả khối; quá trình kiểm thử có thể chia 5 giai đoạn:

          1. Thử đơn vị

          2. Thử Module

          3. Thử hệ con

          4. Thử hệ thống

          5. Thử nghiệm thu: còn gọi thử anpha

          Khi hệ thống được đem bán còn phép thử Beta: phân phối hệ thống cho 1 số người dùng đồng ý dùng thử và báo cáo lại các vấn đề cho người phát triển hệ thống.

Các kỹ thuật kiểm thử:

          + Kiểm thử lược đồ hệ thống: Chỉ quan tâm đến các bản chọn (menu) đánh giá tính hợp lý, khả năng chọn  1 mục, khả năng di chuyển qua mục khác, tính đủ, tính khoa học của các chức năng.

          + Kiểm thử cận dưới

          + Kiểm thử cận trên: Cho hệ thống thực hiện đến mức tối hạn

          + Kiểm thử qua sự cố: Tạo ra các sự cố để kiểm thử Phần mềm