产品生命周期流程图

绿色制造机械产品生命周期评价细则1 范围本标准规定了机械产品生命周期评价（LCA）的评价阶段及流程、目的和范围确定、清单分析、生命周期影响评、生命周期解释、报告与鉴定性评审。

本标准适用于评价机械产品生命周期或指定阶段潜在的环境影响。

2 规范性引用文件下列文件对于本文件的应用是必不可少的。

凡是注日期的引用文件，仅注日期的版本适用于本文件。

凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T 24040-2008 环境管理生命周期评价原则与框架GB/T 24044-2008 环境管理生命周期评价要求与指南GB/T 26119-2010 绿色制造机械产品生命周期评价总则3 术语和定义GB/T 24040-2008、GB/T 24044-2008和GB/T 26119-2010界定的术语和定义适用于本文件。

4 评价阶段及流程机械产品生命周期评价分为目的和范围的确定、清单分析、影响评价和解释4个阶段，各个阶段的主要内容及流程见图1。

图1 机械产品LCA流程框图（见GB/T 26119-2010 图1）5 目的和范围确定5.1 评价目的开展机械产品生命周期评价，首先应明确评价的目的。

评价目的包括评价的应用意图、进行该项评价的理由、评价结果的沟通对象以及是否用于向公众发布的对比论断等信息。

评价目的与范围确定示例参见附录A。

通常进行机械产品生命周期评价的目的主要有（但不限于）：a)用于产品的环境性能改善——可利用简化的生命周期评价方法或生命周期评价的部分阶段，对机械产品概念设计中的关键功能部件和（或）单元过程进行评价，预估设计方案的环境影响程度；——借鉴相近产品的清单分析数据、影响评价结果等信息，评估机械产品详细设计方案的环境影响，帮助设计方案的选择和优化；——识别机械产品不同制造工艺间的环境影响情况，进行制造工艺的选择和优化；——识别机械产品在环境协调性方面存在的问题，判别对其进行改善的可能性与潜力。

软件生命周期模型描述文档编号：FHI_CMMI_OPD_PRD_SLCM文档信息：软件生命周期模型描述文档名称：软件生命周期模型描述文档类别：CMMI规程密级：内部秘密版本信息：1.2建立日期：2016-1-8创建人：EPG批准人：李庆林批准日期：2016.2.25存放位置：集成公司组织资产库/组织标准过程编辑软件：MicrosoftOffice2003中文版文档修订记录*变化状态：C――U建，A――增加，M――修改，D――删除目录1简介4...1.1目的4...1.2适用范围4...1.3术语表4...2过程概述4...3生命周期模型描述5...3.1V字模型5...3.1.1概述5...3.1.2阶段定义5...3.1.3适用情况6...3.1.4优点7...3.1.5缺点7...3.1.6本企业适合项目类型7..3.2中等简化V字模型7..3.2.1概述7...3.2.2阶段定义8...3.2.3适用情况8...3.2.4优点8...3.2.5缺点9...3.2.6本企业适合项目类型9..本文描述组织级定义的软件生命周期模型，供项目策划时根据项目的具体情况选择或裁剪使用，由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。

但是“所有的模型都是错误，有些模型是有用的”。

模型是对它们所代表的真实世界的简化，这种简化更多的是为了规范管理的需要，它只能够照顾大多数。

如果它不适合你的项目或者有更能真实表达现实世界的模型出现，因为涉及到组织管理方式的变化，任何模型的修改或新模型的加入都需要通过组织的审批。

1简介软件生命周期由制定计划、需求开发、设计、编码、测试、维护等各项活动组成，而如何将这些活动合理、有效地衔接组织起来，就需要在软件项目策划阶段选择合适的软件生命周期模型。

正如每个项目的目的是唯一的，每个项目的软件生命周期模型也将是唯一的，定义软件生命周期是项目计划的一个重要步骤，它将直接影响到WBS及软件开发计划的制定。

产品经理简称PM，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。

产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。

产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。

近年来互联网产品经理火热，一起看下为大家精选的互联网产品经理学习文章。

上次介绍了《用例图这样画，3步让你做需求分析有理有据》，这次聊聊活动图。

也许你对活动图并不了解，不过，说起流程图，想必你不会陌生。

你可以暂且把活动图，看成UML 中的流程图。

都知道，做产品要分析流程，可怎么把流程理清楚呢？当然不能凭空想象，而应该借助分析工具。

每当遇到复杂多变的业务，面对冗长的流程，我总会拿出需求分析工具箱，从中挑选合适的工具。

用得最多的，非活动图莫属。

01 认识活动图之前在《做产品为什么要画这些图？》谈到，UML 将视图分为静态视图和动态视图。

静态视图，描述产品的结构特征，即产品由什么组成的、能做什么、长什么样。

例如，手机由屏幕、外壳、摄像头、电池、芯片等组成，能用来打电话、上网。

动态视图，描述产品的行为特征，即产品是怎样运行，或如何使用。

例如，我们要解锁打开手机，得做输入密码，或识别指纹、人脸等操作。

活动图，是常用的动态视图之一，用来描述产品中具体对象，在具体场景下，如何使用产品，或参与实现目标的过程。

所谓对象，是指与产品相关的人或事物，如用户、运营人员、APP、后台系统等。

换句话说，活动图描述的是，谁在什么情况下，如何做特定的事情。

画活动图是为了分析流程，借助可视化的工具，描绘现实世界中具体事情的运转过程（常说的业务分析），输出既方便人们理解，又便于计算机开发实现的内容。

同样用于流程分析，流程图与活动图有啥区别呢？流程图历史更悠久，使用范围更广，业务人员容易理解。

不过，或许是年代久远，而且画图元素较多，它的画图规范，要么被忽视，要么说法不一，想画出一个标准的流程图，也不容易。

华为IPD流程简介-谈流程与个⼈发展IPD：（Integrated Product Development），即集成产品开发,通过对产品开发中各种最佳实践进⾏集成，实现对产品开发⼯作有效管理的理念和⽅法。

它的思想来源于美国PRTM(美国咨询管理公司)公司最先于1986年提出的基于产品及⽣命周期优化法（PACE： PACE：Product And Cycle-time Excellence），IBM公司吸收了PACE的很多精华，最终形成了⼀套IMB关于产品开发的⽅法论体系，就是著名的IPD。

华为公司在1999年引⼊IPD流程，并结合⾃⾝发展和业界实践持续优化，最终形成了华为特⾊的IPD流程和管理体系，华为先进的管理理念不仅⽀撑了华为的⾼速发展，也受到业界的追捧，下图是IPD流程的总体图。

IPD流程图IDP流程整体包含六个阶段和两条决策主线，下⾯分别介绍下涉及的基本概念。

1、IPD各阶段说明概念阶段：想做什么，策略是否可⾏。

计划阶段：怎么做？需要什么资源，怎么才能保证按照计划交付。

开发阶段：做产品或软件。

验证阶段：⼩批量发货进⾏市场验证。

发布阶段：产品⼤批量上市，主要是营销、制造、售后等活动。

⽣命周期阶段：监控销售、⽣产、服务的商业表现，包括友商竞争情况和客户满意度，并采取相应的措施，使产品包在⽣命周期阶段的利润和客户满意度达到最佳状态。

2、IPD业务线决策评审点(DCP, Decision Check Point)业务决策评审点主要进⾏投资决策，是否有投资价值，主要的决策点如下：Charter：成⽴项⽬，Charter通过说明项⽬成⽴。

CDCP（Concept DCP）：概念决策评审点，想做什么已经明确，策略已经制定。

PDCP（Plan DCP）：计划决策评审点，各领域计划制定和对齐，⽣产、销售、发布计划已经确定。

EDCP（Early DCP）：早期发货决策评审点，产品达到质量要求，可以⼩批量发货。

生命周期模型选择指南生命周期模型选择指南目录1.目的 (1)2.范围 (1)3.项目生命周期 (1)3.1.瀑布模型 (3)3.1.1.V字模型 (4)3.1.2.中等简化V字模型 (6)3.1.3.最简化V字模型 (7)3.2.原型模型 (9)3.3.螺旋模型 (10)3.4.增量模型 (12)3.5.迭代模型 (13)1.目的1）根据项目类型和实际情况，从公司认可的生命周期模型选择合适的生命周期模型；2）根据所选择的生命周期模型，裁剪和细化标准过程，使裁剪后的过程符合项目的特点和实际情况。

2.范围本文件适用于公司所有类型的项目。

3.项目生命周期生命周期模型是从项目需求定义直至经使用后废弃为止，跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。

生命周期模型一般分为：瀑布模型、原型模型、迭代模型、增量模型。

软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。

目前软件开发实践中使用的各种生命周期模型，都是下面各阶段的不同排列与组合。

∙系统需求∙需求分析∙设计（概要设计和详细设计）∙编码实现∙测试∙使用与维护各阶段主要工作、应完成的文档、质量控制手段见下表。

该生命周期模型适合于所有项目。

一个完整的开发类项目生命周期一般分为：需求分析、设计、编码、测试、发布、实施以及运行维护阶段。

3.1.瀑布模型1)特点●阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的输入。

对本阶段工作进行评审，若得到确认，则继续下阶段工作，否则返回前一阶段，甚至更前阶段。

只有前一阶段输出正确，后一阶段才能正确；●推迟实现的观点：在编码之前，设置了需求分析与设计的各个阶段，分析与设计阶段的根本任务规定在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现；●质量保证的观点是每个阶段都坚持两个做法：规定文档，没有文档就没有完成该段任务；每个阶段结束前都要对完成的文档进行评审，以便尽早发现问题，改正错误。