Bài giảng Công nghệ phần mềm ứng dụng - Bài 6: Chủ đề nâng cao trong công nghệ học phần mềm

CÔNG NGHỆ PHẦN MỀM ỨNG DỤNG

Giảng viên: ThS. Thạc Bình Cƣờng

1

v1.0015112208

BÀI 6

CHỦ ĐỀ NÂNG CAO TRONG

CÔNG NGHỆ HỌC PHẦN MỀM

Giảng viên: ThS. Thạc Bình Cường

2

v1.0015112208

MỤC TIÊU BÀI HỌC

• Tiếp cận và xây dựng các phần mềm nâng cao,

phần mềm linh hoạt.

• Lập dự trù chi phí phần mềm, nguồn lực.

• Quản lí và bảo đảm chất lượng phần mềm theo

yêu cầu đề ra và các chuẩn phần mềm.

• Hiểu biết và vận dụng các phần mềm tiên tiến

trong thời gian thực.

• Biết xu hướng phát triển phần mềm sau này.

3

v1.0015112208

CÁC KIẾN THỨC CẦN CÓ

• Tin học đại cương;

• Ngôn ngữ lập trình;

• Phân tích thiết kế hệ thống thông tin.

4

v1.0015112208

HƢỚNG DẪN HỌC

• Đọc và nắm được các xu hướng công nghệ mới:

điện toán đám mây, hệ thông minh, các công cụ

lập trình và ngôn ngữ lập trình; các hệ thống

smart phone, lập trình mobile phone.

• Định hướng cho các tổ hợp, tập đoàn và hệ thống

mạng quốc gia ứng dụng các hệ nâng cao trong

công nghệ phần mềm.

• Xây dựng chiến lược quốc gia vùng miền về các

hệ thống dữ liệu lớn, tích hợp dữ liệu.

5

v1.0015112208

CẤU TRÚC NỘI DUNG

6.1

6.2

6.3

6.4

Mô hình RUP

Phương pháp phân tích phần mềm linh hoạt

Ước lượng chi phí phần mềm

Quản lí chất lượng

Cải tiến quy trình

6.5

6.6

Các chủ đề tiên tiến khác

6

v1.0015112208

6.1. MÔ HÌNH RUP

6.1.1. Tổng quan

6.1.2. Các khái niệm

cơ bản

7

v1.0015112208

6.1.1. TỔNG QUAN

• Định nghĩa:

 RUP (Rational Unified Process) là một quá trình phát triển phần mềm bao gồm

các giai đoạn trong vòng đời của dự án và giúp đỡ các nhà phát triển trong hoạt

động quản lí dự án cũng như các hoạt động kĩ thuật. Là sản phẩm được phát

triển và bảo trì bởi Rational.

 Nó cũng được lĩnh hội tương tự như quá trình làm phần mềm khác, và sử dụng

mô hình hướng đối tượng như UML.

• Hai trục của RUP:

 Trục hoành biểu diễn chuỗi công việc theo thời gian: Vòng đời của quá trình và

biểu diễn bởi thuật ngữ giai đoạn, lặp, chuẩn hóa… Nó biểu diễn trạng thái động

của quá trình.

 Trục tung biểu diễn Workflows, tập hợp một cách lôgíc các hoạt động công nghệ

phụ thuộc vào bản chất của nó. Nó biểu diễn trạng thái tĩnh của quá trình.

Chú ý: Sự phân biệt này là rất quan trọng.

• Quá trình kĩ nghệ phần mềm:

 Tiến trình: là một tập hợp các giai đoạn được sắp xếp một cách cục bộ mà mục

đích là đạt mục tiêu đặt ra. Trong lĩnh vực SE đó là sản phẩm hay bảo trì

sản phẩm.

 Mô hình hóa: Tiến trình phần mềm là tiến trình nghề nghiệp nhằm hoàn thiện tổ

chức để phát triển phần mềm. RUP là một tiến trình nghề nghiệp để phát triển

phần mềm theo hướng đối tượng.

8

v1.0015112208

6.1.2. CÁC KHÁI NIỆM CƠ BẢN

• Vai trò (Role): Trạng thái/trách nhiệm của cá thể hay nhóm làm việc theo nhóm trong

ngữ cảnh tổ chức công nghệ phần mềm.

• Hoạt động (Ativité): là một đơn vị công việc được cung cấp bởi vai trò trong ngữ

cảnh dự án. Một hoạt động phải có một đích rõ ràng.

• Giai đoạn (Etape): Một hoạt động được phân thành nhiều giai đoạn: suy nghĩ, thực

hiện, xem xét.

• Hướng dẫn: Những kĩ thuật, tư vấn cần thiết cho hoạt động.

• Artefacts (chế phẩm): Một hoạt động có những artefacts vào và ra. Một artefact là

một phần tử được tạo ta hay được sử dụng bởi quá trình. Một đích sử dụng nhiều

artefact để thực hiện các hoạt động. Một artefact chỉ chịu trách nhiệm bởi chỉ

một đích.

9

v1.0015112208

6.1.2. CÁC KHÁI NIỆM CƠ BẢN (tiếp theo)

• Kiểu kế hoạch: là các mô hình hay mẫu thử liên kết với các chế phẩm.

Ví dụ:

 Kế hoạch kiểu word được dùng cho các artefact kiểu văn bản.

 Kế hoạch kiểu Rational SoDA (công cụ phát triển bởi Rational).

• Báo cáo: Trích rút thông tin từ các mô hình và các phần tử từ một công cụ nhằm

mục đích xem xét lại.

• Hướng dẫn về artefact và điều khiển: Thường liên kết các hướng dẫn cho các

artefact và các điều khiển nhằm tạo ra hay biên tập lại và để đánh giá.

• Liên kết các hoạt động của Workflow.

• Quy trình (discipline).

• Nhóm các hoạt động: Workflow không chỉ ra trực tiếp các hoạt động, song nhóm

hoạt động chỉ ra cách nhóm lại các hoạt động thường được thực hiện cùng nhau.

10

v1.0015112208

6.1.2. CÁC KHÁI NIỆM CƠ BẢN (tiếp theo)

• Bốn giai đoạn:

 Mô hình hóa;

 Khởi tạo (thiết kế);

 Xây dựng (phát triển);

 Khai thác.

Construction

Inception

Elaboration

Transition

Cung cấp sản phẩm

Tác nghiệp

Mục đích

Kiến trúc

Time

11

v1.0015112208

6.2. PHƢƠNG PHÁP PHÂN TÍCH PHẦN MỀM LINH HOẠT

• Thích ứng thay vì dự đoán.

• Hướng đến con người thay vì quy trình.

• Đề cao tính chủ động và sáng tạo.

• Cân bằng giữa sự tổ chức và linh hoạt.

• Các phương pháp phân tích phần mềm linh hoạt: Adaptive, Crystal, DSDM, FDD,

Scum, XP.

• Đặc điểm chung:

 Tính đến khách hàng trong quy trình phát triển;

 Có sự tham gia của cấp lãnh đạo ngoài bộ phận IT;

 Tập trung vào nhiệm vụ;

 Xây dựng từng phiên bản nhỏ, thực hiện vừa đủ những tính năng cần thiết ở

từng vòng lặp phát triển;

 Chu trình phát triển ngắn;

 Giữ cho yêu cầu tối thiểu;

 Giữ cho nhóm phát triển nhỏ;

 Liên tục kiểm tra;

 Chấp nhận và thích ứng nhanh với những thay đổi;

 Khuyến khích việc trao đổi giữa các thành viên.

v1.0015112208

12

6.2. PHƢƠNG PHÁP PHÂN TÍCH PHẦN MỀM LINH HOẠT (tiếp theo)

Extreme programming – XP

• Khái niệm:

 Là cách tiếp cận phát triển dựa vào phát triển và cung cấp các phần gia tăng rất

nhỏ của của chức năng.

 Dựa vào việc cải tiến mã, sự liên quan của người dùng trong phát triển nhóm và

lập trình cặp đôi.

 Do Ken Beck, Ward Cunningham và một số người khác phát triển, khởi nguồn từ

dự án Chrysler Comprehensive Compensation (phần mềm tính lương thưởng

của hãng xe hơi Chrysler, hiện vẫn đang được sử dụng).

13

v1.0015112208

6.2. PHƢƠNG PHÁP PHÂN TÍCH PHẦN MỀM LINH HOẠT (tiếp theo)

• Bốn giai đoạn:

 Lập kế hoạch:

. Xác định nhiệm vụ;

. Lập lịch trình;

. Ước lượng tốc độ dự án;

. Chia dự án thành các vòng lặp;

. Làm việc tập thể;

. Họp mỗi ngày;

. Thay đổi khi gặp sự cố.

 Thiết kế:

. Đơn giản;

. Chọn mô hình hệ thống;

. Phác thảo hệ thống để giảm rủi ro;

. Không thêm sớm các chức năng.

14

v1.0015112208

6.2. PHƢƠNG PHÁP PHÂN TÍCH PHẦN MỀM LINH HOẠT (tiếp theo)

 Viết mã (coding):

. Khách hàng cũng tham gia;

. Mã được viết theo chuẩn;

. Viết kiểm thử đơn vị (unit) trước;

. Mọi mã đều do 2 người viết;

. Tối ưu sau;

. Không vượt thời gian.

 Kiểm tra (testing):

. Mọi mã đều phải có unit test;

. Mọi mã đều phải qua kiểm tra trước khi được sử dụng;

. Khi có lỗi phải kiểm tra lại;

. Kiểm tra tính năng được làm thường xuyên, kết quả được công bố.

15

v1.0015112208

6.2. PHƢƠNG PHÁP PHÂN TÍCH PHẦN MỀM LINH HOẠT (tiếp theo)

• Quy trình dự án XP:

• Kết luận:

 XP được thiết kế nhằm cung cấp phần mềm mà khách hàng cần và vào đúng

thời điểm cần thiết.

 Tuy vậy phương pháp phân tích phần mềm linh hoạt không phải là giải pháp vạn

năng có thể áp dụng cho mọi dự án phần mềm, cũng như các dự án phần mềm

khác luôn thất bại. Cần phải có những điều kiện nhất định để quyết định đi theo

phương pháp nào.

16

v1.0015112208

6.3. ƢỚC LƢỢNG CHI PHÍ PHẦN MỀM

6.3.1. Năng suất

6.3.2. Các kĩ thuật ước đoán

6.3.3. Mô hình chi phí

6.3.4. Nhân lực và thời gian

dự án

thuật toán

17

v1.0015112208

6.3.1. NĂNG SUẤT

• Năng suất là số đơn vị đầu ra trên số giờ làm việc.

• Trong công nghệ phần mềm, năng suất có thể ước lượng bởi một số thuộc tính chia

cho tổng số nỗ lực để phát triển:

 Số đo kích thước (ví dụ số dòng lệnh);

 Số đo chức năng (số chức năng tạo ra trên 1 khoảng thời gian).

18

v1.0015112208

6.3.2. CÁC KĨ THUẬT ƢỚC ĐOÁN

• Mô hình chi phí thuật toán: Sử dụng các thông tin có tính lịch sử (thường là

kích thước).

• Ý kiến chuyên gia.

• Đánh giá tương tự: Chỉ áp dụng khi có nhiều dự án trong cùng một lĩnh vực.

• Luật Parkinson: Chi phí phụ thuộc thời gian và số nhân công.

• Giá để thắng thầu: Phụ thuộc khả năng khách hàng.

19

v1.0015112208

6.3.3. MÔ HÌNH CHI PHÍ THUẬT TOÁN

• Nguyên tắc: Dùng một phương trình toán học để dự đoán (Kitchenham 1990a) dạng:

Nỗ lực = C × PM^s× M, với:

C là độ phức tạp;

PM là số đo năng suất;

M là hệ số phụ thuộc và quá trình, năng suất;

s được chọn gần với 1, phản ánh độ gia tăng của yêu cầu với các dự án lớn.

• Chú ý:

 Rất khó dự đoán PM vào giai đoạn đầu

 Việc dự đoán C và M là khách quan và có thể thay đổi từ người này sang

người khác.

• Mô hình COCOMO (Boehm 1981): Mô hình COCOMO tuân theo phân tích trên, với

các lựa chọn sau:

 Đơn giản: PM = 2,4 (KDSI)^1,05 M

 Khiêm tốn: PM = 3,0 (KDSI)^1,12 M

 Lồng nhau: PM = 3,6 (KDSI)^1,20 M

Với KDSI là số lệnh nguồn theo đơn vị nghìn.

20

v1.0015112208

Bài giảng Công nghệ phần mềm ứng dụng - Bài 6: Chủ đề nâng cao trong công nghệ học phần mềm - Thạc Bình Cường