软件过程附带概念.docx

软件过程附带概念：持续集成：频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。 软件质量保障：原由：软件产品的评审过程、项目的计划和跟踪过程、软件需求分析过程、软件设计过程、软件实现和单元测试过程、集成和系统测试过程、项目交付过程、子承包商控制过程、配置管理过程。特别要强调的是，为保证软件质量，应赋予SQA阻止交付某些不符合项目需求和标准产品的权利。在进行评审和测试时可检测到缺陷。评审是面向人的过程，测试是运行软件(或部分软件)以便发现缺陷。在一个项目里，评审和测试活动是预先策划好的(计划书中确定执行哪些质量控制活动和何时执行这些活动)。在执行过程中，根据已定义好的过程来执行这些活动。通过执行这些活动来识别缺陷，然后消除这些缺陷。例如，系统测试过程一般包括制定测试计划，测试计划中应列出在测试执行过程中所有的测试用例，评审测试计划，并且最终执行测试计划。 　缺陷在软件开发的任何阶段都可能会被引入。项目质量管理过程包含了许多可以识别缺陷、消除缺陷的过程。“识别缺陷”和“消除缺陷”本来是两个不同的过程，但在这里为了简便统一用“消除”来代表它们。潜在的缺陷越大，用来消除它所花的费用越高。因此成熟的软件开发过程在每一个可能会引入潜在缺陷的阶段完成之后都会开展质量控制活动。这些为了消除缺陷的活动包括：需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。 表现形式：审查，走查，？廊道测试，结对编程，问题桌查，轮查，临时评审；阶段：配置管理：最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。版本控制 e.g. svn配置管理工具；变更控制，实现可以基于版本控制的历史记录还原；配置控制；软件质量保障包括哪几方面功能性；可靠性；可移植性；可维护性；效率；可用性；需求阶段：★建立用例图以及用例文档(对用例图的描述，一个用例就是现实世界中一个用户可能执行的功能的流程)；用例：actor(主动发起人)，还有参与者，以及一个方框中一堆的功能几点，通过一定顺序的组织和聚合可以完成一个个用例；★建立分析类图：根据不同用例确定系统分类的对象，并且将这些对象应当具有的属性（没有操作的方法），还有对象间的一一对应关系通过规范的图显示出来；+为public；-为私有属性；关系：继承----△； 关联---直接连线； 聚合---持有，一般是◇； ★系统顺序图；需return的箭头应当是实心箭头；Return的线应当是虚线，同时箭头传递的内容应当标明；顺序图应当注意的是 | | | 对象在系统中的对于每个参与行为的生命周期，且对于某个特定的用例功能的顺序实现，应当是按照应答式机制，即异步方式完成的；★状态图：以〇为起始；并以⊙为终点；中间每个节点都是系统的可能的状态，并且状态节点之间使用箭头进行连接，同时箭头可以表明状态发生转移的条件；软件体系结构设计： 常见的软件体系结构一般有九种：其中四种分别是;主程序/子程序基于过程抽象机制，强调将一个过程分解为多个子过程，直到定义至一定粒度为止，有点类似设计模式中的组合模式；注意与分层区别开来！ 分层是看做一组组功能的集合，即模块化的思想；自顶向下；同时对于一些子过程的修改可能涉及这个过程树的相关的多个节点，从而带来连锁效应；面向对象oo将系统的模块或者构件看见数个对象相互通信从而完成的具体功能；每个对象封装了其数据以及相关的属性行为；对象之间通过通信从而完成上层系统的任务；对于可维护性高要求的软件面向对象体系无疑是一个不错的选择；隐式调用对应于设计模式中的观察者模式；通过构件来声明一个或者多个对象，同时其他对象通过对于该声明链的注册，来决定对于每次的声明的响应结果，即声明者对于每次的响应并不需要知道是调用了谁，这使得程序的可扩展性得到了进一步的增强；同时声明者不能确定在声明过后各个对象的响应次序；分层风格：将系统定义为不同层次之间的调用抽象，与外界进行交互的就只有最上层的抽象，同时相对下层的抽象完成一个完整的子功能，不同子功能之间的协作完成相对上层的抽象的要求；软件设计层次：高层设计：针对系统的体系层面上的规划；中层设计：根据高层设计中的分解出相应的构件，研究这些构件之间的关系的较优的解决方案；底层设计：代码相关，即编码的可读性，单个程序结构设计，以及代码可维护性可修改性等等方面的考虑；体系结构设计完成之后，就应当考