软件过程课程总结.docx

软件过程课程总结.docx

《软件过程课程总结.docx》由会员分享，可在线阅读，更多相关《软件过程课程总结.docx（18页珍藏版）》请在冰点文库上搜索。

软件过程课程总结

湖南商学院

课程总结

题目

《软件过程管理》课程总结

学生姓名

学号

学院

专业班级

指导教师

职称

2014

年

11

月

《软件过程管理》课程总结

一、学习目标

从软件产业兴起以来，软件发展迅速，其在我们生活中占得比重也越来越大。

但是因为没有系统的、有效的管理，从而导致了软件危机。

软件质量没有保证，从而导致项目超期、预算超支。

软件工程师们一直在寻找解决的办法。

软件过程是软件开发与维护中为实现预期目标而须采用的实施路线与活动步骤。

通过这门学科的学习，我们了解了软件研发的过程，认识到软件过程管理的重要性。

通过目标严谨、有效的过程管理，一步步完善软件系统，可以大大提高软件产品的质量，减少人力物力的浪费，给用户一个满意的产品。

二、学习态度

到课的情况只能说一般般，虽然基本上每节课都有到，但还是有迟到的情况，到了以后老师总会说上课了教室里只有几个人。

迟到是因为前一天睡的晚了点，所以第二天起的迟了。

缺课的情况应该是没有的，虽然迟到了但还是都有去。

上课的时候态度还是不够认真，有时会和同学在下面聊聊闲天，被老师提醒后还是有认真的在听课；有时候会自己也会在下面看一些其他的书籍，因为感觉当时老师说的点还是知道的；偶尔也会发发呆，莫名其妙的放空自己了；但是老师说重点的时候还是有在认真的听课的，写在黑板上的内容还是有记笔记的，虽然不多，但都是精华。

三、学习内容

一、传统行业质量管理

所谓传统行业，就是制造业。

早期质量管理，主要体现于成果检验。

休哈特：

减少过程的可变因素，可以提高生产率。

戴明：

改进质量有利于降低成本，与占有更大的市场份额。

提出了PDCA质量管理循环。

建立更加完善的质量控制标准。

朱兰：

提出了“适用性”质量，建立了质量管理的螺旋型提高模式。

克劳士比：

提出了“零缺陷”概念。

ISO9000过程质量认证体系。

二、软件行业质量管理

CMM分为五个等级：

一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

PSP（PersonalSoftwareProcess），个人软件过程：

可用于控制、管理和改进个人工作方式的自我持续改进过程，包括软件开发表格、指南和规程的结构化框架。

TSP（TeamSoftwareProcess），团队软件过程：

为开发软件产品的开发团队提供指导，侧重于帮助开发团队改善其质量和生产率，以使其更好的满足成本及进度的目标。

瀑布模式

瀑布模式

特点

1.线性化过程

各阶段任务之间严格按衔接次序逐级推进，不允许跨越阶段任务，并必须等到上一阶段任务完成之后，下一阶段任务才能开始。

2.里程碑管理

每个阶段都有确定的与任务相关联的成果。

项目进程可量化。

3.阶段评审

各阶段成果都需要进行严格的质量评审，以确保每个阶段都能达到预期目标。

4.文档驱动

前一阶段产生的软件文档，将成为后一阶段的工作基础与约束条件。

因此，可依靠文档使项目由前一阶段推进到后一阶段。

原型进化过程

一种合理的过程考虑是，开发者建立可供用户使用的原型系统，然后收集用户对原型的使用评价，并以此为依据逐步对原型系统进行修正，由此逐步使其接近并最终达到目标系统的要求。

1.原型进化特点

原型进化模式

2.原型进化缺陷

（1）不能建立里程碑管理，以致项目进度难以量化，并使软件质量难以得到有效控制。

（2）虽然可通过新版发布而适应用户需求变更，但版本的快速更替也使得软件配置管理变得复杂起来。

（3）对于面向用户的中小型软件开发，原型进化模式有一定优势。

然而，其有管理规程上的不足，并不能有效保证软件质量，因此不能很好适应大型软件系统的开发。

增量开发过程

分为设计结构、开发构件、集成系统三个任务域。

增量模式

增量模式的优越性

（1）项目前期工作容易开展，仅依靠需求框架，如：

业务域、业务流程、基本功能点等，即可设计系统构架。

（2）基于任务域实现里程碑流程控制，能较好保证软件质量，并可适应大型应用软件系统的开发。

（3）直到开发构件时才需考虑需求细节，有利于用户需求的逐步明朗，并对构件级需求变更有较好的适应。

（4）可按照构件的功能价值安排开发顺序，并逐个实现与交付。

因此，一些用户急需的功能可优先开发，并尽早投入应用。

螺旋模式

螺旋模式是一种可较好规避开发风险的过程模式。

软件研发有来自各个方面的风险，如能够很好地识别风险，并能事先制定应对风险的措施，则风险的危害性必可显著降低。

螺旋模式的特点是项目基于任务域螺旋式递进。

其中的螺旋线用来表示项目进程，每一个螺旋回路对应于一个过程任务域，从内至外分别是需求分析，软件设计，系统集成、验证与交付。

螺旋模式中的每一个任务域都需要进行风险评估，并需要根据评估结论制定风险规避措施。

通常情况中，每个任务域涉及以下几个步骤。

（1）制定任务计划。

（2）确定任务目标，选择实施方案。

（3）评估方案风险，确定风险规避措施。

（4）实施任务方案。

但软件项目进行风险分析也是需要费用的，若软件项目风险分析费用过高，甚至超过了软件开发费用，则软件项目风险分析在经济上就显得不合算了。

螺旋模型

三、UML（UnifiedModelingLanguage，统一建模语言）

20世纪90年代，GradyBooch、JamesRumbaugh和IvarJacobson对诸多对象建模方法与技术的整合，建立了UML。

UML建立起了统一的语法规则、语义规则与语用规则。

●语法规则：

规定有哪些建模符号，并规定这些符号可以如何组合成图型。

●语义规则：

对建模符号以及由符号组合成的图型的文字解释。

●语用规则：

规定建模符号以及由符号组合的图型的建模用途。

UML融各种建模方法融于一体，能够从各个不同的角度对软件进行建模描述，其所涉及模型有：

用例图、活动图、类图、状态图、序列图、协作图、组件图、部署图。

UML建模过程

四、RUP（RationalUnifiedProcess，统一过程）

统一开发过程仍是将软件开发划分为分析、设计、实现三个阶段。

统一开发过程的特点是：

用例驱动、以构架为中心、增量迭代。

（1）用例驱动

用例驱动建模

（2）以构架为核心

统一开发过程要求以系统构架为中心实施系统开发，并要求优先考虑系统构架，以确保系统有较好的稳定性、扩充性与可维护性。

（3）增量迭代

增量迭代所指的是，系统可通过多次反复的修补改进，而逐步地趋于完善。

迭代模式

迭代模型

迭代模式有对面向对象方法更好的过程支持，可使面向对象方法获得更有成效的工程应用。

五、敏捷工程方法

敏捷价值观：

个体与交互胜于过程和工具；

可工作软件胜于宽泛的文档；

客户合作胜于合同谈判；

响应变化胜于遵循计划。

极限编程（XP）

极限编程（ExtremeProgramming，XP）是最早推出的敏捷工程方法，由KentBeck提出，使用了面向对象方法作为开发范型，包含策划、设计、编玛和测试4个框架活动。

（1）策划

策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”（类似用例）。

（2）设计

极限编程设计应遵循简洁原则，即使用简单而不是复杂的表诉。

（3）编码

极限编程认为，“测试先行”。

极限编程编码活动的关键是结对编程。

（4）测试

极限编程方法要求在编码开始之前，即建立好单元测试。

所建立的单元测试，还要求使用一个可以自动实施的框架。

六、项目配置管理

1.设置配置基线

（1）需求基线中的配置项：

需求规格说明书、系统验收计划等。

（2）设计基线中的配置项：

概要设计说明书、详细设计说明书、数据库设计说明书、系统集成计划、单元测试计划等。

（3）产品基线中的配置项：

源程序文件、数据文件、数据库脚本、测试数据、可运行系统、使用说明书等。

2.标识配置项

标识配置项即是给软件配置中的每个配置项一个唯一标记，以使它们能够被清楚地识别与追踪。

3.建立配置库

（1）开发库

开发库是一个面向开发人员的成果库，控制权在个人

（2）基线库

基线库是一个面向项目组的成果库，用来保存被确认的基线成果。

（3）产品库

产品库是一个面向软件开发机构的成果库，用来保存最终产品。

四、学习感悟

UML（UnifiedModelingLanguage，统一建模语言）

UML是面向对象开发中一种通用的图形化建模语言，它定义良好、易于表达、功能强大且普遍适用。

面向对象的分析主要在加强对问题空间和系统任务的理解、改进各方交流、与需求保持一致和支持软件重用等4个方面表现出比其他系统分析方法更好的能力，成为主流的系统分析方法。

UML的出现既统一了Booch、OMT、OOSE，以及其他方法，又统一了面向对象方法中使用的符号，并且在提出后不久就被OMG接纳为其标准之一。

从而改变了数十种面向对象的建模语言相互独立且各有千秋的局面，使得面向对象的分析技术有了空前发展。

它本身成为现代软件工程环境中对象分析和设计的重要工具，被视为面向对象技术的重要成果之一。

特点

一、用例驱动

用例驱动意味着为系统定义的用例是整个开发过程的基础。

用例在多个核心工作流程中都发挥了作用。

1、用例模型是需求工作流程的输出结果。

在这一早期流程中，需要通过用例来建立用户希望系统完成的任务的模型。

这样，用例构成了一个重要的基本概念，客户和系统开发人员都必须认可这个概念。

2、在分析设计中，用例是在设计模型中实现的。

您需要生成用例实现来说明在设计模型中如何通过对象的交互来执行用例。

此模型根据设计对象来说明所实施系统的各个组成部分，以及这些部分如何通过相互作用来执行用例。

3、在实施阶段，设计模型就是实施的规约。

由于用例是设计模型的基础，所以用例需通过设计类来实施。

4、在测试期间，用例是确定测试用例和测试过程的基础。

也就是说，通过执行每一个用例来核实系统。

5、在项目管理过程中，用例被用来作为计划迭代式开发的基础。

6、在部署工作流程中，它们构成用户手册阐述内容的基础。

用例也可用来确定产品构件如何排列组合。

例如，客户可通过将用例进行某种组合来配置一个系统。

二、以架构为中心

使用UML建模时要以架构为中心，构架之所以重要，原因有以下几点：

1、它使您可对项目进行并保持理智的控制，应付项目中复杂多变的情况，同时保持系统的完整性。

一个复杂的系统不仅仅是其各组成部分之和，也不光是一连串没有关联关系的、很小的技巧决定。

它必须依靠某种连贯统一的结构来有条理地组织那些部分，并且提供准确的规则，使系统发展过程中，其复杂程度不会膨胀，超越人类的理解力。

2、它是大规模复用的有效基础。

通过明确阐述它们之间的主要构件和关键接口,构架为您决定重复使用提供依据，包括内部复用（确定公用的部分）和外部复用（并入现成的构件）。

它还允许更大规模上的复用：

构架本身的复用，用于处理同一领域中的不同功能。

3、构架还可作为项目管理的基础。

项目计划和人员配备是根据主要构件的类别组织进行的。

基本的结构决策是由一个人员组成相对固定的构架小组作出的，他们不是分散的。

而开发活动则被分配给若干个小组，每个小组负责开发系统的一个或若干个部分。

三、迭代和递增的开发

使用UML建模时迭代式方法一般要优于线性或瀑布式方法，其原因很多。

1、允许变更需求。

需求有时会变化，这常常给项目带来麻烦，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。

2、逐步集成元素。

在迭代式方法中，集成可以说是连续不断的。

过去在项目结束时要占到整个项目工作量的那段较长的、不确定的且棘手的时期，现分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。

3、及早降低风险。

因为风险一般只有在集成阶段才能发现或得到处理。

在初期迭代时，检查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。

过去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。

4、提高复用性。

因为分部分设计或实施比起预先确定所有共性更容易确定公用部分。

确定和开发可重复使用的部分并非易事。

早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。

5、生成性能更强壮的产品。

因为在多次迭代中您总是不断地纠正错误。

在产品脱离先启阶段后的初期迭代中仍然可以发现缺陷。

性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。

课程总结评审表

姓名

学院

学号

专业班级

题目

《软件过程管理》课程总结

评

审

意

见

优

良

中

及格

不及格

备注

学习目标

学习态度

学习内容

学习感悟

总结客观性

答辩情况

文笔及版面情况

评审成绩

指导教师签名

职称

时间

年月日