kỷ thuật phần mềm

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ế

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

 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

 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

5.1.2 Các vấn đề của phát triển phần mềm

nhanh chóng của yêu cầu

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ồ

 Đá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

Vòng đời phần mềm (Software life-cycle)

đượ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)

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

Tªn pha Néi dung nghiÖp vô Ph ¬ng ph¸p, kü thuËt

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)

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)

 Phân tích yêu cầu (Requirements analysis)

A Mô hình tuyến tính (Cascade model)

 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)

rõ chi tiết đầu vào hay xử lý ra sao hoặc chưa rõ yêu cầu đầu ra

qua các thiết kế nhanh

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)

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)

(Component-based construction) với khả năng tái sử dụng (reuse)

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

Business Modeling

Data Modeling

Data Modeling

Process Modeling

Process Modeling

Application Generation

Application Generation

Business Modeling

Data Modeling

Data Modeling

Process Modeling

Process Modeling

Application Generation

Application Generation

Business Modeling

Data Modeling

Data Modeling

Process Modeling

Process Modeling

Application Generation

Application Generation

 Business modeling

 Thông tin nào điều khiển xử lý nghiệp vụ ?

 Thông tin gì được sinh ra?

 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)

 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

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 phát triển đồng thời

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

Specifications)

5.2.1 Nghiên cứu yêu cầu (Requirements and Specifications)

 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

 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

 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

 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

Đặc tả yêu cầu phần mềm

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

 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

 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

 Đị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)

 Mục tiêu: trừu tượng, khó đạt được

 Yêu cầu:cụ thể, phải đảm bảo đạt được

Biểu đồ luồng dữ liệu (DFD)

bằng các chức năng tương ứng (functions)

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

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

 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).

 (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,

5.2.3 Triển khai (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

 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

 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

 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ử

việc xem xét lại đặc tả, thiết kế và mã hoá.

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ử

 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

Thử tĩnh

bàn, kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xong

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)