读《构建之法》后的问题.

Q1. 在泛读《构建之法》这本书时，我在第一章看到这样一段文字（历史学家们说计算机系统的第一个Bug是一个蛾子，所以你们把软件的缺陷叫作Bug.其实很多工程师在那以前都用”Bug“来统称系统中的问题），有这个问题（Bug到底是什么？到底是软件使用或者测试过程当中，忽然出了须要维护的问题；仍是软件开发人员和用户的需求之间产生的分歧？为何对于Bug没有一个明确的解释?）。我查了资料发现存在这样的说法（所谓“（Bug）”，是指电脑系统的硬件、系统软件（如操做系统）或应用软件（如文字处理软件）出错。硬件的出错有两个缘由，一是设计错误，一是硬件部件老化失效等。软件的错误全是厂家设计错误。那种说用户执行了非法操做的提示，是软件厂商不负责的胡说八道。用户可能会执行不正确的操做，好比原本是作加法但按了减法键。这样用户会获得一个不正确的结果，但不会引发bug发做。软件厂商在设计产品时的一个基本要求，就是不容许用户作非法的操做。只要容许用户作的，都是合法的。用户根本就没有办法知道厂家内心是怎么想的，哪些操做序列是非法的。），可是根据我为数很少的实践，我有这样的经验（硬件中的Bug我不太了解，可是软件中的Bug仅仅是来自程序代码的出错。）。可是我仍是不太懂，个人困惑是（虽然bug不可消除，可是用户和软件开发人员之间的表述不清和功能分歧这是属于沟通领域，已经不关软件自己的问题了，怎么能够以偏概全都叫bug），但愿在之后的学习中能够解决这一问题，并深化本身对软件工程总体的理解。

Q2.我在第七章看到这样一段文字（软件工程，惟一不变的就是变化。因此干脆干脆别幻想用户的需求会在第一时刻很明确。而后保持不会变。但要注意，咱们是预期变化，不是指望变化。），有这个问题（虽然软件开发过程是一个连续修改的过程，力求最合适用户，可是一直变化，会不会出现太屡次大幅度的修改，而后出现开发方向严重偏离或者打击开发者的信心？）。我查了资料发现存在这样的说法（这就须要在需求分析阶段多沟通多了解，先肯定方向，再寻求长期的比较广度的发展，也须要团队保持敏捷的应对方式，符合msf团队模型），可是我依旧以为（须要团队之间的默契和协做，必须让团队中的每一个人都明白彼此的想法，但需求变化依旧是不可控的，但愿能有更好的解决办法。）

Q3.我在第八章看到竞争性需求分析的框架，有这个问题（最新型，有创新点的软件设计，必定就是最符合用户心目中的软件吗？）。我仔细看了书发现存在这样的说法（从需求、作法、竞争、推广多方面分析来看，软件开发市场须要必定的创新和竞争力，但一个公司可能有多种软件产品和服务，它们各有不一样的战略意义。一个软件或服务也由不少功能组成，它们有机地结合起来，才能解决用户的问题，产生效益，要更用心地去优化软件，后期准确的表达与介绍产品的核心价值，体现不一样类型的功能，就也许能够取得好评。），基本解决了个人疑惑。