Các kỹ thuật ứng dụng trong quản trị dự án phần mềm Quản trị phạm vi quản trị thời gian hoàn thành và rủi ro dự án phần mềm

Các kỹ thuật ứng dụng trong quản trị dự án phần mềm Quản trị phạm vi quản trị thời gian hoàn thành và rủi ro dự án phần mềm Các kỹ thuật ứng dụng trong quản trị dự án phần mềm Quản trị phạm vi quản trị thời gian hoàn thành và rủi ro dự án phần mềm luận văn tốt nghiệp thạc sĩ

-

LUẬN VĂN THẠC SĨ KHOA HỌC

CÁC KỸ THUẬT ỨNG DỤNG TRONG QUẢN TRỊ DỰ

DANH 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

Hì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

MỞ ĐẦ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

CHƯƠ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à

khô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 đã

đượ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

Quả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ị

Quyề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

Trong 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

Tạ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í

Đá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

Sau 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

sự 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

Nế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:

• 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ự

á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%

- Đà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

CHƯƠ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

Khí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ý

2.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

cầ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

trì 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

Độ 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

quan 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

Lị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

Thự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

2.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

Hì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

tră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)

PERT 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

sơ đồ 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

ngà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

Xâ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ụ

cầ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

giai đ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

2.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ế

hoạ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

Thang 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

Xem 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ý