【软件工程】第三、四章总结

现在的总结都是补得以前的。没有及时总结的后果就是再看自己的笔记的时候连自己都感觉好陌生。这样的学习是最没有效率的!看完一部分就总结是一个很好的习惯。但是我却总也坚持不下来。多么痛的领悟。。。

【概要】软件的第三章讲的是软件需求分析。说白了就是在设计一个软件之前,我们首先要明白了解客户的需求。如果没有客户的需求就盲目的去做,就好像是没有球门的一场足球赛。就像我们的人生没有目标一样。即便是最后做出了一些东西也不一定满足客户的需求,那样的工作就是没有意义。所以,软件需求分析的阶段很重要。就像一个旗帜,给我们树立一个目标,朝着目标一步一步的前进。

软件工程的第四章是软件设计阶段。当我们做一件手工艺品的时候,往往都是先将它的大致轮廓设计出来,然后再设计里边的细节部分。软件也一样,在设计的初期,我们首要的任务就是系统整个结构的设计,然后就是细化的过程和数据设计。所以,在设计阶段,我们将设计分为概要设计和详细设计。然后就是细化的设计过程。下边是我对这两章的总结导图。

【导图总结】第三、四章

【总结】其实软件工程的视频的整体思路都很清晰。就是设计一个软件我们首先需要做什么,然后需要做什么的整个流程。把握好整个宏观结构,还有整体思路,看视频学习也会是高高兴兴哒。。。还能非常有效率哒。。。。看所有的视频都是一个道理,所以,加油吧。向着前方前进前进。。。

时间: 2024-10-19 08:32:15

【软件工程】第三、四章总结的相关文章

现代软件工程 第十四章 练习与讨论

15.3.1 有些成功人士或公司认为不需要独立的测试角色(Test),你怎么看? 我猜想和踢足球类似,还是那几个原因: 人太牛: 不世出的天才,例如高德纳写书时发现排版软件不好用,就自己写了一个.也没听说他为这个软件项目请了什么独立测试人员.对了,他不读Email,有秘书帮他处理这些事——这也是一种分工! 有些软件工程师是在后台钻研和开发高难度的算法,或者做某种后台的处理工作,这个工作本身的难度较高,测试主要是自己通过工具完成.如果一定要找一个测试人员,这个测试人员的水平要相当高才行,如果水平那

软件工程概论第四章

本章主要介绍了软件需求的业务需求.用户需求.功能需求和非功能需求(用户解决问题或达到目的所需要的条件或能力.系统或系统部件要满足合同标准.规范或其他正式规定文档所需具有的条件或能力.一种反映上面两句所描述的条件或能力的文档说明.),需求工程过程的需求获取.需求分析.需求规格说明.需求验证.需求管理,需求获取技术的免谈.需求专题讨论会.观察用户工作流程.原型化方法.基于用例的方法,小型图书资料管理系统的确定参与者.确定场景.确定用例.编写用例描述.

软件工程概论第四章需求工程

软件需求中一般包括了用户角度和开发人员角度两个方面.通常将软件需求划分为业务需求,用户需求,系统需求,功能需求和非功能需求等类型. 软件需求工程过程一般包括以下的步骤:需求获取,需求分析,需求规格说明,需求验证,需求管理,其中还介绍一些需求管理工具.介绍了需求工 程的步骤还要掌握获取需求的技术一般的方法有:面谈,需求专题讨论会,观察用户工作流程,原型化方法,基于用例的方法. 本章最后介绍了一个案例 :小型图书资料管理系统的的需求过程.他的主要步骤1 确定参与者,2确定场景,3确定用例,4编写用例

现代软件工程 第十四章 【质量保障】 练习与讨论

14.1 有些成功人士或公司认为不需要独立的测试角色(Test),你怎么看? 就像很多事情一样,不能把所有的事情说得太绝对了,举个例子来说,大多数的软件开发都是以小组的形式来进行的,每个人分配了一个模块,如果说每个人对自己的模块都进行一下测试,当然这样的情况下可以不需要独立的测试角色,编程的过程就是不断对自己的程序排错.测试来完成的,但是最后所有的模块整合成一个大的系统,这样如果程序员只对自己的模块进行测试,是肯定不能满足需求的,这时候就需要一个独立的测试角色,对整个系统进行规模测试,在不知道内

软件工程概论第四章概括

需求工程在大体上分为业务需求.系统需求.用户需求.功能需求和非功能需求等类型. 本章首先开始先介绍软件需求工程大致的分类,而后开始详细的介绍每个需求的特点,以及他们之间的关系. 其次把业务需求拿出来详细的介绍了他的过程,首先向用户征集关于软件的信息,根据软件的功能来为软件做一个简单的模型,最后做出来之后向用户验证质量以及是否可行性,之后开始跟进软件的维护以及版本的跟新. 对开发人员向用户征集信息的方式做了介绍,面谈.开小型的见面会.原型化方法,等等. 上面介绍了理论方面的知识,之后吧小型的图书管

软件工程概论第四章--需求工程

本章主要讲了软件开发中的软件需求,从软件需求.需求工程过程.需求获取技术和对小型图书资料管理系统案例分析几个方面展开讲述,讲到了软件需求在软件开发中的重要地位. 软件需求定义:①用户解决问题或达到目标所需的条件或能力.②系统或系统部件要满足合同.标准.规范或其他正式规定文档所需具有的条件或能力.③一种反映上面①或②所描述的条件或能力的文档说明.通常可以划分为业务需求.用户需求.功能需求和非功能需求等类型,业务需求是组织或客户对于系统的高层次目标要求,用户需求是从用户角度描述的系统功能需求和非功能

0403对《软件工程》第四章的理解

一.代码规范    1.代码风格规范:简明易读无二义,包括有意义的命名及增加注释    2.代码设计规范        (1)函数只做一件事,并且要做好        (2)错误处理.验证参数的正确性:使用断言:使用public,protected,private说明成员,非必要不使用虚函数和类型继承    3.代码复审 二.结对编程好处 1.在开发层次上能够提供更好的设计质量和代码质量,两人合作解决问题的能力更强: 2.对开发人员自身来说,结对工作能带来更多的信心,高质量的产出能带来更高的满足

《软件工程》第四章 读后感

1.代码书写规范: (1)代码不仅仅要足够高效,减少冗余,而且在合作过程中要易于合作人的阅读以便更高效的工作.而且命名要尽量避免二义性: (2)在编写过程中,应养成写空白{ }的习惯,注意分行: (3)下划线一般用于作用域和变量: (4)使用Pascal和Camel形式去命名,区分函数和变量: (5)注释应放在函数头,尽量只用ASCII字符: 2.代码设计规范: (1)函数只做一件事: (2)程序逻辑清晰易懂: (3)用断言Assert判断程序应有的正确反应,if().else if()来处理可

《软件工程》第四章总结

软件需求通常可以划分为:业务需求,用户需求,系统需求,功能需求,非功能需求等,并且他们之间存在一定的联系. 需求工程的所有过程,包括需求获取,需求分析,需求规格说明,需求验证和需求管理等. 常见的需求获取技术包括面谈和问卷调查.需求专题讨论会.观察用户工作流程.基于用例的方法.原型化方法等, 而选择这些技术需要根据应用类型.开发团队技能.用户性质等因素来决定. 其中基于用例的方法应确定参与者,确定用例.描述用例.

对《软件工程》第四章的理解

两人合作写软件首先要代码规范,进一步阐述就是要代码风格规范和代码设计规范. 代码风格规范对于结对来说首先要统一开发工具,然后要注意源文件的格式.排版.换行.适当的注释.命名规范.即要简明,易读,无二义性. 代码设计规范:对于函数来说.即用简单的构造函数,最好是默认构造函数,这是因为简单的构造函数增强易用性:对于错误处理来说.包括(逻辑和编程错误,设置错误,被破坏的数据...),然后要对程序增加一些相应的错误处理:对于异常处理来说.不是百分之百确定的情况,不要吞掉异常.如果理解该异常在具体环境当中