一.Capability Roadmap
- 通过创建逻辑路线图,为开发项目的决策制定提供一个框架,从而缩短时间期限、降低实现成本、提高可交付件质量和促进最佳实践。
- 技术和软件开发方面的进展,催生了旨在帮助实现更好未来的强大工作效率工具。
- 项目团队要遵循的结构化方法,以便团队成员能够回答该问题,从而提高成功的可能性。
2.Service realization viewpoint
- 服务实现视角模式创建的元素显示了一个或多个业务服务是如何由基础流程(有时由应用程序组件)实现的。因此,它形成了业务产品视角和业务流程视角之间的桥梁。它提供了一个或多个业务流程的“外部视图”。
- 该服务实现视角图展示了系统的借还书服务和罚款服务
- 绘制流程:要分两种情况,如果按照模板图来画,就要分析business roleA是哪位用户,business role B又是哪一位用户。如果不满足你的业务流程图,就要根据你的业务流程图对服务实现视角进行修改。因为本系统满足该模板,则需要找清楚process是从哪里开始进行的。
3.project roadmap
- Roadmap通常翻译为“路线图”或“蓝图”,目前并没有一个公认的定义。在这里,我们认为Roadmap是产品经理进行产品管理的一个中长期规划,也称路标规划。
- Roadmap主要有时间周期和项目事件(必备的工作项)和路标三部分组成。
- 时间周期。即产品规划的时间区间。通常,时间周期的长度是产品大版本(如3.0.0→4.0.0)开发周期的3~5倍,如果大版本的开发周期是3个月,那么Roadmap时间周期长度就在9个月至15个月之间。
- 项目事件。是指完成产品总体计划必须要完成的工作项。
- 路标。是指关键工作项的完成的时间接点,也称里程碑。
4.Organization Chart
- 使用环境:组织结构图可用于创建任何类型的图,包括:功能导向图,市场导向图或矩阵模型图。可以创建许多图表来表示企业的当前和将来的不同状态。
5.Business Motivation Model
- 如果企业为自己的业务活动规定某种方法,则应该能够说出该方法意图实现的目的和结果。该商业动机模型(BMM)是OMG支持的有关如何应对不断变化的世界的商业决策建模符号。企业将通过获取BMM建模工具,然后创建自己的BMM来使用它-用该企业特定的业务信息填充模型。有两个广泛的目的:
- 捕获有关对变化的反应的决策以及做出变化的理由,以期使这些变化可共享,提高清晰度并通过汲取经验教训来改进决策。
- 引用决策结果对运营业务的影响(例如,对业务流程和组织职责所做的更改),从而提供从影响者到运营更改的可追溯性。
- 愿景(可选):企业自认为是或渴望成为的简单易懂的摘要。所有目标均应支持(或至少不矛盾)愿景。
6. Motivation viewpoint
- 动机观点允许设计者或分析师对动机方面进行建模,而无需关注该方面中的某些元素。例如,通过与利益相关者,他们的主要目标,所应用的原理以及对服务,流程,应用程序和对象的主要要求相关联,可以使用此观点来呈现动机方面的完整或部分概述
7.Principles Viewpoint models
8.Requirement Specification View
- 软件需求规范是整个项目的基础。它奠定了每个参与开发的团队都将遵循的框架。
- 它用于向多个团队提供关键信息-开发,质量保证,运营和维护。这样可以使每个人都在同一页面上。
- 使用SRS有助于确保满足要求。而且,它还可以帮助您做出有关产品生命周期的决策,例如何时停用某个功能。
- 编写SRS还可以最大程度地减少总体开发时间和成本。嵌入式开发团队特别受益于使用SRS。
9.Composite Requirement Hierarchy
复合需求结构常出现在描述需求范围中
10.Requirements traceability Diagram
需求跟踪是指跟踪一个需求使用期限的全过程,需求跟踪包括编制每个需求同系统元素之间的联系文档,这些元素包括其他类型的需求,体系结构,其他设计部件,源代码模块,测试,帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符合用户需求。
11.Non Functional Requirements Diagram
- 软件架构的关键因素:非功能需求;功能需求;非功能需求可能来自用户.因为用户不光要功能,用户也需要质量.如性能,易用性等软件质量属性;质量属性差的软件系统大多数是不会成功的.因此在架构设计时,应该牢记软件的使用者---用户,不仅要满足用户的提出的功能要求,也要达到用户期望的质量.
- 非功能需求可能来自开发者和升级维护人员.软件的可扩展性,可重用性,可移植性,易理解性和易测试性等等非功能的需求.这都是不同的。
- 非功能性需求主要涉及安全性、性能以及兼容性三大方面。
- 通常用于软件测试中,对非功能性需求的测试,往往是决定软件质量的关键因素;或者当需求或业务分析师想要提供非功能性需求的可视化时,通常使用它;
- 目的:供不在存储库中工作的项目涉众使用。还有机会在多个项目或工作计划中重用这些要求。
12.Domain Model Diagram
- 图档使用目的:
- 领域模型为需求定义提供了领域知识和领域词汇。
- 软件界面的设计往往和领域模型关系密切。
- 领域模型是否合理将严重影响软件功能可能的范围。
- 由于分层架构的思想被广泛接受,领域模型经过精化之后会成为业务层的核心。
- 领域模型是设计持久化数据模型的良好基础。
13.Use Case Model、Sequence Diagram
14.Activity Diagram
15.Deploy Diagram
- 目的:描述一个具体应用的主要部署结构,通过对各种硬件,在硬件中的软件以及各种连接协议的显示,可以很好的描述系统是如何部署的;平衡系统运行时的计算资源分布;可以通过连接描述组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的系统运行模型。
- 部署图是结构图的一种,它展示了系统的架构。
- 部署图可以用于描述规范级别的架构,也可以描述实例级别的架构。这与类图和对象图有点类似。
16.Data Flow Diagrams
17.EA MySQL Install OR Simple Cloud install
使用目的:在EA中需要数据库表结构建模,但由于重写数据库十分繁琐,因此使用EA工具下的ODBC导入Schema功能进行导入已写的数据库表,建模的过程就会简单很多。
18.Create a new Database
使用目的:在EA中建立数据库,使用数据库建模是软件开发过程中极为重要的一步,建模后再具体使用相关软件进行开发,为我们节省了许多时间成本和精力。