英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
面向小型软件开发企业的软件过程改进方法
穆罕默德·西亚兹万·阿卜杜拉赫、阿卜杜勒·巴沙尔·马特·阿里克
马来西亚尤塔拉大学艺术与科学学院，科学系，马来西亚基达辛托克06010
摘要
在大多数国家，小型软件开发公司占所有软件公司的大多数。这些公司面临着与大型软件公司同样的软件工程挑战。软件过程改进( SPI )传统模型是为了帮助大型和非常大的公司而开发的，但是小型软件公司负担不起这些模型的花费。此外，他们还需要管理和改进其软件开发过程，原因有几个，例如应对快速的技术进步、维护其产品、满足客户需求和维持其运营。以能力成熟度模型集成( CMMI - DEV 1.2 )为基本改进模型，以极限编程( XP )方法为基本软件开发方法，给出了开发合适的软件开发过程改进框架的方法学阶段。
Elsevier有限公司发布的2010版，根据CC BY - NC - ND许可证开放访问。
由来宾编辑负责选择或同行评审。
关键词:软件过程，软件过程改进，小型软件开发公司。
1介绍
软件产业是增长最快的部门，这一部门的小型软件开发公司在大多数国家的经济中发挥着根本作用。因此，这些公司需要管理和改进其软件流程，以便在保持质量的同时以较低的成本在规定的时间范围内满足客户的要求。SPI是“通过改变或更新工艺来改进现有工艺系统性能的系统过程”。不幸的是，这些公司没有具体的SPI模型，因为所有当前的SPI模型都是为大型公司开发的，并且这些改进模型很难并且不适合于小型软件开发公司使用，因为这些模型过于复杂并且昂贵，无法在其开发中实现。然而，一些研究人员指出，SPI可以作为一个竞争的进步战略，无论是对大小组织。此外，对小型软件企业的实证研究还很少。无佩德雷拉等人，他们在对IEEE计算机学会数字图书馆、ACM数字图书馆、Wiley Inter Science (计算机科学领域)、Science Direct (计算机科学领域)、Springer Link等数字图书馆的实证研究的调查中指出，关于小企业的实证研究仅占20 %，关于大企业的实证研究占80 %。然而，小型软件开发公司需要改进其软件开发过程，这就需要为这些公司建立一个适当的软件开发改进框架。
Elsevier有限公司发布的1877 - 0509 c . 2010，根据CC BY - NC - ND许可证开放访问。
doi : 10.1016 / j . procs . 2010 . 12 . 146
塔拉瓦奈等人。/ Procedia计算机科学3 ( 2011 ) 893 - 897
/ Procedia计算机科学00 ( 2010 ) 000–000
2 小型软件开发企业对SPI的需求分析
在软件过程改进领域，许多研究人员一直关注于大型和非常大型的公司，因为这些公司大多有足够的投资和资源通过实施SPI传统模型和标准来改进其软件过程，这些模型指导软件开发改进过程。不幸的是，代表大多数国家所有公司的小型软件公司无法轻易使用这些传统模式和标准。小型软件开发公司缺乏研究来解决其改进软件过程的问题，在那里，关于小型软件公司实施SPI的速度和成功的大多数实证研究总是被认为是不够的，因为大多数研究集中在大型和非常大的公司。此外，这些公司大多采用临时方法开发其软件产品，因此，这些公司需要管理和改进其开发过程。此外，小型软件开发公司还需要具体的软件开发过程改进框架，以便能够管理和改进其软件开发过程，使其能够更快、更便宜地交付满足客户期望的高质量软件。
3 .极限编程
敏捷开发方法旨在解决在业务和IT环境中不断快速变化的需求下按时交付高质量软件的问题。敏捷方法的出现始于20世纪90年代中期，这些方法被认为是软件开发的最新方法。pressman 指出敏捷的一般方法有极限编程( XP )、Scrum、Crystal、动态系统开发方法( DSDM )、自适应软件开发( ASD )、特征驱动开发( FDD )、精益软件开发( LSD )、敏捷建模( AM )和敏捷统一过程( AUP )。
XP 是敏捷软件开发方法中最流行的轻量级方法。该模型的建立是为了解决传统软件开发模型的诸多局限性，如: ( 1 )大多数传统模型可能无法满足客户的需求；( 2 )所有传统模型都是为适应大型软件而开发的；(三)长期未投产的项目取消；( 4 )误解了业务需求，软件永远无法解决为其开发的业务问题。此外，XP方法之所以被称为extreme，是因为它采用了开发软件的良好做法，并且将这些做法应用于extreme。
由于大部分小型软件开发公司都采用特别的方式开发其软件产品，因此在为这些公司开发拟议的框架时需要考虑到适当的软件开发方法，以帮助它们以正确的方式开发其软件产品。
一个XP项目的所有参与者都作为一个团队的成员坐在一起。这个团队必须包括一个业务的代表——“客户”，他提供需求，设置优先度，并掌管整个项目的方向。最好这个客户或者他的助手是一个最终用户，了解该领域，知道什么是所需要的。团队当然还要有程序员。团队可能会包含测试员，他帮助客户定义客户验收测试。分析员可以作为客户的助手，帮助客户定义需求。通常还会有一个指导,他帮助整个团队跟踪、推动开发进程。也可能会有一个管理者，他提供资源、处理对外交流和分工协作。这些职责中没有任何一个是必须某个个人独有的：每一个XP团队的成员都以任何他们所能做到的方式参与，最好的团队没有专家，只有一些有着特殊的技能的一般的参与者。
规划策略
XP的计划解决软件开发中的两个关键问题：预知在责任期内哪些东西将被完成，并且确定下一步需要做什么。重点是把握项目的正确轨道——这是相当简单明了的——更胜于希望精确预知哪些东西将会需要以及可能花费多少时间——这是相当困难的。在XP这里有两个关键的规划步骤，用来解决这两个问题：
发布计划是一个实践让客户向程序员们演示所希望获得的特性，然后程序员们评估它们的难度。当手中有了代价的评估和这些特性的重要程序的认知之后，客户安排一个项目计划。最初的发布计划需要留有足够的余地：优先级以及评估都不是真实可靠的，并且知道团队开始工作以前，我们都无法确切地了解队伍的开发进度。甚至最初的发布计划也不是足够精确能进行决断，所以XP队伍通常会不时地校正发布计划。
迭代计划是一个实践籍此可以为团队提供每几个开发周的导向。XP队伍通过两周的“迭代”来建立软件系统，在每一个迭代结束时提供可以运行的有实际用途的软件系统。在进行迭代计划时，客户演示下两周内希望完成的特性。程序员们将它们分割成若干个任务，并且评估它们的成本（比发布计划要细致一些）。基于在之前的迭代中完成的工作，团队签定当前迭代中将要承担的工作。
这些计划十分的简单，然而他们为客户提供了非常好的信息和极好的操纵控制。每隔几周，多少进展都可以一目了然。在XP中没有“百分之九十完成”：一个特性故事要么完成了，要么没有完成。关注可视结果方法在于一个很好的小的对立论点：一方面来说，非常直观地，如果进度不能令人满意，客户可以在某一个位置取消项目。从另一方面说，进度是显而易见地，并且判断哪些东西将会完成的能力是很完善的，因此XP项目往往可以在较少的压力下完成更多的需要的东西。
本文讨论的拟议方法将采用XP作为基线软件开发方法，原因如下: [ 10，11 ] :
xXP更适用于小型、中型和不太复杂的项目，因为它是使用最广泛的敏捷方法，也是遵循敏捷原则的更突出的方法。
xXP是一个简单的学习模型。
xXP可以很容易地适应不断变化的需求。
xXP比敏捷方法更能实现软件过程的改进；它符合CMMI中的二级标准。
xXP是一个轻量级的过程模型，它可以帮助小公司实现软件过程改进。
xXP实践可以通过一次仔细地应用不同的实践而紧密地结合在一起，这最终将导致改进。
塔拉瓦奈等人。/ Procedia计算机科学3 ( 2011 ) 893–897895
4 .能力成熟度模型集成
CMMI是卡内基梅隆大学软件工程研究所( SEI )在一些新兴CMM模型的基础上发展起来的，这些模型包括软件能力成熟度模型( SW - CMM ) 2.0草稿、系统工程能力模型( SECM )和集成产品开发能力成熟度模型( IPD - CMM ) v0.98，该模型的第一个版本于2000年在[ 4号发布。CMMI的目标是为组织中的软件过程的改进提供一个指导方针，它是专门为软件行业编写的，用于详细描述软件过程。此外，CMMI产品团队指出，CMMI支持组织管理产品或服务的开发、获取和维护。CMMI还关注供应商改进内部软件流程，其中有两个表示；第一种是以过程领域能力为中心，以能力水平为衡量标准的连续表示，第二种是阶段表示；其重点是组织成熟度，并以成熟度等级[ 12 ]来衡量。
与其他软件过程改进模型相比，CMMI模型应用最广泛，因为CMMI应该适用于所有规模的公司[ 18 ]。然而，这个模型还没有准备好被小软件公司[ 3使用。尽管如此，与阶段表示法相比，连续表示法对小型软件公司是有用的，并且更适用于小型软件公司，因为小型软件公司可以在最突出的问题[ 13上分配其有限的资源。在此基础上，CMMI - DEV 1.2连续表示将被用作开发软件开发过程改进框架的基线改进模型，原因如下: ( 1 ) CMMI被用于指导软件开发改进，例如CMMI - DEV 1.2；( 2 ) CMMI是SEI的综合软件改进模型，该模型主要符合ISO 9000和ISO / IEC 1550 4等相关国际标准；( 3 ) CMMI模型在许多重要方面改进了其他改进模型的最佳实践；( 4 ) CMMI得到软件工程界的国际认可；( 5 ) CMMI已广泛用于评估和改进全球范围内的组织成熟度和流程能力，其中客户对CMMI有信心，因为CMMI广泛描述了各种良好做法如何结合在一起( [ 6，14，15 )
5 .拟议方法
建议的方法包括五个阶段，可用于为小型软件开发公司建立新的软件开发过程改进框架。每个阶段都有实现阶段目标的任务。图1突出显示了以下阶段:
xStage 1 :将CMMI - DEV 1.2的关键过程区域与XP方法进行比较。
x任务1 :在文献的基础上，将CMMI - DEV 1.2的关键流程区域与XP进行比较，确定XP方法可以覆盖或缺失的CMMI - DEV 1.2的关键流程区域。这可以通过将CMMI - DEV 1.2关键流程领域的具体实践与to XP方法(实践、角色、活动等)进行比较来确定CMMI - DEV 1.2的覆盖范围和遗漏的具体实践。
xStage 2 :扩展XP方法以实现CMMI - DEV 1.2中遗漏的关键过程区域。
x任务2 :根据CMMI - DEV 1.2中缺少的每个关键流程领域的具体实践，需要解决实现适合这些公司的缺少的关键流程领域所需的活动(来自文献)，并将这些活动添加到XP方法中。这是在考虑到小型软件开发公司的一般特点的同时进行的。这一阶段的结果是扩展XP。
XP团队建构软件系统为一个简单的设计。他们从简单开始，并且在整个程序员测试和设计改进过程中，他们保持着简单的设计。一个XP团队保持着设计总是刚好适合系统当前的功能要求。这里没有多余的投入，并且软件系统总是为将来做好了准备。 在XP中设计并不是一次性完成的事情，也不是一件从上到下的事情，它是自始至终的事情。在发布计划和迭代计划中都有设计的步骤，在快速设计过程中集合了团队的能力并且在整个项目过程地构中改进设计。在类似于极端编程这样的递增和迭代过程中，良好的设计是本质。这是在整个开发过程中必须更多的关注设计的原因。 成对编程 在XP所有的产品软件都是由两个程序员并排坐在一起，在同一台机器上共同完成的。这个实践保证了所有的产品代码都至少有一个其它的程序员进行了审视，而结果是更好的设计，更好的测试和更好的代码。 让两个程序员去做“一个程序员的工作”看起来有些效率低下，但是实际上刚好相反。研究表明成对编程在让程序员们单独工作相同的时间内会得到更好的代码。这证明了：两个头脑加在一起比一个好得多！ 很多程序员在还没有尝试过的情况下就反对成对编程。这确实需要一些实践来做好它，而且你需要认真地实践数周以上的时间来看到结果。百分之九十的学习过成对编程的程序员都会喜欢这样，因此我们向所有的团队强烈推荐它。除开提供更好的代码和测试之外，成队也提供了知识在团队中间传递。当成对地程序员交换伙伴时，每个人都会从其它的某个人那里学到新的知识。程序员们在学习，他们的技术在提高，他们对团队和公司来讲变得更有价值。成对，即使它本身在XP过程之外实施，也是每个人的巨大成功。在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代码。同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被发现或得到比较好的解决。针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。
为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序。（从这点，我们可以再次看到，XP的各个惯例和规则是怎样有机地结合在一起的。）
十.第三阶段:建立拟议框架
xTask 3 :基于软件过程改进框架的一般要素和扩展XP，建立了软件开发过程改进框架。
xTask 4 :指定拟议框架所需的一般要求，如程序、规则、技术、工具、文档和管理问题，提供活动顺序指导，指导团队、个人开发人员的任务，以及其他所需要求。<br
全文共7709字，剩余内容已隐藏，支付完成后下载完整资料</br
资料编号：[14360]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
