软件工程知识点Word文档格式.docx
《软件工程知识点Word文档格式.docx》由会员分享，可在线阅读，更多相关《软件工程知识点Word文档格式.docx（106页珍藏版）》请在冰豆网上搜索。
其中，计算机科学、数学用于构造模型与算法，工程科学用于制定规范设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。
软件工程包括三个要素：
方法、工具和过程。
方法：
“如何做”
工具：
CASE
过程：
将方法和工具综合起来以达到合理、及时的进行计算机软件开发的目的。
为了克服软件危机，人们从其他产业的工业化生产得到启示，于是在68年北大西洋公约（NATO）的会议上提出了“软件工程”的概念后。
提出了在软件生产中采用工程化的方法，采用一系列科学的、现代化的方法技术来开发软件。
这种工程化的思想贯穿到软件开发和维护的全过程。
2．软件工程过程（Softwareengineeringprocess）
是指在软件工具的支持下，所进行的一系列软件开发和进化的活动。
通常包括以下四类基本过程：
●软件规格说明：
规定软件的功能及其运行环境。
●软件开发：
产生满足规格说明的软件。
●软件确认：
确认软件能够完成客户提出的要求。
●软件演进：
为满足客户的变更要求，软件必须在使用的过程中演进。
如图2所示
图2.软件工程过程
3．软件工程框架
软件工程框架如图3所示。
目标：
生产具有正确性、可用性以及开销合算的产品。
⏹软件工程的目标可概括为：
在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并满足用户需要的软件产品。
应该特别指出；
“可靠性”这个目标在软件工程中有着重要的意义。
广义上讲，它涉及到产品设计的一系列问题，从而使产品能在相当长的期间内稳定工作。
狭义上讲，可靠性是软件成功运行的概率度量，可靠性分析和可靠性测试可作为衡量软件质量和其他开发过程的最重要的方法之一。
软件工程目标之间的关系见图4：
活动（过程）：
生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。
原则：
1、开发范型2、设计方法
3、支持过程4、管理过程
一、选取适宜的开发模型；
二、采用合适设计方法；
三、提供高质量工程支持；
四、重视开发过程管理。
图3.软件工程框架
图4.软件工程目标之间的关系
第二章软件开发模型
第一节软件开发模型
（1）
（一）基本概念
1．软件生存周期（SoftwareLifeCycle）：
软件生存周期（SoftwareLifeCycle）：
软件生命周期实质上是大型系统开发过程中各项目阶段的一种表示方法，如同任何事物一样，软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。
根据这一思想，把上述基本的过程活动进一步展开，可以得到软件生命期的6个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护。
软件生命期模型是从软件项目需求定义直至软件经使用后废弃为止，跨越整个生命周期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。
一个软件项目从问题提出开始，直到软件产品最终退役（废弃不用）为止。
软件生存周期方法学把整个生存周期划分为多个相对独立的较小阶段，给每个阶段赋予确定而有限的任务，从而降低了整个软件工程的难度，提高了软件开发生产率；
对软件生存周期的每个阶段采用科学的、规范的方法和管理，使软件开发全过程以一种有条不紊的方式进行，保证了软件质量，提高了软件的可维护性和软件开发的成功率。
2．软件开发过程开发标准的要点
①采用生存周期方法学开发软件，必须从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行。
②划分阶段应遵循的基本原则是各阶段的任务彼此之间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发过程的组织和管理。
③每个阶段有相对独立的任务，前一个阶段任务的完成是后一个阶段任务开始的前提和基础，而后一阶段任务的完成是前一阶段提出“解”的进一步具体化和实现细节。
④每一个阶段的开始和结束都有严格标准。
对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。
每一个阶段结束之前，都必须对这个阶段的成果进行严格的技术复审和管理审查。
审查的主要对象是每个阶段都应该提交的、最新版本的、高质量的相关文档资料。
⑤完成每个阶段的任务，应该采用适合该阶段任务特点的规范方法和系统化技术。
3.软件开发过程模型
软件开发过程模型（软件生存周期模型），是把软件生存周期中软件生产活动的有序流程用一个合理的框架——开发模型规范描述。
软件开发模型是软件开发全部过程、活动和任务的结构框架。
软件开发过程模型是一种软件过程的抽象表示法，它从一个特定的角度表现一个开发过程。
软件过程模型主要是根据软件的类型、规模，特别是软件的开发方法、开发环境等多种因素确立模型。
最早出现的软件开发模型是1970年W．Royce提出的瀑布模型，而后随着软件工程学科的发展和软件开发的实践，相继提出了原型模型、演化模型、增量模型、喷泉模型等
（二）软件过程各阶段任务
各种软件过程模型虽然有所不同，一般都由软件定义、软件开发和软件维护三个时期组成，每个时期又可由多个阶段（子阶段）组成。
软件定义时期的活动是弄清软件“做什么”，软件开发时期的活动是集中解决软件“怎样做”，软件维护时期的活动是聚焦于软件的“修改/完善”，它们的主要活动特征可以概括为“What-How-Change”。
1.软件定义时期各阶段任务
软件定义时期是了解用户（或客户）提出的需求、确定项目的总目标、考察和分析项目的可行性、导出实现项目目标应该采用的策略，系统的功能，并估计该项目需要的资源和成本，制定工程进度表等。
软件定义时期可以划分成问题定义、可行性研究、需求分析和开发计划四个阶段，其中，最核心的是需求分析阶段，所以，软件定义时期也可以称为需求分析时期。
（1）问题定义和可行性研究
问题定义主要是弄清“用（客）户需要解决什么问题”，提交关于问题性质、工程规模的系统目标与范围的说明文档。
可行性研究是确定所定义的问题是不是能够实现，值不值得实现。
为此必须从抽象的概念出发，对项目做一次简化的需求分析和粗略的系统概要设计，寻求一种至数种在技术、经济、运行和法律诸方面都可行的解决方案，并给出可行性论证报告。
（2）需求分析和开发计划
需求分析（阶段）的任务是分析用户对软件系统的全部需求，确定目标系统的逻辑模型，即目标系统是“做什么”的，并通过需求规格说明文档准确地表达。
开发计划的任务是在软件项目经过可行性研究和需求分析之后，制定出主要包括成本估计、资源配置、工程进度安排的软件项目开发和管理文档。
2.软件开发时期各阶段任务
软件开发时期的任务是设计和实现已定义的，并经过需求分析的软件系统。
软件开发时期通常划分成软件设计、软件实现和软件测试三个阶段。
软件测试也可以分解到软件实现的各个活动中，可重新划分成编码和单元测试、集成测试、系统测试三个阶段。
甚至，还可以认为软件测试不是一个独立的阶段，因为它应该和所有软件生产活动并行进行。
（1）软件设计阶段任务
软件设计阶段是为目标系统的逻辑模型设计出一种（不惟一的）软件实现模型，确定软件的总体结构、数据结构、算法细节和用户界面，并给出软件设计的详尽的软件设计说明文档。
软件设计阶段分成总体设计和详细设计两个子阶段。
总体设计是从需求规格说明文档导出软件结构图。
详细设计为软件结构图中的各个模块的数据结构、算法和模块接口等进行细节设计，并给出过程性描述。
（2）软件实现阶段任务
软件实现阶段的任务是把软件的设计用一种程序设计语言实现。
实现阶段一般分成编码和系统集成两个步骤（或子阶段）进行。
编码是根据目标系统的性质和实际开发环境，选取一种适当的程序设计语言，把详细设计的模块过程性描述“翻译”成所选定程序语言的源程序。
对于多模块的系统集成是把所有的程序模块，按照它的软件结构组装（集成）成一个完整的软件系统。
（3）软件测试阶段任务
软件测试阶段完成产品交付前的“找错”和“改错”两大任务，其测试过程必须通过测试报告文档反映。
按照测试活动的目标，软件测试可细分为单元（模块）测试、综合（集成）测试、确认测试和系统（验收）测试等多个测试层次。
软件测试是对开发活动的技术复审，也可以分解到软件实现阶段的各个活动环节。
3.软件维护时期（阶段）任务
软件维护时期（阶段）任务是在整个软件运行时期内，当发现错误时加以改正，以确保运行正常；
当环境改变时修改软件，以适应新的环境；
当用户有新要求时及时改进软件，以满足需求等一系列维护活动。
每一项维护活动一般都经过提出（或报告）维护问题、分析维护要求、提出维护方案、审批维护方案、确定维护计划、修改软件设计、修改程序、测试/验收、维护报告等一系列环节（维护活动实质是一次压缩和简化了的软件定义和开发过程）。
（二）典型的软件过程模型
软件工程的前20年，软件过程模型的特征是“线性思维”，即把软件的开发活动分解成一系列线性的描述、开发、有效性验证和软件进化等基本过程活动，并且用单独的过程阶段来表现这些活动。
随着软件规模的不断增长，大型而复杂的软件采用渐增式或迭代式的开发理念，即把软件的描述、开发、有效性验证等主要开发活动交替进行，让开发的软件在迭代过程中逐步完成和完善。
（三）瀑布模型
1．瀑布模型结构
瀑布模型（WaterfallModel）也称线性顺序模型。
瀑布模型把开发过程分成固定的、相对独立的各个阶段，每个阶段都有确定的、有限的任务，而且在各个阶段采用一些规范的开发方法和管理手段，力求保证软件质量和提高软件生产率。
瀑布模型各个阶段的工作顺序展开，恰如“奔流不息、拾级而下”的瀑布，故而得名。
模型结构如图5所示。
图5.瀑布模型
2．瀑布模型的特点
1．阶段的“里程碑”标志
2．阶段间的顺序性和依赖性
3．复审/验证环节
4．瀑布模型的适用于预先确定型系统
该模型适用于需求非常清楚的软件开发环境。
第二章第二节软件开发模型
（2）
二、讲解第一节：
软件开发模型
（2）（130分钟）
（一）原型模型
原型模型可分为：
快速原型模型、抛弃式原型模型、演化式原型模型
1．快速原型模型
快速原型模型（RapidPrototypeModel，简称原型模型）打破了瀑布模型的“线性”特征，是一种系统型化的子集扩展式开发模式。
原型模型方法采原用合理的抽象，快速建立一个旨在展示目标系统主要功能的软件“样品”————原型系统，取代形式的、僵硬的（不易更改的）的规格说明，用户通过实际试用原型系统而提供真实的反馈意见。
速成原型的工作模型是一个循环的模型。
如图6、图7所示。
1.快速分析快速确定软件系统的基本要求，确定原型所要体现的特征（界面，总体结构，功能，性能）
2.构造原型考虑主要特征，快速构造一个可运行的系统。
有三类原型：
用户界面原型，功能原型，性能原型。
3.运行和评价原型
4.修改与改进
图6.快速原型模型
图7。
细化的快速原型模型
2．抛弃式原型模型
模型结构如图8所示。
图8.抛弃式原型模型
抛弃式原型模型建立原型的目的是，评价目标系统的某一个或某一些特性，以便更准确地确定需求，或者更严格地验证设计方案。
使用完之后就把该原型系统抛弃掉，然后再重新构造正式的目标系统。
抛弃式原型模型本质上仍属于瀑布模型，建立原型系统只不过是“需求分析”和“有效性验证”的一种辅助手段，需求分析阶段结束时原型系统的生存周期也就终止。
3．演化式原型模型
模型结构如图9所示。
图9.演化式原型模型
演化式原型模型是一种迭代式的动态开发方法。
①演化式的原型开发，必须从对用户需求把握准确的部分做起，优先处理这部分工作，而对用户需求把握程度较差的部分和模糊的需求靠后安排，可以在用户明确要求之后再处理。
②原型系统的演化过程，可以有效提高系统可靠性、健壮性和可维护性。
③有效地快速进行原型的建立和迭代，提高开发效益。
④原型的开发提高系统与用户的友善性，并能提早进行实际系统的应用培训。
（二）增量模型
模型结构如图10所示。
增量模型（IncrementalModel）把软件描述、设计、实现活动分解成一系列相互有联系的增量构件的迭代开发，是瀑布模型顺序特征和快速原型模型迭代特征相结合的一种软件构件化的模型。
增量式的开发过程，首先根据客户需要提供的服务的优先次序，确定一系列交付增量，每个增量提供系统功能的一个子集。
随着开发过程的进展，每次迭代产生一个可发布的（可执行的）软件增量构件。
增量模型是一种非整体开发的模型。
是一种进化式的开发过程。
根据增量的方式和形式的不同，分为：
基于瀑布模型的渐增模型
基于原型的快速原型模型
该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
图10.增量模型
第二章第三节软件开发模型（3）
（一）螺旋模型
螺旋模型（SpiralModel）是增加了风险分析和规避措施的“原型+瀑布”的迭代式开发模型，由于一系列活动和活动间的回溯过程用螺旋线描述，故而得名。
螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周。
软件开发又前进一个层次，系统又生成一个新版本，而软件开发的时间和成本又有了新的投入。
最后得到一个客户满意的软件版本。
当项目开发过程沿螺旋线按顺时针方向前进时，每一个螺旋周期都包括风险分析（开发的中、后期实际是设计或实现的风格分析）。
模型结构如图11所示。
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期可分为4个工作步骤：
第一，确定目标、方案和限制条件；
第二，评估方案、标识风险和解决风险；
第三，开发确认产品；
第四，计划下一周期工作。
对大型软件,需要多个原型描述系统的生存期，适于螺旋模型开发方法，将瀑布模型与原型化模型结合起来,并加入风险分析讨论。
图11.螺旋模型结构
螺旋模型是由上面四个部分组成的迭代模型。
螺旋模型的每一周期都包括需求定义、风险分析、工程实现和评审四个阶段。
开发过程每迭代一次，螺旋线就增加一周，喷泉模型该模型表明软件开发活动之间没有明显的间隙，用于支持面向对象开发过程。
由于对象概念的引入，使分析、设计、实现之间的表达没有明显间隙。
并且，这一表达自然地支持复用
（二）智能模型
智能模型（intelligentmodel）也称为基于知识的软件开发模型，是知识工程与软件工程相结合的软件开发模型。
如图12所示。
（三）喷泉模型
该模型是由B.H.Sollers和J.M.Edwards于1990年提出的一种新的开发模型。
它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性，喷泉模型使开发过程具有迭代性和无间隙性。
其模型结构如图13所示。
喷泉模型特点如下：
１.开发过程有分析、系统设计、软件设计和实现4个阶段。
２.各阶段相互重叠，它反映了软件过程并行性的特点。
３.以分析为基础，资源消耗成塔型。
４.反映了软件过程迭代性的自然特性，从高层返回低层无资源消耗。
５.强调增量开发，整个过程是一个迭代的逐步提炼的过程。
图12.智能模型结构
图13.喷泉模型结构
第三章需求分析
第一节需求分析
（1）
三、讲解第一节：
需求分析
（1）（80分钟）
（一）软件需求工程的基本概念
1．软件需求
我们要做什么？
——首先，要弄清楚用户希望我们做什么（需求获取），确定下规格说明书来（需求规约）。
2．需求获取的内容分为：
●物理环境：
对系统运行时所处的环境的要求。
●界面：
软件与用户界面的友好性。
●用户或人的因素:
对用户的要求。
●功能：
你的系统什么的干活？
●文档：
文字说明等。
●数据：
对数据的各种要求。
●资源：
软件运行时所需的数据、软件、内存空间等各项资源。
●安全性：
******
●质量保证：
可靠性和如何对付出错等。
从功能上分如图14所示。
图14.软件需求获取内容
（1）功能需求
它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。
它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要申明系统不应该做什么。
（2）领域需求
是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。
（3）非功能需求
图15.非功能需求
3．需求获取应遵循的原则
●划分：
“整体”与“部分”的关系。
A是B的一部分。
●抽象：
“一般”与“特殊”的关系。
A是B的一个特例。
●投影：
多个角度创建“视图”。
A是B的一个视图。
（二）需求分析方法
1．需求工程的活动
需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。
它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。
它也提供现实需求和软件能力之间的桥梁。
如图16所示。
图16.需求工程
需求工程的基本活动包括：
●获取需求；
深入实际，在充分理解用户需求的基础上，获取系统需求。
●需求分析与建模；
进行需求建模、对模型或原型进行分析。
●确认需求；
确保需求说明准确、完整地表达系统的主要特性。
●进化需求。
客户的需要总是不断（连续）增长的，进化需求是必要的。
2．需求获取技术
需求抽取的方法一般有：
●面谈法重要而直接，简单的需求获取技术。
（面谈的对象主要有用户和领域专家：
面谈前的准备要充分；
面谈后注意认真分析总结；
注意掌握面谈的人际交流技能。
）
●问卷调查法是对面谈法的补充。
（是从多个用户中收集需求信息的有效方式，一般问卷设计形式：
多项选择问题；
评分问题；
排序问题）。
●需求专题讨论会最有力的需求获取技术。
有利于培养高效团队。
（由开发方和用户方共同召开,操作步骤：
①开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会；
②会后开发方整理出《需求调研记录》提交给用户方确认；
③如果此主题还有未明确的问题则再次沟通,否则开始下一主题；
④所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《用户需求说明书》，提交给用户方确认签字）。
●观察用户的工作流程适用于用户无法准确表达需求的情况。
●原型化方法
●基于用例的方法
还有知识工程方法等如：
场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。
例1：
有一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。
因此系统应该具备以下功能：
⑴基本数据维护功能
⑵基本业务功能
⑶数据库管理功能
⑷信息查询功能
●功能需求
⑴基本数据维护功能：
提供使用者录入，修改并进行维护基本数据的途径。
基本数据包括读者的信息、图书资料的相关信息，可以对这些信息进行修改，更新。
⑵基本业务功能：
读者借、还书籍的登记管理功能，随时根据读者借、还书籍的情况更新数据库系统，如果书籍已经借出，可以进行预留操作，书籍的编目、入库、更新等操作。
⑶数据库管理功能：
对所有图书信息及读者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。
⑷信息查询功能：
提供对各类信息的查询功能，如对本图书馆的用户借书信息，还书的信息，书籍源信息，预留信息等进行查询，对其他图书馆的书籍、资料源信息的查询功能。
●非功能需求
①系统安全性需求：
为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户进行确认。
对其它图书馆借阅图书和文献资料服务控制访问范围：
如限IP、限用户等。
②对系统可用性的需求：
为了方便使用者，要求对所有交互操作提供在线帮助功能。
③对系统查询速度的需求：
要求系统在20S之内响应查询服务请求。
④对系统可靠性的需求：
要求系统失败发生率小于1%。
●领域需求
例如：
对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：
⑴图书编目要求按照《中国图书馆分类法》进行；
⑵由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。
第一条需求是对遵循我国图书管理的规定，执行对图书的分类管理的标准。
而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。
第三章第二节需求分析
（2）
（一）需求分析与建模
主要对收集到的需求进行提炼、分析和认真审查，确保所有参加人员取得一致共识。
找出错误、遗漏和不足，建立完整的分析模型。
需求分析和建模又包含三个层次的工作。
1、需求分析
2、需求建模（分为企业建模、功能需求建模和非功能需求建模等）
3、需求规格说明—不同的描述方式。
（二）需求分析常用技术
为了降低软件的复杂度，便于对问题的分析和理解，常采用以下技术：
1.分解：
将大问题分解为小问题，通常是自顶而下，不断细化的过程。
2.抽象：
抓住问题的本质特性，从不同抽象层次进行分析，提出解决问题的方案。
3.多视点：
注意从各类开发人员和不同用户的角度考虑问题，才能获得对系统的全面完整的需求。
（三）需求管理
1．需求管理
升级会员 