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