Đề Cương Tự Luận Nhập môn Công nghệ phần mềm KHTN 2017

Tuần 1: Tổng quan

Phần mềm
Định nghĩa:
- Chương trình + tài liệu
- Luôn gắn với một hệ thống cụ thể.
- Các sản phẩm phần mềm có thể được phát triển cho một khách hàng cụ thể hoặc cho thị trường
chung
Phân loại :
- Generic products (Sản phẩm dùng chung): Những hệ thống độc lập được chào bán trên thị trường
và bất cứ ai cũng có thể mua chúng. VD: Microsoft Office, Photoshop
- Customized products (Sản phẩm đặt hàng): Phần mềm được phát triển cho một khách hàng cụ thể
để đáp ứng nhu cầu của họ. VD: Phần mềm điều khiển không lưu
- Sự khác biệt: Sản phẩm dùng chung do người phát triển hệ thống đặc tả và do họ quyết định và
thực hiện thay đổi. Còn Sản phẩm đặt hàng do khách hàng.
Tiêu chí:
Maintanability (Tính bảo trì được): Có thể cải tiến phù hợp nhu cầu
Dependability & Security (Tính tin cậy được): Độ tin cậy, an toàn & bảo mật
Efficiency (Tính hiệu quả): không lãng phí tài nguyên
Acceptability (Tính chấp nhận được): Ng sử dụng chấp nhận

CNPM
Định nghĩa: Là lĩnh vực liên quan đến khía cạnh của sản xuất phần mềm
Chi phí:
- Chi phí phát triển: 60%
- Chi phí kiểm thử : 40%

Quy trình PM
ĐN: Một chuỗi các hoạt động để tạo ra một sản phẩm phần mềm
Đặc tả  Phát triển  Thẩm định  Cải tiến
Thử thách chính:

- Tính không đồng nhất (hệ thống càng được yêu cầu như một hệ phân tán qua mạng bao gồm
nhiều loại thiết bị)
- Sự thay đổi của xã hội và thương mại (Xã hội và thương mại không ngừng thay đổi vì kinh tế phát
triển và công nghệ mới ra đời.)
- Bảo mật & tin cậy (Vì phần mềm liên quan đến tất cả các mặt của đời sống)

Các loại ứng dụng (8) :
- Ứng dụng độc lập
- Ứng dụng dựa vào giao dịch tương tác
- Ứng dụng điều khiển nhúng
- Hệ thống xử lý khối
- Hệ thống giải trí
- Hệ thống mô phỏng & mô hình hóa
- Hệ thống thu thập dữ liệu
- Hệ thống của hệ thống

Nguyên tắc:
- Tái sử dụng
- Sử dụng quy trình
- Hiệu năng
- Yêu cầu và đặc tả

CNPM & Web
Xu hướng tương lai
Cloud computing
Phụ thuộc: Trình duyệt

Đạo đức nghề nghiệp

Pháp luật
Trung thực
Trách nhiệm:


- Bảo mật
- Năng lực
- Quyền sở hữu trí tuệ
- Lạm dụng máy tính
Một số câu hỏi thường gặp
1. Công nghệ phần mềm là gì?
Công nghệ phần mềm là một lĩnh vực công nghệ liên quan đến tất cả các khía cạnh của việc sản
xuất phần mềm từ giai đoạn đặc tả hệ thống đến giai đoạn bảo trì hệ thống sau khi nó đã được
đưa vào sử dụng
2. Những hoạt động cơ bản (activities) của CNPM?
3. Sự khác nhau giữa CNPM và khoa học máy tính (computer science)?
Khoa học máy tính (computer science) tập trung vào lý thuyết và nền tảng.
CNPM liên quan đến những thực tiễn của việc phát triển và phân phối sản phẩm phần mềm.
4. Sự khác nhau giữa CNPM và công nghệ hệ thống (system engineering)?
Công nghệ hệ thống (system engineering) gồm tất cả các khía cạnh của việc phát triển các hệ
thống máy tính bao gồm cả phần cứng, phần mềm và quy trình.
CNPM là một phần của quy trình chung đó.
5. Những thử thách chính mà công nghệ phần mềm phải đối mặt?
6. Chi phí của CNPM?
Khoảng 60% chi phí phần mềm là chi phí phát triển phần mềm, 40% là chi phí dành cho kiểm thử
phần mềm.
Đối với phần mềm đặt hàng, chi phí để cải tiến phần mềm lớn hơn chi phí sản xuất phần mềm.
7. Kỹ thuật và phương pháp CNPM tốt nhất?
Tất cả các dự án phần mềm đều phải được quản lý và phát triển một cách chuyên nghiệp. Các kỹ
thuật và phương pháp khác nhau phù hợp với các loại hệ thống khác nhau.

Không có phương pháp nào tốt nhất!
8. Quy trình phần mềm (software process) là gì?
Một chuỗi các hoạt động để tạo ra một sản phẩm phần mềm.


Có 4 hoạt động cơ bản chung nhất cho tất cả các quy trình phần mềm.
Tổng kết
Công nghệ phần mềm là lĩnh vực công nghệ liên quan đến tất cả các khía cạnh của việc sản xuất
phần mềm.
Tiêu chí của một sản phẩm phần mềm là tính bảo trì được, tính tin cậy được, tính hiệu quả và tính
chấp nhận được.
Những hoạt động cơ bản của quy trình phần mềm là đặc tả, phát triển, thẩm định và cải tiến phần
mềm.
Những khái niệm cơ bản của CNPM hoàn toàn có thể áp dụng cho tất cả các loại phát triển hệ
thống.
Có nhiều loại hệ thống khác nhau và mỗi loại cần những công cụ và kỹ thuật CNPM phù hợp để phát
triển.
Bài 2: Quy trình phần mềm
Khái niệm : là một tập có cấu trúc các hoạt động cần thiết để phát triển một hệ thống phần mềm.

Mô hình
Quy trình hoạch định sẵn và quy trình linh hoạt
- Các quy trình hoạch định sẵn (plan-driven process) là các quy trình mà trong đó tất cả các hoạt
động được lên kế hoạch trước và tiến độ thực hiện được đánh giá dựa vào kế hoạch này.
-Trong các quy trình linh hoạt (agile process), kế hoạch được phát triển dần dần và dễ dàng thay
đổi quy trình để đáp ứng sự thay đổi yêu cầu của khách hàng.
Thác nước (waterfall model)
- Mô hình hoạch định sẵn. Các pha đặc tả và phát triển phân biệt và tách rời nhau.

- Ưu điểm:
•
•
•

Dễ quản lý tiến độ
Được sử dụng trong các hệ thống lớn mà được phát triển tại nhiều địa điểm khác nhau
Phối hợp công việc dễ dàng

- Nhược điểm:
•
•

Khó thích nghi thay đổi
Khó khăn đáp ứng thay đổi yêu cầu người dùng

Phát triển dần dần (incremental development)
- Các pha đặc tả, phát triển và thẩm định đan xen nhau. Có thể là mô hình hoạch định sẵn, có thể là
mô hình linh hoạt

- Ưu điểm:
•

Giảm chi phí đáp ứng sự thay đổi yêu cầu của khách hàng


•
•

Dễ dàng lấy phản hồi từ khách hàng.

Phân phối và triển khai phần mềm đến khách hàng nhanh hơn

- Nhược điểm
•
•

Quy trình không rõ ràng.
Cấu trúc hệ thống có xu hướng bị giảm đi vì những phần mới của hệ thống được thêm vào.

Tái sử dụng (reuse-oriented software engineering)

- Hệ thống được xây dựng từ những component có sẵn. Có thể là hoạch định sẵn, có thể là linh hoạt
- Các giai đoạn của quy trình
•
•
•
•

Phân tích component
Bổ sung yêu cầu
Thiết kế hệ thống với việc tái sử dụng
Phát triển và tích hợp

- Các loại component: Web service, Package, COTS
Xoắn ốc Boehm
Quy trình được biểu diễn như một đường xoắn ốc hơn là một chuỗi tuần tự các hoạt động với các
bước quay lui.
Mỗi vòng lặp trong đường xoắn ốc biểu diễn một pha của quy trình.
Không có những pha cố định như đặt tả hay thiết kế, các vòng lặp trong đường xoắn ốc được chọn
theo nhu cầu.

Rủi ro được đánh giá rõ ràng và được giải quyết trong suốt quy trình.


- Ưu điểm:
•
•
•
•

Là phương pháp thực tế để phát triển các hệ thống phần mềm lớn.
Giúp các kỹ sư hiểu rõ và tương tác tốt hơn với các nguy cơ tại mỗi mức tiến hóa.
Cho phép áp dụng nguyên bản tại bất cứ giai đoạn tiến hóa nào.
Giảm được các nguy cơ trước khi nó trở thành vấn đề của hệ thống.

- Nhược điểm:
•
•
•

Không phải là “thuốc chữa bách bệnh”.
Khó khăn trong việc thuyết phục khách hàng rằng phương pháp này có thể điều khiển được.
Cần chuyên gia đánh giá về nguy cơ và dựa vào chuyên gia để thành công. Nếu một nguy cơ
lớn không được tìm ra và quản lý được, các vấn đề về hệ thống sẽ xảy ra.

Các hoạt động
1. Đặc tả: ĐN hệ thống làm gì
- Quy trình công nghệ yêu cầu (requirements engineering process)
•
•
•

•

Nghiên cứu 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 yêu cầu (Requirements validation)


2. Thiết kế & cài đặt: ĐN tổ chức của hệ thống & cài đặt hệ thống
- Thiết kế Kiến trúc
- Thiết kế Giao diện
- Thiết kế Component
- Thiết kế CSDL

3. Kiểm định: Kiểm tra rằng hệ thống đáp ứng được mong muốn của người dùng


- Các giai đoạn kiểm thử phần mềm:
•
•
•

Kiểm thử trong khi phát triể n(Development or component testing)
Kiểm thử hệ thống
Kiểm thử người dùng

4. Cải tiến: thay đổi hệ thống để đáp ứng sự thay đổi yêu cầu người dùng.

Thích nghi sự thay đổi
Thay đổi yêu cầu

- Là điều hiển nhiên trong dự án lớn
- Thay đổi  Làm lại
Giảm thiểu chi phí làm lại
- Tránh thay đổi: dự đoán trước những thay đổi có thể xảy ra (VD: phát triển prototype)
- Chấp nhận thay đổi:
•
•

Chi phí thay đổi thấp
Thường dùng mô hình phân phối dần dần

Nguyên bản PM
- Là phiên bản đầu tiên của một hệ thống được dùng để demo những khái niệm và thử các tùy chọn
thiết kế, tìm giải pháp cho một vấn đề
- Dùng trong trường hợp:
•
•
•

Thu thập yêu cầu và thẩm định yêu cầu
Tìm ra các giải pháp và phát triển thiết kế giao diện người dùng
Chạy các kiểm thử back-to-back.

- Lợi ích:
•
•
•
•
•

Cải thiện khả năng sử dụng hệ thống.
Thoả mãn tốt hơn nhu cầu thực của người dùng.
Cải thiện chất lượng thiết kế.
Cải thiện khả năng bảo trì hệ thống.
Giảm bớt nỗ lực phát triển.


Nguyên bản có phải là cái cơ bản để phát triển hệ thống hay không?
Nguyên bản không phải là cái cơ bản để phát triển hệ thống  cần được loại bỏ. Do:
•
•
•
•

Khó có thể điều chỉnh hệ thống để đáp ứng được các yêu cầu phi chức năng
Nguyên bản thường không được viết tài liệu
Cấu trúc nguyên bản thường bị phá vỡ do bị thay đổi nhanh
Nguyên bản có thể không đáp ứng được những tiêu chuẩn chất lượng về mặt tổ chức

So sánh Chuyển giao dần dần và Phát triển dần dần?
Phát triển dần dần
•
•
•

Phát triển từng phần hệ thống và đánh giá mỗi phần trước khi tiến hành phát triển phần
tiếp theo
Được sử dụng trong các phương pháp linh hoạt
Đánh giá được thực hiện bởi đại diện người sử dụng/khách hàng.

Chuyển giao dần dần
•
•

Triển khai một phần để sử dụng cho người dùng cuối
Đánh giá thực tế hơn.

Quy trình RUP (The Rational Unified Process)
Khái niệm
- Là một quy trình tổng quát bắt nguồn từ UML và Unified Software Development Process.
- Kết hợp các khía cạnh của ba mô hình quy trình tổng quát
- Thường mô tả ba góc độ: Góc độ động, Góc độ tĩnh, Góc độ về thực tiễn
Các pha RUP:
- Khởi động, Phát triển, Xây dựng, Chuyển tiếp
Vòng lặp RUP
- Lặp trong từng pha, Lặp qua các pha
Ưu điểm:
- Phát triển phần mềm theo vòng lặp
- Quản lý yêu cầu


- Sử dụng kiến trúc dựa vào component
- Mô hình hóa phần mềm một cách trực quan
- Kiểm tra chất lượng phần mềm
- Điều khiển các thay đổi phần mềm

Tuần 4: Quản trị dự án phần mềm
Tổng quan
Tiêu chí:
- Phân phối phần mềm đến khách hàng đúng thời gian.

- Đảm bảo tổng chi phí luôn nằm trong mức cho phép.
- Phân phối phần mềm thỏa mãn mong đợi khách hàng.
- Duy trì một nhóm phát triển vui vẻ và hoạt động hiệu quả.
Đặc thù:
- Sản phẩm không hữu hình.
- Nhiều dự án phần mềm là các dự án 'one-off’.
- Các quy trình phần mềm dễ thay đổi và phụ thuộc vào tổ chức phát triển phần mềm, nghĩa là nó
không được chuẩn hóa
Các hoạt động quản trị:
- Lên kế hoạch dự án
- Viết báo cáo
- Quản lý rủi ro
- Quản trị con người
- Viết đề xuất
Lập kế hoạch dự án
Lập kế hoạch:
- Phân bố công việc thành từng phần và gán từng phần cho các thành viên
- Dự đoán các vấn đề phát sinh và giải pháp
- Có bản kế hoạch dự án
Giai đoạn:
- Giai đoạn đề xuất: khi ta bid một hợp đồng để phát triển hay cung cấp một hệ thống phần mềm.


- Trong pha khởi động dự án: khi ta phải lập kế hoạch ai sẽ làm việc trong dự án, dự án được phân
rã thành từng phần như thế nào, và tài nguyên được phân phối như thế nào, ....
- Định kỳ trong suốt dự án: khi ta thay đổi bản kế hoạch dựa vào kinh nghiệm thu được và thông tin
về việc theo dõi tiến độ công việc...
Kế hoạch lập lịch
- Milestones: là các giai đoạn trong dự án mà tại đó việc đánh giá tiến độ được thực hiện.
- Deliverables: các sản phẩm phân phối cho khách hàng

Các kỹ thuật ước lượng
- Các kỹ thuật dựa vào kinh nghiệm
- Mô phỏng chi phí dựa vào thuật toán


Quản lý rủi ro
Nội dung:
- Nhận diện các rủi ro
- Lên kế hoạch để giảm thiểu rủi ro

Quy trình:
- Nhận diện rủi ro: Công nghệ, ước lượng, con người, tố chất, yêu cầu


- Phân tích rủi ro: rất thấp, thấp, bt, cao, rất cao; Hậu quả: rất trầm trọng, trầm trọng, có thể bỏ
qua, không đáng kể

- Lập kế hoạch về rủi ro

- Quản trị rủi ro


Quản lý con người
Các nhân tố giá trị:
- Tính nhất quán ( đối xử như nhau)
- Sự tôn trọng (sự khác nhau về kỹ năng cần tôn trọng)
- Tính bao hàm (mọi quan điểm đều đc xem xét)
- Tính trung thực (dự án đang xấu nói xấu, tốt nói tốt)

Thúc đẩy con người:
- Nhu cầu cơ bản (ăn, ngủ ...);
- Nhu cầu cá nhân (tôn trọng, tự trọng...);
- Nhu cầu xã hội (được chấp nhận như một phần của nhóm)
Các loại cá tính:
- Hướng tác vụ (Động lực để làm việc là công việc của chính họ)
- Hướng bản nhân (Công việc là một phương tiện để đạt được mục tiêu cá nhân. Ví dụ: làm giàu,
chơi tennis)
- Hướng tương tác ( Mục tiêu chính là sự hiện diện và tương tác với đồng nghiệp.)
Làm việc nhóm
Tính gắn kết nhóm (các thành viên xem nhóm quan trọng hơn cá nhân trong nhóm)
Tính hiệu quả của nhóm (Giao tiếp tốt, tổ chức sao cho cá nhân đóng góp tốt nhất, . . . )
Tổ chức nhóm( Phương pháp phát triển linh hoạt, có thể dùng cấu trúc phân cấp,..)
Chọn các thành viên nhóm (chọn trưởng nhóm tốt...)


Tập hợp 1 nhóm (không cần ng best, cần ng fit)
Kết hợp nhóm (các tviên có cân bằng về động lực)
Giao tiếp nhóm (càng lớn càng khó giao tiếp, giao tiếp qua kênh mxh,..)
Nhóm phi hình thức (Phương pháp này thành công đối với các nhóm trong đó các thành viên có khả
năng và kinh nghiệm)

Tuần 5 - 6: Yêu cầu phần mềm
Yêu cầu người dùng (user requirement) // Viết cho khách hàng
- Những phát biểu (bằng ngôn ngữ tự nhiên kết hợp với các biểu đồ) về các dịch vụ mà hệ thống
cung cấp và những ràng buộc về hoạt động của nó.
Yêu cầu hệ thống (system requirement)
- Một tài liệu có cấu trúc mô tả chi tiết chức năng của hệ thống, các dịch vụ và ràng buộc về hoạt
động của hệ thống.
VD:

Yêu cầu người dùng
1. Hệ thống MHC-PMS sẽ phát sinh báo cáo tổng kết hàng tháng về giá cả của thuốc được kê đơn bởi
mỗi phòng khám trong suốt tháng đó.
Yêu cầu hệ thống
1.1 Vào ngày làm việc cuối cùng của mỗi tháng, xuất ra một bản tóm tắt các loại thuốc được kê đơn,
giá cả của mỗi loại thuốc và tên phòng khám kê đơn thuốc.
1.2 Hệ thống sẽ tự động sinh ra báo cáo để in ấn sau 17.30 của ngày làm việc cuối cùng của tháng.
1.3 Một báo cáo sẽ được tạo ra cho mỗi phòng khám và sẽ liệt kê: tên thuốc, tổng số đơn thuốc, liều
lượng, và tổng chi phí cho thuốc được kê đơn.
1.4 Nếu thuốc sử dụng ở nhiều loại đơn vị khác nhau (ví dụ 10mg, 20ml) thì phải tách riêng thành
các báo cáo khác nhau cho mỗi đơn vị thuốc.
1.5 Việc truy cập vào các báo cáo giá thuốc chỉ dành riêng cho một danh sách hạn chế những người
sử dụng
Yêu cầu chức năng & phi chức năng
Yêu cầu chức năng
- Mô tả dịch vụ hệ thống cung cấp
VD:
Yêu cầu chức năng cho hệ thống MHC-PMS
1. Một người sử dụng có thể tìm kiếm danh sách các lịch hẹn trong tất cả các phòng khám.


2. Hàng ngày, với mỗi phòng khám, hệ thống sẽ tự động tạo ra một danh sách các bệnh nhân có hẹn
ngày hôm đó.
3. Mỗi nhân viên của phòng khám sử dụng hệ thống sẽ được nhận diện bởi mã nhân viên gồm có 8
chữ số.
Yêu cầu phi chức năng
- Là những yêu cầu không liên quan trực tiếp đến những dịch vụ mà hệ thống cung cấp đến người
dùng.
- Phân loại yêu cầu phi chức năng
•

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

Yêu cầu đặc tả hay ràng buộc về thuộc tính của phần mềm.
Ví dụ: yêu cầu về hiệu năng của phần mềm liên quan đến tốc độ thực thi, lượng bộ nhớ sử dụng, độ
tin cậy, ...
•

Yêu cầu tổ chức

Yêu cầu xuất phát từ các chính sách và thủ tục về mặt tổ chức.
Ví dụ: yêu cầu về quy trình hoạt động, yêu cầu về quy trình phát triển, môi trường phát triển và
chuẩn về quy trình được sử dụng...
•

Yêu cầu bên ngoài

Yêu cầu xuất phát từ những nhân tố bên ngoài ảnh hưởng đến hệ thống và quy trình phát triển của
nó. Ví dụ: yêu cầu về tương tác, yêu cầu về mặt pháp lý, ...
VD:
Yêu cầu phi chức năng của hệ thống MHC-PMS
Yêu cầu sản phẩm
Hệ thống MHC-PMS sẽ luôn hoạt động để các phòng khám sử dụng trong suốt giờ làm việc (từ thứ 2
đến thứ 6, 8.30 – 17.30). Thời gian ngừng hoạt động trong suốt giờ làm việc sẽ không vượt quá sẽ
không vượt quá 5s trong bất kỳ ngày nào.
Yêu cầu tổ chức
Người sử dụng hệ thống sẽ phải tự đăng nhập bằng thẻ nhân viên của họ.
Yêu cầu bên ngoài
Hệ thống sẽ cài đặt các quy định về tính riêng tư của bệnh nhân.
Đặc tả yêu cầu

ĐN: Là quy trình viết những yêu cầu người dùng và yêu cầu hệ thống vào tài liệu yêu cầu.
Đặc tả bằng ngôn ngữ tự nhiên
- VD:


Yêu cầu của hệ thống bơm insulin
3.2 Hệ thống sẽ đo lượng đường trong máu và bơm insulin 1 lần/phút nếu cần thiết. (Nhưng thay
đổi về lượng đường trong máu khá chậm vì thế việc đo quá thường xuyên là không cần thiết; nếu số
lần đo ít quá có thể dẫn đến lượng đường trong máu cao).
3.6 Hệ thống sẽ chạy một lộ trình tự kiểm tra mỗi phút với các điều kiện để kiểm tra và các hành
động liên quan được định nghĩa. (Một lộ trình tự kiểm tra có thể tìm ra các lỗi phần cứng và phần
mềm và báo cho người sử dụng biết là hệ thống không thể hoạt động bình thường được).
Đặc tả bằng ngôn ngữ có cấu trúc
- Nhược điểm: Cứng nhắc
- VD:

Đặc tả dùng bảng (dùng hỗ trợ ngôn ngữ tự nhiên)
- VD:


Các quy trình công nghệ yêu cầu
ĐN: Tập hợp các tác vụ và kỹ thuật để hiểu rõ các yêu cầu được gọi là công nghệ yêu cầu.
Hoạt động:
- Nghiên cứu khả thi (Feasibility study);
- Thu thập yêu cầu (Requirements elicitation);
- Phân tích yêu cầu (Requirements analysis);
- Thẩm định yêu cầu (Requirements validation);
- Quản trị yêu cầu (Requirements management)
Phụ thuộc:
- Tổ chức viết yêu cầu

- Người liên quan
- Miền ứng dụng
Thu thập và phân tích yêu cầu
Nhận diện yêu cầu (tìm ra yêu cầu của stakeholder)
- Là quá trình tập hợp các thông tin về các yêu cầu hệ thống đề xuất và các hệ thống đang tồn tại
- Chọn lọc các yêu cầu người dùng và yêu cầu hệ thống từ những thông tin này.
- VD:

- Phương pháp nhận diện yêu cầu
•
•

Phỏng vấn
Kịch bản


•

Use case : kỹ thuật dựa vào kịch bản bằng ngôn ngữ UML để chỉ ra các tác nhân (actor)
trong một tương tác và Mô tả chính tương tác đó.

Tổ chức và phân loại (phân nhóm các yêu cầu)
Đặt độ ưu tiên và thương lượng (and giải quyết xung đột)
Đặc tả yêu cầu (Viết yêu cầu thành tài liệu và tiếp tục quay lại bước 1)
Thẩm định yêu cầu : Chứng tỏ rằng yêu cầu định nghĩa được hệ thống mà khách hàng cần
Tiêu chí kiểm tra yêu cầu:
- Tính hợp lệ (chức năng có đáp ứng tốt nhu cầu ng dùng ko?)
- Tính nhất quán (có xung đột ko?)
- Tính đầy đủ (đủ chức năng ko?)
- Tính thực tế (có thể cài đặt các yêu cầu vs ngân sách & công nghệ cho trước?)

- Tính kiểm định được (làm sao kiểm tra yêu cầu?)
Kỹ thuật kiểm định yêu cầu:
- Duyệt lại yêu cầu (Phân tích một cách có hệ thống các yêu cầu)
- Phân bản thử nghiệm (Sử dụng một mô hình chạy được của hệ thống để kiểm tra các yêu cầu)
- Sinh ra các test case (Phát triển các test cho các yêu cầu để kiểm tra khả năng test được hay
không.)
Quản trị yêu cầu
Quy trình quản lý thay đổi yêu cầu:


Tài liệu yêu cầu phần mềm
ĐN:
- Tài liệu yêu cầu phần mềm là phát biểu chính thức về những gì mà người phát triển hệ thống phải
cài đặt.
- Thông tin trong tài liệu phụ thuộc vào loại hệ thống và phương pháp phát triển được sử dụng.
Ng sử dụng: Khách hàng, quản lý, kỹ sư hệ thống, tester, ...

Tuần 7-8 : Mô hình hóa phần mềm
Định nghĩa:


Là quy trình phát triển các mô hình trừu tượng của một hệ thống, trong đó mỗi mô hình biểu diễn
một góc nhìn.

Mô hình ngữ cảnh : Minh họa ngữ cảnh vận hành của hệ thống
Ranh giới hệ thống: định nghĩa cái gì bên trong và bên ngoài hệ thống
Góc nhìn về mặt quy trình:
- Chỉ ra các hệ thống khác trong môi trường
- Được sử dụng cùng mô hình quy trình nghiệp vụ

Mô hình tương tác : Hỗ trợ việc nhận diện các yêu cầu người dùng
Dùng use case và biểu đồ tuần tự :
- Use case: Biểu diễn tác vụ rời rạc và tương tác bên ngoài
- Biểu đồ tuần tự: Tương tác actor và đối tượng trong hệ thống


Mô hình cấu trúc : hiển thị cấu trúc hệ thống về các component & mối quan hệ của chúng
Biểu đồ lớp : Chỉ ra các lớp & mối quan hệ

Tổng quát hóa:
- Dùng quản lý độ phức tạp
- Lớp con kế thừa lớp cha và bổ sung