构建之法 第七次心得

构建之法14、15章总结

第14章

这一章讲的是质量保障。在我们做软件的时候,最重要的是质量,如果做成功的软件质量不过关,那无疑是白费心血,浪费时间。程序的质量体现在软件外在功能的质量,用户体验的质量,国际化的质量,安全性的质量等等。

软件开发过程中有三个主要的特性:好、快、便宜,即软件需要在成本、功能、时间三方面满足利益相关者的需求。一个团队可以靠很多方法来提高程序的质量,比如交付前不断测试,修改,也可以在软件发布之后再一直进行修复问题,但是软件工程的质量需要长期的过程来提高。

软件工程的质量体现在:软件开发过程的可见性;软件开发过程的风险控制;软件内部模块,项目中间阶段的交付质量,项目管理工具的因素;软件开发成本的控制;内部质量指标的完成情况。衡量软件工程的质量有一套比较成熟的理论,CCMI。CCMI的实施能够提高企业的管理水平,降低企业的成本。在一个团队中需要有一个人专门对软件进行测试,这样分工可以有效提高团队的效率,也可以尽可能保证软件的质量。但是有专门的人负责并不意味着团队的个人不需要关注软件的质量。

第15章

这一章主要讲的是软件的稳定和发布阶段。软件经过计划、设计、开发等阶段,最后就需要发布了。但是软件发布也不是一件简单的事情。发布软件需要考虑是在软件的缺陷全部完善之后再发布,还是在不影响使用的情况下先发布,后期再进行更新。

发布时,软件团队的各个角色代表会组成一个会诊小组,负责处理每一个影响产品发布的问题,他们可以选择是否立即修复问题,或者延迟修复。在稳定阶段的初期,团队只需要决定修复哪些缺陷,然后团队成员再进行必要的设计、实现、测试工作,但是项目进展和发布日期不断临近,团队还要保证修改不会影响软件的发布。

有时候,软件修复需要一整个模块的修改,这是需要慎重修改的地方。修复软件有几种招数:设计变更、ZBB、最后回归测试、砍掉功能、修复Bug的门槛逐渐提高、逐步冻结。发布软件时,出现不同频率和不同覆盖范围的渐进发布。

时间: 2024-08-01 17:40:48

构建之法 第七次心得的相关文章

构建之法第七章学习心得

这周我学习了构建之法第七章MSF的介绍.MSF有9个基本原则,针对信息共享,团队内部运营,市场,还有客户.同样是强调效率,人性,灵活,还有前景. MSF对信息共享和沟通十分强调,对团队内部运营强调相互信任,各司其职.MSF敏捷开发模式分为两支,MSF敏捷开发模式和MSF CMMI开发模式.都是很人性,灵活,以及对自身有高要求的模式.结合上一章的敏捷流程和这次学习的MSF,在我看来相对比较迅捷,给人一种少了很严肃气愤的方法,个人还是比较喜欢.MSF的最大特性是商业化,并一直体现在项目的实施过程中.

构建之法 第三次心得

构建之法 第四.五章心得 学习了第四第五章之后,我了解到了两人合作的注意要点,还有团队和开发流程.软件都是在相互合作中完成的,合作的最小单位是两个人.每个人的标准都不一样,对于什么是好的代码规范未必认同,所以我们需要给出一个基准线,即什么是好的代码规范和设计规范. 代码规范可以分成两个部分,一是代表风格规范,主要是文字上的规定,看似是表面文章,实际上非常重要.二是代码设计规范,牵涉到程序设计.模块之间的关系.设计模式等方方面面的通用原则.代码风格的原则是:简明.易读.无二义性.这里可以从几个方面

《构建之法》读后心得,问题

我觉得构建之法这本很不错,书的内容给我一种欢快的阅读体会,能让人更加的快速去接受里面的内容,并吸收为自己所用:并且里面的内容都举例生活中的例子,并且在一些容易有疑惑的地方,以问答形式解答,而且语言通熟易懂,使人看上去更加的了解其实软件工程就在我们的身边. 之前上过软件工程这门课程,那本软件工程的书本不像<构建之法>,都是一些很枯燥乏味的内容,并没有像<构建之法>让人舒适,让人以一种欢快的阅读体会.其实软件工程就是包括了“开发.运营.维护软件的过程中的很多技术.做法.习惯和思想.软件

构建之法 第六次心得

构建之法12.13章小结 第12章 这一章讲的是用户体验,对于软件的使用,用户的体验是非常重要的方面,如果一个软件给用户的体验不好,那么这个软件无疑是不会受到欢迎的.但是用户体验和用户界面的领域不是那么容易的,这两个需要丰富内容的学术领域.就像一个游戏,如果这个游戏界面单调,但是操作又非常复杂,那么用户可能很快就失去了兴趣. 在设计软件界面时,我们也要考虑到使用这个软件的人群的特征,使用习惯等等,可以根据这些来设计界面,还要让用户在每次使用的时候减少对自己没有价值的部分的访问,尽量使得用户不浪费

构建之法 第五次心得

构建之法9.10.11章 第九章 学习了第九章之后,了解到了在一个项目中项目经理的重要性.生活中,无论什么团队工作,都需要一个领队,来掌控团队项目的发展,以及各个成员工作的分配.PM指Product Manager.Project Manager.Program Manager.这个章节主要讲了Project Manager即项目经理,PM要凭自己的能力,把用户的需求展现成其他成员能够理解和执行的语言.项目经理需要正确地协调团队内部外部,调配各部门资源和时间,有效进行风险管理,保证一个项目顺利按

《构建之法—现在软件工程》心得体会

作为软件工程专业的一员,我觉得自己并没有学习到太多跟专业有关的知识,甚至不是很清楚的了解“软件工程”这一词的意思,每逢家中的长辈问学的什么专业,我都需要用很白化的词语解释,就是开发游戏的软件,纯属敷衍了事.因为本人自己也不太清楚. 本学期有一门课程叫——软件测试,可此课程居然有两本教材,后经老师介绍后,才知道<构建之法——现在软件工程>这本书由我们自己去阅读.起初由于无聊,我把<构建之法——现在软件工程>这本书拿出来看,没想到根本停不下来,它把软件开发方法讲得清晰有趣,书中还遇用许

构建之法第八章学习心得

今天,我学习了构建之法第八章软件需求,人们为了解决现实社会和生活中的各种问题,要求助于软件.人们的需求五花八门,那么软件团队如何才能准确而全面地找到这些需求呢? 需求分析1.获取和引导需求 软件团队需要找到 软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 不同的项目需要不同的手段,这一步骤也被叫做"需求捕捉",形容真正的需求稍纵即逝,需要靠火眼金睛和敏捷的身手来发现并抓住它们.另外,很多时候用户并不知道自己确切的需求,或者不愿意表达完整的需求,软件团队需要设

《构建之法》小组学习心得

baba爱你小组  组长:阮俊  组员:钱洪章.黄维.光萍.张启飞.王学飞 这周我们小组学习了<构建之法>第八章需求分析的内容. 人们为了解决现实社会和生活的各种问题,要求助于软件.人们的需求五花八门,那么软件团队如何才能准确而全面的找到这些需求呢?主要有这几个步骤: 1.获取和引导需求 软件团队需要找到软件的利益相关,了解和哇挖掘他们对软件的需求,引导他们表达出真实的需求.另外,很多时候用户并不知道自己确切的需求,或者不愿意表达完整的需求,软件团队需要设身处地,替用户着想,引导出需求. 2.

构建之法 第四次心得

第六章 学习了之前的内容之后,我了解到了团队合作的流程以及在编码时候一些格式的注意,在学习第六章后,对敏捷流程有了大致的了解.敏捷流程是一种很好的软件开发的流程,我认为在软件开发时,敏捷开发可以使得软件可以在满足客户的满足时不断地快速更新. 敏捷开发需要不断关注技术和设计,这种开发模式需要以有进取心的人为项目核心,并且充分支持信任他们.软件开发是一个很漫长的过程,也不是一个人的事情,一个人的效率高是不好完成这个开发的,所以必须要一直总结怎么提高团队效率,并且不断地提高团队内每个人写代码的能力.在