复旦MSE复习资料-软件工程部分(SE01 概论).pptVIP

* Scrum敏捷过程模型（P63图4-3） 原则(和敏捷宣言一致）： 组织小型团队以达到：沟通最大化，负担最小化，非语言描述、非形式化知识”。 过程对技术和业务变化必须具有适应性，以“保证制造具有最好可能的产品”。 过程生产频繁发布“可检查、可调整、可测试、可文档化、可构建”的软件增量。 开发工作和开发人员划分为“清晰的、低耦合的部分或包”。 坚持在产品构建过程中进行测试和文档化。 Scrum过程提供“在任何需要的情况下都能完成产品的能力。 敏捷过程模型 * 特征驱动开发（Feature Drive Developmeng,FDD）（P65图4-4） 特征-是可以在2周或者更短时间实现的具有客户价值的功能。 FDD更加强调项目管理原则和技术。在特征设计和构建阶段定义6个里程碑：设计走查，设计，设计检查，编码，代码检查，促进构建 敏捷过程模型 软件神话 什么都是浮云 不要用机械工程的概念来套用 * * 观点之一 我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。 客观事实 好的参考书无疑能指导我们的工作，充分利用书籍中的方法、技术和技巧，可以有效地解决软件开发中大量常见的问题。但实践者并不能依赖于书籍，因为在现实工作中，由于条件千差万别，即使是相当成熟的软件工程规范，常常也无法套用。另外，软件技术日新月异，没有哪一种软件标准能长盛不衰。 观点之二 如果我们已经落后于计划，可以增加更多的程序员来赶上进度。 客观事实 软件开发不同于传统的机械制造，人多不见得力量大。如果给落后于计划的项目增添新人，可能会更加延误项目。因为新人会产生很多新的错误，使项目混乱，并且原有的开发人员向新人解释工作和交流思想都要花费时间，使实际的开发时间更少，所以制定恰如其分的项目计划是很重要的。 【讲解】　　假设一个项目估计需要12人月工作量，指定由3个人在4个月内完成，如果第一个月的任务花了两个月才完成，那么增加人力的结果如何？假设增加2个人参加项目，不论新增加的人适应能力有多强，总需要有人去帮助了解熟悉情况，如果这些工作占用了一个月的时间，这样又有3个人月工作量在新计划之外。由于人员增加，工作任务需要重新划分，到第3个月结束时虽然有5个人在工作，实际上余留下7个人的工作量。 观点之三 项目需求总是在不断变化，但这些变化能够很容易地满足，因为软件是灵活的。 客观事实 软件需求确实是经常变化的，但这些变化产生的影响会随着其引入时间的不同而不同。对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代价越少，修改越晚代价越大，就跟治病一样道理。 观点之四 有了对目标的一般描述就足以开始写程序了，我们以后可以再补充细节。 客观事实 不完善的系统定义是软件项目失败的主要原因。关于待开发软件的应用领域、功能、性能、接口、设计约束和标准等需要详细的描述，而这些只有通过用户和开发人员之间的通信交流才能确定。越早开始写程序，就要花越长时间才能完成它。 观点之五 一旦我们写出了程序并使其正常运行，我们的工作就结束了。人们有时认为，只有差的软件产品才需要维护。 客观事实 从如图1.12所示的统计数据来看，软件投入的50%～70%是花费在交付给用户之后。品质差的产品被丢弃，只有好的产品才需要维护和改进。 观点之六 一个成功的项目唯一应该提交的就是运行程序。　　 客观事实 软件包括程序、数据和文档，其中文档是成功开发的基础，为软件维护提供了指导。 帮助回忆 观点一：开放软件源代码就一定好。 观点二：软件质量问题可通过软件测试得到彻底解决。 * 观点一 一般人都认为开放源代码对一个软件系统的完善有很好的促进作用，因为这样可以集合很多人的智慧，但这种观点并不完全正确。大家赞同开放源码，其实很大程度上是因为先有了Linux成功的例子，而Linux的出现和成功是有它一定的背景的，很大程度上是因为不支持源码开放的代表--微软的缘故。开放源代码对促进全球软件和信息技术行业的快速发展是很有益处的，但是关于源代码的GPL授权方式目前还看不到它对软件企业发展的好处。一味强调过度开放源代码，在现在盗版泛滥的时代，拥有源代码的公司如何得到回报，没有回报就没有进一步研发资金，软件的发展从何而来。  * 观点二 为了克服软件危机和提高软件质量，人们进行了大量的研究和实践。最初的重点是着眼于技术革新，从各种软件工具（如编辑、编译、调试工具等等）研制开始，发展成为对开发各阶段进行全面支持的计算机辅助软件工程（CASE）环境。同时，注重软件开发模型研究，也就是如何划分软件开发过程的不同阶段，并针对不同阶段开展了有关技术和方法的研究如需求工程、设计工程、程序设计方法学、软件测试等等。 通过