关于企业级统一软件需求管理的设想全解.ppt

* * * * 企业级统一软件需求管理 * （一）以文档的形式存在 （二）以项目为核心 软件需求以软件需求说明的书的形式存在，在以人工管理的时代似乎没有任何问题。但是在电子化管理的时代，已经无法满足条目化、精细化管理的要求。 需求文档的项目的依据，从项目的角度看需求文档没有问题。但是项目只是一种组织形式，项目的成果最终以应用的形式沉淀下来。项目仅仅是整个应用体系的一个局部快照，简单的需求文档无法切实反应，业务需求与现状之间的关系。 一、软件需求管理面临的问题 * 二、企业级统一软件需求管理 企业级统一软件需求管理 对管理的价值 建立企业级业务需求完整视图 深入了解企业业务范围及内容 为以企业级业务规划提供依据 对开发人员的价值 完成了需求的条目化，为后继工作开展，任务的指派提供了依据 模型化的业务需求能够更好的与模型化业务设计相对接 能够明确是新增业务需求还是业务需求变更，对于需求变更可以迅速定位。对于需求变更可以迅速定位到现有的开发资源 业务描述的标准化为实现标准胡提供依据 对于质量管理的价值 条目化的业务需求为测试设计和组织提供了有效依据 通过业务需求能够准确建立实现与测试之间的关系 通过标准化描述，为测试的标准化提供了依据 对应用系统的价值 通过统一建模管理，建立业务需求与应用系统之间的关系 有助于实现业务规划与应用规划之间的双向支持 业务需求影响性分析的依据 * 对业务的价值 更直观的业务管理 明确具体业务需求与现有应用之间的关系 确立一致的需求标准，统一业务规则 业务描述更标准、更明确，便于与开发团队的沟通以及建立测试验收标准 （一）采用统一的工具软件 （二）以企业级整体业务布局为核心 通过建立统一的工具软件，将业务人员、开发人员等相关人员统一到相同的环境中。建立相似的工作环境，有效进行多层次的工作协同。 业务需求以企业级整体布局为核心，项目只是全局业务的局部快照。业务需求围绕企业整体业务架构进行组织。项目仅引用与本项目相关的部分业务需求。基于业务需求的变更，也可以在宏观上对变更进行影响性分析。 三、基本设计理念 * （三）整合资源管理与任务管理 资源并不是孤立存在的，资源本身的生命周期的变化也意味着需要相应的人员进行相应的工作。通过将资源管理和任务管理的整合实现了标量的任务管理，在后期结合持续集成、测试驱动等手段可以在无需手工维护的情况下，实现对工作进度的把控。 （四）基于软件架构的统一建模 统一业务需求是整体研究课题的一个入口。业务需求模型将与后继其它模型建立紧密有效的管理，从而实现对企业级应用系统全方位的管理，直至代码实现。 （一）Microsoft Team Foundation Server 2015 （二）Visual Studio 2015 微软的TFS不仅提供了版本管理还提供了工作项管理、任务管理、测试管理和部署管理等诸多功能。TFS不仅提供了.Net接口和Java接口而且提供了REST API，可以与多种环境进行集成。目前也是互联网金融的管理工具。在研究可提供中将TFS作为核心服务器。 Visual Studio是.Net环境的首选开发工具，而且提供了丰富的API，即使是免费版本也能支持研究课题需要展示的所有功能，而且还可以通过SDK制作定制版本。受限于参与研究课题人员的技术能力，选择了Visual Studio作为公共客户端工具。在此使用了Visual Studio SDK（类似Eclispe插件开发）、Visual Studio 建模SDK（类似Eclipsse EMF + GMF）、Visual Studio集成和独立Shell（类似Eclipse RCP） 四、研究课题基本技术路线 * （三）WPS 2016 在整个研发体系中，虽然核心数据都在TFS中条目化管理，在局部工作节点还是需要提供文档形式的内容集合，例如用于需求评审的《业务需求说明书》等。在研究课题中会通过WPS的API自动生成相应的文档。通过自动化生成，不仅提高了效率更重要的是确保了一致性。 （四）其它 作为研究课题，限于参与人员的的技术能力选择了上述平台。本着设计思想与实现的相对独立，也可以采用其它的技术路线实现相同的目标。 业务项目是整体业务需求架构的局部快照，描述当前项目涉及的所有业务需求。业务项目引用一个业务分类作为业务需求的整体范围，项目中所有业务分类、业务和业务需求都是在继承业务需求架构视图中的相关项关系的引用。 （一）业务需求架构 （二）业务分类 业务需求架构是所有业务需求的根节点，通过业务需求架构树构成了整个企业级业务需求视图。在TFS的项目中有且仅有一个业务需求架构节点。 业务分类在研究课题中简化为目录， 分类可以嵌套。所有的一级业务分类都是业务需求架构的子级，根据我行现状预设业务部门为一级业务分类。在理想状况下