Lập kế hoạch hệ thống quản lý chất lượng phần mềm Software Quality System Plan

Lập kế hoạch hệ thống quản lý chất lượng phần mềm Software Quality System Plan

Trường Cao đẳng Công Nghệ Thông Tin Tp.HCM

Khoa CNTT

TUYÊN BỐ DỰ ÁN

Đồ án môn: QUẢN LÝ ĐỀ ÁN CNPM Nhóm: 1 - Lớp: C10CNPM3

Tên đề tài: Lập kế hoạch Hệ thống quản lý chất lượng phần mềm

(Software Quality System Plan)

2 Ngày bắt đầu: 11/09/2012 Ngày kết thúc: 19/11/2012

4 Mục tiêu của đề tài:

1 Hiểu được về SQS Plan và cách thức triển khai SQS Plan.

2 Hiểu rõ các yếu tố để đánh giá hệ thống chất lượng phần mềm.

3 Hiểu các vấn đề ảnh hưởng đến phạm vi và quyền hạn của thống chất lượng phần mềm.

4 Ứng dụng SOS vào dự án phần mềm ACIS.

5 Nội dung thực hiện:

1 Giới thiệu tổng quan về SQS

1.1/ Các tiêu chuẩn (Standards) 1.2/ Xem xét, xem lại (Reviewing) 1.3/ Kiểm tra (Testing)

1.4/ Phân tích lỗi (Defect analysis) 1.5/ Quản lý cấu hình (Configuration Management - CM) 1.6/ Bảo mật (Security)

1.7/ Đào tạo, huấn luyện (Education/Training) 1.8/ Quản lý người cung cấp, thầu phụ (Vendor Management) 1.9/ An toàn (Safety)

1.10/ Quản lý rủi ro (Risk Management) SQSP là gì? SQSP là yêu cầu kinh điển cũng như thao tác cơ bản của hầu hết

các HTQLCLPM Kết quả của hoạt động này thường là một (hoặc nhiều) tài liệu

2 Xây dựng kế hoạch SQS Plan

• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm.

• Xác định nhân lực, vật lực và chi phí.

• Chỉ định phương pháp, cách tiếp cận để thực thi dự án.

• Lập kế hoạch làm việc chi tiết.

• Kế hoạch phối hợp và hỗ trợ hoàn thành dự án.

• Kế hoạch quản lý cấu hình và quản lý các rủi ro.

• Các kế hoạch khác.

• Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án

3 Ứng dụng SQS vào dự án thực tế:

Ứng dụng SOS vào dự án phần mềm ACIS.

4 Đánh giá - kết luận - đề xuất, cải tiến

6 Các phương pháp tiếp cận:

- Tìm hiểu các tài liệu liên quan đến hệ thống chất lượng phần mềm.

- Các Ebook về quản lý chất lượng phần mềm.

- Tham khảo một số Website giới thiệu các dự án thực tế.

7 Kết quả dự kiến :

- Hiểu được hệ thống chất lượng phần mềm.

- Các yếu tố, các vấn đề liên quan đến chất lượng của một phần mềm.

- Tìm hiểu thiết lập kế hoạch đảm bảo chất lượng phần mềm và ứng dụng lập kế hoạch cho dự án phần mềm ACIS

8 Tài liệu tham khảo:

1 “Shari Lawrence Pfleeger et al Solid Software, Upper Saddle River”, NJ: Prentice Hall, 2002.

2 Roger S Pressman, “Software Engineering: A Practitioner's Approach”, New York: McGraw-Hill, 2001.

3 John W Horch, “Practical Guide to Software Quality Management”, 2003, Second Edition, Artech House.

4 G Gordon Schulmeyer, “Handbook of Software Quality Assurance”, 2008, Fourth Edition, Artech House, INC.

5 Link Website tham khảo:

- http://www.sqs.com/en/group/sqs-software.php : Website chuyên về mảng SQS Plan.

- http://www.pcworld.com.vn/articles/cong-nghe/cong-nghe/2006/05/1189009/ quan-ly-chat-luong-phan-mem/ : Tham khảo về các nội dung cơ bản của SOS Plan.

- http://acis.mit.edu/acis/sqap/sqap.r1.html : Tài liệu cơ bản về SOS Plan (Tiếng Anh)

[1] John W Horch, Practical Guide to Software Quality Management, 2003, Second Edition, Artech House

[2] G Gordon Schulmeyer, Handbook of Software Quality Assurance, 2008, Fourth Edition, Artech House, INC

-Phân công công việc:

1) Trương Văn Việt

 Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm

 Kế hoạch phối hợp và hỗ trợ hoàn thành dự án

 Lập kế hoạch làm việc chi tiết

 Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án

 Ứng dụng vào dự án

 Đánh giá – Kết luận

3) Nguyễn Thị Hoàng Thương

 Tìm hiểu tổng quan về SOS Plan

 Chỉ định phương pháp, cách tiếp cận để thực thi dự án

 Kế hoạch quản lý cấu hình và quản lý các rủi ro

 Ứng dụng vào dự án

 Đánh giá – Kết luận

KẾ HOẠCH THỰC HIỆN ĐỀ TÀI

STT Ngày Nội dung Chữ ký GVHD

1 19/09/2012 Xác định đề tài và những việc cần làm để thực hiện đề tài

2 26/09/2012 Tìm hiểu tổng quan về SOS Plan

3 10/10/2012 Tìm hiểu sâu hơn các vấn đề liên quan đến Hệ thống Quản Lý Chất lượng phần mềm

4 20/10/2012 Tìm hiểu 1 dự án có ứng dụng SOS Plan

5 22/10/2012

Ứng dụng kế hoạch Hệ Thống Quản Lý Chất

lượng phần vào 1 dự án (Ứng dụng SOS vào dự

án phần mềm ACIS)

6 05/11/2012 Hoàn chỉnh và viết báo cáo

7 13/11/2012 Tuần lễ dự trù đề hoàn chỉnh đề tài

8 19/11/2012 Nộp đề tài

MỤC LỤC



Phần 1 GIỚI THIỆU 1

1 Tổng quan: 1

1.1 Quản lý chất lượng phần mềm là gì? 1

1.2 Giới thiệu Hệ thống quản lý chất lượng phần mềm 2

1.2.1 Mục tiêu 2

1.2.2 Hoạt động và yếu tố cơ bản 2

1.3 Lập kế hoạch Hệ thống quản lý chất lượng phần mềm 12

2 Đánh giá hiện trạng chung: 13

3 Đề xuất nội dung nghiên cứu: 14

4 Nội dung thực hiện: 14

Phần 2: PHƯƠNG PHÁP LẬP KẾ HOẠCH QUẢN LÝ CHẤT LƯỢNG 14

1 Ước lượng phạm vi và kích thước dự án: 14

1.1 Phạm vi và kích thước 14

1.1.1 Tổng quan: 14

1.1.2 Quy trình quản lý phạm vi: 15

1.1.3 Lập kế hoạch phạm vi: 15

1.1.3.1 Thảo quy định phạm vi dự án: 15

1.1.3.2 Thảo tôn chỉ dự án: 17

1.1.3.3 Thảo bảng kê công việc: 18

1.2 Khối lượng công việc phải làm 19

2 Xác định nhân lực và chi phí: 20

2.1 Nhân lực: 20

2.1.1 Các dạng tổ chức: 21

2.1.2 Chức năng cơ bản trong các cấu trúc tổ chức: 22

2.1.4 Các đối tượng liêu quan dự án: 23

2.2 Chi phí: 25

2.2.1 Lập kế hoạch về nguồn tài nguyên: 25

2.2.1.1 Nguyên tắc ước lượng chi phí: 26

2.2.1.2 Chi phí nguyên vật liệu: 27

2.2.1.3 Chi phí cơ sở vật chất: 28

2.2.2 Ước tính chi phí: 28

2.2.2.1 Ước lượng chính quy: 29

2.2.2.2 Ước tính sử dụng kết quả chào thầu: 29

2.2.2.3 Thông tin lịch sử hay cơ sở dữ liệu dự án: 30

2.2.2.4 Ước lượng theo giai đoạn: 30

2.2.2.5 Ước lượng theo tham số: 31

2.2.2.6 Ước lượng dưới lên: 32

2.2.2.7 Ước lượng trên xuống: 33

2.2.2.8 Độ tin cậy trong ước lượng: 33

2.2.3 Dự toán ngân sách cho các chi phí (kế toán dự án): 35

2.2.4 Kiểm soát chi phí: 35

2.2.4.1 Theo dõi kinh phí qua các chỉ tiêu: 35

2.2.4.2 Kiểm soát - điều chỉnh phí: 36

2.2.4.3 Tiến hành cập nhật kinh phí: 37

3 Phương pháp, cách tiếp cận để thực thi dự án: 38

3.1 Thế nào là dự án thành công: 38

3.2 Sự thành công – thất bại của dự án: 38

3.3 Các công việc cơ bản của quản trị dự án: 39

3.4 Triển khai dự án: 39

4 Lập kế hoạch làm việc chi tiết: 40

4.1 Giới thiệu: 40

4.2 Cấu trúc phân rã chi tiết công việc (WBS): 42

4.3 Các yếu tố của kế hoạch dự án toàn diện 45

5 Kế hoạch phối hợp và hỗ trợ hoàn thành dự án: 46

5.1 Xác định thông tin-thiết kế kế hoạch trao đổi thông tin: 47

5.1.1 Yêu cầu trao đổi thông tin: 47

5.1.2 Lập kế hoạch truyền thông – kế hoạch trao đổi thông tin: 48

5.2 Phân phối thông tin – xác định các kênh trao đổi thông tin: 49

5.3 Báo cáo hiệu quả dự án: 50

6 Kế hoạch quản lý cấu hình và quản lý các rủi ro: 51

6.1 Kế hoạch quản lý cấu hình: 51

6.1.1 Giới thiệu: 51

6.1.2 Lập kế hoạch quản lý cấu hình: 52

6.1.2.1 Định danh các chỉ số cấu hình IC: 52

6.1.2.2 Kiểm soát phiên bản 53

6.1.2.3 Quản lý baseline 53

6.1.2.4 Kiểm soát thay đổi 54

6.1.2.5 Báo cáo tình trạng cấu hình 55

6.1.2.6 Kiểm tra và xem xét (Auditing) 55

6.1.2.7 Quản lý release 55

6.1.2.8 Lưu trữ và chép dự phòng 56

6.2 Kế hoạch quản lý rủi ro: 57

6.2.1 Giới thiệu: 57

6.2.2 Kế hoạch quản lý rủi ro: 57

6.2.2.1 Nhận diện rủi ro: 58

6.2.2.3 Kiểm soát rủi ro: 62

6.2.2.4 Giám sát và điều chỉnh: 63

7 Các kế hoạch khác: 64

8 Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án: 64

8.1 Định nghĩa cấu trúc tài liệu dự án: 64

8.2 Quy trình quản lý yêu cầu thay đổi: 64

Phần 3: ỨNG DỤNG KẾ HOẠCH QUẢN LÝ CHẤT LƯỢNG PHẦN MỀM VÀO DỰ ÁN ACIS 65

Phần 4: ĐÁNH GIÁ - KẾT LUẬN 83

1 Kết quả đạt được: 83

2 Hạn chế 84

3 Đề xuất – cải tiến 84

DANH SÁCH HÌNH ẢNH, HÌNH VẼ

Hình 1 Các nội dung liên quan tới hệ thống chất lượng phần mềm 1

Hình 2 Vòng đời phát triển phần mềm 2

Hình 3 Các hoạt động chính trong hệ thống quản lý chất lượng phần mềm 3

Hình 4 Các tiêu chuẩn 4

Hình 5 Tổng quan về chu trình phát triển phần mềm 6

Hình 6 Quy trình kiểm tra đơn giản 7

Hình 7 Quản lý cấu hình các hoạt động 9

Hình 8 Biểu đồ khối thể hiện tầm quan trọng về mục tiêu chất lượng và chu kỳ phát triển phần mềm, mỗi thành phần có liên hệ chặt chẽ với nhau 12

Hình 9 Chức năng cơ bản trong các cấu trúc tổ chức 22

Hình 10 Sơ đồ tổ chức theo cấu trúc dự án ma trận 23

Hình 11 Quy trình cơ bản quản lý rủi ro 57

Hình 12 Mối quan hệ và trình tự các bước trong quy trình kiểm soát rủi ro 59

Hình 13 Ví dụ đơn giản dùng sơ đồ xương cá định vị rủi ro 61

Hình 14 Một số chiến lược và minh họa các phương pháp đối phó rủi ro thường gặp 62

DANH SÁCH BẢNG BIỂU

Bảng 1 Phân tích lỗi 8

Bảng 2 Các dạng tổ chức nhân lực 21

Bảng 3 Các đối tượng liên quan dự án trong các dự án điển hình 24

Bảng 4 Các thành phần của Hiệu suất chi phí và Biến động chi phí 35

Bảng 5 Các công thức tính trong EMV 37

Bảng 6 Yêu cầu trao đổi thông tin 48

Bảng 7.Các phương pháp trao đổi thông tin 49

Bảng 8 Phân tích biến động ngân sách 51

Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội tìnhcủa hoạt động phát triển phần mềm, điều họ cần quan tâm là liệu sản phẩm cuối cùnggiao cho họ có đúng hạn hay không và làm việc đúng như họ muốn hay không.

Tuy nhiên theo quan điểm của người phát triển phần mềm, thực tế cho thấy hoạt độngkiểm tra phần mềm là quan trọng, nhưng không đủ để đảm bảo sản phẩm sẽ được hoànthành đúng hạn và đúng yêu cầu Kiểm tra sau cùng để phát hiện lỗi là điều tất nhiên phảilàm, nhưng trong rất nhiều trường hợp, điều đó thường quá trễ và sẽ phải mất rất nhiềuthời gian để sửa chữa

Thực tế cho thấy, để đảm bảo được hai tiêu chí "đơn giản" trên của khách hàng, đòi hỏi tổchức không chỉ vận hành tốt khâu kiểm tra phần mềm, mà phải tổ chức và duy trì sự hoạtđộng nhịp nhàng của cả một hệ thống các công việc liên quan đến một dự án phần mềm,

từ đây xuất hiện một khái niệm có tên là “hệ thống quản lý chất lượng phần mềm”(HTQLCLPM)

Hình 1 Các nội dung liên quan tới hệ thống chất lượng phần mềm

Hiện có nhiều mô hình cung cấp các tiêu chuẩn cũng như hướng dẫn để triển khaiHTQLCLPM Hai trong số những mô hình được áp dụng rộng rãi hiện nay là ISO 9001-

2000 và CMM/CMMi Trong khi ISO 9001-2000 là tiêu chuẩn quản lý chất lượng dànhcho tất cả các ngành nghề với những điều khoản ngắn gọn và mang tính tổng quát, thìCMM/CMMi là một bộ tập hợp khá đồ sộ các kinh nghiệm thực hành (gần 450 trang vớiCMM, và gần 700 trang với CMMi) có thể làm người đọc chưa có kinh nghiệm khó biếtđược các hoạt động và yếu tố đặc trưng cơ bản của HTQLCLPM là gì

1.2 Giới thiệu Hệ thống quản lý chất lượng phần mềm [1]

Hệ thống quản lý chất lượng phần mềm bao gồm các quy trình được thực thi xuyên suốtchu kỳ phát triển của dự án phần mềm nhằm quản lý chất lượng hệ thống phần mềm saocho không vượt quá yêu cầu của khách hàng, các chuẩn của công ty, tổ chức để đảm bảođược chất lượng phần mềm

1.2.1 Mục tiêu [1]

SQS thường có 2 mục tiêu:

• Mục tiêu thứ nhất: xây dựng chất lượng cho phần mềm ngay từ giai đoạn bắt đầu Điềunày đồng nghĩa với việc bảo đảm các yêu cầu cho phần mềm phải được định nghĩa, diễnđạt và hiểu một cách đúng đắn giữa người đưa ra yêu cầu và người thực hiện yêu cầu

• Mục tiêu thứ hai: bảo đảm chất lượng của phần mềm xuyên suốt quá trình phát triển(software life cycle – SLC)

Hình 2 Vòng đời phát triển phần mềm 1.2.2 Hoạt động và yếu tố cơ bản [1]

Một HTQLCLPM hoàn chỉnh bao gồm rất nhiều hoạt động và bộ phận cấu thành, chúngkhác nhau tùy theo từng tổ chức khi triển khai

Có 10 hoạt động và yếu tố cơ bản nhất thường gặp:

Hình 3 Các hoạt động chính trong hệ thống quản lý chất lượng phần mềm

1 Các tiêu chuẩn (Standards) [1]

Sản xuất phần mềm ngày nay không còn đơn thuần mang tính sáng tạo ngẫu hứng nhưtrước đây, mà đang trở thành một lĩnh vực được kiểm soát chặt chẽ, theo những tiêuchuẩn nhất định Các tiêu chuẩn có thể là các kinh nghiệm hoặc các phương pháp hiệuquả nhất, được đề xuất từ các hiệp hội nghề nghiệp như IEEE (The Institute of Electricaland Electronics Engineers, Inc – Học viện các kỹ sư điện và điện tử), từ các tổ chức quốc

tế như ISO (International Organization for Standardization), hoặc các quy tắc chuẩn hóa

để giao tiếp giữa sản phẩm với nhau hoặc đơn giản do chính tổ chức phát triển PM đề

ra để áp dụng cho chính họ

Hình 4 Các tiêu chuẩn

Các tiêu chuẩn có thể bao gồm tất cả các khía cạnh của một chu kỳ phát triển PM, trải dàisuốt mọi pha phát triển Bất kể tiêu chuẩn xuất phát từ đâu, từ nội bộ công ty, hoặc từngoài, nó đều phải có một số đặc điểm sau:

• Tính cần thiết (Necessity)

• Tính khả thi (Feasibility)

• Tính đo lường được (Measurability)

Các tiêu chuẩn nên được chọn và thể hiện sao cho khi sử dụng, các khía cạnh kỹ thuậtcần thiết sẽ được nhấn mạnh, tránh trường hợp hiểu sai hoặc sa vào những tiểu tiết phụtrợ Một ví dụ thường thấy là tiêu chuẩn định dạng cho tài liệu, mục đích của tiêu chuẩn

là để bảo đảm khía cạnh chất lượng về kỹ thuật của tài liệu Tuy nhiên, trong rất nhiềutrường hợp tiêu chuẩn đã bị hiểu sai và sa đà vào việc kiểm tra các chi tiết về mặt hìnhthức Lưu ý là để bảo đảm các tiêu chuẩn được nghiêm túc thực hiện, chúng phải mangtính bắt buộc và được quy định ở chính sách cấp công ty

Một dạng phổ biến bắt buộc phải có của tiêu chuẩn là hệ thống các “quy trình”, kèm theocác bộ phận phụ thuộc như “thủ tục”, “hướng dẫn”, “mẫu biểu”, “tiêu chuẩn”,… Tùy

theo lĩnh vực hỗ trợ mà chúng có các tên tương ứng, chẳng hạn: quy trình sản xuất PM,quy trình kiểm soát chất lượng, quy trình kiểm tra

2 Xem xét, xem lại (Reviewing) [1]

Mục đích là để cung cấp thông tin trực quan về tình trạng của các hoạt động xảy ra trongsuốt quá trình sản xuất và cài đặt PM

Xem xét trên sản phẩm – thường được gọi là xem xét kỹ thuật – bao gồm hai loại: chínhthức hoặc không chính thức Xem xét không chính thức thường được thực hiện trong quátrình phát triển sản phẩm, còn xem xét chính thức thường được thực hiện tại thời điểmkết thúc các chặng phát triển

Điểm khác nhau chính về mặt kỹ thuật giữa xem xét chính thức và không chính thức là ởmức độ nghiêm ngặt của quy trình và các bước thực hiện Chẳng hạn, xem xét chính thứcbuộc phải lên kế hoạch, ghi nhận tất cả các lỗi phát hiện và giám sát đến khi tất cả lỗi đãđược sửa chữa, xem xét không chính thức thì không bắt buộc

Trong thực tế, có khá nhiều định nghĩa và nhiều loại xem xét khác nhau Về tổng quan,IEEE định nghĩa có ba loại:

 Review: Cuộc họp chính thức nhằm trình bày một vấn đề, một tài liệu, một sản phẩm cho những người quan tâm, người sử dụng, khách hàng nhằm thu thập ý kiến phảnhồi hoặc đạt được sự thỏa thuận phê chuẩn trên vấn đề, tài liệu hoặc sản phẩm đượctrình bày

 Walkthrough: Kỹ thuật đánh giá không chính thức, qua đó tác giả của một tài liệu, sảnphẩm giải thích tài liệu, sản phẩm đó cho một nhóm đồng nghiệp Các đồng nghiệpnày sẽ đặt câu hỏi hoặc cho ý kiến bổ sung về một số lĩnh vực để bảo đảm chất lượng

kỹ thuật của tài liệu hoặc sản phẩm

 Inspection: Kỹ thuật đánh giá chính thức, qua đó tài liệu, sản phẩm được nhữngngười không phải là tác giả hoặc trực tiếp liên quan kiểm tra một cách chi tiết để pháthiện lỗi, các vi phạm tiêu chuẩn, hoặc các vấn đề khác (nếu có) Về cơ bản, nó được tổchức và thực hiện chặt chẽ hơn walkthrough Vai trò của những người tham gia đượcphân định rõ ràng Tài liệu chuẩn bị cho việc xem xét được chuẩn bị trước chu đáo

Một điểm cần hết sức lưu ý để bảo đảm việc xem xét mang lại hiệu quả là: mục tiêuchính của việc xem xét nhằm để tìm ra lỗi Một trong những lý do chính khiến cho rấtnhiều cuộc xem xét không mang lại hiệu quả như mong muốn là các cuộc xem xét đó bị

"lún" vào việc thảo luận các giải pháp để sửa chữa lỗi Sửa lỗi thường yêu cầu phải có sựphân tích kỹ lưỡng cũng như phải chấp nhận các phản biện trên các phương pháp sửa lỗi,công việc này hoàn toàn không phù hợp cho một buổi xem xét tìm lỗi Một khi tìm thấylỗi, nó nên được giao cho một/nhóm người phân tích và giải quyết, việc xem xét chỉ nênchú tâm vào việc chỉ ra các sai sót

Hình 5 Tổng quan về chu trình phát triển phần mềm

3 Kiểm tra (Testing) [1]

Kiểm tra lỗi (testing) là một hoạt động sống còn trong sản xuất PM Kiểm tra lỗi nhằmmục đích chứng minh rằng các yêu cầu đối với PM là được thỏa mãn Các hoạt độngkiểm tra bao gồm các bước: lập kế hoạch, thiết kế test, thi hành test, và báo cáo kết quảkiểm tra

Ở đây muốn nhấn mạnh đến bước lập kế hoạch kiểm tra bắt đầu từ giai đoạn nhận và pháttriển yêu cầu Tương tứng với mỗi yêu cầu là một phương pháp kiểm tra thích hợp Mộtyêu cầu không thể coi là hoàn chỉnh nếu như nó không thể kiểm tra được Kế hoạch kiểmtra được thiết lập ngay từ chặng phát triển yêu cầu Do yêu cầu thường thay đổi xuyênsuốt dự án, kế hoạch kiểm tra do đó cũng phải thay đổi theo

Hình 6 Quy trình kiểm tra đơn giản

4 Phân tích lỗi (Defect analysis) [2]

Trong thực tế, lỗi là phần “luôn hiện diện” trong mọi phần mềm từ giai đoạn phát triển sơkhởi đến khi nó không còn được sử dụng

Các tổ chức phần mềm thường dùng thuật ngữ “chất lượng” để chỉ zero, hay một lượngnhỏ các lỗi trên sản phẩm phần mềm, một số khác lại gắn liền khái niệm “chất lượng” với

sự hài lòng của khách hàng Trên quan điểm khách hàng, bất kể lúc nào, hễ phần mềm

“chạy” không tốt, không đáp ứng sự mong đợi đều được xem là có lỗi, bất kể do code sai,hoặc do hiểu nhầm yêu cầu, thậm chí là một chức năng “nên có” nhưng hiện thời chưasẵn sàng

Phân tích lỗi được thực hiện trên tất cả lỗi được tìm thấy, nhằm mục đích tìm hiểunguyên nhân và xu hướng gây ra lỗi, định hướng cho việc sửa chữa các lỗi hiện hànhcũng như phòng ngừa, triệt tiêu khả năng xảy ra lỗi trong tương lai Phân tích lỗi là conđường chính yếu phục vụ cho việc giảm sự xuất hiện lỗi

Phân tích lỗi không chỉ nhằm mục đích cải thiện tình trạng lỗi của phần mềm đang xâydựng, xa hơn nó cho ta thấy được những điểm yếu cần cải tiến của quy trình phát triển

PM Thông tin về lỗi của các dự án trong quá khứ sẽ cho ta thấy được nên cải tiến, thay

đổi quy trình phát triển PM như thế nào để các dự án trong tương lai tránh đi vào "vết xeđổ” của các dự án trước.

Số liệu phục vụ cho việc phân tích lỗi có thể đến từ nhiều nguồn khác nhau Mỗi tổ chứctuỳ theo nhu cầu và đặc điểm riêng, tự định nghĩa và thu thập các số liệu này

Lỗi trong quá trình phân tích và sửa chữa có thể được phân loại để có hành động phùhợp, tuỳ theo các đặc tính khác nhau mà chúng thể hiện Các đặc tính trong Bảng: “Cácthuộc tính của lỗi” thường được sử dụng trong nhiều hệ thống phân tích lỗi

Phân loại Mô tả

Độ nghiêm

trọng

(Severity)

Ảnh hưởng của lỗi đối với PM đang được xây dựng, bao gồm các mức:

 Critical: Rất nghiêm trọng, có thể làm cho PM "chết cứng" và không

Độ ưu tiên

(Priority) Độ ưu tiên sửa lỗi khi so sánh với các lỗi khác, bao gồm các mức: E = emergency; độ ưu tiên cao nhất, lỗi phải được sửa ngay, nếu

không công việc sẽ không thể tiếp tục

 H = high, độ ưu tiên cao; công việc sẽ bị ngăn trở rất nhiều nếu nhưlỗi vẫn chưa được sửa

 M = medium, độ ưu tiên trung bình; công việc sẽ gặp vài khó khănnếu như lỗi vẫn chưa được sửa

 L = low; độ ưu tiên thấp nhất; công việc không bị ảnh hưởng nhưnglỗi vẫn phải được sửa

 I = inspection – khảo sát lỗi

 D = debugging or unit testing – dò lỗi hoặc kiểm tra mức đơn vị

 T = testing – kiểm tra mức hệ thống

Bảng 1 Phân tích lỗi

5 Quản lý cấu hình (Configuration Management) [1]

Mục đích của quản lý cấu hình (QLCH) là để thiết lập và bảo đảm tính toàn vẹn của cácsản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án PM, xuyên suốt chu

kỳ sống của dự án đó

QLCH bao gồm nhiều hoạt động, tuy nhiên về cơ bản chúng bao gồm bốn hoạt độngchính: nhận dạng (identification), kiểm soát (control), kiểm kê báo cáo (accounting) vàkiểm tra đánh giá (audit) Tùy theo độ lớn và độ phức tạp của dự án, phạm vi và mức độ

áp dụng của các hoạt động QLCH sẽ khác nhau Với những hệ thống lớn và phức tạp,mỗi hoạt động QLCH phải do những người được giao trách nhiệm (role) cụ thể phụ trách.Tùy yêu cầu, một số hoạt động QLCH được làm không chính thức (informal) hoặc chínhthức (formal), nhằm quản lý tốt quá trình phát triển của phần mềm, đặc biệt là quản lý sựthay đổi trong dự án

Hình 7 Quản lý cấu hình các hoạt động

Các yếu tố hay nguyên nhân tác động đến dữ liệu hoặc trung tâm dữ liệu của hệ thốngphần mềm rất đa dạng Đó có thể là tự nhiên hoặc cố ý, chẳng hạn thiên tai, cháy, virus,

hacker, phá hoại của chính nhân viên công ty, ăn cắp dữ liệu, thậm chí ngày nay còn docác hoạt động khủng bố gây ra Trong một số tổ chức, việc bảo mật dữ liệu lưu trữ và dữliệu chuyển dịch được xem là vấn đề sống còn.

Một lý do gây hỏng dữ liệu rất thường gặp là dữ liệu bị thay đổi một cách vô tình khôngkiểm soát được Một khi dữ liệu đã không đúng, điều tất yếu là hệ thống phần mềm sửdụng dữ liệu đó sẽ cho ra những kết quả sai Đối với người dùng, đó là một hệ thốngkhông tốt, thậm chí là không dùng được

Một hệ thống phần mềm “tốt” phải chú ý tới tất cả những yếu tố có thể ảnh hưởng đến dữliệu hoặc hoạt động của hệ thống Một hệ thống “tốt” còn phải tính đến khả năng phụchồi dữ liệu, phục hồi hoạt động của hệ thống khi xảy ra sự cố

7 Đào tạo, huấn luyện (Education/Training) [1]

Nói đơn giản, huấn luyện nhằm trang bị cho những người phát triển cũng như sử dụngphần mềm có đủ kiến thức và kỹ năng để thực hiện công việc của họ

Tất cả mọi biện pháp quản lý, kỹ thuật sản xuất, công cụ hỗ trợ trong sản xuất phần mềmđều trở nên vô hiệu hoặc có hiệu quả hết sức hạn chế nếu những người tham gia pháttriển và sử dụng phần mềm không đủ kiến thức, kỹ năng cần thiết Liên quan đến lý donày, các tiêu chuẩn quản lý chất lượng như ISO, CMM/CMMi đều xác lập khả năng, kiếnthức và kỹ năng của những người phát triển phần mềm là một trong những yêu cầu cốtyếu để bảo đảm các tiêu chí và mục tiêu về chất lượng

Một khía cạnh khác thường được cho là ít quan trọng nhưng thực ra lại mang tính quyếtđịnh, đó là khả năng hiểu để sử dụng phần mềm của người sử dụng Người sử dụngthường chỉ có ý tưởng về yêu cầu đối với phần mềm và không biết sử dụng hoặc sử dụngkhông đúng cách làm phần mềm “chạy” sai hoặc không hết chức năng Do vậy huấnluyện cho người sử dụng cũng là một khâu hết sức cơ bản Nhưng thực tế những ngườiphát triển phần mềm lại không có thời gian và kỹ năng thực hiện tốt việc huấn luyện, việcnày thường phải do một bộ phận chuyên trách trong công ty thực hiện

8 Quản lý người cung cấp, thầu phụ (Vendor Management) [1]

Trong các tổ chức phần mềm, mua hay thuê sản phẩm hoặc dịch vụ từ một người cungcấp thứ ba là rất phổ biến Việc “mua” có thể bao gồm những mặt hàng đơn giản như

máy tính, máy in, cho đến những dịch vụ thuê gia công phần mềm Chất lượng của sảnphẩm và dịch vụ “mua” này nếu quản lý không tốt sẽ ảnh hưởng quan trọng đến sảnphẩm hoặc dịch vụ của tổ chức cung cấp cho khách hàng của mình.

Đối tượng sản phẩm hoặc dịch vụ cần mua hay thuê rất đa dạng, tùy mỗi loại và độ phứctạp, các tổ chức sẽ có những biện pháp và mức độ quản lý chất lượng tương ứng

9 Sự an toàn (Safety)[1]

10 Quản lý rủi ro (Risk Management) [1]

Rủi ro (risk) là một yếu tố tồn tại trong mọi dự án Quan niệm về quản trị dự án cho rằng

“người quản trị dự án giỏi là người không ngạc nhiên về các sự kiện xảy ra trong dự án”,điều này có nghĩa là mọi rủi ro tiềm ẩn phải được “nhìn thấy” trước, đi đôi với kế hoạchgiải quyết

Rủi ro là một sự kiện chưa nhưng có khả năng xảy ra, và khi nó xảy ra thường sẽ đặt một

dự án vào tình huống xấu, hoặc thậm chí là một "tai nạn" cản trở khả năng hoàn thành cácmục tiêu của một dự án Có nhiều loại cũng như cách xếp các loại rủi ro khác nhau, tuynhiên nhìn chung có các loại sau:

Về kỹ thuật: Chủ yếu xoay quanh việc có hiểu đúng và đủ các yêu cầu đặt ra cho dự ánhay không, cũng như có giải pháp đúng để giải quyết chúng hay không Việc hiểu saiyêu cầu cũng như đưa ra giải pháp sai là nguyên nhân hàng đầu làm dự án thất bại

Về quản lý: Xoay quanh các vấn liên quan về mặt quản lý Chúng cũng rất đa dạng,gồm các loại rủi ro sau: kế hoạch, tài chính, con người, thay đổi yêu cầu

Về thao tác-vận hành: Liên quan đến việc vận hành hệ thống, bao gồm:

 Huấn luyện cho người sử dụng không đầy đủ

 Sử dụng sai chức năng của sản phẩm, kể cả cố ý hoặc vô tình

 Bảo trì sản phẩm không đầy đủ

Về môi trường: Bao gồm cả môi trường phát triển, kiểm tra lẫn sử dụng sản phẩm.Những rủi ro từ bên ngoài, sự không tương thích, virus, …

Về kiểm tra: Không đủ thời gian hoặc kiểm tra không đúng, không quét hết yêu cầu.Quy trình cơ bản quản lý rủi ro gồm 4 bước:

 Nhận biết các rủi ro

 Khảo sát mức tác động nếu chúng xảy ra

 Xác định các giải pháp đối phó

 Giám sát các rủi ro và thực thi các giải pháp đối phó

Có rất nhiều giải pháp khác nhau để đối phó hay giảm thiểu tác động của rủi ro Trongthực tế, các giải pháp thường gồm các loại:

 Loại bỏ: Khi chi phí loại bỏ rủi ro thấp, hoặc rủi ro nếu xảy ra sẽ gây ảnh hưởngcực kỳ nghiêm trọng

 Phòng tránh

 Giảm thiểu thiệt hại: Khi không thể phòng tránh hay loại bỏ rủi ro, ta có thể thựcthi các biện pháp để giảm thiểu khả năng xảy ra hoặc giảm thiểu chi phí khắc phụcrủi ro nếu nó xảy ra

 Chấp nhận: Đành chấp nhận "sống chung với rủi ro" trong trường hợp chi phí loại

bỏ, phòng tránh, làm nhẹ rủi ro là quá lớn, hoặc mức độ tác hại của rủi ro nếu xảy

ra là không đáng kể, hoặc khả năng xảy ra của nó là cực thấp

Hình 8 Biểu đồ khối thể hiện tầm quan trọng về mục tiêu chất lượng và

chu kỳ phát triển phần mềm, mỗi thành phần có liên hệ chặt chẽ với nhau

1.3 Lập kế hoạch Hệ thống quản lý chất lượng phần mềm [2]

Lập kế hoạch là yêu cầu kinh điển cũng như thao tác cơ bản của hầu hết các hệ thốngquản lý chất lượng phần mềm Kết quả của hoạt động này thường là một (hoặc nhiều) tàiliệu gọi là bản kế hoạch.

Theo quan điểm quản lý hiện đại, các công việc gắn liền với những mục tiêu, ngắn hạnhoặc dài hạn, đều có thể xem như là một dự án hoặc chuỗi các dự án Kế hoạch cho dự ánthường bao gồm những điểm chính sau:

 Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm

 Xác định nhân lực, vật lực và chi phí

 Chỉ định phương pháp, cách tiếp cận để thực thi dự án

 Lập kế hoạch làm việc chi tiết

 Kế hoạch phối hợp và hỗ trợ hoàn thành dự án

Đây là kế hoạch liên quan đến sự tham gia của những người có ảnh hưởng quan trọngđến sự thành công hay thất bại của dự án (thuật ngữ chuyên môn gọi là stakeholders).Những người này thường bao gồm: trưởng dự án, quản lý cấp cao, khách hàng, ban giámđốc, thầu phụ, nhà cung cấp Kế hoạch này phải bảo đảm cơ chế để các stakeholders cóthể tham gia vào dự án ở các mức độ và thời điểm mang lại hiệu quả cao nhất

 Kế hoạch quản lý cấu hình và quản lý các rủi ro

 Các kế hoạch khác

Tùy theo nhu cầu cho từng dự án, có thể có nhiều kế hoạch khác, cả về quản lý hoặc kỹthuật, một số kế hoạch thường gặp chẳng hạn: Kế hoạch kiểm tra, kế hoạch tích hợp sảnphẩm, kế hoạch huấn luyện

 Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án

Lưu ý là các tài liệu kế hoạch của dự án không phải bất di bất dịch, nó phải được cập nhậtthậm chí thay đổi xuyên suốt dự án khi yêu cầu của dự án thay đổi

2 Đánh giá hiện trạng chung: [2]

Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một số đánh giá là cònyếu của các công ty phần mềm Việt Nam Một số công ty trong nước hiện đã đạt cácchuẩn quốc tế CMM/CMMI trong nâng cao năng lực và quản lý chất lượng phần mềm,

song chỉ đếm được trên đầu ngón tay, và hiện cũng chỉ gói gọn trong vài công ty gia côngcho thị trường nước ngoài.

Làm thế nào để một công ty này đạt được chuẩn quốc tế về chất lượng phần mềm? Mỗicông ty đều có đặc thù riêng, tuy nhiên điều chung nhất là họ đều phải phát triển và duytrì một Hệ thống quản lý chất lượng phần mềm

3 Đề xuất nội dung nghiên cứu:

Một HTQLCLPM không chỉ có quy trình, kiểm tra hoặc ra lệnh, nó là sự kết hợp gắn bócủa nhiều yếu tố Mục tiêu sau cùng của HTQLCLPM là, dựa vào kết quả của các yếu tốcấu thành, cung cấp thông tin làm đầu vào cho những quyết định đúng đắn về quản lý,mang lợi ích về khi áp dụng các quy trình phát triển PM

4 Nội dung thực hiện: [2]

 Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm

 Xác định nhân lực, vật lực và chi phí

 Chỉ định phương pháp, cách tiếp cận để thực thi dự án

 Lập kế hoạch làm việc chi tiết

 Kế hoạch phối hợp và hỗ trợ hoàn thành dự án

 Kế hoạch quản lý cấu hình và quản lý các rủi ro

 Các kế hoạch khác

Tùy theo nhu cầu cho từng dự án, có thể có nhiều kế hoạch khác, cả về quản lý hoặc

kỹ thuật, một số kế hoạch thường gặp chẳng hạn: Kế hoạch kiểm tra, kế hoạch tíchhợp sản phẩm, kế hoạch huấn luyện

 Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án

Phần 2: PHƯƠNG PHÁP LẬP KẾ HOẠCH QUẢN LÝ CHẤT LƯỢNG[2]

1 Ước lượng phạm vi và kích thước dự án:[2]

1.1 Phạm vi và kích thước[2]

1.1.1 Tổng quan

 Phạm vi (Scope) là một danh sách tất cả những gì dự án phải làm (và cũng có thể làmột danh sách tất cả những điều mà dự án không phải làm) Dự án phải có một phạm

vi được viết ra rõ ràng, nếu không dự án sẽ không bao giờ kết thúc

 Các kết quả chuyển giao (Deliverables) là những sản phẩm của dự án mà sẽ chuyểngiao: như là phần cứng, phần mềm (mua hoặc phát triển), bảo hành, tài liệu, đào tạo

và phương thức chuyển giao

 Nhóm dự án và các bên liên quan (Stakeholders) phải cùng hiểu những sản phẩm nàođược tạo ra như là kết quả của dự án và chúng được tạo ra như thế nào

1.1.2 Quy trình quản lý phạm vi [2]

 Khởi thảo: Bắt đầu một dự án hoặc chuyển tiếp sang giai đoạn tiếp theo

 Lập kế hoạch phạm vi: phát triển các tài liệu nhằm cung cấp nền tảng cho các quyếtđịnh về dự án trong tương lai

 Xác định phạm vi: chia nhỏ các sản phẩm trung gian của dự án thành các thành phầnnhỏ hơn, dễ quản lý hơn

 Kiểm tra phạm vi: hợp thức hóa việc chấp nhận phạm vi của dự án

 Điều khiển thay đổi phạm vi: điều khiển những thay đổi của phạm vi dự án

1.1.3 Lập kế hoạch phạm vi [2]

1.1.3.1 Thảo quy định phạm vi dự án [2]

Quy định phạm vi dùng để thử mức độ gay go cho mỗi yêu cầu thay đổi mà bạn nhậnđược Quy định phạm vi là chỉ dẫn duy nhất của bạn khi ai đó hỏi liệu điều gì sẽ xảy ra vàliệu lỗi đó có được sửa chữa hay không, liệu đặc tính đó có được xây dựng hay không,liệu giao diện đó có thay đổi hay không hay liệu họ có được đào tạo hay không ?

Thảo quy định phạm vi là công việc khó khăn và buồn tẻ nhưng cần thiết Quy địnhphạm vi phải có tài liệu yêu cầu được nghiên cứu cẩn thận

Nguyên tắc: Tập hợp thông tin phù hợp cho kết luận tuân theo các nguyên tắc sau:

 Đảm bảo rằng loại dự án và quy mô dự án được xác định rơ:

+ Xem xét việc sử dụng kế hoạch dự án tích hợp cho dự án thêm / chuyển / thay đổi vàcác dự án vi mô

+ Chuẩn bị cho quy định phạm vi phức tạp hơn và lớn hơn cho cá dự án vĩ mô

 Đảm bảo rằng các phần có thể chuyển giao và ranh giới dự án được xác định rơ:

+ Tài liệu có xác định rơ cái sẽ được hoàn thành và không được hoàn thành nhưmộtphần của dự án hay không?

+ Các yêu cầu bắt buộc và không bắt buộc có xác định rơ hay không? Các tiêu chíchấp thuận cho các kết quả chuyển giao đă được phác thảo chưa?

+ Tài liệu có xác định rơ mỗi phần có thể chuyển giao nào sẽ bằng ngôn ngữ khôngbiệt ngữ hay không?

+ Bạn có biết khi nào dự án hoàn tất không?

+ Tính đến ngày tháng bắt đầu và ngày tháng hoàn tất theo mục tiêu trong đó có thờiđoạn tương đối với ngày tháng bắt đầu theo lư thuyết và / hoặc ngày tháng bắt đầu/kết thúc

+ Tính đến hậu quả của những ngày tháng bị trễ hạn theo toàn bộ dự án cũng như cácmốc quan trọng cụ thể

 Đảm bảo rằng trách nhiệm được xác lập rơ:

+ Đảm bảo rằng tất cả các bên liên quan hiểu vai tṛ và trách nhiệm của họ trong dự án.+ Cân nhắc việc sử dụng ma trận trách nhiệm

+ Mọi người có hiểu chuỗi yêu cầu cho dự án hay không?

+ Có một số quy định hay chuẩn của ngành ảnh hưởng tới các phần có thể chuyển giaohay không? Giao cho ai đó nghiên cứu và chịu trách nhiệm về các phạm vi này

 Đảm bảo rằng tam giác thép được đặt đúng chỗ:

+ Cái nào là ưu tiên giữa chi phi, lịch tŕnh và chất lượng?

+ Tính năng, lịch tŕnh hay kinh phí có thể thương lượng lại được để giữ cho dự án theođúng lịch tŕnh hay đúng kinh phí nếu cần thiết?

+ Bản đồ nguồn lực có ư nghĩa không? Các phần có thể chuyển giao có thể thực hiệnđược hay không?

+ Các mốc quan trọng đề ra có ư nghĩa không?

+ Ước tính chi phí đề ra có ư nghĩa không?

 Đảm bảo rằng quy định phạm vi phác thảo rơ rủi ro liên quan tới dự án:

+ Cẩn thận các rủi ro nghiệp vụ đó như các điều kiện thị trường xấu không trở thành

bộ phận của quy định rủi ro cho dự án

+ Cân nhắc việc sử dụng ma trận rủi ro để tránh hàng loạt những điều xấu có thể xảy

ra

1.1.3.2 Thảo tôn chỉ dự án [2]

Nghiên cứu trong ngành chỉ ra rằng có khoảng 20% đến 30% toàn bộ các dự án côngnghệ thông tin bị huỷ bỏ khi chúng đang ở giai đoạn xây dựng ý tưởng Tôn chỉ dự án cóthể giúp ngăn chặn điều này xảy ra với bạn Một hay nhiều người chịu trách nhiệm xâydựng tôn chỉ dự án khác nhau rất nhiều từ tổ chức này tới tổ chức khác và cuối cùng là ítquan trọng hơn nhiều so với người ký tài liệu

Dự án bạn đang thực hiện có đòi hỏi thời gian, nguồn lực hay tiền bạc không? Nếu câutrả lời là có thì khi đó bạn cần xây dựng tôn chỉ dự án

Định nghĩa

Tôn chỉ dự án là một tài liệu dự án cấp phép hay phê chuẩn một dự án Sự cấp phépnày quy định từ một mức quản lý thích hợp trở lên và nên thực hiện tối thiểu ba điều:

 Tôn chỉ dự án nên đặt tên dự án và bổ nhiệm giám đốc dự án

 Tôn chỉ dự án nên phác thảo các yêu cầu nghiệp vụ cho dự án

 Tôn chỉ dự án nên mô tả các yêu cầu chức năng sẽ được đưa ra

Xây dựng quy định dự án tuân theo các nguyên tắc sau:

 Đảm bảo rằng bên ký kết hay người ký/ cấp phép cho tài liệu quyết định này phải đúngchức năng, có thẩm quyền:

+ Bên ký kết có thể cho phép bổ nhiệm lại nhân sự có liên quan hay không?

+ Bên ký kết có thể cho phép giải phóng nguyên vật liệu có liên quan hay không? + Bên ký kết có thể cho phép tiêu dùng tiền bạc cần thiết hay không?

 Đảm bảo rằng quy định dự án rõ ràng:

+ Quy định dự án có đặt tên dự án rõ ràng hay không?

+ Quy định dự án có chỉ định rõ giám đốc dự án hay không?

+ Quy định dự án có chỉ rõ thời gian thực hiện và kinh phí dự án hay không?

+ Quy định dự án có phác thảo yêu cầu nghiệp vụ chứng minh cho dự án hay không? + Quy định dự án có mô tả yêu cầu chức năng sẽ được đưa ra hay không?

 Đảm bảo rằng quy định dự án được phân phát hợp lý:

+ Các đối tượng liên quan dự án có bản sao hay không?

+ Đội ngũ thành viên dự án có bản sao hay không?

+ Bộ phận kế toán hay tài chính có bản sao hay không?

+ Các nhà quản lý nguồn lực liên quan trong dự án có bản sao hay không?

1.1.3.3 Thảo bảng kê công việc [2]

Bảng kê công việc là tài liệu kiểm soát dự án có thể được sử dụng như một hợp đồngpháp lý, tài liệu phạm vi hay tài liệu kiểm soát nhưng thông thường nên phác thảo một sốchi tiết quan trọng:

 Công việc được thực hiện

 Ngày tháng, thời gian và địa điểm công việc được thực hiện

 Ai chịu trách nhiệm thực hiện công việc

 Nguyên vật liệu và kỹ thuật được dùng để thực hiện công việc

 Chi phí thực hiện công việc

 Tiêu chí chấp thuận công việc

Xây dựng bảng kê công việc hiệu quả tuân theo các nguyên tắc sau:

 Đảm bảo rằng bạn hiểu về loại dự án:

+ Cân nhắc cẩn thận các phần có thể chuyển giao liên quan để xác định xem dự án là

vĩ mô, vi mô hay thêm/ chuyển/ thay đổi

+ Đảm bảo rằng bạn hiểu rõ mối quan hệ giữa loại dự án và kỳ vọng cho tài liệu dự ántrong tổ chức của bạn

 Đảm bảo rằng bạn hiểu tổ chức của mình sử dụng bảng kê công việc như thế nào: + Tổ chức có mẫu bảng kê công việc hay không?

+ Xem xét các tệp dự án khác để xem họ sử dụng bảng kê công việc như thế nào

 Đi vào cụ thể để tránh những nhầm lẫn và hiểu lầm:

+ Đảm bảo rằng bạn tính đến tất cả các thông tin cần thiết (Đó là ai, cái gì, ở đâu, khinào và như thế nào)

+ Nên tránh các thuật ngữ kỹ thuật, các từ thông dụng, các từ viết tắt, hoặc định nghĩa

để đảm bảo rằng mọi người đang tiến hành công việc từ định nghĩa dùng chung

 Lấy chữ ký nếu bạn muốn nó mang tính pháp lý hoặc ràng buộc:

+ Nếu bạn đang dùng bảng kê công việc như một hợp đồng với các bộ phận khác nhauthì bạn cần chữ ký để làm cho hợp đồng có giá trị

1.2 Khối lượng công việc phải làm [2]

Việc xây dựng một bảng kê tốt phải mất nhiều giờ - thậm chí hàng ngày – làm việc cậtlực và sửa chữa

Bước 1 Viết ra sản phẩm chung nhất Dùng danh từ hay thuật ngữ mô tả trực tiếp 1 cách

vắn tắt (ví dụ: Hệ thống phần mềm quản lí nhân sự, Bệnh viện đa khoa, ) Thông tin lấy

từ tài liệu "Phác thảo dự án"

Bước 2 Tạo danh sách sản phẩm: Phân rã sản phẩm chung nhất thành các sản phẩm con

ở các mức thấp hơn Nói chung, khoảng 2-3 mức dưới là đủ

Bước 3 Tạo lập Danh sách công việc Mô tả các công việc ở dưới mỗi sản phẩm ở mức

thấp nhất Sau đó phân rã từng công việc ra thành các mức thấp hơn

Câu hỏi: Phân rã chi tiết công việc đến mức nào?

Trả lời: Nếu một công việc cần làm nhiều hơn 2 tuần (hoặc 80 giờ) thì nên phân rã tiếp

Bước 4 Đãnh mã cho mỗi ô của Bảng kê công việc

Mức 0: đánh mã 0.0 cho sản phẩm chung nhất

Mức 1: đánh các mã 1.0, 2.0, 3.0 cho các sản phẩm con

Đánh số tiếp mỗi ô trong bảng kê công việc một mã số duy nhất, theo cách sau:

 Từ trên xuống dưới

 Từ trái sang phải

 Nếu là 1.0 => đánh số tiếp là 1.1, 1.2, 1.3,

 Nếu là 1.1 => đánh tiếp là 1.1.1, 1.1.2, 1.1.3,

 Nếu là 1.2 => đánh tiếp 1.2.1, 1.2.2,

Không phân biệt nội dung trong 1 ô là sản phẩm hay công việc

Bước 5 Xét duyệt lại bảng kê công việc

 Tất cả các ô thuộc danh sách sản phẩm đều có danh từ (và có thể tính từ đi kèm),

 Tất cả các ô thuộc danh sách công việc có động từ ra lệnh và bổ ngữ,

 Tất cả các ô đều có mã duy nhất

2 Xác định nhân lực và chi phí: [2]

2.1 Nhân lực:[2]

 Con người quyết định sự thành công hay thất bại của tổ chức hay dự án

 Các con số thống kê gần đây về nhu cầu lực lượng lao động làm việc trong lĩnh vựcphát triển và ứng dụng công nghệ thông tin tăng nhanh, ví dụ dưới đây cho thấy rõđiều đó:

 Ở Mỹ: 12/2002 có hơn 10,1 triệu kỹ sư CNTT, tăng từ 9,9 triêu từ tháng 1/2002

 Các nhà quản lý CNTT dự đoán trong tương lai gần họ sẽ cần thêm 1,2 triệu kỹ sư

 Các công ty không thuộc lĩnh vực CNTT thuê kỹ sư nhiều hơn các công ty CNTTtheo tỉ lệ là 12:1

 Quản lý nguồi nhân lực cho dự án bao gồm các quá trình đòi hỏi phải phân bổ và sửdụng hiệu quả nhất nguồn lực con người trong toàn bộ hoạt động dự án Các quá trình

cơ bản bao gồm:

 Xác định cơ cấu tổ chức - Lập kế hoạch tổ chức

 Lên đội hình - Thu nhận nhân viên

 Triển khai đội hình - Phát triển Nhóm

2.1.1 Các dạng tổ chức:[2]

Các dạng tổ chức là các cấu trúc mà thông qua đó một công ty tổ chức các hoạt độnghàng ngày để tối ưu hoá hiệu quả Có ba dạng tổ chức chính là theo chức năng, ma trận

và theo dự án

Chúng có những đặc điểm sau:

Các dạng tổ chức Đặc điểm

Cấu trúc chức năng  Mỗi bộ phận chịu trách nhiệm thực hiện một tập hợp hoạt động

cụ thể, thường xuyên, và tương đối ổn định

 Nhiều người cùng thực hiện một dạng hoạt động

 Báo cáo theo thứ bậc, báo cáo của từng cá nhân với một nhàquản lý riêng

 Chức năng của giám đốc dự án tương đối thấp so với chức năngcủa các giám đốc chức năng

Cấu trúc ma trận  Các cá nhân vẫn báo cáo lên trên theo thứ bậc về chức năng,

nhưng họ cũng báo cáo theo chiều rộng với từ một giám đốc dự

án trở lên

 Trong một số tổ chức, sơ đồ báo cáo theo ma trận này có thể làhình thức tồn tại lâu dài

 Trong một dự án có cấu trúc ma trận thì ma trận chỉ là tạm thời

 Cấu trúc ma trận có thể được mô tả như hội tụ yếu, cân bằnghay hội tụ mạnh phụ thuộc vào chức năng tương đối của giámđốc dự án so với giám đốc chức năng

Cấu trúc theo dự

án

Hay “dự án thuần

tuý”

 Giám đốc dự án và đội dự án nòng cốt hoạt động như một đơn

vị tổ chức hoàn toàn độc lập với tổ chức mẹ (tổ chức truyềnthống)

 Trong một số tổ chức, cấu trúc dự án thuần tuý có thể bao gồmnhững hệ thống tự hỗ trợ, chẳng hạn như một phòng nhân sựhay phòng thu mua riêng Trong các tổ chức khác, cấu trúc dự

án thuần tuý lại chia sẻ hệ thống hỗ trợ này với tổ chức mẹ

Bảng 2 Các dạng tổ chức nhân lực 2.1.2 Chức năng cơ bản trong các cấu trúc tổ chức: [2]

Chức năng cơ bản là chức năng của giám đốc dự án thông qua dự án đó Trong một cấutrúc chức năng thuần tuý thì chức năng của giám đốc dự án tuơng đối thấp so với giámđốc chức năng trong khi ở một cấu trúc theo dự án thì hoàn toàn ngược lại.

Hình 10 Chức năng cơ bản trong các cấu trúc tổ chức 2.1.3 Biểu đồ tổ chức: [2]

Biểu đồ tổ chức minh hoạ cấu trúc tổ chức của dự án Mục đích của nó là chỉ ra cảmối quan hệ chỉ đạo, quản lý và báo cáo trong dự án và mối quan hệ của dự ánđối với tổ chức mẹ

Một vài tổ chức sử dụng một cấu trúc tổ chức phân cấp chi tiết (OBS) để minhhoạ tổ chức theo chức năng chịu trách nhiệm đối với các dạng công việc khácnhau trong dự án Công bố cấu trúc OBS sớm trong dự án là rất có lợi Thứ nhấtOBS chưa phù hợp sẽ làm xuất hiện những mâu thuẫn hay lầm lẫn về những vaitrò trong dự án, và thứ hai tạo động lực thúc đẩy tinh thần trách nhiệm của cácthành viên dự án khi OBS phù hợp

Ví dụ: Hình sau là sơ đồ tổ chức một công ty điển hình được tổ chức theo một cấutrúc dự án ma trận Hãy chú ý cách thức mà đội ngũ thành viên báo cáo theo cảchiều dọc đối với giám đốc chức năng và chiều ngang đối với giám đốc dự án

Hình 11 Sơ đồ tổ chức theo cấu trúc dự án ma trận 2.1.4 Các đối tượng liêu quan dự án: [2]

Các đối tượng liên quan dự án là người:

 Có lợi ích nghiệp vụ trong kết quả của dự án

 Liên quan trực tiếp tới dự án

 Hoặc đóng góp các nguồn lực cho dự án

Ví dụ: Bảng sau liệt kê một vài ví dụ về các đối tượng liên quan dự án trong các

dự án điển hình

Các đối tượng

liên quan dự án Đặc điểm

Nhà tài trợ  Chịu trách nhiệm cuối cùng đối với sự thành công của dự án

 Ký kết hoàn tất các tài liệu lập kế hoạch và các yêu cầu thayđổi

 Cho phép đội dự án sử dụng các nguồn lực

 Bảo vệ và cố vấn cho đội quản lý dự án

 Cắt băng khởi công, cũng như khánh thành dự án và và tiếnhành hoạt động

 Ký và công bố tôn chỉ dự án

 Nếu nhà tài trợ không phải là người trong công ty, chẳng hạnnhư là một khách hàng thì trách nhiệm của giám đốc dự án

bao gồm một số trách nhiệm khác được liệt kê dưới đây.

Khách hàng  Nhận đầu ra dự án

 Thanh toán cho đầu ra dự án

 Xác định nhu cầu đối với sản phẩm kết quả của dự án

 Có thể là nhiều công ty hay cá nhân với những đặc điểm và yêucầu trái ngược nhau

Giám đốcchức năng

 Các nhà quản lý chịu ảnh hưởng bởi hoạt động hay kết quả của

dự án

 Kiểm soát và các đóng góp nguồn lực cho dự án (con người,trang thiết bị…)

 Có thể có những yêu cầu trái ngược nhau về kết quả dự án

 Có thể tính đến cả cấp trên của Giám đốc dự án Giám đốc dự án  Làm việc với các đối tượng liên quan dự án để định nghĩa dự

án

 Lập kế hoạch, sắp xếp lịch trình và dự thảo ngân sách các hoạtđộng của dự án với đội ngũ ban đầu

 Cùng làm việc với đội để thực thi kế hoạch

 Giám sát hiệu quả hoạt động và thực hiện các hoạt động hiệuchỉnh

 Thường xuyên báo báo cho các nhà tài trợ và các đối tượngliên quan dự án

 Đưa ra yêu cầu và trình bày những thay đổi về phạm vi

 Đóng vai trò như một người trung gian giữa đội dự án và cácđối tượng liên quan dự án khác

Đội ngũ thành viên dự án

 Phân công dựa trên năng lực điều chỉnh, kỹ năng theo các hoạtđộng của dự án cụ thể của họ

 Có thể tính đến các tài nguyên bên trong và bên ngoài

 Tiếp xúc với nhà tài trợ và các đối tượng liên quan đến dự ánkhác thông qua Giám đốc dự án

Bảng 3 Các đối tượng liên quan dự án trong các dự án điển hình 2.2 Chi phí: [2]

 Những dự án về CNTT thường có hồ sơ theo dõi kém hiệu quả cho việc đạt được mụcđích về giá cả

 Chi phí trung bình vượt quá dự toán ban đầu theo nghiên cứu từ năm 1995 củaCHAOS là 189%; đã được cải thiện 145% trong nghiên cứu năm 2001

 Ở Mỹ các dự án CNTT bị huỷ làm tốn trên 81 tỉ đô la năm 1995

 Chi phí là tài nguyên được đem vào sử dụng, tiêu hao, kết chuyển giá trị vào sản phẩmmong đợi Chi phí cần được tính toán trước để đạt được một mục tiêu rõ ràng hay đểtrao đổi cái gì đó Chi phí thường được đo bằng đơn vị tiền tệ

 Quản lý chi phí dự án bao gồm những quy trình yêu cầu đảm bảo cho dự án đượchoàn tất trong sự cho phép của ngân sách

 Quản lý Chi phí dự án gồm những qui trình bảo đảm cho dự án được hoàn tất trong sựcho phép của ngân sách Những qui trình này gồm:

+ Lập kế hoạch cho nguồn tài nguyên: xác định nguồn tài nguyên cần thiết và số lượng

để thực hiện dự án

+ Ước lượng chi phí: ước tính chi phí về các nguồn tài nguyên để hoàn tất một dự án + Dự toán chi phí: phân bổ toàn bộ chi phí ước tính vào từng hạng mục công việc đểthiết lập một đường mức (Base line) cho việc đo lường việc thực hiện

+ Kiểm soát – Điều chỉnh chi phí: điều chỉnh thay đổi Chi phí dự án

2.2.1 Lập kế hoạch về nguồn tài nguyên: [2]

Lập kế hoạch cho ngân sách phụ thuộc vào bản chất của dự án và tổ chức, sau đây

là một số câu hỏi cần cân nhắc:

 Các khó khăn nào sẽ gặp khi thực hiện các công việc cụ thể trong dự án?

 Có phạm vi nhất định nào ảnh hưởng đến nguồn tài nguyên?

 Tổ chức đã thực hiện những công việc nào tương tự như dự án?

 Tổ chức đó có đủ người, trang thiết bị và vật tư để thực hiện dự án?

Tưởng tượng ràng bạn muốn xây dựng thêm một tầng cho ngôi nhà của bạn Bạn

đã dự tính kinh phí 2.000 đôla cho dự án nhưng bạn biết rằng nhà thầu sẽ đòi trảgấp đôi để hoàn tất công việc Do đó bạn tự mình làm việc vào ngày nghỉ cuốituần, kéo dài toàn bộ dự án suốt mùa hè Trong việc lập kế hoạch này, bạn đangđưa ra nhiều giả định: rằng bạn sẽ từ bỏ mọi kỳ nghỉ cuối tuần để làm việc trên

tầng, rằng thời tiết sẽ hợp tác và rằng bạn không muốn mất đi lợi ích trong dự án.

Nhiều dự án công nghệ thông tin sử dụng phương pháp chứa đầy những giả định

tương tự cho nguồn lực và chi phí Các giả định không hoàn thiện là cơ sở gây ra

thảm họa cho nhiều dự án

2.2.1.1 Nguyên tắc ước lượng chi phí: [2]

Đánh giá các tài liệu yêu cầu với con mắt phê bình về những sai lầm và bỏ sót:

 Các yêu cầu nghiệp vụ có rõ ràng và cụ thể không?

 Các yêu cầu chức năng có hỗ trợ các yêu cầu nghiệp vụ không?

 Quan trọng nhất là các yêu cầu kỹ thuật có được phác thảo rõ ràng và đầy đủ không?

 Đảm bảo rằng bạn hiểu đầy đủ về mục đích của ước tính và đang dùng kỹ thuật ướclượng đúng hay không?

 Ước tính sẽ được dùng để đánh giá tiềm lực dự án hay quản lý dự án hay không?

Không sử dụng ước lượng trên xuống nếu dự án chưa từng được thực hiện trước đây.Đảm bảo rằng ước lượng chính quy của bạn có các thành phần chính sau:

 Danh sách các giả định dùng trong xây dựng ước lượng

 Phạm vi biến động cho ước lượng đề ra

 Giai đoạn thời gian dự án có hiệu lực

Đảm bảo rằng thời hạn ước tính của tất cả các dự án theo nguồn lực được chuyên gia vềnội dung chuyên ngành xét duyệt cẩn thận Chuyên gia về nội dung chuyên ngành hiểu cácyêu cầu nguồn lực và các kỹ thuật liên quan tới việc thực hiện hoạt động thực sự:

 Bạn có biết những nhiệm vụ nào là theo năng lực không?

 Bạn có biết kỹ năng nào cần để thực hiện công việc không?

 Đảm bảo rằng nỗ lực cần đến được trình bày bằng các thuật ngữ cụ thể:

 Trình bày ước tính bằng đơn vị đo lường phù hợp với những thứ đã được theo dõi

về phương diện lịch sử

 Đừng quên tính cả chi phí nguồn lực bên trong quá trình tính toán toàn bộ nỗ lực

Đảm bảo rằng cơ sở vật chất, nguyên vật liệu cần đến được trình bày bằng các thuậtngữ, trong đó sức mua sẽ được hiểu là:

 Lập chi phí theo đơn giá, định mức hoặc giá thị trường theo cách tính trên đơn vị tínhcủa nguyên vật liệu, cơ sở vật chất

 Lập hoá đơn, chứng từ nguyên vật liệu cho dự án

 Đảm bảo rằng yêu cầu cơ sở vật chất, nguyên vật liệu được trình bày bằng thuật ngữtài chính

Ví dụ:

Hoàn tất việc ước lượng thời gian cho dự án tự động hoá lưc lượng bán hàng quy mô lớn.Amy đang trong quá trình thông qua các ước tính chi phí Ước tính ban đầu do nhà thầutiềm năng cung cấp cho biêt rằng dự án sẽ chi phí 1,5 triệu USD Do không ai trong vănphòng quản lý dự án có bất kỳ kinh nghiệm gì với loại nỗ lực này nên chuyên gia về nộidung chuyên ngành đã được đưa đến để đánh giá công việc liên quan trong dự án này.Các con số chi phí do nhà cung cấp đưa ra dựa vào một số dự án đã được hoàn tất vàchuyên gia về nội dung chuyên ngành thấy các con số là chính xác Tuy nhiên ước tínhchi phí cơ sở vật chất và nỗ lực được mong đợi mà công ty mong muốn đóng góp cho dự

án Sau khi hoàn tất xét duyệt cẩn thận, Amy đã cung cấp cho nhà tài trợ của mình ướclượng sửa lại 4,0 triệu USD Ước lượng này tính đến tất cả các chi phí kết hợp với nỗ lực,nguyên vật liệu, cơ sở vật chất được cung cấp bởi nhà cung cấp và công ty cần để hoàntất dự án

2.2.1.2 Chi phí nguyên vật liệu: [2]

Chi phí nguyên vật liệu là loại chi phí dùng để chi tất cả các thành phần, bộ phận vànguồn cung cấp hoặc được dùng trong các dự án hoặc trở thành bộ phận của các phần cóthể chuyển giao Các công cụ được dùng để thực hiện công việc không phải là nguyên vậtliệu nếu chúng không trở thành bộ phận của các phần có thể chuyển giao

Ví dụ:

Các máy tính để bàn, máy dịch vụ, máy chủ truy cập và sợi cáp quang sẽ là nguyên vậtliệu dùng trong các dự án nâng cấp mạng Mã bản quyền và phần mềm có thể là nguyênvật liệu trong nhiều dự án công nghệ thông tin Tuy nhiên quan trọng là phải nhớ rằng mãbản quyền cho phần mềm dùng để thực hiện công việc không được xem là nguyên vậtliệu trừ khi chúng được chuyển giao tại thời điểm hoàn tất dự án

2.2.1.3 Chi phí cơ sở vật chất: [2]

Chi phí cơ sở vật chất là loại chi phí dùng để chỉ các công cụ, thiết bị vật chất hay cơ sở

hạ tầng dùng trong suốt dự án không trở thành bộ phận của các phần có thể chuyển giao.Trong nhiều tổ chức, mục này đơn thuần được xem như tổng chi phí hay chi phí cố định

Ví dụ:

Đội dự án đang tiến hành phát triển ứng dụng thương mại mới cần có không gian, bànlàm việc, máy tính để bàn, máy dịch vụ, mạng LAN/WAN và nguồn điện cần để chạymọi thứ Các công cụ phát triển phần mềm dùng để tạo ra môi trường chạy các dịch vụdùng để kiêmt tra cũng sẽ được xem như phần chi phí cơ sở vật chất

2.2.2 Ước tính chi phí: [2]

Đầu ra quan trọng của quản lý chi phí dự án là ước tính chi phí Có nhiều loại phươngpháp ước tính chi phí và theo đó có những công cụ kỹ thuật giúp tính toán Điều quantrọng là phát triển một kế hoạch quản lý chi phí trong đó mô tả sự dao động chi phí sẽđược quản lý trong dự án ra sao Tuy nhiên, một giám đốc dự án kỳ cựu một lần đã nóiđùa: “Sự khác nhau giữa ước tính và ước đoán tuyệt đối là gì?” Ước tính thường được sửdụng khi chưa xác định rõ yêu cầu về đối tượng, môi trường và chất lượng nên quá trìnhước tính được thực hiện ở các giai đoạn đầu của dự án – thuật ngữ chuyên ngành tàichính gọi là “tiền kiểm”, cơ sở đưa ra con số gần đúng

 Liệt kê các phương pháp ước lượng:

 Ước lượng chính quy

 Ước tính sử dụng kết quả chào thầu

 Thông tin lịch sử hay cơ sở dữ liệu dự án

 Ước lượng theo giai đoạn

 Ước lượng theo tham số

 Ước lượng dưới lên

 Ước lượng trên xuống

2.2.2.1 Ước lượng chính quy: [2]

Ước lượng chính quy được dùng để chỉ ước lượng gần đúng Trên thực tế chúngthường tốt hơn chút so với một ước đoán không rõ ràng Phương pháp không được

chuẩn bị trước này tạo ra kỳ vọng rằng một điều gì đó có thể được thực hiện với mộtloạt nguồn lực cụ thể và trong một lượng thời gian đã định

Ước lượng chính quy và không chính quy là các công cụ ta dùng để dự đoán thờigian và nguồn lực cần thiết để thực hiện một dự án cụ thể Ước lượng chính quy dựatrên sự phân tích Trong một thế giới lý tưởng, phân tích này sẽ được tiến hành theochiều sâu Ít nhất là một phân tích mở đầu phải được tiến hành Một ước lượng gồm có

3 thành phần chính:

 Danh sách các giả định được sử dụng trong việc xây dựng ước lượng (Ví dụ nhưcác chi phí đầu vào về lao động và nguyên vật liệu)

 Phạm vi biến động cho ước lượng được đưa ra (Ví dụ +/- 50%)

 Khoảng thời gian ước lượng có hiệu lực (Ví dụ như ước lượng này có hiệu lựctrong vòng 60 ngày)

Ngược lại, ước lượng không chính quy là ước đoán dựa trên sự suy đoán, phỏngđoán và bản năng

2.2.2.2 Ước tính sử dụng kết quả chào thầu: [2]

Ước tính là một tài liệu dự án dùng để dự đoán bao nhiêu thời gian và tổng sốnguồn lực mà dự án cần đến Chào thầu là một tài liệu thương mại ghi rõ thời gian vàtiền bạc cần để hoàn tất công việc dự án trong đó có lãi ròng cho dự án Chào thầu cóthể kết hợp chặt chẽ các ước tính từ các một số nhà thầu phụ

Độc giả dự kiến đưa ra sự khác biệt quan trọng giữa chào thầu và ước tính Chàothầu hầu như định hướng về khách hàng và nhà tài trợ và có sự tăng giá đồng thời trong

đó có tính đến lãi ròng cho dự án, trong khi đó ước tính thường được dùng bên tronghoặc giữa các nhà thầu phụ với mục đích thể hiện chi phí thực

Như một quy tắc chung, các giám đốc dự án công nghệ thông tin không xây dựngchào thầu phê chuẩn mà pháp luật về đấu thầu hiện hành quy định bởi vì các nhà tài trợkhông trả bất kỳ lãi ròng hay tăng giá nào cho việc sử dụng các nguồn lực bên trong.Tuy nhiên nhiều bộ phận công nghệ thông tin hoạt động trong hệ thống khách hàng từchối thanh toán, nhưng họ không cho phép tăng giá dịch vụ của mình Kết quả là tài liệu

họ cung cấp cho khách hàng của mình có chức năng giống như chào thầu nhưng chỉ thể

hiện những chi phí mà họ cho phép sửa lại Nhiều khi các tài liệu này là trình tự côngviệc giữa các bộ phận thay vì các ước tính và chào thầu.

2.2.2.3 Thông tin lịch sử hay cơ sở dữ liệu dự án: [2]

Nếu một dự án đã được thực hiện trước đây thì giám đốc dự án có thể thu đượcnhiều kiến thức về tài liệu và dữ liệu liên quan tới dự án Rõ ràng là mức độ thông tin cóthể dùng trực tiếp sẽ phụ thuộc vào điểm tương đồng của hai dự án đang được giảiquyết

Thông tin lịch sử là các dữ liệu hay tài liệu có thể tồn tại từ dự án trước tương tựnhư dự án hiện tại Về lý tưởng thì thông tin này bao gồm các mục sau:

 Báo cáo sự cố

 Yêu cầu kỹ thuật, chức năng và nghiệp vụ

 Ước tính lịch trình và chi phí chi tiết

 Kinh phí dự án

 Cấu trúc chi tiết công việc

 Chi phí thực và dữ liệu hiệu suất theo lịch trình, tốt nhất là ở mức gói công việc

 Bài học thu được

Thông tin tương tự là dữ liệu từ tình huống khác rất giống nhưng không y hệt như

các tình trạng trước mắt Nếu tình huống giống hệt thì khi đó thông tin được xem như

là mang tính lịch sử Thông tin tương tự xuất phát từ thành phần của các dự án kháctương tự như các thành phần của dự án mới Thông tin tương tự cũng có thể xuất phát từkinh nghiệm điều hành

2.2.2.4 Ước lượng theo giai đoạn: [2]

Ước lượng các dự án công nghệ thông tin thường đưa ra một nghịch lý Các số liệuthống kê của ngành chỉ ra rằng một dự án công nghệ thông tin bất kỳ với hơn 6 triệuđôla có khoảng 10% cơ hội hoàn tất đúng thời điểm và đúng kinh phí (Gartner 2000,107) Phản ứng của quản lý cao cấp đối với tình huống này là yêu cầu giải trình tráchnhiệm lớn hơn và các chỉ dụ được đưa ra cho ước tính cứng rắn càng sớm càng tốt trongquy trình của dự án Thực tế thì phương pháp có vẻ hợp lý này lại làm cho mọi thứ xấu

đi nhiều Hãy nhớ rằng phần lớn các dự án công nghệ thông tin chưa từng được thực