󾠮

Module 1: Introduction
Phần mềm

Sản phẩm phần mềm là phần mềm và tài liệu kèm theo được sản xuất và được thể hiện hay lưu
trữ ở bất kỳ một dạng vật thể nào, có thể được mua bán hoặc chuyển giao cho đối tượng khác
khai thác, sử dụng.

Khái niệm: Sản phẩm phần mềm & Hệ thống thông tin
Sản phẩm phần mềm:

Chương trình máy tính

Mã nguồn

Mã máy

Cấu trúc dữ liệu

Bộ nhớ trong - Làm việc

Bộ nhớ ngoài - Lưu trữ

Tài liệu

Tài liệu kỹ thuật - Phát triển và bảo trì

Tài liệu đào tạo, hướng dẫn sử dụng

Hệ thống thông tin

Bao gồm phần cứng, phần mềm, dữ liệu, thủ tục và chính con người

Nhiều yếu tố có mối liên hệ mật thiết với nhau, cùng làm nhiệm vụ thu thập, xử lý, lưu trữ và phân phối thông tin,
dữ liệu; cung cấp một cơ chế phản hồi để đạt được một mục tiêu định trước.

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

Phần mềm tham gia vào hầu hết các hoạt động trong mọi lĩnh vực của các nước trên toàn thế giới, đặc biệt là các
nước phát triển

Phần mềm tạo ra sự khác biệt trong các tổ chức, bao gồm phong cách làm việc hiện đại và tự động hóa hơn, năng
suất lao động được tối ưu, giảm thiểu đáng kể…

Với 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, phần mềm đóng vai trò vô cùng quan trọng
trong cuộc sống con người ngày nay, và con người ngày càng phụ thuộc vào phần mềm.

Đặc trưng của phần mềm

Không mòn cũ nhưng thoái hóa theo thời gian

Không được lắp ráp từ mẫu có sẵn

Phức tạp, khó hiểu, vô hình (trừu tượng)

Luôn luôn thay đổi - bản chất của phần mềm

Được phát triển theo nhóm, do nhiều người tham gia phát triển

Phân loại phần mềm

Phần mềm hệ thống

Phần mềm nghiệp vụ

Phần mềm công cụ

Phần mềm theo đơn đặt hàng

Phần mềm dùng chung

Module 1: Introduction 1
 Tiêu chí chất lượng
Tính năng Tính khả dụng Khả năng bảo trì

Tính phù hợp Tính dễ hiểu Khả năng phân tích

Tính chính xác Tính dễ học Khả năng thay đổi

Tính an toàn Khả năng vận hành Tính cân bằng

Tính tương tác Tính hấp dẫn Khả năng kiểm định

Tính tin cậy Tính hiệu quả Tính khả chuyển

Tính hoàn thiện Tiết kiệm thời gian Khả năng tương hợp

Khả năng sửa lỗi Sử dụng tài nguyên hợp Khả năng cài đặt
lý
Khả năng phục hồi Khả năng chung sống

Khả năng thay thế

Tiến hóa phần mềm

Thay đổi là bản chất của phần mềm.

Phần mềm được thay đổi trong quá trình phát triển và trong quá trình sử dụng.

Nguyên nhân thay đổi

Quá trình thu thập, phân tích và đặc tả yêu cầu có vấn đề

Đả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

Môi trường phần mềm thường xuyên thay đổi

Thách thức đặt ra từ tiến hóa

Tăng chi phí cho quá trình phát triển

Tăng chi phí cho doanh nghiệp trong quá trình bảo trì

Phát sinh nhiều vấn đề lớn trong kỹ thuật, ứng dụng,…

Công nghệ phần mềm

Ngành công nghiệp liên quan đến mọi khía cạnh của việc phát triển phần mềm

Khái niệm kỹ nghệ

Ứng dụng lý thuyết, phương pháp, công cụ một cách chọn lọc vào xây dựng phần mềm

Cố gắng tạo ra các giải pháp giải quyết vấn đề ngay cả khi không có lý thuyết, công cụ

Tổng quan về SE
Mục tiêu:

Chất lượng cao, đủ các tính năng và dễ dùng

Thời gian phát triển ngắn

Chi phí phát triển “thấp”

Được ứng dụng, trở thành một ngành của các nền kinh tế

Là quá trình tích hợp gồm:

Thủ tục (Procedures): Quy trình quản lý & phát triển

Phương pháp (Methods): Cách làm cụ thể để xây dựng phần mềm

Công cụ (Tools): Trợ giúp các phương pháp, bao gồm CASE - các công cụ trợ giúp các công đoạn khác nhau trong
tiến trình phát triển phần mềm

Module 1: Introduction 2
 → Nhằm tạo ra phần mềm hiệu quả với các ràng buộc cho trước

Các giai đoạn chung nhất của phát triển

Lập kế hoạch dự án

Thu thập yêu cầu sơ bộ

Ước lượng sớm

Lập kế hoạch

Phân tích, đặ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

Phát triển

Thiết kể

Triển khai, cài đặt

Kiểm thử

Viết tài liệu

Tiến hóa

Sửa lỗi, làm thích nghi

Nâng cấp, bổ sung

Thách thức phát triển phần mềm

Không có cách mô tả rõ ràng định nghĩa yêu cầu của người dùng, sau khi bàn giao sản phẩm dễ phát sinh trục trặc.

Những phần mềm quy mô lớn khó đáp ứng kịp thời nhu cầu thay đổi của người dùng.

Nếu không có phương pháp luận thiết kế nhất quán mà thiết kế theo cách riêng thì sẽ suy giảm chất lượng phần mềm
do phụ thuộc nhiều vào con người.

Nếu coi thường việc lập trình hơn thiết kế → giảm chất lượng phần mềm

Nếu coi thường việc tái sử dụng phần mềm → giảm năng suất lao động, …

Module 1: Introduction 3
 󾠯
Module 2: Process Models

I. Định nghĩa tiến trình và mô hình tiến trình

Tiến trình (software process): tập hợp các hoạt động để tạo ra phần mềm, hay còn gọi là quy trình phát triển phần mềm,
thường gồm 4 bước cơ bản

Đặc tả Specification

Thiết kế & Cài đặt Design & Implementation

Thẩm định Validation

Cải tiến (Tiến hóa) Evolution

Mô hình tiến trình (process model): thể hiện trừu tượng của tiến trình

Thác nước Waterfall Phân tách các giai đoạn đặc tả và phát triển

Tiến hóa Evolutionary Development Đặc tả, phát triển và kiểm định xen kẽ nhau

Component-based Software Hệ thống kết hợp các thành phần phần

Thành phần
Engineering mềm có sẵn

Thác nước (Waterfall):

Các giai đoạn được chia ra hoạt động như một chuỗi chu trình tuyến tính, kết quả từng pha sẽ được truyền xuống
cho những bước phát triển tiếp theo.

Phân tích & Xác định yêu cầu ↔ Thiết kế ↔ Cài đặt và Kiểm thử đơn vị ↔ Tích hợp và Kiểm
thử hệ thống ↔ Vận hành và bảo trì

Pros Cons Explanation

Khi tài liệu được làm tốt, vấn đề bảo trì sẽ

dễ dàng và hiệu quả hơn do các giai đoạn
Bảo trì thuận lợi
thành phần được phân tách rạch ròi và
chính xác

Do các sai sót phát hiện muộn đều yêu cầu

nhà phát triển phải kiểm tra lại các bước
Chậm có phiên bản
trước đó, sau đó tiếp tục thực hiện các
thực hiện được
bước tiếp theo, dẫn đến hao phí thời gian
và nhân lực.

Mô hình thác nước sẽ dựa trên yêu cầu từ

Khó đáp ứng khi yêu ban đầu để phát triển, hoàn thiện nên nếu
cầu thay đổi xuất hiện thay đổi sẽ rất khó để đáp ứng
theo.

Ngay khi bắt đầu phát triển phần mềm,

Kết quả đầu ra rõ ràng thiết kế đã được liệt kê rõ các yêu cầu và
kết quả đầu ra rõ ràng.

Tiến hóa (Evolutionary Development):

Tập trung vào tiến trình lặp và phát triển tăng dần dựa trên phản hồi của người dùng và đáp ứng, hưởng tới nâng cao
chất lượng hệ thống phần mềm thông qua các bản thay đổi. Phần mềm không ngừng cải tiến và phát triển dựa theo
sự thay đổi thay vì cố gắng đặt ra tất cả các yêu cầu từ đầu.

Tiến trình lặp (iteration): sự lặp lại tiến trình để đạt tới mục tiêu

//dattrinh, bổ sung cho tiến trình lặp: Kết quả của một lần lặp được sử dụng như điểm bắt đầu của lần lặp tiếp theo.

Module 2: Process Models 1

 Dựa trên hướng phát triển khám phá (thăm dò), mục tiêu là làm việc với khách hàng và cải tiến hệ thống từng bước.

Bắt đầu với những yêu cầu chưa đầy đủ

Thêm những tính năng mới như yêu cầu

Lặp lại cho đến khi có phiên bản cuối cùng

Throw-away Prototyping: Bản mẫu. Mục tiêu là để hiễu yêu cầu khách hàng từng bước và hiểu sâu dần.

Đòi hỏi phải thường xuyên trao đổi với khách hàng, đưa khách hàng trải nghiệm các phiên bản trung gian để thẩm
định,…

Hạn chế

Thiếu trực quan

Hệ thống có cấu trúc nghèo nàn

Đòi hỏi có kỹ năng đặc tả

Khả năng ứng dụng

Hệ thống có nhiều tương tác, nhỏ và vừa

Cho các phần của hệ lớn (VD: giao diện người dùng)

Cho các phần có vòng đời ngắn

Thành phần (Component-based Software Engineering):

Thành phần phần mềm (software components) là 1 đơn vị phần mềm (gói, hoặc module) đóng
gói 1 tập các dịch vụ có liên quan tới nhau. Mỗi thành phần đều có tên, giao diện và code.

Dựa trên việc sử dụng lại 1 cách có hệ thống, phần mềm được phát triển theo hướng thành phần. Hệ thống được tích
hợp từ những thành phần có sẵn.

Các bước (Có sự tương đồng, phát triển từ 4 hoạt động chung nhất)

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

2. Phân tích thành phần

3. Sửa đổi yêu cầu

4. Thiết kế hệ thống với sử dụng lại thành phần phần mềm

5. Phát triển & tích hợp

6. Thẩm định sản phẩm

source

Khung làm việc (framework)

Component Qualification (Đánh giá thành phần): Đảm bảo kiến trúc hệ thống xác định các yêu cầu của các thành
phần để trở thành 1 phần có thể tái sử dụng

Component Adaptation (Kiểm thử thành phần): Đảm bảo kiến trúc xác định các điều kiện thiết kế cho các thành
phần và các phương thức kết nối của chúng

Component Composition (Tích hợp thành phần): Đảm bảo hệ thống tích hợp với các thành phần phần mềm và tạo
thành 1 hệ thống làm việc

Component Update (Cập nhật thành phần): Đảm bảo cập nhật các thành phần có thể tái sử dụng

Phương pháp này ngày càng được ưa chuộng và sử dụng nhiều do các quy chuẩn về thành phần nổi lên mạnh mẽ.

II. Các hoạt động chung nhất của mọi tiến trình
4 hoạt động chung nhất:

Module 2: Process Models 2

 Specification

Đặc tả: Định nghĩa các dịch vụ (chức năng) và các ràng buộc cho phần mềm

Quy trình đặc tả bao gồm:

Nghiên cứu tính khả thi (Feasibility Study)

Thu thập và phân tích yêu cầu (Requirements elicitation and analysis)

Đặc tả yêu cầu (Requirements Specification)

Thẩm định & kiểm định yêu cầu (Requirements Validation & Verification)

Định nghĩa các dịch vụ (chức năng) và các ràng buộc cho phần mềm.

Note:
Verification Validation

Kiểm tra hệ thống trong khi và sau khi
phát triển liệu có thỏa mãn tiêu chí
được đặt ra hay không. → Tập trung
vào sự chính xác của phần mềm so
với đặc tả của nó.
Đặt ra câu hỏi: “Chúng ta có đang làm
sản phẩm đó đúng cách không?”
Ngăn chặn lỗi trong sản phẩm
Đánh giá phần mềm dựa trên mức độ
hoàn thiện của sản phẩm, có đáp ứng
đầy đủ các mong muốn của người
dùng hay không. → Dựa trên phản hồi
của khách hàng
Đặt ra câu hỏi: “Chúng ta có đang làm
đúng sản phẩm đó không?”
Phát hiện lỗi trong sản phẩm

Design & Implementation

Thiết kế: Chuyển hóa các đặc tả yêu cầu thành một biểu diễn thiết kế kiến trúc, cấu trúc, module
của hệ thống, có thể ánh xạ nó ra một chương trình chạy được.

Cài đặt: Chuyển thiết kế thành chương trình chạy được

Thiết kế
Có thể chia làm 3 mức độ khác nhau dựa trên độ chi tiết hay khái quát mà nó diễn tả:
Thiết kế kiến trúc phần mềm (Architecture)
Tập trung vào tổng thể cấu trúc hệ thống, những hệ thống con và module, và những mối quan hệ giữa chúng, cùng
với cách chúng được phân bố

Thiết kế giao diện phần mềm (Interface)

Định nghĩa các giao diện, và các đặc điểm cụ thể của giao diện này không được xác định cụ thể. Một thành phần
có thể được sử dụng theo giao diện này mà các thành phần khác không biết nó đã được cài đặt như nào. Khi đặc
điểm các giao diện được thống nhất, các thành phần có thể được thiết kế và phát triển đồng thời.

Thiết kế chi tiết phần mềm (Detail)

Các cấu trúc dữ liệu và thuật toán được thiết kế dành riêng cho các model khác nhau. Ở bước này, bản thiết kế
bao gồm các thành phần chính (hệ thống con), mối quan hệ giữa chúng và các chúng được phân bố cùng với các
cấu trúc dữ liệu và giải thuật.

Thiết kế phần mềm: kiến trúc, cấu trúc, các module

Chuyển cấu trúc phần mềm thành chương trình thực

thi được.

Cài đặt
Viết các dòng lệnh chỉ dẫn máy tính thực hiện theo.

Khi cài đặt phải tuân theo các quy tắc cụ thể và những quy chuẩn lập trình.

Module 2: Process Models 3

 Lập trình cấu trúc (Structural Programming) giúp đội ngũ lập trình hiểu được phần mềm tốt hơn, dễ dàng định vị được
cách lỗi trong suốt phần mềm, tiết kiệm thời gian và chi phí.

Lập trình thủ tục (Procedural Programming)

Lập trình hướng đối tượng (OOP)

Lập trình dựa trên model (Model-based Programming), e.g: Ngôn ngữ truy vấn cơ sở dữ liệu (SQL)…

Validation

Thẩm định: Chỉ ra rằng hệ thống thỏa mãn yêu cầu khách hàng, cài đặt dễ dàng, chạy ổn định
trong môi trường thực tế.

Mục đích
Sau khi hoàn thành nhiều lần kiểm định (verification), sản phẩm đã được hoàn thành nhằm đáp ứng đặc tả yêu cầu.
Bước thẩm định (validation) sẽ được thực hiện sau đó nhằm xác định xem hệ thống có phù hợp với yêu cầu và thực
hiện các chức năng mà nó được dự định và đáp ứng các mục tiêu, nhu cầu của người dùng hay không.

Chỉ ra rằng hệ thống thỏa mãn yêu cầu khách hàng

Các pha trong kiểm tra thẩm định

Đánh giá thiết kế

Đánh giá cài đặt

Đánh giá hoạt động

Đánh giá hiệu năng

Đưa vào sản xuất

Các hình thức kiểm tra thẩm định

Kiểm tra theo đơn vị (Unit Testing)

Kiểm tra tính tích hợp (Integration Testing)

Kiểm tra hệ thống (System Testing)

Kiểm tra dựa trên đánh giá của người dùng (User Acceptance Testing)

Evolution

Tiến hóa: Làm thích nghi, cải tiến hệ thống với nghiệp vụ mới, môi trường vận hành mới,…

Mục đích
Sự thay đổi phần mềm là không thể tránh khỏi, và việc quản lí thay đổi, cập nhật với những yêu cầu mới là vô cùng quan
trọng. Từ đó, việc liên tục tiến hóa qua chuỗi các bản ra mắt mới là điều thường thấy ở các phần mềm.

Module 2: Process Models 4

 Mô hình xoắn ốc với các phần tư thể hiện cho quá trình liên tục tiến hóa của phần mềm

Làm thích nghi, cải tiến hệ thống với nghiệp vụ mới, môi trường vận hành mới,

Quá trình tiến hóa

Tổng quan: Xác định yêu cầu Hệ thống → Truy cập Hệ thống đang tồn tại → Đề xuất thay đổi Hệ thống → Sửa đổi
Hệ thống

Mô hình Sửa đổi Hệ thống

Bảo trì phần mềm cũng là một hình thức tiến hóa phần mềm. Nó chú trọng vào việc thay đổi phần mềm sau khi đã
đưa phần mềm vào sử dụng. Có một số loại bảo trì phần mềm sau:

Bảo trì sửa chữa lỗi phần mềm

Bảo trì để thích ứng với môi trường làm việc khác

Bảo trì để thêm hoặc chỉnh sửa chức năng phần mềm

Thay đổi yêu cầu là chắc chắn xảy ra với mọi dự án phần mềm, gây ra tốn chi phi cho việc làm lại các phần liên quan. Các
cách tiếp cận để giảm chi phi cho việc làm lại:

Tránh sự thay đổi: Làm bản mẫu để xác nhận và làm mịn yêu cầu

Chấp nhận thay đổi: Chuyển giao dần từng phần của hệ thống.

Quá trình phát triển được chia ra làm các increments với mỗi increment phân phối 1 phần các yêu cầu.

Request KH đc phân độ ưu tiên, cao làm trước.

Khi làm 1 increment thì yêu cầu của increment này bị đóng băng nhưng yêu cầu của các increments khác vẫn phát
triển.

Module 2: Process Models 5

 Người dùng có sản phẩm dùng sớm. Các phiên bản sớm đóng vai trò như bản mẫu để giúp
thu thập yêu cầu mới cho phiên bản kế tiếp. Đặc biệt các yêu cầu có độ ưu tiên cao được kiểm
thử nhiều lần.

Mô hình phát triển xoắn ốc

Kết hợp cả tránh sự thay đổi và chấp nhận sự thay đổi, đồng thời rủi ro được đánh giá và
được giải quyết ở mỗi lần lặp. Bốn khu vực của mô hình bao gồm: đặt mục tiêu, đánh giá và
giảm thiểu rủi ro, phát triển và thẩm định, lập kế hoạch cho pha tiếp theo.

Mô hình xoắn ốc với các phần tư thể hiện cho quá trình liên tục tiến hóa của phần mềm

Module 2: Process Models 6

 󾠰
Module 3: RUP - Agile Processes
I. RUP
Định nghĩa:
Gắn với ngôn ngữ mô hình hóa thống nhất UML

Là một mô hình tiến trình hiện đại tách riêng pha và hoạt động, đi theo 3 quan điểm: dynamic - theo các pha, static -
theo quy trình, practice - theo thực tế. Kết hợp của 3 mô hình tiến trình cơ bản: thác nước, tiến hóa và phát triển phần
mềm dựa trên thành phần.

Là một tiến trình cho phép tạo ra phần mềm chất lượng cao đáp ứng yêu cầu của khách hàng trong một khung thời
gian và ngân sách đã được định trước.

Các pha:
Inception: Định nghĩa phạm vi dự án

Nhận ra các thực thể bên ngoài hệ thống. Đó có thể là con người, hoặc hệ thống khác, chúng sẽ tương tác với hệ
thống

Định nghĩa những tương tác này

Từ những thông tin đó, đánh giá mức độ đóng góp của hệ thống với nghiệp vụ

Nếu đóng góp đó không đáng kể → hủy bỏ dự án

Elaboration: Lập kế hoạch, đặc tả các đặc tính và kiến trúc cơ bản

Định nghĩa mô hình yêu cầu

Lên kế hoạch phát triển phần mềm

Nhận ra các rủi ro

Construction: Phát triển sản phẩm

Thiết kế, lập trình và kiểm thử

Các phần của hệ thống được phát triển song song và tích hợp ở pha này

Tạo ra chương trình vận hành được và các tài liệu sẵn sàng cho pha chuyển giao phần mềm

Transition: Chuyển giao sản phẩm cho người dùng

Chuyển giao phần mềm từ môi trường của đội phát triển sang môi trường vận hành thực tế của khách hàng

Đảm bảo vận hành tốt trên môi trường của khách hàng

Module 3: RUP - Agile Processes 1

 Các bước phát triển được xếp theo trình tự logic. Mỗi quy trình lặp đều thực hiện đủ các bước phát triển.

Các bước:
1. Business Modelling: Mô hình hóa các tiến trình nghiệp vụ, các ca sử dụng nghiệp vụ.

2. Requirements: Chỉ ra các tác nhân và mô tả chi tiết các ca sử dụng để mô hình hóa các yêu cầu của hệ thống.

3. Analysis & Design: Phân tích và thiết kế mô hình hệ thống từ:

Mô hình thành phần (component models)

Mô hình đối tượng (object models)

Mô hình tuần tự (sequence models)

4. Implementation: Cài đặt các thành phần của hệ thống, áp dụng mã tự động từ thiết kế.

5. Testing: Thực hiện nhiều lần kiểm thử, cài đặt. Sau khi hoàn thành việc cài đặt, thực hiện kiểm thử ở mức độ hệ
thống.

6. Deployment: Đưa ra các bản phát hành sản phẩm tới người dùng cuối.

7. Configuration & Change Management: Không chỉ áp dụng trong việc theo dõi phiên bản sản phẩm mà còn được
dùng trong việc kiểm soát các thay đổi.

8. Project Management: Tập trung chủ yếu vào các khía cạnh quan trọng trong quá trình phát triển lặp lại của phần
mềm. Thường được thực thi ở 2 mức độ khác nhau:

Mức độ ở mô hình thô, tập trung vào lên kế hoạch các pha trong dự án

Mức độ ở chuỗi mô hình tinh xảo hơn, quản lí tiến độ các tiến trình lặp trong dự án qua các thông số

9. Environment: Tập trung vào những hành động cần thiết nhằm cung cấp môi trường phát triển hệ thống, bao gồm các
quá trình và các công cụ khác nhau, trải dài ở các pha.

Trong các bước nêu trên, chỉ có 6 bước quan trọng không thể thiếu là 1, 2, 3, 4 ,5, 6. Các bước
7, 8 và 9 đóng vai trò hỗ trợ để phát triển phần mềm hiệu quả và thuận lợi.

Nguyên tắc thực hành RUP:

1. Phát triển phần mềm lặp đi lặp lại: Lên kế hoạch các bước lặp theo độ ưu tiên của yêu cầu.

2. Quản lý yêu cầu: Bao gồm làm tài liệu các yêu cầu, lưu giữ vết của sự thay đổi yêu cầu, phân tích tầm ảnh hưởng của
các thay đổi trước khi chấp nhận thay đổi đó.

Module 3: RUP - Agile Processes 2

 3. Sử dụng kiến trúc dựa trên thành phần: Cấu trúc hệ thống theo các thành phần.

4. Mô hình phần mềm trực quan: Sử dụng UML để thể hiện đủ các khía cạnh tĩnh và động của hệ thống.

5. Kiểm chứng chất lượng phần mềm: Đảm bảo phần mềm đáp ứng chuẩn chất lượng.

6. Kiểm soát sự thay đổi cho phần mềm: Sử dụng hệ thống quản lý thay đổi, Áp dụng các thủ tục và công cụ quản lý
cấu hình hệ thống.

CASE - Computer Aided Software Engineering

Là các công cụ trợ giúp các công đoạn khác nhau trong tiến trình phát triển và tiến hóa phần mềm

Các hoạt động tự động: biên tập đồ họa cho các mô hình phát triển hệ thống, từ điển dữ liệu để quản lý các objects,
thiết kế, gỡ lỗi,…

CASE dẫn đến cải tiến quan trọng trong tiến trình phần mềm. Tuy nhiên, đây không phải thứ tự cường độ cải tiến đã
được định trước. Đặc biệt, công nghệ phần mềm là hoạt động, tương tác nhóm nhưng CASE không hỗ trợ điều này.

Phân loại CASE:

Functional perspective: Phân chia tương ứng với chức năng của chúng

Process perspective: Phân chia tương ứng với hoạt động tiến trình chúng hỗ trợ

Integration perspective: Phân chia tương ứng với tổ chức của chúng thành các đơn vị tích hợp.

Tích hợp trong CASE:

Tools: Hỗ trợ các nhiệm vụ riêng như kiểm tra nhất quán thiết kế, text editing,…

Workbenches: Hỗ trợ các pha đặc tả, thiết kế,… Thường bao gồm 1 số tools.

Môi trường: Hỗ trợ tất cả hoặc 1 phần của phần mềm. Thường bao gồm 1 số workbenches.

II. Agile
Bối cảnh ra đời
Phần mềm là một phần vận hành của doạnh nghiệp trong môi trường mới với nhiều cơ hội mới, vấn đề thị trường mới, cần
được phát triển nhanh để đáp ứng. Bên cạnh đó, yêu cầu ban đầu cho phần mềm chắc chắn sẽ thay đổi, việc thiết kế và
cài đặt phải được làm lại và kiểm thử lại, gây phá vỡ lịch trình và chi phí dự kiến. Từ đó, tiến trình phát triển nhanh phù hợp
với các phần mềm nghiệp vụ.

Tiến trình phát triển nhanh: Thường là yêu cầu quan trọng nhất cho một hệ thống phần mềm.
Gồm những đặc trưng:
- Đặc tả, thiết kế, cài đặt được thực hiện đan xen nhau
- Không có đặc tả hệ thống chi tiết
- Tài liệu thiết kế được tối giản, hoặc được phát sinh tự động
- Tài liệu yêu cầu người dùng chỉ mô tả các đặc điểm quan trọng nhất của hệ thống
- Hệ thống phát triển nhiều phiên bản
- Người dùng và nhà đầu tư có thể tham gia vào việc đặc tả, đánh giá phiên bản và đề xuất sự
thay đổi yêu cầu, thêm yêu cầu mới cho phiên bản tiếp theo.
- Giao diện người dùng thường được phát triển nhanh:
+ Sử dụng công cụ phát triển tương tác
+ Vẽ, kéo, thả, đặt các biểu tượng trên công cụ
+ Phát sinh tự động giao diện cho ứng dụng Web hoặc ứng dụng chạy trên nền hệ điều hành
cụ thể.

Động lực của Agile

Mã nguồn quan trọng hơn thiết kế

Tiếp cận liên tục → phát triển phần mềm

Hướng tới chuyển giao nhanh → đáp ứng yêu cầu thay đổi

Giảm phụ phí, đáp ứng nhanh các thay đổi mà không phải làm lại toàn bộ

Tuyên ngôn của Agile

Module 3: RUP - Agile Processes 3

 Là phương pháp phát triển phần mềm linh hoạt, Agile có 4 tuyên ngôn:

Individuals and interactions > processes and tools

Cá nhân và sự tương hỗ > quy trình và công cụ

Working software > comprehensive documentation

Sản phẩm dùng được > tài liệu về sản phẩm

Customer collaboration > contract negotiation

Cộng tác với khách hàng > đàm phán hợp đồng

Responding to change > following a plan

Phản hồi với sự thay đổi > bám theo kế hoạch

Phương pháp Agile

Phát triển tăng dần

Phiên bản mới được làm trong vòng 2-3 tuần

Khách hàng tham gia vào tiến trình phát triển

– Phát biểu yêu cầu
– Xếp thứ tự ưu tiên các yêu cầu
– Phản hồi nhanh về sự thay đổi, bổ sung yêu cầu cho phiên bản tiếp theo

Hạn chế tài liệu → trao đổi thường xuyên giữa các thành viên đội phát triển với nhau và với khách hàng

Khó khăn khi áp dụng Agile

Thời gian mà khách hàng có thể tham gia với đội phát triển

Sự cộng tác không ăn ý giữa các thành viên trong đội

Khó xếp thứ tự ưu tiên các yêu cầu, đặc biệt khi có nhiều nhà đầu tư

Khó xây dựng được phần mềm cấu trúc tốt và đơn giản, dễ hiểu.

Khó thay đổi văn hóa làm việc từ truyền thống sang Agile.

Thành viên đội phát triển cộng tác chặt chẽ với nhau rời nhóm

Nhận xét: Agile ứng dụng hợp lý trong các sản phẩm phần mềm vừa và nhỏ được phát triển để
bán, khó áp dụng đối với các phần mềm phức tạp hơn. Các phần mềm có yêu cầu về tính an
toàn và an ninh cao sẽ rất khó để áp dụng phương pháp Agile.

Bảo trì phần mềm với Agile

Nhiều tổ chức phát triển phần mềm tiêu tốn phần lớn thời gian vào giai đoạn bảo trì phần mềm hơn là phát triển phần
mềm mới. Do đó:

Đề cao việc viết mã có cấu trúc tốt, dễ đọc, đầu tư vào cải tiến mã

Tối thiểu hóa tài liệu trong Agile

Mô tả yêu cầu: phi hình thức; không tạo tài liệu yêu cầu nhất quán

Do duy trì sản phẩm sẽ được ưu tiên hơn là làm mới, cần xem xét 2 vấn đề:

Agile có thể được áp dụng theo hướng duy trì không?

Agile có hiệu quả cho hệ thống trong việc đáp ứng yêu cầu thay đổi không?

Lựa chọn phát triển với Agile:

Một số các Q&A về nên hay không nên áp dụng Agile.

Question Answer

Cần đặc tả chi tiết và thiết kế trước? True

Chuyển giao tăng dần có thiết thực? True

Hệ thống lớn? False

Hệ thống cần phân tích nhiều? False

Lifetime của hệ thống dài? False

Công cụ hỗ trợ phát triển tốt, nhiều? True

Module 3: RUP - Agile Processes 4

 Tổ chức nhóm rời rạc? False

Nhiều vấn đề ảnh hưởng tới hệ thống? False

Trình độ của thành viên trong nhóm cao? True

Hệ thống bị chi phối với quy định ngoài? Có

Agile Framework:
eXtreme Programming (XP)

XP: eXtreme Programming

Giới thiệu về XP:
Là framework được sử dụng rộng rãi nhất trong các phương pháp Agile.

Áp dụng lối phát triển tăng dần qua nhiều phiên bản. XP yêu cầu khách hàng tham gia toàn bộ thời gian với
đội ngũ phát triển. Cùng với phương pháp lập trình đôi, XP hướng tới chấp nhận thay đổi ở các phiên bản.

“Extreme”: Thể hiện mục đích cuối cùng của XP là phát triển những phần mềm với:

Chất lượng cao nhất

Chi phí thấp nhất

Ít lỗi nhất

Siêu năng suất

Tối đa hóa lợi nhuận đầu tư

XP làm điều này thông qua:

Các giá trị định hướng (Values)
Giao tiếp (Communication)

Đơn giản (Simplicity)

Phản hồi (Feedback)

Tôn trọng (Respect)

Can đảm (Courage)

Các nguyên tắc (Principles)

Phản hồi nhanh (Rapid Feedback)

Giả định đơn giản (Assume Simplicity)

Thay đổi tiệm tiến (Incremental Changes)

Đón nhận thay đổi (Embracing Changes)

Công việc chất lượng cao (Quality Work)

Ngoài ra còn một số nguyên tắc mở rộng góp phần tham gia quy định và điều chỉnh các hoạt động của
đội ngũ phát triển.

Các kĩ thuật thực hành đặc thù theo Agile (Practices)

Lập kế hoạch: Nhanh chóng xác định phạm vi lần phát hành tới bằng cách kết hợp những ưu tiên
nghiệp vụ và ước lượng kĩ thuật

Nhiều bản phát hành nhỏ

Thiết kế đơn giản

Kiểm thử

Lập trình đôi: Lập trình viên làm việc theo cặp → Mọi lập trình viên đều có trách nhiệm và hiểu bất
kỳ đoạn mã nào, thuận lợi trong việc cải tiến mã nguồn. Hiệu suất tương đương làm việc độc lập.

Tích hợp liên tục,…

Yêu cầu của XP:

Khách hàng, người dùng tham gia phát triển, ra quyết định về yêu cầu

Module 3: RUP - Agile Processes 5

 Yêu cầu người dùng được biểu thị bằng kịch bản hoặc câu chuyện người dùng.

Đội phát triển phân chia yêu cầu thành các nhiệm vụ

Các nhiệm vụ đó là cơ sở để ước lượng và lập lịch

Khách hàng chọn các câu chuyện sẽ được thực thi ở phiên bản kế tiếp, phụ thuộc theo độ ưu tiên và ước
lượng lịch trình.

Vòng đời phát triển và chuyển giao phiên bản

Gồm 6 bước:

Lựa chọn yêu cầu cho bản phát hành

Chia yêu cầu thành nhiệm vụ

Lên kế hoạch phát triển phiên bản

Phát triển, tích hợp và kiểm thử

Chuyển giao

Đánh giá

Quy trình dự án XP

Module 3: RUP - Agile Processes 6

 Scrum

Scrum
Định nghĩa:
Scrum là một agile framework hỗ trợ con người có thể giải quyết các vấn đề phức tạp và chúng cung cấp
các sản phẩm có giá trị cao nhất theo cách hiệu quả và sáng tạo.

Scrum làm rõ hiệu quả tương đối của quản lý sản phẩm và kỹ thuật làm việc để có thể liên tục cải tiến sản
phẩm, nhóm và môi trường làm việc.

Trong Scrum, công việc được thực hiện bởi Nhóm Scrum thông qua từng phân đoạn lặp liên tiếp nhau
được gọi là Sprint.

Các vài trò chính:

Product Owner:

Người làm những công việc bắt đầu cho dự án, tạo ra các yêu cầu trong quá trình phát triển dự án.
Phân tích mục tiêu, giải phóng các kế hoạch.

Xác định những gì cần làm và sắp xếp độ ưu tiên để đưa ra kết quả có giá trị cao nhất.

Chịu trách nhiệm quản lý Product Backlog:

Miêu tả rõ ràng từng backlog item

Sắp xếp mức độ ưu tiên của backlog item hợp lý

Tối ưu hóa giá trị mà đội ngũ phát triển thực hiện

Đảm bảo Product Backlog rõ ràng và minh bạch

Đảm bảo đội ngũ phát triển hiểu Product Backlog

Scrum Master:

Module 3: RUP - Agile Processes 7

 Người phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở
ngại.

Tạo điều kiện thuận lợi cho mọi giao tiếp và hợp tác giữa ban lãnh đạo và thành viên trong nhóm để tối
đa hóa giá trị được tạo bởi Scrum-team.

Với nhóm Scrum do mình quản lý, Scrum Master có trách nhiệm:

Huấn luyện thành viên tự quản lý và hoạt động chéo

Giúp nhóm tập trung tạo ra các bước tiến có giá trị cao, đáp ứng yêu cầu sản phẩm

Loại bỏ trở ngại đối với tiến trình của nhóm

Đảm bảo các sự kiện Scrum diễn ra tích cực, hiệu quả và được lưu giữ ở timebox.

Với Product Owner, Scrum Master có trách nhiệm:

Đảm bảo mục tiêu, phạm vi và lĩnh vực sản phẩm được truyển đạt cho các thành viên trong nhóm
Scrum hiểu rõ nhất có thể.

Tìm kiếm kỹ thuật giúp Product Owner quản lý Product Backlog hiệu quả.

Giúp thiết lập kế hoạch, quy hoạch sản phẩm trong môi trường phức tạp

Tạo điều kiện cho sự hợp tác với các bên liên quan khi được yêu cầu hoặc cần thiết.

Development Team

Còn hoạt động dưới tên gọi là nhóm Scrum

Những đặc điểm bao gồm:

Tự tổ chức (Self-organizing): Nhóm phát triển tự lên kế hoạch, ước lượng và quản lý công việc.

Hoạt động chéo (Cross-functional): Nhóm phát triển có đầy đủ các kỹ năng cần thiết của một nhóm
cho sự phát triển của sản phẩm

Các thành viên trong nhóm có thể có các kỹ năng chuyên môn riêng và tập trung vào một số việc
nhất định, nhưng trách nhiệm thuộc về nhóm phát triển nói chung.

Các bước thực hiện

5 pha chính trong Scrum:

Initiation: Khởi tạo dự án, xác định tầm nhìn cho dự án, phân chia nhân lực vào các nhóm Scrum, xây
dựng Product Backlog bao gồm những thứ phải làm để hoàn thành sản phẩm.

Planning & Estimation: Lên kế hoạch cho Sprint, lựa chọn những item liên quan từ Product Backlog
→ Sprint Backlog để thực hiện. Bên cạnh đó, ước tính kết quả và thời gian hoàn thành Sprint.

Implementation: Thực hiện cài đặt theo Sprint đã lên kế hoạch từ trước, liên tục cập nhật backlog,
tăng cường giao tiếp giữa các thành viên.

Reviewing: Duyệt các công việc được hoàn thiện, tìm cách tối ưu kết quả đạt được. Điều chỉnh các
quy trình và phương pháp để thuận lợi chuyển giao sang pha lên kế hoạch và ước tính tiếp theo.

Releasing: Phát hành sản phẩm cuối cùng tới stakeholder, tổ chức nhìn lại (Retrospective) hiệu năng
làm việc qua các Sprint để tìm hướng nâng cao chất lượng làm việc.

Mô hình các bước thực hiện

Module 3: RUP - Agile Processes 8

 1. Stakeholders và Product owner đề xuất yêu cầu phát triển phần mềm. Các yêu cầu được phát biểu
dưới dạng Product Backlog.

2. Đội phát triển ngồi với nhau để lập kế hoạch cho Sprint

a. Xác định yêu cầu sẽ được thực hiện trong thời gian tới

b. Mục tiêu là hoàn thiện một vài chức năng để chuyển giao trong thời gian trên.

3. Tổng hợp kết quả của buổi họp kế hoạch bao gồm mục tiêu và những việc cần làm trong thời gian tới
vào Sprint Backlog.

4. Thành viên đội làm việc được giao và cộng tác chặt chẽ với các thành viên khác. Tổ chức họp hàng
ngày (Daily Scrum) để nắm tiến độ, phát hiện trở ngại hay chỉnh sửa số lượng công việc, cập nhật bản
kế hoạch (Product Backlog Refinement).

5. Khi kết thúc khung thời gian của Sprint, đưa ra được một phiên bản chạy tốt của phần mềm, hoặc một
bước phát triển sản phẩm có tiềm năng chuyển giao.

6. Cùng ngồi với nhau để xem lại hiệu năng làm việc của đội phát triển trong Sprint vừa rồi và tìm ra điều
cần cải tiến.

7. Quay lại bước 2, bắt đầu Sprint tiếp theo.

Module 3: RUP - Agile Processes 9

 󾠱
Module 4: Requirements Engineering
Là quy trình xác định dịch vụ hệ thống mà khách hàng yêu cầu, cùng với những ràng buộc để phát
triển và vận hành các dịch vụ đó. Trong đó, các yêu cầu là mô tả về các dịch vụ và ràng buộc đó.

Yêu cầu (Requirements):

Là các mô 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

Là cơ sở cho đề xuất/ đấu thầu hợp đồng

Là cơ sở cho lập hợp đồng

Các dạng yêu cầu

Yêu cầu người dùng:

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

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

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

Xác định các chức năng, dịch vụ 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 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

Xác định các ràng buộc, thuộc tính hệ thống

Đôi khi yêu cầu phi chức năng quan trọng hơn yêu cầu chức năng vì khi đó, nếu chúng không được thỏa mãn, hệ
thống sẽ trở thành vô dụng.

Tính chính xác: Yêu cầu được mô tả chính xác, tránh nhập nhằng

Tính đầy đủ và nhất quán:

Tính đầy đủ: Tính năng và dịch vụ yêu cầu được mô tả đầy đủ

Tính nhất quán: Tính năng và dịch vụ yêu cầu được mô tả nhất quán

Tính đo được: Yêu cầu phi chức năng phải được lượng hóa dựa trên các tiêu chí thỏa mãn để kiểm tra và thẩm
định tính thỏa mãn của sản phẩm

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

Yêu cầu về sản phẩm

Yêu cầu về tổ chức: Hệ quả của các chính sách (policy) và thủ tục (procedure), e.g. yêu cầu về quy trình

Yêu cầu bên ngoài: Phát sinh bên ngoài hệ thống, e.g yêu cầu pháp lý

Yêu cầu miền

Các ràng buộc xuất phát từ miền hoạt động của hệ thống

Đặt ra các yêu cầu mới về chức năng hay phi chức năng cho hệ thống

Hệ thống có thể không thể hoạt động khi không thỏa mãn các yêu cầu miền

Module 4: Requirements Engineering 1

 Tài liệu yêu cầu

Phát biểu chính thống về những gì cần phải đạt được để phát triển phần mềm

Thường bao gồm đặc tả về:

Yêu cầu người dùng: Dành cho người quản lý khách hàng, người dùng cuối, quản lý hợp đồng, …

Yêu cầu hệ thống: Người dùng cuối, kỹ sư khách hàng, người phát triển phần mềm, kiến trúc sư hệ thống,…

Tài liệu yêu cầu ảnh hưởng tới bản mẫu phần mềm, hướng dẫn sử dụng, tài liệu phần mềm, …

Thông tin trong tài liệu yêu cầu phụ thuộc vào loại hệ thống và phương pháp tiếp cận hệ thống.

✅ Agile Perspective
Agile cho rằng việc viết tài liệu yêu cầu phần mềm là phí thời gian

Đặc tả yêu cầu

Quá trình tổng hợp, đưa yêu cầu người dùng và hệ thống vào tài liệu yêu cầu.

Là một phần hợp đồng phát triển hệ thống:

Yêu cầu người dùng: Phục vụ người dùng cuối, khách hàng

Yêu cầu hệ thống: Chi tiết hơn, nhiều thông tin kỹ thuật hơn

Các dạng đặc tả yêu cầu:

Ngôn ngữ tự nhiên:

Dùng ngôn ngữ tự nhiên và được gắn với các chỉ số

Ưu điểm: Dễ dùng, tự nhiên, phổ biến

Nhược điểm: Khó phân biệt yêu cầu chức năng/phi chức năng, khó đảm bảo đồng thời tính chính xác và dễ đọc

Ngôn ngữ tự nhiên được cấu trúc:

Dùng ngôn ngữ tự nhiên, bảng biểu dựa trên định dạng nào đó

Ngôn ngữ mô tả thiết kế

Dùng ngôn ngữ tựa ngôn ngữ lập trình để mô tả hoạt động hệ thống

Các ký pháp đồ họa

Dùng biểu đồ đồ họa bổ trợ cho diễn đạt ngôn ngữ tự nhiên

Đặc tả hình thức:

Dùng ngôn ngữ, mô hình toán học đặc tả hoạt động hệ thống

⚠ Phần biệt với tài liệu thiết kế.

Tài liệu yêu cầu (đặc tả yêu cầu) tập trung vào câu hỏi “What?”, tài liệu thiết kế tập trung câu hỏi “How?”.

💡 Yêu cầu và thiết kế không thể tách rời.

Hệ thống có thể được thiết kế để mô hình các yêu cầu.

Quy trình kỹ nghệ (Requirements Engineering Processes)

Phụ thuộc vào miền ứng dụng, các cá nhân liên quan và cách tổ chức phát triển yêu cầu

Các hoạt động chung nhất cho quy trình:

Thu thập yêu cầu

Module 4: Requirements Engineering 2

 🔍 Requirements Elicitation: Thu thập yêu cầu
Đặc tả yêu cầu

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

Requirements Validation: Thẩm định yêu cầu

Đảm bảo các yêu cầu xác định đúng hệ thống mà khách hàng mong đợi

⚠ Khâu quan trọng, vì chi phí sửa lỗi yêu cầu tăng lên nhiều lần nếu được phát hiện muộn

Nội dung kiểm tra yêu cầu

Tính hợp lệ (Validity)

Tính nhất quán (Consistency)

Tính đầy đủ (Completeness)

Tính hiện thực (Realism)

Tính kiểm chứng (Verifiability)

Một số kỹ thuật thẩm định yêu cầu

Kiểm định yêu cầu: Kiểm tra, đánh giá và phân tích thủ công yêu cầu

Làm bản mẫu (Prototype)

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 toán

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

Diễn ra trong quá trình đặc tả yêu cầu

Các bên liên quan hợp đồng cùng tham gia kiểm tra đánh giá

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

⚠ Trong phát triển phần mềm

- Kiểm định được thực hiện trong giai đoạn đầu
- Thẩm định được thực hiện ở giai đoạn cuối

Nội dung kiểm định yêu cầu

Tính kiểm chứng được

Tính hiểu được

Tính lần vết được

Tính thích ứng được

Quản lý yêu cầu

Requirements Management: Quản lý yêu cầu

Là quá trình quản lý các thay đổi yêu cầu trong quy trình kỹ nghệ yêu cầu và khi phát triển
hệ thống

Quản lý yêu cầu

Yêu cầu mới xuất hiện trong quá trình phát triển và vận hành

Duy trì phụ thuộc giữa các yêu cầu để phân tích tầm ảnh hưởng của các thay đổi

Thiết lập quy trình tiếp nhận đề xuất thay đổi & liên kết với yêu cầu hệ thống

Module 4: Requirements Engineering 3

 Thay đổi yêu cầu
Thay đổi về môi trường nghiệp vụ và kỹ thuật

Người dùng cuối thường không phải là người chi trả cho phát triển hệ thống
→ Yêu cầu thay đổi từ 2 phía thường xảy ra xung đột

Phức tạp khi cộng đồng người dùng cuối đa dạng và lớn

Kế hoạch quản lý yêu cầu

Định danh các yêu cầu
Mỗi yêu cầu phải được xác định duy nhất để tham chiếu chéo với các yêu cầu khác

Quy trình quản lý thay đổi

Tập hợp các hoạt động đánh giá tác động & chi phí biến đổi

Chính sách lần vết

Xác định mối quan hệ giữa các yêu cầu và ghi lại thiết kế hệ thống

Công cụ hỗ trợ
Được dùng nhiều trong hệ thống quản lý yêu cầu chuyên viên tới cơ sở dữ liệu đơn giản

Quản lý thay đổi yêu cầu

💡 Cần quyết định về việc chấp nhận thay đổi yêu cầu

1. Phân tích vấn đề & đặc tả sự thay đổi

2. Phân tích tầm ảnh hưởng & chi phí thay đổi

3. Cài đặt, hiện thực hóa sự thay đổi

Kỹ nghệ yêu cầu (Engineering Processes) thường gồm các hoạt động lặp lại và gối lên nhau.

Module 4: Requirements Engineering 4

 󾠲
Module 5: System Modeling
Khái niệm về mô hình hóa hệ thống
Khái niệm cơ bản về hệ thống

💡 Hệ thống bao gồm các thành phần (thiết bị, phần mềm, con người), hoạt động trong môi trường, và hướng mục
đích

Hệ thống hiện thời (system-as-is): đang vận hành, có vấn đề, nhu cầu cần cải tiến

Hệ thống được phát triển (system-to-be): cần được phát triển, tiến hóa từ hệ thống hiện thời

Mô hình hóa hệ thống

💡 Mô hình hóa là sử dụng các mô hình để nhận thức và diễn tả hệ thống.

→ Sự đơn giản hóa của chủ thể trong thế giới thực

Mục đích

Hiểu tổng thể hệ thống (chức năng, cấu trúc) và giao tiếp giữa các bên liên quan

Mô hình hệ thống hiện thời: giúp thu thập và phân tích yêu cầu (kỹ nghệ yêu cầu)

Mô hình hệ thống mới: (phân tích, thiết kế, cài đặt)

Đặc tả yêu cầu hệ thống

Đề xuất thiết kế hệ thống

Làm tài liệu

Tác dụng

Để hiểu: Hình dung ý tưởng và hình thành hình ảnh giản lược về đối tượng được tìm hiểu. Ngược lại, việc sử dụng
các mô hình giúp nhận thức vấn đề dễ dàng, nhanh chóng.

Để trao đổi: Mô hình giống như một loại ngôn ngữ chung giữa những người cùng quan tâm tới một vấn đề.

Để hoàn chỉnh: Dễ dàng đánh giá mức độ phù hợp với nhu cầu hay mức độ hoàn thiện của hệ thống. Từ đó tiếp
tục phát triển phần mềm và kiểm định, mô phỏng, thực hiện.

Nguyên lý mô hình hóa hệ thống

Ảnh hưởng đến cách vấn đề được giải quyết: Cung cấp cái nhìn tổng quan, xác định yếu tố quan trọng, hỗ trợ
đưa ra quyết định.

Có thể được biểu diễn ở các mức độ chính xác khác nhau: Trừu tượng (tiếp cận vấn đề tổng quan) → Chi tiết
(tiếp cận các chi tiết cần thiết)

Mô hình tốt nhất khi được kết nối với thực tế: Phản ánh thực tế và kết nối với các khía cạnh thực tế của hệ
thống.

Sử dụng một mô hình duy nhất thường không đủ: Sử dụng nhiều mô hình khác nhau có thể giúp hiểu sâu hơn
các khía cạnh và yếu tố của hệ thống phức tạp.

Ngôn ngữ mô hình hóa UML

✅ UML (Unified Modeling Language) là một ngôn ngữ mô hình gồm các ký hiệu đồ họa để thiết kế các hệ thống
thông tin một cách nhanh chóng

Các loại biểu đồ UML

Module 5: System Modeling 1

 Biểu đồ hoạt động: biểu diễn hoạt động diễn ra trong tiến trình hay một xử lý dữ liệu

Biểu đồ ca sử dụng: biểu diễn tương tác giữa hệ thống và môi trường

Biểu đồ tuần tự: biểu diễn tương tác giữa tác nhân và hệ thống, hay giữa các thành phần hệ thống

Biểu đồ lớp: biểu diễn các lớp đối tượng và quan hệ giữa chúng

Biểu đồ trạng thái: biểu diễn cách hệ thống phản ứng với các sự kiện từ bên trong và bên ngoài

Các góc nhìn hệ thống

Góc nhìn từ bên ngoài: mô hình hóa ngữ cảnh và môi trường hệ thống

Góc nhìn tương tác: giữa môi trường và hệ thống, giữa các thành phần hệ thống

Góc nhìn cấu trúc: mô hình hóa tổ chức, biểu diễn cấu trúc dữ liệu của hệ thống

Góc nhìn hành vi: mô hình hóa hành vi động của hệ thống và cách hệ thống phản hồi các sự kiện

Một số loại mô hình hệ thống

Mô hình ngữ cảnh
Minh họa ngữ cảnh hoạt động của hệ thống

Việc xác định biên hệ thống chịu ảnh hưởng của các yếu tố tổ chức và xã hội.

💡 Dạng mô hình kiến trúc chỉ mối quan hệ của hệ thống với các hệ thống khác

Biên hệ thống

Biên hệ thống xác định những gì thuộc về hệ thống, hay thuộc về môi trường
→ Ảnh hưởng sâu sắc đến yêu cầu của hệ thống

Xác định biên hệ thống mang yếu tố chính trị

Áp lực để xác định hệ thống

→ Điều chỉnh ảnh hưởng hoặc khối lượng công việc các thành phần trong tổ chức.

Mô hình quy trình (bổ trợ cho mô hình ngữ cảnh)

Thường được dùng để bổ trợ cho mô hình ngữ cảnh

Mô tả tương tác giữa hệ thống với môi trường

Có thể dùng biểu đồ UML để mô hình hóa quy trình

Mô hình ngữ cảnh: Biểu đồ hoạt động UML

Mô hình tương tác

Mô hình hóa tương tác người dùng giúp xác định yêu cầu người dùng

Mô hình hóa tương tác hệ thống giúp đặc tả giao thức tương tác

Mô hình hóa tương tác thành phần giúp hiểu cấu trúc của hệ thống và khả năng đáp ứng các yêu cầu phi chức năng
(về hiệu năng và tính tin cậy)

Thường sử dụng biểu đồ ca sử dụng và biểu đồ tuần tự để mô hình hóa

Mô hình ca sử dụng

Dùng ca sử dụng để đặc tả & cấu trúc yêu cầu hệ thống.

Mỗi ca sử dụng đại diện cho một tác vụ có tương tác bên ngoài với hệ thống.

Các tác nhân tham gia có thể là người hoặc các hệ thống khác.

Thường ở dạng kết hợp biểu đồ trực quan và các mô tả văn bản chi tiết.

Mô hình tương tác: Biểu đồ ca sử dụng UML

Module 5: System Modeling 2

 💡 Minh họa biểu đồ ca sử dụng

Tác nhân (1): Con người, thành phần phần

mềm bên ngoài, … tương tác với hệ thống

Ca sử dụng (2): Các hành động được thực

hiện tác nhân có mục tiêu cụ thể.

Liên kết tác nhân và ca sử dụng (3)

Hệ thống (4): Thành phần phần mềm nhỏ

Một số quan hệ:

Quan hệ tổng quát hóa (Generalization): Tác nhân kế thừa lớp tổng quát hơn

Quan hệ bao gộp (Include): Diễn đạt các chi tiết của ca sử dụng khác

Quan hệ mở rộng (Extend): Thêm chức năng cho ca sử dụng trong điều kiện nào đó

Mô hình tương tác: Biểu đồ tuần tự

Mô hình hóa tương tác giữa tác nhân và các đối tượng trong hệ thống
→ Đặc tả kịch bản ca sử dụng

Module 5: System Modeling 3

 💡 Minh họa biểu đồ tuần tự:

Đường sông (1): Biểu diễn các thể hiện của lớp, thành phần, tác nhân,…

Thông điệp (3, 4, 6, 7): Gửi từ đối tượng gửi đến đối tượng nhận

Thông điệp đồng bộ (3): Mô tả tương tác trong đó đối tượng gửi chờ đến khi nhận được phản
hồi của đối tượng nhận

Thông điệp bất đồng bộ (4): Mô tả tương tác trong đó đối tượng gửi có thể tiếp tục công việc
mà không phải chờ phản hồi từ đối tượng nhận.

Khoảng thực thi (5): Xuất hiện ở đối tượng nhận thông điệp

Ký pháp (9): Tình huống thông điệp

Mô hình cấu trúc

Biểu diễn cách tổ chức của hệ thống, chỉ ra quan hệ giữa các thành phần hệ thống

Mô hình cấu trúc:

Ở dạng mô hình tĩnh: Mô tả cấu trúc thiết kế hệ thống

Ở dạng mô hình động: Phản ánh cấu trúc hệ thống khi thực thi

Thường được dùng khi thảo luận và thiết kế kiến trúc hệ thống

Biểu đồ lớp được dùng để biểu diễn mô hình cấu trúc

Lớp: Tập các đối tượng cùng đặc điểm

Quan hệ kết hợp: Quan hệ ngữ nghĩa giữa các lớp

Quan hệ hợp thành: Quan hệ tổng thể - bộ phận

Tổng quát hóa: Lớp con chi tiết hóa lớp cha

Mô hình hành vi
Mô tả hành vi động của hệ thống khi thực hiện
→ Làm rõ cách thức hệ thống phản hồi kích thích từ môi trường

Có 2 dạng kích thích từ môi trường

Dữ liệu: Gửi đến hệ thống xử lý

→ Mô hình hóa hướng dữ liệu

Mô hình hành vi: Hướng dữ liệu

💡 Thường dùng cho các hệ thống nghiệp vụ (business system)

Module 5: System Modeling 4

 Biểu diễn chuỗi hoạt động xử lý dữ liệu đầu vào & kết xuất dữ liệu đầu ra tương ứng

Được hỗ trợ bởi biểu đồ hoạt động UML 2.0 hoặc biểu đồ tuần tự

Biểu đồ luồng dữ liệu (DFD) cho thao tác tiêm insulin

Khi nào sử dụng:

Khi bên cung cấp không biết nhiều về bên tiêu dùng

Phù hợp kịch bản một sự kiện có thể được xử lý bởi nhiều người sử dụng khác nhau

Các sự kiện có thể được xâu chuỗi thành 1 sự kiện phức tạp hơn

Overview

Pros Cons

Tập trung vào dữ liệu thực tế, giúp hiểu rõ hơn về

các quy tắc hoạt động của hệ thống
Dễ dàng mở rộng, linh hoạt hơn trong phát triển và
kiểm tra, xác minh
Tích hợp tốt với dữ liệu thực tế
Phụ thuộc chặt chẽ vào dữ liệu chính xác
Quản lý logic phức tạp và xử lý dữ liệu có thể không
rạch ròi
Không phù hợp cho mọi loại ứng dụng

Sự kiện: Kích hoạt xử lý hệ thống

→ Mô hình hóa hướng sự kiện

Mô hình hành vi: Hướng sự kiện

💡 Thường dùng cho các hệ thống thời gian thực (real-time system)

Biểu diễn cách hệ thống phản hồi các sự kiện từ bên ngoài & bên trong

Giả định: Hệ thống có một tập hữu hạn trạng thái

→ Các sự kiện kích hoạt chuyển trạng thái

Khi nào sử dụng:

Khi bên cung cấp không biết nhiều về bên tiêu dùng

Phù hợp kịch bản một sự kiện có thể được xử lý bởi nhiều người sử dụng khác nhau

Các sự kiện có thể được xâu chuỗi thành 1 sự kiện phức tạp hơn

Overview

Pros Cons

Sự kiện có thể được xử lý ở các mức độ khác nhau Khó khăn trong xử lý bất đồng bộ

Có thể phát sinh nhiều vấn đề phức tạp mới khi có

Giảm phụ thuộc giữa cung cấp - tiêu dùng
thêm các nhân tố xử lý mới
Dễ dàng phân sự kiện vào các luồng khác nhau & xử
Do thành phần không phụ thuộc nhau, lỗi xuất hiện
lý xong song, tạo điều kiện cho các bên tiêu dùng kịp
trong một thành phần có thể không được nhận ra
thời xử lý số lượng lớn sự kiện

Module 5: System Modeling 5

 Mô hình hành vi: Mô hình máy trạng thái

💡 Mô hình máy trạng thái (State Machine Model) mô hình hóa hệ thống, biểu diễn các hệ thống phản hồi
các sự kiện từ bên ngoài và bên trong.

Mô hình máy trạng thái mô tả hành vi của một đối tượng, hệ thống dựa trên trạng thái của nó và các quy tắc
chuyển đổi trạng thái

Khi nào sử dụng:

Thiết kế hệ thống có hành vi phụ thuộc vào trạng thái

Xử lý tương tác và luồng điều khiển

Phát triển các giao diện người dùng

Overview

Pros Cons

Rõ ràng, trực quan và dễ hiểu Không phù hợp với hệ thống phức tạp

Kiểm soát, quản lý hành vi hệ thống Khó thay đổi và bảo trì

Dễ kiểm tra và dỡ lỗi, theo dõi → Kiểm tra, xác định Phức tạp khi hệ thống có nhiều trạng thái và quy tắc
vấn đề khi chuyển đổi trạng thái chuyển đổi phức tạp

Kỹ nghệ hướng mô hình

💡 Phát triển phần mềm trong đó các mô hình được xem là các chế tác đầu ra cơ bản của quy trình phát triển

Các chương trình tương ứng với nền tảng thực thi nào đó thường được sinh tự động từ các mô hình bởi chuyển đổi mô
hình

Hướng tiếp cận này cho phép các kỹ sư làm việc ở cấp độ trừu tượng cao
→ Dễ giao tiếp với chuyên gia miền, giảm nỗ lực ánh xạ thiết kế sang diễn đạt chi tiết ở cấp độ ngôn ngữ lập trình

Pros Cons

Sai khác giữa các trừu tượng mức mô hình và

Xem xét hệ thống ở cấp độ trừu tượng cao
mức cài đặt
Chi phí tạo ra bộ chuyển đổi mô hình, bộ sinh mã
Sinh mã tự động
tự động

Module 5: System Modeling 6

 󾠳
Module 6: Architecture design (Thiết kế kiến trúc)
Định nghĩa kiến trúc phần mềm

💡 Kiến trúc phần mềm của hệ thống là tập hợp của các cấu trúc cần thiết để lập luận hệ thống bao gồm các phần tử,
các mối quan hệ giữa chúng và thuộc tính của cả 2

Sự quan trọng của kiến trúc phần mềm

Hỗ trợ cho giao tiếp giữa các bên liên quan (stakeholders)

Xác định các ràng buộc cho việc hiện thực hóa

Dự đoán chất lượng hệ thống

Nâng cao độ chính xác của việc dự đoán chi phí và thời gian xây dựng hệ thống

Một số khái niệm

Cấu trúc
Là một tập các phần tử (elements) và cách tổ chức chúng

3 loại cấu trúc

– Cấu trúc mô đun (module structures)
– Cấu trúc thành phần – kết nối (component-andconnector structures)
– Cấu trúc phân phối (allocation structures)

Mỗi loại cấu trúc thể hiện một khía cạnh khác nhau của hệ thống và chúng liên quan đến nhau

Mẫu kiến trúc

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

Ví dụ: phân lớp (layered pattern), chia sẻ dữ liệu (shared-data), khách-chủ (client-server)

Thuộc tính chất lượng

Được định nghĩa bao gồm:

Tính linh hoạt: Chúng ta có thể thay đổi thành phần X không?

Tính khả chuyển: Chúng ta có thể triển khai trên một máy khác không?

Tính sử dụng lại: Chúng ta có thể sử dụng lại một phần hay toàn bộ cho ứng dụng khác không?

Kiến trúc và thuộc tính chất lượng

Để có hiệu năng cao

Phân rã thành các tiến trình chạy song song

Quản lý lượng và tần suất dữ liệu truyền nhận giữa các tiến trình

Xác định “nút cổ chai” về hiệu năng trong hệ thống

Để có an ninh tốt

Phân quyền chức năng, bảo mật dữ liệu, an toàn khi sử dụng.

Cấu trúc phần mềm thành nhiều tầng

Các thuộc tính chất lượng

Thuộc tính thiết kế (Design qualities)

Thuộc tính thời gian thực thi (Run-time qualities)

Module 6: Architecture design (Thiết kế kiến trúc) 1

 Thuộc tính hệ thống (System qualities)

Thuộc tính người dùng (User qualities)

Thiết kế kiến trúc

Các 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 chính

Đây là những quyết định quan trọng khi thiết kế

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” (crosscutting concerns)

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

Các 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 kịch bản sử dụng chính
Kịch bản (scenarios) sử dụng chính là sự tổng quát của nhiều ca sử dụng (use case)

Các kịch bản 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, security…

Khía cạnh quan tâm chung: authentication, authorization, caching, exception handling,…

5. Giải pháp dự kiến

Là bản thiết kế kiến trúc ở mức cao

Module 6: Architecture design (Thiết kế kiến trúc) 2

 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

Một số kiểu kiến trúc

Kiểu Khách/Chủ (Client – Server)
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)

Cấu hình 1-1, 1-n, n-1

Trước đây, Client thường là ứng dụng chạy trên desktop; hiện nay có thêm Web browser và ứng dụng di động

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ụ cho các ứng dụng
khách dạng Web hoặc dạng khác

Kiểu phân lớp (Layered 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

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

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

Module 6: Architecture design (Thiết kế kiến trúc) 3

 Kiểu thành phần (Component based architecture)
Hệ thống được chia thành các thành phần độc lập, tương tác với nhau thông qua các giao diện

Các thành phần có thể thực thi phân tán

Kiểu bus thông điệp (Enterprise Service Bus)

Tương tác giữa các thành phần trong hệ thống được thực hiện bằng cách truyền thông điệp trên một bus chung (ESB)

Kiểu hướng dịch vụ (Service Oriented Architecture - SOA)

Chức năng của các ứng dụng được cung cấp dưới dạng dịch vụ

Các ứng dụng có thể được xây dựng dựa trên các dịch vụ (sử dụng các dịch vụ có trước)

Các dịch vụ có kết nối mềm dẻo, giao diện được chuẩn hóa, có thể được xuất bản (pubished), tìm kiếm (discovered),
gọi (invoked)

Module 6: Architecture design (Thiết kế kiến trúc) 4

Module 6: Architecture design (Thiết kế kiến trúc) 5
 󾠴
Module 7: Thiết kế giao diện người dùng ( UI
Design )
I. Tầm quan trọng của thiết kế giao điệ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.

→Hiệu quả sử dụng kém, khó dùng, không thân thiện,…

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

Đầu vào

Tài liệu đặc tả yêu cầu (e.g. biểu đồ ca sử dụng, 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

Xây dựng giao diện mẫu.

III. Yếu tố con người trong thiết kế UI

UI nên được thiết kế sao cho phù hợp với kỹ năng, trình độ, kinh nghiệm, độ tuổi, … 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.

IV. Các bước thiết kế

Phân tích người dùng

Người dùng đưa dữ liệu vào như thế nào ;

→ Có thuận tiện, dễ dàng hay không

Hệ thống cung cấp và biểu diễn dữ liệu ra sao cho người dùng như thế nào
→ (trực quan, dễ hiểu, giàu giá trị thông tin,…)

Thiết kế giao diện

Làm bản mẫu (prototype)

Sử dụng các phương pháp mô tả giao diện.

Xây dựng giao diện

Module 7: Thiết kế giao diện người dùng ( UI Design ) 1

 Thẩm định giao diện

V. Một số lưu ý
Trọng tâm cần xem xét khi thiết kế UI
Người dùng đưa dữ liệu/thông tin vào hệ thống như thế nào

Hệ thống cung cấp và biểu diễn dữ liệu ra sao cho người dùng như thế nào

Một số kiểu tương tác

1. Thao tác trực tiếp

2. Lựa chọn bằng thực đơn

3. Điền biểu mẫu (form)

4. Ngôn ngữ dòng lệnh

5. Ngôn ngữ tự nhiên

Các yếu tố hiển thị thông tin

Người dùng quan tâm đến giá trị hay mối quan hệ dữ liệu

Tốc độ thay đổi giá trị

Hiển thị dạng văn bản (Text) hay dạng đồ họa

Vd:

Vd1:

Một số phương pháp mô tả thiết kế UI

Cây lựa chọn theo thực đơn (Menu-selection trees)

Cây lựa chọn theo hộp thoại (Dialog-box trees)

Biểu đồ chuyển đổi màn hình (Transition diagrams)

Đo tính dễ dùng: các phép đo trực tiếp

Thời gian học để sử dụng

Người học điển hình học mất bao lâu để học các thao tác của một tác vụ?

Tốc độ thực hiện

Công việc làm thước đo (benchmark tasks): cần bao nhiêu thời gian để thực hiện một tác vụ?

Module 7: Thiết kế giao diện người dùng ( UI Design ) 2

 Tỷ lệ mắc lỗi của người sử dụng

Người sử dụng mắc lỗi nào và bao nhiêu lần khi thực hiện các công việc?

Nhớ được

Người dùng có nhớ được các kiến thức đã học bao lâu, vài giờ, vài ngày, hay vài tuần?

Sử dụng thường xuyên và dễ học sẽ làm người sử dụng nhớ lâu.

Hài lòng chủ quan

Mức độ hài lòng của người sử dụng với các khía cạnh của giao diện: màu sắc, bố trí thông tin, thao tác thuận tiện
dễ dùng,…?

Có thể thu thập thông tin này qua phỏng vấn, thu thập phản hồi không theo mẫu hoặc dùng thang điểm

Một số lưu ý
Người thiết kế muốn làm tốt trên mọi phương diện, nhưng thường phải cân đối ở mức độ nào đó (trade-off)
Ví dụ:

Tốc độ thực hiện với thời gian học

Tốc độ thực hiện với tỷ lệ lỗi

Các thiết kế khác nhau cần được đánh giá bởi người thiết kế và người sử dụng thông qua các bản mẫu.

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 dung, thông dụng, chứ
không dùng khái niệm chuyên môn phức tạp; cách bố trí sắp xếp thông tin hợp lý)

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,
…)

Đảm bảo tính an toàn (safety): các thao tác quan trọng phải đảm bảo người dùng luôn được lưu ý, nhắc nhở kịp thời,…

Có hướng dẫn người dùng (help, online manual)

Hướng tới đa dạng người dùng → phổ dụng

Sử dụng màu sắc trong thiết kế UI

Màu sắc có thể được sử dụng để làm nổi bật những phần quan trọng

Giới hạn số lượng màu được sử dụng

Nhất quán trong việc lựa chọn màu

Thông báo lỗi (Error message)

Thiết kế thông báo lỗi là phần việc quan trọng

Nội dung thông báo nên lịch sự, rõ ràng, nhất quán và có tính xây dựng

Thiết kế thông báo lỗi sao cho phù hợp với kỹ năng và kinh nghiệm của người dùng.

Thông báo lỗi tồi: thông báo lỗi hướng hệ thống

Thông báo lỗi tốt: thông báo lỗi hướng người dùng

Module 7: Thiết kế giao diện người dùng ( UI Design ) 3

 󾠵
Module 8: Thiết kế chi tiết

1. Thiết kế trong quy trình truyền thống (Phương pháp hướng cấu trúc)
Thiết kế xử lý
DFD (Data Flow Diagram) được sử dụng để phân
tích và thiết kế

DFD được làm mịn đến mức thấp nhất

Xây dựng biểu đồ cấu trúc (structure chart) dựa trên

các DFD

Làm mịn các biểu đồ cấu trúc đến mức có thể biểu
diễn bằng mã giả hoặc lưu đồ

Biểu đồ cấu trúc:

Thiết kế dữ liệu
Mô hình thực thể (ERM)

Khái niệm:
Đây là một mô hình dữ liệu được sử dụng để mô tả các thực thể trong một hệ thống và các quan hệ giữa chúng.
Trong ER model, các thực thể được biểu diễn dưới dạng các hộp (có thể đại diện cho các đối tượng, nhưng thường là
các bảng trong cơ sở dữ liệu). Các mối quan hệ giữa các thực thể được biểu diễn bằng các đường nối hoặc các mũi
tên, và có thể có các ràng buộc và quan hệ phụ thuộc giữa chúng.

Các bước chính xây dựng ERM

• Liệt kê, chính xác hoá và lựa chọn các thông tin cơ sở
• Xác định các thực thể, các thuộc tính và định danh
• Xác định các mối quan hệ và thuộc tính của mối quan hệ
• Vẽ biểu đồ mô hình thực thể - mối quan hệ
• Chuẩn hóa và thu gọn biểu đồ

Module 8: Thiết kế chi tiết 1

 Mô hình dữ liệu logic

Khái niệm:
Mô hình dữ liệu logic là một khái niệm trong lĩnh vực quản lý cơ sở dữ liệu để biểu diễn và mô tả các mối quan hệ
giữa các đối tượng dữ liệu trong một cơ sở dữ liệu. Nó định nghĩa cấu trúc, các quy tắc và ràng buộc dữ liệu trong cơ
sở dữ liệu mà không phụ thuộc vào bất kỳ hệ quản trị cơ sở dữ liệu cụ thể nào.

Các bước chính để xây dựng mô hình dữ liệu logic

Biểu diễn các thực thể

Nguyên tắc biểu diễn thực thể ERM thành quan hệ

Tên thực thể → tên quan hệ

Thuộc tính của thực thể → thuộc tính của quan hệ

Thuộc tính định danh → khóa của quan hệ

Một quan hệ có thể được biểu diễn ở dạng bảng hoặc ở dạng cấu trúc của lược đồ quan hệ

Biểu diễn các mối quan hệ

Mối quan hệ bậc 2, dạng 1-1: lấy khóa của một bên để vào bên còn lại

Mối quan hệ bậc 2, dạng 1-nhiều và không có thuộc tính riêng: lấy khóa của bên “1” để vào bên “nhiều”

Trường hợp còn lại: tạo quan hệ mới có các thuộc

tính là thuộc tính riêng của quan hệ và các thuộc
tính định danh của các thực thể tham gia mối
quan h

Chuẩn hóa các quan hệ

Chuẩn 1 (1NF)
Trong một quan hệ sẽ không có các nhóm lặp
→ Mỗi bản ghi (dòng trong bảng thực thể) là duy nhất,
thuộc tính (cột dữ liệu) chỉ chứa giá trị đơn
Một hàng trong bảng phải có một khóa chính
Chuẩn 2 (2NF)
Quan hệ là chuẩn 1NF và không chứa các phụ thuộc một
phần (phụ thuộc giữa một số thuộc tính vào một phần của
khóa)
→ Có tồn tại các phụ thuộc không hoàn toàn vào khóa chính
Chuẩn 3 (3NF)
Quan hệ là chuẩn 2NF và không chứa phụ thuộc bắc cấu (phụ
thuộc giữa một số thuộc tính vào thuộc tính không phải là
khóa)
→ Có tồn tại các phụ bắc cầu

Hợp nhất các mối quan hệ

Module 8: Thiết kế chi tiết 2

 Trong quá trình thiết kế, chúng ta có thể phát hiện thấy một số quan hệ thừa (vì các ERM có thể được xây
dựng từ các khung nhìn khác nhau)

Trong một số trường hợp, sau khi hợp nhất, có

thể cần phải chuẩn hóa (đặc biệt là mức 3

2. Phương pháp hướng đối tượng

Hệ thống bao gồm nhiều đối tượng

Cách xử lý và dữ liệu được đóng gói trong đối tượng

Quá trình thiết kế hệ thống là quá trình định nghĩa các lớp đối tượng và sự tương tác giữa chúng

Xác định lớp đối tượng

Một số cách được sử dụng để xác định lớp đối tượng

Phân tích theo khía cạnh ngữ pháp mô tả hệ thống (lớp đối tượng và thuộc tính thường là các danh từ)

Xem xét các đối tượng trong miền ứng dụng

Phân tích các ngữ cảnh sử dụng để xác định các lớp
đối tượng

Ở giai đoạn thiết kế, các lớp được có trong giai đoạn phân tích có thể được bỏ đi (controllers)

Các lớp mới có thể được thêm vào (collection)

Các thuộc tính và kiểu của thuộc tính sẽ được xác

định

Quan hệ kế thừa sẽ được xem xét

Thiết kế xử lý
Xác định phương thức (method) của lớp đối tượng
Một số phương thức được xác định trong quá trình
phân tích
– Thêm các phương thức để truy xuất thuộc tính
– Thêm các phương thức lấy các giá trị tính toán từ các
thuộc tính
– Thêm các phương thức do kinh nghiệm thấy cần thiết
– Thêm các phương thức do yêu cầu của framework,
pattern được sử dụng

Xác định mức độ truy xuất của các thuộc tính và phương thức
Private: chỉ trong lớp đối tượng
Package: trong cùng gói
Protected: lớp con và cùng gói
Public: mọi nơi

Ánh xạ lớp đối tượng vào CSDL

Lớp đối tượng được ánh xạ vào một bảng (thường sẽ có cùng tên)
Các thuộc tính với kiểu dữ liệu đơn giản (string, nguyên thủy) sẽ ánh xạ vào cột
Quan hệ One-to-one được thực hiện bằng cách thêm khóa từ một bảng vào bảng còn lại
Quan hệ One-to-many: thêm khóa của bảng phía “one” vào bảng “many”
Quan hệ Many-to-many: tạo bảng mới chứa khóa của cả hai bảng

Nguyên lý thiết kế HĐT

SRP (The Single Responsibility Principle): Một lớp đối tượng chỉ có duy nhất một lý do để thay đổi

Module 8: Thiết kế chi tiết 3

 OCP (The Open Closed Principle): Lớp đối tượng phải thiết kế sao cho dễ dàng mở rộng mà không cần phải thay đổi

LSP (The Liskov Substitution Principle): Các lớp con phải

thay thế được cho các lớp cha
ISP (The Interface Segregation Principle): Phân tách các giao diện sao cho client không phải phụ thuộc vào giao diện nó
không sử dụng

DIP (The Dependency Inversion Principle): Phụ thuộc vào lớp trừu tượng thay vì lớp cụ thể

UML
Sẽ có 2 loại mô hình được thiết kế

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ó thể sử dụng 3 mô hình cho quá trình thiết kế

Mô hình cấu trúc (thể hiện các nhóm lớp đối tượng có liên quan) → Biểu đồ lớp - Class Diagram

Mô hình tuần tự (thể hiện sự tương tác giữa các đối tượng) → Sequence Diagram, Communication Diagram - Biểu đồ
tuần tự, Biểu đồ giao tiếp

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) → State machine Diagram - Mô hình trạng thái
máy

Module 8: Thiết kế chi tiết 4

 󾠶
Module 9: Cài đặt phần mềm (Implementation)

1. Giới Thiệu:
Định nghĩa:

quá trình chuyển đổi thiết kế và ý tưởng của một phần mềm thành mã nguồn thực tế, có thể chạy được trên một hệ thống
máy tí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ả

2. 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ế

3.Phong cách lập trình:

Đặt tên biến, tên hàm:

Đặt tên biến, tên hàm có nghĩa, gợi nhớ:

Sử dụng các ký hiệu, từ Tiếng anh có nghĩa

Làm cho dễ đọc, dễ hiểu

Module 9: Cài đặt phần mềm (Implementation) 1

 Thí dụ: dateOfBirth hoặc date_of_birth
• Không viết dateofbirth

Tránh đặt tên quá dài

Tránh đặt tên dài với biến cục bộ

Thống nhất cách dùng

Tên lớp bắt đầu bằng chữ hoa

Tên hằng số toàn chữ hoa

Biến vòng lặp, chỉ số: i (iteration, index)

Dùng tiền tố để chỉ kiểu dữ liệu: i.e., sName (string), iCount (int), dTotal (double)

Câu lệnh:

Câu lệnh phải mô tả cấu trúc:

Tụt lề, dễ đọc, dễ hiểu

Làm đơn giản các câu lệnh

Mỗi lệnh trên 1 dòng

Triển khai các biểu thức phức tạp

Hạn chế truyền tham số là kết quả của hàm, biểu thức:

Tránh các cấu trúc phức tạp

Các lệnh if lồng nhau

Điều kiện phủ định if not

Ví dụ:

Vd1:

Vd2:

Module 9: Cài đặt phần mềm (Implementation) 2

 Vd3:

4.Chú thích:
Chú thích rất quan trọng: hỗ trợ đáng kể tính dễ đọc và dễ bảo trì của mã nguồn.

Cách viết chú thích:

1. Mục đích sử dụng của các biến

2. Các câu lệnh phức tạp: i.e., gọi đến hàm khác

3. Chú thích các mô đun:

Chi tiết cần chú thích:

Mục đích, chức năng của mô đun

Tham số, giá trị trả lại

Cấu trúc, thuật toán

Ý nghĩa của các biến cục bộ

Người viết, thời gian sửa đổi mô đun

Cách viết :

Viết chú thích cho File

Viết chú thích cho Lớp

Module 9: Cài đặt phần mềm (Implementation) 3

 Viết chú thích cho Hàm

Lưu ý:

Không cần chú thích cho những câu lệnh đã “rõ

ràng”

5.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

Viết mã nguồn để tái sử dụ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 tổng quát (generic programming)

Phần mềm sinh mã tự động (generators)

Kế thừa, đa hình, giao diện thống nhất,…

Module 9: Cài đặt phần mềm (Implementation) 4

 Quản lý các phiên bản mã nguồn:

Quản lý quá trình chỉnh sửa mã nguồn của một

nhóm phát triển phần mềm

Các khái niệm cơ bản:

Repository (kho lưu trữ):

Lưu trữ dự án chung của đội phát triển phần mềm

Working copies

Check out: Lấy dự án từ server về máy cục bộ

Commit: Đưa các thay đổi lên server

Update: Cập nhật thay đổi từ thành viên khác về máy cục bộ

Merge: Nhiều thành viên cập nhật trên một tệp tin

….

Các loại công cụ quản lý phiên bản:

Tập trung:

Mỗi người dùng lấy bản sao làm việc của riêng mình, nhưng chỉ có một kho lưu trữ trung tâm.

CVS (Concurrent Versions System) và SVN (SubVersioN)

→ Tránh conflic hoặc out of update

Phân tán:

Mỗi người dùng có kho lưu trữ của riêng mình và bản sao làm việc.

Git, Mercurial

→An toàn hơn so với quản lý tập trung

Module 9: Cài đặt phần mềm (Implementation) 5

 6.Gỡ lỗi:
Debug (gỡ lỗi) là một kĩ năng nền tảng của lập trình viên:

Phân tích lỗi của chương trình xuất phát từ nguyên do gì.

Loại bỏ lỗi (errors) khỏi chương trình

Hiểu rõ hơn sự thực thi của chương trình

Các phương pháp gỡ lỗi

Debugging Tool:

Dùng công cụ để debug

Microsoft Visual Studio Debugger , GNU Debugger

Printlining:

Thêm dòng lệnh để in ra những thông tin cần theo dõi

Logging:

Ghi lại những thông tin sau khi chương trình thực thi

Module 9: Cài đặt phần mềm (Implementation) 6

 🔟
Module 10: Testing
I. Kiểm chứng và thẩm định
Đặt vấn đề
Phần mềm được phát triển để phục vụ yêu cầu KH

Yêu cầu khách hàng được biểu diễn bằng đặc tả yêu cầu (requirements)

Thất bại ⇒ Phần mềm không đáp ứng đúng như đặc tả yêu cầu
Nguyên nhân

Đặc tả sai?

Thiết kế sai?

Cài đặt sai?

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)

Phân loại
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

Chất lượng và độ tin cậy

Chất lượng = sự thỏa mãn của sp so với đặc tả

Chất lượng Phần mềm = “độ tốt, độ tuyệt hảo”

Tính đúng đắn (đúng đặc tả)

Tính hiệu quả

Độ tin cậy

Khả kiểm thử

Dễ học, dễ sử dụng

Dễ bảo trì

Độ tin cậy chỉ là một yếu tố để đánh giá chất lượng SP

Là độ đo quan trọng

Module 10: Testing 1

 II. Kiểm thử PM
Định nghĩa
Là hoạt động chủ chốt nhằm đánh giá chất lượng PM

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

Các hoạt động trong quá trình kiểm thử

Điều kiện kiểm thử (“Cái gì”): một phần tử hoặc sự kiện cần kiểm tra

Làm thế nào để có thể kiểm tra được: thực hiện

Xây dựng các ca kiểm thử (mã, dữ liệu)

Chạy hệ thống với các ca kiểm thử

So sánh kết quả thu được và kết quả mong đợi

Các thành phần cần có

Ca kiểm thử (test case)

Bộ kiểm thử (các ca kiểm thử)

Báo cáo kiểm thử

Tiêu chí đánh giá một 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)

Các loại kiểm thử

Kiểm thử hộp đen Kiểm thử hộp trắng

Còn gọi là kiểm thử hàm, kiểm thử chức năng Còn gọi là kiểm thử cấu trúc, kiểm thử logic

Tập trung vào cấu trúc thuật toán của chương

Tập trung vào hành vi vào/ra (đầu vào/đầu ra)
trình

Thay vì thử hết đầu vào, ta sẽ giảm số lượng ca Kiểm tra những gì đã được làm, tuy nhiên
kiểm thử bằng việc chia không gian đầu vào đường đi nhiều khi vô hạn Tiêu chuẩn bao phủ: -
thành các miền tương đương – Sau đó chọn một Dòng lệnh - Nhánh - Đường thực thi(Tất cả các
ca kiểm thử từ mỗi miền tương đương này. khả năng chạy của chương trình) - Vòng lặp

So sánh giữa kiểm thử hộp trắng và hộp đen

Hộp trắng

Số đường đi nhiều khi là vô hạn

Kiểm tra những gì đã làm, không phải những gì cần được làm

Khá phức tạp khi kiểm thử hệ thống và tích hợp

Hộp đen

Dễ bùng nổ tổ hợp về số ca kiểm thử (dữ liệu đúng và dữ liệu sai)

Thường không chắc ca kiểm thử này có phát hiện được lỗi cụ thể
hay không

Thích hợp cho tất cả các cấp độ kiểm thử

Cần cả hai

Module 10: Testing 2

 Kiểm thử hộp trắng và hộp đen là hai thái cực của kiểm thử

Việc lựa chọn ca kiểm thử nằm giữa và phụ thuộc vào

Số đường đi logic có thể

Tính chất của dữ liệu đầu vào

Khối lượng tính toán

Độ phức tạp của cấu trúc dữ liệu và giải thuật

Hai chiến lược là bổ sung cho nhau.

Kiểm thử hồi quy

Khi một hệ thống được chỉnh sửa (sửa lỗi, thêm/bớt chức năng,..) toàn bộ bộ kiểm thử cần phải chạy lại

Đảm bảo các tính năng đang hoạt động tốt không bị ảnh hưởng bởi chỉnh sửa

Kiểm thử lại tự động trước khi lưu thay đổi vào kho (repository.)

Cần các chiến lược kiểm thử tăng dần với hệ thống lớn

Gỡ lỗi
Kiểm thử
– Khẳng định có lỗi → có phát hiện tồn tại lỗi không, với đầu vào như thế nào.

Gỡ lỗi (debugging)
– Định vị và sửa lỗi → phân tích và tìm nguyên nhân gây ra lỗi

Gỡ lỗi thông thường phải lập giả thuyết về hành vi của chương trình và kiểm tra các giả thuyết này để tìm lỗi

Phân loại các lỗi và sai

1 Nhẹ Lỗi chính tả

2 Vừa Hiểu nhầm hoặc thưa thông tin

3 Khó chịu Tên bị thiếu, cụt chữ

4 Bực mình Yêu cầu không được xử lý

5 Nghiêm trọng Mất yêu cầu trong quá trình thực hiện

6 Rất nghiêm trọng Xử lí yêu cầu sai

7 Cực kỳ nghiêm trọng Lỗi rất nghiêm trọng xảy ra thương xuyên

8 Qúa quắt Hủy hoại cơ sở dữ liệu

9 Thảm họa Hệ thống bị tắt

10 Dịch họa Thảm họa lây lan

Các mức kiểm thử

Kiểm thử mức đơn vị
Mục đích: Tìm sự khác biệt giữa đặc tả và cài đặt của đơn vị

Đơn vị: các lớp, hàm, đối tượng, gói, mô-đun

Module 10: Testing 3

 Kiểm thử mức tích hợp
Mục tiêu: Phát hiện vấn đề khi ghép các mô-đun/thành phần với
nhau

Các vấn đề

Bên trong: giữa các thành phần

Gọi: call/message passing/…

Tham số: kiểu, số lượng, thứ tự, giá trị

Kết quả trả về: ai, kiểu, trình tự

Bên ngoài:

Ngắt kết nối (wrong handler?)

Thời gian vào ra

Tương tác

Kiểm thử mức hệ thống

Liên quan đến các yếu tố bên ngoài hệ thống

Không chỉ là kiểm tra chức năng

Khả dụng (usability)

Giao diện, thông báo, dễ học, dễ nhớ, dễ dùng, thuận tiện, …

Hiệu năng

Khả năng đáp ứng/Tìm khả năng đáp ứng

Tài nguyên sử dụng

Kiểm thử mức chấp thuận

Có hai loại kiểm thử chấp nhận

Bởi cơ quan phát triển gọi là BAT

Bởi người dùng gọi là UAT

Mục đích: kiểm tra sự hài lòng của người sử dụng

Cơ sở: mong muốn của người dùng (không xét đến tài liệu đặc tả)

Môi trường: thật

Người thực hiện: người sử dụng

Module 10: Testing 4

 Các ca kiểm thử:

Sử dụng lại từ kiểm thử hệ thống

Do người dùng thiết kế

Nên dừng kiểm thử khi nào

Hết thời gian, hết ngân sách

Đạt mức độ bao phủ mong muốn

Đạt tần suất hỏng hóc mong muốn

III. Một số phương pháp kiểm thử cơ bản

Kiểm thử dựa trên phân tích giá trị biên
Tổng quan
Các chương trình có thể coi là một hàm (toán học)

Các đầu vào chương trình là miền xác định của hàm

Các đầu ra là miền giá trị của hàm

Phân tích giá trị biên (boundary value analysis - BVA) là kỹ thuật kiểm thử hàm phổ biến nhất

Mục tiêu của kiểm thử hàm là sử dung kiến thức về hàm để xác định các ca kiểm thử

Trước kia chủ yếu tập trung vào miền xác định, nhưng nay đã dựa trên cả miền giá trị của hàm để xác định ca
kiểm thử

Phân tích giá trị biên (boundary value analysis - BVA)

Phân tích giá trị biên tập trung vào biên của miền xác định để xây dựng ca kiểm thử

Lý do là lỗi thường xảy ra ở gần các giá trị biên này

Chương trình viết bằng ngôn ngữ không có kiểm tra kiểu mạnh càng cần kiểm thử giá trị biên (VD : JavaScirpt,
Php, Visual Basic)

Chọn giá trị

Phân tích giá trị biên sẽ chọn các giá trị:

Giá trị nhỏ nhất

Ngay trên giá trị nhỏ nhất

Một giá trị bình thường

Ngay dưới giá trị lớn nhất

Giá trị lớn nhất

Tổng quát hóa

Có hai cách tổng quát hóa :

Theo số biến, sẽ có (4n +1) ca kiểm thử cho n biến

Theo loại khoảng của biến

Phụ thuộc ngôn ngữ lập trình

Tính rời rạc của biến

Tính rời rạc không bị chặn (không có cận trên và cận dưới rõ ràng)

Biến logic

Ưu nhược điểm
Ưu điểm

BVA hiệu quả với các chương trình có các đầu vào độc lập nhau và biểu diễn đại lượng vật lý bị chặn

Nhược điểm

BVA lấy các ca kiểm thử mà không tính đến chức năng của hàm, hay ý nghĩa của các biến

Kiểm thử biên mạnh

Module 10: Testing 5

 Là một mở rộng đơn giản của BVA

Ngoài năm giá trị biên bổ sung thêm hai giá trị ngoài biên:

Giá trị ngay trên giá trị cực đại (max+) và

Giá trị ngay dưới giá trị cực tiểu (min-).

Mục đích chính là xem chương trình có kiểm tra giá trị hợp lệ của đầu vào không.

Kiểm thử trường hợp xấu nhất

Điều gì xảy ra khi nhiều hơn một biến nhận các giá trị (gần) cực trị?

Khi các biến có tương tác với nhau thì cần kiểm tra các bộ giá trị kết hợp các cực trị này

Có thể kết hợp với kiểm thử mạnh để có bộ kiểm thử trường hợp xấu nhất mạnh

Kiểm thử giá trị đặc biệt

Kiểm thử giá trị đặc biệt là phương pháp được thực hiện nhiều nhất trên thực tế, nó cũng trực quan nhất, và không
có dạng cố định nhất

Sử dụng kỹ nghệ và kiến thức miền ứng dụng để phán đoán và đưa ra ca kiểm thử

Mặc dù mang tính chủ quan cao, đây vẫn là phương pháp hiệu quả để phát hiện khiếm khuyết của chương trình

Kiểm thử lớp tương đương

Định nghĩa phân lớp tương đương
Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào của một chương trình thành
nhiều lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử. Phương pháp này cố gắng xác định ra một ca kiểm thử mà làm
lộ ra một lớp lỗi, do đó làm giảm tổng số các trường hợp kiểm thử phải được xây dựng.

Ví dụ : “Giá trị x chỉ có thể dao động từ 0 đến 10”.

Lớp tương đương hợp lệ: 0 <=x <= 10

2 lớp tương đương không hợp lệ: x < 0 và x > 10

Ý tưởng
Ý tưởng của ECT (Elementary comparison testing) là chỉ kiểm thử với một phần tử của mỗi miền tương đương

Giảm rất nhiều dư thừa tiềm tàng nếu các lớp tương đương được chọn hợp lý

Mấu chốt là làm sao chọn được quan hệ tương đương để từ đó xác định được các lớp tương đương (phân hoạch)

Chọn phân hoạch

Thường là “thủ công” (craft):

Không dựa trên mã nguồn, chỉ dựa trên đặc tả

Cần hiểu biết về miền xác định, thường không thể xác định dựa vào đặc tả thiết kế giao diện

Phải hiểu đầu vào phụ thuộc nhau như thế nào

Phân loại ECT

ECT yếu
ECT yếu chỉ lấy tất cả các phần tử đại diện ít nhất một lần

Số ca kiểm thử tối thiểu sẽ bằng số lớp của phân hoạch có nhiều tập con nhất

Ví dụ cho ECT yếu

Xét chương trình P có ba biến đầu vào: a, b và c với các miền xác định là A, B, and C.

Phân hoạch của các miền này giả sử là:

A = A1 U A2 U A3
B = B1 U B2 U B3 U B4
C = C1 U C2

⇒ Số ca kiểm thử tối thiểu là 4

ECT mạnh
ECT mạnh dựa trên tích Đề-các của các lớp con

Module 10: Testing 6

 Cách này xét đến tất cả các tương tác của các giá trị đại diện

Ví dụ cho ECT mạnh

Từ ví dụ ở ECT yếu, số ca kiểm thử sẽ là 3 x 4 x 2 = 24 ca

ECT truyền thống

Chỉ phân biệt giá trị hợp lệ và không hợp lệ

Kiểm thử dựa trên bảng quyết định

Tổng quan về bảng quyết định (Determination Table)
DT là một cách chính xác và gọn để mô tả logic phức tạp

Gắn các điều kiện với các hành động tương ứng

Giống lệnh if-then-else và switch-case

DT có thể liên kết nhiều điều kiện độc lập với vài hành động một cách dễ hiểu

Khác các cấu trúc điều khiển trong các ngôn ngữ lập trình

Tác dụng của bảng quyết định

Để quan sát tất cả các điều kiện dễ dàng

Có thể dùng để

Mô tả logic phức tạp

Sinh ca kiểm thử, còn gọi là kiểm thử dựa trên logic

Kiểm thử dựa trên logic được xem là:

Kiểm thử cấu trúc khi áp dụng cho các cấu trúc chương trình
(Vd luồng điều khiển)

Kiểm thử hàm khi áp dụng cho đặc tả.

Cấu trúc bảng quyết định

1. Các điều kiện 2. Các giá trị điều kiện

3. Hành động 4. Xảy ra hay không

1. Mỗi điều kiện tương ứng với một biến, một quan hệ, hoặc một
mệnh đề (predicate)

2. Các giá trị của điều kiện

– Chỉ là True/False – Bảng quyết định hạn chế
– Một số giá trị – Bảng quyết định mở rộng
– Giá trị không quan tâm

3. Mỗi hành động là một thủ tục hoặc thao tác phải thực hiện

4. Đánh dấu hành động có/không xảy ra

Phương pháp xây dựng bảng

1. Xác định các điều kiện và giá trị của chúng

2. Xác định số luật tối đa

3. Xác định các hành động

4. Đánh số các luật nếu cần

5. Đánh số các hành động thích hợp cho mỗi luật

6. Kiểm tra chính sách

7. Đơn giản hóa các luật (gộp cột)

Khi nào sử dụng

Bảng thích hợp khi:

Đặc tả có thể chuyển về dạng bảng

Thứ tự các hành động xảy ra không quan trọng

Module 10: Testing 7

 Thứ tự các luật không ảnh hưởng đến hành động

Khi một luật thỏa mãn và được chọn thì không cần xét luật khác

Các hạn chế trên không ảnh hưởng đến việc sử dụng bảng

Trong hầu hết các ứng dụng thứ tự các mệnh đề được xét là không quan trọng

Một số lưu ý
Trước khi sử dụng bảng cần đảm bảo:

Các luật phải đầy đủ

Có mọi tổ hợp

Các luật phải nhất quán

Mọi tổ hợp giá trị chân lý chỉ gây ra một hoặc một tập hành động

Thiết kế ca kiểm thử

Nhận xét
Khi đặc tả đã được kiểm tra, mục tiêu là chứng tỏ chương trình thực hiện các hành động đúng cho mọi tổ hợp
các giá trị của mệnh đề

Nếu có k luật và n mệnh đề đúng/sai, thì có ít nhất k trường hợp và nhiều nhất là 2^n trường hợp phải xét.

Có thể dựa trên các luật chưa mở rộng hoặc các luật đã mở rộng với 2^n ca

Xác định đầu vào cho mỗi ca

Để xác định ca kiểm thử, chúng ta chuyển các điều kiện thành đầu vào, hành động thành đầu ra.

Một số điều kiện sẽ tham chiếu đến các lớp tương đương đầu vào, và hành động tham chiếu đến các phần xử lý
chức năng chính của cột đang xét.

Các luật được chuyển thành các ca kiểm thử

Module 10: Testing 8

 󾠷
Module 11: Project Management(Quản lý phần
mềm)
I. Quy trình quản lý các dự án CNTT
Dự án và các đặc trưng của dự án
Định nghĩa dự án
Dự án là tập các công việc được thưc hiện bởi một nhóm người có chuyên môn nhằm tạo ra một sản phẩm/ dịch vụ duy
nhất thông qua việc sử dụng nguồn lực dự kiến và được thực hiện trong một môi trường đầy biến động

Các đặc trưng của dự án

Hoạt động để đạt tới một mục tiêu xác định

Có thời điểm bắt đầu và kết thúc (dự kiến)

Có ràng buộc về thời gian, chi phí, nhân lực

Có nhiều rủi ro, nhiều vấn đề, thay đổi, …

Được thực hiện bởi một tổ chức/nhóm

Có nhiều bên liên quan với nhu cầu và mối quan

tâm khác nhau

Nội dung công việc, nguồn lực thay đổi tùy theo
từng pha

Dự án CNTT và dự án Phần mềm

Dự án CNTT

Sản phẩm: Một hệ thống thông tin

Đa số các dự án ở VN là dự án CNTT

Dự án phần mềm

Sản phẩm: Một phần mềm/ dịch vụ phần mềm

Quản lý dự án
Tiêu chí của một dự án thành công
Thỏa mãn phạm vi, thời gian và kinh phí

Thỏa mãn Khách hàng/Chủ đầu tư

Tất cả các bên liên quan đều hài lòng

Quản lý dự án
Định nghĩa
Là áp dụng các nguyên lý, phương pháp, kỹ thuật, công cụ, và đặc biệt là kinh nghiệm nhằm:

Định nghĩa dự án

Lập kế hoạch

Triển khai, tổ chức thực hiện

Kiểm tra giám sát

Kết thúc dự án

Là lập thế hoạch và thực hiện các công việc theo đúng kế hoạch đã lập

Vai trò
Tăng khả năng thành công của dự án, giảm thiểu rủi ro

Đảm bảo có một kế hoạch đúng đắn để thực hiện các mục tiêu của dự án

Module 11: Project Management(Quản lý phần mềm) 1

 Đảm bảo chất lượng của công việc đang được triển khai và thực hiện là đúng như kỳ vọng và tiến độ

Khách hàng có thể theo dõi được những gì bạn thực hiện có đúng với mục tiêu ban đầu không

Học được từ những thành công và thất bại của quá khứ

etc …

Thành phần cấu tạo

Quản lý về kỹ thuật: công việc, tiến độ, ngân sách, chất lượng

Quản lý về con người :

Con người và các tổ chức liên quan đến dự án

Thường là vấn đề chính ảnh hưởng đến sự thành bại của dự án

Cần phát triển các kỹ năng mềm: suy nghĩ, trao đổi, giao tiếp, trình bày, …

Quy trình quản lý dự án

Chuẩn bị, xác định dự án

Lập kế hoạch dự án

Tổ chức, thực hiện dự án

Kiểm tra, giám sát

Kết thúc dự án

Các bên tham gia

Quản lý dự án

Tài trợ dự án

Tổ dự án

Khách hàng

Quản lý cấp cao

Khoán ngoài (bên thứ 3)

II. Kiểm tra giám sát các dự án CNTT

Kiểm soát việc thực hiện dự án
Vai trò của PM (quản lý dự án)
Xây dựng kế hoạch kỹ lưỡng

Cố gắng thực hiện theo kế hoạch ( nếu có vấn đề: điều tra nguyên nhân, tìm giải pháp khắc phục và thay đổi kế
hoạch (nếu cần) )

Thực hiện, điều phối và kiểm soát dự án

Lựa chọn thông tin để điều phối

Nhận diện các điểm quyết định và kiểm soát

Phân tích tiến độ và hiệu năng dự án

Tổ chức họp đánh giá thường kỳ

Lường trước và giải quyết vấn đề

Thông tin cho các bên liên quan

Ước lượng thời gian hoàn thành các pha

Họp đánh giá dự án:
Lúc đề xuất dự án, lúc bắt đầu dự án

Lúc hoàn thành mỗi pha/giai đoạn

Lúc kết thúc dự án

Trong trường hợp khẩn cấp (có vấn đề lớn)

Module 11: Project Management(Quản lý phần mềm) 2

 Ước lượng cái gì?
Mục tiêu của từng pha theo kế hoạch

Các mục cần quản lý và kiểm soát

Đầu ra?

Phương pháp quản lý

Đánh giá, rút kinh nghiệm và lập lại kế hoạch

Xác định các mục đích cần đánh giá

Xây dựng kế hoạch đánh giá

Tổ chức học hỏi và đánh giá lại

Kết thúc dự án: cái gì xong? Tiếp theo là gì?

Liên hoan và học hỏi:

Bài học rút ra:

Kiểm soát vấn đề

Nhiều vấn đề chắc chắn sẽ phát sinh

Cần tìm ra sớm và có giải pháp thích hợp

Tạo không khí/môi trường làm việc để các vấn đề dễ dàng được bộc lộ

Khi giải quyết vấn đề

Có báo cáo, đảm bảo các người liên quan được biết và có cơ chế phản hồi

Những vấn đề phổ biến

Chậm trễ trong xác định yêu cầu và thiết kế

Khách hàng hay thay đổi yêu cầu

Nhiều công việc trùng lặp/làm lại -> tải công việc tăng

Chậm trễ/hủy bỏ trong việc đưa ra các gói PM theo lịch trình

Mất thành viên chủ chốt

Thiếu hành động của người ký hợp đồng

Báo cáo trạng thái dự án

So sánh thực trạng và kế hoạch, có hành động sửa chữa nếu cần thiết

Chia các mốc thời gian để quản lý

Kiểm soát tiến độ dự án

Hiểu trạng thái tiến độ
Nhận báo cáo từ các thành viên về tiến độ

Tổ chức họp thường kỳ để đánh giá tiến độ

Mục đích của quản lý tiến độ

Hiểu trạng thái tiến độ so với kế hoạch

Phát hiện các vấn đề

Lập các giải pháp sửa chữa, giải quyết

Thủ tục kiểm soát tiến độ

Thu thập thông tin từ các thành viên và các bên liên quan

So sánh trạng thái thực tế với kế hoạch

Phân tích vấn đề và cập nhật ds vấn đề

Tìm các giải pháp giải quyết

Làm báo cáo kiểm soát tiến độ

Module 11: Project Management(Quản lý phần mềm) 3

 III. Triển khai, vận hành và nâng cấp các hệ thống CNTT
Vận hành hệ thống
Chuẩn bị nhân lực và cơ sở hạ tầng CNTT

Chuẩn bị dữ liệu

Quy trình nghiệm vụ và chính sách mới

Các vấn đề phát sinh khi triển khai

Chi phí thường xuyên

An toàn, bảo mật

Giảm nhân công

Bảo trì, nâng cấp hệ thống

Đây là vấn đề không thể tránh khỏi

Lỗi phát sinh (do test không hết)

Thay đổi/bổ sung quy trình nghiệp vụ

Thay đổi môi trường (phần cứng, PM, …)

Phải có cam kết với đối tác

– Công ty phát triển PM phải có trách nhiệm trọn đời với sản phẩm
– Đảm bảo chất lượng và tăng khả năng dễ bảo trì

IV. Một số bài học rút ra từ thực tiễn quản lý dự án CNTT ở Việt Nam
Một số vấn đề
Các dự án CNTT ở VN được coi là các dự án đầu tư cơ bản và mua sắm trang thiết bị (không tính đến đầu tư vào con
người)

Quản lý dự án thường kiêm nhiệm nhiều việc -> không có QLDA thực sự, không được đào tạo bài bản, thiếu tri thức,
kinh nghiệm

Không coi trọng vai trò tư vấn hoặc khoán trắng cho nhóm dự án

Không có quan hệ chặt chẽ với người thụ hưởng

Ngân sách eo hẹp -> khó có kinh phí vận hành, bảo trì

Phát sinh cơ chế xin – thẩm định – cho/k cho

Người có quyền thì không làm và ngược lại

Thiếu tư duy chiến lược (làm theo hướng dẫn, …)

Chủ yếu gọi thầu, khoán ngoài: chất lượng không đảm bảo

Một số giải pháp

Cử quản lý dự án giỏi, có tư duy chiến lược

Lập kế hoạch bài bản: WBS, lịch biểu, …

Tổ chức nhóm bài bản, có HTTT hỗ trợ

Lập quy trình kiểm tra giám sát chặt chẽ

Lập HT hồ sơ giám sát hợp đồng khoán ngoài chặt chẽ, đầy đủ

Kiểm soát đầu ra của dự án: tiêu chuẩn nghiệm thu sản phẩm, tài liệu, …

Lựa chọn nhà thầu, nhà cung cấp tốt nhất

Tổ chức nhóm làm việc hiệu quả

Sử dụng chuyên gia giỏi

Sử dụng người hợp lý

Sâu sát trong quản lý

Module 11: Project Management(Quản lý phần mềm) 4

 Quản lý chặt chẽ tiến độ

Một số bài học

Quản lý dự án tích hợp
Quản lý dự án là quản lý tích hợp, theo nghĩa: với mỗi công việc cũng như toàn thể dự án, người quản lý phải nghĩ
đến nhiều vấn đề khác nhau:

Phạm vi công việc là gì? Thời hạn hoàn thành ntn? Chi phí để thực hiện? Các tiêu chí và quy trình để đảm bảo
chất lượng?

Ai sẽ thực hiện? Cách giao tiếp như thế nào? Các rủi ro và cách quản lý? Quản lý thay đổi ntn? Có những bên
liên quan nào và quản lý như thế nào?

Cuối cùng, làm thế nào để tích hợp các vấn đề trên trong một quy trình quản lý thống nhất?

Thách thức khi làm việc với chủ đầu tư

Lý do:

Là sếp trực tiếp của PM

Là người đưa ra nhiều thay đổi cho dự án liên quan đến thiết kế, tài chính, nhân sự...

Do bận công việc nên thường phản hồi chậm các vấn đề liên quan đến dự án, làm ra tăng sức ép về tiến độ

Các lý do khác về cá tính, chuyên môn, quan hệ...

Lựa chọn nhà thầu tốt

Đối tác tốt sẽ mang lại hiệu quả và chất lượng cao và không phải là người gây cản trở
Tiêu chí chọn đối tác

Profile tốt: trên 5 năm kinh nghiệm, 10 năm là tốt nhất, có năng lực hiện tại tốt, lãnh đạo mạnh, tài chính tốt

Đã làm các dự án tương tự cho các khách hàng có yêu cầu cao

Tham quan văn phòng, công trình, gặp gỡ khách hàng và lãnh đạo của đối tác tiềm năng

Quản lý nhóm làm việc

Làm việc nhóm là yếu tố rất quan trọng, quyết định thành công của dự án

Tập hợp trí tuệ nhóm, giải pháp bất ngờ, hiệu quả

Giảm bớt gánh nặng công việc và tư duy cho người quản lý

Tăng cường nhiệt huyết của mọi người, tạo được động lực trong công việc

Triết lý: giỏi mấy cũng không thể biết hết mọi việc

Sử dụng chuyên gia giỏi

Đội dự án không thể biết mọi lĩnh vực công nghệ liên quan đến dự án

Quyết định sai có thể gây hậu quả nặng nề về chất lượng, chi phí và việc vận hành, khai thác sản phẩm của dự án
trong tương lai

Ý kiến của chuyên gia giỏi là cơ sở để ra quyết định và thuyết phục lãnh đạo cấp trên

Sử dụng người hợp lý

Mỗi cán bộ dự án có sở trường, sở đoản riêng

PM không thể thay đổi con người họ → cách tốt nhất là đúng người, đúng việc

Biết được điểm mạnh của cán bộ dự án thông qua CV, quá trình làm việc, trao đổi trực tiếp và thử nghiệm

Nếu không đúng phải thay đổi ngay

Sâu sát trong quá trình triển khai

Nhiệm vụ của người quản trị là P D-C A (Lập kế hoạch – Thực hiện – Kiểm tra – hành động)

Thực tế rất phong phú và khác khá xa so với những gì bạn biết trong phòng họp

Giải pháp có thể nảy sinh từ thực tiễn on-site

Module 11: Project Management(Quản lý phần mềm) 5

 Các thành viên dự án sẽ tin tưởng PM hơn nếu thường thực có mặt, trực tiếp làm việc với nhà thầu, tư vấn, nhà
cung cấp dịch vụ, …

Quản lý dự án – bạn là nhà lãnh đạo

Phải có cái nhìn tổng thể về dự án, các bên liên quan, các hạng mục công việc, ...

Luôn biết đâu là việc đúng cần phải làm (danh sách công việc, WBS, Project network, Grant chart là các công cụ
hữu ích)

Luôn biết ai là người phù hợp. Cổ vũ, động viên kịp thời

Luôn biết nhấn mạnh ý nghĩa của từng công việc

Quản trị chặt chẽ tiến độ

Hiểu thấu đáo các công việc hiện tại, tương lai để tránh bị bất ngờ không lường trước

Luôn có thời gian dự phòng (quản lý rủi ro)

Tiến độ thường là sức ép lớn nhất dành cho dự án và có rất nhiều nguyên nhân gây chậm chễ tiến độ

Minh bạnh, chính trực

Đây là nền tảng cho dự án thành công

Là nền tảng cho hiệu quả và chất lượng

Làm gương

Nhân viên không tin tưởng, anh không thể làm được gì.

Xây dựng mối quan hệ tốt

Với tất cả các bên liên quan

Đặc biệt là với lãnh đạo của đối tác (họ quyết định trong mọi công việc)

Tôn trọng đối tác, mình sẽ được tôn trọng

Làm việc với lãnh đạo sẽ quyết được nhiều việc, nhanh và hiệu quả

Cấp dưới của đối tác sẽ nỗ lực hơn

Phải là nhà đàm phán giỏi

PM có thể không phải là người kí song luôn là người đàm phán

Bạn có thể mang lại lợi ích lớn cho cty thông qua đàm phán

Làm cho đối tác tin tưởng và tôn trọng dù có đạt được thỏa thuận hay không

Quản trị chất lượng

Lúc triển khai dự án người ta luôn luôn bị thức ép về tiến độ, song dự án càng đến thời điểm hoàn tất các vấn đề về
chất lượng càng lộ rõ

Chất lượng chỉ thật sự cao khi mọi nội dung của quản trị dự án rch hợp được hoàn tất tốt

Sử dụng đúng người đúng việc

Cần rất sâu sát và sử dụng chuyên gia, không bao giờ chỉ nghe báo cáo

Đóng gói và làm tài liệu

Làm đến đâu đóng gói đến đó

Văn bản hóa tối đa

Module 11: Project Management(Quản lý phần mềm) 6