|
 
- UID
- 1023230
|
当表达一个要求时，商务人员的期望是实现只要能够正常工作。但对于最终产品是否真正按料想的方式工作，在商务或软件历史上就几乎没有达成过一致意见。从工程角度看，与性能、可靠性、安全性等相关的任何问题如果不能满足要求就都应该被视作缺陷。而从商务角度看，人们认为避免这些问题本身就是所表达的要求的一部分。
商务期望与在开发和测试过程中的要求演变之间的这种隔阂原因比字面意义上要深刻得多。这是与传统组织文化相关的典型症状，即工程师认为商务人员不理解软件开发过程的复杂性。与此同时，组织的商务侧人员认为工程师患有聪明开发人员综合病症(SDS)——一种病态失调，即工程师所做的都是他们认为最好的，因为他们聪明嘛。
实现策略
那么解决方案是什么？一个组织如何在商务目标和开发过程之间架起沟通的桥梁？策略是确保工程师提供满足期望值的软件的关键，并且将品质意识根植于软件开发流程。通过实现策略驱动的开发方法，组织就可以在从创建到支持的整个软件开发周期内降低风险、提高产能并降低成本。策略驱动的开发基础是三个核心行动：
1． 定义策略形式的期望值，并以此指导工程师如何开发和测试软件
2． 在驱动这些策略的商务目标方面培训工程师
3． 在适当的基础设施帮助下自动监视策略的坚持力
清晰地定义可实施和可测量的策略可形成前后一致性和很高的精度，确保用文字定义的严格质量过程能够贯彻实行。此外，为了高效地达到清晰性和可测量性，策略增强自动化很有必要。
指导方针还是策略
如果你询问一个组织的开发策略，许多人会很快指向他们的最佳实践和指导方针。但指导方针和策略是不可互换的两个概念。指导方针描述建议的行为，而策略描述期望的行为。所有策略都有以下三个组成部分：
● 策略必须是自动可实施的：人工检查工程师是否遵循策略是不可行的。必须使用某种自动机制来检查违例并加以提醒。
● 策略违例提醒必须有针对性：只有所编写的代码违反策略的工程师才应被提醒。这样，符合策略的工程师可以继续不中断地工作。
● 必须制定纠正策略违例的自动化工作流程：应该定义工程师发现和处理策略违例的方法并实现自动化。
对嵌入式软件组织来说好消息是，有现成的技术可用来自动执行策略，如果执行正确的话，可以改善质量、提高产能、降低开发成本和风险。
策略与过程的匹配
“胡佛水坝必须滴水不漏”是一个合理的策略，它以平实明确的语言确立了一个组织的目标。现在考虑“每天检查一次漏水情况”的策略。表面上，这个策略似乎可以推动组织朝目标迈进，但更仔细的检查可以暴露出在许多嵌入式开发商店中流行的缺点类型。
这种策略达不到预期效果的地方是它允许问题先发生。它不是支持第一个策略的目标，而只是检查与不能满足在“胡佛水坝必须滴水不漏”中确定的组织目标相关的症状。遗憾的是，许多开发测试实践都遵循这种治标不治本的模型。
一个好得多的策略是“每天加强水坝的最弱点”。通过匹配策略和过程来满足想要的商务目标，你可以创建一个框架来确保并保持嵌入式软件的强度、安全性和可靠性。
图1：静态增强编码策略的开发测试平台。
策略与开发测试
开发测试是在整个开发过程中对软件测试行为的持续整合。它可以减少技术过失，防止缺陷生成，这是在应用生命期内提高效率和降低风险的关键。开发测试平台是实现开发测试实践一致性应用自动化的基础设施，这些实践活动包括静态分析、单元测试、对端检查、覆盖率分析、运行时错误检测，以及精确和客观地测量产能和应用质量。
每个组织可能发现不同的开发测试活动在特定环境下更有价值。策略驱动的开发测试可以确保这些开发测试活动以价值集中的、风险明确的、可核查的方式得到正确实施。开发测试平台接受策略形式的输入，并将它们翻译成一套定义一个或更多过程的规则。这种平台使该过程自动化、跟踪策略的持续性并验证结果是否符合期望值。也就是说，开发测试平台可以让商务领导更好地控制开发过程，并更好地观察过程改变的效果。
本文小结
值得注意的是，开发测试并不能替代品质管理(QA)，而是作为确认软件功能是否正确实现了最初意图的一个过程。开发测试也不只是测试过程的“左移”。开发测试的出现代表了与业界组织目前采用的更多反复、更为灵活的开发过程的一致性。开发测试是软件开发行为的一种模型，如果能够贯彻执行，将形成一种软件缺陷无法生存的环境。 |
|
