研究生复试巩固软工
自己给自己出题目
参考《Software Engineering》
软件生命周期
- 问题定义与可行性研究
- 需求分析
- 软件设计
- 编码
- 测试
- 运行和维护
★ 瀑布模型，适用哪些用户
最早强调软件或系统开发应有完整之周期，且必须完整的经历周期之每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等。
强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制
优点：
- 上一项活动的输出为下一项活动的输入
- 强调开发的阶段性、早期计划、产品测试
缺点：
- 依赖早期进行的唯一一次需求调查，不能适应需求变化
- 单一流程，开发中的经验教训不能反馈于本产品
喷泉模型
软件生命周期的各个阶段是相互重叠和多次反复的。
与瀑布模型类似，只是从串行改并行
主要用于面向对象方法中，面向对象的分析和设计重叠，交叉、并行进行。
增量模型
从给定需求开始，通过构造一系列中间版本来实施开发活动，依次类推，直到系统完成。
每一个中间版本都是需求分析、设计、编码和测试的过程。
某些中间版本的开发可以并行进行。
特点：
- 融合了线性顺序模型的基本成分和原型的迭代特征。
- 是随着日程时间的进展而交错的线性序列。
- 与原型不一样的地方是强调每个增量均发布一个可操作产品。
- 最典型的应用是同一个产品的不同项目（合同、用户）版本
★ 模块的概念
是数据说明，可执行语句等程序对象的集合。例：过程，函数，子程序，宏等。
一般一个模块完成一个子功能。
- 信息隐蔽：每个模块的实现细节对于其他模块来说是隐蔽的
- 模块独立性：即每个模块完成一个相对独立的特定子功能，且和其他模块之间的关系很简单。
★ 模块间耦合度
度量模块独立性的准则：内聚、耦合。
- 内聚：是模块功能强度（即一个模块内部各个元素彼此结合的紧密程度）的度量。模块内部各元素之间联系越紧密，内聚性越强。
- 耦合：是模块之间相对独立性（即互相连接的紧密程度）的度量。模块间连接越紧密，联系越多，耦合性越强。
★ 区分模块的要素是什么
- 输入和输出
- 处理功能
- 内部数据
- 程序代码
（可能有误） 模块与构件相比，没有继承和多态性，没有实例化的概念
★ 软件的设计模式（增量、喷泉、瀑布）
（偏题）
MVC模式（模型-视图-控制器）
- 模型：管理系统数据和在数据上的操作
- 视图：定义和管理如何显示数据给用户
- 控制器：管理用户的交互，并传递这些交互给视图和模型
- （典型观察者(Observer)模式）
- 显示内容与数据密切相关，数据是目标，显示是观察者或订阅者。
- 目标的改变要让观察者都知道，并做出相应的改变。观察者的数量、显示方式都是不确定的。
- 目标是通知的发布者，它发出通知时，并不知道谁是订阅者、有多少订阅者、是什么样的订阅者。
- 模型部件作为目标—出版者，视图和控制器作为观察者、订阅者。
- 注册是一个特定过程，使得视图和控制器可以向出版者自由订阅和退定。
- 模型的内容如果改变了状态，需要通知每个订阅者。
分层体系结构
- 每一层包含一组相关的功能。每一层提供服务给紧邻的上一层。
- 可再接口不变的条件下更换一整个层，便于移植
容器体系结构
- 所有数据在一个中央容器中管理。中央组件被所有系统组件访问。组件之间只能通过容器交互。
- 组件是独立的，一个组件的变更可以传播到所有的组件。所有的数据可以得到一致性的管理。
客户机-服务器体系结构
- 系统的功能以服务器的形态存在。每一个服务来自于某个单独的服务器。客户机是那些使用服务和访问服务器的用户。
- 服务器可以分布在网络上，一般性的功能可以被所有的客户机访问，但并不需要所有的服务实现。
以上为复合设计模式
《Head First 设计模式》提到的常用设计模式如下：
观察者模式 装饰者模式 工厂模式 单件模式
命令模式 适配器模式 模板方法模式 迭代器与组合模式
状态模式 代理模式
IPO图、层次图、DFD图等的使用阶段，作用，描述
扩展：
层次图：每个方框代表一个模块，方框间的连线表示调用关系
. 使用阶段 作用 实体-关系图 ERD 需求分析阶段 数据建模 数据流图 DFD 需求分析阶段 功能建模 状态转换图 STD 需求分析阶段 行为建模 层次图 总体设计阶段 说明每个模块的被调用、调用 输入加工输出图 IPO 总体设计阶段 说明每个模块的输入、输出、被调用、调用、处理 结构图 SC 总体设计阶段 模块之间的层次调用关系和联系 程序流程图 详细设计阶段 过程设计 盒图 (N-S图) 详细设计阶段 过程设计 问题分析图 PAD 详细设计阶段 过程设计 判定树 、判定表、过程设计语言 详细设计阶段 过程设计 Jackson 详细设计阶段 面向数据结构设计
CMM
CMM：软件过程能力成熟度模型
给出了从混乱、个人的过程到成熟的规范化过程的一个框架
软件工程为什么要测试
- 测试是程序的执行过程，目的在于发现错误
- 一个成功的测试用例在于发现至今未发现的错误
- 一个成功的测试是发现了至今未发现的错误的测试
- 确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。
- 确保产品满足性能和效率的要求
- 确保产品是健壮的和适应用户环境的
黑盒白盒
白盒：保证封装性前提下，用户可通过继承等机制对实现细节进行修改（单元测试）
- 测试过程的早期阶段
白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。
黑盒：用户对接口和规约的实现细节一无所知（集成测试）
- 测试过程的后期阶段
- 是与白盒测试互补的测试方法，它很可能发现白盒测试不易发现的其他类型的错误
- 如数据边界，数据量，特定输入值
一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。
做项目的过程
- 需求分析
- 相关系统分析员向用户初步了解需求，然后用相关的工具软件列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。
- 系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。
- 系统分析员向用户再次确认需求。
- 概要设计
首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。 - 详细设计
在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。 - 编码
在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题！ - 测试
测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。软件测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输入范围，可以分为全覆盖测试和抽样测试。以上都很好理解，不再解释。总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会有不可预料的问题存在。完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，直到这个软件被彻底淘汰为止。 - 软件交付
在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。
《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。
《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容，在需要时还应举例说明。 - 验收
用户验收。 - 维护
根据用户需求的变化或环境的变化，对应用程序进行全部或部分的修改。
765
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
