软件工程实践者的研究方法
软件工程—实践者的研究方法
软件工程复习重点
一、 软件工程概述
软件的概念及特点
定义：软件是程序、数据及开发、使用和维护程序所需要的所有文档 特点：软件是一个逻辑的而不是物理的产品
软件危机的表现形式
软件的开发成本和开发进度的估计常常很不准确
用户对“已完成”软件系统不满意的现象常常发生
软件产品的质量往往靠不住
软件通常没有适当的文档资料
软件常常是不可维护的
其他
软件工程的概念及研究内容
定义：采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够用得到的技术方法结合起来，来指导软件的开发与维护。
软件工程的基本原理
用分阶段的生命周期计划严格管理
坚持进行阶段评审
实行严格的产品控制
采用现代的程序设计技术
结果能够清楚的审查
开发小组的人员应该少而精
承认不断改进软件工程实践必要性
软件生存期模型
常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型、喷泉模型等
主流开发方法
PO、 OO
二、 软件过程
软件过程活动与软件过程模型的概念
软件活动过程描述：
成果：软件过程活动的产品
角色：软件过程中的参与人及职责
前置条件：活动能够开展的前提条件
后置条件：活动成功完成后对软件系统开发带来的影响 软件过程模型概念：软件过程模型是软件开发全部过程、活动和任务的结构框架。它能直观的表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。
典型软件过程模型的策略及适用范围
(1)瀑布模型
(2)增量模型
(3)原型模型 适用领域：事先不能完整定义需求的领域
(4)螺旋模型
(5)瀑布模型
RUP的基本策略和特点
RUP的核心工作流程：
商业建模：对系统的商业环境和范围进行建模，确保所有参与人员对开发系统有共同的认识
需求分析:定义系统功能及其他非功能需求，成果是软件需求说明书
分析与设计：根据系统需求给出实现方案，成果为软件设计说明书
实施：定义代码的组织结构、实现代码、单元测试、系统集成
测试：验证各个子系统的交互集成。测试分别从可靠性、功能性和系统性能来进行。
部署：成功的生成版本并将软件分发给最终用户
配置和变更管理：管理并行开发、分布式开发；自动化创建工程；记录产品修改的原因、时间、人员、审计记录
项目管理：为计划、执行和监控软件开发项目提供有效支持 9) 环境：为组织提供过程管理和工具的支持
特点：
面向对象：从技术角度，RUP的软件系统开发是基于面向对象技术的。RUP使用和支持面向对象，且建立的设计、实现模型均是对象模型。
Use Case驱动：系统开发从建立业务领域的用例模型开始。用例模型表达了系统的需求，后面的各种工作围绕如何实现用例模型展开
以体系结构为中心：系统开发过程中，体系结构用作开发的基石。系统的概念化、构造和管理均围绕系统体系结构进行
迭代式、增量式的开发过程：RUP采用迭代式、增量式的思想，开发过程有一连迭代增量构成
以质量控制和风险管理为目标：质量控制贯穿于软件开发的全过程。在每一次迭代周期，都要进行质量评估；在软件项目立项之初，就尽可能识别项目的开发风险，找出避免、克服或减少风险的对策
与UML配套：UML的概念和表示方法与RUP相结合形成一种高效的软件系统开发方法和技术。
适用性强：RUP可适用于各类型和各种规模的软件开发。RUP采用管理与技术相结合的二维方法，特别适合处理需求变动比较大的高风险项目
敏捷开发的基本策略和特点
策略：
小规模，频繁的版本发布，短迭代周期
测试驱动开发（Test-driven development）
结对编程（Pair programming）
持续集成（Continuous integration）
每日站立会议（Daily stand-up meeting）
共同拥有代码Collative code ownership
系统隐喻（System metaphor）
特点：
敏捷开发方法是“适应性”(Adaptive)而非“预设性”(Predictive)
敏捷开发方法是“面向人”(people oriented)而非“面向过程”(process oriented)。
XP与Scrum的基本策略和特点
三、 需求工程
可行性研究的意义、任务和方法。
任务：可行性研究的只要任务是“了解客户的要求及实现环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步的项目开发计划”
方法：
- 确定软件的目标和规模
- 研究分析现有系统
- 导出新系统的高层逻辑模型
- 重新定义问题
- 导出和评价供选择的方案
- 推荐行动方针
- 草拟开发计划
- 撰写《可行性研究报告》
意义：
需求工程的任务、主要活动和方法。
任务：清楚的理解用户要解决的问题，完整准确的获取用户的需求，并用《软件需求规格说明书》规范的形式准确的表达用户的需求。
主要活动：需求获取，需求描述，需求有效性验证
方法：
活动：
需求的内容和层次。
内容：功能需求，非功能需求
层次：业务需求，用户需求，系统需求
基于UML的需求规约方法（用例图+用例描述）。
需求获取的一般策略。
策略： 1. 用户访谈 2. 用户调查 3. 其他方法
需求验证的内容和方法。
内容：检测需求是否正确、完备和一致，且为后续设计开发和测试提供了足够的基础。通常为软件公司内部审查过程
方法：快速原型，需求评审
需求管理的内容、流程与方法
内容：组织记录软件需求，控制变更，并确保软件开发与软件需求一致的一系列方法与活动。
流程：需求标识，建立基线，变更控制，需求追踪
方法：
四、 软件设计
软件设计的任务和内容。
任务：针对需求分析阶段提出的系统需求，给出具体的软件设计方案，解决如何做的问题
内容：交互设计、视觉设计、业务逻辑层设计，数据存储设计，数据库设计，
基于UML的软件设计规约方法。
软件体系结构（逻辑架构、物理架构、开发架构）的内涵及各种体系结构的特点和应用范围。
界面设计的一般策略。
业务逻辑层设计流程、方法与策略（领域模型、接口、设计模式）。
数据存储的方案与设计策略（OLAP Vs. OLTP；SQL vs）。
五、 软件实现
软件实现的任务及地位
任务：将软件设计的结果翻译成计算机可以“理解”的形成—使用某种语言描述程序
地位：程序的质量主要取决于软件设计的质量，程序语言的特性和编码的途径也对程序的可靠性、可读性、可测试性和可维护性产生深远的影响
- 典型编程语言与开发环境的特点
- 源代码文档化
- 基于测试驱动的开发方法
- 版本管理
六、 软件测试
软件测试的任务、目的及基本原则
任务：
目的：发现程序中的错误
原则：
开发和测试队伍分别建立
测试用例应由输入数据和预期的结果两部分组成
兼顾合理的输入和不合理的输入数据
应检查程序是否做了不该做的事
程序修改后要回归测试
应长期保留测试用例，直至系统废弃
软件测试的基本策略（动态、静态）
静态测试：对需求规格说明书，软件设计说明书，源程序做结构分析，流程图分析，符号执行来找错
动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性
白盒、黑盒测试的策略与测试用例设计
黑盒测试：从用户的观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例，是根据程序外部特征进行测试。
白盒测试：根据程序内部逻辑结构进行测试
- 软件测试的流程与步骤
- 软件测试各阶段的任务
七、 软件维护
软件维护的目的和任务
目的：通过必要的维护工作时的系统持久的满足用户需要
四种典型软件维护的特点
特点：
改正性维护：为识别和纠正软件错误，改正软件性能上的缺陷，排除实施过程中的误使用
适应性维护：为适应外部条件的变化，而修改软件
完善性维护：扩充软件功能，增强软件性能，改进加工效率，提高软件的可维护性
预防性维护：采用先进的软件工程方法对需要维护的软件或软件中的一部分重新进行设计，编码和测试
影响软件可维护性的因素
因素： 1) 可理解性 2) 可使用性 3) 可测试性 4) 可移植性 5) 可修改性 6) 效率 7) 可靠性
软件维护的一般过程
逆向工程，再生工程
八、 软件项目管理
软件项目管理的任务和内容
任务：项目管理是一些列的伴随着项目的进行而进行的，目的是为了确保项目能够达到期望的结果的一系列管理行为
软件项目管理过程
软件配置与配置管理
软件质量保证
成本估计与成本预算
进度计划
项目团队组织
软件工程标准
ISO9000系列与CMM
《软件工程—实践者的研究方法》读书笔记
《软件工程—实践者的研究方法》这本书内容丰富，从软件工程的定义、软件过程、建模、质量管理到管理软件项目和软件工程发展趋势的探讨，作者逐个展开并做了大量的讲解。内容丰富，当然书也是非常厚。借到这本书之后，一开始没看，一再推迟，大概十一月末才鼓起勇气开始翻阅这本厚厚的书。
这本书不像之前翻阅的软件工程书，里面有大量篇幅讲解敏捷开发，还有WebApp和移动App的分析、设计、测试和质量管理等。书中内容不局限于理论知识的阐述，使用大量篇幅在简单实例中进行分析和设计，主要以SafeHome来演示软件项目如何推进。也与Brooks的人月神话不同，Brooks的人月神话以工程项目中出现的重大问题为主线，以技术为核心，分析了软件开发和软件工程存在的一些问题，探寻到底有没有存在消灭“人狼”的“银弹”；而本书，我觉得作者想呈现给大家一套比较完整的软件工程理论体系，同时以项目示例演示如何将各种理论方法应用于项目工程。
本书主要分为五大部分，软件过程、建模、质量管理、管理软件项目和软件工程高级课程。在五部分之前还用了两章来讲述软件的定义和软件工程。
软件是：（1）指令的集合（计算机程序），通过执行这些指令可以满足预期的特性、功能和性能需求；（2）数据结构，使得程序可以合理利用信息；（3）软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序的操作和使用。
IEEE对软件工程下的定义是：（1）将系统化的、规范化的、可量化的方法应用于软件的开发、运行和维护，即将软件工程化方法应用于软件；（2）对（1）中所述方法的研究。作者认为我们需要规范，也需要可适应性和灵活性。
第一部分是软件过程，软件工程的通用过程框架定义了五种框架活动：沟通、策划、建模、构建以及部署，此外，还有一系列普适活动：项目跟踪控制、分线管理、质量保证、配置管理、技术评审以及其他活动。过程模式有惯用过程模式、专用过程模式和统一过程。惯用过程模型有：瀑布模型（变体V模型）、增量过程模型、演化过程模型（原型开发、螺旋模型）、并发模型；专用过程模型有：基于构建的开发、形式化方法模型、面向方面的软件开发。敏捷开发推崇：让客户满意且尽早的增量发布；小而高度自主的项目团队；非正式的方法；最小化软将工程工作产品以及整体精简开发。极限编程是敏捷开发中使用最广泛的一种方法。XP关键活动有策划、设计、编码和测试。
第二部分是建模部分，主要内容有指导实践的原则、理解需求、需求建模和设计。软件工程是以一系列核心原则作为指导的，这些原则有指导过程的原则和指导实践的原则。构建一个软件系统最困难的部分是确定构建什么，它会严重的影响随后所开发的系统，于是出现了需求工程。需求工程的任务是为设计和构建活动建立一个可靠且坚固的基础。软件团队成员需要完成7个不同的需求工程任务：起始、获取、细化、协商、规格说明、确认和管理。需求建模有基于场景的方法、基于类的方法以及行为、模式和Web/移动App。软件设计是一个迭代的过程，通过这个过程，需求被变换为用于构建软件的“蓝图”。本书设计内容有：体系结构设计、构件级设计、用户界面设计、基于模式的设计、web App设计和移动App设计。
第三部分是质量管理。什么是质量？质量是一个复杂多面的概念，设计质量和符合质量两方面都需要软件工程师考虑。质量很重要，但是用户不满意，其他的事就都不重要了。这是Robert Glass给出的一个“直观的公式”：用户满意度=合格的产品+好的质量+按预算和进度安排交付。对于质量管理，相关的技术和方法有：评审技术、软件质量保证、软件测试策略和安全性工程。
第四部分是管理软件项目。管理设计的范围包括人员、产品、过程和项目。在这里就需要考虑过程的度量和项目的度量以及软件项目的估算。软件项目管理还涉及项目进度安排、风险管理和维护与再工程。关于人员管理，人月神话中Brooks用一章来讲团队组成的重要性，使用“外科手术团队”来打比方。在本书中，作者也用了不少篇幅来讲团队的重要性。作者用了两章依次来讲过程度量与项目度量和软件项目估算。软件测量的方法有面向规模的度量、面向功能的度量、调和代码行度量和功能点度量、面向对象的度量、面向用例的度量和WebApp项目的度量。软件项目估算使用经验估算模型来预测工作量，本书中展示了典型的估算模型、COCOMO II模型和软件方程。软件方程是一个动态的多变量模型，它假定在软件开发项目的整个生命周期中有特定的工作量分布。
第五部分是软件工程高级课程。这里，作者介绍了软件过程改进（SPI）和软件工程的一些新趋势。SPI方法是迭代和连续的，它包括5个步骤：1、当前软件过程的评估；2、对业务人员和管理者的教育和培训；3、过程要素、软件工程方法以及工具的选区和合理性判定；4、SPI计划的实现；5、基于计划结果的评价和调整。SPI框架评价一个组织软件过程的“成熟度”，并提供成熟度等级定性的表示。CMMI(Capability Maturity Model Integration成熟度模型集成)以两种不同的方式表示过程元模型：一个连续式模型，一个分级式模型。连续式CMMI元模型定义了6个能力等级，分别是：不完全级、已执行级、已管理级、已定义级、定量管理级和优化级。分级式的CMMI元模型定义了5个成熟度等级，分别是：初始级、已管理级、已定义级、定量管理级和优化级。
参考文献：
[1]罗杰S.普莱斯曼（Roger S.Pressman）,布鲁斯R.马克西姆（Bruce R.Maxim）著; 郑人杰等译. 软件工程：实践者的研究方法[M]. 北京:机械工业出版社.2016.9
第一部分 软件过程（引论 软件和软件工程）
软件定义：
1、能够完成预定功能和性能的可执行的指令（计算机程序）
2、使程序能够适当地操作信息的数据结构
3、描述程序的操作和使用的文档
综合来说：软件是计算机系统中与硬件相互依存的另一部分，包括程序、数据及其说明文档（描述信息）
软件的特征：
1、软件是被开发或设计的，不是被制作
2、软件不会磨损
3、正在向基于构建的组装前进，但大多数仍是定制的
软件的分类：
1、系统软件
2、应用软件
3、工程和科学计算软件
4、嵌入式软件
5、产品线软件
6、web应用
7、人工智能软件
软件面临的新挑战：
1、开放计算。2、网络资源、3、开源软件
软件工程的定义：
1、软件工程是建立和使用一套合理的工程原则，以便经济地获得可靠的可以在实际机器上高效运行的软件。
2、软件工程是将系统的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。
什么是模型：模型是现实的简化。
软件工程包括：
1、过程：定义了一个过程框架，包含若干个框架活动：沟通、策划、建模、构建、部署
2、方法：如何做、基本原则
3、工具：CASE计算机辅助软件工程
以下是第一部分 软件过程
软件过程：也称软件生存周期过程，是活动的集合，而活动是任务的集合，任务把输入加工成输出
活动的执行可以是：线性（顺序）的，迭代（重复）的，演化的，并行的
软件生存周期模型，开发模型，过程模型：三个说法一样意思，规定了软件开发、运作和维护等所需的过程、活动和任务
瀑布模型，经典生命周期：严格线性的
适用情况：所需功能、性能需求能一次性理解和描述，不再变动
优势：
1、结构简单，广为人知
2、配套开发方法和支撑工具
2、配套有成熟的管理模式
缺点：
1、实际项目很少遵守顺序；
2、客户很难清楚描述所有的需求；难以适应需求变化
3、可交付版本在最后才出现，风险高；
4、容易阻塞
5、系统太大时，难以一次做完
增量过程模型：线性和并行
第一个增量往往是核心产品，满足基本的需求；每个增量都提交一个可以运行的产品。
适用情况：（优势）
1、需要迅速提供一个可用版本
2、早期的增量可以仅需少量的人员/资金
3、规避技术风险：例如延后某硬件的使用
风险（劣势）：
1、需求未被很好的理解；需求迅速变化
2、技术变化
3、长期内仅有有限的资源
演化过程模型：首先执行风险最大、核心的任务，后续“演化”完善
掌握核心需求后就可以渐进式开发，其余需求可以在后续迭代中实现。不断完善的过程造就了“演化”的名字。
与增量模型的区别：只需要核心需求，其他逐步完善
背景（使用情况）：
1、需求常变
2、短时间内无完善的产品，有限功能产品迅速抢占市场
3、核心产品和系统需求已知，但细节未定
（快速）原型模型，原型开发泛型：
用快速设计的方式（例如：只有界面），跟客户交流；循环迭代地修正、明确需求，开发者也有大体感受；低成本；第一个系统（原型）是要被抛弃的，为了软件质量
适用情况：需求模糊，用于讨论，试水
问题（缺陷）：
1、客户要求将原型上线，软件质量和后续维护性得不到保证
2、原型舍弃了一些软件质量，例如低效的算法等 可能会遗留系统
螺旋模型：结合了原型的迭代性和瀑布模型的系统性和可控性，风险驱动，
特点：1、循环逐步加深；2、里程碑
缺点：
1、很难说服客户演进方法是可控的；
2、依靠风险评估专家
协同开发模型，协同工程：过程网络，状态转换。更适合不同的工程团队共同开发的系统工程项目
现在总结演化模型的总体缺点：
1、开发周期数目不定，不利于传统的项目管理和估算技术的应用
2、演化的速度难以把握
3、灵活性和可延展性 VS 软件质量 的平衡
专用过程模型
1、基于构件
2、形式化方法
3、面向方面
4、模型驱动
基于构件
1、构件是软件复用的重要手段，由构件规约和实现两部分组成
2、基于构件开发模型本质上是演化模型，有螺旋模型的特点
形式化方法模型（净室软件工程）：严格的数学符号保证正确性
优势：依靠数学分析的方法，避免歧义性、不完整、不一致；高度关注安全性，不容有失的软件（飞行器和医疗）
劣势：非主流
1、耗时、成本高
2、极少数程序员具有相关学习背景，因此需要大量培训
3、对于技术水平不高的客户很难沟通
面向方面的软件开发：
方面，表示构建功能及非功能的横切属性，例如：数据存取/查询和索引（持久性方面）
演化模型适合定义和构建方面，协同开发的并行特点用于“方面”和“构建”的并行开发，要注意二者的异步通信
统一过程模型（Unified Process，RUP）：用力驱动，以架构够核心，迭代并且增量
统一过程模型的四个阶段对应本书的五个活动
九个核心工作流
每一个迭代都是一个小的瀑布模型
个人软件过程（PSP:personal software process）：强调对产品及其质量的个人测量。
五个框架活动：策划、高层设计、高层设计评审、开发、后验。
PSP强调今早发现错误。是严格有序的，效果显著的。
劣势：对能力的挑战，培训时间长，价格高，人员不习惯
团队软件过程（TSP: Team Software Process）：自我组织进行高质量的软件开发
框架活动：项目启动、高层设计、实现、集成、测试、后验。
个人和团队软件都强调了：测量、策划和自我管理