Đề cương thiết kế và xây dựng phần mềm

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
ra phần mềm.
- Hiện tại có hai luồng chính của các
phương pháp luận:
+ Structured Methodology(phương pháp
cấu trúc)- (SSADM phân tích cấu trúc và
phương pháp thiết kế…)
+ 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.
Chương 2
Câu 9: 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 UseCase.
Use Case là một phương pháp luận trong ngôn ngữ mô hình hóa UML. Đó là một

phương pháp luận khá hoàn chỉnh cho việc phát triển phần mềm hướng đối tượng. Use
case được mô tả qua biểu đồ Use-case.
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.
Phạm vi dự án.
 Tài nguyên, trước hết bao gồm lao động từ developers, testers, tech writers,
nhân viên đảm bảo chất lượng
Nếu thời gian đủ dài, kết quả công việc có thể được tăng lên, nhưng nó không
tăng tỷ lệ với tài nguyên đầu tư thêm. Hiệu quả tổng thể của dự án vì thế mà
sẽ bị giảm sút. Thêm tài nguyên thậm chí có thể làm chậm dự án bởi vì cần
phải đào tạo và hỗ trợ cho nhân sự mới, vì thế sẽ làm giảm năng suất của 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
dự án.
 Thời gian, có thể thay đổi nếu như tài nguyên sẵn có không đủ để hoàn thành
các chức năng mong muốn. Để phân tích phạm vi, ta coi như thời gian là yếu
tố cố định.
Chức năng tổng thể bị giới hạn bởi thời gian (cố định) và tài nguyên (cũng cố định),
vì thế phạm vi khả thi chính là hình chữ nhật màu trắng.
Nếu hiệu năng đòi hỏi phải bổ sung đặc tính của hệ thống bằng với tài nguyên trên
thời gian sẵn có thì dự án có phạm vi khả thi.
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
- Hoàn thiện
- Chính xác
- Khả thi
- Cần thiết
- Rõ ràng
- 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
Dependability
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
Nhiều-Nhiều
Các dạng biểu diễn ma trận:
Lập bảng liên kết
Lập ma trận liên kết

Ví dụ về ma trận theo dõi phần mềm:
Use case Functional
Requirement
Design element Code Test Case
UC-01 Input.Form FormNL FormNL.input() Input.01
… … … … …
Use Case
Functional
Requirement
UC-01 UC-02 UC-03 UC-4
FR-01 UC-01 FormNL FormNL.Input() Input.01
FR-02 X X
FR-03 X X X
FR-04 X
FR-05 X X
Quá trình lập ma trận:
(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
Quy trình duyệt:
Lập kế hoạch
Các buổi họp mặt
Chuẩn bị
Các buổi họp duyệt
Làm sửa đổi
Kết thúc
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):
Quy trình kiểm thử:
Business Requirement
Use Case

Functional Requirement
Các công cụ sử dụng:
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
hệ thống đã có.
- Software Requirement (yêu cầu phần mềm) là toàn bộ các yêu cầu về chức năng mà
phần mềm phải có để đáp ứng những yêu cầu của khách hàng.
- Trong tài liệu đặc tả yêu cầu phần mềm (SRS) thì System Requirement được đặt phía
trước Software Requirement. System Requirement được đặc tả trong phần các yêu cầu
chung nhất đối với hệ thống phần mềm sẽ phát triển. Software Requirement là phần chính
của tài liệu SRS, bao gồm mô tả chi tiết yêu cầu đối với từng chức năng mà hệ thống cần
phải đạt được , nó được đặc tả ở phần trung tâm của tài liệu SRS.
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
Mô hình dữ liệu mức logic cho ta biết các thực thể và quan hệ giữa các thực thể có trong
hệ thống.
- Thiết kế giao diện người dùng mức cao
Từ danh sách các đối tượng và các phương thức của mỗi đối tượng, đội thiết kế có thể có
những ý tưởng ban đầu về các chức năng, luồng xử lý mà người dùng mong đợi, và có
thể sử dụng những thông tin này để thiết kế các thành phần giao diện người dùng như :
các nút bấm, text box, menu…
4. Kiểm thử và tối ưu thiết kế mức logic
Giai đoạn kiểm thử và tối ưu thiết kế mức logic gồm các quá trình :
- Tinh lọc danh sách các đối tượng :
Khi tinh lọc các đối tượng cần chú ý : Nếu 2 đối tượng cùng diễn đạt một thông tin hay
cùng điều khiển một hoạt động thì ta có thể kết hợp chúng lại. Nếu một thuộc tính cần tồn
tại độc lập thì hãy xem nó là một đối tượng. Cũng có thể sẽ cần những đối tượng mới để
điều phối một tập các dịch vụ…
- Kiểm chứng mô hình đối tượng mức logic
Ta có thể kiểm chứng một mô hình đối tượng mức logic bằng cách kiểm chứng tính hợp
lệ , kiểm chứng từng đối tượng riêng lẻ, hoặc bằng cách duyệt kịch bản sử dụng.
+Với kiểm chứng tính hợp lệ, ta so sánh mô hình đối tượng mức logic với các yêu cầu
phần mềm.
+Với kiểm chứng từng đối tượng riêng lẻ, ta xem lại các input, ouput cũng như các chức
năng mà đối tượng phải có.
+Với cách duyệt kịch bản sử dụng, ta đánh giá từng kịch bản, đi đến quyết định xem cần
phải có các phương thức nào và thứ tự của các phương thức đó.
- Xác định các lời gọi là trong mô hình thiết kế logic là lời gọi đồng bộ hay không
đồng bộ cũng như xác định mô hình điều khiển theo kiểu đóng gói các đối tượng
được gọi lại hay theo kiểu có một đối tượng điều khiển riêng gọi tới những đối
tượng đó.
Điểu này giúp đảm bảo tính toàn vẹn của giao dịch trong một kịch bản.
5. Quá trình mô hình hóa dữ liệu mức logic

Mô hình dữ liệu mức logic cho ta thấy các thực thể và mối quan hệ giữa các thực thể
trong hệ thống. Quá trình mô hình hóa dữ liệu mức logic :
- Phân tích :
+Nhận diện các thực thể , quan hệ giữa các thực thể và các thuộc tính của mỗi thực thể
+Chuyển các thực thể về dạng bảng
+Chuyển các thuộc tính của mỗi thực thể thành các cột của bảng
+Xác định quan hệ giữa các bảng.Ta có thể sử dụng bậc của quan hệ để làm rõ hơn quan
hệ.
Chú ý: Nếu trong quá trình thiết kế mức logic này , ta có đủ thông tin để tinh lọc các cột
và xác định khóa chính, khóa ngoài , thì ta có thể được phép đưa khóa chính , khóa ngoài
vào mô hình dữ liệu mức logic. Tuy nhiên, thường ta chỉ đưa vào trong giai đoạn thiết kế
vật lý.
- Tinh chỉnh bản thiết kế: bao gồm các công việc:
+Tinh lọc bản thiết kế
+Kiểm chứng lại bản thiết kế
6. Quá trình và các phương pháp tạo các thiết kế mức vật lý
Thiết kế vật lý là quá trình mô tả các thành phần, dịch vụ và công nghệ trong hệ thống từ
góc độ của đội phát triển. Đầu ra của quá trình thiết kế vật lý bao gồm :
- Biểu đồ lớp
- Mô hình Component, biểu đồ diễn tiến, biểu đồ hoạt động
- Sơ đồ quan hệ
- Mô hình triển khai : network topology, data and component topology
- Đặc tả các component
- Mô hình lập trình
Quá trình thiết kế vật lý bao gồm 4 bước : nghiên cứu, phân tích, tối ưu, và cài đặt.
- Nghiên cứu:
+ Xác định các ràng buộc và yêu cầu mức vật lý
+ Nhận diện những vấn đề quan tâm, lo ngại , những thay đổi trong nền tảng hạ tầng.
Đẩu ra :
+ Topology mạng hiện tại

+ Topology dữ liệu hiện tại
+ Topology các component hiện tại
+ Các yêu cầu ứng dụng
+ Kế hoạch quản lý rủi ro
- Phân tích:
+ Phát triển một mô hình triển khai sơ bộ
+ Lựa chọn các công nghệ sẽ được sử dụng để phát triển hệ thống
Đầu ra :
+ Các biểu đồ lớp, diễn tiến, hoạt động đã được tinh lọc
+ Mô hình topology mạng, dữ liệu, component sơ bộ
- Tối ưu:
+ Xác định chiến lược triển khai, đóng gói
+ Đóng gói các component và các dịch vụ
+ Phân bổ các component vào các nút mạng
- Cài đặt:
+ Xác định mô hình lập trình
+ Đặc tả giao diện các component, các thuộc tính và các dịch vụ
7. Nêu phương pháp xác định các yêu cầu đối với kiến trúc phần mềm
Thiết kế kiến trúc được bắt đầu bằng pha phân tích các yêu cầu kiến trúc mà mục đích
chính là để hiểu các yêu cầu đối với kiến trúc phần mềm được xây dựng của các
stakeholder. Stakeholder có thể là ban lãnh đạo, đội phát triển, bộ phận bảo trì, khách
hàng ,end-user…
Các kỹ thuật phân tích yêu cầu đối với kiến trúc phần mềm thường gặp là : Phương pháp
đặc tả yêu cầu phi hình thức , phương pháp use-case , phương pháp kịch bản, phương
pháp xây dựng prototypes và phương pháp máy hữu hạn trạng thái.
- Phương pháp đặc tả yêu cầu phi hình thức (ví dụ bằng ngôn ngữ tự nhiên) là
phương pháp rất cơ bản trong khi phân tích các yêu cầu đối với kiến trúc phần
mềm, và được xác định bằng cách làm việc trực tiếp với khách hàng.
- Phương pháp use-case cung cấp góc nhìn rộng hơn và chính xác hơn về các yêu
cầu bằng cách chỉ ra các hành vi bên ngoài của hệ thống từ góc nhìn của nhiều

người dùng khác nhau.
- Phương pháp kịch bản là dạng của use-case, định nghĩa cái nhìn động và những
phát triển có thể của hệ thống.
- Phương pháp prototype được sử dụng để xác định giao diện người dùng và có thể
giúp làm rõ hơn hành vi của hệ thống.
- Cuối cùng, với những hệ thống đòi hỏi độ chính xác an toàn cao (safety-critical
systems), thường dùng phương pháp biểu đồ trạng thái hay những ngôn ngữ đặc
tả hình thức.
Những kỹ thuật trên đã được áp dụng và đã chứng tỏ được khả năng trong việc hỗ trợ
phân tích yêu cầu về kiến trúc phần mềm của khách hàng.
Nguồn : Tekinerdogan , Chapter 7 SYNTHESIS-BASED SOFTWARE
ARCHITECTURE DESIGN
8. Nêu các hướng tiếp cận xây dựng kiến trúc phần mềm
- Mô hình chung:
Các tri thức domain bao gồm : Problem Domain, Business Domain, Solution Domain và
General Knowledge.
- Hướng tiếp cận Artifact-driven :
Tạo mô tả kiến trúc từ các artifact (ví dụ các class) trong đặc tả yêu cầu
Hạn chế :
-Các yêu cầu mơ hồ, nhập nhằng, hoặc không đầy đủ và ít khi hữu ích
-Các hệ thống con nghèo nàn ngữ nghĩa để phục vụ như là các thành phần kiến
trúc
-Kết cấu của hệ thống con không được hỗ trợ tốt
- Hướng tiếp cận Use-Case driven:
Trong hướng tiếp cận này , kiến trúc được tạo ra từ việc suy diễn các use-case mô tả các
chức năng của hệ thống
Hạn chế :
-Mô hình domain và nghiệp vụ được xác định trước mô hình use-case, do đó khó
có thể có được sự chi tiết của 2 mô hình này
-Việc chọn use-case thích hợp không được hỗ trợ

-Use-case không phải là công cụ tốt để xây dựng kiến trúc
-Các packet nghèo nàn ngữ nghĩa để có thể đóng vai trò của các component
- Hướng tiếp cận Domain-driven:
Kiến trúc được tạo ra dựa trên các mô hình domain. Mô hình domain có thể được thể hiện
bởi các dạng như : biểu đồ lớp, biểu đồ liên kết thực thể, frame, mạng ngữ nghĩa, các
luật…