(- thác nước (V), xoắn ốc, prototype, “RUP, RAP, Agile” sơ sơ

- kiểm thử
- mô hình: class diagram, sequence diagram, activity diagram)
Thế nào là Kỹ nghệ phần mềm:
Kỹ nghệ phần mềm được xem như là một tên gọi chỉ cách thức làm phần
mềm theo tác phong công nghiệp.

Kỹ nghệ phần mềm quan tâm đến việc làm thế nào để tạo ra sản phẩm phần
mềm đạt hiệu quả nhất.
Chapter 1: Intro
- Khái niệm Sản phẩm phần mềm, phân biệt với Hệ thống thông tin
Phần mềm (SW): Khái niệm phần mềm:
- = Chương trình máy (Computer program) + Cấu trúc dữ liệu (Data structure) + Tài liệu
(Document)

- . Mã nguồn: source code . Bộ nhớ trong (RAM): làm việc . Kỹ thuật (pt + bảo trì)

- . Mã máy: executable . Bộ nhớ ngoài (db): lưu trữ . Đào tạo, hướng dẫn
Hệ thống thông tin (IS): Là một hệ thống có tổ chức để tổ chức, thu thập,
giao tiếp và lưu trữ thông tin. Nó là nghiên cứu về các mạng bổ sung mà
các tổ chức và con người sử dụng để thu thập, tạo, phân phối dữ liệu, xử lý
và lọc.
SW là một phần của IS, IS còn bao gồm Data, phần cứng mà SW khum có.
Ngoài ra IS còn có thể đào tạo chuyển giao từ nghiệp vụ tay sang ứng
dụng CNTT.

- Vai trò của phần mềm:

- Hầu hết các hoạt động của trong lĩnh vực của các nước (nhất là các
nước phát triển) đều phụ thuộc vào PM
 - PM tạo ra sự khác biệt trong các tổ chức (Phong cách làm việc, năng
suất lao động, thương hiệu, …)
- Xu hướng: tin học hóa toàn bộ các hoạt động của hầu hết các lĩnh vực
- Con người ngày càng phụ thuộc vào PM
- Ví dụ…. (Amazon, Facebook, …)
- Các đặc trưng của sản phẩm phần mềm:
- Không mòn cũ nhưng thoái hóa theo thời gian (Không bị hỏng như
phần cứng/các thiết bị vật lý, môi trường sử dụng, nhu cầu thay đổi,
lỗi phát sinh do nâng cấp, …)
- Không được lắp ráp từ mẫu có sẵn (Không có danh mục chi tiết cho
trước, sản phẩm đặt hàng theo yêu cầu riêng)
- Phức tạp, khó hiểu, vô hình
- Luôn luôn thay đổi (thay đổi là bản chất của PM) (nghiệp vụ thay
đổi, nhu cầu con người thay đổi, lỗi phát sinh (do đảm bảo chất lượng
chưa tốt, …), Môi trường vận hành thay đổi (phần cứng, hệ điều hành))
- Được phát triển theo nhóm (yêu cầu kỹ năng khác nhau, nhu cầu bàn
giao nhanh)
- Phân loại (theo chức năng):
- Phần mềm hệ thống (điều hành hoạt động máy tính, thiết bị, chương
trình (hệ điều hành); trợ giúp các tiện ích (tổ chức tệp, nén, dọn đĩa))
- Phần mềm nghiệp vụ: trợ giúp các hoạt động nghiệp vụ khác nhau
tại các tổ chức/doanh nghiệp, …
- Phần mềm công cụ: hỗ trợ tự động hóa một/một số pha/bước trong
quá trình phát triển PM
- Phần mềm theo đơn đặt hàng (chiếm đa số, phát triển theo đơn đặt
hàng; 1 khách hàng + 1 công ty PM -> 1 SP duy nhất)
- Phần mềm dùng chung (thỏa mãn yêu cầu dùng chung của một số
lượng lớn người dùng)
- Các tiêu chí đánh giá chất lượng của một sản phẩm phần mềm

+ Về tính năng:

. Tính phù hợp: các chức năng phù hợp với nghiệp vụ
 -> Khảo sát 1 tập người dùng khác nhau xem có phù hợp không

. Tính chính xác: Về quy trình: theo các chuẩn

Về kết quả: output chính xác với từng input tương ứng

-> Viết test case

. Tính tương tác: khả năng tương tác với một số HT cụ thể

. Tính an toàn: (Về mặt vật lý lẫn logic) khả năng bảo vệ thông tin và dữ liệu của sản
phẩm phần mềm, sao cho người, hệ thống không được phép thì không thể truy cập, đọc
hay chỉnh sửa chúng

-> Sử dụng tools, pmem mô phỏng tấn công xem sức chịu đựng của pmem

+ Về tính tin cậy:

. Tính hoàn thiện: Ko đc phép sai, ko có lỗi

-> Sử dụng mô hình toán học để CM pmem ko có lỗi,…

. Khả năng chịu lỗi: Khi có lỗi pmem vẫn HĐ bth

. Khả năng phục hồi: Phục hồi lại hoạt động, khôi phục dữ liệu lquan đến lỗi

-> Đo tgian TB để xử lý 1 lỗi

+ Về tính khả dụng

. Tính dễ hiểu:

. Dễ học: người dùng tốn ít công sức, tgian để biết cách sd sản phẩm

. Có thể sd được

. Tính hấp dẫn

-> Khảo sát người dùng, theo 1 số tiêu chuẩn về UI, UX

+ Về tính hiệu quả: Tgian đáp ứng, sử dụng tài nguyên

-> Sd tools, pmem test

+ Khả năng bảo trì:

.Khả năng phân tích: có thể tìm những thiếu sót hay những nguyên nhân gây lỗi hoặc để
xác định những phần cần sửa

.Khả năng thay đổi: có thể chấp nhận một số thay đổi cụ thể trong quá trình triển khai

.Tính ổn định: tránh những tác động không mong muốn khi chỉnh sửa phần mềm

.Khả năng kiểm định: khả năng cho phép đánh giá được phần mềm chỉnh sửa

+ Tính khả chuyển: Có thể vận chuyển qua các môi trường vận hành khác nhau

- Tiến hóa phần mềm: Thay đổi là bản chất của PM

PM bị thay đổi khi nào và thay đổi như thế nào?
 – Một yêu cầu cũ bị sửa hoặc loại bỏ
– Một yêu cầu mới phát sinh
– Lỗi phát sinh
– Môi trường của PM thay đổi. Môi trường PM: Hệ điều hành, các hệ
thống thương tác, …
Thay đổi diễn ra trong quá trình phát triển và trong quá trình sử dụng (bảo
trì)
Nguyên nhân:
- Quá trình thu thập, phân tích và đặc tả yêu cầu có vấn đề
- Sức ép thời gian, làm ẩu, KH hết hợp tác, …
- Đảm bảo chất lượng có vấn đề
- Nhu cầu con người ngày càng cao và phức tạp
- Nghiệp vụ của các tổ chức cũng thường xuyên thay đổi/tái cấu trúc
- Môi trường PM thường xuyên thay đổi
- Vòng đời phát triển PM:

- Các thách thức trong quá trình phát triển PM

- Tiến bộ công nghệ nhanh chóng : Mỗi tiến bộ công nghệ là một may
mắn cho ngành công nghệ thông tin. Nhưng đồng thời, công nghệ
phát triển với tốc độ phi thường dẫn đến áp lực gia tăng cho các
chuyên gia phát triển phần mềm trong việc tận dụng các xu hướng
công nghệ sắp tới này trong phát triển sản phẩm phần mềm để đạt
được lợi thế vượt trội so với các đối thủ cạnh tranh và nổi bật trên thị
trường.
- Nhu cầu của khách hàng ngày càng tăng: Các dự án phần mềm
thường mang tính khái niệm và nhằm mục đích thiết kế và phát triển
 các sản phẩm phần mềm đáp ứng nhu cầu đa dạng của khách hàng.
Để phát triển ngay cả ứng dụng hoặc sản phẩm đơn giản nhất, các
nhà phát triển phải hiểu rõ ràng khái niệm kinh doanh cơ bản và
mang lại các tính năng cần thiết để đáp ứng nhu cầu ngày càng tăng
của khách hàng.
- Giới hạn thời gian: Phát triển phần mềm là một trò chơi thời gian. Các
nhà phát triển làm việc trong môi trường đầy áp lực và cố gắng hoàn
thành các yêu cầu của dự án trong các mốc thời gian nghiêm ngặt
và ít ỏi. Đây đặc biệt là một thách thức khi làm việc với các khách
hàng quốc tế trên nhiều múi giờ. Hạn chế về thời gian thường làm
giảm hiệu quả của các nhóm phát triển và cuối cùng dẫn đến các sản
phẩm phần mềm chất lượng tầm thường.
- Cơ sở hạ tầng / nguồn lực hạn chế: Một thách thức khác mà đa số
các công ty phát triển phần mềm phải đối mặt là thiếu nguồn lực
hoặc cơ sở hạ tầng CNTT để thực hiện các dự án một cách hiệu quả.
Điều này có thể có nghĩa là thiếu các công cụ phát triển phần mềm
hiệu suất cao, nền tảng máy tính mạnh mẽ, kiến trúc lưu trữ dữ liệu
kém hiệu quả hoặc mạng và kết nối không phù hợp. Những trở ngại
như vậy làm giảm năng suất và hiệu suất của các nhóm phát triển
phần mềm và ảnh hưởng đến kết quả chung.
- Yếu tố đánh giá Phần mềm tốt:
- Khả năng bảo trì: Phần mềm nên được viết theo cách để nó có thể
phát triển để đáp ứng nhu cầu thay đổi của khách hàng. Đây là một
thuộc tính quan trọng vì thay đổi phần mềm là một yêu cầu tất yếu
của một môi trường kinh doanh đang thay đổi
- Độ tin cậy và bảo mật: Tính chất mềm đáng tin cậy bao gồm cả một
loạt các đặc trưng, an ninh và an toàn. Phần mềm đáng tin cậy không
nên có thiệt hại vật lý hay kinh tế khi hệ thống thất bại. Những người
dùng xấu không thể truy cập hoặc làm hỏng hệ thống
- Hiệu quả: Phần mềm không được sử dụng lãng phí tài nguyên hệ
thống như bộ nhớ và quy trình hoặc chu trình. Do đó, hiệu quả bao
gồm khả năng đáp ứng, thời gian xử lý, sử dụng bộ nhớ, v.v.
- Khả năng chấp nhận: Phần mềm phải được chấp nhận đối với loại
người dùng mà nó được thiết kế. Điều này có nghĩa là nó phải dễ hiểu,
có thể sử dụng được và tương thích với các hệ thống khác mà họ sử
dụng.
- Chia thành 2 loại phần mềm: phần mềm hệ thống, phần mềm ứng dụng.
- Từng đối tượng quan tâm:
- Chủ đầu tư sẽ quan tâm chi phí bao nhiêu để phát triển phần mềm
hiệu quả
- Người dùng sẽ quan tâm đến chức năng của phần mềm, tính an toàn,
dễ tiếp cận và sử dụng
- Nhà phát triển (developer) quan tâm đến khả năng dễ bảo trì của
phần mềm.
- ISO 9126:
 SE_CS_2021 - Homework - Week 2 - NgoXuanBach
- Thách thức: chưa có một phương pháp đủ tốt, đủ tối ưu
- Dự án phần mềm thất bại khi không đạt được chức năng yêu cầu đã cam
kết, kinh phí hoặc thời gian vượt quá ngưỡng cho phép.
- Quy trình phát triển phần mềm:

Chapter 2: Các mô hình

- https://www.overleaf.com/project/603b6e60c1de700661bb3248 (4 mô hình
đầu)
-
-
-
 Component-based SW development (CBSD)
nó là một mô hình của chiến lược Reuse-oriented software engineering
Hướng đến phát triển các ứng dụng lớn với chất lượng cao bằng cách sử dụng lại các thành phần
phần mềm đã được phát triển trước đây (và đã được vận hành trong các hệ thống hiện tại, ta gọi là
well defined component). Mỗi thành phần sẽ có đặc tả đầy đủ, có CLC.
Bằng cách tiếp cận này, một sản phẩm được phát triển bằng cách ghép nối các thành phần sẵn có.
Đây là cách phát triển nhanh, sử dụng lại tối đa, có chất lượng cao (vì các thành phần có chất lượng
cao).
- Thành phần là 1 đơn vị phần mềm đóng gói một tập các dịch vụ có lquan đến nhau, giao tiếp với
nhau bằng giao diện (well-defined interface). Các thành phần có đặc điểm: độc lập, có chất lượng
cao, tài liệu đầy đủ, đã đc vận hành ở các hệ thống.
*Ưu điểm
● pt nhanh, có clc (do thành phần có clc)
● Tận dụng được reuse (sử dụng lại), giảm thời gian, chi phí phát triển
● Có thể mở rộng
● Bảo trì thuận lợi (thành phần có tài liệu đầy đủ)

- Rational Unified Process (RUP)

Tiến trình này hoạt động xoay quanh việc lặp tiến trình (iteration) và được tổ chức qua 4 pha cùng
các hoạt động tách biệt ở mỗi pha. Tuân theo incremental development
Tiến trình trải qua nhiều lần lặp (tạm gọi là những lần lặp lớn). Trong mỗi lần lặp lớn, tiến trình sẽ
tuần tự đi qua 4 pha tách biệt, đó là:
• Inception: Mục đích của pha này là thiết lập phạm vi (scope) cho dự án. Việc đầu tiên là xác định
được những thực thể (actors) bên ngoài (con người hoặc hệ thống khác) sẽ tương tác với hệ thống.
Từ đó đánh giá mức độ đóng góp của hệ thống đối với nghiệp vụ. Nếu đóng góp là không đáng kể thì
dự án có thể sẽ bị hủy. Cụ thể, pha này xác định:
+ Major users (actors) -> use-case model
+ Initial architecture (System + sub-system)
+ Risk, cost dự kiến
• Elaboration: Mục đích của pha này là lập kế hoạch, tạo được khung kiến trúc cho hệ thống và xác
định các rủi ro. Đầu ra của pha này là có được mô hình yêu cầu (requirements model), kiến trúc cơ
bản và kế hoạch phát triển cho phần mềm. (almost complete UC model, test cases)
• Construction: Là giai đoạn hệ thống được thiết kế, xây dựng và kiểm thử. Các phần của hệ thống
được phát triển song song và được tích hợp. Đầu ra của pha này là một chương trình vận hành được
và các tài liệu liên quan, sẵn sàng cho việc chuyển giao đến khách hàng.
• Transition: Là pha chuyển giao sản phẩm cho người dùng. Pha này bao gồm việc đưa phần mềm từ
môi trường phát triển của chúng ta sang môi trường vận hành thực tế của khách hàng và đảm bảo
việc phần mềm vận hành tốt trên môi trường đó. (đào tạo ng dùng, hỗ trợ KH)
Cách lặp thứ hai là những lần lặp nhỏ hơn ở trong các pha của một lần lặp lớn. Mỗi phiên bản sẽ có
thêm các tính năng được phát triển dựa trên độ ưu tiên của UC. Các tính năng được định nghĩa theo
từng ca sử dụng (use case). Thông thường, các tính năng quan trọng và có rủi ro cao sẽ được lên kế
hoạch và phát triển trước.

Mỗi pha trong RUP đều trải qua 6 hoạt động chính và 3 hoạt động hỗ trợ:
• Business Modelling: Các tiến trình nghiệp vụ được mô hình hóa qua việc sử dụng các ca sử dụng
nghiệp vụ (business use cases).
• Requirements: Các tác nhân (actors) được xác định và các ca sử dụng được mô tả chi tiết để mô
hình hóa các yêu cầu của hệ thống.
• Analysis and Design: Mô hình thiết kế được tạo bằng các mô hình kiến trúc (architectural models),
mô hình thành phần (component models), mô hình đối tượng (object models) và mô hình tuần tự
(sequence models).
• Implementation: Các thành phần của hệ thống được cài đặt, phát sinh mã tự động từ thiết kế có thể
được áp dụng ở đây
• Testing: Kiểm thử được thực hiện lặp đi lặp lại cùng với hoạt động cài đặt. Kiểm thử mức hệ thống
được thực hiện sau khi đã hoàn thành việc cài đặt.
• Deployment: Sản phẩm được đem vào vận hành ở môi trường thực tế của khách hàng.
• Configuration & Change management: Hoạt động hỗ trợ việc quản lý sự thay đổi của hệ thống.
• Project management: Hoạt động hỗ trợ việc quản lý sự phát triển của hệ thống.
• Enviroment: Hoạt động hỗ trợ liên quan đến phát triển môi trường vận hành, bao gồm quy trình và
công cụ (tools).

Trong hình trên, các hoạt động được phân bố theo chiều dọc. Điều này có nghĩa là ở mỗi pha đều trải
qua một quy trình các hoạt động giống nhau. Tuy nhiên, điều khác nhau giữa các pha là ở mức độ
của từng hoạt động, các pha khác nhau sẽ có mức độ của từng hoạt động khác nhau. Ví dụ: Ở pha
Inception, các hoạt động như Business Modeling và Requirements sẽ được chú trọng, do đó sẽ có
mức độ cao; còn ở pha Elaboration, hoạt động Analysis & Design được đẩy 4 mạnh hơn nên có mức
độ cao hơn trong khi các hoạt động Business Modeling và Requirements sẽ có mức độ giảm dần.
- Agile
Là 1 phương pháp luận, tập các nguyên tắc thực hành cho pt pmem
Scrum, XP,… là các quy trình pt pmem tuân theo Agile
Tuyên ngôn của Agile:
+ Cá nhân và tương tác hơn là quy trình và công cụ
+ Pmem chạy tốt hơn là tài liệu đầy đủ
+ Cộng tác với KH hơn là đàm phán hợp đồng
+ Phản hồi với thay đổi hơn là bám sát kế hoạch
-> Nhấn mạnh vế trái hơn vế phải nhưng ko có nghĩa là loại bỏ hoàn toàn vế phải
Cá nhân và tương tác: Những nhân tố cốt lõi tgia làm ra sp -> Tự tổ chức, tự quản lý, duy trì động
lực, đảm bảo môi trường thuận lợi nhất cho quá trình tương tác giữa các cá nhân
Pmem chạy tốt: Về phía KH, 1 sp chạy tốt có ích hơn rất nhiều 1 đống tài liệu mà ko có nhiều gtri,
Agile khuyến nghị chuyển giao sp ngay từ pha đầu tiên
Cộng tác với KH: KH cùng tgia vào trong quá trình pt sp -> đảm bảo t/m KH và đáp ứng đc thay đổi
Phản hồi với thay đổi: Phù hợp với MT đầy biến động, thay đổi
*Ưu điểm
● Đáp ứng được thay đổi
● Thỏa mãn KH tốt
*Nhược điểm
● KH phải tham gia toàn bộ tgian với đội pt
● Các thành viên cộng tác tốt
● Xếp thứ tự ưu tiên cho yêu cầu là khó
● Áp lực về lịch chuyển giao sp -> Khó XD đc pmem có cấu trúc tốt, đơn giản, dễ hiểu
*Sử dụng
● Các sp vừa và nhỏ được pt để bán
● Các sản phẩm phức tạp
● Sản phẩm yêu cầu an ninh an toàn cao

Scrum
Là thành viên của họ Agile, XD dựa trên thuyết thực nghiệm (mọi tri thức đều đến từ kinh nghiệm đã
trải qua, dựa trên những gì mình hiểu biết) -> Giảm thiểu rủi ro, tăng tính chính xác
Nhóm Scrum liên tục thăm dò và điều chỉnh hoạt động của mình để tối ưu hóa gtri sản phẩm
3 trụ cột: Minh bạch, thanh tra, thích nghi
Minh bạch: tất cả khía cạnh quan trọng của tiến trình phải được hiển thị rõ ràng cho tất cả
mng có lquan đến quá trình pt sp -> Giảm rủi ro, tăng tin cậy, nâng cao chất lượng, chính xác trong
qđ
Thanh tra: Thanh tra tạo tác và tiến độ -> phát hiện vấn đề ngoài ý muốn
Thích nghi: Vấn đề ko thể chấp nhận/ ý tưởng mới -> điều chỉnh quy trình, tài liệu
-
-
Use-case Diagram
- Class Diagram:
 ● Class diagram mô tả kiểu của các đối tượng trong hệ thống và các loại
quan hệ khác nhau tồn tại giữa chúng.
● Là một kỹ thuật mô hình hóa tồn tại ở tất cả các phương pháp phát triển
hướng đối tượng.
● Biểu đồ hay dùng nhất trong UML và gần gũi nhất với các lập trình viên.
● Giúp các lập trình viên trao đổi với nhau và hiểu rõ ý tưởng của nhau.
- Sequence Diagram:
Sequence Diagram là bản vẽ xác định câu chuyện hậu trường của một chức
năng. Câu chuyện hậu trường ở đây chính là sự tương tác giữa các nhóm
đối tượng, các thông điệp được gửi và nhận giữa các đối tượng cũng như
trình tự thời gian giữa những thông điệp đó.
Việc thực hiện các chức năng từ lúc nhận input, chạy vòng lặp, kiểm tra rồi
trả kết quả, theo một trình tự, có sự tham gia của các hàm, các đối tượng.
Và được trực quan hóa bằng bản vẽ chính là Sequence Diagram.
- Activity Diagram là bản vẽ tập trung vào mô tả các hoạt động, luồng xử lý
bên trong hệ thống. Nó có thể được sử dụng để mô tả các quy trình nghiệp
vụ trong hệ thống, các luồng của một chức năng hoặc các hoạt động của
một đối tượng
Thu thập và phân tích yêu cầu
•Mục đích của thu thập và phân tích yêu cầu
•Kỹ nghệ yêu cầu (requirements engineering) là quy trình xác định các dịch vụ hệ
thống mà khách hàng yêu cầu, cùng với các ràng buộc để phát triển và vận hành
các dịch vụ đó
•Các yêu cầu (requirements) là các mô tả về các dịch vụ và các ràng buộc đó
Yêu cầu (requirements): các mô tả (từ mức chung chung đến chi tiết) về các dịch
vụ hệ thống cùng với các ràng buộc
•Mục đích chính của yêu cầu (requirements)
–Cơ sở cho đề xuất/ đấu thầu hợp đồng
–Cơ sở cho lập hợp đồng (mức đặc tả chi tiết)
•Yêu cầu người dùng
–Ngôn ngữ tự nhiên
–Viết cho khách hàng
•Yêu cầu hệ thống
–Đặc tả chi tiết
–Xác định những gì cần được phát triển/cài đặt (một phần nội dung hợp đồng)
6
•Yêu cầu chức năng
–Các phát biểu về dịch vụ hệ thống cung cấp, cách hệ thống phản ứng với môi
trường và các hoạt động quan sát được của hệ thống trong các tình huống.
–Có thể bao gồm các phát biểu về những gì hệ thống sẽ không thực hiện.
- Mô tả các chức năng hay dịch vụ của hệ thống
- Yêu cầu chức năng mức người dùng thường bao gồm các phát biểu chung (ở
mức cao) về những gì hệ thống cần làm
- Yêu cầu chức năng mức hệ thống tập trung mô tả ở mức chi tiết hơn các dịch vụ
hệ thống
•Yêu cầu phi chức năng
–Ràng buộc về dịch vụ hay chức năng của hệ thống, chẳng hạn, ràng buộc về thời
gian hay ràng buộc về quy trình phát triển.
–Thường áp dụng cho tổng thể hệ thống, thay vì từng dịch vụ cụ thể
- Xác định các ràng buộc và các thuộc tính của hệ thống, chẳng hạn, ràng buộc
về độ tin cậy, thời gian phản hồi và các ràng buộc về lưu trữ.
- Các ràng buộc về quy trình phát triển như yêu cầu về mô hình quy trình, ngôn
ngữ và môi trường lập trình, phương pháp và công cụ …
- Yêu cầu phi chức năng đôi khi quan trọng hơn yêu cầu chức năng. Đôi khi nếu
chúng không được thỏa mãn, hệ thống sẽ trở thành vô dụng.
•Yêu cầu miền
–Các ràng buộc hệ thống xuất phát từ miền hoạt động
Tài liệu yêu cầu phần mềm là phát biểu chính thống về những gì cần phải đạt
được cho việc phát triển phần mềm
•Thường bao gồm (1) định nghĩa về các yêu cầu người dùng và (2) bản đặc tả các
yêu cầu hệ thống
•Đây không phải là tài liệu thiết kế. Nội dung thường tập trung vào câu hỏi “Cái gì”
thay vì “Như thế nào”.

Đặc tả yêu cầu Là quá trình tổng hợp và đưa các yêu cầu người dùng và hệ thống
vào tài liệu yêu cầu
•Yêu cầu người dùng phục vụ người dùng cuối và khách hàng
•Yêu cầu hệ thống chi tiết hơn và nhiều thông tin kỹ thuật hơn
•Là một phần hợp đồng phát triển hệ thống

Phân biệt đặc tả yêu cầu và thiết kế

- Đặc tả yêu cầu tập trung vào câu hỏi cái gì (what) làm rõ những gì hệ thống
cần làm.
- Thiết kế tập trung vào câu hỏi như thế nào (how), về cách tổ chức thực hiện
để đáp ứng các yêu cầu.
- Trong thực hành, hai hoạt động này thường đan xen nhau:
Các yêu cầu có thể được phát biểu dựa trên kiến trúc đề xuất.
Thiết kế cho hệ thống tương tác với các hệ thống có thể phát sinh
thêm các yêu cầu mới.
Việc sử dụng kiến trúc đặc thù để đáp ứng các yêu cầu phi chức năng
có thể thuộc về yêu cầu miền nghiệp vụ đó.
Một số dạng đặc tả yêu cầu:
- Ngôn ngữ tự nhiên: các yêu cầu được diễn đạt bằng ngôn ngữ tự nhiên và
được gắn với các chỉ số.
- Ngôn ngữ tự nhiên được cấu trúc: Yêu cầu được viết bằng ngôn ngữ tự nhiên,
dựa trên định dạng nào đó.
- Ngôn ngữ mô tả thiết kế: Sử dụng ngôn ngữ tựa ngôn ngữ lập trình để mô
tả hoạt động của hệ thống.
- Các ký pháp đồ họa: Sử dụng các biểu đồ đồ họa để bổ trợ cho các diễn đạt
ngôn ngữ tự nhiên
 - Đặc tả hình thức (toán học): Sử dụng ngôn ngữ, mô hình toán học để đặc tả
hoạt động hệ thống
Đặc tả bằng ngôn ngữ tự nhiên:
- Dùng ngôn ngữ tự nhiên cùng với các biểu đồ, bảng biểu
- Ưu điểm: dễ dùng, tự nhiên và phổ biến
- Hạn chế:
–nhập nhằng, hỗn tạp
–khó tách biệt yêu cầu chức năng và phi chức năng
–khó đảm bảo đồng thời tính chính xác và dễ đọc
- Một số chỉ dẫn
–Sử dụng các form/định dạng chuẩn
–Sử dụng thuật ngữ nhất quán
–Làm rõ (highlight) các điểm chính
–Tránh sử dụng thuật ngữ kỹ thuật
Ví dụ: Hệ thống sẽ chạy chức năng tự kiểm tra sau mỗi phút với các điều kiện
kiểm tra và các hành động tương ứng như mô tả trong Bảng 1. (Tự kiểm tra cho
phép phát hiện các lỗi về phần cứng và phần mềm để có thể gửi cảnh báo cho
người dùng)

Quy trình kỹ nghệ yêu cầu:

● Phụ thuộc vào miền ứng dụng, cá nhân liên quan và cách tổ chức phát triển
yêu cầu
● Hoạt động chung nhất cho các quy trình:
-Thu thập yêu cầu
-Đặc tả yêu cầu
-Thẩm định yêu cầu
-Quản lý yêu cầu
● Kỹ nghệ yêu cầu thường bao gồm các hoạt động lặp và các hoạt động
thường gối lên nhau, có thể nhìn theo hình xoắn ốc

Thu thập và phân tích yêu cầu:

•Đôi khi được gọi chung là thu thập hay khám phá yêu cầu (requirements
elicitation/discovery)
•Tìm hiểu về miền ứng dụng, các dịch vụ hệ thống cung cấp, và các ràng
buộc hoạt động hệ thống
•Các bên liên quan (người dùng cuối, người quản lý, kỹ sư vận hành bảo trì,
chuyên gia miền, …)

Các vấn đề của phân tích yêu cầu:

•Các bên liên quan không thực sự biết họ muốn gì
•Các bên liên quan diễn đạt các yêu cầu theo ngôn ngữ của họ => khó cho
trao đổi, giao tiếp
•Các bên liên quan có thể có các xung đột yêu cầu
•Các chính sách của đơn vị tổ chức có thể ảnh hưởng đến các yêu cầu hệ
thống
 •Các yêu cầu thường thay đổi trong quá trình phân tích yêu cầu. Người liên
quan mới có thể xuất hiện hoặc môi trường nghiệp vụ thay đổi.

Quy trình Thu thập và phân tích yêu cầu:

1)Khám phá yêu cầu
-Tương tác các bên liên quan
-Xác định các yêu cầu miền
2)Phân loại và tổ chức yêu cầu
-Nhóm gộp, cấu trúc hóa
3)Thương lượng, gán độ ưu tiên cho các yêu cầu
-Gán độ ưu tiên
-Giải các xung đột
4)Đặc tả yêu cầu

Một số kỹ thuật khám phá yêu cầu

•Kỹ thuật phỏng vấn: tương tác với các bên liên quan để thu thập thông tin.
Hỏi đáp một cách hình thức hoặc không hình thức với các bên liên quan
•Các kiểu phỏng vấn
-Phỏng vấn đóng
-Phỏng vấn mở
•Một số chỉ dẫn để phỏng vấn hiệu quả
-Tinh thần tiếp nhận và lắng nghe
-Hướng người được phỏng vấn tham gia tình huống được thiết
kế trước, sử dụng bảng câu hỏi, bản đề xuất yêu cầu, hoặc bản mẫu
hệ thống
•Thường kết hợp phỏng vấn đóng và mở
•Ưu điểm: cung cấp cái nhìn tổng quan về các bên liên quan khi thực
hiện và tương tác với hệ thống
•Một số hạn chế
-Người phân tích yêu cầu gặp khó khăn với các thuật ngữ và
tri thức chuyên biệt miền
-Một vài kiến thức miền không được phát biểu tường minh do
quá quen thuộc với chuyên gia miền
•Kỹ thuật dùng các kịch bản (scenarios): dựa vào các ví dụ cụ thể để thu
thập và phân tích
•Sử dụng các ví dụ và phản ví dụ trong thực tế về cách sử dụng hệ
thống
•Cung cấp các nội dung theo tình huống
-thời điểm bắt đầu
-dòng sự kiện thông thường
-dòng sự kiện bất thường
-quan hệ tương tranh giữa các hoạt động
-trạng thái kết thúc
•Kỹ thuật nghiên cứu nhân học (ethnography): dựa vào quan sát hoạt động
nghiệp vụ trong thực tế, là một kỹ thuật dựa vào kịch bản
Mô tả tập chức năng của hệ thống từ góc nhìn của người dùng
 Mô tả tương tác giữa tác nhân và hệ thống
Có thể mô tả bổ sung bằng biểu đồ hoạt động, tuần tự, …

Thẩm định yêu cầu

- Đảm bảo các yêu cầu sẽ xác định đúng hệ thống mà khách hàng mong đợi
- Là khâu quan trọng vì chi phí sửa lỗi yêu cầu tăng lên hàng trăm lần nếu
được phát hiện muộn
- Nội dung thẩm định:
- Hợp lệ (validity): Hệ thống cung cấp các chức năng hỗ trợ tốt nhất
cho nhu cầu khách hàng?
- Nhất quán (consistency): Có các yêu cầu xung đột/mâu thuận
không?
- Đầy đủ (completeness): Tất các các chức năng được khách hàng yêu
cầu đã được đề cập?
- Tính hiện thực (realism): Các yêu cầu có thể được cài đặt trong sự
ràng buộc về ngân sách và kỹ thuật?
- Kiểm chứng (verifiability): Các yêu cầu có thể được kiểm tra
(checked)?
- Một số kỹ thuật:
- Kiểm định yêu cầu: Kiểm tra, đánh giá và phân tích một cách thủ công
các yêu cầu.
- Làm bản mẫu: sử dụng mô hình thực thi được của hệ thống để kiểm
tra yêu cầu. (xem bài 3)
- Sinh ca kiểm thử: tạo ra các ca kiểm thử cho các yêu cầu để kiểm tra
tính kiểm thử được.

Kiểm định yêu cầu

- Diễn ra khi nào: trong quá trình đặc tả yêu cầu
- Ai kiểm tra đánh giá: các bên liên quan hợp đồng cùng tham gia
- Cách thức kiểm tra đánh giá: Hình thức hoặc phi hình thức, Đòi hỏi giao tiếp
tốt với người phát triển, khách hàng và người dùng cuối
- SRS (Software requirement specification): tài liệu đặc tả yêu cầu:
+ Là đầu ra của quá trình pitch và đặc tả yêu cầu

+ Là quá trình tổng hợp và đưa ra các yêu cầu người dùng và HT vào tài liệu yêu cầu (Yêu
cầu người dùng: phục vụ ng dùng cuối và KH; yêu cầu HT: chi tiết hơn và nhiều thông tin kỹ thuật
hơn)

+ Là một phần hợp đồng pt HT (có gtri pháp lý)

+ Một số dạng đặc tả yêu cầu: Ngôn ngữ TN, ngôn ngữ TN đc cấu trúc, ngôn ngữ mô tả
thiết kế, các ký pháp đồ họa,…
- Quy trình thu thập, phân tích và đặc tả yêu cầu

Thu thập yêu cầu -> Phân tích yêu cầu -> Đặc tả yêu cầu -> Thẩm định yêu cầu

+ Thường gồm các HĐ lặp và gối đầu lên nhau

- Các kỹ thuật thu thập yêu cầu: (Thường kết hợp nhiều KT)

+ Phỏng vấn: tương tác với các bên lquan để thu thập thông tin

. phỏng vấn đóng

. phỏng vấn mở

+ Dùng kịch bản: sd các ví dụ, phản ví dụ trong thực tế về cách sd HT

+ Ca sử dụng: Dựa vào kịch bản, mô tả chức năng của HT từ góc nhìn của ng dùng, mô tả
tương tác giữa tác nhân và HT

+ Nghiên cứu nhân học: Quan sát và phân tích các HĐ nghiệp vụ diễn ra trong thực tế
+ Sử dụng chuyên gia,…

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

Làm top-down, từ yêu cầu chung chung -> chi tiết

*Khi phân tích yêu cầu, ngoài yêu cầu của ng dùng, ta cần khảo sát rộng đến các HT khác sử
dụng dvu của HT pmem và HT pmem của ta có sử dụng dịch vụ của HT khác ko. (Các HT khác có
thể tồn tại hoặc chưa tồn tại)
- Đặc tả yêu cầu? làm tài liệu SRS, mô ta quả phân tích bằng các ngôn ngữ đặc tả yêu cầu: UML
+ ngôn ngữ tự nhiên

- Thẩm định yêu cầu

+ Đảm bảo các yêu cầu sẽ XĐ đúng HT mà KH mong đợi

+ Là khâu quan trọng vì chi phí sửa lỗi yêu cầu rất lớn nếu phát hiện muộn

+ ND ktra: Hợp lệ, nhất quán, đầy đủ, hiện thực, kiểm chứng

+ Một số kỹ thuật: Kiểm định yêu cầu (thủ công), làm bản mẫu, sinh ca kiểm thử
-> lặp đến khi tài liệu được các bên chấp nhận

Thiết kế kiến trúc

.
Định nghĩa kiến trúc phần mềm:(Len bass) Kiến trúc phần mềm của một hệ thống
là tập hợp các cấu trúc cần thiết để lý luận về hệ thống, bao gồm các phần tử
phần mềm, các mối quan hệ giữa chúng và các thuộc tính của cả hai ”

Vai trò kiến trúc phần mềm:

• Hỗ trợ cho giao tiếp giữa các bên liên quan
• Xác định các ràng buộc để thực hiện công việc
• Dự đoán chất lượng hệ thống
 • Nâng cao độ chính xác của công việc dự đoán và xây dựng hệ thống thời
gian system

Mẫu kiến trúc (architectural patterns): kiến trúc được sử dụng để giải quyết
một/vài vấn đề khi xây dựng hệ thống và đã được sử dụng ở nhiều hệ thống

Nguyên lý thiết kế:

•Phân tách các khía cạnh quan tâm (Separation of concerns): chia ứng dụng
thành các phần càng ít sự chồng chéo về chức năng càng tốt. Cố gắng hạn chế tối
đa sự tương tác giữa các thành phần nhằm có giảm sự phụ thuộc và tăng cường
sự kết dính (cohesion) trong từng thành phần
•Trách nhiệm đơn: Mỗi thành phần chỉ thực hiện một chức năng hoặc một
tập các chức năng gắn kết chặt chẽ
•Hiểu biết tối thiểu: Các thành phần không cần biết chi tiết bên trong của
các thành phần khác
•Không lặp lại: Mỗi một chức năng chỉ được hiện thực hóa bởi một thành
phần
•Hạn chế thiết kế trước: chỉ thiết kế khi cần và có đủ thông tin

Các mối quan tâm:

•Kiểu ứng dụng
•Chiến lược triển khai
•Các công nghệ phù hợp
•Các thuộc tính chất lượng
•Một số các yếu tố “cắt ngang”

Thiết kế kiến trúc

•Đầu vào: yêu cầu chức năng và phi chức năng, các ràng buộc
•Đầu ra: bản thiết kế kiến trúc
•Là quá trình lặp với 5 bước chính:
1.Xác định mục tiêu: Thiết kế kiến trúc để làm gì? Cho ai? Các ràng
buộc là gì? =>Phạm vi và thời gian thực hiện
2.Xác định các hoạt cảnh sử dụng chính:
•Một hoạt cảnh là sự tổng quát của nhiều ca sử dụng (use case) tương
tự
•Các hoạt cảnh chính
–Có ảnh hưởng lớn, được sử dụng nhiều
–Thể hiện sự “đánh đổi” giữa các thuộc tính chất lượng
3.Xác định tổng quan về ứng dụng
•Xác định kiểu ứng dụng
•Xác định các ràng buộc triển khai
•Các kiểu kiến trúc có thể sử dụng
•Các công nghệ liên quan
4.Xác định các vấn đề chính
•Thuộc tính chất lượng: performance, extensibility,…
 •Khía cạnh quan tâm chung: authentication, authorization,
caching, exception handling,…
5.Xác định các giải pháp chính
•Là bản thiết kế kiến trúc ở mức cao
•Bao gồm cả kiểu ứng dụng, kiến trúc triển khai, kiểu kiến trúc,
công nghệ được lựa chọn, thuộc tính chất lượng, các khía cạnh khác
•Kiểm tra các yêu cầu, ràng buộc

+Client – server architecture

. Cho hệ thống phân tán với hai thành phần riêng biệt Khách (client) và Chủ (server)
. Server cung cấp các dịch vụ, client yêu cầu các dịch vụ
. Một số biến thể
– Client-Queue-Client: cho phép các clients có thể giao tiếp thông qua hàng đợi. Server chỉ đóng vai
trò là hàng đợi để chứa dữ liệu. Còn được gọi là kiến trúc hàng đợi bị động
– Peer-to-Peer: Client và server có thể đổi vai trò cho nhau
– Application server: một dạng khách/chủ đặc biệt với phía chủ chứa các ứng dụng và dịch vụ
+ Kiểu phân lớp (Layer architecture)
. Nhóm các chức năng có liên quan chặt chẽ vào chung một lớp
. Các lớp được sắp xếp chồng lên nhau
. Chỉ lớp trên mới sử dụng chức năng của lớp dưới
Ưu điểm: Chỉ ra đc tương tác giữa các tầng
Nhược: Chia quá nhiều lớp -> Giảm hiệu năng (Gọi từ trên xuống dưới)

+ Pipe and filter architecture (Kiểu ống dẫn và bộ lọc)

. Thể hiện tương tác trong thời gian chạy
. Dữ liệu truyền qua các ống dẫn để đến và được xử lý ở bộ lọc
Ưu: Mô tả đc chi tiết các tương tác giữa các thành phần
+ Bus architecture
. Tương tác giữa các thành phần trong HT đc thực hiện bằng cách truyền thông điệp trên 1
bus chung
Ưu: Hiệu năng tốt

- Thuộc tính đánh giá

Thiết kế giao diện người dùng

- Khái niệm: UI (User interface): giao diện mà người dùng nhìn thấy và tương tác với
pmem

UX (User experience): trải nghiệm người dùng, những yếu tố MT, HĐ của ng dùng

Tầm quan trọng của thiết kế giao diện người dùng

•Người dùng khai thác các tính năng của hệ thống thông qua giao diện người
dùng
•Người dùng thường đánh giá về hệ thống bằng cách đánh giá UI hơn là đánh
giá về tính năng
•Thiết kế UI tồi
–Có thể làm cho người dùng gây ra lỗi
–Có thể là lý do dẫn đến việc phần mềm không bao giờ được sử dụng.

Đầu vào, đầu ra của thiết kế UI

•Đầu vào
 –Tài liệu yêu cầu (e.g. mô tả chi tiết ca sử dụng)
•Kịch bản các hành động của người dùng
•Phản hồi của hệ thống với người dùng
•Đầu ra
–Kịch bản người dùng tương tác với phần mềm thông qua giao diện
–Bố trí màn hình hiển thị

Yêu cầu của UI với con người

•UI nên được thiết kế sao cho phù hợp với kỹ năng, kinh nghiệm và sự mong
muốn của người dùng
•Khả năng nhớ của con người là có hạn
–Tối đa 7 mục thông tin cần người dùng ghi nhớ
•Con người có thể có nhầm lẫn
–Thông báo lỗi hợp lý
•Người dùng có thể có trình độ, kỹ năng khác nhau
–Khi thiết kế không nên chỉ nhắm vào một đối tượng người dùng cá biệt
•Người dùng có thể có các sở thích khác nhau
–Có người thích sự sôi động, nhiều màu sắc, người khác thích sự đơn giản.

Các bước
•Phân tích người dùng
–Người dùng đưa dữ liệu vào như thế nào
–Hệ thống cung cấp và biểu diễn dữ liệu ra cho người dùng như thế nào
•Thiết kế giao diện
–Làm bản mẫu
–Sử dụng các phương pháp mô tả giao diện.
•Xây dựng giao diện
•Thẩm định giao diện

Nguyên tắc thiết kế UI

•Giao diện thân thiện với người dùng
–E.g., sử dụng các thuật ngữ, khái niệm hướng người dùng chứ không dùng
khái niệm thường sử dụng với máy tính.
•Nhất quán
–Các thứ tương tự nhau nên hoạt động theo cách giống nhau (e.g., các
dòng lệnh/các thực đơn nên có cùng định dạng, cùng kiểu)
•Không nên gây sự bất ngờ lớn cho người dùng
–E.g., người dùng nên dự đoán trước được các tương tác của những chức
năng tương tự nhau.
•Khả năng phục hồi
–Cho phép người dùng quay về trạng thái trước khi gây ra lỗi (e.g., undo,
xác nhận trước khi xóa, …)
•Có hướng dẫn người dùng (help, online manual)
•Hướng tới đa dạng người dùng

- Process: Build -> Design -> Test

- Người dùng khai thác các tính năng của HT thông qua giao diện

- Ng dùng thường đánh giá về HT bằng cách đánh giá UI hơn là đánh giá về tính năng

- UI tồi -> ng dùng gây ra lỗi, pmem ko baoh đc sd

- Đầu vào: Tài liệu yêu cầu (SRS), kịch bản các HĐ ng dùng, phản hồi của HT với ng dùng

- Đầu ra: Kịch bản ng dùng tương tác với pmem qua giao diện, bố trí màn hình hợp lý

- 2 yếu tố cần xem xét khi thiết kế UI: ng dùng đưa dữ liệu/ thông tin vào HT ntn, HT cung cấp và
biểu diễn dữ liệu ra ntn

- Đánh giá: Đo tính dễ dùng:

+ Tgian học, tốc độ thực hiện (ng dùng thực hiện công việc của họ nhanh)

+ Tỷ lệ mắc lỗi khi sd (+ tgian khắc phục lỗi)

+ Nhớ được
+ Hài lòng chủ quan

UML
Với UML, hai loại mô hình thiết kế sẽ được xây dựng
–Tĩnh: thể hiện cấu trúc tĩnh của hệ thống (các lớp đối tượng và quan hệ
giữa chúng)
– Động: thể hiện sự tương tác giữa các đối tượng trong hệ thống
Trong giai đoạn đầu của quá trình thiết kế, 3 mô hình có thể sử dụng:
–Mô hình cấu trúc (thể hiện các nhóm lớp đối tượng có liên quan)
–Mô hình tuần tự (thể hiện sự tương tác giữa các đối tượng)
–Mô hình máy trạng thái (thể hiện sự chuyển trạng thái của từng đối
tượng)

Mẫu thiết kế (Design Pattern)

•Là các thiết kế được sử dụng bởi nhiều người, trong nhiều ứng dụng, và đã
được xác nhận là thiết kế tốt
•Thường được miêu tả
–Tên mẫu thiết kế
–Vấn đề cần xử lý (lúc nào mẫu sẽ được ứng dụng)
–Giải pháp (nội dung chính của mẫu)
–Kết quả đạt được

Implement
Implementation = triển khai thiết kế chi tiết thành chương trình
Sản phẩm phần mềm tốt, hiệu quả kinh tế cao
- Hạn chế tối đa xảy ra lỗi
- Mã nguồn dễ bảo trì: dễ hiểu, dễ sửa lỗi được, nâng cấp – thay đổi dễ dàng.
 - Khả năng tái sử dụng cao
=>Kỹ thuật lập trình tốt, hiệu quả

Các yêu cầu viết mã nguồn chương trình

Kỹ thuật lập trình chuyên nghiệp
•Tuân theo các chuẩn viết mã nguồn (coding styles, coding convention,
programming styles)
•Các chuẩn quy định do Ngôn ngữ lập trình, do Công ty
Kỹ thuật lập trình hiệu quả
•Dễ dàng bảo trì: dễ hiểu, dễ sửa lỗi
•Khả năng tái sử dụng cao: nâng cấp, thay đổi :Chú thích rõ ràng, đầy đủ
•Sử dụng các cấu trúc an toàn
•bắt lỗi, xử lý ngoại lệ
•mẫu thiết kế

Tái sử dụng mã nguồn

•Tái sử dụng các thành phần phần mềm (components) định nghĩa trước
–Tránh trường hợp “Phát minh lại bánh xe”
–Sử dụng những đoạn mã đã được thẩm định chất lượng
•Đặc điểm của phần mềm để tái sử dụng
–Phân chia mô-đun
–Có tính đóng gói
•Viết mã nguồn để tái sử dụng
–Tạo thư viện phần mềm
–Lập trình chung (generic programming)
–Phần mềm sinh mã tự động (generators)

KIỂM THỬ
- Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra
lỗi. Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác,
đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề
đã đặt ra. Kiểm thử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập
về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi
thực thi phần mềm. Là hoạt động chủ chốt nhằm đánh giá chất lượng. Có
thể chỉ ra lỗi, không thể khẳng định không còn lỗi Có thể khẳng định hết lỗi
bằng kiểm thử vét cạn, nhưng cách này không khả thi trên thực tế. Một
kiểm thử thành công là một kiểm thử phát hiện ra lỗi
- Verification and Validation
Verification (kiểm chứng)
Kiểm tra sản phẩm có được cài đặt đúng thiết kế không?
Phát hiện lỗi lập trình so với thiết kế
Validation (Thẩm định)
Kiểm tra xem sản phẩm có đáp ứng yêu cầu KH không? (chức năng
và phi chức năng)
Tìm lỗi phân tích thiết kế
Verification -> Validation (V&V)
•V&V tĩnh:
 –Không thực thi/chạy chương trình
–Xét duyệt yêu cầu, thiết kế, mã nguồn
–Tiến hành ở mọi giai đoạn phát triển PM
–Khó đánh giá tính hiệu quả của PM
•V&V động (Kiểm thử PM)
–Thực thi/chạy chương trình
–Là cách duy kiểm tra các yêu cầu phi chức năng
- Các hoạt động kiểm thử”

- Bộ kiểm thử tốt

Chạy các ca kiểm thử với chương trình P
–Bao phủ một số yêu cầu của P;
–Bao phủ một phần chức năng của P
–Bao phủ một phần trong cấu trúc của P
=> Tiêu chuẩn bao phủ sẽ định hướng thiết kế các ca kiểm thử
Bộ kiểm thử tốt: đạt 100% tiêu chuẩn bao phủ (cho trước)
- Kiểm thử hộp đen: Còn gọi là kiểm thử hàm, kiểm thử chức năng
- Là một phương pháp kiểm thử phần mềm mà việc kiểm tra các chức
năng của một ứng dụng không cần quan tâm vào cấu trúc nội bộ hoặc
hoạt động của nó. Tập trung vào hành vi vào/ra. Với đầu vào đã biết ra có
thể đoán/tính đầu ra, rồi kiểm tra chương trình có tạo kết quả như ta
đoán/tính.
Không thể kiểm thử hết các bộ dữ liệu đầu vào
- Bài toán đặt ra là giảm số lượng ca kiểm thử bằng việc chia không gian
đầu vào thành các miền tương đương
Sau đó chọn một ca kiểm thử từ mỗi miền tương đương này.
- Kiểm thử hộp trắng: Còn gọi là kiểm thử cấu trúc, kiểm thử logic, là
phương pháp thử nghiệm phần mềm, trong đó các thiết kế, cấu trúc giải
thuật bên trong, và việc thực hiện các công việc đều được biết đến
 - So sánh kiểm thử hộp trắng và hộp đen:

Trắng Đen

- Các kỹ thuật kiểm thử hộp đen:

Phân tích giá trị biên
+ Các lỗi thường xảy ra ở các giá trị biên/ cận biên của các biến đầu vào của chg trình
Kiểm thử GTB để phát hiện các lỗi này
+ Lấy 5 ca kiểm thử cho mỗi biến: max, min, max-, min+, normHàm n biến -> Có 1+4n ca
kiểm thử
Ưu điểm:
. Hiệu quả khi các biến của hàm là độc lập, ko có QH ràng buộc lẫn nhau
. Đơn giản và có thể sinh tự động các ca kiểm thử
Nhược:
. Khi các biến có QH phụ thuộc nào đó thì dễ tạo ra các ca kiểm thử ko hợp lý
 . KTGTB cũng ko quan tâm đến tính chất, đặc trưng của hàm, đồng thời cũng ko xét
đến ngữ nghĩa của biến hay QH giữa các biến.
Phân hoạch tương đương
+ Chia miền dữ liệu đầu vào thành các miền con sao cho các giá trị trong mỗi miền con có tđ
tương tự nhau với chg trình cần kiểm thử
+ Các miền con ko rỗng, ko giao nhau, thuộc miền dữ liệu đầu vào
Ta lấy ngẫu nhiên 1 giá trị bất kỳ trong mỗi miền con để XD bộ kiểm thử -> Các ca kiểm
thử của 1 miền con cùng gây lỗi/ cùng cho KQ đúng / cùng cho KQ sai tương tự nhau
+ Việc xđ các lớp tương đương thực hiện bằng cách: Phân tích đặc tả của chg trình đặc biệt
là các thông tin về miền dữ liệu của các biến đầu vào và MQH giữa các đầu vào và ra của
chg trình

-
Quản lý dự án
- Khái niệm dự án, dự án CNTT, dự án pmem

+ Dự án: Tập các công việc được thực hiện bởi 1 nhóm có chuyên môn. Tạo ra 1 sp/ dịch vụ
duy nhất. Sử dụng nguồn lực dự kiến (tgian, kinh phí, nhân lực,…). Được thực hiện trong MT
đầy biến động
+ Dự CNTT và dự án pmem
Dự án CNTT Dự án phần mềm
+ Sp: 1 Hệ thống thông tin + Sp: 1 phần mềm/ dịch vụ phần mềm
+ Cty mới, chưa có dữ liệu, quy trình nghiệp vụ, + Đã có nền tảng về cơ sở hạ tầng, dữ liệu, quy
cở sở hạ tầng,… -> Phải xây dựng cả HTTT trình,… -> Chỉ cần XD phần mềm

- Các tiêu chí đánh giá 1 dự án

+ Đng 1: Thỏa mãn phạm vi (Scope), thời gian (Time), kinh phí (Cost)
. Scope: Những việc cần làm và ko cần làm để đạt đc mục tiêu dự án
. Cost: Đo bằng ngày công (công/ngày, men/day)
. Time: Tgian hoàn thành sp
⇨ Tỉ lệ với nhau (Hình tam giác đều, zoom ra zoom vào)*
+ Đng 2: Thỏa mãn KH, chủ đầu tư
+ Đng 3: Tất cả các bên lquan đều hài long
- Khái niệm qly dự án: Là lập kế hoạch và thực hiện các công việc theo đúng kế hoạch đã lập
- Tại sao phải qly dự án:
+ Tăng khả năng thành công của dự án, giảm thiểu rủi ro
+ Đảm bảo có 1 KH đúng đắn để thực hiện các mục tiêu của dự án
+ Đảm bảo chất lượng của công việc đg đc triển khai và thực hiện đúng như kỳ vọng
+ KH có thể theo dõi đc những gì bạn thực hiện có đúng vs mục tiêu ban đầu
+ Học đc từ những thành công và thất bại trong QK
- Quy trình qly dự án
- Các bên tham gia dự án

- 10 miền tri thức trong qly dự án

 + Intergration: Qly 9 miền tri thức trên trong 1 dự án
*Qly dự án là quá trình đạt đc đa mục tiêu (thỏa mãn scope, time, cost, …) -> Qly dự án là qly tích
hợp