团队作业3——需求改进&系统设计
Part one 作业地址
| 这个作业属于哪个课程 | 软件工程 |
|---|---|
| 作业要求 | 团队作业3--需求改进&系统设计 |
| 作业目标 | 团队集体协作完成项目开发，促进彼此间的交流 |
Part two 需求&原型改进
2.1 给目标用户展现原型，与目标用户进一步沟通理解需求
思考：他们想要的商品是什么？
我们在给周围两三个同学展示了我们的原型设计和构想，在课堂上展示过我们之前的需求分析以后，采访了同学们的感受：
问：你们觉得在学校中最大的需求、最需要的商品是什么？
答：书本，宿舍的生活用品，路上的交通工具，以及一些生活需要的护肤品，球鞋等等。
问：在平时你们多久购物一次呢？
答：需要的时候就买，大概一个星期就会购物一次，尤其是上大学以后，有时候没事做也会逛逛淘宝，京东，买一些零食也是会的，
鞋子，生活用品的话，则是一个月买一次差不多，书本以及练习册就一学期买一次差不多。
问：你们是否有想过用更便宜的价格来购买自己的需要，更快的速度到达自己的手中吗？
答：有，我希望有一些专门服务学生的购物平台来让我购买，让我能够更省钱，因为外面的物品许多假货，然后不适合学生需求的，还有价格偏高的，学生的判断能力较差，容易入坑，
而且有时候需要用到的东西往往一星期才到手，速度很慢。
2.2 改进的需求规格说明书
1.21改进说明
改进部分一:为项目需求规格说明书新增一个目录
改进理由:重新查阅需求规格说明书的格式规范之后，我们发现一般比较正式的说明书都应该有一个目录，但是之前的1.0版本的需求规格说明书缺少这个部分，于是我们对说明书重新编排页码后列了一个目录，方便读者能够快速阅读各个部分的内容，然后需求分析功能模块描述的过于含糊和简单，光看“需求规格说明书”不能看出其需求，缺少吸引力。
改进部分二:在引言中为定义重新增加了两个专有名词:App、web端
改进理由:原先的1.0版本的需求规格说明书中只有一个名词定义:web端，作为正式的需求规格说明书，确实显得偏少，于是在改进过程中，我们根据自己的项目，又在此基础上增加了两个新的名词定义:App、web
改进部分三:在需求规定中重新定义了功能规定
改进理由:由于在我们对原型设计的不断改进之中，我们的项目功能也有所改进，所以，对大学生综合性平台，都新增了两个共同的功能:登录和编辑个人信息。
改进部分四:对性能规定中灵活性的补充
改进理由:原先书写好的1.0版本的需求规格说明书中只对灵活性这个性能列出了提纲，对于细化内容尚未书写，所以在这次的改进之中对此做出了补充说明。
改进部分五:在需求规定中新增了属性说明
改进理由:之前1.0版本的需求规格说明书中缺少这一部分的内容，但是在改进过程中了解了需求规格说明书的格式规范之后，我们觉得有必要编写，所以就重新增加了可用性、安全性、可维护性三个属性，最终形成了目前改进之后的2.0版本的需求规格说明书。
Part three 参考《构建之法》功能的定位和优先级，给出功能分析的四个象限
| 外围功能 | 杀手功能 | |
|---|---|---|
| 必要需求 | 第二象限： 任务完成度模块 界面设计 | 第一象限： 用户注册登录 各个模块购物功能 付款方式模块 |
| 辅助需求 | 第三象限： 商品模块商品信息 订单模块购物车 | 第四象限： 商品搜索辅助模块 商品首页展示 |
Part four 任务分解WBS
a.请给出团队项目的WBS：
b. 团队成员估计各自任务所需时间
团队成员这次的任务时间：
张天：负责Alpha任务分配计划，花费4个小时；
黄浩捷：负责测试计划，花费3个小时；
黄炜恒、曾广宁：负责需求分析和改进软件需求说明书，花费8个小时；
曾春华：负责系统设计中的系统架构和数据库设计，花费5个小时；
陈伟升：负责功能性象限和WBS任务分配，花费3个小时。
Part five 系统设计
在设计阶段，我们要清楚：软件是怎么解决这些需求的？
一个好的分层式结构，可以使得开发人员的分工更加明确，一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。
1.如何才能最大限度地实现这些需求，这就是架构设计要解决的问题，请给出系统的架构设计
本系统主要采用的是MVC的设计模式
-
视图（View） 视图层能够实现数据有目的的显示，在视图中一般没有程序上的逻辑，为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。
-
控制器（Controller） 控制器起到不同层面间的组织作用，用于控制应用程序的流程，它处理事件并作出响应，“事件”包括用户的行为和数据模型上的改变。
-
模型层（Model）：“数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法，“模型”有对数据直接访问的权力，例如对数据库的访问。“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作。但是模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。
2.完成团队项目的数据库设计，并在随笔中提供相应ER图（如果必要）
大学生综合性平台设计：
Part six Alpha任务分配计划
-
第一部分：以需求分析为主，选择和排序本次迭代需要实现的订单条目
（1）对市场上以及同学们提出的需求进行汇总，对系统进行设计和实施（张天）
（2）进行系统功能的实现：
1.编写用户注册系统（张天）
2.编写商家入驻导入系统（黄浩捷）
3.编写商品购买系统（黄炜恒）
4.编写商品支付系统（陈伟升）
5.编写前端显示界面（曾春华）
（3）对初步完成的系统进行测试与完善（曾广宁）
-
第二部分：以设计为主，确定系统设计方案和工作内容
（1）用户注册（通过昵称，手机号、学号进行用户的注册）（张天）
（2）商家入驻（导入商家输入的安排）（黄浩捷）
（3）商品制定（根据用户购买的商品进行计划的制定和调整）（黄炜恒）
（4）支付系统（包括微信支付，支付宝支付等）（陈伟升）
（5）前端界面（尽量做到美观，简洁明了）（曾春华）
（6）整体测试及完善（保证用户使用的舒适度及实用性）（曾广宁）
Part seven 测试计划
1.项目背景
为了解决,特此推出等功能，以满足学生日常生活以及学习的需要。
2.测试目的
此计划编写的目的是为使大学生综合性平台能够达到与系统说明书所描述的功能一致，并且检验系统是否运行稳定。
3.测试范围
（1）软件的可用性
（2）功能的完整性
（3）数据的准确性
（4）系统的稳定性
（5）帮助等其他使用说明文件是否表达准确
4.测试安排与进度
| 测试任务 | 人员安排 | 时间估计 | 起始时间 |
|---|---|---|---|
| 各项功能的测试 | 张天、曾广宁 | 3天 | 2020/11/2 |
| 完成所有模块的组合测试 | 黄炜恒、陈伟升 | 2天 | 2020/11/4 |
| 确定各项数据都是准确的 | 曾春华 | 2天 | 2020/11/6 |
| 将安装手册和用户帮助手册与软件操作比较是否有不符 | 曾广宁 | 2天 | 2020/11/8 |
| 安装、卸载是否顺利 | 黄浩捷 | 1天 | 2020/11/12 |
| 系统稳定性测试 | 张天、黄浩捷 | 2天 | 2020/11/15 |
5.测试种类及测试标准
| 测试种类 | 测试标准 |
|---|---|
| 功能测试阶段 | a.测试各个模块以及窗口所完成的功能是否准确，操作是否简洁方便b.功能键是否描述准确、齐全，操作方便c.界面是否设计简洁、符合用户需求 |
| 数据测试阶段 | a.输入正确数据是否能按照预期的答案回显b.是否能识别错误的输入数据，并给予正确的信息提示 |
| 安装手册帮助文件测试 | a.帮助文档是否精确描述了如何使用各种使用功能b.术语、菜单描述和系统响应是否与实际程序一致c.是否能够根据文档方便地解决用户问题 |
| 安装卸载测试阶段 | a.自动安装和手工配置安装是否都能安装成功b.安装退出之后，确认应用程序可以正确启动、运行c.卸载是否成功、彻底，是否把所有相关文件全部删除 |
| 系统稳定性测试 | a.在几种常用的操作系统下是否能顺利运行b.在与其他软件并行时是否运行正确。 |
Part eight 参考文献
1.现代软件工程讲义 7 设计阶段 典型用户 - 故事 - 任务 - 具体工作 https://www.cnblogs.com/xinz/archive/2011/10/30/2229236.html
2.调整任务分解WBS及相应的项目进度计划 https://www.cnblogs.com/zhengrui0452/p/6653964.html
3.BugPhobia进阶篇章：系统架构技术规格 https://www.cnblogs.com/bugphobia/p/4946840.html
4.BugPhobia进阶篇章：功能规格说明书 https://www.cnblogs.com/bugphobia/p/4946849.html