软件设计的风险

1、软件体系结构4.软件设计的风险, ,2,18.07.2020, ,3,18.07.2020,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

2、. 最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。 11. 公司被竞争对手恶意收购。收购时，软件的最终版本包含783个bug。 12. 新ceo走马上任。公司雇了一名新程序员重写该软件。 13. 程序员写出自认为没有bug的代码。, ,4,18.07.2020, ,5,18.07.2020,3、hoperun公司软件过程改进,一、概述 1任务 hoperun企业在进行软件过程改进时，考虑到从企业当前的发展要求来看，软件开发的质量及交货已不是主要矛盾，基本上可以满足用户的要求。但是，如何提高软件开发的生产率，使软件开发能做到增加效益，则对企业显得极为迫切。为

3、了提高软件开发的生产率及提高开发效益，成立了软件过程小组(software engineering process group，sepg)负责软件过程改进。具体任务有三： (1)鼓励开发人员进行软件过程改进； (2)对当前正在进行的软件开发工作的软件过程作出正确而详细的描述及定义； (3)提出一种可行的工作计划，让开发人员遵循，以求改进软件过程。, ,6,18.07.2020,3、hoperun公司软件过程改进,2步骤 sepg采取的过程改进步骤如下： (1)对开发人员调研当前正在进行的软件开发工作，用petri net描述其软件过程。petri net中的transition表示软件开发活动

4、，token表示产品，place表示过程等待执行活动的状态。 (2)深入分析petri net所代表的当前的软件过程流图，制定工作计划，并估计在严格执行工作计划后，可能得到的效益。其后，工作计划及效益估计都要经开发人员认可，认同其可行性，有效性。 (3)按工作计划对实际项目进行实施。 (4)最后，分析实际效果后，肯定了“在测试阶段总的工作量减少10。” 可以得出肯定过程改进有效果的结论。, ,7,18.07.2020,3、hoperun公司软件过程改进,二、项目概况 该公司是进行一系列服务类外包软件的开发。这些软件有类似的结构，其基本结构如图所示。整个系统可分为基本部分和应用部分两大块。其中对

5、各个不同项目说来，实时管理及io部分是共同的，很少修改；对b，c，d，e，f，g模块，在各个不同项目中只须对其进行少量修改；而模块a和h，则要对其大部分进行修改。, ,8,18.07.2020,3、hoperun公司软件过程改进, ,9,18.07.2020,3、hoperun公司软件过程改进,三、调查发现 (1)企业的主要问题是如何减少开发费用。对质量及交付日期，目前用户已基本满意，所以不作主要改进的考虑。且数年来，管理人员已对如何减少费用进行不少改进，但收效甚微，所以这次过程改进应主要考虑这一点。 (2)从企业管理的要求上来说，技术上决定采用瀑布模型。但发现实际执行时，有些阶段是平行的。要

6、分析原因并解决管理要求与实际执行之间的不一致问题。, ,10,18.07.2020,3、hoperun公司软件过程改进,四、软件过程改进工作方法概况 sepg的软件过程改进工作分三个阶段，六个步骤，,第一阶段：描述当前的与改进的过程 第一步：软件开发过程包含许多活动，且相互交互作用，必须精确而形式化地描述。 第二步：从当前软件开发过程中收集的数据中指出费用、质量及进度方面的问题。例如，哪些活动需要大量费用，哪些影响质量(即导致许多出错)都一一标出。sepg与开发组讨论原因。 第三步：根据第二步的问题制定工作计划：改进的过程流图及改进的过程流中每一个活动的详细实施方针。前者也用petri net

7、描述，后者制定成文档。此时各种新的软件工程技术(如设计方法，评审技术，测试技术)引进工作计划，还采用一些过去的过程改进的经验，如cmm的实践等。, ,11,18.07.2020,3、hoperun公司软件过程改进,四、软件过程改进工作方法概况 sepg的软件过程改进工作分三个阶段，六个步骤，,第二阶段：定量估计工作计划的效益 第四步：在执行工作计划前进行效益分析，评估对工作计划的影响，若有几个活动计划，应提出对当前软件开发最合适的计划。, ,12,18.07.2020,3、hoperun公司软件过程改进,四、软件过程改进工作方法概况 sepg的软件过程改进工作分三个阶段，六个步骤，,第三阶段：

8、与开发人员协同工作进行改进活动 第五步：开发者执行新的软件开发过程，此时sepg对过程进行细致而经常性监管。 第六步：新的项目完成后，评估工作计划。, ,13,18.07.2020,3、hoperun公司软件过程改进,具体的改进工作：第一步：精确而形式化地描述开发过程。 sepg对prl，pr2项目开发人员进行访问，构成项目开发过程的图a所示的petri net(sepg花了3个月进行这项工作)。其中ft&vt可细画为图 (b)。 实际上sepg并没有能够直接得到这一过程流图，因在开始时，开发者只是说出管理部门规定他们应该如何做的情况，但不是实际上开发人员所做的情况。所以sepg花了三个月反复

9、与开发人员讨论，收集开发人员的工作数据每项工作的人日数。了解在每个项目prl、pr2上如何查出错误及错误的数目。再反映到图上，画出来给开发人员看。讨论每个阶段中开发人员做了什么，没有做什么。最后，经开发人员同意：实际情况确实如图上所呈现的那样，才得到此过程流图。, ,14,18.07.2020,3、hoperun公司软件过程改进,第二步：分析当前开发过程，指出问题。 sepg经分析，发现黑盒测试阶段工作量极大。即在交付前的功能测试与验证测试(ft&vt)是难于控制且极其混乱。在prl、pr2中开发人员为处理这种混乱经常日以继夜工作。为了度量这些问题，sepg用三个公式来度量黑盒测试状态。, ,

10、15,18.07.2020,3、hoperun公司软件过程改进,对两个项目的数据进行分析后，得到下表的过程状态的度量值。,上表中m2一栏中的全部错误数指pg阶段及以后的错误，可以看到 m1：开发工作的一半工作量用于黑盒测试。 m 2：大部分错误(90以上)是用黑盒测试发现的，说明开发效率十分低，从而产品质量可能很差。 m 3：数值相当大。说明质量并没有达到一定的水平。系统中还存在大量错误时，在可以允许停止测试前，就开始了验证测试vt。这说明对管理人员及开发人员来说，交付日期压力太大，所以结果是只能日以继夜工作。, ,16,18.07.2020,3、hoperun公司软件过程改进,为了了解问题发

11、生的根源和制定解决问题的计划，sefg反复调查下列问题： (1)在黑盒测试中所修正的和发现的错误是哪一阶段产生的。 (2)如何复查源代码。 (3)如何进行白盒测试。 经分析后，sepg认为要改进以下问题： (1)大部分错误是在pg中造成的，是由黑盒测试发现错误且纠正错误。但在源码审查时只查出极少错误。 (2)在白盒测试时没有查出或查出极少错误且白盒测试无记录。主要原因是从管理上没有明确严格的要求。白盒测试只是在ft阶段开始前的业余时间内进行的。 (3)虽然大多数人知道必须进行代码审查及白盒测试，但因为准时交付的压力太大，使他们不能正常执行这些活动。, ,17,18.07.2020,3、hope

12、run公司软件过程改进,第三步：制定工作计划。(sepg用了约2个星期) 过程改进的工作计划包括新的过程流图和进行工作的详细指导原则。新的过程流图如图所示。, ,18,18.07.2020,提出的详细指导原则强调了代码审查，白盒测试等。具体内容如下： (1)坚决执行实际有用的代码审查，具体规定： 1)每个人都要履行审查员的作用。 2)以每个小时审阅代码100一200行的速度进行审查，以保证代码审查的质量。 3)所有新编的或更动过的代码行都必须审查。 (2)引进单元测试工具，并对单元测试阶段所发现的问题一律写入报告。具体要求： 1)所有新的及更动过的代码都必须用工具测试。 2)在ut阶段，对发现

13、及纠正过的错误也都必须记录。 (3)按软件系统的结构进行集成测试。为了改进ft&vt阶段，it阶段的具体要求为： 1)按过程图定义的次序完成it阶段的活动。 2)在工作前必须明确地定义每个it的测试项。 3)在it阶段中发现及排除的错误必须记录。 (4)为了使代码审查及ut阶段的项目进度可控，负责人应对每个开发人员作以下要求： 1)在代码审查及ut阶段中每个模块的进展及发现错误数都必须记录。 2)定期向有关负责人员报告记录内容。, ,19,18.07.2020,第四步：分析新计划的效益：即如何节省开发费用。 为了估计新的工作计划的效益，用“实际prl”代表真实的prl，用“改进prl”表示如果

14、执行改进工作计划后的效果。为了比较两者的区别，作如下假定： (1)“改进prl”在pg及测试阶段发现的错误与“实际prl”在pg及测试阶段发现的错误数全同。 (2)在pg中进行代码审查将查出全部错误的526(数字根据文献给出)。 (3)通过白盒测试将查出全部错误的264(数字根据文献给出)。 (4)通过ft将查出全部错误的159(数字根据文献给出)。 (5)通过vt将查出全部错误的51(数字根据文献给出)。 再按下述公式计算每个阶段的效果：,表示产品在阶段i需要的总工作量,i为pg，ut，it，ft及vt之一, ,20,18.07.2020,表示产品在阶段i需要的总工作量,i为pg，ut，it

15、，ft及vt之一, ,21,18.07.2020,对比上述两个表，得到“1-108312700.147”。即可节省147的工作量。因此此方案得到认可。决定按此执行。, ,22,18.07.2020,第五步：执行，监管工作计划及结果。 sepg向开发组详细解释存在的问题，工作计划及其效益。项目管理人员批准按新的计划启动pr3，每个开发人员都很好理解工作目的(通过与sepg许多非正式会议)。按此工作计划完成后，计算m1，m2，m3，结果如表35所示。 从表中发现：首先pr3的ml改进比期望的小，但要注意在pr3中其他阶段的工作量(即分母)也减小了。在m2上有极大改进，即差不多一半的错误在前面阶段已

16、查出。即在前一阶段进行了质量保证，所以纠错工作量可望减少。而在pr 3中，从m 3的值可看到vt开始时，质量是有保证的，软件可按时交付。 从实际数据中得到：在项目的测试阶段，pr3的测试效率及生产率都比prl有极大改进。总的效益约改进10。, ,23,18.07.2020,第六步：为了更好说明软件过程改进的效果，用“实际pr3”的数据与假定不执行工作计划的“想象pr3”进行比较。为此，作如下假定： (1)在pg以后及测试阶段所发现的错误数相同。 (2)“实际pr3”在pg及ut发现的所有错误(对“想象pr3”来说)，在ft时已发现且已纠正。 (3)“想象pr3”中不进行代码审查及ut。 计算公式如前，而按“实际pr3”中的真实数据，结果如表36。,二者比较，得到“1-105111920.118”。即改进了11.8。考虑到ft&vt阶段可能发生的混乱情况，改进的实际效益可能更大，应接近于以前的估计。, ,24,18.07.2020,五、hoperun公司软件过程改进工作小结 在进行软件改进过程中，开发人员及管理人员都进行很好的合作，且互有好评，并且大家都理解到： (1)管理人员真正地理解到需要改进软件过程。