- 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，因为它在控制的设备的数量以及设备的系列方面和目标系统比较接近。现在的用户界面所具有的一些功能是可以被新系统的客户端Gumtree所使用的。这些仪器的使用进度刚好可以提供给项目组使用，也可以披露给开源社区。
通过对问题域的分析确定了项目的目标和限制。然后开发分两个方向进行，分别开发客户端和服务器端，通过定期的会议同步进度。
小组和一个这个领域的专家组同时工作，这个专家组包括这方面的科学家和HIFAR的开发者和维护者。专家组提供了有关很多专业知识，包括仪表的使用，目前的和计划中的功能的细节，如果有新的操作代码，他们也会马上反馈。作为回报，他们对于仪表的结构和使用取得了更深的认识，这些对于他们以后的工作和决定有所帮助。
每个设备的驱动程序完成的时候，都会组织针对通讯和功能的测试。在可控的状态下对每个驱动进行在线的测试。
作为先行功能列表的一个部分，MRPD的设备和功能也集成在了开发计划中。
在很短的时间内，一个完整系列的设备驱动已经编码完成。MRPD目前正在等待最后的集成的是，然后仪器科学家和用户可以提供关于应用程序使用的反馈。
9 方法论的展望
作为一个新成立的小组，我们没有在开始的时候很急切的建立所有的开发环境以及提供所有的支持工具。NBIP的开发环境和项目开发的过程同步的进行。这不是最理想的，但是在我们所拥有的资源的情况下却是最现实的。尽管我们拥有一些传统的开发过程的工具，但是我们还是选择了更能够支持我们的敏捷实践的方法和工具。
调整目标功能集可以提供一种在项目组成员之间平衡工作量的机制。
作出功能的计划以后，开发者集中精力关注这些内容，而小组负责人维护一张进度的列表。如果发现一些功能是有问题的，或者开发者不能继续原来的工作，资源将通过一个定义完整的机制重新分配。
我们一直坚持每隔三个月在开源社区公布自己的项目里程碑。
尽管我们在这个间隔调整计划，但是我们希望在项目组内部，我们的频率要更高些。这样做的一个先决条件是高度自动化的软件包装和部署。一旦实现了自动部署，一个新开发的功能可以在几分钟之间内反映在软件包里面。
在极限编程里面，我们希望细化开发任务的粒度。XP需要一个功能可以在一天之内完成，其中包括单元测试。
如果不能做到这点，就说明任务的范围太大，需要再分解。简单的说，可能存在潜在的没有其他的支持就无法实现的可能。我们的测试还是一种不是很正式的模式——开发者本人测试他自己的代码。
程序编译是自动进行的，但愿测试是不完整的，也是非正式的。继承测试仍旧是在开发者在完成一系列的功能以后进行的，尽管我们尝试把测试的频率提高。
程序员自己测试的方法被实践证明是非常有效的。似乎，心理上的障碍比事件的障碍更加难于克服。根据我们的有限经验，程序员在潜意识中都希望在开发结束后马上进行测试。去除了bug的程序可以保证更加稳定，这样的做法可以提高整个开发组的效率。这种方法在很大程度上要依赖其他方法的使用。
10 结论
科技软件的成功在很大程度上会受到有经验的参与者和专注的小组的影响。为了更快、更好地完成工作，必须花更多的经历在探索当代软件开发原则和实践上。
敏捷软件开发原则关注的是人。敏捷开发包括很多方法，例如XP和FDD，同重量级的文档驱动的开发过程相比较，敏捷方法在灵活性等方面更有吸引力。这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。然而，在科技和软件开发的精神中，这并不排除在实践过程中会有一些变化。
通过尝试一系列给予敏捷的方法，ANSTO的中子仪器项目产生出了高质量的应用。项目组每天的协调会和与客户的频繁沟通对于鼓舞这个新建立的项目组的积极性起到了重要的作用。协作、公共的开发工具以及面向最终用户的应用、信息的流动和反馈都对结果产生了积极的作用。
很多方法很难独立的使用。开始的时候是凭着知觉选择了测试驱动的开发，结对开发，计划调整周期以及持续改进，不过，后来的结果证实，这些方法都取得了成功。
使用这些方法并不能保证一定成功。现在，我们已经发现开发者的经验和技术仍旧是影响开发结果的最主要因素。然后，我们相信，对于合适的人，基于敏捷原则的开发方法可以产程更好的结果，同时形成一个愉快地、有激情的工作环境。
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:
敏捷宣言所主张的原则
我们遵循以下原则：
我们最高的优先级是通过及时、可靠的提供有价值的软件来满足客户的需求。
欢迎需求的变更，即使会延迟发布。
敏捷方法通过变更达成客户的竞争优势。
频繁发布软件，从几个星期到几个月，优先选择短的时间周期。
在整个项目过程中，业务人员和开发人员必须每天协同工作。
用有激情的人建立项目。
给他们必须的环境和支持，相信他们可以把工作做好。
在一个开发组中传输信息最有效的方法是面对面的交谈。
可执行的软件是衡量进度的唯一要素。
敏捷方法可以提高开发效率。
敏捷开发提高了稳定开发的可能。发起人、开发组、用户都可以取得比较稳步的进步。
对于优秀的技术和好的设计的持续改进可以增强敏捷方法的效率。
朴素—把工作效率尽量提高的艺术—是最基本的。
只有自律性强的组织才可能产生出最好的软件架构、需求、设计。
每隔一段时间，开发组反思一下如何能够提高效率，然后相应的调整以后的开发过程。
文章来源于领测软件测试网 https://www.ltesting.net/