《2022年日本OMRON公司软件过程改进实例 .pdf》由会员分享，可在线阅读，更多相关《2022年日本OMRON公司软件过程改进实例 .pdf（6页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、3 3 日本 OMRON公司的软件过程改进实例一、 OMRON公司软件过程改进概述1任务OMRON 企业在进行软件过程改进时，考虑到企业当前的发展要求来看，软件开发的质量及交货已不是主要矛盾，基本上可以满足用户的要求。但是，如何提高软件开发的生产率，使软件开发能做到增加效益，则对企业显得极为迫切。为了提高软件开发的生产率及提高开发效益， 成立了软件过程小组（software engineering process group,SEPG） 负责软件过程改进。具体任务有三：（1）鼓励开发人员进行软件过程改进；（2）对当前正在进行的软件开发工作的软件过程作出正确而详细的描述及定义；（3）提出一种可行
2、的工作计划，让开发人员遵循，以求改进软件过程。2步骤SEPG 采取的过程改进步骤如下：（1）对开发人员调研当前正在进行的软件开发工作，用 Petri net 描述其软件过程。 Petri net 中的 transition 表示软件开发活动，token 表示产品， place 表示过程等待执行活动的状态。（2）深入分析Petri net 所代表的当前的软件过程流图，制定工作计划， 并估计在严格执行工作计划后，可能得到的效益。其后，工作计划及效益估计都要经开发人员认可，认同其可行性，有效性。（3）按工作计划对实际项目进行实施。（4）最后，分析实际效果后，肯定了“在测试阶段总的工作量减少10%。
3、”可以得出肯定过程改进有效果的结论。二、项目概况该公司是进行一系列嵌入型软件的开发。这些软件有类似的结构，其基本结果如图3-9所示。 整个系统可分为基本部分和应用部分两大块。其中对各个不同项目说来，实时管理及I/O 部分是共同的，很少修改；对B，C，D，E，F，G 模块，在各个不同项目中只须对其进行少量修改；而模块A 和 H，则要对其大部分进行修改。过去相继开发了有相似产品特性的多个软件，至少需 3 年才能完成。 在进行软件过程改进的当时，有二个项目（PR1，PR2）已完成，第三个项目PR3 已开始进行了4 个月。已经认识到在开发软件的过程中，对A，H 与其他模块进行集成的工作是项目的关键部分
4、。这些项目的基本特点如下：（1）工作量：约2030 人月（平均30 人月） 。（2）开发周期：约37 月（平均5 月）（3）项目数：约510 项目 /年。（4）项目组人员：几乎不变动。（5）开发环境： UNIX 工作站。（6）开发语言： C 语言。（7）过程模型，采用如下瀑布模型：C D （concept design）F D (function design) 设计阶段S D (structure design)M D (module design)P G (programming) 实现阶段名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - -
5、 - - - 名师精心整理 - - - - - - - 第 1 页，共 6 页 - - - - - - - - - U T (unit test) 开发者进行白盒测试I T (integration test)F T (function test) 开发者进行黑盒测试V T (verification test) 测试组织进行黑盒测试三、调查发现（1）企业的主要问题是如何减少开发费用。对质量及交付日期， 目前用户已基本满意，所以不作主要改进的考虑。且数年来， 管理人员已对如何减少费用进行不少改进，但收效甚微，所以这次过程改进应主要考虑这一点。（2）从企业管理的要求上来说，技术上决定采用瀑布模型
6、。但发现实际执行时，有些阶段是平行的。要分析原因并解决管理要求与实际执行之间的不一致问题。四、软件过程改进工作方法概况SEPG 的软件过程改进工作分三个阶段，六个步骤，如图3-10 所示。第一阶段：描述当前的与改进的过程第一步：软件开发过程包含许多活动，且相互交互作用，必须精确而形式化地描述。第二步：从当前软件开发过程中收集的数据中指出费用、质量及进度方面的问题。例如，哪些活动需要大量费用，哪些影响质量（即导致许多出错）都一一标出。SEPG 与开发组讨论原因。第三步： 根据第二步的问题制定工作计划：改进的过程流图及改进的过程流中每一个活动的详细实施方针。前者也用Petri net 描述，后者制
7、定成文档。此时各种新的软件工程技术（如设计方法， 评审技术，测试技术 , ）引进工作计划，还采用一些过去的过程改进的经验，如 CMM 的实践等。第二阶段：定量估计工作计划的效益第四步：在执行工作计划前进行效益分析，评估对工作计划的影响，若有几个活动计划，应提出对当前软件开发最合适的计划。第三阶段：与开发人员协同工作进行改进活动第五步：开发者执行新的软件开发过程，此时SEPG 对过程进行细致而经常性监管。第六步：新的项目完成后，评估工作计划。具体的改进工作：第一步：精确而开花经地描述开发过程。SEPG 对 PR1， PR2 项目开发人员进行访问，构成项目开发过程的图3-11 所示的 Petri
8、Net（SEPG 花了 3 个月进行这项工作） 。其中 FT&VT可细画为图3-11（b） 。实际上 SEPG 并没有能够直接得到这一过程流图，因在开始时， 开发者只是说出管理部门规定他们应该如何做的情况，但不是实际上开发人员所做的情况。所以 SEPG 花了三个月反复与开发人员讨论，收集开发人员的工作数据每项工作的人日数。了解在每个项目PR1、PR2 上如何查出错误及错误的数目。再反映到图上，画出来给开发人员看。讨论每个阶段中开发人员做了什么，没有做什么。最后， 经开发人员同意：实际情况确实如图上所呈现的那样，才得到此过程流图。第二步：分析当前开发过程，指出问题。SEPG 经分析，发现黑盒测试
9、阶段工作量极大。即在交付前的功能测试与验证测试（FT&VT ）是难于控制且极其混乱。在PR1、PR2 中开发人员为处理这种混乱经常日以继夜工作。为了度量这些问题，SEPG 用三个公式来度量黑盒测试状态。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 6 页 - - - - - - - - - M1=项目全部工作量黑盒测试工作量M2=错误数代码审查后发现的全部数黑盒测试中发现的错误M3=功能测试的总工作量工作量开始后进行功能测试的VT对两个项目的数据进行分析后，得到表3-2
10、 的过程状态的度量值。表 3-2项目PR1 PR2度量M1 47% 49%M2 95% 94%M3 45% 34%上表中 M2 一栏中的全部错误数指PG 阶段及以后的错误。可以看到：M1：开发工作的一半工作量用于黑盒测试。M2：大部分错误（90%以上）是用于黑盒测试发现的，说明开发效率十分低，从而产品质量可能很差。M3：数值相当大。说明质量并没有达到一定的水平。系统中还存在大量错误时，在可以允许停止测试前，景开始了验证测试VT 。这说明对管理人员及开发人员来说，交付日期压力太大，所以结果是只能日以继夜工作。为了了解问题发生的根源和制定解决问题的计划，SEPG 反复调查下列问题：（1）在黑盒测试
11、中所修正的和发现的错误是哪一阶段产生的。（2）如何复查源代码。（3）如何进行白盒测试。经分析后， SEPG 认为要改进以下问题：（1）大部分错误是在PG 中造成的， 是由黑盒测试发现错误且纠正错误。但在源码审查时只查出极少错误。（2）在白盒测试时没有查出或查出极少错误且白盒测试记录。主要原因是从管理上没有明确严格的要求。白盒测试只是在FT 阶段开始前的业余时间内进行的。（3）虽然大多数人知道必须进行代码审查及白盒测试，但因为准时交付的压力太大，使他们不能正常执行这些活动。第三步：制定工作计划。 （SEPG 用了约 2 个星期）过程改进的工作计划包括新的过程流图和进行工作的详细指导原则。新的过程
12、流图如图3-12 所示。提出的详细指导原则强调了代码审查，白盒测试等。具体内容如下：（1）坚决执行实际有用的审查，具体规定：1)每个人都要履行审查员的作用。2)以每个小时审阅代码100200 行的速度进行审查，以保证代码审查的质量。3)所有新编的或更动过的代码行都必须审查。（2）引进单元测试工具，并对单元测试阶段所发现的问题一律写入报告。具体要求：1)所有新的及更动过的代码都必须用工具测试。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 6 页 - - - - - - -
13、 - - 2)在 UT 阶段，对发现及纠正过的错误也都必须记录。（3）按软件系统的结构进行集成测试。为了改进FT&VT 阶段， IT 阶段的具体要求为：1)按过程图定义的次序完成IT 阶段的活动。2)在工作前必须明确地定义每个IT 的测试项。3)在 IT 阶段中发现及排除的错误必须记录。（4）为了使代码审查及UT 阶段的项目进度可控，负责人应对每个开发人员作以下要求：1)在代码审查及UT 阶段中每个模块的进展及发现错误数都必须记录。2)定期向有关负责人员报告记录内容。第四步：分析新计划的效益：即如何节省开发费用。为了估计新的工作计划的效益，用“实际PR1”代表真实的PR1，用“改进 PR1”表
14、示如果执行改进工作计划后的效果。为了比较两者的区别，作如下假定：（1）“改进 PR1”在 PG 及测试阶段发现的错误与“实际PR1”在 PG 及测试阶段发现的错误数全同。（2）在 PG 中进行代码审查将查出全部错误的52.6%（数字根据文献给出） 。（3）通过白盒测试将查出全部错误的25.4%（数字根据文献给出） 。（4）通过 FT 将查出全部错误的15.9%（数字根据文献给出） 。（5）通过 VT 将查出全部错误的5.1%（数字根据文献给出） 。再按下述公式计算每个阶段的效果：Ei=Eim+Eid+Eir+EioEi表示产品在阶段i 需要的总工作量Eim=i*S i 为 PG，UT， IT，
15、FT 及 VT 之一Eid=i*NiEir=i*NiEio=i其中：Eim表示在完成阶段i 生产性工作量在i=UT ，IT，FT，VT 时=0，因为此时不产生任何产品Eid表示查出错误工作量S 表示产品规模Eir表示纠正错误工作量Ni表示在阶段i 的发现的缺陷数Eio表示其他工作量如准备和建立测试环境根据“实际PR1”中数据确定i，按过去一些其他项目的数据定下I，I，i。并由SEPG 与项目组成员讨论调整这些参数。得到下表。表 3-3 在“实际 PR1”中的错误及工作量统计阶段CD，FD PG UT，IT FT VT 其他总计SD，MD发现错误数14 0 219 81 314（分布 %）（ 4
16、.5）(0) (69.7) (25.8) (100.0)名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 6 页 - - - - - - - - - 工作量（人 -日）399 134 111 448 151 27 1270（分布 %）(31.4) (10.5) (8.8) (35.3) (11.9) (2.1) (100.0)表 3-4 对“改进 PR1”的估计发 现错 误数16.5 83 50 16 314( 分 布 %) （ 52.6）(26.4) (15.9) (5.
17、1) (100.0)工作量（人 -日）399 155 199 227 76 27 1083（分布 %）（36.8）(14.3) (18.4) (21.0) (7.0) (2.5) (100.0)对比上述两个表，得到“11083/1270=0.147” 。即可节省14.7%的工作量。因此此方案得到认可。决定按此执行。第五步：执行，监管工作计划及结果。SEPG 向开发组详细解释存在的问题，工作计划及其效益。项目管理人员批准按新的计划启动 PR3，每个开发人员都很好理解工作目的（通过与SEPG 许多非正式会议） 。按此工作计划完成后，计算M1， M2，M3 ，结果如表3-5 所示。表 3-5项目PR
18、1 PR2 PR3度量M1 47% 49% 44%M2 96% 94% 51%M3 45% 34% 0%从表中发现： 首先 PR3 的 M1 改进比期望小， 但要注意在PR3 中其他阶段的工作量（即分母）也减小了。在M2 上有极大改进，即差不多一半的错误在前面阶段已查出。即在前一阶段进行了质量保证，所以纠错工作量可望减少。而在 PR3 中，从 M3 的值可看到VT 开始时，质量是有保证的，软件可按时交付。从实际数据中得到：在项目的测试阶段，PR3 的测试效率及生产率都比PR1 有极大改进。总的效益约改进10%。第六步：为了更好说明软件过程改进的效果，用“实际PR3”的数据与假定不执行工作计划的
19、“想象PR3”进行比较。为此，作如下假定：（1）在 PG 以后及测试阶段所发现的错误数相同。（2）“实际 PR3”在 PG 及 UT 发现的所有错误（对“想象PR3”来说），在 FT 时已发现且已纠正。（3）“想象 PR3”中不进行代码审查及UT。计算公式如前，得到“11051/1192=0.118” 。即改进了11.8%。考虑到 FT&VT 阶段可能发生的混乱情况，改进的实际效益可能更大，应接近于以前的估计。表 3-6名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 6
20、页 - - - - - - - - - 阶段CD， FD PG UT IT FT VT 其他总计SD，MD发 现 错 误 数141 78 83 93 50 445（ 分 布 % ）（ 31.7 ）(17.5) (18.7) (20.9) (11.2) (100.0)工作量（人-日）303 75 54 127 215 244 33 1051（分布 %）（ 28.9）(7.1) (5.1) (12.0) (20.5) (23.2) (3.2) (100.0)发 现 错 误 数0 0 83 312 50 445（分布 %）（0） （0）（18.7） (70.1) (11.2) (100.0)工作量（
21、人-日）303 59 0 127 425 244 33 1192（分布 %）（ 25.8）(4.9) (0) (10.6) (35.7) (20.2) (2.8) (100.0)五、 OMRON公司软件过程改进工作小结在进行软件改进过程中，开发人员及管理人员都进行很好的合作，且互有好评， 并且大家都理解到：（1）管理人员真正地理解到需要改进软件过程。（2）由于 SEPG 与全体开发组经常进行许多非正式会议及讨论，思想一致， 才能真正做到改进软件过程。（3）全体开发人员认为真正实现了软件过程的改进。如：1)在交付前的混乱状态真正消除了；2)由于许多错误在早期得到纠正，所以软件过程及软件质量更可靠；3)可以想象在PR3 中余留的错误会少多了。六、结论这一个公司的实际过程改进经验，可以看出：（1）过程改进是需要根据实际情况具体分析，具体处理， 不可能只拿一个本本照抄就能执行。要一步一步走，针对问题，解决问题，逐步改进成成熟的开发组织。（2）过程改进是有效益的。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 6 页 - - - - - - - - -