开发架构缩短了开发生命周期

一般来说，IT结构是一个框架。它是一种为帮助资源在一个组织或公司范围的基础上化利用提供指导的结构。在你的IT组织里有许多的框架或者构架。例如，你可以定义一个技术构架用来确认你的技术产品和工具，并且当每个技术构架都正常运用时，你可以定义一个数据构架来描述重要的数据模块和其特点。在本文中，我将着重于开发架构的分析。

　　我现在从广义上定义开发架构，总结出以下三个主要方面：

　　1. 开发生命周期和过程运用于构建商业应用中； 

　　2. 能展示适合的技术设计的应用模型将最适合于商业需要；

　　3. 现在的组织中都存在商业应用的目录和分类。（在有些公司，这一块被称为应用构架，但我将它囊括在更广义的开发架构的定义中。）

　　让我们来仔细观察一下开发生命周期，看看它是如何以一种积极的方式影响你的应用开发环境。

　　应用开发过程
　　开发架构的第一块是与你的开发生命周期相关的过程，定义开发生命周期对各种规模的公司来说都是一个很好的练习。如果贵公司是以生产软件为生，那你可能已经有了这一程序，尽管我知道有一些公司仍然没有。

　　开发过程中的一个相当重要的方面就是要求个人分析员、设计者、和程序员们——每个人都具有创造力和技能。尽管如此，生命周期的许多方面都能被标准化。例如，收集商业需求信息的方法有很多。可是，其中无疑有些方法比其他的要好。另外。从个人面谈的调查到群组会议，有许多收集需求信息的技巧。除此之外，还有已被证实的确定的一些测试技巧。你的开发架构可能提供一个整体的、可用于一般的项目的测试过程，但基于要推出一些具体的结论，这个开发架构就需要按项目定制了。

　　还有许多开发应用过程的途径。你可以使用传统的瀑布方式（例如，分析、设计、设码、测试等等），或者你可以运用通过连续更微小的增量建立解决方法的RAD方式。

　　开发架构的力量之一就是他们可以为辅助决策制定提供指导。这样的话，最初的指导将诞生于你选择的开发生命周期的形式。例如，有许多项目更适合与采取瀑布方式而非RAD方式。

　　在一个项目快完成之前，项目经理会根据一套预先定义的标准来估计其商业需求。这些标准导致基于生命周期形式的指导派上用场。例如，如果解决方法是偏重于在线处理工作，并且需求也不为人所知，那么RAD生命周期将好一些。假设解决方案是偏重批处理工作的并且要求许多元素加入当前其他的应用程序，一个传统的瀑布方式可能是更好的选择。如果解决方案对现存的应用程序主要是一个增强扩展，那么增强型生命周期会更加合适。

　　任何发明过一套方法的人知道这是非常复杂和费时的工作。但事实上不一定必须得如此。你可以购买开发生命周期方法去作为你的起点或者你可以召集大家一起并集体研讨。

　　制定一个决定性的决策显示你所提供详细节的数量。我的偏好是提供足够的细节使你能给项目经理指导，但这些细节不至于多得使整套方法变得难以处理。你可以花一年时间在详细的数目范围内定义一个生命周期，但这里要指出的是项目经理对你所涉及的80%的内容是了解的。这就是我推荐的应用程序结论的中心思想。

　　按照指导，你还需要决定生命周期的的分配是否为强制性的。如果是的，这些就成为每个人必须服从的经过考虑的公司标准。例如，你可以有作为特定指示必须被用于生命周期中标准模板。你的生命周期还可以把建议按提纲形式列出，但不是完全强制性的。

　　决策制定的指南
　　开发生命周期指导该如何开发应用程序。这种生命周期将节约项目经理的时间和精力。它需要在应用程序每次刚刚开始从头开发的时候创建开发的程序。