嵌入式项目管理

嵌入式系统开发项目管理
项目生命周期五大阶段
1、项目启动阶段
(1)项目可行性分析
一个成功的产品，应该从以下3个方面来观察评估：

设计产品：商业行为

产品设计前，要做好市场调查和评估，要考虑产品的时效性、市场需求和技术可行性；

产品设计结束后要写下详细的产品规格(技术层次、人力资源、开发费用、产品成本)

尽量避免中途更改产品规格；

凡事以最终用户需求或体验为准。

管理项目：管理行为

项目经理必须清楚了解其任务事在规定的期限内完成质量可接受的产品开发，在此前提下必须衡量人力及其它相关资源，只做该做的事，能够因时制宜。
开发系统：技术行为

不要追求完美，只需达到在规定的时限，有限的资源条件下，设计开发出“足够好”的满足需求的产品就好。

设计工作一定要确实执行，绝对要文件化。不能为了敢进度而跳过设计直接进行程序编写。

需求管理者确定 ——> 需求分析&Review ——> 项目规模估算 ——> 项目风险分析 ——> 初步项目执行计划&Review

(2)项目授权书
明确说明项目目标与管理方向

明确对授权PM

任何与项目有关的信息

(3)理清必要的约束
确认产品规格(成本/性能/质量/。。。需求)

确认产品限制

初步确认将参与项目的公司与单位

确认开发模式(S/W Development Life Cycle)

Waterfall Model

Prototype Model(初期需求不明确)

Spiral Model(Waterfall + Prototype的多次迭代)

。。。

2、项目规划阶段
初期规划：是否该接这个项目？

没规划，一定挂！在确定接项目前，一定要做过极为仔细的分析。

完成不可能的任务！因为客户交付的项目肯定不会太简单。

(1)Scope/Time/Cost/Quality Plan

(2)Resource/Communication Plan

(3)Risk Plan

(4)Configuration Plan

(1)项目范围(Scope)管理
妥协的艺术：进度 VS 规格

质能守衡原则，如果客户一再压缩进度，那只能降低规格；若客户一再变更规格，那只能delay进度。

当项目启动后，首先就是要花时间做好项目的范围管理(哪些该做，哪些不该做)，唯有定义出正确的范围，之后做的进度、成本和人力计划才是有意义的。

项目管理工具——Work Breakdown Structure,WBS和变更管理

WBS

工作分解，其它项目计划最重要的依据

分解的标准：

按“功能组成”分解

按“项目生命周期”分解

按照“系统架构”分解

WBS的最小分解单元(Work Package)要非常具体，至少拆分到一周或40HRs的工作量。

表述方式(树状图+列表)

image-20201110210209743
变更管理

所有的变更一定要经过CCB(Change Control Board，变更管理委员会，即与此变更有关的关系人参与决策的会谈)的同意，并造出新的计划书，严禁接受客户私下变更规格的请托。

image-20201110211121028
(2)项目进度(Time/Schedule)管理
时间与其他资源特性不同，它具有单向性、不可重复性、不可替代性。

规划“进度计划”：

从WBS中取得所有的最小活动单元(树状图中的叶节点leaf)

确认各任务间的关系(持续时间、次序关系)

FS(Finish to Start)：任务A结束后，任务B才可以开始；

FF(Finish to Finish)：任务A结束后，任务B才可以结束；

SF(Start to Finish)：任务A结束后，任务B才可以结束；

SS(Start to Start)：任务A开始后，任务B才可以开始；

进度管理图表(Gantt图+网络图)

甘特图描述各任务的起讫时间，也可用来执行“进度追踪”；

网络图描述各任务间的先后关系(节点代表任务，箭头指示任务次序，箭头边的数字代表所需时间)，用来找到关键路径CPM(图中用时最长的路径)，唯有缩短关键路径上任务的时间，才能缩短整个项目的周期。

管理预留

为整个项目预留时间(一般是整个项目周期的10-15%)，不到不得已，不要拿出来用。

根据帕金森定律，不论你给员工多少时间，他总倾向于用完分配给他的时间。

需知道的原则

进度计划是用来遵守而不是修改的。当延迟发生时，PM和主管应该积极设法解决问题并设法赶上进度，而不是修改进度。

规划进度表时，应该由粗到细，协调并整合各单位的意见，切记闭门造车。

进度与成本呈反比。

WBS分解的好坏直接影响项目进度计划

执行时期必须不断检查项目计划与实际进度是否存在偏差，并及时追踪和处理。

(3)项目成本(Cost)管理
软件系统的项目成本预估永远不会很精确，只能依靠经验或业界共识来提高精度。

项目是商业行为，开发出一件不赚钱的产品不如不开发。一切要为成本让步。

成本的几个主要来源：

管理成本

硬件/结构设计成本

生产&材料成本

软件开发成本(代码行、函数点、人月。。。)

COCOMO模型估算成本

image-20201110225129815
成本估算误差来源：

基础数据不足，项目仍存在许多不定因素

项目成本对需求敏感

经验不足或低劣的成本估算技术

签约前后不连贯

只有等WBS做出来后，且工作被分割的越细，估算才能最接近实际。但往往实际工作做不可能等你做完WBS才报价。推荐《人月神话：软件项目管理之道》。在嵌入式软件项目中人力成本是总成本最主要的部分；

挣值管理

主要用于项目成本和进度的监控，它将目前为止所完成的工作与项目计划里的估计值比较，以提供关于项目距离完成还有多远的估量，PM可以得到距离项目完成还需花费多少资源。

(4)项目质量(Quality)管理
基本思想

质量是规划出来的，而不是检查出来的，预防重于治疗，要在规划阶段就做好“质量计划”，并明文公布；可以先粗线条定下baseline，再制定细则。

项目质量是所有开发人员工作质量之积；

质量管理并非一次性活动，而是贯穿整项目生命周期；

质量等级是相对的，以客户需求和价格而定；

质量管理是一种精神，并非通过ISO9000或CMM就能做出有质量的产品。

质量管理系统：ISO9000或CMMI

CMM的5级管理体系
QA(Quality Assurance)

专注在流程的正确性上，是一种管理职能。QA的主要目的就是确保产品在既定进度与预算下，能达成预期质量水平与可靠度目标。QA的工具就是稽核(Audit)，从计划拟定、模块设计、Code Review、测试计划、生产流程、备料计划等各阶段都要进行稽核。规划阶段的工作产品是制定质量规划书，明确项目采用的质量标准，确定如何满足该标准的要求。特别是：

完成了某个里程碑

提出了变更要求

项目即将进入下阶段时

QC(Quality Control)

专注在流程bug的查找和追踪上，是一种检查职能。QC必须确定项目结果与质量标准是否相符，同时查找不符的原因(bug)和跟踪是否妥善解决(每个bug的处理流程都必须记录下来)。规划阶段的工作产品是制定测试计划。

质量规划流程图
(5)项目人力资源(Human Resource)管理
人员的组织管理是否得当，是影响软件项目的决定性因素。

MS有一个明确的规则——项目组的人员不要超过10人。

组织结构：

职能型组织(组织与项目利益可能冲突)

项目型组织(资源重复，无法贯彻公司策略)

矩阵型组织(职能或部门经理与项目经理的冲突)

强矩阵组织

矩阵式组织图
团队管理

创建由实际存在感的项目团队

建立奖励机制

确立良好的人际关系

设定工作授权系统

激励理论：因才适所、投其所好

(6)项目沟通(Communication)管理
管理中70%的错误是因为不善于沟通造成的，PM 80%以上的时间是用在沟通上。

沟通计划：

沟通需求：哪些人、哪些时候、需要哪些需求？

沟通内容：沟通的格式、内容、详细程度等

沟通方法：明确沟通方式与沟通管道(会议、bug管理软件、工作报告)

沟通职责：谁发送消息，谁接收消息

沟通安排：在项目计划中必须包含重要沟通事件的Schedule。(例如review meeting)

沟通渠道计算：若项目中有N个人，那么需要建立N(N-1)/2条沟通渠道，相当于沟通成本就很高。

(7)项目风险(Risk)管理
Risk三要素：

是某个事件

有发生的概率

会对项目造成一定的影响

风险管理最容易被忽略也是最难以管理的

风险管理流程(循环往复)：

风险识别：列出风险列表

项目缺乏可见度

新技术的吸引力

技术兼容性风险

性能风险：增加执行设计阶段的力度、制作原型(Prototype)等

仓促上线风险

可用性问题

缺料、零件涨价

合约风险：同法务详细检查合约内容

需求变更风险：提前以书面形式约定好变更处理流程

沟通不良风险：项目沟通计划制定与公布

缺乏高层支持风险

进度风险：若Schedule无法调整，则尽量多获取资源与预算，或者分阶段交付产品。

质量风险：慎重制定项目质量策略，成立质控小组。

团队成员能力风险：提前培训或变更成员。

团队合作风险：目标明确，绩效制度公平。

人员流动风险：核心工作分派给多人执行。

协助厂商风险：合作前即制定审核稽核与验收流程。

风险评估

定性分析

列出概率/严重性矩阵

对项目的薄弱环节有一定的了解

定量分析：基于定性分析成果的数学处理与表达

列出风险排行榜(概率 X 严重性)

风险规划(处理)

回避风险：主动放弃或拒绝使用导致风险的方案，寻找替代方案

转移风险：将风险转移给外包公司

损失控制：减缓风险发生时的危害程度

承担风险：对发生概率低或影响小的风险，可选择先不处理

风险控制

(8)项目采购/合约管理
软件外包：实际比自身开发的净投资多15%至20%

外包项目的管理比自己开发更复杂：

技术难度

沟通复杂度

外包成本

外包项目注意事项：

沟通问题

做好详细计划

避免延误

明确验收标准(软件规格与API。。。)

(9)项目配置(Configuration)管理
贯彻开发的全过程，目的是用于建立和维护产品的完整性和可追溯性

对应软件开发项目中成熟的版本控制流程

软件配置管理——简单说就是项目资产管理，对开发过程中的产品进行标识、追踪、控制的过程，包括：

项目的全貌，包含产品规格与设计规格。

项目原始的计划，以及项目运行期间所有曾做过的变更。

设计阶段的任何重大转折点、与项目运行期间技术上的重大突破。

软件开发期间曾遇到哪些问题，解决的方式是什么？对应的程序代码是什么？

重要软件版本或项目里程碑所代表的意义，以及该事件点项目状况的快照

硬件设计与生产阶段的问题履历即解决方式。

3、项目执行/控制阶段
软件工程与项目管理如何配合执行？

image-20201114130434239

image-20201114130549788
软件工程包含三个循环过程：

开发过程定义：包含软件需求、软件开发过程、软件配置管理SCM

软件开发：包含软件设计、软件构建、测试、维护和更新

软件质量保证：软件质量

项目管理过程包含三个循环过程：

项目规划

项目实施

项目监控

(1)产品规格设计
产品规格写完，最后必须再让客户确认一次并签字！以后所有设计工作必须以此为模板。一旦客户要将新的需求变成“规格”，必须改动已通过审查的正式文件，而这要经过质量管理体系的同意。

一般来说产品规格包含以下方面：

硬件规格简介

产品设计理念、限制与应用范围

使用者功能说明书

操作流程图

使用者界面与美工图案

性能规定

特殊注意事项

(2)硬件设计
硬件设计阶段的工作如下，除了外观与结构设计外，固件工程师应尽量参与：

CPU选择

主要芯片选择

电路设计

Layout

零件、物料管理

产品外形设计

结构设计

开模前的模型制作

在此阶段输出的文件有：

硬件设计规格书

BOM表

3D外观图

结构图

原理图

Layout图

(3)系统设计
根据项目大小或硬件环境，选择合适的设计方法。如果是CPU主频仅有几十M，且内存又很小，建议选择结构化方法设计，并选择C语言进行开发。如果项目较大，CPU主频几百M，且存储资源丰富，则选择面向对象方法，语言上可选择C++或Java语言。

(4)测试计划设计
软件测试也有标准，IEEE 829详细描述了测试计划书的规定与注意事项，但实际情况是，要按照项目本身特点，传承该标准的思想和精神。在测试前，需要着重了解较复杂的功能、新功能、客户特殊的要求或规格书中描述较模糊的地带，然后才设计测试个案testing case和计划。

(5)风险评估
最普遍的风险有以下几个：

进度拖延

需求膨胀

人员流失

规格崩溃

绩效低落

技术落差

文化差异

软硬件整合

生产制造问题

风险识别流程：

风险识别流程图
面对风险的4种处理方法：

回避：不去碰触会产生风险的部分

抑制：准备足够的时间与金钱，在风险成型时砸下去

舒缓：在风险成型前，就先采取某些措施

逃避：什么都不做，祈求老天保佑

(6)动手编码前先写设计文件
从项目开始就应该准备一个服务器存放并管理项目的所有文件，并让所有项目成员都可以很容易取得所需的文件或记录。

应该被记录的文件包含:

产品规格

schedule

硬件设计相关文件(CPU PIN脚配置图、原理图、Layout图等)

技术文件-芯片的datasheet、3rd party软件函式库的API等

系统架构设计规格书(包含各模块API)

测试计划书

测试报告及bug sheets

质量文件

重要会议记录

重要邮件备份

其它需要记录的文档

(7)设计审查(design review)
设计审查的原则：

设计审查必须师渐进式的。且要贯穿设计的全过程

设计审查时要邀请该设计的客户参加

越是大范围的设计，越要召集所有项目人员参加。

(8)实作阶段
当所有设计文件都通过审查后，就可以进入实作阶段了。其包含以下内容：

程序开发与调试

硬件(电子、结构)开发

软件与硬件测试

质量相同执行

工厂试产

项目的每一个阶段都应该根据PDCA(Plan、Do、Chick、Act)循环。当在程序编写时发现设计有问题，切不可自行修改，必须暂时局部停下实作的脚步，找出对策，确认影响范围，通过相关单位的设计审查后，才可以再继续实作。也即就是“设计变更”流程

嵌入式相同开发的成果最终要产品化，所以不可避免要和工厂打交道。

软件工程师必须交付给工厂的项目有：

用来烧录的Binary File

生产线专用自动测试程序与说明书

环境测试专用的测试程序

硬件、电子工程师必须交付给工厂的项目为：

电子电路

电气工程规格

特殊规格测试说明(工厂之前没生产过的功能)

结构工程师必须交付给工厂的项目为：

组合图(把所有零件一一展开)

特殊部品外形图

特殊加工组合图

4、项目结项阶段
(1)对外合约结项
(2)对内项目结项
项目资料归档

技术数据归档

记录经验，累计企业的项目资产

close meeting，人员解散

在项目执行期间，制定流程，并使用自动化工具，将项目开发的轨迹(包含程序、文件、bug管理、issue管理、变更管理等)记录下来，并定期备份。

明确规定执行项目结项流程的起讫时间，最好不超过一周，并于项目成员的部门主管以及现任的项目经理沟通与协调，请这些同事们在某段时间内帮这个项目最后的忙。

转载：嵌入式系统开发项目管理_Leon的博客-CSDN博客