《软件非工程1(fV30)教材》由会员分享，可在线阅读，更多相关《软件非工程1(fV30)教材（22页珍藏版）》请在金锄头文库上搜索。
1、软件工程 第三组 张清健 陈敏军 陈明艳 李桂萍 沙尔合提 11.17 1.解释为什么对新系统来说 快速交付和部 署要比这些系统的具体功能重要？ 时效性 可靠性 风险性 2.解释敏捷方法的基本原理是如何能带来加 速的软件开发和部署？ 敏捷的各种实践中，能够加速软件开发的因素有很多，比如： 1、加快对客户需求变化的响应 2、减少产出不必要的工件 3、强化沟通，降低因沟通导致的损耗 4、建立自组织的团队，激励团队人员 5、使开发人员专心从事当前事务 敏捷联盟宣言: 个体和交互高于过程和工具; 可以工作的软件高于详尽的文档;(甲骨文公司) 客户合作高于合同谈判; 响应变化高于遵循计划; 3.什么情况
2、下劝告不用敏捷开发来开发工程 ? 敏捷开发宣言里各种许愿拔掉敏捷二字不也是所有项目开发的理想？所以为了 解决什么问题而采用敏捷式开发？为了改善工作流程加快效率?那设计师修改到死的 工作情况在敏捷开发里要怎么被改善? 我觉得敏捷开发适用头脑清楚的人，只是这种人往往是大神级的了。和大神 PM 、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、别人在干嘛，还能 Cover 一点别人的领域，知道解决这个问题可以往目标更进一步，这种合作模式才有办法 做到敏捷，而不是因为抓漏抓虫在修改。是啦这也算朝目标迈进，但创新改 良产品和让产品看起来洞没那么大的改来改去本质上是两回事啊！敏捷开发 只是个
3、方法，不是万灵丹。 4.极限编程是用故事情节来表达用户需求的,每一 个情节写在卡片上,讨论这种描述方法的优点和 缺点？ 我觉得XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周 密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目 都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求 是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简 单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以 非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地 调整开发过程。 因此,它的优点有以
4、下几点: 1. 对公司的开发者而言，XP可以让开发者专注于编写 代码，避免了不必要的文案工作 及会议。它营造了更好的工作氛围，更多学习新技术的机会，并令你的员工有成就 感。 2. 相比于传统开发方式，通过XP开发的软件缺陷更少。 它令公司对其商业需求的变化 做出更快速的反应，而且价格低廉，开发者也少有怨言。 从公司管理的角度来看，这种方法可以减少你对牛人 的依赖。同时它也提升了员工满意度。 在XP下，你无需设计未来。你设计今天。整个理念 就是，写简单代码，以及在需求改变的时候相应的改变你的设计。 你的开发人员是两人结队编程，从头到尾都在一起 工作。代码有着统一的规范性和可读性，大家都能够理解代
5、码并按照需求改善代码。 而且，结队编程在一定时间内是最有效率的。 XP项目与传统软件开发的最大区别在于，XP是以测 试推动开发。在XP下可以在编写代码之前开始测试。每一个环节的代码都要100%通 过单元测试。没有unit-level bug和回归bug也意味着开发者能够专注他们自己的工作。你的客户确立自动验收测试以确认该软件的每一 个功能的运行质量。 在XP下，每一个测试阶段之后都可以发布一个小体 积软件。最重要的是，每一阶段完成时都有些东西能够拿给客户看。 在传统流水线方式下，如果项目计划变更，之后要赶 上档期就会需要很大投入。XP的方法可以令你提前判断进程。 极限编程从最简单的解决方案入手
6、。你可以在之后添 加其他功能。这个概念的目的在于为今天做计划，设计及编码，而不是为了明天。 来自系统，客户和团队的反馈是极限编程成功的 关键。在这个概念的指导下，系统的漏洞在前期就被发现，客户可以反复进行验收测试 ，从而最大限度的极限编程 而它的缺点在于: 以代码为 中心，忽略了设计； 缺乏设计文档，局限于小规模项目； 对已完成工作的检查步骤缺乏清晰的结构； 质量保证依赖于测试； 缺乏质量规划； 没有提供数据的收集和使用的指导； 开发过程不详细； 全新的管理手法带来的认同度问题； 缺乏过渡时的必要支持。 5. 解释为什么测试优先的开发能帮助程序 猿获得对系统需求的更好的理解 不同于先写代码，然
7、后对这些代码写相应的测试程序，XP是先写测试程序，再写代 码的。这就意味着，再写程序的同时你可以运行测试代码。先写测试隐含地定义了 界面和要开发的功能的行为描述。减少了对需求和界面的误解。对于任何在系统需 求和实现该需求的代码之间有明确关系的过程中都可以采用此方法。测试优先开发 中，实现任务的人必须彻底理解描述，这样他们才能为系统编写测试。这意味着在 描述中的二义性和遗漏必须在实现开始之前得以澄清。程序员在这个过程中对系统 需求理解会更加深刻。 困难：测试优先的开发和自动测试通常导致要编写和执行大量的测试程序。然而， 这种方法并不一定使程序得到彻底的测试。原因有下：1、程序员更喜欢编程而不是
8、测试，有时候在测试时走捷径。例如，写出不完整的测试无法检测所有可能的异常 情况。2、有一些测试是非常困难的。例如。在复杂用户界面中，通常编写用于实现 “显示逻辑”和屏幕间工作流的测试单元是十分困难的。3、对一组测试的完整性的 判断也是困难的。尽管你可以有很多系统测试，你的测试集合可能不能提供完整的 覆盖。系统的关键部分可能得不到执行，所以也就是没有经过测试的。 6.给出4个理由说明为什么结对编程的软件 生产率比程序猿单个编程时高 1、它可以促进参与项目的程序员自身的提高，一对程序员工作的时候，水平较低的 一方会潜移默化地受水平略高的程序员影响，学到一些新的东西。而水平高的一方 同样因为不断地把
9、自己的想法说出来而整理了自己的思路。 2.一定时间周期地打乱配对，让参与项目的人员相互转换位置，使得维护繁杂的文 档变得不那么重要。大家分组打乱后，口头的交流很容易让所有人都熟悉每个模块 ，这样对于公司也很有好处，项目中万一有人离开，也不至于影响到整个项目。最 后，开发过程变得更为有趣，任何人的交流变得很多，大家关系更为融洽。 3.结对编程有一种相互督促的作用，在一边工作疲惫状态不好使，另一边会起一个 鼓励和激发斗志的作用。 4.有助于支持重构，这是一个软件改善的过程。 7.比较scrum和第23章介绍的常规的计划驱 动的项目管理方法. Scrum 方法是一个通用的敏捷方法,注重迭代开发的管理
10、,有3个阶段:1规划纲要 2冲刺循环 3 项目结束 Scrum 中心阶段冲刺循环过程的要点: 1有固定长度 2起点积压的任务(用户紧密参与,提出新需求 或任务的建议) 3项目团队所有人员与用户一起选择要开发的特性和功能 4团队组织软件开发 5对 已做工作复查并交付给用户。 优点：使开发团队不受外界干扰，工作方式取决于遇到的问题和团队，对如何写需求，测试优先开发 等不作具体要求。其中，1.产品被分解成一组可管理和可被解决的块 2.不稳定的需求并不阻碍工程进 展 3.整个团队的所有事情可见，改善了团队的沟通 4.用户看到增量的及时交付，且得到对产品如何 工作的反馈 5.客户和开发者之间彼此信任，创
11、造了积极文化和项目成功的希望。 常规的计划驱动的项目管理方法：初始阶段-基于用户情节，应包含在系统中。在项目启动前，开发 团队与用户试着定义一系列情节。评估阶段-项目组阅读并讨论这些情节，按所需时间将情景排序并 “速度”估计。 发布规划选择完善情景。 迭代规划开发人员将情景拆分各个开发任务进行详细 规划。优点：整个项目组对迭代过程要完成的任务有整体认识；开发者自行选择任务，激发积极性更 好的完成任务。缺点：依赖于客户参与；对于庞大且分布在不同地点的项目组或组员频繁变动的项目 组而言，不可能每个人参与到项目最核心的集体规划中。 8.系统是要支持将软件需求翻译成形式化软 件描述，评论下列开发策略的
12、优点和缺点 策略a：优点：使开发团队不受外界干扰，工作方式取决于遇到的问题和团队； 缺点;需求范围面不足，导致设计的软件适用性弱；对于庞大系统，很难做到 解决问题全面，只适用于小型系统。 策略b：优点：评估项目做到尽可能全面，使系统更完善。 缺点：采用java开发系统，导致其他语言或软件不适用，大大缩减了应用范 围。 策略c：优点：增强和改善了团队的沟通，建立了客户与开发者间的信任；采用敏捷 开发系统，不受外界干扰，大大提高了创新能力。 缺点：受项目组员的技术及人员变动的影响较大，很难突破创新，在大型公司 中很难引入，可能在文化上受到抵制。 9.对于团队成员采纳开发团队的观点而忽视 用户队员的
13、需求，写出三个建议 计划驱动开发：迭代发生在各个活动之中，用正式文件在软件过程的各个阶段之间 进行沟通，例如 需求将演化。然而我们需要考虑详细的描述和设计是否很重要，用 户反馈是否切实，预想的系统寿命是多少？ 极限编程：客户亲密地投入到系统需求的定义和优先权排序工作中，但是它使软件 结构有变坏的趋势，变得越来越难实现，代码经常重复。 结对编程：支持共同拥有软件的和共同对系统负责，担当了非正式的复查过程有助 于支持重构，缺点是编程效率低，容易出错。 10.为了降低成本和交通环境的影响。 请写出你将如何应对这些问题 大型公司通常有质量保证流程和标准，当团队成员技术都比较高时，敏捷方法似乎 能工作得
14、更好，然而在大型机构中员工的技术和能力很可能是层次不齐的，那些水 平较低的员工可能成为无效的员工。此外员工可能从文化上抵制敏捷开发。 解决方法：引进和维持敏捷在大型机构中的使用是一个文化改变的过程，文化改变 需要一段很长的时间去实现，而且通常需要先改变管理方式才能实现，大型机构中 希望应用敏捷需要传道者去推动改变，他们必须投入很多资源去改变流程。 11.对于什么类型的系统敏捷开发方法特别有可能 成功？ 小型和中型软件产品开发。 定制软件开发组织中,有一个客户参与开发过程的明确承诺。 12.列出敏捷方法的5个原则？ 客户参与； 增量式交付； 人非过程； 接受变更； 维护简单。友情提醒：P37 1
15、3.列表4个在决定是否采用敏捷的软件开发方法 时应该考虑的的问题？ 是一个增量交付可以现实的吗？ 什么类型的系统正在开发？ 预期的系统生命周期是什么？ 开发团队是如何组织的？ 系统是否受到外部监管？ 正在开发的系统有多大规模？ 14.极限编程的三个重要的特点是什么? 需求表示为脚本；P40 结对编程； 测试优先的开发。 15.测试优先的开发是什么? 当系统功能是被认同的,测试的代码实现的功能是在代码之前编写的。测试是自动的 并且新的增量添加到系统中时运行所有的测试。 16.测试优先的开发的可能出现的问题是什 么? 程序员可能在开发测试中采取捷径,系统测试是不完整的。 一些测试很难写的。 很难判断一组测试的完整性。 17.简要描述结对编程的优点？ 详情见P44 18.Scrum冲刺是什么? 在一个短期的(3 - 4周)计划周期里,完成的工作要做评估,选择功能的开发、软件实 现和交付系统利益相关者。 19.将敏捷方法引入到大型企业的障碍是什么? 项目经理可能不愿接受新方法的风险。 在大公司建立的质量程序可能不兼容非正式的敏捷方法的方法文档。 如果一个公司的计划驱动的开发有悠久的历史，可能有文化抵制新方法的引入。 谢谢观看
