软件工程概述
目录
软件工程概述
软件开发生命周期
- 软件定义时期
：包括可行性研究和详细需求分析，任务是确定软件开发的总目标。
- 问题定义
- 可行性研究（经济、技术、操作、社会可行性，确定问题和解决办法）
- 需求分析（确定功能需求，性能需求，运行环境的约束， 软件需求规格说明书 Software requirements specification SRS，软件系统测试大纲，用户手册概要 ）
- 软件开发时期
：涉及软件的设计与实现。
- 概要设计（在SRS的基础上，建立总体结构，包括子系统的划分，模块之间的关系）
- 详细设计（对功能模块细化，包括算法和数据结构）
- 编码
- 测试
- 软件运行和维护 ：将软件产品移交给用户使用。
软件系统文档
- 用户文档 ：描述系统功能和使用方法，不涉及具体实现。这类文档主要面向软件的最终用户，目的是帮助用户理解和使用软件。它包括软件的功能描述、使用方法、操作指南等。用户文档通常不需要详细说明软件内部的工作原理或实现细节。它的目标是让非技术人员能够无障碍地使用软件，了解软件如何满足他们的需求。
- 系统文档 ：描述系统设计、实现和测试等各方面的内容。系统文档则面向软件开发团队和可能需要进行维护的技术人员。它涵盖了软件的设计、实现、测试等详细的技术信息。系统文档通常包括需求规格说明书、设计文档、代码文档、测试计划和报告等。这类文档对于软件的开发、调试和维护非常重要，因为它提供了软件内部结构、工作流程和技术细节的详细信息。
软件工程过程
- P(Plan) ：软件规格说明，规定功能及其运行限制。
- D(Do) ：软件开发，实现满足规格说明的软件。
- C(Check) ：软件确认，确认软件满足用户需求。
- A(Action) ：软件演进，不断改进以满足新需求。
软件系统工具
- 软件开发工具 ：需求分析、设计、编码与排错、测试等工具。
- 软件维护工具 ：版本控制、文档分析、开发信息库、逆向工程、再工程工具。
- 软件管理和软件支持工具 ：项目管理、配置管理、软件评价、工具选择与评估等。
软件设计活动
- 数据设计 ：数据设计是确定系统需要处理的数据类型、数据之间的关系以及数据存储和管理的方式。它包括定义数据库结构、数据格式、数据字典等内容。良好的数据设计有助于确保数据的一致性、完整性和安全性，支持系统的高效运行和维护。
- 架构(体系结构)设计 ：架构设计是定义软件系统的高层次结构，包括确定系统的主要组件、组件之间的关系以及这些组件如何交互来实现系统的功能。架构设计通常涉及系统的技术选型、模块划分、数据流设计等，是一个关键的设计阶段，对软件的可扩展性、可维护性和性能有着重要影响。
- 人机界面(接口)设计 ：人机界面设计主要关注用户与软件系统的交互方式，包括用户界面的布局、颜色、字体、按钮等视觉元素的设计，以及用户操作流程的设计。目标是设计出易于理解和使用的用户界面，提升用户体验，使用户能够高效地使用系统完成任务。
- 过程设计 ：过程设计是指定义软件系统内部的工作流程和操作步骤，确保数据处理的正确性和效率。它包括算法设计、业务规则实现、工作流定义等。过程设计需要考虑如何高效地执行业务逻辑，如何处理异常情况，以及如何优化性能。
软件需求
业务需求 ：企业或客户高层次的目标要求，通常由项目投资人、客户或市场营销部门提供。 **通过业务需求可以确定项
目视图
和
范围
。**
用户需求 ：用户的具体目标及系统需完成的任务，通过访谈、问卷等方式获取。 对用户使用的场景进行整理，从而建立用户需求。
系统需求 ：从系统角度说明软件需求，包括功能需求、非功能需求和设计约束。
- 功能需求（行为需求）
- 非功能需求（质量属性、其他非功能需求）
- 设计约束（限制条件、补充规约）
需求获取是一个确定和理解 不同的项目干系人的需求和约束的过程 。
需求获取方法
- 用户访谈：一对一或小范围访谈，结构化或非结构化形式。
- 问卷调查：适用于用户众多，无法逐一访谈的情况。
- 采样：从种群中选取代表性样本，数量计算方法见文本。
- 情节串联板：使用图片序列讲述故事。
- 联合需求计划（JRP）：关键用户、分析师、开发团队联合会议讨论需求。
- 需求记录技术：任务卡片、场景说明、用户故事、Volere白卡。
需求分析
- 需求特性：无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性。
- 结构化的需求分析的结构化特点： 自顶向下，逐步分解，面向数据。
- 结构化的需求分析的三大模型： 功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图)以及数据字典。
- 任务：
- 绘制系统上下文范围关系图
- 创建用户界面原型
- 分析需求的可行性
- 确定需求优先级
- 建立需求模型
- 创建数据字典
- 使用QFD（质量功能部署）
需求定义
- 软件需求规格说明书（SRS） ：需求开发的结果，作为开发基础的重要文档。是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。
需求定义方法
- 严格定义（预先定义） ：基于所有需求预先定义、清晰交流和图形文字表达的假设。
- 原型方法 ：迭代开发，涉及实际可参与的模型、合适的开发环境、反复验证，最终需求确定后按照严格方法执行。
需求验证
- 目的：确认需求无误，评审和 测试需求规格说明书（SAS） 。
- 步骤：
- 需求评审（正式评审、非正式评审）
- 需求测试（设计概念测试用例）
- 需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求 基线，不可以再随意更新，如果需要更改必须走需求变更流程。
需求管理
- 需求基线 ：评审通过的需求说明书作为基线。
变更和风险 ：关注需求变更过程中的风险，包括风险做法和变更原因。
- 带有风险的做法有：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。
- 变更产生的原因： 外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。
变更控制委员会（CCB） ：也称为配置控制委员会，其任务时对建议的配置项变更做出评价、审批，以及监督已经批准变更的实施。
需求跟踪 ：双向跟踪（正向和反向），确保实现需求的完整性和准确性。
如下图所示：
- 正向跟踪：检查原始需求是否实现。
- 反向跟踪：确认实现的功能是否符合需求。
