- Apache / Bugzilla / Perl / MySQL用于跟蹤bug、發布的版本以及改善功能的請求
- NeXus和HDF是SICS所需要的。這些產品也提供了對于開發工作很重要的API和數據瀏覽器
- Tango包omniORB目標分解器
- DejaGNU測試環境
配置管理和參數保留
開發過程中的一個主要目標是從中心知識庫自動生成配置指令的文件和對于這些配置文檔的可視化控制。
在儀器操作過程中，保留模塊的調用參數可以使模塊從不正常的狀態恢復。
把這些參數保存在一個分布式的系統有利于遠程指令狀態監測和調試。
為了保證系統所有的功能都沒有重復的完成，我們需要一個集中、可靠、快速、基于網絡的模塊，通過它可以知道任何一個配置的關系，以及他們當前的狀態。
目前的數據庫被定義為在SICS初始化的時候完全覆蓋。這樣，SICS可以在適當的時候根據物理配置角本重建。我們傾向于使用JDBC完成對于一個相應到角本的轉換。
數據庫本身使用Eclipse的插件。培植數據庫的角本可以翻譯成各種形式的SQL。數據庫的設計是文檔化的，并且有嚴格的版本控制。
8 HIFAR MRPD：調整計劃和提交代碼
“可執行的軟件是衡量進度的唯一要素�！� [1]
在儀器還沒于安裝的情況下，開發組想到了早期的一個項目，于是想把軟件系統原型運行在這個已經存在的儀器（HIFAR1）HIFAR上。雖然增加了一定的工作量，但是也產生了一些值得期待的成果：
- 取得了在一個實際的儀表項目調整和擴展SICS性能的信心
- 通過小組的開發實踐，取得了開發過程、任務管理等方法論的信心
- 通過和現實的系統的交互，拓展了現行系統和NBIP儀表科學的視野
- 提供了一個測試小的持續改進的平臺
- 測試了可配置的服務器和客戶端目前已經實現的細節，客戶端包括控制選項，儀表狀態顯示，試驗狀態顯示，數據顯示
- 提供了調試和測試過程的驗證
- 提供給所有的用戶一個客戶端已得到關于可用性的反饋
- 取得了存取實際的數據的經驗并對于如何管理它展開了討論
- 測試了我們的前端數據壓縮和分析工具
我們選擇了儀器HIFAR MRPD，因為它在控制的設備的數量以及設備的系列方面和目標系統比較接近�，F在的用戶界面所具有的一些功能是可以被新系統的客戶端Gumtree所使用的。這些儀器的使用進度剛好可以提供給項目組使用，也可以披露給開源社區。
通過對問題域的分析確定了項目的目標和限制。然后開發分兩個方向進行，分別開發客戶端和服務器端，通過定期的會議同步進度。
小組和一個這個領域的專家組同時工作，這個專家組包括這方面的科學家和HIFAR的開發者和維護者。專家組提供了有關很多專業知識，包括儀表的使用，目前的和計劃中的功能的細節，如果有新的操作代碼，他們也會馬上反饋。作為回報，他們對于儀表的結構和使用取得了更深的認識，這些對于他們以后的工作和決定有所幫助。
每個設備的驅動程序完成的時候，都會組織針對通訊和功能的測試。在可控的狀態下對每個驅動進行在線的測試。
作為先行功能列表的一個部分，MRPD的設備和功能也集成在了開發計劃中。
在很短的時間內，一個完整系列的設備驅動已經編碼完成。MRPD目前正在等待最后的集成的是，然后儀器科學家和用戶可以提供關于應用程序使用的反饋。
9 方法論的展望
作為一個新成立的小組，我們沒有在開始的時候很急切的建立所有的開發環境以及提供所有的支持工具。NBIP的開發環境和項目開發的過程同步的進行。這不是最理想的，但是在我們所擁有的資源的情況下卻是最現實的。盡管我們擁有一些傳統的開發過程的工具，但是我們還是選擇了更能夠支持我們的敏捷實踐的方法和工具。
調整目標功能集可以提供一種在項目組成員之間平衡工作量的機制。
作出功能的計劃以后，開發者集中精力關注這些內容，而小組負責人維護一張進度的列表。如果發現一些功能是有問題的，或者開發者不能繼續原來的工作，資源將通過一個定義完整的機制重新分配。
我們一直堅持每隔三個月在開源社區公布自己的項目里程碑。
盡管我們在這個間隔調整計劃，但是我們希望在項目組內部，我們的頻率要更高些。這樣做的一個先決條件是高度自動化的軟件包裝和部署。一旦實現了自動部署，一個新開發的功能可以在幾分鐘之間內反映在軟件包里面。
在極限編程里面，我們希望細化開發任務的粒度。XP需要一個功能可以在一天之內完成，其中包括單元測試。
如果不能做到這點，就說明任務的范圍太大，需要再分解。簡單的說，可能存在潛在的沒有其他的支持就無法實現的可能。我們的測試還是一種不是很正式的模式——開發者本人測試他自己的代碼。
程序編譯是自動進行的，但愿測試是不完整的，也是非正式的。繼承測試仍舊是在開發者在完成一系列的功能以后進行的，盡管我們嘗試把測試的頻率提高。
程序員自己測試的方法被實踐證明是非常有效的。似乎，心理上的障礙比事件的障礙更加難于克服。根據我們的有限經驗，程序員在潛意識中都希望在開發結束后馬上進行測試。去除了bug的程序可以保證更加穩定，這樣的做法可以提高整個開發組的效率。這種方法在很大程度上要依賴其他方法的使用。
10 結論
科技軟件的成功在很大程度上會受到有經驗的參與者和專注的小組的影響。為了更快、更好地完成工作，必須花更多的經歷在探索當代軟件開發原則和實踐上。
敏捷軟件開發原則關注的是人。敏捷開發包括很多方法，例如XP和FDD，同重量級的文檔驅動的開發過程相比較，敏捷方法在靈活性等方面更有吸引力。這個方法的創始人強調了在軟件實踐過程中的變更而不是孤立的進行一些實踐。然而，在科技和軟件開發的精神中，這并不排除在實踐過程中會有一些變化。
通過嘗試一系列給予敏捷的方法，ANSTO的中子儀器項目產生出了高質量的應用。項目組每天的協調會和與客戶的頻繁溝通對于鼓舞這個新建立的項目組的積極性起到了重要的作用。協作、公共的開發工具以及面向最終用戶的應用、信息的流動和反饋都對結果產生了積極的作用。
很多方法很難獨立的使用。開始的時候是憑著知覺選擇了測試驅動的開發，結對開發，計劃調整周期以及持續改進，不過，后來的結果證實，這些方法都取得了成功。
使用這些方法并不能保證一定成功�，F在，我們已經發現開發者的經驗和技術仍舊是影響開發結果的最主要因素。然后，我們相信，對于合適的人，基于敏捷原則的開發方法可以產程更好的結果，同時形成一個愉快地、有激情的工作環境。
11 參考資料
[Astels] Astels, D., G.Miller and M.Novak "A Practical Guide to eXtreme Programming", Upper Saddle River NJ: Prentice-Hall PTR, 2002. ISBN 0-13-067482-6
[Coad] Coad, P., et al. "Java Modelling in Color with UML", Upper Saddle River NJ: Prentice-Hall PTR, 1999.
[Fowler] Fowler, M. "UML Distilled" 3rd Ed., Addison-Wesley Publishing Co., 2003. ISBN 0-321-19368-7
[Hauser] Hauser, N., et al, "Choosing an Instrument Control System", NOBUGS Conference 2004.
[Palmer] Palmer, S.R., and J.M.Felsing "A Practical Guide to Feature-Driven Development", Upper Saddle River NJ: Prentice-Hall PTR, 2002. ISBN 0-13-067615-2
12 URL 參考資料
[0] "Manifesto for Agile Software Development" <http://www.agilemanifesto.org/>
[1] "Principles behind the Agile Manifesto" <http://www/agilemanifesto.org/principles>
[2] "Eclipse" <http://www.eclipse.org>
[3] "eXtreme Programming" <http://www.extremeprogramming.org/>
[4] "Feature Driven Development" <http://www.featuredrivendevelopment.com/>
[5] "The New Methodology", Martin Fowler <http://martinfowler.com/articles/newMethodology.html>
[6] "The Agile Alliance" <http://www.agilealliance.org/>
13 附錄
[A] “敏捷宣言所主張的原則”
附錄A:
敏捷宣言所主張的原則
我們遵循以下原則：
我們最高的優先級是通過及時、可靠的提供有價值的軟件來滿足客戶的需求。
歡迎需求的變更，即使會延遲發布。
敏捷方法通過變更達成客戶的競爭優勢。
頻繁發布軟件，從幾個星期到幾個月，優先選擇短的時間周期。
在整個項目過程中，業務人員和開發人員必須每天協同工作。
用有激情的人建立項目。
給他們必須的環境和支持，相信他們可以把工作做好。
在一個開發組中傳輸信息最有效的方法是面對面的交談。
可執行的軟件是衡量進度的唯一要素。
敏捷方法可以提高開發效率。
敏捷開發提高了穩定開發的可能。發起人、開發組、用戶都可以取得比較穩步的進步。
對于優秀的技術和好的設計的持續改進可以增強敏捷方法的效率。
樸素—把工作效率盡量提高的藝術—是最基本的。
只有自律性強的組織才可能產生出最好的軟件架構、需求、設計。
每隔一段時間，開發組反思一下如何能夠提高效率，然后相應的調整以后的開發過程。
文章來源于領測軟件測試網 http://www.kjueaiud.com/