第1章 软件工程的内容和方法
程序是计算机为完成特定任务而执行的指令的有序集合。
软件=程序+数据+文档
软件工程是研究软件开发方法和软件管理方法的一门工程学科
软件工程的三要素：软件工程的方法（开发方法）、工具（支持方法的工具）和过程（管理过程）。
软件工程的7条原理：（1）用分阶段的生存周期计划严格管理软件开发，分为计划、分析、设计、编程、测试和运行维护6个阶段。（2）坚持进行阶段评审。上一阶段评审不通过，就不能进入下一阶段开发。（3）实行严格的产品版本控制。（4）采用现代程序设计技术。（5）结果应能清楚地审查。（6）开发小组的成员要少而精。（7）要不断地改进软件工程实践的经验和技术，要与时俱进。
软件工程中常用的软件开发方法：面向过程的开发方法、面向对象的开发方法、面向数据的开发方法和形式化开发方法。
面向过程的开发方法的优点：简单好学；缺点：不适应窗口界面，维护困难；适用场合：大型工程计算，实时数据跟踪处理，各种自动化控制系统，以及系统软件实现等领域。
面向对象的开发方法的优点：功能强大，易于维护；缺点：不用掌握；适用场合：互联网时代，完全有用户交互控制程序执行过程的应用程序和系统软件的开发。
面向数据的开发方法的优点：通俗易懂；缺点：不适应窗口界面；适用场合：以关系数据库管理形态为支撑环境的信息系统建设。
形式化开发方法的优点：准确、严谨；缺点：难于上手和应用；适用场合：对安全性要求极高，不容许出错的软件系统，如军事、医药、交通等领域。
软件工程的五个面向理论：面向流程分析、面向数据设计、面向对象实现、面向功能测试和面向过程管理。
软件工程的过程管理有：ISO 9000 质量管理和质量保证体系、CMMI 软件能力成熟度模型和软件企业文化。
|
名称 |
来源 |
特点 |
|
ISO 9000 质量管理和质量保证体系 |
国际标准化组织 |
按20多个质量要素管理 |
|
CMMI 软件能力成熟度模型 |
美国卡内基-梅隆大学软件工程研究所（CMU/SEI） |
按24个过程域PA，分阶段模型和连续模型两种方式管理，属于重载过程管理 |
|
软件企业文化 |
Microsoft公司、IBM公司、敏捷方法 |
属于轻载过程管理 |
第2章 软件生产周期及开发模型
软件的生存周期：1 立项（或签合同）、下达任务书； 2 需求分析；3 概要设计；4 详细设计；5 编码实现；6 软件测试；7 软件发布与实施；8 软件维护；9 版本更新或退役。
瀑布模型的特点：1、里程碑或基线驱动，或者说文档驱动。2、过程逆转性很差或者说不可逆转。优点：开发阶段清晰。便于评审、设计、跟踪、管理和控制。缺点：过程逆转性差，错误以发散式扩大。
|
模型名称 |
优点 |
缺点 |
适用范围 |
|
瀑布 |
简单好学 |
逆转性差 |
面向过程开发 |
|
增量 |
可以分阶段提交 |
有时用户不同意 |
系统可拆卸和组装 |
|
迭代 |
克服了瀑布模型的缺点 |
风险大 |
有高素质软件团队 |
|
原型 |
开发速度快 |
不利于创新 |
已有产品的原型 |
第3章 软件立项与合同
“非订单软件”：通过市场调研之后，认为某产品将会产生巨大的市场空间，而软件公司在人力资源、设备资源、抵抗风险、资金和时间上都具备开发该产品的能力，于是决定立项，这类软件产品被称为“非订单软件”。
“订单软件”：与固定用户签订软件开发合同，由软件公司启动该项目的开发，这类软件被称为“订单软件”。
第4章 软件需求
需求分析为什么重要？
答：（1）许多大型应用系统的失败，最后均归结到需求分析的失败。
（2）需求分析的输出文档《用户需求分析》即使软件生产周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，是三者共同工作的基础，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据。
（3）需求分析要占整个软件开发时间或工作量的30%左右。
（4）需求获取中的错误属于软件开发早期错误，它会在后续的设计和实现中进行发散式传播。
需求获取为什么难？
答：（1）用户需求具有动态性
（2）用户需求具有模糊性
（3）开发者和用户要对需求达成完全一致的认识，用户要在需求报告上签字，要承担责任。
（4）中国的国有企业正处于变动期，中国的民营企业正处于成长期，造成需求不成熟、不稳定和不规范，增加了难度系数。
基线：基线是软件工作产品，它是经内部和外部评审过的，并且是下一阶段工作的基础。一根基线是一个里程碑或一个检查点。
检查点：检查点只是由时间、计划、事件驱动的检查工作进度和质量的一个记号。一个检查点不一定是一根基线或一个里程碑。
里程碑：里程碑是一个标记，只需要经过内部评审。一个里程碑是一个检查点，但不一定是基线。
评审：评审是对软件工作产品质量的一次开会或汇签活动。
审计：审计是复查评审活动程序的合法性，是否按程序与规范进行
需求来源：系统目的、行业知识、软件涉众、运行环境和组织环境。
需求分析的目的：用于说明软件产品或软件项目需要满足的条件和限制。
需求分析是对提取的需求进行分析整理，主要完成以下工作：1、需求分类，将相关需求组织成一个子集；2、检查需求是否准确，是否存在二义性；3、检查和解决不同需求间的冲突；4、分析软件的边界，以及软件与环境是如何相互作用的；5、从系统需求中推导软件需求。
第5章 软件策划
软件策划的4个步骤
|
步骤 |
步骤名称 |
步骤内容 |
|
1 |
估计软件工作产品的规模、工作量、费用及所需的资源 |
软件工作产品，包括需求规格说明书，概要设计说明书，详细设计说明书，源代码，测试计划和测试报告，质量保证计划，软件配置管理计划，里程碑及评审点计划 |
|
2 |
制定时间表 |
包括开发进度时间表和管理进度时间表：软件开发计划、质量保证计划、软件配置管理计划、测试计划、评审计划 |
|
3 |
鉴别和评估风险 |
政策风险，资源风险、市场突变风险、技术风险和技能风险 |
|
4 |
与相关的组或人协商策划中的有关约定 |
策划的结果要实事求是，要得到各方面的同意和认可 |
软件评估：是指对软件项目进行量化估计，并记录估计结果的过程。软件估计是软件策划的核心，是软件策划的重点和难点。
软件项目规模评估的估计方法：希腊古都法、类比法、功能点估计法、无礼估计法。（要求可分清适用范围P107）
第6章 软件设计
《概要设计说明书》和《详细设计说明书》的差异？
答：《概要设计说明书》一是要覆盖《需求规格说明书》的全部内容，二是要作为指导详细设计的依据。因此，塔注重于框架上的设计。《详细设计说明书》一是要覆盖《概要设计说明书》的全部内容，二是要作为指导程序设计的依据，因此，它注重于微观上和框架上的设计。在一般情况下，《概要设计说明书》由系统设计师负责，《详细设计说明书》则有高级程序员负责。
软件价格应描述以下问题：（1）软件系统镇南关包含了那些子系统和部件。（2）每个子系统和部件都完成那些功能。（3）子系统和部件对外提供或使用外部的哪些接口。（4）子系统和部件间的依赖关系，以及对实现和测试的影响。（5）系统是如何部署的。
OOA模型采用分层次结构划分为5层，它们分别是对象-类层、属性层、服务层、结构层和主题层。
OOD体系结构的4个部分内容：问题论域部分、人机交互部分、任务管理部分和数据管理部分。
第7章 软件建模
功能模型：描述系统能做什么，即对系统的功能、性能、接口和界面进行定义。
业务模型：描述系统在何时、何地、由和角色、按什么业务规则去做，以及做的步骤和流程，即对系统的操作流程进行定义。
数据模型：描述系统工作前的数据来自何处，工作中的数据暂存什么地方，工作后数据放到何处，以及这些数据之间的关联，即对系统的数据结构进行定义。
业务模型的描述方法有：组织结构图，岗位（或角色）职能表，业务流程图加上业务规则说明。
功能模型在需求分析时的表示方法有：系统功能需求列表、性能需求列表、接口需求列表、界面需求列表。
数据模型的描述方法有：系统的CDM（概念数据模型，即E-R图）和PDM（物理数据模型，即物理表），以及相应的表结构。
第8章 软件实现
从宏观上讲，软件实现包括详细设计、编码实现、单元测试和集成测试。从微观上讲，软件实现是通过编码、调试、单元测试、集成测试等活动创建软件产品的过程。软件的实现与软件的设计、软件的测试密不可分。
构件：就是标示的且可以被复制的软件制品。
构件的三个特点：可明确被标识、可复用和是软件制品。
程序设计风格的内容包括：规范化的程序内部文档、数据结构的详细说明、清晰的语句层次结构、遵守统一的编程规范。
编程规范的内容包括：命名规范、界面规范、提示及帮助信息规范、热键定义规范等。
软件实现的原则： 1、尽可能的简单 2、易于验证 3、适应变化 4、遵守一个编程规范 5、选择项目组成员最熟悉的工具或语言。
代码重构：代码重构是软件进化的重要手段，定义为“对软件内部结构的修改，使之更容易理解和修改，但不改变软件的对外可见的行为”。需要重构的地方 例如： 重复代码、函数过长、循环过长或嵌套过深、类的内聚性差、方法传递过多的参数、平行类修改、平行修改CASE语句、方法过多使用其他类的成员、公共的数据成员。
界面设计遵从的原则：界面简洁朴素、控件摆放整齐、颜色风格统一、照顾客户的习惯。
项目如果无法按时完成，可以采取以下方式处理：增加开发人员、减少项目的内容和重新认识2 8定律。
提示信息的分类（注意区分）：1、引导性提示信息 2、错误性提示信息 3、状态行提示信息 4、位置性提示信息。
第9章 软件测试
软件测试定义：软件测试是为了发现错误而执行程序的过程。
软件缺陷：符合下面五个规则之一的就是软件缺陷1.软件未达到产品说明书标明的功能。2.软件出现了产品说明书指明不会出现的错误。3.软件未达到产品说明书未指明但应达到的目标。4.软件功能超出产品说明书指明的范围。5.软件测试人员认为软件难于理解，不易使用，速度缓慢，或者最终客户认为不好。
|
详细设计
|
|
概要设计
|
|
需求分析
|
|
集成测试
|
|
系统测试
|
|
验收测试
|
|
编码
|
|
单元测试
|
|
测试需求分析
|
|
系统测试设计
|
|
集成测试设计
|
|
编码测试用例
|
|
单元测试
|
|
集成测试
|
|
系统测试
|
|
验收测试
|
软件测试V模型 改进的软件测试V模型
黑盒测试：又叫功能测试。盒子指的是被测试的软件，“黑盒”就是只知道被测软件的外部情况，主要是界面和接口，被测软件的内部逻辑结构和数据结构，对测试人员是不可见的。黑盒测试的方法有：等价分类法、边界值分析法和错误推测法。
白盒测试：对程序执行路径的测试。白盒测试的方法有：逻辑覆盖测试、循环测试和基本路径测试。
回归测试：在软件发生修改之后，重新执行原有已执行过的测试用例，以保证修改的正确性，为此目的展开的测试工作成为回归测试。
Alpha测试：Alpha测试时开发人员或者测试人员在场，客户在开发环境下使用软件，也称为受控测试。
Beta测试：就是将软件的Beta版本交给大量典型客户，由他们从客户的角度出发在实际环境中使用软件。
以下注意区分：
通过测试：简单说就是验证软件至少能做什么，而不会考验其能力有多强。
失败测试：纯粹是为了验证软件在某一条件下，是否会出现异常、停止工作等现象而进行的测试。
负载/压力测试：一方面，可以通过减少软件需要的资源（内存、磁盘空间、网络资源等），来测试出软件运行的最低配置或最低资源需求；另一方面，可以正常提供软件需要的资源，但是通过不断加重软件要处理的任务，来测试软件在正常配置下能够具有的能力指标
...