Bài giảng Xây dựng và quản lý dự án hệ thống thông tin

Dẫn nhập  Xác định dự án  Phân tích khả thi  Chọn lựa dự án  Quản lý dự án 

ppt66 trang | Chia sẻ: hao_hao | Lượt xem: 2622 | Lượt tải: 3download
Bạn đang xem trước 20 trang tài liệu Bài giảng Xây dựng và quản lý dự án hệ thống thông tin, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Xây dựng & Quản lý Dự án HTTT Xây dựng và quản lý dự án HTTT Dẫn nhập  Xác định dự án Phân tích khả thi Chọn lựa dự án Quản lý dự án 1. Dẫn nhập Dự án là gì? Dự án là tập các hoạt động nhằm tạo ra một HTTT mang lại các giá trị công việc hoặc kinh doanh cho tổ chức. Tập các hoạt động có thời điểm bắt đầu và thời điểm kết thúc rõ ràng. Dự án HTTT phải được bắt đầu bằng việc hiểu rõ HT sẽ cải tiến công việc hoặc kinh doanh của tổ chức ra sao. Nói khác đi, phải hình dung được HT mang lại những giá trị nào cho tổ chức. Đặc điểm của dự án. Nhiều người liên quan. Những người liên quan ở nhiều đơn vị. Hướng về mục tiêu. Các công việc có thứ tự nhất định. Có sản phẩm rõ ràng khi kết thúc. Nhiều ưu tiên khác nhau. Việc truyền thông xuyên qua tổ chức. Đặc điểm của dự án (tiếp theo). Nhiều hoạt động và hoạt động phức tạp. Mang tính duy nhất. Có ngày bắt đầu và ngày kết thúc. Có rủi ro và những điều không chắc chắn. Nguồn lực và tài chính có giới hạn. Những người liên quan có thể xác định. Xây dựng và quản lý dự án HTTT Dẫn nhập Xác định dự án  Phân tích khả thi Chọn lựa dự án Quản lý dự án 2. Xác định dự án Khi một nhóm người trong tổ chức (TC) xác định tồn tại nhu cầu công việc hay kinh doanh (business needs) mà tổ chức cần phải đáp ứng, từ đó thúc đẩy ý tưởng cần một HTTT tốt hơn để có thể đáp ứng nhu cầu  DA bắt đầu hình thành. Bối cảnh hình thành DA thường như sau: Vấn đề, khó khăn  nhu cầu  giải pháp … hình thành DA Giám đốc dự án hay người chịu trách nhiệm dự án (project sponsor) là người nhận thức được nhu cầu công việc hoặc kinh doanh mà HT mới cần phải đáp ứng. Giám đốc dự án sẽ làm việc trong suốt các giai đoạn của vòng đời phát triển HT nhằm bảo đảm dự án đi đúng hướng dưới quan niệm công việc hoặc kinh doanh. Vai trò giám đốc dự án như là điểm liên hệ chính (primary point of contact) trong quá trình xây dựng HT. Tùy theo kích cỡ và phạm vi của DA mà Giám đốc DA có thể là một người hoặc một nhóm người (nhà quản lý + chuyên viên IT). Khi hình thành DA cần xác định mục tiêu DA. Ta có mối liên hệ: Nhu cầu công việc / kinh doanh  Yêu cầu công việc HT  Mục tiêu DA. Yêu cầu công việc HT ở thời điểm này được hiểu là yêu cầu công việc / kinh doanh mức cao (high-level business requirements), cần phải được thông qua bởi tổ chức. - Mức cao ám chỉ sự trừu tượng, tổng quát. - Yêu cầu là những gì HT phải thực hiện hoặc những chức năng mà HT phải có. Giám đốc DA cần phải hiểu rõ mục tiêu DA và nhận thức được các giá trị công việc / kinh doanh (business values) sẽ đạt được từ HT. Giá trị bao gồm các giá trị cụ thể (tangible values) và giá trị mơ hồ (intangible values). Các giá trị cụ thể có thể đo được và lượng hóa dễ dàng (giảm 2% chi phí vận hành HT). Các giá trị mơ hồ hình thành từ trực giác, sự tin tưởng có cơ sở về những lợi ích khó đo được mà HT sẽ đem lại cho tổ chức (cải tiến phục vụ khác hàng, tăng sức cạnh tranh). Tóm lại, trong quá trình xác định DA thì Giám đốc DA cần làm rõ: Nhu cầu công việc, kinh doanh của TC. - Yêu cầu công việc, kinh doanh của HT. - Những giá trị công việc, kinh doanh mà HT sẽ mang lại cho TC. Trong nhiều tổ chức, khâu xác định dự án thường được bắt đầu bởi một kỹ thuật gọi là xác định yêu cầu hệ thống (System Request). (System’s Business Requirements  System Request) Yêu cầu HT (System Request) là một tài liệu mô tả lý do tại sao phải xây dựng HT và những giá trị mà tổ chức mong muốn HT sẽ mang lại. Bản yêu cầu HT được hoàn thành bởi Giám đốc dự án. Bản yêu cầu hệ thống thường có năm phần: 1. Project Sponsor 2. Business Need 3. Business Requirements 4. Business Value 5. Special Issues or Constraints Bản yêu cầu hệ thống đầy đủ cần được đệ trình lên để tổ chức xem xét (Hội đồng Quản trị, Ban Giám đốc, …) và thông qua. Sau khi thông qua yêu cầu HT, PTV cần tiến hành phân tích khả thi nhằm đạt được những hiểu biết đầy đủ hơn về những cơ hội cũng như hạn chế liên quan đến khả năng thực hiện DA. Phân tích khả thi là bước rất quan trọng vì nó giúp ta xem xét các yếu tố giúp thực hiện dự án thành công cũng như các rủi ro có thể ảnh hưởng đến sự thất bại của dự án. Xây dựng và quản lý dự án HTTT Dẫn nhập Xác định dự án Phân tích khả thi  Chọn lựa dự án Quản lý dự án 3. Phân tích khả thi Phân tích khả thi (feasibility analysis) sẽ thu thập thông tin nhằm hướng dẫn tổ chức quyết định xem có nên tiếp tục thực hiện dự án hay không, hay cần điều chỉnh mục tiêu, phạm vi dự án một cách phù hợp hơn. Phân tích khả thi cũng xác định những rủi ro chủ yếu (important risks) có thể có đối với dự án. Những rủi ro này phải được chú ý đến nếu như dự án được thông qua bởi tổ chức. Phân tích khả thi bao gồm các phân tích: Khả thi kỹ thuật (technical feasibility). - Khả thi tài chính (economic feasibility). - Khả thi tổ chức (organizational feasibility). Phân tích khả thi kỹ thuật Nhằm trả lời câu hỏi “liệu chúng ta có đủ khả năng kỹ thuật để xây dựng HT hay không?” - NSD và PTV có quen thuộc, kinh nghiệm đối với lĩnh vực công việc, kinh doanh của TC? - Đội ngũ thực hiện DA có quen thuộc với kỹ thuật xây dựng HT? Phân tích khả thi kỹ thuật còn liên quan đến: - Kích thước, độ phức tạp của DA (bao nhiêu người tham gia, thời gian thực hiện)? - HT mới tương thích với HT hiện thời ra sao (trao đổi, chia sẻ dữ liệu)? Phân tích khả thi tài chính Nhằm trả lời câu hỏi “liệu chúng ta có nên xây dựng HT hay không?” - Xác định chi phí và lợi ích. - Gán giá trị cho chi phí và lợi ích. - Xác định dòng chảy tiền mặt. - Đánh giá khấu hao. Xác định chi phí và lợi ích. Chi phí phát triển HT (lương đội ngũ thực hiện DA, tiền thuê tư vấn, chi phí phần cứng và phần mềm, tiền huấn luyện, tiền thuê mướn văn phòng và thiết bị, …). Các chi phí phát triển HT chỉ trả một lần. Chi phí vận hành HT (lương đội ngũ kỹ thuật như nhà quản trị mạng, chi phí nâng cấp phần cứng, bảo trì phần mềm, …). Các chi phí vận hành HT được trả theo thời gian khi HT bắt đầu hoạt động, không trả một lần. Xác định chi phí và lợi ích (tiếp theo). Lợi ích xác định được tức là những lợi ích có thể đo lường, đánh giá qua con số được (giảm nhân viên, tăng lương, giảm thời gian xử lý công việc, …). Lợi ích không xác định được tức là những lợi ích khó đánh giá bằng con số, dựa trên trực giác, kinh nghiệm nhiều hơn (tăng khả năng cạnh tranh, tăng năng lực đội ngũ nhân viên, cải tiến chất lượng phục vụ khách hàng, theo dõi số liệu hàng hóa chặt chẽ hơn, …). Bảng phân tích chi phí - lợi ích Các chi phí và lợi ích mơ hồ thường gây khó khăn cho việc xác định chi phí và lợi ích. Tuy nhiên chúng lại rất cần thiết để trả lời câu hỏi “HT sẽ mang lại những giá trị gì cho tổ chức?” Sau khi xác định các chi phí và lợi ích, cần gán các số tiền ước tính cho chúng. Công việc này khó khăn vì HT chưa thực hiện, chưa được phân tích và thiết kế kỹ. Dùng biện pháp ước tính và chấp nhận sai số  Cần tư vấn kết hợp kinh nghiệm. Cần phải lượng hóa các chi phí và lợi ích mơ hồ không xác định được. Liệt kê và thảo luận nhiều hơn những chi phí và lợi ích mơ hồ không thể lượng hóa. Việc phân tích lợi ích và chi phí không mang tính thời điểm mà mang tính quá trình tức là có yếu tố thời gian. Việc xác định dòng chảy tiền mặt (cash flow) giúp cho thấy sự so sánh giữa chi phí và lợi ích theo thời gian. Nhược điểm của xác định dòng chảy tiền mặt là không cho ta thấy được mức khấu hao của chi phí cũng như lợi ích qua thời gian  Đánh giá khấu hao. Xác định dòng chảy tiền mặt Đánh giá khấu hao PV nghĩa là Present Value, NPV nghĩa là Net Present Value. Phân tích khả thi tổ chức Nhằm trả lời câu hỏi “nếu chúng ta xây dựng HT, liệu HT có được người dùng chấp nhận không và HT có kết hợp được với guồng máy hoạt động hiện thời không?” Mục tiêu dự án có sát với với mục tiêu kinh doanh hoặc chiến lược phát triển của tổ chức? - Phân tích khả thi tổ chức đối với những người liên quan đến DA (stakeholders)? - Sự chấp nhận thay đổi, sự tham gia của NSD trong quá trình triển khai DA ra sao? Những người quan trọng cần quan tâm trong quá trình phân tích khả thi tổ chức (important stakeholders): Project champion(s). Organizational Managers. System Users. Cần nhận thức và hiểu được vai trò của những người này đối với khả thi tổ chức vì họ có ảnh hưởng đến việc chấp nhận hệ thống hay không khi nó được bàn giao sau khi xây dựng. Xây dựng và quản lý dự án HTTT Dẫn nhập Xác định dự án Phân tích khả thi Chọn lựa dự án  Quản lý dự án 4. Chọn lựa dự án Từ bản yêu cầu hệ thống (System Request) và kết quả phân tích khả thi, tổ chức (Hội đồng Quản trị, Ban giám đốc, …) xem xét: Giá trị DA mang lại cho TC (yêu cầu HT). - Rủi ro khi xây dựng HT (phân tích khả thi). Việc xem xét được thực hiện trong bối cảnh tổ chức có nhiều DA cần thực hiện cùng lúc nhưng tài nguyên thì có hạng. Từ đó quyết định tiến hành hay hủy bỏ DA. Việc chọn lựa thực hiện dự án thường được xem xét dựa trên các yếu tố: Kích cỡ dự án. Chi phí thực hiện. Mục đích của dự án. Thời gian thực hiện. Mức độ rủi ro. Phạm vi dự án. Khả năng hoàn vốn đầu tư. Xây dựng và quản lý dự án HTTT Dẫn nhập Xác định dự án Phân tích khả thi Chọn lựa dự án Quản lý dự án  5. Quản lý dự án Quản lý dự án (project management) là quá trình lập kế hoạch và kiểm soát sự phát triển của HT trong một khung thời gian và chi phí xác định. Nhà quản trị dự án (project manager) là người chịu trách nhiệm chính quản lý các công việc và vai trò mà chúng cần được phối hợp với nhau một cách cẩn thận trong quá trình thực hiện DA. Ngày nay, quản trị DA thực sự được xem là một nghề chuyên môn, và PTV cần được đào tạo về chuyên môn này. Yếu tố then chốt giúp việc quản trị DA thành công là cần sự đánh giá xác thực những công việc cần được hoàn thành và quản lý dự án ứng với những đánh giá đó. Bốn bước chính trong quản trị dự án: Xác định kích cỡ dự án. Lập và quản lý kế hoạch công việc. Tuyển dụng nhân viên. Phối hợp các hoạt động dự án. Xác định kích cỡ dự án Quản trị dự án liên quan đến việc cân nhắc hoặc thỏa hiệp giữa ba yếu tố kích cỡ dự án (theo nghĩa những gì DA thực hiện), chi phí thực hiện dự án và thời gian hoàn thành dự án. Project Size Project Cost Project Time Điều chỉnh một thành phần sẽ ảnh hưởng đến các thành phần còn lại Việc xác định kích cỡ dự án còn được gọi là ước lượng dự án (project estimation). Cơ sở để ước lượng DA bao gồm: Phương pháp xây dựng HT đang dùng. Những dự án được hoàn thành trước đó. Kinh nghiệm của nhà phát triển hệ thống. Ước lượng DA là một quá trình, bắt đầu với các ước lượng thô sau đó được làm rõ và cụ thể dần khi dự án được tiến hành. Có hai cách cơ bản để tính thời gian cần thiết hoàn thành dự án. Dùng thời gian dành cho việc thực hiện giai đoạn lập kế hoạch để dự đoán thời gian cần thiết cho toàn bộ DA, dựa trên mức phần trăm chuẩn công nghiệp, hoặc mức phần trăm của kinh nghiệm của chính tổ chức. Dùng phương pháp cho điểm chức năng (FP - Function Point Approach) để tính thời gian cần thiết cho toàn bộ DA. Ví dụ tính thời gian cần thiết hoàn thành dự án dựa trên mức phần trăm chuẩn công nghiệp Dùng phương pháp FP để tính thời gian cần thiết hoàn thành dự án. FP gọi là điểm chức năng, được xem như là công cụ dùng để đo kích thước chương trình. Việc tính thời gian cần cho dự án được thực hiện qua ba bước: 1. Tính độ lớn hệ thống (theo FP và dòng lệnh). 2. Tính công sức cần cho DA (person-months). 3. Tính thời gian cần cho DA (months). Tính độ lớn HT (theo FP và số dòng lệnh): Cho điểm chức năng dựa trên đánh giá độ phức tạp của các thành phần trong HT. Các thành phần này bao gồm inputs, outputs, queries, files và program interfaces  cho kết quả là Total Unadjusted Function Points (TUFP). Cho điểm sự phức tạp của các khía cạnh của HT. Các khía cạnh này bao gồm data communications, transaction rate, complex processing, …  cho kết quả là Total Processing Complexity (PC). Dùng PC để điều chỉnh giá trị của TUFP  cho kết quả là Total Adjusted Function Points (TAFP)  tính số dòng lệnh cần lập trình cho hệ thống. Processing Complexity (PC) = 7 Adjusted Processing Complexity (PCA) = 0.65 + ( 0.01 x 7 ) = 0.72 Total Adjusted Function Points (TAFP) = 0.72 (PCA) x 338 (TUFP) = 243 Lines of code = 243 (TAFP) x 30 (VB) = 7290 (Hệ số 30 ứng với việc dùng ngôn ngữ lập trình Visual Basic để coding) Tính công sức cần cho DA (person-months): Công sức (effort) là hàm của độ lớn hệ thống và tốc độ sản xuất (lượng công việc mà một người có thể hoàn thành trong một thời gian xác định). Nghiên cứu đưa ra mô hình COCOMO để ước tính công sức theo số dòng lệnh cần lập trình cho hệ thống. Theo mô hình COCOMO thì ước tính như sau: Công sức (person-months) = 1.4 x Số ngàn dòng lệnh - Ví dụ với 7290 dòng lệnh lập trình bằng VB thì cần công sức là 7.290 x 1.4 = 10.20 person-months. Tính thời gian cần cho DA (months): Ước tính theo công thức: Thời gian (months) = 3.0 x Công sức1/3 Ví dụ với công sức là 10.20 person-months thì ước tính thời gian cần cho dự án là 3.0 x 10.201/3 Chú ý thời gian ước tính trên dành cho các giai đoạn phân tích, thiết kế và thực hiện; nó không bao gồm cho giai đoạn lập kế hoạch. Chú ý công thức ước tính công sức theo mô hình COCOMO trên chỉ áp dụng cho những dự án phần mềm quản lý có qui mô nhỏ đến vừa (khoảng 100000 dòng lệnh và cần đến 10 lập trình viên hoặc ít hơn). Lập và quản lý kế hoạch công việc Bản kế hoạch công việc (workplan) là một thời gian biểu động ghi chép lại và theo dõi tất cả các tác vụ (tasks) cần phải được hoàn thành trong quá trình thực hiện dự án. Tính “động” (dynamic) ở đây nhằm nói đến sự cập nhật và điều chỉnh các tác vụ trong bản kế hoạch công việc trong khi dự án được tiến hành. (Từ tác vụ có thể được hiểu là những công việc cụ thể và xác định cần phải thực hiện. Một công việc được mô tả bởi một số các tác vụ.) Để lập bản kế hoạch công việc, trước hết nhà QTDA phải xác định được các tác vụ cần phải thực hiện. Sau đó các tác vụ sẽ được trình bày trong bản kế hoạch công việc ở dạng đồ họa bằng sơ đồ Gantt hay sơ đồ PERT. Những kỹ thuật trên giúp nhà QTDA hiểu và quản lý được sự tiến triển của DA theo thời gian. Nhà QTDA có thể dùng phần mềm MS Project để lập bản kế hoạch công việc sau khi xác định được các tác vụ cần thực hiện. Làm thế nào để xác định được các tác vụ? Dựa vào mục tiêu dự án, thường được liệt kê trong bản yêu cầu HT (System Request). Dựa vào phương pháp luận hiện dùng để xây dựng hệ thống (VD mô hình thác nước). Dựa vào kinh nghiệm quản trị các dự án tương tự đã được thực hiện thành công. Ngoài ra cần xác định mối liên hệ giữa các tác vụ (thứ tự thực hiện giữa các tác vụ). Với mỗi tác vụ cụ thể, cần phải xác định đầy đủ các thông tin sau: THÔNG TIN TÁC VỤ Tên của tác vụ Ngày bắt đầu Ngày hoàn thành Cá nhân chịu trách nhiệm thực hiện Kết quả do tác vụ tạo ra Tình trạng hoàn thành Mức ưu tiên Các tài nguyên cần cho việc thực hiện Thời gian thực hiện ước tính Thời gian thực hiện thực tế Một kỹ thuật thường dùng để xác định tác vụ là phân nhỏ công việc (kỹ thuật WBS). Phân chia một công việc lớn (work) thành các công việc nhỏ hơn. Với mỗi công việc nhỏ (subwork) lại phân chia nó thành các công việc nhỏ hơn nữa. Khi một công việc nhỏ được xác định thì ta xem nó là một tác vụ (task). Sắp xếp các tác vụ vào một danh sách phân cấp có đánh số. Danh sách này được gọi là một cấu trúc phân chia công việc (WBS – Work Breakdown Structure), và nó chính là xương sống của bản kế hoạch công việc. Bản kế hoạch công việc được tạo ra bằng cách liệt kê tất cả các tác vụ trong cấu trúc WBS với sự bổ sung các thông tin sau: Khoảng thời gian ước tính cho tác vụ. Cập nhật tình trạng hiện thời của tác vụ. Sự phụ thuộc lẫn nhau giữa các tác vụ. Các mốc thời gian quan trọng. Nhà QTDA có thể dùng sơ đồ Gantt hoặc sơ đồ PERT để trình bày bản kế hoạch công việc. Mỗi sơ đồ có những ưu điểm riêng. Ví dụ sơ đồ Gantt Ví dụ sơ đồ Gantt Ví dụ sơ đồ Gantt Ví dụ sơ đồ Gantt Ví dụ sơ đồ Gantt Ví dụ sơ đồ PERT 1 2 3 4 5 6 Locate facilities Order furniture Furniture setup Interview Hire and train Remodel Move in Ví dụ sơ đồ PERT 1 2 3 5 6 Locate facilities Order furniture Furniture setup Interview Remodel Move in 4 Hire and train 7 S Ví dụ sơ đồ PERT Ví dụ sơ đồ PERT 1 Start 0 days 2 Select Software 5 days 3 Select Hardware 3 days 4 Purchase System 1 day 5 Delivery Lag 5 days 7 Install System 1 day 6 Train User 3 days 8 Finish 0 days Sơ đồ Gantt. Dạng sơ đồ hình thanh. - Giám sát tình trạng DA ở thời điểm bất kỳ. Sơ đồ PERT. Dạng lưu đồ. - Thấy được sự phụ thuộc các tác vụ. - Tính được hiểm lộ (critical path). Quá trình ước tính các tham số cho mỗi tác vụ trong bản kế hoạch công việc (sơ đồ Gantt, sơ đồ PERT) là quá trình làm mịn dần khi DA được tiến hành. Planning Analysis Design Implementation Việc thay đổi các tham số của tác vụ trong bản kế hoạch công việc được tiến hành như mô hình dự báo bão Tuyển dụng nhân viên Tuyển dụng nhân viên nhằm nói đến các vấn đề sau: Xác định xem dự án cần tất cả bao nhiêu người làm việc. Những người này cần có năng lực gì (kiến thức, kỹ năng chuyên môn và cá nhân). Phân công người có năng lực phù hợp với nhu cầu dự án. Động viên, thúc đẩy tinh thần nhân viên hướng đến hoàn thành mục tiêu dự án. Giảm thiểu tối đa các mâu thuẫn nảy sinh giữa các nhân viên trong quá trình thực hiện dự án. Quản lý và giải quyết mâu thuẫn một cách thích hợp. Nhà QTDA cần phải lập kế hoạch nhân dự cho dự án. Số lượng nhân viên cần cho dự án thường dựa trên ước tính công sức (effort) và thời gian cần cho dự án. Ví dụ với dự án cần đến công sức 40 person-months và thời gian là 10 tháng thì trung bình cần có một nhóm khoảng 4 nhân viên làm việc toàn thời gian. Qui tắc kinh nghiệm cho thấy một nhóm làm việc tốt không nên quá 10 người. Nếu cần nhiều hơn có thể chia thành các nhóm con. Phối hợp các hoạt động dự án Quản lý dự án không phải là sự quản lý các tác vụ một cách độc lập và riêng rẻ. Giữa các tác vụ luôn có sự phụ thuộc vào nhau. Kết quả của tác vụ này có thể là điều kiện thực hiện cho tác vụ khác. Sự chậm trễ hoặc thất bại của một tác vụ có thể ảnh hưởng đến việc thực hiện tác vụ khác. Quản lý rủi ro là hoạt động quan trọng trong quá trình phối hợp các hoạt động dự án. Trong thực tế luôn có sự thay đổi trong quá trình thực hiện dự án: Thay đổi phạm vi  quản lý phạm vi. Thay đổi mục tiêu  điều chỉnh mục tiêu. Thay đổi nguồn lực  điều chỉnh tác vụ. Quản lý sự thay đổi là công việc khó khăn của nhà QTDA, nhưng việc này luôn xảy ra trong thực tế. Có người ví von: “Lập kế hoạch để mà thay đổi”  Lập kế hoạch giúp ta chủ động đối phó với sự thay đổi để giảm thiểu, khắc phục rủi ro để hoàn thành dự án (đáp ứng nhu cầu, đúng thời gian, không vượt chi phí). Tóm lại, chúng ta đã nói về … Dẫn nhập  Xác định dự án  Phân tích khả thi  Chọn lựa dự án  Quản lý dự án 

Các file đính kèm theo tài liệu này:

  • pptxay_dung_va_quan_ly_da_7795.ppt
Tài liệu liên quan