程序的質量如何評價

A. 如何評價工作流程運行質量

一、流速均勻 。各責任崗位能立即辦，並且達到工作質量 標准要求。若出現瓶頸崗位，就說明資源在此崗位匹配不當。應該要分析分析此責任崗位瓶頸的原因是什麼?——人的能力問題，還是人的責任問題?是外部資源的支持問題，還是人對資源的運用問題?找出原因進行調整，調整的目的要明白是解決瓶頸，以保證後面流程 不受阻，不要想的太高，如瓶頸崗位流速過高，又造成後面的責任崗位成為新的瓶頸。

二、整個流程的時間成本到底有多少 ?時間成本過高，辦事效率就會下降，潛虧就隱存著。從計劃與時間資源關繫上來，上道責任崗位辦事效率高，可以為下道責任崗位增強時間資源，若上道責任崗位辦事效率低，就會佔用下道責任崗位的時間資源，這樣下道責任崗位要按計劃完成工作任務就必須要組織協調支持人力資源或增加時間資源，或支持其它資源使工作任務在規定時間里完成。

三、流質質量 。不管是哪個部門，流程中的流質不外乎物資、資金這兩種，但最後都體現為信息流動。物資流動，是否符合生產流程要求?是否按“不流送不良品，不接收不良品，不生產不良品”三大原則流送?其中的信息流動必須要真實與完整體現，若沒有真實、完整、及時體現，那麼流程運行質量就會大大下降。因信息流動是人在操作的，在這里人的責任心，特別是細心就至關重要了。粗心的人，沒有全面、及時、完整流送信息，不去發現違反“三大原則”的不良行為，那麼不良的流質運行，結果就造成了“負效率與負效益”。同樣，組織的資金流動也是信息流動的。在途資金流動流程式控制制，不僅需要財務部門設計良好的工作流程，並且需要財務人員對流程中各個相關責任崗位進行技術指導與責任控制：“指導在先，控制在中，糾正在後”。

四、流程運行勞動設計成本與實際運行成本的差距 。這是結果對照分析。設計得好的流程，有益於明確責任，預防風險，但是具體運行中，責任人的能力與主觀積極性的發揮都會影響到整個流程的成本運行。研究與發現設計成本與實際成本的差距，有助於找出流程中潛存在的“利潤源”。

五、流程對接質量 。包括內部流程環節對接、內部流程與外部流程埠對接。內部流程環節對接，主要抓責任轉移“七大原則”行為落實。內部流程與外部流程對接，主要抓“責任沉澱”預防對接。如供應商到貨驗收工作流程，要預防供應商所供應材料或部件的品質、數量保障，若沒有對接好，那麼責任就沉澱到我們企業 這邊來了。再如，將產品 交付給用戶使用，用戶自身如何使用產品、如何保養產品、如何履行“三包”法中的責任，都要對接好，若沒有對接好，責任就沉澱給用戶，得到的`負面效果就是“用戶的埋怨”與市場的損失。

評價流程運行質量的目的與作用在於：

1、要發現流程設計是否適合現有的人力資源質量;

2、要發現潛存在流程中的“利潤源”與潛虧源;

3、要發現流程中操作者的制約因素：能力因素、責任因素。

4、分析流程運行質量，可以幫助發現“失蹤的績效”與造成“失蹤的績效”的責任者，從而糾正單一的績效考核所造成的不足與毛病。

5、對於個體的經理 人，通過分析流程運行質量，可以看出自我在組織、部門合作中的價值貢獻與決定性作用，從而更全面地認知自我，糾正自我評估值，以客觀地接近組織的評價值。

B. 軟體質量評估的軟體質量評估指標體系

通常，我們在軟體的測試與評估時，主要側重於功能特徵、可靠特徵、易用特徵和效率特徵等幾個方面。在評價活動的具體實施中，應該把被評估軟體的研製任務書作為主要依據，採用自頂向下逐層分解的方法，並參照有關國家軟體質量標准。 功能性是軟體最重要的質量特徵之一，可以細化成完備性和正確性。對軟體的功能性評價主要採用定性評價方法。
a.完備性
完備性是與軟體功能完整、齊全有關的軟體屬性。如果軟體實際完成的功能少於或不符合研製任務書所規定的明確或隱含的那些功能，則不能說該軟體的功能是完備的。
b.正確性
正確性是與能否得到正確或相符的結果或效果有關的軟體屬性。軟體的正確性在很大程度上與軟體模塊的工程模型（直接影響輔助計算的精度與輔助決策方案的優劣）和軟體編制人員的編程水平有關。
對這兩個子特徵的評價依據主要是軟體功能性測試的結果，評價標准則是軟體實際運行中所表現的功能與規定功能的符合程度。在軟體的研製任務書中，明確規定了該軟體應該完成的功能，如信息管理、提供輔助決策方案、輔助辦公和資源更新等。那麼即將進行驗收測試的軟體就應該具備這些明確或隱含的功能。
對於軟體的功能性測試主要針對每種功能設計若干典型測試用例，軟體測試過程中運行測試用例，然後將得到的結果與已知標准答案進行比較。所以，測試用例集的全面性、典型性和權威性是功能性評價的關鍵。 根據相關的軟體測試與評估要求，可靠性可以細化為成熟性、穩定性、易恢復性等。對於軟體的可靠性評價主要採用定量評價方法。即選擇合適的可靠性度量因子（可靠性參數），然後分析可靠性數據而得到參數具體值，最後進行評價。
經過對軟體可靠性細化分解並參照研製任務書，可以得到軟體的可靠性度量因子（可靠性參數）。
a.可用度
可用度指軟體運行後在任一隨機時刻需要執行規定任務或完成規定功能時，軟體處於可使用狀態的概率。可用度是對應用軟體可靠性的綜合（即綜合各種運行環境以及完成各種任務和功能）度量。
b.初期故障率
初期故障率指軟體在初期故障期（一般以軟體交付給用戶後的三個月內為初期故障期）內單位時間的故障數。一般以每100小時的故障數為單位。可以用它來評價交付使用的軟體質量與預測什麼時候軟體可靠性基本穩定。初期故障率的大小取決於軟體設計水平、檢查項目數、軟體規模、軟體調試徹底與否等因素。
c.偶然故障率
指軟體在偶然故障期（一般以軟體交付給用戶後的四個月以後為偶然故障期）內單位時間的故障數。一般以每1000小時的故障數為單位，它反映了軟體處於穩定狀態下的質量。
d.平均失效前時間（MTTF）
指軟體在失效前正常工作的平均統計時間。
e.平均失效間隔時間（MTBF）
指軟體在相繼兩次失效之間正常工作的平均統計時間。在實際使用時，MTBF通常是指當n很大時，系統第n次失效與第n+1次失效之間的平均統計時間。對於失效率為常數和系統恢復正常時間很短的情況下，MTBF與MTTF幾乎是相等的。
國外一般民用軟體的MTBF大體在1000小時左右。對於可靠性要求高的軟體，則要求在1000~10000小時之間。
f.缺陷密度（FD）
指軟體單位源代碼中隱藏的缺陷數量。通常以每千行無註解源代碼為一個單位。一般情況下，可以根據同類軟體系統的早期版本估計FD的具體值。如果沒有早期版本信息，也可以按照通常的統計結果來估計。「典型的統計表明，在開發階段，平均每千行源代碼有50~60個缺陷，交付後平均每千行源代碼有15~18個缺陷」。
g.平均失效恢復時間（MTTR）
指軟體失效後恢復正常工作所需的平均統計時間。對於軟體，其失效恢復時間為排除故障或系統重新啟動所用的時間，而不是對軟體本身進行修改的時間（因軟體已經固化在機器內，修改軟體勢必涉及重新固化問題，而這個過程的時間是無法確定的）。 易用性可以細化為易理解性、易學習性和易操作性等。這三個特徵主要是針對用戶而言的。對軟體的易用性評價主要採用定性評價方法。
a.易理解性
易理解性是與用戶認識軟體的邏輯概念及其應用范圍所花的努力有關的軟體屬性。該特徵要求軟體研製過程中形成的所有文檔語言簡練、前後一致、易於理解以及語句無歧義。
b.易學習性
易學習性是與用戶為學習軟體應用（例如運行控制、輸入、輸出）所花的努力有關的軟體屬性。該特徵要求研製方提供的用戶文檔（主要是《計算機系統操作員手冊》、《軟體用戶手冊》和《軟體程序員手冊》）內容詳細、結構清晰以及語言准確。
c.易操作性
易操作性是與用戶為操作和運行控制所花的努力有關的軟體屬性。該特徵要求軟體的人機界面友好、界面設計科學合理以及操作簡單等。
3.4 效率特徵指標
效率特徵可以細化成時間特徵和資源特徵。對軟體的效率特徵評價採用定量方法。
a.輸出結果更新周期
輸出結果更新周期是軟體相鄰兩次輸出結果的間隔時間。為了整個系統能夠協調工作，軟體的輸出結果更新周期應該與系統的信息更新周期相同。
b.處理時間
處理時間是軟體完成某項功能（輔助計算或輔助決策）所用的處理時間（注意：不應包含人機交互的時間）。
c.吞吐率
吞吐率是單位時間軟體的信息處理能力（即各種目標的處理批數）。未來的社會情況復雜、信息眾多，軟體必須具有處理海量數據的能力。吞吐率就是體現該能力的參數。隨著信息的泛濫，要求軟體的吞吐率應該達到數百批。
d.代碼規模
代碼規模是軟體源程序的行數（不包括注釋），屬於軟體的靜態屬性。軟體的代碼規模過大不僅要佔用過多的硬碟存儲空間，而且顯得程序不簡潔、結構不清晰，容易存在缺陷。
因為這些參數屬於軟體的內部表現，所以需要用專門的測試工具和特殊的途徑才可以獲得。將測試數據與研製任務書中的指標進行比較，得到的結果可以作為效率特徵評價的依據。 隨著計算機技術、數據融合技術、網路技術和通信技術的飛速發展，對軟體功能提出的要求也越來越高，如何評估軟體質量已成為一個迫切需要解決的課題。選擇合適的指標體系並使其量化是做好軟體質量評估的關鍵。當然，由於軟體的評估具有其特有的規范和要求，其評估指標涉及面廣、不確定性因素較多、量化困難，至今還沒有統一的標准。

C. 如何全面評價一下軟體產品的質量，有什麼標准

(1)軟體需求是度量軟體質量的基礎，與需求不一致就是質量不高。(2)指定的標準定義了一組指導軟體開發的准則，如果沒有遵守這些准則，幾乎肯定會導致質量不高。(3)通常，有一組沒有顯式描述的隱含需求（如期望軟體是容易維護的）。如果軟體滿足明確描述的需求，但卻不滿足隱含的需求，那麼軟體的質量仍然是值得懷疑的。

D. 什麼是軟體如何評價軟體的質量

軟體含義
軟體是用戶與硬體之間的介面界面。用戶主要是通過軟體與計算機進行交流。軟體是計算機系統設計的重要依據。為了方便用戶，為了使計算機系統具有較高的總體效用，在設計計算機系統時，必須全局考慮軟體與硬體的結合，以及用戶的要求和軟體的要求。 1．運行時，能夠提供所要求功能和性能的指令或計算機程序集合。 2．程序能夠滿意地處理信息的數據結構。 3．描述程序功能需求以及程序如何操作和使用所要求的文檔。 以開發語言作為描述語言，可以認為： 軟體=程序+數據+文檔。

最傷害硬碟的軟體
1、編碼錯誤的DVDRip 現在網上由DVD轉錄壓縮的DVDRip格式的影片相當受歡迎。這種格式的影片清晰度和DVD相差無幾，但下載一部影片只有700MB~1.3GB大小，因此很多用戶喜歡將DVDRip格式的影片下載到硬碟上慢慢欣賞。不過，播放這種格式的影片對系統有較高的要求：除了CPU、顯卡要求足夠強勁以保證播放流暢外，硬碟負荷也非常大，因為播放DVDRip就是一個不斷解碼解壓縮，再輸送到顯示系統的過程。筆者發現，在遇到有編碼錯誤的DVDRip文件時，Windows會出現磁碟佔用率非常高的現象：系統不斷想要把編碼轉換為視頻信號，但編碼錯誤的文件索引和相應的信號段是不匹配的。此時，硬碟燈會不斷地閃爍，整個系統對用戶的操作響應極慢，用戶點擊菜單但幾乎沒有反應。如果編碼錯誤較多，系統有時候甚至會死機。很多用戶在此時非常不耐煩，直接按下機箱上的RESET鍵甚至是直接關閉計算機電源，在硬碟磁頭沒有正常復位的情況下，這種操作相當危險！ 提示：Windows XP的用戶需要特別注意，當我們在Windows XP中自動預覽一些體積較大的ASF、WMV等文件時，雖然沒有進行正式播放，但也會出現計算機速度突然變慢、硬碟燈不斷閃爍等現象，其罪魁禍首仍然是視頻文件錯誤編碼！ 2、Bittorrent下載 Bittorrent下載是寬頻時代新興的P2P交換文件模式，各用戶之間共享資源，互相當種子和中繼站，俗稱BT下載。由於每個用戶的下載和上傳幾乎是同時進行，因此下載的速度非常快。不過，它會將下載的數據直接寫進硬碟(不像FlashGet等下載工具可以調整緩存，到指定的數據量後才寫入硬碟)，因此對硬碟的佔用率比FTP下載要大得多！ 此外，BT下載事先要申請硬碟空間，在下載較大的文件的時候，一般會有2~3分鍾時間整個系統優先權全部被申請空間的任務佔用，其他任務反應極慢。有些人為了充分利用帶寬，還會同時進行幾個BT下載任務，此時就非常容易出現由於磁碟佔用率過高而導致的死機故障。 因此，除非你的電腦硬體配置相當高(尤其是內存，至少要在256MB以上)，否則在BT下載作出改進以前，如果要進行長時間、多任務的下載應用，最好還是採用傳統的FTP軟體。 3、PQMAGIC轉換的危險 PQMAGIC是大名鼎鼎的分區魔術師，能在不破壞數據的情況下自由調整分區大小及格式。不過，PQMAGIC剛剛推出的時候，一般用戶的硬碟也就 2GB左右，而現在60~80GB的硬碟已是隨處可見，PQMAGIC早就力不從心了：調整帶數據的、5GB以上的分區，通常都需要1小時以上！ 除了容量因素影響外，PQMAGIC調整硬碟分區時，大量的時間都花在校驗數據和檢測硬碟上，可以看出，在這種情況下「無損分區」是很難保證的：由於轉換的速度很慢，耗時過長，轉換調整過程中，很容易因為計算機斷電、死機等因素造成數據丟失。這種損失通常是一個或數個分區丟失，或是容量變得異常，嚴重時甚至會導致整個硬碟的數據無法讀取。 4、硬碟保護軟體造成的異常 容易造成硬碟異常的，還有硬碟保護軟體。比如「還原精靈」，由於很多人不注意在重裝系統或是重新分區前將它正常卸載，往往會發生系統無法完全安裝等情況。此時再想安裝並卸載「還原精靈」，卻又提示軟體已經安裝，無法繼續，陷入死循環中。這種故障是由於「還原精靈」接管了INT13中斷，在操作系統之前就控制了硬碟的引導，用FDISK/MBR指令也無法解決。本來這只是軟體的故障，但很多人經驗不足，出了問題會找各種分區工具「試驗」，甚至輕率地低級格式化，在這樣的折騰之下，硬碟很可能提前夭折！ 5、頻繁地整理磁碟碎片 磁碟碎片整理和系統還原本來是Windows提供的正常功能，不過如果你頻繁地做這些操作，對硬碟是有害無利的。磁碟整理要對硬碟進行底層分析，判斷哪些數據可以移動、哪些數據不可以移動，再對文件進行分類排序。在正式安排好硬碟數據結構前，它會不斷隨機讀取寫入數據到其他簇，排好順序後再把數據移回適當位置，這些操作都會佔用大量的CPU和磁碟資源。其實，對現在的大硬碟而言，文檔和郵件佔用的空間比例非常小，多數人買大硬碟是用來裝電影和音樂的，這些分區根本無需頻繁整理。因為播放多媒體文件的效果和磁碟結構根本沒有關系，播放速度是由顯卡和CPU決定的。

如何判斷軟體的質量我認為應該從軟體的適用，方便，快捷，佔用資源等項來判斷！

http://ke..com/view/37.htm此頁有軟體的相關介紹！