阅读报告--构建之法

  软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。软件工程牵涉的范围很广,对于即将投身IT业的学生而言,软件工程的内容又非常重要。典型的软件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时,各个行业几乎都有计算机软件的应用,如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展,也提高了工作效率和生活效率 。

一、软件=程序+软件工程

  正如书中所言,几乎所有的程序员都知道“程序=数据结构+算法”这句名言。但是,对于一个团队来说,最重要的不是写出一个程序,而是设计这个程序,包括各种需求以及扩展。客户的需求总是在改变,程序的功能也需要随时做出改变;程序需要对各种静态动态的数据进行操作;面对不同的环境,一个程序需要32位、64位等不同的版本;软件团队的人员总是在改变,新的成员需尽快读懂已有的程序;一个好的软件需要有良好的用户体验;等等,一切的一切都是软件开发的活动,都是软件工程的核心部分。

二、窝蜂&写了再改

  在团队和流程章节,书中最先介绍了一种团队模式-窝蜂模式和一种开发流程-写了再改模式。大致的意思就是,一个团队一窝蜂地去干某一件事,很多其他的事情根本顾不过来,开发时,不需要任何的准备,上来就写代码,也许能写出来,或许也写不出来。看到这里时,我的感受颇深。作为一个大学生,杨老师给我们布置的几次团队作业,我们大多都是像那样去做的,因为,这些程序都是一些“演示”程序或者是“用一次就扔”的程序。所以我们并没有很认真的去做一些需求分析等,导致代码虽然写出来了,但是有着各种各样的问题。

三、需求分析

  之前不知道要做需求分析,每次编写代码时,都是想起什么就往里加入,导致最后好多功能都是强行加入进去的,代码整体结构变得很差,有些地方甚至会出现严重的bug。但一个好的需求分析,能够让开发团队更好地了解用户的行为和需求,能够开发出一个让用户满意的软件。

  本书对一个软件的需求分析,可以从4个方面去分析,对产品功能性的需求,要求产品必须实现某些功能;对产品开发过程的需求,要求软件的开发流程必须满足某些约束条件;非功能性需求,也叫服务质量需求;综合需求,有些需求并不是单单一个软件模块就能满足。

  一个软件的需求分析最终利益相关者,最大的就是开发这个软件的团队或者个人,但是利益相关者中还要包含用户和顾客等,所以,软件开发时,还要顾及到所有利益相关者之间的需求关系,这样才能让整个软件的需求分析分析的更好。

四、软件测试

  本书介绍的两种测试方法:黑箱测试和白箱测试

  黑箱:指的是在设计测试的过程中,把软件系统当作一个黑箱,无法了解到内部,更准确的说法是行为测试

  白箱:指的是在设计测试的过程中,设计者可以看到软件系统的内部结构,并选择测试数据即具体的测试方法来测试

  对于测试部分,我深有体会,这次的团队项目开发时,遇到了很多的问题,用了白箱测试的办法,调试了很多,模块开发完成后,我们用黑箱测试了一下,发现了一些用户操作方面的不足。这使得我们的程序更加的完善,并且加快了开发的速度。

  总体来说,构建之法这一本书,从代领我们走进了软件这个世界,到介绍团队开发流程,再到需求分析的介绍,软件设计与实现,到最终软件质量如何去保障,每一部分配以生动实例的讲解,都帮助了我提高开发软件的技能,使得我收获颇深

时间: 2024-11-05 11:26:16

阅读报告--构建之法的相关文章

阅读《构建之法》与链接有感.

4.学术诚信与职业道德 阅读<构建之法>P384~391. 参考阅读以下链接: 偷了『半条命2』源代码的那小子http://blog.jobbole.com/79450/ 2014年,锤子手机在天猫电器城上预约数造假http://tech.ifeng.com/a/20141020/40841049_0.shtml 从天猫处罚作假看手机市场三大趋势http://www.chinahightech.com/html/727/2014/1020/15575128.html 独立游戏制作人作品被盗后…

阅读《构建之法》P384~391

通过阅读<构建之法>P384~391以及参考阅读杜老师给出的链接,得出一个重要的结论:软件工程师的职业道德至关重要. 软件工程的动态性和需求的前后关系,要求一个规范能对出现的新情形有较强的适应性和适用性.但是即使在这种一般性原则下,本规范也只对那些以文档记录职业道德态度并采取积极行动的软件工程师提供支持:即提供相应开发组中的个人以及整个开发组都可以求助的道德基础.本规范也帮助定义哪些是对软件工程师提出的道德上不适当的要求. 原则1  公众 软件工程师的行为应与公众的利益一致. 原则2  客户与

软件工程---阅读《构建之法》P384~391

-阅读<构建之法>P384~391后,我充分认识到软件工程师的职业道德的重要性,具体有: 原则1:公众 原则2:客户与雇主 原则3:产品 原则4:判断 原则5:管理 原则6:职业 原则7:同事 原则8:自身 通过这次的阅读,认识到每一个人都应该具备职业道德.

阅读《构建之法》第四章感想

课下阅读<构建之法>第四章,自己有以下一些感想. 1.我们写的代码最终都是要给人看的,所以代码规范化是一个优秀编程员必备的良好习惯,而且若是在团队里工作,那么代码规范更加重要.编程人员要遵循的代码风格的原则是:简明,易读,无二义性.以后自己要养成规范代码的习惯. 2.复审也是不可缺少的一个步骤,软件工程中最基本的复审手段就是同伴复审,找熟悉代码,有经验的人来进行复审. 3.当今时代,一个人能发挥的力量越来越小,团队的力量日渐重要,因此,如何合作,很关键.两个人合作,如何影响对方,要因人而异,因

阅读《构建之法》和以下链接的读后感

1.关于学术诚信与职业道德 阅读<构建之法>P384~391,并参考阅读以下链接:     偷了『半条命2』源代码的那小子http://blog.jobbole.com/79450/     2014年,锤子手机在天猫电器城上预约数造假http://tech.ifeng.com/a/20141020/40841049_0.shtml     从天猫处罚作假看手机市场三大趋势http://www.chinahightech.com/html/727/2014/1020/15575128.html

阅读《构建之法》第四章、第十七章收获

阅读<构建之法>第四章.第十七章 阅读这一章的时候,我意识到了很多以前写程序没有注意到的地方,以前写程序就只知道能运行就好,根本不管自己写的程序占多少内存,运行的时间,是否有优化的空间,写代码的时候也不注意规范,有时候设计的函数根本用不上,造成代码冗余.同时也认识到结对编程的重要性,没读这本书之前就觉得结对编程就是两个人一人负责一个模块,然后合在一起,调试调试.但实则不然,真正的结对编程应该像书中那样,一个是驾驶人,一个是领航人,两个人有规律的进行编程.期间,一人编程一人复审,极大地提高了效率

阅读《构建之法》有感

之前学习的软件工程那门课程,虽然讲客老师很优秀,是我一直以来敬爱的一个老师,但是,那门课程依旧上的很无聊,整个教师都显的死气沉沉,没有生气.我之前认为这是一个无法避免的问题,因为那门课程的理论知识太多,内容又非常重要,老师如果想把这门课的知识点给我们讲解完就必须循规蹈矩的讲解. 但是自从看了邹欣老师写的这本构建之法,我才知道原来软件工程可以这么学,作者把冷硬的知识都鲜活话了,把原来枯燥无味的理论写的鲜活无比,还大量的举例说明,其中最重要的亮点就是通过阿超,果冻,小飞,小李等人物的对话和活动,把软

[读书报告]构建之法(三)

今天读了<构建之法>的第八章. 第八章讲需求分析.需求分析有以下几个步骤: 1.获取和引导需求 找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 2.分析和定义需求 对从各个方面获取的需求进行规整,定义需求的内涵,从各个角度将需求量化. 3.验证需求 通过分析报告.用户调查等形式向利益相关者验证团队对需求的认知. 4.在软件产品的生命周期中管理需求 在软件的声明周期中不断对需求进行重新审核并作出调整 需求分为以下几个方面: 1.对产品功能性的需求 要求产品必须实现

[读书报告]构建之法(八)

今天读了<构建之法>的第15章:稳定和发布阶段 Alpha:指集成了主要功能的第一个试用版本. Beat:功能基本完备,稳定性较Alpha版本高,用户可以在实际工作中小范围使用. ZBB:某天的版本把在之前记录的Bug都解决掉 RC:发布候选版本 RTM:最终发布版本 RTW:和RTM类似 会诊小组 软件团队的各个角色代表组成了会诊小组,处理每一个影响产品发布的问题. 决定对每一个Bug采取以下哪一种行动: 1.修复 2.设计本来如此 3.不修复 4.推迟 复杂项目的会诊 第一步:开发者提交惨