定义：软件工程是一种系统工程，不止包括对技术问题的分析与解决，还包括对开发过程和给参与者分配合适的角色等方面的管理目的：生产出高质量的软件进而找到解决方案，并考虑那些对质量有影响的特性方法及作用：分析（analysis）—分析问题，调查软件正反两方面，设计（design）—给出解决方案，发展团队（developingteam）—描述在团队中的人员的角色和职责，发展（develop）—实现解决方案（实现对象、活动、封装等等），项目管理（projectmanagement）—将系统分为小部分，逐步明确过程，控制进度，处理每个改变等等
它表示开发软件时特定的方法或哲学。
错误[error]，是进行软件开发过程中人为出错造成的例如，设计人员可能误解了某个需求，创建出与需求分析人员和用户的实际意图不相符的设计。这个设计故障是一种错误的编码，可能导致其他故障，如不正确的代码或用户手册中不正确的描述等。故障/缺陷[fault]：当人们在进行软件开发活动的过程中出现错误时，就会引起缺陷。（静态存在）失效[failure]是指系统违背了它应有的行为（由于故障产生）。（动态存在）例如，需求文档可能会包含故障，所以即使系统按照需求规格来运行，如果它未进行应有的行为，也称为失效。联系：单个错误可能产生多个故障。故障是系统的内部视图，这是从开发人员的角度看待系统；而失效是系统的外部视图，它是用户所看到的问题。并非每一个故障都对应于一个失效（不执行故障代码就不会是代码失效）。
1.活动和对象2.关系和系统边界Asystem=entities(实体)+activities(活动)+relationships(关系)+boundary(边界)
1.需求分析和定义───需求规格说明2.系统设计────设计描述3.程序设计─┐4.程序实现─┴─程序文档5.单元测试─┐6.集成测试─┼─测试数据7.系统测试─┘8.系统交付─┬─培训手册9.维护─┘
抽象（abstraction）是在某种概括层次上对问题的描述，使得我们能够集中于问题的关键方面而不会陷入细节。
定义：软件开发活动中的各种组织及规范方法。重要性：具有通用性（一致性、结构性）和指导性。阶段：上有
重复采用以前开发的软件系统中具有共性的部件,用到新的开发项目中去。
瀑布模型将开发阶段描述为从一个阶段瀑布般转到另外一个阶段。一个开发阶段必须在另一个开发阶段之前完成。优点：·在帮助开发人员布置他们需要做的工作时，瀑布模型是非常有用的；·它的简单性使得开发人员很容易向不熟悉软件开发的客户作出解释。·是其他复杂模型的基础缺点：·瀑布模型最大的问题是它并不能反映实际的代码开发方式。·面临软件变动时,该模型无法处理实际过程中的重复开发问题·文档转换有困难
原型（prototype）是一个部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。
definition:系统被设计成部分提交,每次用户只能得到部分功能,而其他部分处于开发过程中。分类及特点：增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。迭代开发：系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强。
四象限：·确定目标、可选方案及约束；·评估可选方案及风险·计划·开发与测试操作概念是第一次迭代的产品，而需求则是第二次迭代的主要产品，第三次迭代系统开发产生设计，第四次迭代能够进行测试。
瀑布模型V模型原型化模型可操作规格模型分阶段开发模型螺旋模型瀑布模型从一种非常高层的角度描述了软件开发过程中进行的活动，并且提出了要求开发人员经过的事件序列。该模型适用于项目开始时需求已确定的情况。V模型是瀑布模型的变种，它说明测试活动是如何与分析和设计相联系的。原型模型允许开发人员快速地构造整个系统或系统的一部分以理解或澄清问题。原型的用途是获知用户的真正需求，因此原型模型可以有效地引发系统需求。螺旋模型把开发活动和风险管理结合起来，以将风险减到最小并控制风险。
1.设计对于分析模型应该是可跟踪的：软件的模块可能被映射到多个需求上。2.设计结构应当尽可能的模拟实际问题。3.设计应当表现出一致性。4.不要把设计当成编写代码。5.在创建设计时就应该能够评估质量。6.评审设计以减少语义性的错误。
统一过程（RUP/UP，RationalUnifiedProcess）是一种以用例驱动、以体系结构为核心、迭代及增量的软件过程模型，由UML方法和工具支持，广泛应用于各类面向对象项目。统一过程是一个面向对象且基于网络的程序开发方法论。
完成工作的能力，对工作的兴趣，开发类似应用的经验，使用类似工具或语言、开发环境、技术的经验，培训，与其他人交流的能力，与其他人共同承担责任的能力。管理技能
专家估算：请几位专家做出3种预测，来形式化地表示类推过程：一个悲观的预测（x）、一个乐观的预测（y），和最可能的预测（z），通过公式（x+4y+z）/6计算这些数的beta概率分布的平均值。通过使用这种技术，产生的估算是对个人估算的“规范化”。算式估算（这个不用看）：研究人员已经创建出表示工作量和影响工作量的因素之间关系的模型。这些模型通常用方程式描述。大部分模型认为项目规模是方程式中影响最大的因素，表示工作量的方程是：E=(a+bSc)m(X)。其中S是估算的系统规模，而a、b、c是常量。X是从x1到xn的一个成本因素的向量，m是基于这些因素的一个调整因子。
阶段1（应用组装）：根据高层的工作量生成器来获取项目的规模。阶段2（早期设计）：使用功能点对规模进行测量。阶段3（后体系结构）：根据功能点或代码行来进行规模预算。
风险：人们不希望看到的、有负面结果的事件。·通过改变性能或功能需求来降低风险·通过把风险分配到其他系统中，或者购买保险以便在风险成为事实弥补经济上的损失·假设风险会发生，接受并用项目资源控制风险
需求，就是对期望的行为的表达。
（1）绝对要满足的需求（必须的）（2）非常值得要的但并非必须的需求（值得要的）（3）可要可不要的需求（可选的）例如：信用卡记账系统，要求列出最近的费用（1）、要求加起来并要求在某日期前支付（2）、要求购买类型分析（3）
A:针对需求确定一种量化的描述方法，避免模糊的表达方式B:将各种指代用词替换为实体的正式名称C:每个名词或款项应在需求文档中给出唯一定义。
DFD：DataFlowDiagrams数据流图
抛弃型原型是为了对问题或者提议的解决方案有更多的了解而开发的软件。演化型原型是这样的软件：不仅帮助我们回答问题，而且还要演变为最终的产品。Chapter05
早期的设计决策专注于系统的体系结构，用以解释如何将系统分解为单元以及这些单元又如何相互关联
体系结构设计:由软件需求中的系统能力与系统部件关联起来而得到软件整体结构的过程代码设计:各个部件（模块）的算法、数据结构的设计运行设计:最底层设计—内存分配、数据格式、位模式等等关系：流程工作中，先是体系结构设计，然后是代码设计，最后是运行设计；随着设计人员对解决方案及其含义有更多的理解，他们就会往返于各层次之间。（程序设计由代码设计和运行设计组成）
·设计界面要注意解决的要素（寓意/比喻、思维模型、领航规则、外观、感觉）；·文化差异问题；·用户爱好问题Chapter06
耦合：两个软件部件之间的相互关联程度内聚：软件部件内部的关联程度层次划分：如下
面向对象是一种软件开发方法，它将问题及其解决方法组织成一系列独立的对象，数据结构和动作都被包括在内
基本特征：一致性、抽象、分类、封装、继承、多态、持久性
设计模式编写了设计决策以及最好的实践，它们根据设计原则来解决一些特定的问题；它们不是拿来就可以使用的打包的解决方案，而是解决方案的模板，必须针对特定的状况进行修改和调整。
模块化、接口、信息隐藏、增量式开发、抽象、通用性
语言具有一致性（在同一时期同时描述问题和解决方案）；过程具有一致性（从需求到测试，所有的过程采用相同的语义构造）。
OO需求、OO高级设计、OO低级设计、OOP、OO测试
这些表示法每种都显现了系统的某个方面，因此相应地，这种表达也提供了对于问题或解决方案的详细描述。熟悉类图中各个类之间的基本关系分类熟悉类图等的组成和画法了解UML其他图的基本用途。
第一，设计对于编码来说并不总是简单明了的；第二，编码应该是可懂的第三，需要考虑重用
编程标准对自身的用处编程标准对他人的用处设计与编程实现相匹配
1.其他程序注释、2.有意义的变量名和语句标记、3.安排格式以增强理解、4.文档化数据
极限编程（XP）是一种轻量级的软件开发方法论，属于敏捷开发方法。XP从实践中来，是对实践的总结，也是经过实践检验的，其主要特征是要适应环境变化和需求变化，充分发挥开发人员的主动精神。XP承诺降低软件项目风险，改善业务变化的反应能力，提高开发期间的生产力，为软件开发过程增加乐趣等等。派对编程属于主要的敏捷开发方法，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。
·规格说明可能是错误的，或者遗漏了某个需求；·对于指定的硬件和软件，规格说明中可能包含不可能实现的需求·系统设计中可能包含故障。·程序设计中可能包含故障。·程序代码可能是错误的。
当不存在明显的故障时，我们就测试程序，通过创造一些条件，使代码不能像计划的那样做出反应，看一看能否发现更多的故障。因此，知道我们正在查找什么类型的故障是很重要的。
A.算法故障B.计算故障和精度故障C.文档故障D.压力故障或过载故障E.能力故障或边界故障F.计时故障G.性能故障H.恢复故障I.硬盘和系统软件故障J.标准和过程路障
即使用忘我方法开发一个系统，有时也难以从测试过程中排除个人感情。因此，通常使用一个独立的测试小组来测试系统，这样，避免了故障的个人责任与尽可能多地发现故障的需要之间的冲突。
黑盒：从外部观察测试对象，将其看做是一个不了解其内容的闭盒或黑盒，那么，我们的测试就是向闭盒提供输入数据，并记录产生的输出。白盒：将测试对象看成是一个开盒（透明盒）或白盒，然后可以根据测试对象的结构用不同的方式来进行测试。
（1）自低向上集成（驱动程序）优点：易生成测试用例；适合于面向对象开发系统；底层为通用模块比较好缺点：顶层设计缺陷为主要的缺陷，不能及时地发现改正（2）自顶向下集成（桩）优点：顶层模块缺陷尽早发现缺点：产生测试用例比较难，需要大量的桩
面向对象系统的测试中更容易和更困难的部分：
（1）制定测试目标（2）设计测试用例（3）编写测试用例（4）测试测试用例（5）执行测试（6）评估测试结果（了解）
1.功能测试：系统是否按照需求中指定的那样执行它的功能2.性能测试：软件与非功能系统需求进行比较3.验收测试：根据用户的需求描述检查系统4.安装测试：保证系统按照它应有的方式进行
系统配置是向特定客户交付的一组系统组件。配置管理控制不同系统配置之间的差别，将风险和错误降低到最低程度。某个特定系统的一个配置有时称为一个版本基线是软件文档或源码的一个稳定版本,它是进一步开发的基础（这基线我百度的）
回归测试是用于新的版本或发布的一种测试，以验证与旧版本或发布相比，它是否以同样的方式执行相同的功能。
功能测试基于系统功能性需求，属于闭盒测试。我们不必知道正在执行哪个构件，相反，必须知道系统应该做什么。作用：将系统的实际表现与其需求进行比较。
·具有很高的故障检测概率·使用独立于设计人员和程序员的测试小组·了解期望的动作和输出·既要测试合法输入，也要测试不合法输入·永远不要为了使测试更加容易而去修改系统·制定停止测试标准
在我们确定系统能执行需求所要求的功能之后，就要考虑这些功能执行的方式。因此，功能测试针对的是功能需求，而性能测试针对的是非功能需求。
压力测试、容量测试、配置测试、兼容性测试、安全性测试、计时测试、环境测试、质量测试、恢复测试、维护测试、文档测试、人为因素测试
当功能测试和性能测试完成后，我们确信，系统满足在软件开发的初始阶段过程中指定的所有需求，下一步要询问客户和用户，他们是否持有同样的观点。在基准测试中，客户准备一组代表在实际安装后系统运作的典型情况的测试用例。针对每一个测试用例，客户评估系统的执行情况。在并行测试中，新系统与先前版本并行运转，用户逐渐地适应新系统，但是继续使用与新系统功能相同的老系统。
在客户进行实际的试验性测试之前先让来自自己组织机构或公司的用户来测试这个系统，这样的内部测试称为α测试。β测试：客户的测试，属于试用性质的非正式的验收测试。
即在用户的场所安装系统。如果验收测试已经是在实地进行，就不一定需要安装测试了。