软件工程
 |
一位维基教科书用户认为此页面应该拆分为更小的页面，内容更窄。 您可以通过将此大页面拆分为更小的页面来提供帮助。请务必遵循命名策略。将书籍分成更小的部分可以提供更多的关注度，并允许每个部分专注于一件事，这对每个人都有利。 |
与其他书籍重叠：软件工程导论
这本书的目的是将不同软件工程主题的不同项目结合在一起。目前唯一链接的书籍是计算机编程。其他主题应该随着时间的推移而被添加。
正如计算机编程书中所写，编码只是软件工程的一小部分。本书旨在作为软件工程领域的入门介绍。
一种系统的方法，用于分析、设计、实现和维护软件。
软件工程是开发软件的工程学科。通常，这个过程包括找出客户想要什么，将其整理成一份需求清单，设计能够支持所有需求的架构，设计、编码、测试和集成各个部分，测试整体，部署和维护软件。编程只是软件工程的一小部分。
作为工程学科，该学科仍处于起步阶段（增长/发展早期阶段）。我们还没有足够的经验，也没有收集到足够多的经验数据来系统地理解和预测软件项目的生命周期。
软件工程知识体系（SWEBOK）将软件工程分为10个知识领域
- 软件需求
- 软件设计
- 软件构建
- 软件测试
- 软件维护
- 软件配置管理
- 软件工程管理
- 软件工程过程
- 软件工程工具和方法
- 软件质量
注意：以下总结最初来自维基百科。这些只是暂时在这里。标题不是最终的，此页面上的任何内容都不是最终的（甚至接近最终的）。
在企业或工业部门中，软件工程的实践始于业务，并以业务结束。虽然计算机、编程语言和创造性问题解决是工程师对该领域感兴趣的原因，但如果没有服务和赋能用户，这种练习将毫无意义。因此，任何软件工程过程的第一阶段都是愿景和范围文档，或一些类似的会议。
用户或产品负责人描述了要构建的系统的愿景。它将服务于的业务环境被描述。列出了主要利益相关者，包括他们的利益、风险等。列出了成功条件，以便了解将完成什么以及如何衡量成功。
讨论了商业机会，以证明为什么要将程序员、测试人员、项目经理和项目经理的血汗和眼泪投入到这个项目中。项目的范围变得清晰，如果它要分阶段进行，则高层次地列出了每个阶段的范围。记录了项目的优先级。
了解了企业的愿景后，工程师开始提问。
提取所需软件产品的需求是创建它的第一步。这个过程被称为需求获取。虽然客户可能认为他们知道软件应该做什么，但它可能需要软件工程方面的技能和经验来识别不完整、模棱两可或矛盾的需求。
加剧这个问题的是正式抽象的缺乏。土木工程师、机械工程师有平面图、立面图、剖面图可以参考，这些图对这些抽象的作者和读者都有意义。然而，虽然（E-R）或对象图、流程图、数据流图是已被使用和构建的抽象，但其中许多并不被普遍使用或实践。
此外，大量的精力用于修复和增强现有系统。这里所需的工程是逆向工程和正向工程的混合，因为需求定义指的是一组已经存在的情况，而这些情况必须以明确的术语陈述。
也许，缺乏普遍接受的抽象使得软件工程师的生活变得困难，有些人甚至认为软件生产过程更接近艺术而不是工程！
最近，人们开始在不同程度的工作中使用原型。屏幕截图和报表布局是非工作原型，构成了原型制作的基本级别，并在可能的情况下内置了越来越高的复杂性。制作原型总是比不制作更费时。因此，这种做法并不总是被使用。
分析师的角色通常可以由三种类型的人来扮演。技术项目经理、软件工程师或专门的分析师。在某些组织中，工程师认为他们会担任分析师的角色是不可想象的，因为他们是“技术性的”，并且认为直接与客户打交道是不可想象的。这纯粹是一种文化立场，在公司和组织之间有所不同。软件工程师与项目相关的业务人员和客户密切合作也很常见，而这种程序员/分析师角色对项目的成功率非常有利。
在收集需求时，可以对它们进行分析。所讨论的需求是否与其他需求冲突？它的优先级是什么？它从哪里来？它是否需要进一步澄清？
分析是指从需求中推断出结论，并以结构化的方式进行表示。结构本身可能根据分析对象的差异而有所不同。分析与需求收集之间很难划清界限，因为它们在很多时候都使用相同的抽象概念。
有人可能会认为，分析会产生数据存储结构和工作流程结构等等。然而，人们会认为这些并非是分析的唯一产出。
常见的技巧是，软件需求分析从两个或多个参与者之间的沟通开始。软件开发人员和客户都参与对软件需求规格说明的评审。由于规格说明为设计和后续软件工程活动奠定了基础，因此在进行评审时应格外谨慎。评审首先在宏观层面进行。在这个层面上，评审人员试图确保规格说明完整、一致和准确。一旦评审完成，软件需求规格说明就会由“客户和开发人员双方”签署。
在需求分析阶段，会遇到一些问题。这些问题被识别、定义并列在这里。• 问题出在较小的系统中存在的问题，导致对开发软件所涉及的活动优先级重新定义。• 在需求阶段的开始，客户的需求存在于客户组织中不同人员的脑海中。• 问题陈述的主要作用是客户存在一个可能需要计算机解决方案来解决的问题。开发人员响应客户的帮助请求。这里还有一个问题是，从沟通到理解的路径往往充满了困难。
上述案例研究/问题是在“系统工程”中需求分析阶段确定的。此页面很快就会得到改进。--Ananthakumar Selvaraj (讨论 • 贡献) 2013年3月18日 (UTC) 13:02
一旦工程项目的愿景和范围确定，需求收集过程就开始了。用例集是客户、分析师、开发人员和测试人员之间沟通的工具之一。用例通常具有名称、简短描述，以及用户完成任务所需的步骤集。用例有时会分组在UML或其他形式的图表中，描绘用户、系统、外部实体和特定用例。
用例通常是粗粒度的，不会深入到系统的每个细节和功能需求。业务人员或软件工程师应该能够阅读所有用例，并了解项目将交付的整个范围。
敏捷驱动的项目可能会跳过这些用例，或者至少只记录上面讨论的属性。计划驱动的 методология 可能会为用例添加其他属性，例如在涵盖主要步骤后的备选路径、将用例涵盖的需求追溯到其来源，以及为每个用例提供错误处理部分。
分析阶段
分析通常分两个阶段进行。第一阶段，业务分析包括深入分析客户当前的业务或制造流程和程序，着眼于如何通过自动化改进这些流程和程序。第二阶段，系统分析包括对拟议改进进行审查，并就最适合完成这些改进的计算机环境和软件技术提出建议。
业务分析阶段
从对客户当前环境的深入理解出发，业务分析师会创建一套“业务用例”，它们是简要描述每个业务“参与者”在每个流程或程序中所扮演角色的描述。例如，餐厅的服务员可能有一个用例，如下所示：“A. 服务员走到顾客的桌子旁，自我介绍并背诵当天特价菜的介绍。B. 服务员递送饮料菜单，询问顾客是否要点饮料。C. 如果是，服务员将每个顾客的订单写在饮料标签上，然后前往酒吧区。D. 服务员将标签递给酒吧招待员，并在心中记下在正常时间内回头查看饮料订单是否已经完成。E. 如果不是，服务员递送晚餐菜单，并帮助顾客进行选择。当每个新的顾客就座时，服务员重复上述步骤，从步骤A开始。” 借助像上面这样的原始用例集，业务分析师可以与客户协作，检查每个用例如何实现自动化，并由此定义一个正式的系统需求，这个需求将成为定义未来软件应用程序的数百个需求之一。可以推测，有效的业务分析师不仅要拥有丰富的商业世界经验和知识，还要精通现代软件系统提供的潜力，以及这些系统如何映射到商业世界的现实。
系统分析阶段
分析过程的第二阶段，系统分析从业务分析师奠定的基础开始。从业务用例集及其产生的软件需求出发，系统分析师会就最适合完成这些需求的软件技术提出建议。在某些情况下，硬件环境会限制软件技术的选择。例如，在上面的餐厅场景中，客户可能坚决要求为服务员提供手持设备，以取代饮料标签，并在饮料订单准备好之前，无需跑到酒吧区。在这种情况下，系统分析师可能被迫使用仅在首选手持设备上支持的操作系统和API。
一旦确定了编程和运行时环境，系统分析师就可以开始将业务用例和需求转换成“系统用例”集，这些用例描述了参与者如何与拟议的系统交互。这些系统用例共同构成了软件架构师用来开始布局类或其他软件模块的实际蓝图，这些模块将定义软件编码和开发过程的路线图，该过程将紧随其后。
规格说明是精确描述要编写的软件的任务，以数学上严格的方式进行描述。实际上，大多数成功的规格说明都是为了理解和微调已经开发得很好的应用程序而编写的。对于必须保持稳定的外部接口，规格说明是最重要的。
一旦您收集了需求，并将它们捕获到规格说明中，并且客户同意该规格说明，就可以对项目需求进行快照或基线。这样就可以管理现有需求并处理新需求。规格说明被置于配置管理下，例如像CVS这样的工具，以便可以对需求进行版本控制和跟踪。
拒绝不符合以下条件的需求非常重要：
- 不符合项目范围
- 无法显示投资回报率
- 不会使系统具有竞争力
- 技术上不可行
被拒绝的需求不需要进一步分析、实施、记录或测试。每个需求都会给公司带来成本，必须经过深思熟虑。
无论您的方法是敏捷还是计划驱动，您都应该创建某种形式的变更控制来处理新的需求。如果未能做到这一点，可能会导致项目因范围蔓延、项目超支、质量低下或成本过高而失败。变更控制可以像开发经理审查规范一样简单，也可以像一个复杂的工具支持流程一样复杂，该流程包含表格和具有变更控制权的委员会。
缺乏关于规范变更的沟通会导致开发人员、测试人员或分析人员浪费大量成本。在规范中更改一项需求所需的时间，其成本可能是实现该决定的工作时间的 100 倍。
设计与架构是指定软件如何实际工作的活动。此阶段通常被描述为分为两个主要阶段，可以描述为“业务设计”和“技术设计”。业务设计通常指定系统的“为什么”，说明如何使用数据以及数据的流向。技术设计通常指定系统的“如何”，即其组件如何排列、其功能是什么以及系统需要什么样的硬件。这两个阶段通常可以大致同时进行，业务设计通常先开始，技术设计最后结束。
在所有阶段中，设计阶段通常会占用最多时间，许多工程师认为它是最重要的阶段。即使在项目构建阶段花费大量资源后，设计不良也会导致项目失败。对于系统的设计和架构，必须做到足够完整，以便可以对其进行验证，然后将其用于开发系统。
将设计转换为代码可能是软件工程过程中最明显的步骤，但它不一定是最大的部分。事实上，许多软件工程师只参与分析和设计过程，然后将编码工作交给计算机程序员来实现。这种趋势在许多公司中越来越明显，这些公司在国内雇佣软件工程师，然后将实施工作外包给编程劳动力成本更低的国家。尽管有这种趋势，许多软件工程师仍然会经历整个过程，并进行编码以及设计。
测试的目的是不仅要证明代码按设计规范执行，还要证明代码在遇到未定义输入时不会失败。
有几种类型的测试。单元测试测试一个代码模块的正确输入、输出和功能。系统测试测试软件系统的所有模块。用户验收测试是一种系统测试形式，用于查看系统不仅是否正常工作，还是否满足业务用户的需求。回归测试是在系统更改后进行的测试，以确保所有系统功能在更改后仍然存在。
为了执行系统和验证测试，开发了用例。这些用例描述了用户操作或系统的特定功能。这些用例在系统的构建阶段非常有用，通常被指定为设计阶段的可交付成果。用例通常被收集到测试脚本中，这些脚本以可复制的方式描述测试活动。这些脚本可以由测试人员手动执行，也可以由自动测试软件执行。
一般来说，行业惯例是系统测试和验证由独立的人员、团队或部门，或者在某些情况下，由外部实体进行。测试被认为是一项专业技能，其技能组合与系统开发大不相同。通常认为，软件开发人员测试自己的系统是一种不好的做法，因为他们可能会形成不全面测试系统的习惯，并且他们经常会绕过系统故障进行测试。
有不同类型的测试，例如白盒测试或黑盒测试。
一项重要的（而且经常被忽视的）任务是记录软件的内部设计和外部功能，以便于将来的维护和增强。
软件文档非常重要。没有文档，软件将无法使用，因为最终用户不知道如何操作程序。没有文档，应用程序可能无法正确安装在服务器上，导致组件故障。文档对于外部接口最为重要。
软件可以通过多种方式进行记录，包括流程图、部署指南、用户手册和维护手册。
开发团队成员可以编写自己的文档，或者专业的技术作家可以编写或编辑文档以提高可读性和风格。
需要注意的是，测试应该在每个阶段的结束时或期间进行。如果没有做到这一点，传递到下一阶段的输入可能不完整。文档也可能不完整或不存在。
维护和增强软件以应对新发现的问题或新需求，可能比最初开发软件花费的时间要长得多。不仅可能需要添加不符合原始设计的代码，而且在软件完成后的某个时刻确定软件是如何工作的，可能需要软件工程师付出相当大的努力。大约 2/3 的软件工程工作是维护，但这一统计数据可能会产生误导。其中一小部分是修复错误。大多数维护都是扩展系统以执行新功能，从许多方面来说，这可以被视为新工作。同样，大约 2/3 的土木工程、建筑和施工工作也是以类似的方式进行维护。
软件工程过程因软件类型而异。构建文字处理器与构建 3D 第一人称射击游戏有不同的需求和设计方法。这些部分涵盖了不同软件类型的差异和独特属性。
服务器软件的软件工程比台式计算机的开发更加复杂。服务器比普通消费系统更加复杂，具有更多需求和功能。服务器软件可以具有客户端-服务器架构以及集中式架构。服务器软件的开发和测试也与台式软件的开发和测试不同。并非每种编程语言都适合用于服务器软件的实现。总之，服务器软件中的 SE 需要特殊的
服务器软件比普通软件更复杂的主要原因是，两台计算机（服务器和客户端）之间的通信本身比同一台计算机上运行的程序的各个部分之间的通信更复杂且更容易出现故障。
为游戏模拟设计软件可能颇具挑战，因为它需要软件领域的丰富背景。例如，游戏设计师可能需要编写模拟物理的软件，以及渲染三维图像的软件。然而，游戏行业的许多软件工程师能够使用第三方引擎，这使得他们的工作变得更加容易。尽管如此，他们必须严格遵循软件工程流程，因为软件中微小的错误可能会导致产品在消费者市场上失败。为游戏编写软件是一个高风险行业，只有少部分游戏在经济上取得成功。
与嵌入式计算机系统打交道的软件工程师需要比大多数软件工程师更了解硬件，因为与游戏 PC 相比，嵌入式系统通常对内存可用性和处理能力有更多限制。为嵌入式系统设计软件确实可能具有挑战性，因为大多数嵌入式处理器无法处理编译高级语言产生的开销。这经常迫使软件工程师至少部分地在汇编语言中实现嵌入式软件。