《构建之法》-6

  假期即将结束,《构建之法》的阅读也即将告一段落,希望化成指导,帮助我实践。

  下学期必为一场苦战,加油!


  软件团队的所有相关人员都需要处理、了解需求信息,如果在处理的过程中有误解和遗失,就会导致开发过程中的问题,以致最终产品不能满足用户的需求。我们要给事物建造出一个“模型”,描述事物、事物的属性、事物之间的关系以及各个事物之间的信息传递。

  操作越简单,当然用户体验的感觉越好做软件要思考我们的目标用户是什么样的的水平,不能把用户想的太笨。微软有“吃狗食”的传统,但是我们对自己写的软件十分了解,而且操作技术也占优势,所以有的问题不能及时发现。用户在操作时会犯简单的错误,我们需要花心思去设计怎样才能减少这种错误。软件在发布之前,要进行软件测试。按测试设计的方法分有黑箱测试设计和白箱测试设计;按测试的目的,有功能测试和非功能测试,基本功能完成后再来做这些非功能测试。测试方法有单元测试和代码覆盖率测试,构建验证测试,验收测试等等,测试过后要记得写测试报告。

  软件要符合用户以及利益相关者的需求。程序的质量我阅读之后的理解是,是否完成了那个功能。软件工程的质量就是软件在功能、成本、时间三方面满足利益相关者的需求。程序的质量可以通过一些特殊的办法来提高,但是软件工程的质量需要长期的过程来提高。一个团队经历了计划/设计/开发等阶段,达成代码的完成这一目标,并不能松口气,软件生命周期的最后阶段是最考验团队的。在大型复杂项目中,软件团队会进行更为复杂的会诊,对于管理团队来说,重要的是要通过每天的会诊让团队了解Must/No的标准,帮助团队的成员了解整个项目的现状。

  创新的时机很重要,IT产业只有第一没有第二,谁能在更早的时间里发现问题并付诸行动,谁就能领跑创新。那些成功的企业只是比大众的平均值先走了一小步,就是这一小步,让大部分人看到了产品的“相对优势”,从而接受产品。也有一些产品退出,但是往往最后成功的产品成功在时机上。

原文地址:https://www.cnblogs.com/gxt-/p/6412224.html