软件工程概述

软件工程概述

让我们先了解一下软件工程的含义。该术语是由两个词语组成的，软件与工程。

软件 不仅仅是一个程序代码。程序是一个可执行的代码，它提供了一些计算的目的。 软件被认为是集合可执行的程序代码，相关库和文档的软件。当满足一个特定的要求，就被称为软件产品。

工程 是所有有关开发的产品，使用良好定义的，科学的原理和方法。

软件工程 是一门工程分支使用定义良好的科学原理，方法和程序开发软件产品。软件工程的成果是一个高效，可靠的软件产品。

定义

IEEE对于软件工程的定义:

(1) 将系统、规范、可量化的方法应用于软件的开发、运行和维护；也就是说，工程在软件中的应用。
(2) 研究方法如上陈述。

Fritz Bauer（德国计算机科学家）对软件工程的定义:

软件工程是建立和使用合理的工程原理，以便经济地获得可靠且在真是机器上有效工作的软件。

软件演化

运用软件工程的原理和方法开发软件产品的过程被称为软件演化。此处包含的软件的初始开发及维护和更新，直到所需的软件产品的开发，其满足预期需求。

演化从需求收集过程开始。之后，开发人员创建预期软件的原型，并将其展示给用户，以便在软件产品开发的早期阶段获得他们的反馈意见。用户提出的建议，在这几个连续的更新和维护不断变化太大。这个过程改变了原来的软件，直到所需的软件来完成。

即使用户手中已有所需的软件，先进的技术和不断变化的需求迫使软件产品做出相应的改变。从头开始重新创建软件并与需求一对一是不可行的。唯一可行且经济的解决方案是更新现有的软件，使其符合最新要求。

软件演化规律

Lehman 给了软件演化规律。他把软件分为三个不同的类别:

1、S型（静态型)： 这是一款严格按照定义的规范和解决方案工作的软件。解决方法和实现它的方法，都在编码之前立即被理解。S型软件至少受到的更高最少，因此这是最简单的。例如，用于数学计算的计算器程序。

2、P-型 (实用型)： 这是一个程序集合的软件。这是由程序可以做什么来定义的。在这个软件中，规范可以描述，但解决方案并不明显。例如，游戏软件。

3、E-型(嵌入型)： 该软件紧密配合实际环境的要求。这种软件具有高度的进化，因为在现实世界的情况下，法律，税收等会发生各种变化。例如，网上交易软件。

E型软件演化

Lehman 给了八项法律为E型软件演化:

1、不断变化 - E型软件系统必须不断适应现实世界的变换，否则它逐渐变得不那么有用。

2、日益复杂 - 随着 E 类软件系统的发展，其复杂性往往会增加，除非进行维护或减少工作。

3、维护熟悉度 - 必须不惜任何代价保留对软件的熟悉或关于它是如何开发的、为什么以这种特定方式开发等的知识，以便在系统中实施更改。

4、持续增长 - 为了使E型系统旨在解决某些业务问题，其实施变化的规模根据业务生活方式的变幻而增长。

5、降低质量 - 除非严格维护并适应不断变化的操作环境，否则 E 类软件系统的质量会下降。

6、反馈系统 - E型软件系统构成多环回路，多级反馈系统，必须如此对待才能成功修改或改进。

7、自我调节 - E型系统的演化过程是自我调节，产品分布和过程措施接近正常。

8、组织稳定性 - 在不断变化的 E 型系统中，平均有效的全球活动率在产品的整个生命周期内是不变的。

软件范式

软件范例参考方法和步骤，在设计的软件，该软件被执行。有提出许多方法，并在今天的工作，但我们需要看到在软件工程这些范式立场。这些可以组合成各种类别，虽然每个这些被包含在彼此:

编程模式是软件设计模式的一个子集是进一步的软件开发模式的一个子集。

软件开发范式

这种模式被称为软件工程范例，所有有关软件开发工程的概念被应用。它包括各种研究和需求收集，这有助于软件产品来构建。

1、需求收集

2、设计软件

3、编程

软件设计模式

这一模式是软件开发的一部分，包括:

1、设计

2、维护

3、编程

编程范式

这一模式是密切相关的软件开发编程方面，这包括:

1、编码测试

2、整合

软件工程的需求

软件工程的需要，因为较高的利率变化的用户需求及环境上的软件工作。

1、大型软件 - 建造一堵墙比建造房屋或建筑物更容易，同样，随着软件的规模变大，工程必须采取措施为其提供科学的过程。

2、可扩展性 - 如果软件过程不是基于科学和工程概念，那么重新创建软件比扩展现有软件更容易。

3、成本 - 由于硬件行业已经展示了它的技能和庞大的制造业，降低了计算机和电子硬件的价格。但是，如果不采用适当的流程，软件成本仍然很高。

4、动态性 - 软件的不断发展和适应在很大程度上取决于用户工作的环境。如果软件的性质总是在变化，则需要在现有软件中进行新的增强。这就是软件工程发挥良好作用的地方。

5、质量管理 - 更好的软件开发过程提供更好质量的软件产品。

优秀的软件特性

一个软件产品可以判断通过其功能和多少用户友好。这个软件必须满足以下功能：

1、操作

2、过渡

3、维护

一个精心设计和制作的软件预计将有以下几个特点:

操作

这告诉我们如何以及软件的操作工作。它可以在被测定：

1、预算

2、可用性

3、正确性

4、功能

5、可靠性

6、安全

7、安全性

过渡

这方面是重要的，当软件从一个平台转移到另一个：

1、可移植性

2、互操作性

3、可重用性

4、适应性

保养

这讲述一个软件以及如何有能力维护自己的每一个变化的环境中：

1、模块化

2、可维护性

3、灵活性

4、可扩展性

总之，软件工程是计算机科学的一个分支，它使用定义明确的工程概念来产生高效、持久、可扩展、预算内和准时的软件产品。

软件开发生命周期

软件开发生命周期（Software Development Life Cycle），简称SDLC，是软件工程中定义明确、结构化的阶段序列，用于开发预期的软件产品。

SDLC活动

SDLC 提供了一系列需要遵循的步骤，以有效地设计和开发软件产品，SDLC 框架包括以下步骤：

通信

这是用户发起对所需软件产品的请求的第一步。他联系服务提供商并尝试协商条款，以书面形式向服务提供组织提交请求。

要求收集

从这一步开始，软件开发团队将继续执行该项目。该团队与来自问题领域的各种利益相关者进行讨论，并试图提供尽可能多的关于他们需求的信息。这些需求被划分为用户需求、系统需求和功能需求。这些需求是使用给定的许多实践手机的：

1、研究现有的或已过时的系统和软件

2、对用户和开发人员进行访谈

3、参考数据库

4、从问卷中收集答案

可行性研究

在需求收集之后，团队提出了软件过程的粗略计划。在这一步，团队分析是否可以制作一个软件来满足用户的所有需求，以及是否有任何软件不再有用的可能性。如果该项目在预算上、实际上和技术上对组织来说是可行的，就会被发现。有许多可用的算法，可以吧主开发人员得出软件项目的可行性。

系统分析

在这一步的开发者决定他们计划的路线图，并尝试提出适合该项目的最好的软件模型。系统的分析包括了解软件产品的限制，学习系统相关的问题或变化将在现有的系统中之前进行，识别并解决项目对组织人事等团队项目的影响分析项目的范围，并计划进度和相应的资源。

软件设计

在这一步，开发人员决定他们的计划路线图，并尝试提出适合项目的最佳软件模型。系统分析包括了解软件产品的局限性，预先了解系统相关问题或在现有系统中要进行的更改，识别和解决项目对组织和人员的影响等。项目团队分析项目范围，并相应地计划进度和资源。

编码

这个步骤也被称为编程阶段。软件设计的实施始于用合适的编程语言编写程序代码并有效地开发无错误的可执行程序。

测试

据估计，应该测试整个软件开发过程的 50%。错误可能会破坏软件从关键级别到自行删除。软件测试由开发人员在编码的同时进行，由测试专家在各个级别的代码（例如模块测试、程序测试、产品测试、内部测试和用户端测试产品）上进行全面测试。尽早地发现错误及其补救措施是获得可靠软件的关键。

整合

软件可能需要与库、数据库和其他程序集成。SDLC 的这个阶段设计软件与外部世界实体的集成。

实施

这意味着在用户机器上安装软件。有时，软件需要在用户端进行安装后配置。测试软件的可以执行和适应性，并在实施过程中解决与集成相关的问题。

操作和维护

此阶段以更高的效率和更少的错误来确认软件的操作。如果需要，用户将接受有关如何操作以及如何保持软件运行的文档的培训或帮助。通过根据用户终端环境或技术发生的变化更新代码来及时维护软件。此阶段可能面临来自隐藏错误和现实世界中未识别问题的挑战。

处置

随着时间的推荐，软件的性能可能会下降。它可能会完全过时或可能需要大量升级。因此，迫切需要消除系统的主要部分，该阶段包括归档数据和所需的软件组织、关闭系统、规划处置活动和在适当的系统结束时间终止系统。

软件工程项目管理

软件项目管理中可以分成两部分:

1、软件创新

2、软件项目管理

项目是定义明确的任务，这是为了实现某个目标（例如，软件开发和交付）进行的一系列操作的集合。一个项目可以表征为:

1、每个项目都可以有一个独特而鲜明的目标。

2、项目不是日常活动或日常运营。

3、项目带有开始时间和结束时间。

4、项目在其目标实现时结束，因为它是组织生命周期中的一个临时阶段。

5、项目需要充实的时间，人力，财力，物力和知识库资源。

一个软件项目是软件开发从需求收集到测试和维护的完整过程，按照执行方法进行，在特定的时间段内实现预期的软件产品。

软件项目管理的必要性

软件被认为是一种无形的产品。软件开发是世界商业中的一种全新流程，在构建软件产品方面的经验很少。大多数软件产品都是根据客户的要求量身定制的。最重要的是底层技术的变化和进步如此频繁和迅速，以至于一种产品的经验可能无法应用于另一种产品。所有这些业务和环境限制都会给软件开发带来风险，因此有效管理软件项目至关重要。

上图显示了软件项目的三重约束。它是软件组织的重要组成部分，以提供高品质的产品，将成本控制在客户的预算范围内，并按计划交付项目。有几个内部和外部因素，这可能会影响到三重约束三角形。三个因素中的任何一个会严重影响其他两个。

因此，软件项目管理对于用户的需求以及预算和时间的限制结合起来是至关重要的。

软件项目经理

软件项目经理是负责执行软件项目的人。软件项目经理完全了解软件将经历的 SDLC 的所有阶段。项目经理可能不会直接参与生产的最终产品，但他控制和管理参与生产活动。

项目经理密切监察开发过程，准备和执行各种计划，安排必要的和足够的资源，保持所有团队成员之间的沟通，以解决成本，预算，资源，时间，质量和客户满意度等问题。

让我们来看看一个项目经理需要做什么：

管理人员

1、担任项目负责人

2、与利益相关者联络

3、人力资源管理

4、设置报告层次结构等

项目管理

1、定义和设置项目范围

2、管理项目管理活动

3、监控进度和绩效

4、每个阶段的风险分析

5、采取必要措施避免或摆脱问题

6、作为项目的发言人

软件管理活动

软件项目管理包括了一系列活动，其中包括项目的规划、软件产品范围的决定、各个方面的成本估算、任务和事件的调度和资源管理。项目管理活动包括:

1、项目规划

2、范围管理

3、项目估算

范围管理

它定义项目的范围;这包括了为了制作可交付的软件产品而需要完成的所有活动和过程。范围管理是必不可少的，因为它通过明确定义在项目中可以做什么做，不可以做什么来创建项目的界限。这使得项目包含有限的且可量化的任务，它可以很容易地进行记录，进而避免了成本和时间超支。

在项目范围管理，有必要：

1、定义范围

2、决定其验证和控制

3、为了便于管理，将项目划分为各个较小的部分

4、验证范围

5、通过合并对范围的更改来控制范围

项目估算

对于各项措施的有效管理准确的估算是必须的。有了正确的估算，经理可以更有效地管理和控制项目。

项目估算可能涉及以下内容:

软件规模

估算软件规模可能根据 KLOC（Kilo Line Of Code）或通过计算软件中的功能点数量进行估算。代码行数取决于编码实践，功能点根据用户或软件的要求而变化.

工作量

管理人员根据生产软件所需的人员需求和工时来估算工作量。对于工作量估算，软件规模应该是已知的。这可以通过管理人员的经验、组织的历史数据或软件规模可以通过使用一些标准的公式转换成工作量。

时间

一旦估算了规模和工作量，就可以估算生产软件所需要的时间。根据需求规范和软件各个组件的依赖性，所需的工作分为子类别。软件任务通过工作突破结构（WBS）分为较小的任务、活动或时间。他的任务是按天或按日历月安排的。

以小时或天为单位完成所有任务所需的时间总和是完成项目所投入的总时间。

成本

这可能被认为是最困难的，因为它依赖的元素比以前任何一个都多。在估算项目成本时，需要考虑：

1、软件规模

2、软件质量

3、硬件

4、其他的软件或工具，许可证等

5、具有特定任务技能的技术人员

6、出差

7、沟通

8、培训和支持

项目估算技术

我们讨论了涉及项目估算各种参数，例如规模，工作量，时间和成本.

项目经理可以使用两种广泛认可的技术来评估所列出的因素。

分解技术

这种技术将软件假定为各种组合的产品。

主要有两种模式：

1、代码行 估算是代表软件产品中的代码行数进行的。

2、功能点 估算是代表软件铲平中的功能点数量进行的。

经验估算法

这种技术使用经验得出的公式来作出估算。这些公式是基于 LOC 或 FP.

Putnam 模型 这种模式是由劳伦斯·普特南，它是基于 Norden 的频率分布（瑞利曲线）。Putnam 模型映射了软件规模所需的时间和精力。

COCOMO COCOMO 代表构造成本模型，由巴里·W·贝姆开发。它把软件产品分为三类软件：有机、半独立式和嵌入式。

项目安排

项目中的项目安排是指在每个活动分配的时间段内按照指定的顺序完成的所有活动的路线图。项目经理倾向于定义各种任务和项目里程碑，并在考虑各种因素的情况下安排它们。他们在计划中寻找位于关键路径中的任务，这些任务必须以特定的方式（因为任务相互依赖）并严格在分配的时间内完成。关键路径之外的任务安排不太可能影响项目的所有进度。

安排一个项目，有必要：

1、将项目任务分解为更小的、可管理的形式

2、找出各种任务并将它们关联起来

3、估算每项任务所需的时间范围

4、将时间划分为工作单位

6、为每项任务分配足够数量的工作单位

7、计算项目从开始到结束所需的总时间

资源管理

用于开发软件产品的所有元素都可以被假定为该项目的资源。这可能包括人力资源，生产工具和软件库。

资源数量有限，并作为资产池留在组织中。资源短缺阻碍了项目的发展，可能会滞后于进度。分配额外的资源最终会增加开发成本。因此，有必要为项目估算和分配足够的资源。

资源管理包括：

1、通过创建项目团队并将职责分配给每个团队成员来定义适当的组织项目

2、确定特定阶段所需的资源及其可用性

3、通过在需要时生成资源请求并在不再需要时取消分配来管理资源

项目风险管理

风险管理涉及与识别、分析和准备项目中可预测和不可预测风险有关的所有活动。风险可能包括以下内容:

1、经验丰富的工作人员离开该项目，新员工加入。

2、组织管理的变化。

3、需求变更或误解需求。

4、低估了所需的时间和资源。

5、技术变化，环境变化，商业竞争。

风险管理过程

有参与的风险管理流程如下活动:

识别 记下项目中可能发生的所有可能的风险。

分类 根据对项目可能产生的影响，将已知风险分为高、中和低风险强度。

管理 分析各阶段风险发生的概率。制定计划以避免或面临风险。尽量减少它们的副作用。

监测 密切监测潜在风险及其早期症状。还要监控为减轻或避免它们而采取的措施的影响。

项目执行与监控

在这个阶段中，项目计划中描述的任务根据它们的时间表执行。

执行需要监控，以检查按计划一切是否会按计划进行。监控是观察以检查风险发生的可能性，并采取措施应对风险或报告各项任务的状态。

这些措施包括：

1、活动监控 可以每天监控某些任务中安排的所有活动。当任务中的所有活动都完成时，它就会被视为完成。

2、状态报告 报告包含在给定的时间范围内（通常一周）完成的活动和任务的状态。状态可以标记为已完成、待处理或者进行中等。

3、里程碑清单 每个项目都分为多个阶段，根据 SDLC 的阶段执行主要任务（里程碑）。此里程碑清单没几周准备一次，并报告里程碑的状态。

项目沟通管理

有效的沟通对项目的成功起着至关重要的作用。它弥合了客户与组织、团队成员以及项目中其他利益相关者（如硬件供应商）之间的差距。

沟通可以是口头的或书面的。通信管理过程可具有以下步骤:

规划 这一步包括识别项目中的所有利益相关者以及他们之间的沟通方式。它还考虑是否需要任何额外的通信设施。

共享 在确定规划的各个方面，经理专注于在正确的时间与正确的人共享正确的信息。这使参与项目的每个人都能了解项目进度及其状态。

反馈 项目经理使用各种措施和反馈机制并建立状态和绩效报告。这种机制保证了来自不同利益相关者的输入作为他们的反馈传递给项目经理。

关闭 在每一个重大时间结束，SDLC阶段结束或项目本身结束时，正式宣布关闭，通过发送电子邮件、分发文件的硬拷贝或其他有效沟通方式来更新每个利益相关者。

关闭后，团队进入下一阶段或项目。

配置管理

配置管理是跟踪和控制软件在产品的要求、设计、功能和开发方面的变化的变化。

IEEE 将其定义为“识别和定义系统中的项目的过程，控制这些项目在整个生命周期中的变化，记录和报告项目状态和变更请求的过程，并验证项目的完整性和正确性。”。

通常，一旦 SRS 最终确定，用户要求更改的可能性就较小。如果发生这些变化，只有在获得更高管理层的事先批准后才能解决，因为可能会超出成本和时间。

项目管理工具

即使项目是根据既定方法开发的，风险和不确定性也随着项目规模的增加而成倍增加。

有一些可用的工具可以帮助进行有效的项目管理：

甘特图

甘特图是由亨利·甘特（Henry Gantt,1917）设计的。它代表与事件段相关的项目进度表。它是一个水平条形图，其中的条形表示为项目活动安排的活动和事件。

PERT 图

PERT（程序评估和审查技术）图是一种将项目描述为网络图的工具。它能够以并行和连续的方式以图形方式表示项目的主要事件。一个接一个发生的事件表明后一个事件对前一个事件的依赖性。

事件显示为编号节点。它们由描述项目中人物顺序的标记箭头连接。

资源直方图

这是一个图形工具，包含表示项目事件（或阶段）随时间推移所需资源数量的条形图或者图表。

软件开发需求

软件需求是对目标系统特性和功能的描述。需求传达了用户对软件产品的期望。从客户的角度来看，需求可以是明显的或隐藏的、已知的或未知的、预期的或意外的。

需求工程

从客户那里收集软件需求、分析和记录它们的过程称之为需求工程。

需求工程的目标是开发和维护复杂的和描述性的“系统需求规范”的文件。

需求工程过程

这是一个四步骤的过程，其中包括：

1、可行性研究

2、需求收集

3、软件需求说明书

4、软件需求验证

让我们来看看这个过程。

可行性研究

当客户接近组织以开发所需的产品时，它会粗略地想出软件必须执行的所有功能以及软件期望的所有功能。

分析人员参考这些信息，详细研究所需的系统及其功能是否可以开发。

可行性研究的重点是组织的目标。研究分析了软件产品是否可以在实施、项目对组织的巩县、成本约束以及根据组织的价值观和目标方面实际实现。它探讨了项目和产品的技术方面，例如可用性、可维护性、生产力和集成能力。

这一阶段的输出应该是一个可行性研究报告，其中应包含对管理层是否开展该项目的充分评论和建议。

需求收集

如果可行性报告对承接该项目是肯定的，下一阶段就从收集用户的需求开始。收集来自各利益相关方的要求后，系统分析员创建SRS文档.分析师和工程师与客户和最终客户沟通，以了解他们对软件你应该提供什么以及他们希望软件包含哪些功能的想法。

软件需求规格

SRS（Software Requirement Specification，软件需求规格）是系统分析师在从各个利益相关者那里收集需求后创建文档。

SRS定义了预期软件将如何与硬件、外部接口、操作速度、系统响应时间、软件跨各种平台的可移植性、可维护性崩溃后恢复速度、安全性、质量、限制等交互。.

从客户那里收到的要求是用自然语言编写的。系统分析师有责任用技术语言记录需求，以便软件开发团队能够理解它们并对其有用。

SRS应该具备以下功能：

1、用户需求以自然语言表达。

2、技术要求以组织内部使用的结构化语言表达。

3、设计说明应该使用伪代码编写。

4、表格格式和 GUI 屏幕打印。

5、如 DFD 等的条件和数学符号。

软件需求验证

开发需求规范后，将验证本文档中提到的需求。用户可能会要求非法、不切实际的解决方案，或者专家可能会错误地解释要求。如果不将其扼杀在萌芽状态，这将导致成本的巨大增加。可以根据以下条件检查要求：

1、如果它们可以实际实施。

2、如果它们有效并且符合软件的功能和领域。

3、如果有任何的歧义。

4、如果它们是完整的。

5、如果它们可以被证明。

需求获取过程

可以使用以下图表描述需求获取过程。

需求收集 开发人员与客户和最终用户讨论并了解他们对软件的期望。

组织要求 开发人员按照重要性、紧迫性和方便性的顺序对需求进行优先级排序和安排。

谈判和讨论 如果需求不明确或者各个利益相关者的需求存在冲突，如果是，则与利益相关者进行协商和讨论。

需求来自不同的利益相关者。为了消除歧义和冲突，为了清晰和正确，对它们进行了讨论。不切实际的要求被合理地妥协。

文档 所有正式和非正式的、功能性和非功能性的需求都被记录，并可供下一阶段的处理使用。

需求获取技术

需求获取是通过与客户、最终用户、系统用户和其他与软件系统开发有利益关系的人沟通，找出预期软件系统需求的过程。

有多种方法可以发现需求：

面试

面试时收集需求的有力媒介。组织可能会进行多种类型的面试，例如：

1、结构化（封闭式）的采访，其中每一个要收集的信息是预先决定，他们严格遵循讨论的模式和问题。

2、非结构（开放式）的采访，无需事先决定要收集的信息，更灵活且偏见更少。

3、口试。

4、笔试。

5、一对一面试，在桌子对面的两个人之间进行。

6、在参与者之间进行的小组访谈。由于涉及的人员众多，它们有助于发现任何缺失的需求。

调查

组织可以通过询问他们对即将到来的系统的期望和要求，在不同的利益相关者只之间进行调查。

问卷调查

一份带有预先定义的客观问题和相应选项的文件被交给所有利益相关者回答，这些问题被收集和编译。

这种技术的一个缺点是，如果问卷中没有提到某个问题的选项，这个问题会无人注意。

任务分析

工程师和开发团可以分析需要新系统的操作。如果客户已经有一些软件来执行某些操作，则对其进行研究并收集建议系统的要求。

领域分析

每个软件都属于某个领域类别。该领域的专家可以极大地帮助分析一般和特定需求。

头脑风暴

在不同的利益相关者之间举行非正式辩论，并记录他们的所有意见以供进一步的需求分析。

原型设计

原型设计是在不添加详细功能的情况下构建用户界面，以供用户解释预期软件产品的功能。它有助于更好地了解需求。如果客户端没有安装供开发者参考的软件，并且客户端不知道自己的需求，则开发者根据最初提到的需求创建原型。将原型展示给客户并记录反馈。客户反馈作为需求收集的输入。

观察

专家团队访问客户的组织或工作场所。他们观察现有安装系统的实际工作情况。他们观察客户端的工作流程以及如何处理执行问题。团队本身得出了一些有助于形成软件与其需求的结论。

软件需求特点

收集软件需求是整个软件开发项目的基础。因此，它们必须清晰、正确和定义明确。

一个完整的软件需求规格必须是：

1、清楚的

2、正确的

3、一致的

4、相关的

5、可理解的

6、可修改的

7、可验证的

8、优先的

9、明确的

10、可追溯的

11、可信的信息来源

软件要求

我们应该尝试了解在需求获取阶段可能会出现什么样的需求，以及从软件系统中期望什么样的需求。

从广义上讲，软件需求应分为两类：

功能需求

与软件功能方面相关的需求属于这一类、

它们定义了软件系统的内部和来自软件系统的功能和功能性。

例子：

1、为用户提供搜索选项以从各种发票中进行搜索。

2、用户应该能够将任何报告邮寄给管理层。

3、用户可以分为组，组可以被赋予单独的权限。

4、应当遵守业务规则和行政职能。

5、软件开发保持向下兼容性完好。

非功能性需求

与软件功能方面无关的需求属于这一类。它们是用户假设的软件的隐含或预期特征。

非功能性需求，包括：

1、安全性

2、日志记录

3、存储

4、配置

5、性能

6、成本

7、互操性

8、灵活性

9、灾难恢复

10、可访问性

需求按逻辑分类为：

必须具备 : 没有它们，软件就不能说是可操作性的。

应具备 : 增强软件的功能。

可以有 : 软件仍然可以在满足这些要求的情况下正常运行。

愿望清单 : 这些需求并不映射到软件的任何目标。

在开发软件，'必须拥有'必须执行，“应该有”的争论与利益相关者和否定的问题，而“可能”和“愿望清单”，可以保持软件更新。

用户界面的要求

UI（User Interface，用户界面）是任何软件、硬件或混合系统的重要组成部分。一个软件被广泛接受，那么它是：

1、易于操作

2、响应快速

3、有效地处理运行错误

4、提供简单而一致的用户界面

用户的接受程度主要取决于用户如何使用软件。UI 是用户感知系统的唯一途径。一个性能良好的软件系统还必须配备有吸引力、清晰、一致和响应迅速的用户界面。否则软件系统的功能不能方便的使用。如果一个系统提供了有效使用它的方法，那么它就被认为是好的。下面简要提到用户界面要求：

1、内容呈现

2、轻松导航

3、简单的界面

4、响应迅速

5、一致的 UI 元素

6、反馈机制

7、默认设置

8、针对性布局

9、战略运用色彩和质感

10、提供帮助信息

11、以用户为中心的方法

12、基于组的视图设置

软件设计基础

软件设计是将用户需求转化为某种合适形式的过程，有助于程序员进行软件编码和实现。

为评估用户需求，创建了 SRS（软件需求规范）文档，而对于编码和实施，需要在软件方面有更具体和详细地需求。这个过程的输出可以直接用于编程语言的实现。

软件设计是 SDLC（软件设计生命周期）的第一步，它将注意力从问题域转移到解决方案域。它视图指定如何满足 SRS 中提到的要求。

软件设计水平

软件设计产生三个层面的结果:

架构设计：是系统的最高抽象版本。它将软件标识为具有许多相互交互的组件的系统。在这个层次上，设计者获得了提议的解决方案域的想法。

高层设计：将架构设计的“单实体-多组件”概念分解为子系统和模块的抽象视图，并描绘了它们之间的相互作用。高层设计侧重于如何以模块的形式实现系统及其所有组件。它识别每个子系统的模块化结构以及它们之间的关系和相互作用。

详细设计：处理在前两种设计中被视为系统及其子系统的实现部分。它更详细地介绍了模块及其实现。它定义了每个模块的逻辑结构及其与其他模块通信的接口。

模块化

模块化是一种将软件系统划分为多个离散且独立的模块的技术，这些模块有望独立执行任务。这些模块可以作为整个软件的基本结构。设计人员倾向于设计模块，以便它们可以单独和独立地执行或者编译。

模块化设计无意中遵循了“分而治之”的问题解决策略的规则，这是因为软件的模块化设计还有许多其他好处。

模块化的优势:

1、更小的元件更易于维护

2、程序可以根据功能方面进行划分

3、可以在程序中引入所需的抽象级别

4、高内聚的组件可以重复使用

5、可以实现并发执行

6、从安全方面期望

并发

回到过去，所有软件都应该按顺序执行。通过顺序执行，我们的意思是编码指令将一个接一个地执行，这意味着在任何给定时间只有一部分程序被激活。比如说，一个软件有多个模块，那么在任何时候执行时只能发现所有模块中的一个是活动的。

在软件设计中，并发是通过将软件拆分为多个独立地执行单元（如模块）并并行执行来实现的。换句话说，并发为软件提供了并行执行多个代码部分的能力。

程序员和设计师有必要识别那些可以并行执行的模块。

例如

文字处理器中的拼写检查功能是一个软件模块，它与文字处理器本身一起运行。

耦合和内聚

当一个软件程序被模块化时，它的任务根据一些特性被分成几个模块。众所周知，模块是为了完成某些任务而组合在一起的指令集，不过，它们被视为单个实体，但可以相互引用以协同工作，有一些方法可以用衡量模块设计的质量以及它们之间的交互，这些措施称为耦合和内聚。

内聚

内聚力是一种度量，用于定义模块元素内的内部依赖性程度。内距离越大，程序设计就越好。

有七种类型的内聚：

巧合内聚：它是无计划的和随机的内聚，这可能是为了模块化而将程序分解成更小的模块的结果。因为它是计划外的，它可能会给程序员带来混乱并且通常不被接受。

逻辑内聚：当逻辑上分类的元素被放在一个模块中时，它被称为逻辑内聚。

时间内聚：当模块的元素被组织成在相似的时间点进行处理时，它被称为时间内聚。

过程内聚：当模块的元素组合在一起时，它们按顺序执行以执行任务，称为过程内聚。

通信内聚：当模块的元素组合在一起，按顺序执行并处理相同的数据（信息）时，称为通信内聚。

顺序内聚：当模块的元素因为一个元素的输出作为另一个元素的输入而被分组时，它被称为顺序内聚。

功能内聚：被认为是最高的内聚力，值得期待。功能内聚中的模块元素被分组，因为它们都有助于单个定义良好的功能。它也可以重复使用。

耦合

耦合是一种定义程序模块之间相互依赖程度的度量。它告诉模块在什么级别相互干扰和交互。耦合度越低，程序越好。

有五个级别的耦合：

内容耦合：当一个模块可以直接访问或修改或引用另一个模块的内容时，称为内容耦合。

公共耦合：当多个模块对某些全局数据具有读写访问权限时，称为公共或者全局耦合。

控制耦合：如果其中一个模块决定另一个模块的功能或改变其执行流程，则两个模块称为控制耦合。

戳耦合：当多个模块共享公共数据结构并在其中的不同部分工作时，称为戳耦合。

数据耦合：是指两个模块通过传递数据（作为参数）进行交互。如果模块将数据结构作为参数传递，则接收模块应使用其所有组件。

理想情况下，没有耦合被认为是最好的。

软件开发测试

软件测试是根据从用户和系统规范收集的需求对软件进行评估，测试在软件开发生命周期的阶段级别或程序代码的模块级别进行，软件测试包括验证和确认。

软件验证

验证是检查软件是否满足用户要求的过程。它在 SDLC 结束时执行。如果软件符合它的要求，他就会被验证。

1、验证确保正在开发的产品是按用户的要求。

2、验证回答了这个问题 - “我们是否正在开发能够从该软件中满足用户所有需求的产品？"。

3、验证注重用户的需求。

软件确认

确认是确认软件是否满足业务需求的过程，并按照正确的规范和方法进行开发。

1、确认确保正在开发的产品是符合设计规范。

2、确认回答了这个问题 - “我们是否严格遵循所有设计规范来开发这个产品？"。

3、确认集中在设计和系统规范上。

测试的目标是：

错误：这些是开发人员所犯的实际编码错误。此外，软件的输出与期望的输出存在差异，被视为错误。

故障：当错误存在时发生故障。故障，也称为错误，是可能导致系统故障的报错结果。

失败：失败是指系统无法执行所需的任务。故障发生在系统存在故障时。

手动与自动测试

测试可以手动完成，也可以使用自动化测试工具：

手动 - 此测试是在不借助自动化测试工具的情况下执行的。软件测试人员为代码的不同部分和级别准备测试用例，执行测试并将结果报告给经理。

手动测试既费时又费资源。测试人员需要确认是否使用了正确的测试用例。测试的主要部分设计手动测试。

自动 - 该测试是借助自动化测试工具完成的测试过程。使用自动化测试工具可以克服手动测试的局限性。

测试需要检查网页是否可以在 Internet Explorer 中打开。这可以通过手动测试轻松完成。但是要检查网络服务器是否可以承受 100 万用户的负载，手动测试是完全不可能的。

有软件和硬件工具可以帮助测试人员进行负载测试、压力测试、回归测试。

测试方法

可以基于两种方式进行测试：

1、功能测试

2、实施测试

当在不考虑实际实现的情况下测试功能时，它被称为黑盒测试。另一方面被称为白盒测试，其中不仅测试功能，还分析其实现方式。

详尽的测试是完美测试的最佳方法。测试输入和输出值范围内的每个可能值。如果值的范围很大，则不可能在现实世界场景中测试每个值。

黑盒测试

执行它是为了测试程序的功能，它也被称为“行为”测试。在这种情况下，测试仪具有一组输入值和相应的期望结果。在提供输入时，如果输出与期望的结果匹配，则程序被测试为“OK”，否则就会出现问题。

在这种测试方法中，测试人员不知道代码的设计和结构，测试工程师和最终用户对软件进行这种测试。

黑盒测试技术:

等价类 - 输入被分成类似的类。如果一个类中的一个元件通过了测试，则假定所有类都通过了。

边界值 - 输入被分为较高端值和较低端值。如果这些值通过测试，则假定它们之间的所有值也可以通过。

因果图 - 在之前的两种方法中，一次只测试一个输入值。原因（输入） - 效果（输出）是一种测试技术，其中以系统的方式测试输入值的组合。

成对测试 - 软件的行为取决于多个参数。在成对测试中，对多个参数的不同值进行成对测试。

基于状态的测试 - 系统在提供输入时改变状态。这些系统根据它们的状态和输入进行测试。

白盒测试

它用于测试程序及其实现，以提高代码效率或结构。它也被称为“结构”测试。

在这种测试方法中，测试人员知道代码的设计和结构。代码的程序员对代码进行此测试。

以下是一些白盒测试技术:

控制流测试 - 控制流测试的目的建立涵盖所有语句和分支条件的测试用例。测试分支条件的真假，以便覆盖所有语句。

数据流测试 - 这种测试技术强调覆盖程序中包含的所有程序变量。它测试变量的声明和定义位置以及它们被使用或更改的位置。

测试级别

测试本身可以在 SDLC 的各个级别进行定义。测试过程与软件开发并行运行。在进入下一阶段之前，需要对一个阶段进行测试、验证和确认。

单独进行测试只是为了确保软件中没有隐藏的错误或问题。软件在不同级别上进行测试：

单元测试

在编码时，程序员对该程序单元执行一些测试以了解它是否没有错误。测试是在白盒测试方法下进行的。单元测试帮助开发人员确定程序的各个单元是否按要求工作并且没有错误。

集成测试

即使软件单元单独运行良好，也需要确定这些单元如果集成在一起是否也能正常工作。例如，参数传递和数据更新等。

系统测试

软件被编译为产品，然后作为一个整体进行测试。这可以使用以下一项或多项测试来完成：

功能测试 - 根据要求测试软件的所有功能。

性能测试 - 该测试证明了该软件的效率。它测试软件完成所需任务的有效性和平均时间。性能测试通过负载测试和压力测试来完成，其中软件在各种环境条件下处于高用户和数据负载下。

安全性和便携性 - 这些测试是在软件要在各种平台上运行并由多人访问时完成的。

验收测试

当软件准备交给客户就必须经过测试，它是用户交互和响应测试的最后阶段。这是很重要的，因为即使软件符合所有用户要求，并且如果用户不喜欢它的外观和工作方式，它也可能被拒绝。

Alpha测试 - 开发团队自己通过使用系统来执行 alpha 测试，就好像它是在工作环境中使用一样。他们试图找出用户将如何对软件中的某些操作做出反应以及系统应如何响应输入。

Beta测试 - 软件经过内部测试后，交给用户在生产环境下使用，仅供测试使用。这还不是交付的产品。开发者期望用户在这个阶段会带来细微的问题，这些问题被跳过了。

回归测试

每当使用新代码、特性或功能更新软件产品时，都会对其进行彻底测试，以检测添加的代码是否有任何负面影响。这称为回归测试。

测试文档

测试文档在不同阶段准备：

测试前

测试从测试用例生成开始，需要以下文件作为参考：

SRS文档 - 功能需求文档。

测试策略文档 - 这描述了在发布产品之前应该进行多远的测试。

测试战略文档 - 这提到了测试团队、责任矩阵以及测试经理和测试工程师的权利、责任的细节方面。

可追溯矩阵文档 - 这是 SDLC 文档，与需求收集过程相关。随着新需求的出现，它们被添加到这个矩阵中。这些矩阵帮助测试人员了解需求的来源。它们可以向前和向后追溯。

在接受测试时

在开始和进行测试时可能需要以下文档：

测试案例文档 - 本文档包含需要进行的测试列表。它包括单元测试计划、集成测试计划、系统测试计划和验收测试计划。

测试说明 - 本文档详细描述了所有测试用例和执行它们的过程。

测试案例报告 - 本文档包含作为测试结果的测试用例报告。

测试日志 - 本文档包含每个测试用例报告的测试日志。

测试后

测试后可能会生成以下文件：

测试总结 - 此测试总结是对所有测试报告和日志的集体分析。它总结并推断了软件是否准备好启动。如果准备好启动，该软件将在版本控制系统下发布。

测试与质量控制，质量保证和审计

我们需要了解软件测试不同于软件质量保证、软件质量控制和软件审计。

软件质量保证 - 这些是软件开发过程监控手段，通过它可以确保所有措施都按照组织标准采取。进行这种监视是为了确保遵循正确的软件开发方法。

软件质量控制 - 这是一个维护软件产品质量的系统。它可能包括软件产品的功能性和非功能性方面，从而增强组织的商誉。该系统确保客户收到符合其要求的优质产品，并且产品被认证为“适合使用”。

软件审计 - 这是对组织用于开发软件的程序的审计。独立于开发团队的审计员团队检查 SDLC 的软件过程、程序、要求和其他方面。软件审计的目的是检查软件及其开发过程是否符合标准、规则和规定。

软件运营与维护

如今，软件维护已被广泛接受为 SDLC 的一部分，它代表软件产品交付后所做的所有修改和更新。有很多原因，为什么需要修改，下面简要提到其中一些：

市场状况 - 政策随着时间的推移而变化，例如税收和新引入的约束，例如如何维护账本，可能会引发修改的需要。

客户要求 - 随着时间的推移，客户可能会要求软件中的新特性或功能。

主机修改 - 如果目标主机中的任何硬件或平台（如操作系统）发生变化，则需要更改软件以保持适应性。

组织变更 - 如果客户端有任何业务层面的变化，如机构实力下降、收购另一家公司、机构涉足新业务等，都可能需要对原有软件进行修改。

维修类型

在软件生命周期中，维护类型可能会根据性质而有所不同。它可能只是日常维护任务，因为某些用户发现了一些错误，或者它本身可能是基于维护规模或性质的大事件。以下是一些基于其特性的维护特性：

修复性维护 - 包括为纠正或修复问题而进行的修改和更新，这些问题要么由用户发现，要么由用户错误报告得出。

适应性维护 - 包括用于使软件产品保持最新并且适应不断变化的技术和商业环境世界的修改和更新。

完善的维护 - 包括为软件长时间可用而进行的修改和更新。它包括新功能、改进软件和提高其可靠性和性能的新用户要求。

预防性维护 - 包括为防止软件未来出现问题而进行的修改和更新。它旨在解决目前不重要但将来可能会导致严重问题的问题。

维护成本

报告表明，维护成本很高。一项关于估算软件维护的研究发现，维修成本高达整个软件流程周期成本的67％。

平均而言，软件维护成本占所有 SDLC 阶段的50％以上。有各种因素会导致维护成本升高，例如：

影响维护成本的现实因素

1、任何软件的标准年龄都被认为是10至15年。

2、旧的软件本来是要在速度较慢、内存和存储容量较少的机器上工作的，但它们无法与现代硬件上新出现的增强型软件相抗衡。

3、随着技术的进步，维护旧软件的成本越来越高。

4、大多数维修工程师都是新手，使用试错法来纠正问题。

5、通常情况下，所做的更改很容易损害到软件的原始结构，使其在后续的任何更改都很困难。

6、更改通常没有记录在案，这可能会在将来导致更多冲突。

影响维护成本的软件终端因素

1、软件程序结构

2、程序设计语言

3、对外部环境的依赖

4、工作人员的可靠性和可用性

维护活动

IEEE为顺序维护过程活动提供了一个框架。它可以以迭代的方式被使用，并且可以被扩展以便可以包括定制的项目和过程。

这些活动与以下每个阶段密切相关:

识别与跟踪 - 涉及与识别修改或维修要求相关的活动。它是由用户生成的，或系统可能通过日志或错误信息自行报告。在这里，维护类型也进行了分类。

分析 - 分析修改对系统的影响，包括安全和安保影响。如果可能的影响很严重，则寻找可替代解决方案。然后将一组所需要的修改具体化为需求规范。对修改/维护的成本进行了分析，得出估算结论。

设计 - 需要更改或修改的新模块根据前一阶段设定的需求规范进行设计。为验证和验证而创建测试用例。

实施 - 新模块在设计阶段创建的结构化设计的帮助下进行编码。每个程序员应该并行进行单元测试。

系统测试 - 在新创建的模块之间进行集成测试。在新的模块和系统之间也进行集成测试。最后，按照回归测试程序对系统进行整体测试。

验收测试 - 在对系统进行内部测试后，在用户的帮助下对其进行验收测试。如果处于这种状态下，用户会抱怨他们在下一次迭代中解决或注意到要解决的一些问题。

交付 - 验收测试后，系统通过小型更新包或新安装的系统部署到整个组织。最终测试在软件交付后的客户端进行。

除了用户手册的硬拷贝外，如果需要，还提供培训设施。

维护管理 - 配置管理是系统维护的重要组成部分。它是借助版本控制工具来控制版本，半版本或补丁管理。

软件再工程

当我们需要更新软件以保证它适应当前的市场，而不会影响其功能，我们称之为软件再工程。这是一个全面的过程，软件的设计会变更， 程序会被重新写入。

传统的软件无法使用市场上现有的最新技术进行调整。随着硬件的过时，软件更新成为一个头疼的问题。即使软件随着时间的推移而衰老，但是它的功能不会变老。

例如，最初的Unix是用汇编语言开发的。当C语言出现，Unix被重新设计为C语言，因为用汇编语言中的工作是困难的.

除此之外，有时程序员会注意到，软件的某些部分需要比其他部分更多的维护，它们也需要重新设计。

重组流程

1、决定重新设计什么，它是整个软件或其中的一部分?

2、执行逆向工程，以获得现有软件的规格。

3、如果需要的话，重新调整计划。例如，将面向函数的程序更改为面向对象的程序。

4、根据需要重新构造数据。

5、应用前沿工程的概念，以获得重新设计的软件。

还有在软件再工程中很少用到，但是很重要的几个术语：

逆向工程

这是一个通过深入分析，了解现有系统来实现系统规范的过程。这个过程可以看作是逆向的SDLC模式，即我们试图通过分析较低的抽象层次，以获得更高的抽象层次。

现有系统是以前设计的实现，对此我们一无所知。然后，设计师通过查看代码进行逆向工程，并尝试获得设计。有了设计，他们就会尝试总结出规范。因此，从代码到系统规范的顺序是相反的。

项目重组

这是一个重新构建现有软件的过程。这一切都是关于重新编排源代码，无论是用相同的编程语言，还是从一个编程语言到另一种编程语言。重组可以有源代码和数据重组，或两者兼而有之.

重组不会影响软件的功能，但提高可靠性和可维护性。经常导致错误的程序组件可以更改的，也可以通过重组来进行更新。

通过重组，可以消除过时硬件平台上软件的可靠性。.

正向工程

正向工程是通过逆向工程从手头的规范中获取所需软件的过程。它假设过去已经完成了一些软件工程。

正向工程与软件工程过程是一样的，只有一点区别就是，它总是在逆向工程之后执行。

组件的可重用性

组件是软件程序代码的一部分，它在系统中执行独立的任务。它可以是一个小模块或子系统本身。

示例

在Web上使用的登录程序可被视为组件，在软件中打印系统可以被看作是软件的一个组件。

组件具有较高的功能内聚和较低的耦合率，也就是说，它们相互独立，可以不依赖于其他模块的情况下执行任务。

在面向对象（OOP）中，设计的对象非常特定于它们所关注的问题，并很少有机会在其它软件中使用。

在模块化编程中，对模块进行编码以执行特定的任务，这些任务可以跨越多个其他软件程序使用。

有一种全新的垂直结构，这是基于软件组件的重用，被称为基于组件的软件工程（CBSE)。

可以在各个层次进行重用：

应用层 - 将整个应用程序用作新软件的子系统。

组件级 - 使用应用程序子系统的位置。

模块级 - 重复使用的功能模块的位置。

软件组件提供的接口，可用于不同组件之间建立通信。

再利用过程

可以采用两种方法：一是保持需求不变并调整组件，二是保持组件不变并修改需求。

需求规范 - 功能性和非功能性需求被指定，软件产品必须符合其中，与现有的系统中，用户输入或两者的帮助。

设计 - 这也是一种标准的SDLC过程步骤，其中要求在软件中用语的定义。系统的基本架构作为一个整体，其子系统中创建的。

指定组件 - 通过对软件的设计，设计师隔离整个系统分成较小的组件或子系统。一个完整的软件设计，变成了一组组巨大的协同工作的集合。

搜索合适的组件 - 软件构件库是由设计师称为搜索匹配元件，功能的基础上，拟软件要求上。

集成组件 - 所有匹配组件打包在一起，塑造他们作为完整的软件。