Giáo trình Quản lý dự án công nghệ thông tin - Đại học Công nghệ Thông tin

Nội dung text: Giáo trình Quản lý dự án công nghệ thông tin - Đại học Công nghệ Thông tin

1. TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN QUẢN LÝ DỰ ÁN CÔNG NGHỆ THÔNG TIN TP. HỒ CHÍ MINH 3/2010
2. Mục lục NHẬP ĐỀ 6 1. Khái niệm chung về dự án 6 2. Dự án Công nghệ thông tin 6 3. Đặc trưng của một dự án 7 4. Phân loại dự án 8 5. Thế nào là quản lý dự án 10 6. Các bên liên quan đến dự án 14 Câu hỏi 15 Phần I - Chu trình dự án và quản lý theo giai đoạn 16 Chương 1. Tổng quan về các giai đoạn của dự án CNTT 16 1.1 Một cách tiếp cận rõ ràng và tuần tự 16 1.2 Bẩy giai đoạn của dự án CNTT 16 1.3 Minh hoạ cho các giai đoạn của dự án 19 Câu hỏi 22 Chương 2. Giai đoạn xác định 23 2.1 Đề cương dự án 24 2.2 Tài liệu nghiên cứu khả thi 25 2.3 Tài liệu yêu cầu 25 2.4 Danh sách các rủi ro 27 2.5 Kế hoạch ban đầu 27 2.6 Đề xuất giải pháp cho người dùng 34 2.7 Kết luận 36 Câu hỏi 36 Chương 3. Giai đoạn phân tích 37 3.1 Mục tiêu 37 3.2 Các công việc phải thực hiện 37 3.3 Viết tài liệu “đặc tả chức năng” 38 3.4 Dàn bài của đặc tả chức năng 39 3.5 Xem xét lại kế hoạch 41 3.6 Kế hoạch dự án cuối cùng 41 3.7 Thiết kế tổng thể 41 3.8 Kết luận 42 Câu hỏi 42 Chương 4. Giai đoạn thiết kế 43 4.1 Mục tiêu 43 4.2 Các công việc 43 4.3 Một số chú ý 44 4.4 Đặc tả thiết kế 44 4.5 Một số vấn đề trong quá trình thiết kế 46 4.5.1 Đội thiết kế 46 4.5.2. Rà soát lại bản thiết kế 46 4.6 Vấn đề chấp nhận dự án 46 2
3. 4.6.1 Phương pháp cổ điển: 46 4.6.2 Phương pháp trình diễn hoặc kiểm tra lần lượt tất cả các chức năng: 47 4.7 Xem xét lại các ước lượng 48 4.8 Kết luận 48 Câu hỏi 48 Chương 5. Giai đoạn thực hiện 49 5.1 Nhập đề 50 Thiết kế 50 Cài đặt thực hiện 50 5.2 Tổ chức lập trình các module cơ bản; ghép nối hệ thống 50 5.2.1 Những nguyễn tắc cơ bản trong quản lý thực hiện và cài đặt hệ thống 50 5.2.2 Các công việc chuẩn bị trước khi tiến hành lập trình, cài đặt 51 5.2.3 Các bước lập trình 52 5.2.4 Các công cụ trợ giúp lập trình 58 5.2.5 Những điểm lưu ý trong tổ chức công việc lập trình 59 5.3 Mua sản phẩm 61 5.3.1 Tài liệu gọi thầu: 61 5.3.2 Nhận hồ sơ dự thầu: 61 5.3.3 Đánh giá, thẩm định các hồ sơ dự thầu: 61 5.3.4 Đàm phán và ký hợp đồng 62 5.3.5 Mua sản phẩm 63 5.3.6 Kiểm tra, chấp nhận: 63 5.3.7 Cài đặt tính hợp lệ hệ thống: 64 Câu hỏi 64 Chương 6. Giai đoạn kiểm thử hệ thống 65 6.1 Nhập đề 65 6.2 Kế hoạch kiểm thử hệ thống 66 6.3 Tích hợp hệ thống 67 6.3.1 Thứ tự tích hợp phần mềm: 67 6.3.2 Quá trình tích hợp hệ thống (phần mềm) 69 6.3.3 Một vài giải pháp 70 6.3.4 Thứ tự tích hợp phần cứng 70 6.3.5 Thứ tự tích hợp hệ thống (phần cứng + phần mềm) 70 6.4 Kiểm thử hồi qui 71 6.5 Dữ liệu kiểm thử 72 6.6 Tổ chức quá trình kiểm thử 72 6.7 Lưu giữ các kết quả kiểm thử 72 6.8 Kiểm thử lần cuối 73 6.9 Các công cụ kiểm thử hệ thống 74 6.9.1 Hệ quản lý mã (Code Management System CMS) 74 6.9.2 Hệ quản lý kiểm thử (Test Manager) 75 6.9.3 Hệ phân tích mã nguồn (Source Code Analyzer) 75 6.9.4 Hệ phân tích bao quát hiệu năng (Performance Coverage Analyzer) 75 6.9.5 Hệ quản lý Mođun (Module Management System) 75 Câu hỏi 76 Chương 7. Giai đoạn kiểm thử chấp nhận 77 7.1 Nhập đề 77 3
4. 7.2 Người chấp nhận sản phẩm 78 7.3 Vai trò quản lý dự án trong giai đoạn kiểm thử chấp nhận 78 7.4 Danh sách các bước kiểm tra chấp nhận 78 7.5 Chạy các kiểm thử chấp nhận 79 7.6 Kết luận về giai đoạn chấp nhận 80 Câu hỏi 80 Chương 8. Giai đoạn vận hành và khai thác hệ thống 82 8.1 Nhập đề 83 8.2 Dịch vụ bảo hành 83 8.3 Chào hàng bán sản phẩm, thực hiện các dự án tiếp 84 8.4 Bảo trì hệ thống 84 8.5 Hợp đồng đánh giá sau khi kết thúc dự án 84 8.6 Danh sách các công việc trong giai đoạn vận hành 85 8.7 Kết thúc vận hành 85 Câu hỏi 85 Lời kết phần một của tài liệu 86 Phần 2 - Các kĩ năng quản lý dự án 87 Chương 9. ước lượng 87 9.1 Giới thiệu 87 9.2 Kỹ thuật ước lượng 87 9.3 Ước lượng giai đoạn phân tích 95 9.4 Tỉ số 99 9.5 Qui tắc ước lượng theo kinh nghiệm của DEC (và các công ty lớn khác) 100 9.6 Tiến trình ước lượng 101 9.7 Kết luận về ước lượng 103 Câu hỏi 103 Chương 10. Lập lịch 104 10.1 Giới thiệu 104 10.2 Sơ đồ PERT 104 10.3 Cấp phát tài nguyên 109 10.4 Ràng buộc bộ ba 112 10.5 Lịch biểu hay sơ đồ Gantt 115 10.6 Tập trung vào đường găng 117 Câu hỏi 119 Chương 11. Quản lý rủi ro 120 Bước 1: Dự đoán rủi ro 120 Bước 2. Khử bỏ rủi ro ở mọi nơi có thể 124 Bước 3: Giảm bớt tác động của rủi ro bằng lập kế hoạch và định giá cho việc bất ngờ 124 Bước 4. Kiểm soát khi có điều trục trặc 125 Câu hỏi 125 Chương 12. Kiểm soát dự án 126 12.1 Giám sát dự án 126 12.2 Phát hiện và giải quyết các vấn đề 128 4
5. 12.3 Kiểm soát thông qua họp định kỳ, họp tổng quan kỹ thuật và các báo cáo134 Các cuộc họp định kỳ 134 Câu hỏi 140 Chương 13. Nhân sự dự án 141 13.1 Tổ chức dự án 141 13.2 Vai trò của GĐ dự án 144 13.3 Vai trò của PGĐ kỹ thuật 146 13.4 Vấn đề kiêm nhiệm 147 13.5 Vai trò của cán bộ lập trình 148 13.6 Vấn đề uỷ nhiệm 149 13.7 Vai trò của Trường phòng chuyên môn 150 13.8 Vai trò của phía khách hàng 150 13.9 Tuyển chọn nhân sự dự án 151 13.10 Tính cách của người làm quản lý dự án 152 13.11 Giao việc cho từng cá nhân 153 13.12 Động cơ thúc đẩy 153 Câu hỏi 155 Chương 14. Đánh giá tài chính và hiệu quả dự án 156 14.1 Mở đầu 156 14.2 Xác định chi phí dự án 156 14.3 Các phương pháp so sánh các phương án 157 14.3.1 Phân tích điểm hoà vốn 157 14.3.2 Phương pháp thời hạn thu hồi vốn đơn giản 158 14.3.3 Phương pháp thời hạn thu hồi vốn có chiết khấu: 159 14.4 So sánh theo các chỉ tiêu chất lượng 159 Câu hỏi 159 Phần III. Phần mềm hỗ trợ quản lý dự án 160 Chương 15. Giới thiệu phần mềm Microsoft Project 160 15.1 Quản lý dự án bằng Microsoft Project 160 15.2 Tạo lập và tổ chức một lịch biểu 161 15.3 Lập lịch cho các nhiệm vụ 164 15.4 Thêm thông tin nhân lực và phương tiện vào dự án 165 15.5 Gán chi phí cho nhiệm vụ và tài nguyên 167 15.6 Đánh giá vào điều chỉnh lịch biểu 168 15.7 In ấn báo cáo 170 5
6. NHẬP ĐỀ 1. Khái niệm chung về dự án Dự án là một hoạt động tạo ra - một cách có phương pháp và định tiến, với các phương tiện và nguồn lực đã cho - một sản phẩm mới hoặc một thực tế mới. Theo cách hiểu này, thì dự án phải có tính cụ thể và mục tiêu xác định, nhằm đáp ứng một nhu cầu chuyên biệt (của người dùng). Dự án cũng không phải là một nghiên cứu trừu tượng mà phải cấu trúc nên một thực tế mới chưa tồn tại trước đó. Mặc dù việc nghiên cứu, thử nghiệm và phát triển có thể là một phần nhất định trong dự án, nhưng cũng chỉ đóng vai trò hỗ trợ trong quá trình thực hiện mục tiêu cuối cùng của dự án mà thôi. Do vậy cần phân biệt rõ sự khác nhau giữa dự án và các đề tài nghiên cứu triển khai mà các cơ quan, đơn vị nghiên cứu vẫn thường làm. 2. Dự án Công nghệ thông tin Để góp phần thực hiện mục tiêu “Xây dựng những nền móng bước đầu vững chắc cho một kết cấu hạ tầng về thông tin trong xã hội có khả năng đáp ứng các nhu cầu cơ bản về thông tin trong quản lý nhà nước và trong các hoạt động kinh tế xã hội, đồng thời tích cực xây dựng ngành công nghiệp công nghệ thông tin (CNTT) thành ngành công nghiệp mũi nhọn của đất nước (Nghị quyết 49/CP ngày 4/8/1996), nhiều dự án CNTT đẫ được phát triển. Các dự án CNTT tập trung chủ yếu vào các nội dung sau: - ứng dụng CNTT trong các hoạt động quản lý và nghiệp vụ, trong đó trọng tâm là Tin học hoá phục vụ điều hành và quản lý Nhà nước; - Xây dựng hệ thống các Cơ sở dữ liệu (CSDL) quốc gia và chuyên ngành; - Phát triển tiềm lực và cơ sở hạ tầng về CNTT Nội dung cơ bản của các dự án đó đều xoay quanh các vấn đề về phần cứng, phần mềm, sự tích hợp giữa phần cứng/ phần mềm và con người. Cụ thể hơn, đó là những công việc liên quan đến chọn mua hoặc/và phân tích, thiết kế, xây dựng và tích hợp hệ thống máy móc, tổ chức thông tin, xây dựng các ứng dụng, đảm bảo trao đổi giữ các hệ thống cũng như đào tạo người sử dụng vận hành. Cần xác định rõ rằng bản thân các dự án CNTT chỉ tạo ra các công cụ và dịch vụ kỹ thuật mới để hỗ trợ hiệu quả hơn cho hoạt động của các nhà lãnh đạo, các nhà quản lý và đông đảo người dùng trong xã hội, chứ không thể thay thế và bao quát hết mọi vấn đề về nghiệp vụ ở mọi nơi, mọi chỗ. Do vậy, để đưa CNTT vào ứng dụng thực sự trong các hoạt động của nhà nước, đòi hỏi các cơ quan phải có các hoạt động khác, được thực hiện đồng bộ, để hoàn thiện cơ cấu tổ chức, hợp lý hoá các hệ thống thông tin dữ liệu, lựa chọn và động viên nguồn vốn, hợp lý hoá các hệ thống thông tin dữ liệu, lựa chọn và động viên nguồn vốn để phát triển các hoạt động nghiệp vụ của mình 6
7. Từ đây, khái niệm dự án trong giáo trình này sẽ được hiểu là các dự án CNTT, với sự tuân thủ các khái niệm, định nghĩa chung về dự án, với những nội dung đặc thù về CNTT như đã nêu ở trên. 3. Đặc trưng của một dự án 3.1 Mục tiêu của dự án Mọi dự án đều bắt đầu khi có một vấn đề được đặt ra trong thực tế. Kèm theo đó phải là những yêu cầu cần được giải quyết. Mục tiêu của dự án là giải quyết được vấn đề này. Các mục tiêu của dự án nhất thiết phải được viết ra một cách rõ ràng ngay từ đầu, nếu không khó có thể hoàn thành được Từ các mục tiêu chung của việc phát triển CNTT như đã nêu ở trên, mỗi dự án CNTT cần phải cụ thể hoá các mục tiêu của mình cả về mặt định tính và định lượng. Trên thực tế hiện nay, điều này không đơn giản vì muốn có mục tiêu cụ thể, phải xác định được yêu cầu thật cụ thể. Trong khi đó, có lẽ vì ứng dụng CNTT là công việc tương đối mới mẻ ở nước ta, nên nhiều khi người dùng cũng khó nêu rõ yêu cầu của mình, và do đó các mục tiêu được nêu lên hết sức chung chung. Điều này sẽ ảnh hưởng không ít tới sự thành bại của dự án mà chúng ta sẽ phân tích kỹ về sau này. 3.2 Thời gian dự án Đối với mỗi dự án phải xác định được một thời hạn tối đa phải hoàn thành, cụ thể hơn là phải có thời điểm bắt đầu và thời điểm kết thúc. Thời điểm bắt đầu là khi vấn đề giải quyết được đặt ra. Thời điểm kết thúc là hạn cuối cùng mà dự án phải hoàn thành. Thời điểm này phải được xác định rõ ràng, nếu không dự án có thể sẽ không bao giờ kết thúc. Trong thực tế, dự án luôn gặp phải những yêu cầu thay đổi khi đã ở gần giai đoạn cuối cùng. Nếu các thay đổi đó được coi như là một phần của dự án, thì dự án khó mà hoàn thành đúng hạn được. Vì vậy phải rất rõ ràng về thời điểm kết thúc, và hãy đưa những yêu cầu thay đổi này vào một dự án mới. Các dự án CNTT nằm trong khuôn khổ tổng thể của việc phát triển CNTT thường là những dự án trung hạn, kéo dài một vài ba năm. Tuy nhiên, để thực hiện từng bước, ta có thể phân các dự án đó thành các dự án nhỏ và hoàn thành trong thời gian từ vai ba tháng đến một năm để đáp ứng từng mục tiêu cụ thể trong mục tiêu chung của một dự án lớn. 3.3 Kinh phí của dự án Tương tự như trên, mọi dự án đều phải xác định một kinh phí tối đa, hay nói khác đi là một khoản tiền tối đa mà dự án có thể sử dụng. Mỗi dự án trong sự phát triển CNTT đều phải xác định tổng dự toán kinh phí cho toàn bộ quá trình thực hiện, phân bổ theo từng năm thực hiện. Cho đến hiện nay, 7
8. với các dự án CNTT lấy kinh phí từ ngân sách Nhà nước cuối năm đều có việc xem xét lại các kết qủa đã đạt được và trên cơ sở đó dự trù kế hoạch tài chính cho năm sau. Tuy nhiên, để đạt được hiệu quả cao, đồng bộ và tạo ra được những thay đổi cơ bản trong hoạt động quản lý, kinh tế xã hội, các dự án ứng dụng CNTT ở các Bộ ngành địa phương thường đòi hỏi những đầu tư khá lớn mà ngân sách Nhà nước khó có thể đáp ứng cân đối hoàn toàn được. Do vậy, các dự án đều được xác định nguồn vốn khác nhau có thể huy động được để đảm bảo được kinh phí cần thiết thực hiện dự án. 3.4 Nguồn nhân lực Là tất cả những người tham gia vào dự án. Mỗi dự án phải xác định danh sách những người tham gia, từ mức quản lý dự án đến những người thực hiện, triển khai. Nhân lực có thể huy động từ bên trong hoặc bên ngoài đơn vị, tuỳ theo nội dung từng công việc trong dự án. Các dự án ứng dụng CNTT thường luôn đòi hỏi phải có sự phối hợp chặt chẽ giữa các chuyên gia nghiệp vụ và chuyên gia tin học. Trong tình hình triển khai dự án Tin học hoá quản lý nhà nước năm nay, do lực lượng cán bộ tin học tại các đơn vị cơ sở còn thiếu, nên sự phối hợp với các chuyên gia bên ngoài là rất cần thiết. 3.5 Kết quả chuyển giao của dự án Là kết quả của dự án hay nói khác đi là sản phẩm cuối cùng của dự án. Mục tiêu của dự án thông thường là giải quyết vấn đề bằng việc tạo ra các kết quả này. Các kết quả và các mục tiêu nhất thiết phải được viết ra rõ ràng, nếu không mục đích của dự án sẽ không đạt được; sẽ tạo ra những kết quả sai khác đi và sẽ không ai hài lòng cả. 4. Phân loại dự án Dự án trong thực tế rất đa dạng, có thể phân loại theo nhiều cách khác nhau: 4.1 Theo tầm cỡ dự án: • Dự án lớn: được đặc trưng bởi tổng kinh phí huy động lớn, số lượng các bên tham gia đông, thời gian dàn trải, qui mô rộng lớn. Chúng đòi hỏi phải thiết lập các cấu trúc tổ chức riêng biệt, với mức phân cấp trách nhiệm khác nhau, đề ra quy chế hoạt động và các phương pháp kiểm tra chặt chẽ. Người quản lý các dự án này khó có thể đi sâu vào từng chi tiết trong quá trình thực hiện. Nhiệm vụ chủ yếu của họ là, một mặt thiết lập hệ thống quản lý và tổ chức, phân chia dự án thành các dự án bộ phận và phối kết các dự án bộ phận đó, cho phép mỗi mức thực hiện tốt trách nhiệm của mình; mặt khác đảm nhận các mối quan hệ giữa dự án với bên ngoài. 8
9. Việc xây dựng cả một hệ thống tin học lớn là một ví dụ. Dự án về Tin học hoá các hoạt động điều hành và quản lý nhà nước tại các Bộ ngành và địa phương (gọi tắt là dự án THH) có thể xem như là dứ án lớn đối với mỗi nơi. Người quản lý chính của dự án này phải là một nhà tổ chức tốt, xác định được rõ mục tiêu đặt ra, cũng như các dự án nhánh cần phải thực hiện và theo dõi phối hợp, thúc đẩy quá trình thực hiện toàn bộ dự án. Vai trò này ở các địa phương đang là cấp UBND tỉnh, thành. • Dự án trung bình và nhỏ: không dòi hỏi kinh phí nhiều, thời gian ấn định ngắn, không quá phức tạp Ví dụ, viết tài liệu nghiên cứu khả thi hay lập trình cho một modul đơn nào đó có thể coi như là một dự án nhỏ; việc tin học hoá điều hành và quản lý tại một VP UBND là dự án ở mức trung bình Người chủ dự án thường kiêm luôn cả việc quản lý dự án (đối nội) lẫn việc quan hệ với các chuyên gia bên ngoài. Kinh nghiệm các nước cho thấy những dự án trung bình hoặc nhỏ là những dự án cỡ ít hơn 15 người trong một năm. Đó có thể là dự án mà 5 người làm trong 3 năm, hoặc 15 người làm trong một năm. Dĩ nhiên, càng ít người tham gia thì việc quản lý dự án càng đỡ phức tạp hơn. • Về lý thuyết, quản lý dự án lớn hay nhỏ cũng đều theo những phương pháp luận như nhau cả. Dự án lớn có thể gọi là chương trình; chương trình thường được phân thành nhiều dự án nhỏ hơn. Trong trường hợp đó sẽ tồn tại nhiều mức quản lý dự án khác nhau, và để phân biệt có thể gọi những người quản lý bằng những tên khác nhau như người quản lý chương trình, người quản lý dự án, người điều hành dự án, nhóm trưởng, Thậm chí, mỗi một người tham gia vào dự án cũng phải biết cách tổ chức và quản lý công việc mà mình được giao. 4.2 Theo nội dung của dự án: Dự án trong sự phát triển CNTT có thể phân làm 3 loại chính: • Dự án ứng dụng CNTT trong công tác quản lý và hoạt động nghiệp vụ. Ví dụ, như dự án Tin học hoá hoạt động quản lý nhà nước tại các Bộ ngành và địa phương. • Dự án xây dựng cơ sở hạ tầng về CNTT trong đó có xây dựng cơ sở hạ tầng về kỹ thuật là dự án Mạng truyền thông dữ liệu quốc gia; xây dựng cơ sở hạ tầng về thông tin như dự án các CSDL quốc gia; phát triển tiềm năng nhân lực như dự án xây dựng các khoa CNTT tại các trường đại học chính của cả nước • Các dự án nhằm thực hiện nhiệm vụ đã phân công cho các Bộ ngành như phát triển nền Công nghiệp Công nghệ thông tin; đảm bảo đủ cán bộ tin học cho đất nước Nội dung của mỗi dự án có thể bao gồm nhiều vấn đề khác nhau, nhưng liên quan rất chặt chẽ, hỗ trợ lẫn nhau. Ví dụ như các hạng mục trong dự án THH văn phòng, như xây dựng hệ thống thông tin, xây dựng mạng máy tính, đào tạo phục vụ cho dự án 9
10. 4.3 Theo số người thực hiện dự án: Môt dự án có thể được thực hiện bởi một người hoặc nhiều người. Việc quản lý dự án sẽ khó khăn hơn khi có từ hai người trở lên. Nên sử dụng số người tối thiểu (và vẫn có những thời hạn nhất định cho họ). Như đã nêu trên, các dự án CNTT có tầm cỡ khó có thể do một người thực hiện mà xong được. Do vậy vấn đề quản lý dự án một cách nghiêm túc là hết sức cần thiết và không phải là dễ dàng; đặc biệt vai trò phối hợp của những người quản lý ở mức trên trong những dự án như vậy rất quyết định cho sự thành bại của toàn bộ dự án. 4.4 Nội bộ hay bên ngoài Dự án nội bộ là dự án của một đơn vị tổ chức thực hiện nhằm phục vụ cho yêu cầu của chính tổ chức đó. Dự án bên ngoài là dự án được thực hiện để đáp ứng yêu cầu cho một đơn vị nơi khác. Ví dụ như một người ký hợp đồng thực hiện một dự án cho đơn vị nào đó. Như vậy, dự án THH Văn phòng UBND tỉnh nếu do VP chủ trì thực hiện thì sẽ là dự án nội bộ của Văn phòng nhằm nâng cao hiệu quả hoạt động của mình. Nhưng nếu cũng dự án này mà do Sở KHCN & MT chủ trì thì đối với Sở đây lại là dự án bên ngoài. 5. Thế nào là quản lý dự án 5.1 Khái niệm quản lý dự án bao gồm: • Lập kế hoạch: - Định ra mục tiêu của dự án: kết quả cuối cùng cần đạt được, thời gian phải hoàn thành, các tiêu chuẩn về kỹ thuật - Xác định các phương tiện cần huy động (nhân lực, thông tin, thiết bị, ) tất cả những gì cần được tính vào kinh phí của dự án - Xác định cách thức tổ chức quản lý và thực hiện. • Quản lý các rủi ro Rủi ro là những điều xảy ra và làm cho dự án phải kéo dài hơn hoặc phải chi phí nhiều hơn so với kế hoạch đã định. Vấn đề là nếu lường trước được các vấn đề có thể xảy ra để đề xuất các biện pháp theo dõi và hành động kịp thời thì tốt hơn nhiều so với việc chờ chịu một cách bị động. • Quản lý nhân sự: Động viên những người tham gia, kết phối hoạt động của họ, tạo điều kiện khuyến khích họ làm việc tích cực hơn, hiệu quả hơn. 10
11. • Theo dõi dự án: Người quản lý dự án phải theo dõi để đảm bảo mọi việc xảy ra theo đúng kế hoạch. Việc theo dõi có thể được xác định gồm 3 vấn đề chính: 1. Giám sát - có các hệ thống có thể cho bạn biết rõ dự án đang tiến triển thế nào so với kế hoạch. Hệ thống tốt nhất là hệ thống có thể báo động trước cho người quản lý dự án biết về các vấn đề nảy sinh, có thể dẫn đến sự thay đổi chương trình hay mục tiêu của dự án về thời hạn, kinh phí và kết quả. 2. Biết được có vấn đề thực sự nảy sinh hay không. Có thể, dự án không được thực hiện theo sát kế hoạch đề ra một cách chính sác, nhưng điều đó không có ý nghĩa là sẽ gây ra rắc rối. Ví dụ một công việc (không thuộc đường Gant) không được hoàn thành đúng thời hạn đã định, thì không thể coi là một vấn đề. 3.Phản ứng đối với vấn đề: có thể là khắc phục các nguyên nhân gây ra vấn đề, hoặc là thay đổi kế hoạch. Nếu kế hoạch bị thay đổi bạn phải thông báo cho những người có liên quan tới sự thay đổi này. Tóm lại, quản lý dự án không chỉ đơn thuần là thực hiện một khối công việc đã được vạch định sẵn, mà bao gồm cả chính việc hình thành nên khối công việc đó. Hơn thế nữa, trong giai đoạn xác lập dự án, người quản lý phải tập trung nhiều công sức hơn so với giai đoạn thực hiện - khi đã có thể giao nhiệm vụ cụ thể cho các cán bộ kỹ thuật được rồi. 5.2 Mục đích của quản lý dự án Mục đích cuối cùng của việc quản lý dự án là nhằm đảm bảo cho dự án được thực hiện thành công. Một dự án được đánh giá là thành công nếu như đáp ứng được 4 vấn đề cơ bản sau: • Sản phẩm cuối cùng của dự án thực sự đáp ứng các yêu cầu của người dùng, đảm bảo thời gian và kinh phí không vượt quá 10-20% dự tính ban đầu; • Người dùng hài lòng với quá trình thực hiện dự án, thực sự tham dự và góp phần công sức của mình trong các hoạt động của dự án. Đặc biệt đối với các dự án ứng dụng CNTT, vai trò của những cán bộ nghiệp vụ trong việc xác định yêu cầu, phân tích quy trình, thông tin tại chính đơn vị của mình là rất quan trọng; • Các cấp quản lý phía trên của dự án (BCĐ CNTT, Bộ Tài chính ) được cung cấp đầy đủ thông tin về tình hình thực hiện dự án. • Những người thực hiện dự án cũng phấn khởi, không bị quá gò bó, tích luỹ được kinh nghiệm, tăng thêm thu nhập 5.3 Phương pháp luận và kỹ thuật quản lý dự án: Tất cả những vấn đề nêu trên cho thấy cần phải có thái độ hết sức nghiêm túc khi xây dựng và thực hiện một dự án, nhất là các dự án CNTT đòi hỏi có những đầu tư rất lớn của Nhà nước. Do vậy việc quản lý dự án đòi hỏi phải có những phương pháp luận khoa học và những công cụ mạnh để hỗ trợ cho việc lập kế hoạch và theo dõi dự án. 11
12. 5.4 Nguyên nhân khiến dự án thất bại: • Theo thống kê chung trên thế giới, 33% các dự án bị huỷ bời vì - Vượt qua giới hạn về thời gian hoặc kinh phí; - Công nghệ đã bị thay đổi quá nhiều so với hiệu quả mà dự án sẽ mang lại; - Người dùng hoặc khách hàng không cần tới nó nữa; - Những lý do chính trị. 50 - 100% quá tải Một dự án mà chi phí của nó vượt quá 50% kinh phí cho phép hoặc kéo dài quá 50% thời gian dự định thì coi như là đã thất bại. Không được sử dụng: Nhiều dự án không bao giờ đưa vào sử dụng được. Lý do có thể là: - Dự án không giải quyết được vấn đề đặt ra; - Quá khó sử dụng, - Không có đào tạo. • Nguyên nhân sâu xa của việc thất bại có thể xuất phát: - Ngay từ khi bắt đầu dự án, do thiếu một kế hoạch tốt: Đa số dự án không thể triển khai được vì không xuất phát từ thực tế cụ thể. Người ta bắt tay vào việc lập chương trình mà không hiểu rõ tại sao lại có dự án đó và chính xác là cần phải hoàn thành cái gì; nói cách khác, không có kế hoạch gì cả. Nếu không đánh giá xem là sẽ cần phải tốn bao nhiêu công sức để làm việc đó, ta sẽ không thể hình dung được số lượng nhân công cần thiết, mà đó chính là chi phí chính của dự án. Nếu không thống nhất rõ ràng trước với người dùng về những gì họ yêu cầu dự án phải đạt được, thì sau này sẽ rất khó khăn để người dùng chấp nhận các kết quả của dự án. Người ta có thể hứa hẹn với nhau nhiều điều, nhưng tất cả những cam kết đó đều phải được ghi nhớ lại dưới dạng các văn bản. Việc đặt ra những thời hạn và kinh phí không sát thực tế thường khiến cho những nhóm thực hiện không thể nào thực hiện được lời hứa của mình. - Trong các bước phát triển tiếp: Dự án có thể mắc sai lầm trong giai đoạn phân tích và thiết kế. Ví dụ, nếu các kết quả phân tích và thiết kế không được tư liệu hoá lại một cách chính xác, rõ ràng, thì sẽ gây ra những cách hiểu khác nhau về sau này. Nếu người quản lý dự án không phân công rõ nhiệm vụ của từng người một, thì ai cũng nghĩ rằng đó không phải là trách nhiệm, mà là trách nhiệm của người khác, rồi cuối cùng sẽ chẳng có gì hoàn thành xong cả. 12
13. Thiếu hoặc không hiểu rõ các công cụ hỗ trợ cho việc phát triển hệ thống cũng như cho việc quản lý - theo dõi dự án, sẽ làm ảnh hưởng đến thời gian và kết quả của dự án. Không làm rõ lịch điều phối nhân sự và thông báo trước cho các đối tượng liên quan, thì sẽ rất khó khăn khi cần huy động nhân lực cần thiết để hoàn thành công việc. Việc bắt đầu viết chương trình trước khi bản thiết kế được hoàn thành (mà trước đây đã trở thành thói quen của không ít lập trình viên) sẽ khiến cho dự án khó mà thành công một cách tốt đẹp (vì không tính hết mọi vấn đề), hoặc sẽ tốn thêm nhiều công sức để mà điều chỉnh về sau này. Không kịp thời phát hiện ra các vấn đề chính nảy sinh trước và sau giai đoạn phát triển. Đó là do thiếu sự rà soát chi tiết về mặt kỹ thuật (thiết kế, chương trình, tài liệu ) và xem xét lại về mặt quản lý (đề cương, kinh phí, lịch trình ) một cách khách quan từ bên ngoài. Sự thay đổi công tác của các thành viên tham gia dự án cũng là một nguyên nhân phải tính đến. Ví dụ, nếu như ta luôn chỉ phụ thuộc vào một người lập trình duy nhất, thì khi người đó không tham gia được nữa vào dự án, thì dự án có nguy cơ bị bế tắc nếu như ta chưa kịp chuẩn bị người thay thế. Thiếu các chuẩn mực, qui định trong quá trình phát triển cũng làm cho dự án bị thất bại ở một mức độ nào đó. Ngay cả trong việc quản lý dự án CNTT, chúng ta cũng cần phải thống nhất với nhau về một phương pháp luận chung - đó cũng là một loại chuẩn. Và cuối cùng là quá nhiều người tham gia dự án chưa chắc đã đẩy nhanh tốc độ mà có khi còn làm cho dự án chậm đi vì phải thêm việc đào tạo, huấn luyện, thêm việc giao tiếp giữa mọi người tức là thêm thời gian và kinh phí. Trong giai đoạn kết thúc: Khi đã đến thời hạn cuối cùng, hoặc khi đã hết kinh phí mà mọi chuyện vẫn chưa xong, thì yêu cầu đối với dự án thường bị thoả hiệp. Người ta nghĩ rằng một phần (lớn) công việc đã hoàn thành rồi thế là được, vẫn còn hơn là không có gì. Thế nhưng, đối với nhiều người dùng thì phải giải pháp toàn bộ mới đáp ứng yêu cầu của họ, chứ chỉ có một phần thì ít khi chấp nhận được. Một số ứng dụng được tạo ra mà không có sự rà lỗi cẩn thận. Điều đó gây nên ấn tượng ban đầu không hay và gây khó khăn cho việc đưa vào sử dụng. Một số hệ thống đưa ra không đáp ứng được đúng các chỉ tiêu kỹ thuật đã đề ra. Nếu chi phí cho việc bảo trì quá lớn thì hệ thống cũng có thể bị ngừng hoạt động. 13
14. Trong nhiều trường hợp, nếu ở thời điểm nào đó mà chứng minh được rằng không có ích lợi gì mà tiếp tục dự án nữa thì cũng nên mạnh dạnh xem xét đến việc phải ngừng dự án lại. 6. Các bên liên quan đến dự án Sơ đồ dưới đây có thể xem như là một ví dụ đề cập tới tất cả các đơn vị và nhân sự có liên quan đến một dự án về tin học hoá phục vụ điều hành và quản lý nhà nước trong sự phát triển CNTT. Tình hình tiến độ và kết quả thực hiện của dự án là điều mà những nơi (người) đó cần phải quan tâm đến. Ta thấy, nhìn chung có thể phân các đối tượng trên ra làm ba mức chính. Đó là Những nơi quản lý dự án (gián tiếp) ở mức cao: Đó là BCĐ CNTT (của quốc gia và/hoặc bộ ngành, địa phương), Bộ (Sở) Tài chính, Bộ (Sở) Kế hoạch và Đầu tư. Thực chất đó là những nơi quản lý dự án, nhưng ở mức cao hơn, có thính chất tổng hợp hơn, vì dự án cụ thể chỉ là một trong những dự án nằm trong một chương trình chung nào đó. Để phân biệt, đôi khi có thể gọi đó là những nơi quản lý chương trình. Những người trực tiếp có trách nhiệm đối với dự án: Đó là những đối tượng được mô tả bên trong của vòng tròn lớn. Những người này đóng vai trò quan trọng nhất trong việc quản lý dự án và thực hiện dự án. Về tổ chưc quản lý, ta thấy có thể phân biệt và phải biết rõ chức năng của từng người dưới đây: Giám đốc dự án: tổ chức, phối hợp, đối ngoại Giám đốc điều hành: trực tiếp điều hành, tích hợp Nhóm trưởng kỹ thuật: chịu trách nhiệm từng phần kỹ thuật Nhân viên kỹ thuật trong mỗi nhóm: thực hiện công việc kỹ thuật cụ thể. Thực chất, họ đều là những người quản lý dự án, nhưng ở những mức độ chi tiết khác nhau mà thôi. Đây là những đối tượng sẽ được tập trung phân tích kỹ trong phần liên quan đến nhân sự của dự án trong cuốn sách này. Mức quản lý cuối cùng là các nhóm trưởng phụ trách từng phần công việc kỹ thuật. Có thể coi đó là “giao diện” giữa việc quản lý và thực hiện dự án - tức là với các nhóm kỹ thuật, những người trực tiếp xây dựng và phát triển hệ thống. Cần lưu ý nếu những người này nằm trong sự quản lý trực tiếp của đơn vị hiện tại thì việc tham gia vào dự án ít nhiều như là một trách nhiệm mà cơ quan giao cho. 14
15. Ban Chỉ đạo VP BCĐ Chủ (Giám đốc) dự án Tài chính Nhà hợp đồng Điều hành (về kỹ thuật) Trưởng Trưởng Trưởng Nhà cung cấp nhóm 1 nhóm 2 nhóm 3 Các nhóm phát triển Kế hoạch và Đầu tư Các đối tác bên ngoài: Ví dụ như những hợp đồng chuyên gia bên ngoài, các nhà cung cấp thiết bị Những người này có thể cũng sẽ có vai trò nhất định đối với việc thực hiện dự án, thậm chí tham gia vào việc điều hành kỹ thuật vào chức năng nào đó của nhóm ở bên trong vòng tròn, nhưng họ làm việc theo cơ chế hợp đồng thoả thuận giữa hai bên. Câu hỏi 1. Liệt kê các vấn đề mà dự án CNTT ở Việt nam thường gặp phải, có ảnh hưởng tới kết quả và tiến độ của dự án. Mỗi vấn đề tác động đến (những) giai đoạn nào của dự án (khởi đầu, thực hiện hay kết thúc) 15
16. Phần I - Chu trình dự án và quản lý theo giai đoạn Chương 1. Tổng quan về các giai đoạn của dự án CNTT 1.1 Một cách tiếp cận rõ ràng và tuần tự Để lập kế hoạch và kiểm soát dự án, cách tốt nhất là nên phân chia nội dung dự án thành các thành phần cấu thành nhỏ hơn, hoặc theo các công việc mà mọi người phải thực hiện để có thể quản lý được. Quá trình xây dựng và thực hiện một dự án CNTT có thể phân ra thành các giai đoạn khác nhau. Đây chính là cách tiếp cận dự án theo quan điểm thực hiện tuần tự từng bước một “đầu tiên phải làm việc này, tiếp đó sẽ làm việc kia”. Mỗi giai đoạn trong quy trình đó 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 giai đoạn đó Có như vậy, mới có cơ sở để xác định được rằng một giai đoạn đã hoàn thành hay chưa. Điều này 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.2 Bảy giai đoạn của dự án CNTT Hình 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 xác định ở đâ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. Có thể nói cách phân đoạn như vậy tương đối hợp lý và phù hợp chung với những phương pháp luận về thực hiện một dự án CNTT mà chúng ta đã có dịp làm quen. Về mỗi giai đoạn, ta cần hiểu rõ các khái niệm sau đây: 16
17. Hình 1. Bảy giai đoạn của dự án CNTT Xác định Phân tích Thiết kế Thực hiện Kiểm thử hệ thống Chấp nhận Vận hành hiểu vấn đề và có hệ thống tổng thể từng thành phần cầu Xây dựng các Hệ thống làm việc Người dùng Vận hành và hoàn ước lượng ban đầu cần phải làm gì thành của hệ thống, thành phần cấu tốt, không lỗi chấp nhận hệ thiện Mục đích hệ thống sẽ làm thành thống. việc như thế nào. Xác định: - Khảo sát - Thiết kế hệ thống - Lập trình - Tích hợp -Thực hiện qui - Vận hành - vấn đề - Thiết kế mức - Quyết định mua - Mua - đảm bảo chất trình demo đã - Chuyển đổi - mục tiêu tổng thể hoặc tự xây dựng - Sở thích hoá lượng định - Đào tạo Các hoạt - kết quả - Đánh giá lại - Rà soát chi tiết - Kiểm thử từng - Hỗ trợ động chính - Đánh giá mức độ - Đánh giá lại phần - Rút kinh nghiệm rủi ro Quản lý dự án, Xem xét, Báo cáo tính hình Tư liệu hoá, Đào tạo người dùng - Đề cương dự án - Đặc tả chức năng - Đặc tả thiết kế - Bản thiết kế cho - Báo cáo kết quả - Báo cáo kết - Kế hoạch hỗ trợ. và nghiên cứu khả (ND thông qua) (thông qua về mặt từng thành phần tích hợp hệ thống quả của quy - Báo cáo về kết quả thi (ND thông qua) - Kế hoạch triển kỹ thuật) (thông qua về mặt (thông qua về mặt trình demo đào tạo. - Bản yêu cầu (ND khai - Kế hoạch chấp kỹ thuật) chất lượng) (ND thông - Kinh nghiệm đúc thông qua) nhận (người dùng - Kế hoạch kiểm qua) kết được. Tài liệu, - Bảng các rủi ro thông qua) thử hệ thống Điểm mốc - Kế hoạch ban đầu - Kế hoạch đã (thông qua kỹ (các nguồn nhân lực được đánh giá lại thuật) thông qua) - Tài liệu cho - Đề xuất giải pháp người dùng (ND cụ thể (được lựa sẽ thông qua sau chon) này) Công sức: - QLDA 90% 60% 30% 10% 10% 40% 20% - Kỹ thuật 17
18. 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 hóa ” 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ò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 xong 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 ở dòng đồ thị phía trên. 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 rất nhiều khi gần tới lúc kết thúc dự án. Công sức của mỗi người: Dòng đồ thị phía dưới mô tả công sức tổng thể của mỗi một người (kỹ thuật) tham gia vào dự án. Lúc đầu, khi mà chỉ có những hoạt động về quản lý, thì người kỹ thuật không tham dự nhiều; công việc của họ sẽ tăng dần ở giai đoạn giữa khi mà dự án cần đến những người thiết kế và lập trình, và lại được giảm bớt đi ở giai đoạn kết thúc. 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í dụ UBND, thay mặt nhà nước), 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 (ví dụ như các nhân viên của VP UBND tỉnh). Do vậy, trong từng ngữ cảnh cụ thể, hãy chọn ý nghĩa thích hợp nhất. 1.3 Minh hoạ cho các giai đoạn của dự án Để có khái niệm tổng thể và rõ ràng về quy trình phát triển của một sự án CNTT, hãy so sánh việc xây dựng một dự án như vậy với việc xây dựng một ngôi nhà cho dễ hiểu. Những người đã từng làm việc liên quan đến xây dựng nhà cửa có lẽ cũng không để ý biết rằng quá trình đó cũng gồm 7 giai đoạn như đã trình bày trong hình 1. Giai đoạn xác định của việc xây nhà: Hãy bắt đầu từ một kịch bản nhỏ: Người dùng đến gặp bạn (người quản lý dự án) và nêu ra vấn đề của họ: Tôi sống trong một ngôi nhà nhỏ ở một vùng phía Bắc. Bạn có thể hỏi ngay: “Vậy thì sao? Có vấn đề gì?”. Người dùng sẽ trả lời: - ở nhà tôi, mùa đông thì lạnh, còn mùa hè thì lại quá nóng. Tôi cần có sự điều hoà nhiệt độ.
19. - Ban ngày, trong nhà quá sáng, mà buổi tối lại không đủ ánh sáng. Tôi cần có sự điều khiển ảnh sáng. - Hiện nay mỗi khi tắm giặt lại phải đi ra ngoài và khi cần lại phải đun nước nóng. Do vây tôi cần có hệ thống nước thuận tiện. - Cả gia đình 4 người sống trong cùng một buồng chung. Tôi cần có một khoảng riêng và yên tĩnh - Cứ vậy, cho đến khi tất cả mọi vấn đề được liệt kê hết ra. Nếu như các yêu cầu này chưa được viết ra giấy thì bạn hãy giúp người ta ghi lại để tạo ra Tài liệu yêu cầu. Sau đó bạn phải ước tính giá thành xây dựng ngôi nhà mong muốn để thông báo cho người dùng biết. Đưa những ước tính này và thời hạn thực hiện công việc vào một tài liệu gọi là Đề xuất phương án giải quyết. Các số liệu đưa ra tại thời điểm này có thể không được chính xác. Bạn nên thuyết phục người dùng đợi một thời gian nữa cho đến khi kết thúc giai đoạn Phân tích. Trong trường hợp này, bản đề xuất mới chỉ tập trung vào các công việc và giá thành cho giai đoạn phân tích mà thôi. Giai đoạn phân tích của việc xây nhà: Nhà phân tích phải tạo ra tài liệu Đặc tả chức năng của ngôi nhà sẽ xây dựng. Tài liệu này chứa đựng những hứa hẹn kiểu như: Thưa ông, chúng tôi sẽ xây cho ông một cái nhà khác. Nhà này có 4 phòng với các kính mờ và tường cách âm để đảm bảo cho ông có chỗ riêng biệt và yên tĩnh. Chúng tôi sẽ đặt điều hoà nhiệt độ trong tường, nếu vặn công tắc sang trái, phòng sẽ mát lên; nếu vặn điều hoà sang phải phòng sẽ ấm hơn. Trong mỗi phòng sẽ đặt công tắc ánh sáng để đảm bảo cho việc điều khiển ánh sáng. Nếu bật về phía trên, phòng sẽ sáng hơn; nếu bật về phía dưới phòng sẽ tối hơn. Hệ thống nước sẽ tập trung trong nhà tắm với đủ phương tiện cần thiết cho việc tắm giặt. Trong bồn rửa mặt và bồn tắm sẽ có các vòi nước điều chỉnh được mức nước nóng lạnh theo ý muốn. Chú ý rằng Đặc tả chức năng chỉ liệt kê những gì mà ngôi nhà đáp ứng cho yêu cầu của người sử dụng: đầu vào, đầu ra và giao diện giữa ngôi nhà và người dùng. Tuyệt nhiên ở đây ta chưa nói đến sẽ xây dựng cái nhà đó như thế nào? Tài liệu này chỉ liệt kê những hứa hẹn (đầu ra) mà bạn sẽ tạo ra để giải quyết vấn đề mà người dùng nêu ra trong tài liệu yêu cầu. 20
20. Giai đoạn thiết kế của việc xây nhà: Người thiết kế nhà chính là kiến trúc sư. Mục đích của việc thiết kế là chia hệ thống thành các cấu thành chức năng, rồi sau đó nối kết chúng lại một cách hiệu quả. Trên bản vẻ thiết kế ta có thể thấy nơi ở, nơi ăn, nơi ngủ. Mỗi vùng đó có một hoặc nhiều phòng. Các phòng được ngăn cách, nối kết hoặc thông nhau qua các bức tường, cửa sổ, hành lang và cửa ra vào Vị trí và thiết kế để đặt điều hoà nhiệt độ, điều hoà ánh sàng, trang bị phòng tắm - tất cả đều phải thiết kế chi tiết để đảm bảo được các chức năng như đã hứa. Bản thiết kế sẽ cho thấy hệ thống sẽ làm việc như thế nào. Đây mới chỉ là thiết kế tổng thể. Trong một số trường hợp cần có bản thiết kế chi tiết hơn cho từng phòng một. Tất cả những điều này ghi chép lại vào tài liệu Đặc tả thiết kế Giai đoạn kiểm thử hệ thống của việc xây dựng nhà: Là tập hợp tất cả các thành phần vào với nhau và đảm bảo rằng chúng làm việc đồng bộ với nhau (tích hợp). Trong cái nhà này, ta có thể bắt đầu kiểm thử từ cái móng và nền nhà. Sau đó đến tầng 1, đảm bảo rằng tất cả các cấu thành đều làm việc tốt và liên kết chặt chẽ hợp lý với cái nền móng đã xây. Sau đó đến tầng hai, ba Khắc phục tất cả các vấn đề đã phát hiện ra. Cuối cùng người kiến trúc sư và bên làm hợp đồng xây dựng cần kiểm thử lại một cách hệ thống từng chi tiết một: ánh sáng, điều hoà, buồng tắm, phòng ở, theo như đã xác định trong các tài liệu đặc tả thiết kế đã có. Giai đoạn kiểm thử chấp nhận: Người dùng hoặc đại diện của họ lần đầu tiên trông thấy ngôi nhà mới hoàn chỉnh. Họ sẽ kiểm thử lại một cách hệ thống từng chi tiết một ương ứng với đặc tả chức năng đã có. Nếu họ phát hiện ra vấn đề gì đó không ổn, thì nhóm dự án phải có trách nhiệm khắc phục ngay. có những vấn đề dễ khắc phục, nhưng không phải không có những vấn đề khó mà khắc phục ngay được. Hãy hình dung xem nếu người dùng nói:”Tôi nghĩ rằng ông đã hứa xây một nhà 4 phòng chứ không phải là một nhà 3 phòng ngủ như thế này!”. Những việc như vậy cũng rất hay xảy ra trong các dự án CNTT. Do vậy cần có các yêu cầu rõ ràng và thoả thuận về những điều kiện, mức độ đáp ứng yêu cầu này. Giai đoạn vận hành của việc xây nhà: Trong giai đoạn này, người dùng của chúng ta chuyển đến ở trong ngôi nhà mới. Vấn đề chủ chốt ở giai đoạn này là nhà kiến trúc sư và người xây dựng vẫn còn có trách nhiệm với ngôi nhà này. Cần có thời gian bảo hành (6 tháng đến một năm) vì có thể sẽ xuất hiện những vấn đề cần phải khắc phục. Và có thể có cơ hội để đề xuất xây dựng một ngôi nhà lớn hơn - (một dự án mới!). Lưu ý rằng giai đoạn này không bao gồm việc duy trì - khi mà cần có những chi phí cập nhật thường xuyên khác (tiền điện nước, ). Nếu luôn xuất hiện những yêu cầu mở rộng hơn nữa, thì dự án sẽ không bao giờ kết thúc được. Cần 21
21. phải dứt điểm ở giai đoạn kết thúc dự án; còn nếu cần thiết thì sẽ thực hiện một dự án mới. Bình luận: Mặc dù minh hoạ trên cho ta một hình dung khá cụ thể về những công đoạn tương tự trong quá trình thực hiện một dự án CNTT, nhưng cần nhận thức rõ ràng trên thực tế giữa các dự án về xây dựng và dự án CNTT có nhiều điểm khác nhau cơ bản. - Thứ nhất là, ví dụ nêu trên ai cũng có thể hiểu vì đều ít nhiều biết đến các công đoạn để xây dựng một cái nhà. Người dùng cũng rất dễ dàng mô tả cụ thể cho bạn biết xem họ mơ ước có một ngôi nhà như thế nào từ màu sắc đến từng viên gạch một. Nhưng liệu có bao nhiêu người ứng dụng CNTT có thể xác định chính xác được như vậy những yêu cầu của họ? - Tiếp đó là, cho đến nay đã có rất nhiều kinh nghiệm và chuẩn cho việc xây dựng nhà cửa, nhưng trong lĩnh vực CNTT chúng ta thậm chí còn chưa xác định rõ những khái niệm tương tự móng nhà, tâng hay buồng là như thế nào, nói cách khác là còn rất thiếu những chuẩn thống nhất để mọi người cùng hiểu nhau. Các chương tiếp theo sẽ mô tả chi tiết hơn từng giai đoạn một và đặc biệt chú ý đến vai trò, trách nhiệm của người quản lý dự án trong mỗi một giai đoạn đó. Câu hỏi 1. Liệt kê bảy giai đoạn của dự án CNTT với các hoạt, sản phẩm và điểm mốc quan trọng nhất trong từng giai đoạn. 2. Liên hệ với thực tế của các dự án CNTT mà anh (chị) đã từng tham gia. 22
22. Chương 2. Giai đoạn xác định Mục đích: của giai đoạn này là có được một sự hiểu biết đầy đủ về các vấn đề, các yêu cầu của người dùng có thể hình dung được đầy đủ về các vấn đề của dự án, ước lượng được giá thành và thời gian thực hiện. Các hoạt động chính cần làm trong giai đoạn này là: • Tìm hiểu thấu đáo về các vấn đề của người dùng và những gì cần thiết để giải quyết vấn đề đó. • Cần phải quyết định có thực hiện hay không thực hiện dự án. Ta cần phải biết chắc rằng dự án là khả thi và có nhiều cơ hội để mà thành công. • Nếu dự án có thể thực hiện được, cần phân tích đánh giá các rủi ro có thể xảy ra và chi tiết hoá tất cả các kết quả cần đạt được, khi nào và với giá thành bao nhiêu. • Cũng từ giai đoạn này, ta phải bắt đầu ngay các hoạt động về quản lý dự án, xem xét, báo cáo và tư liệu hoá; và tiệp tục tiến hành các hoạt động đó cho đến khi kết thúc dự án. Các tài liệu cần phải viết: • Đề cương dự án: khởi đầu của một dự án, để đề đạt lên cấp trên xem xét và ủng hộ cho thực hiện; • Nghiên cứu khả thi: để chứng minh rằng dự án có thể thực hiện được về mặt kỹ thuật với chi phí có thể chấp nhận được so với lợi ích kinh tế mà nó sẽ đem lại; tài liệu phải được nhà đầu tư thông qua; • Tài liệu yêu cầu: giúp cho nhóm dự án hiểu rõ về những yêu cầu của người dùng và trên cơ sở đó mới có thể đề ra giải pháp cụ thể thích hợp và ước tính giá thành của nó; (trong trường hợp cụ thể, đây chính là tài liệu gọi thầu). Tài liệu này phải được người dùng thông qua; • Danh sách rủi ro: dự đoán trước những trở ngại để chuẩn bị phương án đối phó; • Kế hoạch ban đầu: vạch ra các bước chính, làm cơ sở đầu tiên để ước lượng và lập lịch cho dự án. Kế hoạch đưa ra phải được cả nhóm dự án thống nhất; • Đề xuất (propsal) giải pháp cho người dùng: ước lượng ban đầu về giá thành và thời hạn cho dự án. Đối với các dự án bên ngoài, đây là tài liệu chính thức trình bày những ý định của nhóm dự án nhằm cung cấp các dịch vụ mà ngươì dùng yêu cầu (tài liệu dự thầu). Điểm mốc cần thiết là tài liệu này được chủ dự án chấp thuận hoặc chủ đầu tư quyết định trúng thầu. 23
23. 2.1 Đề cương dự án a) Mục tiêu: Đây là tài liệu khởi đầu của dự án thường để trình lên cấp trên xin đầu tư kinh phí. Nếu xét thấy đó là ý tưởng tốt, cấp có thẩm quyền có thể lựa chọn đầu tư, trước hết hỗ trợ để nghiên cứu thêm. b) Nội dung: Ví dụ đề cương của một dự án CNTT nằm trong KHTT của Bộ ngành địa phương đã được giới thiệu qua tập huấn sau. Tên dự án: Cơ quan chủ trì dự án 1. Cơ sở và luận cứ dự án 1.1. Nhiệm vụ, chức năng của cơ quan 1.2. Nhiệm vụ được giao 1.3. Năng lực hiện có Hạ tầng cơ sở Cán bộ 1.4. Các cơ quan tham gia phối hợp 1.5. Các luận cứ, lý do dẫn đến xây dựng dự án 2. Các mục tiêu của dự án 2.1. Mục tiêu dài hạn 2.2. Mục tiêu ngắn hạn 3. Nội dung của dự án 3.1. Mô tả các nội dung chính 3.2. Các hoạt động, các bước triển khai và tiến độ 4. Kết quả cần đạt được 5. Dự toán 5.1. Theo từng hoạt động 5.2. Theo các khoản: Chuyên gia Đào tạo Thiết bị Các khoản khác 24
24. 2.2 Tài liệu nghiên cứu khả thi a) Mục tiêu: Để xác định xem dự án có đáng làm hay không. Trước tiên, cần trả lời rõ câu hỏi:”Dự án có thể thực hiện được kỹ thuật hay không ?”, và nếu có, thì “với chi phí là bao nhiêu và lợi ích như thế nào?” b) Nội dung • Giới thiệu về nền tảng cơ sở, về tổ chức • đặt vấn đề. • Mô tả các giải pháp kỹ thuật có thể sử dụng để giải quyết vấn đề. Ví dụ, các thiết bị phần cứng, phần mềm khác nhau, mua hoặc tự xây dựng lấy các ứng dụng • Đánh giá về tài chính cho mỗi giải pháp đó. • Phân tích đề xuất lựa chọn giải pháp tối ưu nhất • Chứng tỏ rằng tại thời điểm hiện tại đơn vị có thể triển khai thực hiện dự án khả thi này. • Tiếp tục triển khai dự án như thế nào. c) Chú ý: Tại thời điểm này, việc đánh giá ước lượng có thể mới chỉ là ở mức D (sai số ±100%). Điều này không thành vấn đề lắm, vì các kết quả ước lượng chỉ nhằm phục vụ cho việc xác định xem dự án có nằm trong phạm vi tài chính cho phép hay không. 2.3 Tài liệu yêu cầu a) Mục đích: Giúp cho nhóm dự án có thể nắm bắt được đầy đủ các khía cạnh của vấn đề cần phải giải quyết; đề xuất xem cần phải tự động hoá ở những công việc nào và tính được giá thành/hiệu quả của giải pháp. Tài liệu này phải được diễn tả một cách rõ ràng thông qua ngôn ngữ dễ hiểu với các thuật ngữ nghiệp vụ quen thuộc, chứ không phải là bằng các thuật ngữ tin học. Tài liệu này đôi khi được sử dụng như tài liệu gọi thầu nếu cần gọi thầu từ bên ngoài. b) Nội dung tài liệu bao gồm các mục đích chính như sau: • Giới thiệu chung: Những vấn đề cần giải quyết: chức năng nhiệm vụ, cơ cấu tổ chức, lịch sử của vấn đề, môi trường làm việc hiện tại • Mục tiêu của dự án: . Cần phải làm gì và tại sao phải làm như thế; . Các ràng buộc về kinh phí và thời gian. • Mô tả các chức năng chính: Xác định xem hệ thống sẽ làm việc như thế nào. 25
25. • Các đầu ra: - Xác định các thông tin mà hệ thống cấu tạo ra, tần suất của chúng (còn việc dùng những biểu báo cáo nào để đảm bảo được các thông tin đó là công việc của người phân tích); - Các phần cứng, phần mềm, tài liệu cần có như sản phẩm của dự án. • Sơ bộ về các thông tin đầu vào cần thiết: (Nhiều khi phải sau khi phân tích mới xác định rõ được) • Một số yêu cầu khác: − Tần suất giao dịch, xử lý; khối lượng thông tin cần lưu trữ, sự tăng trưởng; - Ai sẽ sử dụng, sử dụng ở đâu - Tính tương thích với các hệ thống đã có, độ tin cậy, bảo trì • ảnh hưởng đối với đơn vị: Các thay đổi trong quy trình nghiệp vụ sẽ có tác động như thế nào đối với người dùng, ở bộ phận nào • Đối với tài liệu dùng để gọi thầu: - Yêu cầu thêm thông tin liên quan tới kinh nghiệm, năng lực - Các điều khoản quy định về bản quyền, trách nhiệm, bảo hành c) Chú ý: • Kinh nghiệm cho thấy tốt nhất là các chuyên gia phân tích và tin học hãy hỗ trợ cùng với người dùng viết lên được rõ yêu cầu của họ. Chuyên gia tin học không thể nghĩ thay cho người sử dụng những yêu cầu thực sự trong công việc nghiệp vụ của họ được; nhưng mặt khác, vì những người dùng có thể chưa hiểu rõ được là CNTT có thể giúp họ được những gì một cách cụ thể nên đôi khi họ khó phát biểu được chính xác các mong muốn của mình, mặc dù chính họ là người hiểu rõ hơn ai cả hệ thống đang vận hành và các tồn tại cần cải tiến. • Phải tìm đến những người dùng tiêu biểu đầu cuối - những người có quyền cho ý kiến quyết định về hệ thống định xây dựng và đánh giá xem nó sẽ ảnh hưởng đến công việc của đơn vị. Nếu dự án là nội bộ thì việc tiếp cận đến người dùng không mấy khó khăn. Nhưng đối với các dự án có sử dụng lực lượng ở bên ngoài thì người quản lý dự án phải làm sao tạo điều kiện cho việc giao tiếp giữa hai bên. • Qui trình phỏng vấn thường đi từ quy trình thông tin trong đơn vị, đầu ra, tần suất, độ chính xác, thời gian; và sau đó mới xác định để đáp ứng được thì cần các thông tin đầu vào gì, ở đâu, khi nào, ai có trách nhiệm và tại sao phải cung cấp. (5W: What – When – Where –Who -Why). • Đối với những yêu cầu không rõ ràng, có thể phải làm xây dựng các mẫu sẵn (prototype - xem phụ lục cuối chương) để hỏi ý kiến người dùng, hãy tìm đến hỏi người dùng khác và chính xác hoá các yêu cầu một cách dần dần, qua nhiều lần. • Tránh thay đổi yêu cầu khi bắt tay vào thực hiện dự án vì sẽ tốn kém thêm. • Đối với các vấn đề chưa xác định rõ (ví dụ việc cần một hệ điều hành nào đó), có thể có các giả định trước và nhấn mạnh sẽ phải xử lý ra sao trong trường hợp sau này sẽ không theo các giả định đó nữa. 26
26. • Sử dụng hai bước ước lượng nếu dự án quá phức tạp. Tại thời điềm này, có thể ước lượng với sai số +-50%. Đó là mức ước lượng loại C. • Tài liệu này nhất thiết phải được người dùng nhất trí thông qua. Đây là một trong những điểm mốc rất quan trọng. 2.4 Danh sách các rủi ro a) Mục tiêu: Tầm quan trọng và kỹ năng về việc quản lý rủi ro sẽ được đề cập đến trong một chương trình riêng (chương 13). Rủi ro là những điều mà không nằm trong kế hoạch nhưng có thể làm cho dự án phải chi phí nhiều hơn việc kéo dài thời gian đã định. Bước đầu tiên và quan trọng nhất trong việc quản lý rủi ro, là phải cố gắng nhìn thấy trước xem những sự rủi ro có thể xảy ra là gì, để đánh giá những chi phí cho xác đáng. Danh sách rủi ro cần được thiết lập ngay từ giai đoạn này. b) Nội dung: Liệt kê các rủi ro có thể xảy ra trong mỗi giai đoạn của dự án, theo các cột xác suất xảy ra , mức độ ảnh hưởng tới dự án và sắp xếp chúng theo thứ tự cột ưu tiên cần chú ý từ cao đấn thấp, ai có trách nhiệm, cần giải pháp gì để khắc phục, và chi phí ước tính là bao nhiêu (phụ thuộc vào ảnh hưởng của từng rủi ro) - Xem hình 2. Bảng này sẽ được cập nhật trong quá trình theo dõi quản lý dự án. Có thể một số rủi ro sẽ không còn nhiều nguy cơ nữa, và cũng sẽ xuất hiện thêm các loại rủi ro khác. Số Rủi ro Xác ảnh Mức Người Biện Giá thứ suất xảy hưởng tới độ cần có pháp phải tự ra việc chú ý trách trả thành bạu nhiệm của dự án Xác định 1 Thiếu chuẩn 6 4 24 2 Chậm phê 3 2 6 duyệt kinh phí Phân tích 3 Thiếu chuyên gia 6 6 36 4 Không phối hợp 3 4 12 tốt 5 Không có người 7 5 35 dùng am hiểu Hình 2 2.5 Kế hoạch ban đầu 27
27. Lập kế hoạch là một công việc hết sức quan trọng và khó khăn, nhưng cần phải được thực hiện thật tốt. Kinh nghiệm cho thấy số dự án triển khai chệch hướng do thiếu kế hoạch là nhiều hơn so với số dự án như vậy do tất cả các nguyên nhân khác gộp lại. Đây là một quá trình định tiến dần: kế hoạch thường xuyên phải được xem xét lại trong tiến trình phát triển của dự án, trong sự hiểu biết và thu nhận thông tin ngày một tốt hơn, nhiều hơn. Ngoài việc lập kế hoạch ban đầu trong giai đoạn xác định, xin hãy lưu ý là vẫn còn có hai giai đoạn nữa để có thể xem lại kế hoạch; đó là giai đoạn phân tích và giai đoạn thiết kế. ở mỗi mức kế hoạch, các yêu cầu về ước lượng và thoả thuận với các thành viên trong nhóm cũng có mức độ khác nhau. STT Mức độ kế hoạch Ước lượng Nhân sự 1 Nghiên cứu khả thi +-100% (D) 2 Tài liệu yêu cầu - Kế +- 50% (C) Trao đổi trước về khoảng hoạch ban đầu thời gian cần đến nhân sự 3 Kế hoạch cuối cùng (giai + -25% (B) Đạt được sự đồng ý của đoạn phân tích) nhân sự 4 Kế hoạch đã được xem + - 10% (A) Khẳng định lại sự cam xét lại (Thiết kế) kết một lần nữa a) Mục tiêu của kế hoạch ban đầu: Là bước khởi đầu trong việc xác định ra những bước phát triển dự án và những nguồn nhân lực cần thiết trong mỗi bước đó, cần trong bao lâu và giá bao nhiêu. Kế hoạch này cho phép ước lượng và lên lịch trình sơ khởi cho dự án. • Đây là tài liệu nội bộ, trong đó bước vạch ra các bước, xác định chi phí, công việc, số lượng người cần thiết cho dự án, lịch làm việc cho mỗi người những hoạt động chính mà nhóm dự án sẽ phải thực hiện để tạo ra các sản phẩm yêu cầu. • Văn bản hoá những sự thỏa thuận tham gia vào dự án của các thành viên (bao giờ, bao lâu ). Thoả thuận là lời hứa của một người rằng họ sẽ thực hiện một điều nào đó. Chúng ta cần sự thoả thuận của những người mà ta cần, đặc biệt là từ: Những người trong ban quản lý dự án Trưởng ban quản lý dự án Người điều hành dự án Các thành viên trong Ban quản lý dự án Các nhân viên kỹ thuật Người lãnh đạo nhóm kỹ thuật Nhóm làm việc, Nguồn nhân lực khác, đặc biệt từ các nhóm khác trong cùng tổ chức (chương trình). b) Các bước trong quá trình làm kế hoạch, trong đó có kế hoạch ban đầu Việc lập kế hoạch cũng ví như việc cưỡi ngựa vậy: trước khi thực hiện ta cảm thấy rất là khó; nhưng sau khi đã thử rồi thì mọi việc sẽ tiến triển một cách dễ dàng. Vấn đề là phải học cách làm và tuân theo các bước sau: 28
28. b1) Phân chia công việc (WBS - Work Breakdown Structure) • Tầm quan trọng: Vấn đề chính trong mỗi một kế hoạch là chia nhỏ các hoạt động cần thiết thành các hoạt động cần thiết thành các thành phần nhỏ hơn. Điều này rất cần thiết vì có như vậy mới có cơ sở theo dõi và kiểm tra được tiến độ thực hiện về sau này. Cụ thể là qua đó có thể: - Tổ chức sử dụng tốt nhất nguồn nhân lực bằng cách giao cho mỗi người phần việc thích hợp đúng với năng lực của mình; - Dễ đánh giá và ươc lượng hơn đối với những công việc nhỏ kéo dài khoảng từ 2-4 tuần; - Tạo điều kiện cho việc sắp xếp công việc: Công việc càng nhỏ thì càng dễ lập lịch, có thể làm nhiều việc cùng một lúc, do vậy dự án sẽ càng nhanh hơn; - Giúp bạn suy nghĩ toàn diện về mọi việc cần làm; - Dễ kiểm tra tiến độ công việc, vì mỗi một phần công việc nhỏ đều có ngày kết thúc của nó, vì vậy bạn có thể thấy chính xác lúc nào thì nó hoàn thành. • Phương pháp phân chia công việc: Theo cấu trúc phân cấp từ trên xuống dưới, cho đến khi mọi công việc đều được xác định ở mức thấp nhất. Đối với các dự án CNTT, phân chia công việc ở mức đầu tiên thường bắt đầu bằng bảy giai đoạn của dự án như đã và sẽ mô tả trong sách này. Dùng máy tính (ví dụ MS Profect để đưa các công việc này vào theo phân cấp của chúng) 0. Tên dự án 1. Giai đoạn xác định 1.1. Đề cương dự án 1.2. Tài liệu yêu cầu 1.3. Kế hoạch ban đầu 2. Giai đoạn phân tích 3. Giai đoạn thiết kế 4. Giai đoạn thực hiện 5. Giai đoạn kiểm thử hệ thống 6. Giai đoạn chấp nhận 7. Giai đoạn vận hành 0. Tên dự án ⎢ 29
29. 1. Xác 2. Phân 3. Thiết 4. Thực 5. Kiểm tra 6. Chấp 7. Vận định. tích kế hiện hệ thống nhận hành ⎢ 1.1 Đề 1 2 Tài 1.3 Kế cương dự liệu yêu hoạch ban án cầu đầu • Khi nào thì dừng: Bạn phải phân chia công việc thành những phần nhỏ tới mức: - Rõ ràng, dễ hiểu, đặc biệt là đối với những phần việc liên quan tới xây dựng các sản phẩm kỹ thuật; - Có thể giao cho ai đó thực hiện: Bạn có một người hoặc một nhóm người có thể thực hiện giao phần việc đó; - Có thể ước lượng (công sức, giá thành): Công việc phải thực hiện được với sự đảm nhận của một người hoặc một nhóm người thực hiện. Công sức là số ngày/người cần để làm công việc. Giá thành là chi phí cho công sức đó cộng thêm các loại giá khác như giá mua hàng. - Có thể làm thời gian biểu (khoảng thời gian, những công việc kể trước đó). Khoảng thời gian là số ngày cần phải có để hoàn thành công việc đó. Thông thường tính bằng việc phân chia công sức cho số người thực hiện công việc đó. - Tính toàn vẹn: Công việc này phải có điểm kết thúc rõ ràng. • Tiếp theo đó, đối với mỗi công việc này phải ước lượng các yếu tố sau: - Số thời gian cần để thực hiện; - Số nhân lực cần để thực hiện; - Công sức tổng thể (thường bằng số thời gian nhân với số người); Phương pháp và kỹ năng ước lượng sẽ được giới thiệu trong chương 9, phần 2 của sách này. Ta cũng có thể dùng các công cụ phần mềm để quản lý và đưa các dữ liệu vào máy. b2) Sơ đồ hoá thứ tư các hoạt động và sự kiện Xác định xem công việc nào phải làm trước công việc nào: Tốt nhất là sử dụng sơ đồ PERT (sẽ mô tả ở phần sau) để hỗ trợ cho việc lập lịch về sau này. Trên sơ đồ này ta có thể xác định được đâu là đường tới hạn của dự án (critical path hay đường GANTT) - chuỗi các hoạt động có ảnh hưởng chính tới tiến độ thực hiện của dự án - và qua đó xác định thời gian cho toàn bộ dự án. b3) Tính giá thành của cả dự án Giá thành của dự án bao gồm giá cố định (để mua bán các thiết bị) và giá công lao động. Giá công lao động được ước tính cho mỗi công việc nhỏ trong 30
30. bảng phân chia công việc, bằng công sức (effort) nhân với giá tiền trung bình chi cho một công lao động; sau đó cộng tất cả lại thành ra tổng giá mà dự án phải trả cho nhân công. b4) Lập lịch: Bước tiếp theo là tính thời hạn (ngày) giao nộp sản phẩm. Để làm điều đó người lập kế hoạch phải chuyển số ngày đã ước lượng thành ra lịch trình cụ thể, bắt đầu từ ngày nào, kết thúc ngày nào. Vấn đề khó ở đây là làm sao huy động được nguồn nhân lực: ai là người sẽ thực hiện cho từng việc cụ thể, nhất là những việc có thể thực hiện đồng thời; và quyết định xem liệu thời gian có rút ngắn được không nếu như tăng thêm nhân lực. b5) Kế hoạch ban đầu Trên cơ sở các bước làm trên, người quản lý dự án có thể viết kế hoạch ban đầu, với các nội dung chính như sau: 1. Giới thiệu về nhóm dự án: Mô tả chi tiết tổ chức của Ban (nhóm) dự án - (không cần nêu tên cụ thể). Hãy chỉ rõ quan hệ thông tin giữa các thành viên, ai báo cáo cho ai, ai trao đổi với ai v.v Nhóm thực hiện (nhóm trưởng, cán bộ kỹ thuật, ) Nguồn nhân lực được cung cấp từ nơi khác Ban quản lý dự án, Điều hành dự án Ban chỉ đạo Ban QLDA Ban chỉ đạo Ban tư vấn Điều hành Nhóm trưởng Nhóm trưởng Nhóm trưởng Nhóm trưởng CSHTKT HTTT QLDA đào tạo vận hành CB kĩ thuật CB kĩ thuật Thiết kế Phân tích viên Lập trình viên 1 2 viên Hình 5: Một mô hình tổ chức nhân sự của dự án Ví dụ về Phân công công việc 31
31. STT Tên công việc Thời Nhân Ngày Chi Công gian lực công phí việc trước 0 Tin học hoá Văn phòng 1 Xác định 1.1 Viết đề cương, nghiên cứu khả thi 1.2 Viết tài liệu yêu cầu 1.2.1 Phỏng vấn người dùng 2.5 PM, TL 5 1.2.2 Viết tài liệu 1.2.3 Người dùng thông qua 1.3 Phân tích rủi ro 1.4 Kế hoạch ban đầu 1.4.1 Viết tài liệu 1.4.2 Nhóm dự án thông qua 1.5 Viết tài liệu dự án 1.5.1 Nghiên cứu sơ khai 1.5.2 Các nội dung chính của dự án 1.5.3 Các hoạt động hỗ trợ 1.6 Duyệt dự án 2 Phân tích 2.1 Viết tài liệu phân tích 2.1.1 Qui trình thông tin 2.1.2 Đặc tả chức năng 2.1.3 Đặc tả dữ liệu 2.1.4 Tổng hợp, viết tài liệu 2.2 Kế hoạch cụ thể 2.3 Thẩm định, phê duyệt dự án 3 Thiết kế 3.1 Thiết kế chức năng 3.1.1 Thiết kế menu 3.1.2 Thiết kế biểu mẫu 3.1.3 Thiết kế báo cáo 3.2 Thiết kế cấu trúc dữ liệu 3.2.1 Logic 3.2.1.1 Định nghĩa các bảng 3.2.1.2 Xác định quan hệ 3.2.1.3 Chuẩn hoá dữ liệu 3.2.2 Vật lý 3.3 Thiết kế mạng 3.4 Viết bản thiết kế 3.5 Viết quy trình chấp nhận 3.6 Ước lượng lại 3.7 Thông qua 4 Thực hiện 32
32. STT Tên công việc Thời Nhân Ngày Chi Công gian lực công phí việc trước 4.1 Đấu thầu thiết bị 4.1.1 Chuẩn bị tài liệu gọi thầu 5 PM, KT 10 3.7 4.1.2 Gọi thầu 20 4.1.1 4.1.3 Xét thầu 4.1.4 Công bố thầu 4.2 Mua trang thiết bị 4.2.1 Ký hợp đồng 4.2.2 Chuyển giao cài đặt thiết bị 4.2.3 Nghiệm thu Ban quản lý, điều hành dự án: quản lý các nhóm dự án, điều hành, động viên Chịu trách nhiệm đối với việc phối hợp, quan hệ bên ngoài, với lãnh đạo cấp trên và tích hợp chung. Mục đích chính là làm sao cho dự án thành công (Kế hoạch, theo dõi, dán tiếp). • Nhóm trưởng kỹ thuật: chỉ giám sát các cán bộ kỹ thuật, cán bộ lập trình về các chi tiết kỹ thuật. Có trách nhiệm (nhưng không nhất thiết phải trực tiếp làm) về các hoạt động kỹ thuật có liên quan như phân tích, thiết kế và các công việc lập trình chính. Mục đích chính là đảm bảo chất lượng của sản phẩm. • Cán bộ kỹ thuật: chịu trách nhiệm trực tiếp về các phần việc kỹ thuật cụ thể. 2. Chế độ xem xét và báo cáo • Trong phần này phải dự tính trước các buổi xem xét về mặt quản lý dự án, hay về kỹ thuật, mục đích của mỗi buổi họp đó và những người nào sẽ tham dự, với trách nhiệm gì. Cố gắng thu xếp các buổi họp này được tổ chức sau khi một điểm mốc đã đạt được. • Chi tiếp hoá mẫu và nội dung các báo cáo về tình trạng, báo cáo sau mỗi một giai đoạn hay điểm mốc và tất cả các tài liệu khác về dự án. Liệt kê danh sách những ai sẽ nhận từng báo cáo cụ thể và trách nhiệm của họ sau khi nhận báo cáo đó. 3. Các kết quả sẽ chuyển giao và yêu cầu đối với chúng: Phần cứng, phần mềm Chất lượng bảo hiểm Bảo hành Đào tạo Vận hành, thao tác Kế hoạch về tài liệu: Tài liệu cho dự án, Tài liệu cho khách hàng 33
33. 4. Kèm theo bảng phân công công việc với các thông số chính như đã mô tả ở trên - Đây là tài liệu nội bộ - Thời gian biểu - với sơ đồ Gannt và nhấn mạnh giải thích một số điểm đặc thù trong đó - Các yêu cầu về nguồn nhân lực, - Giá cả 2.6 Đề xuất giải pháp cho người dùng (Nếu như dự án thuê hợp đồng bên ngoài làm, thì tài liệu này sẽ là tài liệu dự thầu của đối tác. Những người quản lý dự án tin học hóa hiện nay tại các đơn vị cần nắm rõ yêu cầu của tài liệu này khi xem xét đánh giá các hồ sơ dự thầu). Tài liệu này là câu trả lời cho tài liệu yêu cầu (gọi thầu) của người dùng trong đó nêu ra những đánh giá và ước lượng cho với việc giải quyết vấn đề đặt ra. Trong các dự án CNTT thường người ta ước lượng thấp hơn là thực tế. Nguyên nhân có thể là không biết đánh giá thế nào, mà cũng có thể là do chưa nhìn thấy hết khía cạnh, phức tạp của vấn đề. Nhất là hiện nay, nhiều người mới chỉ nhìn thấy giá thành của phần cứng chứ chưa nhận thức được rằng đó chỉ là một phần nhỏ so với các chi phí khác (hệ thống thông tin, đào tạo ) trong một dự án CNTT. Cho nên, không nên vội vàng ước tính nếu như mới chỉ nghe qua vài lời trình bày của người dùng. Trong nhiều trường hợp đó nên chia dự án thành 2 dự án con mà trong đó giai đoạn phân tích sẽ là dự án thứ nhất, các giai đoạn còn lại sẽ là dự án thứ hai. Như vậy, ở giai đoạn xác định, thì việc đề xuất của ta mới chỉ là những đề xuất cho việc phân tích vấn đề mà thôi. Sau giai đoạn phân tích sẽ đưa ra những đề xuất phát triển tiếp theo. Đây chính là ý nghĩa của cách tiếp cận theo hai giai đoạn. Một số dự án trong điểm của sự phát triển CNTT đã hoặc đang tiến hành theo hai giai đoạn như vậy, ví dụ như dự án về hệ thống các CSDL Quốc gia. a) Mục tiêu của tài liệu: Để được cấp kinh phí triển khai dự án. Mặc dù tài liệu này thường đặc trưng cho những dự án bên ngoài với chức năng là một tài liệu dự thầu, nhưng ngày các dự án nội bộ rất cần có một tài liệu kiểu như thế này: thoả thuận chính thức giữa người dùng và nhóm dự án sẽ đem lại lợi ích cho các đơn vị trong nội bộ về mặt sản phẩm và kinh tế. b) Những nội dung chính: 1. (Nếu là tài liệu dự thầu) Đơn xin dự thầu: Tổng quan chung về các nội dung tham gia dự thầu, gồm các mục sau: • Các chức năng, thành phần chính; • Tổng giá thành; • Thời hạn 34
34. 2. Trang bìa, mục lục của tài liệu 3. Phạm vi của dự án: • Những vấn đề cần giải quyết • Những mục tiêu chính • Những người tham gia vào dự án • Vị trí của dự án trong phần tổng thể • Các chức năng chính, ai sử dụng chúng • Tăng trưởng, giới hạn về mặt kích cỡ, khối lượng (trong vài ba năm) 4. Những tính ưu việt của phương án này (nếu là tài liệu dự thầu): hãy chứng minh rằng giải pháp đưa ra là sát với yêu cầu, có kế hoạch và cách tổ chức thực hiện theo phương pháp luận khoa học 5. Tài chính: • Tổng kinh phí của dự án: trong đó có phân chia thành các hạng mục như phần cứng, phần mềm hệ thống, phần mềm ứng dụng, đào tạo • Kết quả phân tích tài chính • Ngân sách và các nguồn vốn khác ( các kỹ năng phân tích tài chính sẽ trình bày trong chương 10) • Thời hạn dự tính hoàn thành. 6. Kế hoạch: • Các bước tiến hành và các điểm mốc chính. Nếu đây là đề xuất phân tích, hay nêu lý do tạo sao và giải thích rằng kết quả của dự án mới chỉ là tạo ra được một bản Đặc tả chức năng rất cần thiết cho các công việc sau này. • Trách nhiệm và sự tham gia của người dùng • Tổ chức thực hiện dự án (nhóm dự án, họp hành, giao tiếp, quan hệ ) 7. Các kết quả chuyển giao • Liệt kê chi tiết các phần cứng, phầm mềm hệ thống. Nói rõ tại sao có sự lựa chọn này, chức năng, khả năng, thời hạn • Phần mềm ứng dụng (mua hoặc tự xây dựng) • Bảo hành như thế nào: trong bao lâu kể từ khi sự cố xảy ra, bằng cách nào? • Danh mục các tài liệu với mô tả ngắn gọn mục đích, nội dung và đối tượng sử dụng • Danh mục các khoá đào tạo • Phương pháp chuyển giao, vận hành 8. Nghiệm thu nếu thông qua Cần sử dụng một phương pháp kiểm thử để chứng minh với người dùng rằng kết quả đạt được đáp ứng đúng những điều đã ghi trong đặc tả chức năng. Có như vậy, người dùng mới yên tâm để chấp nhận sản phẩm chuyển giao được. 35
35. 9. Một số giải pháp khác (nếu có) Có thể đề xuất những giải pháp khác (so với dự tính của người dùng) và thuyết minh những ưu điểm của chúng. 10. Một số điều khoản ràng buộc khác: . Liệt kê những điều kiện mong muốn có được để triển khai tốt các công việc (ngay cả đối với những dự án nội bộ). . Liệt kê các giả thiết đã sử dụng, vì điều này có liên quan tới các dự toán đã nêu ra. 11. Giải thích một số thuật ngữ 2.7 Kết luận Các mốc chính của giai đoạn Xác định là: 1. Quyết định đầu tư hay không đầu tư cho dự án. 2. Hoàn thành tài liệu yêu cầu được người dùng thông qua. 3. Lên kế hoạch ban đầu với sự nhất trí của các thành viên trong nhóm dự án. 4. Tài liệu đề xuất giải pháp được chủ dự án thông qua để thực hiện. Câu hỏi 1. Thế nào là phương pháp hai giai đoạn? Phương pháp đó có lợi gì? 2. Làm thế nào để viết được một tài liệu yêu cầu tốt? 3. Liệt kê và sắp xếp những rủi ro có thể xảy ra đối với dự án THH tại đơn vị mình theo bảng đã nêu trên. 4. Liệt kê giữa bảng dự trù kinh phí đã làm cho dự án THH và chi phí thực tế khi triển khai dự án. 5. Chi tiết hoá WBS (mức 2, mức 3 ) cho dự án THH. 6. Các hồ sơ dự thầu đã gặp trong thực tế có đáp ứng những nội dung nêu trên hay không? 36
36. Chương 3. Giai đoạn phân tích 3.1 Mục tiêu Giai đoạn phân tích nhằm mục tiêu xác định chính xác hệ thống thông tin dự định xây dựng sẽ “làm gì” cho người sử dụng, và nó sẽ hoà nhập vào môi trường của người sử dụng như thế nào, nói cách khác, trong giai đoạn này phải xác định mọi yêu cầu, mọi vấn đề đặt ra mà hệ thống thông tin phải đáp ứng. Mặc dù theo lý thuyết thì trong giai đoạn phân tích chỉ cần xác định được xem hệ thống sẽ phải làm những gì. Tuy nhiên trên thực tế, kết thúc giai đoạn này người quản lý dự án phải hình dung ra được hệ thống sẽ thực hiện các chức năng chính đó như thế nào? Trong nhiều trường hợp, ta không thể chuyển sang giai đoạn thiết kế sâu được nếu như chưa hoàn thành xong cơ bản giai đoạn phân tích này. 3.2 Các công việc phải thực hiện Các công việc của giai đoạn phân tích bao gồm: 3.2.1. Công việc chính là viết tài liệu xác định mọi chức năng, mọi hành vi của hệ thống. Tài liệu này được gọi là tài liệu Đặc tả chức năng (Functional Specifications - FS). 3.2.2. Sau khi viết xong Đặc tả chức năng, chúng ta đã có hiểu biết đầy đủ hơn về hệ thống thông tin cần phải xây dựng so với giai đoạn xác định, do đó cần xem xét lại kế hoạch dự án ban đầu. Trên cơ sở xem lại viết Kế hoạch dự án cuối cùng (Final Project Plan FPP). 3.2.3. Trong trường hợp dự án được thực hiện theo phương pháp hai bước thì kết thúc giai đoạn phân tích chính là kết thúc bước 1, ta cần đề xuất và đánh giá thực hiện bước hai. Đề xuất này được thể hiện qua việc viết Tài liệu để xuất phát triển (Development Proposal - DP). 3.2.4. Trong giai đoạn phân tích, ta cũng thực hiện một phần công việc của giai đoạn thiết kế. Đó là Thiết kế tổng thể (thiết kế mức tổng quát - Top level design - 37
37. TLD). Như vậy ở giai đoạn này không phải chúng ta chỉ xem xét hệ thống sẽ thực hiện các chức năng như thế nào. Toàn bộ các công việc vừa được môt tả thực chất tương ứng với giai đoạn viết các dự án CNTT của các Bộ, ngành, các Tỉnh, Thành phố vừa qua. 3.3 Viết tài liệu “đặc tả chức năng” Đặc tả chức năng là tài liệu mô tả toàn bộ hoạt động của hệ thống, các giao diện người sử dụng. Trong tài liệu này cần: • Mô tả chi tiết nhất có thể các thông tin vào, thông tin ra, các yêu cầu về thực hiện, các thủ tục, các quy trình • Giải thích các thay đổi môi trường của người sử dụng do đưa vào hệ thống mới. • Mô tả tất cả các sản phẩm chuyển giao bao gồm phần cứng, phần mềm, đào tạo, các tài liệu, các đảm bảo về bảo hành Đặc tả chức năng chính là tài liệu nói rõ “cái gì” hệ thống sẽ làm cho người sử dụng. Tài liệu này nếu làm nghiêm túc, cẩn thận sẽ giúp cho chúng ta: • Hệ thống hoá và ghi nhớ được đầy đủ các vấn đề, các yêu cầu, đặt ra đối với hệ thống, làm cơ sở pháp lý để giải quyết và triển khai các giai đoạn sau. • Giải quyết nhiều vấn đề phức tạp của hệ thống trước khi thực hiện thiết kế kỹ thuật và lập trình, làm cho việc nghiên cứu các dữ liệu, các chức năng xử lý và mối quan hệ giữa chúng được rõ ràng mạch lạc. • Tạo điều kiện thuận lợi để các nhóm chuyên gia khác nhau có thể kế thừa thực hiện hoặc hoàn thiện hệ thống trong những giai đoạn tiếp theo. Tài liệu đặc tả chức năng chỉ có thể hoàn thành sau một quá trình khảo sát thực trạng, thu thập ý kiến từ nhiều người, nhiều bộ phận nghiệp vụ khác nhau, sau nhiều buổi phân tích, trao đổi ý kiến của các bộ chuyên môn và các chuyên gia tin học. Đặc tả chức năng là kết quả đúc kết từ quá trình làm việc này và được trình bày như kết quả nhận thức của các nhà phân tích hệ thống về mọi khía cạnh của các vấn đề đặt ra qua các mức độ khái quát hoá khác nhau. Có một số phương pháp khác nhau có thể được sử dụng trong giai đoạn này và có thể tham khảo về các phương pháp đó trong các tài liệu về phân tích và thiết kế các hệ thống thông tin. Một điều cần chú ý là đặc tả chức năng là tài liệu kỹ thuật nhưng được viết cho những người không kỹ thuật đọc để làm cơ sở cho việc ký kết hợp đồng giữa đội thực hiện dự án và người sử dụng. Do đó rất khó viết. Cần học để hiểu biết công việc và ngôn ngữ của người sử dụng và từ đó có thể viết tài liệu theo quan điểm và thuật ngữ của người sử dụng. Dùng các sơ đồ nhiều nhất có thể được. Phải viết rất chính xác, tránh những từ mập mờ, những câu dễ hiểu sai. 38
38. 3.4 Dàn bài của đặc tả chức năng Tài liệu đặc tả chức năng có thể được viết dựa trên dàn bài sau: 1. Trang bìa, số phiên bản (do tài liệu này có thể được viết và sửa lại một số lần nên cần đánh số phiên bản để biết đó là tài liệu soạn lần thứ mấy). 2. Mục lục. 3. Tổng quan về hệ thống: trong phần này cần mô tả chung về hệ thống, các chức năng chính, quan hệ giữa chúng. Như đã nói ở trên, đặc tả chức năng là tài liệu kỹ thuật, song viết cho người sử dụng (những người không kỹ thuật) đọc. Do đó nên cố gắng dùng nhiều sơ đồ, vì trên sơ đồ người dùng dễ hình dung các chức năng của hệ thống cũng như quan hệ của các chức năng đó. 4. Các mục tiêu chính: Liệt kê các mục tiêu của hệ thống, quan hệ mỗi mục tiêu với các modun của hệ thống. Cần mô tả hệ thống mới được xây dựng sẽ ảnh hưởng đến môi trường của người sử dụng như thế nào: các máy chủ, máy trạm sẽ đặt ở đâu, ai sẽ là người sẽ sử dụng chúng, chức năng của mỗi máy, các tài liệu sẽ được sinh ra như thế nào, hệ thống sẽ thay đổi công việc của mỗi người như thế nào. 5. Mô tả các thành phần chức năng: Đối với mỗi thành phần, mỗi chức năng cần có mô tả chi tiết. Mỗi thành phần của phần cứng được liệt kê để giúp người sử dụng thấy chúng tương tác qua lại với họ như thế nào (lưu ý đây chưa phải là bản thiết kế). Đối với mỗi thành phần của phần mềm cần chỉ ra: các chức năng các quy trình xử lý, các thông tin vào, các thông tin ra, các xử lý, các dữ liệu đưởc sử dụng. Có thể sử dụng các sơ đồ luồng dữ liệu, hoặc sơ đồ luân chuyển tài liệu hoặc các sơ đồ cấu trúc khác. Trong phần này cần có các mô hình: - Các mô hình chức năng nghiệp vụ. - Mô hình dòng dữ liệu (DFD). - Mô hình thực thể - quan hệ (ERD). 6. Các yêu cầu hệ thống: trong phần này cần trình bầy các yêu cầu chung đối với hệ thống, ví dụ: - Tính tương thích: các thành phần tương tác với nhau như thế nào? - Tính tin cậy - Tính an toàn. - Tính dễ sử dụng Các vấn đề tinh tế như khả năng của hệ thống phản ứng để cho câu trả lời (tính bằng thời gian cần thiết để máy tính có thể trả lời, công suất (tổng lượng công việc được giải quyết qua máy tính trong một thời kỳ), sự tăng trưởng (đáp ứng nhu cầu sau một vài năm), cần được đề cập ở đây. Những vấn đề này là những vấn đề khó, và chúng ta không thể cho những câu trả lời quá chắc chắn về chúng). 39
39. 7. Các sản phẩm chuyển giao khác: - Các tài liệu - Huấn luyện, đào tạo 8. Sự chấp nhận: Người sử dụng sẽ kiểm tra hệ thống như thế nào để chấp nhận nó. Một trong những vấn đề lớn nhất của tin học là người sử dụng thường rất miễn cưỡng khi phải chấp nhận và thanh toán tiền thực hiện hệ thống. Họ sợ rằng sau khi trả tiền, nếu hệ thống trục trặc có thể đội dự án không sửa chữa, khắc phục kịp thời cho họ. Về vấn đề này sẽ được bàn kỹ hơn trong chương sau. 9. Quản lý dự thay đổi: Chúng ta sẽ phải xử lý các thay đổi như thế nào sau khi dự án bắt đầu thực hiện. Đặc tả chức năng là bước xuất phát, các khoản mục lần lượt được xây dựng dựa trên nó. Thay đổi đặt tả chức năng có thể gây nên thay đổi các khoản mục này và có thể làm chậm trễ dự án. Các thay đổi do đó cần phải cố gắng để là ít nhất. Cần phải có một thủ tục để quản lý các thay đổi, đánh giá tác động của nó cũng như kinh phí cần thiết để thực hiện các thay đổi. Ví dụ một thủ tục có thể như sau: Lập một “Tiểu ban quản lý sự thay đổi” gồm ít nhất một người từ phía các người sử dụng (thường là người điều phối dự án của phía người sử dụng) và một người từ đội dự án (thường là người quản lý dự án). Thông báo cho toàn bộ những người sử dụng biết tất cả những sự thay đổi cần phải thông qua người điều phối dự án phía người sử dụng để đến đội dự án. Hàng tuần, hoặc khi cần thiết tiểu ban họp và tất cả các thay đổi cần đưa cho người quản lý dự án. Người sử dụng xắp thứ tự ưu tiên các thay đổi từ “bắt buộc” đến “mong muốn”. Người quản lý dự án thảo luận về các thay đổi với đội dự án, phân loại các thay đổi từ dễ đến khó, đưa ra các giải pháp và thảo luận với người sử dụng trong phiên họp tiếp theo. Những thống nhất sẽ được đưa vào thực hiện. 10. Trao đổi ý kiến giữa người sử dụng và tổ dự án: Cần có quy định về những trao đổi ý kiến giữa người sử dụng và đội dự án ở cả mức kỹ thuật lẫn mức quản lý. Phía người dùng cần chỉ định ít nhất một người có đủ hiểu biết và thẩm quyền để trả lời các câu hỏi liên quan đến các vấn đề kỹ thuật (không chỉ ở giai đoạn này, mà suốt trong tiến trình thực hiện dự án). Tương tự ở mức quản lý cũng cần có trao đổi ý kiến về các vấn đề như kinh phí, nhân sự, lịch biểu, tiến độ, các thay đổi 11. Các trách nhiệm của người sử dụng. 12. Các thuật ngữ, các điều kiện và các giả thiết. 40
40. 3.5 Xem xét lại kế hoạch Làm kế hoạch là quá trình lặp. Do đó ngay sau khi tiến hành phân tích xong, cần xem xét lại kế hoạch dự án ban đầu (PPP). Cần nhớ rằng đã nhiều thời gian trôi qua kể từ khi chúng ta viết kế hoạch dự án ban đầu và rất nhiều hiểu biết đã được bổ sung trong thời gian đó. Do đó có điều kiện để đánh giá lại cơ cầu phân việc, các nhiệm vụ, bổ nhiệm người thực hiện, lên lịch và thực hiện. Quan trọng nhất phải xem xét vấn đề nhân sự: Những người được đề nghị để thực hiện các nhiệm vụ đã đảm bảo sẵn sàng khi cần đến hay chưa. Đây là thời điểm tốt nhất để tiến hành kế hoạch hoá phòng ngừa rủi ro, các sự cố bất ngờ. Đối với mỗi chức danh cần đặt câu hỏi “Làm thế nào nếu người đó không có hoặc có nhưng nhận nhiệm vụ muộn?”. Cần phải đề xuất kế hoạch thay thế. Ví dụ về một khó khăn có thể xuất hiện ở các giai đoạn tiếp theo cùng với các đề xuất về kế hoạch phòng ngừa. Lập trình viên chính hoặc thiết kế việc chỉnh bỏ công việc. Ta có thể đào tạo nguồn dự bị. Có thể dùng hệ thống “Người bạn” trong đó lập trình viên có thể được dự tính để làm bạn với lập trình viên chính. Công việc của người bạn chỉ là “hầu hạ điếu đóm” cho lập trình viên chính, song cần học tập từ lập trình viên chính để có thể quản lý được công việc nếu người này bỏ đi. 3.6 Kế hoạch dự án cuối cùng Sau khi xem xét lại dự án ban đầu cần viết kế hoạch dự án cuối cùng. Về bố cục, kế hoạch dự án cuối cùng giống như kế hoạch dự án ban đầu, song từng khoản mục cần được xem xét, điều chỉnh, chi tiết hoá, chính xác hoá. Mức đánh giá tại thời điểm này là mức B (+ - 25%). Đồng thời trong báo cáo dự án cuối cùng cần bổ sung thêm các phần: - Quản lý sự thay đổi. - Đào tạo, huấn luyện đội dự án. 3.7 Thiết kế tổng thể Như đã nói ở đoạn 3.2, trong giai đoạn phân tích, không nên chỉ hình dung hệ thống sẽ “làm gì”, mà cũng nên hình dung ở mức tổng thể hệ thống sẽ hoạt động “như thế nào”. Đó là nhiệm vụ của thiết kế mức tổng thể. Thiết kế mức tổng thể là mô tả chung kiến trúc hệ thống. Mô tả này được bắt đầu bằng việc nêu ra các thành phần chính của phần cứng và chúng được nối với nhau trên mạng như thế nào. Tiếp theo là nêu ra các thành phần chính của phần mềm: Liệt kê các phần mềm trên các máy chủ (máy phục vụ), trên mỗi máy khách hàng. Đối với mỗi phần mềm cần đặt làm, phải có thiết kế riêng. Mức tổng quát chỉ kể ra các thành phần chính của phần mềm. Thiết kế mức tổng thể được tiến hành bằng phương pháp thiết kế có cấu trúc. Đó là phương pháp phân chia dần hệ thống thành các thành phần nhỏ hơn, có thể 41
41. quản lý và xây dựng. Thiết kế có thể bắt đầu từ trân xuống, tức là xuất phát từ các thành phần chính và phân rã dần thành các thành phần nhỏ hơn; hoặc ngược lại theo phương pháp từ dưới lên, bắt đầu từ mức thấp nhất và tổng hợp dần lên. Phương pháp từ dưới lên thường được sử dụng trong trường hợp khi tổ hợp các phần mềm thành phần đã có sẵn thành các môđun mới để tạo thành hệ thống. Có thể có một số phương án khác nhau cho thiết kế mức tổng thể và chúng ta phải tiến hành lựa chọn phương án tốt nhất. Để lựa chọn cần chú ý đến tác động của từng phương án đến các yếu tố sau đây: - Chi phí hệ thống - Thời gian cần thiết để xây dựng hệ thống. - Tính thân thiện đối với người sử dụng - Thực hiện - Kích thước hệ thống - Độ tin cậy - Khả năng thay đổi. 3.8 Kết luận Các mốc chính của giai đoạn phân tích là: 1. Đặc tả chức năng được hoàn thành, thông quan và ký nhận. 2. Nếu dự án được thực hiện theo phương án hai bước, thì cần viết tài liệu đề xuất phát triển. 3. Kế hoạch dự án ban đầu được xem xét lại và từ đó hoàn thành kế hoạch dự án cuối cùng. 4. Hoàn thành thiết kế mức tổng thể. Câu hỏi 1. Mục tiêu của giai đoạn phân tích là gì? Tại sao giai đoạn này là giai đoạn quan trọng nhất đối với người sử dụng. 2. Hãy viết đặc tả chức năng một phần hệ thông tin của cơ quan bạn. 3. Tại sao phải xem lại kế hoạch dự án ban đầu và đánh giá sau khi đã tiến hành phân tích. 4. Các bước của giai đoạn phân tích. 42
42. Chương 4. Giai đoạn thiết kế 4.1 Mục tiêu Gia đoạn thiết kế nhằm mục tiêu xác định chính xác hệ thống sẽ làm việc “như thế nào”. Nói một cách khác nó phải xác định các bộ phận, các chức năng và các mối liên kết giữa chúng của hệ thống. 4.2 Các công việc Viết thiết kế hệ thống thông tin được tiến hành lần lượt theo 3 mức: + Mức tổng thể: Như đã trình bày trong chương 3, thiết kế mức tổng thể thường được thực hiện ở cuối giai đoạn phân tích. Nó cho thấy kiến trúc chung của hệ thống về cả phần cứng và phần mềm. Sử dụng các mô hình khái niệm để minh hoạ. + Mức giữa: Thiết kế ở mức giữa đơn giản là tiếp tục việc chia nhỏ bản thiết kế ở mức tổng thể thành các thành phần nhỏ hơn. Các thành phần của phần cứng được chi tiết đến mức các khối. Các thành phần phần mềm được chi tiết đến mức các chương trình trong mỗi Môđun hoặc mỗi ứng dụng. Sử dụng đến các mô hình logic để minh hoạ. + Thiết kế Môđun: (được tiến hành trong giai đoạn thực hiện): đây là mức (thấp nhất) chi tiết nhất, nhằm thiết kết ra các thành phần cơ bản tạo ra phần cứng, các chương trình con tạo thành các chương trình phần mềm ứng dụng. Mức này thường do các chuyên gia phát triển làm trong giai đoạn thực hiện. Các sơ đồ ở đây chi tiết đến từng dữ liệu và thao tác một. Với quy trình thiết kế mô tả như trên, các công việc của giai đoạn thiết kế bao gồm: 4.2.1 Thiết kế hệ thống mức giữa và phối hợp với kết quả thiết kế hệ thống mức tổng thể để viết tài liệu Đặc tả thiết kế (Design Specification - DS) 4.2.2 Soạn thảo tài liệu “Kế hoạch kiểm thử để chấp nhận” (Acceptance Test Plan - ATP). Đây là tài liệu liệt kê tất cả các phép thử sẽ phải thực hiện để 43
43. kiểm tra tất cả các chức năng của hệ thống cho người dùng thấy trong giai đoạn chấp nhận. Mốc chính của giai đoạn này là tài liệu Đặc tả thiết kế được xem xét thông qua và được chứng tỏ là không sai sót. Cũng có thể trong giai đoạn này người sử dụng kế duyệt “Kế hoạch kiểm thử để chấp nhận”. 4.3 Một số chú ý - Trong khi giai đoạn phân tích sử dụng một số ít các thủ thuật mô hình hoá, các kỹ thuật này để cấu trúc hoá cho Đặc tả chức năng, thì giai đoạn thiết kế dường như phức tạp hơn, chứa nhiều kiểu kỹ thuật hơn, song thực lại kém được chỉ dẫn hơn. Có rất nhiều độ linh hoạt trong việc dùng cụ thể các kỹ thuật đó: dùng ở đâu, dùng khi nào. - Trong giai đoạn thiết kế, vai trò và công sức của các nhà quản lý giảm. Công việc chủ yếu liên quan đến các nhà thiết kế, các chuyên gia phát triển, các lập trình viên và những người xét duyệt. Vai trò của nhà quản lý ở giai đoạn này chủ yếu chỉ là giám sát và theo dõi. Tuy nhiên để có thể làm nhà quản lý tốt, ta cũng nên biết được nội dung cơ bản của các công việc đang được tiến hành trong giai đoạn này. ở đây chúng ta không đi sâu vào các phương pháp và công cụ thiết kế. - Trong giai đoạn thiết kế nên cố gắng phân chia dự án thành các dự án con. Mỗi dự án con có thể đòi hỏi một người quản lý dự án và một đội thực hiện dự án riêng. 4.4 Đặc tả thiết kế Tài liệu đặc tả thiết kế là tài liệu mang tính chất kỹ thuật. Nó được viết để cho các lập trình viên đọc và hiều để thực hiện. Những người sử dụng cũng có thể đọc song không nhất thiết phải hiểu tất cả. Khi viết tài liệu này cần chú ý đến các điều sau đây: - Phải sử dụng ngôn ngữ chặt chẽ, chính xác. Nguyên nhân lớn thứ hay gây ra sai sót trong hệ thống phần mềm là do lập trình viên hiểu sai thiết kế (Nguyên nhân lớn gây ra sai sót là do nhà phân tích hiểu sai nhu cầu của người dùng). - Sử dụng các sơ đồ, các hình vẽ, các mô hình thiết kế chuẩn. - Hãy cố gắng làm cho các ý đồ thiết kế được thể hiện ngay trong những trang đầu tiên, sau đó sẽ giải thích chi tiết. - Bảo đảm tính nhất quán về ngôn ngữ trình bày, cả về lời văn lẫn các hình vẽ. Cách tốt nhất là để một người viết toàn bộ. Trong trường hợp cấp bách về thời gian phải dùng một số người viết thì những người này phải cố gắng để có văn phòng chung. 44
44. Nội dung của một tài liệu “Đặc tả thiết kế” có thể bao gồm các vấn đề chủ yếu sau đây: 1. Tổng quan về hệ thống thông tin: - Các mục tiêu - Các sơ đồ thiết kế cấu trúc 2. Các chuẩn và các quy ước: Trong thiết kế cần thiết lập các chuẩn cho mỗi thành phần. Nếu không quy định, việc liên kết giữa các thành phần không thể tốt được. - Phần cứng: + Các thành phần: Các sơ đồ cấu trúc, máu chủ, máy trạm, mạng. + Các nhà cung cấp - Phần mềm + Các loại thành phần + Các nhà cung cấp + Các phương pháp thiết kế có cấu trúc + Các phương pháp lập trình có cấu trúc - Các phương pháp kết nối. 3. Các thành phần chức năng: Liệt kê tất cả các thành phần chức năng, các modun; Đối với mỗi thành phần chính: - Quyết định làm, mua hay sửa đổi cho thích ứng. - Chia thành các thành phần con - Liệt kê các thành phần 4. Các cơ sở dữ liệu, các file và các bảng: Liệt kê tất cả và đối với mỗi loại hãy chỉ rõ: - Mục đích - Sử dụng - Loại - Thiết lập dữ liệu ở mức vật lý - Tạo lập - Duy trì, cập nhật - Tổ chức - Kiểu dạng - Các giới hạn - Vị trí Đối với mỗi dự án con đều phải có một bản đặc tả thiết kế. 45
45. 4.5 Một số vấn đề trong quá trình thiết kế 4.5.1 Đội thiết kế Nhà quản lý dự án phải chọn những người tốt nhất vào đội thiết kế: họ phải là những người có đầu óc tổng hợp, có thể hình dung tổng thể sự việc. Cần tránh quan điểm cầu toàn, hoàn thiện trong đội thiết kế. Chúng ta luôn luôn có thể tìm ra cách tốt hơn để thực hiện dự án nếu có đủ thời gian và nguồn lực, nhưng cần phải nhớ là chúng ta bị hạn chế về thời gian và kinh phí. Có nhiều sự so sánh lựa chọn phải làm trong thời gian thiết kế, do đó đội nên có một số lẻ người, hoặc ít ra phải có đội trưởng giỏi, để dễ dàng trong việc bỏ phiếu quyết định một vấn đề gì đó cần sự thống nhất. Đối với đội thiết kế cần lập kế hoạch lên các lịch họp và cố gắng đảm bảo các cuộc họp được liên tục. 4.5.2. Rà soát lại bản thiết kế Cần tiến hành các cuộc họp để rà soát lại bản thiết kế trên khía cạnh kỹ thuật. Cuộc họp gồm các đại biểu của đội dự án và có thể có thêm các đại biều từ các nhóm khác. Trong khi rà soát lại cần đảm bảo rằng thiết kế: - Đáp ứng được tất cả các đặc tả chức năng đã đề ra. - Được chia thành các thành phần một cách logic. - Mọi vấn đề kỹ thuật được trình bầy rõ ràng, dễ hiểu và nằm trong giới hạn về thời gian và giấ cả. 4.6 Vấn đề chấp nhận dự án Chấp nhận dự án là việc người sử dụng khẳng định bằng văn bản rằng sản phẩm đã được cung cấp đúng như thoả thuận, và nếu đó là dự án được thực hiện dưới dạng hợp đồng thì cần tiến hành thanh toán hợp đồng. Mặc dù chưa đến giai đoạn chấp nhận, song giai đoạn thiết kế là thời điểm tốt nhất để bắt đầu lập kế hoạch cho giai đoạn này. Chính tại giai đoạn chấp nhận, lần đầu tiên người dùng thực sự mới được trông thấy và sử dụng sản phẩm. Họ cần kiểm tra để xem có chấp nhận được sản phẩm đó hay không. Các phương pháp để kiểm tra: 4.6.1 Phương pháp cổ điển: Giai đoạn chạy thử hoặc cho chạy song song - Giai đoạn chạy thử là giai đoạn đội dự án cài đặt hệ thống và cho người sử dụng chạy thử nghiệm. 46
46. - Cho chạy song song là hệ thống mới được cài đặt song vẫn duy trì hệ thống cũ và cả hai hệ thống được hoạt động song song để có thể so sánh các kết quả. Trong cả hai trường hợp, khách hàng sử dụng hệ thống mới trong một khoảng thời gian quy định nào đó. Trong khoảng thời gian này nếu hệ thống hoạt động không nảy sinh vấn đề gì thì hệ thống được chấp nhận. Nếu có vấn đề nẩy sinh thì đội dự án phải sửa chữa, khắc phục và hệ thống lại được chạy thử nghiệm lặp lại một khoảng thời gian nữa. Phương pháp cổ điển này có ưu điểm là đơn gian, dễ lập kế hoạch, song có nhiều nhược điểm. Các nhược điểm đó là: • Nếu liên tục có nhiều vấn đề nhỏ nẩy sinh đối với hệ thống, thì hệ thống phải chạy thử nghiệm lặp đi lặp lại không biết bao nhiêu lần để có thể chấp nhận hệ thống. Đôi khi một hệ thống phần mềm phức tạp có thể không bao giờ sửa chữa hết lỗi được và ta phải biết cách chung sống với lỗi. • Có thể rất khó khăn để tìm ra được nguyên nhân của những trục trặc nẩy sinh. Khi có tới hàng chục người cùng hoạt động trên một hệ thống phức tạp gồm nhiều thành phần tương tác với nhau thì khi có trục trặc, có thể rất khó biết nguyên nhân tại sao. • Không có gì đảm bảo là các đặc tính cơ bản của hệ thống đã được kiểm tra đầy đủ trong thời gian chạy thử: Hệ thống có thể hoạt động tốt trong thời gian thử nghiệm, song sau khi đã hết thời gian bảo hành nó mới trục trặc. Khi đó nhà cung cấp không còn chịu trách nhiệm khắc phục vấn đề nẩy sinh. • Có thể để lại ấn tượng không tốt cho người dùng: Thường khi cài đặt lần đầu tiên, hệ thống còn nhiều lỗi. Những lỗi đó tạo ấn tượng không tốt của người dùng đối với hệ thống. Để có thể khắc phục những nhược điểm của phương pháp cổ điển, người ta có thể dùng phương pháp tốt hơn để thử nghiệm hệ thống: 4.6.2 Phương pháp trình diễn hoặc kiểm tra lần lượt tất cả các chức năng: Phương pháp tốt hơn để có thể chấp nhận hệ thống là đưa ra một chuỗi các phép thử để trình diễn và kiểm tra tất cả các chức năng đã thoa thuận. Quá trình chấp nhận sẽ tiến hành tất cả các phép thử này đối với khách hàng. Các phép thử nghiệm thành công sẽ được ký nhận lần lượt. Nếu phép thử nào thất bại, đội dự án cần khắc phục vấn đề nẩy sinh, nếu vấn đề đơn giản thì sửa chữa ngay, nếu vấn đề nghiêm trọng thì quá trình thử nghiệm được hoãn lại cho đến lúc khắc phục xong. Về nguyên tắc chỉ cần thử lại các phép thử không thành công, song người sử dụng có quyền chạy lại các phép thử đã được chấp nhận trước khi nẩy sinh vấn đề. Như vậy để tiến hành chấp nhận theo phương pháp này cần thực hiện các công việc sau đây: • Liệt kê tất cả các chức năng mà hệ thống cần phải thực hiện. 47
47. • Xác định các phép thử nghiệm đối với từng chức năng. Danh sách các phép thử chính là tài liệu “Kế hoạch kiểm thử chấp nhận”. • Thực hiện lần lượt các phép thử nghiệm đối với người sử dụng • Chỉ chạy lại các phép thử nghiệm không thành công, các phép thử nghiệm thành công được người sử dụng ký nhận. Phương pháp này có những lợi ích sau đây: • Có thể trình diễn tất cả các chức năng đã thoả thuận. • Dễ dàng nhận biết nguyên nhân gây ra các trục trặc. • Có thể lặp lại. • Người sử dụng thoải mái khi ký nhiều chữ ký cho từng phần hơn là ký một chữ ký cho toàn bộ. Phương pháp này cũng có những nhược điểm: • Phải mất nhiều công sức để viết tài liệu “Kế hoạch kiểm tra để chấp nhận” và thực hiện kế hoạch đó. • Người sử dụng không quen với phương pháp này. 4.7 Xem xét lại các ước lượng Tại thời điểm cuối của giai đoạn thiết kế, chúng ta tiếp tục xem xét lại kế hoạch dự án, đặc biệt là xem xét lại các đánh giá. Mặc dù bây giờ chúng ta chỉ đánh giá bốn giai đoạn còn lại, song phần lập trình trong giai đoạn thực hiện có thể là tốn kém thời gian và công sức nhất trong toàn bộ dự án. Thiết kế cho chúng ta biết số các môđun và ước lượng độ phức tạp của chúng. Đồng thời bây giờ ta cũng đã biết ai sẽ là lập trình viên và có thể đưa năng suất của họ vào các đánh giá. Như vậy có thể dễ dàng đánh giá chính xác hơn lượng thời gian cần thiết để lập trình. Thống kê đã cho thầy là vào cuối giai đoạn thiết kế, ước lượng thuộc loại lớp A (sai số +/- 10%). 4.8 Kết luận Các mốc chính của giai đoạn thiết kế là: • Tài liệu đặc tả thiết kế được hoàn thành và thông qua. • Soạn thảo tài liệu Kế hoạch kiểm tra để chấp nhận • Đánh giá lại các ước lượng. Câu hỏi 1. Mục tiêu của giai đoạn thiết kế là gì? 2. Các mục của giai đoạn thiết kế là gì? 3. Các ưu điểm và nhược điểm của các phương pháp kiểm tra để chấp nhận dự án. 48
48. Chương 5. Giai đoạn thực hiện Mục đích: Thiết kế chi tiết và cài đặt, ráp nối các thành phần, các module trong hệ thống bao gồm cả phần cứng và phần mềm. Các công việc chính: - Thiết kế chi tiết các module và lập trình - Chế tạo các phần trong hệ thống - Dự toán và tổ chức mua thiết bị phần cứng/phần mềm - Chỉnh sản phẩm cho phù hợp với yêu cầu thực tế - Kiểm thử từng phần các module, phân hệ - Biên soạn tài liệu Các tài liệu cần hoàn thành: - Tài liệu thiết kế chi tiết các thành phần trong hệ thống (Thông qua về chuyên môn kỹ thuật) - Tài liệu dự toán/ kế hoạch mua trang thiết bị phần cứng/ phần mềm (Thông qua về chuyên môn kỹ thuật) - Kế hoạch kiểm thử hệ thống (Thông qua về chuyên môn kỹ thuật) - Biên bản kiểm thử các thành phần (Thông qua về chuyên môn kỹ thuật) - Kế hoạch sửa đổi thích nghi các sản phẩm đã có/ mua để phù hợp với yêu cầu (Thông qua về chuyên môn kỹ thuật và người sử dụng) - Tài liệu người sử dụng (Người sử dụng thông qua về sau). Các cuộc họp: - Rà soát thiết kế chi tiết các module và kế hoạch kiểm thử module, hệ thống - Rà soát tài liệu người sử dụng 49
49. 5.1 Nhập đề Quản lý dự án trong Thiên về kỹ thuật nhằm theo dõi, kiểm tra giai đoạn thực hiện ≡ triển khai lập trình theo thiết kế, tiến độ và chất lượng công việc Thiết kế Cài đặt thực hiện + Phân chia hệ thống thành các phần nhỏ + Cài đặt, lập trình các module cơ bản hơn, cho đến khi có thể sẵn sàng cài đặt + Ghép nối các module, phân hệ (Phần trên các ngôn ngữ lập trình cụ thể cứng, phần mềm) thành các module lớn hơn đảm nhiệm một chức năng cụ thể cho khi giải quyết được bài toán ban đầu đặt ra. + Theo kiểu trên - xuống + Theo kiểu dưới - lên Thiết kế hệ thống Phân hệ 1.1 Phân hệ 1.2 Phân hệ 2.1 Thiết kế Thiết kế thao tác xử lý CSDL Phân hệ 1 Phân hệ 2 Phân hệ 1 Phân hệ 2 Hệ thống 5.2 Tổ chức lập trình các module cơ bản; ghép nối hệ thống 5.2.1 Những nguyễn tắc cơ bản trong quản lý thực hiện và cài đặt hệ thống • Lưu ý sự ăn khớp về nhân lực và thông tin giữa các giai đoạn. • Tổ chức và quản lý việc lập trình và cài đặt hệ thống theo tiến độ, mà không đi quá sâu vào các chi tiết kỹ thuật trong các nhóm phát triển. • Không nên bắt đầu giai đoạn lập trình và cài đặt khi các giai đoạn trước đó (phân tích, thiết kế) chưa hoàn tất. 50
50. • Các phân tích và thiết kế càng chi tiết, cụ thể càng dễ dàng cho việc cài đặt, do vậy tránh được không phải làm lại. Những điều nên tránh • Tránh tình trạng nôn nóng, gây sức ép và áp đặt thực hiện công việc cụ thể từ phía cán bộ quản lý, cán bộ lãnh đạo cấp trên. Phải tuân thủ đầy đủ các công đoạn trong quá trình phân tích, thiết kế, cài đặt, thử nghiệm. • Bệnh của các nhà quản lý là hay thắc mắc “Tại làm sao bọn họ (ám chỉ các lập trình viên, chuyên gia tin học) chẳng thấy làm gì cả” và thường họ hay phiền lòng, lo lắng khi các lập trình viên ngồi suy nghĩ trước máy. Đây là quan niệm sai, bởi lẽ các cân nhắc kỹ lưỡng trước khi lập trình sẽ làm cho năng suất lập trình cao lên, vả lại chi phí bảo trì phần mềm sẽ giảm xuống đáng kể. 5.2.2 Các công việc chuẩn bị trước khi tiến hành lập trình, cài đặt Trước khi bắt tay vào giai đoạn lập trình, các chuyên gia quản lý dự án phải trả lời các câu hỏi sau: • Kết quả rà xét lại thiết kế có yêu cầu phải làm lại một phần nào đó trong hệ thống không? Nếu có, phải sắp xếp thời gian một cách phù hợp và không nên bắt đầu lập trình khi chưa giải quyết ổn thoả mọi chuyện. • Các nguồn nhân lực, vật lực và thông tin, cũng như là các lập trình viên lúc nào cũng sẵn sàng và dự an sẽ kết thúc đúng theo kỳ hạn. Khi có thay đổi nhân sự vì bất cứ lý do gì, cần phải lượng trình năng suất công việc của người mới đến thay thế để có thể trù liệu trước mọi chuyện đáp ứng được hạn định đã đặt ra. Bởi lẽ trong các công ty với các điều kiện làm việc như nhau, một chuyên gia lập trình giỏi có thể làm việc với năng suất gấp 8 lần người có trình độ trung bình. • Mọi người đã được đào tạo chưa? Chẳng hạn, khi bắt tay vào công việc, các lập trình viên phải biết rõ về hệ điều hành, ngôn ngữ lập trình và các công cụ lập trình sẽ được sử dụng. Họ còn phải làm quen với ứng dụng mà người sử dụng đặt hàng cũng như bài toán cần giải quyết. Một điều quan trọng là phải cung cấp tài liệu đầy đủ đề các lập trình viên biết rõ về tài liệu yêu cầu và đặt tả chức năng. • Mô trường lập trình dành cho các thành viên trong dự án đó được chuẩn bị tốt, đáp ứng các yêu cầu của công việc không? Kinh nghiệm triển khai thực tiễn đã chứng tỏ rằng nên chọn những phần mềm và công cụ lập trình dễ sử dụng. Các máy tính dùng để phát triển công việc của dự án phải đáp ứng được yêu cầu: trả lời nhanh (tốc độ cao), dung lượng bộ nhớ đủ lớn, có độ tin cậy cao và cung cấp đủ khi cần thiết. Một điểm quan trọng khác là phải đảm bảo các thiết bị vẫn đang được nhà sản xuất bảo hành, các tài liệu về phần mềm phát triển vẫn đang được cập nhật thường xuyên. Trong thời gian thực hiện dự án phải luôn đảm bảo hệ thống không bị gián đoạn. 51
51. 5.2.3 Các bước lập trình Bước 1. Đặt kế hoạch tích hợp và kiểm thử hệ thống: Kinh nghiệm xây dựng các hệ tin học cỡ lớn chỉ ra rằng không nên và không thể xây dựng một chương trình giải quyết được tất cả mọi việc. Trong những trường hợp như vậy, cách làm phân chia hệ thống thành các module nhỏ hơn thường tỏ ra hợp lý. Sau đó người ta tiến hành ráp nối các module một cách nhịp nhàng. Các nhà quản lý dự án phải đặt kế hoạch một cách rõ ràng, đưa ra thứ tự ghép nối các module sẽ được lập trình theo thứ tự tích hợp vào hệ thống. Kế hoạch này được gọi là kế hoạch kiểm thử hệ thống. Các bước sau đây (bước 2 ÷ bước 9) chỉ liên quan tới một module của hệ thống mà thôi. Bước 2. Thiết kế các module Ở bước này, các lập trình viên nhận bản đặc tả thiết kế được bàn giao lại từ giai đoạn thiết kế (do kết quả của việc thiết kế mức tổng thể và mức trung gian). Công việc ở đây là tiếp tục chia nhỏ thành các mức thấp hơn cho đến khi đạt tới các công việc “sơ cấp” theo nghĩa có thể lập trình được ngay bằng một ngôn ngữ lập trình nào đó. Quá trình này được gọi là quá trình thiết kế các module hay thiết kế mức dưới. Ví dụ: Lập trình viên nhận được từ giai đoạn thiết kế sơ đồ ở mức trung gian như sau: Menu AMM00000 Bắt đầu Kéo - nhả Bấm chuột Hành động Lỗi AMST0000 AMDR0000 AMC0000 AMA0000 AME0000 Di Lỗi Lỗi Thực Thu Sửa đổi Báo chuyển đơn con nhập cáo con trỏ Thông Lỗi/ trợ báo lỗi/ giúp trợ giúp Hình vẽ 5.1 Sơ đồ thiết kế mức 3 Lập trình viên còn nhận được từ giai đoạn thiết kế mô tả về module như sau: 52
52. Tên module: AMST0000 Gọi bởi: AM000000 Các chương trình con được gọi đến: Các tham số vào: không Hiển thị: không Các tham số trở lại: Nếu không có lỗi đưa ra mã 0. Nếu có lỗi, đưa ra mã số của lỗi. Các biến ngoài đước sử dụng: Các tệp được sử dụng: STUDENT.DAT (open), COURSE.DAT (open), MATERIAL.DAT (open), SYSTEM.DAT (open), Các chức năng: + Mở Tệp STUDENT.DAT, COURSE.DAT, MATERIAL.DAT, SYSTEM.DAT. Nếu có lỗi, đưa ra các mã lỗi. + Khởi tạo biến + Kiểm tra xem có bị sự cố tắt máy thông qua bản ghi 1 trong tệp SYSTEM.DAT Byte 1 = -1 nghĩa là tắt máy đúng, nếu khác - 1 làm những việc sau + Bảo đảm trạng thái chính của - Chuột nhờ kiểm tra Nếu có lỗi - Màn hình nhờ kiểm tra Nếu có lỗi - Mang nhờ kiểm tra - Nếu có lỗi - + Mã lỗi thoát hệ thống bình thường là 0. Lập trình viên đầu tiên vẽ sơ đồ cấu trúc của module như sau: AMST0000 (Khởi tạo hệ thống) Vào - Thoát Kiểm tra trạng Mở tệp Mở tệp Khởi tạo thái tắt hệ thống biến Hình vẽ 5.2. Chia nhỏ module ở mức 4 53
53. Thiết kế module được tiến hành từ trên xuống dưới, bắt đầu từ ô trên cùng AMST0000 và chia nhỏ nó thành các phần con thích hợp như trên hình vẽ 5.3 AMST0000 1.1.1 1.1.2. 1.1.3. 1.1.4. AMSTSHC AMSTHWCK AMSTOPFI AMSTiNva K AMSTMENU AMSTERRO 1.1.5 1.1.6 Hình vẽ 5.3. Chia nhỏ module ở mức 5 Tiếp sau đó, mỗi thành phần lại được chia nhỏ như trên hình vẽ 5.4 1.1.1 AMSTSHCK AMSTSHOP AMTSHW AMSTSHCD M Hình vẽ 5.4. chia nhỏ module ở mức 6 Quá trình cứ tiếp tục như vậy cho đến một mức đủ chi tiết để các thành phần có thể lập trình được. Câu hỏi đặt ra. Quá trình thiết kế hệ thống sẽ dừng lại ở mức chi tiết như thế nào và khi nào bắt tay vào thiết kế chi tiết từng module? Câu trả lời. Quá trình thiết kế hệ thống nhằm chia nhỏ các module tới mức người lập trình có thể bắt đầu công việc của mình nghĩa là các đặc tả về dữ liệu và thao tác đủ rõ ràng và tường minh để có thể mã hoá thông qua một ngôn ngữ lập trình nào đó. Hơn nữa, mức độ chi tiết hoá tuỳ thuộc vào từng dự án một hay từng phần trong hệ thống, thậm chí cả quan niệm của người lập trình đảm nhận phần việc được giao. Cần phải xem xét các yếu tố như: 54
54. • Nếu chia nhỏ các module là yêu cầu cấp thiết nhằm đáp ứng các đặc tính có độ ưu tiên cao như thời gian trả lời, giao diện hệ thống thân thiện cũng như tính tương hợp trong quá trình xử lý, thì người thiết kế có thể làm tới mức chi tiết sâu hơn. • Mức độ chi tiết trong thiết kế có thể được ghi lại trong hợp đồng. Các dự án tầm cỡ cơ quan chính phủ, các Bộ, Ngành thường quy định rõ số mức thiết kế cần phải tuân thủ. • Nếu lập trình viên không tham gia trong quá trình thiết kế, nên giả định là các thiết kế đó nhằm phục vụ cho các lập trình viên ở trình độ trung bình tức là làm rõ các chi tiết tới mức một lập trình viên hạng trung có thể hiểu và cài đặt được theo ý đồ thiết kế. Chú ý: Cần phải nhấn mạnh rằng các lập trình viên thường không thích nhận được bản thiết kế quá chi tiết tới mức lập trình chỉ còn là phát biểu lại hay dịch các mệnh đề tiếng Anh sang một ngôn ngữ lập trình nào đó. Bước 3: Rà soát thiết kế module Cũng như đối với các thiết kế ở mức trên và mức giữa, cần phải cân nhắc các điểm lợi/hại khi tiến hành thiết kế ở các mức dưới. Do vậy cần phải rà soát lại thiết kế của từng module trước khi lập trình. Công việc này nên tổ chức gọn nhẹ. Chỉ cần bản thân lập trình viên, người phụ trách trực tiếp và có thể là một lập trình viên cùng tham dự. Mục đích của việc rà soát lại thiết kế module là đảm bảo rằng đưa ra được một thiết kế tốt nhất có thể có được sao cho mọi chức năng đã được đề cập đến và tất cả mọi trục trặc đã được lường trước. Bước 4: Đặt kế hoạch kiểm thử module Lập trình viên phải lập kế hoạch kiểm thử module và dữ liệu trước khi bắt tay vào lập trình. Kế hoạch kiểm thử sau khi lập trình phải được xem xét. Trong kế hoạch này chỉ cần tập trung vào những “kiểm thử” đối với các phần khó nhất trong hệ thống. Người phụ trách dự án có thể tham gia rà soát kế hoạch kiểm thử cùng với rà soát thiết kế module. Theo kinh nghiệm, nên kết hợp 2 khâu này cùng một lúc. Bước 5: Lập trình các module Các tiêu chuẩn, các đòi hỏi đối với quá trình lập trình đã được trình bầy rõ trong giai đoạn thiết kế hệ thống (xem phần tài liệu kỹ thuật). Các cách tiếp cận khác nhau trong triển khai lập trình: • Cách tiếp cận cấu trúc • Cách tiếp cận hướng đối tượng Các tư tưởng lớn trong lập trình có cấu trúc là: • Phân chia các công việc thành các module nhỏ. Mỗi module đảm nhận 1 chức năng riêng biệt nào đó, khoảng 100 dòng mã lệnh thực hiện (không quá 2 trang văn bản chương trình). • Chỉ có một tham số vào, một tham số ra 55
55. • Càng ít biến tổng thể càng tốt • Các lệnh cầu trúc được dùng là: tuần tự, if then else, case , while do , repeat until , call Tránh dùng lệnh go to. Bước 6: Kiểm thử module: Lập trình viên tiến hành kiểm thử module sau khi chọn một phạm vi bài toán phù hợp với cùng một ó liệu thử - thông tin vào sao cho quá trình thực hiện phải đi qua các nhánh xử lý chính trong module và quan sát kết quả nhận được. Kinh nghiệm thực tế cho thấy nên tổ chức kiểm thử module theo giai đoạn. Giai đoạn 1 gọi là kiểm thử “hộp trắmg” theo nghĩa người lập trình biết rõ cái gì diễn ra bên trong module và đưa ra các dữ liệu kiểm thử đi qua tất cả các nhành lôgic trong chương trình. Giai đoạn 2 là kiểm thử “hộp đen”. Người lập trình bỏ qua mà không cần biết nội bộ của module, các dữ liệu kiểm thử được đưa ra theo trình tự và tần xuất như trong sử dụng thực tế. Ở giai đoạn này, cần phải chú ý và tránh được những lỗi đơn giản nhất (chẳng hạn lỗi gõ sai phím, lỗi sử dụng chuột, ). Bước 7: Kiểm thử các mức tích hợp thấp nhất: Nếu như một module nào đó gọi tới một vài module khác, thì lập trình viên có thể tích hợp chúng lại ngay sau khi đã hoàn tất công việc với từng module và tiến hành kiểm thử tất cả các module khi chúng phối hợp làm việc với nhau. Ngay cả khi lập trình viên không phải là người viết các module con này, anh ta vẫn phải kiểm thử các lỗi gọi tới chúng và kết quả trả lại. Cách tốt nhất để làm là tạo ra các “cuống chương trình” (program stub) thay cho việc sử dụng thực tế module này. Một cuống chương trình chỉ gồm 4 dòng lệnh, nhằm mô tả đã nhận được tín hiệu điều khiển từ chương trình mẹ, đưa ra các tham số nhận được, và chuyền điều khiển lên mức trên cùng với một số tham số ra (nếu cần thiết). Bước 8: Lưu giữ các kết quả kiểm thử. Đệ trình các module đã hoàn tất để tích hợp. Các kết quả kiểm thử module còn được dùng về sau để xây dựng các thống kê về lỗi, nguyên nhân và chi phí để sửa. Người phụ trách dự án phải chịu trách nhiệm tích hợp các module khi các hệ thống thông tin cần xây dựng thuộc loại cỡ nhỏ và trung bình. Để trợ giúp công việc quản lý, có thể sử dụng phần mềm quản lý mã chương trình (Code Management System) nhằm quản lý cấu hình, lưu giữ các thông tin về các phiên bản, những thay đổi lên mã chương trình nguồn (có thể xem phần nói về các công cụ trợ giúp công nghệ phần mềm – Computer Aided Software Engineering (CASE). Bước 9: Bắt tay vào soạn thảo tài liệu cho người sử dụng Có thể tổ chức biên soạn các tài liệu cho người sử dụng ngay sau khi hoàn tất kiểm thử module, độc lập với chuyện lập trình viên có tham gia trực tiếp trong nhóm biên soạn hay không. Các tài liệu cho người sử dụng bao gồm: 56