Quản trị dự án là một quá trình hoạch định, tổ chức và quản lý các công việc và tài nguyên nhằm thỏa mãn các mục tiệu đã định sẵn với những hạn chế về thời gian, tài nguyên và chi phí Qu
Trang 1-
LUẬN VĂN THẠC SĨ KHOA HỌC
CÁC KỸ THUẬT ỨNG DỤNG TRONG QUẢN TRỊ DỰ
Trang 2DANH M ỤC Danh mục các từ viết tắt sử dụng trong luận văn
CMM Capability Maturity Model
CNTT Công nghệ thông tin
CPM Critical Path Method Phương pháp đường găng ISO International Standards
Organization Tổ chức tiêu chuẩn quốc tế
FS Functionnal Specification Quy định chức năng
PERT Program evaluation and review
technique
Kỹ thuật xem xét và đánh đánh giá chương trình UML Unified Modeling Language Ngôn ngữ mô hình hóa thống
nhất WBS Work Breakdown Structure Cấu trúc phân việc dự án
Danh mục các hình sử dụng trong luận văn
Hình 1.1: Công thức cho việc quản lý dự án hiệu quả
Hình 1.2: Tiến trình quản lý dự án
Hình 2.1 Mạng nhiệm vụ và cơ chế song song
Hình 2.2: Phân bố nỗ lực
Hình 2.3 Rủi ro và mối quan tâm quản lý
Hình 2.4 Mức tham khảo rủi ro
Hình 2.5: Mô hình điều phối rủi ro
Hình 3.1 Mô hình phân tán phát triển phần mềm
Hình 3.2 Quy trình quản trị rủi ro, dựa trên mô hình CMMI
Hình 3.3 Tích hợp quy trình
Trang 3Hình 3.4 Sơ đồ trường hợp sử dụng tích hợp hai quy trình
Hình 3.5 Sơ đồ hoạt động tích hợp hai quy trình
Hình 3.6 Các trục của quản trị rủi ro toàn diện
Hình 4.1: Sơ đồ tiến trình quản lý dự án
Hình 4.2 Tiến trình phân tích và điều phối rủi ro
Hình 4.3 Mô hình tổ chức quản lý tiến trình dự án
Danh mục các bảng biểu sử dụng trong luận văn
Bảng 1.1: Bẩy giai đoạn của dự án CNTT
Bảng 2.1 Nhật kí kiểm soát rủi ro
Bảng 2.2: Danh sách kiểm đánh giá rủi ro
Bảng 4.1 Mẫu quản lý nhân lực
Bảng 4.2 Theo dõi tiến độ và điều phối rủi ro
Bảng 4.3 Quản lý tiến trình và rủi ro
Trang 4MỞ ĐẦU
Sau khi tốt nghiệp trường Đại học Bách Khoa Hà Nội, như bao tân kỹ
sư khác, tôi bắt đầu chạy theo những dự án tin học Tuy nhiên những dự án tôi tham gia hay trực tiếp quản lý thường xẩy ra những tình trạng khác nhau như chậm tiến độ hợp đồng, công nghệ lỗi thời hay trầm trọng hơn sai nghiệp vụ dẫn đến những hậu quả nghiêm trọng như tổn thất kinh tế, thời gian, nhân lực…
Chính vì lý do này nên tôi muốn nghiên cứu và tìm hiểu tại sao và làm thế nào để khắc phục những tình trạng đó nhằm có những thành công trong
việc làm dự án Qua tìm hiểu tôi nhận thấy để có được sự thành công đó điều cần thiết phải quản trị dự án tốt, phân tích, khuyến cáo và có những biện pháp phòng ngừa mọi biến cố đe dọa sự thành công trong khi thực hiện dự án
Trong luận văn này tôi tập trung tìm hiểu và đưa ra một vài biện pháp phòng ngừa và khắc phục rủi ro trong quản trị dự án bởi rủi ro là một đặc thù
nhạy cảm không thể dự đoán trước và mọi rủi ro xảy ra đều có thể gây cho dự
án phần mềm thất bại Hơn nữa quản trị rủi ro tốt sẽ đem lại cho chúng ta những lợi ích về mặt tài chính vượt xa chi phí bỏ ra
Trước khi đi vào phần trình bầy tôi muốn gửi lời cảm ơn chân thành đến thấy giáo TS Huỳnh Quyết Thắng đã tận tình hướng dẫn tôi, cảm ơn Công ty Cổ phần Hỗ trợ Phát triển Tin học HiPT đã tạo điều kiện cho tôi hoàn thiện Luận văn này
Trang 5CHƯƠNG 1 TỔNG QUAN VỀ QUẢN LÝ DỰ ÁN
1.1 Sự cần thiết phải quản lý dự án
Muốn biết tại sao lại cần thiết phải quản trị dự án CNTT, thì trước hết chúng ta cần nắm đuợc một số định nghĩa và đặc điểm sau [1]:
• Một dự án là một tổ chức tạm thời được dẫn dắt bởi một nguời quản trị
để đáp ứng các yêu cầu về chức năng, chất lượng, thời hạn và chi phí
đã đuợc xác định
• Một dự án CNTT là một dự án trong đó có phát triển phần mềm
• Quản trị dự án CNTT là một tập các hoạt động để đạt đuợc mục đích đã đặt ra đối với dự án CNTT đồng thời thoả mãn các điều kiện đòi hỏi về
chất luợng, thời hạn và giá thành
• Phần mềm đuợc phát triển bởi trí tuệ con nguời
• Vấn đề làm việc tập thể là vô cùng quan trọng
Từ những đặc điểm trên ta có thể thấy rõ các khó khăn sẽ gặp phải khi thực hiện một dự án CNTT Tổ chức dự án CNTT là một tổ chức tạm thời, trong nội tại của nó đã có các tiềm năng gây mất ổn định Trong quá trình thực thi
dự án rất có thể xảy ra việc thành viên đội dự án muốn bỏ việc vì vấn đề lương bổng không thoả đáng, vì vấn đề quan hệ giữa các thành viên trong dự
án, vì không thích công việc khi đó thì chúng ta sẽ phải giải quyết như thế nào?
Thời hạn đặt ra cho dự án thường bị quá hạn, ngân sách thường bị vượt, chất lượng thì không thể chắc chắn vì có sự phát triển phần mềm trong đó, và
Trang 6không ai có thể đánh giá đuợc chất luợng của phần mềm khi đang phát triển
nó
Chính vì vậy mà chúng ta cần phải quản trị dự án, cho dù chúng ta có rất nhiều kinh nghiệm thì vẫn cứ phải cẩn thận vì chẳng có dự án nào giống dự án nào bởi vì không ai có thể lường truớc các diễn biến trong quá trình thực hiện
dự án
Liệu quản trị dự án có giải quyết đuợc tất cả các vấn đề sẽ xảy ra trong khi
thực hiện dự án không? Rất tiếc câu trả lời là KHÔNG Tuy nhiên quản trị dự
án sẽ giúp chúng ta dự phòng đuợc các vấn đề có thể làm dự án của chúng ta thất bại
1.2 Định nghĩa dự án và quản lý dự án
Quản trị dự án là một hoạt động quản trị, nó bao gồm quá trình hình thành, triển khai và kết thúc dự án, trong một môi trường hoạt đông nhất định, với không gian và thời gian xác định
Quản trị dự án là một quá trình hoạch định, tổ chức và quản lý các công việc và tài nguyên nhằm thỏa mãn các mục tiệu đã định sẵn với những hạn chế về thời gian, tài nguyên và chi phí
Quản trị dự án được thực hiện bởi người quản lý dự án (Project Manager) trong một doanh nghiệp hay một tổ chức
Nội dung của quản trị dự án bao gồm các phần chính sau [1]:
• Quản trị thời gian
• Quản trị chi phí
• Quản trị rủi ro
• Quản trị tài nguyên
Khi chúng ta nói đến quản lý dự án là ta đã mặc nhiên là dự án này đã
Trang 7được chấp thuận Việc quản lý dự án bao gồm 3 bước chính như sau:
1 Xây dựng một kế hoạch
2 Theo dõi và quản lý dự án
3 Đóng một dự án
1.3 Chìa khóa của thành công
Bất kể tới ngành công nghiệp hay vị trí bên trong công ty, tất cả mọi người quản lý dự án đều thực hiện sáu chức năng cơ bản, với các mức thành công khác nhau: Lãnh đạo, xác định, lập kế hoạch, tổ chức, kiểm soát và kết thúc [1]
Như hình 1.1 nêu ra, việc quản lý dự án có hiệu quả bao gồm một phổ rộng các hoạt động Chúng ta cần xác định các mục đích và mục tiêu quản lý
dự án, nhận đuợc sự hỗ trợ của cấp quản lý, nhận diện tất cả các nhiệm vụ để xây dựng sản phẩm, tập hợp tổ, xây dựng công cụ hành chính tốt, ước lượng thời gian để thực hiện từng nhiệm vụ và toàn bộ dự án, phân bổ ngân quĩ và tài nguyên có sẵn, thiết lập các mức độ chấp nhận được về chất lượng, thu các
kỹ năng quản lý và kỹ thuật cần thiết, kết thúc dự án một cách có hiệu lực, và động viên mọi người qua toàn bộ dự án
Những nhiệm vụ này có thể thực hiện theo cách có trật tự Như hình 1.2 minh họa, chúng ta có thể thực hiến chúng theo trình tự logic để thực hiện các công cụ và kỹ thuật của việc quản lý dự án
Chúng ta có thể dùng sơ đồ này để giúp việc quản lý dự án thành thực
tế cho dự án của chúng ta
Trang 8Quản lý dự
án hiệu quả = Phát biểu về công việc
Cấu trúc phân việc
Tổ dự án Công bố dự án
Hoạt động hành chínhƯớc lượng thời gianNgân sách
Chuẩn chất lượng
Kỹ năng quản lý
Động viênKết thúc dự ánTài liệu dự án
Hình 1.1: Công thức cho việc quản lý dự án hiệu quả Chỉ chúng ta mới có thể ra những quyết định này Bao giờ cũng vậy nguời quản lý dự án phải quyết định mức độ kỹ luật dự án cần thực hiện Đó
là cách nó phải như vậy nữa Người quản trị biết dự án rõ hơn bất kỳ ai khác
và vai trò chủ chốt trong kết quả của nó Bên cạnh đó, chúng ta được chọn là người quản lý dự án bởi chúng đã chứng tỏ có khả năng đưa ra những đánh giá đúng Có khả năng chọn công cụ, kỹ thuật và tài nguyên để thực hiện và biết thực hiện sáu chức năng cơ bản tới mức độ nào là tất cả những gì cần để
là người quản lý dự án hiệu quả Trách nhiệm tất cả là ở người quản trị
Trang 9Quyền lãnh đạo
Tạo ra công bố dự án
Lê n ngân sách
Xác định cách quay trở lại
Thực hiện sửa đổi
Xác định sửa đổi cần thiết
Lập kế hoạch lại?
Ước lượng Lên lịch
án vào
Thực hiện phân bố tài nguyên
Trang 10Trong giai đoạn lập kế hoạch dự án, đối với những dự án có một một thời gian dài hoặc có liên quan đến nhiều người, thì việc quan trọng là phải xác định những mục tiêu, các giả thuyết, và những sự ràng buộc của dự án Khởi động một tập tin dự án
Sau việc đặt kế hoạch ban đầu, chúng ta có thể khởi động tập tin dự án của chúng ta, đưa dữ liệu vào dự án sơ bộ của chúng ta, và gắn việc lập kế hoạch những tài liệu của chúng ta tới tập tin
Trình bày tổ chức của dự án
Sau khi chúng ta có phác thảo những công việc, chúng ta có thể cũng cho thấy rằng cấu trúc dự án của chúng ta sử dụng gắn sẵn hoặc tùy biến làm việc là những mã cấu trúc (WBS) sự cố hoặc phác thảo những mã
Những mã này có thể sử dụng để tổ chức danh sách công việc của chúng ta dựa vào một sự đa dạng của việc đánh lừa những hệ thống, như những mã kế toán hoặc cấu trúc sự cố tổ chức của chúng ta
Tổ chức một dự án vào trong những một tập tin dự án con và dự án chủ
Đặt ra những công việc phụ thuộc và những sự ràng buộc
Sau khi xác định những khoảng thời gian công việc, sẽ là lúc xác định những công việc đó được liên quan đến lẫn nhau như thế nào và xác định những ngày tháng của các công việc
Trang 11Tạo ra những sự quan hệ lẫn nhau giữa những dự án
Chúng ta có thể tạo ra những phần phụ thuộc công việc giữa những công việc trong những dự án khác nhau.Tạo ra những phần phụ thuộc giữa những mô hình dự án chính xác những sự quan hệ lẫn nhau giữa những dự án khác nhau và giúp để dự án đúng lịch trình
Ước tính các tài nguyên cần thiết
Trong quá trình lập kế hoạch dự án, cần xác định tầm nhìn dự án, thiết lập danh sách công việc, và đánh chi phí những khoảng thời gian công việc Chúng ta có thể bây giờ sử dụng thông tin này để đánh giá sơ bộ, xác định những yêu cầu, và bắt đầu bố trí cán bộ và quá trình tìm kiếm để đạt những tài nguyên đủ để thực hiện những công việc dự án
Nhập thông tin về tài nguyên và xác định thời gian làm việc
Ở thời điểm này trong lập kế hoạch quá trình dự án, tất cả các tài nguyên đã được xác định, phê duyệt, và được tìm kiếm
Chúng ta biết ai sẽ thuộc về đội của Chúng ta, và thiết bị nào và nguyên liệu mà Chúng ta đang thu nhận để hoàn thành những mục đích dự án
Chia sẻ những tài nguyên giữa những dự án
Việc chia sẻ những tài nguyên hữu ích để quản lý thông tin và những
sự ấn định tài nguyên qua nhiều dự án trong đó những cùng người đó, nguyên liệu, hoặc thiết bị sẽ được sử dụng
Gán những tài nguyên cho những công việc
Bây giờ thông tin tài nguyên đó đã được đưa vào trong dự án, chúng ta
có thể gán những tài nguyên cho những công việc đặc biệt mà chúng ta thiết lập như công việc của dự án
Đánh giá những chi phí
Trang 12Đánh giá chi phí là quá trình phát triển tài nguyên và / hoặc những Giá công việc xấp xỉ cần hoàn thành những hoạt động dự án
Định nghĩa và chia sẻ thông tin chi phí
Khi tất cả các chi phí được nhập vào, chúng ta có thể muốn cất giữ chúng như dự thảo ngân sách trước khi khởi động theo dõi và quản lý kế hoạch của chúng ta Chia sẻ thông tin ngân quỹ với những người khác, hoặc chuyển nó tới những lịch trình khác, như một hệ thống tài chính mà công ty của chúng ta có thể đang sử dụng
Chuẩn bị quản lý những chi phí
Sau thiết lập những chi phí, chúng ta có thể chuẩn bị mọi thứ cần thiết cho sự theo dõi và quản lý chúng để bảo đảm dự án còn ở bên trong ngân quỹ Chúng ta có thể chỉ rõ ngày tháng bắt đầu, năm tài chính, điều khiển những tùy chọn tính toán, và xác định khi những chi phí cần phải trả Kế hoạch cho chất lượng và những rủi ro
Tối ưu hóa một kế hoạch dự án
Sau việc xây dựng kế hoạch dự án cần tổng quan về thời điểm hoạch định kết thúc, xem lại sự phân phối những tài nguyên, tổng quan việc lập kế hoạch những chi phí
Phân phối một kế hoạch dự án
Sau khi dự án của chúng ta đã được hoạch định, chúng ta có thể muốn phân phối thông tin dự án hiện thời nhất tới những người khác, như những người có liên quan hoặc những thành viên đội
1.4.2 Theo dõi và quản lý dự án
+ Quản lý một lịch trình
Xác định những vấn đề lịch trình
Trang 13Sau khi dự án bắt đầu và chúng ta đang theo dõi sự tiến độ thực tế của những công việc, chúng ta có thể xem lại lịch trình để xác định những khó khăn hoặc những khó khăn tiềm tàng với những lịch trình công việc
Đặt những công việc, những giai đoạn, hoặc dự án trên lịch trình
Sau chúng ta có xác định những khó khăn trong lịch trình, chúng ta có thể sử dụng một sự đa dạng của những chiến lược để quản lý lịch trình dự án Phân phối thông tin dự án trực tuyến
Nếu chúng ta đã thay đổi những công việc, những tài nguyên, hoặc những sự ấn định, thì chúng ta có thể phân phối thông tin dự án hiện thời nhất tới những người khác có liên quan hoặc những thành viên trong đội
+ Quản lý những tài nguyên
Theo dõi tiến trình tài nguyên
Cách có hiệu quả nhất để đánh giá sự tiến độ sử dụng những tài nguyên của công việc của một dự án là cân bằng công việc và theo dõi tiến triển trên những công việc
Xác định những vấn đề phân bố nguồn tài nguyên
Bởi việc xem lại những thông tin tài nguyên, sự quá tải hoặc không đủ tải, những chi phí tài nguyên, và những sự mâu thuẫn giữa công việc trong việc lập kế hoạch và công việc thực tế, chúng ta có thể kiểm tra những tài nguyên được sử dụng cho những công việc một cách tối ưu để có những kết quả mong muốn
Giải quyết những vấn đề phân bố nguồn tài nguyên
Để có những kết quả tốt nhất từ những tài nguyên, chúng ta cần quản lý tải công việc sao cho không xảy ra việc quá tải hoặc không đủ tải Nếu chúng
ta thay đổi sự quyết định tài nguyên, hãy kiểm tra những hiệu ứng của những
Trang 14sự thay đổi trên lịch trình toàn bộ để chắc chắn đạt mục đích của dự án
Quản lý những tài nguyên dùng chung
Sau khi có thiết lập tài nguyên chia sẻ giữa những tập tin dự án với toàn
bộ tài nguyên khác, cập nhật và xem lại thông tin tài nguyên dùng chung, như các thông tin về chia sẻ các tài nguyên, thực tế công việc, và những sự quyết định
+ Quản lý những chi phí
Xác định những vấn đề chi phí và điều chỉnh dự án trong ngân quỹ
Để giữ những chi phí nằm bên trong ngân quỹ, chúng ta sẽ muốn xác định những vấn đề chi phí bằng cách xem tổng chi phí và những sự mâu thuẫn
về chi phí để có sự điều chỉnh cần thiết và đúng đắn
+ Quản lý phạm vi
Thích ứng với thay đổi trong tầm nhìn
Đây là việc xảy ra trong thực tế sau khi dự án bắt đầu, chúng ta có thể cần tăng thêm tầm nhìn, phán đoán xu hướng của dự án
Phân phối thông tin dự án trực tuyến
Nếu chúng ta đã thay đổi những công việc, những tài nguyên, hoặc những quyết định, thì chúng ta cần phân phối thông tin dự án hiện thời nhất tới những thành viên khác liên quan cũng như những thành viên trong đội
Trang 15Nếu chúng ta xác định mới những rủi ro mà đã xuất hiện trong thời gian dự án, chúng ta cần thích ứng với những rủi ro đó Chúng ta sẽ phải xác định và chuẩn bị những kế hoạch để phòng ngừa với những rủi ro sẽ đe dọa chậm trễ công việc, giai đoạn, hoặc lập dự án cho những ngày tháng kết thúc; tăng thêm ngân quỹ; chôn vùi những tài nguyên
+ Báo cáo tình trạng dự án
Trong khi dự án đang tiến triển, chúng ta phải luôn luôn báo cáo tình trạng hiện thời của dự án với những thành viên liên quan như cấp trên hay những người trong đội
1.4.3 Đóng một Dự án
Xem lại thông tin chung về toàn bộ dự án
Kết thúc một dự án là một cơ hội để thu nhặt kinh nghiệm và ghi thông tin dự án và chia sẻ nó với những thành có liên quan, làm tài liệu cho những
dự án tiếp theo
1.5 Các giai đoạn quản lý dự án
1.5.1 Quản lý dự án công nghệ thông tin
Trên cơ sở xem xét các tiến trình xây dựng hệ thốngvà phát triển phần mềm, bây giờ chúng ta xem xét các yêu cầu cụ thể đối với việc quản lý dự án công nghệ thông tin Dĩ nhiên còn có nhiều cách quản lý dự án khác dựa trên các mô hình hay tiến trình phát triển phần mềm khác Trong những phần sau đây chúng ta tập trung chủ yếu là việc xét tới dự án quản lý dự án công nghệ thông tin dựa trên mô hình tuần tự tuyến tính
Quá trình xây dựng và thực hiện một dự án CNTT theo mô hình tuần tự tuyến tính có thể được phân ra thành các giai đoạn khác nhau Mỗi giai đoạn trong quy trình này phải được xác định và phân biệt một cách rõ ràng bởi:
Trang 16• Những điểm mốc chính – các thời điểm và sự kiện
• Các sản phẩm phải được hoàn thành trong giao đoạn đó
Đó là những cơ sở chính để xác định một giai đoạn là đã hoàn thành hay chưa Điều này cũng rất cần thiết cho việc theo dõi đánh giá tiến độ thực hiện dự án về sau này
1.5.2 Bẩy giai đoạn của dự án CNTT
Bảng 1.1 là một bức tranh tổng thể về một cách phân chia quá trình thực hiện dự án CNTT thành các giai đoạn chính Bẩy giai đoạn được trình bày ở đây là xác định, phân tích, thiết kê, thực hiện, kiểm thử hệ thống, kiểm thử chấp nhân và vận hành Về mỗi giai đoạn, cần nắm chắc các khái niệm sau đây:
Mục tiêu của mỗi giai đoạn giải quyết vấn đề cụ thể gì trong toàn bộ quá trình;
Các hoạt động: là những gì mà ta phải làm trong mỗi giai đoạn có những hoạt động phải thực hiện liên tục từ giai đoạn đầu đến cuối như ”quản
lý theo dõi dự án, tư liệu hoá…”
Tài liệu, sản phẩm đầu ra và các điểm mốc: các tài liệu hoặc sản phẩm cần có sau mỗi giai đoạn Các thời điểm mốc(ghi trong ngoặc đơn) là để làm
cơ sở xác định xem công việc hay giai đoạn song 100% hay chưa
Công sức quản lý dự án: công sức của người quản lý dự án được thể hiện ở cột đồ thị cuối Ta thấy công việc của người quản lý dự án trong giai đoạn đầu rất nặng, giảm nhẹ ở giữa và lại trở nên nặng khi gần tới lúc kết thúc
dự án
Ngoài ra, cũng nên phân biệt rõ giữa khái niệm khách hàng và người dùng Mặc dù, trong nhiều trường hợp, hai thuật ngữ này được sử dụng gần như nhau, nhưng chính xác hơn thì có thể hiểu: khách hàng là người đầu tư dự
Trang 17án, và người dùng là những người thực tế sẽ vận hành và sử dụng sản phẩm của hệ thống Do vậy, trong từng ngữ cảnh cụ thể, hãy chọn ý nghĩa thích hợp nhất
- Bản các rủi ro
- Bản kế hoạch ban đầu
- Đề xuất các giải pháp
90%
2 Phân tích Hệ thống tổng thể
cần phải làm gì - tích hệ thống Khảo sát, phân
- Thiết kế mức tổng thể
- Đánh giá lại
- Bản đặc tả chức năng
- Kế hoạch triển khai
60%
3 Thiết kế Từng cấu phân hệ
thống cách hệ thống làm việc
- Thiết kế hệ thống
- Quyết định mua hay làm
- Duyệt xét chi tiết
- Bản đặc tả thừa
kế
- Bản kế hoạch chấp nhận
- Bản kế hoạch đã được thông qua
30%
4.Thực
hiện Xây dựng các cầu phần - phần mềm Lập trình mua
- Chuyên biệt hoá
kế hoạch
- Bản thiết kế cho từng cấu phần,
- Kế hoạch kiểm thử hệ thống
- Tài liệu cho người dùng
- Kiểm thử hệ thống
- Đảm bảo chất lượng
- Báo cáo kết quả tích hợp hệ thống 10%
Trang 18- Đào tạo
- Hỗ trợ
- Rút kinh nghiệm
- Bản kế hoạch hỗ trợ
- Báo cáo kết quả đào tạo
- Kinh nghiệm đúc kết
thể hoá, mọi quá trình quả trị dự án đều chó thể phân làm 3 giai đoan chính là
xây dựng một kế hoạch, theo dõi và quản lý dự án, đóng một dự án Các giai
đoạn này được gặp ở bất kỳ khung cảnh của việc phát triển phần mềm bất kể tới miền ứng dụng, kích cỡ hay độ phức tạp của dự án Mỗi giai đoạn này lại
có thể chia làm nhiều giai đoạn nhỏ cụ thể và tuần tự
Trong phần này chúng ta đã nêu ra được những khái niệm cơ bản và đi vào chi tiết các mô hình, các giai đoạn của quản lý dự án Trong phần tiếp theo chúng ta sẽ đi sâu vào một số quá trình quản lý cơ bản thường gặp trong quá trình quản lý dự án đó là quản lý phạm vi, quản lý thời gian hoàn thành và quản lý rủi ro dự án
Trang 19CHƯƠNG 2 KIẾN THỨC VÀ KỸ NĂNG TRONG LĨNH VỰC QUẢN
LÝ DỰ ÁN 2.1 Quản lý phạm vi dự án
Hoạt động đầu tiên trong lập kế hoạch dự án phần mềm là xác định phạm vi phần mềm Chức năng và hiệu suất của phần mềm cần phải được xác định đánh giá để thiết lập ra phạm vi dự án không mơ hồ và dễ hiểu với các cấp lãnh đạo và kỹ thuật Cần phải chấp nhận một phát biểu phạm vi phần mềm Tức là, dữ liệu định lượng (như số người dùng đồng thời, kích cỡ danh sách gửi thư, thời gian đáp ứng được phép tối đa) cần phải được thiết lập tường minh, các ràng buộc và/hoặc giới hạn (như chi phí sản phẩm hạn chế kích thức bộ nhớ) cần được ghi lại và các nhân tố giảm nhẹ (như thuật toán mong muốn đã được hiểu rõ)
Phạm vi phần mềm mô tả các chức năng, hiệu xuất, các rằng buộc, giao diện và độ tin cậy Chức năng được mô tả trong phát biểu phạm vi sẽ được đánh giá và trong một số trường hợp được làm mịn để đưa ra mức ưu tiên chi tiết hơn cho việc bắt đầu ước lượng Bởi vì cả ước lượng chi phí và ước lượng lịch biểu đều hướng theo chức năng nên có ích hơn cả hơn cả là phân rã chức năng nào đó Các xem xét về hiệu suất bao gồm các yêu cầu về tiến trình và thời gian đáp ứng Ràng buộc xác định ra các giới hạn áp đặt lên phần mềm bởi phần cứng bên ngoài, bộ nhớ có sẵn hay các hệ thống đang tồn tại khác
Phầm mềm tương tác với các phần tử khác của hệ thống dựa vào máy tính Người lập kế hoạch xem xét bản chất và độ phức tạp của từng giao diện
để xác định ảnh hưởng lên tài nguyên, chi phí, thời gian của công việc phát triển
Trang 20Khía cạnh ít chính xác nhất của phạm vi phần mềm là thảo luận về độ tin cậy Việc đo độ tin cậy quả thực tồn tại nhưng chúng còn ít được dùng trong giai đoạn này của dự án
Nếu một đặc tả của một hệ thống đã được phát triển đúng đắn thì gần như tất cả các thông tin cần cho một mô tả về phạm vi phần mềm đều có sẵn
và được làm tư liệu trước khi việc lập kế hoặch dự án được bắt đầu Trong những trường hợp còn chưa xây dựng ra được một đặc tả thì người lập kế hoặch phải đóng vai trò của nhà phân tích hệ thống để xác định các thuộc tính
và giới hạn sẽ ảnh hưởng tới nhiệm vụ ước lượng
Trên đây chúng ta đã sơ lược qua về quản lý phạm vi, các khía cạch của quản lý phạm vi Sau đây chúng ta sẽ đi chi tiết hơn vào một lĩnh vực quản lý phạm vi mà chúng ta cần phải quan tâm nhất, nó có ảnh hưởng rất lớn trong việc phát triển một dự án phần mềm Đó quản lý thay đổi ứng ụng
2.1.1 Tầm quan trọng của quản lý thay đổi ứng dụng
Các ứng dụng phải thường xuyên thiết kế lại Ba lý do cơ bản của thiết
kế lại là sự phân công của một nhóm quản lý mới, dự án vượt qua ngân sách, ứng dụng chậm và có nhiều lỗi, và sự thiếu tin tưởng của chủ sử dụng về việc các kỹ sư phần mềm hiểu rõ các yêu cầu của mình
Các thay đổi có thể là các yêu cầu thiết kế, chương trình, giao diện, phần cứng hoặc phần mềm phải mua Phần lớn các thay đổi bắt nguồn từ bên trong tổ chức phát triển ứng dụng, nhưng cũng có thể được kích hoạt từ các tác nhân ngoài, ví dụ như thay đổi về luật Việc sử dụng chức năng điều khiển thay đổi giúp cho nhóm triển khai kiểm soát được thay đổi của người sử dụng trong khi vẫn cho phép thực hịên các yêu cầu hợp lý
Trang 212.1.2 Các thủ tục quản lý thay đổi
Quản lý điều khiển thay đổi có hiệu lực từ khi sản phẩm công việc đầu tiên được chấp nhận là hoàn thiện và có cơ sở cho các công việc hiện tại khác của nhóm triển khai dự án Ví dụ như, một tài liệu cơ sở là bản quy định yêu cầu chức năng sau khi nó đã được chấp nhận bởi người sử dụng
Các thay đổi có thể phân loại theo một số cách Thứ nhất, chúng được phân theo kiểu như loại bỏ lỗi cải tiến thực hiện hoặc thay đổi chức năng Thứ hai, thay đổi phân loại thành theo yêu cầu và lựa chọn Thứ ba, phân theo độ
ưu tiên như khẩn cấp, lệnh với ngày bắt đầu yêu cầu hoặc ưu tíên thấp Thông thường, kiểu loại bỏ lỗi là khẩn cấp theo yêu cầu, trong khi thay đổi chức năng là bảo dưỡng lệnh theo yêu cầu, và cải thiện thực hiện là lựa chọn và có thể không có ưu tiên
Việc biết được loại yêu cầu thay đổi quyết định xem tài liệu nó có cần phải chịu điều khiển thay đổi không Các thay đổi khẩn cấp thường phá vỡ thủ tục điều khiển thay đổi do các công việc thực hiện tuần tự nhưng chúng lại được tài liệu hoá sau khi thay đổi đã kết thúc Tất cả các loại thay đổi khác đều phải tuân theo các điều khiển thay đổi
Người quản lý dự án và kỹ sư phần mềm định nghĩa các tác động tiến trình và chi phí của thay đổi Sau đó thay đổi được bàn bạc với người sử dụng Dựa trên thương lượng với người sử dụng, thay đổi được gán một ưu tiên hoạt động và chi phí và tiến trình được thay đổi
Yêu cầu, ngày dự định hoạt động thay đổi tiến trình và tăng chi phí được thêm vào một file quá trình dự án Các thay đổi có thể được quản lý bởi một nhân viên điều khiển thay đổi, là một người có nhiệm vụ bảo dưỡng quá trình dự án và các bản ghi điều khiển thay đổi, và hàng tháng in ra một bản báo cáo điều khiển thay đổi Một file điều khiển thay đổi chứa tất cả các yêu
Trang 22cầu, thư từ và tài liệu về các thay đổi Một yêu cầu thay đổi mở có thể được tạo ra khi yêu cầu được đưa ra và một số lượng thay đổi được gán Yêu cầu thay đổi mở nằm trong file cho đến khi yêu cầu được hoàn thành, đóng và được báo cáo
Khi thay đổi được thực hiện các mục có ảnh hưởng được cập nhật, bao gồm tư liệu tương ứng, mã, vv Một danh sách kiểm soát của người quản lý
dự án được dùng để loại bỏ các hoạt động đã được yêu cầu Tài liệu mới được nhân viên điều khiển thay đổi sắp xếp và phân phối nó cho những người có quan tâm
Ngày hoàn thành thay đổi được đưa vào file điều khiển thay đổi Thay đổi được xác định khi được đóng trong báo cáo tình trạng tới và yêu cầu mở được chuyển từ file điều khiển thay đổi sang
Dựa trên tổ chức này, người điều hành có thể muốn theo dõi các yêu cầu thay đổi của dự án để nhận biết sự thành công trong nhóm các yêu cầu Chi phí thay đổi cung của một năm thường được sử dụng như là một chỉ tiêu
để chỉ ra xem ứng dụng đang có triển vọng hay cần vất bỏ hay cần công nghệ hoá lại Trong những trường hợp này cả chi phí và số lượng các yêu cầu thay đổi đều được theo dõi thông qua quá trình điều khiển thay đổi Các báo cáo tổng kết bởi dự án thay đổi trong một thời kỳ nhất định, hoặc so sánh theo thời kỳ(Ví dụ kỳ này so với cùng kỳ năm trước) có thể được triển khai Ba dạng báo cáo này thông qua tổ chi phí lần lượt theo kiểu, tác động chi phí và tiến trình, và các yêu cầu thay đổi
2.1.3 Nhập quá trình quyết định
Khi bắt đầu một dự án, người quản lý dự án và kỹ sư phần mềm quyết định sử dụng các công cụ để lưu trữ quá trình quyết định Có nghĩa là có thể dùng công cụ điện tử hoặc một phiên bản viết tay và các quyểt định được duy
Trang 23trì dưới dạng văn bản Với công cụ điện tử, các bản sao điện tử được lưu trữ Với công cụ ghi tay, phiên bản cũ được cập nhật và đổi tên khi một tài liệu thay đổi Ví dụ như, các quy định chức năng của ABC có thể được đặt tên là ABCFS- mmddyy, trong đó ABC là công ty, FS là viết tắt của quy định chức năng(Functional Speciffication) và mmddyy là ngày tháng Phần ngày tháng của tên sẽ thay đổi do bất kỳ một thay đổi quan trọng nào của tài liệu Thủ tục quản lý thay đổi sẽ được nói đến trong phần tiếp theo
2.1.4 Quản lý thay đổi tài liệu
Các thay đổi tài liệu có thể được xác định bởi một bản nội dung các thay đổi tại đầu mỗi tài liệu Bảng nội dung các thay đổi bao gồm ngày hiệu lực, các phần bị ảnh hưởng của tài liệu và một tóm tắt về thay đổi Mục đích của bảng nội dung các thay đổi là để tóm tắt tất cả các thay đổi cho người đọc
Các thay đổi nên được đánh dấu đỏ trong văn bản để xác định bộ phận thay đổi Nếu nội dung cũ là quan trọng, thì nó có thể được đưa vào chú ý, được ghi ngày tháng, và được dán nhãn là phiên bản trước
2.2 Quản lý thời gian thực hiện dự án
Lập lịch cho các dự án phát triển phần mềm có thể được xem xét theo hai bối cảnh khá khác nhau Trước hết, ngày cuối cần phải bàn giao hệ thống dựa trên máy tính đã được ấn định rõ (và không thể thay đổi) Tổ chức làm phần mềm bị ràng buộc phải phân bố nỗ lực trong khuôn khổ thời gian đã định Quan điểm thứ hai của việc lập lịch phần mềm giả sử rằng giới hạn thời gian đại thể đã được thảo luận nhưng ngày cuối đó do tổ chức làm phần mềm
ấn định Nỗ lực được phân bố để làm cho việc sử dụng các nguồn tài nguyên được tốt nhất và ngày cuối đó sẽ được xác định sau khi phân tích cẩn thận về phần mềm Nhưng không may là viễn cảnh thứ nhất thường gặp hơn rất nhiều
so với viễn cảnh thứ hai
Trang 24Độ chính xác trong việc lập lịch đôi khi có thể là quan trọng hơn độ chính xác về chi phí Trong một môi trường hướng sản phẩm, giá phụ trội có thể được tính vào việc làm lại giá hay khấu hao trên số bán lớn Tuy nhiên việc lập lịch thiếu sót có thể làm giảm tác động làm cho khách hàng không hài lòng và làm tăng chi phí nội bộ bằng việc tạo ra vấn đề phụ trong khi tích hợp hệ thống
Khi chúng ta tiếp cận tới việc lập lịch dự án, có một số câu hỏi cần được trả lời Làm sao chúng ta có thể phối hợp thời gian với nỗ lực con người? Ta trông đợi nhiệm vụ và cơ chế song song nào? Vạch mốc nào có thể được dùng để chỉ ra tiến độ? Phân phối nỗ lực thế nào trong toàn tiến trình kỹ nghệ phần mềm? Phương pháp lập lịch nào hiện có? Làm sao ta có thể biểu diễn về mặt vật lý cho một lịch biểu và rồi theo dõi tiến độ khi dự án bắt đầu?
2.2.1 Lịch biểu
Cấu trúc phân việc cho chúng ta biết mỗi điều chúng ta phải làm Nó không cho chúng ta các thông tin khác để giúp chúng ta lãnh đạo, xác định, lập kế hoạch, tổ chức, kiểm soát và kết thúc dự án của mình một cách hiệu quả Công cụ chính để giúp chúng ta hoàn thành điều này là lịch biểu dự án
2.2.2 Mục đích của lịch biểu
Là người quản lý dự án, chúng ta cần biết trình tự logic của từng nhiệm
vụ và ngày tháng bắt đầu kết thúc cho từng nhiệm vụ Lịch biểu giúp cho chúng ta suy ra ngày tháng
Chẳng hạn, chúng ta có thể muốn lập kế hoạch cho một dự án để tạo ra một đề nghị tiếp thị Chúng ta sẽ cần biết các bước để hoàn thành dự án Chúng ta cũng sẽ cần biết trình tự logic cho mỗi bước (như bước nào đi thứ nhất, thứ hai, thứ ba, đi song song…) Một khi chúng ta đã nhận diện các mối
Trang 25quan hệ giữa những nhiệm vụ này thì chúng ta có thể ước lượng thời gian để thực hiện từng nhiệm vụ, rồi tính toán thời gian bắt đầu và kết thúc
2.2.3 Lợi ích của lịch biểu
Lịch biểu nhận diện khi nào một hoạt động bắt đầu và kết thúc, đặc biệt nếu những ngày tháng này là không bị áp đặt bởi bên khác Cấp quản lý không nên xác định khi nào dự án phải kết thúc; một lịch biểu chính xác nên cho chúng ta biết khi nào dự án có thể kết thúc
Lịch biểu cung cấp cho chúng ta lợi ích khác Nó cho chúng ta biết trình tự logic của dự án Mọi nhiệm vụ bên trong một dự án, nếu được quản lí tốt, sẽ rơi vào bên trong một trình tự với một số nhiệm vụ đi trước và số khác theo sau Lịch biểu tạo khả năng cho chúng ta đi theo trình tự mà chúng ta xây dựng Một khi dự án của chúng ta bắt đầu, thì mọi thứ nên xuất hiện tương ứng theo trình tự này
Thường thì người quản lý dự án không dùng lịch biểu hay rơi vào trong cái bẫy của việc thực hiện các nhiệm vụ chưa chín muồi trước khi họ nhận được cái vào từ nhiệm vụ khác có liên quan Kết quả là chất lượng thấp, năng suất kém, mực độ thất vọng cao của nhân viên, kéo dài ngày kết thúc dự án,
và vượt quá chi phí
Lịch biểu cũng cung cấp việc kiểm soát tốt hơn Chúng ta có thể theo dõi dấu vết và điều phối tiến độ trong dự án - biết nhiệm vụ nào là 100% hoàn thành, nhiệm vụ nào hoàn thành một phần; và nhiệm vụ nào mới bắt đầu
Lịch biểu áp đặt kỷ luật lên dự án Bằng việc tuân theo lịch biểu, chúng
ta buộc dự án phỉ tiến hành theo cách đặc biệt và tương ứng với thời gian biểu
đã đặt Một khi chúng ta phát hiện ra bất kì sai lệch nào với những tham biến này, thì chúng ta có thể đáp ứng tương ứng
Trang 26Lịch biểu chỉ ra khi nào chúng ta cầu tài nguyên đặc biệt Biết khi một hoạt động xuất hiện sẽ cho phép chúng ta tập hợp tài nguyên trước chứ không đợi cho tới sau khi hoạt động đã bắt đầu
Một số người quản lý dự án không xác định được khi nào họ cần người với kỹ năng đúng mãi cho tới khi nhiệm vụ đó đã bắt đầu Trong khi họ cố gắng hết sức để tìm ra người với kỹ năng khớp, thi dự án của họ bị tụt lại sau lịch biểu Với lịch biểu chính xác, họ có thể tránh được được vấn đề này bằng việc định trước khi nào họ cần một người với kỹ năng yêu cầu
Cuối cùng, lịch biểu cho phép chúng ta xác định nhiệm vụ nào là găng
và nhiệm vụ nào thì không Nó giúp chúng ta nhận diện hoạt động nào nên được giải quyết ngay ngược với việc cố gắng làm tất cả chúng một lúc Nỗ lực như vậy sẽ làm cạn kiệt tài nguyên của chúng ta(thời gian, lao động, tiền bạc, trang bị…) hướng tới việc thoả hiệp chất lượng, năng suất thấp, chậm trễ lịch biểu và gây ra ngân sách bị thâm hụt
2.2.4 Xây dựng lịch biểu
Dù chúng ta xây dựng sơ đồ thanh hay biểu đồ mạng, nên nhớ các điểm sau đây Đừng bao giờ đặt lịch biểu soạn nháp vào dạng cuối cùng Nó có tác động về mặt tâm lí nên chất lượng của ý kiến phản hồi mà chúng ta nhận từ mọi người Mọi người ngần ngại phê bình cái gì đó ở dạng cuối cùng Họ cảm thấy chúng ta đã làm công việc đáng kể - mà chúng ta có thể đã làm - để xây dựng lịch biểu Nếu họ thấy cái gì đó không đúng, họ có thể cảm thấy rằng việc thay đổi nó có thể yêu cầu nỗ lực đáng kể và có thể làm hại tới tình cảm của chúng ta Chúng ta hãy giữ lịch biểu dưới dạng nháp chừng nào mà nó còn chưa nhận được việc chấp thuận hoàn toàn
Chúng ta hãy dùng cả các phiên gặp gỡ cá nhân và cuộc họp nhóm để xây dựng lịch biểu Chẳng có gì nói chúng ta phải tự mình xây dựng lịch biểu
Trang 27Thực vậy, xây dựng lịch biểu một cách độc lập có thể làm chúng ta bị phơi ra cho sự phản đổi của những người khác về sau trong dự án Ý tưởng là tạo ra một lịch biểu mà mọi người đều có thể đồng ý tuân theo Cách tiếp cận tốt nhất là xác định ai nên tham gia vào việc xây dựng lịch biểu Một cách lí tưởng, chúng ta sẽ phải nhận diện tất cả những cá nhân sau đó khi tạo ra cấu trúc phân việc Chúng ta nên ngồi với từng người, ban đầu là từng cá nhân, và soạn nháp phần của lịch biểu liên quan tới họ Sau khi nhận được phản hồi từ mọi người, chúng ta có thể tổ chức các cuộc họp nhóm để giải quyết các bất đồng Sau khi đạt tới sự đồng thuận, hãy thu lấy chữ kí của mọi người vào lịch biểu Hãy ghi lại ngày tháng kí nữa Hành động này có ý nghĩa là sự đồng
ý làm việc theo lịch này Việc thu được chữ kí còn nhiều ý nghĩa hơn là nhận
sự chấp thuận của họ; nó cũng có tác động tâm lí có ích Khi mọi người kí vào một tài liệu, thì bản thân họ cam kết dưới dạng được ghi lại
Được vũ trang bằng chữ kí của mọi người, chúng ta tạo ra lịch biểu dưới dạng cuối cùng Chúng ta nên cất giữ lịch gốc ở chỗ an toàn và đưa bản sao cho từng thành viên trong dự án và những bên quan tâm khác Hành động tồi nhất chúng ta có thể làm là xây dựng một lịch biểu và giấu cả tổ về nó Hãy chắc chắn mọi người cần tới lịch biểu đều có nó Chỉ bởi vì chúng ta có lịch biểu dưới dạng cuối cùng thì cũng không có nghĩa là chúng ta không thể thay đổi nó một cách đều đặn Thỉnh thoảng, chúng ta có thể phải lập lại lịch Chúng ta nên lưu trữ các phiên bản trước của lịch biểu khi lập lại lịch biểu Hành động này cung cấp việc theo dõi dấu vết tuyệt vời về nguyên nhân sinh
ra việc lập lịch lại Nó cũng cung cấp thông tin lưu trữ vô giá cho các dự án tương lai mang bản chất tương tự
2.2.4 1 Xác định nhiệm vụ và cơ chế song song
Khi có nhiều người cùng tham gia trong một dự án kĩ nghệ phần mềm thì rất có thể là các hoạt động phát triển sẽ được thực hiện song song Hình
Trang 282.1 chỉ ra một sơ đồ mang nhiệm vụ cho một dự án kĩ nghệ phần mềm nhiều người điển hình Mạng này biểu thị cho tất cả các nhiệm vụ dự án, trình tự của chúng và sự phụ thuộc của chúng
Phân tích, đặc tả và tổng quan về các yêu cầu kết quả là những nhiệm
vụ đầu tiên cần phải thực hiện và đặt nền tảng cho các nhiệm vụ song song theo sau.Một khi các yêu cầu đã được xác định và xem xét thì hoạt động thiết
kế (thiết kế kiến trúc và dữ liệu) và việc vạch kế hoạch kiểm thử có thể bắt đầu song song Bản chất môđun của phần mềm thiết kế tốt tự bản thân nó đã giúp cho việc theo dõi sự phát triển song song cho thiết kế thủ tục, mã hóa và kiểm thử đơn vị như được minh họa trong hình 2.1 Khi các thành phần của phần mềm được hoàn tất, nhiệm vụ kiểm thử tích hợp bắt đầu Cuối cùng kiểm thử hợp lệ để làm cho phần mềm sẵn sàng bàn giao cho khách hàng
Tham khảo đến hình 2.1 điều quan trọng cần lưu ý là các mốc được đặt
ở những khoảng đều đẳn trong toàn bộ tiến trình công nghệ cung cấp cho các nhà quản lí một chỉ báo đều đặn về tiến độ Các mốc được đạt tới một khi tài liệu được tạo ra xem như một phần của nhiệm vụ kĩ nghệ phần mềm đã được xem xét thành công
Bản chất tương trang của các hoạt động kĩ nghệ phần mềm dẫn tới một
số yêu cầu lập lịch quan trọng Bởi vì các nhiệm vụ song song xuất hiện không đồng bộ nên người lập kế hoạch phải xác định sự phụ thuộc giữa các nhiệm vụ để đảm bảo tiến độ liên tục hướng tới hoàn tất bên cạnh đó, người quản lí dự án cũng cần biết về những nhiệm vụ nằm trên đường găng, tức là những nhiệm vụ phải được hoàn tất theo lịch biểu để cho dự án như một tổng thể được hoàn thành theo lịch
Trang 29Hình 2.1 Mạng nhiệm vụ và cơ chế song song
2.2.4 2 Phân bố nỗ lực
Từng kỹ thuật ước lượng dự án phần mềm dẫn tới các ước lượng về
người – tháng (hay người – năm ) cần để hoàn tất phát triển phần mềm Hình
2.2 minh họa cho một phân bố đề nghị về công sức cần thực hiện cho các giai
đoạn xác định và phát triển Phân bố này, còn được là qui tắc 40-20-40, nhấn
mạnh vào các nhiệm vụ phân tích và thiết kế đầu trước và kiểm thử đầu sau Độc giả có thể suy ra đúng đắn rằng phần mã hóa (20 phần trăm công sức) là không được nhấn mạnh
Phân bố công sức được vẽ trong Hình 2.2 nên được dùng chỉ như bản hướng dẫn Các đặc trưng của từng dự án phải quyết định ra cách phân phối công sức.Công sức danh cho việc lập kế hoạch dự án hiếm khi được tính lớn hơn 2 đến 3 phần trăm công sức,trừ khi kế hoạch có dính dáng đến một tổ chức và rủi ro cao Việc phân tích yêu cầu có thể chiếm tới 10 đến 25 phần trăm công sức dự án Công sức dành cho phân tích và làm bản mẫu cần phải tăng tỉ lệ trực tiếp với kích cỡ và độ phức tạp dự án Phạm vi 20 đến 25 phần
Trang 30trăm công sức thông thường được áp dụng cho thiết kế phần mềm Thời gian dành cho tổng quan thiết kế và việc lặp về sau cũng phải được xem xét đến
Hình 2.2: Phân bố nỗ lực Bởi công sức được dành cho thiết kế phần mềm nên việc mã hóa đi theo với tương đối ít khó khăn Có thể đạt tới một phạm vi 15 đến 20 phần trăm trên tổng số công sức Kiểm thử và gỡ lỗi sau đó có thể chiếm tới 30 đến
40 phần trăm công sức phân bố nỗ lực phát triển phần mềm.sự căng thẳng của phần mềm thường quyết định đến khối lượng kiểm thử cần tới Nếu phần mềm bị lỗi do con người thì có thể xem xét tăng số phần trăm nỗ lực cao hơn dành cho việc này
2.2.4.3 Lập lịch theo sơ đồ mạng
Có hai kiểu lịch biểu là sơ đồ thanh và biểu đồ mạng Biểu đồ mạng có nguồn gốc vào khoảng cuối năm 1950 Chúng được phổ biến rộng rãi với cái tên là PERT(Kỹ thuật đánh giá và xét duyệt chương trình) và CPM( Phương pháp đường găng)
Trang 31PERT có nguồn gốc từ chương trình tên lửa Polaris Nó đặt sự nhấn mạnh vào việc hoàn thành các cột mốc chính thay vì tuân theo các ước lượng thời gian đích xác CMP có nguồn gốc trong việc xây dựng nhà máy hoá chất của Dupont Nó đặt nhấn mạnh vào việc đáp ứng các ước lượng thời gian chính xác
Qua nhiều năm thì hai phương pháp này đã hoà vào nhau và bầy giờ đã tiến đến hoá thành hai kỹ thuật lập lịch mạng Hai kỹ thuật này là phương pháp lập
biểu đồ mũi tên và biểu đồ ưu tiên
phương pháp lập biểu đồ mũi tên là phương pháp truyền thống, nó đã được dùng rộng rãi từ những năm 1950 và được sử dụng đều đặn trong ngành xây dựng Trong khi đó phương pháp lập biểu đồ ưu tiên là một phương pháp khác để làm biểu đồ mũi tên, nó phổ biến với các dự án hiện có trong công nghiệp hơn cách xây dựng khác như hệ thông tin, kỹ nghệ và không gian
Đường găng
Đường găng minh hoạ cho các hoạt động trong sơ đồ mạng mà không để trượt
đi bất kỳ khoảng thời gian nào Phải hoàn tất chúng tương ứng với ngày tháng
đã được tính toán
Các khoản mục đường găng có một số đặc trưng duy nhất phân biệt chúng với các hoạt động khác Các khoản mục đường găng được đặt trên đường đi dài
nhất trên sơ đồ mạng, mọi hoạt động trên đường găng đều có thể thả nổi, tức
là những hoạt động này không thể để lỡ bất kỳ ngày bắt đầu hay ngày hoàn thành mà không gây tác động lên các hoạt động lên các hoạt động sau và ngày kết thúc của dự án
Cách xây dựng biểu đồ mạng
Việc xây dựng sơ đồ mạng là không dễ, nó đòi hỏi việc lập kế hoạch và kinh nghiệm xử lý Cấu trúc phân việc là nguồn thông tin chính cho việc xây dựng
Trang 32sơ đồ mạng Tuy nhiên không dùng tất cảc các khoản mục được nêu trong WBS, chỉ cần dùng những hoạt động nằm ở mức thấp nhất của mỗi nhánh Các khoản mục này được coi là ở mức gói công việc và là những phần tử chung để xây dựng biểu đồ mạng
Sau khi xác định các phần tử mức gói công việc thì bắt đầu nhiệm vụ nặng nền là nối chúng lại với nhau để phản ánh trình tự logic Phương pháp thông
thường là chỉ viết số hiệu hoạt động hay mã WBS trong biểu diễn cho hoạt động
Cách thông dụng để xây dựng biểu đồ mạng là phác thảo biểu đồ trên trang giấy lớn, rồi ghi số hiệu hoạt động hay mã WBS cho từng nhiệm vụ trên một thẻ riêng biệt Đặt thẻ thích hợp lên tờ giấy này ở vị trí dường như đúng đắn
rồi vẽ mũi tên nối từng phần tử, kết quả là một bản thảo sơ đồ mạng đầu tiên
Bất kể phương pháp xây dựng sơ đồ mạng nào thì nên ghi lại về mặt đồ thị rồi phản ánh bản sao của đồ thị này Nếu dùng bộ trình lập tự động thì việc này đơn giản hơn nhưng quan trọng vẫn là phải xây dựng WBS làm ước lượng
thời gian, xác định trình tự logic các hoạt động và đưa các thông tin đó vào hệ
thống tính toán bởi không gói phần mềm hiện có nào giúp được việc này
2.2.4.4 Lập lịch theo Sơ đồ thanh
Sơ đồ thanh
Sơ đồ thanh hay còn gọi là sơ đồ Gantt được dùng rộng rãi hơn trong nhiều ngành công nghiệp, những sơ đồ này dễ xây dựng và chuyển tải thông tin rõ ràng, chính xác hơn Các sơ đồ này không cung cấp tất cả thông tin trao đổi trong sơ đồ mạng Thường thì một số nhà quản lý coi nhẹ những thiếu sót này
Sơ đồ thanh không chỉ ra các phụ thuộc giữa các hoạt động Không thể biết
hoạt động nào đi trước hoạt động nào Sơ đồ thành không chỉ ra tất cả các
Trang 33ngày cho từng hoạt động Thông thường, việc bắt đầu của thanh chỉ ra ngày bắt đầu sớm và kết thúc của thanh chỉ ra ngày kết thúc sớm Hiếm khi người
quản lý dự án xây dựng sơ đồ thanh với các thanh phản ánh ngày bắt đầu và
kết thúc muộn cho các hoạt động
Một thiếu sót nữa là sơ đồ thanh không chỉ ra hoạt động nào là găng hoạt động nào là không găng Đường găng không được chỉ rõ ràng trừ phi các ký
hiệu được dùng để chỉ rõ hoạt động nào là găng và không găng Bên cạnh đó
sơ đồ thanh không chỉ ra việc thả nổi cho từng hoạt động Thiếu sót này làm cho khó xác định hoạt động nào cần chú ý
Mặc cho những thiếu sót thì sơ đồ thanh có cái hữu dụng của nó, nó rất tốt cho việc báo cáo quản lý cấp cao và khách hàng Nó dễ đọc và dễ hiểu hơn sơ
đồ mạng Và chúng hoàn hảo để cung cấp thông tin lịch biểu tóm tắt cho cả
cấp quản lý và khách hàng Sơ đồ thanh tạo nên khả năng tóm tắt các mức khác nhau bên trong cấu trúc phân việc, trong khi sơ đồ mạng chỉ đòi hỏi các khoản mục thấp nhất trong cấu trúc phân việc được xem như mức gói công
việc
Bất kỳ sơ đồ nào thì cũng nên đưa vào một số tính năng chung cho tất cả các
sơ đồ thanh Thứ nhất, sơ đồ phải có thang thời gian để chỉ ra luồng thời gian, hay thời hạn của từng hoạt động Thang thời gian này có thể tăng theo bất kỳ
độ tăng nào như theo giờ, ngày, tuần … Thứ hai, sơ đồ thanh phải có các cột
liệt kê các nhiệm vụ, cột này được chi thành hai cột con để liệt kê số hiệu nhiệm vụ và mô tả nhiệm vụ Thứ ba, các thanh nên được vẽ để phản ánh luồng thời gian hay thời hạn của từng hoạt động Có thể dùng thanh bôi đen hay để hổng hoặc cả hai để biểu diễn phần trăm hoàn thành và toàn bộ hoạt động
Cách xây dựng sơ đồ thanh
Trang 34Xây dựng sơ đồ thanh dễ hơn sơ đồ mạng vẫn với cấu trúc WBS làm nguồn thông tin, tốt nhất là tại mức gói công việc Có thể xây dựng sơ đồ thanh bằng
việc chỉ ra các thanh cho cho các mức khác nhau bên trong WBS Có thể chỉ
ra các thanh cho các phần tử tại cùng mức trong WBS hay các mức trộn lẫn bằng việc dùng mã WBS cho mô tả nhiệm vụ để chỉ ra mức bên trong WBS
Có thể vẽ phần lớn các sơ đồ thanh trên một tờ giấy lớn, nhớ đưa cả vào một
cột định danh nhiệm vụ và một vùng để vẽ các thanh để phản ánh luồng thời gian cho hoạt động
Khi vẽ biểu đồ thanh hãy chú ý tới trình tự logic của các nhiệm vụ Một sai lầm chung là vẽ các thanh đông thời trong khi thực tế chúng phải theo nhau tuần tự Người quản lý đôi khi vẽ một thanh cho một nhiệm vụ, không hiểu rõ trình tự thời gian cho các hoạt động Việc phát hành một lịch biểu với lỗi nền
tảng đó có thể gây ra tin trạng lúng túng nào đó
Có nhiều lựa chọn sẵn có để cải tiến dáng vẽ của sơ đồ thanh bản thảo Một số gói phần mềm máy tính cho phép đưa vào ngày tháng cho hoạt động, một số khác đưa vào các thông tin trên các hệ thống lớn hơn bằng việc dùng gói đồ
hoạ giúp các sơ đồ thanh một dáng vẻ chuyên nghiệp Tuy nhiên điều quan trọng nhất là độ chính xác của thông tin chứ không phải là dáng lịch biểu
2.2.4.5 Phương pháp lập lịch
Lập lịch cho dự án phần mềm không khác gì lớn lắm với việc lập lịch cho bất kì nỗ lực phát triển đa nhiệm nào Do đó, các công cụ và kỹ thuật lập lịch dự án tổng quát có thể được áp dụng cho phần mềm với một chút sửa đổi
Kỹ thuật xem xét và đánh giá chương trình (PERT) và phương pháp đường găng (CPM) là hai phương pháp lập lịch dự án có thể áp dụng cho việc phát triển phần mềm Cả hai kỹ thuật này đều xây dựng việc mô tả dự án theo mạng nhiệm vụ, tức là, việc biểu diễn theo hình hay bảng chocác nhiệm vụ
Trang 35cần phải tiến hành từ đầu tới cuối dự án (Hình 2.2) Mạng được xác định bằng
cách xây dựng một danh sách tất cả các nhiệm vụ, đôi khi còn được là cấu
trúc phân việc dự án (WBS), liên kết với một dự án xác định và một danh
sách có trật tự (đôi khi còn được gọi là danh sách hạn chế ) chỉ ra các nhiệm
vụ phải thực hiện theo thứ tự nào
Cả PERT và CPM đều cung cấp các công cụ định lượngcho phép người
lập kế hoạch phần mềm: (1) xác định đường găng – dây chuyền các nhiệm vụ xác định ra thời hạn dự án; (2) thiết lập ước lượng thời gian có thể nhất cho
từng nhiệm vụ bằng cách áp dụng mô hình thống kê; (3) tính toán thời gian biên, cải tạo ra “ của số thời gian” cho một nhiệm vụ đặc biệt
Việc tính thời gian biên có thể rất có ích trong việc lập lịch dự án.độ trượt trong thiết kế của một chức năng, chẳng hạn, có thể làm chậm thêm việc xây dựng các chức năng khác.Rigg mô tả thời gian biên quan trọng có thể thấy được từ mạng PERT hay CPM: (1) thời gian sớm nhất mà một nhiệm vụ
có thể bắt đầu; (2) thời gian muộn nhất cho việc khởi đầu nhiệm vụ trước khi thời gian hoàn thành dự án tối thiểu bị trễ; (3) sự kết thúc sớm nhất – tổng của việc bắt đầu sớm và thời hạn nhiệm vụ; (4) sự kết thúc muộn nhất – thời gian bắt đầu muộn nhất cộng với thời gian nhiệm vụ; (5) tổng độ nổi – khối lượng thời gian quá mức hoặc chậm trễ được phép theo các nhiệm vụ lập lịch để cho đường găng trên mạng được duy trì theo lịch Việc tính toán thời gian biên dẫn tới việc xác định đường găng và cung cấp cho người quản lí một phương pháp định lượng để ước tính tiến độ cũng như nhiệm vụ cần hoàn thành
Xem như một bình luận cuối cùng về lập lịch, chúng ta gọi cách biểu diễn đường cong Rayleigh – Norden[2] cho nỗ lực trải trong vòng đời phần mềm Người lập kế hoạch phải nhận ra bằng nỗ lực trải trên phần mềm không kết thúc vào lúc cuối việc xây dựng nỗ lực bảo trì, mặc dầu không dễ lập lịch tại
Trang 36giai đoạn này, cuối cùng trở thành nhân tố chi phí lớn nhất Một mục tiêu chủ yếu của kĩ nghệ phần mềm là giúp làm giảm thiểu chi phí này
2.3 Quản lý rủi ro
Tương lai là mối quan tâm của chúng ta – rủi ro nào có thể gây ra cho dự
án phần mềm bị thất bại? sự thay đổi là mối quan tâm của ta – làm sao mà những thay đổi trong yêu cầu của khách hàng, sự phát triển của công nghệ,
và tất cả những thực thể khác có liên quan tơi dự án, lại ảnh hưởng tới thời gian và sự thành công của tổng thể được? Cuối cùng chúng ta phải túm lấy những chọn lựa – chúng ta nên dùng phương pháp và công cụ nào, cần huy động bao nhiêu người, nhấn mạnh bao nhiêu vào chất lượng là đủ?
Phân tích rủi ro thực tế là bốn hoạt động phân biệt: xác định rủi ro, dự phóng rủi ro, định giá rủi ro và quản lý rủi ro Mỗi một trong các hoạt động này được mô tả trong các đoạn sau đây
Trang 372.3.2 Xác định rủi ro
Để loại bỏ được rủi ro và đặt vấn đề cố làm giảm thiểu nó thì điều bản chất là rủi ro được xem xét phải là đúng rủi ro Trước khi chúng ta có thể xác định đúng rủi ro cần xem xét trong một dự án phần mềm, điều quan trọng là phải xác định mọi rủi ro hiển nhiên cho cả người quản lí và người hành nghề
Có thể phân loại rủi ro theo nhiều cách Có thể xác định, ở mức vĩ mô, các rủi ro dự án, các rủi ro kỹ thuật và rủi ro nghiệp vụ Rủi ro dự án xác định các vấn đề yêu cầu, khách hàng, tài nguyên, nhân sự (nhân viên và tổ chức), lịch biểu, ngân sách tiềm năng và ảnh hưởng của chúng lên dự án phần mềm
Độ phức tạp, kích cỡ của cấu trúc dự án cũng được xác định như các nhân tố rủi ro Rủi ro kỹ thuật xác định các vấn đề tiềm năng về thiết kế, cài đặt, giao diện, kiểm chứng và bảo trì Bên cạnh đó, độ mơ hồ riêng, độ bất trắc kỹ thuật, sự lạc hậu kỹ thuật và kỹ thuật “mũi nhọn” cũng là những nhân tố rủi
ro Rủi ro kỹ thuật xuất hiện bởi vì vấn đề khó giải quyết hơn ta tưởng Rủi ro nghiệp vụ là ở bên trong bởi vì chúng có thể làm sáng tỏ kết quả của ngay cả
dự án phần mềm tốt nhất Ứng cử viên cho năm loại rủi ro nghiệp vụ là: (1) xây dựng một sản phầm tuyệt vời mà chẳng ai thực sự muốn (rủi ro tiếp thị); (2) xây dựng một sản phẩm chẳng thích hợp với chiến lược sản phẩm tổng thể cho công ty; (3) xây dựng một sản phẩm mà lực lượng bán hàng không hiểu làm sao bán được; (4) mất sự hỗ trợ của cấp quản lý cao do thay đổi mối quan tâm hay do thay đổi trong con người (rủi ro quản lý); (5) mất cam kết về tài chính hay nhân sự (rủi ro ngân sách) Điều cực kỳ quan trọng cần phải lưu ý
là sự phân loại đơn giản trên không phải bao giờ cũng vận hành Một số rủi ro đơn thuần là không thể tiên đoán được trước
Xác định rủi ro liệt kê những rủi ro dự án riêng bên trong cả loạt các rủi
ro chung đã được nêu đại cương ở trên Một trong những phương pháp tốt nhất để hiểu từng rủi ro là dùng một tập các câu hỏi giúp cho người lập kế
Trang 38hoạch dự án hiểu được rủi ro trong dự án hay các thuật ngữ kỹ thuật Bohm gợi ý dùng từ “danh sách khoản mục rủi ro” – một tập các câu hỏi liên quan tới từng nhân tố rủi ro Chẳng hạn, người lập kế hoạch có thể đạt tới cảm nhận
về rủi ro nhân viên bằng cách trả lời các câu hỏi sau:
• Có người giỏi nhất không?
• Mọi người có tổ hợp đúng tài năng không?
• Có đủ người sẵn có không?
• Các nhân viên có cam kết theo đuổi toàn bộ dự án không?
• Một số nhân viên dự án chỉ dành một phần thời gian cho dự án?
• Các nhân viên có mong đợi đúng việc hiện được giao không?
• Các nhân viên có được huấn luyện đầy đủ không?
• Có hay luân chuyển nhân viên làm gián đoạn công việc không?
Sự chắc chắn tương đối của câu trả lời cho những câu hỏi này sẽ cho phép người lập kế hoạch ước lượng được ảnh hưởng của rủi ro
2.3.3 Dự phòng rủi ro
Dự phòng (projection) rủi ro, cũng còn được gọi là ước lượng rủi ro, cố gắng xác định tỉ lệ từng rủi ro theo hai cách – có thể xảy ra tức là rủi ro là có thực và hậu quả của vấn đề liên quan tới rủi ro đó, nếu nó xuất hiện Người lập kế hoạch dự án cùng với các nhà quản lý khác và các nhân viên kỹ thuật, thực hiện bốn hoạt động dự phóng rủi ro: (1) lập thang phản ánh khả năng có thể xảy ra cảm nhận được rủi ro; (2) phác họa những hậu quả của rủi ro; (3) ước lượng ảnh hưởng của rủi ro lên dự án và sản phẩm, (4) và chú ý đến độ chính xác của dự phóng rủi ro sao cho không có sự hiểu lầm
Trang 39Thang có thể được xác định hoặc theo thuật ngữ có – không, định tính hay định lượng Về một cực, mỗi câu hỏi trong bảng khoản mục rủi ro đều có thể trả lời bằng “có” hay “không”, nhưng điều này thì không thực tế cho lắm Hiếm khi có thể định giá rủi ro theo cách tuyệt đối như vậy Cách tiếp cận tốt hơn có thể là trả lời theo tỉ lệ xác suất định lượng có các giá trị sau: gần như hoàn toàn không thể có, vừa phải, có thể, rất có thể Theo một cách khác, người lập kế hoạch có thể ước lượng xác suất tóan học mà một rủi ro có thể xảy ra (như xác suất 0.90 kéo theo rủi ro rất có thể xảy ra) Người ta có thể ước lượng xác suất số bằng cách dùng phân tích thống kê về các độ đo thu được từ các dự án quá khứ, từ trực giác hay các thông tin khác Chẳng hạn, nếu độ đo được thu thập từ 45 dự án chỉ ra rằng 37 dự án đã qua kinh nghiệm gấp đôi số những thay đổi của khách hàng so với dự kiến thì xác suất một dự
án mới bị thay đổi rất có thể sẽ vượt quá số thay đổi 37/45=0.82
Cuối cùng rủi ro được đánh trọng số bởi ảnh hưởng được cảm nhận (theo dự án) và rồi được sắp thứ tự ưu tiên Ba nhân tố chi phối ảnh hưởng: bản chất của rủi ro, phạm vi của nó và thời gian Bản chất của rủi ro chỉ ra vấn đề có thể xảy ra nếu nó xuất hiện Chẳng hạn, một giao diện ngoài kém xác định đối với phần cứng khách hàng (một rủi ro kỹ thuật) sẽ ngăn cản thiết
kế sớm và việc kiểm thử và rất có thể sẽ dẫn tới vấn đề tích hợp hệ thống về sau trong dự án Phạm vi của một rủi ro tổ hợp cả sự ngặt nghèo (vấn đề nghiêm trọng đến đâu?) với phân bố tổng thể của nó (dự án sẽ bị ảnh hưởng đến đâu hay bao nhiêu khách hàng sẽ phải chịu thiệt hại?) Cuối cùng thời gian của một rủi ro đề cập đến khi nào thì có tác động của rủi ro và nó kéo dài bao lâu Trong phần lớn trường hợp, người quản lý dự án có thể muốn “tin dữ” xuất hiện sớm nhất có thể được, nhưng trong một số trường hợp, để trễ càng lâu lại càng tốt hơn
Trang 40Xem trong hình 2.3, tác động và xác suất của rủi ro có ảnh hưởng phân biệt lên mối quan tâm quản lý Nhân tố rủi ro có trọng số tác động cao nhưng
có xác suất xuất hiện rất thấp không nên làm tổn phí nhiều thời gian quản lý Tuy nhiên, các rủi ro có tác động cao với xác suất từ trung bình đến cao và các rui ro tác động thấp nhưng xác suất cao thì nên được đưa vào bước phân tích rủi ro
Hình 2.3 Rủi ro và mối quan tâm quản lý