2013/06/30

資管碩專兩年的心得及回顧

兩年一下子就快過了,有沒有畢業一回事,但修課過程的心得個人感覺可以拿出來說一說,資管碩專班的教育和日間部研究所的教育,是一般人很難分清楚的除非你真的走過一遭。

資管系從以前工作的觀點來看,他就是一個培養嘴泡人才的科系,很多畢業生,到了畢業連寫程式都有困難,一些程式設計、網站服務的實作能力都有很大的問題。在我還沒讀之前,這是很明顯的成見,但事實上真的是有一部分是這樣,也就剛好在職場上看到的可能大都是比較廢的,這可能是抽樣上面的誤差問題.......^^ 。但如果透過另一個面向思考,資管所並不完全是培養資訊實作的能力,有大部分的時間是在培養資訊系統使用過程間人類行為的溝通及問題的處理,這是職場上常見的解決問題的能力。但是要一個剛出社會沒有經驗,程式系統不是很清楚的人直接面對這些問題,當然被打槍的機會就很大了 .....

中山資管碩專班主要是讓有一定技術能力,工作了一段時間經驗的資訊人員來進修的場合,我覺的他的不適合沒有工作經驗及資訊素養不足的的人來讀這個地方,當然也不是說一定要都會才可以讀只是你會讀得很辛苦,因為在課堂上很多觀念的釐清仍需要基本的資訊素養。

通常老師教授課程時有一定的主題,講授的內容都是層級較高的的抽象思考過程,但如何落實在實務上則是透過案例分享、問答思辨的過程釐清,且因為碩專學生也因為有些人有工作經驗,也會分享自己的觀點透課程中的多元思辨過程,引導學生思考與辯論。甚至針對事件吵起來,我覺的這是很大的收穫。多元多樣的思考發散想法後再行收斂決策目標,我覺的是讀資管碩專最主要的收穫。當然前提是在資訊技術的學習上已經到達一定的程度,既有固定的理論只要有時間看書大多能吸收,而珍貴的是多元的經驗不論是年輕的、老的、同業、或是不是同業,再課堂上針對議題發揮的想法,很難遇到這樣相關主題的分享。最近流行的社群網路或許有些人會分享,但大多數是專家的分享,素人及不同職業的使用者分享觀點則是未見。

中山資管另一個有趣的地方是上課的老師通常就是寫書的作者,教授門因為教授了多年的上課經驗累積到一定程度就自己寫書。書本在品質上有一定水準以上,很多考試及教學甚至列為指定經典用的教學用書。當然上課過程中,因為教書的和寫書的作者本身對於他寫的文字,想要表達的意思解釋的也就越精確當然也可以精確的表達它所要呈現的內容。

底下是目前還在的老師及其著作,有時候或許會質疑這些內容是不是和實務上有結合。這就看個人的解讀了,我個人是覺的在抽象層次上有更精進的發展。但是能不能應用於實務賺大錢,我只能有把握的說「應該可以提高虧少一點錢的機率」......!!!

林信惠老師的軟體專案管理


林東清老師的資訊管理:e化企業的核心競爭能力


黃三益老師的資料庫的核心理論與實務

吳仁和 系統分析與設計:理論與實務應用(六版)



2013/06/22

軟體工程--微型團隊的WEB程式開發流程

這是我軟體工程學習的期末報告,我想應該是個經驗可以提供分享。


大概說明一下簡報的內容:






也就是說,我配合很多工讀生執行這些工作。工讀生素質不一程度有差異,且都是學生,人員組成有太高的風險存在。學校並不會教寫程式的時候要版本控管因為能寫出來就偷笑了,通常平時能夠使用 WAMP 懶人包架設網站已經是萬分幸運了。比較糟糕的是拿 WAMP 直接上線當網站。要求到使用 LAMP 方式開發並且遵循版本控管及軟體專案管理的流程,並請使用某種特性流程的開發方式,如果沒有經過一番的訓練是有難度的。

開發的環境程式為 PHP + HTML + Jacascripts 的程式,後端是 MySQL、PostgreSQL及 Oracle 等資料庫,通常系統端只有我自己維護且再程式部份有範例程式碼提供撰寫的範例。
需求通常來自於我的上級長官,再經由我確認後交派給工讀生開發或是自行開發,但是長官的高深莫測需求漂移不定是最大的困擾。即使本人多方進行需求分析了解也有時會有方向錯誤的狀況發生......


通常交派工作後會遇到的情境狀況1,使用者聽到需求後馬上使用他的 WAMP 懶人包開發程式,工具使用 Dreamweaver or Notepad++ 工具,配合 filezilla 等 FTP 上下傳程式。然後直接觀看網站的結果與輸出,執行測試。測試正確 Testing == Release ,馬上即時成為釋出的版本。

這問題很大,通常這個過程沒有明確的將需求紀錄由可能造成傳遞上的錯誤,並且沒將需求分段設定里程碑來驗證,開發人員寫完後,也沒有管道可以不同部的回報。如果遇到需求變動,這就更麻煩了....


情境狀況2,再內部我架設了一個 bug tracker (PHP、全中文 and GPL)傳遞管控開發工作的訊息,可以控管每件事情包含平時的工作、軟體開發的工作、網路維護工作,用來追蹤工作是否有完成。這軟體很好用,我第一次遇到和它一樣的類似的是 http://www.fogcreek.com/fogbugz/ forbugz 這套,這作者就是有名的作家「 Joel on Software 周思博趣談軟體」作者自行創業的公司開發的軟體,可惜它要錢否則是很棒的軟體。

如果遇到多個開發者,開發者可以觀看 bug tracker 知道目前的進度。但是仍有 FTP 版本覆蓋的問題,沒版法徹底解決.....


所以問題就是開發者沒有版本控管不知道協同開發者改了什麼東西,以前的開發者幹了什麼事。原始的需求不斷變動沒有紀錄,版本即使有差異也很難比較差異。版本控管早期就是用 copy and paste 問題會越來越多檔案,不知名的檔案。

人員如果流動,一個專案又重新開始說明。延遲的專案加入一個人之後會更加延遲..(人月神話) 。管理者更慘,根本不知道程式寫到哪了,程式碼寫的有沒有問題。 code style 有沒有遵循也不知道。


所以我打算用版本控管程式碼, WIKI 控管文件,bug tracker 控管追蹤專案。並調整規範開發的流程及方式,要求所有開發者確實遵循開發規範。


所以上面的圖加上了 SVN 機制,及 RedMine 軟體專案管理平台。


再人員的角色上,專案經理也就是我本人。採用人月神話中的外科手術醫生團隊開發模式,由我主導負責整個專案的進行,分工後採用專案控管的方式追蹤稽核。

開發人員則是由比較有經驗的資深工讀生,經過訓練後讓它可以自己 commit、測試 及 Deploy 程式碼到 Release 的平台。

報告人員大多為生手或是搞不清楚狀況的使用者,讓它只做報告人員報告問題即可。不用做太多以免發生風險。


所以根據上面流程圖及角色,列出了開發需要執行的流程方式。但是這個流程其實在某些例子下,是可以稍微簡化的。例如:同時間只有一人開發的時候(也就是我摸著鼻子默默的把程式寫完的時候)


因為工讀生的工作時間長短不一定,品質不一定。長官的需求也常常不一定。所以採用類似螺旋模型的方式,讓每次開發都是小循環,每次都經歷全部的開發流程,降低風險。


至於專案平台選擇的考量,有打算採用 TRAC or RedMine 之類的整合型平台。雲端上也有 github or googlecode 等平台,但是它門 public code 才可以免費用,所以摸摸鼻子自己維護了。
這兩套是用了一陣子發現 Redmine 的界面、中文、控管都很方便,對於管理專案者的門檻比較低,我可以把工作分派出去所以我暫時選了它。(為何說暫時勒?因為我不喜歡 Ruby On Rails ,所以暫時接受它....)


REDMINE 是一個 Ruby on Rail 開發的專案管理平台,且包含了可以讀取 svn or git 版本控管系統的界面,wiki 文件及 issue tracker 的整合性平台。功能完成,外掛套件也很多。且針對每各專案都有獨立的 wiki , SCM , 文件,日曆等界面,可以專一的控管專案。


這是他的活動,最近有那些變化都會列出再這裡。


這個是他的 bug tracker ,issue 可以父子問題相依,填功能時用點小技巧就可以達成里程碑的功能控管專案的進度。


上面的 issue tracker 可以直接和日曆、甘特圖結合,非常的方便可以控管專案。


WIKI 就跟維基百科一樣,可以檢視修改的文件變化。維護也很簡單。


程式碼儲存庫,可以支援 svn or git 等,且可以再 web 上比對程式碼的不一樣,也可以看 code style 隨時可以稽核。



版本控管最後選擇了 Subversion 的版本控管系統,因為員工程度落差過大,集中式的控管方式最能保障不會出大問題。也可以知道目前的進度。




這段我應該作個 SVN 的 step by step 教學文的,不過限於篇幅晚點再說....


當開發環境只有一個人的時候,可以用這個比較簡單的方式作程式碼的控管。只要先 svn commit 倒 Testing 的平台,測試正確後就可以 Release 的產品網站了。


另外這是修改 bug 的原則方式,及開發一個功能的時候因為會大幅動到程式碼,所以建議先 branches 再 merge 合併到 trubk 主幹之中。


我希望我的員工可作息正常,身體健康。熬夜開發程式是不健康的行為,寫程式要在白天寫,集中精神大概 3HR 就讓它一個循環,可以提高效率降低工時。且遵循下班前不要隨便將 Testing 轉換到 Release 的網站,因為通常那有可能讓我加班修理 bug.....
並且程式碼希望寫的淺顯異動,否則其他人看不懂那就沒辦法了........


最後就是推行了,通常開發人員看不到整個開發流程的全貌。所以透過這份報告,告訴它門開發軟體的全貌。我想這種勇氣、正直、善良和不爆肝的軟體開發流程大家應該可以接受才對。


軟體工程是一個有趣的課題,整個學期讀完一本軟體功能的議題,並且經過作者本人再課堂上面的講解,有實務經驗的超資深業界學長帶領完成整個軟體工程課程。



底下為引用上課不是我錄影的錄影檔....(google 找到的,我沒去要連結)只有部份課程有錄影這有點可惜。 上課錄影檔:(鄭炳強老師)

軟體工程 - 導論

軟體工程-課程大綱

上課錄影檔:(李智 http://richchihlee.wordpress.com/ )
為何要軟體工程,軟體專案為何會失敗? 如何避免失敗
軟體工程 - 出發前的準備
軟體工程- Requirement Analysis
軟體工程理論與實務 - 軟體估算

軟體工程-雛型法

SOA 服務架構導向
軟體工程-coding規範風格&測試軟體方法
典型資訊系統架構-利用Archi工具塑模