作業(yè)流程晴雨表

    是否存在專注于組織整體的開發(fā)作業(yè)和項目流程的人或者小組？
    是否存在項目開發(fā)作業(yè)的標準作業(yè)流程？
    是否存在記述顧客需求式樣的文檔標準？
    是否存在設計書的文檔標準？
    是否不經過設計階段而直接進入編碼階段？
    設計階段是否實施了以設計為對象的審查？
    編碼階段是否實施了以代碼為對象的審查？
    中途式樣變更后，是否未經其影響范圍的分析直接分配給擔當者？
    是否未經單體測試直接開始綜合測試？
    是否時至后才發(fā)現(xiàn)此前隱藏的諸多問題？
    是否無視已經發(fā)現(xiàn)的問題而繼續(xù)推進作業(yè)？
    是否多次重復出現(xiàn)以前相同的錯誤而沒有吸取教訓？
    是否沒有專門的測試人員而在交付之前還是由開發(fā)者自己實施測試？
    對式樣需求是否確立了適當?shù)臏y試項目？
    測試是否幾乎沒有自動化手段？
    過程改善方面是否存在可以商量和咨詢的人員？
    是否鼓勵各開發(fā)小組寫作事后分析報告，至少能項目進程開會討論？
    是否組織正式的活動，軟件開發(fā)與質量控制流程的相關問題相互切磋？

項目配置晴雨表

    是否在發(fā)現(xiàn)潛在的缺陷時難以確定其對現(xiàn)有模型的影響范圍？
    是否只有擔當者知道而沒有向所有成員公布缺陷的修正范圍和修正方法？
    是否因為修改一個程序缺陷而引發(fā)多個新的缺陷？
    擔當者是否能在任何時間對源程序做自由的變更？
    開發(fā)期間是否定期對制作過程中的文件和程序進行備份？
    是否確立了資源備份在非常時期的因應方式？
    需求式樣書和設計書等正式文件是否存在“確認”手續(xù)？
    項目文檔是否一直保持初的狀態(tài)，即使在式樣變更后仍然沒有變化？
    是否在項目后期難以想起中途式樣變更的“理由”？
    對于程序缺陷和式樣變更，是否能追蹤其修改點？
    對于開發(fā)環(huán)境目錄中的舊代碼是否難以判斷其能否刪除？
    開發(fā)文檔是否會出現(xiàn)鏈接到舊版本的情況？

教育培訓晴雨表

    是否描繪出現(xiàn)在的開發(fā)組織多年后的“風姿”？
    在組織上，是否對現(xiàn)在的人員實施技術性教育和培訓？
    是否確立了員工教育培訓的計劃和目標？
    是否將技術學習視為個人任務而沒有組織上的“方向”？
    項目開發(fā)人員所持有的軟件開發(fā)文獻的平均數(shù)量是否在1冊以下？
    項目作業(yè)休息時間是否毫不涉及嶄新技術方面的話題？
    項目組成員是否不知道軟件工程的意思？
    是否不了解“凝聚度”、“結合度”等詞匯的意思？
    是否難以說出5個以上的軟件質量特性及其副特性？

項目審查晴雨表

    參與者是否了解審查的整體流程？
    是否帶著目的而非盲目地實施審查作業(yè)？
    是否僅僅局限于代碼審查而不顧及其他？
    審查者是否只關注形式而非實質？
    是否明確審查對象物，針對“物”而非“人”？
    是否記錄審查結果并追蹤缺陷修正結果？
    是否將審查的反饋結果導入下一項目中？
    審查會議是否演化成為問題解決會議？

其他

    是否采取了數(shù)據(jù)備份以及病毒防范等措施？
    對電子郵件的應對是否總是滯后？
    是否感到電子郵件的應對很繁瑣？