软件开发

The Joel Test 软件开发成功12法则及四个实用领域。

通常情况下，软件开发与测试是既相互独立，又存在千丝万缕联系的两种不同性质的工作，如在一个项目开发小组里，开发工程师和测试工程师共享一个信息资源配置库等。软件测试是在受控条件下对软件系统或应用程序进行操作并评估操作结果。受控条件应该包括正常条件和非正常条件，例如为了故意造成错误而人为创造的测试条件。

不论是“敏捷开发”还是“极限编程”都可以加速软件的开发周期，增强用户的满意度。其中成功的“妙诀”在于将软件测试与开发紧密集成，并贯穿于软件生命周期。

测试自动化与软件配置管理是密不可分的。与测试有关的资源都应在配置管理中进行统一的计划考虑。另外，测试工具的采用也是一个提高质量的关键，有些专用的测试工具能帮助发现一些用任何测试个案都难以触及的错误。

软件作为一种纯数字化商品，在没有权威的第三方进行监督认证的情况下，软件供应商和用户在软件产品是否达到目标需求的问题上，往往各执一词。

首先谈谈软件测试。这可以说是一个非常令人捉摸不定的领域。“应该怎样对我们的产品进行测试?”和“怎样才算对产品进行了足够的测试?”等问题，对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品，实际操作上都会有很大的不同。

本文讲述了如何把RUP应用到小型项目团队开发J2EE应用系统的过程中，并且结合J2EE技术的特点从项目管理、架构设计、开发和测试等方面重点阐明了对RUP的裁剪。

为了使软件文档能起到前节所提到的多种桥梁作用，使它有助于程序员编制程序，有助于管理人员监督和管理软件开发，有助于用户了解软件的工作和应做的操作，有助于维护人员进行有效 的修改和扩充，文档的编制必须保证一定的质量。

中国人大都喜欢用武侠小说来比较软件开发，但是在实战武功中，只有葵花宝典才是最厉害的，也只有掌握了葵花宝典，才能称为"不败"。

我始终认为，对一个初学者来说，IT界的技术风潮是不可以追赶的，而且也没有能力去追赶。我时常看 见自己的DDMM们把课本扔了，去卖些价格不菲的诸如C#, VB.Net 这样的大部头，这让我感到非常痛心。

今天一晚上把有关敏捷开发的帖子，基本扫了一遍，收获不小。有些帖子对于日本的开发方式很不屑一顾，对于代码注释也不屑一顾，似乎日本的软件业马上要玩完了，似乎只有代码就够了一样。

在软件公司从事工作多年，亲身经历了几个包括OA、CRM的新产品开发半途夭折、走麦城的案例之后，我不得不对“软件产品开发为何失败”这个问题进行反思。我所接触到的朋友、同事多半是做软件开发的，他们和我一样，经历失败的例子要比成功的要多不少。从网上的各种文章、论坛得来的信息也一样充满着悲观。为什么会有这么多的失败？下以一个案例为

随着现代编程语言的到来，诸如Java、PHP、Python和Ruby等，以及丰富的代码库和来自类似Amzon的空前的底层服务的出现，我们正在进入另一个革命性的阶段。在这篇文章中，我们将描绘出软件开发走到今天的轨迹，以及未来将走向何方。

《哈利·波特》系列小说第七部《哈利·波特与死圣》不久前面世，很快受到书迷热捧，仅在24小时内就售出1100多万本，不仅创下了新书首发日销量纪录，而且形成了一个奇特的“哈利·波特现象”。

在实际的项目实施中，尽管旁边常常站着解决项目问题的专家，但当项目经理被不自觉地卷入到项目的各种问题中时，项目管理的各种方法也变得苍白无力。此时，敏捷开发往往成为项目经理的制胜法宝。

提到“软件危机”，人们的印象往往是指一些大型信息化项目延期而导致项目交接困难。但这并不意味着“软件危机”就与中小型信息化项目毫不相关。

我们现在软件业仍然采用非常落后的手工作坊的方式生产应用软件。劳动密集型产业中：产能的落后，成本的居高不下，质量低下等等问题让所谓的"高新"产业变得有点尴尬。所以，我们必须要工艺革新，软件开发工艺就是软件行业实现跨越式发展的动力。

从管理上说，中铁信与铁道部信息技术中心是一套班子两块牌子。在中铁信的四块业务中，IT产品销售和第三方服务是完全市场化的，另外两块业务与铁道部信息中心的业务是重叠的。成立中铁信，对铁道部信息技术中心的员工来说，更多的是观念的转变；由原来的职能管理部门、技术开发部门变为市场服务部门。

SOA 的目标是以服务作为构建企业应用的“积木块”，使整个企业敏捷起来，而敏捷软件开发则是通过引入一些最佳实践来增加沟通与反馈，以达到同样的目的。哪个是正确的？哪个更好？我们正在拿苹果和桔子做比较吧？它们可以一起使用吗？如果可以，那怎么使用呢？很难用一篇文字来彻头彻尾地评判SOA和敏捷，所以让我们一同来关注它们吧。本文仅是关