软件工程笔记10.docx
《软件工程笔记10.docx》由会员分享，可在线阅读，更多相关《软件工程笔记10.docx（12页珍藏版）》请在冰豆网上搜索。
软件工程笔记10
软件危机
软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
软件危机的主要表现
1）软件开发无计划性2）软件需求不充分
3）软件开发过程无规范4）软件产品无测评手段
//软件的的特点
软件具有的独创性（即原始性）、无形性、复制性及复杂性等特点。
软件生命周期
软件生命周期是软件的产生直到报废或停止使用的生命周期
信息隐蔽
信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，定义每一个模块时尽可能少地显露其内部的处理。
//应该让模块仅仅公开必须要让外界知道的内容，而隐藏其它一切内容。
//信息隐蔽原则对提高软件的可修改性、可测试性和可移植性都有重要的作用。
回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
模块独立
模块独立是指每个模块完成一个相对独立的子功能，并且与其他模块之间的联系简单。
//衡量模块独立程度的度量标准有两个：
耦合和内聚。
软件质量
与明确定义的功能和性能需求的一致性
•与明确成文的开发标准的一致性
•与所有专业开发的软件所期望的隐含的特性（如：
健壮性、可维护性、良好的界面风格、可移植性等）的一致性
•软件的质量因素：
如正确性，性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性
软件复用
软件复用（SoftWareReuse）是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。
软件工程
软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。
它由方法、工具和过程三部分组成。
//软件工程是建立和使用一套合理的工程原则，从而经济地获得可靠的，可以在实际机器上//高效运行的软件。
数据字典
数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述，其目的是对数据流程图中的各个元素做出详细的说明。
耦合性
耦合性（Coupling），也叫耦合度，是对模块间关联程度的度量。
//耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。
内聚性
内聚性，又称块内联系，指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。
完善性维护
在系统的使用过程中，用户往往要求扩充原有系统的功能，增加一些在软件需求规范书中没有规定的功能与性能特征，以及对处理效率和编写程序的改进。
更正性维护
由于系统测试不可能揭露系统存在的所有错误，因此在系统投入运行后频繁的实际应用过程中，就有可能暴露出系统内隐藏的错误
适应性维护
适应性维护时为了使系统适应环境的变化而进行的维护工作。
预防性维护
系统维护工作不应总是被动地等待用户提出要求后才进行，应进行主动的预防性维护，即选择那些还有较长使用寿命，目前尚能正常运行，但可能将要发生变化或调整的系统进行维护，目的是通过预防性维护为未来的修改与调整奠定更好的基础。
多态性
同一操作作用于不同的类的实例，将产生不同的执行结果，即不同类的对象收到相同的消息时，得到不同的结果。
为什么要把软件分解为模块
采用模块化原理使软件结构清晰，不仅容易设计，也容易阅读和理解；模块化使软件容易测试和调试，因而有助于提高软件的可靠性；模块化可以提高软件的可修改性；模块化有助于开发过程的组织和管理；
//模块分解的目的是将系统“分而治之”，以降低问题的复杂性，使软件结构清晰易阅读、//易理解、易于测试和调试，因而也有助于提高软件的可靠性
什么是软件生存周期模型
软件生命周期模型是软件开发的全部过程、活动和任务的结构框架。
软件生命周期模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目开发的基础。
白盒测试和黑盒测试的特点和主要区别
白盒测试方法按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。
黑盒测试并不涉及程序的内部结构和内容特性，主要根据规格说明，只依靠被测试程序的输入和输出之间关系或程序的功能来设计测试用例。
.非渐增式测试与渐增式测试有什么区别？
答：
（1）非渐增式方法把单元测试和集成测试分成两个不同的阶段，前一阶段完成模块的单元测试，后一阶段完成集成测试。
而渐增式测试往往把单元测试和集成测试合在一起，同时完成。
（2）非渐增式需要更多的工作量，因为每个模块都需要驱动模块和桩模块，而渐增式利用已测试过的模块作为驱动模块或桩模块，因此工作量少。
（3）渐增式可以较早地发现接口之间的错误，非渐增式最后组装时才发现。
（4）渐增式有利于排错，发生错误往往和最近新加入的模块有关，而非渐增式发现接口错误推迟到最后，很难判断是哪一部分接口出错。
（5）渐增式比较彻底，已测试的模块和新的模块再测试。
（6）渐增式点用时间较多，但非渐增式所需更多的驱动模块和桩模块也占用一些时间。
（7）非渐增式开始可并行测试所有模块，能充分利用人力，对测试大型软件很有意义
软件开发模型
•瀑布模型（经常发生阻塞状态于开始和结束时）
•增量开发模型（具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
）
•原型法（尽快开发一个简化的系统原型版本。
用于用户和开发人员学习和交流）
•螺旋模型（将瀑布模型和增量模型结合起来，并加入了风险分析）
•喷泉模型（适用于面向对象技术该模型中各阶段的界线不是明显分开的，而是相互重叠的）
•智能模型（特点是必须建立知识库，并将模型本身、软件工程知识、特定领域知识放入知识库。
）
瀑布模型（WaterfallModel）
它将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
优点：
1）有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
2）与用户见面晚，从而增加了开发的风险；
3）早期的错误可能要等到开发后期的测试阶段才能发现，发现问题越晚代价越高
传统"瀑布模型"的主要缺陷是什么？
试说明造成缺陷的原因。
答：
“瀑布模型是文档驱动的”。
在项目的早期，用户常常很难清楚地给出所有需求，瀑布模型却要求如此。
由于瀑布模型的特点，早期的错误直到开发晚期才能被发现，开发的风险较大。
适用范围：
瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。
例如操作系统、编译系统、数据库管理系统等系统软件的开发。
应用有一定的局限性。
原型模式
在项目开发的早期尽快开发一个简化的系统原型版本。
用于用户和开发人员学习和交流。
•多次分析和设计
•针对事先不能完成定义需求的软件开发
存在问题：
用户将原型认为是最终产品，开发者有时也不会坚持原则。
适用：
它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目组成员（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情况。
快速原型模型
又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。
快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。
通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
优点：
减少由于软件需求不明确带来的开发风险。
//
（1）可以得到比较良好的需求定义，容易适应需求的变化；
（2）有利于开发与培训的同//步；（3）开发费用低、开发周期短且对用户更友好。
缺点：
所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
//
（1）客户与开发者对原型理解不同；
（2）准确的原型设计比较困难；（3）不利于开发//人员的创新。
增量模型
增量模型是一种非整体开发的模型，分为两种形式：
基于瀑布模型的渐增模型；基于原型的快速原型模型
增量模型的优点：
（1）采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源；
（2）如果核心产品很受欢迎，则可增加人力实现下一个增量；（3）可先发布部分功能给客户，对客户起到镇静剂的作用。
缺点：
（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性
增量模型和瀑布模型之间的本质区别是：
瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。
而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产生工作软件。
增量模型的使用范围：
（1）进行已有产品升级或新版本开发，增量模型是非常适合的；
（2）对完成期限严格要求的产品，可以使用增量模型；（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的
循环模式
螺旋模型
将瀑布模型和增量模型结合起来，并加入了风险分析，按照计划-》风险分析-》工程-》用户评价，象螺旋线一圈一圈地向外发展，最终建立起运行的系统。
主要分为四个工作步骤：
（1）制定计划：
确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：
分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：
实施软件开发和验证；
（4）客户评估：
评价开发工作，提出修正建议，制定下一步计划。
优点：
1）设计上的灵活性,可以在项目的各个阶段进行变更。
2）以小的分段来构建大型系统,使成本计算变得简单容易。
3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
4）随着项目推进,客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互。
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
缺点：
1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
2）过多的迭代次数会增加开发成本，延迟提交时间。
适应场合：
支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。
喷泉模型
•适用于面向对象技术
•该模型中各阶段的界线不是明显分开的，而是相互重叠的
是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
优点：
该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。
其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
缺点：
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
智能模型
也称为基于知识的软件开发模型，是知识工程与软件工程相结合的软件开发模型。
其主要特点是必须建立知识库，并将模型本身、软件工程知识、特定领域知识放入知识库。
具体描述可以使用形式功能规约，也可以使用知识处理语言描述等。
RUB模型
•适用于面向对象技术
•RUP将软件开发过程分为4个阶段:
初始阶段（Inception）
筹划阶段（Elaboration）
构建阶段（Construction）
转换阶段（Transition）
边做边改模型（Build-and-FixModel）
在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2）忽略需求环节，给软件开发带来很大的风险；
（3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
黑盒测试（确认功能）：
指把测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求，又称为功能测试或数据驱动测试。
优点：
①适用于各阶段测试②从产品功能角度测试③容易入手生成测试数据
缺点：
①某些代码得不到测试②如果规格说明有误，则无法发现③不易进行充分性测试
白盒测试（验证逻辑）：
指把测试对象看成一个打开的盒子，测试人员需了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。
优点：
①可构成测试数据使特定程序部分得到测试②有一定的充分性度量手段③可或较多工具支
缺点：
①不易生成测试数据（通常）②无法对未实现规格说明的部分进行测试③工作量大，通常只用于单元测试，有应用局限
软件开发组织
常见的三种组织形式：
主程序员组、民主制小组、层次式小组
主程序员组
主程序员是指一支软件开发队伍的领导者，不管他的职务是开发组长，项目经理，还是部门经理。
主程序员是技术性的基层或中层干部，是软件企业得以发展的生力军。
好的主程序员至少应具备以下几个条件：
•技术水平是程序员队伍中的最高级别
•能做最多且最难的工作
•有人格魅力等
现代程序员组
可行性研究报告：
说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施的方案，说明并论证所选定实施方案的理由。
项目开发计划：
为软件项目实施方案制定出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。
项目开发计划应提供给管理部门，并作为开发阶段评审的参考。
软件需求说明书：
也称软件（系统）规格说明书，其中对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。
它是用户与开发人员双方对软件需求取得共同理解基础上达成的协议，也是实施开发工作的基础。
数据要求说明书：
该说明书应给出数据逻辑描述和数据采 集的各项要求，为生成和维护 系统数据文卷作好准备。
概要设计说明书：
该说 明书是概要设计阶段的工作 成果，它应说明功能分配、模 块划分、程序的总体结构、输 入输出以及接口设计、运行设 计、数据结构设计和出错处理 设计等，为详细设计奠定基 础。
详细设计说明书：
着重 描述每一模块是怎样实现的， 包括实现算法、逻辑流程等。
用户手册：
本手册详细 描述软件的功能、性能和用户 界面，使用户了解如何使用该软件。
数据流图的作用
（1）系统分析员用这种工具可以自顶向下分析系统信息流程。
（2）可在图上画出需要计算机处理的部分。
（3）根据数据存贮，进一步作数据分析，向数据库设计过渡。
（4）根据数据流向，定出存取方式。
（5）对应一个处理过程，用相应的语言、判定表等工具表达处理方法。
其中的符号表示什么含义？
箭头表示数据流、圆圈表示加工、双横线表示存储、方框表示数据的原点和终点。
软件项目无法按时解决该如何做：
1）PM与最终用户沟通：
把用户的更改要求和我们的理解与用户进行了更加细致的沟通确认，让用户认识到我们非常在意他们的意愿，但是按照原来的方案更改的话，项目正式运行时间至少要延期半个月，其实这个风险对用户方的影响也很大，最终项目组与用户达成了折中的方案：
项目组在正式运行的时候，只是更改那些工作量不是非常大的但是不解决无法让用户方领导满意的问题，而对于其它的问题，都放在正式运行之后一直到验收这段时间来完成。
其实，当时用户并没有想得非常多，只是想尽量尽早的把所有的工作提前做完，也并没有认真考虑到很多工作需要耗费大量的时间和精力而导致整个项目拖延而影响到他们自己，而这些工作大部分并不是那么要紧。
经过第一次沟通以后，项目组成员对于项目的问题和期限有了更加清晰的认识，已经能够感觉到其实用户并非是故意难为项目组，项目即使延期，对项目整体的影响并不大。
2）PM与部门领导沟通：
把项目需求变更可能导致延期的问题和原因进行了汇报，随即在项目例会中，部门领导对项目组的整体成绩给予了肯定，对项目组的优秀人员给予了口头表彰，对个别的非常懈怠的员工也提出了一定的批评。
终于，项目组内部的种种猜疑都基本上结束了，用户方和部门内部对于项目的问题都有了比较清楚的认识，项目组的成员也都明白：
项目虽然有困难，但是还是会成功结束的，每一个人的利益其实并不受什么影响。
3）PM与项目组内部沟通：
沟通的问题解决以后，还是有个别涣散军心的人继续做一些对项目不利的事情。
但是这个人在项目组中又比较重要，如果轻易的在项目组中去除，很多比较关键的工作就没有人负责了。
为了避免这个人笼络更多的人，最后掌握更多的要害来要挟项目组而造成更坏的结果，当时在项目组中专门制定了“代码同行评审”的制度，每天抽出一点时间对于项目中比较共性的设计、代码进行相互评审，这也是一个相互学习的过程，对于表现比较好的个人记入绩效，予以表彰。
这不但让每个人都有更多机会了解学习他人，也给每个人提供了更加好的展示自己的舞台，大大激发了大家学习进取的积极性。
这样不但更好的保证设计与编码的一致性以及好的设计、代码的复用性，而且大大降低了个别人的变动对整个项目组的影响。
然后项目组决定把涣散军心的人的地位抬高到系统设计师的地位，而把具体的工作不断的拆分给那些比较好学的其它人员手中。
升级会员 