ISO9000軟體項目評審過程記錄_親曆記錄

ISO評審過程記錄

版本	V1.0
建立者	XXXX	建立時間	2013-02-27
修改者		修改時間

1、項目獲得的形式：

   是否進採取了招投標的形式？

    如果回答通過招投標的形式較好，因為對招投標這個流程沒什麼可考察的，如果回答沒有走招投標的形式，評審員會問什麼問題未知。

2、進度控制(MPP)的制定時機：

項目評審通過之後就應該編寫項目進度檔案了，而不是需求分析之後採取編寫。

3、概要設計的確認工作：

  評審員可能會採取反問的形式，舉例：軟體項目的概要設計客戶可能都看不懂，你們也要拿去確認嗎？概要設計肯定是要做確認工作的，可以這樣解釋：我們的概要設計採取的是使用者語言(自然語言而不是程式語言)，並且概要設計裡會有大量的圖示的形式，很直觀，使用者很容易能看懂。

4、詳細設計的確認工作：

      詳細設計採取的是內部評審的方式進行，無需客戶參與。內部評審的過程記錄要有；評審過程中發現的修改項目要記錄下來，包含修改的項目、解決方案、在詳細設計裡體現的部分。

5、開發用的是什麼原型：

   當初回答的是瀑布模式，審查員也沒提出什麼異議。

6、國家標準、行業標準、項目標準：

     都要有一份列表，列表裡特別注意的地方：標準編號裡年份資訊一定不能太早了，舉例某個標準文檔編號SL 323-1988,1988年的標準太過陳舊了是不允許的。

   編碼規範一定要有，每個語言(C#,VB,SQL)都要有,不要混用一套編碼規範。

7、整個項目過程中所有的模板檔案清單：

需要有一個這樣的列表，項目進行的每個環節都應該有模板。

8、進度控制(MPP)的一些注意事項：

進度控制檔案裡要體現出各種評審的環節；進度控制裡任務與任務之間要有前置任務關係，消除資訊孤島。

9、所有的文檔的一些注意事項：

   版本資訊都要體現出來；都要有封皮較好；

10、需求分析注意事項：

把效能要求體現出來比較好；如果有第三方介面的話要寫清楚。

11、組態管理的認知注意事項：

這一點答的不太好，需要根據配置計劃的標準檔案，把組態管理需要管理哪些資料；怎麼管理等事情捋清楚。

12、概要設計要與需求分析對應起來，所有需求文檔的項目都要在概要設計裡有所體現，針對這個問題，推廣開來就是所有的項目過程檔案都要有前後合理關係。

13、概要設計要體現出軟體系統的軟硬體運行環境。

14、Bug管理有沒有使用工具：

回答的是沒有使用工具，採用的是excel的形式進行。

15、配置計劃：

配置計劃一定要有，要不然會產生不合格項的。

針對配置計劃，評審員可能會考一些問題舉例：項目組做不做備份呀？備份計劃是什麼呀？備份的介質是什麼呀？(備份一定要注意物理隔離)，備份是手工進行還是指令碼化進行呀？(當時回答的是手工進行，評審員沒有提出什麼異議)。

16、安全機制的控制：

項目組每個人安不安安全軟體呀?（回答是公司統一要求每台機器必須安裝安全軟體，一般個人都是安裝的360安全軟體）；

整個公司怎麼保證項目組的安全呀?(最好回答：軟體研發部跟其他部分採取的物理隔絕的形式，其他部分的人員絕對不可以訪問開發人員的電腦的，公司外的電腦更是絕對的絕對不能訪問開發人員的電腦的)。

附件：

1、軟體項目流程參見：