客戶的需求是否應該得到滿足？軟體工程是否目的就是滿足客戶的需求？這個問題看來是無法加以回答的，因為，它沒有提供兩個基本的解釋，其一：客戶 的需求即算從客戶的利益立場出發，是不是合理的？其次，客戶的需求有多大程度上是必要的？還是只是一種個人的喜好？
如果說對於商業客戶來說，在專案開始前，還存在著做與不做；以及多少價錢來做的選擇的話，那麼，在許多情況下，工程人員如果不對此有明確的立場，唯一的結果就是累死自已，而軟體專案永遠不令人滿意，也永遠不能完成。對於商業性客戶來說，客戶的需求是否合理是客戶自已的事情，客戶永遠是對的，這句口號的台下詞是：只要客戶肯掏錢，那怕他要跳海，那也是他自已的事！但如果專案是已經簽署定的合同單，那麼就存在著是否按原合同繼續，還是中止，還是變更付款條件的的問題。而對於內部專案，所謂的成本就是工程人員有多累和什麼時侯累死的問題。這時侯，軟體工程從業人員最好能夠明白，在自已累死以前，老闆，以及那些不學無術對技術一竅不通卻自以為是行裡大家的同事，都不會對你有任何憐惜的。
所以這時侯那種無條件滿足客戶需求的工程需求管理就不適用了，這時侯，軟體工程人員只能根據自已能夠承受的工作強度對各種需求進行取捨，而不是無條件地牽就「客戶」的需求，更不是遷就無知的需求。客戶是上帝這句話這時侯完全不適用，因為客戶不會為朝改晚改的需求付錢，付帳的是程式設計師自已——讓自已早點累死。
把種種需求明列並分級是唯一的辦法；自已就按步就班一點點地完成，這是唯一的辦法。事實上，對於商業客戶這也是適用的，因為收錢的畢竟是公司老闆而不是專案組的程式設計師，公司老闆收了錢就不管實際專案成本是多少而讓程式設計師無條件接受客戶的需求也是常見的事情。所以把需求明列，既是讓老闆明白眼前專案的成本到底是多少（老闆通常是技術盲），也有了與客戶討價還價的根據。
我把需求分成五個等級。五分等級也是工程技術上的常用方式，如同大學的五分制。
一級需求(或改變)是關鍵性的需求，這種需求如果不滿足，意味著整個專案不能正常交付使用，前期工作也會被全部否定。這是必須滿足的，否則就意味著否定程式設計師自已。所以定為urgent.； 這通常是屬於補救性的debug型別，要救火。
二級需求（或改變）是後續關鍵性需求，它不影響前面工作內容的交付，但不加以滿足，新的專案內容無法提交或繼續。所以是necessary；一般新模組關鍵性的基礎元件，屬於這個級別。
**需求是後續重要的需求，它不能滿足會令整體工作價值下降，為了體現專案價值，也是程度員自已的技術價值的證明，所以定為needed;一般性的重大的有價值的全新模組開發，屬於這個級別。
以上三個等級是應該實施的，但時間性上可以作優先順序的排列。
四級需求是改良性需求，沒有它並不影響已有功能的使用，但實現了，有可信的根據可以是better。介面和使用方式的要求，一般在這個檔次。
五級需求是可選性需求，沒有它沒有誰會活不下去，有了它，沒有根據一定帶來好處，更多是一種設想，以及一種可能；通常只是需求**人員的一種個人喜好。所以是maybe。
對於四級需求，工程人員專案有空，不妨做下去；對於五級需求，有興趣有餘力就做，沒有興趣或者沒有餘力，管他需求不需求，除非額外付大錢，就讓提這些外行需求的家為一邊涼快去
講專案中產生的日誌自動上傳到HDFS上
說明 專案產生日誌存放的路徑 root luheng hdfs上儲存日誌的路徑 fengqing logs 在 root luheng目錄下新建乙個upload.sh檔案，其內容如下 bin bash src dir root luheng dst dir fengqing logs ls src ...
軟體測試過程中產生的文件
軟體測試是軟體開發的乙個重要環節，同時也是軟體質量保證的乙個重要環節。所謂測試就是用已知的輸入在已知環境中動態地執行系統 或系統的部件 測試一般包括單元測試 模組測試 整合測試和系統測試。如果測試結果與預期結果不一致，則很可能是發現了系統中的錯誤，測試過程中將產生下述基本文件 1 測試計畫 確定測試...
軟體專案中的風險管理
http www.csai.cn 2005年07月27日 1.引言 軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現，如果專案風險變成現實，就有可能影響專案的進度，增加專案的成本，甚至使軟體專案不能實現。如果對專案進行風險管理...