第一篇：論文代碼

根據GB3469-83《文獻類型與文獻載體代碼》規定，以單字母標識：

M——專著（含古籍中的史、志論著）

C——論文集

N——報紙文章

J——期刊文章

D——學位論文

R——研究報告

S——標準

P——專利

A——專著、論文集中的析出文獻

Z——其他未說明的文獻類型

電子文獻類型以雙字母作為標識：

DB——數據庫

CP——計算機程序

EB——電子公告

非紙張型載體電子文獻，在參考文獻標識中同時標明其載體類型：

DB/OL——聯機網上的數據庫

DB/MT——磁帶數據庫

M/CD——光盤圖書

CP/DK——磁盤軟件

J/OL——網上期刊

EB/OL——網上電子公告 參考文獻規范格式

一、參考文獻的類型

參考文獻（即引文出處）的類型以單字母方式標識，具體如下： M——專著

C——論文集

N——報紙文章

J——期刊文章

D——學位論文

R——報告

對于不屬于上述的文獻類型，采用字母―Z‖標識。對于英文參考文獻，還應注意以下兩點：

①作者姓名采用―姓在前名在后‖原則，具體格式是： 姓，名字的首字母.如： Malcolm Richard Cowley 應為：Cowley, M.R.，如果有兩位作者，第一位作者方式不變，&之后第二位作者名字的首字母放在前面，姓放在后面，如：Frank Norris 與Irving Gordon應為：Norris, F.& I.Gordon.； ②書名、報刊名使用斜體字，如：Mastering English Literature，English Weekly。

二、參考文獻的格式及舉例 1.期刊類

【格式】[序號]作者.篇名[J].刊名，出版年份，卷號（期號）：起止頁碼.【舉例】

[1] 王海粟.淺議會計信息披露模式[J].財政研究，2004,21(1)：56-58.[2] 夏魯惠.高等學校畢業論文教學情況調研報告[J].高等理科教育，2004(1):46-52.[3] Heider, E.R.& D.C.Oliver.The structure of color space in naming and memory of two languages [J].Foreign Language Teaching and Research, 1999,(3): 62 – 67.2.專著類

【格式】[序號]作者.書名[M].出版地：出版社，出版年份：起止頁碼.【舉例】[4] 葛家澍，林志軍.現代西方財務會計理論[M].廈門：廈門大學出版社，2001：42.[5] Gill, R.Mastering English Literature [M].London: Macmillan, 1985: 42-45.3.報紙類

【格式】[序號]作者.篇名[N].報紙名，出版日期（版次）.【舉例】

[6] 李大倫.經濟全球化的重要性[N].光明日報，1998-12-27(3).[7] French, W.Between Silences: A Voice from China[N].Atlantic Weekly, 1987-8-15(33).4.論文集

【格式】[序號]作者.篇名[C].出版地：出版者，出版年份：起始頁碼.【舉例】

[8] 伍蠡甫.西方文論選[C].上海：上海譯文出版社，1979：12-17.[9] Spivak,G.―Can the Subaltern Speak?‖[A].In C.Nelson & L.Grossberg(eds.).Victory in Limbo: Imigism [C].Urbana: University of Illinois Press, 1988, pp.271-313.[10] Almarza, G.G.Student foreign language teacher’s knowledge growth [A].In D.Freeman and J.C.Richards(eds.).Teacher Learning in Language Teaching [C].New York: Cambridge University Press.1996.pp.50-78.5.學位論文 【格式】[序號]作者.篇名[D].出版地：保存者，出版年份：起始頁碼.【舉例】

[11] 張筑生.微分半動力系統的不變集[D].北京：北京大學數學系數學研究所, 1983：1-7.6.研究報告

【格式】[序號]作者.篇名[R].出版地：出版者，出版年份：起始頁碼.【舉例】

[12] 馮西橋.核反應堆壓力管道與壓力容器的LBB分析[R].北京：清華大學核能技術設計研究院, 1997：9-10.7.條例

【格式】[序號]頒布單位.條例名稱.發布日期

【舉例】[15] 中華人民共和國科學技術委員會.科學技術期刊管理辦法[Z].1991—06—05 8.譯著

【格式】[序號]原著作者.書名[M].譯者，譯.出版地：出版社，出版年份：起止頁碼.三、注釋

注釋是對論文正文中某一特定內容的進一步解釋或補充說明。注釋前面用圈碼①、②、③等標識。

四、參考文獻

參考文獻與文中注（王小龍，2005）對應。標號在標點符號內。多個都需要標注出來，而不是1-6等等，并列寫出來。

第二篇：部門代碼

部門代碼

總經理：GMD 行政人事部：AD 技術部：TD 發展部：RDD 宣傳部：PD 策劃部：SD 工程部：ED 造價部：EC 財務部：ACD 投融資部：FD 戰略計劃部：SPD 招標合約部：BCD 審計部：ADD 招商部：MD 研究院：RI 物業部:PD 后勤部：LD 資源管理部：RD

第三篇：代碼檢查

代碼檢查

摘要：代碼檢查是白盒測試的一種靜態測試方法，是眾多軟件測試方法中發現軟件缺陷最有效的方法之一。本文結合國內外學者在相關領域的研究情況，介紹代碼檢查相關的基本概念、過程和分析方法。

關鍵字：白盒測試，代碼檢查，靜態分析，檢查規則

一、引言

按照測試時源代碼是否可見，軟件測試可以分為白盒測試和黑盒測試兩類。

白盒測試（結構測試），即邏輯驅動的測試，是在了解程序內部結構的基礎上，對程序的邏輯結構進行檢查，從中獲取測試數據。白盒測試關注的是測試用例執行的程度或覆蓋程序邏輯結構的程度。白盒測試一般只應用于軟件開發階段。

白盒測試，又可按照是否需要運行程序，進一步細分為了靜態測試和動態測試兩種。通常情況下是按照先靜態后動態測試順序來實施。其中，靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等測試內容。靜態測試既可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。

代碼檢查是一種對程序代碼進行靜態檢查。傳統的代碼檢查是通過人工閱讀代碼的方式，檢查軟件設計的正確性；用人腦模擬程序在計算機中的運行，仔細推敲、校驗和核實程序每一步的執行結果，進而判斷其執行邏輯、控制模型、算法和使用參數與數據的正確性。

在實踐中，代碼檢查比動態測試更有效率，能找到更多的缺陷，通常能發現30%～70%的邏輯設計和編碼缺陷。代碼檢查非常耗費時間，而且需要專業知識和經驗的積累。代碼檢查定位在編譯之后和動態測試之前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。

代碼檢查可以發現的軟件問題包括：聲明或引用錯誤、函數/方法參數錯誤、語句不可達錯誤、數組越界錯誤、控制流錯誤、界面錯誤和輸入/輸出錯誤等。

1、代碼檢查

代碼檢查包括桌面檢查、代碼走查和代碼審查等方式，主要檢查代碼和設計的一致性，代碼對標準地遵循、可讀性，代碼邏輯表達的正確性，代碼結構的合理性等方面；發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型檢查、程序邏輯檢查、程序語法檢查和程序結構檢查等內容。下面對代碼檢查的三種具體方式進行介紹。

桌面檢查

是一種傳統的檢查方法，由程序員檢查自己編寫的程序。程序員在程序通過編譯之后對源代碼代碼進行分析、檢驗，并補充相關的文檔，目的是發現程序中的錯誤。

代碼走查

代碼走查就是針對代碼，在假想的輸入情況下，逐行的瀏覽代碼，走查代碼中潛在的缺陷并記錄結果的過程。

代碼走查以小組會議方式進行，每小組3-5人。與代碼審查不同的是，走查要求與會者扮演計算機的角色讓測試用例沿被測程序的邏輯運行，是在模擬動態測試；而代碼審查更多的是靜態測試。

代碼審查

代碼審查是由一組人通過閱讀、討論和爭議對程序進行靜態分析的過程，以小組會的方式進行。

審查小組一般由若干程序員（包括程序代碼的設計者）和代碼檢查人員組成。會前把設計規格說明書、控制流程圖、程序文本以及要求、規范、錯誤檢查清單交給與會者，開會時程序作者朗讀解釋程序，其他人則集中精力，捕捉程序在結構、功能、編碼風格等方面的問題。

2、代碼檢查項

代碼檢查項即檢查代碼時，指定需要進行檢查的內容。具體如：檢查變量的交叉引用表；檢查標號的交叉引用表；檢查子程序、宏、函數；等價性檢查；標準檢查；風格檢查；選擇、激活路徑；對照程序的規格說明，詳細閱讀代碼，逐字逐句分析；補充文檔。

檢查項可以作為依據，用來編制代碼規則、規范和缺陷檢查表等。

3、編碼規范

編碼規范是程序編寫過程中必須遵循的一套事先約定或者已經制度化、標準化的規則集，一般會詳細的規定代碼的語法規則和語法格式。

一個良好的編碼規范能夠帶來許多好處：改善代碼質量；提高開發進度；增進團隊精神。對于軟件開發而言，采用好的編程規范，雖然不能徹底杜絕糟糕的代碼產生。但對于代碼檢查和將來的代碼維護，仍然是意義重大的。

4、缺陷檢查表

在進行人工代碼檢查時，使用代碼缺陷檢查表作為代碼檢查的參考依據。在軟件測試項目實踐中代碼缺陷檢查表又常被稱作代碼檢查清單。

代碼缺陷檢查表中一般包括開發人員容易出錯的地方和在以往的工作中遇到的典型錯誤。對應于不同的編程語言，代碼缺陷檢查表的具體內容將會有所不同。例如：對于C/C++語言代碼缺陷檢查表內容有以下幾部分：文件結構；文件的版式；命名規則；表達式與基本語句；常量；函數設計；內存管理；C++函數的高級特性；類的構造函數、析構函數和賦值函數；類的高級特性；其他的常見問題等。

5、代碼檢查規則

在代碼檢查中，需要依據被測軟件的特點，選用適當的標準與規范。在使用測試軟件進行自動化代碼檢查或輔助代碼檢查時，測試工具需要內置許多編碼規范。不同編程語言，對應的檢查規范有所不同。針對與C/C++語言的規則有以下幾類規則：通用規則、C++編碼規則、C編碼規則、Meyers-Klaus規則以及自定義規則。使用時，需要根據編程語言和被測程序的特點，選擇適當的規則進行檢查。

6、靜態分析

靜態分析是不執行程序，而分析程序代碼的過程。源代碼被靜態分析器分析之后，得到的靜態分析結果，通常可以表示成一棵靜態語法樹。其中包含了被測項目源代碼的靜態結構信息：基本代碼成分、程序結構、語句結構、類型和模板等信息。

程序代碼靜態分析的結果能夠給代碼檢查提供幫助。

三、代碼檢查過程

傳統的代碼檢查是一種靜態檢查程序的測試方法，通常以團隊的形式來進行。檢查團隊由程序作者，一個負責人，一個記錄員以及一些檢查員組成。首先需要一系列的準備工作，包括參與者的挑選和材料的準備。然后是個人準備階段，每個小組成員各自熟悉材料。個人準備階段后，就是實際的檢查會議。在會議上，檢查小組在假想的輸入下，由程序作者帶領，逐行的瀏覽代碼，評審代碼中潛在的缺陷。檢查小組根據發現缺陷的嚴重程度和類型對其進行分類，并將問題記錄下來供作者修正。會議后是作者的返工，作者匯報每個缺陷，最后確認每個缺陷已經被陳述過了。圖 11為傳統的代碼檢查過程。

圖 1 代碼檢查過程示意圖

代碼檢查過程中的兩個重要階段“個人準備”和“召開會議”階段有以下注意事項：

1、“個人準備”階段：

會前準備階段是檢查過程的一個關鍵階段，因為如果檢查者沒有為檢查做好充分的準備，檢查效果會大打折扣。如果有檢查人員沒有做好準備，主審員可取消其代碼檢查資格，甚至取消這次檢查會議。

檢查人員要熟悉檢查內容的相關文檔，了解程序背景、設計思想和編程方法，在讀懂、“吃”透代碼的基礎上，查出盡可能多的錯誤。

2、“召開會議”階段：

參與會議的檢查者應具有一定的專業技能和經驗，缺乏經驗的檢查人員必然缺乏合適的領域知識來深入理解材料；

參與會議的檢查者應做充分的個人準備，沒有做充分準備的檢查人員不能在檢查會中做出實質性的貢獻；

檢查會議的速度應進行控制，如果試圖在短時間內處理太多的材料，檢查效果也會大打折扣?，F在較為常見的代碼檢查速度上的建議為：匯編代碼150行/小時，C語言150行/小時，而對于C++、Java這種面向對象語言，代碼檢查速度可以提高到200-300行/小時。

由此可見，代碼檢查適合于采用工具輔助的特性有：文檔處理，個人準備，會議支持，數據收集。

文檔處理

這是工具可支持的最明顯的領域。傳統的檢查要求分發每份文檔的復印件等，而將紙質的文檔替換成計算機式的文檔，不只是簡單的介質變更，更是提供了一種契機——提高文檔的可用性和表示性的機遇。

個人準備

首先，自動的缺陷檢測可以用來發現簡單的缺陷。如果簡單問題能被自動發現，檢查員就能專注于更加復雜/困難的缺陷，以及那些不能被自動發現的、潛在的、可能帶來更大影響的問題。另外，自動化工具應該對個人準備階段提供更多的幫助。例如，檢查員可以利用檢查表以及其它支持文檔，并能很容易地交叉引用它們；還有些代碼輔助理解工具，可為檢查員理解程序、了解程序結構提供幫助。? 會議支持

一些成員由于某些原因，可能沒有花費足夠的時間來進行準備，但他們仍然參加會議并試圖掩蓋他們的過失。項目管理人員可以使用計算機監控的個人準備時間信息，來剔除那些沒有做好個人準備的成員，或者督促他們投入更多的努力。

召開會議時，檢查員通常面對的是一堆枯燥的程序代碼，如果在代碼之外再結合一些圖、表等便于分析、理解代碼的信息，相信檢查會議可以進行得更加有序和高效。

數據收集

代碼檢查一個重要的部分就是度量信息的收集，用來提供反饋以改進檢查過程。度量信息包括會議時間、發現的缺陷、檢查花費的總時間等。根據這些數據，可以來評價每一次代碼審查的質量，進而給出關于代碼審查的改進建議。

通過對檢查過程的部分階段提供計算機支持，代碼檢查可以進行得更加有效。使用計算機來支持檢查過程，可以提高效率，并增加檢查過程的嚴格性。

四、代碼檢查歷史數據

代碼檢查中的歷史數據本質是軟件問題（缺陷）。按照不同的代碼檢查角度，存在多種對缺陷分類的方法。對過往發現的軟件問題進行分析，總結出今后對于類似的代碼需要按照某種規則來加以檢查，這種的規則就是檢查清單上的一條清單項，代碼檢查清單就是大量規則的集合。此外，由于軟件問題總是以軟件問題報告為載體形式出現，因此軟件問題報告也被通俗的理解為代碼檢查歷史數據。

下面對缺陷分類、代碼檢查清單和軟件問題報告加以研究。

1、缺陷分類

關于缺陷分類存在以下幾種常見的劃分方式：

1）按缺陷出現的區域分類

這種分類方式是最常見的缺陷分類方式。按照出現區域將代碼缺陷劃分為變量級、屬性級、函數/方法級和類級缺陷。其中，變量級、屬性級和部分函數/方法級的缺陷，與傳統的面向過程編程中的缺陷分類基本一致；而多數方法級缺陷和類級缺陷，則是針對面向對象技術編程特點提出的。

2）按檢測內容分類

分為沖突、一致性問題兩種。

沖突對應于文獻[1]中的基于確定性“信念”的判定，而一致性問題則對應于基于可能性“信念”的判定。

3）按對代碼的危害分類

按照對代碼的危害，一般分為浪費時間和空間；語義混淆；暴露封裝性，擴大使用權限；程序一致性問題；程序約束條件問題和空指針問題等。

2、代碼檢查清單（Checklist）

代碼檢查過程中，代碼檢查人員都會有一份代碼檢查清單。代碼檢查清單是一份為代碼檢查人員準備的缺陷檢查表，檢查表中開列所有可能與代碼有關的缺陷，并注明了檢查的內容、缺陷類型以及嚴重性。檢查清單是檢查代碼的依據，代碼檢查人員根據它來發現并判斷問題。代碼檢查清單中會逐條列出所有應該檢查的缺陷種類，以及每條缺陷的各種特征，并且根據缺陷的嚴重程度和類型對其進行分類。通常每一條缺陷的特征描述如下：

1）缺陷描述：該缺陷的問題描述、舉例說明，以及相應的正確形式；

2）缺陷出現的區域：分別為表達式級、語句級、聲明級、模板缺陷、預處理缺陷、類級缺陷以及性能缺陷。表達式級、語句級、聲明級以及預處理的缺陷，主要面向過程程序中的缺陷；模板缺陷、類級缺陷，則是針對面向對象軟件的特點提出的；代碼冗余等歸為性能缺陷；

3）缺陷對代碼的危害：代碼中出現某種缺陷將會造成什么樣的影響。

例如，檢查表中一條缺陷的特征描述如下：

問題描述：指針所指內存釋放后沒有將指針賦為NULL。

舉例說明：

char *p=(char *)malloc(100);strcpy(p, “hello”);free(p);//p所指的內存被釋放，但是p所指的地址還是不變 …

if(p!=NULL)//沒有起到防錯的作用 { strcpy(p, “world”);//出錯 }

正確形式：在釋放內存的同時將指針置空。

char *p=(char *)malloc(100);strcpy(p, “hello”);free(p);p=NULL;//增加指針置空語句

…

if(p!=NULL){ strcpy(p, “world”);}

出現區域：語句級。

危害：指針被free釋放后其地址并不會自動發生改變（非NULL），p成為了“野”指針，這種情況下再對p進行操作，很容易造成程序崩潰，后果非常嚴重。而代碼檢查清單正是由若干條這樣的缺陷特征描述構成的。

3、軟件問題報告（Software Problem Report）

在軟件測試過程中，對于發現的每個軟件問題（缺陷），都要進行記錄該錯誤的特征和再現步驟等信息，以便相關人員分析和處理軟件問題。為了管理測試發現的軟件問題，通常要采用軟件問題報告數據庫，將每一個發現的軟件問題輸入到軟件問題報告數據庫中，軟件問題報告數據庫的每一條記錄稱為一個軟件問題報告。

軟件問題報告包括頭信息、簡述、操作步驟和注釋。

頭信息包括：被測試軟件名稱、版本號、缺陷或錯誤類型、可重復性、測試平臺、平臺語言、缺陷或錯誤范圍。并要求填寫完整和準確。

簡述是對缺陷或錯誤特征的簡單描述，可以使用短語或短句，要求簡練和準確。

操作步驟是描述該缺陷或錯誤出現的操作順序，要求完整、簡潔和準確。對命令、系統變量、選項要用大寫字母，對控件名稱等要加雙引號。

注釋一般是對缺陷或錯誤的附加描述，一般包括缺陷或錯誤現象的圖像，包括其他建議或注釋文字。

軟件問題報告是軟件測試過程中最重要的文檔之一。它記錄了軟件問題發生的環境，軟件問題的再現步驟以及性質的說明，而且還可以跟蹤軟件問題的處理過程和狀態。軟件問題的處理進程從一定角度反映了測試的進程和被測軟件的質量狀況及改善過程。

五、代碼檢查規則管理的研究

1、潛在的編碼規則和缺陷代碼模式

潛在的編碼規則（Implicit Coding Rules）和缺陷代碼模式（Bug Code Pattern）是Tomoko MATSUMURA在文獻[3,4]中針對代碼檢查實踐，提出的兩個相關的概念。

潛在的編碼規則

潛在的編碼規則包含以下幾個特征：

1）不同于在開發啟動時明確決定的“編碼規范”的規則，這些規則在長期的測試/維護過程中是潛伏的，對這些規則的發現是不可預見的。

2）這些規則很少在設計文檔或者特定的文檔中被清楚的描述。他們通常只存在于開發人員、測試/維護人員的記憶中。換言之，是一種尚未系統化的經驗積累和總結的結果。

3）不同于使用規范庫的公用規則。對于特定的軟件有其特定的規則，這也意味著對于不同的軟件有不同的潛在的編碼規則。

4）由于違反潛在的編碼規則導致的缺陷通常情況下不是那么容易發現的。其中相當多一部分只在特定的罕見的情況下發生，所以在早期要想發現這些問題是很困難的。

5）目前，還不存在好的工具或者檢查清單來發現違反潛在的編碼規則的代碼片段，通常的檢查工具（例如PC-Lint、Purify）和通用的檢查清單只能發現常見的問題。

6）為了減少違反潛在的編碼規則的現象的發生，而進行重構通常很困難。要重構一個軟件，準確理解代碼是非常必要的，然而，老的系統太復雜，并且沒有精確的文檔和了

解系統的專業維護人員。總之，重構過期系統的代價很大，需要冒很大的風險。

缺陷代碼模式：違反潛在的編碼規則的編碼模式。

缺陷代碼模式不是肯定會導致缺陷的發生，一段符合缺陷代碼模式的代碼片段，并不意味著代碼片段一定就有缺陷，缺陷代碼模式只是疑似存在缺陷。另一方面，因為缺陷代碼模式是靜態的，沒有考慮到代碼片段之間的動態關聯。需要代碼檢查人員或者維護人員把符合缺陷代碼模式的代碼片段提出來，并判斷究竟是否存在缺陷。

在軟件開發過程中發現和建立缺陷代碼模式有三條主要途徑。其一：在進行代碼檢查過程中，代碼檢查人員發現一個軟件問題的同時，根據對該問題是否具備代表性和通用性等因素的考慮，確定是否建立一個缺陷代碼模式；其二：當軟件失效或者發生問題，檢查對應的代碼部分，發現并確定是否有潛在的編碼規范與之相關；其三：分析現存的代碼規范和積累的大量問題報告，從中提煉出潛在的編碼規則。

在文獻[3,4]中還給我們介紹了一個代碼缺陷檢測系統的大致工作流程，如2所示。

圖2 缺陷檢測模型系統的代碼檢查流程參考圖

2、C++代碼檢查規則類型

1）規則層次

在代碼檢查工作中常?？梢园l現這樣的現象：有些規則能在所有的項目中都能發現問題，另一些規則所能發現的問題只存在于某類項目中。

根據規則的這個特點，如圖 33中所示，參考文獻[2]中將代碼檢查規則分為兩個層次：

公共規則（General checks）：用于檢查在大多數情況都有可能發生的缺陷。

項目相關規則（Project specific checks）：用于在項目中檢查可能的缺陷。

圖 3 一個典型的代碼檢查規則清單節選圖

在項目中積累了大量軟件問題報告歷史數據的支持下，可以從中進一步細化出與項目或開發人員相關的檢查規則。

在學習任何一種計算機編程語言時，總是按照基本數據類型－>表達式－>語句－>復雜語句－>函數－>整個程序體(類)的順序逐步學習的。事實上軟件正是按照這樣的順序自下而上逐層組建起來的，代碼缺陷作為軟件編程寫時的一種異常情況，毫不例外也是按照這樣層次的構建而成。在實際測試項目的代碼檢查過程中，我們發現在每個層次上都有可能存在潛在代碼缺陷，要找到引起軟件問題的根源，要求在盡可能低的層次上找到引發缺陷的代碼。正因如此，非常有必要在C++語法的每個層次上都建立相應的檢查元規則。

圖4為一個代碼檢查規則體系模型圖[2]，圖中展示了在代碼檢查項目開始前，通過逐級組合各種元規則和規則形成新的檢查規則，最后形成了初始的檢查清單。在項目實踐中，經過對缺陷代碼模式的推導，進而得到擴展的檢查清單。初始檢查清單和擴展檢查清單本質上并沒有什么區別，只是因為形成的時間不同。

圖4 代碼檢查規則體系模型圖

在檢查代碼時我們有時會想要定義一個帶有否定意義的規則，如“在AA情況下如果沒有BB，則可能存在一個問題”。這類檢查規則采用自然語言描述比較容易，但是要用代碼實現起來往往并不簡單，并且對這類規則的定義和維護也比較麻煩。定義組合規則，是解決這類問題一種變通的方法。

下面簡單介紹一下定義組合規則的原理。如圖5中所示定義三個規則，“滿足情況AA”對應規則R1，“滿足在AA情況下出現BB”對應規則R2，將滿足R1但不滿足R2（即以！符號表示）組合則對應規則R3－“在AA情況下如果沒有BB，則可能存在一個問題”。

圖5 組合規則示例圖

根據前面討論，本文將代碼檢查的規則分類設計如下：

公共規則?

定義針對函數體（含）以上層次的檢查規則，在這些層次上出現的缺陷問題一般不容易精確到具體的代碼行。

關鍵字規則?

針對每個關鍵字定義的檢查規則。由于關鍵字是C++語法中一種最普通的元素，單獨使用關鍵字規則的意義不大，一般情況需要和語句、表達式規則或者復雜語句規則配合使用。

語句/表達式規則?

針對基本語句類型或基本表達式定義的規則，滿足對應結構的表達式，則可認為符合了相應的表達式規則。語句/表達式規則中可以包含多個關鍵字，在同一語句/表達式規則中包含的關鍵字地位是平等的，與檢查的先后次序無關。

復雜語句塊規則?

針對條件、開關選擇等多分支語句定義的規則，通常由關鍵字、語句/表達式進行組合來定義復雜語句塊，并在定義時可以進行嵌套，在定義復雜語句塊規則加入語句或表達式和復雜語句時需要考慮檢查的先后次序。

高級組合規則?

關鍵字規則、語句/表達式規則和復雜語句塊規則合稱為普通規則。

對于難以使用普通規則定義方式定義的復雜語義，需要定義高級組合規則。定義高級組合規則可以使用上面幾種規則作為基本單元，也可以嵌套使用其它組合規則。

圖6為一個由下至上、由多個缺陷代碼模式組合形成的組合規則結構圖。其中{}表示某條缺陷代碼模式對應的規則。

圖6 組合規則結構圖

六、代碼分析方法

1、靜態分析

靜態分析主要對源代碼進行詞法分析、語法分析，提取被分析程序的靜態信息，所提取的靜態信息是代碼缺陷檢測的基礎。靜態分析結果主要包括三部分信息：

程序定義信息：程序定義信息包含了程序中所有的定義和聲明信息，如類定義、方法和數據成員的定義、方法內局部變量的定義等。

程序結構信息：主要指方法內的控制流信息和方法間的調用關系。靜態分析器分析程序的語句分支、分支間的嵌套關系和方法調用，記錄方法的控制流信息和調用信息，構造語法樹。

分支內的變量操作：以方法控制流程中的分支為基本單元，記錄每一分支中各語句對各變量施加的操作和操作序列。

2、數據流分析

數據流分析也是一種靜態代碼檢查方法。它是在不通過計算機運行被測程序的條件下，利用預先進行靜態分析后獲取的信息，檢測對變量的賦值與使用操作中，是否存在不合理情況，即找出被測程序中是否存在變量在使用前未被賦值；變量在兩次賦值之間未被使用；一個變量在被賦值后是否未被使用等異常情況。

數據流分析目前的主要用途大多局限在編譯器的實現和優化技術方面，而在代碼檢查系統中實用的數據流分析技術并不多見，主要集中在某幾種缺陷檢測上，如賦值引用異常檢測以及內存錯誤檢測，使用方式主要是定義數據流操作的符號，使用該符號系統構造數據流表達式（由數據操作符號構成的符號串），再分析該符號串來確定是否存在代碼缺陷。

數據流分析包括以下兩個步驟：一是分析程序的所有邏輯路徑；二是對所有邏輯路徑上的所有變量，分析其所有操作序列，然后將得到的操作序列輸入自動機進行分析。因此數據流分析方法不可避免的存在以下缺點：

1）信息量多，上面所述的數據流分析方法是一種窮舉法。事實上一個變量在大部分路徑上存在問題的幾率并不高，因此窮舉每個變量的所有操作序列不可避免的要分析很多正確的信息，而且信息量巨大；

2）組合爆炸，當程序復雜度增長時，該分析方法的復雜度呈幾何級數增長，并且當這種組合是建立在對所有邏輯路徑、所有變量的窮舉基礎上時，如果不能找到一個非常高效的算法，數據流分析方法將是一個非常低效的方法；

3）實用性低，上述兩點導致的數據流分析的實用性降低。

為緩解這些的缺點，數據流分析過程有許多改進方法，但實現都具有一定難度。本系統中數據流分析不是重點，采取的策略是盡可能簡化數據流分析的過程，或者在可能的情況下盡量避免數據流分析。

第四篇：代碼注釋格式

////////////////////////////////////////////////////////////////////////// //函數名稱: WriteFile //函數功能: 向加密鎖創建文件,并且向文件中寫入數據,注意寫入的數據不宜過大,最好少于2k為最佳 //參數說明: fileSize: 文件的大小,以字節為單位 // fileID: 文件在加密鎖中的ID, // fileName: 文件在加密鎖中的名字 // fileContent: 文件內容

//返 回 值: 如果寫入文件成功,則返回true,如果寫入文件失敗,則返回false.//作 者: luyao ///////////////////////////////////////////////////////////////

第五篇：代碼工作計劃

2015年個人工作計劃 自從2014年年初進入公司工作以來，在公司領導的關懷和指導下，在公司部分同事的大力支持下，我在工作和生活上都學到了很多。2015年公司將全面壯大，各項規章制度逐步健全，尤其是軟件部將更加繁忙更加充實，公司的壯大將給公司員工提供更加優質的工作環境和更加廣泛的發展空間。俗話說,欲行千里,先立其志。想要在2015年新的一年工作有條不紊、順利的完成，就應該先行一步，做好工作計劃。

我的計劃分為兩塊一是個人發展目標及計劃安排，二是個人工作目標及計劃安排。

首先說一下個人發展目標及計劃：

由于自己接觸公安行業時間還比較短，自身經驗和處事能力、人際關系方面都需要全面提高。一方面，自己認真努力完成工作，并對自己的工作進行自查，自我監督。另一方面，離不開公司領導的關懷指導和公司同事的幫助?！叭诵斜赜形規煛?，我會虛心向領導和各位同事請教相關問題。

加強自己工作中闡述問題的能力和分析能力以及解決問題的能力，不斷學習新技術與知識，讓自己更能適應新的需求發展變化，給自己制定短期目標并完成它。在業余的時間我將補充項目管理方面的知識、軟件架構及設計的深入學習，積累新的知識點，提升專業技能。

在個人工作目標及計劃安排方面，有以下幾點：

項目上

計劃抽時間去一趟客戶那邊，給客戶演示一下我們的系統，讓客戶了解我們系統的相關信息。與客戶討論并且記錄客戶提出的意見以及需要調整的需求，進一步完善產品。與客戶討論下一步計劃及相關后續事宜。

整個研發團隊必須積極配合公安及用戶的安裝培訓工作，在實踐中不斷探索、不斷完善不斷豐富產品的功能。并在人力資源充足的前提下對業務進行深挖，提升產品亮點及市場競爭力。以便在其它省份進行推廣。

帶新人

大多數新人，用我們領導的話說就是“被動人”，是完全依照計劃做工作的角色，當然原因是多樣的，對于新人，不知該如何工作，只能按照上面的計劃進行工作。當然也有一群人意識不行，不知道給自己找事干，于是一直處于被動狀態。處于這個狀態時一定要努力讓自己盡快擺脫這個狀態，不要以完成任務為目標，這樣才能朝著更高更遠的方向發展。在2015年將更加注重團隊新新人的培養，把自己學到的教出去以及從外部

學習。同時在這個過程中，學會做計劃。“因材施教”是很難做到的，而對新人教育計劃的制定能夠在很大程度上鍛煉規劃能力以及識人用人能力。我希望在這方面有所提升。

團隊源代碼管理相關工作

源代碼管理是我們工作中很重要的一部分，是開發團隊的生命。為保障公司源代碼和開發文檔的安全，保證源代碼的完整，我們要讓每個成員理解基本的，核心的版本控制的概念，明確公司源代碼控制管理的流程。

我們研發團隊將合理安排產品開發的整個周期的工作內容和時間，積極配合部門完成新產品的開發工作，確保全部工作在預算范圍內按時優質地完成，使客戶滿意，使公司滿意。

1、對新入職員工進行公司開發環境及常用工具軟件培訓，以便快速上手投

入到工作中。

2、產品開發前完成對軟件開發生命周期規劃、軟件的架構設計等等工作

3、現有系統日常維護以及培訓等工作，確保系統良好運轉提升客戶滿意度。篇二：工作計劃書范文 工作計劃書范文

工作計劃格式

工作計劃是一個部門在一定時期內的工作打算。寫工作計劃要求簡明扼要、具體明確，用詞造句必須準確，不能含糊。(一)工作計劃的格式： 1.計劃的名稱，也就是標題。內容包括訂立計劃部門的名稱和計劃期限兩個要素，如“團委××部門××工作計劃”或者“工作計劃——團委××部門××”。2.計劃的具體要求。一般包括工作的目的和要求，工作的時間、內容，實施的步驟和措施等，也就是為什么做、做什么怎么做、做到什么程度。3.最后寫訂立計劃的日期。(二)工作計劃的內容。一般地講，包括： 1.工作背景，也就是情況分析(制定計劃的根據)。制定計劃前，要分析研究本部門工作現狀，充分了解下一步工作是在什么基礎上進行的，是依據什么來制定這個計劃的。2.工作目的，指的是工作任務和要求(做什么)。根據需要與可能，規定出一定時期內所應完成的任務和應達到的工作指標。3.工作的方法、步驟和措施(怎樣做)。在明確了工作任務以后，還需要根據主客觀條件，確定工作的方法和步驟，采取必要的措施，以保證工作任務的完成。(三)制訂好工作計劃須經過的步驟： 1.認真學習研究上級的有關指示辦法。領會精神，武裝思想。2.認真分析本部門的具體情況，這是制訂計劃的根據和基礎。3.根據上級的指示精神和本部門的現實情況，確定工作方針、工作任務、工作要求，再據此確定工作的具體辦法和措施，確定工作的具體步驟。環環緊扣，付諸實現。4.根據工作中可能出現的偏差、缺點、障礙、困難，確定預算克服的辦法和措施，以免發生問題時，工作陷于被動。5.根據工作任務的需要，組織并分配力量，明確分工。6.在實踐中進一步修訂、補充和完善計劃。計劃一經制定出來，并經正式通過或批準以后，就要堅決貫徹執行。在執行過程中，往往需要繼續加以補充、修訂，使其更加完善，切合實際。

企業個人計劃書范文

年伊始，萬象更新。自從xx年年底將工作的重心放在企業erp系統實施的工作中時，在公司領導的關懷和指導下，在公司部分同事的大力支持下，對erp相關工作作出了初步的整理。2011年公司全面壯大，各項規章制度逐步健全，尤其是5月份城陽總部的成立，給公司員工提供了優質的工作環境和廣泛的發展空間。俗話說的好：“笨鳥先飛!”

想要在201x年新的一年工作有條不紊、順利的完成，就應該先行一步，做好工作計劃。

自身建設方面：由于自己參見工作時間比較短，自身經驗和處事能力、人際關系方面都需要全面提高。

一方面，自己認真努力完成工作，并對自己的工作進行自查，自我監督。

另一方面，離不開公司領導的關懷指導和公司同事的幫助?！叭诵斜赜形規煛?，我會虛心向領導和各位同事請教相關問題。

工作方面：

一、公司erp的現實狀況。對于我們公司來說，erp――k3系統，還是一個比較新鮮的事務，雖然我們每天都在說k3，但是，現在k3系統在我們公司運行上線還處在初步的階段。目前，只有倉儲部――倉存模塊和財務部――總賬模塊、應收應付和存貨核算，對系統實施了比較全面的應用，第一期計劃范圍內的公司供應鏈中的銷售模塊和采購模塊，還只是用了一些皮毛，公司其他部門還沒有實現信息化。另外，公司現行的k3系統編碼方案規則不合理，存在中文、英文、字母和希臘文字共同組成的編碼以及重碼、無碼現象。編碼權限下放，造成編碼規則不能很好的執行，編碼混亂。公司試用一段時間的條形碼也不是國際通用，給人造成產品不入流的假象。還有，因這是一期遺留項目問題，我個人對k3的相關經驗不是很多，實施起來需要金蝶公司的配合。但目前看來，配合還是有些問題需要協調。

二、3月份工作計劃的安排。針對上述公司erp運作方面出現的公司現實存在的狀況，整個三月份，擬計劃三月底完成公司k3系統物料編碼的調整工作，實現新舊代碼的轉換以及一期項目中的銷售模塊和采購模塊的培訓，實施和上線后相關問題的解決維護。

具體工作安排如下： 1.物料編碼的調整：因年前相關工作的調整，物料編碼的調整推遲了一個月，中間舊的物料編碼又新增了很多，給這一塊的工作造成了一定的難度。整個物料編碼的相關工作會貫穿整個三月。這中間需要相關部門的配合。我個人這方面同時做新舊代碼對照和新代碼審核及每天新增編碼的修改，工作內容、工作量比較大，需要增加短期配合工作的工作人員和我一塊工作。另外，因為本人一直從事公司辦公室、后勤等相關工作，對公司的生產線、產品不甚熟悉，中間可能有很多產品物料編碼方面的問題需要和相關部門同事進行溝通交流，希望本著為了公司的長足發展，能夠得到領導和同事的配合。2.銷售和采購模塊的實施：通過與金蝶相關實施人員的協調聯系，在三月份訂出時間，請實施人員過來對我們這兩個模塊的相關使用做一下培訓并跟蹤指導，同時對我們的物料編碼工作進行指導配合。上線實施后，相關軟件操作、運行方面出現的問題進行跟蹤解決和系統維護。

三、下一步工作計劃的安排。1.定期做好k3系統服務器的維護、備份工作。保障k3系統的正常運行。針對單機用戶使用k3系統出現的問題，進行處理。2.針對公司戰略決策中的時間安排對201x年內需要實現信息化的部門進行調研。

將第二期計劃中需要上線的系統模塊分四部實施：

首先，與系統上線運作相關部門組成相關的項目小組，對項目進行分析、調研，把相關的業務需求整理并確認實施方案。

其次，將系統能夠實現的相關業務需求，對業務流程進行梳理、微調(企管部、相關部門配合)，并對系統上線模塊進行培訓和技術指導。在次，對上線相關模塊進行測試運行，出現的相關問題有針對行的解決和完善。

最后，系統正式上線運行期的維護以及運行期問題的反饋和總結，給以后系統實施提供寶貴的工作意見和經驗。

四、其他工作計劃的安排。

除了工作重點k3項目外，還有其他幾項工作安排： 1.配合人力資源部把玉舟人力資源系統全面運行上線，實現系統最大最優化發展。2.配合網管對公司的辦公自動化系統和郵件服務器擬定計劃，實施。3.公司的網站進行頁面的更新維護和公司的網站服務器的建立。4.領導交辦的其他工作。

五、針對公司發展提出的建議在日紅公司工作的兩年時間里，對公司也有一定的了解，下面就公司的相關工作提出自己的意見和建議。因為搞物料編碼的原因，就前期對物料編碼的調研發現的問題總結如下:公司現在的編碼比較混亂,研發部門有自己的成品編碼,業務部門下定單的時候,有客戶訂單號和貨號,生產有自己的配件編碼,鍍一種顏色,就會有一種編碼,模具有自己的模具編碼，k3系統有自己的k3編碼。一款產品，會有幾個編碼，好幾個名字，到了一個部門，可能編碼就有變化，需要編碼對照，才有可能指導自己和兄弟部門可能其實是用的一個東西，只是叫法不同。這樣，很不方便。建議公司成立編碼部門或者小組，對公司所有的編碼進行整合，有必要的話，可以抹去客戶相關編碼，從訂單到我們業務員手里，業務員生產下單，公司一律走自己的編碼，出廠后(發貨)，由倉儲部(物流)在使用客戶相關編碼對照發貨。這樣切斷的好處有：跟客戶打交道的只有相關接口部門，這樣我們公司的相關技術信息也不會外露，以后公司發展壯大后有自己的品牌以后，公司的相關編碼，條形碼和進銷存流程也比較順暢，避免到時再整合物料編碼帶來的諸多麻煩。

以上，是我在201x年的工作計劃，感謝領導審閱及批評指正。祝我們日紅公司在201x年里與時俱進，勇創輝煌!篇三：某it公司2014年公司工作計劃

某it公司2014年工作計劃

一、銷售現狀

從2013年銷售額度完成情況來看，未完成項目的主要原因一是因客戶拖延導致項目進度延后，造成有些項目只能2014年開展；二有些重要客戶沒有及時拜訪，導致丟單。總結2013年的經驗與不足，在制定2014年的工作計劃時，要有針對性的對上訴問題，制定好的解決方案。

二、2014年定位：公司2014年公司定位：以產品為導向、開拓市場、推進項目、提高管理、招攬人才

三、目標

（一）2014年總體目標： 2014年公司的整體發展規劃是：突出核心產品優勢，提升研發、銷售的整體水平，以產品為主導，以優質的產品為依托，逐步實現整體目標。

1、提升銷售額度：2014年公司的銷售整體銷售目標為283.5萬元至469萬元

2、完善產品：根據企業目前的核心產品現實狀況，屬于尚未成熟。因此2014年企業總體目標是加強完善核心產品的開發。

（二）具體目標分解

1、完善產品目標 a、完善產品有哪些：1）網站后臺管理（加強版）2）在線考試管理系統 3）話單分析系統（升級版）4）企業網站模版設計 5）臉譜識別 b、整理出產品完善需求：盧、朱、田負責整理各個產品功能完善文檔 c、實施步驟 1）根據盧、朱、田整理完善文檔，召開產品完善會議，各部門主管參加； 2）按階段完成各個項目，朱根據原有產品進行產品設計架構、相關文檔的整理，并且安排具體工作；

3）程序員實施開發 4）測試部進行測試。d、時間：完善產品需要的時間為6個月

2、銷售工作目標 a、預計額度目標：軟件項目開發285.5萬元至477萬元（注：軟件項目和硬件項目是1134.5萬元至1326萬元）b、網站軟件目標分解： d

四、具體銷售策略 附近1：《業務具體定位策略》

（一）市場策略

吸取2013年銷售的經驗和不足，因此，將2014年確定為“市場推廣年”，全力以赴開拓市場，發展客戶、提高銷量。

1、總體策略：

1）實行“提供高品質產品，實現低交付成本 ”市場競爭策略； 2）以《話單分析》《臉譜》《在線學習的平臺》等為拳頭產品，以公檢法、政府、部隊為主推渠道，以黑龍江省市場為突破口。3）建立有效的銷售渠道和加強銷售隊伍建設；

2、營銷策略： 1）第一步：全公司必須以市場為導向，以營銷為重點開展經營和管理活動。公司制訂相關制度、流程、政策，規范、鼓勵全體員工參與營銷及管理工作。2）第二步：將公司研發的《話單分析》《臉譜》《在線學習的平臺》等軟件產品在黑龍江省公檢法、政府、部隊行業進行推廣，并挖掘客戶對相關產品的需求。3）第三步：采取一切措施，集中精力做好行業深挖的開發、老客戶的普及、新客戶挖掘鋪設。主攻方向是消防、省領導干部出、邊防、工大管院、檢察院等主要手客戶。

3、營銷手段

1）加強擴大公司知名度和影響力的宣傳工作，加強互聯網的宣傳力度。2）豐富公司網站內容，并與公安廳、消防總隊等重要單位機構的網站相鏈接。通過網頁宣傳、推廣公司的產品及服務，并為客戶提供網上咨詢、網上培訓。3）與各地消防、邊防部門、工大、企業保持聯系，建立一個對市場、對競爭對手反應靈敏、快捷的信息網絡體系。

4）重新設計企業的宣傳冊，突出企業的企業優勢、產品優勢等。5）銷售隊伍建設：鼓勵全體員工參與營銷及管理工作，加強與東亞銷售人員配合銷售工作。

（二）產品策略 2014年公司的整體產品策略是“品牌分級、產品多元”，即：在確保品質的基礎上，在產品功能、特性上改良產品的設計，使其多元化。并從產品的設計、價格、服務上對產品的品牌分級處理。始終圍繞客戶需求，以客戶需求為出發點和歸屬點，提升總體銷量，實現利潤總量最大化。為此，應采取下列措施：

1、調整主打產品，以《話單系統》、《學習的平臺》、《題庫管理》、《臉譜識別》為主打，網站建設作為鋪設，樹立自我品牌。

2、實行差異化的銷售策略： 1）產品差異：使我公司產品與競爭對手產品相比具有獨特優點。2）服務差異：服務模式，服務理念不同與競爭對手。3）人員差異：系統對公司營銷人員進行培訓，對公司產品要求掌握熟練，知道產品的優勢，能

為客戶解決什么問題。

（三）品牌策略

3、重點客戶拜訪：對重要的客戶和意向較大的客戶進行拜訪，現場銷售。

五、管理

（一）項目管理

1、項目總體控制： a、項目初期： 1）碰頭會：部門主管研究功能，做出項目計劃。2）項目計劃：總經理助理根據《項目計劃表》監督各個部門完成進度情況。b、項目實施：

1）項目總調度要實時跟進各部門項目進度情況。2）項目總調度要每周周六組織開發部（美工、程序、測試）例會，掌握現有項目的進度。c、項目收尾：

1）總經理助理負責項目結項后文檔、源代碼存檔后刻錄光盤。

2、文檔管理：

a、文檔分類：共10個文檔 1）開發部7份：《功能要求》、《項目設計方案》、《需求分析》、《系統分析》、《數據庫文檔》、《功能函數文檔》、《項目總結》 2）測試部3份：《測試計劃報告》《測試報告》《測試總結報告》《使用手冊視頻》 b、要求： 1）開發部文檔由項目經理負責整理完成，測試部文檔有測試部主管負責整理完成，交給項目總調度（盧）驗收查看。2）所有的項目都必須要文檔齊全，否則不能結項，任何項目少文檔，扣除相關部門負責人項目獎金2%。

3）項目文檔要求在項目完成后，與源代碼、數據庫一起集中封裝。4）電子版文檔要求在項目完成后一個月內完成調整刻錄成光盤備份。孫老師負責刻盤備份。5）未來可以放在相應服務器上然后建立相應的檔案管理系統對電子版文檔進行備份和管理。

3、源代碼管理：源代碼結構是指源代碼在版本管理服務器上存放的文件夾結構。源代碼結構的設定由項目實施負責人決定。a、源代碼結構設定有幾項基本要求： 1）必須設臵項目專屬文件夾：每一個獨立項目或子項目源代碼文件內，至少設定一個docs或doc文件夾以存放僅與該項目相關技術文檔和參考資料； 2）必須考慮支持庫：源代碼結構中，應考慮具體項目所引用的非標第三方支持庫或框架的存放位臵； 3）必須可以直接編譯：源代碼結構必須是可直接編譯結構。即任一臺新裝計算機，在安裝了必要的開發環境軟件以后，通過從版本管理服務器上簽出整套源代碼后，應該可以直接完成編譯 b、工作要求: 1）提交時間：所有參與開發的技術人員，每日5:30必須將當日所編制的源碼或技術文檔提交至版本管理服務器。2）審閱時間：5：30審閱是指項目實施負責人，每日下班前審閱版本服務器上所有下屬技術人員所提交的源代碼和技術文檔。

4、客戶數據管理：

1、資料收集：在公司的日常營銷工作中，收集客戶資料是一項非常重要的工作，它直接關系到公司的營銷計劃能否實現。客服資料的收集要求客服專員每日認真提取客戶信息檔案，以便關注這些客戶的發展動態。

2、資料整理：客服專員提取的客戶信息檔案遞交客服主管，由客服主管安排信息匯總，并進行分析分類，分派專人管理各類資料，并要求每日及時更新，避免遺漏。

3、資料處理：客服主管按照負責客戶數量均衡、兼顧業務能力的原則，分配給相關客服專員?？头T負責的客戶，應在一周內與客戶進行溝通，并做詳細備案。

4、客戶檔案建立。

（二）部門管理 附件2：《2014年各部門管理計劃》

（三）人員管理

1、梯隊建設（分工、檔次）開發部人員組建：

注：① 根據公司發展要求，核定部門人數（此為考核的基礎條件之一）； ② 以搶、挖、聘為主要形式；

③ 新員工履行培訓、考核、篩選、轉正流程； ④ 軟件部、美工部以優厚待遇搶、挖1名業內成手。⑤ 人才管理一定要注重梯次型培養，不可斷檔。

不定時的注入新鮮血液是團隊建設的一個重要手段；目的是要使團隊內的每一個成員都有不同程度的危機感：讓老員工有緊迫感，讓新員工有壓力感，煥發大家珍惜崗位的意識。

2014年各部門團隊建設計劃

根據2013年各部門情況，現美工部、程序部缺少中間力量，因此在2014年個部門需要招聘下： 程序部：高級程序員1人； 美工部：高級美工設計1人

2、合同（勞動、保密）

注：開發部所以部門（程序組、美工組、測試組、網絡營銷部）的全體員工都要簽署勞動合同和公司

保密合同。

（四）管理工作

1、工作原則： a、以銷售為主導工作，確保完成全年銷售任務目標 1）目標要具有合理性，可行性，制定目標要有從分的依據： ①于往年的公司業務完成情況。②前一年的市場鋪墊。③市場情況的分析機遇期。2）目標的嚴謹性。

①經過反復論證，討論后形成。

②對目標進行細化，分解，與市場、項目一一對應。③有落實直接責任人。

④有目標進程管理的負責人。公司總目標總經理負責，具體目標盧負責。b、從全局的角度上考慮問題，管理工作更加細致，執行到位、監督到位。1）掌控項目 2）跟進團隊 3）合理安排項目開發時間 4）項目溝通 5）團隊溝通 6）掌控項目風險 c、帶好新員工和下屬，讓他們感覺到融入到這個“家”中，感覺自己受到重視、能學到東西，不斷成長和進步了 1）員工生日：許姐提前一周提醒，單位送一份禮物給員工，幫助她調整心態的書、實用的工

具、有意義的禮物等，基本花費在100元以內，領導和同事寫祝福的話； 2）員工聚餐：項目完成或節假日組織員工聚餐，平均1—2個月一次，目的是增強凝聚力和篇四：計劃類別代碼

遼寧省科學技術計劃項目申報書

計劃名稱：

技術領域： 申報主題： 項目名稱： 項目負責人： 申報單位： 通訊地址：

郵政編碼： 電子郵箱： 聯系電話： 傳真： 主管部門： 申報日期：

申 報 說 明

一、本申報書專門用于遼寧省科學技術計劃項目的申報、立項等管理過程。

二、應用基礎研究計劃（即科技基金計劃），按專門格式與要求另行申報。

三、申報書由基本信息表、專項信息表、各類計劃項目可行性報告、申報單位及管理部門意見等四部分組成： 1.基本信息表：是各類基本計劃和專項計劃必報的通用表格。用于表述申報項目及負責人與申報單位簡況、項目組人員配備、項目相關基本信息摘要等。2.專項信息表：用于補充陳述基本信息表述部分尚未闡明的專項信息；原則適用于申報某專項計劃時對應填報，是申報書重要組成部分。4.申報單位及管理部門意見： ——申報單位簡況及推薦意見：單位基本信息由申報單位填報。單位推薦意見要簡明扼要。

——初審推薦意見；由各市科技局（或省直有關單位科技管理部門），發揮專家咨詢作用，提出初審推薦意見；

——復審推薦意見：由科技廳各類計劃歸口管理部門，依靠專家提出。

四、申報單位和申報者，可通過遼寧科技信息網“省科技計劃項目遠程申報系統”，按要求進行單位注冊，申請個人帳號，下載申報書軟件；填報統一的項目申報書可行性報告；按網上遠程申報填寫具體要求和提示，如實填寫申報內容。

五、受理編號、參審編號、批準編號以及項目類別，無須申報者填寫?！鯙檫x填標記，請按遠程申報填寫指南有關規范，單選或多選。

六、申報書陳述部分，一律用簡體中文、仿宋gb2312、小四號字體填寫；應文字簡潔，表述清晰，數據詳實；外來語要同時用原文和中文表達，首次出現縮略詞要注明全稱，再次出現同一詞時可使用縮寫；需提供紙質文件打印時，請用a4紙。

七、需提供有關證明材料的申報項目，應真實有效，編排有序，以書面形式報送科技廳歸口管理處室（一式1份）。自籌或匹配經費證明，須有申報單位及主管部門出據核準意見明確、帶有公章的函件。1.基本信息表 【1.1 基本信息簡表】 1.基本信息表 【1.2 項目組人員配備簡表】 1.基本信息表

【1.3 項目背景、主要內容與指標、創新點簡表】 篇五：浙江省科技計劃項目計劃類別代碼(2012版)浙江省科技計劃項目計劃類別代碼（2012版）

申報專項名稱

重大與高發疾病防治技術

重大自然災害預警和應急處置技術 水污染防治與水資源綜合利用技術 固體廢物綜合處置技術

海水淡化與海水綜合利用技術 可再生能源利用技術 高效節能技術 綠色化工技術

現代紡織與服裝加工技術及裝備 重大機電裝備 汽車及關鍵零部件設計制造技術 高檔皮塑加工技術及裝備 網絡、通訊技術及裝備 數字多媒體技術與應用 軟件與集成電路設計

重大應用電子技術和新型電子元器件 磁浮交通系統技術與裝備 100萬伏特高壓輸電技術與裝備 納米技術攻關及示范應用 生物制藥技術 中藥現代化

農業新品種選育技術

農產品質量安全與標準化技術 農業生物技術 工程農業技術

農產品（食品）精深加工技術

代碼 zx01 zx02 zx03 zx04 zx05 zx06 zx07 zx08 zx09 zx10 zx11 zx12 zx13 zx14 zx15 zx16 zx17 zx18 zx19 zx20 zx21 zx22 zx23 zx24 zx25 zx26 優先主題名稱

信息技術 生物技術 新材料技術 新能源技術 制造業信息化

嵌入式技術在傳統產業中的應用 生物技術推廣應用 新材料技術推廣應用 船舶修造 工業自動化 環保裝備

重大技術裝備 先進專用設備

數控裝備及控制單元 農業高技術 傳統農業技術升級 緊缺資源替代技術 資源綜合利用 工業污染控制

農村及城鎮生態環境建設 環境安全預警

海洋基礎設施的信息化技術開發與裝備 海洋生物綜合加工與利用 海洋生態與環境保護 人口與健康 公共安全

文化傳媒技術 電子商務技術 現代物流技術 智能交通技術

代碼 yt01 yt02 yt03 yt04 yt05 yt06 yt07 yt08 yt09 yt10 yt11 yt12 yt13 yt14 yt15 yt16 yt17 yt18 yt19 yt20 yt21 yt22 yt23 yt24 yt25 yt26 yt27 yt28 yt29 yt30

四、行業分類代碼

參照國標行業代碼填寫，由2位數字構成。