KỸ THUẬT PHẦN MỀM
Chương V: Các pha trong phát triển phần mềm
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
Khoa Điện tử Viễn Thông – Bộ môn Điện tử Tin học
Nội dung
5.1 Đặt vấn đề
5.1.1. Đặc điểm của phần mềm
5.1.2. Các vấn đề của phát triển phần mềm
5.1.2. Các mô hình phát triển phần mềm
5.1.4. Các kỹ thuật thế hệ thứ 4
5.2 Các pha trong phát triển phần mềm
5.2.1. Nghiên cứu yêu cầu (Requirements and Specifications)
5.2.2. Phân tích và thiết kế (System Analysis and Design)
5.2.3. Triển khai (Coding and Unit Test)
5.2.4. Thử nghiệm (Test)
5.2.5. Cài đặt và bảo trì (Deployment and Maintenance)

5.1.1. Đặc điểm của phần mềm
Đặc tính chung của phần mềm:
Là hàng hóa vô hình, không nhìn thấy được
Chất lượng phần mềm: không mòn đi mà có xu hướng tốt lên sau mỗi lần có lỗi (error/bug) được phát hiện và sửa
Phần mềm vốn chứa lỗi tiềm tàng, theo quy mô càng lớn thì khả năng chứa lỗi càng cao
Lỗi phần mềm dễ được phát hiện bởi người ngoài
Chức năng của phần mềm thường biến hóa, thay đổi theo thời gian (theo nơi sử dụng)
Hiệu ứng làn sóng trong thay đổi phần mềm
Phần mềm vốn chứa ý tưởng và sáng tạo của tác giả/nhóm làm ra nó
Có thể sao chép rất đơn giản
5.1.1. Đặc điểm của phần mềm
Các chỉ tiêu cơ bản
Phản ánh đúng yêu cầu người dùng (tính hiệu quả - effectiveness)
Chứa ít lỗi tiềm tàng
Giá thành không vượt quá giá ước lượng ban đầu
Dễ vận hành, sử dụng
Tính an toàn và độ tin cậy cao
5.1.1. Đặc điểm của phần mềm
PHẦN MỀM
“Chỉ có 26% các dự án phần mềm là thành công”
Standish Group
Report 1998
Ngày càng phức tạp.
Yêu cầu triển khai nhanh.
Yêu cầu chất lượng cao.
Nhưng…
5.1.2. Các vấn đề của phát triển phần mềm
Hiểu sai yêu cầu của người dùng
Không có khả năng đáp ứng tốc độ thay đổi nhanh chóng của yêu cầu
Các modules không ghép được với nhau
Phần mềm làm ra khó bảo trì và nâng cấp
Phát hiện muộn các sai lầm trong dự án
Chất lượng phần mềm thấp
Các thành viên trong nhóm không cùng nỗ lực
Quá trình xây dựng và phát hành không tin cậy
Nguyên nhân cơ bản của các vấn đề…
Thiếu việc quản lý yêu cầu
Giao tiếp không chính xác hay mơ hồ
Kiến trúc ứng dụng yếu
Quá phức tạp
Không phát hiện được sự mâu thuẫn giữa yêu cầu, thiết kế và thực thi
Kiểm thử không đủ
Đánh giá tình trạng dự án theo chủ quan
Sự chậm trễ trong việc giảm rủi ro do áp dụng mô hình thác nước
Không kiểm soát được sự thay đổi lan truyền
Thiếu tự động hóa

Các yếu tố thành công của phần mềm
Bắt đầu bằng đối xử đúng với đúng quyền hạn
Luôn quan tâm, chăm sóc định kỳ
Luôn theo dõi ghi chép tiến trình
Ra quyết định đúng đắn, sáng suốt
Tiến hành phân tích đúc rút bài học kết thúc dự án.
Vòng đời phần mềm (Software life-cycle)
Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không đâu dùng)
Quy trình phần mềm (vòng đời phần mềm) được phân chia thành các pha chính: phân tích, thiết kế, chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng người
Vòng đời phần mềm (Software life-cycle)
Mô hình vòng đời phần mềm của Boehm
Xác định yêu
cầu hệ thống
Kiểm chứng
Xác định yêu
cầu phần mềm
Kiểm chứng
Thiết kế
căn bản
Kiểm chứng
Thiết kế
chi tiết
Kiểm chứng
Lập trình
Gỡ lỗi
Kiểm thử
Chạy thử
Vận hành
Bảo trì
Kiểm chứng lại
Vòng đời phần mềm (Software life-cycle)
(1) Pha xác định yêu cầu và thiết kế có vai trò quyết định đến chất lượng phần mềm, chiếm phần lớn công sức so với lập trình, kiểm thử và chuyển giao phần mềm
(2) Pha cụ thể hóa cấu trúc phần mềm phụ thuộc nhiều vào suy nghĩ trên xuống (top-down) và trừu tượng hóa, cũng như chi tiết hóa
(3) Pha thiết kế, chế tạo thì theo trên xuống, pha kiểm thử thì dưới lên (bottom-up)
Vòng đời phần mềm (Software life-cycle)
(4) Trước khi chuyển sang pha kế tiếp phải đảm bảo pha hiện nay đã được kiểm thử không còn lỗi
(5) Cần có cơ chế kiểm tra chất lượng, xét duyệt giữa các pha nhằm đảm bảo không gây lỗi cho pha sau
(6) Tư liệu của mỗi pha không chỉ dùng cho pha sau, mà chính là đối tượng quan trọng cho kiểm tra và đảm bảo chất lượng của từng quy trình và của chính phần mềm
Vòng đời phần mềm (Software life-cycle)
(7) Cần chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu cho từng pha, nhằm đảm bảo chất lượng phần mềm
(8) Thao tác bảo trì phần mềm là việc xử lý quay vòng trở lại các pha trong vòng đời phần mềm nhằm biến đổi, sửa chữa, nâng cấp phần mềm
Phương pháp luận và kỹ thuật cho từng pha
5.1.3. Các mô hình phát triển phần mềm
A. Mô hình tuyến tính (Cascade model)
B. Mô hình bản mẫu (Prototype model)
C. Mô hình phát trển ứng dụng nhanh (RAD)
D. Mô hình xoắn ốc (Siral model)
E. Các mô hình khác

A. Mô hình tuyến tính (Cascade model)
Phân tích
Thiết kế
Lập trình
Kiểm thử
System engineering
and model
Điển hình là mô hình vòng đời cổ điển
(mô hình thác nước) Classic life cycle /
waterfall model: là mô hình hay đựoc dùng nhất
A. Mô hình tuyến tính (Cascade model)
System engineering and modeling:
Phân tích yêu cầu (Requirements analysis)
Thiết kế (Design)
Tạo mã / lập trình (Code generation / programming)
Kiểm thử (Testing)
Hỗ trợ / Bảo trì (Support / Maintenance)
A. Mô hình tuyến tính (Cascade model)
Nhược điểm của mô hình tuyến tính:
Thực tế các dự án ít khi tuân theo dòng tuần tự của mô hình, mà thường có lặp lại (như mô hình của Boehm)
Khách hàng ít khi tuyên bố rõ ràng khi nào xong hết các yêu cầu
Khách hàng phải có lòng kiên nhẫn chờ đợi thời gian nhất định mới có sản phẩm. Nếu phát hiện ra lỗi nặng thì là một thảm họa!
B. Mô hình bản mẫu (Prototype model)
Nghe Khách
trình bày
Tạo / sửa
bản mẫu
Khách kiểm tra
bản mẫu
B. Mô hình bản mẫu (Prototype model)
Khi mới rõ mục đích chung chung của phần mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao hoặc chưa rõ yêu cầu đầu ra
Dùng như “Hệ sơ khai” để thu thập yêu cầu người dùng qua các thiết kế nhanh
Các giải thuật, kỹ thuật dùng làm bản mẫu có thể chưa nhanh, chưa tốt, miễn là có mẫu để thảo luận gợi yêu cầu của người dùng
C. Mô hình phát trển ứng dụng nhanh (RAD)
Rapid Application Development
Là quy trình phát triển phần mềm gia tăng, tăng dần từng bước (Incrimental software development) với mỗi chu trình phát triển rất ngắn (60-90 ngày)
Xây dựng dựa trên hướng thành phần (Component-based construction) với khả năng tái sử dụng (reuse)
Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hình xử lý, Tạo ứng dụng, Kiểm thử và đánh giá (Business, Data, Process, Appl. Generation, Test)

Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Turnover
60 - 90 days
Team #1
Team #2
Team #3
C. Mô hình phát trển ứng dụng nhanh (RAD)
Business modeling
Thông tin nào điều khiển xử lý nghiệp vụ ?
Thông tin gì được sinh ra?
Ai sinh ra nó ?
Thông tin đi đến đâu ?
Ai xử lý chúng ?
C. Mô hình phát trển ứng dụng nhanh (RAD)
Data and Process modeling
Data modeling: các đối tượng dữ liệu cần để hỗ trợ nghiệp vụ (business). Định nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng
Process modeling: Các đối tượng dữ liệu được chuyển sang luồng thông tin thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu
C. Mô hình phát trển ứng dụng nhanh (RAD)
Hạn chế ?
Cần nguồn nhân lực dồi dào để tạo các nhóm cho các chức năng chính
Yêu cầu hai bên giao kèo trong thời gian ngắn phải có phần mềm hoàn chỉnh, thiếu trách nhiệm của một bên dễ làm dự án đổ vỡ
RAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụng không thể môđun hóa hoặc đòi hỏi tính năng cao
Mạo hiểm kỹ thuật cao thì không nên dùng RAD
C. Mô hình phát trển ứng dụng nhanh (RAD)
D. Mô hình xoắn ốc (Spiral model)
Giao tiếp
khách hàng
Lập kế hoạch
Phân tích rủi ro
Kỹ nghệ
Xây dựng &
Xuất xưởng
Khách hàng
đánh giá
Bảo trì
Nâng cấp
Làm mới
Khái niệm
E. Các mô hình khác
Mô hình xoắn ốc WINWIN
Mô hình phát triển đồng thời
Mô hình theo thành phần
Mô hình lập trình cực đoan (XP- eXtreme Programming )
Mô hình RUP
5.1.4. Các kỹ thuật thế hệ thứ 4
Tập hợp các công cụ cho phép xác định đặc tính phần mềm ở mức cao, sau đó sinh tự động mã nguồn dựa theo đặc tả đó
Các công cụ 4GT điển hình: ngôn ngữ phi thủ tục cho truy vấn CSDL; tạo báo cáo; xử lý dữ liệu; tương tác màn hình; tạo mã nguồn; khả năng đồ họa bậc cao; khả năng bảng tính; khả năng giao diện Web; vv
5.1.4. Các kỹ thuật thế hệ thứ 4
Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa khách và người phát triển là quan trọng
Không nên bỏ qua khâu thiết kế. 4GT chỉ áp dụng để triển khai thiết kế qua 4GL
Ư điểm: giảm thời gian phát triển và tăng năng suất
Nhược điểm: 4GT khó dùng hơn ngôn ngữ lập trình, mã khó tối ưu và khó bảo trì cho hệ thống lớn  cần kỹ năng của kỹ sư phần mềm
Tương lai: 4GT với mô hình theo thành phần
5.2 Các pha trong phát triển phần mềm
5.2.1. Nghiên cứu yêu cầu (Requirements and Specifications)
5.2.2. Phân tích và thiết kế (System Analysis and Design)
5.2.3. Triển khai (Coding and Unit Test)
5.2.4. Thử nghiệm (Test)
5.2.5. Cài đặt và bảo trì (Deployment and Maintenance)

5.2.1. Nghiên cứu yêu cầu (Requirements and Specifications)
Mục đích:
Tìm hiểu xem phải phát triển cái gì, chứ không phải là phát triển như thế nào.
Kết quả của bước nghiên cứu yêu cầu là tạo ra đặc tả yêu cầu của phần mềm - là tài liệu ràng buộc giữa khách hàng và người phát triển.
Yêu cầu phần mềm: là tất cả các yêu cầu về phầm mềm do khách hàng - người sử dụng phần mềm - nêu ra, bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác:
Các yêu cầu về phần mềm (Software)
Các yêu cầu về phần cứng (Hardware)
Các yêu cầu về dữ liệu (Data)
Các yêu cầu về con người (People, Users)

5.2.1. Nghiên cứu yêu cầu (Requirements and Specifications)
5.2.1. Nghiên cứu yêu cầu
Tại sao phải nghiên cứu yêu cầu:
Khách hàng chỉ có những ý tưởng còn mơ hồ về phần mềm cần phải xây dựng để phục vụ công việc của họ, chúng ta phải sẵn sàng, kiên trì theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính năng cần thiết”
Khách hàng rất hay thay đổi các đòi hỏi của mình, chúng ta nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý

Quy trình xác định yêu cầu
the problem
Requirements
elicitation

Build a
prototype
Create
analysis
models
Develop
specification
Review
Quy trình xác định yêu cầu
Phát hiện các yêu cầu phần mềm (Requirements elicitation)
Phân tích các yêu cầu phần mềm và thương lượng với khách hàng (Requirements analysis and negotiation)
Mô tả các yêu cầu phần mềm (Requirements specification)
Mô hình hóa hệ thống (System modeling)
Kiểm tra tính hợp lý các yêu cầu phần mềm (Requirements validation)
Quản trị các yêu cầu phần mềm (Requirements management)
Phát hiện yêu cầu phần mềm
Phạm vi của phần mềm (Scope)
Hiểu rõ phần mềm (Understanding)
Các thay đổi của hệ thống (Volatility)
Phương pháp:
Xác định các phương pháp sử dụng phát hiện các yêu cầu phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác, v.v.
Tìm kiếm các nhân sự (chuyên gia, người sử dụng) có những hiểu biết sâu sắc nhất, chi tiết nhất về hệ thống giúp chúng ta xác định yêu cầu phần mềm
Xác định “môi trường kỹ thuật - technical environment”
Xác định các “ràng buộc miền - domain constraints”
Thu hút sự tham gia của nhiều chuyên gia, khách hàng để chúng ta có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàng
Thiết kế các kịch bản sử dụng của phần mềm
Kết quả cần có:
Bảng kê (statements) các đòi hỏi và chức năng khả thi của phần mềm
Bảng kê phạm vi ứng dụng của phần mềm
Mô tả môi trường kỹ thuật của phần mềm
Bảng kê tập hợp các kịch bản sử dụng của phần mềm
Các nguyên mẫu xây dựng, phát triển hay sử dụng trong phần mềm (nếu có)
Danh sách nhân sự tham gia vào quá trình phát hiện các yêu cầu phần mềm - kể cả các nhân sự từ phía công ty- khách hàng
Đặc tả yêu cầu phần mềm
Đặc tả các yêu cầu phần mềm là: việc xây dựng các tài liệu đặc tả, trong đó có thể sử dụng tới các công cụ như: mô hình hóa, mô hình toán học hình thức (a formal mathematical model), tập hợp các kịch bản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trên
Chất lượng của hồ sơ đặc tả đánh giá qua các tiêu thức
Tính rõ ràng, chính xác
Tính phù hợp
Tính đầy đủ, hoàn thiện
Đặc tả chức năng
Đặc tả chức năng (Funtional Specifications):
Miêu tả các chức năng của hệ thống, phụ thuộc vào kiểu PM và mong đợi của người dùng
Thông thường khi đặc tả các chức năng của phần mềm người ta sử dụng các công cụ tiêu biểu sau:
Biểu đồ luồng dữ liệu (Data Flow Diagrams)
Máy trạng thái hữu hạn (Finite State Machines
Mạng Petri (Petri nets),…
Đặc tả phi chức năng
Đặc tả phi chức năng (Non-Funtional Specifications):
Định nghĩa các tính chất của hệ thống, các ràng buộc, thí dụ như độ tin cậy, thời gian trả lời, dung lượng bộ nhớ,…
Các yêu cầu do tổ chức qui định như qui định chuẩn về quá trình tiến hành, chuẩn tài liệu,…
Các yêu cầu từ ngoài
Phân tích: phân tích toàn bộ các yêu cầu đã xác định ở bước nghiên cứu yêu cầu. Cần phải "số hoá" từng yêu cầu đó thành ngôn ngữ mà người thiết kế, lập trình có thể hiểu được: thông qua các biểu đồ xác định luồng dữ liệu, biểu đồ mô tả các đối tượng cũng như chức năng tổng quát của hệ thống.

5.2.2. Phân tích và thiết kế
(System Analysis and Design)
5.2.2. Phân tích và thiết kế
(System Analysis and Design)
Cần phân biệt:
Mục tiêu: trừu tượng, khó đạt được
Yêu cầu:cụ thể, phải đảm bảo đạt được
5.2.2. Phân tích và thiết kế
Nghiên cứu khả thi:
Kinh tế
Khả năng tài chính
Lợi ích của hệ thống
Chi phí phát sinh khi vận hành
Kỹ thuật
Pháp lý
Khả năng hoạt động
Biểu đồ luồng dữ liệu (DFD)
Hệ thống (System): tập hợp các dữ liệu (data) được xử lý bằng các chức năng tương ứng (functions)
Các ký pháp sử dụng:
Thể hiện các chức năng (functions)
Thể hiện luồng dữ liệu
Kho dữ liệu
Vào ra dữ liệu và tương tác giữa hệ thống và
người sử dụng (Tác nhân)
Ví dụ: Quản lý thư viện - DFD
Có
sách
Tìm theo
chủ đề
Yêu cầu từ người mượn
Kho sách
Danh sách tác giả
Danh sách tên sách
Danh sách chủ đề
Chủ đề yêu cầu
Đưa ra
Tên sách
Danh sách người mượn
Thông tin
về sách
Sách
Chủ đề
Tên tác giả
Tên sách
Liệt kê các tên sách
liên quan đến chủ đề
Tên sách;
Tên người mượn
Sách
Tên sách, tác giả
Tên người mượn
Các mức DFD
Mức ngữ cảnh
Mức đỉnh
Mức tiếp theo (1.x,…)
Tham khảo
LinksUWE-CEMS - Data Flow Diagrams.htm

Thiết kế: trên cơ sở những kết quả thu được từ bước phân tích, người thiết kế tiến hành mô tả tổng quát mô hình logic cũng như mô hình vật lý của hệ thống. Người thiết kế đi sâu thiết kế chi tiết các yêu cầu đặt ra, các chức năng cần có của phần mềm thông qua những biểu đồ chi tiết hơn về chức năng, về trạng thái, về giao diện, về lưu trữ dữ liệu. Có thể phân ra thành các công việc chính như sau:
Là thiết kế cấu hình phần cứng và cấu trúc phần mềm (gồm cả chức năng và dữ liệu) để có được hệ thống thỏa mãn các yêu cầu đề ra.
Có thể xem như Thiết kế cấu trúc (WHAT), chứ không phải là Thiết kế Logic (HOW).
5.2.2. Phân tích và thiết kế
(System Analysis and Design)
Các bước thiết kế
Phân chia mô hình phân tích ra các hệ con
Phân bố các hệ con cho các bộ xử lý hoặc các nhiệm vụ (tasks)
Phát triển thiết kế giao diện
Chọn chiến lược cài đặt quản trị dữ liệu
Tìm ra nguồn tài nguyên chung và cơ chế điều khiển truy nhập chúng.
Thiết kế cơ chế điều khiển thích hợp cho hệ thống, kể cả quản lý nhiệm vụ.
Xem xét các điều kiện biên được xử lý như thế nào.
Xét duyệt và xem xét các thỏa hiệp (trade-offs).
Thiết kế
Chú ý:
(1) Có thể trích được luồng dữ liệu từ hệ thống: đó là phần nội dung đặc tả yêu cầu và giao diện.
(2) Xem xét tối ưu tài nguyên kiến trúc lên hệ thống rồi quyết định kiến trúc.
(3) Theo quá trình biến đổi dữ liệu, hãy xem những chức năng được kiến trúc như thế nào?
(4) Từ kiến trúc các chức năng theo (3), hãy xem xét và chỉnh lại, từ đó chuyển sang kiến trúc chương trình và thiết kế chi tiết.
(5) Quyết định các đơn vị chương trình theo các chức năng của hệ phần mềm có dựa theo luồng dữ liệu và phân chia ra các thành phần.
(6) Khi cấu trúc chương trình lớn quá, phải phân chia nhỏ hơn thành các môđun.
(7) Xem xét dữ liệu vào-ra và các tệp dùng chung của chương trình. Truy cập tệp tối ưu.
(8) Hãy nghĩ xem để có được những thiết kế trên thì nên dùng phương pháp luận và những kỹ thuật gì?
Thiết kế phần mềm
Là thiết kế chi tiết cấu trúc bên trong của phần mềm: thiết kế tính năng từng môđun và giao diện tương ứng.
Cấu trúc ngoài của phần mềm: thiết kế hệ thống.
Trình tự xử lý bên trong: Thuật toán (giải thuật, Algorithm); Logic.
Không có trạng thái mờ (fuzzy), để đảm bảo thiết kế cấu trúc trong đúng đắn.
Ngôn ngữ lập trình phù hợp.
Triển khai đúng đắn đặc tả chức năng các môđun và chương trình nhờ phương pháp luận thiết kế chi tiết.
Dùng quy trình thiết kế dễ chuẩn hóa từng bước.
Thiết kế phần mềm
Kỹ thuật thiết kế
Hướng tiến trình (process) : Kỹ thuật thiết kế cấu trúc điều khiển.
Hướng cấu trúc dữ liệu (data): Kỹ thuật thiết kế cấu trúc dữ liệu.
Hướng sự vật / đối tượng (object): Kỹ thuật thiết kế hướng đối tượng.
Phụ thuộc vào kỹ năng và kinh nghiệm của người thiết kế.
Cần chuẩn hóa tài liệu đặc tả thiết kế chi tiết.
5.2.3. Triển khai (Coding)
Mã hóa (Coding)
Cấu trúc chương trình
Cấu trúc dữ liệu dễ hiểu
Cấu trúc thuật toán dễ hiểu
Các công cụ lập trình
5.2.3. Triển khai
Cấu trúc thuật toán dễ hiểu
Tuân theo quy cách lập trình
Một đầu vào, một đầu ra
Tránh GOTO, trừ khi phải ra khỏi lặp và dừng
Dùng comments hợp lý
Dùng tên biến có nghĩa, gợi nhớ
Cấu trúc lồng rõ ràng
Tránh dùng CASE / switch nhiều hoặc lồng nhau
Mã nguồn 1 chương trình / môđun nên viết trên 1 trang
Tránh viết nhiều lệnh trên 1 dòng
5.2.3. Triển khai
Cấu trúc dữ liệu dễ hiểu
Nên xác định tất cả các cấu trúc dữ liệu và các thao tác cần thực hiện trên từng cấu trúc dữ liệu.
Việc biểu diễn/khai báo các cấu trúc dữ liệu chỉ nên thực hiện ở những mô đun sử dụng trực tiếp dữ liệu.
Nên thiết lập và sử dụng từ điển dữ liệu khi thiết dữ liệu.

5.2.3. Triển khai
Chú thích trong chương trình
Tại sao cần đặt các chú thích trong chương trình ?
Vị trí đặt các chú thích trong chương trình
Thành phần/ Module
Lớp
Hàm/thủ tục
Các vị trí đặc biệt khác
Một số quy định khi đặt chú thích:
Ngắn gọn
Gợi nhớ
5.2.3. Triển khai
Các công cụ lập trình:
Environments: DOS, WINDOWS, UNIX/LINUX
Editors, Compilers, Linkers, Debuggers
TURBO C, PASCAL
MS C, Visual Basic, Visual C++, ASP
UNIX/LINUX: C/C++, gcc (Gnu C Compiler)
JAVA, CGI, perl
C#, .NET
5.2.4. Thử nghiệm (Test)
Khái niệm kiểm thử
Phương pháp thử
Kỹ thuật thiết kế trưòng hợp thử
Kỹ thuật kiểm thử môđun
Khái niệm kiểm thử
Là mấu chốt của đảm bảo chất lượng phần mềm
Là tiến trình (và là nghệ thuật) nhằm phát hiện lỗi bằng việc xem xét lại đặc tả, thiết kế và mã hoá.
Kiểm thử thành công là phát hiện ra lỗi; kiểm thử không phát hiện ra lỗi là kiểm thử dở (Sue A.Conger- The New SE)
Khái niệm kiểm thử
Khó khăn khi kiểm thử
Nâng cao chất lượng phần mềm nhưng không vượt quá chất lượng khi thiết kế: chỉ phát hiện các lỗi tiềm tàng và sửa chúng
Phát hiện lỗi bị hạn chế do thủ công là chính
Dễ bị ảnh hưởng tâm lý khi kiểm thử
Khó đảm bảo tính đầy đủ của kiểm thử

Khái niệm kiểm thử
Chú ý:
Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử
Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình
Người kiểm thử và người phát triển nên khác nhau
Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, cần có những dữ liệu kiểm thử mà phát hiện ra lỗi
Khi thiết kế trường hợp thử, không chỉ dữ liệu kiểm thử nhập vào, mà phải thiết kế trước cả dữ liệu kết quả sẽ có
Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp thử trướcđó để tránh ảnh hưởng lan truyền sóng
Phương pháp thử
Thử tĩnh
Kiểm thử trên máy
Thử tĩnh
Kiểm thử trên bàn hay Kiểm thử tĩnh: giấy và bút trên bàn, kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xong
Đi xuyên suốt (walk through)
Thanh tra (inspection)
Kiểm thử trên máy
Dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình
9 bước của trình tự kiểm thử bằng máy
Thiết kế trường hợp thử theo thử tĩnh
Trường hợp thử phải có cả kết quả kỳ vọng sẽ thu được
Dịch chương trình nguồn và tạo môđun tải để thực hiện
Khi trường hợp thử có xử lý tệp vào-ra, phải xác định miền của các tệp
Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử
Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy cập tệp vào chương trình)
Thực hiện môđun tải và ghi nhận kết quả
Xác nhận kết quả với kết quả kỳ vọng
Lặp lại thao tác (5)-(8)
Thiết kế trường hợp thử
Kỹ thuật thiết kế trường hợp thử dựa trên đặc tả bề ngoài của chương trình: Kiểm thử hộp đen (Black box test): WHAT ?
Kỹ thuật thiết kế trường hợp thử dựa trên đặc tả bên trong của chương trình: Kiểm thử hộp trắng (white box test): HOW ?
Kiểm thử Top-Down hay Bottom-Up
5.2.5. Cài đặt và bảo trì
(Deployment and Maintenance)
Các bước triển khai:
Cài đặt hệ thống
Thử nghiệm hệ thống một mình và với các hệ thống mà nó có liên hệ
Đào tạo người sử dụng và đội ngũ nhân viên kỹ thuật
Tiến hành các thử nghiệm chấp nhận
Chuyển đổi dữ liệu cho hệ thống mới
Thay đổi hệ thống cũ và các thủ tục cũ thành hệ thống mới và các thủ tục mới
Lập kế hoạch bảo trì
Lập kế hoạch backup dữ liệu và khôi phục hệ thống

Cài đặt hệ thống
Lắp đặt thiết bị
Cài đặt phần mềm hệ thống
Cài đặt phần mềm ứng dụng
Cài đặt truyền thông
Chạy thử lần đầu
Cho hệ thống chạy một mình để nhận diện và sửa chữa các sai sót bên trong hệ thống
Cho hệ thống chạy tích hợp với các hệ thống khác mà nó có liên quan như với các máy tính khác, mạng,…

Đào tạo
Tiến hành trước hoặc trong quá trình cài đặt hệ thống sao cho trước khi bàn giao cho người sử dụng không có những thay đổi đáng kể trong hệ thống và người sử dụng nên/có thể sử dụng hệ thống ngay khi vừa kết thúc khoá học:
Các đối tượng cần đào tạo
Người sử dụng cuối cùng
Người quản trị hệ thống
Nhóm làm công việc bảo trì
Thử nghiệm chấp nhận
Là giai đoạn cuối của quá trình thử nghiệm trước khi hệ thống được chuyển tới vận hành sử dụng
Thử nghiệm hệ thống với dữ liệu do người làm trong hệ thống cung cấp chứ không phải dữ liệu mô phỏng
Thử nghiệm chấp nhận thường phát hiện ra các lỗi và các phần bị bỏ qua về các yêu cầu của hệ thống
Trước thử nghiệm chấp nhận cần thực hiện các việc:
Đảm bảo các pha thử nghiệm khác đã được hoàn thiện
Kết thúc việc tập hợp các dữ liệu cần dùng cho thử nghiệm chấp nhận
Hoàn thành việc sao lưu dữ liệu
Kế hoạch thử nghiệm chấp nhận và dữ liệu phải sử dụng trong pha này
Phải hoàn thành việc định nghĩa các thử nghiệm chất lượng
Chuyển đổi số liệu
Chuyển đổi số liệu đang xử lý trên hiện thống hiện tại sang hệ thống mới
Chuẩn hóa dữ liệu
Chuyển đổi cấu trúc
Chuyển đổi dữ liệu
Kiểm tra lại số liệu
Công cụ:
Thủ công
Bán thủ công
Chương trình nhỏ hỗ trợ
Kết hợp
Hiệu suất: thấp
Chuyển đổi hệ thống
Đột ngột
Song song
Từng vùng
Từng giai đoạn
Bảo trì
Bảo trì là gì?
Trình tự nghiệp vụ bảo trì
Những vấn đề về bảo trì hiện nay
Bảo trì là gì?
Định nghĩa: Bảo trì là công việc tu sửa, thay đổi phần mềm đã được phát triển (chương trình, dữ liệu, JCL, các loại tư liệu đặc tả, . . .) theo những lý do nào đó.
Các hình thái bảo trì: bảo trì để
Tu chỉnh
Thích hợp
Cải tiến
Phòng ngừa
Bảo trì
Tu sửa:
Là bảo trì khắc phục những khiếm khuyết có trong phần mềm.
Một số nguyên nhân điển hình
Kỹ sư phần mềm và khách hiểu nhầm nhau.
Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình hoặc khi kiểm thử chưa bao quát hết.
Vấn đề tính năng của phần mềm: không đáp ứng được yêu cầu về bộ nhớ, tệp, . . . Thiết kế sai, biên tập sai . . .
Thiếu chuẩn hóa trong phát triển phần mềm (trước đó).
Kỹ nghệ ngược (Reverse Engineering): dò lại thiết kế để tu sửa.
Bảo trì
Bảo trì để thích hợp
Là tu chỉnh phần mềm theo thay đổi của môi trường bên ngoài nhằm duy trì và quản lý phần mềm theo vòng đời của nó.
Thay đổi phần mềm thích nghi với môi trường: công nghệ phần cứng, môi trường phần mềm.
Những nguyên nhân chính:
Thay đổi về phần cứng (ngoại vi, máy chủ,. . .)
Thay đổi về phần mềm (môi trường): đổi OS
Thay đổi cấu trúc tệp hoặc mở rộng CSDL

Bảo trì
Bảo trì để cải tiến
Là việc tu chỉnh hệ phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý hơn.
Những nguyên nhân chính:
Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức truy cập tệp.
Mở rộng thêm chức năng mới cho hệ thống.
Cải tiến quản lý kéo theo cải tiến tư liệu vận hành và trình tự công việc.
Thay đổi người dùng hoặc thay đổi thao tác.
Mục đích: đưa ra một thiết kế cùng chức năng nhưng có chất lượng cao hơn
Bảo trì để phòng ngừa
Là công việc tu chỉnh chương trình có tính đến tương lai của phần mềm đó sẽ mở rộng và thay đổi như thế nào.
Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt.
Mục đích: sửa đổi để thích hợp với yêu cầu thay đổi sẽ có của người dùng
Quy trình bảo trì
Hiểu phần mềm đã có
Loại bảo trì?
Chỉnh phần mềm đã có
Kiểm thử tính nhất quán
Kiểm thử sau bảo trì
Tạo biểu quản lý bảo trì
Phát triển phần mềm mới
2
1
1 – Tu chỉnh cái đã có
2 – Xây dựng thêm cái mới
Bảo trì
1. Tu sửa cái đã có
Bảo trì chương trình nguồn, tạo các môđun mới và dịch lại.
Thực hiện kiểm thử unit và tu chỉnh những mục liên quan có trong tư liệu đặc tả.
Chú ý theo sát tác động của môđun được sửa đến các thành phần khác trong hệ thống.
2. Phát triển thêm phần mới
Khi thêm chức năng mới phải phát triển chương trình cho phù hợp với yêu cầu
Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm thử unit
Phản ảnh vào giao diện của phần mềm (thông báo, phiên bản, . . .)
Quản lý bảo trì
Cần quản lý tình trạng bảo trì
Lập biểu quản lý tình trạng bảo trì
Ngày tháng, giờ
Nguyên nhân
Tóm tắt cách khắc phục
Chi tiết khắc phục, hiệu ứng làn sóng
Người làm bảo trì
Số công


THANK YOU FOR YOUR ENJOYING!

Best wishes !
Strong in …
Rich in …
Happiness in …
High mark in examination
Successful in your life.