软件开发实务总结

一、为什么要学习软件工程

• 学习软件工程可以帮助人们更好地了解如何开发高质量的软件系统。
• 软件工程是将计算机科学和工程学的原则应用于软件开发的实践。
• 软件工程师需要掌握各种工具和技术，如需求分析、设计、编码、测试和维护等，以便他们能够设计、开发和维护高质量的软件系统。

二、软件工程导论

• 软件工程实务是指在软件开发过程中，实际应用和实施各种软件工程方法和技术的过程。它包括软件生命周期的各个阶段，如需求分析、设计、编码、测试、部署和维护等。

2.1 软件工程概念

• 软件工程是指将系统化、规范化、可量化的方法应用于软件的开发、使用和维护的过程。 具体而言，软件工程涉及到软件开发过程中的各个方面，包括需求分析、规划、设计、编码、测试、维护和管理等。
• 软件工程的目标是提高软件开发的效率、质量和可靠性，降低软件开发的成本和风险。

2.2 可行性研究

2.2.1 可行性研究的任务

• 可行性研究的目的不是解决问题，而是问题是否值得去解决
• 实质：是要进行一次次大大压缩简化了的系统分析和设计的过程，也是再较高层次上以较抽象的方式进行的系统分析和设计的过程。

** 三个方面研究每种解法的可行性**

1. 技术可行性
2. 经济可行性
3. 操作可行性

2.2.2 可行性研究的过程

以下是可行性研究的经典过程：

• 复查系统规模和目标
• 研究目前正在使用的目标
• 导出新系统的高层逻辑模型
• 进一步定义问题
• 导出和评论供选择的解法
• 推荐行动方针
• 草拟开发计划
• 书写文档提交审查

2.2.3 系统流程图

• 系统流程图是一种用图形化的方式表示系统或过程中各组成部分以及它们之间流动关系的图表。该图可以用来描述计算机系统、工业生产流程、管理流程等各种系统或过程。
• 系统流程图中包含了各个组成部分之间的输入输出关系、决策点、转移点、控制流程等关键信息，可以帮助更好地理解并分析系统或过程中的细节。

2.2.4 例子

2.2.5 数据流图

关于系统流图的详细可以从这里了解

• 软件工程的数据流图（Data Flow Diagram，简称DFD），是一种描述系统或软件功能的图形工具。它主要描述了一个系统中的数据、过程和数据存储之间的关系和交互。

• DFD由数据流、处理机、数据存储和外部实体四种基本元素组成。其中，数据流表示数据在系统中流动的路径，处理机表示数据的加工和处理过程，数据存储表示数据的持久化保存，外部实体表示与系统进行交互的外部环境。

• DFD可以分为多个层次，每个层次表示不同的抽象级别。最底层的DFD称为0级数据流图，它展示了系统的最基本的处理逻辑和数据流动情况。而更高层次的DFD表示了更高层次的抽象和总体的系统功能和交互情况。

• DFD作为一种较为简单易懂的图形工具，广泛应用于软件工程中的需求分析、设计和测试等阶段，可以帮助分析师和开发人员更好地理解和设计软件系统的交互和功能。

2.2.6 数据流图的介绍

2.3 项目愿景

是对于软件产品的预期结果和目标的描述。 它提供了整个项目实现的方向和指导，并为项目团队提供了明确的目标和愿景。

构成：

1. 项目的目标和愿景：明确项目的目标和愿景，描述项目的预期成果，以及项目实现后可以达到的效益。
2. 用户需求和期望：从用户的角度出发，分析他们的需求和期望，确定解决问题的方法和方案。
3. 技术实现和架构：明确技术实现的方向和架构，确保技术实现能够支持项目的目标和愿景。
4. 项目交付和实施：确定项目交付的时间表和实施计划，确保项目能够按时交付，并且能够顺利地实施。
5. 项目管理和控制：明确项目的管理和控制方式，以确保项目的质量、进度和成本可控。

2.4 需求分析

系统需求是这个系统必须执行支持的所有活动和必须满足的约束条件。通常分为功能需求和非功能需求。

2.3.1 功能需求

系统必须执行的活动。以工资管理系统为例，可能包括电子支付、计算工资、计算工资税、维护员工相关信息、社保、医保、公积金缴纳等等。
功能需求是根据公司开展业务交易的过程和业务规则确定的。
有时这些规则详细记录与文档，从而易于确定和描述；而另外的一些规则可能隐蔽而难以被发现。
而尽早发现这类规则是需求分析的重要任务。

2.3.2 非功能需求

是系统的固有特征，它不同于系统必须执行或支持的活动。
区别功能/非功能需求并不容易，人们开发了一些架构来识别和分类需求的方法，如FURPS+架构（功能、可用性、可靠性、性能、可支持性的首字母）。

需求	FURPS+	举例
功能需求	功能（Functional）	业务规则和流程
非功能需求	可用性（Usability）可靠性（Reliability）性能（Performance）可支持（Supportablity)+设计约束条件实施 接口物 可支持	用户界面、易用性失误率、回收法响应时间、生产力 适应性、可维护性、国际化 硬件和支持的软件 开发工具、协议 数据交换格式 尺寸、重量、消耗

常用的需求信息收集技术包括：

• 用户/系统干系人访谈
• 发放和收集调查问卷
• 检查输入、输出和文档
• 观察和记录业务流程
• 收集活跃用户的用户评论和建议

三、系统分析技术

是指通过对现有软件系统进行调研、了解和分析，以确定其需求、约束和问题，并为设计和开发新系统提供重要的指导

3.1 用例

1. 用例和用户目标

• 定义用例的一个方法是用户目标技术，这个技术要求用户描述他们使用新系统或者更新系统的目标

2. 用例和事件分解

• 定义用例最复杂的方法是事件分解技术。事件分解首先定义所有的业务事件，这些事件会引起信息系统的回应，同时每个事件都会产生一个用例。

3. 事件分解技术

• 事件分解技术聚焦于定义出系统必须对哪些事件做出响应，然后决定系统怎样响应。

3.2 领域建模

详情可以看详情地址

• 领域建模¹是一种需求工程中的技术，它的目的是通过对问题领域的分析和建模，深入了解用户需求，为软件开发提供指导和支持。
• 可以有效地提高软件开发的质量和效率，同时也可以减少软件开发中的错误和风险。

领域建模包括以下步骤:

1. 需求采集：与客户和用户进行沟通，了解需求和业务流程。
2. 领域分析：对需求进行详细分析和理解，确定系统的业务领域和范围。
3. 领域建模：使用UML或其他建模语言，将领域的实体、属性、关系等信息进行抽象和建模，以便软件开发人员更好地理解和实现。
4. 验证和确认：验证建模的正确性和完整性，与客户和用户确认需求和模型的一致性。

3.3 需求模型的延伸

• 场景模型（Scenario Model）：使用场景来描述软件系统的功能和需求，通常以用户故事、使用案例、场景规范等形式呈现。
• 原型模型（Prototype Model）：通过制作原型来探索用户需求和设计解决方案，在早期阶段发现和解决问题，提高开发效率。
• 历史模型（Legacy Model）：对于一些现有的软件系统，需要对其进行维护、升级和改进，此时可以使用历史模型来识别和记录系统的功能和缺陷。
• 面向特定领域的模型（Domain-specific Model）：针对某个特定的业务领域和行业，设计相应的模型和工具，帮助开发人员更好地理解和满足用户的需求。

四、系统设计

是指根据需求分析所得到的需求规格说明书和软件需求说明，确定软件的整体结构、模块划分、模块接口设计、算法设计、数据结构设计等各个方面的问题，使得软件系统能够满足用户需求，并且能够达到可靠性、可维护性、可扩展性、可重用性等质量要求。

4.1 设计与设计活动的基本要素