软件过程改进浅谈

第一章  软件过程简介

1.  CMMI

　  CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。

1.1  CMMI的原则

 

　（1）强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的一致的支持是过程改进的关键。

　（2）仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。

　（3）选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。

　（4）过程改进要与组织的商务目标一致，与发展战略紧密结合。

1.2  CMMI的组织结构

 

CMMI的组织结构一般在最高领导之下设立EPG（Engineering Process Group, 工程过程组）、QA（Quality Assurance, 质量保证组）、EG（Engineering Group, 工程组），这三个组的构成就好像是立法、监督和执法的制衡体系，体现了西方的法治观念。EPG源于SEPG（Software Engineering Process Group, 软件工程过程组），本是组织中专职推进CMM的职能单位，随着CMM发展到CMMI，内容更加广泛，EPG的职能就是组织的过程改进。

CMMI 与CMM 最大的不同点在于：CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。

CMMI 有两种表示方法，一种是大家很熟悉的，和软件CMM 一样

的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI 中过程区域分为四大类：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。

 

 

 

2.  RUP

    RUP：Rational 统一软件开发过程,软件开发流程框架或定义平台。RUP是可配制的、风险驱动、架构为中心的、基于用例驱动的软件开发过程。是无数软件工程实践经验的总结。

2.1  四个阶段

 

    初始阶段：大体的构想、范围和模糊评估、用例，只详细编写最重要的部分用例。

    细化阶段：核心架构的迭代实现，高风险用例的实现、确定大多数需求、范围以及更为准确的评估。

    构造阶段：对遗留下来的风险较低的比较简单的元素迭代实现，准备部署。

    移交阶段：进行beta测试和部署。

2.2  六个最佳实践

 

     迭代的开发软件：在迭代中执行你的项目，化解需求变化风险

     需求管理：用例，从用户的角度描述需求，进化式需求

     使用基于构件的体系结构：利用组件与服务进行构架

     可视化软件建模：对主要观点建模

     验证软件质量：测试你的代码，单元测试，持续集成测试

     控制软件变更：拥抱并管理变更

 

 

3.  极限编程

    极限编程（XP）是由 Kent Beck 在 1996 年开发的一种软件开发学科。它基于四个价值：沟通、简单、反馈和勇气。它强调客户与开发团队成员的持续沟通，在开发进程中设立一名现场客户。该现场客户决定创建的内容和顺序。通过持续重构代码并创建最小的非代码工件集合而体现简单。许多短期发布和持续单元测试建立了反馈机制。勇气意味着完成正确的事情，即使并不是最流行的事情。它还意味着诚实面对您能做的和不能做的事情。

3.1  12 个 XP 实践

    有计划的开发：通过结合使用优先级"故事"和技术估算，确定下一版本的功能。

    小版本：以小的增量版本经常向客户发布软件。

    隐喻：隐喻是一个简单、共享的"故事"或描述，说明系统如何工作。

    简单设计：通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立刻进行移除。

    测试：用户编写测试内容以对"故事"进行测试。程序员编写测试内容来发现代码中的任何问题。在编写代码前先编写测试内容。

    重构：这是一项简化技术，用来移除代码中的重复内容和复杂之处。

    结对编程：团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动，另一个人同时审查代码的正确性和可理解性。

    集体代码所有权：任何人都拥有所有的代码。这就意味这每个人都可以在任何时候变更任何代码。

    持续集成：每天多次创建和集成系统，只要任何实现任务完成就要进行。

    每周 40 个小时：程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的。

    现场客户：一名真实的客户全时工作于开发环境中，帮助定义系统、编写测试内容并回答问题。

    编码标准：程序员采用一致的编码标准。

 

第二章  从国产操作系统看我国软件过程

1.我国软件过程发展现状   

 

     从上次国产操作系统的破产到最近的优麒麟操作系统的出现并对其的评测中可以看出，我国软件过程很滞后，关键是没有得到高层领导的重视，并且实施过程仅是样式而已，不仅没有起到应有的作用，还沦为一些不当牟利的工具。纵观历史可以看出，大部分技术或者观念都是先从军方开始，再到民间，所以我国软件过程滞后主要因为高层没有给到应有的重视，犯了形式主义。优麒麟的评测中可以发现，此系统仅是在原有的Ubuntu的基础上开发了几款应用程序而已，几乎没有改变原有Ubuntu的核心，哪怕是一些简单地扩展功能，外观，易用性，健壮性，都没有得到发展和改变，究其原因，还是软件过程的应用没有切实实施，导致出现这样的结果，如果继续这样下去，中国永远不会赶上，超越。

 

第三章  我的看法

1.我的想法和建议

 

    在开发时针对不同规模和复杂程度的项目灵活运用软件过程，小项目适合完全敏捷，而大项目更适合以架构为核心和风险驱动，在早期研究架构和风险，能保证大项目更顺利，而对于其中的具体活动，则可以使用敏捷思想，这样既保证项目有组织，又快速迭代。对于可视化工具的使用，我认为千万不要为了可视化而可视化，只有在有必要利用可视化使大家明白有关内容的情况下才使用，工具始终只是工具，只是辅助，团队成员一定不能形式主义。

     各种软件过程模型并不是对立的，应该相互结合。比如在管理变更方面，就可以结合rup和scrum各自的优点，我们可以在一次迭代过程中集中精力完成当前规定的任务和需求，而不去理睬关于此次迭代任务需求的变更，这样有利于集中精力，增强团队信心。但并不是从不关心变更，我们可以再本次迭代中完成关于上次迭代中需求的变更，这样既是积极地应对变更，又不影响本次迭代，保证本次迭代的顺利进行。

     随着面向Agent的软件开发技术的发展和成熟，软件过程必然会发生很大的变化，有些过程可能变得更重要，而有些不太需要。软件重用和构件技术将得到充分发挥，届时不但能降低软件工程复杂度，还能保证高质量，低成本，短时间。

    在我看来，软件工程的趋势是各种软件过程会继续融合，最终形成一个标准、规范，他的覆盖面很全很广，他只是一个参考，不同的公司参照他做出适合自己的一套软件过程，并不断优化。从哲学角度看，每个事物都具有两面性，都有其优秀的地方和弊端，每种软件过程都会存在利弊，只有具体问题具体分析，用实践检验一切，才能找到适合自己发展的方法。不断吸收长处弥补短处，逐步优化自己，才能达到更好，这样，到最后，各种软件过程在实质上其实就是一种模板，一个思想，只是可能他们的名字不同罢了（商业目的）。

    软件不同于一般商品，他是智力的结晶，具有个性和共性，所以我认为，不会达到现在意义上的工业化，只能尽可能的标准化，模板化，并保持一定程度的灵活性，适应性，以此达到重用。最终全球的优秀模板会全部公开，并相互使用来组装软件，这就是未来的软件工业化。这就需要一种管理分布式和本地式软件过程的方法，来量化管理开发过程。而且，随着人工智能的深入发展，以后软件开发和管理将会更简单，高效，机器人可能会代替人做一部分工作。

    厚积薄发，从实践角度看，我们应该做的首先是在实践中应用这些过程，并领会其中思想，综合应用优秀思想建立适合我们自己的总体框架和具体实践，并做进一步升华，结合发展趋势，不断优化。