现代软件工程 第五章 练习与讨论

15.3.0 案例分析 可以看看这两个学生项目的例子,推断出这些团队的血型: STG游戏的跳票(为了完美,推迟了7天,但是7天之后也没有发布……)[leal1] [i] 英语学习软件(说了“明早发布”,但是明早一直没到)[ii] 15.3.1  反动分子阿超 在最后的稳定阶段,阿超不断地把事情推到下一个版本,二柱和果冻都不耐烦了——为什么不拼一下,把所有事情在第一版搞定? 阿超: 有两种做法—— 1. 根据事情的轻重缓急,安排大部分事情在下一个版本做.正因为我们对项目.团队.商业模式有信心,才会

13.5.2  有错不改 果冻: 微软的产品经过这么多版本的不断完善,应该是把所有问题都搞定,“止于至善”了吧? 阿超: 那也不一定,在非常有名的电子表格软件Excel中,就有这样一个Bug:Excel 的日期计算功能认为1900年是一个闰年,这是不对的,但是它愣是一直没有改正这个错误. 众人: 真的?为什么屡教不改呢? 阿超: 故事是这样的,当时这类电子表格软件的市场领头羊是Lotus 1-2-3这一款软件.它的日期计算功能有一个Bug,就是把1900年当作闰年.这类软件在内部把日期保存为“从

7.7  移山开发方法——比TFS敏捷更精简 几个软件学院的学生来请教阿超,同学们自豪地说,我们要用全套TFS敏捷开发模式开发项目! 真的?阿超不敢相信. 同学: 对!我们要用全5个工作项类型 – 任务.缺陷.场景.风险.服务质量需求. 阿超: 你们有多少实战项目的经验?哦,都没有.这么说这是你们第一个真正的实用项目,我建议你们先忘记这么多工作项类型,把时间花在写代码上好了. 同学: 可是老师要我们上敏捷开发模式呀? 阿超: 当敏捷模式变成强迫,那还能敏捷到哪儿去呢?如果你们非用不可,我建议你们

6.3.1  什么时候适合选择敏捷 我们看了这么多方法论之后,一些同学一定比较困惑,到底选择哪一种开发方法比较好呢? 这在实践中不是难题,有学者还列出了一些简单的问题来帮助人们做决定[i]: 表6-3 问题引出方法 问题 Yes – 偏向传统的瀑布+文档的流程 No –   偏向敏捷流程 1. 项目需要有明确的spec 么? 2. 项目没有明确的用户,也无法联系用户进行沟通 3. 软件系统是大型的么? 4. 软件系统是复杂的么?例如实时系统 5. 软件的生命周期很长么? 6. 你使用比较差的软件

4.7.1  结对项目的案例和论文 在现代软件工程教学的过程中,同学们已经总结了不少切身体会.例如: 总结1[i]:那是project到了比较关键的创造阶段,整整一天,我们俩椅子靠椅子的坐在电脑前,一边讨论一般coding,那次才真正的体会到结对真的能够带来效率.一整天的coding是容易走神的事,还好有pair在旁边指导,总是不断在我敲某某变量之前提前告诉我成员变量的名字,数据修改时帮忙检查是否有漏掉的,变量和函数定义的时候一起为其取名字,感觉有点眼花了,就换了个角色,我也开始对他“指指点点”

1  选哪一种医生? 作为一个软件工程师, 你觉得自己表现如何? 有没有这样的体会: 看书的时候觉得“技止此耳”,开发项目的时候才觉得实际情况和书上讲的都有一些出入,一些重要的细节书上没有提.我们很多人是边看Asp.net的书, 边开发Asp.net 的项目,这相当于一边看医学书一边动手术…… 如果你是病人,你希望你的医生是下面的哪一种呢? a)     刚刚在书上看到你的病例, 开刀的过程中非常认真严谨, 时不时还要停下来翻书看看…… b)    富有创新意识, 开刀时突然想到一个新技术. 新

1  如何避免在产品开发后期不断有重大修改,导致其它模块的连锁反应? DCR Tell mode vs. Ask mode设计变更 在项目早期,如果大家觉得要做一个设计变更,便可以采用告知模式(Tell-mode)的形式,也就是说,修改方必须通告所有关系人:“我在这里修改了某某界面, 我在某个API 增加了一个参数.”但是修改方不必取得其他关系人(或者模块)的事先同意,就是说可以先行设计并编码.当然,如果其他关系人不同意,修改还是不能签入. 当项目进行到稳定阶段,例如达到了代码完成(CC)阶段,

软件工程-----第五章 总体设计(复习) (1)概要 经过需求分析阶段的工作,系统必须"做什么"已经很清楚了,现在是决定"怎样做"的时候了.总体设计的基本目的是系统应该如何实现.他最重要的一项工作是设计软件结构.因此,总体设计又称为概要设计或初步设计.通过这个阶段的工作确定划分出组成系统的物理元素-----程序.文件.数据库.人工过程和文档. (2)设计过程 总体设计过程通常是有两个主要阶段组成:系统设计阶段,确定系统的具体实现方案:结构设计阶段,确定软件结构.

第五章—软件工程中的形式化方法 软件的设计过程就是一个建立形式规约的过程. 当规格说明用非形式化方法说明时,可称之为“规格说明”,当用形式化方法说明时,可称之为“形式规约”.已建立的形式化方法可分为操作类和描述类.形式证明与验证技术主要包括模型检测和定理证明,模型检测主要适用于有穷状态系统,优点是完全自动化并且验证速度快,进行定理证明的过程就是应用这些公理或推理规则来证明系统具有某些性质.程序求精是将一个抽象程度低.过程性强的程序替代一个抽象程度高.过程性低的程序. 目前应用较为广泛的形式化方法