大學裡面學的軟體工程裡面軟體專案管理早已經忘記許多，最近接了乙個婚姻的flash來做，和乙個師弟一起幹這樣的活，對這個軟體開發管理有一點感觸。由於製作這個flash 的時候需求不完整的。在製作過程當中，需求不斷更改，並且不斷滿足客人的需要。我們大學老師金老師說過，軟體的需求是一直伴隨軟體開發專案的開始到結束。也就是說，需求不能一下子完全滿足客人的需求，在開發的過程中，需要更改並加以完善。
在製作這個flash裡面，需要預算了乙個開發周期。也就是乙個專案開始，要有乙個時間預定時間約束。在這個時間內，完成我們指定的目標。當時間確定後，我們需要對這個專案進行一定預算。簡單來講，就是需要支出多少，這些支援包括需要支付人工，需求哪些裝置方面資源等一系列的費用。專案確定好後，我們需要對該軟體專案產品進行乙個劃分期。初始階段，中間階段，結束階段。
在初始階段裡面，由於需求不能完整完善，我們快速定乙個模型出來，也就是開發第乙個demo版本。通過這個demo 版本，先讓客人測試，還需要哪些調整和不滿意的地方。在第乙個版本開發後，客人會指出很多毛病，和需求的地方。滿意度不一定會高。
有了這個基礎上，我們在製作這個flash的時候，大概確立乙個模型，在第乙個版本的調整上，我們發現了變更的度很大，客人需要調整的地方很多，而且還額外增加乙個功能要求。然後，我們繼續按乙個時間約定，進行第二個版本製作，這次比開發比第乙個版本的時間縮短了2天（第乙個demo開發花了4天）。然後客人提出的需求改動開始變少了。到了中間階段，我們不斷讓軟體版本發生變更，從最初的demo1發展到demo 5 ，每乙個版本所花費的時間不斷縮小。客人滿意度慢慢提公升了。
結束階段，當我們匯出最終的flash版本的時候，經過測試後，基本的功能已經完成了。到了最後的驗收階段，客人經過檢查，滿意度達到了90%，在這樣前提下，客人還是指出一兩點的需要改動的地方，如美工，或者背景**，影象的問題。由於個人技術和人員調配的問題，在這些時間預算和時間內，不一定完全能夠達到要求。只能進行完善的修補。這也是這次製作這個flash 一點遺憾。由於個人技術缺陷，最終導致一點不完善的地方，但是基本上的需求已經完成了。
最後，在規定的時間開發周期內，完成了這一次的任務。總算熬過了這14天的時間。
總述：開發專案確立，時間週期約束，預算支援，需求變更，版本變更，客人滿意度
這就是最近感言的，完成了這個flash後，會繼續進行我的無敵flash之旅。哈哈
系統軟體版本變更規範
版本號與具體軟體內容具有唯一對應關係，內容有任何變更，版本號必須跟隨變更。自定義版本號，遵循語義化版本原則 示例 u boot 2017.01 v1.2.1 g8fc2019 說明 u boot 是固定字首，表示類別 2017.01 是所使用的 uboot 的原始碼版本 v1.2.1 是自定義版本號...
對設計一點感觸
今天，稍微參悟了下 spring框架。裡面提到了 3種類 物件解耦的方式 介面注入 setter注入 構造注入 前一種 比較傾向與純物件導向的設計思想，主要通過介面來實現類 物件兩兩之間的耦合問題。在真正實現方案時，比較偏向於應用設計模式來解決一切物件之間的問題，對反射應用不是很多。後兩種 比較傾向...
軟體版本的分類
trial 試用版，軟體在功能或時間上有所限制，如果想解除限制，需要購買零售版。retail 零售版。free 免費版。full 完全版。alpha 內部測試版，通常在beta版發布之前推出。beta 測試版，正式版推出之前發布的版本。以上兩種測試版本bug可能較多。final 正式版，軟體的正式版...