A-level 计算机科学/WJEC（Eduqas）/组件 1/系统分析
瀑布模型采用线性方式进行软件开发，并在每个阶段结束时产生“可交付成果”。该方法之所以得名，是因为开发的本质就像天然瀑布一样，一个阶段必须完成才能进入下一个阶段——而且您也不能向上移动一个阶段，必须从头开始。在这个过程中，对文档的明确重视是显而易见的，因为在每个阶段，您都必须生成这些“可交付成果”。
优点
- 可交付成果可以向客户展示，以便告知他们项目进度。
- 由于每个阶段都有截止日期，因此整个过程都保持着纪律感。
- 必须在开始工作之前考虑需求。
缺点
- 使用这种方法交付项目需要很长时间。
- 缺乏灵活性——您不能随意遍历各个阶段，必须按照严格的顺序进行。
- 即使市场上出现了新的创新，您也不能在后期更改项目。
- 任何错误/遗漏的问题都意味着您需要完全重新开始项目。
- 在开始开发之前，几乎不可能掌握需求。
敏捷方法将更多控制权交给了开发人员，而不是专注于客户。开发人员被信任找到问题的解决方案并编写代码，在获得执行此操作的资源后，例如通常安装有 Visual Studio 的功能强大的 PC。开发人员通常被分组为团队，并被赋予实施解决方案的一部分，这些团队会与客户会面并详细讨论他们的需求。
优点
- 敏捷方法认为，您无法在项目开始时就了解所有需求。
- 该项目非常灵活，因为计划可以更改。
缺点
- 许多人不喜欢结对编程。
- 不了解这种方法的客户会不喜欢缺乏文档。
- 人们以冲刺的方式工作，这意味着代码通常是意大利面条代码。
在敏捷宣言中，我们重视“个人和互动高于流程和工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，对变化的响应高于遵循计划”。
极限编程：在这种情况下，开发人员必须与彼此和其他团队以及客户进行沟通。应采用最简单的解决方案，并由他人提供反馈，例如在结对编程中。
Scrum：以尽可能快的方式创建定期原型。这些原型在称为“冲刺”的特定时间段内生成。由于人们在多个领域以团队形式工作，因此会举行称为“每日站立会议”的会议，以讨论进度并为他人提供建议。
利益相关者：对新系统感兴趣的人。他们要么是构建该系统并获得报酬的人，要么是为该系统付费的客户。
用户：使用新系统的人，例如使用购物网站的人。
程序员/开发人员：构建系统的人。
项目经理：通过将开发人员分配到项目的不同部分并监控他们的进度来协调项目的完成。他们可以根据自己的技能进行调动，而拥有更高技能的人可以从事原来的工作领域。
系统分析师：找出客户在新系统中想要什么。这是通过各种事实调查方法完成的，因为大多数客户并不知道他们到底想要什么，或者没有提供关于系统已包含哪些数据的足够信息。
客户和开发团队将举行会议并讨论项目的范围——需要做什么以及当前系统的限制是什么。客户可能对可以完成的事情以及新系统必须包含哪些数据过于乐观，这就是我们举行会议并决定问题范围的原因。问题定义可能是设计一个新的系统，因为他们的旧系统不符合他们当前的业务目标，或者使用新的网站或移动应用程序扩展系统。
可行性研究旨在评估在开发公司有限资源（资金、时间、技术能力和声誉）的情况下，解决方案是否可行。
经济方面
[edit | edit source]承接项目的公司资金有限，因为他们需要雇用开发人员以及办公场所，而办公场所也存在支出：Visual Studio 许可证、计算机、开发人员薪资、办公场所费用（电费、燃气费、租金等）。公司还希望获得一些利润，这些利润可能与开发人员分成，也可能不分成。
时间限制
[edit | edit source]每天只有这么多小时，开发人员从早上 9 点到下午 5 点工作，这意味着只有这些时间可用于项目。项目经理必须计算完成项目的所需时间，然后决定是否继续进行 - 延期项目会面临处罚，甚至可能面临法律诉讼。客户希望在截止日期前完成项目，这需要与完成项目所需的时间进行核对，以计算时间可行性。
技术方面
[edit | edit source]开发人员不是神，他们只能掌握有限的编程语言，只阅读过一些文档，并不熟悉每一个系统实现。通过技能评估，公司可以了解开发人员的技能水平。另一个问题是，客户可能要求一些目前技术上不可行的东西，例如薄型 VR（虚拟现实）眼镜。
政治方面
[edit | edit source]一些系统由于政治环境恶劣而无法实施，例如道德选择系统、医疗保健系统、产品测试系统。如果系统在政治上不正确，将影响公司的声誉。
法律方面
[edit | edit source]提议的系统可能违反其原产国的一些法律。因此，该系统不能被认为是法律上可行的。这很难做到，例如公平使用法和分享文件/制作评论视频，这些视频可能会被自动系统错误地标记。据报道，YouTube 因其内容识别系统错误标记视频而面临强烈反对。
分析
[edit | edit source]分析是通过各种事实调查方法，如访谈、问卷调查、文件收集和观察，收集有关新系统需要具备的功能的详细信息的过程。
问卷调查
[edit | edit source]问卷调查也称为调查，包含与系统相关的问卷。如果员工分布在广泛的地理区域或人数众多，这种方法很有用。
优点
- 对于大量人群来说，制作成本相对较低。
- 可以收集广泛的观点。
- 大量的（可能非常丰富的）细节。
- 可以分布在全球许多公司地点。
- 可以在线完成，因此结果可以很快获得。
缺点
- 问卷必须由专家设计，否则信息可能无法使用。
- 人们可能“太忙了”，可能不会完成问卷。
- 人们可能不会给出正确答案。
访谈
[edit | edit source]访谈是指利益相关者与系统分析师之间的一对一讨论。当分析师需要从少量人那里获取大量信息时，这种方法很适合。
优点
- 可以收集大量详细的信息。
- 可以通过个人接触或肢体语言判断信息的有效性。
- 访谈对象将是利益相关者，因此会积极配合回答问题。
- 可以进行后续问题，这与其他分析方法不同。
缺点
- 耗时且成本高。
- 必须由经过培训的访谈员或专家撰写的封闭式问题进行。
- 难以分析大量信息。
- 难以分析各种信息。
文件收集
[edit | edit source]文件收集涉及收集各种公司文件，例如发票、税收收据、员工记录、公司电子表格等。这种方法适合调查当前的数据存储需求和数据流。
优点
- 团队可以了解系统当前的运行方式。
- 一种廉价且快速收集大量信息的方法。
- 可以确定系统的存储需求。
缺点
- 员工可能没有按照文档中列出的程序进行操作，而是以自己的方式使用系统。
- 信息可能高度机密，系统分析师可能无法获得。
- 文档可能已过时，没有更新以反映对系统的更改。
观察
[edit | edit source]观察是指观察某人进行日常工作，通常称为“跟班学习”。这种方法适合直接收集信息。
优点
- 了解问题定义中遗漏的细节。
- 验证其他找到的信息。
- 可以实际了解正在发生的事情，不依赖于其他人告诉您他们认为正在发生的事情。
缺点
- 非常耗时且成本高。
- 员工可能会因为被观察而感到受到威胁，因此行为可能与他们的日常行为不同。
- 派遣分析师到全国各地会产生费用。
需求
[edit | edit source]需求是系统为了交付给客户而必须满足的具体目标。这在法律意义上很重要，这样公司可以证明它提供了客户要求的内容，但在另一个意义上，它可以将项目保持在范围内。需求包括三个方面，所有这些方面都必须是可衡量的，以满足法律/范围要求：界面、功能和性能。
界面
[edit | edit source]界面需求是系统如何与用户交互的可衡量标准。以视频流网站 Twitch 为例。用户交互将通过用户点击鼠标按钮来触发流加载。在规范中，我们感兴趣的是可衡量的标准，这将被称为“网站必须可供所有类型的计算机用户使用鼠标访问，以及可供使用触屏的移动用户访问”。我们不关心他们在游戏鼠标上有多少个按钮，而是左键单击可以用来与网站交互，这意味着界面需求将得到满足。
功能需求详细说明系统应该具备的功能。继续以Twitch为例，一些功能需求可能是“订阅系统，用户每月支付费用并获得奖励”，或者简单地“视频必须在交互时加载相应的流”。这两种方法都可以用多种方式实现，但仅仅拥有功能就足以满足需求。
性能需求只涵盖系统在使用时的速度。Twitch在良好的宽带连接下相当流畅，也许它的性能需求是“在5秒内加载视频流”。这绝对是可衡量的，如果流确实在那么快的时间内加载，那么这个性能需求就达到了。
需求规格说明书，通常称为“规格说明”，概述了新系统的生产及其内容。其内容因公司而异，但它们都严格遵循自己的规格说明模板。这可能包括：目的、范围、功能/界面/性能需求、产品功能、约束和问题。可以在伊利诺伊大学查看一个示例模板。
设计决定了系统的外观以及数据如何在系统中输入和处理。只有在需求规格说明书完成后才能创建最终设计。设计应考虑可用的硬件/软件，例如网站或游戏、数据结构设计、输入（即数据如何进入系统）和输出（即数据在读取出系统时如何呈现）。
数据结构设计以图表形式展示数据如何在系统中表示。分析阶段收集的所有数据将被组织成字段并放置在数据字典中。
| 名称 | 类型 | 大小 | 描述 | 示例 |
|---|---|---|---|---|
| 姓 | 文本 | 64 个字符 | 学生的姓。 | Bob |
| 名 | 文本 | 64 个字符 | 学生的姓。 | Ross |
| 年龄 | 数字 | 3 个字符 | 学生的年龄。 | 13 |
| 年级 | 文本 | 2 个字符 | 学生获得的年级。 | A* |
在构建数据字典后，选择存储方法，最常见的是某种形式的数据库。
我们可以使用多种技术来解决问题，但你需要了解其中的两种技术：抽象和分解。
抽象是指为一个过程命名。也许你可以在编程的意义上理解它 - 在你的代码中解决问题的许多方法，一旦你解决了它，你可能会将解决方案放在一个函数中，这样你就可以在需要的时候调用它。这就是对问题进行抽象。
如果你仍然不理解，请查看这个详细的StackOverflow 答案。
分解是指将一个问题分解成更小、更可实现的部分。分解的一个很好的例子是在面向对象编程中，其中每段数据都被分解成各种不同的对象。
为了理解系统中的数据流，通常最好构建系统的图表表示以供参考。你需要了解三种图表：实体关系图、流程图和数据流图。
实体关系图 (ERM) 用于表示数据库，显示哪些表相互关联以及以何种方式关联。有三种类型的关系：一对一、一对多和多对多。每个链接表示两个条目（数据库表）之间的关系。
数据流图 (DFD) 显示信息如何在系统中处理。将有一系列流程，系统将根据“外部实体”对系统的交互来执行这些流程（外部实体是任何与系统交互的人）。当运行一个进程（在系统中执行一个操作）时，将需要数据，这些数据可以从“数据存储”中获取。数据存储是任何存储数据的实体，通常是数据库。例如，以电影院为例，员工将作为外部实体与系统交互，流程将预订门票，而数据存储将存储谁购买了哪张门票、他们的支付信息以及他们观看电影的屏幕。
本节内容将很快补充完善。
在将项目交付给客户之前，测试始终至关重要。它确保系统按预期工作，并且系统中没有错误或严重错误，这在实时业务环境中可能至关重要。开发人员需要其他人测试项目，因为每台计算机都不同，因此系统可能无法在其他计算机上正常工作。
白盒测试由原始开发人员以及内部的其他开发人员进行。代码对任何测试人员都是完全可见的，因此名称中的“白色”来自代码清晰可见。在白盒测试中，运行每个可能遇到的路径。一个简单的 IF this THEN do that ELSE do this，有两条路径 - 一条是条件满足，另一条是条件不满足。
黑盒测试外包给其他专门测试程序的公司，或者由其他对代码一无所知的人进行。“黑色”来自代码对测试人员隐藏的事实。测试系统的每个元素以查看每个路径在正确或不正确的情况下是否产生正确的输出。
Alpha 测试是在系统开发过程中进行的，此时系统尚未完工，缺乏很多功能或无法正常工作。这些版本**绝不会**提供给客户，因为他们会认为这就是最终交付的产品。这种类型的测试由公司内部员工进行，以测试系统的功能。
Beta 测试是在系统接近完成时进行的，此时系统已经具备了所有功能，并且是在 Alpha 测试之后进行的。这项测试通过将系统发布给公司外部的有限用户群体来进行，并记录他们的反馈意见。Beta 版本中通常会有一些小问题。
单元测试是完全自动化的测试，它以定期的时间间隔运行，将一些测试条件输入系统，以查看是否产生了相关的输出。由于代码是单独开发然后插入到主系统中的，因此新插入的代码很可能破坏旧代码，这就是进行单元测试的原因。单元测试的原始开发人员创建了需要通过的测试，才能将代码更改接受到主系统中。
最终用户测试由最初请求系统的客户进行。他们使用真实数据测试系统，并检查需求规格说明，确保双方都满意地履行了自己的承诺。客户将拥有完整的系统，而开发公司将获得报酬。
验收测试由客户或最终用户进行，以证明系统正常工作。
直接切换，也称为“大爆炸”切换，是指突然用新系统替换旧系统。当系统故障不会对企业造成灾难性后果时，可以使用这种方法，但当系统故障会导致人员伤亡或巨额损失时，则不能使用这种方法。这种方法实施成本低廉，因为没有额外的员工成本，但如果系统故障，企业将没有系统可用，这可能会很危险或造成损失。
分阶段切换是指逐步引入新系统，每次引入一部分新的功能。这种方法适用于企业中有多个部门的情况。如果新系统出现故障，员工可以恢复使用旧系统。由于会有更多的专家在手，因此问题可以很快得到解决。一个区域的问题也可以在下一个区域中得到修复，以免在实施系统的下一个部分时造成问题。但这种切换方法可能会在切换期间造成问题，因为员工需要使用两个不同的系统并相互沟通。
试点切换是指在企业的某个部分实施系统，因此适用于多个分支机构/办事处，可以在单个分支机构/办事处推广。如果新系统在该办事处出现故障，其他办事处将继续正常运作，因此故障不会造成灾难性后果。在一个区域发现的问题可以在下一个区域中得到修复，以免在所有分支机构/办事处推广时造成任何问题。但这种方法可能会造成问题，因为员工需要使用两个不同的系统并相互沟通。例如，这种方法可以用于单个超市分店。
并行切换是指两个系统同时运行一段时间。这是四种切换方法中最安全的一种，因为如果系统出现故障，企业仍然可以使用旧系统正常运作。这种方法可能很昂贵，因为可能需要额外的员工在两个系统上输入数据，或者现有的员工加班才能同时操作两个系统。这可能会给客户和企业的员工带来混乱。这种方法适用于关键系统，例如银行机构使用的系统。
系统文档是为系统开发内部使用以及系统用户编写的，以便他们了解系统的运作原理以及如何使用系统。
用户文档帮助用户了解系统的用户界面 (UI)，并展示如何使用系统完成许多常见的任务，以及每个按钮的功能，并解释系统中每个元素的含义。文档必须使用通俗易懂的语言，以便普通用户能够理解，并且能够完成系统可以执行的任何任务。
必须编写维护文档，因为系统不可避免地需要进行一些更改，因为企业会发生变化，社会也会采用新的设计语言。系统维护人员需要能够理解系统，他们将是技术娴熟的，而这些文档将对他们具有相关性。系统可能需要完全迁移到另一个数据中心，而维护文档中的安装部分将在这种情况下具有相关性，记录如何设置数据库，安装 nginx/apache 等 Web 服务器，等等。其他部分可以包括：数据结构，算法流程图，数据字典，内部文档（如设计文档）以及最低系统要求，例如 RAM、CPU 能力、所需驱动器空间。
在系统的生命周期中，将需要进行各种类型的维护。
这是在使用系统时发现错误时所需的维护。纠正性维护的一个例子是，当发现错误（例如错误的计算）时，需要修改计算以生成正确的结果。
当系统必须进行调整以适应新的法律或环境时，需要进行适应性维护。适应性维护的一个例子是，当程序必须进行修改以在新操作系统上运行时，例如，在 Windows 上运行的桌面应用程序必须进行修改以在移动电话上运行。或者法律的变化，例如，增值税税率从 20% 上调到 25%。
当系统的性能必须得到提升时，需要进行完善性维护。完善性维护的一个例子是，当程序的性能得到改进时，例如，修改搜索算法以更快地生成结果。
• 需求：评估原始需求是否应该得到满足，以使解决方案取得成功。
• 成本 – 包括财务成本、人力成本和资源成本。解决方案必须不超过任何预算成本。
• 鲁棒性 – 根据测试结果进行评估。应使用错误捕获和验证方法来提高鲁棒性，并减少系统错误和故障的可能性。
• 可用性 – 根据最终用户使用解决方案的难易程度进行评估。解决方案应使用直观的用户界面，适合最终用户使用以取得成功。
• 性能 – 针对内存使用和处理速度进行评估
备份是指将一个存储区域中的文件复制到另一个独立的存储区域的过程。数据备份和恢复主要有两种策略，第一种是
- 将数据复制到便携式介质上，例如 USB 闪存驱动器或外部硬盘驱动器。
- 这应该定期进行，例如每周或每月一次。
- 介质应存放在另一个位置，在防火/防水保险箱中。
- 如果发生灾难，数据可以复制回新的硬盘驱动器/SSD。
第二种方法是使用“云存储”
- 数据应上传到第三方。
- 这应该定期进行，例如每周或每月一次。
- 数据物理存储在第三方站点（其数据中心）。
- 如果发生灾难，数据可以复制回新的硬盘驱动器/SSD。