个人博客作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 作业要求 |
| 我在这个课程的目标是 | 提高自己的团队协作能力，体会软件的开发过程 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读教材，对软件工程有了一个大概的了解 |
一、提出问题
问题1
问题来自7.2.4 “各司其职，对项目共同负责”一节。
问：如果我要做一件事情，但是周围的人有不少不同意见，短时间又不能完全说服他们，怎么办？
答：对此事负责任的角色要自己拿主意。
在大家共同完成一个项目时，的确会发生一些意见不统一的情况，书中说负责人要自己拿主意。但是怎么才能让意见没被采纳的其他人不感到自己被无视了，或者避免在意见存在冲突时产生矛盾呢？
可能因为我的性格是比较偏向去实现一个大家都满意的方案，有些时候会考虑太多周围的人的意见，而感到比较累。所以想知道团队合作中作为负责人和周围的人发生了意见分歧的话怎么处理比较好。
问题2
问题来自9.3 “PM做开发和测试之外的所有事情”一节。
是由一个松散的集体通过不断改进产品来取得成功，或者由某个有远见的个人主导？......牛人主导的项目，往往会大起大落；PM主导的产品中，“不犯大错”成了一个特点，微软的很多产品在长期的竞争中，靠“不犯大错”，从第三版开始，赶上并超越对手。这也是了不起的能力。问题是，在新的商业模式下，用户是否能耐心地等待第三版？
大起大落的风险较大，但“富贵险中求”，可能短期内会有很大的收益。走“不犯大错”的路线，可能需要较长时间的竞争才能体现出优势。在现在的商业模式中，是“大起大落”更好，还是“不犯大错”更好呢？
我个人更偏向于前者。感觉现在的IT产品更新换代很快，如果求稳的话，可能还没等到超过对手，这个产品就已经被淘汰了。
问题3
问题来自16.2 “创新的时机”一节。
很多大家正在使用的“新颖”产品，往往是经历了迷茫期之后的第二代产品，那些在泡沫最大的时候匆忙出现的第一代产品大多数都没有等到这一天。
如作者所说，获得成功的往往不是这个领域最初的开拓者，而是吸取了前人经验教训的后来之人。所以就是说不要在一个产业刚刚新兴的时候就匆忙加入吗？怎么才能把握时机呢？
问题4
问题来自3.2 “软件工程师的思维误区”一节。
这一节中提到了两种问题——“过早优化”和“过早扩大化”，它们一个是陷入了局部问题，一个是过于扩展，两者都会成为成功的阻力。既要不过分拘泥于细节的优化，但又不能太泛泛而谈一个大问题，怎样才能平衡局部和整体之间的关系呢？
问题5
问题来自3.3 “软件工程师的职业发展”一节。
这一节中讨论了“专和精的关系”，在学生时代，更应该侧重只钻研一门技术，还是每一项都做一些了解呢？在软件工程项目的各个职位中，哪些职位更偏重“作曲家写乐谱”型，需要对每种乐器都了解一些，哪些职位更偏重“演奏家演奏乐器”型，需要只精通一种乐器呢？
二、请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件
The first theory about software—prior to the creation of computers as we know them today—was proposed by Alan Turing in his 1935 essay On Computable Numbers, with an Application to the Entscheidungsproblem (decision problem).
最初与“软件”有关的理论由艾伦·图灵于1935年在论文《可计算数》中提出。
软件工程
The origins of the term "software engineering" have been attributed to various sources. The term "software engineering" appeared in a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION and was used more formally in the August 1966 issue of Communications of the ACM (Volume 9, number 8) “letter to the ACM membership” by the ACM President Anthony A. Oettinger, it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering.
“软件工程”一词的出现有多种来源。上世纪60年代，一些杂志刊物和会议上使用了“软件工程”这一词语。
Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy. At the time there was perceived to be a "software crisis".
Margaret Hamilton在阿波罗任务期间，曾独立地将这门学科命名为“软件工程”，地点位于MIT Draper 实验室。
她是这样描述如何创造出“软件工程”这一术语的：
When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new 'term' per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.
当她第一次想出这个词的时候，很长一段时间里，大家都把它当成一个笑话看待。直到有一天，一位备受尊敬的硬件学家在一次会议上表示，他同意她的观点，即构建软件的过程也应被视为一门工程学科。
参考资料
三、附加题：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
微软趣事
在微软联合创始人比尔·盖茨(Bill Gates)于1975年写给另一位联合创始人保罗·艾伦(Paul Allen)的一封信件中，盖茨首次提到了“微软”(Micro-soft)这个名称，该名称的寓意是“微型计算机”(microcomputer)与“软件”(software)的结合体，但其英文名称中间有一个连字符。
任何一家公司都有自身传统，微软也不例外。微软员工已形成这样的惯例：每当庆祝自己加盟微软的周年纪念日时，会专门拿出M&M巧克力与同事分享。
据悉，最初有人在微软园区附近抛弃了一些不愿再养的兔子宠物，这些兔子便在微软园区内生存下来并成群繁殖。《西雅图时报》1998年的一则文章称，不仅微软园区存在兔子数量过多问题，当地其他一些公司也深受其害。
四、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
使用人数统计
| Name | Users |
|---|---|
| GitHub | 31,000,000 |
| Bitbucket | 5,000,000 |
| Launchpad | 3,965,288 |
| SourceForge | 3,700,000 |
| GitLab | 100,000 |
| GNU Savannah | 93,346 |
| OSDN | 54,826 |
| Ourproject.org | 6,353 |
优缺点
Microsoft TFS
-
优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用
-
缺点：能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能
Github
-
优点：基于web，允许你使用Git的源代码管理功能
-
缺点：可能不是捕捉创意过程和记录创意点子的最佳工具
Trac
- 优点：非常灵活，可以随心所欲控制，可以和SVN集成
- 缺点：功能不是很强大
Bugzilla
-
优点：免费，有中文版支持
-
缺点：快速搜索结果不准确，只能管理缺陷
Apple XCode
-
优点：编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码
-
缺点：更新版本后，某个插件可能会失效
五、动手实践
Git
使用Git保存对README.md的修改并上传
GitHub
在GitHub上可以看到已经成功修改
