软件详细设计和单元构建过程的目的是为软件组件提供一个经过评估的详细设计，并据此构建软件单元。
在软件架构设计中，为了实现软件需求，将软件划分为不同的SW Component，定义了每个SW Component的职责、以及不同SW Component之间的接口和交互。
软件详细设计是基于软件架构设计中定义的SW Component的职责和接口，进一步将SW Component划分为SW Unit，并设计SW Unit之间的接口和交互、以及每个SW Unit的内部逻辑。
什么是SW Unit？
很多人非常关心这个问题，与该问题有关的一些误区包括：
只有接口函数需要做详细设计，内部函数是组件内的，外部感知不到，不需要详细设计
C++/Java中的类私有函数，不需要详细设计
说明：在比如车联网、自动驾驶等领域，存在车内SW接收外部服务器SW的数据的场景，外部服务器SW有时是C++/Java开发的。
ASPICE中的SW Unit定义：
Part of a software component which is not further subdivided. (软件组件的组成部分，不能被进一步拆分了)
某OEM对其供应商的要求中，定义的SW Unit：
A unit is the smallest separately executable and testable entity of a component. (软件单元是软件组件中的，能独立执行和测试的最小实体)
A unit encapsulates data and statements on the level of a function (C), method (C++, Java) or procedure (Pascal). (在C语言中，软件单元是函数；在C++/Java中，软件单元是方法；在Pascal中，软件单元是Procedure)
综上所述，软件单元在C语言中是函数（接口函数和内部函数），在C++/Java语言中是类成员函数（私有 & 公有）。
软件详细设计
软件详细设计是SW Component的解决方案，在设计解决方案时，一般需要考虑：
非功能性的技术需求：如性能（如：响应时间、采样时间、cycle time等）、功能安全（如：安全通路、故障容忍处理等）、信息安全、具有确定接口的COTS软件组件等
可维护性的需求，如可用性、简单性、高内聚低耦合、可测试性、可分析性、可更改性等
业务需求，如成本、可移植性（如：重用、平台、既存接口等）、可调节性等
软件详细设计需要通过不同的视图（如：静态视图、动态视图）来进行展示，方能让相关方都对软件详细设计有清晰和明确的掌握和了解，以利于对详细设计能进行沟通、讨论、评审、评价、变更影响分析、维护等。
静态视图：是将SW Component分解为SW Unit，分解后的SW Unit可以方便进行管理，包括将需求分配到SW Unit，或分配SW Unit的开发任务等。
动态视图：展示SW Unit之间的交互（如：函数调用关系、时序图等形式）、每个SW Unit的内部逻辑（如：函数流程图的形式）
在项目中，需要根据需要来选择合适的方式展示软件详细设计。
模型开发场合，模型就是详细设计吗？
目前越来越多的应用层软件是基于模型开发(MBD)，在这种场景下，模型本身是不是就是详细设计？还需要写另外的比如Word文档的详细设计吗？
业界的相关标准规范中，均没有一刀切的给出上述问题的答案，这个问题的答案更多的是需要基于场景。
软件详细设计的目的是展示SW Unit之间的关系、定义SW Unit的职责和接口、以及每个SW Unit的设计。如果模型设计能够完全达到这个目的的话，没有另外的比如Word文档的详细设计，是可以接受的。但有些时候，特别是SW Component的内部结构比较复杂的场合，只是模型设计很难达到上述目的。
目前很多的OEM和供应商，是要求其开发团队要做单独的详细设计的。
接下来看看VDA Guideline中的一些规则要求
1）开发软件详细设计
<ASPICE模型要求>
SWE.3.BP1: 开发软件详细设计 / Develop software detailed design
根据功能性和非功能性软件需求，为软件架构设计中定义的每个软件组件开发详细设计
Develop a detailed design for each software component defined in the software architectural design that specifies all software units with respect to functional and non-functional software requirements.
[SWE.3.RL.1] If the software detailed design does not reflect dynamic views the indicator BP1 shall be downrated.
老杨解读：如果软件详细设计中没有反映动态视图，则应降低BP1的打分。
[SWE.3.RL.2] If the software detailed design does not reflect applicable non-functional requirements the indicator BP1 shall be downrated.
老杨解读：如果软件详细设计中没有反映出适用的非功能性需求，则应降低BP1的打分。
2）定义软件单元接口
<ASPICE模型要求>
SWE.3.BP2: 定义软件单元接口 / Define interfaces of software units
识别、定义和记录每个软件单元的接口
Identify, specify and document the interfaces of each software unit.
[SWE.3.RL.3] If the software interface definition is absent or incomplete regarding the definition above the indicator BP2 shall be downrated.
老杨解读：如果软件单元之间的接口是缺失的或不完整的，则应降低BP2的打分。
说明：软件单元的接口往往是函数接口，接口定义需要包括：函数名、参数/返回值的含义、数据类型、数据范围等
3）描述动态行为
<ASPICE模型要求>
SWE.3.BP3: 描述动态行为 / Describe dynamic behavior
评估和记录相关软件单元的和软件单元之间的动态行为和交互
Evaluate and document the dynamic behavior of and the interaction between relevant software units.
[SWE.3.RL.4] If evidence of describing dynamic behavior regarding the topics mentioned above is missing the indicator BP3 shall be downrated.
老杨解读：如果软件动态行为的描述有缺失，则应降低BP3的打分。
说明：动态行为一般包括与功能相关的动态行为（如使用时序图、状态迁移图、数据流图、过程图等来展示动态行为）、与并发处理或响应时间相关的动态行为（如使用任务、中断、时间片、调度等展示动态行为）
4）软件详细设计的评价
<ASPICE模型要求>
SWE.3.BP4: 评估软件详细设计 / Evaluate software detailed design
从互操作性、交互、关键性、技术复杂性、风险和可测试性方面评价软件详细设计
Evaluate the software detailed design in terms of interoperability, interaction, criticality, technical complexity, risks and testability.
[SWE.3.RL.5] If none of the three described approaches for detailed design development is observable in the assessed project, PA 1.1 shall be downrated.
老杨解读：如果在被评估的项目中，没有看到如上三种详细设计的开发方式中的任何一种，则需要降低PA1.1的打分
说明：
VDA Guideline中，在软件详细设计这个部分，给出了与“SYS.3 系统架构设计”、"SWE.2 软件架构设计“相同的要求。（该要求的描述参照：ASPICE VDA Guideline解读(12)：SYS.3 系统架构设计），对该要求，本文作者存在不同意见
SWE.2/SYS.3中确定的是架构，架构对于产品来说是非常重要的，需要&值得采用系统化的、非常正式的方式对所选择的架构进行评价。
软件详细设计是对每个SW Component进行的设计，BP4是要求从软件单元的互操作性、交互、关键性、技术复杂性、风险和可测试性方面评价软件详细设计。不需要像评价架构设计那么正式，一般也不需要去评价几个备选方案并从中选择一个最合适的架构方案。需要的是：
基于BP4的要求定义软件详细设计的准则，如：圈复杂度<=10（关注技术复杂性）、调用本函数的函数个数<=5（关注交互性）、本函数调用其它函数的个数<=7（关注交互性）等。
基于定义的上述准则，对每个软件详细设计进行评价
[SWE.3.RC.1] If the used procedure for detailed design selection does not involve the required parties or competencies, the indicator BP4 should be downrated.
老杨解读：如果在详细设计选择评价过程中没有包括必要的相关方，或缺失相关的能力，则应降低BP4的打分。
5）开发软件单元
<ASPICE模型要求>
SWE.3.BP8: 构建软件单元 / Develop software units
根据软件详细设计，开发和记录每个软件单元的可运行的表示
[SWE.3.RL.6] If software units contain content which is not described in the detailed design, the indicator BP8 shall be downrated.
老杨解读：如果软件单元中包括的内容没有在软件详细设计中进行描述，则应降低BP8的打分。
