构建之法阅读笔记06-2

经过对软件工程的10周+的学习,我们对软件工程也有了深刻的理解。软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

对于前期提出的问题的回答:

在课前的阅读中,因为一开始对软件工程不是很了解,提出了一些问题,当时周老师也为我解决了一些问题。我提出的问题比较广泛。

1.对于“软件工程的学习应该达到何种程度和只靠《构建之法》这本书真的够吗?”周老师给出的回答是先学好这本书,的确,邹欣老师的这本书对软件工程的开发与实现写的很是详细。当我拜读邹欣老师的书时,无不感叹他对软件工程的认知和了解。

2.对于“我们是否也要定期进行自我评价来改进自己,增强学习进度和效率”,对于这个问题,邹老师的书上也有体现,那就是定期的发几篇博客,通过博客来审视自己的工作和学习进度。

3.对于“是否团队模式有助于学习和编程,如果是,那该多少人为一组为好”,对于这个问题,周老师给出的意见是学校可以定在五个人左右。在我看来,团队合作确实有助于学习,团队的几个人互相协作,共同学习,共同进步,使团队的优点更加显著。但是相对的,团队合作也有一定的弊端。每个人都会有自己的思考,我们不一定要求完全的同一,我们可以做到集思广益,择优而行,这样才能吧团队的能力发挥到极致。

总结课程的体会:

通过16周的学习,我对软件工程这门课有了一定的了解。对于软件的开发流程又有了新的认识,软件开发流程包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序等一系列操作。想要做好软件开发,必须遵循以下几个步骤:

第一步:需求分析,需求分析阶段是一个很重要的阶段,这一阶段做的好,将为整个软件项目的开发打下良好的基础。

第二步:软件设计,其中包括总体设计和详细设计

第三步:程序编码,在程序编码中必定要制定统一、符合标准的编写规范。以保证程序的可读性、易维护性。提高程序的运行效率。

第四步:软件测试,整个测试阶段分为单元测试、组装测试、系统测试三个阶段进行。测试方法主要有白盒测试和黑盒测试。

除此之外,我对流程图也有了新的认识,原来不是所有的图都是流程图,流程图只是图形建模的一种。图形建模包括思维导图、实体关系图、数据流图、流程图等。图形建模可以更好的帮助自己对自己要实现的软件进行分析。

对课程的建议:

软件工程这门课,感觉老师只是按照书上写的教我们,我们课后还是得再学一些其他的内容才行。

时间: 2024-11-25 06:33:08

构建之法阅读笔记06-2的相关文章

构建之法阅读笔记06

这周我阅读了软件测试这一章,在读完这一章之后,我知道了软件测试的方法主要有单元测试.代码覆盖率测试.构建验证测试.验收测试.探索式测试以及回归测试等. 读完这一章使我对软件测试有了新的认识,一款软件的开发,从开发初期的问题定义及规划到各个阶段的有序进行,整个软件的开发需要做到层层相扣.而软件测试----作为软件开发过程中最后也是最关键的一步,其把我这软件的质量关,在其中发挥着至关重要的作用,无论是对软件安全性的保证,还是对软件功能性的检验,都有着无可代替的地位.因此,要想让一款新的软件很好的满足

构建之法阅读笔记06(完)

第十五章:稳定和发布阶段 一个团队经历了计划/设计/开发等阶段,就达成了代码完成这一目标.这就来到了软件生命周期中最后的阶段,也往往就是最考验团队的阶段.首先,优秀的团队会发布有缺陷的软件,它能找到一个平衡点,能及时发布解决用户问题的新版本,并能及时修改软件中的问题.软件发布会经历许多版本:Alpha-Beta(对用户的反馈给予应答,进行改进)-ZBB(在多次修改BUG与反弹之后,将bug数目控制在0)-RC-RTM-RTW.对于不同的BUG,团队会给出不一样的解决方案:修复,放任,不修复,推迟

构建之法阅读笔记三—结对编程

构建之法阅读笔记三——结对编程 何谓结对编程,结对编程就是程序员肩并肩,平等的,互补的进行开发工作,他们使用同一台电脑,编写同样的程序,一起分析,一起设计,一块交流想法. 然而我以前却并不是这样做的,我以前喜欢在没人打扰的环境下写代码,我觉得有人在我身边看着,会影响我的思路,还有我个人自尊心比较强,不太喜欢被人指指点点,所以每次都是,我写完代码之后,自己先找自己的bug,每当自己实在找不到之后,才会请教大神,但是有时候可能由于自己的能力不足,往往一个很简单的问题,我自己发现就会花费很久的时间,让

构建之法阅读笔记四—团队开发

构建之法阅读笔记—团队开发 软件开发过程中有团队和非团队之分.其区别就在于目标利益的不同,团队中每个人的目标是一致的.共同的,会根据实际情况给每个人分配不同的任务,不会计较个人利益的得失.非团队每个人的目标都是不同的,大家都为自己的利益而奋斗. 在阅读了构建之法后,我了解到团队开发有以下的特点:1.团队开发有一致的集体目标,团队要完成这个目标.一个团队成员不一定要同时工作.2.团队成员有各自的分工,互相依赖合作,共同完成任务.还有完成一个项目开发的工作流有业务建模,需求,分析和设计,实现,测试,

构建之法阅读笔记6--敏捷开发2

构建之法阅读笔记—敏捷开发2 敏捷开发并不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发:而这种开发方式的主要驱动核心是人:它采用的是迭代式开发:敏捷开发并不是瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据:而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心.而所谓的迭代开

03构建之法阅读笔记之一

构建之法阅读笔记03 遇到问题总是想弄清楚所有细节.所有依赖关系之后再动手,想的太多,没法前进,分析的就会出现错乱,或者直接动手,慢慢发现偏离的一开始的轨道,忘记了目标,这样就会产生"分析麻痹"和"不分主次,想解决所有问题",以后遇到问题应该时刻记住自己的目标,在解决问题的时候不断提醒自己,应该如何思考.越早对自己有一个清晰的定位,对自己越好,很多人只是把软件工程师当成一个工作,当成一个能挣钱养家的营生,而我想把它的当成自己投身的事业,把软件项目相关的目标作为长期的

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

构建之法阅读笔记05

2017.5.20 今天阅读的是<构建之法>第8章需求分析的阅读笔记,我们如果要开始做一个软件,最先要进行的就是需求分析,我们应该充分的了解我们这个软件是否具有前景,我们为用户提供的服务是不是用户所需要的,这一章详细的叙述了如何进行需求分析. 首先是获取和引导需求,我们应该找到软件的利益相关者,了解挖掘他们对软件的需求,引导他们表达出真实的需求.然后分析和定义需求,对各个方面的需求进行规整,定义需求内涵,从各个角度将需求量化,然后估计实现这些需求所需要的时间和资源,确定各个需求的优先级.紧接着

构建之法--阅读笔记二

阅读笔记二—代码规范 代码的风格的原则就是:简明,易读,无二义性.我虽然是计算机系的学生,但是我以前却没有秉着这个原则来编写代码,现在阅读了构建之法后,我明白了如何让你的代码变得简明,更容易理解. 代码在编写的过程中注意: 用Tab键缩进 要注意行宽,最多限定100字符的行宽 在复杂的条件表达式中,用括号清楚地表达逻辑优先级 要注意断行与空白的{ }行,有明确的“{”和“}”来判断程序的结构 不要把过多的语句放在同一行上 对变量命名要有实际的意义 用下划线来分隔变量名字中的作用域标注和变量的语义

构建之法阅读笔记三

今天阅读了构建之法第四章,对我最深的感触就是代码规范,对于一个软件工程师来说,编程是一项基本技能,程序编的好一半来自于代码的规范:就算你学的算法再好,编程能力再强,代码不规范也没有任何意义.当阅读者拿到你的代码时一头雾水,完全看不懂,这样的代码对于后期的维护和bug的寻找难上加难,或者是对于后来的初学者来说,也是去了教育意义.所以在我们日常的编程过程中要养成代码规范的习惯,习而久之,这样的习惯会一直伴随我们编程整个过程. 还有就是代码复审,我一开始也想不明白,代码为什么要复审呢,写完代码得到执行