第一章：软件工程概论
软件工程概论
应用软件
为满足特定应用领域、不同应用问题之需求的专用软件
支撑软件
软件系统的中间层，支撑各种软件的开发运行与维护的软件
系统软件
最靠近计算机硬件的一层软件——控制和协调计算机及外部设备，支持应用软件开发与运行的软件
软件的四大特征——复杂性
软件的四大特征——不可见性
软件的四大特征——易变性
软件的四大特征——一致性
遗留系统
仍在使用的软件系统，可满足客户需求，但很难以“优雅的”方式对其进行演变以适应新需求或新环境。
软件危机
计算机软件开发和维护的过程中所遇到的一系列严重问题
软件神话
关于软件及其开发过程中的一些说法被人盲目相信
软件工程
是为了经济的获得能够在实际机器上高效运行的可靠软件而建立和使用的一系列工程化原则。
软件开发方法——结构化开发方法
软件开发方法——面向对象的开发方法
软件开发方法——面向服务的开发方法
软件开发环境
多个工具集成在一起，形成了软件工程的开发环境，支持软件开发的全过程。
软件质量
软件产品与需求一致的程度，由一系列质量特性来描述；
敏捷过程与方法
软件项目管理
项目
为创建某种特定的产品或服务而住址或设计的临时的一次性的活动，通过执行一组活动，使用受约束的资源（资金、人、原料、能源、空间等）来满足预定义的目标
项目管理
有效的组织和管理各类资源（例如人），以使项目能够在预定的范围、质量、时间、成本等约束条件下顺利交付
软件项目特征：软件产品的不可见性：软件项目复杂和抽象；软件的高度不确定性：预定计划与实际情况存在较大偏差；软件过程的多变化性：不确定、不稳定；软件人员的高技能及其高流动性：风险；
软件项目管理的4p
人员、过程、产品、工具
一窝蜂模式
主治医师模式
首席程序员处理主要模块的设计与编写，其他成员从各种角度支持他的工作。
社区模式
很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量。
交响乐团模式
人多门类齐全，各司其职，各有专门场地，演奏期间严格遵守纪律。
爵士乐模式
演奏时没有谱子，没有现场指挥
功能团队模式
具备不同能力的同事平等协作，共同完成一个项目开发；在这个项目完成之后，这些人又和别的角色一起去完成下一个功能，他们之间没有管理和被管理的关系。
官僚模式
软件产品
是指向用户提供的计算机软件、信息系统或设备中的嵌入的软件或在提供计算机信息系统集成、应用服务等技术服务时提供的计算机软件。
产品结构分解（PBS）
通过分层的树型结构来定义和组织范围内的所有产出物，自顶向下，逐级细分
工作结构分解（WBS）
通过分层的树型结构来定义和组织工作任务之间的分解关系，自顶向下，逐级细分。
W5HH原则
项目管理过程
项目先后衔接的各个阶段
项目管理核心要素——功能性
项目管理核心要素——可信性
项目管理核心要素——易使用性
项目管理核心要素——可维护性
项目管理核心要素——可移植性
项目管理的主要任务
项目可行性分析与估算、项目进度安排、项目风险管理、项目质量管理、项目跟踪与控制
范围
描述了将要交付给最终用户的功能和特性、输入输出数据、用户界面、系统的性能、约束条件、结构和可靠性，以及期望的时间、成本目标；
可行性分析——技术可行性
可行性分析——经济可行性
可行性分析——时间可行性
可行性分析——资源可行性
项目进度计划
确保合同工期和主要里程碑时间的前提下，对设计，采办和施工的各项作业进行时间和逻辑上的合理安排，以达到合理利用资源，降低费用支出和减少施工干扰的目的。
项目进度跟踪
项目进度表只是提供了一张进度路线图，在实际执行过程中需要对其进行跟踪和控制，以决定是否需要对进度计划进行调整。
git的基本思想
Git关心文件数据的整体是否发生变化，直接会将文件提交时的数据保存成快照，并不保存这些前后变化的差异数据，并且使用SHA-1加密算法保证数据的完整性。
把变化的文件作快照后，记录在一个微型的文件系统中。
每次提交更新时，它会遍历一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。
为提高性能，若文件没有变化，Git不会再次保存，而只对上次保存的快照作一链接。
软件编码与测试
代码评审分析和优化
代码评审
是被主流IT行业普遍认同的，提高代码质量的有效途径之一。
代码评审主要内容——设计
代码评审主要内容——功能性
代码评审主要内容——复杂度
代码评审主要内容——测试
代码评审主要内容——注释
代码评审主要内容——命名
代码评审主要内容——文档
代码复审
代码中是否存在“代码规范”的框架内正确地解决了问题
走查
由设计人员或变成人员组成一个走查小组，通过阅读一段文档或代码，并进行体委和讨论，从而发现可能存在的缺陷、遗漏和矛盾的地方。
类型：设计走查、代码走查
静态代码分析
在代码构建过程中帮助开发人员快速有效的定位代码缺陷。
主要技术：缺陷模式匹配、类型推断、模型检查、数据流分析。
性能分析
以收集程序运行时信息为手段研究程序行为的分析方法，是一种动态程序分析的方法。
目的：
决定程序那个部分应该被优化，从而提高程序的速度或内存使用效率。
两种方法：抽样、代码注入
需求分析
软件需求与需求获取
软件需求
以一种清晰、简洁、一致且无二义性的方法描述用户对目标系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。
业务需求
客户对于系统的高层次目标要求，定义了项目的远景和范畴。
用户需求
从用户角度描述的系统功能需求和非功能需求，通常只设计系统的外部行为而不设计内部特性。
功能需求
系统应该提供的功能或服务，通常设计用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节。
非功能需求
从各个角度对系统的约束和限制，反映了客户对软件系统质量和性能的额外要求，如响应时间、数据精度、可靠性等。
约束条件
系统设计和实现时必须满足的限制条件，对其进行权衡和调整是相当困难的，甚至是不可能的。
业务规则
是指对业务定义和约束的描述，是对某系功能的可执行性或内部执行逻辑的一些限定条件。
外部接口需求
描述系统与其所处外部环境之间如何进行交互
好需求具备特征
完整性、正确性、可行性、必要性、划分优先级、可验证性、无二义性。
产生不合格需求原因
没有用户参与，模棱两可的需求、不必要的特性、过于精简的规格说明、忽略用户分类、不准确的计划。
需求工程
应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的过程。
需求工程的总体流程
需求获取
通过与用户的交流，对现有的系统的观察及对任务进行分析，从而开捕获和修订用户的需求。
需求分析
对收集到的需求进行提炼、分析和审查，为最终用户所看到的系统建立概念化的分析模型
需求规格说明
需求开发的结果
精确的、形式化的阐述一个软件系统必须提供的功能、非功能、所要考虑的限制条件等
作为用户和开发者之间的一个契约
是用户、分析人员和设计人员之间进行理解和交流的手段
需求验证
以需求规格说明为输入，通过评审、模拟或快速原型等途径，分析需求规格的正确性和可行性，发现存在的错误或缺陷并及时更改和补充。
需求管理
