题目：野趣识别---野生动物物种识别
队名：对对队
新项目地址：https://github.com/OrenAlexandotus/duiduidui
【菜鸟教程-Django】https://www.runoob.com/django/django-first-app.html
【Marktext工具】https://github.com/marktext/marktext
【2022 B站最详细django3教程(django从入门到实践)】 https://www.bilibili.com/video/BV1NL41157ph
【Django官方文档】https://docs.djangoproject.com/zh-hans/5.0/
【文心一言API使用教程】https://zhuanlan.zhihu.com/p/653708207
【金山文档】 技术问题共享文档 https://kdocs.cn/l/cvrWxEknCpPI
【金山文档】 项目经理日报(模板) https://kdocs.cn/l/cfgSzn33B46a
【金山文档】 系统测试用例模板 https://kdocs.cn/l/cb0PnwdNlYwn
【金山文档】 缺陷跟踪表 https://kdocs.cn/l/ciyycplzgnRw
【金山文档】 单元测试缺陷跟踪表 https://kdocs.cn/l/cuowGdznQVMn
【实训网站】http://training.easthome.com/ 登录：手机号+123456(项目经理：手机号+zzzxxx)
【金山文档】 团队创建报告(模板) https://kdocs.cn/l/ciVBb0IdVrRg
【金山文档】 产品待办列表（总需求） https://kdocs.cn/l/cmGLx2qCiyne
【金山文档】 Spint待办列表 https://kdocs.cn/l/ck3DnTmOwYYd
【金山文档】 简单风险追踪 https://kdocs.cn/l/ctoITEB8vqaa
- Vue、Django
- Django
| 数据集 | 地址 |
|---|---|
| 国家一级保护动物一级一二三等数据集 | https://aistudio.baidu.com/datasetdetail/127411 |
- 确定用户：
- 平台样式：
- 产品架构：
-
草图模式
-
原型创建
- 工具：墨刀
项目经理日报
一、项目整体需求分析和范围确认（今天2/26）
- 确认做什么样的产品:
- 给什么人用---确认客户
- 怎么用：Web系统;手机APP，微信小程序
- 产品架构：三层
- 构思产品的功能范围---原型创建设计每个页面需要包括的功能
- 草图模式---团队讨论，设计页面功能设计:
- 结合业务--需求分析-调研调研方式：
- 同类产品；
- 用户访谈；
- 结合业务--需求分析-调研调研方式：
- 使用工具创建原型 (墨刀) 所有成员对最终产品的功能达成一致用户对最终产品功能达成一致
- 草图模式---团队讨论，设计页面功能设计:
二、创建产品代表列表（明天2/27中午之前） 主要的内容：
- 用户故事：站在用户的角度，去描述一个功能点的作用 格式: 作为(用户角色)，我可以(功能点)，以便 (作用)作为一个还没有使用该程序的摊主，我想要在本程序中注册为用户，以便我使用这个程序管理我的摆摊的财务
- 验收条件：站在用户的角度，使用功能的正确流程
- 未注册的用户身份打开程序;系统监测到该用户为注册，则自动打开注册页面
- 用户输入正确的用户名和两次一致的密码，并且提交，系统提示新用户注册成功并跳转到登录页面。
- 当输入两次不一致密码时，系统提示两次密码不一致，注册失败
- 当输入一个已经存在的用户名并提交，系统提示该用户已经存在，注册失败
三、定义需求优先级
Scrum流程中，Scrum框架，每个迭代周期称为Sprint。
前期：确认项目范围、创建产品待办列表
进入Sprint周期，每个周期固定时长。
每个Sprint周期的任务：
- 在Sprint开始之前的半天---下一个Sprint计划会议，全体成员参加
- 定义本Sprint可用时长，人时为单位
- 团队人数(6人) * 每日有效时长(5h) * sprint天数(5天)
- 较好情况：150人时
- 按优先级对产品待办列表中的用户故事排序
- 按优先级依次对多个用户故事进行分解：完成一个用户故事，需要团队做哪些步骤：每个步骤分为一个任务
- 任务1：设计一个xxx页面
- 细节：该页面的目的是，让xxx；
- 估算时长：2人时
- 任务2：实现xxx页面的创建
- 细节：技术特点
- 估算时长：1人时
- 任务3：学习xxx
- 细节：学习xxx
- 估算时长：3人时
- 任务4：设计和实现xxx数据模型
- 细节：设计和创建一个数据模型，用来记录每个销售记录。销售记录包括：商品名称，单价，数量，交易时间。
- 估算时长：3小时
- 任务5：设计和实现后端销售记录创建功能
- 细节：在云端创建一个云函数，处理前端提交的销售数据，存储到数据库中。
- 注：实际建议设计与实现分开
- 时间：6小时
- 任务6：设计和实现销售记录的列表显示
- 细节：前端创建一个销售记录页面，可以分页展示所有销售记录。销售记录包括：商品名、数量、售价、交易
- 时间：6小时
- 任务7：设计和实现销售详情查看 6h
- 任务8：测试销售记录功能 6h
- 任务9：统计该用户故事的故事点 3h
- 任务1：设计一个xxx页面
- 统计该用户故事的故事点（总时长25） 总工时 - 上个用户故事的时长 如 120-25 = 剩余95人时
- 提取下一个优先级高的用户故事，继续分解任务……（循环）
- 填写Spint待办列表，右侧三行分别为天数、理想工作量（剩余总人时）、实际工作量，填写后对应“燃尽图”。
- 注：excel是本地表格，平台中有该部分内容。
- 任务分配：
- 待完成任务、已完成任务、无法完成的任务(Bug)。
- 注：bug要在下个sprint最先讨论
- 对应成员：昨天做了什么、今天打算做什么、遇到什么障碍。
- 待完成任务、已完成任务、无法完成的任务(Bug)。
- 定义本Sprint可用时长，人时为单位
总结：需要填写产品待办列表（总需求）和Spint待办列表。
项目管理：一个团队使用一定的规则保证项目顺利实施。
管理的选项：
- 进度管理：项目经理制定计划，在周期内，要达到的功能范围
- 进度：跟踪每个任务的完成状态：从未完成--进行中--完成
- 资源管理：人和钱
- 风险管理 障碍：阻止一个任务完成的所有因素 识别和计划所有影响项目进度的障碍的管理
- 识别风险：标记所有影响当前sprint的计划的因素，列举出来
- “简单风险追踪”表格
- 风险说明：描述该因素，如“团队中没有人做过微信小程序”；
- 后果说明：该因素会产生什么样的障碍，如“无法完成任何功能”（技术类），如“所有人不擅长页面设计，完成的用能用户体验太差”，如“东方瑞通停电，无法如期交付所有功能”，如“团队成员生病，无法如期交付”；
- 风险估算：
- 可能性（百分比）* 严重程度（1-10） = 曝光量
- 团队中没有人做过微信小程序 100% * 9 = 9，高度风险
- 风险处理
- 缓解：预防风险发生的措施
- 解决方案：风险发生后，
- 如 快速学习小程序开发、同类程序源代码、使用框架开发
- 如 云端备份
http://training.easthome.com/ 登录：手机号+123456
项目经理才有权限修改：敏捷管理、职位修改
- 修改项目描述、周期等
- 创建迭代
产品经理
- 创建需求
- 添加任务（每个人都有权限）
| 任务 | 完成状况 |
|---|---|
| 站立会议(Daily routine) | ✅ |
| 需求创建 | ✅ |
| 确定本阶段要完成的需求 | ✅ |
| sprint1对应需求的任务创建 | ✅ |
| 24：00前提交日报(daily routine) | ✅ |
一、软件系统的结构
软件产品：
- 前端（微信小程序、网页）显示和接收用户数据
- 后端（Web服务器、微信云函数）
- 数据库
- 前端和后端交互
- 需求定义——用户故事
- 查找候选对象——名词筛选
- 定义对象关系：两个名词之间是否存在“是”“包含”“使用”
- 确定对象的行为 动词 卖出 商品
- 对象持久化 一个对象的属性，发生变化，需要保存属性的值持久化对象--数据库中记录
二、数据库和服务端的设计和部署
Web类型的程序：数据库需要统一，开发人员访问的是同一个数据库
微信小程序：云开发模式
……
sprint2会议：上一个sprint完成失败的任务，这周要完成的任务。
本周需要有：测试、源代码管理。
明天上午，测试的培训
☐风险管理-感冒要加进去，概率至少30%（今天感冒请假的人特别多）
☐第一周大多数团队用户故事等设计不合理，实际上无法展开，老师没有干涉，目的：让同学通过实践体会到流程
☐复盘sprint1出现的问题，安排方面等
☐有问题随时找老师，用户设计、代码问题等随时找老师
☐每天提醒上下班打卡，不要代签到，老师数过人数
☐文档交到平台，sprint2的文档下周一早上之前必须提交
☐早上站会记录所有人当天要完成的任务以及估时（不论是否准确，要按照估时来跟踪，督促项目进度完成），晚上挨个检查是否完成，未完成要问还剩百分之几，记录，第二天早上根据燃尽图看当天是否需要弥补工作量
☐日报百分比应该是=剩余部分需要小时数/预计需要工时，不是主观填写
☐至少要有一次团建（所有人一起吃饭）
测试的目的:减少软件缺陷(bug)，保障软件质量。 一、软件测试分类
-
测试原理分类
☐黑盒测试:关注软件实现的功能
☐白盒测试:代码可见，关注代码结构和算法
☐灰盒测试:部分代码可见(接口测试)
-
测试阶段分类
☐单元测试(开发人员，白盒测试，代码的功能)
☐模块测试、集成测试(开发人员，黑盒测试为主，软件的功能)
-
☐系统测试(测试人员，系统全面测试)
- 软件的外观界面测试(简称UI测试):主要测试软件界面功能模块的布局是否合理，整体风格是否一致，界面文字是否正确，命名是否统一，页面是否美观，文字、颜色、图片组合是否完美等。测试难度:相对简单。
- 软件的功能测试:主要是测试软件所呈现给用户的所有功能点是否都能正常使用和操作，是否满足需求文档里的要求。测试难度:中等。
- 软件的性能测试:测试软件在不同环境和压力下是否能正常运转，其中有一个很重要的指标就是系统响应时间，例如多人同时访问某个网页时，网页是否能在规定的时间内打开等。测试难度:较高
- 软件的安全性测试:测试该软件防止非法侵入的能力。测试难度:较高。
- 软件的易用性测试:测试软件是否容易操作，主观性比较强，站在用户的角度体验软件产品好不好用。测试难度;相对简 单。
- 软件的兼容性测试:测试该软件与其他软件的兼容能力，比如浏览器、操作系统等。测试难度:相对简单
- ☐验收测试(用户进行的测试)
- Alpha测试
- Beta测试
-
-
是否使用工具(自动化) ☐手工测试 ☐自动化测试
二、软件测试流程
- 需求评审
- 计划编写
- 用例设计
- 用例执行
- 缺陷管理
- 测试报告
| 负责 | 完成度 |
|---|---|
| S01 | |
| S02 | |
| S03 | |
| S04 | |
由于github的限制，使用一下HTML语言进行对任务的标注：
| Description | Checkmark |
|---|---|
| HTML Entity: check mark | ✓ |
| HTML Entity: heavy check mark | ✔ |
| HTML Entity: ballot box with check | ☑ |
| HTML Entity: ballot box with x | ☒ |
| HTML Entity: ballot box (unchecked) | ☐ |
| Emoji: heavy check mark | ✔️ |
| Emoji: ballot box with check | ☑️ |
| Emoji: white check mark | ✅ |