软件工程第一次阅读做业

项目	内容
做业所属课程	BUAA_SE_2019_LJ
做业要求	第一次阅读！

1. 看完教材《构建之法》，列出仍然不懂的问题。

1. 如何在团队中创建相互信任的关系？

   MSF提倡自下而上的计划，每一个人有充分的权力估计并决定本身的任务须要多长时间。

     这句话来自书中7.2.3节。“充分受权给团队和成员”意味着团队成员之间是相互信任的，只有在信任的基础上才能给团队成员充分的受权。不过即便没有信任，也是能够对这个原则生搬硬套的，可是这就将信任流于形式了。首先，信任是双向的，第二，团队成员应该是值得被信任的。在一个新组建的团队中，团队成员尚且不能相互认识，如何快速地创建起真正的信任呢？

2. 在软件开发中，如何应用建模方法？

     这个问题来自11.2节的“图形建模和分析方法”。这一节介绍了多种图形建模的方法，我也在以前的课程中使用过ERD、DFD、UML，但结果是，就是书中所说的，有了模型，殊不知道下一步该作什么，或者，模型与后续的工做脱节，模型没有可以给以后的实现予以足够的指导。最后，画图的目的就是为了画图。出现这个问题，我以为可能有这样的缘由，模型与最终实现抽象层次不一样，对于那些实现中的复杂细节，不知道应该如何体如今模型中，在模型中应该体现多少，或者说，在设计模型的时候，应该体现哪个层次。那么，如何才能将建模方法融入软件的设计和实现中，避免为了建模而建模呢？

3. 如何进行量化的绩效管理？

     17.6节介绍了衡量我的在团队中的绩效的方法，例如根据工做量，bug数量，队友评估等等。每一种方法都有必定的合理之处，但又存在着明显的不足。

   纯粹强调外接的驱动因素（金钱的报酬或惩罚）仅仅对体力劳动或有明确规则的活动有效（奖金约定，结果越好），但对于须要创造性思惟的活动，即便是简单的认知能力的活动，更多奖金反而起到相反的效果。

     若是认为软件工程师的工做是“须要创造性思惟的活动”，按照书中的观点，咱们在进行绩效管理的时候就须要注意内部的驱动因素。如今的问题是，课程评分中有一项团队贡献分，须要在团队成员中分配，咱们不得不面对如何量化我的绩效的问题。那么是否存在一种量化绩效的方法，能给出每一个人贡献的比例呢？

     下面给出个人愚见。既然内部驱动因素影响着团队成员的工做效率，不妨从内部驱动因素入手。关注“自主性”，书中解释说“由本身决定工做的部份内容”，我认为在绩效评比的时候也发挥自主性，每一个人主张本身的贡献比例，给出本身作了什么，对团队的贡献在哪里，有多大，分析为何是这个比例。而后团队成员在一块儿讨论，每一个成员分别对其他每一个人的主张发表意见，最终讨论得出一致结论，肯定每一个人贡献的比例。若是这种方式可以施行的话，应该比计算代码行数或bug数会好不少。

4. 为何每日构建很重要？

   咱们的软件构建，就和脚手架同样，天天都要立着，倒下了就麻烦了。

     这句话来自11.5.2每日构建一节。这个比喻很形象，也符合直观，不过我还未能给出具体的论据来支持这个观点。

5. 若是错误的状况不少，怎么进行错误处理？

     书中4.3.3节错误处理说到，“若是你认为某事可能会发生，这时就要写代码来处理可能发生的错误状况”，若是错误的状况不少，要照顾每一种可能的错误，就须要编写冗长的代码来进行错误处理，这一过程就比较机械和繁琐。好比编译器在进行错误处理时，错误的状况无穷无尽，即便要分出每一种错误的类别都是很花时间而且容易遗漏的。这种状况下，我常常怀疑，是否有必要处理每一种可能的错误，有没有一种好的方法可以帮助分析各类可能的错误状况而无遗漏？

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

• “软件”是由John Tukey于1958年在其论文"The Teaching of Concrete Mathematics"中提出来的。
• “软件工程”一词是由Margaret Hamilton创造的。在1968年北约科学委员会召开的会议上正式使用。

3. 【附加题】：你们知道了软件和软件工程的起源，请问软件工程发展的过程当中有什么你以为有趣的冷知识和故事？

"It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter."

- Nathaniel Borenstein

Explanation

查看解释

  Borenstein说，没有哪一个通过职业道德培训的程序员会写出DestroyBagdad过程，基本的职业道德告诉他们，应该写一个DestroyCity过程，而将Bagdad做为一个参数。
  这段话的幽默之处在于，读者会认为程序员的受到的道德(ethics)教育与其余人相同，好比“不要杀人”，“作一个好人”之类的，然而，Borenstein说的是程序员的职业道德，具体地说，就是编码时的一系列规范(coding ethics)，用于在软件工程中写出高质量的代码。
  这段话有必定的误导性，但又不彻底是，这就是其幽默所在。要理解这段话，须要琢磨ethics一词的含义，翻译成中文后，因为找不到合适的词，反倒丧失了几分幽默。

4. 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？ （提示：搜索一下Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode）?

1. Microsoft TFS: 测试管理和软件生命周期管理工具

   优势：

   • 与Visual Studio等微软产品集成得很好，易于使用
   • 容易访问，能够从客户端、浏览器和Visual Studio访问
   • 源代码管理方面：方便的签入/签出
   • 项目管理方面：易于管理bug

   缺点：

   • 网页的用户界面和用户体验比较糟糕

2. GitHub: 提供代码管理，软件协做开发的平台，用户数31,000,000

   优势：

   • 漂亮的UI
   • 能够与不少开发工具集成
   • 使用Git便于代码管理
   • 方便代码复审等多人协做

3. Git

   优势：功能强大，很好地处理分支，适合大型项目使用

   缺点：难于理解，对初学者不友好

4. Mercurial

   优势：比Git易于使用

   缺点：比Git功能弱，没有部分签出功能，不适合大型项目

5. BitBucket：用户数5,000,000

   优势：

   • 仓库和项目的管理简单易使用
   • 有方便的可视化工具显示分支
   • 与Atlassian产品集成得很好

   缺点：

   • 相比GitHub，缺乏第三方工具的集成
   • 搜索方式不如GitHub丰富

6. BugZilla

   优势：缺陷报告能够处处，支持多项目的缺陷跟踪。

   缺点：不支持自定义界面