软件开发费用.doc

分发号受控状态北京四海华辰科技有限公司SHHC-CX-7.3-01 设计和开发控制程序（A/0）2014-07-15发布 2014-07-15实施 北京四海华辰科技有限公司发布文档信息*文件名称设计和开发控制程序*文件编号SHHC-CX-7.3-01*文件所有者产品研发部*文件密级秘密 机密*颁发部门产品研发部_份 供应链管理部_份 质量管理部_份 市场部_份 销售部_份 人力资源与行政部_份本版批复信息意见*签字*日期编制审核批准文件版本记录*生效日期*作者*版本*变更说明说明：*项为必需项，不得缺失。如果“审核意见”及“变更说明”写不下，可以附页说明设计和开发控制程序1 目的 本程序规定了对本公司设计开发活动的控制要求，以使设计开发过程得到控制，并确保设计输出满足设计输入的要求，设计开发出满足顾客期望和要求的、符合相关法律法规要求的产品。 2 适用范围本程序适用于本公司新产品开发项目和变型设计开发项目的过程控制。 不适用于 OEMODM 项目、技术平台项目的设计开发过程控制。 3 术语和定义 3.1 项目分类 3.1.1 变型设计开发项目 对于已定型并投入生产的产品进行局部设计修改并形成新型号的产品开发项目。 3.1.2 新产品设计开发项目 针对新的用户需求进行的产品设计开发项目。 3.2 阶段评审 对项目各阶段要实现的一组既定目标是否达到预期要求所作的评审，并做出是否进 入下一阶段的决定。 3.3 设计评审 设计评审是指对设计开发工作所作的正式的、综合性的和系统性的评审，以评价设计开发的结果是否满足要求，识别任何问题并提出必要的措施。 3.4 技术评审 针对开发过程中的一项或几项开发任务，进行评审，检查可交付成果所采用的技术、方案是否能够达到所要求的功能和性能，是否存在缺陷，能否进行改进等。 3.5 DMR（Device Master Record） 产品主文档，包括产品所需的用于支持生产、检验、使用、维护和描述接受准则的文件。 3.6 DHF（Design History File） 开发过程文件，包含用于描述开发过程而形成的所有文件和记录。 3.7 DHR（Device History Record） 设备档案，是依据文件规定的规范和流程，即 DMR，生产某一产品的记录，包含制造、装配、调试、检验记录，序列号记录，问题追踪及返工记录，批准放行记录等。3.8 项目组 在综合开发计划中确定的跨部门的设计开发所需的人力资源。架构如图 3-1 所示： 图3-14 职责权限4.1 总经理 参与P0、P3阶段评审和批准。 4.2 研发总监 参与设计评审和阶段评审，批准并签署综合开发计划、用户需求说明书、 产品规格说明书。 4.3 项目经理 项目经理是项目组这个跨部门团队的领导，负责制定和实施综合开发计划，组织协调项目组内各项工作，控制项目质量、开发进度、开发费用及产品成本。负责编制立项申请报告，批准设计验证计划、设计验证报告、设计确认计划、设计确认报告。 4.4 市场部产品经理 负责编制市场调研分析报告，负责提供用户需求和预期用途等设计输入信息，编制用户需求说明书，并关注市场并及时反馈顾客需求的变更，主导需求变更评审。 4.5 系统工程师 负责整合设计输入的信息并编制产品规格说明书，汇总设计输出并确保完整性。审核设计验证计划、设计验证报告、设计确认计划、设计确认报告、潜在缺陷。负责系统设计并主导设计工作。 4.6 硬件工程师 负责产品的硬件设计开发工作、硬件模块集成调试。 4.7 机械结构工程师 负责产品的机械结构、包装、标识设计开发工作、机械模块集成调试。 4.8 软件工程师 负责产品的软件设计开发工作、软件模块集成调试。 4.9 测试工程师 主导产品的设计验证与设计确认活动，制定设计验证计划、设计确认计划，编写验证方案，填写验证记录，完成设计验证报告、设计确认报告。 4.10 安全法规工程师 负责提出安全法规要求，主导产品的风险管理活动，制定并更新风险管理计划，形成风险管理报告。 4.11 新品转换工程师(工艺工程师) 负责提出产品可制造性的要求、样机的工艺性审核，参与样机装配，完成工艺文件， 制定中试计划，并主导中试过程。在中试过程中，保证设计输出正确地转换为工艺文件，使得批量生产的产品能够满足设计输出要求，建立和维护制造 BOM 清单，保证工艺文件的完整性。负责与生产工程师沟通，以便供应链进行量产的准备。4.12 产品认证/注册工程师 负责提出相关注册和认证的法规要求、与第三方检测机构的联络，协助项目组完成 产品注册和认证所需的技术资料，并按要求完成产品注册和认证。 4.13 临床应用工程师 负责制定和实施临床评价方案、完成临床试验，协助项目组收集临床对比资料并完 成临床评估报告。协助市场部产品经理完成用户需求说明书。 4.14 采购工程师 负责协助项目经理制定采购策略，采购样机所需的物料，保证物料的按时齐套，负 责新供方的选择和评价。 4.15 维修设计工程师 负责收集和研究维修信息，提出可维修性和安装性要求，并对可维修性和安装性进行验证。负责使用说明书、安装维护手册、预安装手册的编写和维护。 4.16 QA工程师 负责组织项目各项评审，监督项目执行，保证设计开发工作符合质量管理体系要求。 5 程序 5.1 设计开发控制流程 本程序所描述的设计开发控制流程如图 5-1 所示，它描述了设计开发控制程序中各接口的关系及活动的顺序。 图5-15.2 开发项目立项 5.2.1 市场部产品经理应及时收集和整理市场需求和用户需求，通过分析发现潜在的市 场机遇，并结合公司产品线规划提出立项建议，编制市场调研分析报告，研发部可 结合立项建议对于此项目的技术可行性进行初步判断，对于技术风险可控的项目可以编 制立项申请报告，报告应包含以下内容： a) 产品概念： 产品的预期用途； 目标市场分析，如：竞争对手分析、市场容量、注册认证法规要求等； 产品的主要功能、性能及基本结构、产品配置等； b) Business Case 成本预估； 市场前景预测； 经济效益分析； c) 综合开发计划（初稿）： 预期的项目组织架构，职责，权限； 项目控制和操作机制； 预期开发时间表； d) 项目风险分析及规避计划； 5.2.2 由项目经理提出申请并按照设计开发评审管理规定对立项申请进行评审。立 项评审得出通过或有条件通过的结论、立项申请报告得到批准标志着本项目启动， 并意味着公司对于此项目所需资源的投入做出承诺。 5.3 综合开发计划 5.3.1 综合开发计划概述了完成项目开发所必需的活动和可交付成果。每个项目都应建 立并维护综合开发计划，并保证计划得到评审和批准。 5.3.2 项目的实现依赖于综合开发计划。项目经理负责建立和整合综合开发计划，核心项目组成员负责提供综合开发计划中所需信息。综合开发计划至少应包含如下内容： a) 项目范围和项目目的； b) 项目质量目标； c) 项目开发方式； d) 项目组织架构及职责； e) 开发计划； f)法规策略；g) 项目控制和操作机制； h) 样机和中试计划； i)软件配置管理计划。注：立项评审时综合开发计划可以只包含上述 d）、e）、g）的内容。 5.3.3 项目范围和复杂程度决定着综合开发计划所包含的内容，当核心项目组判定上述 内容中某些内容不需要时，应在综合开发计划中对此结论进行充分的说明。 5.3.4 综合开发计划需要得到核心项目组成员的评审，并被研发总监批准。 5.3.5 在设计开发过程中，需要更新综合开发计划，如实反映已完成的活动，更新后需得到评审和批准。 5.4 设计输入 5.4.1 设计输入应最大程度地描述与产品有关的所有要求，产品级需求是由用户需求和性能功能需求定义的。 5.4.2 市场部产品经理应负责收集整理用户需求和预期用途等信息，并编制用户需求说明书，应体现的用户需求如下： a) 预期用途； b) 使用者和患者需求； c) 可用性要求（人机工学、产品易用性）； d) 使用环境； e) 产品改进机会（可通过分析以往同类产品的客户抱怨、维修记录等）； f)手册与标识；5.4.3 系统工程师应整合用户需求说明书、风险分析结果、性能和功能需求并最终形成产品规格说明书。采纳的设计输入信息应该是得到反复论证和评审后完整并可验证的。同时应当识别并排除含糊不清、重复的和自相矛盾的要求。 5.4.4 系统工程师编制产品规格说明书作为设计开发过程的输入，应体现以下内容： a) 产品配置、兼容性、平台； b) 与预期用途相关的功能、性能和安全要求； c) 预期销售的市场要求： 语言要求 法律法规要求 d) 可生产性、可安装性及可维修性需求； e) 风险分析所得到的风险降低措施； f) 包装、标记和手册要求等。 5.4.5 用户需求说明书及产品规格说明书应得到核心项目组的评审（FDR1），并由研发总监批准。应保留设计评审的记录，评审记录是 DHF 的一部分。 5.5 设计输出 5.5.1 设计输出是一套用于生产、安装、检验、调试、包装、运输、维修和使用的表述产品特性的文件。 5.5.2 设计输出应： a) 满足设计输入，即产品规格说明书中的要求； b) 给出采购、生产和服务的适当信息； c) 包含或引用产品接收准则； d) 规定对产品的安全和正常使用所必需的产品特性； e) 得到充分的验证或确认； f)得到审核和批准。5.5.3 设计输出是 DMR 的一部分，应包含下列等文件： a) 产品及零部件图纸、BOM、CAD 文件； b) 外购件规格说明书； c) 软件应用程序、嵌入式软件； d) 为保证产品功能及安全所需的技术要求；e) 包装设计文件；f)使用说明书、安装维护手册、预安装手册；g) 标识文件。5.5.4 系统工程师对设计输出的完整性负责。设计文件的完整性应符合设计文件管理规定的要求。 5.6 设计验证 5.6.1 设计验证是通过提供客观证据来证实设计输出满足设计输入的活动。 5.6.2 测试工程师负责制定设计验证计划，设计验证计划应包含设计验证的策略和方 法，并得到系统工程师的审核和项目经理的批准。设计验证计划是 DHF的一部分。 5.6.3 设计验证计划中需包含以下部分： a) 设计验证活动的目的、范围； b) 设计输入的要求，应标识产品规格说明书上的需求编号； c) 设计验证所需资源，包含所需样品规格等； d) 验证方案等。 5.6.4 验证方案中应描述如何验证设计输出是否满足设计输入的要求，验证方案可独立形成文件并被设计验证计划引用。 5.6.5 验证方案中需包含如下要素： a) 产品规格说明书中所有的要求； b) 使用的测试设备和设备的校准有效期； c) 验证步骤和方法； d) 每一测试项的通过条件。 5.6.6 可采取的验证方式有： a) 测试和试验； b) 变换方法计算； c) 与已经证实的设计进行比较（应记录以往设计的完整数据和采取此方法的理由）。 5.6.7 测试工程师依据验证方案进行验证并记录结果。以下信息作为设计验证的客观证 据需要记录： a) 用于验证的设计输出的识别方式，如序列号、文件号、版本等； b) 采取的验证方式； c) 验证方案； d) 测试人员签署； e) 测试设备，其中监视和测量仪器需记录校准有效期； f) 任何用于测试的软件及仿真工具，需要得到授权或确认； g) 验证结果； h) 结果判定（通过或不通过）。 设计验证过程中发现的任何与产品规格说明书不一致的验证结果，均需要记录、 处理并通过缺陷管理进行关闭。 5.6.8 在第三方检测前需要对检测样机进行自测，并保留相关验证记录和验证报告，作为 DHF 进行管理。第三方检测结果可以作为设计验证的一部分。 5.6.9 测试工程师将依据设计验证计划进行验证后得到的结果汇总成设计验证报告，并基于验证结果得出结论。设计验证报告应由系统工程师审核并由项目经理批准， 作为 DHF 进行保存。 5.6.10 设计验证结束后，项目组应依据设计评审管理规定组织召开设计评审（FDR2）， 设计评审记录做为 DHF 的一部分进行保存。 5.7 设计转换 5.7.1 在设计开发与设计验证阶段，新品转化工程师应参与样机的生产，并在设计验证 完成评审（FDR2）前主导完成： a) DMR 中除设计文件外的其余文件，包含： 工艺流程图； 作业指导书； 配置单； 检验作业指导书等。 b) 中试计划，应包含以下信息： 范围、策略、方式及时间表； 职责权限； 物料采购计划； 验收准则； 验证可制造性的计划及方案； 验证可安装性的计划及方案； 验证可维修性的计划及方案等； 其中维修设计工程师负责可安装性验证及可维修性验证部分的内容。 5.7.2 在设计验证完成评审（FDR2）时需由核心项目组对 DMR 和中试计划进行评审，并由项目经理批准执行。 5.7.3 设计验证完成评审（FDR2）通过后，由新品转化工程师依据中试计划进行中试的各项工作。 5.7.3.1 新品转化工程师负责实施中试计划，并确保： a) 依据制造工艺可生产出满足要求的产品； b) 采购流程能够交付满足要求的零部件； c) 工装、卡具及测量设备适用于产品生产且产品满足要求； d) 每一台设备形成了 DHR。 5.7.3.2 维修设计工程师负责实施中试计划中安装与维修部分，并确保安装与服务过程： a) 可以依据安装维护手册的描述实现； b) 安装维修工具和设备适用于产品的安装和维修。 5.7.4 中试完成的标志是： a) 中试阶段出现的缺陷已得到审核和分类； b) 出现的重大缺陷、主要缺陷已得到处理、验证和关闭； c) DMR 中发现的问题已进行修改和完善； d) 依据中试计划及 DMR 生产出首台满足要求的设备。 注：安装流程可以在典型的室内模拟环境进行。 5.7.5 设计转换完成后，项目组应依据设计评审管理规定组织召开设计评审（FDR3）。 设计评审的记录做为 DHF 的一部分进行保存。 5.8 设计确认 5.8.1 设计确认是通过提供客观证据证实产品满足用户需求及预期用途的活动。 5.8.2 设计确认活动应在满足临床需求的样机上进行。 设计确认需要在其预期使用的真实环境或者模拟环境下进行，并应当证明： a) 该产品满足用户需求说明书中的要求； b) 使用说明书清晰明了。 5.8.3 测试工程师负责编制设计确认计划，并在设计确认开始前得到系统工程师的审核和项目经理的批准。 设计确认计划中应包含： a) 设计确认活动的目的和范围； b) 产品的预期用途及用户需求，即用户需求说明书中的要求； c) 产品配置及附件，并记录不同配置的差异性； d) 完成设计确认活动所需资源； e) 设计确认方案等。 5.8.4 设计确认方案应包含： a) 需要确认的用户需求或预期用途； b) 所需的试验设备和仪器； c) 确认步骤； d) 每个确认方案的接收准则。 5.8.5 测试工程师依据设计确认计划进行设计确认并保留记录，以下信息需作为证 实材料予以保留： a) 用于设计确认的产品或设备的鉴别码，如序列号、版本等； b) 实施设计确认的方法； c) 相关的设计确认方案； d) 确认人员签署； e) 所使用的试验设备、工具及软件； f)客观结果；g) 结果判定：通过或者不通过； h) 总结。 5.8.6 当国家或其他国家和地区法规要求进行下列临床评价时，按相应的法规进行： a) 临床试验； b) 与所设计和开发的医疗器械相关的科学文献的分析； c) 能证明类似设计在临床上是安全的历史证据。 当需要进行临床评价时，设计确认计划中应包括临床评价计划，临床应用工程师负责临床评价计划的实施。 5.8.7 测试工程师应当汇总设计确认的结果，形成设计确认报告，并得到系统工程师的审核及项目经理的批准，做为 DHF 进行保存。 5.8.8 设计确认完成后，项目组应依据设计评审管理规定组织召开设计评审（FDR3）。 设计评审记录做为 DHF 的一部分进行保存。 5.9 设计评审 5.9.1 设计评审是设计开发过程中在定义的评审点通过对设计开发的可交付成果进行的 系统评审，以便： a) 评价设计和开发的结果满足要求的能力； b) 识别任何问题并提出必要的措施。 5.9.2 综合开发计划中设计评审点应设置如下： a) 完成设计输入及策划时（FDR1）； b) 完成设计验证时（FDR2）； c) 完成设计确认及设计转换时（FDR3）。 5.9.3 设计输入及策划完成评审（FDR1）应评审以下内容： a) 设计输入是否充分和适宜； b) 综合开发计划是否合理可行； c) 关键供方及关键部件是否识别； d) 安全风险评估是否考虑充分。 5.9.4 设计验证完成评审（FDR2）应评审以下内容： a) DMR 是否完整； b) 设计验证是否按验证计划进行； c) 验证结果是否能够证实产品满足设计输入要求； d) 中试计划与设计确认计划是否合理可行； e) 设计输入是否有变更并被评审和考虑； f) 综合开发计划是否更新； g) 发现的缺陷是否得到适当的处理和关闭，采取的措施是否适当； h) 风险降低措施是否有效等。 5.9.5 设计确认及设计转换完成评审（FDR3）应评审以下内容： a) 设计转换是否按计划进行并完成； b) 设计确认是否按计划进行并完成； c) 设计确认的结果是否满足产品的预期用途； d) 综合开发计划是否更新； e) 发现的缺陷是否得到适当的处理和关闭，并更新 DMR； f) 风险降低措施的有效性等。 5.9.6 系统工程师可以依据情况增加需评审的内容。 5.9.7 设计评审活动依据设计开发评审管理规定的要求进行，各评审点的可交付成 果依据评审输入检查表的要求进行准备，评审的记录应当做为 DHF 进行保存。 5.10 阶段评审 5.10.1 阶段评审是为了更好的控制项目开发过程以确保开发的产品符合市场预期，同时 便于跨部门活动的协调。阶段评审通过，标志着项目开发可以进入下一阶段，项目开发周期的三个阶段及各阶段评审点的设置如图 5-1 所示。 5.10.2 立项评审（P0）的目的是： a) 确定市场需求和符合用户及市场需求的产品概念； b) 确定产品定位、优先级； c) 评估项目风险及收益； d) 评估项目所需资源。 5.10.3 策划评审（P1）应评审以下内容： a) 设计输入是否定义明确并被评审； b) 已识别的主要风险是否被规避或已制定降低风险措施； c) 综合开发计划是否满足立项要求。 5.10.4 设计验证完成评审（P2）应评审以下内容： a) 确认设计验证活动已完成，并证明设计输出满足设计输入； b) 确认 DMR 已经完成。 5.10.5 临床启动评审（PE）应评审以下内容： a) 确认临床样机已经完成，并经过测试已符合临床要求； b) 临床所需材料已经完备； 5.10.6 产品发布评审（P3）应评审以下内容： a) 确定设计确认活动已完成； b) 确定设计转换活动已完成； c) 确定市场发布前批量生产能力已具备。 5.10.7 产品发布评审（P3）批准后，代表产品正式上市，可投入市场销售。 5.10.8 阶段评审活动依据设计开发评审管理规定的要求进行，各评审点的可交付成 果依据评审输入检查表的要求进行准备。评审的记录应当做为 DHF 进行保存。 5.11 需求管理 5.11.1 设计输入应在项目开发周期内保持完整性和一致性，并在设计输入及策划评审 （P1）后得到控制。 5.11.2 当设计输入需要变化时，应对提出的需求进行评估后确定是否导入新的需求，评估的方面可包含以下内容： a) 预期用途的变化； b) 产品规格的变化； c) 对已完成的开发阶段的输出的影响； d) 成本变化； e) 开发周期变化； f) 对后续活动的影响程度，等。 基于设计输入的变化，项目经理应组织项目组成员依据评估结果及时更新相关的开发过程文件（不得晚于下一个 FDR 前完成更新）并依据更新后的文件开展后续的项目工作。 5.11.3 新增的设计输入如果影响到预期用途或用户需求应对相关变化重新进行设计确 认，如果影响产品规格性能和功能应对相关变化重新进行设计验证，并依据开发过 程文件管理规定的要求保留相关记录。 5.12 设计更改 5.12.1 产品设计开发过程中，需对已经评审和批准的文件进行修改时，应按该文件的评 审和批准的要求对修改内容进行评审和批准。 5.12.2 设计文件发布后的设计更改控制依据设计更改控制程序进行。 5.13 风险管理 在产品寿命期内，按风险管理控制程序进行风险管理活动，形成的相关记录和 文件作为 DHF 保存。 5.14 开发过程文件（DHF） 5.14.1 每个项目都应建立并保存开发过程文件，开发过程文档需包含以下内容： a) 综合开发计划及更新； b) 用户需求说明书及更新 c) 产品规格说明书及更新； d) 开发过程中的技术文档；设计验证相关文件和记录； e) 中试计划及更新； f) 设计确认相关文件和记录； g) 设计评审记录； h) 风险管理相关文件和记录等。 5.14.2 项目经理应在综合开发计划中制定开发过程文件的编制策略，需对省略、合并和引用的开发过程文档进行说明，并确保其按计划实施及完整性。 5.15 缺陷管理 5.15.1 缺陷管理适用于追溯在产品上市发布前的设计、测试、中试等过程中发现的设计缺陷。一个设计缺陷是指一个存在不可接受临床风险或者是一项不满足设计输入的设计输出。 设计缺陷可能是不满足： a) 用户需求和预期用途； b) 产品规格，即性能参数； c) 可接受的安全风险等级； d) 法律法规的要求。 设计缺陷可能在开发过程中各阶段发现。 5.15.2 项目组成员应将发现的问题和潜在缺陷以问题报告的形式录入 RDM 系统中，并 提交系统工程师进行审核，问题报告中需包含以下信息： a) 问题名称； b) 发现方法； c) 所属项目； d) 严重性； e) 发生概率； f)问题的描述。5.15.3 系统工程师负责审核问题报告并对潜在缺陷进行判断： 如果该问题不影响产品安全、满足预期用途及功能性能要求、符合法律法规要求， 但通过修正该问题可以提高生产效率、改善用户体验、优化产品性能或提高产品定位等， 此类问题为可改进机会，不是设计缺陷。 如果是设计缺陷，需指定责任人进行关闭，并判断所属缺陷类别： a) 当设计缺陷导致 预期用途未得到满足时； 发生涉及人身安全的风险时； 系统崩溃或无法联动时； 不满足法律法规的要求时； 判定为主要缺陷； b) 当设计缺陷导致某一功能模块无法正常工作或只能在特定条件下进行运行时， 判定为一般缺陷。 5.15.4 责任人需要对设计缺陷进行根本原因分析，并制定关闭措施，必要时可组织相关 人员进行评审，并保留评审记录。 5.15.5 责任人依据关闭措施完善设计，并提交验证，测试工程师依据缺陷描述进行验证， 并保留验证记录和报告，同时对 RDM 系统中的设计缺陷进行关闭。 5.15.6 设计验证阶段结束时， a) 所有的设计缺陷得到了审核和分类； b) 所有设计缺陷得到解决，并得到验证和关闭。 6 支持性文件 风险管理控制程序（xx） 设计更改控制程序（XX） 设计文件管理规定（XX） 设计验证管理规定（XX） 设计开发评审管理规定（XX） 开发过程文件管理规定（XX） 设计输入管理规定（XX） 综合开发计划编制规定（XX） 7 质量记录 用户需求说明书（XX） 产品规格说明书（XX） 综合开发计划（XX） 设计确认计划（XX） 设计确认报告（XX） 设计验证计划（XX） 设计验证报告（XX） 评审输入检查表（XX） 人生就像一部书，每个人都在书写着自己的故事，书写着生命中曾承载的苦辣酸甜和正在经历的风霜雪雨。不管这部书的情节精彩也好，简约也罢，我们都必须字斟句酌，用心构思。只有这样，认真写好人生的每一个章节，才能把握生命的主旋律。人生也像一条河，有谁不是在风里行舟，雨中穿梭。昨天还在逆浪而行，今朝依然奔奔波波。尽管如此，我们也不应气馁，更不敢稍有停歇。只有这样，才能穿越人生的风浪，踏平生命的坎坷，从而抵达理想的彼岸，收获人生累累硕果。人生还像一盘棋，我们每个人俨如上帝手中的一枚棋子，贫富贵贱难预料，生老病死不由己。楚河汉界今犹在，谁见君王卷土来？是啊！人生苦短，岁月蹉跎。在不老的时光里，我们每个人充其量不过是一个匆匆的过客。当你走过半生，蓦然首，你会发觉：转眼间，我们便告别了葱茏的年华，跨过了中年的门槛，走进了枫红菊艳的时节。有道是，流光容易把人抛，红了樱桃，绿了芭蕉。岁月如梭，不经意间便穿越半生沧桑。回首往事，多少情怀已经更改，多少青春早已不再，多少梦想恍如云烟，多少足迹已湮入尘埃。实乃，人生得失如萍散，雪落花开辞红颜。三毛说：“我来不及认真地年轻，待明白过来时，只能选择认真地老去。”昨天已经落幕，明天无法彩排，唯有今天才是人生的最好舞台。轻捻指尖流年，细数过往云烟。曾经的莽撞少年，总以为伸手就能够着天，凡理都要辩出个曲和直，凡事都要弄出个里和面。人过中年，我们才恍然顿悟：不和别人比，好好活自己，这才是后半场人生棋盘最好的布局。好好活自己，就要力求“身心两安逸”.老了不可怕，就怕放不下。人过中年，身体机能不断下降，就像一部半新不旧的机器，各个零部件都已濒临保养期，如果不及时加以检修，等到停止工作那一天，悔之晚矣。凡事不攀比，保命是正理，浮云随风去，任尔东与西。身体健康是前提，心情快乐才安逸。服老不并非消及，而是保护自己。山有山的伟岸，水有水的柔情，每个人的生活模式千差万别，就像世界上没有一模一样的两片叶子，你有你的脉络，我有我的纹理。寸有所长，尺有所短，每个人都不是完美无缺的个体，你有你的色彩，我有我的艳丽；你羡慕别人的同时，别人也许正在羡慕你。就像卞之琳所说的那样，你站在桥上看风景，看风景的人在楼上看你。明月装饰了你的窗子，你装饰了别人的梦。我们每个人何尝不是一道独一无二的风景线，只是缺乏一双欣赏的眼光而已。好好活自己，就要力求“退而求其次”.后半生，我们没有多余的精力去开拓一个未知的领域。所谓的“大不了从头再来”,那只不过是年轻人的豪言壮语。人生后半场，上帝给予我们的时间和精力是有限的，适时地放手才是最好的选择。退而求其次，看似是一种“无奈”,却也是一种豁达的智慧。它并非真正意义上的“退化”,而是为生命“留白”,为自己留下一点周旋的余地。老子曾言，“虚而不屈动而愈出，多言数穷不如守中。”事多必乱，言多必失，只有保留一定的“空”,才能其用无穷。正所谓，月满则亏，水满则溢。有时退一步海阔天空，进一步山重水复。留白，也是一种取舍，只有“丢卒保车”,才能满盘皆活。古人说：“路漫漫其修远兮，吾将上下而求索。”可见，“求索”原本就分“上”“下”.当你的“上策”无法策马扬鞭时，你必须要退避三舍求“下策”,谋定而后动，知止而有得。叶公好龙，玩假把式；夜郎自大，唯我独尊，只能是自讨苦吃。好好活自己，就要力求营造一个“小天地”.人生需自渡，这个世界上从来就没有救世主。自己的人生，黯淡与精彩完全由自己去书写，去掌舵，去布局。红尘如梦，亦真亦幻；人生如戏，亦悲亦喜。当曲终人散时，不过是乐者自乐，歌者自歌；伤者自伤，痛者自痛。人生就像一部书，每个人都在书写着自己的故事，书写着生命中曾承载的苦辣酸甜和正在经历的风霜雪雨。不管这部书的情节精彩也好，简约也罢，我们都必须字斟句酌，用心构思。只有这样，认真写好人生的每一个章节，才能把握生命的主旋律。人生也像一条河，有谁不是在风里行舟，雨中穿梭。昨天还在逆浪而行，今朝依然奔奔波波。尽管如此，我们也不应气馁，更不敢稍有停歇。只有这样，才能穿越人生的风浪，踏平生命的坎坷，从而抵达理想的彼