开通VIP，畅享免费电子书等14项超值服
首页
好书
留言交流
下载APP
联系客服
2021.11.09
本文目录：
一、系统工程运行的基本要义
1、系统工程运行从工程系统的论证开始
论证是为拟实施的工程项目的技术先进性和适宜性、经济上的合理性和盈利性、实施上的可能性和风险性进行全面科学的分析，为工程项目决策提供客观依据的一种经济研究活动。
我们的项目在论证之初，更多地聚焦于总体和控制等核心专业，这使得在最初的论证时，对于各关键技术、关键产品技术水平和现状的把控不好，论证表现出的以自我认知为代表的的主观性色彩更浓一些。
2、系统工程全面运行的标志是任务书的形成
显而易见，任务书是需求方向承担任务方下达的具有法律效力的、包含了产品各项功能、性能指标要求的文件，这类文件至关重要。
既然任务书是系统工程全面开始运行的标志，所以务必高度重视任务书的编制和下达，一定要行程一套全面的、定量的、以工程各项指标为内容的任务书。系统级任务书在出手和接手时，均需要组织针对性的评审，而非简单地提出和一味地接受，必要时，任务承担方要积极参与任务书的编制工作，在过程中更好的沟通交流，确保工程任务要求的可实现性。
除此之外，各层级任务书在形成和分解过程中，要形成任务需求的跟踪矩阵，输入要求是什么，输出实现又是什么，指标怎样，一次闭环各层级的要求，同时确保任务需求无遗漏。
3、系统工程的全寿命周期特性
系统工程的终点不以产品的交付为运行终点，会因产品的使用而一直运行，一个典型的例子就是卫星的在轨运行，以及装备的战备值班等，直至系统产品寿命周期终结。对于一个庞大的系统工程而言，其运行周期较长，对于批量交付产品的系统工程而言，系统工程的运行以产品退出使用未终结点。
二、系统工程运行的特点
1、系统工程运行的连续性
系统工程的工作是分阶段的，每个阶段有其任务和预设的目标，正因为区分了不同的阶段，即要求在不同阶段衔接时，做好上一阶段的总结和下一阶段基线的确认，这也就是平时工作中的转段，前提是迁移阶段工作的完结、目标的达成，否则阶段的划分就形同虚设，也就起不到有效的约束并开启下一阶段工作的目的，使得整个系统工程任务不再连续。
此处就有了过程跟踪、节点控制、里程碑考核的基本要求，其中的里程碑考核，更是赋予了系统工程运行的节奏感，这也恰恰是系统工程展现出的分段实施、分段控制特点。
2、工程目标的量化
只有量化的指标和目标，才能有效地将要求和技术指标传递下去，保证各系统的统一性和目标一致性，同时规避因理解不一致而导致的歧义，进而造成技术、产品实现的偏离。量化的目标保证了整个系统工程目标的度量和测试验证，对产品和工程本身可以进行有效的评价。
但在整个系统工程实现和运行过程中，总会有难以量化的环节，更多的体现在结果表征层面，然而并不是没有办法，结果不可度量，并不意味着过程控制的不可量化，于是有了关键过程控制和“四不到四到”，通过细分过程的量化控制，保证最终指标的达成。
也就是定性定量化的概念，分等级，可能性，百分比，概率等，如风险的等级，技术和产品成熟度的区分。
3、性能指标的均衡性（统筹性）
此处的均衡更多的却是指统筹而非平均。
比如可靠性指标的分配，需要视技术、产品的成熟度来展开，极少见所有单机的可靠性指标给出一个值，毕竟越过于复杂的单机，串联的环节越多，可靠性指标也就会越低，对于系统、分系统而言也是如此。
所以需要在突出重点的基础上兼顾其他。
一个大规模的系统工程，各个系统的技术难度、生产加工难度、投入的资源等会因自身特点而各不相同，同时需要兼顾整个系统工程的成本要求，所以没有必要要求所有的系统、所有单机的技术指标都达到最高值。
因此，所谓的均衡是要求关键系统、单机指标的提升。
对于一个系统而言，也绝非要求各项指标都做到最优，有复合导航的飞行器，针对惯性器件的某些要求可以适度降低，飞行过程中机动幅度不大的，则对伺服机构动态要求也可以适度降低。
均衡是兼顾下的重点突出，将经费和精力聚焦在能够保证成功的性能指标的完成上，切不可为了一些环节投入过多的人力和物力，成本居高不下以至于超概。
4、方案的集优性
方案的集优性是指在确定大方案和系统方案时，综合考虑不同方案的优点，并将其集成，换言之就是要规避其他项目曾将犯过的错误，在分系统、子系统层面，集优性也是必须要考虑的，对于系统工程而言，我们有足够的积累去做集优，因为成功的样本足够多。
在涉及到新技术较多的项目中，进行方案集优时首当其冲要发挥好组织作用和专业优势，保证集优的效果。
5、可信度的连续性
在系统工程初期，对各个组成系统的认知是不全面、待深入的，随着研制的进展，才会逐渐有一个全面、深刻的认识，尤其是针对庞大复杂的系统工程，系统构成复杂在先，一般又会采用全新的技术和产品，决定了其与过往的项目一定存在变化和不同，这些也正是系统工程人员所把握的重点。
确信和不确信，是整个工作的重点，工作充分之后，可信度才会有所提升。
6、性能指标的流动性（要求的纵向贯通）
这需要对余量的共同掌控，从整个工程层面。
为了保证性能指标的流动性，首先是量化，然后是全程的跟踪和检查。
7、最佳概念的相对性
系统工程的最佳和最优，体现的是系统的最优，而非所有环节的最优，质量和成本的最佳搭配才是最优，产品之间的最佳搭配才会做到质量和成本的最优，适用的技术+产品达成的适用系统级产品，这才是一个最优的结果。
譬如试验验证，有时候仿真+部分试验验证反而是一种好的选择，毕竟地面模拟所有的工况不太现实，边界验证可以通过注入和仿真去实现。
8、系统工程要求的全息性
各个层级均需要执行系统工程的所有要求，不能够逐层衰减，实际过程中除了任务书、技术条件和各类型大纲之外，剩下的最为关键的就是质量要求了，而质量要求的落实受限于配套方质量体系和所属行业，这其中的不理解和没有必要成为质量要求向下传递的最大障碍。
全息性的要求可以理解为两层意思，一个层面就是要求传递到各个层级，另一个层面就是要求的全面性传递。
全息性也可以逆向一下，也就是各层级对总体或上一层级信息传递和提供，以便于上一层级根据必要的信息（数据包）分析和决策一些事情。
三、系统工程的风险分析
1、风险产生的源头
风险取决于暴露的程度、遗漏的条件、预案的覆盖和工程的透明。
暴露的程度是指工程研制过程中问题暴露的程度。遗漏的条件是指试验验证条件不完备、不完整的程度。预案的覆盖即紧急异常、故障预案的覆盖和可执行性，在设计实现中考虑得越周全，则预案覆盖的程度越高。
工程的透明，即是指在研制过程中对技术细节、问题、进度、成本等额把握度，把握得越好，过程失察的环节就越少，工程的透明度越好。
2、暴露的程度
取决于各种类型的仿真试验和试验验证，在过去我们通过不断出问题、解决问题去保证，但随着进度、成本要求的提高，则需要我们在试验过程中更多地暴露问题，这需要针对性地完成试验设计，以及不放心环节的梳理。
实际上在某些项目的研制过程中，如果在使用之前出现了一大堆问题，哪怕是多么不堪的问题，但项目团队以及外界却都会因此而对后续充满信心，一个说法就是问题已经得到了充分的暴露，这不无道理。
对于不可测试环节，前面已经提及通过过程的量化控制和检验最大限度地规避问题，这是其一，然后司使用工况下的验证或仿真，对于项目新增技术、产品引入的不可测试环节，一定要有一定数量的试验去验证其在系统中的适用性。
3、遗漏的条件
条件即是指诱发问题的条件、环境或诱因，决定了问题暴露的程度，也就是如果斩断问题激发的诱因，则问题就不会发生，需要与工程系统本身的固有薄弱去统筹考虑。
一台产品，如果本身电磁兼容性差，而所处的电磁环境又比较恶劣，也没有进行必要的电磁屏蔽，消除此问题比较妥帖的方式还是综合治理，自身电磁兼容的提升是根本，必要的电磁屏蔽。
提及诱因时，也需要充分考虑以下自身的健壮性，这才是系统思维。
试验越充分，遗漏的条件就会越少，暴露的问题也就越多，由此引出了试验的完备性和充分性问题。
完备解决的是应该测试的环节是否都已经进行了测试的问题，比如设备未见面、未联调即用于最终的使用，这属于典型的该测未测；又比如惯组的六自由度试验，验证的是其在振动条件下的导航精度，以及惯组在振动条件下有无异常，这些可以纳入到惯组的验收试验中去，进一步讲，一台产品如果不做验收试验就属于试验的不完备。
与之对应的产品的例行试验则属于试验的充分性，试验条件是否满足，特定的试验条件是否能表征和覆盖使用工况，而实际上一般例式条件都略高于使用工况。
试验的完备性和充分性在遗漏条件规避过程中的重要性相同，试验不完备，则试验不会充分。
4、预案的覆盖
预案是针对潜在的或可能发生的质量、安全故障的类别和影响程度而事先制定的应急处置方案，其是系统工程运行中一项非常重要的工作内容和环节。
预案一定是针对操作手册或是规程而来的，此处专指细致程度，包含了最低发射条件、逆流程操作、现场故障排查等诸多环节，最好的预案，应该是嵌入进流程操作，只有这样才能够保证最大程度的覆盖。
此外，预案的覆盖体现为预案的演练，未经演练确认的预案难以支撑重大问题异常的处置。同时在针对预案的分析和演练过程中，可以进一步查找遗漏的条件，最大限度地提升暴露问题的程度。
5、工程的透明
所谓透明，是指整个项目团队之于研制的把握程度，不囿于各项管理活动，也包括一些关键的技术管理活动，内容包括研制信息、进展、问题信息等的及时通报和沟通。
工程的透明之于工程的研制尤为重要，比如系统的接口、子系统的余量等各关键信息，遇到的瓶颈和困难，必须为系统和上一层级有效地把控，以便更好地从大系统维度策划并开展针对性的工作。
指标达到的程度，质量管理的状况，问题的处置，经费和计划的安排，都需要做到透明，避免问题在某个阶段集中爆发。
各层级的评审，协调，定期的检查都是提高工程透明度的有效方式，当前一些项目的周例会现实地发挥了这个作用，但也说明了我们在策划和计划执行过程中仍然存在一些需要改进的环节。
而实际上工程透明的最佳方式还是与最基层的工程技术人员进行深入地沟通，尽管这被认为是不符合行政层级及隶属关系的约束（越级），但这种模式往往是最为有效的。
四、系统工程运行的阶段划分
1、研制阶段的划分
一般情况下，可以归纳区分为定义、设计、建造和交付四个阶段，似乎与我们平时所讲的论证阶段、方案、初样、试样、定型交付阶段有所不同，但在实际上是一致的。
对于一个项目个基点的划分可以根据不同的项目特点而有所区分，在设计、建造阶段，对于系统工程而言，却是比较难以区分的，方案、初样、试样，从当前项目研制来看，无论是初样开始应用验证还是试样开始，都可以划归为设计阶段，但在方案阶段主要是对关键技术、产品开展设计和验证工作，只有在初样及以后才会针对系统工程的功能需求全部转换为系统和分系统的设计，同时实现性能指标要求，此外要保证所有技术指标的可观测性。
（1）定义阶段
定义阶段主要是完成各系统的需求分析、项目论证和概念性设计，形成研制工作的总要求，对于系统工程而言，首先要进行工程系统的需求分析，其次是在需求分析的基础之上提出各系统的功能要求，并形成各系统的总体技术要求，进而确认分系统的组成及技术指标的分配，一并梳理出关键技术风险及攻关建议。
定义阶段等同于论证阶段。
（2）设计阶段
主要工作包括系统、分系统、子系统的研制及试验，整个大系统的集成与各种大型试验，包括技术参数的试验验证、环境试验验证、可靠性试验以及系统性试验。
（3）建造阶段
一般可以归结为系统工程研制的最后一个阶段，进入建造阶段的标志是技术攻关已经完成，风险已经得到释放，技术状态、工艺状态都得到了固化，此阶段的主要工作就是严把质量关和安全关，同时要完成大量的系统性验证、鉴定试验，为整个交付奠定基础。
在建造阶段，要执行严格的拒收拒付规定。
（4）交付阶段
此阶段即交付、部署、使用或值班，对于小项目而言一般为批产交付。
2、研制阶段划分的本质
之所以将系统研制划分为这四大阶段，是因为系统工程的复杂性和特点，定义、设计、建造、交付，是系统工程运行的四个基本阶段，四个阶段的侧重点不同，因此在质量体系和研制流程中，我们设置了诸多的质量控制点，以确保系统工程顺利运行。
研制阶段划分的根本在于技术成熟度和产品成熟度，这两个成熟度的提升过程以及结果，是整个系统工程工作的重点和目标。
（1）选用技术和产品的成熟度
全新技术、产品的成熟度一定不会高，整个研制的过程必定伴随着单机、系统性问题的不断涌现，如果一个系统工程所采用的的技术、产品采用全新的模式，其实已经背离了系统工程的初衷，所以系统工程必定是继承和创新的组合体，两者的占比由系统工程的目标所决定。
退一万步讲，即便是一个继承度很高的系统工程，也会面临着系统性技术问题。
（2）成熟度到了一定程度，研制阶段划分的简化
从细分的工程研制阶段而言，方案+初样即可以解决掉大部分问题，剩下的重点工作就是建造和交付中的难题。如果有基础，这几个阶段的主要工作应该是以过往项目发生过的问题为导向，去规避一些麻烦。
（3）聚精会神对待全新环节
系统工程研制经验表明，凡是新技术、新产品在应用中总会遇到各种问题，一方面是技术未吃透、产品未吃透，这符合客观规律；另外一方面说明前期论证时应该启动的技术创新、积累和产品研发工作不及时，工作不充分，或者说系统工程研制的需求为能够与组织技术创新发展的方向一致起来，这是一个系统性问题。
但即便是遇到了此种类型的问题，我们一样有办法积极地寻求国内科研机构的帮助，关键的技术及产品采用双定点或多定点模式，而这取决于成本管控的目标。
五、系统工程运行的质量管理
1、设置合理的质量控制点
(1)产品质量控制点设置
应遵循以下几个原则：
①对工程的适用性有严重影响的关键环节或重要影响因素,应设置质量控制点;
②测试不到的,以及在工艺上有特殊要求,对下道工序有严重影响的关键质量特性和部位,应设置质量控制点；
③薄弱环节,质量不稳定的部位,工程质量通病,应设置质量控制点；
④特殊工序应重点设置质量控制点,其质量控制点包括,影响工序质量的人、机、料、法、环等因素;
⑤采用新工艺、新材料、新技术的部位或环节应设置质量控制点。
(2)系统研制质量控制点设置
①决策评审,系统雷求(任务书)评审,方案设计和设计方案的评审;
②软硬件设计规范评审(大纲、准则);
③关键技术评审、技术状态变化、风险控制评审;
④生产准备评审,产品试验要求、技术条件、试验方案、大纲、结果评审;
⑤系统验收评审。
（1）评审组的构成
（2）非拥护性评审
资料备查：
3、技术状态管控
当前技术状态管控较之GJB的要求相去甚远，更多地掌控于项目几个人手中个，没有专业的较为完备的介入，没有充分地更改措施确认前的试验验证，更改的影响域分析不够全面，上一层级对下一层级的监控不够，下一层级技术状态变化的透明度也不够，需要从项目内部严控审批程序，并且要严格执行组织级针对重大技术状态变化把关的要求。
4、技术故障和质量问题的处置
出了问题，不能够通过简单地更换一换了之，最为基本的前提是弄清楚机理，找到规避的措施，或者是个性化剥离，原则上先有问题归零，然后才有后续工作的继续开展，但对于小项目而言，也可以采取质量问题阶段关闭的模式，主要是看问题之于整个信用工程的影响程度。
（2）组织力量和资源保证是质量问题快速处置的保障
技术问题产生的根源在于技术和产品的成熟度不高，或者是系统集成技术存在短板，所以是一个系统性问题，需要动用组织的力量和优势资源一起查摆问题机理，找到解决的措施，并转化为组织级资产。
（3）做好问题的剥离和举一反三
有效把握好内控质量问题的举一反三，借助于组织级力量。
5、质量工程化
一种理念提出了质量流、质量链、链节点、链节图、耦合效应等基夲概念,它们的定义分别如下：
①质量流(QualityStream)是产品固有或隐含的质量特化在设计、制造交付、服务等各个过程中的定向流动和有序传递,质量流件随着产品质量形成而产生,与信息流和价值流一样属于产品质量的一种特征,他们共同作用以满足客户及市场对产品质量的需求。
②信息流(nformationStream.)是指正在各系统之间或系统内部运动的具有双向性的信息,包括信息的发送与反馈。质量链的信息流需要按照约定的要求,在特定的渠道按照特定的方向流动,信息的流动分为系统内的流动和质量系统间的流动。
③价值流(ValueStream)是指包含经济价值、社会价值、生态环境价值等在内的价值总体的运动,反映了一个系统及其子系统间的价值投入、增加、存储输出等价值变化规律。
⑥耦合效应(CouplingEffect),是描化关键链节点处的组织和要素发生相互影响、相互作用所产生的结果和程度。
上述提法较为直观地将质量链管理进行了阐述,将质量链进行分析和工程化,也就是质量工程化
质量的工程化是相对于质量体系而提出的,我们时常对于体系在系统工程中的落实状况不太满意,这其中的原因错综复杂,但最为关键的是质量与工程诸多环节脱节所致。
质量的工程化是指质量工作与工程同步进行,超前管理,从制定质量目标明确质量要求、落实质量责任、强化质量保证、确立质量管理模式方法等入手将质量工作设计为系统的、连续的、有计划的一项工程。
（1）质量目标
系统工程的目标貌似是不出问题，但这是分阶段的，在设计阶段我们需要最大限度地暴露问题，提升技术和产品成熟度，有诸多的质量问题待解决；在交付阶段要最大限度地减少问题发生，杜绝低层次质量问题发生。
质量目标有阶段属性和区分，每一个阶段的目标都应该是明确的。
质量目标可量化最好，但也可以是定性定量化的约束，因为质量目标与大系统的指标实现密切关联，因此功能、性能以及“六性”指标的满足性，可以归属于质量目标实现的一个重要维度，这是基本的要求——设计目标的达成率，有了这个基础才会有顾客的满意度。
系统工程涉及到的设计和生产交付等环节，可以从以下确立质量目标：
（2）质量责任
落实好全员质量责任，贯彻质量是设计、生产出来的理念。
①解决好谁去干，怎么干的问题
系统工程的特点就是复杂，接口众多，上下游，左右邻，哪些是你的职责，哪些是我的职责，哪些是共同职责，而问题往往出现在共同职责和接口层面，以及需要协作的环节。现在我们强调组织的产品责任和专业的技术支撑，以及项目直接质量责任，而在重大质量问题发生时，谁更应该站出来去承担责任，似乎总是鸡飞狗跳，貌似所有环节都有责任，但细究下去又并非如此。
所谓的责任方是针对产品质量直接发生关联的组织和人员，主要责任方和次要责任方。
再比如近期又沉渣泛起的计算机病毒问题，就要指定总体或试验组织方去负责，否则就会陷入没人去想、去干的尴尬境地。
体现的就是付出和收获的辩证关系，这是显而易见的，所以该是谁的就是谁的，不能简单地将质量责任推向下游。
③质量首责和质量管理责任
质量监管依旧需要通过组织派驻人员的方式有效解决，但需要平衡好派驻人员的组织、项目属性带来的问题。
④做好计划、质量、成本的统筹
计划是有质量的计划，质量也是有计划的质量，当然这些是在成本的前提和约束下，计划不能突破质量底线，质量也要为计划着想，合理、适时地安排好过程质量活动。
（3）质量程序
抛开质量体系程序不谈，重点应该是质量活动开展的要求、步骤和达成的结果，这是用以指导质量活动开展的必要存在，可以归结为研制流程的一部分，或者是质量活动的作业指导书。
系统工程的研制不能就质量而谈质量，须结合产品本身的过程管控节点，针对每一个节点明晰质量目标、检验和度量的方式，最终确认闭环和问题处置的要求。
（4）质量大纲、质量资源和质量风险
作为系统工程质量管理目标的载体，质量大纲其实很重要，约束各阶段研制需要完成的质量工作，达成质量目标，所以其应该充分结合项目的特点，无论是叫质量保证大纲、还是产品保证大纲，都应该对质量活动有基本的约束，尤其是针对过程质量控制的关键节点。
有助于产品质量提升的资源和保障，均可视为质量资源，包括专业的力量、专门的技术支撑和试验验证机构，各层级的技术专家，专门的试验室和科研机构。
提及质量工程化，也就是在工程研制过程中，如何有效地发挥这些资源的作用。如EMC，这是一个从单机到系统的复杂课题，我们致力于一个系统层级EMC水平的真正提高，但更多的时候，却只是在系统、单机设计完成后，通过EMC试验摸底，通过防护技术、泄放通路来保证整个系统的电磁兼容性，而实际上从最初的的EMC设计仿真、试验摸底等层面，开展的工作还远远不够，而这些恰恰是可以发挥这些优势资源作用的所在。
无论是技术风险还是产品风险抑或是进度风险，最终均会转化为质量风险，而质量活动不完善、不深入所引入的风险，又会直接体现在技术、产品和进度层面，所以在项目之初，就应该紧紧抓住风险辨识和风险消减的工作。
（5）质量管理的信息流
契合系统工程的透明度,要求质量管理信息流的顺畅和便捷,在对于产品质量信息把控不齐全的前提下,无从更好地从系统维度去有效把控各个系统、专业、产品的研制工作,质量问题难以追溯和举一反三。
因此必须通过较为健全的质量信息管理系统,将整个系统工程各系统产品质量信息有效贯穿起来,也就是质量管理的数字化。
（6）小结
六、小项目质量差异化质量管理要求的提出
1、系统工程基本要义的回顾与强调
1）系统工程要有论证，要有各层级的任务书，要从全生命周期开展相应的工作。
2）系统工程的连续性、工程目标的量化，性能指标的均衡性，方案的集优性，可信度的连续性，性能指标的流动性，最佳概念的相对性，工程要求全息性。
3）系统工程的风险取决于问题暴露的程度、遗漏的条件和预案的覆盖，以及工程的透明程度。
4）系统工程质量管理的工程化，以及工程化的质量管理活动。
从要义的回顾来看，差异化的重点要紧扣系统工程的阶段和特点，均衡、集优、逐深、流动，最佳相对性，要求全息性，在此基础上抓住小项目研制的风险点，在过程中践行工程化的质量管理活动。
2、小项目的研制特点
小项目的三高、三少无疑增加了其复杂性，但因其同样是系统工程，就一样需要严格按照系统工程的规律来开展研制工作。
系统工程研制的现实性困难：
(1)项目构成的复杂性增加质量管理难度
复杂大型项目构成复杂、规模宏大,往往包舍多个功能系统。不同功能系统之间的质量具有一定联系,部分系统甚至具有较强的质量和功能依赖性。另外大型项目往往需要众多参建方共同参与建设。复杂大型项目建设的难点主要体现在人的管理和物的管理两方面,复杂大型项目在这两方面都容易形成较多质量交接界面,致使质量管理难度大增。
(3)工序质量控制点多且具有不同程度的联系
项目的大型特性决定了其工序质量控制点数量众多,而且工序之间质量往往具有较强联系,不仅施工过程中的控制难度大,发生质量缺陷时找寻原因也是难点问题。另外,工序质量控制点众多,当工序质量参差不齐时,容易导致工程整体质量波动。
(4)工程项目目标具有冲突管理控制难度大
所以此处强调的规律,也就是系统工程研制的基本要义,在三高和三少前提下,如何更为有效地做好各系统解耦,任务下达、研制和集成,以及整个过程中的质量控制工作。
3、暂且划一条线,明晰加减法的重点
1）从研制阶段维度
（1）论证阶段
此阶段典型的活动和产品：
①关键技术的明确和攻关
其中不乏难以通过继承而达成的指标要求,针对这些确认为关键技术,有效识别风险,制定攻关计划和路线,确需外部支持的审慎确认、选择合作方,尽早启动,也不要简单地寄期望于一家机构。
②系统方案的集优
在论证阶段需要解决的另外一个问题就是方案的比对和分析,一般情况下会主推一个方案,但还是可以在借鉴和创新糅合维度确认几个方案,以供最终的决策之用。因此,在方案的准备和遴选层面需要做加法,针对需求从成本、技术实现、产品继承和产品化等层面,给出实现的途径和模式,自然也要列写出方案的优缺点,由组织以及评审专家依据一定的规则打分评判,而最终的方案也极有可能是集中方案的重新糅合。
③系统的透明
论证阶段参与方的不齐全容易导致整个论证工作透明度不高,一些短板甚至与隐患不能被很好地线性化,给后续的研制工作无形中增加了难度。
在论证阶段,可能整个队伍尚未完全建立,这时更应该有效地发挥专业和组织的优势,组织针对性的方案评审、产品选用评审,此时的论证不能简单地闭合于大方案和大系统的要求。
针对借沿用、继承的项目,要针对适用性和创新可达性进行分析,借沿用的根本目的就是为了有效降低成本,提升效率,所以产品借用的源头也确认好满足使用环境、工况以及元器件等级和成本要求。
(2)方案阶段
该阶段主要确认系统工程系统级需求、所需的需要架构,开展任务需求的分解和各系统需求的定义,提出系统级产品需求,形成分系统层级产品的初步设计;形成方案系统工程及各系统、分系统重要关键单机任务书,形成数字样机结构样机或实物样机(新产品和关键结构产品),开展数字模装或实物模装,关键系统开展原理性综合试验,需要先行启动部分涉及到新技术、新产品的技术研发及大型验证试验。
样机和文档是该阶段的主要输出,但这一阶段受制于不同项目的转点和进度要求,完全可以开展更为深入的工作,如各种类型产品研发,各种系统性集成验证试验,而深入的前提就是技术和产品的高占比继承性。
①系统工程方案、系统方案设计,集优与权衡
②系统工程研制策划
整个系统工程的策划,各系统、各分系统的策划,关键技术、关键单机设备研制和试验的策划。绝大多数情况下,我们工作的无序性取决于策划的无效性没有策划或草草策划,不严谨也不科学,不知道要到哪里去,也不知道怎么去变成了漫无目的的游荡。
③风险分析以及新技术的攻关和验证
什么是风险全新的、变化的、不变的都可以成为风险。
此外,囿于当前小项目的竞争态势,方案阶段需要开展的工作越来越多甚至于初样及工程阶段的工作也被提上日程,未尝不可,但需要把握一点,那就是在此阶段要策划好系统方案的闭合、关键技术的攻关、验证,一并确认好后续研制的基线。
(3)工程研制阶段
系统的详细设计完成,软件和硬件的生产持续开展,产品组装集成为系统同时通过试验验证确认其能够满足系统及工程需求,实施产品的研制、组装、集成与试验验证,并准备交付使用。
这一阶段输出的是产品及详细设计,该阶段需要序时开展一系列的评审活动。此外要更新控制基线,做好接口、六性质量控制计划,集成验证、制造验收条件明确,形成详细设计报告,形成验证和确认计划,数据包和使用手册逐步完善,关键设计评审、生产准备评审、系统集成评审,产品验收、环境试验涌现。
①转入工程研制阶段的标志
方案阶段工作的闭合,工程级技术指标的闭合,关键技术攻关已经取得成效,对应的技术风险等级已经下降,各系统方案阶段的工作均已经保质完成,初样阶段技术基线已经得到确认,剩余的技术攻关工作依托组织、专业成立专门团队并有序开展。
②产品的选用、设计、生产,系统的组装、集成与试验验证
永远将选用置于第一位,突出产品化和借沿用的思路,以此提升产品成熟度,规避因产品本身质量问题而引入的诸多困难。做好产品的适用性分析,补充相应的试验验证;策划针对性的试验验证。
③系统研制的透明
项目总体、各级总体要对系统、分系统、单机有一个较为深入的把握,对其技术工作进展、问题处置、输入输出的明晰,技术状态的把控,定期组织例会和协调会、检查,确保各项工作齐头并进,确保串行质量工作开展的接续性。
④大阶段的人为划分
既然原先的工程阶段区分为初样阶段和试样阶段,那么一定是基于将复杂简化,初样阶段只在于产品的研制和整个大系统的搭建并完成初步试运行,舉露出运行中不匹配的大问题,然后在试样阶段去闭合,同时通过试样阶段进一步提升技术和系统产品的成熟度。
所以有必要将工程阶段人为在区分为前后两个阶段,将产品的投产实现批次却分,确保问题充分暴露后的改进,以期在工程阶段将所有问题闭环解决掉,具备系统交付使用的条件。
(4)定型和批产阶段(交付运行)
2）从技术、产品成熟度维度
（1）产品和系统的技术方案
对于系统工程而言,宜采用已有的系统架构,无论是在分系统还是总体层面,技术均已经得到了最大限度地验证,较高的系统成熟度,意味着少走弯路,试验验证也将得到最大限度地精简。
产品以及系统以继承为主,在需求满足的前提下,最大限度控制新产品、新技术应用的占比,在产品选用层面,除非是因新技术应用而引入的新研产最,其他直接借沿用,或采用产品化产品,或在产品化产品基础之上进行适应性更改。
一旦采用了成熟的技术、产品,重点工作即放在实用性分析和适应性更改层面,首先是满足需求和工况,一般而言总会存在或多或少的不适应和不满足,因此需要进行适应性更改,而更改的前提就是最原先系统架构以及产品的深入把握需要对借用的系统技术、产品方案以及在使用过程中遇到的问题进行深入了解避免重蹈覆辙或因更改而引入新错误。
同时,需要合理设置单机和系统性验证试验,尤其是在单机产品层面,针对不满足和重大更改环节,相对性的验证要有、要充分,不能试图通过简单的分析去替代必要的试验验证。
实战化设计,环境适应性设计,维修性、测试性、保障性设计,之于小项目而言,显得尤为关键,无论从系统架构还是产品层面,总会有成熟的项目和产品值得我们去借鉴,也会有大量业已存在的问题值得我们去反思、去彻底改进。
（2）元器件、原材料的选用控制
小项目具有长寿命、高可靠,高质量的特点,同时具有其特有的大批量,低成本、短周期等研制特点,需要满足用户在快响应、个性化等方面不断增长的需求,以更低的成本、更快的速度投入市场。要求元器件在保证质量的基础上,方面能够自主可控,确保可获得和持续供应;另一方面还要兼顾通用性和成熟性通过选用成熟元器件来压缩生产周期,确保满足型号进度和质量要求。
实施统一选型控制,开展“自上而下”的元器件选用管理,指导型号设计师队伍将成本控制理念融入设计过程,力争从设计创新上实现元器件的成本控制。
首先在满足电路性能的前提下,优先选用总体单位目录内元器件,保证元器件产品质量,确保生产厂家资质。其次要压缩元器件、原材料的种类,规格和元器件的生产厂家,提高元器件的可获得性和元器件的通用性。因为,从制造工艺方面来看,新研元器件、原材料往往不太成熟,技术状态并没有最终定型,还有些有可能是致命的问题没有在实际应用中暴露出来,因此建议对新研元器件和原材料采用慎用的态度。同时尽量减少元器件的种类和元器件供货商能进一步提高采购和质量控制水平。再者,选用标准型号规格的元器件和原材料,尽量减少首飞等新研元器件的使用。
针对通用元器件选用种类、规格及性能指标进行统一规范,压缩品种规格便于从项目维度进行集中的协议采购。
针对FPGA、DSP、存储器等关鍵元器件编制选型指南,系统提出关键元器件的选型意见,统一规划选型。对部分元器件的选用种类、规格及性能指标要求等进行统一规范,通过压缩品种规格,指导型号正确选用,同时也可以降低周期成本和采购成本。
可以对目录内的元器件开展分类管理,将选用类别分为“优选”“可选”“候选”等类别：
①优选元器件：符合元器件发展方向、质量等级和抗辐射指标等要求,具有充分的应用经历和长期可获得性的国产元器件。
②可选元器件:具有充分的地面验证数据但尚无充分的应用经历的国产元器件、进口元器件
建立元器件质量等级与应用等级矩阵表,差异化选用,对于影响成败单机的关键模块,优先选用满足指标的较高等级元器件;非影响成败的环节适当降低等级选用,选用普军级产品,充分考虑单机力学环境和使用工况,部分产品可选用经多次飞行验证过的汽车工业级元器件。
此外,对于新研单机设备,需要从设计层面着手,有意识地降低元器件的工作应力(电、热、机械应力),使实际使用应力低于其规定的额定应力;为防止电子元器件的热失效,在元器件的布局和安装过程中必须采取有效的热设计和环境保护设计。
电子元器件的环境特性选择电子元器件的环境特性是指电子元器件正常工作所要求的使用环境条件,主要有环境温度、耐振动和冲击性能,耐加速度性能等不同等级电子元器件的环境特性有很大的差距(如军品工作温度范围通常为-55——+125℃,而民用产品一般为0-+70℃)在电子元器件选用时应保证其环境特性高于(至少同等于)整机的环境条件,当在一定的环境下电子元器件特性发生变化时,产品仍能正常工作。
例如:半导体分立器件的质量保证等级分为:JP(普军级)、JT(特军级),JCT(超特军级)、JY(宇航级);集成电路的质量与可靠性保证等级为B1级、B级、S级(宇航级);混合电路的质量保证等级在GJB2438A-2002中,将质量保证等级划分为DG、H和K级,D级电路是由生产厂规定的质量保证等级,其工作温度范围一般为0℃~70℃.G级电路则是由H级派生出来的一个较低质量保证等级的产品,其工作温度范围一般为-40℃-85℃.H级为军用标准质量保证等级产品;K级是最高质量保证等级产品,预定为宇航用,H和K级工作温度范围均为-55℃-125℃。
（3）软件及软件评测
①软件开发过程中的复用和重用技术
随着现代软件工程技术越来越向集成化、构件化方向发展,相应地,能够在不同层次,不同程度上,以不同方式重复使用软件各个要素及成分的软件复用技术也得到了越来越普遍的运用,可复用软(构)件具有测试充分、接口清晰、可移植性好、质量稳定等特点,合理的复用能够有效缩短软件开发周期、减少软件代码错误率,从而有效地减少项目开发的成本。
软件复用是一个很大的范畴,小到一行代码的复用,大到系统平合的重用都属于软件复用的范畴。从程序员到架构师,每天都在考虑怎么样能更好的复用已经存在的功能成果。软件复用没有正确与错误的说法,只有效率高低,级别高级的说法,一般来说级别越高,效率也就越高。
通常来说复用的类型有语句,模块、结构、功能。文档、思想等形式。
语句(代码)的复用依靠的主要就是可复用构件,因其灵活性,可被广泛运用。代码的复用包括两个内容,一是目标代码,二是源代码,而源代码在一定程度上是高于目标代码的
语句复用就是简单语句复制,是一种代码级别的复用,是最小的复用单元也是软件工程中复用级别最低一种复用模式,虽然此种复用方式效率不高,但却是软件工程中最普通的复用模式。在程序员的开发工作中,有30-40%编码工作可以通过此种方式来进行
软件模型构件技术是软件模块复用的核心,主要的点：
a模型获取:分析现存的多个相似或相近领域的软件系统,提取出可以被重用的部分,作为重用的模型；
b模型构件:模型构件主要是描述软件模型的特征和模型库中的各个模型间的耦合关系,比如有的模型之间强耦合,有的弱耦合；
c模型描述语言:采用易于理解安全的描述性语言,描述模型的功能组成和相互间的关系；
d模型符合组装:可以采用策略设计模式进行模型的组装,从而优化代码实现重用；
e标准化:统一标准化模型接口,这样可以规范模型库建立和使用。
软件架构包含了软件系统架构的特点,主要包括软件系统的控制和软件系统中各个模型之间的耦合性,模型间的物理分布以及各个模型元素间的集成、模型性能、模型库的伸缩性,各模型间数据的同步和模型间数据的访问协议以及模型设计的选择等等。在一个特定的应用范围内,实现一个功能时,应用程序框架的搭配,整体框架可以重复使用,同一功能的不同应用程序只需要更换一些软件的框架,只要够方便组装的软件组件和适应性软件体系结构应用的调整,应用软件装配开发人员会依据实际的应用软件提供给用户的实际需求,也可由用户自己方便自由切割组建模型构件。
软件复用的源头,在于产品和技术方案实现的最初设计,只有从设计源头尽可能多的采用成熟产晶和技术,才有可能从架构层面做到顶层复用,从模块层面最大化复用,而一个极致就是算法的硬件化
②不同测试中软件状态最大限度地一致性迭代
主要是在产品研制阶段,产品成熟度提升过程中,往往会有多个大型试验并行开展,而此时整个系统软件在不同的试验过程中因为更改而存在不同的状态，极为迫切地需要针对几个大型试验软件技术状态进行一致性的比对,短则三五天长则以周计,用以规避因测试用软件技术状态不一致而引入的测试覆盖性问题。
这属于不同试验中软件技术状态的回归和归集。
③系统测试和流程性测试的覆盖
软件的系统测试是一种集成测试和确认测试之后进行的测试类型,进行系统测试的根本原因是,软件除了要实现规定的功能以外,还必须满足规定的安全、兼容、易用性和特殊情况下也能正常运行等要求。
系统测试的组织与管控一般可分为三层：组织监督层、监控层和实施操作层。
组织监督层(项目和组织)确定系统测试的方针与策略,对整个系统测试进行组织监督,提升软件产品质量监控层(计划和质量)以计划、监控和考核等职能方式完成测试计划的制订更新、测试过程的监控以及对测试团队员工进行考核。实施操作层(测试承担方)设计更新测试用例、执行具体的测试、完成测试报告和BUG报告。
工程软件系统测试实施中的两个重点方面:正常和全负荷性能测试,极端条件和负荷加强测试。
软件正常和全负荷性能测试是指用手工或自动方式测试软件在正常和全负荷条件下各个性能指标是否能满足规定要求。
从软件角度的测试中,有两个条目的测试任务最重,一个是并发竟争负荷测试一又叫“压测”,另一个是容量测试。
在工程软件中,容量测试又一般表现为单个重复重负荷测试和多个重复重负荷测试。
对国防或军用软件,还应有时空变更极端条件测试的特别要求。
主要有四个测试项目：
(a)考查数据是否能保存完好持久不损坏的测试项目；
(b)考查数据输入能否在遇到意外情况后能否尽快转移继续灵活处理的测试项目；
(c)考查整个软件在遇到意外情况后能否独立转移处理的测试项目;
(d)考查软件能否在遇到意外情况后能否和硬件一起尽快转移继续处理的测试项目。
系统工程硏制中：
软件测试往往是用真实环境进行,但是受到嵌入式软件运行环境难以修改的约束限制,对于一些安全性的测试难以正常注入,测试的充分性得不到保障。并且,不同的测试级别对测试环境的要求也不尽相同。所以,嵌入式软件测试必须根据测试级别、软件项目需求建立合适的测试环境。
嵌入式软件是软硬件耦合系统,把软硬件分离开来,建立嵌入式软件独立的运行环境是建立嵌入式软件仿真测试环境的关键。一个完整的嵌入式系统包括处理器、I/0接口以及各种外部设备。在建立嵌入式软件仿真测试环境时,需要考虑软硬件的分高原则,即哪些采用真实硬件设备,哪些需要用软件仿真实现,哪些需要用硬件仿真实现。
④系统工程研制软件系统测试的几个一般性要求：
(a)使用工况的模拟,包括数据传输、各类指令、中断的处置,包括响应的竟争处置,异常后的处置等,都要创造条件模拟测试；
(b)软件评测的系统环境搭建和模拟,要么专门的测试平合,要么在系统环境中开展必要的测试；
(c)重视测试用例的设计和确认,系统、软件实现和软件评测三方都必须在位；
(d)一定级别涉及系统或其他分系统以及使用安全的更改环节,务必要完成回归测试。
（4）产品生产及试验
①工艺环节
②首件试制和批产
首件试制,主要是针对新研产品而言,规避影响到一个批次的问题,尽早通过试制,将问题和薄弱暴露。
批产更要控制工艺的一致性,以此保证产品的合格率和稳定性,合格率要通过工艺的切实提升和优化,当然前提是工具装备、方法的完备性。
从首件,到小批量试制,再到大批量生产,这其中涉及到诸多环节成熟度的提升,技术、工艺,是一个逐渐完善的过程,批产不可能没有问题,但需要规避批次性问题,所以设计缺陷和元器件、原材料缺陷的识别和消除是最为关键的环节,实践证明,在批产阶段一样可以见到设计类问题。
③单机试验的针对性和覆盖性
单机试验需要一定的针对性和覆盖性,但不能寄期望于解决所有的问题,如果那样,系统集成试验就绝无存在的必要了。
首先是使用工况的模拟,单机要把握好自身在系统中的作用、运行的工况,输入输出,做好最严酷程度的模拟,比如整个数据流的最大负载,时序动作的竞争等情况的处置,使用过程中环境条件的适应。
以此,要求针对单机的部分试验要求应该在任务书和技术要求中进行细致的描述和明确,在验收过程中进行有效确认。
需要针对借沿用产品组织针对性的补充试验,重点分析不适应和要更改加强的环节,一个是使用和贮存环境,一个是技战术指标,已经经过验证的环节可以适当减少重复性试验验证工作。
也就是如果不需要做补充试验,则可以与原先产品一起组批抽例。
（5）系统集成试验
测试项目的设计,借鉴居多的项目,在继承以往测试项目设计的基础之上以问题为导向,进行补充性试验验证;针对新研项目,则需要尽量多的安排一些专项技术验证,确保新技术应用顺利。
试验验证不能仅仅测试验证正常、正确的状态,需要更多地去尝试对临界和便捷的测试验证,通过鼓掌注入、仿真实验和软件测试、评测等形式,摸清系统在两界条件下甚至于异常状态下的响应,以此判定整个系统运行是否按照预期进行故障的隔离,避免进入死循环。
较为重大的技术状态更改验证,需要设计专门的试验项目,不能简单地采用之前的测试项目进行无意义的重复性测试。
3）报告的编制以及质量活动把控
(1)关于报告的编制
①重点把握好方案设计报告、生产工艺类报告,技术条件以及试验要求数据分析,质量问題分析和归零报告等,要有效控制文档的篇幅,能将事情说清楚就足够了。
③针对新技术、新产品、系统层面的分析环节,跟随研制进度,有效、适时安排开展独立评估,依据项目当前的输入和输出,保证专业和专家的覆盖,不必专门准备所谓的独立评估报告,最为关键的就是设计的输入输出和验证情况,以及对专家意见和建议的答复;涉及重大更改的,一定要严格按照要求推进实施；
④尽可能的减少汇报类报告和专题分析报告,这类报告不属于体系要求与研制的直接关联度其实并不高,报告写与不写于项目研制而言不具有太多的推动作用,可以省略掉,采用最为直观的数据、图表来表征当前研制的进展和困难就已经足够了。
(2)严格技术状态的管理和控制
技术状态管理涉及两个基本的管理要素,一是技术状态项目,二是基线技术状态管理是以产品的研制生产过程为主线,以产品研制基线为主体,以研制程序各阶段节点为控制点,对产品的研制生产状态实施动态管理。
在研制和批产交叉阶段,加强技术状态管理,在研制和批量生产高度交叉的几个重要阶段设立控制节点,制定相应的质量控制点和措施,重点对工程更改文件资料变更、器材代用、故障报告及不合格品处理和审理5个方面加强技术状态管理,有效控制技术状态的转移,确保产品的技术状态和基线受控。
在研制和批产交叉阶段,一方面要抓好各个阶段的质量控制,使技术文件的要求都能落实到产品中,也要将产品状态的变化都反映到技术文件中;另一方面,加强研制、批产和质量改进过程中的技术状态检查清理工作,细化设计质量控制要求,严格履行技术状态管理程序,防止状态变更的随意性。
凡是满足任务书要求,经考核验证并经评审确认的技术状态,不得随意更改;确实需要更改的,要按照论证充分、各方认可、试验验证、审批完备和落实到位五原则执行。
(3)加强生产过程的质量控制
进行工艺攻关、工艺优化,提高过程能力,特别是关键工序能力,积极开展生产工艺过程故障模式影响分析,消除工艺缺陷,确保工艺质量的稳定;杜绝」不按工艺、工序要求生产,出现虛焊、脱焊或防护处理不到位等质量问题,在后期的制造加工过程中加强检验和现场检查环节,加大考核力度,增强操作人员的质量意识,确保产品质量。
(4)强化环境适应性设计研究
针对产品实际使用问题,从系统的角度出发,综合多方面技术力量,开展产品全寿命周期的环境适应性研究和思考,在管理上加强对使用环境和使用需求的准确分析和设计策划控制,在合同评审中强化或增加环境适应性和使用性专项评审,并进行充分的环境适应性论证和试验验证工作,对不同用户出现的问题采取针对性的措施,解决困扰产品使用环境的防护、锈蚀问题,避免类似问题的再次发生。
(5)加强软件工程化管理
按照软件工程化管理要求,对软件的论证,研制、测评,定型、使用和维护过程实施质量控制,认真实施软件工程管理,强化软件的评审,加强软件的测设立软件的“开发库”、“受控库”“产品库”的配置管理,规定相应的控制和管理程序,确保软件满足规定的要求。另外软件文档的修改和完善必须纳入软件的配置管理并严格按照技术状态管理要求进行控制。
(6)抓好外购、外协配套产品的质量控制
4）一些底线和需要加强的环节
(1)部分底线
①产品验收和交付,应该在最终系统工程产品交付测试前完成②元器件选用以使用工况和环境为依据,关键的采用1级降额,非关键的要求放低;
③使用工况下参与流程的环节,系统集成试验时分系统和单机都要在位,都要进行匹配
⑤重大技术状态更改必须上报上一级系统;
⑦各系统出厂前要组织专业放行工作；
⑧极性环节必须测试和确认到;
⑨大型试验数据分析必须经过一定层级的评审确认。
(2)需要加强的环节
①借沿用产品的适用性分析;
②风险的辨识与管控;
③必要环节的序时性保证
④试验设计的针对性和充分性;
⑤技术状态变化的透明。
4、敏捷开发——小项目研制的必由之路
【关于敏捷开发,具体参见：
1)拥抱变化
变化已经成为新常态,无论是上有输入,还是内部自生优化提升的需求个系统性能的提升需要不断的变化,拥抱变化的前提就是系统架构和产品化工作的完备,甚至于包括重用模式的推广,因为重构需要的片段化的重构,整体性的巨变一般发生在系统工程之初。
拥抱变化,需要大家去一起拥抱,所以组织内部或团队内部,包括与用户方要有充分的沟通,不变有不变的理由,但实际问题得得到彻底解决,变有变化的流程和程序。
2)快速迭代
快速迭代的前提是系统的可测试性,最为便捷的还应该是整个系统基于建模基础之上的仿真验证,在模型的精准度更高前提下的仿真,能够暴露研制之初的诸多问题,而整体性投入不会因此增加太多。所以要尝试基于流程的建模和研发模式。
3)以数据说话
数据是客观存在,一切端倪都会在数据中有所体现,但数据需要深入挖掘，而最为迫切的是表征系统、产品功能性能指标数据的可获取、可度量问题,让关键的环节可以通过数据来表征和评判。
数据在获取之后要随着产品和系统集成交付有序流动,那么最为关键的首先是流程中数据的自动获取、存储,其次是打通数据流通的渠道,破除数据屏障。
七、结论
这是一个大课题,在GJB9001C大框架约束之下,如何将小项目质量管理的经念好,很难从具体约束上给出太过于具体的意见,但横向看我们的小项目,不乏走得很顺畅的,这说明其抓住了关键所在,优势和短板在哪里,只有明晰了这些,聚焦发力,就一定能抓住系统工程研制的命门。
参考资料
1、《军用电子元器件的选择和使用》,薛海利,郭涛,王珲,《鱼雷技术》,2005年03月
2、《规模化研制的商业通信卫星元器件选用控制管理研究》,南方,胡楠楠,朱峰,《质量与可靠性》,2019年第1期,总第199期
3、《国产和进口电子元器件质量保证等级研究》,祝军生,沙群,《电子质量》,2017年第10期(总第367期)
4、《航天产品元器件、原材料质量控制》,梁贵芬,《电源技术》,2014.10V01.38.10
5、《空空导弹电子元器件正确选择与控制》,史玉琴,《物联网技术》,2015年/第3期
6、《浅析软件工程中软件复用的意义》,温立辉,《福建电脑》,2018年第7期
7、《基于软件性能的系统测试》,谭李孟清,张莹,王玉林,《软件》,第41卷第11期
8、《军用嵌入式软件测试技术研究》周平平,张俊,罗海鹰,李用,《教练机》,2021.N0.2
9、《航天软件测试过程管理技术研究与改进》,王捷爽,天津大学
10、《军用软件测试过程质量因素与度量指标》,杨玲萍,张丽,《指挥信息系统与技术》,2014年6月
11、《军贸产品质量管理方法探讨》,周虹,《质量与可靠性》,2013年第2期,总第164期
12、《论矩阵式组织结构下的航天型号项目质量管理》,李达银,张奎好张昌海,《质量与可靠性》,2013年第2期,总第164期
13、《复杂大型建设项目质量链识别方法及其优化模型研究》,杨益晟,华北电力大学
14.Tang,Xiaofen,etal.ResearchontheTheoryandRealizationModeofQualityChain[CI,thelOthInternationalConferenceonIS09000andTQM2005:20-53
15、《航天系统工程运行》,栾恩杰,宇航出版社,2010年1月第1版
附录
F.1.1软件测试的基本概念
IEE在1983年把软件测试定义为“用人工及自动运行的手段来测试某个系统的过程,它能够检查出软件是否满足规定的需求,以及为软件确定是否达到预期的结果,实际的结果与预期结果之间是否有差别不同类型的软件测试具有不同的特征,需要从不同角度进行研究软件测试从被测软件是否需要执行的角度来看可分为静态和动态测试两类方法PL静态测试是指分析、检查和测试软件时,被测试程序不实际运行;动态测试是指在测试时,实际运行被测软件,以检查软件的动态过程和检验软件系统运行结果的正确性
从在动态测试中是否需要研宄程序代码的角度,可将动态测试分为黑盒测试和白盒测试。黑盒测试方法主要有判定表驱动法、正交实验设计法、等价类划分法、边值分析法、因果图法等。白盒测试方法主要有控制流分析法、数据流分析法、符号测试法、逻辑覆盖法、域测试法、路径分析及程序变异法等。
软件测试的价值体现三个不同层次：
一是测试初期尽量多地发现缺陷；
适用范围:(1)业务较成熟;(2)技术较成熟。
二是测试发展期尽早发现缺陷；
实施重点:(1)重视静态测试机开发文档评审,重视对开发需求和开发设计的缺陷检查和完善;(2)重视早期代码和数据库测试分析,重视代码文件的静态分析
主要使用的技术:(1)正规检视;(2)技术评审;(3)代码走查;(4)数据库测试;(5)白盒测试
适用范围:(1)新项目研发;(2)使用新技术;(3)开发人员的;(4)技术或业务背景不成熟。
三是测试成熟期预防缺陷的产生。
实施重点:(1)缺陷统计分析;(2)缺陷定位;(3)开发测试过程改进。
主要使用的技术:()1缺陷统计分析技术:;(2)缺陷定位技术:(3)软件过程改进。
适用范围：(1)企业有一定的测试数据积累;(2)企业的过程较规范较成熟;(3)企业有较成熟的项目或生产线。
F.1.2软件测试的一般过程
1)测试需求分析
关键活动:确定需要的测试类型及其测试要求;确定每个测试项的测试充分性要求。按确定的文档编写软件测试需求规格说明,并通过测试需求评审测试类型包括功能测试、性能测试、接口测试、人机交互界面测试、强度测试、余量测试、容量测试、安全性测试、安装性测试、边界测试,恢复性测试数据处理测试、可靠性测试、互操作测试、敏感性测试、代码审查、代码走查逻辑测试、静态分析和文档审查等,测试要求包括状态、接口、数据结构和设计约束等
活动输入:研制总要求、技术方案或其他等效文件,被测软件需求规格说明和软件设计文档
活动输出:软件测试需求规格说明
软件测试需求分析质量好坏对被测对象的测试充分性产生影响。在进行测试需求分析时,需根据被测软件特征和重要性程度,在分析被测软件状态、接口数据结构和设计约束基础上,选取测试类型,确定相应测试内容和要求。同时基于每个测试类型进行测试项分解,分解后的测试项需全部覆盖软件设计文档规定的所有功能点,包括关键、重要和一般功能点.
在测试需求分析阶段,为保证测试需求分析充分性目标,采用CQM范式(目标一问题-度量),针对测试需求覆盖软件需求充分性以及测试类型选取充分性等问题,需选取以下度量元:总功能点数、提取的关键/重要/一般需求功能点数需求涉及的测试类型、计划执行的测试类型、关键/重要/一般功能测试项覆盖和测试类型覆盖率.
2)测试策划
关键活动:确定测试策略,明确用于测试的资源和技术要求;明确软件评价准则和方法、测试活动进度和人员安排;按确定的文档编写软件测试计划,并通过测试计划评审
活动输入:研制总要求、技术方案或其他等效文件,被测软件需求规格说明和软件设计文档.
活动输出：软件测试计划。根据需要可将测试计划与测试需求规格说明合并为测评大纲或测试计划。
3)测试设计和实现
关键活动:分解软件测试项,说明每个测试项的测试用例设计方法以及测试数据的选择依据;获取并验证测试数据,获取测试资源;开发必要的测试支持软件,如模拟器软件;建立并校核测试环境;按确定的文档编写软件测试说明。在转入测试执行阶段前,应进行测试就绪评审,以确定能否开始测试。
活动输入:软件测试计划和软件测评大纲
活动输出:软件测试说明(含测试用例集)和准备的测试数据。
4)测试执行
关键活动:执行测试用例,获取测试结果;分析并判定测试结果,同时根据不同判定结果采取相应措施;对测试过程的正常或异常终止情况进行核对,并根据核对结果,对未达到测试终止条件的测试用例,决定是停止测试,还是修改或补充测试用例集进一步测试,直至全部用例执行和软件问题回归测试完成，
活动输入:软件测试计划、软件测评大纲、测试说明和测试用例。
活动输出:测试执行记录和测试问题报告。
按照测试计划和测试说明的内容和要求,在执行测试时,一方面,实施代码走查/审查和设计文档审查等静态测试;另一方面,实施动态测试,在构建的测试环境中运行测试用例,判定测试用例是否通过,分析是否需进行补充测试。最后根据测试发现的问题,对修改后被测软件进行回归测试,重复该过程,直至所有问题归零,测试执行的有效性依赖于测试用例缺陷的发现率,有效性和检错率等;测试执行的充分性取决于测试用例对需求的覆盖率、用例执行率,代码走查/审查力度和文档审查检错率等;测试执行的效率依赖于代码审查效率,测试人员工作效率和当前过程工作偏差率等。
5)测试总结
关键活动:分析和评价测试工作,确定无法解决的软件测试事件并说明不能解决的理由;分析和评价被测软件,总结测试反映的被测软件与软件需求(或软件设计)之间的差异,对测试问题和结果进行分类和总结;按确定文档编写测试报告
活动输入:被测软件文档、测试计划、测试说明、测试执行记录和测试问题。
活动输出:软件测试报告。
F.1.3、系统测试用例设计
4)提高测试人员之间以及测试与开发之间的沟通和交流,尽量避免重复或无效工作,提高测试用例的复用性和质量,要将测试工作和开发工作的目标协同致,而不是相互矛盾,要树立测试的服务和学习观念。