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 mới nhất trên website Tvzoneplus.com. 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.
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
Quản Lý Dự Án Phần Mềm Là Gì?
Mục tiêu của bài viết
Hiểu vai trò của quản lý dự án phần mềm.
Sử dụng một số công cụ, môi trường hỗ trợ quản lý dự án.
Chương 1: Giới thiệu
Vài số liệu thống kê về dự án
Mỗi năm Mỹ chi 2.3 nghìn tỉ USD vào các dự án.
Toàn thế giới chi gần 10 nghìn tỉ USD cho tất cả các loại dự án.
Hơn 16 triệu người xem quản trị dự án là nghề của mình.
Hơn nửa triệu dự án phát triển các ứng dụng CNTT được khởi động trong năm 2001, so với 300,000 dự án năm 2000.
Lý do phải nghiên cứu Quản lý dự án
Các dự án Công nghệ thông tin có thành tích kém:
Nghiên cứu của CHAOS năm 1994 – 2009:
1994 1996 1998 2000 2002 2004 2006 2009Thành công
16%
27%
26%
28%
34%
29%
35%
32%
Khó khăn
53%
33%
46%
49%
51%
53%
46%
44%
Thất bại
31%
40%
28%
23%
15%
18%
19%
24%
Các dự án công nghệ thông tin khởi đầu thuận lợi.
Các dự án công nghệ thông tin ngày càng gia tăng.
Dự án thất bại
Bị hủy:
33% các dự án bị hủy (vượt thời gian hay chi phí).
Nghiên cứu của Standish Group (CHAOS) năm 1995 trên 31% bị hủy, tốn kém 81 tỉ USD tại Mỹ.
Quá tải: nhu cầu các dự án công nghệ thông tin ngày càng tăng.
Không hiệu quả: nhiều sản phẩm phần mềm không bao giờ được sử dụng.
Dự án thành công
Đúng thời hạn, trong phạm vi kinh phí cho phép: vượt quá khoảng 10% → 20% được coi là chấp nhận được.
Nhóm thực hiện không cảm thấy bị kiểm soát quá mức
Khách hàng thỏa mãn:
Sản phẩm dự án giải quyết được vấn đề đặt ra.
Được tham gia vào quá trình quản lý dự án.
Người quản lý hài lòng với tiến độ.
Khái niệm dự án (project)
Dự án là “một nỗ lực tạm thời được cam kết để tạo ra một sản phẩm hoặc dịch vụ”. Dự án là một chuỗi các công việc (nhiệm vụ, hoạt động) được thực hiện nhằm đạt được mục tiêu đề ra với 3 ràng buộc: phạm vi, thời gian và chi phí. Dự án được kết thúc khi nó đạt được các mục tiêu đề ra hoặc nó bị chấm dứt (hết hạn, hết kinh phí). Dự án có thể lớn hoặc nhỏ và nó cần một khoảng thời gian để hoàn thành.
Các đặc trưng của một dự án
Có một mục đích duy nhất.
Là tạm thời.
Được thực hiện dưới sự hợp tác của nhiều người.
Cần nguồn lực từ nhiều lãnh vực khác nhau.
Rủi ro là tất yếu.
Dễ có xung đột.
Ví dụ về dự án
Dự án khác với hoạt động nghiệp vụ
Các loại dự án
Dự án hợp đồng.
Dự án nghiên cứu phát triển.
Dự án xây dựng.
Dự án hệ thống thông tin.
Dự án phần mềm.
Dự án đào tạo quản lý.
Dự án bảo trì.
Các dự án khác…
Các đặc trưng của phần mềm
Phần mềm được phát triển, nó không được chế tạo theo nghĩa cổ điển.
Phần mềm không hư hỏng nhưng thoái hóa theo thời gian.
Phần lớn phần mềm được xây dựng theo đơn đặt hàng.
Sự phức tạp và tính thay đổi là bản chất của phần mềm.
Ngày nay phần mềm được phát triển theo nhóm.
Thuận lợi của một dự án phần mềm
Dễ sữa đổi hơn so sẩn phẩn vật chất khác.
Các pha của vòng đời là rõ ràng.
Có thể có nhiều giải pháp cho 1 yêu cầu.
Định hình sản phẩm không cứng nhắc.
Công cụ trợ giúp ngày càng mạnh.
Cho phép vận dụng nhiều giải pháp: công nghệ, quản lý,… trong dự án phần mềm
Quản lý dự án
Quản lý dự án là vận dụng các kiến thức, kỹ năng, công cụ và kỹ thuật vào các hoạt động của dự án nhằm đạt được mục tiêu của dự án.
Quản lý dự án là các quá trình lập kế hoạch thực hiện, quá trình tổ chức, điều hành các công việc và tài nguyên để hoàn thành mục tiêu đề ra mà vẫn tôn trọng các ràng buộc về thời gian, chí phí và tài nguyên.
Những mặt chung của quản lý dự án:
Hoạt động: lập kế hoạch, triển khai, theo dõi, giám sát, đánh giá & điều chỉnh kế hoạch.
Nội dung: quản lý công việc, quản lý tiến độ, quản lý tài chính, quản lý nguồn lực, quản lý chất lượng, quản lý rủi ro.
Quản lý dự án phần mềm
Dự án phần mềm:
Sản phẩn có thể là sưu liệu hoặc phần mềm.
Dự án phần mềm luôn gắn với giải pháp của bài toán
Quản lý dự án phần mềm là qui trình bao trùm lên tất cả các hoạt động của công nghệ phần mềm:
Lập kế hoạch.
Tổ chức theo dõi kế hoạch.
Kiểm tra và điều chỉnh kế hoạch.
Mục đích của quản lý dự án phần mềm: đảm bảo cho dự án thành công.
Tài liệu tham khảo
Nguyễn Văn Hòa và Hồ Nhã Phong, 2016, Giáo trình Quản lý dự án phần mềm, NXB ĐH Cần Thơ.
Kathy Schawalbe, 2011, Information technology project management, Revised 6e, Course Technology.
Günther Ruhe and Claes Wohlin, 2014, Software project management in a changing world, Springer.
Joseph Philips, 2010, IT project management: On track from start to finish, third edition, Mc Graw Hill.
Các nội dung dự kiến tiếp theo
Vai trò, trách nhiệm của người quản lý dự án.
Các kỹ năng của người quản lý dự án.
09 lĩnh vực trong quản lý dự án.
Bốn yếu tố trong quản lý dự án:
Con người (people).
Quá trình thực hiện (process).
Sản phẩm (product).
Kỹ thuật (technology).
Các hoạt động quản lý dự án phần mềm.
Các giai đoạn của dự án phần mềm.
Các công cụ và kỹ thuật quản lý dự án phần mềm
{{userFollowed ? ‘Following’ : ‘Follow’}}
Quản Lý Dự Án Phần Mềm: Mô Hình, Quy Trình Và Báo Cáo Chi Tiết
Quản lý dự án phần mềm là gì và cách thức triển khai ra sao để đạt được hiệu quả tối ưu trong các hoạt động của doanh nghiệp? Tất cả sẽ được giải đáp trong bài viết lần này.
1. Quản lý dự án phần mềm là gì
Quản lý dự án phần mềm là khái niệm dùng để chỉ hoạt động quản lý dự án dành riêng cho việc lập kế hoạch, lập lịch, phân bổ tài nguyên, thực hiện, theo dõi và phân phối các dự án phần mềm và web.
Cùng với sự phát triển vượt bậc của công nghệ thông tin, những xu hướng mới ra đời ảnh hưởng mạnh mẽ đến phong cách sinh hoạt và lối sống của con người, đặc biệt là thói quen mua hàng trực tuyến dẫn tới các phần mềm bán hàng ra đời. Sau khi đã ký hợp đồng kinh tế, việc tiếp theo của cả hai bên khách hàng và nhà cung cấp là quản lý dự án sao cho có hiệu quả nhất. Hoạt động quản lý dự án phần mềm bán hàng đang ngày càng phát triển và hoàn thiện hơn để đáp ứng nhu cầu của các doanh nghiệp.
2. Báo cáo quản lý dự án phần mềm
Báo cáo quản lý dự án phần mềm là một bản tóm tắt tổng quan về tình trạng hiện tại của dự án phần mềm. Đây là bản trình bày chính thức về tình hình của một dự án tại một thời điểm nhất định. (Biểu mẫu và chi tiết chính xác có thể khác nhau tùy thuộc vào yêu cầu của công ty và văn phòng quản lý dự án). Tùy thuộc vào quy mô và độ phức tạp của dự án, báo cáo quản lý dự án có thể được yêu cầu hàng tuần hoặc hàng tháng.
Một số thông tin cần thiết trong bản báo cáo:
Tên dự án
Tên người quản lý dự án
Ngày bắt đầu của dự án
Ngày kết thúc dự kiến
Tên khách hàng và thông tin
Ngày phát hành báo cáo
Các số liệu chính về dự án
Lập kế hoạch tiến độ so với kế hoạch. Dự án vượt trước hay chậm tiến độ?
Chi phí hiện tại so với ngân sách.
Phạm vi hiện tại so với kế hoạch. Phạm vi có thay đổi kể từ khi dự án bắt đầu không?
Lập kế hoạch so với nguồn cung ứng thực tế. Có bất kỳ tài nguyên nào bị thiếu hoặc phân bổ tổng thể không?
Tổng quan về rủi ro. Có rủi ro cao nào cần được quản lý không?
Kết quả chất lượng hiện tại. Kiểm tra chất lượng đã được thực hiện? Có vấn đề gì không?
3. Quy trình quản lý dự án phần mềm
Quy trình quản lý dự án phần mềm là quy trình vận dụng những kiến thức, kỹ năng và kỹ thuật công nghệ vào hoạt động của dự án để đạt được mục tiêu của dự án đặt ra. Những ứng dụng này được đưa vào phần mềm theo một tiêu chuẩn hóa của quản lý dự án theo tiêu chuẩn PMI.
Để đảm bảo dự án thành công, đội ngũ phải đảm bảo:
Lựa chọn quy trình phù hợp để đạt được mục tiêu của dự án
Cân bằng được các yêu cầu (nhân tố) cạnh tranh trong dự án như: phạm vi công việc, ngân sách, tiến độ, chất lượng, rủi ro, thay đổi. Tùy theo quy mô của từng dự án mà các mỗi giai đoạn lại có thể gồm những quy trình nhỏ hơn.
Ngoài các lợi ích chiến lược nêu trên phần mềm còn cung cấp đầy đủ các tính năng hệ thống. Việc bảo mật được tiến hành một cách tuyệt đối nghiêm ngặt. Việc phân quyền được cụ thể đến từng vai trò của người sử dụng.
1. Khởi tạo dự án (Initiating): Giai đoạn này thực hiện việc định nghĩa một dự án mới hoặc một phát sinh (hoặc trộn lẫn) mới của một dự án có sẵn như: Xác định yêu cầu của dự án, mức độ ưu tiên của dự án, phân tích các yêu cầu đầu tư, phân công trách nhiệm cho các bộ phận triển khai.
2. Lập kế hoạch dự án (Planning): Giai đoạn này yêu cầu thiết lập phạm vi công viêc của dự án, điều chỉnh lại mục tiêu và xác định đường đi tới mục tiêu đó.
3. Triển khai (Executing): Giai đoạn này thực hiện hoàn thành các công việc được xác định trong phần lập kế hoạch để đảm bảo các yêu cầu của dự án.
4. Giám sát và kiểm soát (Monitoring & Control): Giai đoạn này yêu cầu việc theo dõi, rà soát và điều chỉnh lại tiến độ và khả năng thực hiện của dự án. Theo dõi các rủi ro, thay đổi, phát sinh trong quá trình thực hiện và có những đề xuất điều chỉnh kịp thời.
5. Kết thúc (Closing): Giai đoạn này thực hiện để kết thúc tất cả các hoạt động của dự án để chính thức đóng lại dự án.
Bên cạnh các mô hình quản lý dự án phần mềm, quản lý dự án công nghệ thông tin (CNTT) cũng là một hoạt động vô cùng quan trọng đối với doanh nghiệp. Quản lý dự án CNTT là quá trình quản lý kế hoạch, tổ chức và trách nhiệm giải trình để đạt được các mục tiêu công nghệ thông tin. Vì phạm vi tiếp cận của CNTT trải dài trên hầu hết các doanh nghiệp hoặc doanh nghiệp, phạm vi của các dự án này có thể lớn và phức tạp.
Tầm quan trọng của quản lý dự án CNTT thường có nghĩa là nó không chỉ là áp dụng kiến thức, sắp xếp các kỹ năng và sử dụng các công cụ và kỹ thuật thông thường để thúc đẩy một dự án hoàn thành. Các nhà quản lý dự án CNTT đối phó với các thách thức về tích hợp phụ thuộc lẫn nhau, nâng cấp công nghệ nhanh chóng và thay đổi phiên bản có thể xảy ra trong suốt tiến trình dự án.
Một số mô hình quản lý dự án phần mềm có thể kể đến như:
Rational Unified Process (RUP)
Đây là một mô hình được thiết kế bởi Công ty Phần mềm Rational, được IBM mua lại vào năm 2003. RUP rất dễ điều chỉnh vì nó sử dụng Ngôn ngữ mô hình hợp nhất (UML). Mô hình này có sự khác biệt lớn hơn với các mô hình phần mềm chính khác vì nó không sử dụng phương pháp tiếp cận Waterfall.
Structured Systems Analysis and Design Methodology (SSADM)
SSADM là một mô hình phát triển dự án phần mềm được sử dụng rộng rãi. SSADM được ra mắt vào năm 1981 với sự cải tiến hơn nữa đối với phiên bản ổn định được đưa ra thị trường vào năm 1990. SSADM không giống như RUP, nó là phần mềm mở tiêu chuẩn, có nghĩa là nó được sử dụng miễn phí.
Đây là một mô hình kỹ thuật phần mềm được phát triển bởi Kent Beck vào năm 1996. Ban quản lý dự án phần mềm có thể sử dụng mô hình này trong việc thiết kế dự án phần mềm của họ. Mô hình này nhằm giảm thiểu rủi ro trong quá trình quản lý và phát triển phần mềm.
Lập Và Quản Lý Dự Án Cntt, Lập Và Quản Lý Dự Án Cntt ,
Giới thiệu chương trình
Các dự án CNTT thường đi kèm với những thách thức riêng biệt đối với tất cả các thành viên trong nhóm dự án và kể cả người có vai trò là quản lý dự án IT (Project Manager). Hai trong số các thách thức mà người quản lý dự án (PM) thường gặp phải đó là Phương pháp triển khai dự án & Năng lực lãnh đạo của Project Manager.
Khóa học “Quản Lý Dự Án IT Chuyên Nghiệp” là chương trình được thiết kế dành riêng cho những người mong muốn trở thành Chuyên gia quản trị các dự án IT biết cách: Lập hồ sơ mời thầu; lập kế hoạch dự án; Tổ chức đội dự án; Phân tích yêu cầu & chuẩn hóa quy trình; Lựa chọn giải pháp và đơn vị triển khai giải pháp; Giám sát triển khai dự án. Với các loại dự án CNTT như: Dự án hạ tầng công nghệ (Data-center), Dự án xây dựng phần mềm (Software development), Dự án phân tích hoặc tích hợp dữ liệu doanh nghiệp (Data-warehouse), Triển khai dự án phần mềm (ERP), Triển khai quản lý dịch vụ CNTT (ITSM) ..v.v. Ngoài phương pháp quản trị dự án IT chuyên nghiệp, học viên còn trãi nghiệm toàn diện những kiến thức về kỹ năng lãnh đạo để giúp đảm bảo quản trị dự án IT tại doanh nghiệp thành công…v.v.
Mục tiêu của khóa học / Học xong học viên làm được những gì?
1. Cung cấp Kiến thức, Phương pháp, Quy trình quản trị dự án chuyên nghiệp với các bài thực hành cô đọng, chuyên sâu ứng dụng trong việc quản lý các dự án CNTT. 3. Biết cách Tổ chức, chọn lựa nhân sự, thiết lập mục tiêu các nhóm dự án, các kỹ năng cần thiết để lãnh đạo nhóm thành công. 4. Biết cách Lập các kế hoạch dự án cần thiết (Phạm vi, Tiến độ, Tài nguyên, Chi phí, Mua sắm, Truyền thông, Rủi ro, Bảo mật, Kiểm thử, Đào tạo, Thay đổi,,,) để triển khai dự án IT thành công. 5. Biết cách Triển khai các nhóm dự án, phân công công việc dự án, giám sát tiến độ và đánh giá chất lượng dự án. 6. Biết cách Họp ra quyết định cũng như giải quyết vấn đề trong các trường hợp có sự biến động giữa kết quả dự án so với kế hoạch ban đầu. 7. Biết cách Sử dụng thành thạo các template và công cụ hỗ trợ để quản trị các dự án IT thực tế bất kỳ.
Đối tượng học viên
i. Giám đốc dự án (IT Project Manager). ii. Trưởng nhóm dự án IT (IT Project Team Leader). iii. Thành viên đội dự án (IT Project Team Member). iv. Trưởng phòng IT (IT Manager). v. Quản trị IT cao cấp (IT Senior Manager). vi. Giám đốc IT (IT Director/ CIO). vii. Các chuyên viên tư vấn dự án CNTT: ERP/ CRM/ E-COMMERCE/ ITSM/ ISO 27001,… viii. Những ai có mục tiêu trở thành giám đốc dự án CNTT chuyên nghiệp.
PHẦN 01. LẬP ĐỀ XUẤT KHẢ THI & KHỞI ĐỘNG DỰ ÁN IT
Xác định tầm nhìn và mục tiêu của dự án IT Đánh giá tính khả thi của một dự án IT Các loại dự án CNTT trong doanh nghiệp Phân loại mức độ dự án IT dựa trên nguyên tắc rủi ro Những rào cản ảnh hưởng đến thành công của dự án IT Quy tắc để đảm bảo dự án IT thành công Tính toán TCO và ROI Phân tích TOV khi chọn giải pháp công nghệ Viết đề xuất kế hoạch dự án IT (Project Initiation) Bảng điều lệ dự án (Project Charter) Họp công bố và khởi động dự án (Kick-off) Thực hành
PHẦN 02. LẬP KẾ HOẠCH DỰ ÁN IT
Kế hoạch phạm vi dự án Kế hoạch công việc chi tiết Kế hoạch nhân lực – Tài nguyên cho dự án Kế hoạch ngân sách dự án Kế hoạch mua sắm hàng hoá dịch vụ IT Kế hoạch truyền thông dự án Kế hoạch quản lý rủi ro dự án Kế hoạch bảo mật cho dự án IT Kế hoạch quản lý sự thay đổi dự án Kế hoạch quản lý chất lượng dự án Kế hoạch thử nghiệm cho dự án Kế hoạch đào tạo & Bàn giao Thực hành
PHẦN 03. TỔ CHỨC ĐỘI DỰ ÁN
Cấu trúc nhóm theo mô hình chức năng Cấu trúc nhóm theo mô hình dự án Phát triển mục tiêu của nhóm và các cá nhân Xác định vai trò của các thành viên Tiêu chuẩn chọn lựa nhân sự cho đội dự án Ma trận phân công trách nhiệm Thiết lập quy trình hoạt động nhóm Phát triển mối quan hệ giữa các thành viên Cũng cố hình ảnh của nhóm Ký cam kết của các thành viên trong nhóm Các loại cuộc họp nhóm Tìm kiếm sự hỗ trợ bên ngoài nhóm Chiến thuật tạo động lực nhóm hiệu quả Thực hành
PHẦN 04. TRIỂN KHAI DỰ ÁN IT HIỆU QUẢ
Tổ Chức Hồ Sơ Quản Lý Dự Án Xây Dựng Môi Trường Dự Án Thành Lập Ban Chỉ Đạo Dự Án & Nhóm Dự Án Phân Bổ Nhân Lực Và Tài Nguyên Dự Án Phân Công Trách Nhiệm/ Nhiệm Vụ Ký Cam Kết Giao Việc Ký Cam Kết Phương Pháp Làm Việc Nhóm Thực Hiện Mua Sắm – Quản Lý Hợp Đồng Thiết Lập Quy Trình Kiểm Soát Dự Án (Kiểm soát ) Đánh Giá Hiệu Quả Và Chất Lượng Công Việc Kiểm Soát Chi Phí Dự Án Kiểm Soát Sự Thay Đổi Dự Án Họp Báo Cáo Tiến Độ/ Trạng Thái Dự Án Họp Rà Soát Với Nhà Cung Cấp Giải Quyết Xung Đột Cá Nhân Trong Dự Án Thực hành
Tài liệu học
i. Tài liệu lưu hành nội bộ (Tiếng Việt) ii. Tài liệu tham khảo (Tiếng Anh) iii. Các dự án IT mẫu dành cho người quản trị dự án IT
Phương pháp giảng dạy
Chuyên gia sử dụng các phương pháp đào tạo sau đây để chuyển tải nội dung khóa học: ii. Nghiên cứu tình huống (Case study) iii. Bài tập tự đánh giá (Self-assessment) iv. Thuyết giảng ngắn đề tài thực tế (Mini-lecture)
Sự khác biệt về phương pháp đào tạo
– Phương pháp giảng dạy Coaching dựa trên các mô hình quản lý thực tế – Đào tạo thực hành sát nhất với chuyên môn của từng vị trí – 100% là thực hành kỹ năng thực tế môi trường công việc hàng ngày – Đảm bảo chuẩn đầu ra là hiểu và làm được việc – Ưu tiên giới thiệu nhân sự cấp cao cho một số tập đoàn đối tác với chúng tôi
Kết thúc chương trình: Học viên tham gia khóa học phải hoàn thành đề án cuối khoá học, mục tiêu đánh giá khả năng nắm bắt kiến thức và ứng dụng nội dung học vào môi trường quản lý IT thực tế của doanh nghiệp.
Chứng nhận tốt nghiệp: Học viên tham gia và hoàn tất khóa học sẽ được cấp chứng nhận “Quản Lý Dự Án IT Chuyên Nghiệp” được chứng nhận có giá trị trên toàn quốc.
CÔNG TY CỔ PHẦN ĐÀO TẠO VÀ TƯ VẤN ĐẦU TƯ HÀ NỘI
Địa chỉ: Toà nhà FS tầng 1606 số 47 Nguyễn Tuân, Quận Thanh xuân, Hà Nội
Hotline: 0976.464688 – 0917.951558
Bạn đang xem bài viết Quản Lý Chất Lượng Dự Án Phần Mềm – Apmp trên website Tvzoneplus.com. 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. Chúc bạn một ngày tốt lành!