建設(shè)工程施工管理科目是二級建造師的基礎(chǔ)科目課程（點擊聽課>>）。該科目立足于建設(shè)工程項目整個建設(shè)實施的全過程，涵蓋了建設(shè)工程成本、進度、質(zhì)量、安全與環(huán)境、合同、信息幾個方面，內(nèi)容繁多，知識面廣泛，但是考試的重復(fù)性比較大，不要逐字逐句看書，跟著233網(wǎng)校老師走，學(xué)會抓重點，就必定能通過。233網(wǎng)校老師教你本科目通關(guān)秘籍，實施最保守的得分方法，你都能高分通關(guān)。單選通過排除法等各種問題技巧得分至少70%~80%的分?jǐn)?shù)，即49-56分。多選題盡量不要出現(xiàn)得0分的題目。除少數(shù)幾個絕對有把握的題，有幾個選幾個，得8分左右。剩下21個題目都只選2個選項，其中假設(shè)有4個題目正確答案就2個選項，得8分；剩余17個題目得一半分，即17分；多選題總分可得33分。此時總分至少為82分，能順利通過考試。

    項目文檔對于項目管理的作用已經(jīng)不用再講了，但文檔的管理卻又通常是項目管理中最容易忽略的內(nèi)容。實際對于任何一個項目而言，文檔一定要有的，但不一定要多，只要可以說明問題就行了。
    最近正在接手一個項目，就以此項目為例， 說一下我的體會。這個項目已經(jīng)開發(fā)完成，并且已經(jīng)上線運行，具備了一定的客戶群體。接手這個項目時，此項目只有成果，沒有過程。僅有一份完整的用戶手冊。
    針對此情況，提出要求，需補充以下文檔：
    一、《成果說明文檔》：需說明當(dāng)前所有可提交成果、成果內(nèi)容描述及成果評估。
    成果描述至少需要描述以下內(nèi)容：
    1）成果存在形式及現(xiàn)狀：針對軟件項目而言，基本上成果都是以可運行代碼形式存在，但在此一定要明確說明代碼的現(xiàn)狀，是否經(jīng)過測試，如果經(jīng)過測試，需提交相關(guān)的測試報告，如果沒有經(jīng)過測試，那是否已經(jīng)完成，完成后，如果未完成則進行到什么程度，尤其是如果沒有注釋的代碼，應(yīng)明確交代代碼實現(xiàn)的功能描述及接口描述。
    2）成果研發(fā)過程說明：主要說明成果的追溯過程，此代碼從何而來，是否具備相應(yīng)的計劃內(nèi)容，如果沒有，這成果的上一個環(huán)節(jié)是什么，以代碼為例，代碼上一個環(huán)節(jié)是否有設(shè)計，設(shè)計上一個環(huán)節(jié)是否有需求分析等等。這部分代碼是根據(jù)什么來進行的研發(fā)。如果某個成果沒有追溯到最初環(huán)節(jié)，就需要注意了，這部分內(nèi)容就是風(fēng)險了。
    3）成果可用性說明：并不是最終提交的成果就一定是有效、可用的。也許會隱藏很多的問題，這需要任務(wù)的相關(guān)承擔(dān)人進行可用性描述，我們作編碼的都知道，在特定的情況下，可能會采用一種臨時方案去實現(xiàn)一個功能，等最終集成時再去修正，但很多情況下這種臨時方案都成為了最終方案。所以，一定要對成果進行有效性說明，如果沒有的，就一定要進行嚴(yán)格的測試驗收。
    4）成果責(zé)任人說明：一定要有，不是追究責(zé)任，而是便于溝通。
    文檔制作說明：此文檔建議采用表格進行說明，如果可以建議采用excel，這樣便于使用跟蹤管理，如下： 
    
    二、《計劃管理說明文檔》：如果有完整的porject計劃是最好的，但此文檔一定要注意的是其準(zhǔn)確性，在用project進行計劃管理時，往往是項目進展時間越長，變更越多，計劃維護就越困難，此時就有可能計劃已經(jīng)無法反應(yīng)實際的項目進展情況了。
    計劃管理文檔一定要仔細(xì)研究，整個項目計劃是否安排妥當(dāng)，哪些任務(wù)制定了但沒有完成，哪些任務(wù)取消了，這些取消的任務(wù)是否是屬于預(yù)定的功能要求，哪些環(huán)節(jié)就沒有進行，哪些環(huán)節(jié)多次重復(fù)，有哪些人員工作過程中發(fā)生了任務(wù)的中斷變化，都可以從計劃管理說明文檔看出，這樣更有利于評估項目的實際情況，風(fēng)險情況，并可以根據(jù)前階段未完善的內(nèi)容進行后續(xù)完善。同時，很關(guān)鍵的一點是，這些任務(wù)中是否存在非正常情況，譬如：你認(rèn)為很難的技術(shù)研發(fā)工作在短時間內(nèi)卻已經(jīng)完成，這都需要注意，并了解實際情況。最終通過計劃管理說明確文檔定是否預(yù)定的目標(biāo)已經(jīng)全部完成。而已經(jīng)完成的內(nèi)容應(yīng)該和以上提交的成果說明是一致的，此部分如果不存在文檔，就需要根據(jù)相應(yīng)的成果內(nèi)容及人員對整個過程進行文檔補充。此文檔完成后，也可成為后續(xù)管理的一個基礎(chǔ)，進行優(yōu)化處理。
    如果沒有計劃管理文檔的話，補充的時候，則建議采用project來完成，前一個成果提交文檔，并且最好可以采用wbs來組織任務(wù)的安排，將已經(jīng)提交的對應(yīng)到相的任務(wù)中。通過前一文檔狀態(tài)的說明，將未完成的內(nèi)容做標(biāo)記，并且看是否存在同樣的任務(wù)不同的成果表現(xiàn)形式的情況，這時應(yīng)該是屬于重復(fù)性任務(wù)，也做標(biāo)記說明。 [page]    三、《需求說明書》：需說明產(chǎn)品的最初需求內(nèi)容實際對于我當(dāng)前接手的這個產(chǎn)品，需求說明書的重要性已經(jīng)大大降低了，因為產(chǎn)品已經(jīng)研發(fā)完成，且提供了完整的用戶手冊，但整理需求說明書的主要目的還是有兩個：
    1、是要建立完整的項目過程追溯流程，為后續(xù)工作做準(zhǔn)備。
    2、通過需求驗證成果的有效及可用性。
    需求說明書是一個可簡可繁的一個文檔，在這個項目中，需求說明書更多的是從用戶手冊中來提取需求了，實際的意義并不是很大。但如果是做一個新的項目，則需求說明書應(yīng)該是僅最大可能的對用戶業(yè)務(wù)進行一種還原描述，不要摻雜個人的理解。至于是否可以實現(xiàn)，怎么實現(xiàn)是后續(xù)工作的事情，不是這個環(huán)節(jié)的內(nèi)容。
    四、《系統(tǒng)設(shè)計說明書》：系統(tǒng)設(shè)計說明書現(xiàn)在在這個時候已經(jīng)無法在考慮設(shè)計的問題，但此時應(yīng)該提供以下內(nèi)容：
    1、系統(tǒng)的架構(gòu)設(shè)計及架構(gòu)在應(yīng)用過程的調(diào)整。并且最好可以提供架構(gòu)的弊病分析說明。
    2、接口設(shè)計說明及接口的詳細(xì)規(guī)格及設(shè)計說明?，F(xiàn)在的系統(tǒng)基本上都是松散的，通過接口標(biāo)準(zhǔn)從而最終實現(xiàn)系統(tǒng)的集成，所以，接口部分非常關(guān)鍵，這部分內(nèi)容一定要非常清晰和準(zhǔn)確。
    3、如果現(xiàn)在無法再提供設(shè)計文檔，則建議通過第三方工具，根據(jù)成果代碼反項生成設(shè)計，并在此基礎(chǔ)上進行文檔補充，看設(shè)計總比看代碼好很多，所以，這部分內(nèi)容應(yīng)該進行提供。如果在新項目中，此部分內(nèi)容頁建議考慮，主要是規(guī)劃接口調(diào)用、對象職能及對象關(guān)系。
    五、《數(shù)據(jù)庫設(shè)計說明書》我本人還是十分重視數(shù)據(jù)庫設(shè)計的，雖慮，主要是規(guī)劃接口調(diào)用、對象職能及對象關(guān)系。 
    《數(shù)據(jù)庫設(shè)計說明書》我本人還是十分重視數(shù)據(jù)庫設(shè)計的，雖然現(xiàn)在有很多的dao的工具，而且也倡導(dǎo)對象建模，但實際在應(yīng)用過程中，完全做到的的卻是少之又少，尤其是針對數(shù)據(jù)分析部分內(nèi)容。所以此文檔我認(rèn)為還是非常重要的。至于文檔的格式，因為此方面已經(jīng)非?！皹?biāo)準(zhǔn)”化了，就不在進行說明了。
    六、《測試報告》這個項目中是不需要了，如果是一個新的項目則建議由測試計劃起進行。
    基本上就是這么多了，應(yīng)該說文檔不少，但，是一個完整的流程，項目最初啟動的時候，應(yīng)該建立文檔規(guī)范，文檔不要多，但要可以對項目的每個環(huán)節(jié)都有描述說明的。我見過一個項目光需求說明就有很多份不同的文檔，很頭疼，而且后期的維護也會很麻煩。建議每個環(huán)節(jié)就一份統(tǒng)一文檔。制定大家習(xí)慣的閱讀方式（這點很關(guān)鍵，否則大家都不看），由大家共同維護完成。做一總結(jié)：《需求說明文檔》：建議先將需求進行分解，然后用表格進行說明。如果條件允許，那就用requisitepro管理需求，實現(xiàn)跟蹤。
    《系統(tǒng)分析設(shè)計文檔》：建議采用rose，需求用例一定要有，哪怕|考|試大|顆粒度大一些，在需求用例部分進行需求分析的說明，而且要說明規(guī)格要求。組件及類圖一定要有，規(guī)范接口調(diào)用規(guī)則，組織代碼結(jié)構(gòu)，建立良好的系統(tǒng)框架。其中說明組件或類職能。此部分不一定完全由設(shè)計人員完成。有可能的情況下，提供活動圖。程序員對活動圖的興趣要高于時序和狀態(tài)圖。可以用soda產(chǎn)生相應(yīng)文檔（只讀）供開發(fā)查詢使用。不一定一個rose文件，可以多個，如果要拆分，對應(yīng)需求拆分。
    《數(shù)據(jù)庫說明書》：建議用pd，然后自動生成文檔（只讀），供開發(fā)查詢使用。
    《測試報告》：可以用測試報告對成果進行說明，但我個人感覺《測試計劃》比《測試報告》更重要，因為沒有一個好的測試計劃進行指導(dǎo)，最終測試也就成為了一個成果描述環(huán)節(jié)了。
    其中，建議使用project進行項目計劃管理，最好可以用projectserver來進行跟蹤，這樣聯(lián)工作日志也可以省略了。
    采用版本工具進行文檔管理，一定要，非常重要。

二級建造師施工管理科目單項選擇題70題，每題1分，共計70分；多項選擇題25題，每題2分，共計50分；總計120分。大家根據(jù)233網(wǎng)校老師講課中的章節(jié)重難點指引，看最新教材進行預(yù)習(xí)，再來聽精講班老師解讀教材考點，聽課時就不會一頭霧水，思路會比較清晰，也容易掌握各個考點。點擊聽課，進入備考>>