功能特性与实现方法 (功能特性与实际不符)

功能特性与实现方法：探讨实现过程中的潜在偏差及其解决方案

一、引言

在软件开发和产品设计过程中，功能特性与实现方法的关系密切且至关重要。
功能特性描述的是产品的功能和性能，是产品开发的目标和需求。
而实现方法则是将这些功能特性转化为实际产品的过程。
在实际操作中，我们可能会遇到功能特性与实际实现不符的情况。
本文将探讨这种情况的原因、解决方案以及预防策略。

二、功能特性与实际实现的偏差原因

在产品开发过程中，功能特性与实际实现之间出现偏差的原因有很多，主要包括以下几点：

1. 需求理解不准确：开发团队对客户需求理解不足或存在误解，导致开发出的功能与预期功能存在偏差。
2. 技术实现难度：某些功能特性的实现可能面临技术挑战，如技术限制、技术更新等，导致实际实现与预期存在差异。
3. 沟通不畅：开发团队、客户、测试人员等各方之间的沟通不畅，导致信息传递不及时或信息丢失，从而产生偏差。
4. 变更管理不当：在项目进行过程中，需求的变更管理不当，可能导致原有功能特性的改变，进而产生偏差。

三、解决方案

针对功能特性与实际实现之间的偏差，我们可以采取以下解决方案：

1. 加强需求调研与沟通：通过与客户深入沟通，确保对需求有准确、全面的理解。同时，及时将反馈和变更传达给相关团队，确保信息的准确性。
2. 技术评估与预研：在产品开发前，对技术实现的可行性进行评估和预研，确保技术难题在开发过程中得到及时解决。
3. 建立严格的变更管理流程：对于项目过程中的需求变更，应建立严格的变更管理流程，确保变更的合理性、必要性和可行性。同时，对变更进行记录和跟踪，以便后续审计和复盘。
4. 引入第三方评审：在项目关键阶段，引入第三方专家或机构进行评审，以客观、公正地评估项目的进展和成果，确保功能特性与实际实现的一致性。

四、预防策略

为了降低功能特性与实际实现之间出现偏差的风险，我们可以采取以下预防策略：

1. 提前识别风险：在项目启动阶段，对可能存在的风险进行识别和评估，制定相应的应对措施。
2. 制定详细的项目计划：建立详细的项目计划，明确各阶段的目标和任务，确保项目按照预期进行。
3. 建立监控机制：建立项目监控机制，定期对项目进度、质量进行检查和评估，及时发现并纠正偏差。
4. 提升团队能力：通过培训、引进人才等方式提升团队的技术能力和项目管理能力，确保项目的高质量完成。

五、案例分析

假设某公司在开发一款在线支付产品，其功能特性包括快速支付、安全保障等。
在实际开发过程中，由于技术实现的难度和对需求理解的不足，导致实际支付速度没有达到预期，安全保障功能也存在漏洞。
针对这一问题，公司采取了上述解决方案，如加强需求沟通、技术预研、建立变更管理流程等。
最终，成功解决了问题，确保了产品的质量和功能的实现。

六、结语

功能特性与实现方法之间的关系是产品开发过程中的核心问题。
在实际操作中，我们应充分了解可能存在的偏差原因，采取有效的解决方案和预防策略，确保产品的质量和功能的实现。
通过不断地学习和实践，我们可以更好地处理功能特性与实现方法之间的关系，提高产品开发的成功率。

---

技术状态管理

技术状态管理是指在产品寿命周期内，为确立和维持产品的功能特性、物理特性与产品需求、技术状态文件规定保持一致的管理活动，主要内容包括技术状态标识、技术状态控制、技术状态记实和技术状态审核。 本文先从几个概念的理解入手，再从技术状态管理的四个方面说明对技术状态管理的理解与感悟。 一、几个概念的理解 1.1 技术状态项 技术状态项是指能满足最终使用功能，并被指定作为单个实体进行技术状态管理的硬件、软件或其集合体。 1）确定时机：较高层次的技术状态项可在方案阶段初期或之前选择，较低层次的技术状态项可在工程研制阶段初期或之前选择。 2）确定顺序：先进行产品工作结构分解，确定产品分解结构后再确定技术状态项，技术状态项应与工作分解结构单元对应。 3）确定原则：并非所有的工作分解结构单元都要作为技术状态项，被选择作为技术状态项的产品一般是： a）武器装备、分系统级产品或跨单位、跨部门研制的产品； b）在风险、安全、完成作战任务等方面具有关键特性和重要特性的产品； c）新研制的产品； d）接口复杂且重要的产品； e）单独采购的重要产品； f）使用和保障方面需要着重考虑的产品。 1.2 技术文件、技术状态文件和技术状态基线 技术状态文件是规定技术状态项的功能特性和物理特性，或从这些内容发展而来的关于技术状态项验证、使用、保障和报废要求的技术文件。 通常是直接作为产品研制、生产或使用保障依据的技术文件，主要包括规范、图样及其他需要的技术文件。 计算报告、试验报告等技术文件虽是产品定型所需技术文件，但一般不作为技术状态文件。 并非所有的技术文件都是技术状态文件，这句话可以从两个方面理解： 1）对于规定其他非技术状态项特性的文件非技术状态文件。 2）对于技术状态项相关的文件，但没有规定其功能特性和物理特性的文件非技术状态文件，如计算报告等。 技术状态基线是在产品寿命周期内的某一特定时刻，被正式确认并作为今后研制生产、使用保障活动基准，以及技术状态改变判定基准的技术状态文件。 一般包括功能基线、分配基线和产品基线。 作为技术状态基线，应同时满足三个条件： 1）被正式确认。 什么叫正式确认呢？依据GJB3206，通过按GJB3273标准执行的技术审查才叫正式确认；在日常操作中，由客户组织或参加，多方认可或正式批复的方式都可以认为是正式确认。 2）作为今后研制生产、使用保障活动基准。 通常指研制总要求（研制基准）、技术规格书（生产基准）、使用维护说明书（使用保障活动基准）以及相关的合同、规范或要求。 （从这个角度看，技术设计报告、六性设计报告等都不属于技术状态基线。 ） 3）技术状态改变判定基准。 通常说的是在研制、生产、使用过程中作为技术状态改变的基准，主要也是指研制总要求、技术规格书、使用维护说明书以及相关的合同、规范或要求。 怎么确定技术状态基线呢？这里提供两种思路，都有道理，但没有明确规定哪种是对的，但考虑到技术状态管理是为了管理技术状态，所以名称的问题就无关紧要了。 1）站在武器系统总体的角度来确定技术状态基线，GJB3206就是这种思路，技术状态管理基线表如下： 表1 武器系统总体的技术状态基线表 运用这个思路，那作为分承包商如何确定技术状态基线呢？GJB3206给出的思路是在这三个基线的基础上，在进行细分，如任务基线、研制基线、性能基线、制造基线等等，可以在概念不冲突的情况下实现技术状态可控。 2）站在分承包商的角度来确定技术状态基线，具体基线如下： a）功能基线：研制合同、研制任务书； b）分配基线：方案设计报告、“六性”计划、标准化大纲、技术规范等； c）产品基线：同表1。 比较两个角度的不同，相对于总承包商，分承包商因为接触不到方案论证报告和研制总要求，只能把研制合同和研制任务书作为功能基线，并从分配基线中拿出来，仅此而已。 1.3 功能特性、物理特性、功能技术状态审核、物理技术状态审核 把这两组概念拿出来的原因是因为在GJB3206中，类似的概念名称却有着完全不同的含义，废话少说，直接上定义了。 功能特性是指产品的性能指标和设计约束条件，如战术技术指标、使用保障特性等；物理特性是指产品的形体特征，如组成、尺寸、表面状态、形状、配合、公差、质量等，又称实体特性。 所以，两者的区别是，一个指的是性能指标相关特性，一个指的是实体特征相关的特性，泾渭分明，比较清楚。 按惯常的思维，那功能技术状态审核应该是对技术状态项的功能特性的审核，物理技术状态审核应该是对技术状态项的物理特性的审核，事实呢，不是这样的，看定义。 功能技术状态审核是为了验证技术状态项的功能特性达到功能基线、分配基线规定的要求所进行的技术状态审核，可与设计定型工作结合进行，审核的内容一般包括（以下内容重点是针对设计过程的，重点看是否满足功能基线和分配基线）： 1）审核承制方的试验程序和试验结果是否符合技术状态文件的规定； 2）审核正式的试验计划和试验规范的执行情况，检查试验结果的完整性和准确性； 3）审核试验报告，确认这些报告是否准确、全面地说明了技术状态项的各项试验； 4）审核接口要求的试验报告； 5）对那些不能完全通过试验证实的要求，应审查其分析或仿真的充分性和完整性，确认分析或仿真的结果是否足以保证技术状态项满足其技术状态文件的要求； 6）审核所有已确认的技术状态更改是否已纳入技术状态文件并已经实施； 7）审核未达到质量要求的技术状态项是否进行了原因分析，并采取了相应的纠正措施； 8）审查偏离许可、让步清单； 9）对软件和硬件集合成一体的技术状态项，除进行上述审核外，还可进行必要的补充审核。 物理技术状态审核是为建立或验证产品基线，对技术状态项试制试产样品的完工状态，所依据的技术状态文件而进行的技术状态审核，物理技术状态审核应在功能技术状态审核完成之后进行，可与生产定型工作结合进行，审核的内容一般包括（以下内容重点是针对生产过程的，重点是为了验证产品基线）： 1）审核各技术状态项有代表性数量的产品图样和相关工艺规程（或工艺卡、下同），以确认工艺规程的准确性、完整性和统一性，包括反映在产品图样和技术状态项上的更改； 2）审核技术状态项所有记录，确认按正式生产工艺制造的技术状态项的技术状态准确地反映了所发放的技术状态文件； 3）审核技术状态项首件的试验数据和程序是否符合技术状态文件的规定：审核组可确定需重新进行的试验；未通过验收试验的技术状态项应由承制方进行返修或重新试验，必要时，重新进行审核； 4）确认技术状态项的偏离、不合格是在批准的偏离许可、让步范围内； 5）审核技术状态项的使用保障资料，以确认使用保障资料的完备性和正确性； 6）确认分承制方在制造地点所做的检验和试验资料； 7）审核功能技术状态审核遗留的问题是否已经解决； 8）对软件和硬件集合成一体的技术状态项，除进行上述审核外，还可进行必要的补充审核。 简单总结一下，功能特性和物理特性是从产品的特性角度分类的，而功能技术状态审核和物理技术状态审核与前面两个概念没有必然的联系，分别针对设计和生产过程，前者验证功能基线和分配基线，后者验证产品基线。 二、技术状态标识 从字面意思看，技术状态标识就是对技术状态项进行标识，对吗？不对，从GJB3206看，技术状态标识的工作任务包括： 1）选择技术状态项； 2）确定各技术状态项在不同阶段所需的技术状态文件； 3）标识技术状态项和技术状态文件； 4）建立技术状态基线； 5）发放经正式确认的技术状态文件并保持其原件。 这里需要说明的内容有三个：① 确定技术状态项在不同阶段所需的技术状态文件。 因为技术状态项不包括产品所有的组成单元，所以，此处的技术状态文件包括两种：一是单独规定技术状态项的技术状态文件；二是包含技术状态项的技术状态文件。 ② 标识技术状态项和技术状态文件。 如何标识呢？技术状态项的产品型号和编号，因为具有唯一性可作为技术状态项的标识；技术状态文件也都有文件编号，同样具有唯一性可作为技术状态文件的标识。 ③ 发放经正式确认的技术状态文件并保持其原件。 这个要求比较严格，应该制定技术状态文件发放的程序，经过批准后才能发放，并记录发放的信息。 在技术状态基线建立后，应控制并保持所有现行已批准的技术状态文件的原件（部分单位技术状态文件的底稿和正稿的管理方式应该是来源于此处要求）。 三、技术状态控制 大家对技术状态控制内容相对比较熟悉，具体内容包括三个方面： 1）制定控制技术状态更改、偏离许可和让步接收的管理程序与方法； 2）控制技术状态更改、偏离许可和让步； 3）确保已批准的技术状态更改申请，及偏离许可、让步申请得到准确实施。 技术状态控制的内容可分为两个部分来说明，一是技术状态更改，二是偏离许可和让步接收，具体内容如下。 3.1 技术状态更改 大家对技术状态更改的内容非常熟悉，关于其分类、程序等内容就不再一一赘述，需要说明的有两点： 1）技术状态更改应遵循的五条原则：“论证充分、试验验证、各方认可、审批完备、落实到位”，这也是来源于航天的经验总结，深刻而精辟。 2）I类、II类、III类技术状态更改的差异：I类技术状态更改和II类技术状态更改需要先编制技术状态更改申请，经审批后在编制技术状态更改通知（技术状态更改通知的形式一般有更改单或修改单、技术通报等），且I类技术状态更改和设计定型后的II类技术状态更改申请应经客户审批；而III类技术状态更改可直接编制技术状态更改通知，且III类技术状态更改和设计定型前的 II类技术状态更改申请可由承制方自行审批，并通知客户即可。 3.2 偏离许可和让步接收 在技术状态项制造前，如果承制方认为有必要临时偏离已批准的技术状态文件，可提出偏离许可申请。 在技术状态项制造期间或检验验收过程中，如果承制方认为不合格品可返修或原样使用，可提出让步申请。 偏离、不合格的级别一般分为严重级和轻度级。 严重级之外的属于轻度级，对下列一项或多项产品影响的偏离、不合格均属严重级： 1）性能； 2）功能接口或物理接口； 3）互换性； 4）形状、质量、质心； 5）可靠性、维修性、测试性、保障性、安全性； 6）环境适应性和电磁兼容性等特性； 7）人员健康与安全； 8）服役使用或维修； 9）造成严重后果的其他方面。 产品设计定型前的偏离许可、让步申请一般由承制方自行审批。 产品设计定型后的偏离许可、让步申请应经客户审批。 四、技术状态记实 技术状态记实是在产品寿命周期内，为说明产品的技术状态所进行的记录、报告活动，具体任务包括： 1）记录并报告各技术状态项的标识号、现行已批准的技术状态文件及其标识号； 2）记录并报告每一项技术状态更改从提出到实施的全过程情况； 3）记录并报告技术状态项的所有偏离许可和让步的状况； 4）记录并报告技术状态审核的结果，包括不符合的状况和最终处理情况； 5）记录并维持已交付产品的版本信息及产品升级的信息； 6）定期备份技术状态记实数据，维护数据的安全性。 应从产品的方案阶段其开展技术状态记实活动，根据技术状态记实的任务，主要工作分为记录和报告两个方面，记录指的是在产品生命周期内记录相关的技术状态活动，容易理解，那报告的要求包括什么呢？从两个方面看： 1）在产品研制生产阶段，向客户报告，报告内容如下： a）技术状态项及其技术状态基线文件清单； b）当前技术状态说明报告； c）技术状态更改、偏离许可和让步状况报告； d）技术状态更改实施和验证报告； e）其他客户要求的报告。 2）向供方报告，其报告方式是从上面内容中挑选适用的文件发送给供方。 五、技术状态审核 技术状态审核是为确定技术状态项与其技术状态文件的一致程度而进行的正式检查，包括功能技术状态审核和物理技术状态审核，在第一章中已经说得比较清楚了，这里不再赘述。 六、结语 技术状态管理是武器装备研制系统工程的重要组成部分，是实施研制、生产质量保证的重要手段，只有在型号产品全寿命周期内严格控制技术状态，才能可靠地保证武器装备质量满足最终的使用要求。

软件质量有什么特性

软件质量有什么特性？ 《软件工程—产品质量》（GB/T -2006）中规定对软件的每个质量特性与子特性都有定义：一、功能性：是指当软件在指定条件下使用，软件产品满足明确和隐含要求功能的能力。 适合性：是指软件产品与指定的任务和用户目标提供一组合适的功能的能力。 准确性：是指软件产品具有所需精确度的正确或相符的结果及效果的能力。 互操作性：是指软件产品与一个或多个规定系统进行交互的能力。 保密安全性：是指软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，但不拒绝授权人员或系统对其的访问。 功能依从性：是指软件产品依附与同功能性相关的标准、约定或法规以及类似规定的能力。 二、可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。 成熟性：是指软件产品避免因软件中错误发生而导致失效的能力。 容错性：是指在软件发生故障或违反指定接口的情况下，软件产品维持规定的性能级别的能力。 易恢复性：是指在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。 可靠性依从性：是指软件产品依附与同可靠性相关的标准、约定或法规以及类似规定的能力。 三、易用性：是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。 易理解性：是指软件产品使用户能理解软件产品是否合适以及如何能将软件用于特定的任务和使用环境的能力。 易学性：是指软件产品使用户能学习它的能力。 易操作性：是指软件产品使用户能操作和控制它的能力。 吸引性：是指软件产品吸引用户的能力。 易用性依从性：是指软件产品依附与同易用性相关的标准、约定、风格指南或法规以及类似规定的能力。 四、效率：是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。 时间特性：是指在规定条件下，软件产品执行其功能时，提供适当的响应时间和处理时间以及吞吐率的能力。 资源利用性：是指在规定条件下，软件产品执行其功能时，提供合适的数量和类型的资源的能力。 效率依从性：是指软件产品依附与同效率相关的标准或约定的能力。 五、 维护性：是指软件产品可被修改的能力，修改可能包括修正，改进或软件适应环境、需求和功能规格说明中的变化。 易分析性：是指软件产品诊断软件中的缺陷或失效原因，以及判定待修改的部分的能力。 易改变性：是指软件产品使指定的修改可以被实现的能力。 稳定性：是指软件产品避免由于软件修改而造成意外结果的能力。 易测试性：是指软件产品使已修改软件能被确认的能力。 维护性依从性：是指软件产品依附与同维护性相关的标准或约定的能力。 六、 可移植性：是指软件产品从一种环境迁移到另一种环境的能力。 适应性：是指软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同的指定环境的能力。 易安装性：是指软件产品在指定环境中被安装的能力。 共存性：是指软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。 易替换性：是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力。 可移植性依从性：是指软件产品依附与同可移植性相关的标准或约定的能力

机械特性的DTE与DCE

DCE（数据通信设备或数据电路终端设备）：这种设备及其与通信网络的连接共同构成了网络终端的用户网络接口。 它提供了与网络的物理连接、转发业务量，并且生成一个用于同步DCE设备和DTE设备之间数据传输的时钟信号。 调制解调器和接口卡都是DCE设备的例子。 DTE与DCE之间的接口标准特性包括：机械的、电气的、功能的、过程的。 机械特性规定了DCE与DTE的实际物理连接。 电气特性规定了DTE和DCE必须使用的编码，必须用相同的电压来表示相同的状态，必须使用相同宽度的信号比特，这些特性决定了能够实现的数据传输速率和距离。 功能特性指明了每条交换电路必须完成的功能。 根据接口的功能特性，过程特性规定了传送数据的事件序列。 RS-232接口是DTE（数据终端设备）和DCE（数据通信设备）之间的一个接口；DTE包括计算机、终端、串口打印机等设备。 DCE通常只有调制解调器（MODEM）和某些交换机。 标准指出DTE应具备一个插头（针输出），而DCE应具备一个插座。