SWE.2的软件架构设计

网友投稿 1268 2022-08-25

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

SWE.2的软件架构设计

过程ID:SWE.2

过程名称:软件架构设计

过程目的:软件架构设计过程目的是建立一个架构设计,识别哪些软件需求应该分配给软件的哪些要素,并根据已定义的标准评估软件架构设计。

过程结果:为了成功地执行了这一过程:

1)定义了识别软件要素的软件架构设计;

2)软件需求被分配到软件的组成部分;

3)定义了各软件要素的接口;

4)定义了软件要素的动态行为和资源消耗目标;

5)在软件需求和软件架构设计之间建立一致性和双向可追溯性;及

6)对软件架构设计达成一致并与所有受影响的各方进行沟通。

最佳实践:SWE.2.BP1:开发软件架构设计。开发并编制软件架构设计,该设计指定了与功能和非功能软件需求相关的软件要素。[outcome1]

注1:软件被分解为跨越适当的层次级别的要素,直到详细设计中描述的软件组件(软件架构设计的最低层次的要素)。

SWE.2.BP2:分配软件需求。将软件需求分配到软件架构设计的要素中。[outcome2]

SWE.2.BP3:定义软件要素的接口。识别、开发和记录每个软件要素的接口。[outcome3]

SWE.2.BP4:描述动态行为。评估和记录软件要素的时间和动态交互,以满足系统的动态行为需求。[outcome4]

注2:动态行为由运行模式(如启动、关机、正常模式、校准、诊断等)、过程和过程间通信、任务、线程、时间片、中断等决定。

注3:在评估动态行为时,应考虑目标平台和目标上的潜在负载。

SWE.2.BP5:定义资源消耗目标。在适当的层次级别上确定并记录软件架构设计的所有相关要素的资源消耗目标。[outcome4]

注4:资源消耗通常是由内存(ROM、RAM、外部/内部EEPROM或数据闪存)、CPU负载等资源决定的。

SWE.2.BP6:评估可供选择的软件架构。为架构定义评估标准。根据定义的标准评估备选的软件架构。记录所选软件架构的基本原理。[outcome1,2,3,4,5]

注释5:评估标准可能包括质量特征(模块化、可维护性、可扩展性、可伸缩性、可靠性、安全实现和可用性)和购买-复用分析的结果。

SWE.2.BP7:建立双向追溯性。在软件需求和软件架构设计要素之间建立双向可追溯性。[outcome5]

注6:双向可追溯性包括将软件需求分配到软件架构设计的要素。

注7:双向可追溯性支持覆盖、一致性和影响分析。

SWE.2.BP8:确保一致性。确保软件需求和软件架构设计之间的一致性。[outcome1,2,5,6]

注8:一致性由双向可追溯性支持,并可通过评审记录证明。

SWE.2.沟通商定的软件架构设计。与所有相关方沟通已达成协议的软件架构设计和软件架构设计的更新。[outcome6]

输出工作产品:04-04软件架构设计[outcome1,2,3,4,5]

13-04沟通记录[outcome6]

13 - 19评审记录[outcome5]

13-22可追溯性记录[outcome5]

17-08接口需求规范[outcome3]

原文标题:SWE.2软件架构设计

责任编辑:haq

上一篇:运维工程师的前景好不好(运维工程师是干什么的 前景又如何)
下一篇:2018年Linux运维必须抓住的前沿技能
相关文章

 发表评论

暂时没有评论,来抢沙发吧~