Giáo trình Quản lý dự án CNTT (Phần 2) - Trình độ: Cao đẳng - Trường Cao đẳng nghề kỹ thuật công nghệ

Nội dung text: Giáo trình Quản lý dự án CNTT (Phần 2) - Trình độ: Cao đẳng - Trường Cao đẳng nghề kỹ thuật công nghệ

1. BÀI 4. CÁC CÔNG CỤ PHỤC VỤ QUẢN LÍ DỰ ÁN Mã bài: MHCNTT 23.4 1. Sử dụng phần mềm để trợ giúp Quản lí Dự án 1.1. Giới thiệu chung - Phải chọn ra một phần mềm thích hợp để mua và sử dụng - Phải học sử dụng phần mềm sao cho thành thạo (mất một thời gian ban đầu để học) - Nên sử dụng một phần mềm cho: 〈 Tất cả các máy tính trong dự án 〈 Tất cả các công việc mà phần mềm có thể đáp ứng (tránh dùng các phần mềm khác nhau) - Nên để ý đến các phiên bản nâng cấp của phần mềm - Phần mềm chỉ trợ giúp, không thể thay thế cho Người quản lí dự án. Nhiều Người quản lí dự án cùng dụng một phần mềm, nhưng kết quả thành công khác nhau. Có rất nhiều công việc phải làm bằng tay và phải suy nghĩ rất cẩn thận (xác định bảng công việc, ước tính một số tham biến, ) - Dữ liệu cho phần mềm phải thường xuyên được cập nhật mới có ý nghĩa - Người cập nhật phần mềm: càng ít càng tốt. Người xem phần mềm: càng nhiều càng tốt. - Biết sử dụng thành thạo một phần mềm còn hơn là biết sử dụng không thành thạo nhiều phần mềm. - Mọi dữ liệu nhập vào phần mềm chỉ là những dữ liệu thô thiển, trong khi thực tế còn rất nhiếu yếu tố khác không mô tả được, không định lượng được. - Nên kết hợp thêm với các phần mềm Word, EXCEL, Email 1.2. Giới thiệu một số phần mềm trợ giúp quản lí dự án - Quản lí các dự án nhỏ 〈 Microsoft Project 〈 Fast Track 〈 ManagePro 〈 TimeLine 〈 MacProject - Đặc điểm: 〈 Dễ sử dụng đối với những nhà quản lí không chuyên Tin học 〈 Phản ảnh tốt việc lập kế hoạch dự án (công việc, thời gian, chi phí tài chính, nhân lực) 〈 Còn chưa đáp ứng tốt các yêu cầu khác dối với quản lí: giám sát, điều khiển công việc 61
2. - Quản lí các dự án mức trung bình 〈 Project Management Workbench 〈 SuperProject - Quản lí các dự án lớn, phức tạp 〈 Primavera 〈 Artimis 〈 OpenPlan Lưu ý: Các phần mềm chỉ có thể trợ giúp người quản lí mà không thể quản lí dự án! 1.3. Phần mềm MS Project Chức năng: - Lập kế hoạch dự án (Thiết kế hoạch thực hiện dự án): dựa trên các dữ liệu ban đầu về 〈 Các công việc phải làm 〈 Ràng buộc đối với mỗi công việc (thời gian, thứ tự thực hiện) 〈 Đội ngũ thực hiện dự án 〈 Kinh phí cần thiết (tiền lương cho anh em) (Lưu ý: các dữ liệu trên giấy phải sẵn sàng trước khi dùng phần mềm) - Xem tình hình thực hiện dự án: Nhiều cách xem (View) khác nhau 〈 Trục thời gian: tương đối hay tuyệt đối 〈 Các thông tin kèm theo sơ đồ công việc 〈 Menu View o Xem theo Lịch (Calendar) o Xem theo lược đồ Gantt o Xem theo lược đồ đường găng (PERT ) o Xem theo tình hình phân bố Người-Việc (Task usage) o Xem tình hình diễn biến thực tế (Tracking Gantt) o Xem chi phí nhân công (Resource Sheet) o Xem tình hình sử dụng nhân lực (Resource usage) - Điều chỉnh kế hoạch làm việc 〈 Thêm, bớt các công việc 〈 Tăng, giảm thời gian cho mỗi công việc 〈 Bố trí lại nhân sự 〈 Tăng, giảm tiền lương 62
3. - Cập nhật tiến độ công việc - Xem báo cáo (Report) 〈 Báo cáo tổng hợp (Overview) 〈 Báo cáo theo công việc (Current Activities) 〈 Báo cáo tài chính (Cost) 〈 Báo cáo giao việc (Assignement) 〈 Báo cáo về phân tải công việc (Workload) 2. Sơ đồ luồng công việc - Cần phải xây dựng một số thủ tục làm việc trong dự án. - Mỗi thủ tục là một qui định/nội qui bắt buộc các thành viên dự án phải tuân theo. - Mỗi thủ tục là một bản viết rõ ràng, phát cho thành viên, không nói bằng lời. 2.1. Các thủ tục Dự án - Vì sao phải áp đặt các thủ tục 〈 Tạo ra một chuẩn mực để trao đổi, làm việc trong nhóm một cách hiệu quả 〈 Tập trung suy nghĩ, hành động của các thành viên trong tổ theo một hướng 〈 Tăng năng suất công việc (mọi việc qui định rõ ràng, không mất thời gian hỏi nhau) - Mỗi thủ tục đều phải trả lời các câu hỏi: liên quan tới ai, cái gì, khi nào, ở đâu, thế nào và tại sao. - Việc xây dựng các thủ tục Lưu ý - Chỉ nên đặt ra các thủ tục cho những nội dung chính, quan trọng (tuỳ người quản lí dự án quyết định). Nên xây dựng các thủ tục cho: 〈 Kiểm soát thay đổi 〈 Sử dụng thiết bị 〈 Dùng các biểu mẫu 〈 Quy chế báo cáo 〈 Trách nhiệm của một số người trong dự án 〈 Họp hành 〈 Mua sắm vật tư, thiết bị 2.2. Mô tả luồng công việc Minh hoạ bằng hình vẽ cho các thủ tục 63
4. Lập danh sách các Có Ghi ngày Ghi hoàn công việc trong Công việc hoàn thành thành biểu đồ mạng hoàn thực tế 100% thành Xác định công việc Không nào còn chưa bắt đầu hay chưa hoàn tất tới ngày hiện tại Ghi ngày bắt đầu thực tế Xác định người tiếp xúc để biết hiện Thủ tục quản lí công việc trạng về từng công việc Ghi phần trăm hoàn thành Thu thập hiện trạng về mỗi công việc Khối vuông: Xử lí. Mô tả lời, thường là một động từ và một bổ ngữ Viết tài liêu Lập trình cho 1 module v.v Điều kiện rẽ nhánh: Câu hỏi, trả lời "Có" hoặc "Không" Có đạt không? Ví dụ: Mô tả luồng công việc cho thủ tục "Xin cấp vật tư trong dự án" - Nhân viên viết yêu cầu đưa cho nhóm trưởng - Nhóm trưởng kí duyệt, chuyển cho trưởng nhóm Hành chính - Vật tư có sẵn ?=> phát cho nhân viên - Vật tư không có sẵn ? => Vật tư trên 200 nghìn? 64
5. - - Vật tư dưới 200 nghìn => Mua và phát cho nhân viên Chuyển hoá đơn cho kế toán trưởng - Vật tư trên 200 nghìn => Lấy 3 báo giá Chọn báo giá tốt nhất Mua và phát cho nhân viên Chuyển hoá đơn cho kế toán trưởng 3. Hồ sơ Dự án 3.1. Hồ sơ quản lí Dự án - Hồ sơ quản lí dự án: bao gồm tất cả các giấy tờ, tài liệu liên quan đến quá trình hoạt động của dự án. - Lưu trữ những gì: Chia thành các loại tài liệu khác nhau 〈 Thư từ trao đổi với bên ngoài (thư đến, thư đi) 〈 Các ước lượng thời gian 〈 Các biểu mẫu 〈 Các bản ghi nhớ 〈 Các biên bản các cuộc họp 〈 Các thủ tục 〈 Các báo cáo 〈 Các quy định về trách nhiệm, quyền hạn trong dự án 〈 Các cập nhật lịch biểu 〈 Bảng công việc 〈 Các tài liệu khác có liên quan - Ai thực hiện việc lưu trữ, Trợ lí Người quản lí dự án: Có trách nhiệm 〈 Phân loại tài liệu 〈 Tạo lập, thu thập, bổ sung hồ sơ 〈 Cung cấp tài liệu khi được yêu cầu - Lưu trữ như thế nào 〈 Trên giấy: (không khuyến khích): Tổ chức thành các cặp tài liệu 〈 Trên máy tính (khuyến khích): Tổ chức thành các folder chia sẻ trên mạng (Nếu Dự án trải rộng trên nhiều tỉnh => Truy cập qua Web) 〈 Luôn có một "File list" (trên giấy, trên máy) được cập nhật thường xuyên và thông báo cho mọi người - Tại sao phải tổ chức lưu trữ hồ sơ dự án 65
6. 〈 Mất thời gian một lần, tiết kiệm thời gian nhiều lần 〈 Tạo điều kiện theo dõi dự án 〈 Tạo điều kiện thuận lợi cho cấp trên (hoặc nhà tài trợ) kiểm tra dự án 〈 Là cơ sở để lập các báo cáo 〈 Là chỗ dựa để Người quản lí dự án tự bảo vệ mình Chia sẻ thông tin trong tập thể thực hiện dự án 3.2. Các biểu mẫu Người quản lí dự án cần quy định một số biểu mẫu cho một số báo cáo, đề nghị, tờ trình, - Ý nghĩa của các biểu mẫu 〈 Thống nhất cách trình bày về một vấn đề 〈 Dễ theo dõi, xử lí - Ví dụ về một số biểu mẫu 〈 Mô tả công việc 〈 Ước lượng thời gian công việc 〈 Bản ghi hiện trạng công việc 〈 Kiểm soát thay đổi 〈 Bổ nhiệm nhân viên 〈 Dự kiến chi phí 〈 Vấn đề náy sinh 〈 Đơn mua hàng 〈 Theo dõi sử dụng lao động (chấm công) 〈 Bản ghi chi phí sử dụng tài nguyên thực tế 〈 Đồ hình tài nguyên - Lưu ý: 〈 Nên soạn biểu mẫu trên máy tính (chia xẻ và thông báo rộng rãi) 〈 Có hướng dẫn cách khai (ngắn gọn, rõ ràng) 〈 Thiết kế thoáng, nhiều chỗ trống 〈 Chỉ yêu cầu viết đủ các thông tin cần thiết, tránh viết dài, thừa 〈 Biểu mẫu nên thiết kế sao cho dễ khai, mất ít thời gian để khai 3.3. Báo cáo - Báo cáo: là một loại Biểu mẫu (Form), được thiết kế để cấp dưới báo cáo lên cấp trên. 66
7. - Form cho báo cáo được thiết kế đa dạng, phong phú (lời văn, hình vẽ, bảng biểu, ). Cố gắng sao cho báo cáo có thể tạo ra trên máy tính. - Một số ví dụ về báo cáo được dùng trong dự án bao gồm: 〈 Biểu đồ mũi tên 〈 Sơ đồ thanh 〈 Biểu đồ việc trước 〈 Lịch biểu việc trước - sau 〈 Lịch biểu dự án 〈 Tóm tắt trạng thái dự án 〈 Chi phí tài nguyên 〈 Việc sử dụng tài nguyên đến ngày đó 3.4. Thư viện dự án, lưu trữ - Các ấn bản của riêng cơ quan - Sách - Báo chí, tin tức - Hồ sơ, tài liệu dự án - Các thủ tục dự án - Tài liệu kĩ thuật 3.5. Các biên bản - Là một loại tài liệu không thể thiếu - Là một dạng ghi lại những thống nhất, cam kết - Theo dõi và quản lí các cuộc họp và các sự kiện của dự án - Lưu ý 〈 Biên bản cần cụ thể, rõ ràng, tránh sơ sài 〈 Nói trực tiếp vấn đề, ngắn gọn (1- 2 trang) 〈 Cấu trúc logic, hợp lí 〈 Nên tập trung vào những điểm đã thỏa thuận, thống nhất 3.6. Văn phòng Dự án Trung tâm chỉ huy và kiểm soát của dự án. Phần lớn các hoạt động và quyết định quản lí dự án chính đều xuất hiện tại văn phòng dự án - Nơi cung cấp các tài nguyên dự án - Nơi tổ chức các cuộc họp quan trọng - Nơi làm việc chính thức của Ban quản lí dự án - Lưu ý: 67
8. 〈 Dự án càng lớn => Văn phòng dự án càng lớn 〈 Nên lập Văn phòng dự án càng sớm càng tốt 〈 Văn phòng dự án cần có o Phần mềm quản lí dự án tự động o Văn kiện dự án o Hồ sơ quản lí dự án o Thư viện dự án 〈 Trên tường của Văn phòng dự án phải treo các bảng phóng to o Các sơ đồ thanh (Gantt) o Sơ đồ tổ chức o Các bản đồ o Bảng tiến độ công việc o Các nội dung quan trọng khác 4. Xây dựng Tổ dự án Bao gồm nhiều tổ (nhóm con), làm việc dưới sự quản lí của người quản lí dự án, thông qua các tổ trưởng. Ban QLDA Người quản lí dự án Nhóm hỗ trợ Tổ 1 Tổ 2 Thành Thành Thành Thành Thành Thành Thành Thành viên 1 viên 2 viên 3 viên 4 viên 5 viên 6 viên 7 viên 8 Vì cần đến các chuyên môn khác nhau, mỗi tổ dự án có thể tuyển người từ các phòng Ban khác nhau: 68
9. Phòng Phòng Phòng Phòng ban A ban B ban C ban D Tổ 1 Tổ 2 Lưu ý: - Một tổ không nên đông quá (dưới 10 người) - Nếu trên 10 người => tìm cách tách thành 2 tổ - Xác định rõ mối quan hệ "ai báo cáo ai": - Lập ma trận trách nhiệm Công việc Công việc Công việc Công việc Z X Y Tên Ng Văn A A A A Lê Thị B P I R Cao Văn C I P Không Vũ Văn D C R Không Phạm Văn E C Trần Thị F R C P - Các kiểu trách nhiệm khác nhau trên công việc 〈 A (Approving): Xét duyệt 〈 P (Performing): Thực hiện 〈 R (Reviewing): Thẩm định 〈 C (Contributing): Tham gia đóng góp 〈 I (Informing): Báo cho biết 69
10. BÀI 5. QUẢN LÍ, KIỂM SOÁT DỰ ÁN Mã bài: MHCNTT 23.5 1. Các yếu tố làm ảnh hưởng đến năng suất và chất lượng Phần mềm - Năng lực cá nhân: Năng khiếu, lòng yêu nghề, tính sáng tạo, tính cần cù 〈 Kĩ năng trao đổi trong tổ, nhóm 〈 Nói một cách thuyết phục 〈 Mình nói người khác hiểu, người khác nói mình hiểu 〈 Nói một cách thuyết phục - Độ phức tạp của phần mềm 〈 Nhiều dòng lệnh, thuật toán phức tạp, nhiều module 〈 Phụ thuộc vào nghiệp vụ phức tạp hay đơn giản - Cách tiếp cận hệ thống - Thời gian được phép 〈 Nếu thời gian căng thẳng quá è phần mềm bị làm gấp sẽ nhiều lỗi - Khả năng hiểu thấu vấn đề, hiểu nghiệp vụ, hiểu công cụ lập trình - Độ ổn định của các yêu cầu - Kĩ năng đòi hỏi của những công nghệ mới: Công nghệ client/server, công nghệ Web - Môi trường làm việc, công cụ - Sự đào tạo, huấn luyện của tổ chức - Kĩ năng quản lí - Các rủi ro xảy ra - Những hạn chế của một lập trình viên mới 〈 Khả năng diễn đạt vấn đề 〈 Hiểu nghiệp vụ của những lĩnh vực ứng dụng 〈 Chưa có ý thức về việc bảo hành, bảo trì phần mềm 〈 Làm việc trong một khuôn khổ, bài bản của quản lí dự án 〈 Làm việc trong nhóm 2. Thu thập và đánh giá hiện trạng Thu thập hiện trạng là: Dùng mọi phương sách để xác định xem các công việc (nói riêng) và toàn bộ dự án (nói chung) hiện nay đang tiến triển thế nào. Các bước: (1) Thu thập các dữ liệu về hiện trạng theo định kì (1 hoặc hai tuần). Công bố cho anh em biết 70
11. (2) Thu thập dữ liệu hiện trạng từ mọi thành viên của tổ dự án. (3) Tránh đưa ra đánh giá (vội vã) khi thu thập dữ liệu. (Cần phân tích kĩ lưỡng) (4) Làm tài liệu tổng hợp (tốt nhất là tổng hợp từ các tài liệu, báo cáo điện tử) - Mục đích cuối cùng của đánh giá: Làm rõ sự khác biệt giưã Dự kiến và Thực tế 〈 Khác biệt có thể là xấu hoặc tốt. 〈 Khác biệt không nhất thiết là tốt hay xấu (tuỳ từng trường hợp cụ thể) 〈 Sai biệt lịch biểu = Ngày bắt đầu và kết thúc theo kế hoạch - Ngày bắt đầu và kết thúc thực tại 〈 Sai biệt ngân sách Sai biệt chi phí = Chi phí ngân sách - Chi phí thực tế - Nhiệm vụ của người quản lí dự án: trả lời câu hỏi 〈 Tại sao có sự khác biệt? 〈 Sự khác biệt là tốt hay xấu? 〈 Có cần những hành động uốn nắn, điều chỉnh dự án hay không? Nếu có, thì là gì? 3. Họp - Họp theo kế hoạch - Họp đột xuất - Nên tránh 〈 Họp không hiệu quả 〈 Quá dài 〈 Không tập trung 〈 Bị vài cá nhân chi phối, 〈 Ghi lại kết quả không đầy đủ - Nên 〈 Công bố cuộc họp từ trước 〈 Chuẩn bị chương trình họp, phát cho mọi người và theo đúng chương trình đó. 〈 Ghi lại biên bản, kết quả cuộc họp. 〈 Mời tất cả những ai có liên quan. 〈 Khuyến khích mọi người đóng góp ý kiến. Tránh để vài người chi phối đối thoại. 〈 Nếu phải họp trên 1 giờ => tìm cách thư giãn 4. Quản lí cấu hình - Quan niệm về Quản lí cấu hình 〈 Cung cấp việc truy cập an toàn và đơn giản đối với bản copy tổng thể về các kết quả bàn giao đã được thông qua 〈 Kiểm soát được thực trạng của các kết quả bàn giao và mối quan hệ qua lại lẫn nhau giữa các kết quả này - Các chức năng Quản lí cấu hình 71
12. Trả lại mục đã cập nhật Bàn giao (3) sản phẩm (4) Kho Khôi phục quản lí / cập nhật (2) cấu hình Lưu giữ (5) Bổ sung khoản mục mới (1) Kiểm soát báo cáo (6) - Tại sao bạn cần quản lí cấu hình? Các kết quả bàn giao của dự án là tài sản có giá trị mà đã đầu tư vào. Nếu chúng ta không xác định và kiểm soát các cấu phần của nó và mối quan hệ qua lại giữa chúng, thì chỉ một thay đổi nhỏ sẽ chúng không có giá trị. - Các công việc của Quản lí cấu hình 〈 Xác định các yêu cầu và phạm vi của CM 〈 Xây dựng kế hoạch CM 〈 Nhất trí và triển khai các qui trình và công cụ 〈 Triển khai các qui trình bảo mật - Phạm vi Quản lí cấu hình 72
13. Các mục Mô hình đích kiểm tra & phạm vi Triển khai Văn bản chiến lược kĩ thuật Quản lí cấu hình Các yêu cầu Tài liệu đào chức năng tạo Kiểm soát phiên Kế hoạch bản Qui trình dự án hoạt động Phần mềm Văn bản trọn gói hệ thống Đặc tả Tài liệu Đặc tả Đặc tả nâng cấp triển khai giao diện phần cứng - Kiểm soát phiên bản phải được thực hiện đối với từng kết quả bàn giao. - Các kết quả bàn giao nằm trong phạm vi quản lí cấu hình. 5. Kiểm soát thay đổi - Hai trong số những lí do thông thường nhất đối với sự thất bại của dự án: 〈 Không nhận ra sự thay đổi và sự kiện, và 〈 Không quản lí hiệu quả những vấn đề này - Về nguyên tắc 〈 Các thành viên tham gia dự án cần được khuyến khích đối với các tài liệu về sự kiện hay các thay đổi đề xuất khi họ nêu ra o Phản hồi, hành động, tuyên truyền nhanh chóng để giảm rủi ro 〈 Các thành viên của nhóm cần hiểu qui trình quản lí sự thay đổi và sự kiện 〈 Theo dõi toàn diện được yêu cầu đối với việc kiểm soát và truyền thông o Bao gồm tất cả các khoản mục hiện tại và đã hoàn thiện - Thực tế cho thấy: kế hoạch và thực tế không bao giờ giống nhau. - Ai gây ra/đề nghị những thay đổi? 〈 Khách hàng 〈 Các cơ quan/đơn vị liên quan 73
14. 〈 Tổ dự án 〈 Người tài trợ 〈 Chính người quản lí dự án 〈 v.v - Phân loại thay đổi: 3 loại (1) Thay đổi quan trọng: lịch biểu, đặc tính sản phẩm, ngân sách, và những gì được xem là quan trọng cho dự án. Làm thay đổi cơ bản kết quả của dự án. Ví dụ: Nhà tài trợ tuyên bố cắt giảm ngân sách (gây ra bởi người tài trợ), yêu cầu bổ sung thêm một số tính năng của phần mềm (gây ra bởi khách hàng). (2) Thay đổi nhỏ: không làm thay đổi kết quả chung cuộc của dự án, nhưng có thể ảnh hưởng đến sự thành công của dự án. Ví dụ: Dự án xây nhà: Những phát sinh lặt vặt (từ phía chủ nhà - khách hàng) Dự án làm phần mềm: Yêu cầu làm thêm một vài module lập báo cáo (khách hàng đề nghị) (3) Thay đổi mang tính sửa chữa/sửa lỗi: Đã coi nhẹ hoặc bỏ qua 1 điểm nào đó, bây giờ phải bổ sung hoặc khắc phục Ví dụ: Dự án xây nhà: Quên đi dây điện thoại ngầm trong tường, cần phải lắp thêm hệ thống dây điện nổi (do người quản lí dự án hoặc tổ dự án đề nghị) Dự án xây dựng phần mềm: Quên chưa lên kế hoạch huấn luyện cho người sử dụng trước khi bàn giao (do khách hàng phát hiện ra) - Làm thế nào để khỏi rơi vào phong cách quản lí bị động? => Cần phải biết cách kiểm soát các thay đổi. - Kiểm soát thay đổi là: phát hiện, phân tích, đánh giá và thực hiện những thay đổi liên quan đến mô tả sản phẩm, lịch biểu, ngân sách và yêu cầu chất lượng. - Xem xét tác động của thay đổi 〈 Ảnh hưởng tới công việc, thời gian 〈 Ảnh hưởng tới kinh phí 〈 Ảnh hưởng tới con người: phải làm thêm việc => phản ứng tiêu cực 〈 Ảnh hưởng tới chất lượng sản phẩm của dự án - Xét xem thay đổi nào cần ưu tiên thực hiện trước 〈 Lập danh sách những thay đổi 〈 Xác định mức độ ưu tiên: cao, thấp, rất thấp, không cần phải thay đổi 〈 Từ đó có kế hoạch đáp ứng: người, thời gian, tiền, - Thủ tục kiểm soát thay đổi Do người quản lí dự án tự xây dựng cho dự án của mình. Ví dụ: 74
15. Thủ tục kiểm soát thay đổi Do người quản lí dự án tự xây dựng cho dự án của mình. Ví dụ: Ghi yêu cầu thay đổi Phân tích yêu cầu thay đổi Làm rõ Lập lịch Thực biểu Phân tích Nhất trí? yêu hiện thực tác động cầu thay hiện Viết rõ lí do từ chối Thông báo cho người yêu cầu thay đổi - Biểu mẫu kiểm soát, theo dõi thay đổi Hoặc gọi là "Nhật kí kiểm soát thay đổi" Ngày Mô tả Phân Mức Người Người Đồng Ngày tháng thay tích tác ưu tiên khởi chịu ý? hiệu lực đổi động đầu trách nhiệm [1] [2] [3] [4] [5] [6] [7] [8] - Đối với những dự án làm phần mềm, cần tập trung quản lí thay đổi các phiên bản phần mềm 〈 Có bao nhiêu phiên bản của sản phẩm 〈 Các phiên bản đó khác nhau thế nào 〈 Phiên bản nào của sản phẩm được cài đặt và ứng dụng ở chỗ nào 〈 Tài liệu nào đi với mỗi phiên bản 〈 Phần cứng nào cần cho mỗi phiên bản 〈 Phiên bản nhằm khắc phục lỗi gì 6. Kiểm soát tài liệu Dự án - Ý nghĩa của kiểm soát tài liệu 〈 Tài liệu là sản phẩm. Phần mềm chỉ được hiểu qua tài liệu 〈 Tài liệu cũng là công cụ làm việc 75
16. 〈 Mỗi tài liệu thuộc một loại nào đó, nhằm mục đích sử dụng nào đó: đặc tả yêu cầu, đặc tả thiết kế, báo cáo công việc, báo cáo sự cố/rủi ro, báo cáo tài chính, 〈 Viết tài liệu cũng khó như viết văn 〈 Trong thực tế: tài liệu là khâu thường bị bôi bác 〈 Không chuyển sang công việc tiếp sau, nếu tài liệu không sát thực, đầy đủ, dễ hiểu, nhất quán 〈 Kết luận: làm tài liệu tốt trong quá trình thực hiện dự án là vấn đề khó - Các tiêu chuẩn xem xét, đánh giá tài liệu 〈 Tính chính xác o Tài liệu viết có chính xác không? o Có lỗi nào hiển nhiên không? o Các mô tả về tài nguyên, môi trường của hệ thống có hợp lí không? o v.v 〈 Tính rõ ràng o Tài liệu có được trình bày sáng sủa, dễ hiểu không? o Những chỗ cần dùng bảng hoặc biểu đồ thay lời nói thì có dùng hay không? 〈 Tính đầy đủ o Những thông tin trong tài liệu có phù hợp với mục đích tài liệu không? o Có những điểm nào quan trọng bị bỏ sót không? o Trong trường hợp một tài liệu là phát triển tiếp tục của một tài liệu khác, những điểm cần thiết của tài liệu trước có được nhắc lại hay không? 〈 Tính nhất quán o Cách đánh số các chương, mục, điều khoản trong tài liệu có nhất quán không? o Các kí hiệu có thống nhất không? Hoặc có theo chuẩn không? 〈 Mức độ chi tiết o Đủ chi tiết như mục đích và yêu cầu của tài liệu không? o Liệu có phần nào cần hoàn thiện chi tiết hơn nữa không? Một số tài liệu chính cần có khi thực hiện vòng đời của dự án - Xác định, phân tích yêu cầu Bao gồm a/ Mô tả khái lược về hệ thống (sâu hơn tài liệu mô tả dự án) b/ Tài liệu về yêu cầu và đặc tả c/ Tài liệu về kế hoạch phát triển phần mềm 76
17. Chú ý: Phải đảm bảo những nội dung sau: 〈 Nhu cầu của khách hàng được diễn đạt theo một cách thức rõ ràng, chi tiết, mô tả hệ thống phải làm gì. 〈 Phải làm việc với các chuyên gia trong lĩnh vực chuyên môn để hiểu được các khái niệm nghề nghiệp, hoạt động nghiệp vụ 〈 Nên tận dụng những phần mềm mà khách hàng trước đây đã sử dụng (nếu có). Xem xét và thảo luận trên những phần mềm đó (về ưu/khuyết của các modules, về quan điểm thiết kế, ) 〈 Mô tả những loại dữ liệu vào, ra 〈 Các tài liệu trên phi được đánh giá và thông qua trong một (hoặc một số) cuộc họp. - Thiết kế 〈 Tên tài liệu: Tài liệu thiết kế chi tiết, làm cơ sở cho lập trình Chú ý: Phải đảm bảo những nội dung sau: 〈 Xác định kiến trúc của phần mềm sao cho phù hợp với đặc tả hệ thống 〈 Phân rã các yêu cầu thành các hệ thống con 〈 Chi tiết hoá kiến trúc phần mềm (làm mịn dần dần), cố gắng chi tiết tới mức gần như có thể lập trình được 〈 Thiết kế các sơ đồ theo chức năng hoặc định hướng theo đối tượng 〈 Mô tả mọi dữ liệu được nhập bởi người dùng, các kết quả cần cho (ví dụ: trên màn hình, trên máy in, ) 〈 Thủ tục, qui trình vận hành phần mềm 〈 Mô tả từng đơn vị chưng trình: chức năng, thuật toán thực hiện, giao diện, dữ liệu vào, dữ liệu ra 〈 Tài liệu trên phải được đánh giá và thông qua trong 1 (hoặc một số) cuộc họp - Lập trình Tài liệu ngoài chương trình 〈 Đặc biệt quan trọng khi o Phát triển những phần mềm lớn, thuộc những dự án lớn. o Phải xây dựng những phần mềm với sự tham gia của nhiều người. Sẽ xẩy ra trường hợp một người lập trình phải gỡ lỗi và đọc những đoạn chương trình của người khác viết. Thậm chí người này đã chuyển sang cơ quan khác. 〈 Việc viết tài liệu cho chương trình phải đủ rõ ràng để bảo trì chương trình 〈 Tài liệu cho chương trình không liên quan đến mã lệnh của chương trình. 77
18. 〈 Nội dung chính: Mô tả chung chưng trình, mục đích chung của chưng trình, ai viết, viết khi nào, các thuật toán riêng có sử dụng, chương trình được thiết kế và phát triển cho những hệ thống nào, nguồn dữ liệu vào, những yêu cầu cần có đối với dữ liệu vào, format của dữ liệu vào, hình thức của kết quả đưa ra, v.v 〈 Tài liệu cho chương trình còn bao gồm sơ đồ cấu trúc của chưng trình Tài liệu trong chương trình Là một bài viết ngắn đặt ở đầu chương trình, dưới dạng comment. Bài viết này thường chứa những thông tin sau: 〈 Tên tác giả, tên nhiệm vụ, ngày giao nhiệm vụ, ngày phải hoàn thành 〈 Mô tả vấn đề cần giải quyết 〈 Cách tiếp cận để giải quyết vấn đề. Mô tả vắn tắt thuật toán, hoặc tên thuật toán nếu thuật toán đã quen thuộc đối với mọi người. Có thể chỉ ra tên tài liệu tham khảo liên quan đến thuật toán. 〈 Các yêu cầu khác đối với chương trình: ngôn ngữ sử dụng, chương trình dịch, nguồn của dữ liệu vào (vào bằng tay, đọc từ file, ) 〈 Các yêu cầu đối với chương trình còn chưa đáp ứng được, hoặc có thể cải tiến cho tốt hơn 〈 Các lỗi còn xuất hiện, chưa gỡ được 〈 v.v Nội dung của chương trình Những khía cạnh cần xem xét trong nội dung chương trình 〈 Cách đặt tên biến, tên hàm, tên lớp 〈 Định lề cho mỗi dòng lệnh 〈 Sự sáng sủa của chưng trình 〈 Giải thích cho chương trình (comment) 〈 Tổ chức chương trình 〈 Tính khả chuyển - Kinh nghiệm thực tế cho thấy rằng: 〈 Để phát triển và hoàn thiện một chương trình (đặc biệt là các chương trình lớn), lập trình viên mất 70% thời gian vào việc xem lại và cải tiến các đoạn chưng trình cũ, chỉ 30% thời gian dành cho việc viết mã lệnh mới. 〈 Ngoài ra, rất nhiều tình huống trong thực tế đòi hỏi người này phải đọc chương trình của người kia (để gỡ lỗi, hoặc để mở rộng thêm một số chức năng) 〈 Nhiều khi phải xem lại mã chương trình sau hàng tháng, hoặc hàng năm. 78
19. 〈 Thông thường, lập trình viên làm việc dưới một sức ép về thời gian, do đó không quan tâm đến hậu quả của những đoạn mã lệnh sản sinh ra, miễn là chương trình chạy được. - Kiểm thử và Chấp nhận phần mềm 〈 Tên tài liệu: Tài liệu kiểm thử phần mềm 〈 Kế hoạch và kịch bản kiểm thử (được viết dựa trên tài liệu về yêu cầu và đặc tả hệ thống) 7. Quản lí chất lượng 1. Lập kế 2.Thiết lập 3. Tiến hành 4. Tiển khai hoạch chất khung đảm các hoạt động các họat động lượng bảo chất kiểm soát hiệu chỉnh lượng chất lượng - Ở mức lập kế hoạch quản lí, cần quyết định: - Tiêu chuẩn - Nhóm có trách nhiệm đối với việc ngừng hoạt động - Nếu cần tách nhóm kiểm soát chất lượng, và thẩm quyền của họ - các kiểu rà xét (không chính thức, chính thức, walk through kiểm tra cấu trúc) - Thường xuyên rà xét (ví dụ: tất cả các kết quả chuyển giao theo công việc hoặc chỉ kết quả bàn giao dự án) - Có được cam kết đối với khái niệm quản lí chất lượng - Ở mức độ lập kế hoạch làm việc, cho phép thời gian đối với: 〈 Kiểm soát và phương pháp quản lí chất lượng 〈 Thiết lập qui trình quản lí chất lượng 〈 Thống nhất người (chính xác) sẽ kí nhận: o Người chịu trách nhiệm o Quản đốc dự án / trưởng nhóm o Đại diện người sử dụng có ảnh hưởng o Người kiểm soát chất lượng - Đánh giá Kế hoạch chất lượng 〈 Kế hoạch quản lí có xác định được các phương pháp, tiêu chuẩn, qui trình, và hướng dẫn được sử dụng cho từng giai đoạn hoặc hoạt động cuả dự án không? 〈 Các lí do có cho thấy những điểm này là rõ ràng hợp lí không? 〈 Những tiêu thức kiểm soát được xác định để giám sát hiệu quả có sử dụng các phương pháp đã lựa chọn không? 79
20. - Khung đảm bảo chất lượng 〈 Các phương pháp luận, tiêu chuẩn, hướng dẫn hợp lí 〈 qui trình kiểm soát thay đổi hiệu quả 〈 Rà xét các hoạt động kiểm soát chất lượng 〈 Cán bộ có kĩ năng hợp lí - Kiểm soát chất lượng 〈 Rà xét / walkthrough / kiểm tra 〈 Thẩm định tính chấp nhận 〈 Rà xét quản lí nhóm/sign-off 〈 Thẩm định việc phê chuẩn 〈 Rà xét ban điều hành/sign-off 〈 Thẩm định việc triển khai 〈 Quản lí lợi ích 〈 Điều tra người sử dụng / các câu hỏi 〈 Phương pháp kiểm soát chất lượng phải được lập thành văn bản trong kế hoạch chất lượng 〈 Kế hoạch làm việc chi tiết phải bao gồm việc thẩm định các nhiệm vụ và các nguồn lực - Các hoạt động điều chỉnh 〈 Khi việc thực hiện dự án không diễn ra theo kế hoạch, hoặc chất lượng sản phẩm/công việc chưa đạt yêu cầu 〈 Khi chi phí cho dự án có nguy cơ tăng lên 〈 Khi chất lượng công việc/sản phẩm có nguy cơ giảm - Ví dụ về hoạt động điều chỉnh 〈 Phân bổ lại các nhiệm vụ quan trọng cho các thành viên nhóm nhiều kinh nghiệm hơn 〈 Tăng quy mô nhóm với các thành viên/ hợp đồng tạm thời 〈 Phân bổ lại các thành viên giữa các nhóm 〈 Cung cấp các đào tạo bổ sung về công cụ, kĩ thuật 〈 Triển khai các công cụ tự động 〈 Yêu cầu các thành viên nhóm làm ngoài giờ 〈 Nhiều ca làm việc để tối đa hoá việc sử dụng các thiết bị - Khi chất lượng công việc/sản phẩm có nguy cơ giảm 〈 Tăng cường kiểm tra chất lượng sản phẩm 〈 Thuê thêm tư vấn 〈 Tập trung vào những khâu trọng yếu ảnh hưởng đến chất lượng sản phẩm 〈 Kiểm tra chéo 〈 Huấn luyện, đào tạo, nâng cấp nhân viên (có thể huấn luyện tại chỗ) 〈 Thưỏng/phạt 8. Quản lí rủi ro - Lập kế hoạch phòng ngừa rủi ro 〈 Lập biểu phân tích rủi ro 〈 Liệt kê các giả thiết 〈 Cần được sự ủng hộ của những người chịu tác động của rủi ro. 〈 Với những "sự cố" đã xẩy ra mà không dự kiến được, cần ghi lại nhật kí 80
21. - Hướng dẫn hành động ngăn ngừa 〈 Bảo đảm rằng chi phí sẽ thấp hơn chi phí của nguy cơ rủi ro 〈 Bảo đảm rằng chi phí sẽ thấp hơn chi phí của hành động bất ngờ 〈 Điều đặc biệt quan trọng là sẽ không xảy ra hành động bất ngờ - Quản lí rủi ro hiệu quả cần 〈 Phòng ngừa hơn là chữa trị 〈 Đánh giá rủi ro theo thời kì trong suốt vòng đời của dự án 〈 Kết hợp chặt chẽ một qui trình liên tục về xác định rủi ro, phân tích, quản lí và rà xét 〈 Không đi quá giới hạn và kết thúc không chính xác! 〈 Mức hợp lí của quản lí rủi ro chuẩn sẽ không tốn những nỗ lực vô lí. - Cần ghi lại nhật kí Mô tả Độ quan trọng Người chịu trách Ngày giải quyết nhiệm [1] [2] [3] [4] • Mô tả, thuật lại sự cố • Tầm quan trọng của sự cố. • Tên người giải quyết sự cố. • Thời gian vấn đề đã được hay sẽ được giải quyết. - Lưu ý 〈 Dự án càng lớn thì rủi ro càng nhiều. 〈 Việc dự báo rủi ro phụ thuộc vào kinh nghiệm QLDA của người PM 〈 Kiểm soát rủi ro không nhằm loại bỏ rủi ro, chỉ nhằm hạn chế tối thiểu thiệt hại của rủi ro. 〈 Không thể loại trừ được triệt để 〈 Không phải cứ tập trung hết sức để ngăn chặn và đề phòng rủi ro đã là tốt, vì có thể phải trả giá đắt, nếu rủi ro không xảy ra 8.1. Sự khác nhau giữa rủi ro và thay đổi - Rủi ro: Tai hoạ, sự cố, biến cố đã được dự phòng, lường trước - Thay đổi: Chênh lệch so với kế hoạch đã được ghi trong tài liệu, đã được thống nhất, cam kết 8.2. Qui trình quản lí rủi ro Qui trình quản lí rủi ro 81
22. Xác định Phân Quản lí Giám sát Xác định mức tích rủi ro ban đầu của dự án Lập thành văn bản các rủi ro Bước 1 cụ thể Tiến hành Bước 2 phân tích ảnh hưởng rủi ro Xây dựng và Bước 3 triển khai kế hoạch quản lí rủi ro Xây dựng và Bước 4 triển khai kế hoạch quản lí rủi ro 8.3. Lập kế hoạch phòng ngừa rủi ro - Dựa trên phân tích rủi ro, lập biểu sau: Mô tả Giả thiết Xác suất Ảnh Phản hưởng ứng [1] [2] [3] [4] [5] [1] Mô tả: Xác định vấn đề (rủi ro) [2] Giả thiết: Hoàn cảnh có thể làm xuất hiện rủi ro [3] Xác suất: Ước lượng khả năng xuất hiện (%) [4] Đánh giá ảnh hưởng đối với dự án [5] Cách giải quyết (đối sách) 82
23. - Cần liệt kê tất cả các giả thiết ảnh hưởng tới quyết định cách giải quyết. Nếu sau này hoàn cảnh không còn hợp với các giả thiết nữa, có thể thay đổi đối sách. - Cần được sự ủng hộ của những người chịu tác động của rủi ro. - Với những "sự cố" đã xẩy ra mà không dự kiến được, cần ghi lại nhật kí Mô tả Độ quan Người chịu Ngày giải trọng trách nhiệm quyết [1] [2] [3] [4] [1] Mô tả, thuật lại sự cố [2] Tầm quan trọng của sự cố. [3] Tên người giải quyết sự cố. [4] Thời gian vấn đề đã được hay sẽ được giải quyết. 9. Các hoạt động điều chỉnh - Khi việc thực hiện dự án không diễn ra theo kế hoạch, hoặc chất lượng sản phẩm/công việc chưa đạt yêu cầu 〈 Điều chỉnh lại lịch biểu thời gian: cho chính xác hơn 〈 Tìm thêm nhân viên mới 〈 Chú ý: thời gian làm quen với dự án, quan hệ với các thành viên cũ, kinh phí phát sinh) 〈 Mua hay thuê thiết bị tốt hơn, phần mềm tốt hơn 〈 Chú ý: tăng kinh phí, mất thời gian để anh em học sử dụng 〈 Hợp lí hoá, cải tiến phong cách làm việc 〈 Hạ thấp yêu cầu chất lượng công việc (không nên !!!) 〈 Tập trung cho các công việc trên đường găng 〈 Làm thêm giờ (không nên kéo dài quá lâu) 〈 Hạn chế nghỉ phép (coi chừng phản ứng của tổ viên!!!) 〈 Khen thưởng/phê bình 〈 Đào tạo, huấn luyện, nâng cấp nhân viên (chú ý thời gian và chi phí huấn luyện) 〈 Xem lại cách thức hợp tác , trao đổi thông tin trong nhóm - Khi chi phí cho dự án có nguy cơ tăng lên 〈 Hạ thấp yêu cầu sản phẩm (Chú ý: khách hàng có thể phản đối) 83
24. 〈 Giảm nhân viên: những người không làm các công việc trên đường găng (chú ý: nguy cơ mất người giỏi) 〈 Thuê lao động rẻ mạt (nguy cơ "tiền nào của nấy!!!) 〈 Dùng thiết bị, vật tư rẻ tiền 〈 Rút bớt thời gian huấn luyện (chú ý phản ứng tâm lí của tổ viên) 〈 Xem lại: có cần làm thêm giờ? 〈 Hợp lí hoá hơn nữa: Giảm số cuộc họp, giảm các phê chuẩn, - Luật BROOKS 〈 Khi một dự án phần mềm đã bị trễ hạn, việc bổ sung thêm người (lập trình viên) chỉ làm cho dự án trễ thêm mà thôi. 〈 Nếu một ông thợ cày có thể cày một mẫu ruộng trong ba ngày, ba ông thợ cày có thể cày một mẫu ruộng trong 〈 Nếu một phụ nữ có thể sinh một đứa bé trong 9 tháng, chín người phụ nữ có thể sinh một đứa bé trong 10. Lập lại kế hoạch - Khi nào phải làm lại kế hoạch 〈 Phát hiện ra những lỗi lầm trong kế hoạch đang thực hiện 〈 Gặp những thay đổi quá lớn, nếu không làm lại kế hoạch thì không thể đi tiếp được - Khi lập kế hoạch lại có thể phải cấu trúc lại một phần hay toàn bộ dự án => yêu cầu thời gian, kinh phí, - Làm lại kế hoạch, tức là có thể thay đổi lại tất cả những nội dung đã xây dựng: mục đích mục tiêu, mô tả sản phẩm, ước lượng thời gian, kinh phí, lịch biểu, - Cần tận dụng những kết quả, kinh nghiệm đã có trong lần lập kế hoạch trước => có 1 kế hoạch tốt hơn - Xác định rõ những lí do, nguyên nhân phải lập lại kế hoạch - Xác định rõ những thay đổi cần có trong kế hoạch mới (khác với kế hoạch cũ) - Phải được sự đồng thuận của Ban Quản lí dự án, nhà tài trợ (có thể cả của khách hàng) - Thời gian chi phí cho việc lập lại kế hoạch: 〈 Nếu nhiều quá: ảnh hưởng đến tiến độ dự án 〈 Nếu ít quá: => kế hoạch có thể sơ sài, tiềm ẩn những sai lầm - Tránh phải lập lại kế hoạch nhiều lần 84
25. BÀI 6. KẾT THÚC DỰ ÁN Mã bài: MHCNTT 23.6 1. Nhập đề - Một dự án phải kết thúc, sớm hay muộn. Các lí do kết thúc dự án 〈 Đã hoàn thành các yêu cầu 〈 Chưa hoàn thành các yêu cầu, nhưng có các yếu tố sau: o Kinh phí đã hết, không thể cấp thêm o Thời hạn đã hết, không cho phép gia hạn thêm o Ban Quản lí và nhà tài trợ quyết định chấm dứt o Những lí do đặc biệt khác - Trước kết thúc dự án, cần làm một số công việc dưới đây 〈 Thống kê lại dữ liệu 〈 Rút bài học kinh nghiệm 〈 Kiểm điểm sau khi bàn giao 〈 Đóng dự án - Hoàn tất dự án là việc giải thể tổ chức và môi trường dự án theo phương thức đã được ấn định sau khi đã đạt được các mục tiêu của dự án và tất cả các nhiệm vụ trong kế hoạch làm việc chi tiết được hoàn thành. - Qui trình hoàn thiện dự án 〈 Rà xét và cập nhật kế hoạch quản lí 〈 Xây dựng kế hoạch chi tiết hoàn tất dự án 〈 Tiến hành rà xét các hoạt động 〈 Kết thúc hợp đồng với các nhà thầu phụ 〈 Chuẩn bị các báo cáo dự án cuối cùng 〈 Lập văn bản và giữ các kết quả bàn giao 〈 Đóng văn phòng dự án 〈 Giải thể tổ chức dự án 〈 Tiến hành các cuộc họp kết thúc dự án 〈 Tiến hành rà xét sau thực hiện 〈 Thiết lập lại việc phân bổ nhân sự 2. Thống kê lại dữ liệu Thống kê lại các số liệu "lịch sử" về chi phí, thời gian thực hiện, chất lượng công việc, chất lượng sản phẩm. - So sánh giữa kế hoạch và thực tế - Tìm nguyên nhân (kể cả trong trường hợp mọi sự là hoàn hảo) - Nguyên tắc: 〈 Qui trình đối với việc hoàn tất dự án cần được lập kế hoạch với sự chú ý vào từng chi tiết giống như các giai đoạn vai trò và trách nhiệm con người trải qua sự thay đổi lớn vào thời điểm cuối cùng của dự án 85
26. 〈 Các kế hoạch đối với việc hoàn tất dự án cần lên lịch các hoạt động yêu cầu của Rà xét sau thực hiện 3. Rút bài học kinh nghiệm - Gợi ý về một dàn bài I. Giới thiệu chung về dự án A. Mục đích B. Phạm vi II. Tình hình/hiện trạng trước khi thực hiện dự án III. Tóm tắt nội dung công việc của dự án IV. Những điểm đã đạt được/thành công A. Các thành công B. Thảo luận về từng thành công V. Các vấn đề gặp phải trong khi thực hiện dự án A. Thảo luận về từng vấn đề B. Cách khắc phục vấn đề VI. Cơ hội cho công việc tương lai - Các nguồn tài liệu tham khảo để viết tài liệu 〈 Yêu cầu kiểm soát thay đổi 〈 Bản ghi chi phí 〈 Phỏng vấn với các thành viên tổ, Ban lãnh đạo và khách hàng 〈 Biên bản các cuộc họp 〈 Lịch biểu thời gian 〈 Phác thảo dự án và những sửa đổi 〈 Tài liệu thống kê - Thời gian tốt nhất để viết tài liệu: liệu này: cuối dự án hoặc hay ngay sau khi dự án kết thúc. Càng để muộn càng không hay. - Tài liệu này là không có lợi khi nào? 〈 Người quản lí dự án không đủ trình độ, không đủ thông tin => viết ra một tài liệu không chính xác. 〈 Mục đích chính trị của tài liệu: Tài liệu không phản ảnh sự thật, hoặc để công kích người khác 〈 Không phổ biến cho ai, hoặc không cho ai đọc 4. Kiểm điểm sau khi bàn giao - Mục đích: Khảo sát năng suất phục vụ của sản phẩm và các hoạt động duy trì, bảo trì, hỗ trợ khách hàng. 86
27. 〈 Xác định xem mục đích và mục tiêu của dự án có đạt được không? 〈 Khẳng định sản phẩm có đáp ứng nhu cầu của khách hàng không? 〈 Đánh giá ích lợi thực sự của sản phẩm? 〈 Khách hàng có thực sự thoả mãn? 〈 Thảo luận sự hỗ trợ tiếp tục - Các lưu ý khi họp kiểm điểm 〈 Mời tư vấn độc lập 〈 Khoanh vùng những nội dung cần họp bàn, tránh đi lan man, cãi vã 〈 Cần khoảng 3-6 tháng chuẩn bị cho cuộc họp (tuỳ độ lớn của dự án) 〈 Tổng kết những điểm mới (sáng kiến, kinh nghiệm, ) trong dự án 5. Đóng dự án Trong giai đoạn cuối của dự án, trước khi kết thúc, nên làm một số việc: - Tiến hành các cuộc họp kết thúc dự án 〈 Xem xét các yêu cầu dự án 〈 Các mục tiêu dự án 〈 Phạm vi dự án 〈 Các kết quả bàn giao chính 〈 Phương pháp tiếp cận dự án 〈 Lịch trình ở mức cao 〈 Xem xét các thành quả dự án 〈 Nền tảng 〈 Kết quả bàn giao 〈 Đặc tính nổi bật 〈 Các lợi ích lớn đã đạt được 〈 Thực trạng cuối cùng 〈 Kế hoạch so với thực tế 〈 Phân tích sự khác nhau và thảo luận 〈 Xem xét các khoản mục mở 〈 Danh mục nổi bật 〈 Danh mục các vấn đề thay đổi 〈 Khái quát các bước tiếp theo 〈 Hoàn tất lịch trình chuyển đổi 〈 Các mục tiêu/ kế hoạch đối với rà xét sau thực hiện 87
28. - Giảmbớt người, phân công lại công việc - Xác nhận và công bố những cá nhân/đơn vị đã làm tốt (động viên tinh thần, hoặc kèm theo vật chất - dù nhiều/ít) - Lấy xác nhận từ phía khách hàng (một cách để người quản lí dự án tự bảo vệ mình) - Các nhân tố thành công 〈 Kế hoạch làm việc toàn diện được xây dựng 〈 Việc đánh giá quá trình triển khai được tiến hành 〈 Các báo cáo dự án cuối cùng được phát hành, các kết quả bàn giao được lưu giữ 〈 Giải thể chính thức tổ chức của dự án 〈 Việc rà xét toàn diện sau triển khai được tiến hành a. Kết luận - Việc giải thể yêu cầu sự cẩn thận không kém việc xây dựng nên dự án - Rà xét sau thực hiện là một cơ hội tốt đối với nghiên cứu của cá nhân cũng như tổ chức - Nhưng nó phải được lập kế hoạch và tiến hành đảm bảo tập trung tích cực vào các mục tiêu kinh doanh của dự án và tổ chức 88
29. CÁC THUẬT NGỮ CHUYÊN MÔN English Vietnamese Abstract Trừu tượng, tóm lược Accommodate Điều tiết, làm cho phù hợp Accuracy Đúng đắn, chính xác Acti-gram Sơ đồ hoạt động Activate Kích hoạt Activate mechanism Cơ chế kích hoạt Activity chart Lược đồ hoạt động Ad - hoc Không thể thức, đặc biệt Adaptability Tính thích nghi, thích ứng Adaptation Thích nghi, thích ứng Adaptive maintenance Bảo trì thích nghi Add-on Phụ thêm Adjusted productivity value Giá trị hiệu năng được điều chỉnh Algorithm Giải thuật Alias Biệt hiệu, bí danh, tên phụ Allocation Cấp phát, phân phối Alternative Phương án khác, lựa chọn, phụ Analysis Phân tích Application context Ngữ cảnh áp dụng Architecture context diagram Biểu đồ ngữ cảnh kiến trúc Architecture design Thiết kế kiến trúc Architecture dictionary Từ điển kiến trúc Architecture flow diagram Biểu đồ kết nối kiến trúc Architecture interconnection Biểu đồ liên nối kiến trúc diagram Architecture template Tiêu bản/khuôn mẫu kiến trúc Archive Lưu trữ Argument đối Arithmetic-logic unit Bộ số học-logic Artifact Tạo tác, mẫu 89
30. Assembler Hợp ngữ Assembly line diagram Biểu đồ đường lắp ráp Assembly structure Cấu trúc lắp ghép Assign Gán Associative data object Đối tượng dữ liệu kết hợp Attribute Thuộc tính Audit Kiểm toán Available Có sẵn, sẵn dùng Background Hậu cảnh, nền, ngầm Background processing Xử lý hậu cảnh, ngầm Backing - off Thúc đẩy Backup Sao lưu Balance Cân bằng Bar chart Sơ đồ thanh Bar code Mã vạch Baseline Vạch ranh giới, đường cơ sở, nét cơ bản Batch processing Xử lý theo lô Behavior Hành vi Behavious modeling Mô hình hoá hành vi Benchmark Tiêu chuẩn Black box testing Kiểm thử hộp đen Boundary Biên Boundary time Thời gian biên Breakpoint Điểm đứt, gián đoạn Bubble chart Lược đồ hình tròn Budget Ngân sách Buffer Bộ đệm CASE (Computer Aided Software Engineering) Công nghệ phần mềm với máy tính hỗ trợ Case Study Ví dụ lớn minh hoạ Characteristic Đặc trưng, đặc tính 90
31. Chart Lược đồ Checklist Danh sách kiểm tra Class diagram Biểu đồ lớp Classification Phân lớp Clean room Phòng sạch Closely couple Gắn chặt Closely Couple Kết nối chặt Closely couple Kết nối chặt Code generator Bộ sinh mã (chương trình,) Coding Mã hoá Coercion Bó buộc Cohesion Cố kết Coincidentally Trùng khớp ngẫu nhiên Combination Tổ hợp Combined entity diagram Biểu đồ thực thể được tổ hợp Communication Truyền thông Compatibility Tính tương hợp, tương thích Compilation, Compile, Compiler Biên dịch, Chuơng trình dịch Complexity adjustment value Giá trị điều chỉnh độ phức tạp Component Thành phần, cấu phần Composite data item Khoản mục dữ liệu hợp thành (phức hợp) Composition object Đối tượng hợp thành Computer system engineering Công nghệ hệ thống máy tính Concurrence Tương tranh, đồng thời Configuration Cấu hình Conic Hình nón Connectivity Tính nối được, tính liên thông Con-routine Trình tương tranh Consistence Nhất quán Constitute Cấu thành, hợp thành, thiết lập Constraint Ràng buộc, điều kiện Construct Kết cấu, xây dựng 91
32. Context Ngữ cảnh Context model Mô hình Ngữ cảnh Context switching Chuyển Ngữ cảnh Contractor Nhà thầu Control điều khiển, kiểm soát Control flow diagram Biểu đồ luồng điều khiển Control hierarchy Phân cấp điều khiển Control process Tiến trình điều khiển Control specification Đặc tả điều khiển Control unit Bộ điều khiển Conveyer Băng truyền Coordinate Phối hợp Core Lõi Co-routine Trình tương hỗ Corrective maintenance Bảo trì hiệu chỉnh Correctness Tính đúng đắn Cost Chi phí, giá Cost-benefit analysis Phân tích chi phí-lợi ích Couple Dính nối, gắn kết Coupling Kết nối Crisis Khủng hoảng Critical path method Phương pháp đường găng Cross stimulate Kích thích chéo Cyclomatic Xoay vòng Data condition Điều kiện dữ liệu Data flow diagram Biểu đồ luồng dữ liệu Data flow graph đồ thị luồng dữ liệu Data modeling Mô hình hoá dữ liệu Data object Đối tượng dữ liệu Data store Kho dữ liệu Data structure Cấu trúc dữ liệu Data transfer rate Tỉ lệ truyền dữ liệu Data typing Định kiểu dữ liệu 92
33. Database Cơ sở dữ liệu Database engineering Kỹ nghệ cơ sở dữ liệu Datagram Bức dữ liệu Data-object-type hierarchy Phân Cấp dữ liệu-Đối tượng- kiểu Datum Dữ liệu Debate Tranh luận Debug Gỡ rối i Declaration Khai báo Decomposition Phân rã Defect Khiếm khuyết Dependable Tính tin cậy Deployment Triển khai Depth độ sâu Design Thiết kế Design model Mô hình thiết kế Design specification Đặc tả thiết kế Design walkthrough Xét duyệt thiết kế Detail design Thiết kế chi tiết Development plan Kế hoạch phát triển Development system Hệ thống phát triển Diagnostic analyzer Bộ phân tích chẩn đoán Diagram Biểu đồ Diagrammatic Văn phạm biểu đồ Dimension Chiều, kích cỡ Direct Trực tiếp Dispatch branch Nhánh gửi Dispatch module Mo đun gửi Display Hiển thị Distributed system Hệ phân tán Document Tư liệu Driven Đi ra từ, rút ra Driver Điều khiển Dynamic multi-variable model Mô hình đa biến động 93
34. Dynamic single-variable model Mô hình đơn biến động Economic feasibility Khả thi kinh tế Economic justification Luận chứng kinh tế Effort Công sức effort Trách nhiệm Effort adjustment factor Nhân tố điều chỉnh công sức Elaboration Kỹ lưỡng, Chi tiết Embedded software Phần mềm nhúng Empirical estimation Ước lượng thực nghiệm Encapsulation Bao bọc Endeavors Nỗ lực mới Engineering Công nghệ Kỹ nghệ Enhancement Nâng cao Entity Thực thể Entity diagram Biểu đồ thực thể Entity-relationship diagram Biểu đồ thực thể- liên kết (ER) Enumeration type Kiểu kiệt kê Environment Môi trường Estimate Estimation ước lượng Estimation model Mô hình ước lượng Estimation variable Biến ước lượng Event Sự kiện Event flow Luồng sự kiện Exception handling Khiển giải biệt lệ Expected value Giá trị kỳ vọng Expert system Hệ chuyên gia Explode Khai triển Exploration Khái thác Extensibility Tính mở rộng được External entity Tác nhân ngoài (Thực thể )i Facilitated application specification Kỹ thuật đặc tả ứng dụng techniques(FAST) thuận tiện Facilitator 94
35. Người điều khiển Factoring Lấy thừa số chung Failure Sai lỗi Fan- in Số modul vào, tản ra Fan-out Số modul ra, co cụm Fault tree analysis Phân tích cây thiếu sót Feasibility study Nghiên cứu khả thi Feature Tính năng Feature point Điểm chức năng Finalize Hoàn tất Flag Cờ Flexibility Tính mềm dẻo Flow Luồng Flowchart Lưu đồ Foreground Tiền cảnh Form Hình thái, hình dạng Formal specification đặc tả hình thức Formal technical review Họp xét duyệt kỹ thuật hình thức Fourth General Technology (4GT) Kỹ thuật thế hệ 4 Frame Khuôn khổ, khung Framework Cơ cấu Khuôn khổ công việc Framework Khung mẫu Fulfillment Hoàn chỉnh, Thực hiện Function Hàm, chức năng Functional decomposition Phân rã chức năng Functional point điểm chức năng Functionality Tính chức năng Fundamental system model Mô hình hệ thống nền tảng Generality Tính tổng quát Grammar Văn phạm Handle Giải quyết Handler điều giải 95
36. Hardware Phần cứng Hardware requirement analysis Phân tích yêu cầu phần cứng Heuristic Trực cảm, mẹo Hierarchy Cấp bậc Home-machine interaction Tương tác người-máy Homologous đồng đẳng Host machine Máy chủ Human engineering Kỹ nghệ con người Identification Căn cước Identifier Tên gọi, định danh , căn cước Identify Xác định, định danh Implementation Cài đặt Implementation description Mô tả cài đặt Implode Hợp triển Incoming flow Luồng đi vào Inconsistency Bất nhất Incremental Tăng lên, gia tăng Index Chỉ số Indicator Chỉ báo Indirect Gián tiếp Information flow Luồng thông tin Information society Xã hội thông tin Information structure Cấu trúc thông tin Inherent Cố hữu Inheritance Kế thừa Immature Input Cái vào, đầu vào Instance Thể nghiệm, thể hiện Instance connection Mối nối thể nghiệm Instantiation Việc lấy thể nghiệm Instruction Lệnh Integrate Tích hợp Integrate test Kiểm thử tích hợp Integrate testing Kiểm thử tích hợp 96
37. Integrity Toàn vẹn Interactive Tương tác Interconnection description Mô tả liên nối Interface Giao diện Interoperability Tính liên tác Interpretation Thông dịch Interrelated Tương quan nhau Interrupt Ngắt Interrupt latency Trễ ngắt Item Khoản mục Knowledge Tri thức Knowledge database Cơ sở tri thức Layer Tầng, lớp Legal feasibility khả thi pháp lý Level of abstraction Mức độ trừu tượng Life cycle Vòng đời Line of balance chart Biểu đồ cân bằng Linearity Tính tuyến tính Linguistic modular unit Đơn vị mô đun ngôn ngữ Link Móc nối, nối, mối nối Link weight Trọng số nối Linked list Danh sách móc nối List Danh sách LOC (Line Of Code) Số dòng mã lệnh Locality Tính cục bộ Logic manipulator Bộ thao tác logic Loosely couple Gắn lỏng Machine cycle Chu trình máy Machine language Ngôn ngữ máy Macroscopic level Mức vĩ mô Mailbox Hộp thư Maintainability Tính bảo trì được 97
38. Maintenance Bảo trì Maturity Trưởng thành, thuần thục Measure Việc đo Member Thành viên Memory locking Khoá bộ nhớ Message Thông báo, Thông điệp Message path Đường thông báo Meta-model Siêu mô hình Meta-rule Siêu luật Method(s) Phương pháp, phương thức Metric độ đo Micro-electronic Vi điện tử Milestone Cột mốc Mock-up Mô hình, market Mode Mốt. Chế độ Model checking tools Công cụ kiểm tra mô hình Modification Sửa đổi Modularbility , Module Tính mô đun, Mô đun Module diagram Biểu đồ mô đun Monitor Bộ điều phối, giám sát Multiple inheritance Kế thừa bội Multi-programming đa lập trình Multi-tasking đa nhiệm Multi-user Nhiều người dùng Mutual exclusion Loại trừ lẫn nhau Narrative Lời thuật Network Mạng Neuron network Mạng nơ ron Node đỉnh , nút Non-procedural Phi thủ tục Normalization rule Quy tắc chuẩn hoá Object Đối tượng, sự vật Object code Chương trình đích Object diagram Biểu đồ Đối tượng 98
39. Objective Mục tiêu Object-oriented Hướng Đối tượng Obsolesce Lỗi thời Occurrence Sự xuất hiện Off - the - shelf Không lỗi thời Off-line Gián tuyến On-line Trực tuyến Operability Tính vận hành Operation Thao tác , tác vụ Organizational unit Đơn vị tổ chức Outgoing flow Luồng đi ra Output Cái ra, đầu ra Outsourcing Gia công/ khoán ngoài Out-souring Thoái hoá Package Đóng gói Package body Thân bộ trình Paradigm Khuôn cảnh Parallel Song song Parallel computing Tính toán song song Parameter Tham biến Partition Phân hoạch Password Mật khẩu, mật hiệu Path đường dẫn Perceptive maintenance Bảo trì hoàn thiện Performance Hiệu năng Performance criteria Tiêu chuẩn hiệu năng Performance test Kiểm thử hiệu năng Phase Pha Planning Lập kế hoạch Polygon Đa giác Polymorphism Đa hình thái Portability Tính khả chuyển Pragmatic Thực dụng, thực hiện Precision Chính xác 99
40. Preliminary design Thiết kế sơ bộ Preventive maintenance Bảo trì phòng ngừa Primary storage Bộ nhớ chính Problem space Không gian vấn đề Procedural abstraction Trừu tượng thủ tục Procedural language Ngôn ngữ thủ tục Process Quá trình, tiến trình Process activate table Bảng kích hoạt tiến trình Process activation table Bảng kích hoạt tiến trình Process diagram Biểu đồ xử lý Process identifier Bộ định danh tiến trình Processing Xử lý Processing narrative Lời thuật xử lý Processor Bộ xử lý Profile Sơ thảo Program design language Ngôn ngữ thiết kế chương trình Program structure Cấu trúc chương trình Programming language Ngôn ngữ lập trình Programming, coding Lập trình progress Tiến độ Project Dự án Proof checking tools Công cụ kiểm tra chứng minh Protocol Giao thức Protocol description Mô tả giao thức Prototype environment Môi trường làm bản mẫu Prototyping Làm bản mẫu Pseudo-code Giả lệnh Pull-down menu Đơn kéo xuống Quality Chất lượng Quantity Số lượng Quasi formal Giả hình thức Query Truy vấn Rayleigh-Norden curve Đường cong Rayleigh-Norden 100
41. Real-time Thời gian thực Reclamation Tái chế Recover Dò lại Recursion, recursive Đệ quy Re-engineering Tái kỹ nghệ Reference Tham khảo Refinement Làm mịn Relation model Mô hình quan hệ Reliability Tính tin cậy được, độ tin cậy Repeat Lặp Repertoire, Repository Kho , Kho chứa Request for proposal (RFP) Yêu cầu về các đề nghị Requirement Yêu cầu Requirement analysis Phân tích yêu cầu Requirement dictionary Từ điển yêu cầu Requirement statement language Ngôn ngữ phát biểu yêu cầu Resolution Giải trình, độ phân giải, Resource model Mô hình tài nguyên Reusability Khả năng tái sử dụng Reusable Dùng lại, tái dụng Reverse engineering Kỹ nghệ ngược Reverse reengineering tool Công cụ tái công nghệ ngược Risk analysis Phân tích rủi ro Rough merge Gộp thô Round-trip Khứ hồi Scalar Vô hướng Scalar item Khoản mục vô hướng Scenario Kịch bản Schedule Lập lịch Schema Sơ đồ Schematic block diagram Biểu đồ khối sơ đồ Scope Phạm vi Scrap Manh mún Secondary storage Bộ nhớ phụ 101
42. Security An toàn Selection Tuyển chọn Semantic Ngữ nghĩa Semaphore Cờ báo hiệu Send Truyền, gửi Sensitive test Kiểm thử nhạy cảm Sequential Tuần tự Sequential vector Vec tơ tuần tự Server Phục vụ Service Dịch vụ Serviceability Tính phục vụ được Simple Simplicity Đơn giản Simulation Mô phỏng Size Kích cỡ Software architecture Kiến trúc phần mềm Software configuration Cấu hình phần mềm Software engineer Kỹ sư phần mềm Software engineering (SE) Công nghệ phần mềm Software project plan Kế hoạch dự án phần mềm Software requirement specification Đặc tả yêu cầu phần mềm Software safety An toàn phần mềm Software store Kho phần mềm Solution Giải pháp Solution space Không gian giải pháp Source code Chương trình gốc , nguồn Specification đặc tả Specification environment Môi trường đặc tả Spine Chốt trục Spiral Xoắn ốc Spoilage Hỏng hóc Stage Giai đoạn stakeholder Người tham gia State Trạng thái State transition diagram Biểu đồ chuyển trạng thái 102
43. Static multi-variable model Mô hình đa biến tĩnh Static single-variable model Mô hình đơn biến tĩnh Stepwise elaboration Làm kỹ lưỡng từng bước Stepwise refinement Làm mịn dần từng bước Store Ghi nhớ, lưu giữ, Kho Stress test Kiểm thử gay cấn Strong type Kiểu mạnh Structure chart Lược đồ cấu trúc Structure clash Va chạm cấu trúc Stub Cuống Sub-flow Luồng con Subordinate Thuộc cấp Substantiate Chứng minh Suite Loạt Super-ordinate Thượng cấp Supplementary Phụ trợ, bù Supportability Tính hỗ trợ được Swap Tráo đổi Synergy Hoà hợp Syntax Cú pháp Synthetic Toàn thái System analysis Phân tích hệ thống System concept document Tài liệu quan niệm về hệ thống System image Hình ảnh hệ thống System module narrative Lời thuật mô đun hệ thống System perception Cảm nhận hệ thống System respond time Thời gian hệ thống đáp ứng System software Phần mềm hệ thống System specification đặc tả hệ thống System specification review Xét duyệt đặc tả hệ thống System state Trạng thái hệ thống System test Kiểm thử hệ thống Tactics Chiến thuật 103
44. Tangible Hữu hình, rõ ràng Target machine Máy đích Task analysis Phân tích nhiệm vụ Task network Mạng nhiệm vụ Technical feasibility khả thi kỹ thuật Technology Công nghệ, Kỹ nghệ Template Tiêu bản Test Kiểm thử Test plan and procedure Bản kế hoạch và thủ tục kiểm thử Testability Tính kiểm thử được Threat Đe doạ Time scale Khoảng thời gian Time stamp Đóng dấu thời gian Time-out Thời gian chết Tool Công cụ Trace-ability Tính theo dõi được Trade-off Trả giá, cân nhắc Transaction Giao tác Transform Biến đổi Transform center Trung tâm biến đổi Transform flow Luồng biến đổi Transition Chuyển dịch, Chuyển đổi, biến đổi Treatment Xử lý Trigger Kích hoạt , cá Type checking Kiểm tra kiểu Typeless Phi kiểu Unit test Kiểm thử khối Update Cập nhật Usability Tính sử dụng được User Manuel Sổ tay người dùng User model Mô hình người dùng Valid 104
45. Hợp lệ Validation test Kiểm thử hợp lệ Variability Độ biến thiên Variant Biến thể Verification test Kiểm thử Visibility Thấy được , trực quan Visual Trực quan Vocabulary Vốn từ walkthrough Xét duyệt Warehouse Nhà kho Warning Cảnh báo Waterfall model Mô hình thác nước Wayside Bó hẹp Weak type Kiểu yếu White box testing Kiểm thử hộp trắng Width Chiều rộng Work breakdown structure Cấu trúc phân chia công việc Workflow Dòng công việc Workforce Nhân lực Workplace Hiện trường 105
46. TÀI LIỆU THAM KHẢO Tiếng Việt 1. Đề án Tin học hoá quản lí hành chính Nhà nước 2001-2005 trong 2. Giáo trình Khoa học quản lí - Đoàn Thị Thu Hà, Nguyễn Thị Ngọc Huyền - NXB KHKT - Hà Nội - 2001 3. Phương pháp luận quản lí dự án Công nghệ thông tin - Ngô Trung Việt - NXB KHKT - Hà Nội - 2002. Tiếng Anh 4. Project Management Methodology - Ralph L. Kliem, Irvin S. Ludin, Ken L. Robertson - Marcel Dekker Inc., 1997 5. Software Project Management - Bob Hughes and Mike Cotterell - The McGraw Hill - Third Edition - 2002 6. A Guide to the Project Management - Body of Knowledge - William R. Duncan - PMI Standard Committee - 1996 7. Software Engineering - A Practitioner's approach - Roger S. Pressman - Fifth edition - McGraw Hill - 2001 8. Managing Large Database Development Projects -Tài liệu ging cho Workshop - Dự án CNTT Việt Nam-Canada tổ chức tại Hà Nội- tháng 5/1998 9. Một số Website 106
47. CÁC PHỤ LỤC Phụ lục 1. Sơ lược về sự phát triển các tư tưởng quản lí Hoạt động quản lí đã có từ rất lâu, nhưng khoa học quản lí lại rất mới mẻ. Có tồn tại nhiều chủ thuyết khác nhau về quản lí. 1.1. Thời Trung Hoa cổ đại - Khổng tử: Đức trị 〈 Khổng Tử: 551 TCN - 479 TCN (Thời Xuân Thu) 〈 "Nhân" là nguyên tắc cơ bản, quy định hoạt động của chủ thể quản lí và quan hệ với đối tượng quản lí. Động viên, khuyến khích. 〈 Xuất phát điểm của con người: Thiện. Công-Tư thống nhất 〈 Khuyến khích chủ nghĩa "quân tử", đả phá chủ nghĩa "tiểu nhân" 〈 Nhấn mạnh tâm và đức của người quản lí - Hàn Phi Tử: Pháp trị 〈 Hàn Phi Tử: 403 TCN - 221 TCN (Thời Chiến Quốc) 〈 "Pháp" là nguyên tắc cơ bản, quy định hoạt động của chủ thể quản lí và quan hệ với đối tượng quản lí. Thưởng phạt công minh. 〈 Xuất phát điểm của con người: ác, vụ lợi. Công-Tư mâu thuẫn. 〈 ủng hộ chuyên chế, cổ vũ độc tài 〈 Ba khái niệm cơ bản trong quản lí: "thế" (quyền lực), ""pháp" (luật pháp), "thuật" (biện pháp quản lí). 1.2. Trường phái cổ điển trong thời kỳ đầu của phát triển công nghiệp - Sự ra đời: Thế kỷ 18, công nghiệp bắt đầu phát triển ở Châu Âu => ra đời các nhà máy, công ty => xuất hiện nhu cầu quản lí - Lí thuyết quản lí một cách khoa học (Scientific Management) 〈 Freadrich Winslow Taylor (Mỹ), 〈 Quy trình lao động hợp lí, không trùng lặp, tốn ít sức, năng suất cao 〈 Tiêu chuẩn hoá công việc, đặt ra định mức, trả lương theo sản phẩm 〈 Chuyên môn hoá lao động 〈 Tiền thưởng là động cơ thúc đẩy sản xuất - Lí thuyết "quản lí hành chính - tổ chức" 〈 Henry Fayol (Pháp), Max Weber (Đức), 〈 Các chức năng quản lí: POSDCORB P: Planning - Lập kế hoạch O: Organizing - tổ chức (xác định phân cấp quản lí) S: Staffing - quản lí nhân sự D: Directing - Chỉ đạo CO: coordinating - Phối hợp (=>họp) 107
48. R: Reviewing - Kiểm tra B: Budgeting - Tài chính, ngân sách 〈 Các nguyên tắc quản lí 〈 Các nguyên tắc ra quyết định 1.3. Trường phái tâm lí - xã hội trong thời kỳ hiện đại - Coi trọng mối quan hệ con người - Xem xét quản lí trên quan điểm tâm lí học - Năng suất làm việc phụ thuộc rất nhiều vào các yếu tố tâm lí, xã hội của đối tượng quản lí - Người quản lí tìm cách gia tăng sự thoả mãn tâm lí và nhu cầu tinh thần của nhân viên - Coi trọng mối quan hệ tốt đẹp giữa các thành viên trong tổ chức 1.4. Trường phái định lượng về quản lí - Cố gắng áp dụng các bộ môn khoa học khác phục vụ cho quản lí - Không coi trọng các yếu tố tâm lí, xã hội - Các bộ môn khoa học được áp dụng cho quản lí: Lí thuyết hệ tthống, lí thuyết xác suất, lí thuyết thống kê, lí thuyết chọn mẫu, lí thuyết mô phỏng, lí thuyết xếp hàng, lí thuyết quyết định, tin học 1.5. Một vài tư tưởng quản lí của xã hội đương đại (từ 1960 đến nay) Ví dụ về một mô hình mới quản lí nhà máy, doanh nghiệp của Nhật Nhật Châu Âu - Làm việc suốt đời - Làm việc theo hợp đồng, có thời hạn - Đánh giá và đề bạt chậm - Đánh giá và đề bạt nhanh - Công nhân đa năng - Công nhân được chuyên môn hoá - Cơ chế kiểm tra gián tiếp - Cơ chế kiểm tra trực tiếp - Quyết định tập thể - Quyết định cá nhân - Trách nhiệm tập thể - Trách nhiệm cá nhân - Quyền lợi toàn cục - Quyền lợi riêng 108
49. Phụ lục 2. Kĩ năng họp và trình bày 1.6. Không nên và nên - Không nên 〈 Họp không hiệu quả, 〈 Quá dài, 〈 Không tập trung, 〈 Bị vài cá nhân chi phối, 〈 Ghi lại kết quả không đầy đủ - Nên: 〈 Công bố cuộc họp từ trước 〈 Chuẩn bị chương trình họp, phát cho mọi người và theo đúng chương trình đó. 〈 Ghi lại biên bản, kết quả cuộc họp. 〈 Mời tất cả những ai có liên quan. 〈 Khuyến khích mọi người đóng góp ý kiến. Tránh để vài người chi phối đối thoại. 〈 Nếu phải họp trên 1 giờ => tìm cách thư giãn 1.7. Kỹ năng trình bày - Chuẩn bị cho trình bày Lưu ý: Không chuẩn bị tức là chuẩn bị cho thất bại - Chọn chủ đề o Thính giả muốn nghe o Chủ đề mới mẻ o Mình nắm vững - Phân tích thính giả o Vãng lai, tự nguyện hay bất đắc dĩ o Mục đích nghe của thính giả o Thái độ, lòng tin của thính giả - Phân tích cơ hội o Thời gian thuyết trình o Địa điểm thuyết trình o Mong đợi của tính giả - Cấu trúc bài thuyết trình 109
50. Mở đầu Thân bài Kết luận - Mở đầu: 〈 Tạo ra sự chú ý 〈 Khái quát vấn đề 〈 Chứng minh tầm quan trọng 〈 Sắp đặt tâm trạng và giọng điệu Lưu ý: Không có cơ hội thứ hai để gây ấn tượng ban đầu - Thân bài 〈 Lựa chọn những nội dung quan trọng 〈 Sắp xếp theo một trình tự logic 〈 ấn định thời gian cho từng nội dung 〈 Chia thành các phần dễ tiếp thu Lưu ý: Cần giới hạn các điểm chính - Kết luận 〈 Thông báo trước khi kết thúc 〈 Tóm tắt điểm chính 〈 Thách thức và kêu gọi - Sự chú ý của người nghe Mức độ chú ý Thời gian 110
51. - Tài liệu hỗ trợ 〈 Làm rõ 〈 Tăng hấp dẫn 〈 Tăng ấn tượng 〈 Chứng minh 〈 Dụng cụ và phương tiện 〈 Tài liệu phân phát 〈 Máy chiếu, slide/PowerPoint o Khoảng 5-7 dòng cho một slide o Chữ to - Khả năng lưu thông tin Sau 3 giờ Sau 3 ngày Nghe 70% 10% Nhìn 72% 20% Nghe và nhìn 85% 65% Giao tiếp phi ngôn từ - Khái niệm phi ngôn từ Hữu thanh Vô thanh Ngôn từ Từ nói Từ viết Giọng nói Điệu bộ Phi ngôn từ Tiếng thở dài Dáng vẻ Kêu la Hình thức Chất giọng (âm lượng, Nét mặt độ cao, ) - Các loại hình của thông điệp phi ngôn từ 〈 Giọng nói o Giới tính, tuổi tác, quê quán o Âm lượng, Độ cao, Chất lượng o Tốc độ, Điểm dừng, Nhấn mạnh 〈 Dáng điệu và cử chỉ 〈 Mặt (Mặt là mặt tiền của ngôi nhà thân thể) 〈 Mắt (Mắt là cửa sổ tâm hồn) 〈 Tay 〈 Di chuyển, khoảng cách với thính giả 〈 Trang phục Lưu ý: Cần biểu lộ Nhiệt tình trong mọi thông điệp phi ngôn từ 111
52. - Sức mạnh của thông điệp 〈 Luôn tồn tại 〈 Có giá trị thông tin cao 〈 Mang tính quan hệ 〈 Chịu ảnh hưởng của văn hóa - Sự khác biệt của thông điệp ngôn từ và phi ngôn từ Ngôn từ Phi ngôn từ Đơn kênh Đa kênh Không liên tục Liên tục Kiểm soát được Không kiểm soát được Rõ ràng Không rõ ràng 1.8. Lắng nghe - Khái niệm chung 〈 Lợi ích của việc lắng nghe 〈 Thời lượng sử dụng các kỹ năng o Đọc: 16% o Nói: 30% o Viết: 9% o Nghe: 45% - So sánh các hoạt động giao tiếp Nghe Nói Đọc Viết Phải học Đầu tiên Thứ hai Thứ ba Cuối cùng Phải sử dụng Nhiều nhất Tương đối Tương đối ít ít nhất nhiều Được dạy ít nhất Tương đối ít Tương đối Nhiều nhất nhiều - Các kiểu nghe 〈 Nghe thông tin 〈 Nghe có phân tích 〈 Nghe đồng cảm - Các yếu tố ảnh hưởng đến hiệu quả nghe 〈 Người nghe o Nhu cầu o Thái độ, lòng tin o Mục đích o Sự thông minh 112
53. 〈 Thông điệp 〈 Cấu trúc của thông điệp 〈 Kênh truyền thông điệp 〈 Sự mới lạ, hấp dẫn 〈 Ngôn ngữ, ngữ pháp 〈 Người nói o Sự gần gũi o Sự hấp dẫn o Sự tin tưởng o Mục đích, động cơ o Cách diễn đạt o Địa vị, quyền lực 〈 Môi trường - Nguyên nhân nghe không hiệu quả 〈 Nghe không nỗ lực, tập trung 〈 Nghe phục kích 〈 Nghe một phần 〈 Giả vờ nghe 〈 Nhiễu tâm lí 〈 Nhiễu vật lí 〈 Tai có vấn đề - Kỹ năng nghe hiệu quả (1) 〈 Nghe xong hãy nói 〈 Gác tất cả các việc khác lại 〈 Kiểm soát cảm xúc bản thân 〈 Phản hồi để ủng hộ người nói 〈 Nhìn vào người nói 〈 Không ngắt lời khi không cần thiết 〈 Không vội vàng tranh cãi hay phán xét 〈 Hỏi để hiểu rõ vấn đề - Kỹ năng nghe hiệu quả (2) 〈 Đối diện với người nói 〈 Ngồi thẳng 〈 Giao lưu bằng mắt - Kỹ năng nghe hiệu quả (3) 〈 Nhắc lại nội dung 〈 Diễn giải nội dung 〈 Tìm ra ý chính 〈 Không võ đoán 〈 Ghi chép thông tin chính. 113
54. Phụ lục 3. Độ đo của Dự án - Là những gì có thể định lượng hoá, nhằm đánh giá tiến độ, độ ổn định và chất lượng của việc phát triển phần mềm. 〈 Số liệu khách quan: số lượng giờ làm việc của các thành viên trong nhóm, SLOC, số lỗi mắc phải 〈 Số liệu chủ quan: phụ thuộc vào đánh giá chủ quan, ví dụ: mức độ khó khăn của bài toán, độ rõ ràng của các yêu cầu, - Các thông tin về khách quan và chủ quan là bổ sung cho nhau. 〈 Các số liệu chủ quan là cơ sở để giải thích cho các số liệu khách quan 〈 Các số liệu khách quan là chỗ dựa để người phụ trách xem lại xem sự đánh giá của mình, sự hiểu của mình về bài toán đã chính xác chưa 〈 Những thông tin khách quan phản ánh tiến độ hoặc tình trạng dự án. Ví dụ: số các module đã lập trình xong, số lượng các kiểm thử đã thực hiện. Những con số này sẽ cho thấy tiến độ đến đâu. Kiểu độ đo Ví dụ Nguồn lấy Thời gian Mục đích độ đo lấy độ đo Khối lượng - Total SLOC Người Hàng tháng - Xem độ ổn định (new, quản lớ của sự tiến triển modified, dự án reused) - Total modules/units - Total effort Lao động - Số giờ làm - Lập trình Hàng tuần - Độ ổn định của việc viên dự án - Số giờ máy - Có thể - Căn cứ để lập kế tính thông qua hoạch lại phần mềm chuyên dụng Trạng thái - Yêu cầu hệ - Người 2 tuần - Tiến độ dự án thống (Số quản lớ - Độ ổn định của lượng các yêu các yêu cầu cầu chung, yêu cầu chưa rõ) - Các Modules/Units - Lập trình đã thiết kế, đã viên 114
55. lập trình, đã kiểm thử - SLOC - Lập trình - Số lượng các viên kiểm thử Lỗi/sửa đổi - Số lỗi - Lập trình Hàng tuần Chất lượng công - Số các thay viên việc đổi 115
56. Phụ lục 4. Khoán ngoài – Mua sắm 1.9. Khoán ngoài - Tại sao cần khoán ngoài cho bên thứ ba? 〈 Để có được ưu thế cạnh tranh. 〈 Để tận dụng được tri thức chuyên gia cao cấp và những kinh nghiệm thực tế công nghiệp tốt nhất. 〈 Dành nguồn lực nhân lực khan hiếm cho việc kinh doanh cốt lõi. 〈 Tạo điều kiện thuận lợi cho việc tái cấu trúc vận hành và giảm chi phí. 〈 Nhiều cơ hội an toàn và hợp pháp để cải tiến hiệu năng tài chính. 〈 Nâng cao việc cung cấp sản phẩm, tài sản đa dạng và thu nhập. 4.1.1. Dịch vụ khoán ngoài - Thực hiện các chức năng nhân danh tổ chức 〈 Hợp đồng với các nhà cung cấp dịch vụ bên thứ ba để thực hiện các chức năng vận hành của tổ chức thay vì tiến hành chúng một cách có chủ ý. 〈 Bao quát một phạm vi rộng những thu xếp, bao gồm o Thông tin lõi và xử lí giao tác o Dịch vụ Internet o Trung tâm dịch vụ khách hàng o Dịch vụ vận hành trung tâm dữ liệu - Cung cấp sản phẩm và dịch vụ mà tổ chức lúc đầu chưa có 〈 Tổ chức cung cấp sản phẩm và dịch vụ cho khách hàng qua bên thứ ba. 〈 Chẳng hạn, ngân hàng có thể đi vào mối quan hệ thị trường mà ngân hàng bán cho khách hàng các sản phẩm không mang tính ngân hàng. - Vượt ra ngoài các thuộc tính của tổ chức 〈 Tổ chức để tên hiệu hay toàn bộ trạng thái đã được qui định cho sản phẩm và dịch vụ của mình thành có nguồn gốc và/hoặc được tiến hành bởi người khác. 〈 Tổ chức cho phép bên thứ ba tiến hành kinh doanh theo tên hiệu của mình mang tiềm năng dễ gây vấn đề nhất cho mối quan hệ với bên thứ ba và thường cấp quyền kiểm soát giám sát phụ có ý nghĩa. 4.1.2. Rủi ro liên quan tới khoán ngoài - Dựa vào bên thứ ba có thể làm tăng đáng kể rủi ro cho tổ chức, làm giảm việc kiểm soát quản lí, và do đó đòi hỏi nỗ lực giám sát nhiều của cấp quản lí. - Việc dùng bên thứ ba của tổ chức để đạt tới mục đích của mình không làm giảm đi trách nhiệm của cấp quản lí tổ chức đảm bảo rằng hoạt động bên thứ ba được tiến hành theo cách an toàn và đúng đắn và tuân thủ với luật định. 116
57. - Mối quan hệ với bên thứ ba nên là chủ đề cho cùng việc quản lí rủi ro, an ninh, riêng tư và những chính sách bảo vệ khác vẫn được trông đợi nếu tổ chức tiến hành các hoạt động đó một cách trực tiếp. 4.1.3. Tiến trình quản lí rủi ro - Thẩm định rủi ro và lập kế hoạch chiến lược - Tuyển chọn bên thứ ba và trách nhiệm nghề nghiệp - Chuẩn bị hợp đồng - Giám sát mối quan hệ bên thứ ba - Thẩm định rủi ro và lập kế hoạch chiến lược 〈 Tích hợp với mục tiêu chiến lược toàn thể 〈 Nhận diện các chủ định chiến lược, ích lợi, khía cạnh pháp lí, chi phí và rủi ro liên kết với hoạt động bên thứ ba. 〈 Xây dựng hiểu biết đầy đủ và hiện thực về mối quan hệ có thể làm gì cho tổ chức. 〈 Tự thẩm định về năng lực lõi, sức mạnh quản lí và yếu điểm. 〈 Xây dựng chiến lược đi ra thích hợp và kế hoạch dự phòng trong trường hợp cần kết thúc mối quan hệ với bên thứ ba. - Tri thức chuyên gia để giám sát và quản lí hoạt động. 〈 Thẩm định tri thức chuyên gia nội bộ để đánh giá và quản lí hoạt động và mối quan hệ với bên thứ ba. 〈 Phải dành nguồn lực cần thiết cho việc điều phối và đo hiệu năng. 〈 Phân công trách nhiệm rõ ràng để quản lí mối quan hệ bên thứ ba. 〈 Phải có đủ tri thức kĩ năng để đánh giá thiết kế, vận hành và giám sát mối quan hệ bên thứ ba. - Quan hệ chi phí/ lợi ích 〈 Đo sự ổn định và tính sống lâu dài so với lợi nhuận ngắn hạn hay tiết kiệm chi phí. 〈 Giữ cân bằng tiết kiệm chi phí với quyền lợi lâu dài và giá sát thích hợp. 〈 Phải có thẩm định hiệu năng theo kế hoạch tiếp diễn, nếu không sẽ có nguy cơ ước lượng thấp chi phí hay ước lượng quá lợi ích của khoán ngoài. - Chọn bên thứ ba và trách nhiệm nghề nghiệp 〈 Trách nhiệm nghề nghiệp nên bao gồm việc đánh giá kĩ tất cả thông tin về bên thứ ba, và bao gồm: o Kinh nghiệm trong việc thực hiện và hỗ trợ cho hoạt động được đề nghị. o Bản kê tài chính được kiểm định. o Uy tín kinh doanh, tai tiếng và kiện tụng. 117
58. o Trình độ chuyên môn, kiến thức kinh nghiệm và danh tiếng của người uỷ nhiệm bên thứ ba. o Môi trường kiểm soát nội bộ và sự kiện kiểm định - Bắt đầu, tiếp tục, khôi phục kinh doanh và kế hoạch dự phòng. 〈 Chi phí phát triển, thực hiện và hỗ trợ. 〈 Tín nhiệm và thành công giải quyết với người thầu lại. 〈 Tin tức về bảo hiểm. 〈 Thông tin quan trọng khác về điều không thấy được: o Chiến lược và mục đích kinh doanh của bên thứ ba o Chính sách nguồn lực con người o Sáng kiến chất lượng o Chính sách quản lí chi phí và cải tiến hiệu quả 4.1.4. Vấn đề hợp đồng - Cấp quản lí phải đảm bảo rằng những trông đợi và nghĩa vụ của từng bên được xác định rõ, được hiểu rõ và thực thi được. - Tính mật và tính an ninh - Việc tiếp tục lại kinh doanh và kế hoạch dự phòng - Nhận diện - Bảo hiểm - Giải quyết tranh chấp - Giới hạn về trách nhiệm pháp lí - Không trả được và kết thúc - Phàn nàn của khách hàng - Nhà cung cấp dịch vụ ngoại quốc 4.1.5. Giám sát mối quan hệ bên thứ ba - Sau khi tham gia vào hợp đồng hay thoả thuận với bên thứ ba, 〈 Cấp quản lí phải điều phối bên thứ ba theo các hoạt động và hiệu năng của bên đó. 〈 Cấp quản lí phải dành đủ nhân viên với tri thức chuyên gia cần thiết để giám sát bên thứ ba. - Điều phối tình hình tài chính 〈 Ước lượng tình hình tài chính của bên thứ ba ít nhất cũng theo hàng năm, và ước lượng thường xuyên hơn khi rủi ro cao. 〈 Đảm bảo rằng các nghĩa vụ tài chính của bên thứ ba với người kí hợp đồng là được đáp ứng theo cách đúng hạn. 〈 Xét duyệt sự thích hợp của bao quát bảo hiểm của bên thứ ba. 〈 So sánh thu nhập/chi phí thực tế với các dự kiến. - Kiểm soát điều phối 〈 Thực hiện các cuộc họp kiểm điểm đảm bảo phẩm chất tại chỗ. 118
59. 〈 Tài trợ cho việc kiểm định có phối hợp và kiểm điểm với nhóm người dùng. 〈 Kiểm điểm báo cáo kiểm định. Theo dõi mọi khiếm khuyết. 〈 Kiểm điểm việc lập kế hoạch dự phòng để tiếp tục nghiệp vụ của bên thứ ba và kiểm thử để đảm bảo rằng tất cả các dịch vụ có thể được khôi phục trong thời gian chấp nhận được. 〈 Điều phối những thay đổi trong nhân sự bên thứ ba chủ chốt đã được dành cho hợp đồng. - Làm tài liệu 〈 Nếu tổ chức định quản lí mối quan hệ bên thứ ba thành công, thì nó phải làm tư liệu đúng đắn cho chương trình giám sát của mình. 〈 Lập danh sách các nhà cung cấp lớn hay bên thứ ba khác mà cấp quản lí đã chi số tiền lớn, hay những người được cho là chủ chốt đối với việc này. o Hợp đồng hợp pháp, hiện thời và đầy đủ. o Quản lí rủi ro đều đặn và báo cáo hiệu năng được nhận từ bên thứ ba. o Kế hoạch nghiệp vụ nhận diện ra tiến trình lập kế hoạch của quản lí, và trácnh nhiệm nghề nghiệp trong việc chọn bên thứ ba. - Chất lượng truy nhập của dịch vụ và hỗ trợ 〈 Báo cáo kiểm điểm đều đặn làm tư liệu về hiệu năng của bên thứ ba liên quan tới thoả thuận mức dịch vụ. 〈 Làm tài liệu và theo dõi các vấn đề hiệu năng theo cách thức đúng thời gia. 〈 Xác định việc huấn luyện thích hợp. 〈 Duy trì tài liệu và bản ghi liên quan tới việc tuân thủ hợp đồng, cải biên, và giải quyết tranh cãi. 〈 Họp thường kì với các bên hợp đồng để thảo luận về vấn đề hiệu năng và vận hành 1.10. Khoán ngoài 4.1.1. Cấu phần hợp đồng - Hợp đồng bao giờ cũng đề cập tới các cấu phần sau: 〈 Người kí hợp đồng chủ yếu: thực thể tiến hành khoán ngoài để đạt tới mục đích và là người chủ của sản phẩm cuối. 〈 Nhà cung cấp: thực thể cung cấp nguồn lực và vật chuyển giao cho người kí hợp đồng chủ yếu. 〈 Nguồn lực: phương tiện hay tài sản được dùng để đạt tới mục đích. Nguồn lực như phần cứng, phần mềm hay nhà cửa có thể được các bên cung cấp 119
60. - Mục đích: lí do của người kí hợp đồng chủ yếu về quan hệ với nhà cung cấp. - Thoả thuận: hợp đồng nêu đại cương mối quan hệ giữa người kí hợp đồng chủ yếu và nhà cung cấp, và Phát biểu về công việc hay Lệnh làm việc xác định tất cả các vật phẩm chuyển giao và tiêu chí chấp nhận. - Trách nhiệm công việc: tất cả các hoạt động trong tiến trình chọn nhà cung cấp phải được tóm tắt và làm tư liệu như một phần của tiến trình trách nhiệm công việc. Bản tóm tắt phải bao gồm tất cả các nhà cung cấp được xét tới, kết quả bản chào thầu Request for Quote (RFQ), và việc kiểm tra kinh nghiệm làm việc được dùng để đi tới quyết định. - Điều khoản và điều kiện hợp đồng có liên quan: tất cả mọi thoả thuận đều phải được kiểm điểm qua thảo luận pháp lí thích hợp và việc quản lí hợp đồng/nguồn/sở hữu trí tuệ trước khi cam kết từng phần hay toàn thể. - Thoả thuận cấp phép và hợp đồng nhà cung cấp 〈 Thoả thuận cấp phép và hợp đồng phải được thương lượng trước để cho chúng có sẵn khi cần tới cho hoạt động sản xuất. 〈 Phần mềm và tài liệu được chuyển giao ra ngoài nước đòi hỏi có giấy phép xuất khẩu và giấy phép nhập khẩu hợp lệ. 〈 Tất cả các phần mềm, nâng cấp và tài liệu phải đưa qua cuộc họp kiểm điểm phân loại xuất/nhập khẩu của ban quản trị để đảm bảo việc cấp phép đúng. 〈 Nên có thoả thuận sử dụng để hạn chế và xác định việc dùng có thẩm quyền và/hoặc đưa ra sản phẩm. 4.1.2. Quản lí hợp đồng Tiến trình làm hợp đồng là như sau: (1) Dự án xác định rõ chỗ nào đòi hỏi việc xây dựng do bên ngoài thực hiện. (2) Nhận diện người kí hợp đồng có khả năng làm khoán ngoài. Kí kết các phát biểu được giữ bí mật và gửi bản chào thầu Request for Quote (RFQ) cho từng nhà cung cấp có thể. (3) Phân tích kết quả RFQ, và chọn ra người cung cấp tuân thủ theo chính sách, trách nhiệm công việc thường được thực hiện và xác nhận vào lúc này. (4) Xây dựng bản hợp đồng với nhà cung cấp được chọn, và xây dựng Phát biểu công việc ban đầu có cả các cột mốc và tiêu chí chấp nhận. (5) Xác định các trông đợi giao hàng của nhà cung cấp (đặc tả chức năng, kết quả kiểm thử đơn vị, etc ). (6) Điều phối tiến độ và việc phát triển bởi người quản lí dự án và người quản lí phát triển. (7) Kiểm thử các sản phẩm công việc đã chuyển giao rồi chấp nhận hay đệ trình lại để sửa chữa hay gỡ lỗi. 120
61. (8) Sản phẩm công việc phần mềm được chấp thuận dựa trên điều khoản của hợp đồng và bản phát biểu về công việc SOW. (9) Dự án đi vào phần bảo trì như đặc tả của bản thoả thuận. - Xác định nhu cầu phần mềm 〈 Cấu phần phần mềm có tại chỗ hiện nay không? 〈 Có sản phẩm tại chỗ mà có thể được sửa đổi hay nâng cao để khớp với nhu cầu hiện tại không? 〈 Có giải pháp phần mềm hàng chợ tổng quát không? 〈 Có giải pháp hàng chợ tổng quát sẽ có tác dụng với sửa đổi nào đó không? 〈 Nếu không có tất cả các khả năng trên, thì phải xây dựng phần mềm. Nếu thiếu kĩ năng tại chỗ hay nhân lực không sẵn có thì sẽ phải thuê làm hợp đồng hay khoán ngoài cho phần việc này. - Chọn nhà cung cấp 〈 Thiết lập yêu cầu nghiệp vụ rõ ràng. 〈 Tài liệu yêu cầu nghiệp vụ sẽ trở thành cơ sở để tạo ra bản chào thầu Request for Quote (RFQ). 〈 Cần nhận diện các nhà cung cấp tiềm năng để xem xét. - Nỗ lực quản lí hợp đồng/nguồn tài liệu/sở hữu trí tuệ là mấu chốt để làm tài liệu về nhà cung cấp và đánh giá hiệu năng của nhà cung cấp. - Thương lượng hợp đồng 〈 Về mặt kĩ thuật, việc thương lượng bắt đầu khi lần đầu tiên tiếp xúc với nhà cung cấp tiềm năng để lấy thông tin. 〈 Điều mấu chốt là quản lí sự trông mong của nhà cung cấp từ đầu. Họ không được có thông tin chỉ dẫn rằng họ là nhà cung cấp được chọn trước khi đưa ra quyết định cuối cùng. 〈 Sau khi nhận được và phân tích bản dự thầu RFP, người quản lí dự án cùng với sự trợ giúp từ CSIPM, sẽ xác định ra nhà cung cấp được ưa chuộng. 〈 Tổ thương lượng bao gồm người quản lí dự án, CSIPM, và cố vấn pháp luật. - Kiểm điểm nhà cung cấp 〈 Có hai kiểu họp kiểm điểm quản lí chủ chốt cho từng hợp đồng. o Kiểm điểm hợp đồng trên cơ sở thường lệ (theo tháng, theo quí) để đảm bảo việc tuân thủ các điều khoản và điều kiện. o Họp kiểm điểm quản lí các hoạt động của nhà cung cấp khi thực hiện các nhiệm vụ hợp đồng. 4.1.3. Quản lí nhà cung cấp 121
62. - Người quản lí nhà cung cấp (VM) sẽ được chỉ định trong bản kế hoạch dự án cho từng nhà cung cấp đã có hợp đồng làm việc với dự án. Thông thường đó chính người quản lí dự án hay người quản lí phát triển của dự án đặc biệt. - Người quản lí nhà cung cấp phải có các thủ tục tại chỗ để đánh giá mức độ hiệu năng và chất lượng của nhà cung cấp trong cả thời hạn dự án - Hiệu năng của nhà cung cấp nên được lập kế hoạch và theo dõi trong tất cả các pha của vòng đời phát triển dự án. 〈 Lập kế hoạch nhà cung cấp và báo cáo trạng thái o Họp và kiểm điểm nhà cung cấp o Kiểm điểm sản phẩm công việc của nhà cung cấp o Kiểm soát thay đổi nhà cung cấp o Quản lí cấu hình phần mềm nhà cung cấp o Đảm bảo chất lượng phần mềm nhà cung cấp - Kế hoạch của nhà cung cấp và báo cáo trạng thái 〈 Người quản lí nhà cung cấp phải đảm bảo rằng thủ tục lập kế hoạch dự án của nhà cung cấp tuân thủ phương pháp phát triển ứng dụng phần mềm của tổ chức (SDM). 〈 Bản kế hoạch của nhà cung cấp phải bao gồm: o Chỉ báo hiệu năng (kích cỡ, chi phí, nguồn lực máy tính) o Lịch biểu (đường găng và các thành tựu cột mốc) o Các hoạt động kĩ thuật o Thẩm định rủi ro liên kết với chi phíe, nguồn lực, lịch biểu o Tuân thủ an ninh 〈 Người quản lí nhà cung cấp phải đảm bảo rằng nhà cung cấp gửi báo cáo trạng thái thường kì (theo tuần, tháng). - Họp và kiểm điểm nhà cung cấp 〈 Họp về trạng thái 〈 Cuộc họp khởi động cho tất cả các thành viên tổ để xem xét về bản kế hoạch dự án, vai trò và trách nhiệm, thủ tục, kế hoạch của nhà cung cấp. 〈 Kiểm điểm các yêu cầu phần mềm với tổ dự án, cộng đồng doanh nghiệp/người dùng, và nhà cung cấp. 〈 Các cuộc họp về trạng thái diễn ra tiếp sau đó được tổ chức để thảo luận các vấn đề, mối quan tâm, trạng thái các hoạt động, việc cần làm. - Xem như một hướng dẫn, cuộc họp kiểm điểm nhà cung cấp phải được tổ chức sau khi hoàn thành: 〈 Pha lập kế hoạch 〈 Pha xây dựng (phát triển) 122
63. 〈 P hSản phẩm công việc Khi nào kiểm điềm a Kế hoạch của nhà cung cấp Pha lập kế hoạch ổĐặc tả chức năng và giao diện Pha lập kế hoạch n Tài liệu phân tích và thiết kế Pha xây dựng đKế hoạch và trường hợp kiểm thử Pha xây dựng ị nKết quả kiểm thử Họp kiểm điểm tính sẵn sàng h bàn giao của nhà cung cấp Tài liệu người dùng Họp kiểm điểm tính sẵn sàng h bàn giao của nhà cung cấp o á (kiểm thử) 〈 Pha trình diễn / Đánh giá (kiểm thử chấp nhận của người dùng) - Họp kiểm điểm tính sẵn sàng bàn giao của nhà cung cấp nên được tổ chức trước mọi việc bàn giao sang kiểm thử tích hợp hay sản phẩm. - Thủ tục và tiêu chuẩn chấp nhận được xác định cho phần mềm và sản phẩm công việc không là phần mềm: 〈 Bản ghi nhớ bàn giao của nhà cung cấp 〈 Kết quả ki - Người quản lí nhà cung cấp đưa ra chữ kí chấp nhận để chỉ ra việc hoàn thành thoả đáng. 〈 Hiệu năng của nhà cung cấp được đánh giá theo tiêu chí đánh giá được xác định trong thoả thuận hợp đồng. 〈 Việc đánh giá hiệu năng có thể được tiến hành một cách thường kì trong toàn bộ thời gian của hợp đồng, không chỉ vào lúc cuối. 〈 Mọi tài liệu đánh giá nên được dùng làm cái vào cho việc chọn nhà cung cấp tương lai. - Kiểm điểm sản phẩm làm việc của nhà cung cấp 〈 Với mỗi cuộc họp kiểm điểm, phải chuẩn bị báo cáo kiểm điểm và lưu trữ trong bộ tài liệu dự án của người quản lí nhà cung cấp. 〈 Nhà cung cấp phải được thông báo về bất kì sự không tuân thủ nào bằng văn bản. 〈 Nhà cung cấp phải tạo ra và thực hiện bản kế hoạch hành động sửa chữa để giải quyết vấn đề. 〈 Người quản lí nhà cung cấp theo dõi các việc cần làm để kết thúc. - Quản lí thay đổi với nhà cung cấp 123
64. 〈 Mọi thay đổi với yêu cầu phần mềm đều phải được trao cho nhà cung cấp bằng văn bản viết. 〈 Nhà cung cấp phải tuân theo các thủ tục kiểm soát thay đổi và đánh giá tác động của thay đổi. 〈 Người quản lí nhà cung cấp phải kiểm điểm việc phân tích thay đổi của nhà cung cấp và truyền đạt sự chấp thuận cho tiến hành thay đổi. 〈 Số lượng các thay đổi phải được điều phối và làm tư liệu rõ ràng. - Quản lí cấu hình phần mềm của nhà cung cấp 〈 Người quản lí nhà cung cấp phải đảm bảo rằng các thủ tục quản lí cấu hình phần mềm là tuân thủ theo phương pháp phát triển phần mềm SDM của tổ chức. 〈 Người quản lí nhà cung cấp điều phối các hoạt động quản lí cấu hình của nhà ucng cấp và thông báo cho nhà cung cấp, bằng văn bản, về bất kì sự không tuân thủ nào. 〈 Người quản lí nhà cung cấp phải đảm bảo rằng nhà cung cấp đã tiến hành các hành động sửa chữ như được yêu cầu. - Đảm bảo chất lượng của nhà cung cấp 〈 Người quản lí nhà cung cấp phải đảm bảo rằng các thủ tục đảm bảo chất lượng là tuân thủ với phương pháp phát triển phần mềm SDM của tổ chức. 〈 Tổ chức các cuộc họp kiểm điểm đều đặn để xác định nguồn lực đảm bảo chất lượng phần mềm SQA thích hợp, các kế hoạch đảm bảo chất lượng phần mềm và các chuẩn là thích hợp cho việc điều phối hiệu năng của nhà cung cấp. 〈 Người quản lí nhà cung cấp điều phối các hoạt động của nhà cung cấp và thông báo cho nhà cung cấp, bằng văn bản, về bất kì sự không tuân thủ nào của họ. 〈 Người quản lí nhà cung cấp phải đảm bảo rằng nhà cung cấp đã tiến hành các hành động sửa chữa như được yêu cầu. 124