2017BUAA软工个人作业Week1

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

1.第四章讲到两个人的结对编程：

结对编程是一个渐进的过程，有效率的结对编程不是一天就能做到的。结对编程是一个相互学习，相互磨合的渐进过程。……一开始，结对编程很可能不比单独开发效率更高……

我了解到结对编程一开始必然有一个磨合熟悉的过程，在这个过程中可能有人会不习惯时刻在对方视线下工作的情况，也可能两个人水平有差距，会出现一个人一直在听另一个人的意见的情况，我想问如何能让这种磨合过程的时间尽量缩短呢，有没有什么可行的策略？

2.在第六章讲到敏捷开发的适用范围表格，提到微博的开发是忙乱的开发流程，导致了用户信息数据丢失，还提到：

要记住，有许多最佳实践在各种开发方式下都在使用，所以各种开发方式并不是井水不犯河水，老死不相往来的关系。

我可否理解为敏捷流程的开发在很多情况下会和其他开发方式相结合以达到提高产品可靠性的要求？如果是，那么敏捷开发和那种流程结合的最多也最好呢？

3.十一章提到了小强地狱，在开发人员的bug达到一个限定值时，可以采用限制其工作，将所有时间用于解决BUG到限定值以下，这样的方法会不会挫败该开发人员的积极性，导致其在后续的开发过程中无法跟上进度，陷入恶性循环？

4.在一个创新产品的设计开发过程中，如何定义用户需求是很困难的事情，很多情况下只能由团队成员臆想得到，因为这样一个产品本身也是没有原型的，在这种情况下，似乎只有调查问卷才能给出部分答案，但以我自己的经历来说，我基本都不会认真看这样的调查问卷，那我想问是否有更可行的收集用户需求的方式？

5.第五章讲到渐进交付流程即MVP方法：

MVP更强调更早获得用户反馈，为此可以在产品完成前就发布，强调产品的核心价值，为了突出核心功能，别的辅助功能可以不考虑或者用别的平台提供的服务来代替。

我想请问这种方法开发出来的软件是不是就是相当于每一个周期都在不断地打补丁，没有系统化的设计实现，是否会导致软件的臃肿化，可维护性变差？

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

答：

1.The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.

1953年8月，Richard R. Carhart在Rand公司的研究备忘录中最早使用了Software一词。

2.Hamilton coined the term "software engineering" during the Apollo space mission days。

Margaret Hamilton在阿波罗计划早期（1968左右）创造了这个词，在NASA；也有不同的说法：it was used in 1968 as a title for the World's first conference on software engineering, sponsored and facilitated by NATO.（software engineering）说是在1968年北约赞助的世界上第一次软件工程大会上作为标题被使用。

3.【附加】请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

百度了高德纳（Knuth）：《美国数学月刊》刊载过高德纳（TAOCP作者）一篇名为“卫生纸问题” 的论文，研究如何合理使用厕纸的算法，小节标题中使用了大量的“粪便学”词汇。编辑警告他，过度调侃的文风在我们这里是危险的，请三思！高替换了小标题里的某些词，但不想动文章标题，遂在给编辑的回信里写道：我用这个题目做过两次演讲，主题早已被广泛采用和讨论……云云。编辑无奈之下只好表示：“你的厕纸被接受了！”（斯坦福大学计算机科学系楼内的厕纸架可并放两筒厕纸，供如厕者取用。卷筒大小不等时，喜欢从大筒拿纸的叫big-chooser【大的选择器】，喜欢从小筒拿纸的则称little-chooser【小的选择器】；若两筒大小接近，一般人的选择可能是离手最近的。厕纸平时由janitor【看门人】负责更换，用完一筒换掉一筒；不过要是同时用完，恐怕就会有人遇上麻烦了……高德纳研究的是两筒纸同时用完的窘境出现的概率）

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

根据资料查阅的资料密集程度，粗略地给出用户人数排序（除了GitHub找到了人数统计，其他都没找到…）：GitHub（超千万）>Bugzilla>Mercurial>Trac

参考网址：

http://www.infoq.com/cn/articles/github-chinese-developers-annual-analysis-report/

https://www.zhihu.com/question/21943395

http://blog.csdn.net/dengsilinming/article/details/7999188

https://www.zhihu.com/question/20401926

https://www.zhihu.com/question/20403480/answer/25068499

https://baike.baidu.com/item/trac/7367196?fr=aladdin

https://baike.baidu.com/item/Bugzilla

https://zhidao.baidu.com/question/193468903.html

https://www.zhihu.com/question/34797982

https://zhidao.baidu.com/question/201831153417263125.html

软件名称	优点	缺点
Microsoft TFS	集成项目管理，版本控制，BUG跟踪，能有效实现SCRUM，与VS无缝接合	浏览器访问慢，XP无法访问，测试用例没有好的应用案例。
Git	版本库本地化，内容按元数据方式存储，利于完整克隆，支持快速切换分支方便合并。	概念过于复杂，语法设计随意，没有系统化，各版本命令有不兼容的情况，帮助提示晦涩难懂，缺乏良好的封装，一些简单的操作会用到过多的命令。
Mercurial	跨平台（基于python），相比git来说封装好，命令少，学习门槛低。	分支管理不灵活，例如branch出来就删不掉，支持的社区在功能和用户上都差一点。
GitHub	大量的开源项目用于分享，学习，自动email用户watch的项目的近况。	git命令的学习需要不断上手实践。
Bitbucket	支持hg(Mercurial)，易学易用，支持完全免费的闭源项目，以及人以内合作开发，支持中文。	易学易用但功能不如Github强大。
Trac	以简单的方式建立软件项目管理的web应用，力求不影响团队的开发流程，以面向进度模型为项目管理模型。有良好的扩充性，很方便地安装插件。	功能不够丰富强大。
Bugzilla	开源缺陷跟踪系统，提供强大的检索功能，可配置email公布BUG 变更，版本向下兼容。	界面很差。
Apple XCode	为iOS和Mac开发而设计，代码自动补全，便捷的代码管理器，自动生成类关系图、函数方法列表等。	不适合用来写Objective-C/Swift之外的语言。