Doc1软工Word格式.docx
《Doc1软工Word格式.docx》由会员分享，可在线阅读，更多相关《Doc1软工Word格式.docx（14页珍藏版）》请在冰豆网上搜索。
软件工程方法学包括3个要素：
方法、工具和过程。
方法：
完成软件开发各项任务的技术;
工具：
运用方法提供的自动的或半自动的软件工程支撑环境；
过程：
为了获得高质量的软件所要完成的一系列任务框架，规定了完成各项任务的工作步骤：
1方法使用的顺序；
2要求交付的文档资料；
3为保证质量和适应变化所需要的管理；
4软件开发各个阶段完成的里程碑。
目前使用得最广泛的软件工程方法学分别是传统方法学和面向对象方法学：
传统方法学又称生命周期方法学或结构化范型。
采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。
把软件生命周期的全过程划分为若干个阶段：
前一阶段是基础、前提；
后一阶段是细化；
每一个阶段的开始和结束都有严格的标准；
在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审；
传统方法学的优点:
通过将软件生命周期划分成若干个阶段降低了整个软件开发过程的困难程度；
每个阶段结束前的严格审查保证了软件的质量，提高了软件的可维护性。
传统方法学存在的问题:
当软件规模庞大，或者对软件的需求是模糊的或会随时间而变化的时候，使用传统方法学开发软件往往不成功，而且维护起来仍然很困难。
原因：
把原本密切相关的数据和操作人为地分离成了两个独立的部分，增加了软件开发与维护的难度。
面向对象方法学是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
面向对象方法学的4个要点：
1把对象作为融合了数据及在数据上的操作行为的统一的软件构件；
2把所有对象都划分成类；
3按照父类与子类的关系，把若干个相关类组成一个类层次结构，位于下层的类继承了上层中某类的特点；
4对象彼此间仅能通过发送消息互相联系。
“面向对象=对象+类+继承+通信”
面向对象方法学的出发点和基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，从而使描述问题的问题空间与实现解法的求解空间在结构上尽可能一致。
面向对象方法学开发软件的过程更为符合人类认识和解决新问题的过程：
循序渐进、归纳+演绎。
面向对象方法学的优点:
降低了软件产品的复杂性；
提高了软件的可理解性；
简化了软件的开发和维护工作；
促进了软件重用。
软件生命周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进一步划分成若干个阶段。
软件定义时期：
1问题定义阶段：
界定问题的范围，确切地定义问题；
2可行性研究阶段：
研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法；
3需求分析阶段：
确定目标系统必须具备哪些功能；
4另外，要估计完成该项工程所需要的资源和成本，制定工程进度表。
开发时期：
0具体设计和实现在前一个时期定义的软件。
1总体设计阶段：
设计出实现目标系统的几种可能的方案，权衡利弊推荐一最佳方案，并制定实现最佳方案的详细计划，以及设计软件的体系结构；
2详细设计阶段：
设计出程序的详细规格说明；
3编码和单元测试阶段：
写出正确的、容易理解、容易维护的程序模块；
4综合测试阶段：
通过各种类型的测试使软件达到预定的要求。
维护阶段：
0关键任务是：
通过各种必要的维护活动使软件系统持久地满足用户的需要。
通常的4种维护活动：
1改正性维护：
诊断和改正使用过程中发现的软件错误；
2适应性维护：
修改软件以适应环境的变化；
3完善性维护：
根据用户需要改进或扩充软件使之更完善；
4预防性维护：
修改软件从而为将来的维护活动做好准备。
软件过程：
为建造高质量软件所需完成的任务的框架，它规定了完成各项任务的工作步骤。
软件过程与软件生命周期的关系：
1软件过程是在软件生命周期中所实施的一系列活动的集合；
2软件生命周期与选择的软件过程有关，不同的软件过程可能对应不同的软件生命周期。
瀑布模型:
瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型;
瀑布模型的本质是“一次通过”
0图形：
（解释：
实际的瀑布模型是带反馈的，实线代表开发过程，虚线表示维护过程，当在后面阶段的发现前面阶段的错误时，需要）
1特点：
1）阶段间具有顺序性和依赖性
（2）推迟实现的观点,（清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是瀑布模型开发软件的一条重要的指导思想）3）质量保证的观点（软件工程的基本目标是优质、高产;
两个重要做法第一，每个阶段都必须完成规定的文档第二，每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误）；
优点：
1强迫开发人员采用规范的方法；
2严格规定了每个阶段必须提交的文档；
3阶段产品必须经过质量保证小组的验证。
缺点：
1客户必须能够完整、正确和清晰地表达他们的需求；
开发人员一开始就必须理解需求。
2缺乏灵活性。
一旦软件需求存在偏差，就会导致开发出的软件产品不能满足用户的实际要求。
3在一个项目的早期阶段，过分地强调了基线和里程碑处的文档,可能要花费更多的时间，用于建立一些用处不大的文档。
4直到项目结束之前，都不能演示系统的能力，增加了项目的风险。
“由文档驱动”的这个事实也是瀑布模型的一个主要缺点,这可能导致最终开发出的软件产品不能真正满足用户的需要
快速原型（不带反馈环）是快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集;
原型在开发中的作用：
（1）获得用户的真正需求；
（2）可用于为一个项目或项目中某些部分，确定技术、成本和进度等。
快速原型模型中各主要部分
（1）原型快速分析:
指在分析者和用户的紧密配合下,快速确定软件系统的基本要求。
（2）原型构造:
在原型分析的基础上,根据基本需求规格说明,忽略细节,只考虑主要特性，快速构造一个可运行的系统。
3）原型运行与评价：
软件开发人员与用户频繁通信、发现问题、消除误解的重要阶段，目的是发现新需求并修改原有需求。
4）原型修正：
对原型系统，要根据修改意见进行修正。
（5）判定原型完成：
如果原型经过修正或改进，获得了参与者的一致认可，那么原型开发的迭代过程可以结束;
原型模型的优势：
1快速原型模型是不带反馈环的，软件产品的开发基本上是线性顺序进行的。
原因如下1）原型系统已经通过与用户交互而得到验证2）开发人员通过建立原型系统已经学到了许多东西3）利用原型能统一客户和开发人员对软件项目需求的理解，有助于需求的定义和确认；
4）可以考虑结合瀑布模型，二者互补性强。
用快速原型做为需求分析的一种技术，用于收集客户的真实需求，然后把客户满意了的原型再作为瀑布模型的输入，从而达到优势互补。
使用原型必须要注意的问题：
1由于要求能够快速建立可供运行的模型，原型不可能象最终产品一样面面俱到；
2客户：
不可把原型当作软件的正式运行版本；
3开发人员：
同上。
还必须牢记原型中没有考虑质量因素的部分；
4使用前要与用户达成一致：
原型只是模型而已;
增量模型的优点：
作为瀑布模型的一个变体，具有瀑布模型所有优点1适用于人员配备不充裕、不能在软件项目期限之前实现一个完全版本的软件的情况；
2能有计划地管理技术风险；
3每个增量都发布了一个高质量的可操作的版本，用户能在较短时间内使用上部分功能；
4逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，减少一个全新的软件可能给客户带来的冲击。
允许增量投资;
增量模型缺点：
1.如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；
2.如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；
3.管理发生的成本、进度和配置的复杂性，可能会超出一些组织的能力。
增量模型存在的困难：
1要求每个新的增量构件能够无缝地集成到现有的软件体系结构中，必须不破坏原来已经开发的产品；
2因此软件体系结构必须是开放的，增加了设计阶段的投入；
3本身具有矛盾性，一方面要求开发人员把软件看作一个整体，另一方面要求开发人员把软件看作构件序列，且构件间彼此独立。
需要开发人员协调这一矛盾。
第一个增量往往是核心的产品，实现最基本需求，提供最基本功能；
分解时必须遵守的约束条件是，当把新构件集成到现有软件中去时，所形成的产品必须是可测试的。
迭代开发是在一开始就移交一个完整的系统，然后在每一个新的发布版本中改变每个子系统的功能。
螺旋模型的基本思想是：
是用原型及其他方法来尽量降低风险。
1确定阶段目标，为完成阶段目标选择方案，设定这些方案的约束条件2用建造原型的方法来排除上述方案中潜在的风险
3用瀑布模型开发4评价该阶段工作，计划下阶段工作;
螺旋模型的特点:
1实质上相当于在瀑布模型每个阶段开始前引入风险分析，并由客户对阶段性产品做出评审，这对保证软件产品质量十分有利；
2由于引入风险分析等活动，测试活动的确定性增强了；
3螺旋模型最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视
螺旋模型的缺点：
1主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解；
2只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本；
3对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟;
螺旋模型的优点：
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；
减少了过多测试和测试不足带来的风险；
在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别；
其优势在于它是风险驱动的；
RUP（统一过程）软件开发生命周期（图解释）核心工作流：
1业务建模：
了解目标系统的机构、商业运作2需求：
开发人员、用户对需求达成共识3分析与设计：
建立分析、设计模型4实现：
设计转化成结果5测试：
识别、确认缺陷并消除6部署：
生成目标系统的可运行版本，移交给用户7配置与变更管理：
跟踪维护开发过程中Artifacts的完整性和一致性8项目管理：
提供项目管理框架，为软件开发项目制定计划、人员配备、执行和监控等方面的使用准则，并为风险管理提供框架9环境：
软件开发环境，包括过程管理和工具支持；
工作阶段：
1初始阶段：
建立业务模型，定义最终产品视图，确定项目的范围2精化阶段：
设计并确定系统的体系结构，制定项目计划，确定资源需求3构建阶段：
开发所有构件和程序，集成为用户需要的产品，测试所有功能4移交阶段：
把开发出的产品提交给用户使用；
敏捷过程的价值观1个体和交互胜过过程和工具2可以工作的软件胜过面面俱到的文档3客户合作胜过合同谈判4响应变化胜过遵循计划；
交流、简单、反馈、勇气、谦虚；
根据上述价值观提出的软件过程统称为敏捷过程；
敏捷过程的原则：
1）我们最优先要做的是通过尽早的,持续的交付有价值的软件来使客户满意2）即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势3）经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好4）在整个项目开发期间,业务人员和开发人员必须天天都在一起工作5）围绕被激励起来的个人来构建项目.给他们提供所需要的环境和支持,并且信任他们能够完成工作6）在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈7）工作的软件是首要的进度度量标准8）敏捷过程提倡可持续的开发速度。
责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度9）不断地关注优秀的技能和好的设计会增强敏捷能力10）简单是根本的11）最好的架构、需求和设计出自于自组织的团队12）每隔一段时间，团队就会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整;
第2章可行性研究
可行性研究最根本的任务：
对以后的行动方针提出建议;
可行性研究的目的：
用最小的代价，在尽可能短的时间内确定问题是否能够解决。
2可行性研究的实质就是要进行一次压缩，简化了的系统分析和设计的过程。
4可行性研究应着重考虑如下5个方面1）技术可行性：
使用现有的技术能否实现这个系统。
2）经济可行性：
进行成本∕效益分析。
从经济角度判断系统开发是否“合算”。
3）操作可行性：
系统的操作方式在这个用户组织内是否行得通。
4）法律可行性：
确定系统开发可能导致的任何侵权、妨碍和责任。
5）开发方案的选择性研究：
提出并评价实现系统的各种开发方案，并推荐较优方案。
开发方案的选择性研究，为选取最有效的方案，使用一组权衡准则进行评价：
项目考虑；
商业考虑；
技术分析；
生产评估；
人员问题；
环境界面；
法律考虑。
可行性研究过程:
1复查系统规模和目标2研究目前正在使用的系统3导出新系统的高层逻辑模型4进一步定义问题即重复1-4直到提出的新系统逻辑模型复合系统目标；
5导出和评价供选择的解法6推荐行动方针7草拟开发计划8书写文档提交审查；
可行性研究过程的基本活动⑴问题识别⑵市场调查⑶分析准备⑷环境分析（明确系统的目的和限制条件）⑸物理分析⑹功能分析⑺信息分析⑻动态分析⑼确立系统方案，作出各种估算⑽模型评审
书写文档提交审查，重要的内容应该有：
1项目背景：
问题描述、实现环境、限制条件；
2管理概要和建议：
重要的研究结果、说明、建议、影响；
3系统描述：
系统工作范围的简要说明、系统元素的可行性；
4侯选方案：
侯选系统的配置、最终方案的选择标准；
5经济可行性（成本/效益分析）；
6技术可行性（技术风险评价）；
7法律可行性；
8用户使用可行性：
用户单位的行政管理和工作制度以及员工的素质；
9其他与项目有关的问题：
其他方案介绍、未来可能的变化。
系统流程图：
是描绘物理系统的传统工具。
它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件。
包括程序、文档、数据库和人工过程等。
它表达了数据在系统各部件之间的流动情况。
所使用的符号（图）
系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用。
运行费用包括操作人员数、工作时间、消耗的物资等。
投资回收期：
是使累计的经济效益等于最初投资所需要的时间。
数据流图有四种基本符号：
箭头：
数据流表示数据在系统中的流动；
方框：
数据的源点和终点；
平行双线：
数据存储（写入,修改,读出,检索）；
圆圈：
加工对数据进行变换的单元；
附加符号:
+:
或;
*与;
⊕抑或,有一个两个不能同时有;
画数据流图的原则:
1确定系统的源点和终点；
2确定系统的输入和输出数据流。
保持分解前后输入/输出数据流必须相同（平衡）；
3用“自顶向下”的方法，逐层画出数据流图。
每张数据流图中加工（处理）的个数不能超过9个（7加减2原则）；
4将必要的存储与加工（处理）相匹配；
5在画数据流图时应避免线条交叉，必要时可使用重复的外部项（源点或终点）或数据存储符号；
6画出出错及例外条件处理情况。
数据流图的用途:
1作为交流信息的工具；
2作为分析和设计的工具；
3数据流图可以辅助物理系统的设计；
4数据流图对详细设计也有帮助。
第三章需求分析
需求：
就是系统的特征（Features），或对系统为达到某个目标所能做的事情的一个描述；
需求过程本质：
在问题空间与求解空间中间架设桥梁
所有分析方法都应遵守下述准则：
1理解并描述问题的信息域，建立数据模型;
2定义软件应完成的功能，建立功能模型;
3描述作为外部事件的软件行为，建立行为模型;
4必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节;
需求分析的任务:
需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型
1、确定系统的综合要求:
1功能需要:
划分出系统必须完成的所有功能;
2性能需要:
系统必须满足的定时约束或容量约束:
速度（系统的响应时间）;
信息速率;
主存容量;
磁盘容量;
安全性3可靠性和可用性需求;
4出错处理需求5接口需求6约束7逆向需求8将来可能提出来的需求；
功能需求：
系统与环境间的交互——描述系统必须支持的功能和过程的系统需求；
非功能需求：
客户给出的具体约束、指标——描述操作环境和性能目标的系统需求；
二者的区别：
功能需求描述系统应该做什么，非功能需求则为如何实现这些需求设定约束非功能需求包括：
性能：
实时性、资源利用、硬件配置限制、精确度；
可靠性：
有效性、完整性；
安全/保密性；
运行限制：
使用频度、运行期限、控制方式（如本地或远程）、对操作员的要求；
物理限制：
系统的规模等限制；
用户界面友好性：
易用性；
与用户沟通获取需求的方法：
1、访谈；
2、面向数据流自顶向下求精（如结构化分析）；
3、简易的应用规格说明技术；
4、快速建立软件原型（3种方法和工具：
技术：
数据查询和报表语言、程序和应用系统生成器、高级的非过程语言；
可重用的软件构件；
形式化规格说明和原型环境；
）。
模型与工具：
数据模型—实体-关系图；
功能模型—数据流图；
行为模型—状态转换图；
状态图可以表示系统循环运行过程，也可以表示系统单程生命期；
事件是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象；
验证软件需求的正确性方面：
1）一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
（2）完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
（3）现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。
（4）有效性必须证明需求是正确有效的，确实能解决用户面对的问题。
需求过程是用来导出、确认和维护系统需求文档的一组结构化活动包括：
需求提取，需求分析和协商，需求确认
系统模型（结构化分析方法）：
必须理解并描述问题的信息域，建立数据模型；
必须定义软件应完成的功能，建立功能模型；
必须描述作为外部事件结果的软件行为，建立行为模型；
必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节；
第五章：
总体设计
结构设计是总体设计阶段的任务，而过程设计是详细设计阶段的任务;
软件设计过程：
（信息描述，功能描述，行为描述，其他）->
设计（数据设计,总体结构设计,过程设计）->
编码（程序模块）->
测试（集成并确认的软件）;
概要设计：
将软件需求转化为数据结构和软件的系统结构，即系统的模块划分。
详细设计：
通过对系统的结构表示（每个模块的内部工作）进行细化，得到软件的详细的数据结构和算法;
总体设计过程一般分为两个阶段1系统设计阶段：
确定系统的具体实现方案2结构设计阶段：
确定软件的结构;
总体设计的步骤:
1设想供选择的方案2选取合理方案3推荐最佳方案4功能分解5设计软件结构6设计数据库7制定测试计划8书写文档9复审
模块：
是由边界元素限定的相邻程序元素（例如，数据说明，可执行的语句）的序列，而且有一个总体标识符代表它
1模块化：
就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。
2抽象：
人们在实践中认识到，在现实世界中一定事物、状态或过程之间总存在着某些相似的方面（共性）。
把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象
层次:
处理复杂系统的唯一有效的方法是用层次的方式构造和分析它;
3逐步求精：
为了能集中精力解决主要问题而尽量推迟对问题细节的考虑;
4信息隐蔽和局部化@信息隐蔽原理指出：
应该这样设计和确定模块，使得一个模块内包含的信息（过程或数据）对于不需要这些信息的模块来说，是不能访问的。
&
局部化:
是把一些关系密切的软件元素物理地放得彼此靠近。
显然,局部化有助于实现信息隐藏;
5模块独立性:
模块独立性的概念是模块化、抽象化、信息隐蔽概念的一个直接产物。
强调模块的独立性，有两个重要原因:
1模块化程度较高的软件容易编制2独立的模块比较容易维护和测试;
模块的独立程度可以由两个定性标准度量，即耦合和内聚:
耦合:
是对一个软件结构内不同模块之间互连程度的度量。
由低到高有六种耦合。
（1）两个模块之间完全独立，无任何连接;
（2）数据耦合;
（3）控制耦合（可以通过模块分解用数据耦合代替）4）特征耦合（调用的模块只需要使用其中一部分数据元素）（5）公共环境耦合（如果只有两个模块有公共环境，那么这种耦合有下面两种可能：
一个模块往公共环境送数据，另一个模块从公共环境取数据。
这是数据耦合的一种形式，是比较松散的耦合。
两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。
）6）内容耦合（一个模块访问另一个模块的内部数据；
1一个模块不通过正常入口转入另一个模块的内部；
2两个模块有一部分程序代码重叠；
3一个模块有多个入口）;
尽量使用数据耦合；
少用控制耦合和特征耦合；
限制公共环境耦合的范围；
完全不用内容耦合。
内聚:
标志着一个模块内各个元素彼此结合的紧密程度;
内聚有七种，由弱到强分别为：
（1）偶然内聚
（2）逻辑内聚（块内任务间在逻辑上相似或相同;
几种相关的功能组合在一起，通常是单接口多功能模块）3）时间内聚（如果一个模块包含的任务必须在同一段时间内执行，就叫时间内聚。
）（4）过程内聚（如果一个模块内的处理元素是相关的而且必须以特定次序执行，则称为过程内聚）;
（5）通信内聚（如果模块中所有元素都使用同一个输入数据和（或）产生同一个输出数据，则称为通信内聚）（6）顺序内聚（如果
升级会员 