适应不断变化的业务需求?

时间:2009-01-21 16:58:08

标签: architecture design-patterns

关于如何开发能够适应不断变化的业务需求的软件的想法?任何模式,架构等。可能一些轶事的例子会很棒。这不仅仅是一项调查而是一项具体问题。感谢

9 个答案:

答案 0 :(得分:7)

您需要了解有关整个Agile Development运动的更多信息。敏捷就是它所说的:能够快速适应。

答案 1 :(得分:2)

在我看来,特定的代码比通用抽象代码更容易改变。因此,如果您希望代码可以更改,请坚持使用特定代码并避免元编程。

从现在开始的6个月,很可能没有人会理解那些广义和抽象方法的真实用例,并且害怕改变它们。

答案 2 :(得分:2)

如果这是您的开发环境,您将需要使用Agile development process

作为此过程的一部分,您可能希望不断拥有一个工作系统来向您的客户展示,以便他们可以在此过程中进行课程更正。它将帮助他们了解正在取得的进展以及您所处的位置。但更重要的是,它将使他们更好地了解系统如何与当前的业务需求一起工作,以及他们的新变化将产生什么影响。

请注意不要让原型具有视觉吸引力。 如果原型看起来有图形抛光,那么您的业务开发人员很可能会认为该软件很多比实际更完整。我建议尝试让它看起来不那么精致,更专注于功能。例如,如果您正在使用Java Swing,那么有一个很棒的look & feel called Napkin可以帮助解决这个问题。 IT允许您根据需要构建尽可能多的功能,但屏幕看起来像是在餐巾纸上绘制的。所以人们的注意力和焦点都集中在功能上,而不是图形细节上。

答案 3 :(得分:1)

尝试设计一个通用系统,可以轻松地根据不断变化的需求进行定制,但不起作用。正如Mark建议的那样,整个敏捷运动的发展源于一种简单的特定代码比通用代码更容易适应的认识,只要它编写得很好并且可维护。

答案 4 :(得分:1)

Domain-Driven Design是一个很好的方法,有一本好书可以帮助你开始。

这种方法的一个重点是软件中使用的开发领域模型与其建模的实际“真实世界”之间的紧密反馈循环,因此不断变化的现实世界很好。

答案 5 :(得分:0)

(几乎)每个程序都有不断变化的业务需求。 尝试与客户谈判(营销或产品经理也是客户)很重要,但永远不够。要求总是在变化。 Scrum有很多技术来管理需求的变化。 this是对scrum的精彩视频介绍。值得你花时间

答案 6 :(得分:0)

考虑业务需求变化的规模:

  • 如果小规模的需求经常变化,即人们改变他们想要的想法,但他们需要做的事情并没有真正改变,那么采用敏捷实践并保持你的迭代非常短(只需1个特征迭代) ,如果有必要真正完成某事!)
  • 如果大规模的需求经常变化,即运营业务需要什么样的基础设施,这可能反映了管理层的变化(我认为是“最后一个推销员综合症” - 无论上一个销售人员销售的是什么突然之间的未来之路)。如果您参与这些决策,请尝试将技术问题减少到基础(通信,存储,计算,交互,访问......),不要被产品级别的花里胡哨分散注意力。请记住,没有什么可能是100%合适,但是经常改变主意的成本可能超过改变平台或架构的好处。如果你没有参与这些决定,那么除了快速学习并轻轻地鼓励你做出更深层次的承诺之外,你无能为力; - )
  • 如果业务的性质经常发生变化,即每隔几周需要新的业务线,旧线路得到整合,等等,并且您参与了此级别的讨论,您可以尝试通过探测来预测未来的变化深入了解公司计划。如果你没有涉及这个级别,那么在你找到一份更稳定的公司工作之前,尽量保持灵活性和宝贵的价值; - )

答案 7 :(得分:0)

考虑业务规则引擎。并不总是合适,但可以帮助您从技术架构/解决方案中分离业务逻辑和需求。例如,假设您需要根据一组测试结果设置汽车的安全等级。在汽车上进行的测试可以改变,分类标准也可以改变(包括实际的分类数,例如从5星系统到10星系统)。鉴于这种情况,业务规则引擎可能是对汽车进行分类的好方法。

规则引擎将提供基于文本或XML的规则,理论上至少可以由非编程人员(例如业务分析员)编写和维护。这些规则将应用于Car对象(假设Car对象包含对TestResults对象的引用)。规则/规则引擎将分析测试结果并相应地设置SafetyClassification对象的Car属性。

实际规则可以驻留在数据库或共享位置,甚至可以通过消息传递基础结构或Web服务调用提供给系统。可以向系统提供新规则并激活而无需重新编译/重新部署系统。

不同的技术可以使用不同的规则引擎。 E,g,.Net有Drools.Net,WWF规则引擎,以及其他几个。 Java有JBoss规则以及许多其他规则。

答案 8 :(得分:0)

我认为Stephen Mellor的文章"Coping with changing requirements"以一种非常有趣的方式解决了这个问题。