最近讀了一本不錯的軟體工程的書《軟體專案管理》機械工業出版社。
以前總是看一些老外寫的軟體工程方面的書，國內的軟體工程的書就看過清華大學的《基於軟體能力成熟度模型的軟體過程改進》（也是一本不錯的軟體工程的書，就是厚點，但是比起國外的來說不是很厚，羅嗦了阿）。
這個本的最大的特點是，都是中國的專家寫的一些實際經驗，符合中國國情的軟體開發方式。外國有些個軟體工程的東西在中國可能走不通，不如說工作流，中國的辦事流程太複雜了。
作為第一部分先說說需求分析階段的事情。
「需求分析人員在工作過程中可能會遇到一下問題：一些很忙的使用者可能不原意積極參入需求調研過程，對需求分析的工作不重視，這些現象給專案造成的影響往往是致命的。因為到專案驗收時使用者一定是非常重視需求調研，等問題到專案驗收的階段才暴露，一切都悔之晚矣。」這種現象在實際的專案開發中確實十分的常見，所以有乙個重點的要提出來，就是需求要使用者簽字確認，當需求變更的時候，一定要對變更也要簽字確認。
解決客戶不合作的矛盾的方式主要有一些幾個點：明確責任、確立工作目標、明確客戶的目標、請客吃飯、開會聊天。
需求階段要盡量避免二異性，需求規格說明書要準確。還有最重要的一點，需求規格說明書寫成後，一定要與利益的各方進行一次評審。
在實際的情況下，專案的雙方的地位是不平等的，往往使用者有一種優越的心理，在專案進行過程中處於優越的地位。在協作的過程中，只有充分尊重使用者，才能得到對方的尊重。當使用者提出變更的時候，不能一味的拒絕，這樣可能導致僵局。
實際情況下，使用者往往對需求只是乙個模糊的概念，這種情況下，我們要給使用者樹立乙個靶子，開發乙個簡單的原型系統，讓使用者來提修改意見，這樣會事半功倍。
《需求規格說明書》和《使用者需求說明書》的區別，我理解是，《需求規格說明書》主要是針對開發人員，《使用者需求說明書》主要針對客戶。前者比後者更詳細，更專業化。
需求分析方法的幾個點：資料流程圖、資料字典、需求條目化及標示。
《演算法之道》 一本不錯的書
作為乙個對程式設計感興趣而又非計算機專業的學生，我一直想對演算法理論有乙個系統的學習。買了一本 演算法導論 但讀起來卻覺得比較吃力，經常被書中的數學推理打擊自信。所以這本書一直是斷斷續續地讀著，至今未曾完工。無意中看到有 演算法之道 這本書，初一看，感覺很有趣，作者在每章的開始都會通過乙個有趣的故事...
學習SSH還不錯的一本書 spring
4.1搭建spring框架 工作目標 知識目標 技能目標 素養目標 工作任務 改造3.1節的任務，在註冊入庫功能的業務控制層 action 與業務處理層 service 之間引入spring框架 工作計畫 任務分析之問題清單 什麼是spring框架 為什麼要使用spring框架 如何使用spring...
一本關於職場哲理的書 咖啡
駐足，注視，聆聽 當你駕車行駛在忙碌的城市中時，前方有停車標誌，你會停下來。觀察前方是否有行人和車輛穿過，此時的你會特別關注周圍發生的一切。現在的人們生活節奏太快，工作也過於辛苦，以至於他們很容易忽略生活與工作的平衡。人們總是自己埋頭苦幹，很少抬起頭來看看到底進展如何。於是，他們便錯過了很多改善現狀...