单元 1.2.3 软件开发
这是一个众所周知的模型，它由一系列阶段组成，每个阶段只有在完成前一个阶段后才能开始。如果需要，也可以返回模型中的上一步。所涉及的阶段是
- 问题定义
- 可行性研究
- 分析 (包括系统调查/信息收集)
- 设计
- 评估
- 安装
- 维护
在分析人员开始设计和构建系统之前，必须仔细识别问题。这是因为
- 客户可能不知道计算机系统的功能。
- 分析人员可能不知道问题领域的来龙去脉。
- 它确保解决的是正确的问题。
- 它确保创建的解决方案满足客户的需求。
- 它将确定项目的结束时间，从而确定付款时间。
这项研究使用 TELOS（技术、经济、法律、运营和进度安排）来确保项目能够完成
- 技术 - 是否有技术可用于解决问题？
- 经济 - 项目在经济上可行吗？
- 法律 - 问题是否可以在法律范围内解决？
- 运营 - 是否有足够的人员来运行新系统，这对客户有何影响？
- 进度安排 - 问题是否可以在时间限制内解决？
其他因素可能包括社会或环境影响。
这项研究将产生一份可行性报告，其中详细说明了用户需求、现有软件和硬件、当前系统范围、主要数据处理功能和流程、成本效益分析以及结论和建议。
分析包括理解当前系统、新系统的需求、提出新系统和新系统的规格。
这种技术包括尽可能多地了解当前系统的功能。它可以通过多种方式完成
- 员工和管理层的问卷调查
- 一种快速收集方法，因为可以一次发放许多问卷。它需要问题简单，因为无法解释。
- 员工和管理层的访谈
- 在这里可以询问更详细的问题，并且提出的问题可以基于之前对问卷的回答。
- 程序观察
- 观察工作场所的人可以提供有关系统功能和遇到的问题的有用信息。
- 文件研究
- 这些可能包括手册/指南、行为准则、纸质文件、发票、收据，甚至墙上的便签！
- 数据
- 必须存储哪些数据？
- 这些数据是如何收集的？
- 自动 - 条形码、OMR 等
- 新数据采集表格/方法的设计
- 输入
- 数据是如何输入系统的？
- 手动输入，还是使用自动化方法？
- 数据是如何输入系统的？
- 处理
- 必须对数据进行哪些处理？
必须为新系统设计所有输入、处理和输出。这可能包括屏幕设计和打印的报告。它需要定义系统的类型，例如批处理系统或实时系统。还必须考虑安装的软件，以及 HCI（人机交互）。
这将产生一份设计规格，其中详细说明了系统的功能，并可能包括其算法、设计、屏幕布局或数据存储方法。
包括系统的全面测试部分，使用不同的方法
- Alpha 测试 - 使用开发公司内部没有参与该项目的工作人员，旨在查找系统中的错误。
- Beta 测试 - 使用公司外部的特定用户组在不同的环境中测试软件。
- 破坏性测试 - 一种试图以尽可能多的方式破坏程序的测试形式。
- 验收测试 - 用户根据需求规格对程序进行测试。一旦测试成功，项目就可以签署。
这涵盖了系统将如何安装。这包括任何硬件购买、员工培训、数据文件创建、转换方法和未来维护。
有两种类型 - 用户和技术。
- 用户 - 关于如何操作系统的指南，提供错误消息和故障排除的描述。
- 技术 - 用于以后的维护，可能包括代码和模块的描述以及算法。
主要有三种转换/转换方法
- 分阶段 - 将系统的一部分更改为新系统，而其余部分保持在旧系统上。如果出现任何问题，它们将被限制，因此不会影响系统关键部分。
- 并行 - 旧系统和新系统并行运行，使用实时数据，以便可以比较两个系统的效率。最终，旧系统可以完全下线。
- 直接 - 在一个特定的时间点，旧系统关闭，新系统上线。最便宜、最简单，但可能是最危险的方法，因为如果系统出现故障，将没有备份。
3 种主要类型
- 适应性 - 对系统进行改进以满足变化，例如新的增值税门槛。
- 完善性 - 改进以满足用户需求，例如移动按钮或菜单。
- 纠正性 - 修复错误。
.png)
螺旋模型围绕着风险处理。它使用四个阶段，每个阶段构成螺旋的四分之一，螺旋循环。
- 确定目标 - 第一个阶段根据最大潜在风险确定此螺旋迭代的目标。
- 识别和解决风险 - 识别可能的风险并考虑替代方案。如果风险被认为过高，项目可能会停止。
- 开发和测试 - 开发和测试正在处理的项目组件。
- 规划下一次迭代 - 此阶段计划下一次螺旋迭代的内容。
螺旋模型能够很好地处理风险，适合大型项目，但需要熟练的风险评估员和管理人员，这可能很昂贵。
此模型使用原型系统，这些系统缺乏最终系统的全部功能。这可能包括屏幕模拟或部分工作的系统。这可以向用户展示以获得反馈和评论，并在此基础上进行改进。每个构建-评估周期都会添加改进，直到产品完成，最终原型成为最终系统。它非常适合那些一开始需求不明确的项目，并且由于原型化的反馈循环，很可能导致产品具有出色的可用性。但是，它不适合创建高效的代码，并且它确实需要最终用户的参与。
敏捷方法是一组方法，能够很好地应对不断变化的需求。软件以迭代的方式生成，并且可以在每次迭代中添加功能。它通常被描述为一套价值观和原则，这些价值观和原则决定了代码的生成方式。它提倡适应性规划、演化开发、早期交付和持续改进，并鼓励对变化做出快速灵活的响应。通常，敏捷将包括一个“Scrum 团队”，他们在“冲刺”中开发软件。在每次迭代之后，用户将在每日站立会议上评估软件。但是，需要注意的是，敏捷是一种非常灵活的方法，因此这些共同特征是可选的。
敏捷开发的一种形式。XP 重视编码 - 一名代表客户成为团队的一部分，并提供“用户故事”（需求）、设计测试并回答程序员的问题。迭代时间短，它会生成“工作版本” - 该代码将在最终产品中使用。在编程时必须确定用户故事的顺序，程序员成对编写代码（结对编程）。一名程序员编写代码，而另一名程序员评估编写的代码，他们定期交换角色。代码被重构以使其更有效，并且在开发过程中使用了一套明确的标准。程序员每周工作时间不超过 40 小时。最终代码质量可能非常高，但是此方法需要一个紧密合作的团队，并且客户必须不断地派出一名员工加入开发人员。
| 模型 | 原则 | 优势 | 劣势 |
|---|---|---|---|
|
瀑布模型 |
|
|
|
| 螺旋模型 |
|
|
|
| 敏捷 |
|
|
|
| RAD |
|
|
|
| XP |
|
|
|
瀑布生命周期是为一种编程方法而命名的。解释遵循这种编程方法的程序员的优势。
答案
瀑布模型具有循环（1）模型，可以在需要时回溯（1）到以前的阶段。有定义的阶段，因此可以提供截止日期（1），并且每个程序员都可以处理定义的阶段（1）。
瀑布生命周期的替代方案是快速应用程序开发（RAD）。描述为什么 RAD 更适合由两名程序员组成的的小团队。
答案
RAD 强调立即开发（1）而不是规划（1）。需求被调整，原型被使用（1）。这更适合小型团队，因为需要遵循的繁文缛节较少（1）。