软件过程管理习题学习资料Word格式.docx
《软件过程管理习题学习资料Word格式.docx》由会员分享，可在线阅读，更多相关《软件过程管理习题学习资料Word格式.docx（11页珍藏版）》请在冰点文库上搜索。
理由：
确定好软件开发所采用的开发方法，就能尽早的做下步计划，不至于到最后为选择开发方法而浪费太多时间。
目前已形成了八类软件开发方法，开发时是选择面向数据结构的开发方法还是面向对象的开发方法，直接会影响到小组的开发进度。
要根据成员的擅长情况制定方法。
（5）软件版本管理员，以及设计、编程、测试人员的职责明确。
理由:
权责分明，遇到问题追究到人，会使项目开发更有计划。
完善制度，将责任明确到人，这样才能明确目标，将工作细化，使成员做好自己的工作，认识到重要性，使开发过程能高效的进行。
（6）制定正式评审规程、建立相应的评审机构。
项目评审工作就是对项目计划执行情况以及未来计划的新情况做一个评审，同时对项目的财务状况及其它情况做一个总结。
另外，它可以为项目团队在处理项目风险时提供机会，以获得管理层的支持，同时也为项目团队继续开展项目工作提供在高层管理方面的认可。
（7）根据项目实际情况，选定本项目应遵循的软件过程标准、规范。
如果一个团队中有了统一的过程，那么，大家的行为就会符合规范，从而提高团队的整体能力。
如果一个团队缺乏执行规范化过程的活动，就会导致整个组织的混乱。
为了消除软件过程所常见的问题，建立软件过程规范是必要的。
软件过程规范可以确保过程活动的一致性、有效性和持续性。
（8）任命项目负责人。
项目负责人除了调配好小组成员，运用专业知识做整体质量的导向，控制项目的进度以外，还要与用户协调，利用周边人力资源做项目规划的流程安排，项目负责人要及时的发现程序开发中的困难和障碍，并且努力的及早的解决。
一个项目从开始运作到最后完成，不论是合同的签定、还是人员的调配、还是执行的安排，处处隐藏着不可预见的漏洞，因此需要项目负责人全局的掌控思维和能力。
（9）具有各阶段活动所需要的软/硬件环境、支持工具，并提供足够的经费。
只有硬件基础具备了，才能形成一个好的开发环境，同时经费也是基础，要合理的制定经费计划，保证开发过程顺利进行。
要做好软件开发成本估算，这样才能合理的开发。
（10）项目软件负责的职责明确。
责任是管理的基础，明确了职责，才能使成员更加认真的做好自己的本职工作，同时将责任细分，在出问题后也可以责任到人。
2.软件配置管理主要包括哪些？
请详细说明。
（1）配置管理过程
软件配置管理（SCM）简单而言就是管理软件的变化。
它属于软件工程过程，通常由相应的工具、过程和方法学组成。
在整个过程管理的活动中占有很重要的位置。
IEEE“软件配置管理计划标准”关于SCM论述如下。
软件配置管理由适用于所有软件开发项目的最佳工程实践组成，无论是采用分阶段开发，还是采用快速原型进行开发，甚至包括对现有软件产品进行维护。
SCM通过以下手段来提高软件的可靠性和质量。
1）在整个软件的生命周期中提供标识和控制文档、源代码、接口定义和数据库等工件的机制。
2）提供满足需求、符合标准、适合项目管理及其他组织策略的软件开发和维护的方法学。
3）为管理和产品发布提供支持信息，如基线的状态、变更控制、测试、发布和审计等。
软件配置管理贯穿于项目的整个软件过程中，与项目过程行为密不可分。
一方面，对于在软件过程中所产生的工作产品或变更请求通过配置管理活动进行管理，将有效的信息存储在配置管理库中。
另一方面，项目人员可依赖配置管理活动获取配置项的有效版本和历史信息。
软件配置控制是软件配置管理的核心工作。
软件配置控制主要包括对软件的存取控制、版本控制、变更控制和产品发布等4个方面。
（2）基线控制
在软件开发过程中，由于各种原因，可能需要变动需求、预算、进度和设计方案等，尽管这些变动请求中绝大部分是合理的，但在不同的时机做不同的变动，其难易程度和造成影响差别比较大，为了有效的控制变动，软件配置管理引入基线的概念。
简单地说，基线就是项目存储库中每个工件版本在特定时期的一个“快照”，它提供一个正式标志，随后的工作基于这个标志进行，并且只有经过授权后才能变更这个标志。
建立一个初始基线后，以后每次对它进行的变更都将记录一个差值，直到建成下一个基线。
基线是软件生命期各阶段末尾的特定点，也称为里程碑。
在这些特定点上，阶段工作已结束，并且已经取得了正式的阶段性产品。
建立基线的概念是为了把各个阶段的工作划分的更加明确，使得本来连续开展的软件工作在这些点上被割开，从而更加有利于检验和肯定阶段性的成果。
同时也有利于变更控制。
有了基线的规定后，就可以禁止跨越里程碑去修改另一阶段“已冻结”的工作成果。
就各种不同类型的基线而言，有一条较为特殊的基线，它是软件过程中的第一条基线。
它包含通过评审的软件需求，因此称之为“需求基线”。
通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求基线的变更请求将受到慎重的评估和严格的控制。
受控的需求还是对软件进行功能评审的基础。
需求基线是整个软件生命周期的起点和终结点。
（3）版本控制
版本控制是对系统不同版本进行标识和跟踪的过程，是实行软件配置管理的基础，也是所有配置管理系统的核心功能。
配置管理系统的其他功能大都建立在版本控制功能之上。
版本控制主要分为版本的访问与同步控制、版本的分支和合并。
1）版本的访问和同步：
一般来说，不同的工作空间是由不同的目录来表示的，而对工作空间的访问是由文件系统提供的文件访问权限来加以控制的。
版本的访问控制：
工作区域中的源文件是从库中恢复得到的一个副本，该副本可以是“可写”的，也可以是“可读”的。
对于“可写”的副本来说，它就是真正的工作文件。
而对于“可读”的副本，它可以被视为软件库中源文件的一个缓冲副本，此时一般有两种工作模式。
在工作区域一旦有“读”请求，则作一次恢复操作，获得一个副本。
当“读”操作结束后，该副本被删除。
这样就形成一种重复恢复，从而可以保证工作区域中的文件内容被更新为与软件库中的内容一致。
针对上一种模式中重复恢复引起的较大时间代价，不是每次“读”操作都要求与软件库中发生交互，而是将重点放在工作区域上，仅当软件库中的内容发生更改时，才发生交互。
版本同步控制：
同步控制实际上是版本的检入检出控制。
2）版本的分支和合并：
版本分支的人工方法就是从主版本---称为主干上复制的一份，并做上标记。
在实行了版本控制之后，版本的分支也是一份复制，这时的复制过程和标记动作由版本控制系统自动完成。
对于合并，在没有版本控制的时候，一般是通过文件的比较来进行合并。
在实行了版本控制之后，还是要通过文件的比较来进行合并，但是这时的比较工作可以由版本比较工具自动进行合并，自动合并后的结果需要人工检查，才有很高的可靠性。
（4）变更控制
在软件过程中要产生许多变更，比如配置项、配置、基线、构建的版本和发布版本等。
对于所有的变更，都要有一个控制机制，以保证所有变更都是可控的、可跟踪的和可重现的。
为了有效地进行变更控制，需要规范相应的变更控制流程，变更控制流程主要分为7个阶段，变更请求提交、接受、评估、决策、实现、验证和完成。
3.如何综合运用过程管理的工具？
在软件过程活动中，要经历不同的阶段和涉及很多的过程域，为了有效的执行这些软件过程活动，需要在整个软件开发过程中引入相关工具。
一般来说，实施软件过程活动所需要的工具主要有下面几种。
●需求管理工具
●面向对象的分析设计工具
●配置管理、变更管理工具
●软件测试管理、缺陷跟踪工具
（1）需求管理工具
一个优秀的需求管理工具，可以有效地管理需求，提高需求管理工作流程的自动化程度，在项目实施中完整的、一致的管理好需求。
IBM-RationalAnalystStudio：
IBM-RationalAnalystStudio可以帮助更好地分析问题，更好地定义并交流问题的解决方案，用于可视化建模、需求和用例管理以及缺陷和变更请求跟踪等。
TelelogicDOORS：
TelelogicDOORS-EnterpriseRequirementsSuite（DOORS/ERS）是基于整个软件组织的需求管理系统，用来捕捉、链接、跟踪、分析及管理信息，以确保项目与特定的需求及标准保持一致。
DOORS/ERS提供多种工具与方法对需求进行管理，可以灵活地融合到组织的软件过程管理中。
BorlandCaliber：
BorlandCaliber是一个基于Web和用于协作的需求定义和管理工具，可以帮助分布式的开发团队平滑协作，从而加速交付应用系统。
Caliber辅助团队成员沟通，有助于更好地理解和控制项目，较少错误和提升项目质量。
（2）面向对象的分析设计工具
IBM-RationalRose是面向对象技术分析设计工具的代表，是可视化的建模工具。
它采用“统一建模语言（UML）”的表示方法，在同一个模型中实现业务建模、对象建模和数据建模，使所有参与项目的成员都可以在统一的语言环境中工作于同一个模型之上，有利于改善成员之间的沟通。
其次，IBM-RationalRose支持多种语言的代码生成及双向工程，可实现代码和模型的互相转换，并且可以将遗留代码引入模型中。
最后，IBM-RationalRose带有对设计元素进行测试的模块工具，可以尽早发现设计中的问题，真正实现“质量从头抓起”。
（3）配置管理和变更管理工具
在CMM标准中，明确规定了软件配置管理以及变更请求管理的相关工作，主要包括以下两方面。
1）配置管理的主要工作包括通过创建软件配置管理库、定义配置项以及建立和维护软件的基线。
2）变更请求管理的主要工作包括控制和记录配置项内容的变更，建立和维护一个系统并使其追踪和管理变更请求及问题报告。
常用的软件配置管理工具有国内青鸟软件的JBCM、IBM-Rational的ClearCase和开源工具CVS。
4.通过一个案例，说明一下如何运用IPD提高产品集成的质量。
华为是国内第一家引进和实施IPD的公司，也是受益最大的国内企业。
华为的IPD可以分为两个大的阶段，这两个阶段的效果有明显差别；
在IBM为华为提供IPD咨询后，华为的IPD取得了巨大成功。
（1）实施背景
实施IPD之前，华为每年将销售额的10%投入产品开发，但是研发费用浪费比例和产品开发周期仍然是业界最佳水平的两倍以上。
华为销售额虽然连年增长，但产品的毛利率却逐年下降，人均效益只有思科、IBM等企业的1/3-1/6。
产品开发流程处于企业价值链最上游，这里出现的问题通过生产制造、销售、交付、售后服务等下游环节会产生若干倍的放大。
在分析采购业务系统时，华为就发现很多问题的根本出在产品开发过程中。
因此，从产品开发入手，解决产品开发这一源头上的问题，是提高产品投资收益和解决公司系统性问题的治本之举。
华为花巨资引进IPD，就是希望通过变革产品开发模式，缩短产品上市时间，降低费用，提升产品质量，最终能够提高产品的盈利能力。
IBM的专家认为，华为在产品研发方面的主要问题是概念与计划阶段合并在一起，研发活动缺乏计划性和严格的评审。
以前，华为经常是基本上没有业务计划，甚至在高层指示下就直接开始了开发。
这导致产品与技术的开发重合，最后导致实用产品迟迟推不出来。
华为以前的评审往往是技术型而不是业务型，主要依靠主观判断来分析市场需求。
由于评审和决策仅仅是出于主观判断，没有符合市场需求的标准，结果造成产品不断修改。
（2）实施过程
华为的IPD经过了两个阶段。
第一阶段从1998年初开始。
当时华为开始自己摸索实施IPD，组织了项目组（主要由一批MBA构成），拿出了一套基于IPD的研发体系变革方案，并进行了推广实施。
但这次IPD变革效果并不像人们预期的那样，基本上是一次失败的尝试。
后来华为经过分析决定请IBM作为咨询方来帮助解决问题。
华为在IBM的帮助下实施IPD是从1998年开始起步的。
当年，由IBM为华为实施IPD提供咨询，打破了华为以部门为管理结构的模式，转向以业务流程和生产线为核心的管理模式。
仅此一项华为付给IBM的咨询费达到了数千万美元。
根据IBM咨询的方法论，华为IPD项目划分为关注、发明和推行三个阶段。
在关注阶段，进行了大量的“松土”工作，即在调研诊断的基础上，进行反复的培训、研讨和沟通，使相关部门和人员真正理解IPD的思想和方法。
发明阶段的主要任务是方案的设计和选取三个试点PDT，按IPD进行运作。
推广阶段是逐步推进的，先在50%的项目中推广，然后扩大到80%的项目，最后推广到所有项目。
华为的IPD在刚开始起步时，各个产品的研发在组织架构上已经基本形成了PDT的雏形，各种计划、文档、研发活动也是按IPD的模式进行。
但在这个时期，只有华为与IBM配合成立的IPD项目组里的人对IPD有较为明确的理解。
当时研发流程用的是所谓IPD1.0，IPD的实际效用没有完全发挥出来。
公司内部只是在研发活动的称谓以及重要文档的输出上模仿PDT1.0流程的规定。
IPD的核心组决策，IPMT的决策评审等关键措施并没有施行，只是在两个产品线上作试点。
这个过程持续到了2001年，从2001年开始，华为规定，公司内30%的产品线必须严格按照IPD2.0流程运作，其他产品线继续按照IPD1.0流程运行。
2002年华为规定，到年底所有产品线必须完全按照PDT2.0的流程运作。
此时，支撑PDT流程的相关人事制度，财务制度，以及绩效考核制度等都已建立起来。
同时，华为公司从高层领导到基层产品研发管理者都对PDT的思想和流程有了比较清晰深入的认识，因此已经具备全面推行PDT的客观条件。
至2003年，华为的IPD已经从1.0版本升级到了3.0版本。
（3）华为IPD构成
华为的IPD主要由以下几个部分组成：
1）固化的结构化研发流程
2）支持流程实施的跨部门团队
以前华为的产品开发完全是研发部门的事情，技术方向由关键人物来选择。
在IPD模式下，各部门都要有人参与到规划和实施的过程里，组成跨部门的团队—IPMT与PDT（IPT）。
跨部门的团队基本上要在产品开发之前做出相关联的规划，并且在产品开发的过程中相互协调，以保证这个产品从始至终都是技术领先、成本合理并且符合市场需求。
华为共有约一百多个产品线，类似的产品线再一起组成一个大的产品线。
每个大的研发产品线都有一个IPMT，他们是由总监级（现在改为产品线总裁）或者资深的产品专家组成，负责对旗下各个产品线的研发活动作关键环节（立项评估，计划决策，实验局评估等）的监控和评估。
监控和评估的主要依据就是看这个产品研发成本投入和未来市场效益的比较，以及技术、资金、人力等方面的可行性。
决策评审点：
决策评审点实际上是一种喇叭口的结构。
也就是通过仔细的调查、研究和分析之后筛选出最有潜力的项目，并且在“动手”之前尽可能地进行“瞄准”和计算“提前量”。
使得最后进入开发阶段的项目都是最健康和最明确的。
应该说这种研发管道管理，是华为在以前最欠缺的。
异步开发模式：
IPD在开发过程中为华为第一次引进了“异步开发”的概念。
这种流程实际上很好地使用了并行工程的思想，它比华为原来串行研发流程的效率要高很多。
（4）实施成效
华为IPD的实践表明，IPD能够加快产品开发速度，缩短产品上市时间，减少产品开发的投资失败从而减少浪费，降低产品开发成本，增加收入，给客户提供价廉物美的产品。
总的来说，IPD实施几年来，华为逐渐建立起世界级的研发管理体系，形成了世界级的研发能力，优化了公司的整体运行，取得了明显成效。
5.针对一个过程管理模型（RUP,MSF,XP或者是面向构件的软件过程），设计一个合适的软件项目的过程流程。
极限编程（XP）是敏捷方法的代表，强调软件发布版本小、周期短、速度快、其核心是迭代。
通过一次次地迭代使产品不断完善，同时用户能及时得到他们想要的功能。
另一方面，软件开发组织可以及时获得用户的反馈、调整产品功能特性的定义来适应用户不断变化的需求，而不至于造成在某个时刻的大规模返工——损失惨重。
在XP中，强调需求来自用户案例，同时测试用例的设计也是基于用户案例展开。
XP过程遵循“系统架构、发布计划、迭代、验收测试、版本发布”这条主线，但只有系统层次的设计，没有设立特定的详细设计阶段，而是将详细设计直接融入编程之中，在日常的编码中就穿插着所需要的小规模、低层次的设计。
除此之外，极限编程强调下列一些基本观点。
编码。
作为一种轻量级方法论，XP明确放弃了系统建档和分析以外的任何外在活动，而将其视为一种相对简单、但和客户的日常沟通中发生的持续活动。
文档则明确不予鼓励，而是鼓励XP编程人员在日常工作中倾听客户和其他编程人员的需求和意图。
编码则是XP最主要的活动。
测试。
为了确保所完成得代码能正确无误地工作，XP提倡编写大量测试脚本来检查代码是否正确。
XP所呈现的生命周期如下图所示。
XP还包括了测试驱动开发（TDD）的思想——在编码开始之前将测试用例/脚本写好。
TDD在XP中，被称之为“测试第一的开发”。
强调“测试先行”，使得开发人员对自己的代码要有足够的信心，同时也有勇气进行代码重构。
TDD要求在编程之前就要将各种特定条件、使用场景等想清楚，写成测试用例、测试用例转化为测试脚本，然后再去编写代码，并要通过事先写好的测试脚本的验证。
下图给出了一个TDD的软件过程的简单描述。
如果进一步看TDD，就会发现更丰富的内容，包括客户需求卡片、单元测试、结对编程、持续集成、代码重构等。
升级会员 