软件过程管理大作业

上海第二工业大学

课程作业报告

报告名称：如何加强软件过程管理，提高个体软件过程能力，做一个合格的软件工程师？

课程名称：《个体软件过程》

专业：软件工程

班级：12 软工A2

姓名：张云龙

学号：2014 3430 134

指导老师：谭文安

等分：

2014-12-21

如何加强软件过程管理，提高个体软件过程能力，

做一个合格的软件工程师？

摘要：

在当今互联网蓬勃发展的时代，软件企业面临着巨大的挑战。顾客需求瞬息万变、全球性竞争环境和技术创新不断加速等，导致产品生命周期不断缩短，商业模式不稳定，软件过程管理必须适应这种变化。CMM（能力成熟度模型）没有几年前那么火热而开始受到冷落，敏捷开发过程管理越来越受到推崇，而在敏捷开发中最引人关注的就是极限编程。

关键字：

CMM，敏捷过程，软件过程管理，极限编程

1．前言

近10年来，软件过程越来越成为人们关注的焦点，她正在打破过去人们已经习惯的面向任务的思维模式，逐渐加强面向过程的思考，软件开发和维护的运作以过程为中心的方式正在进行。正如软件工程领域领袖级人物、能力成熟度模型奠基人Watts Humphrey所说，要解决软件危机，首要任务是把软件活动是做可控的、可度量的和可改进的过程。

而敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。因此，敏捷开发是一种比较好的软件过程管理的好的方法。

2．使用敏捷开发思想，采用极限编程的模式

敏捷开发的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

敏捷开发的核心原则是：（1）主张简单（2）拥抱变化（3）第二个目标是可持续的（4）递增的变化（5）令Stakeholder投资最大化（6）有目的的建模（7）多种模型（8）高质量的工作（9）快速反馈（10）软件是你的主要目标（11）轻装前进

宣言原则：

最重要的是通过尽早和不断交付有价值的软件满足客户需要。

我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

可以工作的软件是进度的主要度量标准。

敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。

简单——尽可能减少工作量的艺术至关重要。

最好的架构、需求和设计都源自自我组织的团队。

每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为

敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：

单一职责原则（SRP)

就一个类而言，应该仅有一个引起它变化的原因。

开放-封闭原则（OCP)

软件实体应该是可以扩展的，但是不可修改。

Liskov替换原则（LSP)

子类型必须能够替换掉它们的基类型。

依赖倒置原则（DIP)

抽象不应该依赖于细节。细节应该依赖于抽象。

接口隔离原则（ISP)

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

重用发布等价原则（REP)

重用的粒度就是发布的粒度。

共同封闭原则（CCP)

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。共同重用原则(CRP)

一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。

无环依赖原则（ADP)

在包的依赖关系图中不允许存在环。

稳定依赖原则（SDP)

朝着稳定的方向进行依赖。

稳定抽象原则（SAP)

包的抽象程度应该和其稳定程度一致。

敏捷开发的方法有极限编程，Scrum，精益开发，动态系统开发方法等。

而在所有敏捷开发方法中，极限编程是敏捷开发方法中一种最引人注目的软件开发方法，它适应于需求快速变动背景下的中小型规模的开发团队。他是一种全新的、生机勃勃的软件开发方式。极限编程的出众之处在于兼顾了质量的两个方面（满足客户期望的同时，降低缺陷的数量），颠覆了复杂性不断增加的循环。极限编程是一种轻量级的开发方法，适用于需求快速变动背景下的中小规模的开发集体，它建立了一种渐进型的开发过程，通过迭代对源码进行重组，设计工作是以当前的迭代为基础，而不注重将来的变化，它既有传统的软件工程很强的纪律性，又有软件开发中必须的适配性，二者相结合，是的极限编程在敏捷开发中具有很强的生命里。极限编程技术对软件测试十分重视，并将其作为开发的基础。引入原型和风险分析以及极限编程的开发方法提高软件开发的效率，必须从开发方法和技术等方面来进行。[3]

2.1 拥抱极限编程（DO do XP）[1]

在文章远离极限编程(Don’t do XP) 里, Tobias Mayer 建议人们不要去搞极限编程(XP)。我和Tobias相知已久，我想他这个问题上错了。我不知道他在跟谁争论，但他们的有些争论就是“嚼舌根”。我想如果他曾经试过一次XP，那他的言论会更有说服力。XP并不是一个万能的解决方案，但它确实是一种方案，而且我们知道如何使用它。

作为一个临时的XP支持者，我并不抱怨“在软件工业中Scrum没有提供很好的开发原则”，我只抱怨这个产业。如果我们能在这个产业里有效率的工作，那我们也就不会有这场关于方法论的战争了，因为我们的目地就是出产品。如今当人们把Scrum概念应用到这个产业时，Scrum也不幸被人们使用的混乱不堪。另一方面，责备XP阻碍了实施方法的进步显然有些牵强。

XP是一种很小的运动，只吸引了一部分人的目光。XP（第一版）所实现的成果是让大家知道解决一直困扰很多开发团队的无法负担开发工期压力的问题是有办法解决的，而且是在不须求助高人协助的情况下。它提供了我一套好的实践方法让我们在开发中使用。当然了，XP 并不能解决世界上的所有问题，它并不是对每个人都适用，至少一个原因是你必须对它有相当的认识和研究，这是一般的团队所不具备的。Kent beck所论述的第一版XP极具有针对性：它的设计目标是让我们控制混乱，拓宽我们软件开发的思路，重新制定研讨框架。

我想Tobias似乎已经忘了这十年来发生的事情。其实我们所处的完全是一个理论性的运动，因为XP把推迟代码实现作为论述的中心——只需看看与此相关的人，他们是相同的一群人。他似乎也忘了众多的XP实施建议直接和我们的直观感觉有冲突，特别是和当前的产业发展方向有冲突。

Tobias说这些优秀的开发实施意见传播的如此缓慢，而我要说的是，没有XP，我们估计仍在原地等待。测试驱动开发一直没有被广泛的接受，甚至连最初的

C3小组也没有完全的接受它——直到有一天Kent写出了这本书。持续反省理论有一小群学院派的人追随，但是这种理论的实践如果没有TDD很好的支持会存在一定的风险情。我怀疑大多数的团队仍旧不愿轻易重整代码，除非要添加新的功能。结队编程方式也在滞销，同样，这种方式在TDD的环境中发挥的会更好。我知道有相当多的Scrum团队都没有找到一套系统的方法理论。如果说他们需要改进Scrum的实施方法，这是把问题归咎于他们如何使用Scrum和他们的自我组织问题。

最的的一点挑剔。XP的论著有二版，第二版发布不是很久远，而且里面提到的方法论更加“柔和”。与这些实践理论相关的一件事情：C3 项目组是在(Smalltalk/Gemstone) 这样的环境中工作的，落后于大多数我们今天使用的环境。XP社团里的很多工作都是在增加XP的灵活性，让它能在新的开发环境中使用。真正让人恐怖的事是这个产业缓慢的发展速度。

2.2 远离极限编程（Don’t do XP）[2]

Steve Freeman 写了一篇blog 拥抱极限编程(Do do XP) 来反驳我的这篇文章。我开始厌倦了和那些坚持认为Scrum离开了极限编程就不再有价值的人的无休止的论战。Scrum 很好用—但前提是实施者必须从基础上理解它的价值所在和实施原则。你应用Scrum所处的环境条件决定了你在实施过程中应该采取哪些措施。比如，在教堂里实施Scrum和在软件开发中实施Scrum有着不同的一套实施策略。而这两种情况下的实施措施又和传统的Scrum有不同之处。

极限编程的拥护者动不动就抱怨在软件工业中Scrum没有提供很好的开发原则。但就目前极限编程被业界采纳的缓慢进度来看，真正应该受责备应是XP

的缺少实践措施的问题，XP应该为这种状况负责。

从八十年代到九十年代，随着开发语言的进步和更适合于软件设计，人们开发和测试的方式发生了改变。在广大的面向对象群体中，有些概念正在缓慢的、但广泛的被人们所接受。例如持续反省、限制责任、测试代码优先（TDD）、持续集成、推迟设计、编码规范、以及结对编程等。所谓的极限编程(Kent Beck 和他的一些同事所做的) 也就是将所有的这些好的实践方法集中到一起打成一个包，再加上Jeff Sutherland 1993年在Easel公司实践出的Scrum模式。某种意义上说，这也就有抽象Scrum概念的第一次具体的实现。

这些都很成功。然而他们的这些实践经验的推广和采纳并没有像他们想象的那样进行。也许就是因为取了个极限编程的错误名称；也许是因为主要的、嗓门最大的拥护者非要说这是唯一真理的原因；也许是因为管理者恐惧这个新出现的异类，暗中作梗反对它；也许是因为，说到底，XP也不过是另一种开发方法。我不知道。我只知道，只有很少的开发团队宣称和承认采用了XP。

然而与此同时，Scrum正在获得强大的发展动力。并不需要多少华丽的理由，实际情况却是Scrum正在被为数不少的团队接受，正在用它来改进我们软件的开发过程。反而是XP现在想来分一杯羹。他们确实很饥饿。

首先，让我把问题说明白。我十分赞同软件开发团队采用一些已知的实践指导来提高代码质量、生产更高水平的软件作品。但为什么这么多人不愿意这么做？我不太喜欢把十几个任务打个包直接丢给团队，也不喜欢事先指定一种开发方法让他们必须遵守。那样做很显然违反了“people over process”和自我管理原则。在好的Scrum实施里，团队成员应根据自身情况找到适合自身的实施策略，这样的Scrum应用过程才是与实际相结合、才有意义。这才是我追求的进步。有些Scrum团队一直没有找到很满意的开发方法，这说明Scrum实施方式需要改进，而不是去告诉团队成员强制实施。

我有一个问题思考：如果XP从来没诞生过，有多少团队愿意完全接受所有XP所推荐的方法？我相信会有很多。我相信这些宝贵的开发经验会自然而然的被程序员和团队们采用，对我来说，关心的是经验本身，而不是他们出现的形式。我从来没有“done XP“，但我显然可以写出高质量的软件。XP的错误就在于坚持要求全盘接受。这并不是XP的创始人的初衷，可现在却搞成这样。很可能就是XP导致了这些好的实践经验不被人接受。很讽刺，不是吗？

另一个大问题是，XP论述写于12年之前，于此至今已有40多种新的语言诞生。XP倡导者在向人们推荐12年前的、现在可能过时的经验—12年相当于整个软件工业年龄的四分之一。惊人吧。让人们去发现适合自己的开发方法，他们将会总结出最有效的开发经验，这远不是几个脑瓜好用的人在上个世纪末能创造的。

我强烈要求Scrum倡导者停止与XP的争吵，我们讨论的应该是软件艺术。这才是我们在这个领域里急切需要的最终目标。幸运的是，现在有一个有着自己的manifesto的软件艺术运动正在逐步为人们所关注。最终，我们可以通过好的软件艺术实践运动重新改革我们这个领域，而不是使用那些修修补补的策略。开发者们：Don’t do XP。我们要实现一个通常意义上的指导框架，解决多年来的困扰，构建以人为本的核心基础。让我们重新为艺术而工作。或者从此离开这个行业。

3．极限编程中的软件质量管理[4]

极限编程中的软件质量管理关注与质量谱系的两端：准确的需求和健壮的产

品，同时控制软件的外部质量和内部的质量。它不依赖于某一“高效”的方法，而是将12种核心实践协同嵌套，形成一套严格的软件质量管理手段，使软件开发人员能够快速的，准确的为用户开发出高质量的软件。

1>准确的把握需求，保证软件外部质量

传统的瀑布型软件开发将需求分析放在开始端，当客户确认需求之后才进入编码设计。据统计，有50%~60%的质量问题来源于需求和设计，只有大约5%的问题来源于编程阶段。每进入一个新的开发阶段，修复错的成本就会成倍的增加。因此无法在功能上做出大幅度的扩展。

而在实际情况中，需求将随客户对客观约束的认识和开发人员对业务的深入而发生演变。极限编程采用的是一套主动探索需求的自适应方法，鼓励进行不可预期的需求的变更。因此他有如下几个特性

（1）现场客户（On-site Customer）

（2）用户描述需求（User Story）

（3）计划博弈（Planning Game）

（4）小型发布（Small Release）

（5）迭代（Iteration）

2>平衡敏捷和规范，保证软件内部质量

极限编程的软件内部质量管理以持续改进流程的方法将质量保证工作贯穿在开发过程的始终，采用轻量级的敏捷实践，重视写作和交流。极限编程同样重视编码规范，生产出风格统一，独立于作者的软件。

（1）编码的标准

（2）测试驱动

（3）简单设计

（4）集体拥有

（5）结对编程

（6）持续集成

3>开发小组在软件质量管理中的角色

在极限编程中，现场客户作为开发小组中的一员将全程的参与质量管理过程，提供需求，制定质量标准，编写验收测试。

在极限编程中的开发人员将承担部分软件质量保证工作，除了进行系统分析，软件设计外，还需要进行软件测试（测试驱动）和代码审计（结对编程）。

其次，在软件质量管理中的两个起重要作用的角色是一个就是教练，他是软件开发和软件过程的专家，他的职责就是密切的关注项目的开发过程，随时发现问题，解决问题，调整项目组的开发方向。二是跟踪人员，他的职责就是收集项目的过程数据，如计划的执行情况，软件的缺陷数，软件错误的改正日志等。这些数据是项目分析和管理的依据。

4．结论

成为合格软件工程师应该遵循的5项原则：站在用户角度看问题;面对问题，解决问题;解决问题，要系统化;专注于细节问题;以最小代价，获最大效益。在整个项目的计划实施中，软件工程师要明白个人服从团队，一个团队有一个很优秀的软件工程师，而不去愿意与团队合作，导致最终项目失败，个人再优秀，也不能代替一个团队。在项目的各阶段，每个软件工程师都是在一个团队的前提下，来进行项目的计划、分析、实施、交付用户及检验。团队利益要绝对凌驾与个人利益至上。管理人员要密切与各个软件工程师保持联系，统一每个人的思想，为

整个软件项目的研究而提供坚实的技术保障。

个体软件过程，它是一个记录经验的过程；一个总结经验的过程；一个了解自己的过程；一个对自己负责的过程；一个估计的过程；一个完善计划的过程。我们都知道工作经验是很重要的，而PSP就是可以统计自己先前的经验，并以文档的方式记录下来，而不是散乱在头脑中，遗忘于脑海间。我们需要在课堂所学知识中、在一次次项目实践的积累中，提高自身个体软件过程的能力。

作为软件工程专业的一员，无论将来是从事技术还是算法的研究，利用PSP 提高自己的程序修为，我认为都是很有必要的，一个人的快速成长离不开正确的理论指导，PSP正是这样一个较为科学的理论。不仅如此，在PSP完成一个项目的过程中，它有一个目标，同时具备从低到高的各个等级，在不同的等级PSP 也有着各自的任务，总而最终得以完美地完成次项目，达到原定的目标。人生就像一个项目，我们需要先为自己制定一个长远的理想，同时在各个成长阶段，我们需要用适应本阶段的要求约束自己，完成每个阶段的任务和目标，并最终达成并实现我们的理想。

参考文献

[1] Steven Freeman，Do do XP，译文出处：外文IT评论

[2] Tobias Mayer，Don’t do XP，译文出处：外文IT评论

[3]刘玲惠，梁晓强，敏捷软件开发中的极限编程，《产业与科技论坛》，2011

[4]唐红，刘宇翔，基于极限编程的软件质量管理，《标准科学》，2008