第2章_软件工程与需求工程
第2章-软件需求与软件需求规约
6
（3）应用
针对一个小型简单的系统，运 用合适的需求求发现技术，按 一定要求的规格说明格式，以 限定的自然语言给出该系统的 需求规约。
7
软件需求及系统/产品(需求)规约
不论是自顶向下的软件开发,还是自底 向上的软件开发,正确定义问题,是解决 问题的前提.
1
课 名：
软件工程
2
2
第1章 第2章 第3章 第4章 第5章 第6章 第7章 第8章
绪论 软件需求与软件需求规约 结构化方法 面向对象的方法——UML 面向对象的方法——RUP 软件测试 软件生存周期过程与管理 集成化能力成熟度模型（CMMI）
3
第2章 软件需求与软件需求规约
软件需求以一种技术的形 式，描述一个产品/系统应该 具有的功能、性能和其他性 质。
第一个问题：依据需求工程人员的技能和产品、合同的 实际情况，往往需要“组合”地使用这些技术来开发 初始需求。
第二个问题：在任意特定的环境中，在实施上述任何一 项技术时，还都可以辅以诸如原型构造等其他方法， 例如，在举行小组会时可以使用原型，方便人员之间 的交流。
第三个问题：执行需求发现这项活动的人，其技能水平 对这项活动的成功具有重大的影响。
--硬件限制(Hardware limitations)，例如：处理速度 、信号定序需求、存储容量、通讯速度以及可用性等；
--与其它应用接口(Interfaces to other applications) ，如，当外部系统处于一个特定状态时，禁止新系统某些 操作
--并发操作(Parallel operations)，例如，可能要求从/ 自一些不同的源，并发地产生或接收数据。对此，必须清 晰地给出有关时间的描述。
软件工程中的需求分析与验证
需求识别、需求分 类、需求确认
验证需求是否符合 客户期望
数据流图、状态图、 用例图
需求跟踪管理
追踪需求的变化
需求文档的编写
需求文档的格式规范
包括标题、介绍、需求描述等
需求文档的书写技巧
清晰明了、避免歧义、扼要概括
需求文档的审查与评审
团队内部、客户反馈
需求变更管理
需求变更的原因
需求不清晰 新需求的出现 客户需求变更
● 02
第2章 需求管理过程
需求识别与获取
在软件工程中，需求来源可以包括客户需求、 用户需求、系统需求等。需求获取的方法包括 访谈、问卷调查、头脑风暴等。确定需求优先 级可以帮助团队更好地安排工作。需求变更管
理是确保需求变更过程可控的重要环节。
需求分析与建模
需求分析的步骤
需求验证与确认
需求建模方法
工具A在项目X中的 应用
工具C在项目Z中的 应用
工具B在项目Y中的 应用
工具D在项目W中 的应用
成功检测到需求缺 陷，提高产品质量
发现安全漏洞，提 前修复风险
有效评估系统性能， 确保用户体验
减少人力投入，节 约测试成本
● 05
第五章 需求工程的实践案例
案例一：在线教育平台需求分析
案例背景
分析在线教育市场趋势
案例二：智能家居系统需求管理
案例介绍
介绍智能家居系统的背景和目 标
需求获取过程
需求变更处理
需求跟踪与确认
通过用户访谈和调研获取需求
如何处理需求变更，维护系统 稳定性
如何跟踪需求的实现情况，并 确认需求是否满足用户期望
案例二：智能家居系统需求 管理
智能家居系统的需求管理是一个复杂的过程， 涉及到用户习惯、安全性、互联性等多方面的 考量。通过合理的需求获取、变更处理和跟踪 确认，可以有效提高系统的稳定性和用户满意
软件工程第二章(可行性分析)
（5） 交付的产品清单。
项目开发计划书供软件开发单位使用。
小结：
1、项目的问题定义、可行性分析和项目计划是总体 规划阶段的工作，重点是项目的可行性分析。
2、可行性分析主要从技术可行性、经济可行性和操 作可行性三方面来分析该项目是否值得开发。
3、可行性分析最后形成的成果是可行性分析报告。
项目的筹备、规划与准备是软件项目实施的前
期工作，它由两个重要的工作阶段构成：一是
项目规划及可行性分析；二是项目需求分析。
一、可行性分析的概念
可行性分析就是解决一个项目是否有可行解以及是
否值得去解的问题。该阶段的主要任务就是用最小
的代价在尽可能短的时间内确定问题是否能够得到 解决。
二、可行性分析的目标和内容
等。
(6) 技术可行性(技术风险评价)：技术实力分析、已有的 工作及技术基础和设备条件等等。 (7) 法律可行性分析结果描述。 (8) 可用性评价：汇报用户的工作制度和人员的素质，确 定人机交互功能界面需求。
(9) 其他项目相关的问题：如可能会发生的变更等等。
可行性研究报告由系统分析员撰写，交由项目负责人审查， 再上报给上级主管审阅。 在可行性研究报告中，应当明确项目“可行还是不可行”， 如果认为可行，接下来还要制定项目开发计划书。
识别用户要求 评价系统的可行性 进行经济分析和技术分析 把功能分配给硬件、软件、人、数据库和其它系 统元素 建立成本和进度限制 生成系统规格说明，形成所有后续工程的基础
三、 可行性分析的主要任务
具体地说，分析员应从下面三个方面对项目做出可行性分 析： （1）技术可行性：使用现有的技术能实现这个系统吗? （2）经济可行性：这个系统的经济效益能超过它的开发成本 吗?（详细在后面介绍成本/效益分析） （3）操作可行性：系统的操作方式在该用户组织内行得通吗?
软件设计 Zhou Su 第2章 理解需求
领域活动。
2.1 需求工程
• 在项目起始阶段中，要建立起基本的理解，包括对问题、 谁需要解决方案、所期望解决方案的性质、项目干系人和 开发人员之间达成初步交流合作的效果等。
2.1 需求工程
• （2）导出 • 询问客户、用户和其他人，系统或产品的目标是什么，想 要实现什么，系统和产品如何满足业务的要求，最终系统 或产品如何用于日常工作。这些问题看似简单，但实现却 很困难。
2.3.1 协同收集需求
• 已经有了很多不同的协同需求收集方法，各种方法适用于 稍有不同的场景，而且所有这些都以下面这些原则为基础：
– 会议由软件工程师和其他的利益相关者共同举办和参与。 – 制定筹备和参与会议的规则。 – 拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的重 点；但也不能太正式，以鼓励思想的自由交流。 – 由一个“调解人”（可以是客户、开发人员或其他人）控制会议。 – 采用“方案论证手段”（可以是工作表、活动挂图、不干胶贴纸 或电子公告牌、聊天室或虚拟论坛）。
供指导。
2.1 需求工程
• （6）确认 • 在这一步将对需求工程的工作产品进行质量评估。需求确 认要检查规格说明以保证：已无歧义地说明了所有的系统 需求；已检测出不一致性、疏忽和错误并得到纠正；工作 产品符合为过程、项目和产品建立的标准。
2.1 需求工程
• 正式的技术评审是最主要的需求确认机制。确认需求的评 审小组包括软件工程师、客户、用户和其他利益相关者， 他们检查系统规格说明，查找内容或解释上的错误，以及 可能需要进一步解释澄清的地方、丢失的信息、不一致性 （这是建造大型产品或系统时遇到的主要问题）、冲突的 需求或是不可实现的（不能达到的）需求。
– 如何描述由某成功的解决方案产生的“良好”输出的特征？ – 该解决方案强调解决了什么问题？ – 能向我们展示（或描述）解决方案使用的商业环境吗？ – 存在将影响解决方案中特殊的性能问题或约束吗？
软件工程专业优质课软件需求工程
软件工程专业优质课软件需求工程软件工程专业优质课——软件需求工程软件需求工程是软件工程领域的一门重要课程，它主要关注软件项目中的需求分析、规划与管理。
通过系统地收集、分析和定义用户对软件系统的需求，软件需求工程可以帮助开发团队更好地理解用户需求，并将其转化为可执行的开发计划。
下面将从需求工程的基本概念、流程和关键技术等方面进行论述。
一、需求工程的基本概念软件需求工程是指在软件开发或系统维护过程中，对需求进行收集、分析、定义、验证与管理等一系列活动的过程。
它的目标是构建一个正确、完整、准确、一致和可追踪的需求规格说明，为软件开发提供基础。
需求工程的核心是要确保需求的正确性和完整性。
只有对用户需求进行准确的理解和把握，才能保证软件开发过程中的目标和结果与用户的期望保持一致。
因此，需求工程在整个软件开发过程中具有举足轻重的地位。
二、需求工程的流程需求工程的流程可以分为需求获取、需求分析、需求定义、需求验证和需求管理等五个阶段。
1. 需求获取阶段需求获取阶段主要通过面对面交流、问卷调查、访谈和文献分析等方式，与用户直接沟通以获取需求信息。
在这个阶段中，需求工程师需要充分了解用户的背景、目标和需求，明确项目的范围和目标，以确保需求的准确性和一致性。
2. 需求分析阶段需求分析阶段是对需求进行详细分析和整理的过程。
在这个阶段中，需求工程师会对需求进行分类、排序和整理，以便更好地理解和表达需求。
同时，需求工程师还需要识别需求之间的相互关联和依赖，并找出潜在的冲突和问题。
3. 需求定义阶段需求定义阶段是将需求转化为可执行的设计和规划的过程。
在这个阶段中，需求工程师需要将需求进行详细描述，并明确需求的优先级和可实现性。
同时，还需要与开发团队共同讨论和协商，确立一个合理的开发计划和时间表。
4. 需求验证阶段需求验证阶段是对需求的正确性和完整性进行验证的过程。
在这个阶段中，需求工程师会与用户进行沟通和协商，共同确认和验证需求的准确性和可行性。
软件工程第二章软件过程
第二章：软件过程目标：软件工程和软件过程模型的概念；了解3个一般的软件过程模型及何时使用它们；了解软件需求工程，软件开发，测试和进化中所涉及的基本过程活动；理解为什么软件过程要有效地组织以应对软件需求和设计上的变更；了解Rational统一过程是如何集成好的软件过程实践来产生一个可适应的软件过程。
所有的软件过程都必须具有4种对软件工程来说是基本的活动。
它们是：1.软件描述：必须定义软件的功能以及软件操作上的约束。
2.软件设计和实现：必须生产符合描述的软件。
3.软件有效性验证：软件必须得到有效性验证，即确保软件是客户所想要的。
4.软件进化：软件必须进化以满足不断变化的客户需要。
2.1软件过程模型一软件过程模型一般有1.瀑布模型：该模型将基本的过程活动，描述，开发，有效性验证和进化，看成是一些界限分明的独立的过程阶段，例如，需求描述阶段，软件设计阶段，实现阶段，测试阶段，等等。
2.增量式开发：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统的开发是建立一系列的版本（增量），每个版本添加部分功能到先前的版本中。
3.面向复用的软件工程：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统开发过程着重于集成这些组件到新系统中，而非从头开发。
2.1.1瀑布模型一瀑布模型中的主要阶段直接映射基本的开发活动：1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护二适合采用瀑布模型的时候瀑布模型是与其他工程过程模型相一致的，在它的每个阶段都要生成文档。
这使得过程是可见的，项目经理能够根据项目计划监控项目的过程。
它的主要问题在于它将项目生硬地分解成这些清晰的阶段。
关于需求的责任和义务一定要在过程的早期阶段清晰界定，而这又意味它对用户需求变更的响应较困难。
所以只有在对需求了解的好，而且在系统开发过程中不太可能发生重大改变的时候，适合采用瀑布模型。
瀑布模型的一个重要变形是形式化系统开发。
软件工程第2章-系统工程
软件工程第2章-系统工程软件工程第2章-系统工程2.1 系统工程概述系统工程是一种系统性和综合性的工程方法，旨在设计、开发和维护复杂的软件系统。
系统工程的主要目标是满足用户需求，并确保系统的有效性、可靠性和可维护性。
2.1.1 系统工程定义系统工程是一个跨学科的领域，涉及到多个专业领域的知识和技术。
它集成了工程学、计算机科学、信息技术等多个学科的理论与实践，以解决大规模软件系统开发和维护过程中的各种问题。
2.1.2 系统工程过程系统工程的过程涵盖了软件系统的整个生命周期，包括需求分析、设计、开发、测试、部署和维护等阶段。
每个阶段都有特定的任务和活动，并且需要进行严格的管理和控制。
2.1.2.1 需求分析阶段需求分析阶段是系统工程的起点，通过与用户沟通和交流，收集和整理用户需求，并将其转化为系统的功能和性能要求。
2.1.2.2 设计阶段在设计阶段，系统工程师会根据需求分析阶段的成果，设计整个系统的结构和组件之间的关系。
这包括系统架构设计、模块设计和接口设计等。
2.1.2.3 开发阶段开发阶段是系统工程中最为关键的阶段，主要是根据设计阶段的成果，进行软件编码、集成和测试。
开发人员需要按照设计规范和编码标准进行开发工作，并保证代码的质量和可维护性。
2.1.2.4 测试阶段测试阶段是为了验证系统是否满足用户需求，并发现和修复潜在的缺陷和问题。
测试人员会执行各种测试活动，包括单元测试、集成测试和系统测试等。
2.1.2.5 部署阶段在部署阶段，系统工程师会将已经通过测试的系统部署到目标环境中，并进行安装、配置和调优等工作，确保系统能够正常运行。
2.1.2.6 维护阶段维护阶段是系统工程的最后一个阶段，主要是为了确保系统能够持续地运行和满足用户的需求。
维护人员会定期检查系统的性能和可靠性，并进行必要的修复和优化等工作。
2.2 系统工程的关键技术2.2.1 需求工程需求工程是系统工程中非常重要的一环，它主要涉及到需求获取、需求分析、需求验证和需求管理等方面的内容。
软件工程基础(胡思康)第2章
软件需求工程
S
1
2
软件需求的基本概念 需求工程的过程
3
需求获取技术
4
结构化需求分析和建模
5 案例：简历自动获取和查询系统的需求建模
6
需求评审
➢实际项目经验表明：用户自身对将要开发的系统 也并不是完全理解，对需求目标的陈述带有主观片 面性、模糊性、不一致性，甚至还会出现错误；用 户不会把需求按照功能、性能、行为、约束等特性 对需求分门别类。
➢对传统的需求变更管理过程来说，主要包括软件配置、软 件基线和变更审查。
软件基线由一组软件配置项组成。当软件配置项处于稳 定状态后（如需求文档经过评审以后），就确定了这组软 件配置项的基线。在后续的开发过程中，软件配置项发生 变更，则这一变更须通过变更审查并确定，变更才能记录 在软件配置项中，并通知与之有关的人员。
基线是进行需求变更的界线。在需求分析的基线定义 之前，能够随时进行需求变更，若在基线定义之后变 更，则需要重新进行审查和复审。
功能是否有约束，系统如何使用更能符合用户的操作习 惯。在需求评审中，软件人员需要在用户的配合下，对 需求规格说明进行管理复审，以确保和用户对需求规格 说明的理解达成一致。
数据从哪里来（收集过程），到哪里去（存储过程）， 系统内部如何操作和转换这些数据，如果表示数据，如 何共享数据等问题。 数据分析将数据从物理实体映射 为逻辑实体，分析逻辑数据间的连接、视图模型。
把问题域中的问题转换成信息领域 问题。结构化方法采用数据流图、 数据字典等图形工具定义。面向对 象方法采用例图、类-对像图。
➢对传统的需求变更管理过程来说，主要包括软件配置、软 件基线和变更审查。
软件配置的目的是确保所做的工作是可回朔的，能够恢 复原来工作的文档、代码等内容，也能跟踪目前工作结果 的来龙去脉。需要进行软件配置的内容称为软件配置项， 主要有两类：一是属于产品自身需要的内容，如开发文档、 代码、数据等；二是为软件产品服务的内容，如进度计划、 人员安排、报告等。
软件需求工程
软件需求工程
第1章 软件需求工程概述 IEEE 关于软件需求的定义 1) 用户解决问题或达到目标所需的条件或能力；（用户的角度 ） 2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条 ቤተ መጻሕፍቲ ባይዱ或能力。（软件系统的角度 ） 软件需求的分类 1) 目标需求； 2) 业务需求； 3) 功能需求； 4) 性能需求； 5) 约束与限制。 6) 软件需求间的层次关系
复杂的软件系统的描述方法
?当前系统：已经存在的人工系统 ?目标系统：待开发的计算机系统 SA方法的分析步骤如下： 1)理解和分析当前的现实环境，以获得当前系统的具体模型。具体模型必须忠 实地反映人工系统的实际情况，软件开发人员在获得需求信息的基础上，利用DFD将现实环境中的人工系统表达出来。 2)建立当前系统的逻辑模型。从系统的具体模型中抽象出当前系统的逻辑模 型，当前系统的逻辑模型应反映当前系统必须满足的性质。 3)建立目标系统的逻辑模型。主要是分析目标系统与当前系统在逻辑系统的差 别，并建立目标系统的逻辑模型。 4)进一步完善目标系统的逻辑模型，完善的工作大致为： ①至今尚未说明的处理细节，如出错处理 ②某些需要的输入/输出格式或用户界面的说明 ③增加性能需求和其它一些约束限制等 状态转换图 P60-图5-18、P61-图5-19 第6章需求定义 需求规格说明的作用 需求规格说明的作用主要体现在： 1)需求规格说明是软件设计和实现的基础 2)需求规格说明是测试和用户验收软件系统的重要依据 3)需求规格说明能为软件维护提供重要的信息 一个软件系统能否满足用户需求，主要是用户的需求能否全部反映在需求规格说明中。因此，需求规格说明作为需求工程的最 终成果必须具有综合性，必须包括所有的需求，开发人员与客户不能做任何假设。 除了设计和实现的限制，需求规格说明不应包括假设、构造或维护阶段的细节； 需求规格说明=技术合同，是软件开发方与用户达成的一致性文档，是基准的规格说明。
现代软件工程 第二章 软件需求分析
现代软件工程第二章软件需求分析在现代软件工程中，软件需求分析是软件开发过程中至关重要的一环。
它就像是建筑工程中的蓝图设计，为后续的软件开发工作指明了方向和目标。
如果在需求分析阶段出现偏差或错误，就可能导致整个软件开发项目的失败，浪费大量的时间、人力和资源。
那么，什么是软件需求分析呢？简单来说，软件需求分析就是要弄清楚用户到底需要一个什么样的软件，这个软件要具备哪些功能，能够解决哪些问题，以及用户在使用过程中会有哪些期望和要求。
在进行软件需求分析时，首先要与用户进行充分的沟通和交流。
用户可能是各种各样的人群，他们对于软件的需求和期望也各不相同。
有些用户可能对技术比较了解，能够清晰地表达自己的需求；而有些用户可能对技术一无所知，只能用一些比较模糊的语言来描述自己想要的东西。
这就需要需求分析人员具备良好的沟通技巧和理解能力，能够从用户的只言片语中捕捉到关键信息，并通过进一步的询问和引导，帮助用户明确自己的需求。
与用户沟通的方式也是多种多样的。
可以通过面对面的访谈、电话交流、问卷调查、邮件往来等方式获取用户的需求。
在沟通的过程中，要注意倾听用户的意见和想法，不要急于表达自己的观点和看法，以免影响用户的思路。
同时，要做好记录，将用户的需求和意见详细地记录下来，以便后续进行整理和分析。
获取到用户的需求之后，接下来就要对这些需求进行整理和分析。
这是一个非常复杂和繁琐的过程，需要需求分析人员具备较强的逻辑思维能力和分析能力。
要对用户的需求进行分类、归纳和总结，找出其中的共性和个性，明确哪些需求是核心需求，哪些需求是次要需求，哪些需求是可以暂时忽略的。
同时，还要对用户的需求进行可行性分析，判断这些需求是否能够在技术上实现，是否符合项目的预算和时间要求。
在整理和分析需求的过程中，可能会发现用户的需求存在一些矛盾和冲突的地方。
这就需要需求分析人员与用户进行进一步的沟通和协商，解决这些矛盾和冲突，达成一致的意见。
同时，还要对需求进行优先级排序，确定哪些需求需要优先实现，哪些需求可以放在后续的版本中进行开发。
软件工程(邓良松)第二章
第2章 软件要求定义
应该收集、研究和分析现有系统的文档资料，实地考察现 有系统，在考察的基础上，访问有关人员，然后描绘现在系统 的高层系统流程图(见2.1.3节)， 与有关人员一起审查该系统流 程图是否正确。系统流程图反映了现有系统的基本功能和处理 流程。 (3) 建立新系统的高层逻辑模型。根据对现有系统的分析 研究，逐渐明确新系统的功能、处理流程以及所受的约束，然 后使用建立逻辑模型的工具——数据流图和数据字典(见8.3、8.4 节)来描述数据在系统中的流动和处理情况。注意，现在还不是 软件需求分析阶段，不是完整、详细的描述，只是概括地描述 高层的数据处理和流动。
第2章 软件要求定义
1. 技术可行性 技术可行性 对要开发项目的功能、 性能和限制条件进行分析， 确定在 现有的资源条件下，技术风险有多大，项目是否能实现，这些 即为技术可行性研究的内容。这里的资源包括已有的或可以搞 到的硬件、软件资源，现有技术人员的技术水平和已有的工作 基础。 技术可行性常常是最难解决的方法，因为项目的目标、功 能和性能比较模糊。技术可行性一般要考虑的情况包括： (1) 开发的风险： 在给出的限制范围内， 能否设计出系统 并实现必须的功能和性能? (2) 资源的有效性： 可用于开发的人员是否存在问题? 可用 于建立系统的其他资源是否具备?
第2章 软件要求定义
输入变更记录
库存管理模块
订货信息
报告生成模块 订货报告
库存
图 2.1 库存管理系统的系统流程图
第2章 软件要求定义
2.1.4 成本 效益分析 成本—效益分析
成本—效益分析的目的是从经济角度评价开发一个新的软 件项目是否可行。成本一效益分析首先是估算将要开发的系统 的开发成本，然后与可能取得效益进行比较和权衡。效益分有 形效益和无形效益两种。有形效益可以用货币的时间价值、 投资回收期和纯收入等指标进行度量；无形效益主要从性质上、 心理上进行衡量，很难直接进行量的比较。系统的经济效益等 于因使用新的系统而增加的收入加上使用新的系统可以节省的 运行费用。运行费用包括操作人员人数、工作时间和消耗的物 资等。下面主要介绍有形效益的分析。
软件工程第1-2章课后习题参考答案
第一章课后参考答案1.什么是软件危机？它们有哪些典型表现？为什么会出现软件危机？“软件危机”是指计算机软件的“开发”和“维护”过程中所遇到的一系列“严重问题”。
这些问题决不仅仅是不能正常运行的软件才具有的，实际上，几乎“所有软件”都不同程度地存在这些问题。
“软件危机”包含两方面的问题：（1）如何开发软件，以满足对软件日益增长的需求；（2）如何维护数量不断膨胀的已有软件。
它们有以下表现：（1）对软件开发成本和进度的估计常常很不准确；（2）用户对“已完成的”软件系统不满意的现象经常发生；（3）软件产品的质量往往靠不住；（4）软件常常是不可维护的；（5）软件通常没有适当的文档资料；（6）软件成本在计算机系统总成本中所占的比例逐年上升；（7）软件开发生产率提高的速度，远远跟不上计算机应用普及深入的趋势。
出现软件危机的原因（1）开发人员与客户认识之间的矛盾（2）开发人员能力与开发目标之间的矛盾（3）预估与实际工作量之间的矛盾（4）客户认识的提高与软件维护之间的矛盾（5）遗产系统与实施软件之间的矛盾2.假设自己是一家软件公司的总工程师，当把图1.1给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”是在引入变动，当然付出的代价更高。
一个故障是代码错误造成的，有时这种错误是不可避免的，但要修改的成本是很小的，因为这不是整体构架的错误。
3.什么是软件工程？它有哪些本质特征？怎么用软件工程消除软件危机？软件工程是知道计算机软件开发和维护的一门工程学科。
软件工程-第2章-数据流图
Data flow diagram of the main graphic elements （主要图形元素）
编号 加工 名称
Example of DFD:
DFD of Bank Withdrawals Process
描述银行取款过程的数据流图
Example of DFD:
Each element must have a name DFD can not be attached to control flow In the beginning, the trivial details could be ignored, in order to concentrate on the main data stream
图上每个元素都必须有名字 数据流图中不可夹带控制流 初画时可以忽略琐碎的细节，以集中精力于主要数据流
Naming for each elements of DFD If it is difficult to give a name, it is possible because DFD decomposition problem Data Flow (Database): Using data noun Processing: using verb-object phrase. Data source: using normal noun
Tools of Software Need Analyzing 需求分析工具
Ning Hong-yun 2009.8
Tools of Software Need Analyzing 需求分析工具
Data flow diagram ( DFD, 数据流图)
软件工程讲义_第二章
演化过程模型评述[NOG00]
首先，原型开发（和其他更加复杂的演化过程） 由于构建产品需要的周期数目不确定，给项目策 划带来了困难。 其次，演化软件过程没有确定演进的最快速度。 如果演进的速度太快，完全没有间歇时间，项目 肯定会陷入混乱；反之，如果演进速度太慢，则 会影响生产率…… 再次，软件过程应该侧重于灵活性和可扩展性， 而不是高质量。为了追求高质量而延长开发时间 势必造成产品推迟交付，从而失去进入市场的良 机。
过程模式
过程模式提供了一种有效的机制来描述各 种软件过程。模式使得软件工程组织能够 从高层抽象开始，开发层次化的过程描述。 高层抽象描述又进一步细化为一系列步骤 模式以描述框架活动，然后每一个步骤模 式又进一步逐层细化为更详细的任务模式。 过程模式一旦建立起来，就可以在过程变 体的定义中复用——即软件开发队伍可以 将模式作为过程模式的构建模块，定制特 定的过程模型。
演化过程模型评述
演化模型的初衷是采用迭代或者增量的方式开 发高质量软件。可是，用演化模型也可以做到强 调灵活性、可扩展性和开发速度。软件开发团队 及其经理所面临的挑战就是在这些严格的项目和 产品参数与客户（软件质量的最终仲裁者）满意 度之间找到一个合理的平衡点。
专用过程模型
专用过程模型具有传统过程模型的一些特 点，但是，专用过程模型往往应用面较窄， 只适用于某些特定的软件工程方法。 在某些情况下，这些专用过程也许更确切 地应该称为技术的集合或方法论，是为了 实现某一特定的软件开发目标而制定的。 但它们确实也提出了一种过程。
模式名称：应能清楚地表述该模式在软件过程中的功能。 驱动力：模式使用环境及主要问题， 以明确主要难点 并可能影响解决方案。 类型：定义模式类型。 启动条件：描述模式应用的前提条件。 问题：描述模式将要解决的问题。 解决办法：描述模式的实现。 结束条件：描述模式成功执行之后的结果。 相关模式：以层次或其他图的方式列举与该模式相关的 其他模式。 已知应用实例：介绍该模式的具体实例。
《软件工程》各章节重点
瀑布模型
软件过程的经典模型，每个 阶段按顺序完成。缺点是不 能容忍修改和反馈。
螺旋模型
一种适应型软件过程模型， 强调风险管理。缺点是变化 不稳定。
迭代模型
一种多次迭代的软件过程模 型，每次迭代完成一个小而 完整的软件。缺点是需求的 稳定性。
敏捷开发
一种以人为核心,注重适应变 化,提供高质量服务的软件开 发方法。缺点是文档化的缺 失和不同项目难以比较。
第三章：需求工程
1
需求来源
如何识别和获取需求，包括需求表示法、需求描述、需求协商。
2
需求分析
如何分析理解、抽象和总结需求特性，包括需求抽象、需求验证。
3
需求管理
如何跟踪需求变更、评审需求变更的影响范围
第四章：软件设计
设计任务
系统结构设计、数据结构和 算法设计、接口及数据管理 设计。
设计方法
结构化设计、面向对象设计、 面向方面设计、进化设计。
3 项目管理：Redmine
4 测试工具：JUnit
开源的项目管理和缺陷跟踪工具，支持敏 捷开发，提高团队协作能力。
开源的测试框架，支持自动化构建、单元 测试和回归测试。
结论
软件工程是一门需要持续学习和探索的学科，为软件开发提供了良好的指导 框架和开发流程。在软件开发过程中，我们应该根据实际情况选择合适的软 件开发方法和工具，提高软件开发效率和质量。
《软件工程》各章节重点
软件工程是一门综合性、系统性很强的学科，主要研究如何开发和维护高质 量的软件。《软件工程》一书对软件工程的基础理论、知识和方法进行了全 面详细的阐述。
引言
引言是一份礼物，像向朋友打开您内心的大门。引言是一篇文章或书籍的开端，包含主题和相关内容的 介绍。在软件工程中，引言的重点是软件工程学科的产生背景和发展历程。
第二章 软件工程复习题
第二章软件工程复习题1.可行性研究的目的不是去开发一个软件项目，而是研究这个软件项目是否_____,____。
2．成本—效益分析首先是估算将要开发的系统的______，然后与可能的效益进行_____。
3．软件工程有两种效益，它们是______和_______。
4．成本-效益分析的目的是从______评价开发一个新的软件项目是否可行。
5．_______就是使累计的经济效益等于最初的投资费用所需的时间。
项目的______是指在整个生存周期之内的累计经济效益(折合成现在值)与投资之差。
6.可行性研究的第一个具体步骤是_______。
7.可行性研究实质上进行一次简化、压缩了的_______。
8．研究开发资源的有效性是进行( )可行性研究的一方面。
A.技术B.经济C.社会D.操作9．在软件的可行性研究中，可以从不同的角度对软件进行研究，其中是从软件的功能可行性角度考虑的是( )。
A.经济可行性B.技术可行性C.操作可行性D.法律可行性10．技术可行性要解决( )。
A.存在侵权否B.成本—效益问题C.运行方式可行D.技术风险分析11．研究软硬件资源的有效性是进行( )研究的一方面。
A.技术可行性B.经济可行性C.社会可行性D.操作可行性12．在软件工程项目中，不随参与人数的增加而使软件的生产率增加的主要问题是( )。
A.工作阶段间的等待时间B.生产原型的复杂性C.参与人员所需的工作站数D.参与人员之间的通信困难。
13.制定软件计划的目的在于尽早对欲开发的软件进行合理估价，软件计划的任务是( )。
A. 组织与管理B.分析与估算C.设计与测试D.规划与调度14.对每个合理的方案分析员都应该准备( )资料。
A.系统流程B.组成系统的物理元素清单，成本-效益分析C.实现这个系统的进度计划D.以上全部正确15.原型化方法是一类动态定义需求的方法，下列叙述中，( )不具有原型化方法的特征。
A.提供严格定义的文档B.加强用户参与和决策C.简化项目管理D.加快需求的确定。
软件工程(习题及参考答案)
第1章概述（习题与参考答案）［判定题］1. 由于今天个人运算机不断进展壮大，人们再也不采纳软件团队的开发方式。
（×）2. 由于软件是产品，因此能够应用其他工程制品所用的技术进行生产。
（×）3. 购买大多数运算机系统所需的硬件比软件更昂贵。
（×）4. 大多数软件产品在其生命周期中不需要增强功能。
（×）5. 大多数软件系统是不容易转变的，除非它们在设计时考虑了转变。
（√）6. 一样来讲，软件只有在其行为与设计者的目标一致的情形下才能成功。
（×）［选择题］1. （）因素促使运算机系统愈来愈复杂。
（D）A. 运算机内存和存储容量上的庞大增加B. 外部输入／输出选项的加倍多样性C. 运算机体系结构方面的深刻转变D. 以上所有选项2. 下面的（）再也不是现代软件工程师关注的问题。
（A）A. 什么缘故运算机硬件的本钱这么高？B. 什么缘故软件需要很长时刻才能完成？C. 什么缘故开发一个软件的本钱这么高？D. 什么缘故不能在产品发布前去除软件错误？3. 软件会慢慢退化而可不能磨损，其缘故在于（）。
（C）A. 软件通常暴露在恶劣的环境下B. 软件错误通常发生在利用以后C. 不断的变更使组件接口之间引发错误D. 软件备件很难订购4. 大多数软件仍然是定制开发的，其缘故在于（）。
（C）A. 软件组件重用是十分普遍的B. 可重用的组件太昂贵而无法利用C. 软件在不利用其他组件的情形下很容易构造出来D. 商业组件在很多应用领域中能够取得5. 下面的（）说法是正确的。
（C）A. 软件危机在20世纪70年代末期全面暴发B. 当前先进的软件工程方式已经解决了软件危机的问题C. 软件危机是指在运算机软件的开发和保护进程中碰到的一系列严峻问题D. 软件危机是指在软件产品中存在一系列的质量问题6. 软件工程的大体目标是（）。
（B）A. 排除软件固有的复杂性B. 开发高质量的软件C. 尽力发挥开发人员的制造性潜能D. 更好地保护正在利用的软件产品7. （）是将系统化的、标准的、可定量的方式应用于软件的开发、运行和保护的进程，它包括方式、工具和进程三个要素。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
不足
◦ （1）在把每个新增的构件或功能集成到现有的软件系统中时，必 须不破坏该软件系统。
◦ （2）在设计软件系统的体系结构时，要充分考虑到其开放性，而 且加入新构件的过程必须简单和方便。
Software Requirements Engineering
11
2.2.4 螺旋式模型
将瀑布式模型与快速原型模型结合到一起，并加上风 险分析。理解这种模型的一个简便方法是把它看作在每个 阶段之前都增加风险分析。
累计费用
各步骤的进度
确定目标， 选定方案， 设定约束条件
风险分析 风险分析 风险分析
评估方案， 识别并排除风险
需求计划 与生命周
期计划
开发计划
风险 分析
原型1
操作概念
需求确认
原型2
软件需 求
可运行的 原型3 原型
软件 产品 设计
详细 设计
时间
单
元 编码
计划下一阶段
集成 测
实现
验收 测试 试 测试
开发、验证 下一级产品
– 软件开发过程、软件开发和维护的方法和技术、软件开发和维护 工具系统、质量评价和质量保证、软件管理和软件开发环境等。
Software Requirements Engineering
4
2.2 软件开发过程模型
1. 瀑布式模型 2. 快速原型模型 3. 渐增式模型 4. 螺旋式模型 5. 面向对象的开发模型
需求分析和定义
（概要）设计
实现与集成各个构件
测试
维护
渐增式模型表明，必须在实现各个构件之 前就全部完成需求分析和概要设计工作。
Software Requirements Engineering
10
2.2.3 渐增式模型
特点
◦ （1）能在短时间向用户提交可完成部分功能的产品。 ◦ （2）能逐步增强产品功能以使用户有较充裕的时间学习和适应新
• 局限性
– （1）风险分析执行的困难使螺旋模型仅适用于大规模软件项目
Software Requirements Engineering
13
2.2.5面向对象的开发模型
所谓面向对象就是应 用对象、类、继承、封装、 消息、对象或类之间的关 系等面向对象的概念对问 题进行分析和求解的软件 开发技术，或者说，是以 对象（类）为数据中心、 对象之间的动态行为模式 作为运行机制的一种问题 求解方法。
Software Requirements Engineering
12
2.2.4 螺旋式模型
• 特点
– （1）适用于软件开发机构内部开发大规模软件项目。 – （2）对于可选方案和约束条件的强调有利于已有软件的重用，也
有助于把软件质量作为软件开发的一个重要目标。 – （3）减少过多测试或测试不足所带来的风险。
Software Requirements Engineering
5
2.2.1瀑布式模型
依据软件生命期而提出的软件开发模型 ，将软件的开 发过程被分为六个阶段，每个阶段都有明确的分工和任务， 并产生一定的书面结果。各阶段之间是紧密相关的，后一 阶段的工作是依据前一阶段的工作结果而开展的。
软件计划
需求分析与定义
7
2.2.2快速原型模型
快速原型模型的基本思想是快速建立一个实现了若干 功能的（不要求完全）可运行模型来启发、揭示和不断完 善用户需求，直到满足用户的全部需求为止。
收集需求 快速设计 建立原型 评价并细化需求 设计与实现 测试 维护
Software Requirements Engineering
Software Requirements Engineering
14
2.2.5面向对象的开发模型
• 特点
（1）有一部分分析工作必须在设计之前进行，而另 外一些分析工作则需与其他部分的设计与实现工作 并行地进行，因而呈现出非线性的工作方式。 （2）软件系统的表达形式在整个开发模型中都是相 同的，即面向对象方法中把类及其结构作为系统的 表达单元，无论哪一个阶段都以渐增的方式不断地 进化或细化这些表达单元。 （3）开发模型支持软件的重用。
– （1）大型软件系统十分复杂，很难理解和维护； – （2）软件开发周期过长； – （3）大型软件系统的可靠性差； – （4）软件费用往往超出预算。
Software Requirements Engineering
3
• 软件危机的解决方法
– 应用工程化的方法来进行软件的开发和维护
• 软件工程的研究内容
设计
编码
测试
维护
Software Requirements Engineering
6
2.2.1瀑布式模型
• 不足
– （1）要求用户一开始就提出清晰完整的需求 ；
– （2）段间移交信息（文档）的过程中，由于个人的理解不同， 容易产生误解；
– （3）用户的参与程度不够。
Software Requirements Engineering
不足
◦ （1）用户易于视原型为正式产品；
◦ （2）快速原型系统对于软件系统的开发环境要求较多，在一定程 度上也影响了其使用的范围和实用价值。
Software Requirements Engineering
9
2.2.3 渐增式模型
渐增式模型的基本思想是从核心功能开始，通过不断 地改进和扩充，使得软件系统能适应用户需求的变动和扩 充，从而获得柔软性较高的软件系统。
8
2.2.2快速原型模型
目的
◦ （1）明确并完善需求； ◦ （2）探索设计选择方案； ◦ （3）可以发展为最终的产品。
特点
◦ （1）能弥补瀑布模型中用户参与程度不够等不足； ◦ （2）能减少用户需求的遗漏以及（在软件开发后期）用户频繁修
改需求的可能性 ； ◦ （3）用户可以充分地参与到软件开发中； ◦ （4）快速。
Software Requirements Engineering
15
2.3 需求工程与软件开发
1. 需求工程对软件开发的影响 2. 需求工程面临的困难
Software Requirements Engineering
16
2.3.1 需求工程对软件开发的影响
第2章 软件工程与需求工程
第2章 软件工程与需求工程
2.1 软件工程 2.2 软件开发过程模型 2.3 需求工程与软件开发 2.4 软件需求的开发和管理过程
Software Requirements Engineering
2Байду номын сангаас
2.1 软件工程
• 软件危机
– 是指人们难以控制软件的开发和维护。
• 表现