Panorama++介绍课案.ppt

Copyright (c) 2005 by Jay Xiong 技术交流、产品介绍与演示 DPT(缺陷预防与可追溯性驱动） 软件工程与质量保证革新体系 及其产品化支撑平台艾赛银弹/Panorama（全景）++ (非嵌入式与嵌入式） 原因，国际现有整个软件工程体系存在着一系列致命的缺陷： （1）严重残缺：正如国际著名软件专家Scott W. Ambler等人所指出的：“软件系统成本和工作量的主要部分，直达75%，发生在系统发布之后。它包含了产品的操作与技术支持，修改维护，和最终的引退。” – 然而，对于占了软件产品开发总费用和总工作量如此大份额的软件修改维护，国际现有整个软件工程体系却从来就没有提供过任何真正称得上系统化、量化和规范化的支撑和引导，造成需求变更的实现盲目，源码模块的修改也盲目，于是每一次修改都有20-50%的几率引入新的错误； （2）一直迷路：软件问题的总根源在于，它是逻辑思维产品，不是机械产品，取决于开发它的人的因素，而由于人的自然本质，以及知识、经验的局限性，总会想错、记错、看错、写错或者相互之间的沟通与理解有错。因此，软件产品既是参与其开发的所有人员的智慧与努力的结晶，也是各人在产品开发过程中可能引入的种种错误的汇集地 – 这，才是软件种种问题的总根源、软件质量问题的本源。对此，国际现有整个软件工程体系却“视而不见”，不仅没有任何有效的应对措施，反而成了这些软件错误的纵容者 – 采取以治为主的软件质量保证体系，先放任错误的发生、引入，然后才通过测试去查找、纠正； （3）更糟糕的是，还成了这些软件错误的传播者与放大器 – 采用线性瀑布模型或者线性单向增量迭代模型，没有双向自动追溯机制，使得大量错误很容易从“上游”传播到“下游”，并被一步步放大，最终才在维护阶段堆积，造成这些错误最终排除费用成几十倍甚至几百杯增加； （4）软件产品开发的主要矛盾，已经从过去“需求能否被实现”而转移到“软件初始需求被实现后如何解决需求变更的实现（往往是原始需求的一倍）和源码的修改维护问题” – 这是因为随着高级编程语言和编译技术的进步，实现软件的初始需求已经不像使用汇编那么困难了。但是，构成国际现有软件工程体系的所有模型、方法、技术与工具，几乎全都依然只针对今天的次要矛盾 – 仅占软件产品开发总费用和总工作量的25%的、狭义的软件开发过程（仅包括需求分析、设计、编码和测试四个主要阶段），却置主要矛盾 – 堆积了大量软件错误的、占了软件产品开发总费用和总工作量的75%的软件需求与源码修改维护与回归测试于不顾； （5）与复杂事物构建之路背道而驰 – 正如国际软件工程大师Roger S. Pressman在其所著的《软件工程实践者的研究方法》第六版中所指出的：“软件开发的线性方法违反了大多数系统的构建实践”! 国际现有整个软件工程体系，生硬地套用了其它硬件领域 – 例如电子工程 – 的工程化概念，来处理软件这种特殊的、属于逻辑思维的产品,却又违反了其它系统的构建所遵从的、需要非线性地经过“构思 – 设计 -试验/实现”多次循环的法则。 （6）由于线性模型没有双向自动追溯机制，造成软件需求实现的确认困难、软件需求修改实现的盲目、源码修改的盲目，软件修改后的回归测试的盲目，文档与修改后的源码不一致等。 2. 全方位解决基于线性模型（包括线性迭代模型）的国际现有软件工程体系所存在的一系列致命缺陷的革新方案及其产品化 DPT软件工程革新体系的开发目标 特点： 非线性 增量式 多轨 并行 实时 双向迭代 将软件开发与维护融为一体 将软件开发与项目和需求管理融为一体 支持全系统生命周期的缺陷预防 支持基于构件的软件开发 支持团队间的实时沟通 高度适应需求的变更，可实时响应 继承性与结构化书签命名法 按照上述书签设计法则，那么： r3d3_1p1t2s3_c3__6F5_2这一个书签，是项目技术论坛的第5个主题的第2个书签，它关系到第3号子需求的实现，以及该子需求对应的第3号设计文档的第一部分， 其有关项目计划及进度情况由r3d3_1p1书签指定，所关系到的测试需求说明书文档，由r3d3_1p1t2书签指定位置，对应于第3号测试用例脚本的3、4、5、6测试用例。 相应地，s6_c2_3u8,是手册中的一个书签 （可能是关于“帮助”信息的自动输出的），其对应的测试用例脚本编号为6，相关的测试用例编号为2和3 – 这可以供项目验收时作验证用。 （注：书签的命名也可用功能性名字，如r_ADD表示加法处理子需求，r_ADD_d_ADD 表示对应于加法子需求的、实现加法处理的设计文档） Time Ta