软件设计的风险PPT文档资料.pptVIP

软件体系结构4.软件设计的风险;Date;1. 程序员写出自认为没有Bug的代码。 2. 软件测试，发现了20个Bug。 3. 程序员修改了10个Bug，并告诉测试组另外10个不是Bug。 4. 测试组发现其中5个改动根本无法工作，同时又发现了15个新Bug。 5. 重复3次步骤3和步骤4。 6. 鉴于市场方面的压力，为了配合当初制定的过分乐观的发布时间表，产品终于上市了。 7. 用户发现了137个新Bug。 8. 已经领了项目奖金的程序员不知跑到哪里去了。 9. 新组建的项目组修正了差不多全部137个Bug，但又发现了456个新Bug。 10. 最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。 11. 公司被竞争对手恶意收购。收购时，软件的最终版本包含783个Bug。 12. 新CEO走马上任。公司雇了一名新程序员重写该软件。 13. 程序员写出自认为没有Bug的代码。 ;Date;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;3、Hoperun公司软件过程改进 ;提出的详细指导原则强调了代码审查，白盒测试等。具体内容如下： (1)坚决执行实际有用的代码审查，具体规定： 1)每个人都要履行审查员的作用。 2)以每个小时审阅代码100一200行的速度进行审查，以保证代码审查的质量。 3)所有新编的或更动过的代码行都必须审查。 (2)引进单元测试工具，并对单元测试阶段所发现的问题一律写入报告。具体要求： 1)所有新的及更动过的代码都必须用工具测试。 2)在UT阶段，对发现及纠正过的错误也都必须记录。 (3)按软件系统的结构进行集成测试。为了改进FTVT阶段，IT阶段的具体要求为： 1)按过程图定义的次序完成IT阶段的活动。 2)在工作前必须明确地定义每个IT的测试项。 3)在IT阶段中发现及排除的错误必须记录。 (4)为了使代码审查及UT阶段的项目进度可控，负责人应对每个开发人员作以下要求： 1)在代码审查及UT阶段中每个模块的进展及发现错误数都必须记录。 2)定期向有关负责人员报告记录内容。 ;第四步：分析新计划的效益：即如何节省开发费用。 为了估计新的工作计划的效益，用“实际PRl”代表真实的PRl，用“改进PRl”表示如果执行改进工作计划后的效果。为了比较两者的区别，作如下假定： (1)“改进PRl”在PG及测试阶段发现的错误与“实际PRl”在PG及测试阶段发现的错误数全同。 (2)在PG中进行代码审查将查出全部错误的52．6％(数字根据文献给出)。 (3)通过白盒测试将查出全部错误的26．4％(数字根据文献给出)。 (4)通过FT将查出全部错误的15．9％(数字根据文献给出)。 (5)通过VT将查出全部错误的5．1％(数字根据文献给出)。 再按下述公式计算每个阶段的效果： ;表示产品在阶段i需要的总工作量 ;对比上述两个表，得到“1-1083／1270＝0.147”。即可节省14．7％的工作量。因此此方案得到认可。决定按此执行。 ;第五步：执行，监管工作计划及结果。 SEPG向开发组详细解释存在的问题，工作计划及其效益。项目管理人员批准按新的计划启动PR3，每个开发人员都很好理解工作目的(通过与SEPG许多非正式会议)。按此工作计划完成后，计算M1，M2，M3，结果如表3—5所示。 从表中发现：首先PR3的Ml改进比期望的小，但要注意在PR3中其他阶段的工作量(即分母)也减小了。在M2上有极大改进，即差不多一半的错误在前面阶段已查出。即在前一阶段进行了质量保证，所以纠错工作量可望减少。而在PR 3中，从M 3的值可看到VT开始时，质量是有保证的，软件可按时交付。 从实际数据中得到：在项目的测试阶段，PR3的测试效率及生产率都比PRl有极大改进。总的效益约改进10％。 ;第六步：为了更好说明软件过程改进的效果，用“实际PR3”的数据与假定不执行工作计划的“想象PR3”进行比较。为此，作如下假定： (1)在PG以后及测试阶段所发现的错误数相同。 (2)“实际PR3”在PG及UT发现的所有错误(对“想象PR3”来说)，在FT时已发现且已纠正。 (3)“想象PR3”中不进行代码审查及UT