pdf

1

NHẬP MÔNNHẬP MÔNCÔNG NGHỆ PHẦN MỀMCÔNG NGHỆ PHẦN MỀM

TS. Trần Cao ĐệNăm 2010

TRƯỜNG ĐẠI HỌC CẦN THƠKHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

BỘ MÔN CÔNG NGHỆ PHẦN MỀM

CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 2

Nội dung môn học• Chương 1: Giới thiệu về CNPM• Phần 1: Quản lí phần mềm

Chương 2: Giới thiệu về quản lí phần mềm - Quản lí dự án phần mềmChương 3: Các mô hình về tiến trình phần mềmChương 4: Quản lí cấu hình (6)Chương 5: Quản lí nhân sự và tổ chức (6)Chương 6: Quản lí chất lượng (5)Chương 7: Ước lượng giá thành (1)Chương 8:

• Phần 2: Tiến trình phần mềmChương 9: Đặc tả yêu cầu (2)Chương 10: Kiến trúc phần mềm (4)Chương 11: Thiết kế phần mềm (4)Chương 12: Phân tích và thiết kế HĐT Chương 13: Kiểm thử phần mềm (3)

Tự Tham khảo: Chương 14: Bảo trì phần mềmChương 19: Software Tools

2


Tài liệu tham khảo • Sách tham khảo chính:

1. Hans Van Vliet, Software Engineering principles and practice, John Wiley, 2000.

2. Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill, 5th edition, 2003.

• Sách đọc thêm1. Ian Sommerville, Software Engineering, 6th edition 2000.2. Nhập môn CNPM, Ngô Trung Việt dịch. 3. Jacobson I., Object-Oriented Software Engineering: A use case driven

approach, Addison-wesley, 1995.4. Pascal Roques, UML par la pratique, Eyrolles, Paris, 2000.5. Michel Lai, UML – La notation unifiée de modélisation objet, de Java aux

EJB, Dunod, Paris, 2000

• Web http://www.sei.cmu.edu/


Cách đánh giá (SV CNPM) • Project: 40%

– Nhóm 9 SV– Phát triển một phần mềm theo các yêu cầu của KTPM

• Tự lập nhóm, tự đặt ra đề tài viết đặc tả (bằng lời). Lưu ý đặt đềtài nhỏ thôi!

• Tự tham khảo UML, viết đặc tả UML, thiết kế, test cases • Ước lượng effort, time• Phát triển phần mềm, help, tài liệu, test• Đóng gói, bàn giao, báo cáo

– Yêu cầu NN: dùng môi trường phát triển chuyên nghiệp• C++: Visual C++ hoặc tương đương• .NET: VB.NET, C#• Java: Jbuilder, Eclipse

Thi cuối kỳ: 60%– Trắc nghiệm 40-50 câu (40-60 phút)– Sau kết thúc môn 1 tuần

3


Đánh giá (CH K15)

• Thảo luận: 10%• Đồ án: 30%• Thi trắc nghiệm: 60%


Liên hệTS. Trần Cao ĐệBộ môn Công Nghệ Phần MềmKhoa CNTT & [email protected]

**Các email sẽ được trả lời trong thời gian 3 ngày

4

Phần 1TỔNG QUAN VỀ CNPM

TS. TRẦN CAO ĐỆNĂM 2009

Chương 1: Giới thiệu về CNPM

5


PHẦN MỀM• Phần mềm là gì?

- Là hệ thống gồm có chương trình máy tính, tài liệu, dữ liệu và qui trình vận hành các chương trình đó để vận hành hệ thống máy tính

- Phần mềm không chỉ là các chương trình máy tính mà còn bao gồmcả các tài liệu cần thiết cho việc phát triển và bảo trì các chươngtrình đó.

- Ngày nay các phần mềm là phần không thể thiếu trong hệ thống tácnghiệp tại các cơ quan, xí nghiệp

- Phần mềm có mặt khắp nơi: điện thoại di động, máy lạnh, máy giặt, đồ chơi,…

• Chất lượng phần mềm như thế nào? Phần mềm kém chấtlượng có tác hại gì?


Lỗi phần mềm

6


Lỗi phần mềm (tt)

• Hình ảnh tên lửa Ariane5 nổ tung ngày4/6/1996 sau vài giâyđược phóng lên, thiệthại 500.000.000$US.

• Image source: European Space Agency


Lỗi phần mềm (tt)• Máy xạ trị triệu $, chế tạo

bởi Canada + Pháp.

• 1985-1987: KTV thao táclỗi, máy hào phóng choquá liều bình thường ítnhất với 6 bệnh nhân.

• Kết quả:– Chết 3– Số còn lại ngoắc ngoải!

Therac – 25

7



• Sân bay Denver (USA), 1994• Bugs trong hệ thống quản lí hành lí (Baggage

Handling System) đã làm cho hệ thống chậmtiến độ 16 tháng, thiệt hại mỗi ngày1.000.000 $US.

• Tổng số thiệt hại > số tiền đầu tư cho dự án(234M)

• Nếu tính tổng số tiền phải chi để thao tácbằng tay, thiệt hại lên đến hơn 3G $US



• Ở VN: - Chưa nghe nói có phần mềm nào kém chất

lượng- SV có thể thêm vd vào đây

8


1. Công nghệ phần mềm là gì?• Thuật ngữ Software Engineering

– Sơ lược lịch sử• Khủng hoảng phần mềm• Các vấn đề trong phát triển phần mềm• Sự phát triển vượt bậc của phần cứng• Vấn đề bảo trì phần mềm

– CNPM là: (1) áp dụng cách tiếp cận có hệ thống, khoa học và định lượng vào phát triển, vận hành vàbảo trì phần mềm; (2) nghiên cứu các cách tiếp cậnnêu trên [IEEE93].

– CNPM là việc thiết lập và dùng các nguyên tắc côngnghệ đúng đắn để thu được phần mềm một cách kinhtế nhất và chạy hiệu quả trên các máy thật [NATO68].


Công nghệ phần mềm• Một môn khoa học tập trung vào việc thực hiện

các hệ thống PM lớn, phức tạp và được pháttriển bởi một đội kỹ sư phần mềm.

• Lý thuyết, phương pháp và công cụ để PTPM chuyên nghiệp

• CNPM quan tâm tới việc xây dựng hệ thống lớn– Kiềm chế/kiểm soát độ phức tạp– Sự tiến triển của phần mềm– Hiệu quả phát triển phần mềm: giá thành, thời gian,

tính dễ bảo trì– Hợp tác giữa các thành viên, nhóm– Đáp ứng hiệu quả yêu cầu người dùng: dễ dùng,

chức năng phù hợp với yêu cầu.– Tính đa ngôn ngữ, đa văn hóa

9


Khủng hoảng PM những năm 70

2%

3%

20%

45%

30%

chạy lúc bàn giao

Chạy sau khi có một sốthay đổi nhỏChạy sau khi đã sửa đổilớnkhông bao giờ dùng

trả tiền nhưng không cógiao hàng


Ở đầu thế kỷ 21Standish Group, CHAOS Report, 2002

– 28% of software projects succeed– 72% of software projects failed

Why so bad? Lack of user input

Unclear objectivesIncomplete requirements and specifications Changing requirements and specificationsLack of planning

10


• CNPM là môn học liênquan tới mọi khía cạnhtrong sx PM

• Mục tiêu của CNPM là làm sao để tạo ra phần mềm:– Có chất lượng cao

• Đúng, thỏa yêu cầu kháchhàng

• Dễ khai thác, vận hành• Dễ bảo trì

– Đúng kế hoạch thời gian– Trong phạm vi ngân sách

dự kiến– Giá thành ngày càng hạ

• Phạm vi của CNPM [PRES00]– Điều hành và theo dõi dự

án phần mềm– Qui trình phần mềm– Xem xét các kỹ thuật hình

thức– Đảm bảo chất lượng phần

mềm– Công tác tài liệu– Sử dụng lại– Đo lường phần mềm– Quản lí rủi ro dự án phần

mềm

2. Phạm vi của CNPM


3. Các giai đoạn trong phát triển PM

• Đặc tả• Thiết kế• Cài đặt / phát triển• Kiểm thử• (Triển khai)• Bảo trì

11


• Tìm hiểu yêu cầu: thuthập mô tả đầy đủ của bàitoán– Chức năng/tính năng của

software– Khả năng mở rộng– Các loại tài liệu đòi hỏi– Thời gian đáp ứng hoặc

các yêu cầu về chất lượngcủa hệ thống

– Nghiên cứu khả thi

• Thiết kế: mô hình hóa hệthống, module hóa hệthống– Kiến trúc hệ thống

• Cài đặt: tập trung vàotừng module riêng lẻ:– Giải thuật– Tài liệu– Coding

• Kiểm thử: thử và xácnhận tính đúng đắn của– Tài liệu đặc tả– Thiết kế– Module– Chuyển tiếp giữa các giaiđoạn

• Bảo trì– Sửa lỗi– Đáp ứng thay đổi yêu cầu


4. Công sức của từng giai đoạn40-20-40

xác định yêu cầu, 10%

đặc tả, 10%

thiết kế, 15%

cài đặt, 20%

kiểm thử, 45%

12


5. Công tác bảo trì• Only thing we maintain is

user satisfaction – Sửa lỗi còn sót trong

chương trình– Thích ứng với các thay đổi

(hardware, OS)– Hoàn thiện: thích ứng với

các yêu cầu mới, tăng hiệuquả, cải tiến giao diện

– Phòng ngừa (preventive): làm cho dễ bảo trì hơntrong tương lai

sửa lỗi (corrective),

21%

thiích ứng (adaptive), 25%

hoàn thiện (perfective),

50%

phòng ngừa (preventive), 4%

Phân phối các hoạt động bảo trì


Các thuật ngữ

Phần mềm (software)Mã lệnh (code)Các dạng tài liệu đặc tả, thiết kế, kế hoạch kiểm thử, tích hợp…Các dạng tài liệu hướng dẫn sử dụng, bảo trì.

Chương trình (program):là một đoạn mã lệnh có thể thực thi được trên máy tínhHệ thống (system): tập hợp các chương trình liên quan với nhauSản phẩm (product) phần mềm

Một mẩu bình thường của phần mềmKết quả đạt được sau một tiến trình (process) phát triển phần mềm

Sản xuất phần mềm (software production) Phát triển phần mềm (software development)Bảo trì (maintenance)

13


Phân loại phần mềm

• Hệ thống- Compiler - HĐH

• Thời gian thực- PM điều khiển CN.- PM điều độ điện.

• Tác nghiệp- CSDL - Hỗ trợ nghiệp vụ

• Hệ thống nhúng- Điều khiển máy móc- Tự động, robot.

• Khoa học KT- Simulation- Tính toán khoa học

• PM máy tính cá nhân-Văn phòng-Trò chơi

• Trí tuệ nhân tạo- Hệ CG- Mạng neuron


Phân loại phần mềm (cách khác)• PM đặc thù: cho

khách hàng riêng lẻ• PM tổng quát (chung):

bán ra TT • Nhúng

– Tích hợp vào phầncứng

– Khó sửa đổi

• PM thời gian thực– Hệ thống điều khiển &

bảo vệ– Hành động đáp ứng 1

sự kiện với 1 lượngthời gian hạn chế

• PM xử lí dữ liệu– Dùng trong quản lí và

tác nghiệp– Kết quả tin cậy– An ninh trong truy cập

• 1 PM có thể có cả 2 đặc tính trên

14


Các đặc tính của phần mềm• Phần mềm được phát

triển chứ không chế tạo.• Phần mềm có tính cá thể

hơn là sx theo kiểu lắp ráp hàng loạt

• Không « rách » nhưng lỗi thời

• Độ phức tạp của phần mềm– Tác động lên tiến trình– ảnh hưởng đến quản lí– ảnh hưởng đến chất lượng

• Tính vô hình• Phần mềm mang lại cơ

hội kinh doanh, tăng khả năng cạnh tranh

• Các luật trong PTPM (Lehman và Belady)– Thay đổi liên tục: hệ thống

PM luôn thay đổi thậm chílà thay mới hoàn toàn

– Độ phức tạp ngày càngtăng

– Tiến triển của chương trình• Độ tăng trưởng của hệ

thống toàn cục xuất pháttừ các bất ổn cục bộ

– Nhịp độ/cường độ làm việclà bất biến

– Giới hạn tăng trưởng: Khităng trưởng quá mức sẽdẫn đến vấn đề chất lượngvà sử dụng.


Tóm tắt chương• CNPM tập trung vào lí thuyết, PP và công cụ để

phát triển quản lí và triển khai sản phẩm PM. • SP PM bao gồm chương trình dữ liệu và tài liệu• Chất lượng SP PM được đánh giá qua tính hiệu

quả, độ tin cậy, khả năng bảo trì được• Qui trình PM là tập hợp các họat động để phát

triển PM.

• Bài tập 1 8 trang 29

15

Chương 2: Giới thiệu về quản lí phần mềm

và quản lí dự án phần mềm


1. Vấn đề Quản lí phần mềm• Phát triển phần mềm:

– Nhiều người– Thời gian dài

• Quản lí– Thiết lập cột mốc các sự

kiện chính– Tài liệu

• Kinh nghiệm cho thấy: – Giao hàng chậm– Vượt ngân sách– Khách hàng không hài lòng

• Các lí do thường gặp– Lập trình viên không nói sự

thật về trạng thái của code.– Nhà quản lí ước lượng

thiếu thời gian– Nhà quản lí không đủ thời

gian để lập kế hoạch cẩnthận

– Năng suất thấp hơn dựkiến

– Khách hàng không biết họcần gì

– Phân tán nguồn lực chonhiều dự án cùng một lúc

16


Quản lí dự án phần mềm• Các hoạt động nhằm đảm bảo thành công của

dự án– Giao hàng đúng thời hạn– Thỏa mãn yêu cầu người dùng– Trong phạm vi ngân sách dự kiến

• Các hoạt động– Viết đề cương– Kế hoạch và lịch biểu cho PM.– Ước lượng giá.– Kiểm tra và kiểm soát dự án.– Sử dụng người và đánh giá.– Viết báo cáo và trình bày.


Các nội dung chính trong QL dự án– Các chuẩn, hướng dẫn, qui

trình:– Hoạt động quản lí

• Làm sao đạt mục tiêu dựán

• Hội họp, báo cáo• Xác định ưu tiên trong cân

bằng giữa: đòi hỏi, ngânsách và thời gian

– Đánh giá rủi ro: nhận diệncác tác động xấu đến dựán

– Kế hoạch nhân lực• Dự án cần số người khác

nhau và kỹ năng khácnhau tại những thời điểmkhác nhau

– PP và KT dùng trong tiếntrình PM: đặc tả, phân tích, thiết kế, code, test …

– Đảm bảo chất lượng:• Ai?• Làm gì?• Các bước tiến hành?

– Phân gói công việc• Chia nhỏ dự án

– Nguồn lực phần cứng– Ngân sách và kế họach

thời gian– Thay đổi– Bàn giao

17


Phát triển phần mềm là phát triển HT• Phát triển phần mềm

là phát triển một hệthống– Software– Hardware– Document– Qui trình dùng hệ

thống– Người dùng hệ thống

• Một hệ thống baogồm nhiều thànhphần

• Kết quả của việc pháttriển phần mềm làmột tập hợp cácchương trình cungcấp các chức năngmong muốn


Phát triển phần mềm là phát triển hệ thống

18


2. Quan điểm hệ thống vềkiểm soát dự án

• Kiểm soát dự án đượcmô tả:– Hệ thống được kiểm soát– Các thực thể kiểm soát

(người quản lí, tổ chức vàquyết định)

– Thông tin dùng để ra quyếtđịnh

• Bên trong• Bên ngoài

• 3 trục chính trong mụctiêu kiểm soát:– Thời gian– Hiệu quả– chất lượng

• Theo lý thuyết về hệthống, các điều kiện đểkiểm soát hiệu quả hệthống:– thực thể kiểm soát phải

biết mục tiêu của hệ thống– thực thể kiểm soát phải có

các biện pháp kiểm soátkhác nhau

– thực thể kiểm soát phải cóthông tin về trạng thái, đầuvào, đầu ra của hệ thống

– thực thể kiểm soát phải cómô hình quan niệm chokiểm soát (biết phạm vi vàtác động qua lại giữa cácyếu tố khác nhau)


3. Kiểm soát dự án phần mềm• Nội dung kiểm soát

– Thời gian– Thông tin– Tổ chức– Chất lượng– $$$

• Tiến trình dự án (thờigian): – rất khó đo

• “90% code đã hoànthành!”

– Đo bằng số nhân lực đòihỏi

• Nhân lực đòi hỏi = size hệthống

• Brook’s law: adding people to a late project only make it later.

• Thông tin– Tài liệu– Trạng thái hiện tại của dự

án– Các thay đổi– Các quyết định

• Tổ chức– Vai trò của từng thành viên– Giao tiếp– Hợp tác

19


Kiểm soát dự án phần mềm (tt)• Chất lượng

– Đánh giá chất lượngxuyên suốt quá trìnhphát triển

– Chất lượng = thỏamãn khách hàng (user satisfaction)

• $$$– Đội ngũ kinh nghiệm

“rẽ hơn” đội ngũ mới– Dùng công cụ để cải

tiến năng suất

• Nguyên tắc kiểmsoát: Định lượng– Thu thập dữ liệu– Phương pháp phân

tích, đánh giá


4. Qui tắc và đạo đức nghề nghiệp• Software engineering involves wider responsibilities than simply the

application of technical skills.• Software engineers must behave in an honest and ethically responsible way

if they are to be respected as professionals.• Ethical behaviour is more than simply upholding the law.• Confidentiality

– Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.

• Competence – Engineers should not misrepresent their level of competence. They should not

knowingly accept work which is outwith their competence.• Intellectual property rights

– Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.

• Computer misuse – Software engineers should not use their technical skills to misuse other people’s

computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).

20

Lập kế hoạch và kiểm soát dự án


1. Lập kế hoạch cho dự án phần mềm• Trước khi triển khai một

dự án, phải có kế hoạchcẩn thận: đánh giá tất cảcác yếu tố liên quan đếnqui trình phát triển PM

• Đặc điểm:– Không đủ thông tin– Lập kế hoạch không phải là

một việc làm 1 lần– Kế hoạch mang tính động

• Các nội dung chính trongdự án– Mở đầu:

• Lịch sử dự án• Tên người chịu trách

nhiệm• Tóm tắt dự án

– Mô hình tiến trình• Các bước/cột mốc chính

– Tổ chức dự án• Mối liên hệ giữa dự án và

các thực thể khác trong vàngoài tổ chức

• Người dùng• Phân công trong dự án

21


Kế hoạch cho mọi hoạt động trong dự án

Plan Description

Quality plan Describes the quality procedures and standards that will be used in a project.

Validation plan Describes the approach, resources and schedule used for system validation.

Configuration management plan

Describes the configuration management procedures and structures to be used.

Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required.

Staff development plan.

Describes how the skills and experience of the project team members will be developed.


Qui trình lập kế hoạchEstablish the project constraints Make initial assessments of the project

parameters Define project milestones and deliverableswhile project has not been completed or

cancelled loopDraw up project scheduleInitiate activities according to scheduleWait ( for a while )Review project progressRevise estimates of project parametersUpdate the project scheduleRe-negotiate project constraints and deliverablesif ( problems arise ) then

Initiate technical review and possible revisionend if

end loop

22


Các khía cạnh phải có trong kế hoạch

• Nguồn lực dành cho dự án• Chia nhỏ công việc• Lịch biểu cho dự án


2. Phân loại các dự án PTPM• 3 lớp đặc trưng của dự án:

– đặc trưng của sản phẩm– đặc trưng của qui trình– đặc trưng của nguồn lực

• Các đặc trưng có mức độ xácđịnh và chắn chắn khắc nhau

• 3 chiều trong dự án phát triểnphần mềm

– Product certainty: mức độxác định trong mô tả sảnphẩm, ví dụ: đặc tả rõ ràng, hoàn chỉnh

– Process certainty: mức độxác định của qui trình, tức làkhả năng định hướng lạihoặc thiết lập lại qui trìnhphát triển, sự hiểu biết vềcác hoạt động kiểm soát.

– Resource certainty: mức độcủa nguồn lực hiện có: độingũ có chất lượng, tiềm lực tàichính...

• 4 trạng thái điển hình:– Realization: khả thi; các chiều

đều chắc chắn; chỉ cần rà soátđể có hiệu quả cao

– Allocation: cần bố trí lại nguồnlực

– Design: cần phải design project & bố trí nhân lực

– Exploration: trạng thái khókhăn; phải “mày mò”; hiệu quảkhông đoán được.

23


3. Quản lí rủi ro• Rủi ro là một sự kiện có thể

xảy ra trong tương lai và khi nóxảy ra sẽ có ảnh hưởng tiêucực tới sự thành công của mộtcông việc.

• Quản lí rủi ro– không phải là giải quyết sự cố– chỉ là nhận diện rủi ro và tìm

cách ngăn ngừa rủi ro• Các bước quản lí rủi ro

– nhận diện yếu tố rủi ro– với mỗi yếu tố, tính xác suất

xảy p và mức độ ảnh hưởngE.

– Xác định cách giảm nhẹ rủi ro– Xác định cách khống chế các

yếu tố rủi ro

• 10 rủi ro hàng đầu trong PTPM– thiếu hụt nhân sự (Personal

shortfall).– Thời gian và ngân sách không

thực tế; có thể do ước lượng sai)– Phát triển sai chức năng– Sai giao diện– “Mạ vàng” (Gold plating): phát

triển các đặc trưng không đượcyêu cầu.

– Sự không ổn định của đặc tả– Các thành phần bên ngoài hỏng

(vd dùng nguồn mở)– Các công việc bên ngoài bị đình

trệ (các hợp đồng con với bênngoài hỏng)

– Không đáp ứng các yêu cầu thờigian thực (real-time shortfalls)

– thiếu khả năng (Capability shortfalls)


4. Kỹ thuật lập kế hoạch và kiểm soát• Nguyên tắc chung

– Chia nhỏ dự án thành các công việc (đơn thể) kiểm soát được– Mỗi đơn thể có một cột mốc thời gian và nguồn lực có thể kiểm

soát được tiến độ.– Các đơn thể thường được thực hiện theo một trật tự nào đó Vì

vậy có thể lập bảng công việc & các biểu đồ như PERT, GANTT

24


Công việc, thời gian và phụ thuộc Activity Duration (days) Dependencies

T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)


Sơ đồ tiến trình

PERT chart

GANTT chart

25


Tiến trình


Phân bổ nhân lực

26


Tổng kết chương• Lập dự án là cần thiết, trước khi phát triển PM.• Kết quả: tài liệu, kế hoạch dự án. Bức tranh tổng thể, rõ

ràng về dự án• Kiểm soát dự án

– Thời gian– Thông tin– Tổ chức– Chất lượng– $$$

• Quản lí dự án theo quan điểm kiểm soát hệ thống• Quản lí rủi ro• Kỹ thuật lập kế hoạch và kiểm soát

Bài tập 1-9 trang 198


6. Tổng kết chương• Lập dự án là cần

thiết, trước khi pháttriển PM.

• Kết quả: tài liệu, kếhoạch dự án. Bứctranh tổng thể, rõràng về dự án

• Kế hoạch cho dự án

• Kiểm soát dự án– Thời gian– Thông tin– Tổ chức– Chất lượng– $$$

27

Chương 3:Các mô hình về tiến trình phần mềm


1. Tiến trình phần mềm• A software process model is an abstract representation

of a process. It presents a description of a process from some particular perspective.

• Tiến trình phần mềm là cách thức tạo ra phần mềm, mỗi công ty có tiến trình phần mềm riêng• Khách hàng (client): cá nhân hay công ty đặt hàng sản phẩm • Nhà phát triển (developer): các thành viên của công ty có trách

nhiệm phát triển phần mềm đã được đặt hàng• có thể quán xuyến toàn bộ các công việc của sản phẩm • có trách nhiệm một phần như thiết kế, cài đặt,...

• Người sử dụng (user): một hay nhiều cá nhân thay mặt kháchhàng để sử dụng sản phẩm

• Phát triển phần mềm (software development): bao gồmtất cả các công việc tạo ra sản phẩm trước khi nó đượcchuyển sang giai đoạn bảo trì

28


2. Sự cần thiết của kiểm soát tiến trình và tiếnđộ

• Dự án phát triển phầnmềm là rất lớn– Nhiều người– Thời gian dài– Dùng các nguồn lực khác

nhau…– Có sự cạnh tranh giữa các

mục tiêu

• Cần thiết phải:– Kiểm soát tiến trình– Kiểm soát nguồn lực– Kiểm soát tiến độ

• Qui trình/Mô hình pháttriển phần mềm– Qui trình: định nghĩa các

bước trong tiến trình PM.– Tài liệu hóa qui trình

• Các mô hình PTPM– Mô hình xây dựng và hiệu

chỉnh– Mô hình thác nước– Mô hình định khung nhanh– Mô hình xoắn ốc– Các mô hình hướng đối

tượng– …


3. Các mô hình về tiến trình PM

• Mô hình xây dựng và hiệu chỉnh• Mô hình thác nước• Mô hình bản mẫu• Mô hình tăng trưởng• Phát triển ứng dụng nhanh• Mô hình xoắn ốc• Mô hình hướng đối tượng

29


3.1. Mô hình xây dựng và hiệu chỉnh(Build-and-fix model )

• Ad-hoc• Không có đặc tả hay thiết kế• Xây dựng 1 phiên bản, chỉnh sửa theo yêu

cầu của khách hành cho đến khi nào đápứng được yêu cầu của khách hàng

• Sử dụng trong các hệ thống rất nhỏ (100-200 dòng lệnh)


3.2. Mô hình thác nuớc (waterfall model)•Royce, 1970•V & V:

- Verification (kiểm tra): hệthống thỏa mãn đặc tả (Build the system right)-Validation (KT-xác nhận): hệthống thỏa mãn yêu cầu ngườidùng (Build the right system)

- Đặc điểm:-Hướng tài liệu-Phân tích kỹ trước khi xây dựnghệ thống- kiểm tra từng buớc-Kiểm tra chuyển tiếp giữa cácbước

30


Mô hình thác nước (tt.)

• Đặc tính: – Các lỗi ở một số giai đoạn trước được phản hồi bởi các giai đoạn sau– Mỗi giai đoạn chỉ được xem là hoàn thành sau khi đã có đầy đủ tài liệu

cho giai đoạn đó và được nhóm SQA chấp thuận• Các bước tiến hành chính:

– Các yêu cầu được xác định và kiểm chứng bởi khách hàng và nhómSQA

– Các đặc tả được kiểm chứng bởi nhóm SQA và gửi cho khách hàng– Giai đoạn thiết kế bắt đầu sau khi khách hàng đồng ý về giá thành và

thời gian thực hiện; thực hiện cài đặt và tích hợp– Khách hàng cho hoạt động thử– Chấp nhận sản phẩm – Chuyển sang giai đoạn bảo trì

• Ưu điểm: Kỷ luật cao; quy định tốt về tài liệu cho mỗi giai đoạn; kiểmchứng cẩn thận bởi nhóm SQA; được ứng dụng rộng rãi

• Khuyết điểm: – Quá nhiều kiểm thử, kiểm tra-xác nhận và tài liệu – Hướng tài liệu: khó hình dung và khó hiểu đối với khách hàng


3.3. Bản mẫu (prototyping)• Khó khăn để có 1 nhận thức

đầy đủ về hệ thống làm bảnmẫu.– Một mô hình về một phần

của hệ thống– Nhấn mạnh vào một vài

khía cạnh nào đó• Tạo ra một bản mẫu # làm

“bản thật”– Làm nhanh– Rẻ– Thể hiện được ý tưởng

trước khi đầu tư lớn

Dùng ngôn ngữ cấp caoPhát triển một HT với ítchức năng

31


Khuyến cáo cho việc dùng bản mẫu• Yêu cầu của người dùng không rõ ràng• Cần minh họa cao về giao diện người dùng• Bản mẫu là công cụ để đặc tả yêu cầu• Nguời dùng phải ý thức về sự thay đổi yêu cầu là rất khó

khăn. Bản mẫu không làm nâng cao chất lượng hệthống.

• Việc làm bản mẫu phải có kế hoạch và được kiểm soáttiến độ


3.4. Mô hình tăng trưởng

32


Mô hình tăng trưởng• Chức năng của hệ thốngđược xây dựng vàchuyển giao dần dần chongười dùng. Bắt đầu từtrạng thái hiện tại dầnđến trạng thái mongmuốn: từng bước nhỏ.

• Mô hình tăng trưởng– Tránh bị “big bang”: một

thời gian dài chẳng có gì, đùng một cái, cả một hệthống mới.

– Người dùng tham gia tíchcực vào việc lập kế hoạchcho bước tiếp theo

• Tránh “dư thừa chứcnăng” (overfunctionality)– Yêu cầu quá nhiều– Quá dư thừa chức năng sẽ

làm hệ thống phức tạp vàkhó sử dụng

• Người phân tích dễ dàngước lượng thời gian, công sức xây dựng mộtchức năng, đặc tính nàođó của PM.

• Cách tiếp cận tăngtrưởng giúp tập trung vàocác điểm cốt lõi và cácchức năng cần thiết đápứng yêu cầu thực tiễn.


3.5. Phát triển ứng dụng nhanh• Áp dụng mô hình tăng

trưởng cho nhiềunhóm RAD phát triểntrong một thời gianngắn

• Có sự tham gia củangười dùng trong quátrình phát triển

33


Lặp tăng trưởng trong phát triển nhanh


3.6. Mô hình xoắn ốc (spiral model)

Reviewpartition

Commitment

Requirements planLife-cycle plan

Simulations, models, benchmarmks

ImplementationAccep-tancetest

Inte-grationtest

Unittest

Code

Detaileddesign

Plan next phase

Concetp ofoperation

Developmentplan

Integration andtest plan

Design validationand verification

Requirementsvalidation

Software requirements

Riskanalysis

Prototype 1 Prototype 2

Prototype 3

Riskanalysis

Riskanalysis

Riskanalysis

Operationalprototype

Evaluate alternatives, identify, resolve risks

Determine objectives,alternatives, constraints

Cumulative cost

Progress through steps

Develop, verify next-level product

34


Mô hình xoắn ốc (tt.)• Hướng rủi ro (risk-driven); giảm thiểu rủi ro

– Các công việc luân phiên và chịu các ràng buộc đã hỗ trợ choviệc tái sử dụng phần mềm hiện có

– Đánh giá mức độ rủi ro– Mục tiêu quan trọng luôn là chất lượng phần mềm– Giảm nhẹ kiểm thử và nhanh chóng sửa chữa những lỗi xảy ra– Bảo trì đơn giản chỉ là một vòng tròn trong xoắn ốc, như vậy

không có sự phân biệt giữa phát triển và bảo trì• Dành riêng cho các phần mềm nội bộ có kích thước lớn• Có thể chấm dứt do các đánh giá về rủi ro, do đó sẽ rất

không hay khi đã ký kết các hợp đồng, rắc rối về mặt luật pháp

• Kích thước sản phẩm ảnh hưởng đến giá thành việcphân tích rủi ro


3.7. Mô hình hướng đối tượng

Mô hình vòi phun nước

Bảo trì

Thiết kế HĐT

Phân tích hướng đối tượng

Xác định yêu cầu

Cài đặtTích hợp

Đưa vào hoạt động

Phát triển thêm

35


Mô hình hướng đối tượng (tt.)

• Đặc tính quan trọng nhất là lặp:– giữa các giai đoạn– một phần trong giai đoạn

• Mô hình vòi phun nước thể hiện các giai đoạn gối lên nhau

• Giảm bớt nhân lực cho công tác bảo trì


RUP

36


4. So sánh các mô hình

So sánh giữa các mô hình tiến trình phần mềm

Có thể suy thoái thành CABTAB (thuật ngữ về sự thiếu kỷ luật trong công việc: trình tự thựchiện các công việc lung tung, bừa bãi)

Hỗ trợ việc lặp lại bên trong các giai đoạn, song song hóa giữa các giai đoạn

Các mô hình hướng đối tượng

Chỉ có thể sử dụng cho các sản phẩm có kích thước lớn haycho các tổ chức

Các nhà phát triển phải có khả năngphân tích rủi ro và giải quyết rủi ro

Kết hợp nhiều đặc điểm của tất cả các môhình phía trên

Mô hình xoắn ốc

Xem nhẹ tài liệu, khó bảo trìĐảm bảo sản phẩm được chuyển giao có được những gì khách hàng cần

Mô hình phát triển nhanh

Sản phẩm chuyển giao có thểkhông theo những gì kháchhàng cần

Tiếp cận có kỷ luậtHướng tài liệu

Mô hình thác nước

Không đáp ứng được các chươngtrình tương đối lớn trở đi

Tốt đối với các chương trình ngắn khôngyêu cầu về bảo trì

Mô hình xây dựng và hiệuchỉnh

Điểm yếuĐiểm mạnhMô hình


CASE• Computer- aided software engineering (CASE) is

software to support software development and evolution processes.

• Activity automation– Graphical editors for system model development;– Data dictionary to manage design entities;– Graphical UI builder for user interface construction;– Debuggers to support program fault finding;– Automated translators to generate new versions of a

program.• CASE weaknesses

– Software engineering requires creative thought - this is not readily automated;

– Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.

37


Tổng kết chương• Giới thiệu về tiến

trình/qui trình phầnmềm

• Các mô hình về tiếntrình phần mềm

• So sánh các mô hình

• Bài tập 1 9 trang 70

Chương 4:Quản lí cấu hình

38


Quản lí cấu hình• Tại sao phải quản lí cấu hình:

– Quản lí lượng lớn các phần tử: tài liệu, code, yêu cầuthay đổi

• Nhiều tài liệu• Thường xuyên thay đổi• Nhiều version

– Quản lí cấu hình nhằm đảm bảo cho các tài liệuthống nhất nhau.

• Các phần tử trong baseline có thể được thêm vào theo thờigian

• Một phần thay đổi sẽ sinh ra không thống nhất giữa các tàiliệu.

• Quản lí cấu hình là thiết lập và áp dụng cácchuẩn để quản lí mọi sự thay đổi của sản phẩmphần mềm.


Khái niệm baseline

• Tại một thời điểm, tất cả các văn bảnchính thức của dự án gọi là baseline.

• Baseline is a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development and that can be changed only through formal change control procedure [IEEE90]

• Baseline = {approved items}• Mỗi phần tử (item) được gọi là một phần

tử cấu hình

39


Nội dung quản lí• Các phần tử cấu hình

có thể là:– Các module chương

trình nguồn– Các module mã đối

tượng– Các đặc tả yêu cầu– Tài liệu thiết kế– Kế hoạch test– Các test cases– Các kết quả test– Tài liệu người dùng

• Cần phải quản lí mọithay đổi của các phầntử cấu hình

Thay đổi yêu cầu

Xem xétTừ chối

Thông báocho chủ đầutư

Chuẩn y thay đổi

Chuẩn bị và lập lịchcho gói công việc

Xếp đặt thứ tự ưu tiên

Cài đặt thay đổi Cập nhậtcấu hình

Xin ý kiếncủa chủ đầutư

Hoãn


Ví dụ về một yêu cầu thay đổi

40


CCB • Dự án lớn

– Ban QL cấu hình(CCB)

– Các thay đổi phải đưaqua CCB.

– CCB đánh giá cácthay đổi

– CCB đảm bảo rằngcác phần tử trong cấuhình là thống nhất

– Các phần tử chưađược duyệt chưađược đưa vàobaseline

Sơ đồ chuyển trạng thái củacác hoạt động phát triển


Kế hoạch quản lí cấu hình• Xác định các loại tài liệu cần được quản lí và một cấu

trúc lưu trữ (đặt tên)• Xác định người chịu trách nhiệm về qui trình quản lí cấu

hình và tạo ra baseline• Xác định chính sách quản lí thay đổi và quản lí version• Xác định các số liệu về quản lí cấu hình và trách nhiệm

cập nhật số liệu.• Xác định công cụ hỗ trợ quản lí cấu hình và hạn chế của

các công cụ đó• Xác định qui trình dùng công cụ• Xác định CSDL quản lí cấu hình dùng để lưu trữ thông

tin• Xác định các thông tin hỗ trợ như cấu hình của phần

mềm bên ngoài, xác nhận qui trình.

41


Kế hoạch quản lí cấu hình• Theo chuẩn IEEE

– Quản lí: • mô tả tổ chức dự

án• Cách thức quản lí

thay đổi• cách thức xác định

kết thúc mỗi côngđoạn

• Cách thức quản líchất lượng

– Hoạt động: mô tả cáchthức quản lí cấu hình

• Qui trình• CCB

1. Introductiona. Purposeb. Scopec. Definition and acronymsd. Reference

2. SCM a. Organizationb. SCM responsibilityc. Applicable policy, directive and

procedures3. SCM activities

a. Configuration identificationb. Configuration controlc. Configuration status accountingd. Configuration audits and

reviewse. Interface controlf. Subcontract/ vendor control

4. SCM schedules5. SCM Resources6. SCM plan maintenance


Tóm tắt chương• Quản lí cấu hình nhằm đảm bảo sự thống nhất

các phần tử trong dự án phát triển phần mềm– Các phần tử cấu hình phải được nhận diện và định

nghĩa– Các bản bàn giao và thay đổi phải được kiểm soát– Trạng thái của các phần tử cấu hình phải được ghi

chép và báo cáo• CCB

• Bài tập: 1 6 trang 82

42

Chương 5Quản lí nhân sự và tổ chức


1. People are the organization’s most important asset

• Nhiều người cùng làmviệc tổ chức đội (team)– Số người– Trình độ, kinh nghiệm– Loại dự án– Cá tính

• Cách thức giao tiếp– Người trong nhóm– Các nhóm trong tổ chức

• Quản lí nhân sự– Nhóm ={cá nhân}– Cá nhân có mục tiêu riêng

Mục tiêu chung của dự ánPhải xác định mục tiêucủa dự ánMọi người phải hiểu cái gìđược trông đợi ở họ

• Sau khi đã xác định mụctiêu dự án, hiệu suất củacác thành viên phải đượckiểm soát và đánh giá.

• Làm thế nào để kiểm soátđánh giá và đo tiến độ?• Chức năng bàn giao/đơn vị

thời gian• Line of code/đơn vị thời

gian!!! Nguy hiểm: người ta viết

nhiều code kém chất lượngVerification & validationĐánh giá chất lượng code và tài liệu

43


Các yếu tố trong QLNS• Consistency

– Team members should all be treated in a comparable way without favourites or discrimination.

• Respect– Different team members have different skills and

these differences should be respected.• Inclusion

– Involve all team members and make sure that people’s views are considered.

• Honesty– You should always be honest about what is going well

and what is going badly in a project.


Lựa chọn nhân sựA pplicat ion dom ai n expe rienc eFor a project to deve lop a su cce ssf ul sys te m , th e

deve lopers m ust underst an d the applic ation dom ai n. It isess ential that som e m em bers of a devel opm ent tea m hav esome dom ai n expe rienc e.

Pla tfor m ex perie nce This m ay be significa nt if lo w- le vel program ming isinvolved . O th erw ise, n ot usu al ly a crit ica l at tribute .

Programm inglangua ge e xperien ce

This is norm ally only si gnifica nt fo r short duration project sw he re the re is not enough time to lear n a ne w lan guage.W hile lea rning a language itse lf is not difficu lt, it ta kesseveral mo nths to bec om e prof ici ent in usi ng the ass oc iate dlibrarie s an d com pone nts.

Problem so lving ability This is ve ry imp orta nt for softw are enginee rs w hoconst an tly ha ve to sol ve tec hnical proble ms . Howeve r, it isalmos t im poss ible to judge w ithout know ing the work ofthe poten tia l team m em ber.

44


Educa tiona lback gr ound

This m ay pro vide an indic ato r of the basic fundam enta ls that theca ndida te sh ould know and of the ir ab ili ty to lea rn . This fac torbeco m es incr easingly irreleva nt as engine ers gai n experien ceac ros s a range of pro jec ts .

Comm unica tionabil ity

This is imp orta nt beca us e of the nee d for projec t sta ff tocom munica te ora lly and in writing w ith other engi nee rs , ma na gersand custom ers .

A da pta bility A da pta bility m ay be judged by looking at the different types ofexpe rienc e that can didat es ha ve had. This is a n imp orta nt attri buteas it indic ate s a n abi lity to lea rn.

A tt itude Project st aff sh ould have a p osi tive attitude to th eir w ork andshould be will ing to lea rn new skills. Th is is an im por ta nt attributebut ofte n v er y d ifficult to ass ess .

Pers onal ity This is an im por tant attribute but difficult to assess . Candid ate sm ust be rea sonably co mp at ible w ith other te am m em be rs . Nopar tic ula r type of pe rs onal ity is mor e or less su ited to softw areenginee ri ng.


2. Các kiểu phối hợp• Giao tiếp giữa các thành

viên– Hội họp– Thanh tra– Ban quản lí cấu hình

• Cơ chế phối hợp: 5 kiểu(theo Mintzberg)– Cấu trúc đơn giản: một

lãnh đạo nhóm– Bộ máy hành chính: phối

hợp được chuẩn hóa theotrình tự xử lí công việc

– Dạng tự chủ• Phân thành các nhóm tự

chủ• Phối hợp chuẩn hóa theođầu ra công việc

• Khi mục kết quả cuối cùngcó thể đặc tả rõ

• Hành chính chuyênnghiệp: – phối hợp theo kỹ năng

người làm• Adhocracy

– Với dự án lớn, công việcchia theo chuyên ngành

– Không có mục tiêu– Không có phương pháp

tiến hành– Phối hợp theo kiểu thúcđẩy lẫn nhau

• Lưu ý: trong mỗi tổ chứccó thể có nhiều mô hìnhkhác nhau

45


3. Các kiểu quản lí• Hai chiều trong quản lí [Reddin]

– Hướng quan hệ: tập trung vào các cá nhân và quan hệ với cánhân khác

– Hướng công việc: tập trung vào kết quả có thể đạt được và cáchthức đạt được kết quả đó.

• Hai chiều trên có thể : Thấp / CaoTổ hợp thành 4 khả năng


• Kiểu phân tách– Dựa trên thủ tục, qui trình– Phối hợp kiểu phân cấp– Quyết định trên xuống– Cơ chế xin-cho– Giống bộ máy hành chính

của Mintzberg• Kiểu quan hệ

– Dùng với đội ngũ có độngcơ, có tinh thần phối hợpvà được đào tạo tốt

– Công việc hướng tới cáccá nhân

– Quyết định là của nhómdựa trên thương thảo vàxây dựng quan điểm chung

– Giống cơ chế adhocracy

• Kiểu đồng thuận: quyếtđịnh đưa ra từ tầm nhìnchung của nhóm– Giống cơ chế hành chính

chuyên nghiệp• Kiểu tích hợp

– Thích hợp trong hoàn cảnhlà kết quả không chắc chắn

– Công việc bùng nổ tổ hợpvà các công việc phụ thuộclẫn nhau

– Quyết định từ dưới lên– Giống cơ chế adhocracy

46


4. Tổ chức nhóm (team organization)• Trong một nhóm

– Nhiều vai trò: người quảnlí, kiểm thử viên, lập trìnhviên.

– Một người có thể giữ nhiềuvai trò

– Trách nhiệm và công việcxác định trong kế hoạch dựán

• Tổ chức phân cấp: – phân nhóm chức năng– Tổ chức phân cấp– Giống mô hình tổng thể

của dự án– Nhược điểm là khoảng

cách giao tiếp xa, thông tin nhiễu


• Tổ chức ma trận

Các nhóm bộ phận– có chuyên môn sâu– tham gia bán thời gian vào các dự án khác nhau– Người quản lí dự án chịu trách nhiệm cho sự thành công toàn bộ dự ánVà nâng cao kiến thức chuyên môn của nhóm.

• Đội lập trình viên chính (chief programmer team theoHarlan Mills)– Hạt nhân của mỗi đội gồm 3 người:

• Trưởng nhóm: thiết kế và cài đặt phần chính của hệ thống• Trợ lý: giúp việc cho trưởng nhóm• Người quản lí tài liệu

– Cần có một trưởng nhóm giỏi kỹ thuật và năng lực quản lí tốt– Lưu ý: công việc không có cấu trúc, không có người phân tích,

người thiết kế, lập trình viên…

47


• Đội SWAT(Skilled With Advanced Tools)– Nhóm nhỏ: 4-5 người– Thường áp dụng trong tiến

trình theo mô hình tăngtrưởng

– Dùng ngôn ngữ cấp cao, các gói dùng lại, các phầnmềm sinh mã.

– Nhóm trưởng là người giỏi• Đội có cấu trúc mở

– Phát triển PM là 1 côngviệc phức tạp,

– Hướng quan hệ là thíchhợp

– Mô hình đội có cấu trúcmở: tích hợp hướng quanhệ với một cấu trúc rõ ràng

– Có một trưởng nhóm kỹthuật (giống như trong môhình đội lập trình viênchính) giải quyết mọi xungđột giữa các thành viên.

– Tập trung vào• năng lực chuyên môn cá

nhân• Các hoạt động phối hợpđể hoàn thành một cáchcó hiệu quả mục tiêu củadự án.


Các nguyên tắc cơ bản trong tổ chức nhóm

• Dùng ít người nhưng màtinh (user fewer and better people)

• Đúng người đúng việc (fit tasks to the capability and motivation of the people available-Peter principle)

• Tổ chức lớn mạnh nếu nógiúp mọi người đều cốgắng vuợt lên chính mình– Một lập trình viên giỏi chỉ

có thể là chuyên gia trong1 số lĩnh vực nếu họ khôngcó cơ hội cọ xát trong lĩnhvực khác

– Qui tắc của Paul (Paul principle): một ngườitrưởng thành trong một tổchức, tại một vị trí sẽ trởthành cổ hủ trong 5 năm!

• Lựa chọn người sao chocân bằng và đồng thuận(tập thể hài hòa, đoànkết)

• Ai không thích hợp trongđội phải bị loại

48


P-CMM model


Tóm tắt chương• Phần mềm được con người viết ra. Hiệu suất

của họ phụ thuộc vào một số yếu tố: ngôn ngữlập trình, HĐH, phần cứng, công cụ.

• Môi trường tổ chức cũng là một yếu tố quantrọng

• Hai kiểu quản lí– Cá nhân chủ nghĩa– Có cấu trúc phân cấp

• Năm cách tổ chức nhóm làm việc• Năm nguyên tắc cơ bản trong quản lí nhân sự.• Bài tập: 1 6 trang 99

49

Chương 6Quản lí chất lượng


1. Kiểm soát chất lượng phần mềm• Phần mềm

– Phức tạp– Thường thay đổi

Cần phải theo dõi và đánhgiá chất lượng để có sp thỏa mãn yêu cầuThận trọng trong quá trìnhphát triển phần mềm

• Tiên đề: Chất lượng củasp dựa trên chất lượngcủa tiến trình làm ra sảnphẩm.

• Quan điểm quản lí chấtlượng• Sản phẩm – qui trình• Tuân thủ chuẩn – cải tiến

4 cách tiếp cận cho vấn đềchất lượng

• Chất lượng là gì?– Những người khác nhau có

quan điểm khác nhau• Một người kiểm thử hệ

thống: “đúng theo đặc tảyêu cầu”

• Người dùng: “phù hợpnhất để sử dụng”

• Quality is the pursuit of excellent in everything

• Chuẩn chất lượng– ISO– CMM

• Quản trị định lượng

50


2. Đo lường (measures)• Phép đo (measurement): là

một ánh xạ từ thế giới thực(thế giới kinh nghiệm) vào mộtthế giới hình thức.– Đo trực tiếp– Đo gián tiếp

• Số đo: là một con số gán chomột thuộc tính của một thựcthể qua ánh xạ đó. – Có một đơn vị. – Có kiểu thang đo (scale type)

• Thuộc tính– Trong– ngoài

• Độ đo (metric) – Trong toán học có ý nghĩa là

khoảng cách giữa 2 điểm– Trong CNPM nó được dùng

với ý nghĩa lỏng lẽo

để chỉ :• Thuộc tính của một thực thể• Hàm để gán giá trị cho một

thuộc tính• Đơn vị mà giá trị được biểu

diễn• Kiểu thang đo

• Thang đo– Gọi tên (nominal)– Thứ tự (ordinal): độ C– Khoảng (interval): độ F– Tỉ lệ (ratio): độ K– Tuyệt đối: đếm số

• Mỗi thang đo sẽ cho phép mộtphép toán nào đó, một số phéptoán là không có nghĩa. Ví dụlấy trung bình của các số đotheo thang thứ tự là không cónghĩa.


3. Vấn đề trong đo lường phần mềm• Thế giới thực dùng để

kiểm chứng phép đo/độđo. – Vd A cao hơn B. phép đo

S, xác định S(A)>S(B) vậyS là hợp lệ.

• A cao hơn B là thế giớithực hay còn gọi là điềukiện biểu diễn.

• Đối với phần mềm, thếgiới thực không rõ ràngVd: độ phức tạp PM? Đo

bằng số IF:– Hai đoạn code có số IF

bằng nhau là cùng độ phứctạp

– Đoạn code có nhiều IF hơnlà phức tạp hơn.

??? Phép đo hợp lệ ???

• Các thuộc tính phần mềmthường không thể đo trựctiếp.– Đo gián tiếp thông qua cácđộ đo khác

• Vấn đề tổ hợp các độ đokhác kiểu thang đo– Khi tổ hợp nhiều độ đo vào

một độ đo mới, thang đocủa độ đo mới là thang yếunhất trong các thang đo tổhợp.

– Vd: f(x,y), x có thang thứtự, y có thang tuyệt đối thì f có thang thứ tự

51


4. Phân loại các thuộc tính chất lượng• Chất lượng là gì?

– IEEE: quality is defined as the degree to which a system, a component, or process meets customer or user needs or expectations.

– Áp dụng vào PM: CLPM làmức độ thỏa mãn củangười dùng về: tính chínhxác, độ tin cậy, tính dùngđược, dễ bảo trì, dễ kiểmthử, tính khả chuyển…

• Các yếu tố chất lượngPM theo McCall– Chính xác (correctness)– Tin cậy (reliability)– Hiệu quả (efficiency)– Toàn vẹn (integrity)– Dễ dùng (usability)– Dễ bảo trì (maintainability)– Dễ kiểm thử (testability)– Mềm dẽo (flexibility)– Khả chuyển (portability)– Dễ dùng lại (reusability)– Tính tương tác

(interoperability)

Product operation

Product revision

Product transition


McCall’s Quality Factors

52


5. Các tiêu chí chất lượng theo McCall• Minh bạch: dễ kiểm

chứng (access audit) PM và dữ liệu tuân thủ chuẩn

• Kiểm soát được (Access control) : có các cơ chếkiểm soát và bảo vệ PM, dữ liệu

• Chính xác (Accuracy) trong tính toán và kếtxuất

• Tính thông dụng tronggiao tiếp (Communication commonality) : protocole, interface

• Dễ giao tiếp(communicativeness) vớicác hệ thống khác

• Cô đọng (consiseness) trong code

• Nhất quán (consistency) trong thiết kế và kỹ thuậtcài đặt; các kí hiệu

• Tính thông dụng của dữliệu (data commonality)

• Khả năng chịu đựng lỗi(Error tolerance)

• Thực hiện hiệu quả(Execution efficiency) vềthời gian

• Dễ mở rộng(expandability)


Các tiêu chí chất lượng theo McCall (tt)• Tính tổng quát

(generality): tính bao trùmcác ứng dụng và thànhphần tiềm tàng

• Độc lập phần cứng(Hardware independence)

• (có công cụ) Đo lường(instrumentation): sốngười dùng, nhận diệnlỗi.

• Mô đun hóa (modularity)• Dễ thao tác (operability)• Tài liệu hóa trực tiếp

code, component (self-document)

• Đơn giản (simplicity): dễhiểu, tránh làm phức tạp.

• Độc lập PM hệ thống: Hđh, thư viện…

• Hiệu quả lưu trữ (storage efficiency)

• Lần vết (traceability)• Dễ đào tạo (training)

53


McCall’s Quality Criteria


6. Quan hệ giữa các tiêu chí và yếu tố chấtlượng

Software system independence

Instrumentation

Data commonality

Communications commonality

Machine independence

Modularity

Generality

Expandability

Self−descriptiveness

Conciseness

Simplicity

Communicativeness

Training

Operability

Access audit

Access control

Storage efficiency

Execution efficiency

Error tolerance

Accuracy

Consistency

Completeness

Traceability

Correctness

Reliability

Efficiency

Integrity

Maintainability

Usability

Testability

Flexibility

Portability

Reusability

Interoperability

Quality criteria Quality factors

54


7. Đo chất lượng?• Chủ quan:

– Ước lượng và đánh giáchủ quan các tiêu chí: chođiểm theo một thang nàođó vd 0..10

– Người khác nhau cho điểmkhác nhau

• Khách quan– Chia nhỏ các tiêu chí chất

lượng ra thành các tínhchất có thể đo được.

– Dùng các độ đo kháchquan để đo từng tiêu chíthành phần

– Thiết lập công thức tính“điểm chất lượng”

• Vấn đề đo độ phức tạpphần mềm– McCall “bỏ qua” độ phức

tạp (complexity)– Độ phức tạp phần mềm “làđộ khó hiểu và kiểm chứngthiết kế, cài đặt của hệthống hoặc thành phần” (IEEE).

– McCall diễn giải độ phứctạp qua: tính dễ hiểu, đơngiản,…

– Một số phép đo độ phứctạp thông thường dựa trênsource code và cấu trúccủa module.


8. Đặc điểm trong quản lí chất lượng• Các tiêu chí chất

lượng không độc lậpmà có tác động lẫnnhau: cả + và –

55


9. ISO 9126• ISO cố gắng định nghĩa chất

lượng theo lược đồ phân cấp: mỗi đặc tính chất lượng quanhệ với 1 thuộc tính chất lượng

• ISO chú trọng vào sản phẩmphần mềm và “lờ” chất lượngcủa qui trình PM.

• Các đặc tính chất lượng là“nhìn thấy” bởi người dùng

• ISO giới thiệu một số độ đođịnh lượng cho các đặc tínhchất lượng

• Các đặc tính chất lượng địnhnghĩa trong ISO 9126:

– Chức năng (functionality)• Phù hợp (suitability)• Chính xác (accuracy)• Tương tác• Bảo mật

– Độ tin cậy (reliability)• Độ chín (maturity)• Khả năng chịu lỗi (fault

tolerance)• Khả năng phục hồi

(recoverable)– Tính dễ dùng (Usability)

• Dễ hiểu, học• Dễ thao tác, hấp dẫn

– Hiệu quả (efficiency)• Thời gian, tài nguyên

– Khả năng bảo trì(maintainability)

• ổn định (stability)• Phân tích được (analyzability)• Thay đổi được (changeability)• Test được (testability)

– Khả chuyển (portability)• Thích ứng (adaptability)• Cài đặt được (installability)• Cùng tồn tại (co-existence)• Thay thế được (replaceability)


The ISO 9126 Quality Characteristics

56


standard feature refinementQuality subcharacteristic

Suitability

Accuracy

Interoperability

Security

Maturity

Fault tolerance

Recoverability

Reliability

Usability

Understandability

Learnability

Operability

EfficiencyTime behavior

Resource behavior

Maintainability

Portability

Analyzability

Changeability

Stability

Testability

Adaptability

Installability

Conformance

Replaceability

Functionality

Quality characteristic


Các hoạt động quản lí chất lượng• Quality assurance

– Establish organisational procedures and standards for quality.

• Quality planning– Select applicable procedures and standards for a

particular project and modify these as required.• Quality control

– Ensure that procedures and standards are followed by the software development team.

• Quality management should be separate from project management to ensure independence.

57


10. Kiểm soát chất lượng ?• Mỗi tổ chức có cách kiểm

soát chất lượng riêng, một hệ thống chất lượngvà kiểm soát chất lượngriêng– Định nghĩa các đặc tính

chất lượng– Xác định và mô tả các

thuộc tính của mỗi đặc tínhchất lượng

– Chỉ ra các độ đo (chủquan/khách quan) cácthuộc tính cách tổng hợpcác độ đo này thành chỉ sốchất lượng.

• Quality requirements that can not be quantified can not be controlled

• Tham khảo trang 118-119 và thảo luận tại lớp– Ý nghĩa của mỗi đặc tính

và thuộc tính– Các thức đo– Cách tổng hợp các độ đo


11. Quản lí chất lượng trong tiến trình PM

58


12. Hệ thống chất lượng• ISO 9000: chuỗi các

chuẩn cho các hệ thốngquản lí chất lượng– ISO 9000-1: hướng dẫn

cách chọn và dùng cácchuẩn cho hệ thống quản líchất lượng

– ISO 9001-9003: 3 mô hìnhcho hệ thống chất lượng

• ISO 9001: chuẩn phù hợpcho phát triển phần mềm(có thể dùng trong kí hợpđồng)

• ISO 9002: chuẩn cho sx, cài đặt và phục vụ

• ISO 9003: chuẩn cho kiểmtra, kiểm thử (test).

• 20 Thành phần trongISO 9001:

1. Trách nhiệm quản lí2. Hệ thống CL3. Xét duyệt HD4. Kiểm soát thiết kế5. Kiểm soát tài liệu và dữ

liệu6. Mua bán7. Kiểm soát sp bên thứ 38. Nhận diện và lần vết sp9. Kiểm soát tiến trình10. Thanh tra và test11. Kiểm soát thanh tra; dụng

cụ đo và test12. Trạng thái thanh tra và

test


• Kiểm soát sp không tuânthủ chuẩn

• Hoạt động sửa lỗi vàngăn ngừa

• Buôn bán, lưu trữ, đónggói, bảo quản, và giaohàng

• Kiểm soát ghi chép vềchất lượng

• Kiểm tra /kiểm toán chấtlượng nội bộ

• Đào tạo• Phục vụ• Kỹ thuật thống kê

• Chứng chỉ ISO– Cần chuẩn bị ít nhất 1 năm– Có một bên thứ 3 kiểm tra

và công nhận– Thanh tra 6 tháng/lần– Phải làm lại sau 3 năm

Phải tốn thời gian và tiềncủa.

59


13. Đảm bảo chất lượng PM (SQA)• Software quality

assurance– Đảm bảo mọi thứ theođúng ý đồ

• Mục tiêu của SQA– Cải tiến chất lựong bằng

cách kiểm soát PM và qui trình sx

– Đảm bảo tuân thủ cácchuẩn đã đề ra và thủtục/qui trình phát triển

– Đảm bảo mọi thứ khôngthích hợp trong sp, qui trìnhđược quản lý, kiểm soát vàsửa chữa

• Người trong đội SQA co trách nhiệm xem xét vàxác nhận trạng thái vềchất lượng

• Có sự mâu thuẫn trongmục tiêu của SQA và độiphát triển

• Để SQA có hiệu quả:– SQA phải độc lập– Sếp SQA nghiêm túc– Đội ngũ SQA giỏi và sáng

suốt; có tinh thần hợp tác.– Hoạt động kiểm soát và

xác nhận chất lượng phảidựa trên kế hoạch pháttriển PM.

• Nội dung quản lí chấtlượng– Chuẩn IEEE 730– IEEE 983: hướng dẫn bổ

sung IEEE 730.


Các nội dung chính trong tài liệu SQA theoIEEE 730

1. Mục tiêu2. Tài liệu tham khảo3. Quản lí4. Tài liệu5. Các chuẩn, qui tắc thực

hành, qui ước, và độ đo6. Xem xét và xác nhận

chất lượng7. Test8. Báo cáo sự cố và họat

động ngăn ngừa9. Công cụ, kỹ thuật và

phương pháp luận

10.Kiểm soát code11.Kiểm soát việc truyền

thông12.Kiểm soát nhà cung cấp13.Tập hợp số liệu, sàn lọc

và lưu trữ14.Đào tạo, huấn luyện15.Quản lí rủi ro

60


14. Mô hình CMM• Kiểm soát CL dựa trên SP:

chậm, bị động• Ý tưởng: Kiểm soát tiến

trình thay vì kiểm soát SP.• 5 mức trưởng thành cho

qui trình PM; mỗi mức– Key process areas– Common features– Key practices

• Kinh nghiệm chỉ ra– Từ mức 1 2: 2 năm;

500$ 2000$/người– 1$ để cải tiến qui trình

tiết kiệm 5$.• Một số mô hình khác

– PSP: dùng cho cty nhỏ, dựán nhỏ

– BOOTSTRAP– SPICE


Tổng kết chương• Khái niệm CLPM• Sự cần thiết phải

quản lí chất lượng• Yếu tố chất lượng

của McCall• Các tiêu chí chất

lượng của McCall• Các chuẩn chất

lượng– ISO– IEEE

• Mô hình mức độtrưởng thành của mộttổ chức, một qui trìnhPM:– CMM– CMM-like

• Bài tập: 1 16 trang140

61

Chương 7:Ước lượng giá thành


1. Khái niệm giá thành• Công sức (effort): tính

bằng người-tháng (hoặcngười-ngày)

• Giả thiết: giá thành tỉ lệvới công sức phát triểnphần mềm.

• Giá thành tính dựa theocông sức cho tất cả cácgiai đoạn phát triển phầnmềm: khởi đầu, phântích, thiết kế, cài đặt, kiểm thử.

• Giai đoạn bảo trì chưađược tính vào giá thànhPM.

• Thông thường người tatính effort theo số dònglệnh (LOC)

• Công thức:E = 2.7 KLOC1.05

KLOC = 1000 LOC• Từ E tính giá thành bằng

cách nhân với một hằngsốC = kE

• Vấn đề ước lượng C trởthành vấn đề ước lượngE hoặc LOC.

62


2. Vấn đề ước lượng giá thành• Ước lượng giá thành

không đơn thuần dựatrên kỹ thuật– luật Parkinson: work fills

the time available– đấu giá (Price to win)– Cân bằng các ràng buộc

khác về thời gian; ví dụdeadline ước lượng giá thành chỉ cógiá trị tham khảo

thực tế: dự án cần 1 năm; nhưng 10 tháng làchấp nhận được vậythực hiện trong 10 tháng

• Mô hình ước lượng giáthành thường là mô hìnhthực nghiệm. Kết luận rútra từ dữ liệu trong quákhứ• Cách thức tiến hành thu

thập dữ liệu• Tính trung thực của dữ liệu• Môi trường tổ chức khác

nhau• Thiếu dữ liệu để phân tích


Algorithmiccost modelling

A model based on historical cost information that relates some softwaremetric (usually its size) to the project cost is used. An estimate is madeof that metric and the model predicts the effort required.

Expertjudgement

Several experts on the proposed software development techniques andthe application domain are consulted. They each estimate the projectcost. These estimates are compared and discussed. The estimationprocess iterates until an agreed estimate is reached.

Estimation byanalogy

This technique is applicable when other projects in the same applicationdomain have been completed. The cost of a new project is estimated byanalogy with these completed projects. Myers (Myers 1989) gives avery clear description of this approach.

ParkinsonÕsLaw

ParkinsonÕs Law states that work expands to fill the time available. Thecost is determined by available resources rather than by objectiveassessment. If the software has to be delivered in 12 months and 5people are available, the effort required is estimated to be 60 person-months.

Pricing to win The software cost is estimated to be whatever the customer hasavailable to spend on the project. The estimated effort depends on thecustomerÕs budget and not on the software functionality.

Estimation techniques

63


3. Các mô hình ước lượng trước kia• Mô hình tuyến tính (Nelson 66)

E = a0+a1x1+...+anxn

– ai là hằng; xác định bởi dữ liệutrong quá khứ

– xi là các yếu tố ảnh hưởng giáthành. Theo mô hình Nelson thì có 14 yếu tố:

• Tính không ổn định của đặctả (0-2)

• Không ổn định của thiết kế (0-3)

• tỉ lệ các tính toán toán học(%)

• tỉ lệ các chỉ thị I/O (5)• số chương trình con (số)• Dùng NN cấp cao (Y=0 / N=1)• Ứng dụng tác nghiệp (Y=0 /

N=1)• ...

– Mô hình Nelson cho thấy mộthình ảnh sớm về công sức.

• Ma trận giá– Dùng bảng giá theo độ khó– Đánh giá chủ quan độ khó

từng module (ý kiến chuyêngia)

– Tính cost của moduleC = Sk x CijSk là kích thước (có thể làLOC)Cij là giá theo bảng giá


4. Các mô hình mới• Dạng tổng quát:

E = (a+bKLOCc )f(x1,..xn)Trong đó:a,b,c là hằngf(x1,..xn) là hàm n biến chỉ n yếu

tố ảnh hưởng đến cost.• Dạng cơ bản:

E = a+bKLOCc

• Walson-Felix– E= 5.2 x KLOC0.91

– Dựa trên 60 dự án của IBM– Có 29 yếu tố ảnh hưởng tới E

• COCOMO (Boehm, 81): 3 dạng cơ bản– Organic: E= 2.4 x KLOC1.05

Áp dụng cho nhóm nhỏ, môitrường quen thuộc

– Trung gian : E= 3 x KLOC1.12

Áp dụng cho dự án khá lớn, cómột ít kinh nghiệm

– Dạng nhúng: E= 3.6xKLOC1.20

Áp dụng cho dự án lớn, môitrường mới

• Halstead: E= 0.7 x KLOC1.5

KLOC tính theo công thức củaHalsteadn1: số toán tử phân biệtn2: số toán hạng phân biệtN1: tổng số toán tửN2: tổng số toán hạng

LOC tính bằng N= N1+N2ước lượng bởi:N’= n1log2n1 + n2log2n2

64


Các mô hình mới (tt)• DeMarco

– Tương tự như COCOMO– ước lượng độ lớn của PM

(software size) từ các chức năngcơ bản (Functional Primitive-FP).

– Các chức năng cơ bản xác địnhtừ DFD ở mức chi tiết.

– Giả thiết của DeMarco: • Mỗi chức năng được phân tích

như 1 DFD• Mỗi DFD diễn tả một chuỗi các

phép biến đỗi Input thành Output. Như vậy có một số phần tử (dữliệu) liên quan.

– ước lượng cho một phép biến đổi:Size(FP) = k x TCFPx log2(TCFP)TCFP: số phần tử liên quan trong

phép biến đổik là một hằng

• 10 chức năng cơ bản theoDeMarco:– Nhập tách dữ liệu (0.6)– cập nhật dữ liệu (0.5)– Phân tích dữ liệu bằng một

chuỗi các hành động (1.0)– Đánh giá input trên giao diện

(0.8)– kiểm tra tính nhất quán (1.0)– Thao tác chuỗi(1.0)– đồng bộ hóa trong tương tác

với user (1.5)– Sinh ra output (1.0)– Tính toán đơn giản (0.7)– Tính toán phức tạp (2.0)

• Tính FP = ∑ αiTCilog2TCi• ước lượng E=aFPb


Các mô hình mới (tt)• Phân tích điểm chức năng

(FPA-Albrecht)– Tương tự như DeMArco– Thích hợp cho các PM tác

nghiệp (HTTT QL)– Tính điểm chức năng (FP) cho

mỗi chức năng cung cấp chongười dùng

– điểm chức năng tính theo cấutrúc dữ liệu bằng cách tính sốkiểu phần tử cơ bản.

– Có 5 kiểu phần tử cơ bảnđược đếm:

• Input type (I): input từ ngườidùng để xử lý hoặc thay đổiformat. Các input để điềukhiển CT không được tính

• Output type (O):Các cấu trúcdữ liệu được kết xuất chongười dùng

• Inquiry type (E): các truy vấnyêu cầu hệ thống thực hiệnmột tác vụ

• số logical internal file (L): cácfile kết xuất của HT trong quátrình xử lí

• số interfaces (F): các output đi vào hệ thống khác

– Tính FP thô dựa theo bảngvd: UFP = 4I+5O+4E+10L+7F

65


• FPA (TT)– Tính độ phức tạp (complexity

level): dựa trên số file và độphức tạp (số fields) của file:

• Danh sách 14 yếu tố kỹ thuật:– Data communication– Distributed function– Performance – Heavily used configuration– Transaction rate– Online data entry– End-user efficiency– Online update– Complex processing– Reusability– Installation ease– Operation ease– Multiple site– Facilitate change

• Tính điểm chức năngFP = UFPx(0.65+0.01DI)

• Sau khi tính UFP, tính hệ sốảnh hưởng của các yếu tố kỹthuật (14 technical factors). Mỗi yếu tố cho điểm từ 0 (không ảnh hưởng) ... 5 (ảnhhưởng lớn nhất). DI = ∑ TFi (i=1..14)TFi có giá trị từ 0..5


Ví dụ tính FPA• Đặc tả: hệ thống quản lí kho hàng và thông tin khách

hàng• Chức năng:

– Cho phép nhập mã khách hàng và các chi tiết khách hàng (đã tồn tại hoặc tạo mới). Số khách hàng tối đa 100.

– Kiểm tra hạng tín dụng (credit rating) của khách hàng và từ chốigiao dịch nếu khách hàng có hạng tín dụng thấp.

– Cho phép nhập các mặt hàng được đặt hàng.– Kiểm tra lượng hàng trong kho xem có đủ đáp ứng yêu cầu

• (Nếu không đủ thì tạo ra đơn hàng cho nhà cung cấp, việc đặt hàngnày là ngoài hệ thống). Đơn đặt hàng của khách hàng sẽ được đápứng khi khi có đủ hàng.

– Cập nhật lượng hàng trong kho và chi tiết khách hàng– Lệnh chuyển hàng và hóa đơn– Cập nhật lượng hàng trong kho theo các lệnh giao hàng– Cập nhật kế toán chi tiết khách hàng theo các lần chi trả của

khách hàng.

66


Unadjusted Function Point Counting

• 5 transaction types – External Inputs– External Outputs – External Inquiries– External Files:0– Internal Files

• Function Point Complexity Weighting– Tất cả đều ở mức simple

• Tinh UFP• DI = 0• Tinh FP =0.65*UFP (tra LOC)• E = 2.4 (KLOC) 1.05

• Tinh T = 2.5*E0.38


Total

Is the application designed to facilitate change and ease by the user?14

Is the system designed for multiple installations in differentorganizations?

13

Are the conversion and installation included in the design?12

Is the code designed to be reusable11

Is the internal processing complex?10

Are the inputs, outputs, files, or inquiries complex?9

Are the master files updated on-line?8

Does the on-line data entry require the input transaction to be built overmultiple screen or operations?

7

Does the system require on-line entry?6

Will the system run in an existing, heavily utilized operating system5

Is performance critical4

Are there distributed processing functions?3

Are data communication required2

Does the system require reliable back up and recovery?1

14 technical factors

67


5. COCOMO II• COCOMO II phát triển từ COCOMO 81• Có 3 mô hình

– Application composition: áp dụng rất sớm dựa trên sốmàn hình, reports và 3GL (các thành phần thư viện) để ước lượng sơ bộ cost

– Early Design: giống FPA dùng để ước lượng dựa trênthiết kế

– Reuse Model: dựa trên LOC, tính E để tích hợp code

– Post-Architecture: phiên bản đầy đủ nhất, dựa trênLOC, tính E.


Các mô hình ước lượng COCOMO II

68


Application composition

3. Tính điểm cho từng pt cơbản (Object point)

4. Tính tổng điểm của toàn bộdự án (Total Object Point -TOP)

5. Tính Total object Point chophần mới (bỏ phần reuse)NOP = TOP x (100-%reuse)/100

6. Xác định hiệu suất PROD (cóđơn vị là NOP/man-month).

Hiệu suất này phụ thuộcvào kinh nghiệm, khả năngcủa đội phát triển và công cụ

7. Tính effortE = NOP/PROD

1. ước lượng số pt cơ bản: screens, reports và 3GL components

2. Xác định độ phức tạp củatừng pt cơ bản


Early design• Dùng điểm chức năng (UFP) như là độ đo cơ bản• Qui đổi FPA sang KSLOC (dùng bảng):

1UFP = 91 SLOC pascal= 128 SLOC C= 29 SLOC C++= 320 SLOC assembly

- Dùng 7 yếu tố tác động giá thành (cost drivers)E = a* KSLOCb ∏(cost driveri)

69


Post architecture- Dùng KSLOC như độ đo cơ bản- Dùng 15 yếu tố tác động giá thành (cost drivers)

E = a* KSLOCb ∏(cost driveri)a, b là hằng số thực nghiệm (B có tính dựa trên 5 yếu tố theo công thứcb= 1.01 + 0.01 ∑ Wi, trong đó Wi là trọng số biến đổi từ very low

(5) tới extra high (0)

Precedentedness (PREC); Development flexibility (FLEX); Architecture/risk resolution (RESL); Team cohesion (TEAM); Process maturity(PMAT)


15 cost drivers

70


Ảnh hưởng của cost drivers


6. Phân phối nhân lực theo thời gian• Một dự án được ước lượng là 20

man-months nghĩa là gì?– cần 20 người làm việc 1 tháng– cần 4 người làm 5 tháng– cần 1 người làm 20 tháng

• Không thực tế, nhân lục khôngphân phối đều suốt dự án

• Dựa theo phân phối Rayleigh, Putnam đưa ra mô hình

• Ước lượng thời gian của dựán– Walston-Felix

T= 2.5 E0.35

– COCOMO organic T= 2.5 E0.38

– COCOMO II (nominal schedule)T= 3.0 E0.33+ 0.2(b-1.01)

– Putnam T= 2.4 E1/3

• Hiệu suất trung bình (theoConte)L = 777P-0.5 (LOC)trong đó P là team size

• Giới hạn của thời gian pháttriển: 75% thời gian ước lượng0

∫0∝

p(t)dt= Effort

td= 1/√2a

71


p(t) = 2.a.Effort.t . e-at2 a = 1/2*td2

0

∫0∝

p(t)dt= Effort

td= 1/√2a

Putnam ManPower distribution Model

a = speed-up factor

Initial Slope= 2.a.Effort


Tổng kết chương• Các mô hình ước lượng cost,

effort và thời gian dự án

• Các mô hình dựa trên thựcnghiệm trong các môi trườngkhác nhau vì vậy sự chênhlệch là rất lớn.

• Các ước lượng mang giá trịtham khảo để trợ giúp quyếtđịnh

• Bài tập 7,8,10,12

Documents

pdf