软件需求评审_软件适航QA集

这是平时遇到比较多的问题。如果有其它问题请在评论区提出，会在后续整理并在本帖更新。

---

1. 什么是参数数据项文件（Parameter Data Item File）？

举个例子，有时候我们做软件的时候，有可能软件本身用到的一些参数会经常变动，针对这些参数，常见的有三种做法。第一，最不方便的做法，把这些参数在程序中写死，每次修改参数的时候打开源代码进行修改，其实这种做法在代码格式比较规范、修改又不频繁的情况下也还是可以接受的。比如把所有参数变量集中卸载一个源代码文件中，这样每次修改也比较好找；第二，把参数作为初始化的动态输入项，由初始化函数从外部读入，一般这种做法需要有输入界面，我们原来写PC程序经常这么做，只要在输入UI界面中将所需值填入即可；第三，对于嵌入式软件，或者说没有输入界面，而且前期更改几次，一旦确定后基本不太更改的情况下，使用输入文件是最好的方法。也就是说，以一定的格式把所需数据写入某个txt文件或规定格式的文件中，程序执行前自动去该文件中获取所需要的参数值即可。PC软件中常用的XML输入文件就是其中一种。飞机上，各种各样的配置表就属于这一类。参数数据文件中的每一项数据被称为参数数据项。

2. 什么是验证？

Verification and Validation.我们通常说的验证和确认。容易搞混淆的，一个概念是验证和确认，另一个是验证和测试。验证和确认都是比较大的概念，是一种确认对象是否正确的方法，它可能包括评审、分析、测试、仿真等等不同手段。所以说，测试仅仅只是支持验证或支持确认的一种方法。DO-178C中不提确认（Validation），所以我们就先说验证。计划阶段要求写验证计划，那么验证计划中就需要具体写我的五份计划文件采用什么方法来验证（如计划评审）、需求采用什么方法来验证（如需求评审），等等。实际上，在目标代码出来之前，因为无法测试，所以基本都是采用评审的方法（当然有工具的话也可以进行仿真），计划评审、需求评审、设计评审、代码评审等都属于这一类。之后会有基于需求的测试、测试覆盖率分析（这是分析方法），等等，具体按照178C的目标要求执行。每种方法还要写清楚进入的时机和准则，记录的方法等等。

那么验证和确认什么区别呢？学过系统工程的知道有这么两句话，验证就是Do things right（正确的做事）， 确认是Do right things（做正确的事）. 具体怎么讲呢？拿确认来说，我怎么知道我做的事情是不是正确呢？当然是靠用户需求来判断。用户说我的需求是从西安飞到北京，那么最后只要到了北京，而且是飞去的，那就算做了正确的事。至于怎么做，选南航还是选东航，那是属于验证的事。换句话说，针对用户需求的验证就是确认。那178C中为什么没有确认呢？因为软件的需求是系统分配的，也就是说，用户需求从某种层面来讲可以认为是系统需求。而对系统需求的验证是在系统级别要做的事情，软件不需要做，也就不用提确认的事情了。

3. 追踪数据的重要性？都包括哪些？

追踪数据能帮助梳理高层需求、底层需求（设计）、源代码之间的一致性，还能在影响分析的时候帮助确定受影响范围。从需求到代码的正向追踪可以证明每条需求都进行了实现，反向追踪能证明没有多余代码产生。

追踪数据包括高层需求和低层需求之间、低层需求和源代码之间、所有需求和测试用例之间、测试用例和测试程序之间、测试程序和测试结果之间的双向追踪。

5. 适航联络过程如何做？

适航联络过程主要是TC申请人的责任，软件供应商的职责仅仅是支持。如果只是为了写PSAC，那么相应章节只需要提到PSAC、SCI、SAS的局方提交，其余文件可以应局方要求进行提供（提供可以包括提交和现场供查两种方式），以及对SOI审查的支持，其余联络责任由TC申请人承担即可。

对于TC申请人来说，适航联络过程就包含更多的内容，但具体过程是一个case by case的情况。需要完成的包括，与局方商定机载软件的适航符合性方法、与局方的日常沟通方式的确立、四次SOI审查的方式（哪些桌面审查，哪些现场审查，哪些局方确认要参与，哪些交由DER执行等等），审查通过的形式等等。具体商定的方式不限定，应与局方审查组共同商议决定。