软件工程的规则建议系统开发在维护的早期变化。如果你已经在需求阶段组织了设计代码模块以及交叉引用部分，你就可以跟踪需求变化到受到影响的模块，以及必须重新进行测试。相应地，如果发生了错误，你可以找到包含错误的模块，然后在所有的层次（设计、编码和测试）上进行更正而不仅仅在编码上进行修正。软件工程的原则不仅导致了好的设计和代码，而且导致了快捷的改变能力。
当我们开发一个系统时，我们集中注意力于产生能实现需求而且能正常工作的代码 。在开发的每一个时期，我们不断地借鉴前后阶段产生的结果。系统设计与需求说明紧密相连，代码模块是交叉引用的。而且与设计一致，测试基于找到函数和规范是不是按照需求和设计的规定工作的。因此开发包括以一种仔细的可控制的方式复查。维护是不同的，作为维护人员，我们不仅回顾开发的产品而且建立用户和操作人员的关系。以弄清楚它们对于系统工作方式是否满意，我们也展望未来以提前发现将会出错的东西。考虑由于变化的商业需求而产生的功能性的改变并且考虑由于硬件软件或接口的改变而改变系统的需要。因此，维护的范围更广。有更多的事情需要去追踪和控制。下面让我门看一看为了使系统顺利地工作，并能区分操作人员而需要进行的活动。
传统的软件生命周期把维护描述成在软件投入使用后开始的。然而，软件的维护依赖于并且开始于用户需求。因此，好的软件开发法则将用于开发和维护过程。因为好的软件开发支持软件的改变，改变是在软件产品的生命周期中必须考虑的问题。而且一个看起来不重要的改变常常比预料的范围更广。影响分析是对许多改变可能产生的冒险的评估，包括对资源、工作量、工作计划的影响的评估。多个部分的改变的影响可以在形成的不适当的过期的文档中找到，如对软件的不恰当或者不完全的修补、设计或者编码的结构不清晰、不符合标准的自己造的东西等等。问题随着复杂性的增加、开发人员理解改变的代码需要的时间的增加以及代码的改变对系统其他部分的负面影响的增加而复合化。这些问题增加了维护的开销，管理倾向于使这种开销易于控制。我们可以使用影响分析来控制维护开销。