团队作业3-需求改进&系统设计
团队作业3-需求改进&系统设计
| 这个作业属于哪个课程 | 22计科1 — 软件工程 |
|---|---|
| 这个作业的要求在哪里 | 团队作业3-需求改进&系统设计 |
| 这个作业的目标 | 对需求进行改进，给出系统的架构设计，制定Alpha任务分配计划和测试计划 |
一、需求&原型改进
1.1 需求改进：
问题1：由于每个人对于消费类型的理解不同，我们设计了账目的自定义添加分类的功能，但并未考虑到有些人可能比较懒，更愿意用已有的分类来添加。
修改1：用户除了能自定义添加分类，还可以用我们提供的类别直接标记，例如：餐饮、服饰、医疗、旅行、教育、交通等类别。
问题2：估计的用户量太保守，可以面向全校的学生。
修改2：更改用户量为1000-3000。
问题3：主界面模块中导入导出功能其实用处不大
修改3：去掉这个功能。
1.2 完善需求规格说明书
场景描述:
学生小明打算使用我们的简易记账系统，他需要先注册，设置好密码后即可登录，他可以修改用户头像和密码，也可以修改主题皮肤，如果对于软件存在疑问，可以查看软件帮助说明。早上去饭堂吃了早餐，花了8块钱，他打开我们的简易记账系统，点击“添加”功能，把这笔支出添加进去，可以选择“餐饮”分类，也可以自定义分类。
用户场景如下:
小明想要记录自己的开销，查看自己每日，甚至周，月，年的各个方面的消费占比，从而做到理性消费。小明希望这个软件记账可以快速简洁，也可以满足自己偶尔细致的分类。总结查看时可以清晰明了。
简易记账系统解决方式：
小明注册登录系统后，可修改头像，主题皮肤等，调整到自己喜欢样式。记录时，小明可以选用已经提供的分类，也可以选择自定义类别来满足自己细微的分别。当小明想查看自己的账目数据时，有多种图可以展示，如条形图，折线图，饼图等。同时，如果对某类开销有疑惑可以选择查询进行查看。例如：小明今日生日收到朋友家人的红包，他想单独分类可选择自定义添加为“生日红包”，两个月后，他查看时对该月的收入表示疑惑，进行查询理清来源。
1.3 功能分析
参考《构建之法》5节功能的定位和优先级，给出功能分析的四个象限
| 外围功能 | 杀手功能 |
|---|---|
| 必须要求 | 账目记录功能 |
| 辅助要求 | 展示功能 |
1.4 调整WBS及计划
根据修改后的需求，调整任务分解WBS及相应的项目进度计划
二、系统设计
在设计阶段，我们要清楚：软件是怎么解决这些需求的？一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。
2.1系统的架构设计
本系统采用javaweb MVC（Model-View-Controller）设计模式。
M即model模型是指模型表示业务规则。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，模型与数据格式无关，这样一个模型能为多个视图提供数据，由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
V即View视图是指用户看到并与之交互的界面。比如由html元素组成的网页界面，或者软件的客户端界面。MVC的好处之一在于它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，它只是作为一种输出数据并允许用户操纵的方式。
C即controller控制器是指控制器接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。
根据设计模式，src包下建立以下功能包：bean（功能模型实体类包）、view（界面视图文件包）、controller（控制类包）、dao（相关数据库操作包）、Utils（工具类包）
2.2 数据库设计
用户数据表（users）
| NO | 列名 | 类型 | 说明 |
|---|---|---|---|
| 1 | uID | int(10) | 用户表ID号 |
| 2 | name | varchar(20) | 用户名 |
| 3 | password | varchar(20) | 密码 |
| 4 | image | varchar(200) | 头像图片路径 |
收入支出分类表（classification）
| NO | 列名 | 类型 | 说明 |
|---|---|---|---|
| 1 | cf_ID | int(10) | 分类表ID号 |
| 2 | cName | varchar(20) | 分类名称 |
| 3 | cType | varchar(20) | 分类类型（收入支出） |
具体信息表（information）
| NO | 列名 | 类型 | 说明 |
|---|---|---|---|
| 1 | in_ID | int(10） | 信息表ID号 |
| 2 | uID | int(10) | 用户ID |
| 3 | inType | varchar(20) | 分类类型（收入支出） |
| 4 | money | float | 收入支出金额 |
| 5 | kinds | varchar(20) | 收入或支出的内部分类 |
| 6 | memo | varchar(3000) | 信息备注 |
| 7 | date | date | 记录日期 |
2.3 项目ER图
三、Alpha任务分配计划
3.1 Product Backlog和Sprint Backlog
3.2 甘特图
四、测试计划
4.1 引言
项目背景
该产品主要面向用户为个人或家庭，简单，方便，可以满足日常的需求。在实际操作过程中，我们开发的简易记账管理系统主要应用于我们在校学生的记账情况，以及一个家庭的收入支出情况，不涉及贷款、债权债务等复杂数据统计。作为学生，每个月的生活费有限，如果不记账的话很容易超出金额消费，不仅会给家庭带来负担，也会出现月末被迫做廉价的大学生兼职的现象，甚至是大学生贷款的现象。此项目系统能很好地帮助我们进行个人的消费分析，有助于改正自己不合理的消费习惯，为今后的财务管理做铺垫。
参考资料
《需求规格说明书》
测试术语
黑盒测试，功能测试，压力测试，测试项
黑盒测试（Black Box Testing）
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
压力测试（StressTesting）
压力测试也称为强度测试，通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。压力测试需要确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大的服务级别。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。
有关项目人员组成
王伊若 黄锐 江佳哲 叶尔森·玛合沙提
4.2 任务概述
测试范围
该项目所需的功能模块、功能与数据库
测试目标
所有功能均能正常实现,能承受计划所要求的用户量
4.3 测试策略
测试方法
手动测试、黑盒测试、压力测试
工具引用及测试培训
手动，内训
测试阶段计划
整体计划：功能测试->整体测试->压力测试
| 工作内容 | 人员安排 | 测试时间 |
|---|---|---|
| 测试用户注册及登录功能 | 黄锐 | 开发全过程 |
| 测试账目记录的增删查改 | 江佳哲 | 开发全过程 |
| 测试账目查询功能 | 叶尔森·玛合沙提 | 开发全过程 |
| 测试账目数据展示 | 王伊若 | 开发全过程 |
| 测试数据库的记录和恢复 | 王伊若 | 开发全过程 |
| 测试整体功能 | 全体人员 | 上线前一周 |
| 进行压力测试 | 全体人员 | 上线前一周 |
测试停止及恢复条件
测试停止条件：开发人员需要更改代码
恢复条件：确认代码修改无误
4.4 测试资源
硬件资源需求
PC机，笔记本
软件资源需求
windows10，sqlsever，IntelliJ IDEA
测试环境需求
移动网络或WIFI
4.5 风险评估
-
人力方面：人力充足
-
时间方面：边开发边测试，可以省时间
-
环境方面：面向百度进行配置
-
资源方面：资源充足
