Đề Cương Thiết Kế Và Xây Dựng Phần Mềm - 123doc

Nêu khái niệm phân tích và thiết kế phần mềm Software analysis and development Thiết kế phần mềm bao gồm cả chu trình từ xác định kiến trúc, thành phần, giao diện và các nhân tố khác của

1 Nêu khái niệm phân tích và thiết kế phần mềm (Software analysis and development)

Thiết kế phần mềm bao gồm cả chu trình từ xác định kiến trúc, thành phần, giao diện

và các nhân tố khác của một hệ thống hay một thành phần nào đó, lẫn kết quả của chu trình đó(định nghĩa của IEEE )

2.Phân biệt khái niệm Phương pháp luận (methodologies) và Kỹ thuật (technique)

Methodologies(Phương pháp luận) Technique(kĩ thuật)

- Phương pháp chung(cách tiếp cận) để tạo

+ Object Oriented Methodology(phương

pháp hướng đối tượng)(OOA/OOD…)

- Được thiết kế ra để làm chuẩn hoá quá

trình phần mềm

- Phương pháp cụ thể trong một giai đoạn của phương pháp luận, thực hiện cụ thể của phương pháp luận.

VD: SSADM: dùng 3 kĩ thuật chủ yếu: mô hình dữ liệu logic, mô hình luồng dữ liệu,

mô hình ứng xử thực thể OOA/OOD: UML

(Tham khảo K47)

- Phương pháp luận là các hướng tiếp cận khi phân tích thiết kế phần mềm nói chung Đây là các phương pháp tuân theo một chuẩn thiết kế nào đó được đưa ra nhằm làm chuẩn hóa quá trình thiết kế phần mềm Ví dụ: phương pháp tiếp cận trên xuống, phương pháp tiếp cận hướng dữ liệu, …

- Các kĩ thuật là các phương pháp được sử dụng để thực hiện một giai đoạn nào đó trong toàn bộ chu trình phát triển phần mềm Ví dụ:

o Phương pháp đặc tả hình thức là kĩ thuật dùng để mô tả các đặc tả của phần mềm dựa trên các luật hình thức.

o Phương pháp Jackson là kĩ thuật dùng để định nghĩa thuật toán của một chương trình theo cấu trúc dữ liệu đầu vào.

Câu 3 : Công cụ (tool): Vai trò, tác dụng Nêu tên một số công cụ chính và ứng dụng của những công cụ này

Trả lời :

- Vai trò: cung cấp những hỗ trợ tự động hoặc bán tự động cho các quy trình và phương pháp phân tích thiết kế phần mềm Nói cách khác công cụ chính là những phần mềm được tạo ra nhằm mục đích sử dụng chung.

- Tác dụng: khi một công cụ được tích hợp thì những thông tin do nó tạo ra có thể được sử dụng cho việc xây dựng và phát triển các phần mềm khác Chính vì vậy việc sử dụng công cụ có một số tác dụng như sau:

o Rút ngắn thời gian phát triển hệ thống

o Kích cỡ phát triển được rút ngắn lại

o Dịch vụ nâng cấp được kèm theo

- Một số công cụ và vai trò của nó:

o CAD: (Computer Aided Design) thiết kế có máy tính hỗ trợ Người làm ra bản thiết kế bằng cách nhận sự hỗ trợ của máy tính qua hiển thị đồ họa.

o CAM: (Computer Aided Manufactoring) chế tạo có máy tính hỗ trợ Hỗ trợ cho quản lý tiến trình, chuẩn bị cho sản xuất, kiểm thử xử lý và lắp ráp.

o CAE: (Computer Aided Engineering) kĩ nghệ có máy tính hỗ trợ Là hệ thống hỗ trợ cho một loạt các công việc bao gồm từ thiết kế sản phẩm, kiểm thử hiệu năng và chế tạo.

Câu 4 : Phân tích viên (Software Analyst): Vai trò và vị trí của cán bộ này trong công ty phần mềm

Trả lời :

- Vai trò: nhìn nhận được các yêu cầu đặt ra đối với hệ thống cả về phía người dùng lẫn về phía hệ thống ví dụ như về quy mô hệ thống, về chức năng của hệ thống, lấy được các yêu cầu của khách hàng… Từ đó đề ra các chiến lược để thiết kế và phát triển hệ thống Do đó phân tích viên cần phải có các yếu tố sau :

o Am hiểu về công việc của công nghệ phần mềm.

o Có nhiều kinh nghiệm và thành thạo trong lập trình phần mềm.

o Có hiểu biết chung về nghiệp vụ.

o Có các kĩ năng giải quyết vấn đề.

o Khả năng giao tiếp tốt.

o Linh hoạt và có khả năng thích nghi.

- Vị trí: Có vị trí quan trọng đầu tiên trong một dự án Nếu không đưa ra được những phân tích điểm lợi của dự án hay những điểm yếu cần khắc phục cũng như những yêu cầu cần thiết đặt ra của dự án thì có thể dẫn tới thất bại dự án Trong một công ty phần mềm, là người chịu trách nhiệm phân tích những hướng phát triển trong tương lai của công ty cũng như đưa ra những ưu nhược điểm của các

mô hình phát triển hiện thời mà công ty đang áp dụng.

5 Quá trình phát triển của phương pháp tiếp cận phân tích và thiết kế phàn mềm

- Hướng tiếp cận hướng tiến trình:

o Tập trung vào các giải thuật và xử lý dữ liệu

o Quá trình phát triển phần mềm tập trung thể hiệnc ác phương pháp xử lý

dữ liệu.

o Cấu trúc dữ liệu thông thường không được thể hiện rõ

o Nhược điểm của hướng tiếp cận: các tệp dữ liệu rất khó xây dựng để thỏa mãn phần mềm.

- Hướng tiếp cận hướng dữ liệu:

o Mô tả tổ chức của dữ liệu: mô tả dữ liệu được lấy ở đâu ra và sử dụng như thế nào

o Mô hình dữ liệu được thành lập cũng như mối quan hệ giữa các dữ liệu này

o Sử dụng các business rules dể chỉ ra phương pháp xử lý dữ liệu

- Hướng tiếp cận hướng kiến trúc:

o Lựac họn kiến trúcvà công nghệ phần mềm để thực hiện bài toán

o Áp dụng phương pháp prototyping để nhah chóng xây dựng được phần mềm

o Sử dụng các partern kiến trúc mẫu để chỉ ra phương pháp xử lý dữ liệu

6 So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm: phương pháp cổ điển, phương pháp hướng tiến trình, phương pháp hướng dữ liệu

So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm:

- Phương pháp cổ điển: là phương pháp phân tích và thiết kế có cấu trúc Các yêu cầu về hệ thống đích được phát triển được phân tích bằng việc đặc biệt chú ý tới chức năng của hệ thống và luồng dữ liệu giữa các chức năng Mục đích của phương pháp này là chuyển các tiến trình trong biểu đồ DFD thành các module chương trình và tiến hành phân chia các module bằng cách tiếp cận trên xuống.

- Phương pháp hướng tiến trình: việc phân tích và thiết kế đặt trọng tâm vào các chức năng do phần mềm thực hiện Không có chuẩn rõ ràng để định nghĩa đơn vị chức năng do đó việc định nghĩa này có thể ảnh hưởng bởi cách nghĩ riêng của người thiết kế Khó điều chỉnh các yêu cầu cho nhiều người dùng Sử dụngc ác chức năng chồng chéo nhau là khó tránh khỏi Kết quả là hệ thống bao gồm nhiều chức năng chồng chéo nhau là một trong những nhân tố làm cho việc bảo trì trở nên khó khăn.

- Phương pháp hướng dữ liệu: dữ liệu không thay đổi bởi các yêuc ầu hay đòi hỏi của người dùng về thao tác nghiệp vụ Trong thiết kế hướng dữ liệu hệ thống được thiết kế dựa trên cấu trúc tiến trình dữ liệu Việc phân tích thiết kế được tiến hành cho dữ liệu được tách bạch với yêuc ầu hay đòi hỏi của người dùng về thao tác Do vậy tiến trình được xác định và tích hợp vào trong các thủ tục chuyên dụng dữ liệu.

Use case mô tả tương tác giữa người dùng với hệ, nó cho biết các actor (Các tác nhân) , các chức năng của hệ thống Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía hệ thống (tức là Use case) Các tác nhân và các Use case được

mô hình hóa cùng các mối quan hệ và được miêu tả trong biểu đồ Use case của UML Mỗi một Use case được mô tả trong tài liệu, và nó sẽ đặc tả các yêu cầu của khách hàng.

Xây dựng mô hình Use-case:

- Bước đầu tiên của quá trình mô hình hóa Use-Case là định nghĩa hệ thống(Xác định phạm vi của hệ thống – Hình chữ nhật liền nét) : Vì hệ thống

là một thành phần của mô hình Use Case nên ranh giới của hệ thống mà ta muốn phát triển cần phải được định nghĩa rõ ràng Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải bao giờ cũng là việc dễ dàng, bởi không phải bao giờ người ta cũng rõ ràng nhìn ra tác vụ nào có khả năng được tự động hóa tốt nhất ở hệ thống này và tác vụ nào thì tốt nhất nên thực hiện thủ công hoặc dành cho các hệ thống khác Một khía cạnh khác cần chú ý là hệ thống cần phải lớn tới mức độ nào trong phiên bản đầu tiên của nó Cố gắng tối đa cho phiên bản đầu tiên của hệ thống thường là cách mà người ta hay thực hiện, thế nhưng những mục tiêu quá tầm như vậy có thể khiến cho hệ thống trở nên quá lớn và thời gian để cung cấp hệ thống quá lâu.

- Tìm ra các tác nhân(Actor) và các use-case

o Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống Trong khái niệm "tương tác với hệ thống", ý chúng ta muốn nói rằng tác nhân sẽ gửi thông điệp đến hệ thống hoặc

là nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi các thông tin cùng với hệ thống Nói một cách ngắn gọn, tác nhân thực hiện các Use Case Thêm một điều nữa, một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví dụ như là một chiếc máy tính khác được nối kết với hệ thống của chúng ta hoặc một loại trang thiết bị phần cứng nào đó tương tác với hệ thống).

o Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận được Một Use Case trong ngôn ngữ UML được định nghĩa

là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống.

- Mô tả các Use-case

- Định nghĩa mối quan hệ giữa các Use-case

- Kiểm tra và phê chuẩn mô hình.

Ví dụ:

Câu 10: Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng Prototyping.

Prototyping là phương pháp xác định yêu cầu phần mềm bằng cách đưa ra các mẫu thử Người phát triển sẽ dựa vào các yêu cầu khảo sát để đưa ra 1 sản phẩm ban đầu phác thảo có thể bằng công nghệ khác với công nghệ sẽ được sử dụng Sau đó có sự trao đổi với người sử dụng, từ đó tìm ra các yêu cầu một cách cụ thể, rõ ràng hơn, đặc biệt là các yêu cầu có tính “mờ” Việc tạo mẫu thử có thể được sử dụng nhiều lần ở nhiều phần

và giai đoạn khác nhau Các mẫu thử được tạo ra có thể có khả năng tái sử dụng, các mẫu thử sau sẽ phát triển liên tiếp nên nền các mẫu thử trước.(Mô hình tiến hóa)

Với mục đích phân tích yêu cầu phần mềm ta xem mẫu thử yêu cầu phần mềm như là sự thực thi riêng lẻ của hệ thống, nhằm mục đích giúp đỡ người phát triển, người

sử dụng và khách hàng hiểu cặn kẽ hơn về yêu cầu của hệ thống.

Với mục đích phân tích yêu cầu ta có thể chon xây dựng các mẫu thử : throwaway, horizontal, user interface (Nếu muốn nói cụ thể từng loại mọi người đọc sách Managing Requirement Software chương 13 nhe)

Để xây dựng các mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người phát triển phải khảo sát các yêu cầu của hệ thống, tiến hành trao đổi đàm phán với khách hàng Lựa chọn công cụ thích hợp cho việc phát triển mẫu thử Dựa vào các yêu cầu đã khảo sát tạo bản mẫu rồi tro đổi với người sử dụng, với khách hàng, để phát hiện

cụ thể hơn các yêu cầu đặc biệt các yêu cầu có tính “mờ” Tiến hành phát triển theo mẫu thử đã được phê duyệt, sau bước đó tiếp tục tạo các mẫu thử có thể sử dụng các mẫu thử

đã có từ trước.

Câu 11: Trình bày các yêu cầu khi xác định nhiệm vụ và phạm vi của phần mềm

Trong phát triển phần mềm, có nhiều yếu tố cấu thành phạm vi của dự án Phạm vi dự

án là một hàm của:

 Chức năng cần có để đáp ứng nhu cầu người dùng.

 Tài nguyên sẵn sàng cho dự án.

 Thời gian cần có để có thể thực hiện dự án.

Nhằm mục đích phân tích phạm vi, ta coi tài nguyên là không đổi trong suốt

Thông thường trong công nghiệp, các dự án đều là dự án vượt phạm vi.

Câu 12 Xác định và quản lý giới hạn của các yêu cầu phần mềm

Một số vấn đề quan trọng khi xác định giới hạn của các yêu cầu phần mềm:

 Thiết lập một ranh giới cho các yêu cầu cấp cao, một tập các đặc tính được đánh chỉ mục sẽ được phân cho một phiên bản cụ thể của sản phẩm.

 Thiết lập ở mức phác thảo hiệu năng của mỗi đặc tính của ranh giới.

 Ước lượng rủi ro cho mỗi đặc tính, hay xác suất thực hiện có thể gây ra ảnh hưởng tới lịch trình và ngân sách.

 Sử dụng các dữ liệu này, thiết lập ranh giới đảm bảo sự phân phối các đặc tính có ảnh hưởng đến thành công của dự án.

a Ranh giới của các yêu cầu.

Mục đích của quản lý giới hạn của các yêu cầu phần mềm là nhằm thiết lập một ranh giới cho các yêu cầu cấp cao của dự án Chúng ta xác định ranh giới theo: tập các đặc tính được chia thành các chỉ mục, hay các yêu cầu sẽ được phân phối cho một phiên bản cụ thể nào đó của ứng dụng.

Ranh giới các yêu cầu.

Ranh giới vạch ra phải:

 Ít nhất là có thể chấp nhận được đối với khách hàng.

 Có một khả năng thành công hợp lý.

Bước đầu tiên để tạo ranh giới đơn giản là liệt kê các đặc tính được định nghĩa cho ứng dụng Chìa khóa của bước này chính là việc điều khiển mức độ chi tiết.

b Thiết lập mức ưu tiên.

Trong thiết lập mức ưu tiên, quan trọng là khách hàng và người dùng, quản đốc hoặc một người đại diện nào đó, chứ không phải đội phát triển, sẽ thiết lập mức

ưu tiên từ bộ phận marketing trong nhà.

c Định mức hiện năng.

Thiết lập mức thô cho hiệu năng mỗi đặc tính của ranh giới đã đề xuất Chia nhóm theo 3 mức: thấp-trung bình-cao.

d Bổ sung yếu tố rủi ro.

Chúng ta coi xét rủi ro là xác suất việc thực hiện đặc tính sẽ gây ra tác động bất lợi đến lịch trình và ngân sách Rủi ro cho phép chúng ta ước đoán được tác

động của việc gộp mỗi đặc tính riêng biệt vào trong ranh giới Một đặc tính có độ rủi ro cao có tác động rất xấu đến dự án, dù cho tất cả các đặc tính khác được hoàn thành đúng thời hạn.

Rủi ro cũng được chia thành 3 mức như với hiệu năng.

e Thu hẹp phạm vi.

Thông thường mức ưu tiên, hiệu năng và rủi ro không đồng nhất với nhau Có nhiều chỉ mục cấp thiết lại có hiệu năng thấp, nhiều chỉ mục hữu dụng lại khó thực hiện Từ đó, ta có thể xem xét ưu tiên cho các đặc tính, áp dụng vào các tài nguyên được cung cấp để tăng tối đa lợi ích cho khách hàng Có thể thêm nhân lực cho đội

dự án hoặc có thể cho một số tính năng có độ ưu tiên thấp hơn, dành nguồn lực để phát triển các tính năng tối cần thiết.

Câu 13 Trình bày phương pháp xác định các yêu cầu phần mềm từ khách hàng

Trong khi xác định yêu cầu của khách hàng, ta phải xem xét có hai dạng khách hàng: -Khách hàng cung cấp các yêu cầu về nghiệp vụ : Cung cấp các thông tin về công ty, về các đặc điểm ở mức độ cao, về mô hình và phạm vi của hệ thống.

-Khách hàng cung cấp các yêu cầu người sử dụng " cung cấp các thông tin về từng nhiệm

vụ cụ thể mà họ sẽ làm việc với phần mềm.

Ta cần phối hợp, kết hợp chặt chẽ với hai loại khách hàng trên

Phương pháp xác định yêu cầu của khách hàng :

-Lên lịch hẹn gặp rõ ràng khi thực hiện công việc trao đổi với khách hàng

-Tạo môi trường thân thiện với khách hàng trong khi thực hiện xác định các yêu cầu, tránh làm cho khách hàng khó chịu trong quá trình phỏng vấn(đây là vấn đề rất nhạy cảm)

-Trong khi trao đổi với khách, cần tôn trọng các quyền lợi của khách hàng.

-Trong quá trình trao đổi, sử dụng các ngôn từ thông dụng, không sử dụng nhiều các thuật ngữ tin học

-Cần trao đổi về công việc của khách hàng, nắm bắt, học và hiểu các công việc đó(để khi thiết kế và xác định chức năng cho phần mềm chính xác) Yêu cầu khách hàng giải thích từng đặc điểm công việc nếu chưa hiểu rõ để phần mềm được làm ra sẽ tốt và dễ sử dụng hơn.

-Khi xác định được các yêu cầu của khách hàng, cần thực hiện việc đánh trọng số, tức là xác định mức độ quan trọng của từng yêu cầu khách hàng để tập trung xây dựng phần mềm hợp lý.

-Tôn trọng khách hàng, ngay cả khi phương pháp của khách hàng khác với mình, vì có thể đó là ý tưởng mới!

-Kết thúc quá trình trao đổi, cần viết các đặc tả phần mềm

Câu 14 Trình bày các bước (quy trình) Phân tích các yêu cầu phần mềm

Sau khi thu thập được các thông tin về yêu cầu phần mềm từ khách hàng, ta cần tiến hành phân tích các yêu cầu đó Mục đích của việc phân tích này là để xác các yêu cầu đó

có dư thừa, mức độ quan trọng của các yêu cầu đó.

-Từ các yêu cầu phần mềm, ta xác định biếu đồ use case.

-Xác định các hoạt động nghiệp vụ với các điểm bắt đầu và kết thúc Trong các chu trình này, ta cần xác định các đối tượng tham gia, các luồng thông tin và điều khiển trong chu trình

-Xác định vấn đề của môi trường hoạt động phần mềm

-Thực hiền kết nối các yêu cầu nghiệp vụ và yêu cầu của người sử dụng

-Mô ta cụ thể chính xác các điều kiện và thuận lợi trong khi thực hiện các yêu cầu đó

Câu 27:Kiểm thử (testing) yêu cầu phần mềm

Kiểm thử yêu cầu phần mềm là công việc thực hiện lại sau khi có được các yêu cầu phần mềm từ phía NSD, chủ dự án…Qúa trình này là một quá trình cân nhắc về khả năng đáp ứng lại yêu cầu phần mềm do những hạn chế về nhân lực, thời gian và tài chính của đội ngũ phát triển phần mềm.

Quá trình kiểm thử phát hiện các yêu cầu phần mềm đi quá phạm vi và giới hạn của phần mềm, ảnh hưởng đến kiến trúc hệ thống.

Nhìn chung kiểm thử phần mềm là một quá trình kiểm tra các yêu cầu phần mềm, từ đó đưa ra những yêu cầu hợp lý và những phương án chấp nhận được, thỏa mãn cả hai bên

là người sử dụng và người phát triển hệ thống.

Tại sao phải kiểm thử yêu cầu phần mềm:

- Do tính chất 2 mặt của yêu cầu phần mềm: Cách nhìn và suy nghĩ về phần mềm

từ phía người sử dụng và cách nhìn, suy nghĩ về phần mềm từ phía nhà phát triển.

- Người sử dụng đưa ra những đòi hỏi quá cao hoặc chẳng liên quan đến quá trình phát triển phần mềm

- NSD đưa ra các yêu cầu và đề nghị rất khó chấp nhận là gây khó khăn cho các lập trình viên

- NSD đưa ra các yêu cầu nhập nhằng và mơ hồ, quá trình kiểm thử sẽ có trách nhiệm làm rõ các yêu cầu này.

- Phát hiện các đặc tính thừa do người phát triển hệ thống đưa thêm vào hoặc các yêu cầu phụ phần mềm từ phía người sử dụng gây tốn kém và không cần thiết

- Kiểm tra khả năng đáp ứng về mặt kỹ thuật

- Đặc tả rõ ràng và chi tiết các yêu cầu

Tiêu chí kiểm thử yêu cầu phần mềm

- Kiểm tra được, xác minh được

Câu28.Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm

Người phát triển (developer) của một hệ thống có trách nhiệm cho việc xác định các yêu cầu của ứng dụng , Phát triển phần mềm là việc thực thi các yêu cầu đó , và phân phối các tài nguyên ( processor và các mạng cộng đồng ) Không chỉ đơn thuần là đáp ứng được các yêu cầu về chức năng Ngoài ra hệ thống phải đáp ứng được các yêu cầu về bảo mật , an toàn ,tin cậy , vận hành …vì vậy một phần mềm chất lượng phải kết hợp đựoc các đặc tính mong muốn :

 Thực thi(performance) : từ truyền thống của hệ thống thời gian thực và khả năng lập kế hoạch

 Tin cậy( dependability):từ truyền thống của hệ thống hòan toàn tin cậy

 An ninh(security): từ các hệ thống chính phủ , ngân hàng , cộng đồng học thuật

 An toàn(safey) : từ truyền thống của các phân tích rủi ro

Performance :

Theo định nghĩa của IEEE : là một cấp độ , mà một hệ thống hay một thành phần hoàn thành các chức năng được thiết kế nằm trong một lọat các ràng buộc như tốc độ , chính xác , hay việc dùng bộ nhớ

 Performance requirements : số lượng các yêu cầu được định nghĩa trong các term về các sự kiện của các ràng buộc về thời gian cho sự đáp ứng tới mỗi sự kiện

 Behavior patterns and intensity : số lượng dòng sự kiện và các trường hơp tồi tệ nhất và ồn định nhất sẽ xảy ra cho mỗi dòng sự kiện

 Software descriptions : các phép toán phần mềm cần để chạy để đáp ứng các sự kiện

 Resource usage estimates : các yêu cầu về nguồn dữ liệu cho việc mang theo các phép toán phần mềm giông như thời gian sử lý của processor, các đòi hỏi I/O ,

bộ nhớ

 performance concerns : giống như các tiêu chuẩn cho việc đánh giá việc lập lịch ,

và các ràng buộc thời gian cho việc đáp ứng các sự kiện

 performance factors : cách cư sử của các pattern , việc sử dụng các tài nguyên, các miêu tả phần mềm , công việc , các phép toán , mô tả các đòi hỏi của hệ thống

 performance methods :giống như tổng hợp và phân tích vẽ lên thuyết

Là thuộc tính của một hệ thống máy tính tin cậy có thể chính đáng đặt trong một dịch vụ

nó phân phối Nó có một vài đặc tính , bao gồm :

 tồn tại : sẵn sàng cho sử dụng

 tin cậy : tiếp tục phục vụ

 an toàn : không sự cố về việc lộ thông tin

 đầy đủ : không có sự kiện thay đổi thông tin không phù hợp

 bảo trì : khả năng sửa và phát triển

Security :

 An toàn trước các mối đe doạ

 Bảo vệ dữ liệu hệ thống khỏi sự soi mói , chỉnh sửa , hay phá huỷ Bao gồm cả công nghệ và quản trị

 Các chính sách an toàn được xiết chặt , với một vài cấp độ đảm bảo

 Dùng các khả năng phán đoán ngăn chặn

Security được thực thi về cơ bản dựa trên sự phân tích các rủi ro của môi trường xác định , sau đó nó được dùng như một framework để miêu tả hoặc là các lỗi an ninh hay các cơ cấu ngăn chặn trong hệ thống

Safety

Chúng ta có thể định nghĩa sự an toàn như một tính chất của một hệ thống máy tính như

sự tin cậy có thể chính dáng được đặt lên một hệ thống không có các rủi ro

 Trong khi Dependability được tập trung với các sự cố của các lỗi , định nghĩa trong các term của các kết quả bên trong

 Thì Safety tập trung với các sự cố đã được chỉ rõ , được định nghĩa trong các thuật ngữ của các kết quả bên ngoài

Ví dụ một hệ thống được coi là không hoàn hảo thì hệ thống đó có thể tin cậy , nhưng không an toàn

Safety cho các đặc tính an toàn định nghĩa các điều kiện của hệ thống về rủi ro có thẻ dẫn đến những kết quả không mong muốn Phương thức sử dụng là xác định các rủi

ro , đánh giá các kết quả cuối cùng của các rủi ro, và loại trừ hay giảm thiểu các rủi ro

và xác định các kết họp an toàn ( hệ thống , môi trường , người dùng , các phép toán )

29 Nêu phương pháp theo dõi các yêu cầu phần mềm và đảm bảo các yêu cầu phần mềm Trả lời:

 Phương pháp theo dõi các yêu cầu phần mềm:

Theo dõi dấu vết của một yêu cầu phần mềm cho phép chúng ta quản lý được các yêu cầu phần mềm này, nguồn gốc của nó, các mối liên quan của nó và cách thực hiện, kiểm thử, bảo dưỡng và phát triển nó.

04 thao tác cần thiết với quá trình theo dõi dấu vết của một yêu cầu phần mềm:

Forward to Requirement: quá trình mang yêu cầu khách hàng(cusomer’s needs) chuyển thành yêu cầu phần mềm.

Backward from Requirement: quá trình xác nhận khả năng đúng đắn của yêu cầu phần mềm bởi yêu cầu của khách hàng.

Forward from Requirement: là quá trình ấn định một yêu cầu cho một hoặc nhiều thành phần hệ thống Thao tác này thuận tiện cho việc ước lượng ảnh hưởng của việc thay đổi yêu cầu phần mềm.

Backward to Requirement: quá trình này chỉ ra rằng yêu cầu đã được kiểm tra thích ứng với hệ thống nhất định.

Tồn tại 03 loại yêu cầu được liên kết với nhau:

Tại sao cần theo dõi yêu cầu phần mềm:

Tính chứng nhận (certification): xác thực tất cả các chức năng đã được thực hiện Khả năng phân tích phần mềm tốt hơn (change impact analyis)

Khả năng bảo dưỡng phần mềm tốt hơn(maintenance)

Khả năng theo dõi quản lý, hiệu chỉnh dự án tốt hơn (project tracking)

Khả năng phát triển hệ thống(Reengineering)

Khả năng tái sử dụng (reuse)

Khả năng giảm rủi ro (Risk Reduce)

Khả năng kiểm thử (testing)

Ma trận theo dõi các yêu cầu phần mềm(Requirements Traceability Matrix):

Phương pháp hay được sử dụng nhất để liên kết các yêu cầu phần mềm và các thành phần khác của hệ thống là sử dung ma trận theo dõi các yêu cầu phần mềm.

Các liên kết này thường được thể hiện giữa các thành phần:

Các trường hợp sử dụng (yêu cầu phần mềm)

Các yêu cầu chức năng (functional requirement)

Các thành phần thiết kế(design element)

Mã chương trình (code)

Trường hợp kiểm thử(test case)

Các mối liên kết có thể được phân chia:

Một-Một

Một-Nhiều

Use case Functional

Requirement element Design Code Test Case

)

Input.01

Use Case Functional

Requirement

(1) Xác định các mối liên kết và các khả năng lập ma trận

(2) Chọn dạng ma trận: tổng hợp hay chi tiết

(3) Chọn các chức năng/ các yêu cầu cần theo dõi

(3) Xác định phương pháp gán nhãn các yêu cầu

(4) Xác định nguồn các thông tin về các yêu cầu phục vụ cho sự liên kết

(5) Thông báo cho những người tham gia về sự liên kết

(6) Kiểm soát sự liên kết trong quá trình phát triển phần mềm

 Đảm bảo yêu cầu phần mềm(Thẩm định&xác minh các yêu cầu phần mềm):

Mục đích của việc kiểm tra xác minh thẩm định các yêu cầu phần mềm về tính đúngd

ắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm

Các yêu cầu phần mềm chúng ta miêu tả trong SRS phải đúng là những yêu cầu từ khách hàng, các yêu cầu giải quyết được những công việc của họ.

Chúng ta có nhiệm vụ kiểm soát tính chính xác, tính không trùng lặp của các yêu cầu phần mềm này.

Các thao tác thẩm định xác minh có thể bao gồm:

Viết các trường hợp kiểm thử cho các yêu cầu: sử dụng mô hình hộp đen từ các trường hợp sử dụng để đánh giá hoạt dộng và hành vi của hệ thống Duyệt các hành vi

và theo dõi các hoạt động để kiểm tra hệ thống đang đặc tả có đáp ứng các yêu cầu của NSD hay không.

Xây dựng tài liệu hướng dẫn sử dụng (user manual): để tiết kiệm thời gian chúng ta

có thể dựng bản nháp của tài liệu hướng dẫn sử dụng và sử dụng nó như là tài liệu để kiểm tra lại các yêu cầu phần mềm.

Định nghĩa các tiêu chuẩn chấp nhận: Hỏi NSD xem các tiêu chí thực họ đánh giá sản phầm phần mềm cần xây dựng theo những tiêu thức như thế nào để chúng ta có thể đưa những tiêu thức đó vào các trường hợp sử dụng của hệ thống

Tham gia vào quá trình duyệt các yêu cầu phần mềm:

Các PTV

Các đại diện của NSD (Product champions)

Tất cả các thành viên của công ty phần mềm sẽ tham gia vào quá trình thực hiện phần mềm: LTV, các nhà kiểm thử, v.v

Các công cụ/biểu mẫu sử dụng:

Các tiêu thức đánh giá(entry and exit criteria check list)

Requirement Inspection Checklist

Kiểm thử các yêu cầu phần mềm(Testing):

Dialog Map

Test Case

Ma trận theo dõi các trường hợp sử dụng

Câu 30: Nêu tên một số kỹ thuật phát hiện các yêu cầu phần mềm :

Các kĩ thuật phát hiện phần mềm:

 Phân tích bài toán:

 Xác định quá trình phát triển các yêu cầu phần mềm:

 Xác định các bước và tài liệu mô tả quy trình chúng ta sẽ thực hiện quá trình phát triển các yêu cầu phần mềm.

 Mô tả phương pháp xác định các NSD trong phạm vi bài toán của phần mềm

và các kỹ thuật sẽ sử dụng đểphát hiện các yêu cầu phần mềm

 Mô tả các đặc tả hoặc các mô hình phân tích của phần mềm

 Các thông tin cho mỗi yêu cầu, trọng số của yêu cầu

 Các bước tiến hành phát hiện các yêu cầu, phân tích yêu cầu

 Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm:

 Khả năng và phạm vi của phần mềm tập hợp các yêu cầu phần mềm ở mức độ cao(business requirement).

 Mô tả khả năng, mục tiêu của phần mềm, các phạm vi ứng dụng của phần mềm, các hạn chế của phần mềm, một số đặc điểm của ứng dụng: ai sử dụng, trong môi trường nào.

 Xác định các nhóm người sử dụng và đặc tính của họ và đại diện tiêu biểu cho mỗi nhóm:

 Phân lớp người sử dụng phần mềm(user classes)

 Phân loại theo đặc điểm Phân loại theo vị trí địa lý.

 Phân loại theo vai trò công việc

 Phân loại theo chức năng

 Liệt kê các phân loại (cáclớp) và mô tả chi tiết các đặc điểm của NSD ở từng lớp

 Tìm các NSD tiêu biểu (presentativeuser)

 Những đại diện tiêu biểu của từng nhóm người sử dụng Trên thực tế các yêu cầu phần mềm sẽ được phát hiện từ những khách hàng này

 Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm NSD:

 Xây dựng các đặc tính xác định chất lượng yêu cầu và các yêu cầu

khác(non-functional requirement):

33 Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS) System Requirement và Software Requirement được hiểu khác nhau như thế nào và được đặc tả ở vị trí nào trong tài liệu SRS

- System Requirement (yêu cầu hệ thống) nêu lên cấu hình hiện tại của cơ sở hạ tầng thông tin của hệ thống sẽ được phát triển phần mềm như : cấu hình hạ tầng mạng, hệ thống máy tính, các thiết bị ngoại vi đang có, và ảnh hưởng của chúng lên phần mềm

sẽ xây dựng Nó xác định cách mà phần mềm mới phải tương tác với hệ thống đã có và những ràng buộc quan trọng phải được quản lý cẩn thận

Các yêu cầu hệ thống bao gồm : Xác định và mô tả chi tiết tất cả các dịch vụ hoặc đặc tính mà phần mềm mới sẽ phụ thuộc; Mô tả các hệ thống và dịch vụ ngoài mà phần mềm mới sẽ tương tác; Mô tả ảnh hưởng của giải pháp lên hệ thống mạng như thế nào; Cuối cùng mô tả các tiến trình cần có để đảm bảo hệ thống mới sẽ không ảnh hưởng xấu đến

34 Tại sao cần kiểm thử đánh giá các yêu cầu phần mềm Nêu tên một số phương pháp kiểm thử yêu cầu phần mềm thông dụng mà em biết

Việc kiểm thử đánh giá các yêu cầu phần mềm là cần thiết bởi vì qua việc kiểm thử đánh giá, chúng ta mới có thể thẩm định được tính đúng đắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm mà chúng ta đã miêu tả trong SRS Các yêu cầu đó phải đúng là những yêu cầu từ khách hàng, giải quyết được các công việc của họ.

Một số phương pháp kiểm thử yêu cầu phần mềm thông dụng:

- Kiểm thử hộp đen

- Kiểm thử hộp trắng

35 Nêu các phương pháp theo dõi vết của yêu cầu phần mềm

Có 2 loại theo dõi vết: Tường minh và không tường minh.

o Tường minh: Các mối quan hệ được thêm vào một cách tường minh bởi đội

dự án Ví dụ: Mối quan hệ giữa yêu cầu và các use case.

o Không tường minh: Ví dụ mối quan hệ phân cấp giữa các yêu cầu với nhau Yêu cầu cha có mối quan hệ không tường minh với các yêu cầu con.

Phương pháp: (từ sách SE – Pressman – p289)

Sau khi xác định yêu cầu, chúng ta lập các bảng theo dõi vết Các bảng này cho phép chúng ta biết khi thay đổi một yêu cầu thì nó sẽ ảnh hưởng đến những nhân tố nào trong hệ thống sẽ xây dựng Một số bảng theo dõi vết:

Features traceability table: Cho biết mối quan hệ giữa yêu cầu và các tính năng mà

khách hàng sẽ thấy được trong sản phẩm.

Source traceability table: Xác định nguồn của từng yêu cầu.

Dependency traceability table: Cho biết mối quan hệ giữa các yêu cầu với nhau.

Subsystem traceability table: Phân loại các yêu cầu theo các phân hệ mà nó có ảnh

hưởng.

Interface traceability table: Cho biết mối quan hệ giữa yêu cầu và các giao diện của hệ

thống (cả giao diện ngoài và giao diện trong).

36 Quản lý thay đổi yêu cầu phần mềm

Lý do thay đổi yêu cầu phần mềm

Các tác nhân bên ngoài: thay đổi vấn đề, người sử dụng thay đổi quyết định của mình, môi trường bên ngoài thay đổi, hệ thống mới tồn tại.

Các tác nhân bên trong: chúng ta đã không hỏi những người đúng các câu hỏi đúng tại thời gian đúng trong suốt quá trình tập hợp yêu cầu ban đầu Chúng ta đã không tạo ra một tiến trình thực hành để giúp đỡ việc quản lý thay đổi yêu cầu mà thông thường xảy ra theo chiều hướng tăng tiến.

Quá trình để quản lý thay đổi:

1.Đoán nhận những thay đổi tất yếu, và lên kế hoạch xử lý nó

2.Thiết lập ranh giới các yêu cầu.

3.Thiết lập một kênh đơn để kiểm soát sự thay đổi

4.Sử dụng một hệ điều khiển thay đổi để nắm bắt những thay đổi

5.Quản lý sự thay đổi theo phân cấp

Quản lý Cấu hình các yêu cầu :

1 Ngăn ngừa những yêu cầu không hợp pháp và các phá hoại tiềm tàng hay những yêu cầu thay đổi linh tinh.

2 Bảo đảm việc duyệt lại những tài liệu về yêu cầu.

3.Làm thuận tiện việc lấy lại và/ hoặc xây dựng lại những phiên bản trước của tài liệu.

4 Hỗ trợ quản lý, tổ chức ranh giới “giải thoát kế hoạch” cho những cải tiến hoặc cập nhập ngày càng tăng của hệ thống.

5.Ngăn chặn đồng thời việc cập nhật tài liệu hay xung đột và không cho phép cập nhập những tài liệu khác nhau cùng lúc

Chương 2 Thiết kế phần mềm (Software Design)

Câu 1 Nêu quy trình thiết kế phần mềm mức Logic

 Thiết kế mức logic là sự mô tả giải pháp về mặt tổ chức, cấu trúc và mối quan hệ giữa các phần của giải pháp từ góc nhìn của đội dự án.

 Pha thiết kế logic bắt đầu sau pha thiết kế mức khái niệm.

 Quy trình:

o Phân tích thiết kế mức logic:

o Lọc danh sách các công cụ và công nghệ thích hợp.

o Xác định các dịch vụ và đối tượng nghiệp vụ.

o Xác định các thuộc tính quan trọng và các mối quan hệ chủ đạo.

o Tối ưu thiết kế logic:

o Trau chuốt thiết kế logic.

o Kiểm tra, phê chuẩn thiết kế logic.

 Đầu ra của thiết kế logic:

o Mô hình đối tượng mức logic.

o Thiết kế giao diện người dùng ở mức cao.

o Mô hình dữ liệu mức logic.

Đầu ra của thiết kế logic là cơ sở cho thiết kế vật lý.

Câu 2 Các phương pháp tạo các thiết kế mức logic (Logical Design)

Sử dụng lược đồ usecase để tạo thiết kế mức logic Bao gồm các bước sau:

 Lựa chọn danh sách các công nghệ có thể

 Xác định các đối tượng nghiệp vụ phù hợp nhờ lược đồ Use case.

 Xác định các dịch vụ từ lược đồ usecase

 Xác định các thuộc tính từ lược đồ usecase

 Xác định các quan hệ giữa các đối tượng từ lược đồ usecase

3 Đặc tả tài liệu thiết kế mức logic

Tài liệu đặc tả thiết kế mức logic gồm 3 phần chính : mô hình đối tượng mức logic, mô hình dữ liệu mức logic, và thiết kế giao diện người dùng mức cao.

Trong khi xây dựng tài liệu , chú ý sử dụng CRC card và biểu đồ diễn tiến CRC card giúp ta tập trung vào những trách nhiệm mức cao của một lớp, chứ không đi vào các phương thức và thuộc tính chi tiết của lớp CRC card cũng giúp nhận diện các quan hệ giữa các đối tượng khác nhau trong thiết kế Biểu đồ diễn tiến giúp ta thấy các actor và đối tượng tham gia vào một tương tác và thứ tự các thông điệp tương tác giữa các đối tượng đó.

- Mô hình đối tượng mức logic

Mô hình đối tượng mức logic cho ta biết các đối tượng, mối quan hệ giữa các đối tượng trong hệ thống cũng như các phương thức và thuộc tính của mỗi đối tượng Khi tạo mô hình , ta phải xem xét tất cả các yêu cầu nghiệp vụ và yêu cầu người dùng cũng như các ràng buộc có thể xuất hiện trong các kịch bản.

- Mô hình dữ liệu mức logic