软件 = 软件 + 软件工程
软件质量=程序质量+软件工程质量
软件工程的质量体现在：软件开发过程的可见性、风险控制、软件内部模块，项目中间阶段的交付质量，项目管理工具的因素、开发成本的控制、内部质量指标的完成。软件的质量不能仅仅依靠测试人员去保证，编程人员在进行编程时要尽力保证自己代码的质量以及各模块连接之间的稳定性。
《构建之法》中印象比较深的是其中有一章讲解了“典型用户和场景”，书上开始举了一个很好理解的例子，是一个理发师给顾客剪头发的例子，由例子可见，你光看用户的表面语言是不够的，我们应该理解的是用户语言背后的动机。当我们做一个服务于顾客的软件时，我们应该遵循的规则是一样的。在我们软件的需求分析中，顾客的分析是必不可少的。我们应该罗列我们软件的典型用户，我们应该分析他们的需求，针对他们的特点来确定我们的软件服务于谁，并且要实现哪些具体的功能。我们应该设计一个场景，这个场景是我们的用户最可能使用我们的软件时遇到的场景。将用户放到这个场景中，分析我们的软件应该为用户如何提供更好地服务，让用户使用起来更方便。在我们自己这学期的软件制作中也是一样，我们应该有典型用户的分析，来明确我们的软件到底是提供给哪一个类型的用户使用，并且用户大多数情况下是在什么场景使用我们软件，这是我们必须考虑的。所以我们应该确定典型用户，我们的典型用户应该就是当下的大学生，所以我们应该切实从大学生出发，场景应该为学校，所以我们应该从在学校使用我们软件的大学生出发去完善我们软件的功能。
每个团队都应该有自己的团队绩效，应该用团队绩效来评估该团队的成员在这一阶段对这个软件做出的贡献。我们应该从不同的方面来评估一个人在这一阶段对软件做出的贡献。单单从一个方面去评估一个人的价值是不合理的。每个人在每个方面的贡献都是不可低估的。另外这章中还提到了团队合作的几个阶段，开始大家聚集在一起，是团队的萌芽阶段，每个人都很生疏，不知道做事的流程，不知道在团队中该怎么做。接着团队进入磨合阶段，这时候团队中会迎来疑惑和冲突，这正是我们的磨合期，没有任何一个团队可以一团和气的从头到尾，争吵总会有的，关键也在于我们应该尊重别人的意见把团队磨合的越来越好。接着进入规范阶段，每个成员似乎都意识到了争吵是没用的，每个人都知道了工作流程，按部就班的工作，最后是创造阶段，进入这个阶段的团队已经很厉害了，这个阶段的团队已经可以自己创造出一些属于自己的东西。我们的团队已经成立了一段时间，好像还处于第一阶段，我们对自己的工作流程好像并不熟悉，我们还是没有规整的工作计划，我们应该制定一个工作计划，坚持每天汇报自己的工作，并且为每个人分配好固定的工作，然后大家一起努力争取早日进入规范阶段。