关于如何开发能够适应不断变化的业务需求的软件的想法?任何模式,架构等。可能一些轶事的例子会很棒。这不仅仅是一项调查而是一项具体问题。感谢
答案 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)
考虑业务需求变化的规模:
答案 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"以一种非常有趣的方式解决了这个问题。