Bài giảng Kỹ nghệ phần mềm - Nguyễn Việt Hà

Tiến hành quản lý dự án là ng−ời quản lý dự án, có các nhiệm vụ và quyền hạn nh−
sau
• Thời gian
- tạo lập kế hoạch, điều chỉnh kế hoạch
- kiểm tra/đối chiếu các tiến trình con với kế hoạch
- giữ một độ mềm dẻo nhất định trong kế hoạch
- phối thuộc các tiến trình con
• Tài nguyên: thêm tiền, thêm thiết bị, thêm ng−ời...
• Sản phẩm: thêm bớt chức năng của sản phẩm...
• Rủi ro: phân tích và tìm ph−ơng pháp xử lý, chấp nhận một số rủi ro
63
Ngoài ra, ng−ời quản lý dự án còn cần phải quan tâm đến sự phối thuộc với các
dự án khác và thông tin cho ng−ời quản lý cấp trên... Ph−ơng pháp tiếp cận của ng−ời
quản lý dự án
• hiểu rõ mục tiêu (tìm cách định l−ợng các mục tiêu bất cứ khi nào có thể)
• hiểu rõ các ràng buộc (chi phí, lịch biểu, tính năng...)
• lập kế hoạch để đạt d−ợc mục tiêu trong các ràng buộc
• giám sát và điều chỉnh kế hoạch
• tạo môi tr−ờng làm việc ổn định, năng động cho nhóm
Quản lý tồi sẽ dẫn đến sự chậm trễ của dự án, tính năng yếu kém và tăng chi phí
phát triển. Một ví dụ kinh điển về quản lý tồi là dự án hệ điều hành OS360 của IBM
bị chậm 2 năm so với kế hoạch.
6.2 Độ đo phần mềm
Để quản lý chúng ta cần định l−ợng đ−ợc đối t−ợng quản lý cần quản lý, ở đây là phần
mềm và qui trình phát triển. Chúng ta cần đo kích cỡ phần mềm, chất l−ợng phần mềm,
năng suất phần mềm...
6.2.1 Đo kích cỡ phần mềm
Có hai ph−ơng pháp phổ biến để đo kích cỡ phần mềm là đo số dòng lệnh (LOC -
Lines Of Code) và đo điểm chức năng (FP - Function Points). Độ đo LOC t−ơng đối
trực quan, tuy nhiên phụ thuộc rất nhiều vào ngôn ngữ lập trình cụ thể. Từ kích cỡ của
phần mềm (LOC), chúng ta có thể tính một số giá trị nh−
- Hiệu năng = KLOC/ng−ời-tháng
- Chất l−ợng = số khiếm khuyết/KLOC
- Chi phí = giá thành/KLOC
Các thông số của các dự án đã phát triển trong quá khứ sẽ đ−ợc dùng dể phục vụ
cho −ớc l−ợng cho các phần mềm sẽ phát triển.
Điểm chức năng FP đ−ợc tính dựa trên đặc tả yêu cầu và độc lập với ngôn ngữ phát
triển. Tuy nhiên nó lại có sự phụ thuộc vào các tham số đ−ợc thiết lập dựa trên kinh
nghiệm. Mô hình cơ sở của tính điểm chức năng là
FP = a1I+ a2O + a3E + a4L + a5F,
trong đó
- I : số Input
- O: số Output
- E: số yêu cầu
- L: số tệp truy cập
- F: số giao diện ngoại lai (devices, systems)
64
6.2.2 Độ đo dựa trên thống kê
Ng−ời ta còn thiết lập một số độ đo phần mềm dựa trên thống kê nh− sau:
- Độ tin cậy MTBF - Mean Time Between Failure: thời gian chạy liên tục của hệ
thống
- Thời gian khôi phục hệ thống MTTR - Mean Time To Repair
- Tính sẵn có M TB F/(M TB F + M TTR)
6.3 Ước l−ợng
Công việc đầu tiên của ng−ời quản lý dự án là −ớc l−ợng - −ớc l−ợng về kích cỡ, chi
phí, thời gian tiến hành dự án. Việc này thông th−ờng đ−ợc tiến hành bằng cách phân
rã phần mềm cần phát triển thành các khối nhỏ và áp dụng các kinh nghiệm (các thông
số nh− kích cỡ, chi phí, năng lực nhân viên...) đối với các phần mềm đã phát triển để
−ớc l−ợng, đánh giá công việc.
Một mô hình −ớc l−ợng hay đ−ợc dùng là mô hình COCOMO - Constructive Cost
Model −ớc l−ợng chi phí từ số dòng lệnh. Dùng mô hình này ta sẽ có thể −ớc l−ợng
các thông số sau:
- Nỗ lực phát triển E = aLb
- Thời gian phát triển T = cE d
- Số ng−ời tham gia N = E /T
Trong đó a,b,c,d là các tham số tùy thuộc vào từng loại dự án (xem bảng 6.1).
Điểm đáng chú ý ở đây là từ nỗ lực phát triển chúng ta suy ra thời gian và số ng−ời
tham gia vào dự án.
Bảng 6.1: COCOMO - Các tham số cơ sở
a b c d
organic 3.2 1.05 2.5 0.38
semi-detached 3.0 1.12 2.5 0.35
embeded 2.8 1.2 2.5 0.32
Các b−ớc tiến hành của COCOMO nh− sau:
- thiết lập kiểu dự án (organic: đơn giản, semi-detached: trung bình, embeded: phức
tạp)
- xác lập các mô đun và −ớc l−ợng dòng lệnh
- tính lại số dòng lệnh trên cơ sở tái sử dụng
- tính nỗ lực phát triển E cho từng mô đun
- tính lại E dựa trên độ khó của dự án (mức độ tin cậy, kích cỡ CSDL, yêu cầu về
tốc độ, bộ nhớ,...)
- Tính thời gian và số ng−ời tham gia
65
Ví dụ: Phần mềm với 33.3 nghìn dòng lệnh và các tham số a,b,c,d lần l−ợt là 3.0,
1.12, 2.5, 0.35, ta tính đ−ợc:
E = 3.0∗33.31.12 = 152 ng−ời-tháng
T = 2.5∗E 0.35 = 14.5 tháng
N = E/D ≈ 11 ng−ời
Cần nhớ rằng đo phần mềm là công việc rất khó khăn do
• hầu hết các thông số đều không đo đ−ợc một cách trực quan
• rất khó thẩm định đ−ợc các thông số
• không có mô hình tổng quát
• các kỹ thuật đo còn đang thay đổi
Chúng ta không thể kiểm soát đ−ợc quá trình sản xuất phần mềm nếu không −ớc l−ợng
(đo) nó. Một mô hình −ớc l−ợng nghèo nàn vẫn hơn là không có mô hình nào và phải
liên tục −ớc l−ợng lại khi dự án tiến triển.
6.4 Quản lý nhân sự
Chi phí (trả công) con ng−ời là phần chính của chi phí xây dựng phần mềm. Ngoài ra,
năng lực của ng−ời phát triển phần mềm lại rất biến thiên, kéo theo sự phức tạp trong
tính toán chi phí.
Phát triển phần mềm đ−ợc tiến hành theo nhóm. Kích th−ớc tốt của nhóm là từ 3
đến 8 ng−òi. Phần mềm lớn th−ờng đ−ợc xây dựng bởi nhiều nhóm nhỏ. Một nhóm
phát triển có thể gồm các loại thành viên sau:
• ng−ời phát triển
• chuyên gia về miền ứng dụng
• ng−ời thiết kế giao diện
• thủ th− phần mềm (quản lý cấu hình phần mềm)
• ng−ời kiểm thử
Một nhóm phát triển cần có ng−ời quản lý, và ng−ời có vai trò lãnh đạo về mặt kĩ
thuật.
Một đặc tr−ng của làm việc theo nhóm là sự trao đổi thông tin (giao tiếp) giữa các
thành viên trong nhóm. Thời gian dùng cho việc giao tiếp có thể chiếm đến nửa tổng
thời gian dành cho pháp triển phần mềm. Ngoài ra, thời gian không dùng cho phát triển
sản phẩm cũng chiếm một phần lớn thời gian còn lại của ng−ời lập trình.
Một ng−ời có thể đồng thời làm việc cho nhiều nhóm (dự án) phần mềm khác nhau.
Điều này làm cho việc tính toán giá thành phần mềm phức tạp.
Cần ghi nhớ, trong sản xuất phần mềm thì
- Năng lực của các thành viên là không đồng đều
- Ng−ời tốt (nhất) có thể sản xuất hơn 5 lần trung bình, ng−ời kém có thể không
cho kết quả gì
66
- Một số công việc quá khó đối với mọi ng−ời
Không nên tăng số thành viên một cách vô ý thức, vì nh− thế chỉ làm tăng sự phức
tạp giao tiếp giữa các thành viên, khiến công việc nhiều khi chậm lại. Một số việc
(phức tạp, đăc thù) chỉ nên để một ng−ời làm.
6.5 Quản lý cấu hình
Quản lý cấu hình phần mềm (còn gọi là quản lý mã nguồn) là một công việc quan trọng
trong sản xuất phần mềm. Mã nguồn (và dữ liệu) là sản phẩm chính của dự án phần
mềm.
Quản lý cấu hình đ−ợc tự động hóa thông qua các công cụ. Nhiệm vụ chính của
công cụ quản lý là:
• l−u trữ mã nguồn
• tạo ra một điểm truy cập duy nhất (phiên bản thống nhất) cho ng−ời lập trình sửa
đổi, thêm bớt mã nguồn.
Do đó chúng ta có thể dễ dàng:
• kiểm soát đ−ợc tính thống nhất của mã nguồn
• kiểm soát đ−ợc sự sửa đổi, lý do của sự sửa đổi, lý lịch các lần sửa đổi
• dễ dàng l−u trữ và truy cập tới các phiên bản khác nhau của phần mềm
• tối −u hóa vùng đĩa cần thiết cho l−u trữ
Ph−ơng thức hoạt động của các công cụ này là:
• quản lý tập chung (mã nguồn, t− liệu, công cụ phát triển...)
• các tệp đ−ợc tạo một lần duy nhất, các phiên bản sửa đổi chỉ ghi lại sai phân đối
với bản gốc
• sử dụng ph−ơng pháp check out/check in khi sửa đổi tệp
Thông th−ờng, ng−ời phát triển khi muốn sửa đổi mã nguồn sẽ thực hiện thao tác check
out tệp đó. Khi tệp đã bị check out thì các ng−ời phát triển khác chỉ có thể mở tệp d−ới
dạng chỉ đọc. Khi kết thúc sửa đổi và ghi tệp vào CSDL, ng−ời sửa đổi tiến hành check
in để thông báo kết thúc công việc sửa đổi, đồng thời có thể ghi lại các thông tin liên
quan (lý do sửa đổi...) đến sự sửa đổi.
Dữ liệu đ−ợc l−u trữ của dự án thông th−ờng bao gồm:
• mã nguồn
• dữ liệu
• t− liệu
• công cụ phát triển (ch−ơng trình dịch...), th−ờng cần để đảm bảo t−ơng thích với
các phiên bản cũ, và để đảm bảo ch−ơng trình đ−ợc tạo lại (khi sửa lỗi...) đúng
nh− cái đã phân phát cho khách hàng
• các ca kiểm thử
Một số các công cụ quản lý cấu hình phổ biến là RCS, CVS trên HĐH Solaris và
SourceSafe của Microsoft.
67
6.6 Quản lý rủi ro
Quản lý rủi ro là một công việc đặc biệt quan trọng và khó khăn trong phát triển phần
mềm. Có các nguyên nhân (rủi ro) sau dẫn đến chấm dứt dự án:
• chi phí phát triển quá cao
• quá chậm so với lịch biểu
• tính năng quá kém so với yêu cầu
Quản lý rủi ro bao gồm các công việc chính sau:
• dự doán rủi ro
• đánh giá khả năng xảy ra và thiệt hại
• tìm giải pháp khắc phục
D−ới đây là các rủi ro th−ờng xẩy ra khi phát triển phần mềm và các ph−ơng pháp
khắc phục chúng:
• thiếu ng−ời phát triển: sử dụng những ng−ời tốt nhất; xây dựng nhóm làm việc;
đào tạo ng−ời mới
• kế hoạch, dự toán không sát thực tế: −ớc l−ợng bằng các ph−ơng pháp khác nhau;
lọc, loại bỏ các yêu cầu không quan trọng.
• phát triển sai chức năng: chọn ph−ơng pháp phân tích tốt hơn; phân tích tính tổ
chức/mô hình nghiệp vụ của khách hàng
• phát triển sai giao diện: phân tích thao tác ng−ời dùng; tạo kịch bản cách dùng;
tạo bản mẫu.
• yêu cầu quá cao: lọc bớt yêu cầu; phân tích chi phí/lợi ích.
• thay đổi yêu cầu liên tục: áp dụng thiết kế che dấu thông tin; phát triển theo mô
hình tiến hóa.
68
Tài liệu tham khảo
[1] Kent Beck, Extreme Programming Explained, Addison-Wasley, 2000.
[2] Bruce Eckel, Thinking in Java, 3rd ed., 2002.
[3] Mike Gancarz, The Unix Philosophy, Digital Press, 1994.
[4] Roger S. Pressman (dịch: Ngô Trung Việt), Kỹ nghệ phần mềm, Tập I,II,III, NXB
Giáo dục, 1997.
[5] Walker Royce, Software Project Management - A Unified Framework, Addison-
Wesley, 1998.
[6] Stephen R. Schach, Classical and Object-Oriented Software Engineering with
UML and C++, 4th ed., McGraw-Hill, 1999.
[7] Ian Sommerville, Software Engineering, 6th ed., Addison-Wasley, 2001.
[8] Nguyễn Quốc Toản, Bài giảng về Nhập môn Công trình học phần mềm, Khoa
Công nghệ, 1999.
[9] Lê Đức Trung, Công nghệ phần mềm, NXB Khoa học và Kỹ thuật, 2001.
[10] Ngô Trung Việt, Nguyễn Kim ánh (biên soạn), Nhập môn Công nghệ phần mềm,
NXB Khoa học và kỹ thuật, 2003.
[11] Nguyễn Văn Vỵ, Phân tích thiết kế các hệ thống thông tin hiện đại, NXB Thống
kê, 2002.
69