软件工程博客做业1

这个做业属于北航计算机学院软件工程
这个做业的要求位于此连接
我在这个课程的目标是：积累软件项目开发经验，取得大于85分的成绩。
这个做业在以下方面帮助我实现目标：快速浏览全书，掌握课程的总体结构。经过查阅资料，了解软件工程的历史。

1. 快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的我的博客上。

（1）第33页，将代码段

for(int i = 0; i < m_wordList.Count; i++)

更改成

int count = m_wordList.Count;
for (int i = 0; i < count; i++)

第34页写道：“你们也要注意避免没有作分析就过早地进行‘效能提升’。”
问：相似上述代码的优化，是否能够视为必然可以提升效能，而无需每次都进行分析呢？

（2）第7章 第137页
“有些团队把开发和测试有意无心地对立起来，好像两者是矛盾的。” “这种对立情绪，也许在短时间内能刺激成员的工做热情，而从长远来看是有害的。”
北航计算机学院的“面向对象设计与构造”课程的每份做业都采用以下的评分标准：修课的同窗代码随机分配至其余人手里，找出别人的BUG会为本身加分，而本身的程序被别人找出BUG会被减分。这种评分规则是否能够看做违反了上述原则，而应被废止或修改呢？

（3）第8章 需求分析 之中的内容，有一部分与北航经管教材上的知识重合。例如167页的“用户满意度模型”、177页的“分而治之”思想。
能否认为软件工程在进行需求分析时，较多地借鉴了传统管理学知识？或者认为软件工程是管理学的一个分支？

（4）11.5.2 每日构建（235~237页）
这一节的写做有些漏洞。阿超与小飞的对话，主要论证的是“构建”的重要性，却忽略了论述“每日”进行构建的必要性。
因此，每一天都进行构建工做是不是有必要的？若是不是，这一名称是否有修改的必要？

（5）第14章 质量保障 第312页
做者设想了第三方的软件质量认证服务将为人们的生活带来的便利。那么，第三方认证软件质量为何尚处于起步阶段，其难点在哪里？

2. 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 什么时候、何地、何人？

根据百度百科“软件工程”词条的描述，软件与软件工程的发展经历了以下阶段：

• 程序设计阶段：1946~1955年
  此阶段的特色是：尚无软件的概念，程序设计主要围绕硬件进行开发，规模很小，工具简单，无明确分工（开发者和用户）。
• 软件设计阶段：1956~1970年
  此阶段的特色是：硬件环境相对稳定，出现了“软件做坊”的开发组织形式。开始普遍使用产品软件（可购买），从而创建了软件的概念。软件系统的规模愈来愈庞大，高级编程语言层出不穷，应用领域不断拓宽，开发者和用户有了明确的分工，社会对软件的需求量剧增。但软件开发技术没有重大突破，软件产品的质量不高，生产效率低下，从而致使了“软件危机”的产生。
• 软件工程阶段：1970年至今
  因为“软件危机”的产生，迫令人们不得不研究、改变软件开发的技术手段和管理方法。今后软件产生进入了软件工程时代。此阶段的特色有：
  第一代软件技术：结构化程序设计在数值计算领域取得优异成绩；
  第二代软件技术：软件测试技术、方法、原理用于软件生产过程；
  第三代软件技术：处理需求定义技术用于软件需求分析和描述。

“软件”一词的提出者通常认为是美国数学家John Tukey。他的维基百科中有以下论述：

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.

而“软件工程”的提出者和实践者通常认为是Margaret Hamilton。她开发了“阿波罗”飞船飞行控制软件。在一次采访中她提到：

软件在这个计划的初期还被看成初初学步的孩子通常对待，彻底不像其余工程学科；例如像硬件工程那样的受到重视，并且在你们的眼光中他就像是艺术、魔术通常，而不是一门科学。我一直以来坚信这项发明流着艺术与科学的血液，虽然当时不多人是这么想。所以，我致力于为软件以及那些发明者争取应有的正统性与尊重，因此我开始使用“软件工程”这样的字眼来将之与硬件还有其余工程学类作出区别。

——引用自《就是她，写出了让阿姆斯壮成功登录月球的代码！》
事实上，尽管Hamilton是半路出家，可是她在软件测试方面贡献了一些卓有成效的思想。

一天，劳伦在摆弄 MIT 控制舱模拟器的显示器键盘一体机 DSKY。当她在键盘上乱按的时候，一条错误信息忽然出现。劳伦不知怎地启动了一个叫作 P01 的预运行程序，本来正在飞行状态的模拟器一会儿崩溃了。
虽然通常来讲宇航员不会犯这样的错，但玛格丽特仍是想加一段代码防止这种情况的发生。这一提议被 NASA 否决，「他们一遍又一遍地跟我说宇航员不会犯任何错误，他们被训练得近乎完美，」玛格丽特说。她转而加了一句程序说明，全部 NASA 工程师和宇航员都能看到：「不要在飞行过程当中按下 P01」。她回忆说，「全部人都说，『那样的事情永远都不会发生』。」
但事情的的确确发生了。时间大约在 1968 年的圣诞节，进入阿波罗 8 号飞船的第五天飞行，宇航员吉姆·洛威尔 (Jim Lovell) 不当心在飞行中启动了 P01 程序。当电话从休斯顿打来的时候，玛格丽特正在仪器实验室的 2 层会议室。启动 P01 程序致使此的导航数据所有清空，阿波罗计算机没法计算出如何返回地球。
玛格丽特和 MIT 的程序员们须要想出一个补救的办法，必须是无错漏的完美办法。在花费 9 小时钻研过面前 8 英寸厚的程序列表后，他们有了一个计划。休斯顿方面须要上传一份新的导航数据，然后一切都会顺利进行。

——引用自《代码传奇 | 明明能够靠颜值 却用代码把人类送上了月球的女人——Margaret Hamilton》

4. 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

git

Git是一个开源的分布式版本控制系统，能够有效、高速地处理从很小到很是大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
优势：

• 适合分布式开发，强调个体。
• 公共服务器压力和数据量都不会太大。
• 速度快、灵活。
• 任意两个开发者之间能够很容易的解决冲突。
• 离线工做。

缺点：

• 资料少（起码中文资料不多）。
• 学习周期相对而言比较长。
• 不符合常规思惟。（主要指远程仓库、分支等概念）
• 代码保密性差，一旦开发者把整个库克隆下来就能够彻底公开全部代码和版本信息。

Mercurial

Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。其是基于 GNU General Public License (GPL) 受权的开源项目。
优势：

• 更轻松的管理。传统的版本控制系统使用集中式的 repository，一些和 repository相关的管理就只能由管理员一我的进行。因为采用了分布式的模型，Mercurial 中就没有这样的困扰，每一个用户管理本身的 repository，管理员只需协调同步这些repository。
• 更健壮的系统。分布式系统比集中式的单服务器系统更健壮，单服务器系统一旦服务器出现问题整个系统就不能运行了，分布式系统一般不会由于一两个节点而受到影响。 对网络的依赖性更低。因为同步能够放在任意时刻进行，Mercurial 甚至能够离线进行管理，只需在有网络链接时同步。

缺点：

• 使用人数太少。

Trac

Trac是一个为软件开发项目须要而集成了Wiki和问题跟踪管理系统的应用平台，是一个开源软件应用。Trac以简单的方式创建了一个软件项目管理的Web应用，以帮助开发人员更好地写出高质量的软件。

Bugzilla

Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它能够管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。
Bugzilla是一开源Bug Tracking System，是专门为Unix定制开发的。

参考资料：

GIT
Mercurial
trac
Bugzilla