这个作业属于哪个课程	软件工程
这个作业要求在哪里	团队作业3——需求改进&系统设计
这个作业的目标	团队项目：针对需求分析进行改进，通过系统设计满足需求，细化项目任务分配并确定测试计划

团队成员	学号	博客园主页	GitHub
徐宗韬（组长）	3121004802	yuLLin	yulinnn
冯浩天	3121004779	FHTgduthomework	FHTHomeworkAtgdut
朱正东	3121004806	Momota	momotaaa
黄皓坤	3121004783	jiaoqud86	jiaoqud86

队名：硬工队
团队GitHub：VividImages

1 需求&原型改进

1.1 针对所提出问题的需求分析修改

- 问题1：对计算机“小白”来说，操作是否可以更简便、快捷一些？能否提供滤镜的预览效果显示？
修改：为使操作更简便，系统将抛弃复制粘贴目标地址的方式，改为直接通过按钮搜索目标图片文件、选择保存地址；此外，在用户选择图片和滤镜后，将直接在软件中显示原图以及滤镜效果，用户可以将原图和处理后的图片进行对比，用户得以自由选择是否使用这个滤镜，而不是保存后才能看到滤镜效果。

- 问题2：图片拼接和图片水印功能是否也可实现批量操作？
修改：对系统进行重新设计，系统的所有功能（即滤镜、拼接、水印）处理的图片数量都可以由用户自由选择，系统中不再区分单张和批量处理，使系统更加简洁，避免系统功能的臃肿。

- 问题3：能否使滤镜选择更多样化、个性化？
修改：系统将支持用户从外部导入滤镜，用户能够依照自己的喜好更自由地处理照片。

1.2 对《需求规格说明书》进行修改

通过分析上述所提出的问题，我们发现本项目存在功能考虑不全、功能模块设计不够全面、用户交互不协调等问题，因此对于交互逻辑的重新设计以及系统功能的重新划分为修改的重点。
根据上述所提出的修改，经团队内讨论，我们将原《需求规格说明书》中的功能设计及用户操作逻辑修改如下：

1.3 项目原型设计

经团队内讨论，基于《需求规格说明书》，项目Vivid Images的原型设计如下：

1.4 功能分析的四个象限

	外围功能	杀手功能
必要需求	提供图片滤镜、图片拼接、图片水印功能	能够批量处理图片；可以从外部导入滤镜
辅助需求	可以查看历史纪录；提供图片处理效果预览	三个图片处理功能一体化，方便快捷

1.5 任务分解WBS及相应的项目进度计划

1.5.1 任务分解WBS

通过WBS，本项目的功能模块分解如下：

1.5.2 相应的项目进度计划

经团队内讨论，根据本周任务完成情况和团队自身情况，校正时间安排如下：

时间	任务
第9周	1.团队组队、团队博客
	2.团队介绍、成员展示、角色分配、选题确定
	3.制定团队计划安排，团队贡献分的规定
第10周、第11周	1.需求规格说明书
	2.确定项目功能模块和实现方法，估计任务难度并学习必要的技术
	3.平台环境搭建完成、初步架构设计和搭建
	4.对用户界面和交互逻辑进行初步设计
第12周	1.原型改进（给目标用户展现原型，并进一步理解需求）
	2.WBS, 团队成员估计各自任务所需时间
	3.测试计划
	4.完成UI初步设计
	5.初步编码，实现文件IO、图片预览功能
第13周	1.团队项目Alpha任务分配计划
	2.连续7天的Alpha敏捷冲刺，7 篇每日Scrum Meeting博客+代码提交
	3.完成所有功能的编码，完成UI设计
	4.进度计划：图片风格化处理3天，图片拼接1天，图片水印1天，历史记录1天，测试与开发同步，优化1天
第14周	1.用户反馈+测试计划改进
	2.团队Alpha阶段个人总结
	3.团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理
第15周	1. 团队项目Alpha博客：事后分析

2 系统设计

2.1 系统架构设计

2.2 为什么本项目不使用数据库技术

本项目所实现的软件的定位为免费开源的轻量化本地软件，所有功能应能够离线使用，目的是让用户高效快捷地处理图片。本软件初始化数据信息少（仅有滤镜风格名称、图片拼接方式名称、水印样式名称）并且用户无法更改这些初始化数据，软件产生的数据信息少（仅有历史记录数据），并且软件产生的所有文件数据及图片处理结果均保存在本地；此外，本软件没有登录注册功能，也因此没有如分享之类的用户间交互功能。综上，我们认为本项目的开发无需使用数据库技术。

3 Alpha任务分配计划

3.1 Product Backlog

3.2 Sprint Backlog

3.3 使用甘特图拟定迭代冲刺计划

4 测试计划

4.1 引言

4.1.1 测试计划基本信息

使用本测试计划的项目为Vivid Images，开发团队为广东工业大学硬工队。
本测试计划的制定者：徐宗韬。制定日期：2023/11/13——2023/11/14。
本测试计划的使用人员：徐宗韬，冯浩天，朱正东，黄皓坤。

4.1.2 项目背景

项目Vivid Images的目标为实现一个拥有GUI的基于OpenCV的图像处理软件。系统包含图片风格化处理、图片拼接、图片水印三大功能，允许对多个图片进行同时处理，并提供历史记录查看；此外，系统的用户界面简单明了、易于使用，用户能够方便、快捷、高效地处理图片。

4.2 测试范围

本测试计划主要测试系统的图片风格化处理模块、图片拼接模块、图片水印模块、历史记录模块、文件IO、用户界面以及系统兼容性，具体如下：

测试方面	测试内容
图片风格化处理	是否所有内置滤镜都可以正常显示，滤镜效果是否与用户选择一致，能否兼容导入的滤镜
图片拼接	图片是否可以正常拼接，拼接方式是否与用户选择一致
图片水印	图片是否可以正常打上水印，水印的透明度和清晰度，水印排布方式是否与用户选择一致
历史记录	历史记录是否正确记录了用户所有操作，历史记录能否成功删除
文件IO	图片的读取和保存是否正常，历史记录的写入和读取是否正常
用户界面	用户界面是否可以流畅使用，用户指引是否清晰，UI交互是否合理
兼容性	系统能否兼容主流设备

4.3 测试目标

系统的所有功能可以正常使用，系统不存在明显的BUG，系统能够兼容主流设备，用户拥有流畅的使用体验。

4.4 测试方式

4.4.1 测试人员需求和分工

所有团队成员均参与测试，每个功能实现后所有团队成员都至少使用三次，在测试出问题后与其他成员讨论，并由负责对应部分开发的成员修复。

4.4.2 测试时间安排

测试覆盖整个Alpha阶段（13、14周）。

4.4.3 测试策略

测试策略采用W模型，Alpha阶段即从详细设计到交付的流程，具体如下：

项目的开发分模块进行，故测试内容也分模块进行。在所有模块开发并分模块测试完成后，集成所有功能，进行整个系统的使用测试优化，覆盖所有测试方面。

4.4.4 测试方法

采用黑盒测试和白盒测试相结合的方法。

黑盒测试，即把被测的软件看作是一个黑盒子，我们不关心盒子里面的结构如何，只关心软件的输入数据和输出结果。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
白盒测试，即把盒子打开，去研究里面的源代码和程序结果，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

4.4.5 测试停止及恢复条件

停止条件：系统崩溃；系统响应时间超过15秒；程序运行结果出现错误。
恢复条件：程序可正常运行。

4.4.6 测试资源和环境

CPU	AMD Ryzen 7 6800H
内存	16GB
操作系统	Windows11
编程语言	Python
IDE	Pycharm
性能分析工具	cProfile，Coverage

4.5 测试风险评估

4.5.1 进度风险

风险：由于时间不足导致的项目无法完成，或测试时间不足。
分析：开发时间较少，进度比较紧迫，风险较高。
方案：持续监控项目开发进度，严格安照甘特图进行项目开发和测试，并且预留至少两天时间以应对开发时间不足和测试优化时间过长等情况。

4.5.2 技术风险

风险：所开发软件的架构体系存在问题，或者团队成员技术水平不足，使完成的软件产品未能实现项目预定目标或质量低劣。
分析：团队成员已基本完成所需技术的学习，并且团队成员有比较丰富项目合作经验，大多有与本项目相关应用的开发经历，风险较低。
方案：反复确认项目开发所需技术，所有成员按照学习计划自我提升，确保在实际开发和测试前熟悉使用相关技术。此外，必须深入考虑软件架构是否合理，发现问题后需与所有成员讨论，尽快得出优化方案。