键盘的诱惑一直是所有太多嵌入式开发的失败。编写代码很有趣。很好 我们觉得我们正在该项目上取得进展。我们的老板通常不擅长构建固件的细微差别,他们赞成批准,微笑着,因为我们显然正在做有价值的事情。
作为从事基于汇编语言的系统的年轻开发人员,我学会了期待很长时间的调试会议。编写一些代码,然后花几个月的时间使它起作用。调试是艰苦的工作,因此我学会了预算50%的项目时间来解决问题。
多年后,在制造和销售仿真器的过程中,我几乎在与我合作的每个公司中都不断看到这种模式。实际上,这种构建固件的方法是工具公司的天赐之物,这些公司都因开发人员的不良做法以及由此产生的大量错误而兴旺发达。如果没有错误,调试器供应商就会兜售铅笔。
在我自己的第一个功能失调的开发项目完成四分之一世纪之后,在我向嵌入式开发工程师讲课的旅途中,我发现这种模式仍然保持不变。急于编写代码淹没了所有常识。
过度使用的“过程”一词(注意仅使用了过度的词;在固件界却被忽略了)本身已经引起了足够的关注,以至于一些嵌入式开发工程师声称已经合理化了一种合理的方式来创建软件。然而,在严谨的质疑下,这些人中的大多数人承认以偶然的方式适用其规则。
当压力变大时(最需要紧贴系统的时候),大多数人会屈从于放弃系统并只编写代码的诱惑。
任何愚蠢的人都可以编写代码
在对程序员工作效率的研究中,汤姆·德马可(Tom DeMarco)和提姆·李斯特(Tim Lister)(《Peopleware》的作者)发现,在所有方面都是平等的,只有6个月经验的程序员的表现通常与一年,十年,或者更多。
随着我们开发人员年龄的增长,我们会获得更多的经验,但通常都是相同的经验,一次又一次地重复。随着我们事业的发展,我们以不断增长的智慧和效率来证明我们不断提高的薪水是合理的。然而,数据表明,经验的价值是神话。
除非我们准备寻找新的更好的固件创建方法,并且在我们实施这些改进的方法之前,我们只比住在Jolt和Twinkies时令人惊讶的野生目瞪口呆的十几岁宗师高出一个台阶大量的代码。
任何白痴都可以创建代码;专业人员找到了在预算内按时一致地创建高质量软件的方法。
固件是宇宙中最昂贵的东西
洛克希德·马丁公司前首席执行官诺曼·奥古斯丁(Norman Augustine)讲述了一个有关国防界遇到的问题的生动故事。高性能战斗机是需求冲突的微妙平衡:燃油范围与性能,速度与重量。
看来到1970年代后期,战斗机的重量已经达到了以往的水平。总是追求更大利润的承包商,徒劳地寻找可以增加很多成本的东西,但是却无济于事。
答案:固件。无限成本,零质量。航空电子设备现在占战斗机成本的40%以上。
二十年后,除了固件价格更加昂贵之外,没有任何改变。
固件成本是多少?
贝尔实验室发现,要实现每1000行代码1-2个缺陷,他们每月会产生150-300行。根据薪水和开销,这相当于每行代码约25至50美元的成本。
尽管有很多不公平的负面报道,IBM的航天飞机控制软件还是非常无错误的,并且可能代表有史以来最好的固件。成本?每条语句1000美元,每10,000行不超过一个缺陷。
对嵌入式系统的研究很少。在索要固件的每行成本后,我通常会遇到空白,然后数字低得离谱。“我想每条线2美元”很常见。但是,还有其他几个问题(有多少人?从成立到发货需要多长时间?)揭示的数字要高出一个数量级。
轶事证据(针对现实情况进行了粗略的调整)表明,如果您认为自己的代码成本为每行5美元,则说明您在撒谎,或者代码很垃圾。每行$ 100,您正在编写的软件几乎都符合DOD标准。大多数嵌入式项目的价格介于20-40美元/线之间。
那里有一些大师总是能产生比这便宜得多的质量代码,但是它们处于钟形曲线的1%渐近线上。
如果您认为自己属于该选择组(我们都愿意),则可以收集一两年的数据。然后,测量从开始到完成(已修复所有错误)在项目上花费的时间,然后除以程序的大小。
应用您已加载的薪水数字(通常是薪水存根上数字的两倍)。
您会感到惊讶。
只要免费,质量就很好刚刚描述的成本数据与质量水平相关。由于很少有嵌入式人员可以测量错误率,因此几乎不可能将质量度量添加到轶事成本中。但是质量确实有代价。
如果没有定义质量,我们就无法谈论质量。我们的直觉认为无错误的程序是高质量的程序,这是完全错误的。除非您使用Netscape“免费赠送并批量生产”模型,否则我们编写固件的原因仅在于:利润。没有利润,工程预算就会减少。没有利润,业务最终将失败,我们正在寻找工作。
快乐的客户为成功的产品和业务做出了贡献。客户对我们产品的满意是最终且唯一重要的质量衡量标准。
因此:产品的质量恰好是客户所说的。
明显的软件错误肯定意味着质量很差。糟糕的用户界面等同于质量差。如果产品不能完全满足买方的需求,则表明产品存在缺陷。
无论我们的代码是易碎的还是市场承诺过高的,还是产品的规格没有达到要求,都无关紧要。由于质量问题,公司面临风险,因此我们都必须采取措施解决问题。
无过错离婚和无过错保险承认跨千年人寿的严峻现实。我们还需要一种无懈可击的质量管理方法,以认识到无论问题来自何处,我们都必须采取措施纠正缺陷并取悦客户。
这意味着,在交付新要求的一周前进行营销时,工程学的成熟回应就不会让人觉得s昧。也许只是营销有道理。我们会犯错误(并在调试工具上投入大量资金来修复错误)。市场营销和销售也是如此。
将对提议的变更更改为诅咒的评估。质量不是免费的。如果产品不能满足设计要求,或者直到发货一周前这些事实才变得显而易见,那么让市场和其他部门知道对成本和进度的影响。
就像Dilbert漫画一样有趣,它通过加强工程师与公司其他成员之间的敌对关系,对工程界造成了可怕的伤害。
我们需要的最后一件事是更多的对抗,犬儒主义和部门之间缺乏合作。我们的使命是:让客户满意!这是不断提高我们的认股权,奖金和工作保障的唯一方法。
不幸的是,迪尔伯特确实描绘了太多公司,但都太准确了。如果您的服装始终需要英雄,如果部门之间没有(礼貌的)沟通,那么事情就坏了。修复它或离开。
CMMI
很少有人会否认固件是一个灾难地区,劣质产品进入市场的时间太晚,而且预算超支。不要屈服于现状。作为工程师,我们有报酬解决问题。没有比发现或发明更快,更好的代码创建方法更大的问题,没有任何问题更重要。
该软件工程研究所的能力成熟度模型集成(CMMI)定义了软件成熟度的五个级别,并概述了计划规模拉升到更高的,更有效的水平:
1.首字母缩写: 特设和混乱。很少定义流程,而成功与否更多地取决于个人的英勇努力,而不是遵循流程和使用协同团队的努力。
2.可重复: 直观。建立了基本的项目管理流程来跟踪成本,进度和功能。计划和管理新产品是基于类似项目的经验。
3.定义: 标准且一致。对管理和工程流程进行记录,标准化,并集成到组织的标准软件流程中。所有项目都使用组织的标准软件流程的经过批准的定制版本来开发软件。
4.托管: 可预测。详细的软件过程和产品质量指标为定量评估奠定了基础。可以将过程性能的有意义的变化与随机噪声区分开,并且可以预测过程和产品质量的趋势。
5.优化: 以持续改进为特征。该组织具有定量反馈系统,可以识别过程中的弱点并主动加以弥补。项目团队分析缺陷以确定其原因;对软件过程进行评估和更新,以防止发生已知类型的缺陷。
(美国空军上尉汤姆·斯科尔希(Tom Schorsch)意识到CMMI只是发展模型真实世界的乐观子集。他发现了CIMM(能力集成不成熟度模型),它从0到_3增加了四个等级:
0.过失:冷漠。未能使成功的开发过程成功。所有问题都被视为技术问题。管理和质量保证活动被认为是软件开发过程中的开销和多余的工作。
1.阻碍:适得其反。施加适得其反的过程。严格定义过程并强调对表单的遵守。仪式仪式比比皆是。集体管理排除了责任的分配。
2.轻蔑: 自大。无视良好的软件工程制度化。在软件开发活动和软件过程改进活动之间完全分裂。完全缺乏培训计划。
3.破坏:破坏。完全忽略自己的章程,自觉抹黑组织的软件过程改进工作。奖励失败和性能不佳。
如果您从事此业务已有一段时间,那么对CMMI的扩展可能太准确了,以至于不有趣
)
CMMI背后的想法是找到一种可预测的方式来制造好的软件。“可预测”和“始终如一”是CMMI的主题。即使功能最失调的团队也偶尔会取得成功,通常每个人都会感到惊讶。关键是要改变我们构建嵌入式系统的方式,以使我们持续取得成功,从而可以可靠地预测代码的特征(期限,错误率,成本等)。
下面的图6.1 显示了使用CMMI的租户实现计划和成本目标的结果。实际上,第5级组织并不总是按时交付。但是,准时到达的可能性很高,典型的误差带很低。
将此与第1级(初始)团队的表现进行比较。成功的几率与拉斯维加斯的掷骰子表差不多。EE Times在1997年进行的一项调查在其报告中证实了该数据,其中80%的嵌入式系统交付延迟。
图6.1:改进流程可以提高实现目标的几率并缩小错误范围
一项针对公司在CMMI方面取得进展的研究每年发现以下 结果:
生产率提高37%,
测试前发现的缺陷增加了18%
,上市时间减少了19%
,客户发现的缺陷减少了45%
这些结果很难争论。但是,绝大多数组织都处于1级。在与嵌入式人员的讨论中,我发现大多数人只是模糊地意识到CMMI。一个显而易见的道德是要不断学习。跟上软件开发的最新水平。
我冒着被宣布为异端和被政治不当之火烧死的危险,我建议大多数公司要警惕CMMI。尽管拥有CMMI的明显好处,但追求CMMI仍然是一条艰难的道路,所有太多公司都无法驾驭。问题包括:
1.没有深层管理的承诺,CMMI注定要失败。由于管理层很少了解或什至不在乎创建高质量软件的问题,因此,由于迫在眉睫的截止日期而遭受攻击时,他们温和的买入常常会崩溃。
2.从一个台阶到另一个台阶的路径是曲折的。 没有热情洋溢的技术远见指导和召集部队,单个工程师可能会失去希望,而退回到他们旧的,功能失调的软件习惯。
CMMI是一种工具。而已。研究一下。从中汲取一些好主意。将其优点传达给您的管理层。但是有一个备份计划,您现在就可以现实地实施,以立即开始构建更好的代码。在“分析选项”或“研究领域”时推迟改进总是会回到现状。立刻行动!