1. 軟體工程 - 期末報告
微型團隊的 WEB 程式開發流程
N004020014 張明泰
2013.06.15

2. 大綱
●
團隊是一個 5 人內的微型的協同合作團隊。
●
以 SCM 配合專案開發的流程，來管理開發專案。
●
預計提出一個實務的開發的工作流程，配合 SVN 軟體來
執行 SCM 的辨識、變更管理、狀態報告及稽核等工作
該。
●
軟體預計使用 Subversion Server 及 SVN Client ，配合
REDMINE(bug tracker) 來追蹤專案的執行。
●
實際使用上可能會遇到的問題及提出解決的方式。

3. 主題
●
開發團隊的工作情境角色及開發方式說明
●
開發方式遇到的問題
●
解決的對策
●
Redmine 專案管理網站
●
SVN Server 及 Client 使用方式
●
預期困難
●
心得

4. (1) 開發情境
●
微型的專案團隊，一個全職其他為兼職。
●
開發的環境及程式為 PHP +HTML + JS 的 WEB 程式。
●
資料中心架構，以後端的 MySQL or PostgreSQL 為資料
核心。部份為 Oracle 。
●
需求由專案經理溝通協調確認，透過 issue tracker 做功能
交派。
●
Server 平台為 Linux ，使用 FTP 上傳更新，網頁直接驗
證測試。

5. (1) 開發情境 - 示意圖

6. (2) 開發遇到的問題
●
開發者之間互相蓋掉對方的程式碼，且不知道版本的差異
及改正修正哪些問題。
●
需求不斷更動，沒有紀錄不知道改些什麼。
●
如果有新的成員加入專案，必須要重新說明開發的每各細
節。
●
對於專案管理者，無法掌控目前的開發進度。
●
測試和正式機器同一環境，安全性及穩定性有問題。

7. (3) 解決的對策
●
使用版本控管軟體 (svn or git) 解決程式碼覆蓋的問題。
●
使用 wiki 協同作業軟體解決文件不斷更動的，讓文件的變
動可以追蹤。且可以作為對新成員的教育訓練文件。
●
使用 issue(bug) tracker 來追蹤問題，使用專案管理的時
程來掌握進度。
●
調整開發、測試及釋出版本的流程，並規範確實遵循。

8. (3) 解決的對策 - 開發關係示意圖

9. (3) 解決的對策 - 角色
●
專案經理：即是首席程式設計師擁有所有平台環境的存取
管理權限。 ( 首席程式設計師團隊 P367)
●
開發人員：兼任測試人員，可以 commit 各版本到
Testing 平台，並且自行測試功能正常沒有問題後，就可
以自行 Release 正式發布的平台。
●
報告人員：只擁有 Redmine 專案平台的問題回報權限，
工作的分派由專案經理分派或開發人員認領。

10. (3) 解決的對策 - 需求已確認的開發流程
●
專案經理確認需求及功能，以 REDMINE 的建立問題 -> 功能說明需求。
●
開發者再本地端建立一個開發者使用的測試環境，所有的測試都在這裡地方。
●
本地端程式碼的編寫測試更新都透過 svn client 上傳更新到 svn 儲存庫中。
●
當測試到一個段落，將程式碼放到 Testing 的 LAMP 平台上，測試人員進行測試。
●
如果有問題，測試人員再 REDMINE 上面填寫問題回報，系統會以 Email 通知開發
人員。
●
開發人員接件，解決問題。專案經理再過程中全程協調監控所有的活動狀態。
●
當測試沒有明顯的問題後，就進行 Release 程式更新到正式的 LAMP 平台上面。
●
完成一個 Release 後，再 REDMINE 上編寫這個里程碑的文件。
( 文件的編寫程式過程中，就和程式碼寫在一起，整理文件再整個 review 一次 )

11. 解決的對策 - Redmine 專案管理平台
http://redmine.jangmt.com/http://redmine.jangmt.com/

12. (3) 解決的對策 - Redmine 專案管理平台
●
Redmine 功能清單 (ref:
RedMine Features)
●
Per project wiki - 每個專案獨立
Wiki 系統
●
Per project forums - 每個專案獨
立 討論區
● SCM integration (SVN, CVS, Git,
Mercurial, Bazaar and Darcs) –
支援多種版本控制系統
●
Multiple projects support - 可以開
多專案管理
● Flexible role based access control
- 多種角色的存取控制
● Flexible issue tracking system -
議題追蹤管理
●
Gantt chart and calendar - 甘特圖
自動生成、行事曆
● News, documents & files
management - 文件、檔案管理
● Feeds & email notifications -
RSS 、 Email 通知

13. (3) 解決的對策 -RedMine 活動
● Activity
●
可以知道最近專案的活動
狀態。
●
包含問題處理、文件編
寫、程式碼更新等 ....

14. (3) 解決的對策 - RedMine 問題清單及新問題
●
可以針對 BUG 或議題或變更
管理並且給予追蹤及確認的後
續流程。
●
此功能定位為紀錄每個變更事
件發生時候詳細紀錄。
●
可以用 mail 追蹤這個問題的
處理狀況。
●
可以分派這個工作給開發人
員，可以安排預計規劃的工作
時程。並且與甘特圖結合。

15. (3) 解決的對策 - Redmine 甘特圖 or 日曆
●
甘特圖和日曆可以協助安
排專案的時程，視覺化顯
示專案的進度。 .

16. (3) 解決的對策 - RedMine 的 wiki
●
WIKI 可以用來記載需求文
件及需求變更的管理。且
以系統化的方式紀錄。
●
因為可以查詢版本變化的
過程，所以適合需求變更
的軟體專案開發活動使
用。
●
和問題追蹤不同處在於可
以系統化的紀錄專案。

17. (3) 解決的對策 - Redmine 儲存庫
●
可以結合 SVN or GIT 等
外部的版本控管系統，同
時知道程式碼的變更狀
況。方便稽核程式碼。
●
可以再 web 上 diff 比較
檔案。

18. (3) 解決的對策 -SVN 版本控制系統
●
使用 SVN 版本控制系統的原因：
●
可在協同開發創作的環境中可以保有所有的變動紀錄、回
復到指定的版本、成員的程式更動與其更動狀況紀錄。
●
SVN 是集中式的版本控制系統，需要網路才可以更新。
●
其他的版本控制系統： GIT( 分散式版本控制系統 )

19. (3) 解決的對策 -SVN 軟體及使用原則
●
Windows 上常見的工具有 TortoiseSVN
●
Linux 上推薦 RapidSVN (GUI) 及命令列 SVN
●
Repository ：儲存放置文件的儲存庫或資料庫
●
SVN 可以透過 http 、 https 、 ssh+svn 、 svn 等方式存
取。 Ex: svn://svn.jangmt.com/home/repos/test/
●
SVN 目錄習慣上分成為 Trunk/Tags/Branches 。

20. (3) 解決的對策 -SVN 原則
●
Trunk: 版本主幹，主要開發都在這裡
●
Tags: 可以依據里程碑或 Release 的版本
分支成為 Tags
●
Branches: 通常用於功能點的分割或 bug 的
修正。完成後使用 Merge 合併回 trunk 。

21. (3) 解決的對策 -SVN 功能 (1)
●
Svn Checkout 將 SVN 儲存庫中的資料取出
●
Svn Update 更新 svn 上面的版本到最新
●
Svn Commit -m ' 說明 ' 提交修正的內容
●
Svn add 將檔案或目錄加入 svn 儲存庫，需要 commit 後才會生效。
●
Svn mv 改檔名
●
Svn status 顯示上次 update 後的檔案狀態 , 有 conflict 也會顯示。
●
常見的 SVN 檔案狀態 :
A - 新增檔案
C - 檔案和儲存庫不同，合併失敗需要人工介入處理
M - 有修改過得檔案
? - 新的檔案不在儲存庫中

22. (3) 解決的對策 -SVN 功能 (2)
●
Svn revert 目錄 / 檔案 還原為前一個版本
●
Svn info 顯示目前 SVN 的相關資訊
●
Svn resolved 處理 conflict 的狀況 , 否則 commit 都會出問題
●
Svn diff 比較目前的檔案和 SVN 儲存庫的不同處
●
Svn copy 可以用來建立 Branch 分支或 tags 保存版本狀態。
●
Svn import 將本地端來源匯入 svn 儲存庫
●
Svn log 顯示 commit 的 log 狀態
●
Svn lock 鎖定檔案
●
Svn unlock 解除鎖定

23. (3) 解決的對策 -SVN 原則
●
同時間只有一個人的開發方式：
●
直接對 儲存庫的 trunk 主幹作 commit ，先上 Testing
平台測試，沒問題後再 svn update 到 Release 的平台。
●
Redmine 的文件及 issue 解決仍是需要回報。

24. (3) 解決的對策 -SVN 原則
●
修正 bug 的方式：
●
1. 先作 svn update 將程式碼更新到最新版本
●
2. 檔案較少可以 lock 該檔案，修正後重新 commit 到
Testing 機器。沒問題後再 Release 小版本修正。
●
寫功能的方式：
●
1. 先作 svn update 將程式碼更新到最新版本
●
2. 寫功能一定要 copy a branches ，測試完成後再
merge 合併回 trunk 。

25. (3) 解決的對策 - 資料庫的對策
●
因為使用資料中心的架構的開發方式，資料庫資料是核心
的一環。
●
讓開發者可以存取維護三個不同開發流程中的資料庫，但
在資料上以每日或每 6 小時備份的方式避免發生不可逆轉
的意外。

26. (3) 解決的對策 - 開發方式原則
●
參考極限編程的流程。遵循期核心價值：溝通、簡單、回
饋、勇氣，掌握基本原則。
●
再遵循原則流程中，放手讓開發人員去開發，確保資料可
以回朔保存，最多損失一天的開發量。
●
一次不用寫太多，分成小功能逐步編寫。
●
寫程式就同時寫註解，但是要避免亂寫。
●
Code 要有一定的水準才提交，提交要有責任感。

27. (3) 解決的對策 - 開發方式原則
●
一定要遵循測試開發的流程，謹慎的開發流程 Policy 可以
減少爆肝修 bug 的次數。 ( 不要在下班前 2 小時
Release code)
●
每次開發以 3HR 左右為一個短循環，立即驗證且得到回
饋。要求每次短循環的開發都要寫下文件。 ( in Issue
tracker or wiki )
●
以人性的角度思考程式碼及功能，不要做出違反人性的工
作及程式。

28. (4) 預期困難點
●
開發人員會因為時程壓力或怕麻煩而沒有遵循這樣的開發
流程規則。
●
此種開發模式類似極限編程方式，需要有獨當一面的開發
人員。
●
開發人員的 code style 不好規範，寫出來的程式很難重
複使用。
●
不能使用程式框架這會讓新進人員的學習曲線過高。
●
整合的開發環境，開發人員無法熟悉每個環節。

29. (5) 心得
●
對於團隊的軟體的開發流程，實務上沒有經歷過合作或遇
到問題沒辦法準確的抓出問題的所在。
●
迎合實際的工作環境，設計出自己執行上合理的維護流
程，我想是這門課給我最大的收穫。

30. 報告完畢