软件工程资料整理06.docx
《软件工程资料整理06.docx》由会员分享，可在线阅读，更多相关《软件工程资料整理06.docx（27页珍藏版）》请在冰点文库上搜索。
软件工程资料整理06
本文档只是一个模板，个人可根据自己需要删减、排版。
希望都能理解软件工程的一些知识。
软件工程资料整理
第一章软件工程概述
本部分为重点
本部分主要告诉软件工程是什么东西？
一定要抓住软件工程三要素、研究内容去理解所有章节
1.软件工程的由来:
软件危机（焦油坑）
软件危机：
①如何开发软件，以满足不断增长，日趋复杂的需求；②如何维护数量不断膨胀的软件产品。
软件危机的表现：
对软件开发成本和进度的估算很不准确，甚至严重拖期和超出预算
无法满足用户需求，导致用户很不满意
质量很不可靠，经常失效
难以更改、调试和增强
没有适当的文档
软件成本比重上升
软件开发生产率跟不上计算机应用迅速深入的趋势
2.软件的定义：
程序+数据+文档
3.软件的特征：
复杂性不可见性易变形（需求）一致性（接口协同一致）
4.现在的软件：
面向对象的软件=对象（Object）+消息（Message）
面向构件的软件=构件（Component）+框架（Framework）
面向服务的软件=服务（Service）+消息（Message）+总线（Bus）
5.遗留系统：
很难进行演变适应新需求或新环境且还在使用的软件系统
6.软件的生命周期：
问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃的过程
7.软件工程的概念
软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
8.软件工程的基本原理
严格按照软件生命周期计划进行管理
坚持进行阶段评审
实行严格的产品控制
采用先进的程序设计技术
结果应能清楚的审查
开发小组成员应少而精
承认不断改进软件工程实践的必要性
9.软件工程的目的
为高质量的软件开发提供一个科学的体系框架。
10.软件工程主要研究内容：
软件开发技术、软件（项目、质量）管理技术
11.软件工程的框架
1软件工程目标：
生产具有正确性、可用性以及开销适宜的软件产品（高质量按时交付控制成本满足用户需求）
2软件工程过程：
需求、设计、实现、确认（运行）、支持（维护）
3软件工程原则：
（1）采取适宜的开发模型
（2）采用合适的设计方法
（3）提供高质量的工程支持（4）重视开发过程的管理
12.软件工程的三大要素
方法：
为软件开发提供了“如何做”的技术【软件生命周期全过程中使用的一整套管理和开发技术方法的集合】（面向对象方法）
工具：
为软件工程方法提供了自动的或半自动的软件支撑环境（如：
项目管理工具
需求管理工具、设计建模工具、编程与调试工具、测试与维护工具----case）
过程：
为了获得高质量的软件所需要完成的一系列任务框架，它规定了完成各项任务的工作步骤
13.软件工程的本质
用严格的规范和管理手段来缩小误差，通过牺牲“时间”来提高“质量”（不同抽象层次之间的映射与转换）
14.软件工程两大映射
概念映射【问题空间的概念与解空间的模型化概念之间的映射】与业务逻辑映射【问题空间的处理逻辑与解空间的处理逻辑之间的映射】（实现这两映射要解决的问题：
哪些抽象层次、每个抽象层次的表示、相邻抽象层次的沟通）
15.软件工程所关注的对象
产品：
各个抽象层次的产出物
过程：
在各个抽象层次之间进行映射和转换
特点：
软件工程具有产品与过程二相性的特点
16.软件工程关注的目标
功能性需求：
系统能够完成所期望工作的能力（完备性、健壮性、正确性、可靠性）
非功能性需求：
系统能够完成所期望工作的性能和质量（性能、易用性、清晰性、安全性、可扩展性、兼容性、移植性、经济性、商业质量）
17.软件开发中的多角色
视角不同，需求有差别
18.软件工程基本开发原则
模块化
抽象和信息隐蔽
模块的高内聚和低耦合
确定性
一致性
完备性
19.软件工程的核心概念
复用、分治、折中、演化（可维护性、可修改性、可扩展性）、概念和形式模型、抽象层次
一致性和完备性、效率
第二章
注重讲解软件工程三要素中的过程对应的模型，以及敏捷开发的技术、软件管理技术
第一部分：
软件过程模型
本部分为重点
1.软件过程组织和管理软件生命周期的方式
定义软件生产过程中的活动
定义这些活动的顺序及其关系
2.软件过程目的
可预见性、提高开发效率、获得高质量产品
提升制定时间和预算的能力
3.典型的软件过程模型
瀑布模型【基本模型】
特点：
顺序进行、难以回溯
优点：
追求效率
缺点：
太过理想化
适用场合：
（1）软件项目小
（2）需求在开始之前已经被完全了解，产品定义明确
（3）需求在开发中不会遇到重大改变
（4）使用技术相当成熟，团队成员都很熟悉这些技术
增量过程模型
（1）增量模型【串行的瀑布模型】
特点：
采用随着日程时间进展而交错的线性序列。
每个线性序列产生软件一个可发布的增量（以叠加方式顺序开发模块）
本质：
以迭代方式运用瀑布模型（每个增量为串行的瀑布）
优点：
各个阶段交付满足客户需求的一个子集的可运行产品
人员分配灵活
使用户有充裕时间来学习和适应产品
项目总体性失败的风险降低
困难：
必须不破坏原来已构造好的东西
该类软件的体系结构应该开放
无法处理需求变更
协调好各增量之间的关系
（2）RAD模型【并行的瀑布模型】
特点：
侧重于短开发周期（基于构建的构建方法，复用思想）
多个团队并行进行开发
技术不应很高
困难：
需要大量的人力资源
短时间内为急速完成整个系统做好准备
系统要被合理的模块化
演化过程模型
特点：
专门应对不断的演变
本质：
循环、反复、不断调整当前系统以适应需求变化
目的：
需求的变更频繁，要求在非常短的期限内实现，以充分满足客户/用户要求、及时投入市场
适用场合：
开发过程中，需求经常发生变化
严格的交付时间使得开发团队不可能圆满完成软件产品，但必须交付功能有限的版本以应对竞争或压力
很好的理解和核心产品与系统需求，但对其他扩展的细节问题却没有定义
（1）快速原型法【迭代----基本模型】
抛弃式原型：
只为收集和验证需求，不会作为交给用户最终系统的一部分（不可执行）演化式原型：
最初构造的原型将具备较高的质量，包含了系统的核心功能，然后通过
收集需求对其进行不断的改善和精化，会成为子系统的一部分（可执行）
优点：
提高用户与客户参与程度，最大限度响应需求变化
缺点：
没有过多考虑整体软件的质量和长期的可维护性，系统结构性差
原型和最终系统会混淆
额外的开发费用
（2）螺旋过程模型（原型+瀑布）【分为：
制定计划、风险分析、实施工程、客户评估】
适用场合：
大规模的开发项目
特点：
风险驱动型的过程模型
优点：
开发过程中及时识别和分析风险，并采取适当措施减少或消除风险带来的危害
缺点：
对开发人员要求高
形式化过程模型
特点：
严格运用数学化分析方法
面向复用的软件过程
敏捷开发过程模型【增量+迭代】
第二部分：
敏捷开发
本部分为重点
1.敏捷开发的概念：
以人为核心、迭代、循序渐进的开发方法（理念+优秀实践+具体应用）
2.敏捷开发的目标：
打造保证质量前提下的交付效率的核心能力
3.敏捷开发的原则：
小步快跑，及时反馈
4.敏捷开发本质：
以快速的增量和迭代方式进行开发
5.敏捷开发核心：
迭代（每个迭代周期【2-4周】生成稳定和被验证过的软件版本）、快速增量、快速反馈（配合每个迭代周期适应变化）、快速交付（小批量）
6.敏捷开发方法
极限编程（XP）
计划阶段：
形成用户故事，按照价值或风险为每个用户故事指定优先级
评估用户故事，制定成本（超过三周则拆分）
将一些用户故事制定为下一次发布的增量
规划整体进度
设计阶段：
遵循KIS（简单）原则
用面向对象方法设计模型（CRC卡片【正面：
类名+属性+操作+想获取的信息背面：
类的详细描述等】）
遇到问题，构建原型
对设计方法不断重构
编码与测试阶段：
（1）编码：
根据用户故事设计单元测试用例
结对编程（两人一起编程、强调实时讨论、评审）
测试驱动的开发：
先写用例再写代码
（2）测试：
自动化单元测试、持续集成、持续进行回归测试、验收测试
对于结对编程的特别说明：
伙伴关系（强调平等、互补）
scrum（按用户需求增量、迭代开发过程）
发布计划会议：
找出完成产品需要做的事情（productbacklog【产品清单】）
Sprint计划会议：
决定当前的冲刺需要解决的事情（sprintbacklog【冲刺清单】一个sprint为2-4周迭代）
冲刺sprint
每日站会（短期会议形式）：
昨天做了什么、今天要做什么、碰到的问题【燃尽图、任务墙】
Sprint评审会
Sprint回顾会议
7.敏捷开发常见误区
敏捷开发意味着可以不需要文档、设计和计划
敏捷只是一些优秀实践。
或者优秀实践的结合
敏捷只适用项目开发
敏捷只会对研究产生改变
管理者不需要亲自了解敏捷，只需要管理上支持就可以了
引入敏捷只需要按照既定步骤去做就可以了
敏捷是CMM（能力成熟度模型【过程】）的替代品，是另一种流程
敏捷只注重特性的快速交付，架构就不重要了
第三部分:
软件项目管理
本部分大部分内容不重要
1.软件项目的特征：
（1）软件产品的不可见性
（2）项目的高度不确定性
（3）软件过程的多变化性（4）软件人员的高技能及其高流动性
2.软件项目管理的“4P”：
人员、过程、项目、产品
人【高级管理者、项目技术管理者、开发人员、客户、最终用户】
组织方式：
一蜂窝模式、主治医师模式、明星模式、社区模式、开源社区、交响乐团模式、爵士乐模式、功能团队模式、官僚模式
总之，人是不同的。
要根据项目需求、个人能力（如：
协调与沟通能力）来组建团队，并采用适宜的组织方式。
产品【需求分析、软件设计、软件实现、软件测试、软件运行】开发管理文档
确定软件范围
分解【分治】
工具：
产品结构分解【PBS】
过程
选择合适的软件过程模型
根据所选的过程模型，对其进行适应性修改
确定过程中应包含的工作任务列表
工具:
工作结构分解【WBS】
项目【关注的四方面：
范围、时间、成本、质量】
项目管理的主要任务：
（1）项目可行性分析与估算
（2）项目进度安排（3）项目风险管理
（4）项目质量管理（5）项目跟踪与控制
原则：
W5HH（why【为什么开发系统】what【将要做什么】when【什么时候做】who【某功能由谁做】where【他们的机构组织位于何处】how【如何完成技术与管理工作】howmuch【各种资源分别需要多少】）
A．可行性分析（技术可行性、经济可行性、时间可行性、资源可行性）与估算（技术活【代码行技术、功能点技术、过程估算技术】）
需要多少工作量、时间、人员
确定范围：
并不是所有需求都接受、用户签字确认【注意】
B．项目进度计划与监控
任务进度安排图：
【甘特图（GanttChart）：
资源分配给任务明确产出结果明确里程碑任务】
项目进度跟踪图：
【甘特图（GanttChart）】
项目管理工具：
VersionOne【敏捷开发】
C．项目质量管理
“质量不是检验出来的，而是设计/开发出来的”
“评审、评审、再评审”
“产品/过程二相性”
“越往后，后果越严重”
“缺陷放大”
“犯错误的是人，但错误是在产品中存在的”
“不要被表面现象所迷惑”
D．风险预测与分析
列出可能的风险
估计风险发生的可能性或概率
建立风险表
估计风险可能产生的影响或后果
风险求精
风险环节、监测和管理
风险应急计划
第四部分：
软件配置管理与工具Git
1.软件演化
原因：
需求商业环境软件缺陷软硬件环境升级软件性能可靠性改进
演化定律（lehman）:
持续变化复杂度逐渐加大
处理策略：
软件维护软件再工程
第三章SaaS与云端部署
本部分主要讲解一些架构（重点）
第一部分：
主要（基本/原始）架构
1.软件架构（体系结构、构架）的概念【构件（描述计算）+连接器（描述构件的连接部分）+配置（将构件和连接器组成一个有机整体：
程序流）】
概念1:
一个程序/系统各构件的结构、它们之间的相互关系以及进行设计的原则和随时间进行的指导方针【体系结构IEEE】
概念2：
一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯【软件架构】
其实，软件架构是一个抽象的概念，就是针对一个系统的描述（规则），所以才说它是超越程序代码的。
【程序代码往上就是抽象的层面】我们可以看见它着重体现了软件工程的两大映射以抽象方法表示的层面。
也就是说架构可以理解为表示概念映射和业务逻辑映射的模型。
2.软件框架的概念【框架是架构的部分实例化】
概念1：
面向某领域的、可复用的“半成品”软件，它实现了该领域的共性部分，并提供一系列定义良好的可变点以保证灵活性和扩展性。
概念2：
可实例化的、部分完成的软件系统或子系统，它为一组系统或子系统定义了统一的体系结构（architecture），并提供了构造系统的基本构造块（buildingblocks），还为实现具体功能定义了扩展点（extendingpoints）。
其实，框架里面包含代码。
它的核心思想是体系结构级别的复用（面向构件），为了解决程序开发困难和周期长的问题。
至于为什么称为半成品，则是因为它能有可变的部分。
所谓可变就是特定的模块在加入到可变点时要符合它所采用的方法和规则（调整机制）。
也就意味着框架能控制绑定的特定应用模块，绑定（动态绑定）入框架的模块可以没有自己的控制块，只要符合相应的规范就行了。
此外，框架必须是成熟的，而且框架可以有架构。
3.主要的架构
C/S架构（客户机/服务器【应用系统分为的逻辑上的两部分】）
客户机（前端）：
业务逻辑、与服务器通讯的接口
服务器（后端）：
与客户机通讯的接口、业务逻辑
C/S的层次性：
（1）三层：
A.表示层：
客户界面B.功能层：
业务逻辑服务器C.数据层：
数据库服务器
（2）四层：
客户界面Web服务器业务逻辑服务器数据库服务器【置于最后是为了数据的安全】
典型：
QQ
B/S架构（浏览器/服务器）
B/S层次性：
（1）表现层：
浏览器
（2）逻辑层：
Web服务器、应用服务器
（3）数据层：
数据库服务器
特点：
系统维护成本低（客户端为任何业务逻辑【一个浏览器可运行全部模块、零客户端】、良好的灵活性和可扩展性）
廋客户端（很高的稳定性、延展性和执行效率）
服务集中管理，统一服务于服务器端（良好的容错能力、负载平衡能力）
缺点：
采用B/S结构，客户端只能完成浏览、查询、数据输入等简单功能，绝大部分工作由服务器承担，这使得服务器的负担很重
由于客户端使用浏览器，使得网上发布的信息必须是以HTML格式为主，其它格式文件多半是以附件的形式存放。
而HTML格式文件（也就是Web页面）不便于编辑修改，给文件管理带来了许多不便
个性化特点明显降低，无法实现具有个性化的功能要求
操作是以鼠标为最基本的操作方式，无法满足快速操作的要求
页面动态刷新，响应速度明显降低
无法实现分页显示，给数据库访问造成较大的压力
功能弱化，难以实现传统模式下的特殊功能
典型：
网上办公
C/S+B/S混合模式【折中】
C/S与B/S的区别
（1）C/S:
表现层仍部署在客户端
（2）B/S：
客户端除了浏览器之外无任何程序需要部署
遵循“内外有别”原则【企业内部用户采用C/S企业外部用户采用B/S】
遵循“查改有别”原则【改采用C/S查采用B/S】
典型：
阿里旺旺
M/C架构（移动端/云端）【C/S架构的扩展】
特点：
移动，可以做到任何时候、地点使用软件的功能
典型：
各类App
第二部分：
B/S的发展—SaaS
本部分重点
1.SaaS的概念【软件即服务】
通过Internet提供软件的模式，用户不用再购买软件，而改用向提供商租用基于web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商负责软件的可用性（软件维护、可扩展性、灾难恢复等）管理与支持。
例如：
网易VIP邮箱
2.SaaS的理念：
按需消费
3.SaaS的优点：
降低组织中应用先进技术的门槛与风险
4.SaaS2.0标准：
服务运营商能够提供具备灵活定制、即时部署、快速集成的SaaS应用平
台，能够提供基于web的应用定制、开发、部署工具，能够实现无编程的SaaS应用、稳定、部署实现能力
5.SaaS的特征（多组户共享Server和软件实例）【本质属于B/S，对于B/S的扩展】
通过web来管理和使用软件
软件被集中式的部署与管理，统一升级和维护
单实例、多租户
6.SaaS的刚需用户：
公司组织结构跨地域、创业初期的企业
7.SaaS安全性关注的问题：
账户劫持、云数据访问、数据恢复/备份（排行前三的关注点）
8.SaaS发展的四阶段：
定制开发、可配置、高性能的多租户架构、
Scalable【升级】,configurable【配置】,Muti-Tenant-Efficient【高效】
9.SaaS的层次划分：
表示层控制层逻辑层持久化层数据层【分层不是必须的，根据NFR（非功能性）需要（折中）】
表示层：
接收用户输入的数据与指令、展示数据的处理结果
本身并不维护数据，也不包含业务逻辑
控制层：
统一维护一组对象
根据界面层发来的指令，调度这些对象的行为
除了调度之外，本身也可能包含业务逻辑（处理对象集合的逻辑
可直接访问DB
逻辑层：
对象（数据+业务逻辑）【MCV架构】
持久化层：
数据的持久存储
目的：
清晰分工、职责明确【牺牲系统运行时的性能代价】
10.MVC架构（模型+视图+控制器）
目标：
将承担不同职责的软件实体清晰的分离开来，降低耦合【高内聚、低耦合】
特点：
将应用程序的数据模型将应用程序的数据模型/业务逻辑、用户界面分别放在独立的构件中
不适合小型、中等规模的应用程序
更新快
组成：
模型：
管理应用系统的行为和数据，并响应为获取其状态信息（通常来自视图）而发出的请求，还会响应更改状态的指令（通常来自控制器）——对应于传统B/S中的业务逻辑和数据
视图：
管理数据的显示——对应于传统B/S中的用户界面
控制器：
用于解释用户的鼠标和键盘输入，以通知模型和视图进行相应的更改。
——在传统B/S结构中新增的元素
优点：
耦合性低重用性高生命周期成本低部署快可维护性高有利于软件工程化管理
缺点：
增加系统结构和实现的复杂性
视图对模型数据的低效率访问
实现技术：
不同层次实现技术不同
提供MVC架构的框架：
Struts、Spring（java）、Django（python）、Zend（php）、Rails（ruby）
补充：
http是无状态协议（不会为了下一次连接而维护这次连接所传输的信息,为了保证服务器内存）通过浏览器端的cookies保持同一用户的多次请求，通过服务器端的session保持与用户的连接。
第三部分：
SaaS的部署环境（云平台）
了解一些概念
1.软件部署与实施的概念：
将系统设计方案与软件系统转换成实际运行系统的全过程
2.软件部署模型【设计初期完成】的作用
反映了系统中软件和硬件的物理架构，表示系统运行时的处理节点以及节点中对象/子系统的分布与配置
描述系统中各硬件之间的物理通讯关系
描述各软件实体被配置到哪个具体硬件上、这些软件实体之间的物理通讯关系
为系统选择硬件配置和运行平台
将类、包、子系统分配到各个硬件节点上
3.UML部署图（分布式的多台硬件设备描述）
组成：
节点：
一个立方体表示一组可运行的资源
连线：
立方体之间的连接表示节点间的通信关系（如：
异步、同步；http、ODBC等）作用：
High-level：
描述系统中各硬件之间的物理通讯关系
Low-level：
描述各软件实体被配置到哪个具体硬件上、这些软件实体之间的物理通讯关系
4.绘制部署图：
确定节点对节点加上必要的“构造型”确认链接绘制配置图
5.SaaS部署于何处：
本机自己搭建的服务器公共服务器----云
第四部分：
云
了解一些概念
1.云的概念
基于“云计算”技术，实现各种终端设备之间的互联互通。
用户享受的所有资源、所有应用程序全部都由一个存储和运算能力超强的云端后台来提供。
基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。
通过网络以按需、易扩展的方式获得所需服务。
这种服务可以是IT和软件、互联网相关，也可是其他服务。
它意味着计算能力也可作为一种商品通过互联网进行流通。
2.云计算的概念【新的计算方式和共享基础架构的方法】
基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源
分布式计算（DistributedComputing）、并行计算（ParallelComputing）、效用计算（UtilityComputing）、网络存储（NetworkStorageTechnologies）、虚拟化（Virtualization）、负载均衡（LoadBalance）等传统计算机和网络技术发展融合的产物
3.云的目标：
将IT计算能力（存储和计算）作为一种服务通过Internet提供给客户【不需了解这些计算能力的物理来源及其分布】
4.提供的三种典型服务
IaaS（InfrastructureasaService，基础架构即服务）
概念：
物理服务器（裸机，CPU+内存+磁盘）的虚拟化
代表：
GoogleComputeEngine（GCE）
Paas（PlatformasaService，平台即服务）
概念：
在IaaS基础上，有了完整的运行环境和基础服务支持（例如OS、DB、应用服务器、MVC、Message等）
代表：
GoogleAppEngine（GAE）SinaAppEngine（SAE）
SaaS（SoftwareasaService，软件即服务）
5.云的分类：
公共云（PublicCloud）与私有云（PrivateCloud）混合云
第四章软件设计与架构设计
第一部分：
软件设计
本部分只为了解
1.软件设计的概念
为问题域的外部可见行为的规约增添实际的计算机系统实现所需的细节，包括关于人机交互、任务管理和数据管理的细节。
（不断做出决策，在决策中折中）
2.好的软件设计的特征
目标：
设计必须是实现所有包含在分析模型中的明确需求、以及客户期望的所有隐含需求
形态：
对开发、测试和维护人员来说，设计必须是可读的、可理解的、可操作的指南
内容：
设计必须提供软件的全貌，从实现的角度去说明功能、数据、行为等各个方面
3
升级会员 