Bạn đang xem bài viết Quản Lý Chất Lượng Dự Án Phần Mềm – Apmp được cập nhật mới nhất trên website 2atlantic.edu.vn. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất.
Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một số đánh giá là còn yếu của các công ty phần mềm Việt Nam. Một số công ty trong nước hiện đã đạt các chuẩn quốc tế CMM/CMMI trong nâng cao năng lực và quản lý chất lượng phần mềm, song chỉ đếm được trên đầu ngón tay, và hiện cũng chỉ gói gọn trong vài công ty gia công cho thị trường nước ngoài.
Làm thế nào để một công ty này đạt được chuẩn quốc tế về chất lượng phần mềm? Mỗi công ty đều có đặc thù riêng, tuy nhiên điều chung nhất là họ đều phải phát triển và duy trì một Hệ thống quản lý chất lượng phần mềm.
QUẢN LÝ CHẤT LƯỢNG PHẦN MỀM LÀ GÌ ?
Lâu nay, nói đến chất lượng phần mềm (PM), không ít người nghĩ ngay đến vấn đề là xác định xem PM đó có phát sinh lỗi hay không, có “chạy” đúng như yêu cầu hay không và cuối cùng thường quy về vai trò của hoạt động kiểm tra phần mềm (testing) như là hoạt động chịu trách nhiệm chính.
Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội tình của hoạt động phát triển PM, điều họ cần quan tâm là liệu sản phẩm cuối cùng giao cho họ có đúng hạn hay không và làm việc đúng như họ muốn hay không.
Hình 1: Các mối quan hệ.
Tuy nhiên theo quan điểm của người phát triển PM, thực tế cho thấy hoạt động kiểm tra PM là quan trọng, nhưng không đủ để đảm bảo sản phẩm sẽ được hoàn thành đúng hạn và đúng yêu cầu. Kiểm tra sau cùng để phát hiện lỗi là điều tất nhiên phải làm, nhưng trong rất nhiều trường hợp, điều đó thường quá trễ và sẽ phải mất rất nhiều thời gian để sửa chữa.
Hiện có nhiều mô hình cung cấp các tiêu chuẩn cũng như hướng dẫn để triển khai HTQLCLPM. Hai trong số những mô hình được áp dụng rộng rãi hiện nay là ISO 9001-2000 và CMM/CMMi. Trong khi ISO 9001-2000 là tiêu chuẩn quản lý chất lượng dành cho tất cả các ngành nghề với những điều khoản ngắn gọn và mang tính tổng quát, thì CMM/CMMi là một bộ tập hợp khá đồ sộ các kinh nghiệm thực hành (gần 450 trang với CMM, và gần 700 trang với CMMi) có thể làm người đọc chưa có kinh nghiệm khó biết được các hoạt động và yếu tố đặc trưng cơ bản của HTQLCLPM là gì.
Qua một số tài liệu tham khảo, cũng như bằng kinh nghiệm bản thân khi nghiên cứu và ứng dụng ISO 9001-2000 và CMM/CMMi, chúng tôi sẽ trình bày các khái niệm, hoạt động cũng như yếu tố cơ bản cấu thành HTQLCLPM.
CĂN BẢN VỀ HỆ THỐNG QUẢN LÝ CHẤT LƯỢNG PHẦN MỀM
Một HTQLCLPM thường có 2 mục tiêu (hình 1):
• Mục tiêu thứ nhất: xây dựng chất lượng cho PM ngay từ giai đoạn bắt đầu. Điều này đồng nghĩa với việc bảo đảm các yêu cầu cho PM từ mọi nguồn khác nhau phải được định nghĩa, diễn đạt và hiểu một cách đúng đắn, giữa người đưa ra yêu cầu và người thực hiện yêu cầu.
• Mục tiêu thứ hai: bảo đảm chất lượng của PM xuyên suốt quá trình phát triển.
Một HTQLCLPM hoàn chỉnh bao gồm rất nhiều hoạt động và bộ phận cấu thành, chúng khác nhau tùy theo từng tổ chức khi triển khai. Tuy nhiên, theo kinh nghiệm, chúng tôi chỉ giới thiệu 10 hoạt động và yếu tố cơ bản nhất thường gặp:
1. Các tiêu chuẩn (Standards)
2. Lập kế hoạch (Planning)
3. Xem xét, xem lại (Reviewing)
4. Kiểm tra (Testing)
5. Phân tích lỗi (Defect analysis)
6. Quản lý cấu hình (Configuration Management)
7. Bảo mật (Security)
8. Đào tạo, huấn luyện (Education/Training)
9. Quản lý người cung cấp, thầu phụ (Vendor Management)
10. Quản lý rủi ro (Risk Management)
(Để đơn giản, từ đây, “10 hoạt động và yếu tố” được gọi tắt là “10 yếu tố”)
Có mối liên hệ giữa 10 yếu tố cơ bản trên và các giai đoạn hay pha phát triển PM. Hình 2 cho thấy sơ đồ liên hệ trong mô hình phát trình waterfall (xem bài “Tổng quan các mô hình phát triển phần mềm”, ID: A0508_106 và A0510_122). Ký hiệu “x” giao nhau giữa một yếu tố và một pha biểu thị yếu tố được thực hiện tại pha đó. Phần sau đây sẽ làm rõ ý nghĩa của 10 yếu tố cơ bản.
1. Các tiêu chuẩn
Sản xuất PM ngày nay không còn đơn thuần mang tính sáng tạo ngẫu hứng như trước đây, mà đang trở thành một lĩnh vực được kiểm soát chặt chẽ, theo những tiêu chuẩn nhất định. Các tiêu chuẩn có thể là các kinh nghiệm hoặc các phương pháp hiệu quả nhất, được đề xuất từ các hiệp hội nghề nghiệp như IEEE (The Institute of Electrical and Electronics Engineers, Inc – Học viện các kỹ sư điện và điện tử), từ các tổ chức quốc tế như ISO (International Organization for Standardization), hoặc các quy tắc chuẩn hóa để giao tiếp giữa sản phẩm với nhau… hoặc đơn giản do chính tổ chức phát triển PM đề ra để áp dụng cho chính họ.
Các tiêu chuẩn có thể bao gồm tất cả các khía cạnh của một chu kỳ phát triển PM, trải dài suốt mọi pha phát triển. Bất kể tiêu chuẩn xuất phát từ đâu, từ nội bộ công ty, hoặc từ ngoài, nó đều phải có một số đặc điểm sau:
• Tính cần thiết
• Tính khả thi
• Tính đo lường được
Các tiêu chuẩn nên được chọn và thể hiện sao cho khi sử dụng, các khía cạnh kỹ thuật cần thiết sẽ được nhấn mạnh, tránh trường hợp hiểu sai hoặc sa vào những tiểu tiết phụ trợ. Một ví dụ thường thấy là tiêu chuẩn định dạng cho tài liệu, mục đích của tiêu chuẩn là để bảo đảm khía cạnh chất lượng về kỹ thuật của tài liệu. Tuy nhiên, trong rất nhiều trường hợp tiêu chuẩn đã bị hiểu sai và sa đà vào việc kiểm tra các chi tiết về mặt hình thức. Lưu ý là để bảo đảm các tiêu chuẩn được nghiêm túc thực hiện, chúng phải mang tính bắt buộc và được quy định ở chính sách cấp công ty.
Một dạng phổ biến bắt buộc phải có của tiêu chuẩn là hệ thống các “quy trình”, kèm theo các bộ phận phụ thuộc như “thủ tục” “hướng dẫn” “mẫu biểu” “tiêu chuẩn” v.v. Tùy theo lĩnh vực hỗ trợ mà chúng có các tên tương ứng, chẳng hạn: quy trình sản xuất PM, quy trình kiểm soát chất lượng, quy trình kiểm tra…
2. Lập kế hoạch
Lập kế hoạch là yêu cầu kinh điển cũng như thao tác cơ bản của hầu hết các HTQLCLPM. Kết quả của hoạt động này thường là một (hoặc nhiều) tài liệu gọi là bản kế hoạch.
Theo quan điểm quản lý hiện đại, các công việc gắn liền với những mục tiêu, ngắn hạn hoặc dài hạn, đều có thể xem như là một dự án hoặc chuỗi các dự án. Kế hoạch cho dự án thường bao gồm những điểm chính sau:
• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm
• Xác định nhân lực, vật lực và chi phí
• Chỉ định phương pháp, cách tiếp cận để thực thi dự án
• Lập kế hoạch làm việc chi tiết
• Kế hoạch phối hợp và hỗ trợ hoàn thành dự án
• Các kế hoạch khác
Tùy theo nhu cầu cho từng dự án, có thể có nhiều kế hoạch khác, cả về quản lý hoặc kỹ thuật, một số kế hoạch thường gặp chẳng hạn: Kế hoạch kiểm tra, kế hoạch tích hợp sản phẩm, kế hoạch huấn luyện…
• Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án
Lưu ý là các tài liệu kế hoạch của dự án không phải bất di bất dịch, nó phải được cập nhật thậm chí thay đổi xuyên suốt dự án khi yêu cầu của dự án thay đổi.
3. Xem xét, xem lại
Mục đích là để cung cấp thông tin trực quan về tình trạng của các hoạt động xảy ra trong suốt quá trình sản xuất và cài đặt PM.
Xem xét trên sản phẩm – thường được gọi là xem xét kỹ thuật – bao gồm hai loại: chính thức hoặc không chính thức. Xem xét không chính thức thường được thực hiện trong quá trình phát triển sản phẩm, còn xem xét chính thức thường được thực hiện tại thời điểm kết thúc các chặng phát triển.
Điểm khác nhau chính về mặt kỹ thuật giữa xem xét chính thức và không chính thức là ở mức độ nghiêm ngặt của quy trình và các bước thực hiện. Chẳng hạn, xem xét chính thức buộc phải lên kế hoạch, ghi nhận tất cả các lỗi phát hiện và giám sát đến khi tất cả lỗi đã được sửa chữa, xem xét không chính thức thì không bắt buộc.
Trong thực tế, có khá nhiều định nghĩa và nhiều loại xem xét khác nhau. Về tổng quan, IEEE định nghĩa có ba loại:
• Review: Cuộc họp chính thức nhằm trình bày một vấn đề, một tài liệu, một sản phẩm… cho những người quan tâm, người sử dụng, khách hàng… nhằm thu thập ý kiến phản hồi hoặc đạt được sự thỏa thuận phê chuẩn trên vấn đề, tài liệu hoặc sản phẩm được trình bày.
• Walkthrough: Kỹ thuật đánh giá không chính thức, qua đó tác giả của một tài liệu, sản phẩm… giải thích tài liệu, sản phẩm đó cho một nhóm đồng nghiệp. Các đồng nghiệp này sẽ đặt câu hỏi hoặc cho ý kiến bổ sung về một số lĩnh vực để bảo đảm chất lượng kỹ thuật của tài liệu hoặc sản phẩm.
4. Kiểm tra lỗi
Kiểm tra lỗi (testing) là một hoạt động sống còn trong sản xuất PM. Kiểm tra lỗi nhằm mục đích chứng minh rằng các yêu cầu đối với PM là được thỏa mãn. Các hoạt động kiểm tra bao gồm các bước: lập kế hoạch, thiết kế test, thi hành test, và báo cáo kết quả kiểm tra. Chi tiết về kiểm tra PM chúng tôi đã trình bày trong TGVT A số tháng 12/2005 (ID: A0512_110).
Ở đây tôi muốn nhấn mạnh đến bước lập kế hoạch kiểm tra bắt đầu từ giai đoạn nhận và phát triển yêu cầu. Tương tứng với mỗi yêu cầu là một phương pháp kiểm tra thích hợp. Một yêu cầu không thể coi là hoàn chỉnh nếu như nó không thể kiểm tra được. Kế hoạch kiểm tra được thiết lập ngay từ chặng phát triển yêu cầu. Do yêu cầu thường thay đổi xuyên suốt dự án, kế hoạch kiểm tra do đó cũng phải thay đổi theo.
5. Phân tích lỗi
Trong thực tế, lỗi là phần “luôn hiện diện” trong mọi PM từ giai đoạn phát triển sơ khởi đến khi nó không còn được sử dụng.
Các tổ chức PM thường dùng thuật ngữ “chất lượng” để chỉ zero, hay một lượng nhỏ các lỗi trên sản phẩm PM, một số khác lại gắn liền khái niệm “chất lượng” với sự hài lòng của khách hàng. Trên quan điểm khách hàng, bất kể lúc nào, hễ PM “chạy” không tốt, không đáp ứng sự mong đợi đều được xem là có lỗi, bất kể do code sai, hoặc do hiểu nhầm yêu cầu, thậm chí là một chức năng “nên có” nhưng hiện thời chưa sẵn sàng.
Phân tích lỗi được thực hiện trên tất cả lỗi được tìm thấy, nhằm mục đích tìm hiểu nguyên nhân và xu hướng gây ra lỗi, định hướng cho việc sửa chữa các lỗi hiện hành cũng như phòng ngừa, triệt tiêu khả năng xảy ra lỗi trong tương lai. Phân tích lỗi là con đường chính yếu phục vụ cho việc giảm sự xuất hiện lỗi.
Phân tích lỗi không chỉ nhằm mục đích cải thiện tình trạng lỗi của phần mềm đang xây dựng, xa hơn nó cho ta thấy được những điểm yếu cần cải tiến của quy trình phát triển PM. Thông tin về lỗi của các dự án trong quá khứ sẽ cho ta thấy được nên cải tiến, thay đổi quy trình phát triển PM như thế nào để các dự án trong tương lai tránh đi vào “vết xe đổ” của các dự án trước.
Số liệu phục vụ cho việc phân tích lỗi có thể đến từ nhiều nguồn khác nhau. Mỗi tổ chức tuỳ theo nhu cầu và đặc điểm riêng, tự định nghĩa và thu thập các số liệu nầy.
Lỗi trong quá trình phân tích và sửa chữa có thể được phân loại để có hành động phù hợp, tuỳ theo các đặc tính khác nhau mà chúng thể hiện. Các đặc tính trong Bảng: “Các thuộc tính của lỗi.” thường được sử dụng trong nhiều hệ thống phân tích lỗi.
6. Quản lý cấu hình
Mục đích của quản lý cấu hình (QLCH) là để thiết lập và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án PM, xuyên suốt chu kỳ sống của dự án đó.
QLCH bao gồm nhiều hoạt động, tuy nhiên về cơ bản chúng bao gồm bốn hoạt động chính: nhận dạng (identification), kiểm soát (control), kiểm kê báo cáo (accounting) và kiểm tra đánh giá (audit). Tùy theo độ lớn và độ phức tạp của dự án, phạm vi và mức độ áp dụng của các hoạt động QLCH sẽ khác nhau. Với những hệ thống lớn và phức tạp, mỗi hoạt động QLCH phải do những người được giao trách nhiệm (role) cụ thể phụ trách. Tùy yêu cầu, một số hoạt động QLCH được làm không chính thức (informal) hoặc chính thức (formal), nhằm quản lý tốt quá trình phát triển của phần mềm, đặc biệt là quản lý sự thay đổi trong dự án. Tham khảo bài “Quản Lý Cấu Hình…” (ID: A0506_122) để biết thêm chi tiết.
7. Bảo mật
Bảo mật luôn là vấn đề gây nhức nhối vì thường không được nhận thấy cho đến khi hệ thống bị chọc thủng. Bảo mật có ba khía cạnh chính, bảo mật nội dung dữ liệu, bảo mật dữ liệu đang được truyền (trên đường truyền) và bảo mật về mặt vật lý của vật chứa dữ liệu. Các hoạt động bảo mật được áp dụng cho cả nội dung dữ liệu lẫn bản thân vật lý của vật chứa dữ liệu.
Các yếu tố hay nguyên nhân tác động đến dữ liệu hoặc trung tâm dữ liệu của hệ thống PM rất đa dạng. Đó có thể là tự nhiên hoặc cố ý, chẳng hạn thiên tai, cháy, virus, hacker, phá hoại của chính nhân viên công ty, ăn cắp dữ liệu, thậm chí ngày nay còn do các hoạt động khủng bố gây ra. Trong một số tổ chức, việc bảo mật dữ liệu lưu trữ và dữ liệu chuyển dịch được xem là vấn đề sống còn.
Một lý do gây hỏng dữ liệu rất thường gặp là dữ liệu bị thay đổi một cách vô tình không kiểm soát được. Một khi dữ liệu đã không đúng, điều tất yếu là hệ thống phần mềm sử dụng dữ liệu đó sẽ cho ra những kết quả sai. Đối với người dùng, đó là một hệ thống không tốt, thậm chí là không dùng được.
Một hệ thống PM “tốt” phải chú ý tới tất cả những yếu tố có thể ảnh hưởng đến dữ liệu hoặc hoạt động của hệ thống. Một hệ thống “tốt” còn phải tính đến khả năng phục hồi dữ liệu, phục hồi hoạt động của hệ thống khi xảy ra sự cố.
8. Đào tạo/huấn luyện
Nói đơn giản, huấn luyện nhằm trang bị cho những người phát triển cũng như sử dụng PM có đủ kiến thức và kỹ năng để thực hiện công việc của họ.
Một khía cạnh khác thường được cho là ít quan trọng nhưng thực ra lại mang tính quyết định, đó là khả năng hiểu để sử dụng PM của người sử dụng. Người sử dụng thường chỉ có ý tưởng về yêu cầu đối với PM và không biết sử dụng hoặc sử dụng không đúng cách làm PM “chạy” sai hoặc không hết chức năng. Do vậy huấn luyện cho người sử dụng cũng là một khâu hết sức cơ bản. Nhưng thực tế những người phát triển PM lại không có thời gian và kỹ năng thực hiện tốt việc huấn luyện, việc nầy thường phải do một bộ phận chuyên trách trong công ty thực hiện.
9. Quản lý người cung cấp
Trong các tổ chức PM, mua hay thuê sản phẩm hoặc dịch vụ từ một người cung cấp thứ ba là rất phổ biến. Việc “mua” có thể bao gồm những mặt hàng đơn giản như máy tính, máy in, cho đến những dịch vụ thuê gia công PM. Chất lượng của sản phẩm và dịch vụ “mua” này nếu quản lý không tốt sẽ ảnh hưởng quan trọng đến sản phẩm hoặc dịch vụ của tổ chức cung cấp cho khách hàng của mình.
Đối tượng sản phẩm hoặc dịch vụ cần mua hay thuê rất đa dạng, tùy mỗi loại và độ phức tạp, các tổ chức sẽ có những biện pháp và mức độ quản lý chất lượng tương ứng.
Hình 3: Mô hình tổ chức truyền thống.
10. Quản lý rủi ro
Rủi ro (risk) là một yếu tố tồn tại trong mọi dự án. Quan niệm về quản trị dự án cho rằng “người quản trị dự án giỏi là người không ngạc nhiên về các sự kiện xảy ra trong dự án”, điều nầy có nghĩa là mọi rủi ro tiềm ẩn phải được “nhìn thấy” trước, đi đôi với kế hoạch giải quyết.
Rủi ro là một sự kiện chưa nhưng có khả năng xảy ra, và khi nó xảy ra thường sẽ đặt một dự án vào tình huống xấu, hoặc thậm chí là một “tai nạn” cản trở khả năng hoàn thành các mục tiêu của một dự án. Có nhiều loại cũng như cách xếp các loại rủi ro khác nhau, tuy nhiên nhìn chung có các loại sau:
• Về kỹ thuật: Chủ yếu xoay quanh việc có hiểu đúng và đủ các yêu cầu đặt ra cho dự án hay không, cũng như có giải pháp đúng để giải quyết chúng hay không. Việc hiểu sai yêu cầu cũng như đưa ra giải pháp sai là nguyên nhân hàng đầu làm dự án thất bại.
– Huấn luyện cho người sử dụng không đầy đủ
– Sử dụng sai chức năng của sản phẩm, kể cả cố ý hoặc vô tình
– Bảo trì sản phẩm không đầy đủ
• Về môi trường: Bao gồm cả môi trường phát triển, kiểm tra lẫn sử dụng sản phẩm. Những rủi ro từ bên ngoài, sự không tương thích, virus v.v.
• Về kiểm tra: Không đủ thời gian hoặc kiểm tra không đúng, không quét hết yêu cầu.
Quy trình cơ bản quản lý rủi ro gồm 4 bước:
• Nhận biết các rủi ro
• Khảo sát mức tác động nếu chúng xảy ra
• Xác định các giải pháp đối phó
• Giám sát các rủi ro và thực thi các giải pháp đối phó
Có rất nhiều giải pháp khác nhau để đối phó hay giảm thiểu tác động của rủi ro. Trong thực tế, các giải pháp thường gồm các loại:
• Loại bỏ: Khi chi phí loại bỏ rủi ro thấp, hoặc rủi ro nếu xảy ra sẽ gây ảnh hưởng cực kỳ nghiêm trọng.
• Phòng tránh
• Giảm thiểu thiệt hại: Khi không thể phòng tránh hay loại bỏ rủi ro, ta có thể thực thi các biện pháp để giảm thiểu khả năng xảy ra hoặc giảm thiểu chi phí khắc phục rủi ro nếu nó xảy ra.
• Chấp nhận: Đành chấp nhận “sống chung với rủi ro” trong trường hợp chi phí loại bỏ, phòng tránh, làm nhẹ rủi ro là quá lớn, hoặc mức độ tác hại của rủi ro nếu xảy ra là không đáng kể, hoặc khả năng xảy ra của nó là cực thấp.
Trong thực tế, quản lý rủi ro là một quá trình phức tạp, tuy nhiên đó không phải là mục tiêu của bài viết này.
MỘT SỐ YẾU TỐ QUAN TRỌNG KHÁC
Bên cạnh 10 yếu tố chính như đã trình bày trên, còn có một số yếu tố quan trọng khác ảnh hưởng đến chất lượng PM.
1. Bảo trì phần mềm
Bảo trì PM nhìn chung có thể xem như là phần mở rộng hoặc lặp lại của một chu trình phát triển PM.
Bảo trì PM bao gồm hai hoạt động chính: sửa chữa các lỗi đã không được phát hiện trong giai đoạn phát triển và kiểm tra; nâng cấp PM theo yêu cầu phát sinh hoặc yêu cầu đã được hiểu không đúng trong gia đoạn phát triển.
Mỗi hoạt động bảo trì đều được thực hiện tương tự như một hoạt động trong giai đoạn phát triển, yêu cầu để dẫn đến hành động bảo trì chính là yêu cầu thay đổi.
Một điều cơ bản nhưng lại hay mắc phải trong giai đoạn này là việc phớt lờ hay áp dụng lỏng lẻo các quy tắc QLCH và điều tất yếu là nguy cơ sai sót sẽ rất lớn, nhất là trong các trường hợp thay đổi xảy ra nhiều hay liên tục.
2. Tài liệu
Nhiều tổ chức PM do chưa hiểu đúng thường hay e ngại áp dụng ISO hay CMM/CMMI sẽ dẫn đến việc phát sinh quá nhiều tài liệu. Điều thiết yếu là phải hiểu rõ ý nghĩa và mục đích của tài liệu.
3. Tổ chức bộ máy
Dù bao nhiêu phương pháp quản lý chất lượng được thiết lập đi nữa, vấn đề nhân sự và tổ chức bộ máy làm việc hợp lý trong nhiều trường hợp lại là yếu tố quyết định tính hiệu quả của hệ thống.
Thực tế có rất nhiều mô hình tổ chức, hình 3 và 4 cho thấy 2 trong số các mô hình thông dụng, mỗi mô hình đều có ưu nhược điểm riêng, tùy đặc thù từng tổ chức, có thể sử dụng mô hình thích hợp.
Mô hình tổ chức như hình 3 cho ta có cảm giác tiết kiệm chi phí, trưởng dự án sẽ chịu trách nhiệm tất cả, không có chi phí riêng biệt cho nhân viên chỉ lo vấn đề chất lượng. Tuy nhiên, thực tế lại cho thấy, việc trưởng dự án xoay vần để lo hết mảng này đến mảng khác lại phát sinh chi phí đôi lúc còn cao hơn. Mặt khác, thường thì trưởng dự án dành phần lớn thời gian cho mảng phát triển sản phẩm, các mảng khác bị lơ là kể cả việc kiểm soát chất lượng.
Ở mô hình tổ chức như hình 4, bộ phận phụ trách chất lượng là độc lập và có kênh báo cáo hoàn toàn độc lập với dự án, khi cần thiết, báo cáo có thể lên thẳng đến cấp quản lý cao nhất. Thành công của mô hình nầy phụ thuộc nhiều vào mối liên kết hợp tác hỗ trợ giữa bộ phận chất lượng và bộ phận phát triển sản phẩm. Những công ty có độ trưởng thành cao, mối quan hệ giữa 2 bộ phận nầy rất khăng khít.
Mặc dù có rất nhiều mô hình, tuy nhiên chúng vẫn tuân thủ một nguyên tắc chung: Nếu nhân viên hoặc nhóm phụ trách chất lượng ở vị trí thấp hơn nhóm đang bị giám sát (sản xuất/phát triển), hệ thống chất lượng đó sẽ không mạnh và có vấn đề.
Tuy nhiên, một mô hình tổ chức tốt cùng các quy tắc chất lượng cũng chưa đủ, điều quan trọng là, trong một hệ thống quản lý chất lượng mạnh, mỗi thành viên trong hệ thống phải thực hiện thật tốt vai trò của mình.
Hình 4: Mô hình tổ chức cải tiến
4. Thiết kế và vận hành hệ thống quản lý chất lượng
Thiết kế và vận hành một hệ thống quản lý chất lượng (HTQLCL) trước hết phải gắn liền với việc định nghĩa rõ rệt chức năng và quyền hạn của tất cả những người tham gia, các hoạt động và trách nhiệm cụ thể cho từng vị trí một. Kế tiếp là lập kế hoạch, thiết kế và áp dụng các quy tắc và quy trình của HTQLCL.
4 nguyên tắc và yếu tố chính để bảo đảm sự thành công của một HTQLCL:
1. Văn hóa chất lượng “Hãy làm mọi thứ đúng ngay từ đầu”
2. Định nghĩa rõ ràng trách nhiệm và quyền hạn của những người tham gia
3. Mô tả rõ ràng các bộ phận của HTQLCL
4. Các tiêu chuẩn và quy trình cho HTQLCL
Những người trực tiếp sử dụng các quy trình của HTQLCL phải tham gia càng sớm càng tốt và tham gia xuyên suốt. Việc tham gia của họ là yếu tố quan trọng để quy trình làm ra có khả năng được chấp nhận và giá trị sử dụng cao, giảm thiểu những yếu tố không thực tế và không khả thi của quy trình.
Một yếu tố không thể thiếu nữa là sự kiểm soát và hỗ trợ đầy đủ, kịp thời của quản lý cấp cao đối với tiến độ phát triển và áp dụng HTQLCL. Sự giám sát, đôn đốc và giải quyết khó khăn của quản lý cấp cao giúp giải quyết các ách tắc, nâng cao trách nhiệm của thuộc cấp, và thúc đẩy tiến độ thấm nhuần văn hóa chất lượng trong toàn bộ tổ chức.
KẾT LUẬN
Một HTQLCLPM không chỉ có quy trình, kiểm tra hoặc ra lệnh, nó là sự kết hợp gắn bó của nhiều yếu tố. Mục tiêu sau cùng của HTQLCLPM là, dựa vào kết quả của các yếu tố cấu thành, cung cấp thông tin làm đầu vào cho những quyết định đúng đắn về quản lý, mang lợi ích về khi áp dụng các quy trình phát triển PM.
Source: PC World VN
Một Số Khái Niệm Trong Quản Lý Chi Phí Dự Án – Apmp
Xác định giá trị của dự án
189% là chi phí vượt quá dự toán ban đầu cho dự án của các doanh nghiệp
81 tỉ đô la là con số tiêu tốn bởi các dự án bị huỷ tại Mỹ mỗi năm
MOV (Measurable Organizational Value) là giá trị hữu ích mà dự án cung cấp cho tổ chức. 04 đặc điểm bắt buộc của MOV bao gồm:
(1) Đo lường được: Các chỉ số đo lường được thiết lập dựa trên giá trị của các chuyển giao (sản phẩm/dịch vụ chuyển giao) đối với mục tiêu của công ty
(2) Tạo giá trị: Ví dụ: một dự án phần mềm quản trị không chỉ dừng lại ở một sản phẩm thương mại, mà phải hỗ trợ đắc lực cho doanh nghiệp giải quyết các bài toán phát sinh từ chiến lược.
Dự án phải hữu ích cả về thời gian (được chuyển giao vào đúng thời điểm tổ chức cần) và giá trị thu về (vượt trội chi phí đầu tư).
Tài chính: Gia tăng lợi nhuận, Đầu tư ổn định, Chi phí quản lý thấp
Khách hàng: Nhiều lựa chọn về sản phẩm, Chất lượng sản phẩm tốt hơn, Cách phục vụ tốt hơn
Quy trình nội bộ: Giảm hoạt động sửa chữa, Cải tiến chuỗi cung ứng
Học hỏi & phát triển: Cải tiến các tiến trình, Áp dụng công nghệ mới, Chất lượng cuộc sống cao hơn
(4) Kiểm chứng được: Đánh giá kết quả thực tế của dự án đối với các mục tiêu của doanh nghiệp
Xác định các loại chi phí:
(1) Direct Cost: chi phí chi trực tiếp cho nguồn lực thực hiện dự án.
Ví dụ: Trong dự án có 1 công việc tốn 1 ngày để hoàn tất, yêu cầu 1 người thực hiện. Ngoài chi phí nhân lực (tiền công của người thực hiện), dự án cần trả thêm chi phí cho các tiện ích cho công việc:
Chi phí cho các phương tiện làm việc (điện, nước, thuê máy), tính theo giờ. • Chi phí bảo hộ lao động (quần áo, găng tay,…), tính theo tháng.
Chi phí tập huấn và các loại phí bảo hiểm hàng quý/năm.
Chi phí trực tiếp được xác định qua 5 bước:
Gọi tên các loại nguồn lực cần thiết
Đánh giá mức độ sử dụng mỗi loại nguồn lực
Xác định đơn giá của mỗi loại nguồn lực
Tính toán chi phí cho các công việc
Cân đối nguồn lực qua việc xem xét lại (review) để nguồn lực không bị sử dụng quá mức (cấp phát cho nhiều công việc cùng lúc)
(2) Indirect Cost: Chi phí gián tiếp chủ yếu sinh ra từ các hoạt động quản lý. Ví dụ: số giờ viết báo cáo/tuần, số giờ họp/tháng. Dự án càng phức tạp, nhiều rủi ro chi phí cho các hoạt động quản lý càng cao.
(3) Sunk Cost: Chi phí tồn đọng trước dự án. Ví dụ: hậu quả của dự án pilot (thí điểm) thất bại. Bất kể công ty có tận dụng được gì từ dự án pilot, chi phí này vẫn được ghi nhận.
(4) Learning Curve: Chi phí làm mẫu thử để doanh nghiệp hiểu rõ bài toán hoặc sử dụng công nghệ một cách hiệu quả hơn.
(5) Reserve: Chi phí dự phòng cho các rủi ro
Nguồn SME Hospital
Lý Luận Về Dự Án Và Quản Lý Dự Án Đầu Tư
Khái niệm.
Có nhiều cách định nghĩa dự án. Tuỳ theo mục đích mà nhấn mạnh một khía cạnh nào đó. Trên phương diện phát triển, có hai cách hiểu về dự án: cách hiểu “tĩnh” và cách hiểu “động”. Theo cách hiểu thứ nhất “tĩnh” thì dự án là hình tượng về một tình huống (một trạng thái) mà ta muốn đạt tới. Theo cách hiểu thứ hai “động” có thể định nghĩa dự án như sau:
Theo nghĩa chung nhất, dự án là một lĩnh vực hoạt động đặc thù, một nhiệm vụ cụ thể cần phải được thực hiện với phương pháp riêng, nguồn lực riêng và theo một kế hoạch tiến độ nhằm tạo ra một thực thể mới.
Như vậy theo định nghĩa này thì:
Dự án không chỉ là một ý định phác thảo mà có tính cụ thể và mục tiêu xác định.
Dự án 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 thể mới.
Trên phương diện quản lý, có thể định nghĩa dự án như sau:
Dự án là những nỗ lực có thời hạn nhằm tạo ra một sản phẩm hoặc dịch vụ duy nhất.
Định nghĩa này nhấn mạnh hai đặc tính:
Nỗ lực tạm thời (hay có thời hạn). Nghĩa là, mọi dự án đầu tư đều có điểm bắt đầu và điểm kết thúc xác định. Dự án kết thúc khi mục tiêu của dự án đã đạt được hoặc khi xác định rõ ràng mục tiêu của dự án không thể đạt được và dự án bị loại bỏ.
Sản phẩm hoặc dịch vụ duy nhất. Sản phẩm hoặc dịch vụ duy nhất là sản phẩm hoặc dịch vụ khác biệt so với những sản phẩm tương tự đã có hoặc dự án khác.
Dù định nghĩa khác nhau nhưng có thể rút ra một số đặc trưng cơ bản của khái niệm dự án như sau:
Dự án có mục đích, mục tiêu rõ ràng. Mỗi dự án thể hiện một hoặc một nhóm nhiệm vụ cần được thực hiện với một bộ kết quả xác định nhằm thoả mãn một nhu cầu nào đó. Dự án cũng là một hệ thống phức tạp nên cần được chia thành nhiều bộ phận khác nhau để thực hiện và quản lý nhưng phải đảm bảo các mục tiêu cơ bản về thời gian, chi phí và việc hoàn thành với chất lượng cao.
Dự án có chu kỳ phát triển riêng và thời gian tồn tại hữu hạn. Nghĩa là, giống như các thực thể sống, dự án cũng trải qua các giai đoạn: hình thành, phát triển, có thời điểm bắt đầu và kết thúc.
Sản phẩm của dự án mang tính chất đơn chiếc, độc đáo (mới lạ). Khác với quá trình sản xuất liên tục và gián đoạn, kết quả của dự án không phải là sản phẩm sản xuất hàng loạt, mà có tính khác biệt cao. Sản phẩm và dịch vụ do dự án đem lại là duy nhất. Lao động đòi hỏi kỹ năng chuyên môn cao, nhiệm vụ không lặp lại . . .
Môi trường hoạt động “va chạm“. Quan hệ giữa các dự án là quan hệ chia nhau cùng một nguồn lực khan hiếm của một tổ chức. Dự án “cạnh tranh” lẫn nhau và với các bộ phận chức năng khác về tiền vốn, nhân lực, thiết bị… Một số trường hợp, các thành viên quản lý dự án thường có hai thủ trưởng trong cùng một thời gian nên sẽ gặp khó khăn không biết thực hiện quyết định nào của cấp trên khi hai lệnh mâu thuẫn nhau.
Tính bất định và độ rủi ro cao. Hầu hết các dự án đòi hỏi lượng tiền vốn, vật tư và lao động rất lớn để thực hiện trong một khoảng thời gian nhất định. Mặt khác, thời gian đầu tư và vận hành kéo dài nên các dự án đầu tư phát triển thường có độ rủi ro cao.
Chu kỳ của dự án đầu tư.
Chu kỳ của hoạt động đầu tư là các giai đoạn mà một dự án phải trải qua bắt đầu từ khi dự án mới chỉ là ý đồ đến khi dự án được hoàn thành chấm dứt hoạt động.
Ta có thể minh hoạ chu kỳ của dự án theo sơ đồ sau đây:
Hình vẽ :Chu kì của dự án đầu tư
Chu kỳ một dự án đầu tư được thể hiện thông qua ba giai đoạn: Giai đoạn tiền đầu tư (Chuẩn bị đầu tư), giai đoạn đầu tư (Thực hiện đầu tư) và giai đoạn vận hành các kết quả đầu tư (Sản xuất kinh doanh). Mỗi giai đoạn lại được chia làm nhiều bước. Chúng ta có thể sơ đồ hoá như sau:
Tiền đầu tư
Đầu tư
Vận hành kết quả đầu tư
Nghiên cứu phát hiện các cơ hội đầu tư
Nghiên cứu tiền khả thi sơ bộ lựa chọn dự án.
Nghiên cứu khả thi ( Lập dự ánBCNCKT )
Đánh giá và quyết định (thẩm định dự án)
Đàm phán và kí kết các hợp đồng
Thiết kế và lập dự toánthi công xây lắp công trình
Thi công xây lắp công trình
Chạy thử và nghiệm thu sử dụng
Sử dụng chưa hết công suất
Sử dụng công suất ở mức độ cao nhất.
Công suất giảm dần và thanh lý.
Bảng 1.1. Các bước công việc của một dự án đầu tư.
Các bước công việc, các nội dung nghiên cứu ở các giai đoạn được tiến hành tuần tự nhưng không biệt lập mà đan xen gối đầu cho nhau, bổ sung cho nhau nhằm nâng cao dần mức độ chính xác của các kết quả nghiên cứu và tạo thuận lợi cho việc tiến hành nghiên cứu ở các bước kế tiếp.
Trên cơ sở chu kỳ một dự án đầu tư chúng ta có thể đưa ra một số nhận xét cơ bản sau đây:
Giai đoạn 3: vận hành các kết quả của giai đoạn thực hiện đầu tư (giai đoạn sản xuất kinh doanh dịch vụ) nhằm đạt được các mục tiêu của dự án. Nếu các kết quả do giai đoạn thực hiện đầu tư tạo ra đảm bảo tính đồng bộ, giá thành thấp, chất lượng tốt, đúng tiến độ, tại địa điểm thích hợp, với quy mô tối ưu thì hiệu quả trong hoạt động của các kết quả này và mục tiêu của dự án chỉ phụ thuộc trực tiếp vào quá trình tổ chức quản lý hoạt động các kết quả đầu tư. Làm tốt các công việc của giai đoạn chuẩn bị đầu tư và thực hiện đầu tư tạo thuận lợi cho quá trình tổ chức quản lý phát huy tác dụng của các kết quả đầu tư.
Thời gian hoạt động của dự án được xác định bởi thời gian vận hành các kết quả đầu tư.
Thời gian hoạt động của dự án bị phụ thuộc những nhân tố tác động đến chu kỳ sống của sản phẩm do dự án tạo ra, hiệu quả của quá trình vận hành dự án.. .
Nội dung chủ yếu của giai đoạn tiền đầu tư là việc xây dựng dự án đầu tư.
Khái niệm và tác dụng của quản lý dự án.
Khái niệm.
Phương pháp quản lý dự án lần đầu được áp dụng trong lĩnh vực quân sự Mỹ vào những năm 1950, đến nay nó nhanh chóng được ứng dụng rộng rãi vào các lĩnh vực kinh tế, quốc phòng và xã hội. Có hai lực lượng cơ bản thúc đẩy sự phát triển mạnh mẽ của phương pháp quản lý dự án là:
Nhu cầu ngày càng tăng những hàng hoá và dịch vụ sản xuất phức tạp, kỹ nghệ tinh vi, trong khi khách hàng ngày càng khó tính;
Kiến thức của con người (hiểu biết tự nhiên, xã hội, kinh tế, kỹ thuật) ngày càng tăng.
Quản lý dự án là quá trình lập kế hoạch, điều phối thời gian, nguồn lực và giám sát quá trình phát triển của dự án nhằm đảm bảo cho dự án hoàn thành đúng thời hạn, trong phạm vi ngân sách được duyệt và đạt được các yêu cầu đã định về kỹ thuật và chất lượng sản phẩm dịch vụ, bằng những phương pháp và điều kiện tốt nhất cho phép.
Quản lý dự án bao gồm 3 giai đoạn chủ yếu. Đó là việc lập kế hoạch, điều phối thực hiện mà nội dung chủ yếu là quản lý tiến độ thời gian, chi phí thực hiện và thực hiện giám sát các công việc dự án nhằm đạt được các mục tiêu xác định.
Lập kế hoạch. Đây là giai đoạn xây dựng mục tiêu, xác định những công việc cần được hoàn thành, nguồn lực cần thiết để thực hiện dự án và là quá trình phát triển một kế hoạch hành động theo trình tự logic mà có thể biểu diễn dưới dạng sơ đồ hệ thống.
Điều phối thực hiện dự án. Đây là quá trình phân phối nguồn lực bao gồm: tiền vốn, lao động, thiết bị và đặc biệt quan trọng là điều phối và quản lý tiến độ thời gian. Giai đoạn này chi tiết hoá thời hạn thực hiện cho từng công việc và toàn bộ dự án (khi nào bắt đầu, khi nào kết thúc).
Các giai đoạn của quá trình quản lý dự án hình thành một chu trình năng động từ việc lập kế hoạch đến điều phối thực hiện và giám sát, sau đó phản hồi cho việc tái lập kế hoạch dự án như trình bày trong hình 1.2
C= f ( P, T, S ).
Trong đó :
C : Chi phí.
P : Hoàn thành công việc ( kết quả )
T : Yếu tố thời gian.
S : Phạm vi dự án.
Phương trình cho thấy, chi phí là một hàm của các yếu tố: hoàn thành công việc, thời gian và phạm vi dự án. Nói chung chi phí của dự án tăng lên nếu chất lượng hoàn thiện công việc tốt hơn, thời gian kéo dài thêm và phạm vi dự án được mở rộng.
Ba yếu tố cơ bản: Thời gian, chi phí và hoàn thiện công việc là những mục tiêu cơ bản của quản lý dự án và giữa chúng lại có quan hệ chặt chẽ với nhau. Không đơn thuần chỉ là hoàn thành kết quả mà thời gian cũng như chi phí để đạt kết quả đó đều là những yếu tố không kém phần quan trọng. Hình 1.3 trình bày mối quan hệ giữa 3 mục tiêu cơ bản của quản lý dự án. Tuy mối quan hệ giữa 3 mục tiêu có thể khác nhau giữa các dự án, giữa các thời kì đối với cùng một dự án, nhưng nói chung đạt được kết quả tốt đối với mục tiêu này phải “hi sinh” một hoặc hai mục tiêu kia. Do vậy, trong quá trình quản lý dự án các nhà quản lý hi vọng đạt được sự kết hợp tốt nhất giữa các mục tiêu quản lý dự án.
Tác dụng của quản lý dự án.
Mặc dù phương pháp quản lý dự án đòi hỏi sự nỗ lực, tính tập thể và yêu cầu hợp tác nhưng tác dụng của nó rất lớn. Phương pháp quản lý dự án có những tác dụng chủ yếu sau đây:
Liên kết tất cả các hoạt động, công việc của dự án.
Tạo điều kiện thuận lợi cho việc liên hệ thường xuyên, gắn bó giữa nhóm quản lý dự án với khách hàng và nhà cung cấp đầu vào cho dự án.
Tăng cường sự hợp tác giữa các thành viên và chỉ rõ trách nhiệm của các thành viên tham gia dự án.
Tạo ra sản phẩm và dịch vụ có chất lượng cao hơn.
Các Khái Niệm Cơ Bản Dự Án Phần Mềm
Published on
các khái niệm cơ bản của dự án phần mề
1. 1 BÀI 1 CÁC KHÁI NIỆM CƠ BẢN CỦA DỰ ÁN PHẦN MỀM ThS. Thạc Bình Cường
2. 2 TÌNH HUỐNG DẪN NHẬP * Chi tiêu cho Công nghệ thông tin (CNTT) thế giới tiếp tục tăng, và Forrester Research dự đoán rằng chi tiêu cho CNTT của Mỹ sẽ tăng 5.7% trong năm 2005, lên đến $795 tỷ. * Trong năm 2003, trung bình quản trị dự án cấp cao ở Mỹ thu nhập khoảng $90,000 một năm, và Giám đốc Trung tâm Quản trị dự án (PMO) kiếm nhiều hơn Trưởng phòng Công nghệ (CIO) ($118,633 so với $103,925). * Quản trị dự án CNTT giống như một công trường. Mọi việc đều rất ngổn ngang bừa bãi cần một nhà quản lý để đưa vào trật tự. Vai trò của quản trị dự án trong việc phát triển một dự án CNTT?
3. 3 MỤC TIÊU Trình bày được các khái niệm về các vấn đề dự án và quản trị dự án. Trình bày được các bước quá trình phát triển dự án CNTT. Liệt kê được các kỹ thuật và mô hình kinh tế, nền kinh tế khi áp dụng các mô hình quản trị dự án.
4. 4 NỘI DUNG 1 Phát triển phần mềm truyền thống2 Sự tiến hóa nền kinh tế phần mềm3 Cải tiến kinh tế phần mềm4 Giới thiệu chung về dự án
5. 5 1. GIỚI THIỆU CHUNG VỀ DỰ ÁN * Dự án là gì? * Quản lý dự án là gì? * Nói về người quản lý dự án.
6. 6 * Dự án là một tập hợp các công việc, được thực hiện bởi một tập thể, nhằm đạt được một kết quả dự kiến, trong một thời gian dự kiến, với một kinh phí dự kiến. Phải dự kiến nguồn nhân lực; Phải có ngày bắt đầu, ngày kết thúc; Phải có kinh phí thực hiện công việc; Phải mô tả được rõ ràng kết quả (output) của công việc. * Dự án kết thúc khi: Hoàn thành mục tiêu đề ra và nghiệm thu kết quả (kết thúc tốt đẹp) trước thời hạn; Hết kinh phí trước thời hạn (kết thúc thất bại); Đến ngày cuối cùng (nếu tiếp tục nữa cũng không còn ý nghĩa). * Dự án thất bại khi: Không đáp ứng các mục tiêu ban đầu; Không đáp ứng được thời hạn; Vượt quá ngân sách cho phép (20 – 30%). 1.1. DỰ ÁN LÀ GÌ?
7. 7 Không rõ mục tiêu: 18% Không quen thuộc với Phạm vi và sự phức Của dự án: 17% Thiếu thông tin: 21% Quản lý dự án không tốt: 32% Lý do khác: 12% Tại sao dự án thất bại? * Để tránh việc thất bại dự án 0 10 20 30 40 50 60 70 80 90 % Respondents Cải tổ việc quản lý dự án Nghiên cứu khả thi Tăng số các thành viên tham gia Tăng các phương sách từ bên ngoài Không phải những lý do trên 1.1. DỰ ÁN LÀ GÌ? (tiếp theo)
8. 8 * Quản lý dự án (QLDA) là việc áp dụng các công cụ, kiến thức và kỹ thuật nhằm định nghĩa, lập kế hoạch, tiến hành triển khai, tổ chức, kiểm soát và kết thúc dự án. * Một dự án được quản lý tốt, tức là khi kết thúc phải thoả mãn được chủ đầu tư về các mặt: thời hạn, chi phí và chất lượng kết quả. * Các nguyên lý chung của phương pháp luận QLDA: Linh hoạt; Hướng kết quả, không hướng nhiệm vụ (nhằm thoả mãn các thượng đế – khách hàng); Huy động sự tham gia của mọi người (tính chất dân chủ); Làm rõ trách nhiệm (chữ ký); Phân cấp có mức độ (không nên chia thành quá nhiều mức); Tài liệu cô đọng và có chất lượng (quá nhiều tài liệu tức là có quá ít thông tin); Kết quả quan trọng hơn công cụ hay kĩ thuật (thực dụng); Tạo ra các độ đo tốt (để có đánh giá đúng); Suy nghĩ một cách nhìn xa trông rộng; Cải tiến liên tục (kế hoạch không xơ cứng). 1.2. QUẢN LÝ DỰ ÁN LÀ GÌ?
9. 9 Thực hiện dự án Nguồn Các đầu vào khác Các yêu cầu Các kết quả bàn giao của dự án Các đầu ra khác Quản lý dự án Những yêu cầu của người quản lý * Quản lý và thực hiện dự án: 1.2. QUẢN LÝ DỰ ÁN LÀ GÌ? (tiếp theo)
11. 11 * Lập kế hoạch quản lý bao gồm: Xác định ranh giới của dự án: Đội lập kế hoạch, văn bản/thông tin hiện có; Xây dựng các lựa chọn tiếp cận của dự án: Chiến lược thực hiện và các phương pháp luận tổ chức dự án; Xây dựng các ước tính ban đầu; Xây dựng cơ sở hạ tầng nguồn: Môi trường làm việc, MOC; Xây dựng cơ sở hạ tầng của dự án: Quản lý cấu hình, chất lượng, rủi ro, sự kiện, sự thay đổi, kiểm soát dự án, lập báo cáo và lập kế hoạch; Lập thành văn bản về kế hoạch quản lý. * Các phong cách QLDA: Sau khi vạch kế hoạch rồi, phó mặc cho người khác thực hiện, không quan tâm theo dõi. Khi có chuyện gì xảy ra mới nghĩ cách đối phó; Một đề tài nghiên cứu khoa học: Không có sáng kiến mới, cứ quanh quẩn với các phương pháp cũ, công nghệ cũ; Thiết lập hướng làm việc chung; Không lo lắng đến thời hạn giao nộp sản phẩm, đến khi dự án sắp hết hạn thì mới lo huy động thật đông người làm cho xong; Quản lý chủ động, tích cực. Suốt quá trình thực hiện dự án không bị động về kinh phí, nhân lực và tiến độ đảm bảo (lý tưởng). 1.2. QUẢN LÝ DỰ ÁN LÀ GÌ? (tiếp theo)
12. 12 * QLDA thụ động có những đặc tính: QLDA luôn đứng sau các mục tiêu của dự án; Hấp tấp, bị kích động, tương lai ngắn hạn; Khi làm quyết định, chỉ nghĩ đến các khó khăn trở ngại tạm thời, trước mắt, không nghĩ đến liệu rằng đó có phải là một bước đi đúng hay không; Không kiểm soát được tình thế, nhiều khi phải thay đổi kế hoạch và tổ chức. * Hậu quả của QLDA thụ động: Kết quả thu được không ổn định; Tinh thần làm việc không cởi mở, hợp tác; Năng suất thấp, công việc không chạy; Rối loạn trong điều hành; Không sử dụng hiệu quả tài nguyên; Người quản lý dự án bị dự án quản lý; Hồ sơ dự án kém chất lượng; Chậm tiến độ, tiêu vượt quá kinh phí; Chất lượng dự án không đảm bảo. 1.2. QUẢN LÝ DỰ ÁN LÀ GÌ? (tiếp theo)
13. 13 * Các thuộc tính của dự án IT: Kết quả bàn giao có thể là ít hữu hình; Phạm vi có thể khó kiểm soát; Kỹ năng, kinh nghiệm, thái độ và kỳ vọng trái ngược nhau; Có thể bất đồng về mục tiêu kinh doanh; Thay đổi quan trọng về tổ chức; Các yêu cầu, phạm vi, và lợi nhuận chính xác có thể rất khó xác định; Sự thay đổi nhanh chóng về công nghệ. * Lưu ý: Quản lý dự án thành công chính là vấn đề về con người; Khám phá các nguồn hỗ trợ và ngăn trở; Nhìn bản chất, không tin hiện tượng; Người khác có cách nhìn khác nhau; Thiết lập kế hoạch chỉnh sửa dễ dàng; Dám đối mặt với sự kiện; Sử dụng quản trị để hỗ trợ cho các mục đích của dự án; Thời gian mục tiêu đối với từng nhiệm vụ không được giống như đã nêu trong kế hoạch; Đọc lại phạm vi và các mục tiêu của dự án mỗi tuần một lần; Không ngạc nhiên. 1.2. QUẢN LÝ DỰ ÁN LÀ GÌ? (tiếp theo)
16. 16 * Trách nhiệm của QLDA: Trách nhiệm chính Chi tiết Nêu ra những điểm bao quát chung Về công việc, cấu trúc phân việc, lịch biểu và ngân sách Trao đổi với các đồng nghiệp Bao gồm các báo cáo, biểu mẫu, bản tin, hội họp và thủ tục làm việc. Ý tưởng là trao đổi cởi mở và trung thực trên cơ sở đều đặn Động viên, khuấy động tinh thần làm việc Bao gồm khích lệ, phân việc, mời tham gia và ủy quyền Định hướng công việc Bao gồm điều phối, theo dõi, thu thập hiện trạng và đánh giá hiện trạng Hỗ trợ cho mọi người 1.3. NÓI VỀ NGƯỜI QUẢN LÝ DỰ ÁN (tiếp theo)
18. 18 * Xây dựng tập thể vững mạnh: Bổ nhiệm người phụ trách; Phân bổ trách nhiệm; Khuyến khích tinh thần đồng đội; Làm phát sinh lòng nhiệt tình; Thành lập sự thống nhất chỉ huy; Quản lý trách nhiệm; Cung cấp môi trường làm việc tốt; Trao đổi với đồng nghiệp. * Sức ép với QLDA: Kinh tế, marketing, các chuẩn về công nghệ, mục tiêu, uy tín danh dự, nguồn nhân lực, nhân sự, thủ tục hành chính, quan hệ với người đặt hàng, môi trường kinh doanh. * Phẩm chất QLDA: Trung thực, toàn tâm toàn ý, khả năng diễn đạt, khả năng chia sẻ thông cảm với người khác, nhất quán, kiên nhẫn, tính kiên quyết, khách quan, tầm nhìn xa trông rộng, … 1.3. NÓI VỀ NGƯỜI QUẢN LÝ DỰ ÁN (tiếp theo)
19. 19 2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG * Sơ lược về quá trình – dự án truyền thống: Dạng Văn bản không theo thể thức Sơ đồ luồng Chương trình nguồn Vạch ranh giới cấu hình Hoạt động Yêu cầu phân tích Thiết kế chương trình Lập trình và kiểm thử Tích hợp theo tỷ lệ mở rộng và kiểm sửa Sản phẩm Tài liệu Tài liệu Chương trình Vạch ranh giới yếu ớt Các hoạt động kế tiếp: Yêu cầu – thiết kế – lập trình – tích hợp – kiểm sửa Bắt đầu tích hợp Điểm gián đoạn thiết kế chậm Ngày đạt mục tiêu gốc Lịch trình dự án Tiếnđộpháttriển (%lậptrình) 100%
20. 20 * Các kinh nghiệm của quá trình phát triển phần mềm: Quá trình phát triển là không dự đoán được rất cao. Chỉ có 10% dự án là đúng hạn và ngân sách; Các nguyên tắc quản lý là khó phân biệt được thành công hay thất bại như các tiến bộ công nghệ; Các mức vụn vặt và làm lại phần mềm là xác định trong tiến trình tăng trưởng. * Hai bước cơ bản để xây một chương trình: Phân tích và lập trình sẽ bao gồm các công việc sáng tạo mà nó đóng góp trực tiếp tới tính hữu dụng của sản phẩm. Phân tích Lập trình 2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
21. 21 Yêu cầu hệ thống Yêu cầu phần mềm Phân tích Thiết kế chương Lập trình Kiểm sửa Thực hiện * Mô hình thác nước cổ điển: 2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
22. 22 * Chi phí: STT Hoạt động Chi phí (%) 1 Quản lý 5 2 Xác định yêu cầu 5 3 Thiết kế 10 4 Mã hóa và kiểm sửa 30 5 Tích hợp và kiểm sửa 40 6 Triển khai 5 7 Môi trường 5 2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
23. 23 2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo) * Sơ lược rủi ro: Kiểm sửaSơ lược rủi roSơ lược rủi roYêu cầu Chiềuhướngrủirocủadựán Thấp Cao Định hướng tập trung chu kỳ giải trình rủi ro Điều khiển chu kỳ quản lý rủi ro Chu kỳ khai thác rủi ro Chu kỳ chi tiết hóa rủi ro Vòng đời dự án
24. 24 * Lập tài liệu và điều khiển dự án: Nhà dự thầu (contractor) chuẩn bị một tài liệu hợp đồng để phân phát cho khách hàng duyệt mà nó bảo đảm nắm bắt được các mẫu phát triển qua các bước trung gian; Khách hàng có góp ý trở lại (trong vòng 15 đến 30 ngày); Nhà thầu sau khi xem xét lại các ý kiến của khách hàng và nộp lại bản cuối cùng để duyệt (cũng trong vòng 15 tới 30 ngày). * Các kinh nghiệm cụ thể: Các kinh nghiệm ban đầu thường thấy thông qua thiết kế trên giấy và qua đó thường rất tóm tắt. Vi phạm về sự mã hoá muộn trong vòng đời dự án; Việc tích hợp hệ thống gây ra ác mộng về các vấn đề thể hiện không nhìn thấy trước và sự nhập nhằng về các giao diện giữa chúng; Thờì gian và tài chính là các áp lực cho hệ thống làm việc; Một sản phẩm không tối ưu nhưng đã chót làm và không có thời gian thiết kế lại; Một sản phẩm rất yếu ớt, khó bảo trì và phân phối rất muộn mằn. 2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
25. 25 * Tóm tắt các vấn đề về thực tiễn: Việc tích hợp kéo dài và phá vỡ thiết kế sau này; Sự giải quyết rủi ro quá muộn; Có yêu cầu phân rã theo chức năng; Mối quan hệ giữa các cổ đông đối nghịch nhau; Chỉ tập trung vào tài liệu và các cuộc họp rà soát lại. * Năm cải tiến cần thiết đối với mô hình thác nước: Hoàn thiện thiết kế chương trình trước khi bắt đầu phân tích và mã hóa (xây dựng) chương trình; Bảo trì hiện hành và hoàn thiện tài liệu; Làm các nhiệm vụ hai lần nếu có thế; Lập kế hoạch, điều khiển và theo dõi kiểm tra; Trao đổi sâu sát và thu hút khách hàng. 2. PHÁT TRIỂN PHẦN MỀM TRUYỀN THỐNG (tiếp theo)
27. 27 * Nền kinh tế phần mềm; * Sự ước lượng chi phí phần mềm thực tế. 3. SỰ TIẾN HÓA NỀN KINH TẾ PHẦN MỀM
28. 28 * Mô hình chi phí phần mềm bao gồm 5 tham số: Kích cỡ của sản phẩm cuối thông thường số dòng chương trình nguồn. Tiến trình xử lý để đưa ra sản phẩm cuối. Khả năng của nhân sự. Môi trường – Các công cụ và kỹ thuật. Chất lượng yêu cầu của sản phẩm cuối. * Công thức lượng giá chi phí: Chi phí = (Nhân sự)(Môi trường)(Chất lượng)(Kích thướctiến trình). * Ba giai đoạn phát triển phần mềm được thể hiện ở hình vẽ sau: 3.1. NỀN KINH TẾ PHẦN MỀM
29. 29 3.1. NỀN KINH TẾ PHẦN MỀM (tiếp theo) – 1960s-1970s – Mô hình thác nước – Thiết kế chức năng – Tỷ lệ phi kinh tế – 1980s-1990s – Cải tiến tiến trình – Dựa vào bao bọc – Tỷ lệ phi kinh tế – 2000 và sau đó – Sự phát triển lặp đi lặp lại – Thành phần – Kết quả đầu tư ROI phần mềm Môi trường/Công cụ Tập quán Môi trường/Công cụ Không lỗi thời, riêng rẽ Môi trường/Công cụ Không lỗi thời, tích hợp Kích thước: 100% tập quán Kích thước: 30% dựa vào thành phần cơ bản 70% tập quán Kích thước: 70% dựa vào thành phần cơ bản 30% tập quán Tiến trình: Theo trường hợp đặc biệt Tiến trình: Có thể lặp lại Tiến trình: Quản lý/phân phối Kích thước phần mềm Sự phù hợp môi trường, kích thước và các công nghệ tiến trình Hiệu năng của dự án điển hình Khả năng dự đoán tồi Luôn luôn: Vượt quá ngân sách Vượt quá lịch trình Không có khả năng dự đoán Không thường xuyên: Đúng ngân sách Đúng lịch trình Có khả năng dự đoán Thường xuyên: Đúng ngân sách Đúng lịch trình Chiphí
30. 30 * Đánh giá các điểm chức năng: Sự biến đổi chương trình nguồn làm cơ sở cho việc đánh giá; Sử dụng các điểm chức năng “Function Points” để đánh giá chi phí: Các dữ liệu đầu vào của người sử dụng Các dữ liệu đầu ra Nhóm các dữ liệu cục bộ Giao diện dữ liệu ngoài Các dạng câu hỏi ngoài * Độ chính xác: Toàn bộ độ chính xác của việc đánh giá chi phí phần mềm hiện tại được mô tả như là “… 20 % sự chính xác , 70 % về thời gian…” * Tiến trình chi phí nổi bật được mô tả như sau: Nhà quản lý phần mềm, nhà quản lý kiến trúc phần mềm, nhà quản lý phát triển phần mềm, nhà quản lý định giá phần mềm Mô hình chi phí Chi phí ước lượng “Đây là sự biện hộ nào đó về giá trị đó” Các rủi ro, sự lựa chọn, trả giá, thay thế “Dự án này phải có giá trị là $X để chiến thắng trong nền thương mại này” 3.2. SỰ ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM THỰC TẾ
31. 31 * Các thuộc tính của đánh giá tốt: Việc đánh giá phải được nhận thức và hỗ trợ bởi mọi các thành viên tham gia dự án; Cán bộ quản lý dự án, đội kiến trúc, đội phát triển và đội kiểm thử trong từng công việc của họ; Việc đánh giá phải được chấp nhận bởi tham vọng của toàn bộ các cổ đông nhưng cần hiện thực; Việc đánh giá dựa vào mô hình xác định chuẩn với nền tảng tin cậy; Việc đánh giá dựa trên các kinh nghiệm của các dự án trước; Việc đánh giá được chi tiết cụ thể và đặc biệt quan tâm hiểu biết tới lĩnh vực rủi ro. 3.2. SỰ ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM THỰC TẾ (tiếp theo)
32. 32 * Năm tiêu chí cải tiến nền kinh tế phần mềm: Giảm kích cỡ của phần mềm; Cải tiến tiến trình phát triển phần mềm; Sử dụng các nhân sự có kỹ năng và nhóm đội tốt hơn; Sử dụng môi trường, công cụ phát triển phần mềm tốt hơn; Thoả hiệp, cân nhắc, hoặc thúc đẩy các mặt còn yếu dựa vào ngưỡng chất lượng. * Giảm kích thước phần mềm: Lựa chọn ngôn ngữ lập trình; Áp dụng các phương pháp hướng đối tượng và mô hình hoá trực quan; Sử dụng lại phần mềm; Các thành phần phần mềm thương mại hoá. * So sánh các điểm chức năng qua ví dụ ngôn ngữ: 1,000,000 dòng lệnh – ngôn ngữ Assembly; 400,000 dòng lệnh – ngôn ngữ C; 220,000 dòng lệnh – ngôn ngữ Ada 83; 175,000 dòng lệnh – ngôn ngữ Ada 95 hoặc C++. 4. CẢI TIẾN NỀN KINH TẾ PHẦN MỀM
33. 33 * Phương pháp hướng đối tượng và mô hình trực quan: Việc nắm bắt tính trừu tượng hoá của phần mềm dẫn đến giao tiếp và làm việc theo đội nhóm tốt hơn; Việc tích hợp liên tục thường xuyên dẫn đến nhận biết các rủi ro sớm và hạn chế chi phí chỉnh sửa; Kiến trúc hướng đối tượng đảm bảo phân tách các thành phần của hệ thống và tạo bức tường ngăn cản các sự cố lan truyền nhằm giảm chi phí; Mô hình hướng đối tượng và trực quan tạo ra kiến trúc vững chắc nhằm tạo ra sản phẩm sạch và giảm chi phí. * Sử dụng lại phầm mềm: Kiến trúc phần mềm chung; Môi trường phát triển; Các hệ điều hành; Hệ thống quản trị CSDL; Các sản phẩm trên mạng; Các ứng dụng văn phòng. 4. CẢI TIẾN NỀN KINH TẾ PHẦN MỀM (tiếp theo)
34. 34 * Chi phí sử dụng lại và lập lịch: 1 giải pháp dự án: $N và M tháng 2 giải pháp dự án: trên 50% chi phí và 100% thời gian 5 giải pháp dự án: trên 125% chi phí và trên 150% thời gian Giải pháp nhiều dự án: Thao tác với giá trị cao tên đơn vị đầu tư, các sản phẩm thương mại điển hình Số dự án sử dụng thành phần có thể tái sử dụng được Pháttriểnchiphívàlậplịchtàinguyên 4. CẢI TIẾN NỀN KINH TẾ PHẦN MỀM (tiếp theo)
35. 35 CÂU HỎI THẢO LUẬN Xu hướng nền kinh tế phần mềm trong những năm gần đây như thế nào?
36. 36 TÓM LƯỢC CUỐI BÀI * Phát triển phần mềm thông thường ngày nay không đáng tin cậy và lạc hậu. * Mô hình thác nước cần cải tiến để làm việc thỏa đáng. Thực tiễn thông thường đảm bảo các tiêu chuẩn cho việc cải tiến trong tương lai và thay đổi các phương pháp phát triển phần mềm. * Đánh giá phần mềm phải dựa vào việc phân tích cụ thể và được hỗ trợ bởi các thành viên. * Cải tiến nền kinh tế phần mềm phải dựa vào việc giảm kích thước, sử dụng các thành viên có kỹ năng và cân đối các chỉ tiêu phần mềm tương lai.
Cập nhật thông tin chi tiết về Quản Lý Chất Lượng Dự Án Phần Mềm – Apmp trên website 2atlantic.edu.vn. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung để bạn nhận được thông tin nhanh chóng và chính xác nhất. Chúc bạn một ngày tốt lành!