質量是「使實體具備滿足明確或隱含需求能力的各項特徵之總和」，明確或隱含的需求是指按專案需求制定的基礎性檔案。在資訊系統專案中，一般把《系統需求規格說明書》作為專案需求的基礎性檔案。
質量管理作為專案管理的一部分，具有非常重要的地位。質量管理的目的是通過執行專案質量管理過程，使用一些基本專案管理工具和技術來保證資訊系統的質量。時間、成本、質量是專案管理的三大目標，如果質量不能滿足要求，即使進度再快，成本再節省，專案也沒有意義。
閱讀以下關於資訊系統專案管理過程中質量管理方面問題的敘述，回答問題1至問題3。
某銀行資訊系統工程專案，包含省級廣域網工程、儲蓄所終端安裝工程、主機系統工程、儲存系統工程、備份系統工程、銀行業務軟體開發工程等若干子專案。此工程專案通過公開招標方式確定承建單位，希賽資訊科技****(csai)經過激烈競標爭奪，贏得工程合同。合同約定，工程專案的開發周期預算為 36 周。
由於銀行對於應用軟體質量要求很高，csai 也非常重視工程質量，安排有資深資歷的高階工程師張工全面負責專案實施。在工程正式開工之前，張工對工程專案進行了分解，根據工程分析，張工認為此工程專案質量、進度的關鍵在於銀行業務定製應用軟體的開發。除工程整體的開發計畫外，張工還針對應用軟體開發制定了詳細的開發計畫，定製應用軟體的開發周期為 36 周。
網路工程、終端安裝工程、主機系統工程、儲存系統工程、備份系統工程等與應用軟體開發並行實施。
張工對工程專案在需求分析、概要設計、詳細設計、編碼、單元測試、整合測試等各個環節要求均非常嚴格。根據張工安排，需求分析、概要設計均安排有多年工作經驗的高階軟體工程師擔任，各個階段的階段成果均組織了嚴格的評審，以保證各個階段成果的質量。
在軟體編碼及單元測試工作完成之後，張工安排軟體測試組的工程師編制了詳細軟體測試計畫、測試用例，包括整合測試、功能測試、效能測試、安全性測試，等等。
張工在安排軟體測試任務的時候，在動員軟體開發小組時宣講： 軟體測試環節是軟體系統質量形成的主要環節，各開發小組，特別是測試小組，應重視軟體系統測試工作」。因此，張工安排給測試組進行測試的時間非常充足，測試週期佔整個軟體系統開發周期的 40%,約 14.
5 周。在軟體系統測試的過程中，張工安排了詳細的測試跟蹤計畫，統計每週所發現軟體系統故障數量，以及所解決的軟體故障。根據每週測試的結果分析，軟體系統故障隨時間的推移呈明顯的下降趨勢，第 1 周發現約 100 個故障，第 2 周發現約 90 個故障，第 3 周發現 50 個故障，……，第 10 周發現 2 個故障，第11 周發現 1 個故障，第 12 周發現 i 個故障。
於是張總工斷言軟體系統可以在完成第 14 周測試之後
順利交付給使用者，並進行專案驗收。
【問題1】請以 300 字內回答，張工的軟體開發計畫中是否存在問題？為什麼？
【問題2】請以 200 字內回答，張工根據對定製軟體系統測試的跟蹤統計分析結論，得出專案可於計畫的測試期限結束後達到驗收交付的要求，你認為可行嗎，為什麼？
【問題3】請以 300 字內回答，若你是本專案的總工，你將怎樣改進工作，以提高軟體系統開發的質量，保證工程專案按期驗收？
過去，很多 it 整合公司所承建的定製軟體工程專案，當進入到驗收階段的時候，使用者常常拖延，或找這樣那樣的藉口不給承建單位驗收，這是什麼原因呢？針對這個問題，建設單位、承建單位都有一定責任。對於建設單位來講，由於建設單位對資訊系統建設認識上的侷限性，對軟體系統質量鑑定的困難性，建設單位存在著對定製軟體系統的質量的擔心，因此，很難果斷地做出驗收專案的決定。
而對於承建單位來講，承建單位在專案質量管理方面常常做得很不到位，比如：該提交工程實施計畫、工程實施計畫進度跟蹤記錄、工程概要設計書、詳細設計書、應用系統配置檔案、使用者手冊、培訓資料等若干文件的時候沒有提交，而很多承建單位在專案驗收時，根本看不到這些文件，或即使有文件，但也極其不規範，文件質量很低。再比如：
曾有個資訊系統工程專案在提交使用者驗收的時候，有一台防火牆散亂地擺放在機櫃外面，再看機櫃上面所布放的通訊線纜，顯得雜亂無章，承建單位也沒有意識到這個問題，使用者雖看在眼裡卻不提醒承建單位，那請問，使用者會給這樣的專案進行驗收嗎？
通過硬體所表現出來的表面質量是很容易發現的，但對於軟體系統的質量的衡量卻是非常困難的，特別是對於那些對軟體系統認識不夠深入的 it 系統建設單位，他們面對 it 專案的驗收，常常顯得很謹慎也是可以理解的。
資訊應用系統專案的質量保證與承建單位的質量保證體系是密切相關的，但並不等於承建單位有質量保證體系，如通過了 iso9000 認證，或通過了 cmm3, cmm4 等認證，就一定能夠保證 it 專案的質量。承建單位的質量保證體系是乙個大綱性質的，但實施專案的是專案小組，專案小組不能很好融合到承建單位的質量保證體系中是比較常見的現象，因此，為有效保證專案的質量，專案小組應當向建設單位或監理單位提交專案的質量保證計畫。質量保證計畫是在承建單位質量保證體系下編制的，是針對專案特點的，涉及保證專案質量的具體措施，更易於操作。
當然，乙個專案的質量保證計畫如果照搬到另外乙個專案，卻不一定適用。而建設單位、監理單位可以通過對承建單位質量保證計畫的執**況來判斷其軟體開發過程的質量，從而協助對定製軟體產品質量的鑑定。
【問題1】
軟體測試是保證軟體質量的重要工作內容之一，但軟體測試環節卻不是軟體質量的形成環節，測試只能檢查軟體中所存在的缺陷，發現問題。軟體質量是在需求分析、設計、編碼、測試、文件編制等軟體生產的全過程中形成的。因此，我們要了解定製軟體系統的質量，就必須了解承建單位開發軟體系統的全部過程的質量。
測試計畫和測試用例應當在軟體的設計階段制定。越晚進行的測試，其測試計畫的編制時間就越早。如整合測試計畫在概要設計階段編制，功能確認測試計畫在需求定義階段就應當制定，整體測試計畫也應當在需求分析階段制定。
雖然我們在實踐中有很多這樣的情況，很多軟體開發團隊並不是在軟體設計階段同步制定軟體測試計畫和測試用例，甚至有很多軟體開發中根本就沒有制定規範的測試計畫和測試用例。但這些並不是正統、規範的做法，這樣的軟體工程過程對於保證定製軟體系統的質量來說是會打折扣的。
若測試計畫的編制時機不能按照規範進行，那說明軟體企業的過程能力成熟度還不夠，還是在採用手工作坊方式生產軟體，想到**做到**，沒有計畫或計畫不科學，不能有效地控制軟體生產的質量。
【問題2】
軟體系統的質量，僅僅根據測試的結論來進行斷言是不夠的。我們在進行專案開發計畫安排的時候，應當將系統的試執行也安排在計畫之內。系統的試執行牽涉到工程專案的建設方和承建方，除了技術方面的因素外，還涉及組織方面的因素，人文方面的因素等。
承建方要安排足夠的時間與建設方協商系統的試執行問題，在雙方的配合下開展系統試執行工作，系統在試執行中，通常還會發現大量的故障，承建單位也必須配合解決這些系統故障。只有通過試執行的考驗，才能夠基本斷定系統的質量是否符合要求；通過了試執行的考驗，再向使用者提出工程專案的驗收，一般來說，使用者的接受程度會比較高。
軟體系統的試執行為什麼如此重要呢？這是根據不同的工程專案的特點，如公路建設就不需試執行，住宅建設也不需試入住，通過質檢方式就可確定工程專案的質量。而另外一些工程專案則是必須要進行試執行的，比如鐵路系統建設、水電站建設、化工廠建設等，這些型別的工程專案，不通過試執行，就不可能鑑定其質量，資訊應用系統的建設也是一樣。
【問題3】
另外，在向使用者提出專案驗收前，還得整理並提交完整的工程技術文件、系統維護文件、軟體配置清單，給使用者舉辦系統操作培訓、維護培訓，全面審核合同執**況，編制專案竣工報告，等等。如果專案小組不注意這些工作，使用者大多也不會來提醒你，使用者只卡住驗收關不讓通過就可以了，當然也有部分使用者可能會提醒專案小組離驗收還差什麼。畢竟專案的實施任務是屬於承建單位的工作，承建單位理應完善自身的專案管理水平，不可能讓使用者來督促你、提示你，那不是使用者的職責，更何況，很多使用者自身也不知道 it 專案該怎樣管理，有哪些工作需要完成，但承建單位很多不規範的做法、存在的問題，讓使用者對質量不放心，使用者卻是能夠覺察到的。
特別要注意的是，專案經理在計畫專案驗收時，應當與使用者的主要領導充分溝通，讓客戶領導了解專案的建設過程，了解專案的質量實施情況，讓領導對專案的驗收充滿信心。
但請仔細分析本題，案例場景中通篇並沒有提到關於工程文件、配置清單、培訓等話題，這些內容並不是本題的關鍵，未提及的內容，張工可能沒做到，但也可能做到，不好斷言。我們只要能夠抓住場景所描述的張工的主要缺陷，一是制定測試計畫的時機不對，二是根據測試斷定軟體系統的質量不對，只要能抓住這兩點就夠了。其他的內容，也可以反映在答案中，但要注意語言要簡練，雖不會導致扣分，但也不是得分的要點。
【問題1】
張工安排測試計畫的編制時機不對。測試計畫和測試用例的編制應當與軟體系統的概要設計、詳細設計同步進行。
測試計畫不夠全面，還應當包含系統整體測試、執行測試。執行測試是對應用軟體系統整體功能的全面檢驗，也是最能夠說明軟體系統質量的測試環節。
系統測試計畫、確認測試計畫應當在需求分析階段制定，測試用例、測試說明應當在概要設計階段制定。
整合測試計畫應當在概要設計階段制定，測試用例、測試說明應當在詳細設計階段制定。
單元測試計畫應當在詳細設計階段制定，測試用例、測試說明應當在編碼階段制定。
【問題2】
在定製軟體開發專案中，根據測試結果判定軟體系統的質量是不夠的，因為軟體系統中的缺陷可能由於多種原因而未在測試中被發現，如測試環境與執行環境的區別、測試人員的能力問題、測試計畫和測試用例的侷限及缺陷。
由於軟體系統質量、功能、效能具有很強隱蔽性的特點，使用者往往不大可能根據專案開發小組的測試結論來進行專案的驗收。最好讓使用者組織對專案進行試執行，以試執行的結論來作為驗收的依據之一是比較有說服力的。
【問題3】
(1)在進行需求分析的時候，同步制定功能確認測試計畫和測試用例，同步制定系統整體測試計畫和測試用例。
(2)在進行軟體系統概要設計的時候，制定整合測試計畫和測試用例。
(3)在進行軟體系統詳細設計的時候，制定單元測試計畫和測試用例。
(4)在專案計畫驗收日期前，提前與使用者協商系統試執行計畫，並給使用者進行充分的培訓，包括領導和一般操作人員，讓系統接受實際執行的考驗，在試執行過程中暴露出來的問題，及時進行解決。以軟體系統實際執行所表現出來的功能、效能來說服使用者對專案進行驗收，這通常是更可行的方法。
第8章專案質量管理
1.控制圖中的控制上限和控制下限表明 a.專案團隊不受處罰的最大偏差範圍b.產品質量合格與不合格的分界線 c.生產過程不需採取糾正措施的界限d.判斷專案成敗的重要統計依據 2.精確不同於準確，因為 a.精確是指重複測量的結果的離散度很小，準確是指單次測量的結果與目標值很接近 b.準確是指重複測量的結...
第6章質量管理
第六章專案質量管理 6.1 專案質量管理的概念 6.1.1 質量的基本概念 1 質量的定義 iso的質量定義 質量是反映實體 產品 過程或活動等 滿足明確和隱含需要的能力特性總和 我國國標gb t 1900 2000的質量定義 一組固有特性滿足要求的程度。質量不僅指產品，質量也可以是某項活動或過程的...
專案質量管理與案例
工程專案質量控制與管理 班級 專案管理 姓名 繆孟航 學號 2010090012 摘要 工程施工質量，是業主和消費者對建築施工企業評價的首條標準，因此做好工程專案的質量控制，是工程專案管理的重要環節。文章通過對工程專案質量控制基本要素的闡述，提出了工程專案質量控制的理論模型，在此基礎上從工程專案施工...