敏捷开发框架/资源下的软件工程
本节不会保持这种状态。它是本书其余部分的暂存区。
最终，一个名为“资源”的章节将包含本书中所有活动的空白模板。
环境报告
该项目最终使用所在的环境将从只有几个人观看时的非常安静，到学校旅行观看展览时的非常吵闹。目标项目受众在人数众多时最有可能非常吵闹。由于蝴蝶需要空调，总体温度会相当恒定。照明也会保持恒定，因为项目将在室内进行，并且易于控制。在栖息地，将有大约 28 摄氏度的恒定温度和 90% 的湿度，温度在夜间仅略微下降。由于任何硬件都将完全包含在栖息地内部或外部，因此气候不会造成任何明显的问题。
| Tithlyon 解决方案 - 决策矩阵 | |||||||||
|
项目 Digifly |
弹出式图书/教科书 | 互动式展品 | 互动式 DVD/CD 光盘 | 视频纪录片 | 虚拟现实 | ||||
| 功能需求 | 优先级 | 权重 1-10 | ' ' | ||||||
| 允许博物馆拥有一个基于蝴蝶的互动软件活动 | 至关重要 | 10 | 40% | 100% | 90% | 40% | 100% | ||
| 允许人们创建他们自己的虚拟蝴蝶 | 至关重要 | 10 | 10% | 100% | 100% | 10% | 100% | ||
| 允许将输入数据库的蝴蝶由其创建者检索 | 至关重要 | 9 | 0% | 100% | 100% | 0% | 95% | ||
| 蝴蝶将飞行、移动并与环境互动 | 至关重要 | 6 | 50% | 95% | 65% | 80% | 100% | ||
| 蝴蝶将在设定的时间后从数据库中删除 | 至关重要 | 7 | 0% | 100% | 80% | 0% | 100% | ||
| 必须迎合 10 岁及以上的人群 | 至关重要 | 9 | 50% | 95% | 95% | 75% | 80% | ||
| 足够灵活以处理不同的主题 | 有用 | 3 | 0% | 100% | 80% | 0% | 100% | ||
| 为用户提供一个机会，让他们带回家与展品相关的物品 | 有用 | 3 | 50% | 100% | 100% | 50% | 70% | ||
| 必须有断电时的关机程序 | 至关重要 | 10 | 0% | 100% | 100% | 100% | 100% |
| 具有某种屏幕保护程序 | 至关重要 | 10 | 0% | 100% | 100% | 100% | 100% | ||
| 展示自然生命周期 | 至关重要 | 10 | 100% | 100% | 100% | 100% | 100% |
| 易于使用（针对公众） | 至关重要 | 10 | 100% | 100% | 80% | 100% | 50% | ||||||||||
| 总数 | 107 | 31.78% | 99.30% | 92.94% | 63.60% | 92.38% | |||||||||||
| 约束条件 | |||||||||||||||||
| 对用户来说不应该像一台电脑 | |x||x | ||||||||||||||||
| 为用户提供一个返回的理由 | | | ||||||||||||||||
| 能够每天处理 300 到 1000 人 | |x | ||||||||||||||||
| 完全健壮 | |x | ||||||||||||||||
| 在 28 摄氏度和 90% 湿度的环境中正常运行 | | | ||||||||||||||||
| 无人值守运行并尽可能少地维护 | |x| |
在启动时显示版本号等 | |
显示区域之间的视觉关系 | |
|满足约束条件 | |||||||||||
| 'x' | 违反约束条件 | ||||||||||||||||
故事板对我们的开发至关重要。由于我们都讨厌文档，因此我们尽可能多地使用故事板，这节省了大量的时间和误解，因为我们都可以看到其他人的想法。
界面故事板有多个阶段，其中更改了许多细节，并且发现了许多潜在的问题。大部分故事板制作是在前三个月完成的，几乎没有在主要白板上的后期故事板，这些故事板是对原始故事板的微小修改。
以下故事板用于演示，向客户展示整体设计理念，并说明我们目前对界面需求的理解。最终产品与以下故事板有两个主要变化：没有 VR 部分，取而代之的是第三人称飞行部分，并且投影显示已成为最终部分。这两个变化都不需要任何故事板来实现，因此从未制作过。
功能需求
| 需求系统应 | 说明 | |
| FR 1 | 允许博物馆拥有一个基于蝴蝶的互动软件活动。 | 博物馆为博物馆的访客提供学习体验。 |
| FR 2 | 允许人们创建他们自己的虚拟蝴蝶。 | 将提供功能以允许人们设计自己的蝴蝶。 |
| FR 3 | 允许将输入数据库的蝴蝶由其创建者检索。 | 数据库将保存蝴蝶，以便人们可以回来再次查看它们。 |
| FR 4 | 限制用户使用系统的时间量。 | 为了保持队列移动，以便更多人可以使用系统。 |
| FR 5 | 吸引成年人和儿童。 | 吸引尽可能多的人群的需求是一个重要的因素。 |
| FR 6 | 蝴蝶将飞行、移动并与环境互动。 | 为了让显示内容更有趣，并提供更好的整体体验。 |
| FR 7 | 蝴蝶将在设定的时间后被删除。 | 为了为更多蝴蝶腾出资源，并完成生命周期。数据库文件将保留，但会停用，因为删除任何数据库内容都是不好的做法。 |
| FR 8 | 展示自然生命周期。 | 蝴蝶的完整生命周期，展示四个主要阶段。 |
| FR 9 | 迎合 8 岁及以上的人群。 | 8 岁以上的大多数人无需帮助即可使用。 |
| FR10 | 足够灵活以处理不同的主题。 | 整体设计应该能够处理更改以显示另一个概念。 |
| FR11 | 为用户提供一个机会，让他们带回家与展品相关的物品。 | 博物馆希望他们的访客带走一些实物以供参考，同时宣传博物馆和热带植物园，以吸引新访客和回头客。 |
| FR12 | 必须有断电时的关机程序。 | 博物馆中有许多带电显示设备。关机顺序比开关更复杂，因此是可取的。 |
| FR13 | 必须有开机时的启动程序。 | 与关机相同。开机与关机一样复杂的任务，应在启动显示器时要求博物馆工作人员执行。 |
| FR14 | 具有某种屏幕保护程序。 | 需要屏幕保护程序，因为显示器将运行很长时间。此外，还需要一个“屏幕保护程序”循环来吸引用户并告知用户产品。 |
| C1 | 对用户来说不应该像一台电脑。 | 大多数人发现电脑可能令人生畏、无聊或普通。所有这些都不是可能吸引用户与之互动的方面。 |
| C2 | 无人值守运行并免维护。 | 由于长时间内几乎无法进行维护，因此系统无需定期维护才能运行的需求非常大。 |
| C3 | 完全健壮。 | 能够承受博物馆互动式展品的磨损。 |
| C 5 | 在启动时显示版本号等。 | 需要版本号，以便不会混淆当前正在运行的软件/硬件版本。在维护或升级软件时很重要。 |
| C6 | 在潮湿和变化的环境中正常运行。 | 蝴蝶屋内的条件为 28 摄氏度和 90% 的湿度。该系统还可能在一段时间内安装在博物馆门厅或其他可能具有不同条件的区域。 |
| C7 | 能够每天处理 1000 个用户。 | 博物馆游客数量波动较大，受假期和天气等因素影响。同时，也经常会有旅游团或学校团等大型团体参观。这意味着系统可能在一天中持续使用，也可能完全不使用。 |
| C8 | 提供不同级别的信息 | 能够满足那些想要了解更多的人。 |
| C9 | 为用户提供一个返回的理由 | 用户会反复回到展览的一些原因。 |
锁定在昂贵的软件系统中 历史数据远程存储，难以访问或调整 即将到来的立法要求保留所有预订和调度数据的历史记录
预订表 预订表用于存储特定预订信息，这些信息在成功成为工作后会记录在工作表中。与地址表之间有两种关系，一种用于引用接送地址，另一种用于引用目的地地址。与班次表之间也有两种关系，一种用于记录操作员，另一种用于记录调度员。 关系 地址 1..N 预订（用于接送地址） 地址 1..N 预订（用于目的地地址） 班次 1 .. N 预订（用于操作员） 班次 1 .. N 预订（用于调度员） 班次 1..N 预订（用于出租车）
Booking.BookingID 通用信息 此字段是表的主键。它主要用于将自身引用到工作表上的记录。 值 此字段包含整数 来源 创建记录时，该值由 Access 自动分配 技术规格 数据类型：自动编号 必须唯一：是 默认值：由 Access 分配 主键
Booking.PickupID（Address.AddressID） 通用信息 引用地址表中的一个地址作为预订的接送地址 来源 操作员创建记录时输入此数据。它可以稍后编辑。 技术规格 外键 查看地址表了解更多信息 Booking.DestinationID（Address.AddressID） 通用信息 引用地址表中的一个地址作为预订的目的地地址 来源 操作员创建记录时输入此数据。它可以稍后编辑。 技术规格 外键 查看地址表了解更多信息
Booking.BookingCustomerName 通用信息 存储预订客户的姓名 值 此字段可以包含任何文本，最多 255 个字符 来源 操作员创建记录时输入此数据。它可以稍后编辑。 技术规格 数据类型：文本 必须唯一：否 默认值：NULL
Address.AddressShortcut 通用信息 存储操作员在前端使用的快捷方式，以便快速引用热门公共场所。 值 此字段可以包含任何文本，最多 10 个字符 来源 控制室主管在特殊界面管理此数据 技术规格 数据类型：文本 必须唯一：是 默认值：NULL
Address.AddressCustomerName 通用信息 存储与地址关联的客户姓名。 值 此字段可以包含任何文本，最多 255 个字符 来源 操作员创建记录时输入此数据。它可以稍后编辑。 技术规格 数据类型：文本 必须唯一：否 默认值：NULL
Booking.BookingTaxiShiftNumber（Shift.ShiftID） 通用信息 此字段引用执行结果工作的出租车的班次 来源 调度员将预订分配给出租车作为工作时输入此数据 技术规格 外键
查看班次表了解更多信息
Booking.PostDispatchNote 通用信息 此字段包含调度员输入的有关调度工作的任何备注 值 此字段包含任何形式的文本，最多 255 个字符 来源 调度员将预订分配给出租车作为工作时输入此数据 技术规格 数据类型：文本 必须唯一：否 默认值：NULL
团队管理合同
innovate.It 的成员将按以下方式进行会议
• 星期一 3:30 开始（大约 5 小时） • 每周至少一个其他晚上，事先安排（大约 2.5 小时）
此外，团队成员将在自己的时间内完成至少 2.5 小时的工作。
如果情况导致上述情况无法实现，则将做出安排以弥补时间。
沟通 • 任何成员都可以与讲师/客户沟通 • 演示将作为小组进行 • 与利益相关者/用户进行的任何会议都需要项目代表详细记录，带回小组，并保存在中央文档持有者中 • 团队成员之间的沟通将通过电子邮件和短信进行，使用 Blackboard 作为公共信息系统 • 团队成员必须每周至少相互沟通一次 • 团队成员必须在遇到任何不清楚的地方寻求澄清 - 作为一个团队前进，而不是作为个人 • 团队成员应该乐于分享想法，并让团队成员倾听和讨论这些想法 • 每月将根据设定的模板（位于 Blackboard 中）向客户提供进度报告，在此时间之外，将根据需要进行联系 • 客户在进度报告后至少每月提供一次反馈
程序 • 文档标准 - 标准格式、清晰简洁、适当使用空白、信息逻辑流动、标题与文本区分、目录、页面格式/编号、一种字体（12pt Times Roman） • 主文档放在 Blackboard 上供小组访问 • Hamish 每周（周一下午）备份 Blackboard 上的文档 • 所有文档上使用标准小组徽标 • 图片/图形使用得当，而不是为了美观 • 最终文档的标准将由一个尚未确定的独立人员检查，并基于相关经验 • 截止日期：使用指导表，列出每个步骤并保存在 Blackboard 上供小组访问 • 演示：所有演示的工作尽可能简单，并将包含所有关键要点
管理 • 小组应遵守 NZCS 概述的相同道德准则，例如保证能力、责任、问责制、良好实践、道德标准、风险理解和管理、他人看法、诚信和忠诚、可靠性、保密性。 • 我们向客户提出的提案大纲应包括目标和可交付成果。我们将确定所需资源，并按照向客户概述的项目计划进行。任何修订都应尽快解释。文档将在最终演示之前进行审查。
通用策略 • 与所有利益相关者的沟通将是透明和定期的 • 任何小组无法解决的问题将由讲师进行调解。 • 任何需要的资源将通过与奥塔哥理工学院或客户的协商获得。
放弃 • 如果团队成员在三周内未与项目主管或其他团队成员联系，则应视为放弃项目，除非事先通知。 • 一旦放弃，违反规定的成员将把所有项目材料和状态移交给剩余成员。 • 任何指定的替换成员可以根据项目主管的决定继承到目前为止的项目材料和状态。 • 如果客户放弃项目，则项目主管将自行决定项目是否继续与其他客户合作，或者团队是否加入或开始其他项目。
审查 • 进度将进行审查；在客户联系后，在每次 scrum 会议期间，以及在每次迭代的评估阶段（即原型审查）期间。 • 在客户联系后，将填写“客户联系”表格。
成绩分配 • 所有成员将获得相同的成绩，除非成员不符合本文件的规定。任何成绩调整将由项目主管决定。
项目执行摘要
该项目的目的是为 City Taxis 提供一个调度系统。调度系统应尽快投入使用。
我们使用了一种将迭代思维和敏捷思维相结合的方法。我们相信理解在整个项目中不断增长，因此通过使用原型和定期与利益相关者会面，将创造建设性的反馈，以确保成功实施系统。该系统应方便调度并提供历史记录。
目前已识别出的主要风险包括：缺乏立法合规性、隐私泄露、数据不准确、数据不安全。
项目名称：出租车调度系统
团队名称：innovate.It 团队成员：Hamish Smith、Shane van Dyk
客户：Allan Ward，City Taxis 项目赞助人：奥塔哥理工学院 项目主管：Sam Mann
项目描述
目标：提供一个能够轻松成功地进行出租车调度，同时准确记录所有必要数据的系统。 1. 准确记录所有调度的记录 2. 方便地提供当前的调度状态 3. 跟踪所有出租车的状态 4. 及时完成所有调度
第二部分：业务概述 业务声明 City Taxis 提供“大但尼丁地区”的交通服务，无论是观光、商务还是休闲。
City Taxis 为但尼丁提供优质交通服务 55 年。
他们是但尼丁所有领先酒店和汽车旅馆的首选出租车公司。也是该市许多领先企业的首选承运人。
无论是您的出租车费用是个人支出，还是记入您的公司或雇主账目，在当今审慎的会计时代，选择能够以经济的价格提供优质服务的承运人才是明智之举。 City Taxis 将为您做到这一点。
客户使命宣言：我们提供优质服务，拥有现代车队和高素质的司机。
我们努力成为最好，决不低于此。
City Taxis 为但尼丁人民提供 55 年的优质服务，我们致力于为客户提供最优质的服务和物超所值的服务。
第三部分：方法 项目方法
敏捷方法鼓励现实的进度和资源分配，允许项目需求和技术复杂性的变化。它还考虑了团队成员的技术短板以及对适当技术的访问。分阶段的生命周期方法帮助团队了解要执行的活动、每个阶段的交付成果、活动和不同阶段之间的不同类型的通信，以及在进行到下一阶段之前确定每个阶段的交付成果是否令人满意。每个循环的相对速度意味着团队和客户会多次重新审视项目的各个阶段，因此完成满足客户需求的项目的可能性更高。这也允许灵活地适应不断变化的客户/项目需求。定期使用“Scrum”会议（团队成员和客户之间每 15 分钟的定期会议）促进了团队成员和客户之间的高标准沟通，并将重点放在下一步要做什么以及谁在做什么。原型使用允许客户定期以动觉方式体验项目的开发。这促进了客户的建设性反馈，并增加了项目朝着满足利益相关者需求的方向发展的可能性。由于在整个项目中都在进行构建和评估，因此最终产品满足利益相关者需求的可能性更大。不期望所有各方在项目早期就达成共识。预计随着所有各方参与构建和评估过程，理解将不断加深。
项目概述
项目描述
City Taxis 需要一个改进的调度系统，该系统可以轻松高效地促进出租车调度，同时准确记录所有必要的数据。City Taxis 的主要枢纽包括电话接线员和一名调度员。电话接线员处理客户预订。调度员分配工作并与司机沟通。目前的系统似乎在办公室环境中很好地促进了调度工作，但成本很高。出租车司机与总部之间的当前通信系统似乎存在时间延迟，并且对司机的干扰比认为必要的更多。轻松访问存储的数据至关重要，因为未来的立法要求规定警方可以访问某些数据。客户的直接愿望是建立一个能够准确记录调度数据以供将来参考的系统，同时提供一个易于使用的前端界面。
项目风险 软件开发本质上存在风险和不确定性，这就是为什么我们需要在项目开始时设定明确且可衡量的目标。主要的项目风险包括软件无法满足用户期望以及软件开发人员无法为用户生成可运行或可工作的系统。此外，
• 无法获得用户承诺 • 用户参与不足 • 误解用户需求 • 无法管理最终用户期望 • 不同用户之间的冲突 • 用户培训不足 • 时间不足
绿卡，红卡 在流程的早期，我们为 City Taxis 的员工留下了卡片系统，让他们用来评论他们当前的系统。他们喜欢的事情可以写在绿卡上，需要改进的事情可以写在红卡上。
7 月 23 日讨论
• 预订始终需要电话号码和姓名 • 会出现没有街道地址的情况。在这种情况下，接送需要有一个位置，需要提供一个郊区和一个区域 • 从理论上讲，地址表中是否存在重复的位置条目并不重要 • 快捷方式不会动态更新，并且将有自己的界面用于编辑 • 说明是可选字段 • 地址号码不是强制性的 • 适用于接送的规则也适用于目的地 • 车辆类型是可选字段，默认情况下为空 • 所需时间是强制性的，默认值为当前时间 • 乘客人数是可选的 • 大型行李箱将从表单中删除 • 自行车架的真值将生成“，自行车架”以连接到调度屏幕的车辆类型字段。这种情况发生在生成调度数据时 • 预订需要接送地点和目的地
预订表单的当前状态 • 如果没有街道名称，数据将无法正确记录 • 目前没有预订验证流程，无论数据量有多少，任何内容都可以输入，尽管如果缺少某些数据，则不会创建任何数据 • 如果进行空白预订，则不会进行任何数据传递，但仍会显示“预订已保存”对话框 • 预订需要接送地址和目的地地址，否则不会记录任何新数据
TaxiDispatch 功能发布
2007 年 8 月 13 日
在去 City Taxis 之前，我对预订表单上的代码做了最后一次修改，使电话号码可选。这更适合他们目前的需要。
到达后，我将数据库拆分，将后端放在计算机上的文件夹中，用作调度员工作站，映射为 City Taxis 局域网上的“T: 驱动器”。我将前端打包成安装文件，并将安装文件创建到我们理工大学计算机上的共享文件夹中。该程序安装在 City Taxis 网络上的所有机器上，并开始测试。
测试中出现的问题和建议包括：• 调度作业屏幕无法正常工作。如果屏幕上有多个作业，作业将不会清除。这可能只是一个编程错误。• 保存预订或清除预订表单后，会出现大约三秒钟的延迟。大多数情况下这没问题，但在繁忙时间可能会成为问题。即便如此，在任何时候，三秒钟的延迟都足以让人感到厌烦。• 无法取消预订。• 我们没有为不同的车辆类型提供便利。没有施加任何限制，这意味着可以为一辆车预订 6 位乘客，即使这在物理上是不可能的。• 用于帮助提供地址详细信息的下拉框不适用于向下箭头键。• 特殊说明似乎没有进入数据库。• 对街道数据库进行了各种更正，并对位置快捷方式列表进行了补充，但仍需要进行一些更改。• 有人建议在下一个版本中，调度员需要能够随时重新定位板上的一辆车。
我花了一个多小时向值班人员展示预订表单，并监督他们的使用。之后，我坐在调度员的办公桌前观察调度员，并随时准备记下建议、意见和问题。我能够使用理工大学计算机直接访问后端并编辑表中的数据，从而立即解决现场的一些数据问题。
开发顺序
• 查看调度板并讨论线框界面 • 设计线框界面 • 纸质原型 • 设计选项 • 平台讨论 • 创建基本原型 • 做出平台决策 • 任务分析 • 详细界面 • 后端开发/迁移 • 创建逻辑过程层 • 构建/修改预订前端 • 构建/修改调度前端 • 构建/修改历史记录和配置前端 • 数据字典 • 技术文档 • 软件手册 • 帮助结构 • 测试 • 现场测试 • 实时稳健发布
排除 • 物理板：不实用，不符合客户的需求
组合选项：1. 访问表 + 访问查询 + 访问表单 2. SQL Server + 访问查询 + 访问表单 3. SQL Server + 存储过程 (SQL Server) + Windows 应用程序 4. SQL Server + ColdFusion + HTML 5. 访问表 + ColdFusion 或 PHP + HTML 6. SQL Server + ColdFusion 或 PHP + Google Maps
排除 • 选项 6：Google Maps 与线框界面的要求不匹配 • 选项 1 和 2：这些选项使用访问表单，这些表单实际上不支持线框界面的功能 • 选项 4 和 5：这些选项使用 HTML 作为前端。它没有适当的编码环境，这将使支持我们的线框界面变得复杂且困难
留下 • 选项 3：SQL Server + 存储过程 (SQL Server) + Windows 应用程序
SQL Server 是最适合的后端，因为与 Access 不同，它专为多用户环境设计，并且具有更好的稳定性和备份功能。它对我们使用数据的限制也更少。
SQL Server 上的存储过程将构成一个良好的逻辑层，因为它们与实际数据保持紧密联系，一旦创建，它将使前端开发变得更加容易。为适应前端的需求，有更大的范围来定制过程。
独立的 Windows 应用程序也是构建前端的最佳平台，因为我们将自行设计和构建它，我们可以使其满足我们的要求。Microsoft Visual Studio 可能是最好的编码环境，因为它将拥有连接到 SQL Server 数据源的功能。
你的时尚
[edit | edit source]
1. 系统应存储用户资料（用户需注册为会员，拥有用户名和密码才能使用网站并创建资料） 2. 系统应提供个性化反馈 3. 系统应存储用户购买历史记录 4. 系统应成为一个“专家”系统 5. 系统应包含基于网络的组件 6. 系统应整合虚拟社区/论坛 7. 系统应提供二手服装在线拍卖功能 8. 系统应保存搜索参数 9. 系统应“智能”地提供针对性的促销优惠 10. 系统应访问零售商的商品数据库 11. 系统应展示商店的相关产品 12. 用户应能够就服装选择对其他用户的资料进行评分 13. 用户可以编辑自己的资料 14. 用户可以删除自己的资料 15. 系统应为用户提供创建多个资料的选项 16. 零售商可以随时上传新的服装系列 17. 系统应允许用户在用户同意的情况下查看其他用户的资料 18. 系统应整合高质量的图形，并提供充足的空白区域，以提升易用性 19. 系统应允许在在线使用时进行更新 20. 系统应在出现任何停机时通知开发人员，例如输出消息“零售商XY，乔治街111号的屏幕B无响应” 21. 系统应使用移动平台（如手机、PDA、MP3播放器）实现便携性（因此，资料文件大小很重要） 22. 系统应能够使用56K连接在线创建资料 23. 系统应能够使用蓝牙技术发送针对性的短信 24. 用户应能够搜索过去的购买者（例如，在过去3个月、6个月、12个月内购买过的用户等） 25. 用户应能够将自己的衣橱物品添加到资料中，以完善资料（可能需要设置上限，例如使用低分辨率图像的50件服装） 26. 系统应根据用户资料将建议限制在所有可能组合中评分最高的五项 27. 用户应能够通过添加信息（例如，向虚拟衣橱添加物品）持续完善资料 28. 零售商应能够使用系统向目标用户资料发送购买建议（例如，年龄在30-35岁之间、年收入超过35,000美元、梨形身材、皮肤白皙的女性） 29. 用户应能够通过高级搜索（例如，特定风格、零售商、价格等）在线搜索衣橱建议 30. 用户应能够查看生成的时尚物品，并与其他建议物品进行互换 31. 用户应能够将建议的服装搭配发短信给其他人，以便征求反馈（使用3G技术，例如，请帮我评价一下这套服装=1,2,3,4,5） 32. 系统应能够剔除虚假资料（例如，用户提供的比例失衡的生物特征，用于创建不切实际的资料）
上面的图表还展示了衣架的概念，其中衣架用于对每件物品进行评分。一件物品的绿色衣架越多，就越适合该用户；一件物品的红色衣架越多，就越不适合该用户。衣架也可以是半绿半红，因为衣架评分来自适合度指数，因此一件物品的评分可以是5分中的3.5分。我们考虑过使用颜色滑块条来对物品进行排名，但最终决定使用星级评分（使用衣架，因为它独一无二）。
