關於人事檔案系統，系統本身功能實現很不難，但因為其資料資訊的邏輯性有很問題，使得系統的邏輯一改再改，這裡很大原因在客戶的需求變更和對業務需求不明確。
1、需求的變更一般在系統有了乙個較完整的介面功能後，客戶會逐漸對系統有一定的了解，客戶可能會想到各種新的功能和特色，對以前提出的要求進行改動，相應的就會提出需求變更（一般客戶在最初提出需求後會頭腦形成乙個自己的模型，**的布局，流程等等，而且客戶了解的越多，新的要求也會越多），這只能迫使開發工作返工，無疑這會造成一定的損失
,但又無法完全避免。要求使用者一次性把需求講清楚
,並且不
允許此後需求有任何變更
,這是不現實的。只能儘量減少需求變更
,降低它所造成的影響。 2
、對需求的理解:
當客戶向需求分析人員提出需求的時候往往是通過自己的想法用自然語言來表達的，這樣的表達結果對於真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，或者需求開發中開發人員與使用者溝通不夠充分,如未能如實獲得使用者的潛在需求等。而這些一般跟需求分析員的知識、背景，還有客戶表述的標準程度、雙方的交流情況有關。
1、專案開始前的變更預防
對於任何軟體專案，需求變更都無可避免，也無從逃避，無論是專案經理還是開發人員只能積極應對，而這個應對應該是從專案啟動的需求分析階段就開始了。
做好專案啟動前的需求分析尤為重要，如果需求沒做好（不管是客戶還是專案需求分析員的原因），需求不明確，開發過程中使用者往往會發現很大的「新需求空間」，造成專案的延期甚至重構。
所以必須要做好專案啟動前的需求，要求客戶提供全部已知的需求，專案的需求達到雙方的共識，需求文件還應包括需求變更造成的影響和變更代價等等，對於我們不熟悉的領域的專案，需求分析員和開發人員要做好充分的調研。
2、專案進行中的需求變更
成功的軟體專案和失敗的軟體專案的區別就在於專案的整個過程是否是可控的。
如何應對專案進行中的需求變更，首先從開發角度看，我們開發的軟體必須的可變的可擴充套件的，讓我們的軟體足夠軟，能夠應對客戶提出的新增刪減功能模組的需求。（例如資料庫三正規化，三層思想以及設計模式的應用）。每一次需求的變更都需要正規的需求管理流程，否則極少成多，影響專案的開發進度。
任何軟體的需求不可避免，而做好需求變更的應對更為重要，需求的變更有時會對專案能否正常完成有很大影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，在接受需求變更的同時學會引導客戶。需求變更控制的目的不是控制變更的發生，而是對變更進行管理，確保變更有序進行。
每一次的專案開發都是一次歷練，做好過程中的總結很重要，積累每一次的經驗。
未完待續。。。
從檔案系統看系統架構
struct vop vector struct vop vector vop default 定義乙個預設的操作結構，注意型別也是vop vector int vop bypass struct vop generic args ap int vop open struct vop open ar...
重新看檔案系統
乙個實體的儲存裝置掛到linux下的時候都要以某個節點來實現，其實就是用 dev 下的乙個檔案來充當介面的功能，在將這個實現了這個介面的實體類掛在樹上就可以訪問了。linux在安裝的時候要有乙個 boot必須安裝到第乙個分割槽，以此開始系統的初始化工作。從這裡出發說說硬碟的分割槽 乙個硬碟最多分四個...
從人事變動看行情
跳槽1 h 職位專案經理 管理很多專案 在公司2年.應該算達人 原因不明 跳槽2 h 職位至深技術人員。工作年限4年。家族大部分去外地發展。跳後感受 珠海工資高很多！消費比這邊低 我無語了 跳槽3 g 6月份拿到畢業證 去深圳找工作！理由工資高，同學一起出去闖世界 工作1年時間 跳槽4 c 6月份拿...