项目方案咬文嚼字

没有真正意义上使用过UML，偶然看到IBM开发社区上的一篇文章思路很顺。就想着整理到博客中来。

原文地址：http://www.ibm.com/developerworks/cn/rational/10/using-stakeholder-collaboration-strategy-with-requirements-composer-part1/

 

以下是根据原文和网上其它文章自己梳理的内容：

为以后写项目报告中积累点资料。

 

典型的商业系统涉及的领域：

-提供业务服务组件（ESB、SOA）

-相对独立的财务管理（ERP）

-资产方面设备维护和物流支持（ITIL、GIS+GPS）

-行政。。。未知

-监察。。。未知

-办公自动化商务流程（OA）

-决策支持（DSS）大学学的出来工作后未见到一个像样的

 

软件是什么：

是辅助工具。符合需求（业务需求），解决问题（业务目标）。

 

软件开发过程：

了解领域的业务概况和业务目标。

 

-潜在的问题：

在方案生命周期分析，定义和交流需求，是一项非常复杂的任务，它涉及到了很多的领域。可以导致很多的问题

业务与 IT 没有得到适当的安排，所以项目可能就不能交付预期值了

原始意图，内容以及规格的背景可能被误解

完全基于文本的文献很难理解

涉众在决策时不能访问完整的信息

涉众在评审时会误解文献，因为文献巨大的数量，缺乏可视性技术，非目标的内容，缺乏清晰的场景或者背景。

需求作者可能会从评审那里得到大量的回馈信息，这样就会十分的困难及耗时。

不健康的项目会经历不清晰的查看，不频繁的交流，以及处理不正确假设的团队

当涉众没有理解提供的工件，或者不把它们当做自己的责任时，需求作者就不会接受回馈信息，或者接受不足够的回馈信息

开发者不能轻松理解或者分清需求内容

团队在交流方面可能存在地域分布太过分散的困难

想要交流更改的团队发现想法很难沟通

不同的基础形成了协作以及定义可理解需求的障碍

 

-造成的影响：

创建了其他的工作以指定，设计，开发和测试系统。

当涉众不能访问工件时可能的再使用和生产力会丢失掉

涉众不会交付回馈信息，因为找到相关的工件是很困难的

涉众并不是总是交付回馈信息，或者交付高品质的回馈信息，因为理解需求是很困难的

当测试员不能找到相关的信息时，他们不能轻松促进测试

地理分布的项目生产效率低下，成功几率降低

对业务的变更和响应性受限制

大量高成本受控的需求会扰乱可能提供的业务价值

方案的晚期交付性

更高的成本

降低的品质以及不能向业务交付预期价值的方案

降低的信任感，并且损害了业务与 IT 单元之间的关系

降低了IT的可信度以及信誉

 

-成功的方案带来：

有助于需求分析，定义，确认和方案生命周期内涉众之间的协作交流。

更好地理解涉众的需求，并使得涉众就促进方案开发达成一致意见，该方案会向业务涉众交付价值。