敏捷开发框架下的软件工程/全过程
原型: 建立一些东西来回答具体的问题，从中学习并继续前进。
客户满意度
客户参与
文档（和证据组合）
部门 {{Adfmetabox |title |Bite |2 hours |Inputs |Evidence |Stakeholders }}
| 标题 |
|
|
本书中的彩虹扇形图旨在作为引导您自己的项目的模板。在前两次迭代中，我们将方框连接起来，在第三次迭代中，扇形是空白的。
诀窍是从左边的输入到右边的输出。
1. 画出您从输入到输出所需的活动。如果某些东西没有朝向输出方向，那么问问自己，我们为什么要这样做？
2. 注意所有五个工作流。
- 理解
- 构建
- 评估
- 沟通
- 引导
顶点项目是大多数信息技术学位的重要组成部分，奥塔哥理工学院的信息技术学士（B.InfoTech）也不例外。完整的项目列表可以在线获取：www.otagopolytechnic.ac.nz
Fincher 等人（2001）描述了项目的“成功关键”。虽然他们希望这些措施用于建立项目，而不是具体的项目，但它们确实为成功的项目提供了一个有用的衡量标准。奥塔哥 B.InfoTech 在完整系统方面可能独树一帜，包括硬件和软件。
顶点课程设计中一个重大的挑战是过程与产品之间的关系。作为学者，我们认为强大的过程将产生好的产品，但讲师在确定合适的过程方面却很少有指导。一个主要问题是将原型系统地整合到软件设计和开发生命周期中。在本文中，我们确定了一个成功进行这种整合的开发框架。该框架是根据示范项目开发的，并提供了一个最佳系统框架。该框架还用于探索较弱项目的开发过程。
本章旨在探讨开发方法论在成功顶点项目中的作用，特别是原型设计的程度、性质和整合。
在计算开发项目中，开发方法论的选择是一个永恒的争论话题，就像编程语言的选择一样。任何给定项目都需要选择一种方法论，选择可能基于无数因素。许多教育机构都包含一个顶点项目，学生，通常是小组，合作完成一个重要的项目。开发过程的选择在顶点项目中变得至关重要（Beasley 2003; Chamillard 和 Goold 2003; Bridgeman 2003, Clear 2003）。在计算教育中，引入教学要求使得选择变得复杂。我们面临的问题不仅是找到最佳的开发方法，而且是找到最佳的教学方法。
Clear 等人（2001）描述了他们在顶点课程设计中所谓的“过程与产品之间的张力”（p95）。他们指的是顶点课程的重点应该是开发过程还是开发的产物：一个可工作的系统。他们认为，由于顶点课程模拟了专业人士的工作，“建议采用并遵循一种可接受的方法论或过程。选择何种具体的方法论或其变体并不重要，重要的是使用某种正式过程”。Chamillard 和 Braun (2002) 这样描述了这个问题
| “ | “鉴于过程在实际软件开发活动中的重要性，我们希望确保我们的学生能够充分了解过程问题。另一方面，我们也不希望我们的学生认为，只要遵循了适当的过程，他们生成的是否是一个可工作的产品并不重要！因此，我们还必须适当强调学生正在开发的产品，以确保它满足项目要求”。（p229） | ” |
那么，顶点项目适合什么过程？传统上，大多数顶点课程都使用软件开发生命周期 (SDLC) 的派生版本，例如 Hoffer 等人（1999）所描述的版本。近年来，教学设计师将它与敏捷建模，特别是原型设计的组件混合起来（Fincher 等人 2001）。
Hakim 和 Spitzer (2000) 认为“挑战在于将原型系统地整合到软件设计和开发生命周期中”。
在本文中，我们的目标是确定一个成功的项目框架。
在接下来的部分中，我们将检查示范项目的开发过程的定性证据。选择小组是为了提供一系列的项目类别。来自学生反思性评论的引言说明了决策和过程的复杂性。
 案例研究 ACKI |
|
小组: Kevin Barclay
ACKI 项目旨在开发一个放置在电脑和键盘之间的盒子，供行动不便的用户使用 (Barclay 等人，2001)。这是一个针对独特用户需求的通用解决方案。该盒子模拟键盘，可以从任何设备接收模拟或数字输入。 开发过程中的几个方面尤为突出。建立了一个稳定的测试平台，这意味着可以建立详细的测试协议，并集成测试程序。小组详细记录了过程，并定义了测试结果。不同级别的原型满足不同的需求，测试平台用于调查技术问题，而白板笔模拟操纵杆以探索控制水平，输入设备需要做什么。 尽管这是一个硬件项目，但该项目与敏捷开发框架相符。对于每个组件，都使用了“微型生命周期”，并进行了分析-设计-测试循环。
|
| 案例研究 学校网络 |
|
小组: Boudewyn Erkens, Lorna Lou, Rebecca Sidaway
该项目旨在满足当地一所小学的 ICT 需求。除了网络设计和实施外，小组还与教师密切合作，满足其专业发展需求。虽然该项目涉及硬件和培训，但小组遵循了 SDLC 的自上而下的结构。特别是在培训需求方面，小组通过培训需求分析来满足需求，然后设计和实施课程。网络解决方案使用快速安装和借用设备进行了原型设计，学校使用了一个月，以查看解决方案是否满足他们的需求。
|
5.7 替代 CAD 接口 SDLC 被用作开发一个绘图板接口，用于建筑 CAD 系统 (Lawton 和 Meikle，2003) 项目的基础。该项目的大部分工作是开发和配置硬件，然后对每次迭代进行用户测试。团队开发了许多不同的原型系统，尽管使用了许多相同的组件，但他们每次都从头开始在他们开发的平台上进行构建。
“原型设计的一些方面被反复... 而且又一次地重新审视。某些方面被证明过于耗时，并且在一个案例中，由于这个原因，一个决定不得不被放弃。”
“纸质”接口将在建筑制图学生的协助下开发。将要求学生评估每个版本的接口，并提出建议或批评。这将影响后续的接口草稿，以及菜单文件（CAD 应用程序的接口代码）的要求。
硬件将被组装和安装，以便与潜在用户一起进行测试。与批评一样，观察和建议也将被评估并纳入系统。重复此阶段，直到满足功能需求。”
分析、逻辑设计和原型设计的迭代阶段同时进行。涉及原型设计的项目方面包括绘图表面、框架的构建、指向设备、投影系统和 AutoCAD 接口的定制。遇到了问题，也发现了系统意想不到的优势。
5.8 短信 该小组的目标是开发一个通过手机控制多个远程设备的系统。该系统涉及多个硬件和软件组件的开发和集成。小组遵循 SDLC 流程，在分析中开发了一个硬件和软件原型：“我们拼凑了一个应用程序……在该测试应用程序运行后，我们发现设计中存在一些问题……现在我们已经确定了功能需求，并签署了协议，可以继续深入规划……”
小组开发了一个可工作的系统“原型”，并在实施阶段按顺序更换了主要组件。
5.9 Edubuilder 建筑行业是一个存在多层复杂性、交互作用、不同时间尺度和决策后果的领域。这是技术支持的良好交互式学习体验的主要目标。该项目承担了提供一个内容管理系统，该系统所在的领域拥有大量的专家知识，但很少有好的信息来源利用交互式媒体。小组遵循 SDLC，从梳理大量建筑标准开始，并努力寻找一个可以将它们联系在一起的主题。他们使用了几个比喻，然后又回到了建筑本身和项目计划图上。他们开发了一个图示原型，并在与几个“客户”的讨论中，他们发现不同时间尺度、上下文和用户对甘特图的看法，这才是难以捉摸的概念。为了检验这一前提，小组开发了几个原型来证明这一概念，这些原型从单个草图到系统的半功能交互式模型不等。这些原型用于明确测试前提的各个方面。为了实现这一概念，小组意识到需要一些复杂的技术程序。小组使用了精心管理的测试制度，该制度确定了测试的必要性、代码的开发、测试程序和记录。由于需求定义明确，开发了一个稳定的系统，并使用了严格的测试制度，因此项目结束时的实施非常迅速，但交付成果既健壮又实用。5.10 为西装租赁开发信息系统 尽管这个项目是传统信息系统的理想选择，但客户并不完全相信他需要一个计算机化的系统。为了消除这种顾虑，小组在计算机上开发了一个早期原型，该原型反映了纸质系统。客户相信，他将提高效率，而不会失去纸质系统的基础。该原型还允许开发强大的功能需求。小组还能够通过在客户的场所同时运行原型和现有系统来测试他们对当前系统的理解。分析完成后，小组放弃了原型。然后他们经历了正常的逻辑和物理设计，涉及几个原型。客户在该阶段五个月内无法使用，但小组能够根据他们开发的强大功能需求来测试原型。最终的系统在业务运营方面与最初的原型有很大不同，但它保留了纸质系统的外观。 5.11 Familtrak 熟悉之旅（“Famil”）是指旅行社人员进行的旅行，以熟悉他们正在销售的产品。他们应该在返回后写一份报告，但几乎从不这样做。该项目的客户想要一个系统来促进此类报告的发布和传播。这不仅仅是一个简单的数据库，解决方案涉及网页、XML、GIS 和高度的交互性 (Hamilton 2003)。最初的功能需求是在小组和客户之间协商的。然后，小组花费数周时间验证和改进功能需求。这包括对工作模式进行大量观察、问卷调查和纸质原型。原型最初用于表示系统需要执行的功能集。在逻辑设计中，使用了第二个纸质原型来开发系统的结构。小组首先在纸面上与客户一起测试了原型，然后他们巧妙地扫描了纸张并将它们链接在一起，从而产生了一个低保真但高交互性的原型。这意味着“测试在任何代码编写之前就已完成”。该系统在截止日期前三个月发布给客户进行实际生产使用，然后小组能够致力于完善系统并开发一些更困难的方面（链接空间和多媒体方面）。 6 示例流程 从示例项目中，一些主题出现了。我们将这些主题提炼成一个示例开发框架。
1. “SDLC”识别的方法 2. 原型使用 3. 强大的功能需求使用 4. 使用低保真但高交互性的原型测试功能需求 5. 早期开发稳定平台 6. 原型是集成测试计划的一部分 7. 向客户交付早期功能产品 8. 稳健的最终产品 9. 仍然需要“正常”设计 - 原型设计不会取代 10. 原型用于与客户进行沟通 11. 通过革命性（与进化性相比）的成熟。分阶段硬件更换。
这些因素中的一些可能是质量的预期衡量标准；它们出现在这里并不令人惊讶：我们没有关注拼写或良好的组内沟通，但这些也是这种框架所期望的。然而，我们拥有的证据表明，示例小组确实做了这些事情。有些因素令人惊讶；我们没有预料到会发现示例项目中的成熟过程如此相似。
7 验证 为了进一步探讨开发框架的重要性，我们对所有已记录项目的完整集进行了分析。第一作者与一个不了解项目历史的第三方合作，对十一个因素中的每一个因素进行五分制评分。这些分数与项目的成绩进行比较。需要注意的是，本分析使用成绩作为质量衡量指标，我们认识到这里还有其他因素在起作用。我们也认识到作者在进行这种评估时可能存在的偏见，尽管这应该会在一定程度上被公正的第三方所缓解。对十一个因素进行简单汇总，与每个项目获得的成绩之间存在很高的相关性（r=0.756）（图 3：对于此统计数据以及后续统计数据，示例项目除外）。此外，这种关系不受项目类型的影响。
图 3：流程评分汇总与质量密切相关，不受项目类型影响。
图 4 显示了根据开发框架评估的所有项目。所有因素都与成绩呈正相关。可以识别出一些异常项目：“78 HW A”项目是一个没有遵循框架的硬件采购项目，而 “174 IS A-”项目是一个回顾性项目，该项目虽然遵循了流程，但证据不足，导致成绩略低。构成此评分的大多数组成因素可以被认为是质量的一般衡量指标。其他指标，例如团队合作的效率或拼写，可能也会具有正相关性。这仍然有用，我们也会将这些因素确定为关键成功因素。一些因素并不那么明显；实施类型——革命性或阶段性替换，而不是演进式——在由优秀团队执行的模式中令人注目。
图 4：按开发框架评估的项目，按成绩从上到下排序。较深的阴影表示使用此因素时的 4 或 5。示例项目位于线以上。
也许比流程因素的总体相关性更重要的是它们在频谱两端的关系——较差的团队在做什么不同？仔细观察图 4（或查看相关性——未显示），会发现一些有趣的模式。较差的团队进行的原型设计较少，这是可以理解的；他们也较少做其他事情。关键的是，当他们进行原型设计时，他们并没有同时进行“正常设计”，也没有稳定的系统、提前交付等。在早期阶段使用原型的较差团队也具有非常薄弱的功能需求，没有强大的测试计划等，换句话说，原型成为了整个开发。中等范围内的团队，他们进行原型设计，往往有较弱的逻辑和物理设计，相反，他们将开发视为使原型更稳固的过程。这些模式也可以从评审小组对成绩排名前一半的团队的评论中看出来（表 2）。
将代码写成概念验证原型，然后尝试设计它。'团队的一半在设计，另一半在编码，而且速度不同'
在获得原型时做出的技术决策困扰了后期的开发，良好的流程受技术技能的限制
功能原型在早期开发出来，但没有设计，这个糟糕的设计一直存在，将糟糕的流程数字化，因为 SDLC 的一些阶段被遗漏了。
最初的概念是用原型完成的，任何被认为太难的东西都没有被视为 SDLC 中的真实需求，而是从最初的想法跳跃到实施。
无法实现太多技术复杂性，因此缩减了范围以使原型可交付。
成功地完成原型后，在接下来的一年里几乎没有进展。在最后一刻，他们独立地实施了剩下的部分，并回顾性地进行了 SDLC 分析。
为概念验证开发的原型卡住了 SDLC，非常薄弱。客户很满意，但技术复杂性不足。
手掌开发。从来没有稳定的平台。无法使其正常工作。
表 2：评审小组对 C 组和不及格组的评论
8 结论 Hakim（2000）认为，“挑战在于将原型系统地纳入软件设计和开发生命周期”。在本文中，我们已经确定了一个成功地实现了这种集成的开发框架。该框架是从示例项目中发展而来的，并提供了一个最佳系统框架。
Stein（2002）也确定了成功项目共有的属性。但警告说，“然而，对于我发现的每个属性，……我都能找到包含相同属性的不太成功的项目”。通过研究开发框架与较差团队正在做什么的比较，我们已经能够确定该框架如何适用于较弱的团队。特别是，我们证明了较弱的团队进行原型设计而不是正常设计，或者相反，坚持对 SDLC 的天真看法，导致设计测试不足的风险。
本文没有考虑项目的技术复杂性。Goold（2003）讨论了团队成员的技术技能和拟议项目的范围的影响。值得研究项目的复杂性，以及这与成绩和采用的开发框架之间的关系。我们发现，该框架同样适用于不同类型的项目（参见 Avrahani 2002）。
通过采用能够被认为可以生产出优质产品的同时又灵活和稳健的流程，可以减轻产品和流程之间的紧张关系。我们相信本文中开发的开发框架将为顶点课程提供基础。
9 致谢 我们感谢多年来学生们提供的丰富信息。以及本课程其他讲师的工作。Patricia Haden、Phoebe Eden-Mann 和 Zuzette van Vuuren 在分析方面提供了帮助。本研究是在奥塔哥理工学院 B 类伦理审批下进行的。参考文献
Barclay，K.，Mann，S.，Brook，P. 和 Doonan，A.（2001）自适应计算机键盘界面的开发和测试 在第 14 届全国计算资格咨询委员会年会的论文集 Napier，第 13-22 页 Beasley，R. E.（2003）。“在计算领域成功进行高级顶点课程。”小型学院计算杂志 19（1）：122-131。Bridgeman，N.（2003）。项目成功：定义、设计、构建和展示顶点项目。第 16 届 NACCQ 年会，帕默斯顿诺斯，NACCQ.211-216 Clear，T.（2003）。“瀑布已死，长存瀑布！”SIGSCE 公告 35（4）：13-14。Clear，T.，F. H. Young，M. Goldweber，P. M. Leidig 和 K. Scott（2001）。“计算领域顶点课程讲师的资源。”ACM SIGCSE 公告 33（4）：93-113。Chamillard，A. T. 和 K. A. Braun（2002）。软件工程顶点：结构和权衡。第 33 届计算机科学教育 SIGCSE 技术研讨会论文集，辛辛那提，肯塔基州。227-231 Fincher，S.，M. Petre 和 M. Clark，编者（2001）。计算机科学项目工作：原则和实用性。伦敦，施普林格。Garrett，P.，D. Youngman，J. McCormack，C. Rosescu 和 S. Mann（2003）。成功的特点——虚拟存在。第 16 届 NACCQ 年会论文集。269-272 Goold，A.（2003）。为顶点课程中的项目提供流程。第八届计算机科学教育创新与技术年会论文集，塞萨洛尼基，希腊，SIGCSE ACM。26-29 Hakim，J. 和 T. Spitzer（2000）。有效地进行原型设计以实现可用性。ACM 通信设计特别兴趣小组，IEEE 专业通信学会国际专业通信会议论文集和第 18 届 ACM 国际计算机文档大会论文集：技术与团队合作。47-54 Hamilton，M.（2003）。Familtrack。第 16 届 NACCQ 年会论文集，NACCQ.484 Hoffer，J. A.，J. F. George 和 J. S. Valacich（1998）。现代系统分析与设计。美国雷丁，本杰明·卡明斯。Lawton，B. 和 A. Meikle（2003）。替代 CAD 用户界面。第 16 届 NACCQ 年会论文集，NACCQ.487 Ponting，D.，L. Quarrie 和 G. Robertson（2003）。为酒店业提供正确的服务：酒店培训 CD-ROM。第 16 届 NACCQ 年会论文集。495 Rudd，J.，K. Stern 和 S. Isensee（1996）。“低保真度与高保真度之争。”交互 3（1）：76-85。Singh-Cosgrave，B.，Sinclair-Fox，C.，McLellan，G.，Mann，S. 和 McGregor，G.（2001）用于教授基于开发的主题的交互式 CD 简明论文，第 14 届全国计算资格咨询委员会年会论文集 Napier，第 460 页 Stein，M. V.（2002）。“在顶点课程和软件工程课程中使用大型和小型小组项目。”小型学院计算杂志 17（4）：1-6。
4 结果
4.1 初始发现 值得调查项目的外部特征，以表明成功项目的开发特征。在 2001 年至 2003 年之间，完成了 65 个项目。35% 获得 A，32% 获得 B，16% 获得 C，17% 失败。这些项目可以分为八类，如表 1 所示，以及每类的分数分布。除了一些小的例外（“总系统”全部成功，“硬件”的失败率高于预期），项目类型与成绩之间没有强烈的关系。无论项目类型如何，都可以获得好成绩。
表 1：项目的分类和成绩分布。
总系统 3 硬件 15 应用软件 7 信息系统 13 多媒体 12 内容管理 6 网络 3 其他 6 总计 65
图 1：小组规模对项目成绩的影响。
小组规模存在影响，如图 1 所示。虽然两人或三人的小组表现出类似的模式，但单独工作的学生失败的可能性要高得多。我们认为这里有两个潜在因素：学生的质量（即为什么他们单独工作）以及他们错过了在小组中工作的益处。
大多数学生遵循以文档为中心的开发方法。然而，学生们错了，规模并不重要，关于按权重分配成绩的谣言是不真实的。图 1 表明最终成绩与文档页数之间的关系非常弱（n=49，图书馆中有完整的文档）。一旦超过大约 100 页的最低阈值，任何成绩都是可能的。在约 260 页处有一组高分。文档最多的项目没有获得最高分，而且显然，糟糕的项目无法通过大量文档来挽救。
图 2：页数和成绩之间的弱关系（n=49）
无法通过项目类型或工作量来识别好的项目。因此，我们回到这个问题，优秀的团队在做什么？