4IPD-第四篇-常见问题(FAQ)及解答讲解

IPD流程常见问题答复

1.对于计划阶段的“如果提前采购订单批准，向Oracle发布初试BOM”的活动（活动号PROPDT-49），

活动描述为PDM。我们的理解是这项活动涉及到产品开发流程与内部采购流程相关的迁移问题，对这项活动的触发时机、工作开展方式和在相关管理系统（如PDM系统）中的审批过程不太了解，希望咨询公司能够给出参考意见。

Oracle是一个IT管理系统，此项活动的主要目的就是将审批通过的需要提前采购的物料信息提供给物资采购部门，由物资采购部门进行提前采购。此项活动一般是在计划阶段概要设计完成之时，同步需要提前采购的物料也应该提出提前采购申请，需要提前采购的物料一般包括长货期物料、有风险的独家供应商物料、需要进行公司物资认证的物料等；此申请通过项目经理（产品经理）审核后，然后通过物资采购部门主管批准后，开始触发物资采购流程。

2.计划阶段的“拟制合同书”（活动号LPDT-70），根据对本模板的理解，主要是项目开发团队与研

发委员会之间以承诺的方式对产品开发的进度、质量一级财经指标加以约束，明确PDT与IPMT在开发过程中所负的责任和承担的义务，并作为考核依据。是否需要在流程中予以实施，也请咨询公司能够给出参考意见。

为了进行项目管理和绩效管理，产品经理（LPDT）需要根据产品概要设计结果和3/4级工作计划，拟定项目合同书，作为对产品线（IPMT）、研发委员会(IRB)的承诺，同时也作为研发委员会IRB、产品线（IPMT）对资源和奖惩条件的承诺。合同书甲方为产品线、乙方为产品经理、第三方可为研发委员会或其办事机构。合同书以及产品业务计划书均需上报研发委员会备案（根据授权规定，重大项目的合同书以及产品业务计划书需要研发委员会批准）。

需指出，所有产品线（IPMT）要干的项目都是经过IRB批准的。什么时候批准的呢？ 这项活动是在MM流程中执行的。市场营销管理（Marketing Management）流程,简称MM流程。MM流程就是要制定出具体的市场策略和产品规划，做好产品研发与市场的衔接，保证企业始终“做正确的事”。所以，市场营销管理在很大程度上可理解为“产品规划”。通过运用市场营销管理流程，各产品线制定业务发展规划，企业负责跨产品线的整合，最终形成一致性良好的企业及产品线业务发展规划，指导各级部门有序、协调开展业务。

3.咨询版的制造操作人员（MOPS）和制造-试制工程师（PP）在概念和计划阶段没有出现任何活动和

产出，请咨询公司给出相应的主要职责，便于对这2个角色的理解。同时，请给出PP和中试经理之间的关系，使本次在IPD流程的回归过程中能够把这些角色的活动落地到位。

制造操作人员（MOPS）和试制工程师（PP）是制造方面（制造部门）的两个角色，每个角色都可以是多个人。MOPS和PP可以来自于工厂、车间。在IPD过程中，他们要分阶段、根据需要参与工作。

在概念阶段和计划阶段的与制造相关的活动都是有高级制造工程师（AME）负责的。我们多称“工艺师”。其职责：根据制造系统现状提出可制造性需求、制定制造系统（装备及工艺）总体方案、制定生产装备研制方案等活动，对产品的制造系统负责，对产品的生产负责。

试制工程师（PP）主要职责（具体参见IPD活动定义）：简单讲，就是配合AME，根据AME的方案，把生产线制造出来，并在上面试制出合格的产品，然后把生产活动转交到MOPS手中：1. 试产准备过程中（TR4之前）, 完成产品整机、单板、模块生产指导书的编写；2. 制订产品制造系统验证方案和产品一致性验证方案；3.在未来的生产线上试制产品，对制造系统和产品一致性的结果进行评估，以便改进生产线和产品；4. 初始产品生产前，拟制试产规划报告，并保证顺利通过技术评审4A；5.制造工艺开发完成后，生产小批用于测试的产品单元，借此机会来微调工艺流程；6. 产品在试产验证过程中，组织实施制造系统验证数据的分析处理和产品一致性测试，完成对产品在制造工艺系统方面和产品一致性方面的评估，以及各种问题的及时分析总结、反馈和处理，并跟踪至彻底解决。

制造操作人员（MOPS）主要职责：利用通过验证的制造系统（定型的生产线）加工产品（通常讲的工人）。主要工作在产品发布和生命周期阶段。

中试或称试制[pilotscale experiment]是指产品大规模量产前的较小规模试验试制；或者说，正式投产前的试验试制。2000年前，华为的产品实现过程分为：开发-中试-生产三个阶段，即产品经历两次状态转换过程：开发转中试和中试转生产。2000年实施IPD后，中试阶段取消（因为中试多了一道“弯”），中试的相关工作融入到IPD的各相关阶段特别是验证阶段。

企业的制造部门负责生产线的设计、开发（或采购、集成）、验证、定型和产品的试制。

4.对于TR1中的评审要素中设计的子评审，有无相应的评审要素？

评审要素表既可以用于自查，也可以用于子评审和主评审，只是评审者不同而已。

在TR1评审要素表中的要素就是全要素表，因为TR1评审的内容是包括多个方面的，其中子评审的意思的可以将一部分要素提取出来做为子评审来支撑TR1评审，这样就不一定要组织所有成员一起开大会进行评审了，而是可以通过不同专业的人员组成小组负责进行相关的子评审来完成TR1评审。

5.产品需求的分解分配工作模式和文档输出形式，是由系统、硬件、软件、结构分别按产品各层级进

行分解分配，还是统一输出一个文档？

由系统级工程师组织相关的软件工程师、硬件工程师、结构工程师等相关人员进行集中开发的方式共同完成产品需求分解分配的工作，最终可以统一输出成一个文档，但由不同的人员负责各自相关内容的编写。

6.业务计划书中无预研计划、关键技术已解决情况评估等内容，但在DCP1的评审要素中有这些要求。

需要明确这些缺的内容是否形成单独文档，由谁在何时出？

关于业务计划书中预研计划、关键技术是否解决情况评估的内容在TR1技术评审时对备选概念进行评审时就要进行，因为在备选概念选择的时候就得将产品细分到哪些模块可以有共享的不用重新开发，哪些模块需要重新开发，对于需要重新开发的模块是否存在关键技术未解决的情况，是否需要进行预研，这些都是在TR1技术评审过程中要评审的，TR1技术评审也就相当于DCP1决策评审的一个前置评审，大部分技术相关的评审应该都在TR1技术评审中进行评审了。

7.咨询版流程中的缺陷跟踪使能流程仅出现在了TR1、TR2和TR3之后紧跟的触发活动上，但TR4后紧跟

的触发活动上没有。请核实，若不需要，请给出原因。

IPD中关于问题归零管理是这样描述的：TR1后，需求问题处理（使用缺陷跟踪流程，持续到开发流程结束）；TR2后，规格问题处理（使用缺陷跟踪流程，持续到开发流程结束）；TR3后，设计问题处理（使用缺陷跟踪流程，持续到开发流程结束）；TR4A后，生产质量问题处理（持续到开发流程结束）；SVT后：网上问题（即使用问题）处理流程（持续到开发流程结束）。

在概念阶段和计划阶段的技术评审主要是针对需求、产品包概念、产品规格以及产品概要设计的评审，在此两个阶段的技术评审过程中是可以对需求、产品规格、概要设计的发现的部分问题是可以通过“缺陷跟踪流程”同步进行处理，主流程也可以同步往下走，而不用等所有问题都处理完成之后才往下走，但对于这些问题一定要在开发流程结束时处理完成。例如在TR1对市场需求和产品概念评审后，针对每个要素的评审情况，可能大部分评审要素都完成得很好，但有部分要素（非关键的）内容存在一些缺陷，那么评审完成后要针对这些缺陷制定相应的改善计划，对于这些缺陷的处理就采用“缺陷跟踪流程”进行管理，同时产品开发流程可以进入下一个活动。在概念阶段和计划阶段的需求、产品规格、概要设计等内容中的问题是可以存在一定的灵活性的，而且变化的概率会比较大，只要不会造成大的影响是允许带着部分问题往下进行的。

TR4之后，研发自身测试并发现的问题不解决，就不能交给测试部门进行TR4A。TR5是针对生产线的评审，发现的生产问题及产品不解决，就不能进行试产（小批量）。TR6是在所有试验都完成的基础上进行的评审，发现的问题不解决，就不能上市（针对定制项目，只要客户允许带着问题出厂，则是可以交付试运行的）。所以，这些技术评审后就都没有“缺陷跟踪流程”。

8.计划阶段活动：监控和管理配置（SE-120）有一个注释：“规格更改控制流程”。请说明规格更改

控制流程与交付件变更使能流程间的关系。

在计划阶段的TR3评审完成之后，产品的系统、硬件（单板）、软件、结构等概要设计就已经基线化了，那么产品的配置（产品规格）也就基本确定了，后续的开发和验证过程中要严格按照此概要设计和产品配置进行开发，而不能随意更改，所有的关于产品配置（产品规格）的更改都要走“规格更改控制流程”，一定要经过相关人员评审才允许对产品配置（产品规格）进行更改。

“规格更改控制流程”主要是管理产品配置（产品规格）更改的使能流程，而“交付件变更流程”主要是管理产品开发过程中所有的交付件（包括技术设计文档、业务文档、管理文档等所有产品相关的内容）更改的管理（包括过程版本的变更管理）。一般情况下如果产品配置（产品规格）发生变更，触发了“规格更改控制流程“，一旦更改被确认，那么一定也会触发“交付件变更流程”。

9.流程图上活动：计划阶段“软件概要设计（SWE-30）”相关注释为“注：此活动对应软件项目级开

发的软件需求分析活动，具体参见IPD-CMM流程”；开发阶段“软件项目开发（SWE-50）”相关注释为“注：此活动对应软件项目级开发的软件概要设计，软件详细设计，编码，单元测试，集成测试和系统测试活动，具体走CMM流程”。凭注释的理解是软件概要设计做需求分析的活动；软件开发做概要设计的活动。因此，感觉IPD中软件开发的时机比硬件开发较滞后。请核实并确认。

应用级软件（直接面向用户）需要与硬件同步。而与硬件配套的工程软件（Engineering Software）的概要设计往往滞后硬件的概要设计，这是允许的。软件开发的时机比硬件开发稍滞后。计划阶段的概要设计中，对于软件来说主要是完成“软件需求说明书”。开发阶段完成概要设计、详细设计、编码、单元测试、集成测试和系统测试等活动。在很多情况下软件的概要设计要考虑硬件的实际情况，一般情况下都是软件来适应硬件环境，因为软件可塑性比较强。

10.在发布阶段，活动（MOPS-20)RAMP UP生产是指什么？其后紧跟的“开始量产，与ISC流程连接”。

ISC流程是否包含对供应商绩效的监控？若是，如何监控？

MOPS-10完成“向生产操作切换”，即生产部门全面“接手”；MOPS-20就是要不断扩大产能，生产活动中，RAMP UP指“逐步放量”、“量能逐步提升”；MOPS-20开始，IPD流程切换至集成供应链（ISC）流程。

11.在发布阶段的2个虚框：“监控供应与需求（MOPS）”和“监控生产（MOPS）”是否为2个使能流程。

这是生产过程中的例行工作，属于ISC中的活动。

12.请说明业务流程与使能流程之间的关系（如分类的划分原则）。

流程分为产出流程（价值创造流程）和使能流程（支持流程、支撑流程）。

产出流程是指为顾客和企业的经营创造收益的流程，这些流程是组织运营最重要的流程，多数员工介入这些流程，通过这些流程产生企业的产品、服务。这些流程在企业赢利和取得成功方面的贡献较大。这类流程包括：需求管理流程、营销（业务规划）MM流程、产品开发流程（IPD）、ISC流程、客户关系流程（销售流程）、客户服务流程等。

IPD流程中面向角色的流程都是产出流程。其中，面向角色（对象）的流程是主流程的子流程。

使能流程是指支持企业日常运作、生产、服务交付的流程，可以包括财务与统计、设备管理、法律服务、人力资源服务、公共关系和其他行政服务。这些流程虽然不能直接为顾客增加价值或创造价值，但为产出流程（价值创造流程）的实施起到保证、支持作用，使得产出流程能够实施下去。这类流程包括：项目管理（计划制定和监控；绩效考核；财务管理；质量管理）、技能管理流程（含任职资格、培训）、技术管理流程、交付件/配置/技术状态变更管理流程（EC管理流程）、需求问题/规格问题/设计问题/生产问题/使用（网上）问题处理流程（缺陷跟踪流程）、人力资源释放管理流程、供应商认证流程等。

很多使能流程（支持流程）在ISO 9000认证时，已经做过，否则是通不过ISO 9000认证的。问题在于这些使能流程的质量是好还是一般、支持流程与产出流程之间是否能够很好衔接。

13.在技术评审2评审要素表“可行性”对应有一个关联的文档模板《产品包/解决方案业务计划》在流

程和活动定义中没有出现过。请问此文档在何时出，由什么角色出。

《产品包/解决方案业务计划》指的是《产品业务计划书》。《产品业务计划书》的责任主体是产品经理。第一稿《产品业务计划书》是由产品经理的上级市场营销部门负责起草，下达任务书，作为IPD 流程的输入。进入IPD流程后，由产品经理负责进行三次优化。

14.RDPDT与SE的关系如何？两角色的活动合并到SE合适否？如果不合并，应由谁来承担RDPDT的活动？

RDPDT是研发部门的代表，偏重于研发管理方面的角色，该角色是PDT团队与研发资源线之间的接口，组织具体的研发工作，其主要职责如下：研发经理代表研发中心参与产品开发过程中研发事务的决策；编制并管理研发开发计划；组织管理产品开发过程中的需求分析、设计、开发、测试、验证及配置管理等开发工作；组织智力资产分析、多概念论证和选择，组建跨项目组的Build小组；保持研发中心与PDT 之间的双向沟通。RDPDT一般是研发部门领导。RDPDT还可以选择研发部中熟悉技术开发，且组织和管理能力比较强的人员，而不一定是技术开发能力最强的人员，曾经有过预研开发（或平台开发）项目经理经验的人员是RDPDT的较理想的人选。

SE是系统级工程师，主要负责产品的需求分解分配、系统概要设计等系统级的技术开发工作。概念阶段有多个系统工程师参与多概念论证，待RDPDT组织选择一个概念并通过TR1评审后，将选定一个系统工程师负责IPD流程的后续工作。具体职责和活动详见IPD关于SE的活动。

两个角色的活动不能合并。实际工作中，可以由一个人担任多个角色。一个角色也可以由多个人担任。比如，一个系统工程师是要负责可靠性分解与分配的，在复杂系统中，通常安排专业的可靠性工程师，根据IPD流程的角色定义，可靠性工程师是系统工程师的一个组成部分。

15.由于概念阶段和计划阶段在开工会后才进行相应的“制定概念阶段项目计划（WBS1/2/3/4)”和“制

定计划阶段项目计划（WBS3/4）”。因此，此前的资源落实和在开工会上进行的资源承诺工作如何落实？是否需要在开工会之前先做一个业务计划来落实这2项工作来解决这个问题。如果可以，那么业务计划的程度要多深才能确保上述问题的落实。同时，这个业务计划和开工会后制定的计划之间的关系如何？（本问题的提出基于不可能在概念和计划2个阶段的全程采用强矩阵的方式进行）

概念阶段：先进行“创建和分发沟通计划（LPDT-08）”，实际上就是开工会前的准备，包括初步的项目计划沟通。开工会后，根据会议意见，将细化概念阶段项目计划，并固化下来，作为监控依据。

计划阶段：概念阶段结束前，将制定端到端的项目WBS1/2级计划（LPDT-30），并进行概念阶段决策评审。所以，在计划阶段的开工会之后，主要是“制定计划阶段项目计划（WBS3/4）”。

项目计划包括项目范围（任务要求、活动描述）、进度计划、人力资源计划、其它资源计划、风险分析等。项目计划的制定是以IPD流程的活动定义为基础的。IPD流程给出了2级活动，更细的活动需要企业根据自己的具体工作继续向下分解，并逐步形成3/4级流程。

16.IPD开发流程中计划阶段产品数据结构设计（SE-99），请咨询公司给出一个有实例的文档模板，以

便我们能够理解产品数据结构应包含的所有信息，同时请核实，能否通过建立的产品数据结构快速找出不同层次的产品规格。同时，请反馈产品数据结构和结构树的区别和联系。

产品结构树的主要作用是通过结构分解，明确产品的主要构成，以及明确哪些模块是可以共享的，哪些是需要重新开发的，能明确产品开发的关键路径和风险在哪儿，指导产品开发的主要方向，产品结构树在分解时对于可以共享的模块可能只用分解到模块名称或者主要功能，对于没有共享的模块可能需要分解到可能的技术路径、元器件、物料等。产品数据结构主要作用是明确最终的产品具体功能模块，以及每个功能模块包括的子模块以及相关的元器件，产品数据结构中还要对各模块及元器件按照公司规定进行统一编号，其最终是要指导形成产品的BOM清单；所以对于产品数据结构要对所有的功能模块（包括可共享和不可共享的）并分解到所需的元器件、物料等。产品数据结构和产品结构树在形式上是很相似的，产品数据结构要比产品结构树更详细更具体。

17.在咨询版《TR技术评审体系指导书（顾问版）》中第4.3.1PDT角色中描述：“PDT经理可以但不是

必须参加技术评审，特别的，建议PDT经理应该参加早期的技术评审会议（如TR1、TR2）听取意见和参与讨论。PDT经理不是TR会议的核心人员并且在会议过程中不承担决策者和管理者角色。但在咨询版的《TR1评审报告》中第二部分“TR1评审结论”下面的斜体字说明中描述“此部分在TR1评审会后根据LPDT的决定填写。”，这两者是否存在不一致的地方？同时请咨询公司反馈PDT经理与TR主审人之间的关系。并阐明两者在TR评审中的职责和权力上的区别和联系。

这两部分是不矛盾的，《TR技术评审体系指导书（顾问版）》中第4.3.1PDT角色中首先就描述了“PDT 经理根据项目进度和方向，利用TR报告中提供的信息来进行决策”，PDT经理是不对评审会过程负责和管理，但其要根据评审会的情况来决策技术评审的结论（继续，带着风险继续，返工），而其决策的评审结论还需要通过公司质量部确认后才能发布生效，公司质量部主要关注的是PDT经理做的技术评审决策是否符合公司相关规定（例如：是否有公司规定的要素没有评审通过而PDT经理决策通过的情况、评审报告是否清晰、评审过程是否符合公司规定等）。

由于PDT经理是对产品质量负责的责任主体，而评审工作是产品质量工作的重要环节，所以由PDT 经理来负责决策产品的技术评审结论，从产品质量的角度考虑PDT经理应该是会严格控制技术评审结论的，而由于产品经理可能不是技术上的高手所以其可以但不是必须参加技术评审的过程，其可以通过技术评审过程整理出来的初步评审报告（含风险分析、冲突点分析）来进行决策。

TR主审人一定是相关业务或技术上的高手，其也是产品中占最大权重的评审专家，一般可以选择产品关键路径相关领域的专家做为主审人，其是技术评审过程的主体，其要负责针对其熟悉的业务和技术方面进行技术评审，并对与其相关的评审要素进行逐一评审和提供建议，并其要对其提出的评审意见负责；同时其要根据评审专家预审情况决策是否需要组织召开评审会议。TR主审人通常是PDT之外的同行专家，由PQA在公司范围内聘任，一旦确定，则在项目过程中不会更换。

在技术评审两者的职责和权力如下：

TR主审人：负责与自身业务或专业领域相关的内容进行评审，并对这些评审结果负责；根据所有评审专家的预审情况决策是否需要召开评审会议；召开评审会议时与评审专家共同对产品进行技术评审，但其评审意见权重较大；Sub-TR的主审人还负责相应子评审报告的编写。

PDT经理：可参加但不是必须参与技术评审过程，且参与评审时不作为管理者和决策者；根据评审报告有关内容决策下一步工作如何开展（继续、带着风险继续、返工）；帮助确立和实施技术评审报告中确认的项目专项工作；授权发布TR报告（含改进计划）给PDT以外的利益相关人，以便公司内部共享。

18.在学习咨询版TR1和TR2的评审要素表时，发现其中都涉及到相同的子评审“SUB-TR 产品备选概念”。

由于TR2是在计划阶段分解分配和设计规格之后进行的评审而备选概念是在概念阶段定义产品包需求和产品概念之前进行的工作。请说明TR2中备选概念子评审和TR2以及概念阶段进行备选概念之间的关系。以及在TR2中设计备选概念子评审的目的和作用。另外，在TR1评审要素表中的对应产品备选概念中第一条评审要素为：“选择的产品备选概念是否满足所有的产品包需求项？”。在流程图上，备选概念是在定义产品包需求和产品概念之前的活动，因此对于这条评审要素如何理解。

概念阶段与产品包需求和产品概念有关的主要活动包括：进行产品包需求验证（外部需求）和补充、完善（内部需求）；由研发代表组织多个系统工程师开展多个技术方案论证（主要针对功能和性能）；在多个技术方案基础上，考虑产品的全部因素（CBB因素、RAS因素、UCD因素、标准策略等），产生多个产品概念，并由研发代表组织从中优选一个，同时明确一个系统工程师，其他系统工程师可退出；以选中的产品概念为主进行优化（吸取其他产品包概念的优点），同时完善产品包需求，最终确定产品包需求和对应的产品概念；先进行“SUB-TR 产品备选概念”子评审；之后，提交TR1总评审（也可以合并评审，不设置子评审），TR1评审包括产品包需求评审和产品概念评审；根据TR1评审意见，将产品包需求基线化，同时，对产品概念评审中发现的问题进行“缺陷跟踪”（即修订、完善所选择的那一个备选概念）。

计划阶段TR2评审：为确保TR1评审后所有有关产品概念的遗留问题都得到了解决，TR2时进行了再一次审视和确认，所以才会出现“所有产品包需求（包括客户需求、可服务性/可维护性/可靠性/DFM/DFA/DFT需求/环保等）是否清晰地定义并映射到产品备选概念中？”。

19.ESP测试计划中的内容，内容模板够明晰。以前的产品都没有做过ESP测试，如果以后做此工作，相

当于产品开发过程中增加此项，需要和客户签订相应的合同。

在产品开发期间的签单客户，称为ESP客户。有些产品开发时，没有ESP客户，比如开发一个大众消费品“鼠标”。而对于定制项目，ESP就是甲方，企业的作法最好是借此机会，把这个定制产品变为一个具有多个客户的产品或产品系列。

20.客户定单履行策略这个文件对于目前我们公司来说意义不大，编写内容不清楚，而且实用性不大。

每个企业都会涉及这一问题。销售拿来订单提交给谁，谁录入，提交给谁批复，批复后生产、采购部门如何执行，产品提交给谁，如何进入物流渠道，货谁发、发货地址，如何通知对方，货物途中如何跟踪，如何验货等等。订单履行就是接到订单到完成订单的整个过程，这是公司的一个重要环节。

21.产品标准策略：要求为产品达一个标准框架，什么是标准框架？什么是技术路线？已经发布的标准

是什么？我们的产品大部分属于客户订制，没有制定相应的标准。还有未来的新标准。这些都与我们实际情况不符合，此文件对导航产品来说没什么意义。

根据产品的配置搭建标准框架，比如导航仪包括：天线、射频、基带、协议、信号格式等，这些方面都有哪些国际、国内、行业标准？列出来就是标准框架。哪些标准是正在实施的，哪些还在制定中，哪些即将制定。然后分析，哪些必须遵守，哪些不遵守，哪些部分遵守，所有的标准对产品开发和后续销售会有什么影响，包括正在制定的标准和将来制定的标准，为什么？有些标准能够决定或影响产品的技术方案/路线。所以，产品设计时需要研究标准策略。事实上，客户定制的北斗导航产品就有不少的标准约束，比如电文格式。

通常实现一个产品功能是有多个技术路径的，我们不是很随意的先一个技术路径，因为在产品标准框架的约束下进行比较与选择。技术路径的选择要指导我们后续的概要设计、详细设计工作。

已发布标准指标准框架中涉及到或相关的国际、国内正式发布的标准，这儿不仅仅是罗列出标准名称，还需说明是用在我们产品那块上，如是硬件标准还是软件标准还是那个接口的接口协议等，这是要指导我们后续相关内容开发需遵循的基本要求，建议做成表格。我们经常说要遵循国标、遵循军标都是要纳入我们策略中的。

22.产品包开发主计划：这个文件到底有什么作用？计划的汇总吗？本来各个阶段都有相应的1，2，3

级计划，为什么还要这个文件呢？什么叫汇总计划的交付件？汇总计划的成本？这些与我们实际工作相差较大，写此文件没什么意义。

产品包开发主计划是“产品业务计划书”的主要内容、核心内容，是指导开发业务计划书中研发类内容的。可以理解为研发部门的综合工作计划，而且淡化技术、偏管理，包括：交付成果有哪些？要干什么事？用多少人？化多少钱？进度、里程碑？下面产品包验证主计划指产品及服务的验证工作计划。

23.对外合作策略：我们现在的外购器件如天线、通道、电池等，到底算不算对外合作，我们只是提技

术要求，厂家研制后卖给我们，我们并不给厂家提供研制费用。这种算对外合作吗？

算。具体解释见《对外合作策略》。

24.测试的输入输出通道和测试总线，这是什么意思？能观性设计：这是什么东西？能控性设计，这又

是什么东西？计算机\网络配套设备选型方案，这个跟我们实际不符合。产品测试路线里面的内容不知如何填写。

可测试性中的逻辑结构是指从测试的角度审视系统的整体描述，包括各模块间的接口关系等是否符合可测试要求。

测试总线：以前的测试是分离测试的，如电源测试电源的，显示器测试显示器的。现在是利用总线技术将产品各测试模块关联起来，大家都通过总线进行测试，这条总线就是测试总线，而测试输入命令及测试的输出信息的物理通道就是测试的输入输出通道。在系统工程师个人无法完成测试的规格设计时，由测试工程师协助完成。在我们芯片小手持没用运用测试总线技术时，本内容可暂不填写。

能观性：产品状态的可监测性，指产品各功能状态可由输出命令测量到系统状态的能力，监测对象通常包括五个部分：系统配置监测、业务通道监测、单板运行监测、系统资源监测、其他状态的监测，具体监测内容在产品设计规格说明书有详细定义。

能控性：能控性和能观性的概念是由卡尔曼在1960年提出的，能控性是指系统的状态变量可由外输入作用来控制的一种性能。如通过输入使偏离系统平衡状态的某个初始状态回复到平衡状态，就称这个

初始状态是能控的。当系统的所有可能的初始状态都能控时，称系统为完全能控的。在《产品设计规格说明书》中对产品的能观性和能控性都提出了明确的要求。

对于能观性、能控性、内置自测试、结构造型及机电规格和设计方案，我们需要考虑哪些内容是我们现在已做过到的，哪些内容还没做过的。没做过的内容中，哪些是我们现有能力能做的，哪些是不能做的，我们将如何提高？

计算机\网络配套设备选型方案：如果一个产品（比如卫通地面站）要用到计算机和网络，就要选型。用不到就不必考虑。

产品测试路线：可以理解为产品测试方案（含测试流程），测试内容包括从产品的来料到产品生产的全过程中，我们的测试环节、先后顺序以及各环节的测试内容及要求。测试路线用框图（流程图）的形式表达（业界典型的生产路线：IQC（进料检验）→SMT（表面组装技术（表面贴装技术））→MVI（人工视觉检查）→插件→MVI →波峰焊→MVI →补焊→MVI →ICT/FT（在线测试/功能测试）→老化→FT →PQC（过程质量控制）→入库→出库→整机装配→系统测试→发货）。系统工程师要根据我们芯片小手持的测试要求画出测试路线，并对每个测试的环节提出测试设备、测试时间、测试数量及其他测试指标的要求。

25.概要设计：概要设计中的功能定义和物理定义有什么区别，请解释再清楚些。里面的所有内容都不

知道怎么填，真不知道这个文件跟我们实际工作有什么关系。里面的内容对我们的实际工作有什么指导意义吗？

要了解概要设计的意义就必须了解概要设计与详细设计的关系和区别。我们产品开发是结构化的，自上而下的逐步细化展开的开发过程。以软件为例：概要设计实现软件的总体设计、模块划分、用户界面设计、数据库设计等等；详细设计则根据概要设计所做的模块划分，实现各模块的算法设计，实现用户界面设计、数据结构设计的细化等。详细设计必须遵循概要设计来进行。详细设计方案的更改，不得影响到概要设计方案；如果需要更改概要设计，必须走严格的变更流程。从数据库设计看：概要设计重点在描述数据关系上，说明数据的目的和原因。详细设计中数据库设计就应该是一份完善的数据结构文档，就是一个包括类型、命名、精度、字段说明、表说明等内容的数据字典。从功能角色看：概要设计里的功能重点在功能描述，对需求的解释和整合，整体划分功能模块，并对各功能模块进行详细的图文描述，应该让读者大致了解系统作完后大体的结构和操作模式。详细设计则是重点在描述系统的实现方式，各模块详细说明实现功能所需的类及具体的方法函数。

以手机为例：具有话音功能、邮件功能、短信功能、多媒体播放器功能，这就是所谓的功能。这些功能是如何实现的？比如由天线、双工器、ARM处理器、显示器、触摸屏等组成，这就是所谓的物理定义。先梳理产品的所有功能，以及这些功能之间的相互关系，称之为功能定义。功能如何由硬件或软件实现，称为物理定义。一个硬件可能实现多个功能，也有可能多个硬件实现一个功能。某个功能是由单一硬件实现还是由硬件和软件联合实现，比如软件无线电？这是概要设计需要回答的。概要设计就是我们讲的总体设计、总体方案、顶层设计之类的。至于软件无线电如何实现则是下一步的事。

26.结构概要设计模板的内容很多很全面，但与现状相距甚远，写的时候需要大幅度裁剪了。

我们要分析哪些内容是我们现在已经在做的，哪些是没有做过的，在没有做过的内容中，哪些内容又是我们现在能力可以尝试去做的，哪些内容是根本不能做的，对于这些不能做的我们将如何去提升？

对于我们现在已经在做的，我们要详细的总结、描述出来，将好的东西进行沉淀、固化。

对于我们可以尝试去做的，要尽我所能的写出来，相关的角色负责人要参与进来，进行辅导，甚至亲自执行，然后将方法传授下去。

27.硬件概要设计模板：单板软件需求和配套方案，这个是什么内容？业务处理软件对单板硬件的需求

可实现性评估，这个内容与实际相差较远。单板基本逻辑需求和配套方案，这个内容不会写。单板逻辑的配套方案、单板大规模逻辑需求、大规模逻辑与其他单元的接口这些内容与实际不符。最后10的内容是开发环境，应该是放在最开始的，怎么放置到了最后才写，不合理。

有的单板不需要软件，有的单板是要和软件一起才能实现某些功能。这里讲的是，单板对软件有什么需求，提出来以便软件人员开发。有则提，无则不用提。反之，软件也需要对硬件提要求。这是个双方协调的过程。

单板的时钟及时序关系就属于基本逻辑，如果有就写，没有就不写。很多工作我们都有，只不过是“术语”、“名词”用的不一样，所以需要理解术语，必要时可以本地化。

单板开发要完成规定的任务，就需要配套的开发环境支持。有的是公司已经有的，但是当公司已有环境满足不了要求，还需要提出相应的要求。所以在最后讲开发环境也是合理的。