103
社区成员
发帖
与我相关
我的任务
分享晴空ClearSky——CodeArts团队实战总结
| 这个作业属于哪个课程 | 2501_CS_SE_FZU |
|---|---|
| 团队名称 | 晴空ClearSky |
| 这个作业要求在哪里 | 软工实践——CodeArts团队实战总结 |
| 这个作业的目标 | 极限编程，构建基于大语言模型的购车决策软件，训练快速开发能力 |
| 其他参考文献 | 《构建之法 现代软件工程》第三版 邹欣著 |
目录
- 1.项目地址
- 2. CodeArt的提交日志截图与组员提交次数
- 3. 程序运行环境
- 4. 程序截图说明
- 4.1 用户登录
- 4.2 用户注册
- 4.3 主界面导航
- 4.4 购车咨询服务
- 4.5 历史咨询记录
- 4.6 礼品积分兑换
- 个人信息管理
- 5. 功能实现思路
- 5.1 功能需求建模分析
- 5.2 体系结构设计
- 5.3 数据库设计
- 5.4 接口设计
- 5.5 关键模块设计
- 5.5.1 用户模块
- 5.5.2 购车咨询模块
- 5.5.3 礼品兑换模块
- 6. 组员职责分工
- 7. 组员贡献比例
- 8. 合作中遇到的困难与解决方法
- 9. PSP表格
- 10. 极限编程总结
1.项目地址
使用演示视频如下：
2. CodeArt的提交日志截图与组员提交次数
| 组员 | 有效提交次数 |
|---|---|
| 102300107陈沁怡 | 3 |
| 102300121潘剑华 | 3 |
| 102300207郑晗希 | 3 |
| 102300211陈国明 | 3 |
| 102300405杨雅婷 | 8 |
| 102300408高榕苓 | 4 |
| 102300432邹皓 | 19 |
| 102300434陈昊 | 8 |
3. 程序运行环境
- 可完整运行使用的网页http://8.148.213.29/
- 前端代码环境：Vue.js + TypeScript
- 后端代码环境：Java 21+Spring Boot+MyBatis+MySQL
- 服务器环境：Ubuntu 24.04 64位
4. 程序截图说明
4.1 用户登录
用户登录（获取 JWT Token 进行后续请求认证）。
4.2 用户注册
用户注册（需满足用户名为9位纯数字，密码至少8位且包含字母和数字）。
4.3 主界面导航
默认展示用户个人信息，可导航至购车咨询、历史记录查看、礼品积分兑换等功能模块。
4.4 购车咨询服务
支持选择 AI 模型（默认 qwen3-max 或 deepseek-v3）。
对话前收集用户购车预算、喜好车型等信息。
实时与 AI 进行购车相关对话交流。注意：当前项目未选用流式输出，生成时间较长约为20s左右，因为大语言模型会一次性综合思考给出推荐车型，但是用户可以继续追加提问。
完成一次咨询后奖励 10 积分。
4.5 历史咨询记录
查看所有历史购车咨询记录。
点击具体记录查看详情对话内容。
4.6 礼品积分兑换
显示当前用户积分余额。
展示可兑换礼品列表及库存情况。
支持在线兑换并填写收货地址。
提供兑换历史查询功能。
个人信息管理
展示并允许修改用户基本信息（真实姓名、性别、手机号等）。
可设置默认购车预算和偏好车型。
5. 功能实现思路
5.1 功能需求建模分析
- 简单需求如下：
用户认证界面
（1）提供用户登录界面，提供一个用户名输入框，提供一个密码输入框，以及一个登录按钮，一个注册按钮。若用户名或密码错误，提示用户。登录成功后进入主界面。
（2）提供用户注册界面，提供一个用户名输入框，提供一个密码输入框以及密码二次确认输入框、一个注册按钮。要求用户名为9位纯数字，密码至少8位并且需要包含字母和数字。同时注册时需要二次输入密码确保两次输入的密码一致，校验逻辑由前端完成，两次输入密码一致性由前端校验，后端不做检查，后端只接受传来的用户名和密码信息。注册成功后跳转登录界面。
主界面
主界面提供功能导航栏，需要包含“购车咨询”、“咨询记录查看”、“礼品积分兑换”、“用户个人信息”，点击后跳转对应界面，默认显示用户个人信息界面。
购车咨询对话界面
（1）构建一个类似AI对话的界面，同时提供一个大语言模型下拉选择框，默认提供两个选择qwen3-max、deepseek-v3，默认选择qwen3-max。
（2）在开始对话前，弹出表单，要求用户设置自己的购车预算、喜好车型（SUV、轿车、MPV等）、主要使用场景（通勤、家庭、商务等）、燃料类型偏好（燃油、电动、混动等），购车预算与喜好车型默认从用户个人信息获取，但是仍然要以可编辑输入框形式展示，其它信息以表单输入框形式要求用户输入。填写完表单后就与常规AI对话一致，用户发送消息，AI回复消息。提供一个结束对话按钮，点击后结束对话，跳转到主界面。用户每次完成一次购车咨询对话后自动获得10积分。
历史咨询记录查看界面
展示当前用户所有历史咨询记录，点击后能够展示对应的咨询历史记录。
礼品积分兑换界面
（1）展示当前用户积分余额，展示礼品列表，一个兑换历史查询按钮，每个礼品展示一个图片、礼品名称、库存、所需积分数量以及一个兑换按钮。
（2）用户点击兑换若积分充足提示用户是否确认兑换，若确认兑换，弹出表单提示用户填写收货人姓名、收货人电话、收货地址。
（3）填写完成后用户可在兑换历史查询查看兑换记录。
用户个人信息界面
展示用户个人信息，包括用户名，真实姓名，性别，手机号，购车预算，喜好车型，除用户名外点击后可修改。
用况图分析如下：
最终形成的设计类图如下：
5.2 体系结构设计
简单分为前后端快速开发，前端采用vue.js框架，后端采用SpringBoot+MyBatis框架。
5.3 数据库设计
用户表users：
需要包含id,username,password,real_name,gender,phone,budget,like_cars,points.
id作为自增主键标识用户，username存储9位数字用户名，password存储用户加密后的密码，real_name存储用户真实姓名，gender存储用户性别可枚举值（MALE、FEMALE、OTHER）,phone存储用户手机号，budget存储用户购车预算（单位万元），like_cars以字符串存储用户喜好车型，points存储用户积分数量
购车对话表chat：
需要包含id,user_id,model,created_at.
id作为自增主键标识对话，user_id作为外键关联用户，model用于标识对话的AI模型名称，create_at标识对话的创建时间
购车对话信息表message：
需要包含id,chat_id,sender,content,created_at.
id作为自增主键标识对话消息，chat_id作为外键关联购车对话表，sender标识消息发送方可枚举值（USER，AI），content为发送的文本信息，created_at标识消息的创建时间
礼品表gifts：
需要包含id,name,need_points,numbers,icon_url
id作为自增主键标识礼品，name存储礼品名称，need_points存储兑换该礼品需要的积分数量，numbers存储该礼品的库存数量，icon_url存储该礼品的图片URL地址
礼品兑换表gifts_get:
需要包含id,user_id,gift_id,name,phone,address,created_at
id作为自增主键标识礼品兑换信息，user_id作为外键关联用户表，gift_id作为外键管理礼品表，name存储收货人姓名，phone存储收货人手机号，address存储收货地址，created_at标识兑换信息的创建时间
数据库建库文件如下：
5.4 接口设计
接口基础路径：http://8.148.213.29:8081/api/v1
状态码说明
| 状态码 | 说明 |
|---|---|
| 200 | 成功 |
| 400 | 请求参数错误 |
| 401 | 未认证 |
| 403 | 权限不足 |
| 404 | 资源不存在 |
| 500 | 服务器内部错误 |
认证要求: 除注册、登录接口外，其他接口都需要在Header中携带JWT Token
用户模块
（1）用户注册（/auth/register）POST请求
（2）用户登录（/auth/login）POST请求
（3）获取用户信息（/auth/profile）GET请求
（4）设置用户信息（/auth/profile）POST请求
购车咨询模块
（1）发起购车咨询请求（/chat/create）POST请求
（2）发送咨询信息（/chat/messages）POST请求
（3）结束购车咨询请求（/chat/end）POST请求
（4）获取当前用户的咨询记录列表（/chat/history/{userID}）GET请求
（5）根据咨询记录ID获取咨询记录详情（/chat/history/detail/{historyId}）GET请求
积分兑换模块
（1）查询当前用户积分（/points）GET请求
（2）获取可兑换礼品列表（/points/gifts）GET请求
（3）兑换周边礼品（/points/gifts）POST请求
（4）填写收货地址（/points/gifts/address）POST请求
（5）查询当前用户礼品兑换信息（/points/gifts/my）GET请求
API接口详细文档如下：
5.5 关键模块设计
5.5.1 用户模块
用户模块负责用户身份验证、注册、登录和个人信息管理功能。
主要组件：
实体类：User - 存储用户基本信息，包括用户名、密码、个人信息及积分等
控制器：AuthController - 提供REST API接口处理用户注册、登录、获取和更新个人信息
服务层：AuthService 及其实现 AuthServiceImpl - 实现用户业务逻辑
数据访问层：UserMapper 及其XML映射文件 - 处理数据库操作
功能特点：
使用JWT进行身份验证和授权
密码采用BCrypt加密存储
支持用户基本资料维护（真实姓名、性别、电话等）
记录用户购车偏好信息（预算、喜好车型）
5.5.2 购车咨询模块
购车咨询模块基于LangChain4j框架实现与AI模型的交互，为用户提供购车建议。
主要组件：
实体类：Chat 和 Message - 分别表示咨询会话和消息记录
控制器：ChatController - 提供创建咨询、发送消息、结束咨询等API
服务层：ChatService 及其实现 ChatServiceImpl - 处理咨询业务逻辑
AI代理：AiCounselor 接口及其实现服务 - 与AI模型通信
内存管理：ChatMemoryPersistence - 管理对话历史的持久化存储
功能特点：
支持多种AI模型（qwen3-max、deepseek-v3等）
对话历史持久化存储到数据库
根据用户个人偏好（预算、喜好车型等）提供个性化购车建议
完整的对话生命周期管理（创建、进行中、结束）
5.5.3 礼品兑换模块
礼品兑换模块允许用户使用积分兑换实物礼品，并管理兑换记录。
主要组件：
实体类：
Gift - 表示可兑换的礼品
GiftGet - 表示用户兑换记录
控制器：PointsController - 提供积分查询、礼品兑换相关API
服务层：PointsService 及其实现 PointsServiceImpl - 处理积分和礼品业务逻辑
数据访问层：GiftMapper 和 GiftGetMapper 及其XML映射文件
功能特点：
用户完成咨询会话后可获得积分奖励
支持浏览可兑换礼品列表
积分不足时禁止兑换
兑换后需填写收货地址完成整个兑换流程
实时更新礼品库存数量
6. 组员职责分工
| 组员 | 分工 |
|---|---|
| 102300107陈沁怡 | 前端查询咨询历史记录界面及其功能构建 |
| 102300121潘剑华 | 前端登录、注册界面及其功能构建 |
| 102300207郑晗希 | 前端购车咨询对话页面及其功能构建 |
| 102300211陈国明 | 前端主负责人，构建整体页面框架，协调各前端工作，前端服务器部署 |
| 102300405杨雅婷 | 测试后端接口、编写测试数据、系统功能测试与验收、生成用户使用文档 |
| 102300408高榕苓 | 前端积分兑换礼品界面及其功能构建 |
| 102300432邹皓 | 功能需求分析、用况图绘制、系统架构设计、数据库设计、API设计、后端构建、后端测试、后端服务器部署、撰写博客 |
| 102300434陈昊 | 前端用户个人信息界面及其功能构建、类图绘制 |
7. 组员贡献比例
| 组员 | 实际工作内容 | 贡献度 |
|---|---|---|
| 102300107陈沁怡 | 前端查询咨询历史记录界面（纯UI，无功能） | 9% |
| 102300121潘剑华 | 前端登录、注册界面及其美化（纯UI，无功能） | 9% |
| 102300207郑晗希 | 前端购车咨询对话页面及其美化与接口对接部分逻辑实现 | 11% |
| 102300211陈国明 | 前端主负责人，构建整体页面框架，协调各前端工作 | 12% |
| 102300405杨雅婷 | 测试后端接口、编写测试数据、系统功能测试与验收、生成用户使用文档 | 13% |
| 102300408高榕苓 | 前端积分兑换礼品界面及其功能构建 | 11% |
| 102300432邹皓 | 功能需求分析、用况图绘制、类图生成、系统架构设计、数据库设计、API设计、后端构建、后端测试、后端服务器部署、前端对接、前端功能实现、美化前端界面添加css样式、部署前端到服务器、撰写博客 | 25% |
| 102300434陈昊 | 前端用户个人信息界面及其功能构建 | 10% |
8. 合作中遇到的困难与解决方法
| 成员 | 遇到困难 | 解决方法 |
|---|---|---|
| 102300107陈沁怡 | 对vue文件组件不熟悉，设置为HTML文件，git使用不熟练。 | 研究学习相关知识，和小组成员多请教。 |
| 102300121潘剑华 | 对于git命令的使用不够熟练，对于前后端的对接没有清晰的认知。 | 上网查阅资料，询问小组成员。 |
| 102300207郑晗希 | 页面在初次实现时布局错乱，按钮点击事件未能正常触发；同时在样式适配不同分辨率时出现显示问题。 | 通过调试日志逐步定位问题，调整组件层级与约束关系，参考官方文档修改布局属性；同时利用模拟器多设备测试，确保页面在不同分辨率下正常显示。 |
| 102300211陈国明 | 前后端api对接产生跨域问题，浏览器拒绝访问。 | 前端采用proxy代理。 |
| 102300405杨雅婷 | 对数据库表之间的外键依赖关系理解不够清晰，初期设计的测试数据存在引用无效 ID 的问题；JSON 类型字段（如 like_cars）格式不规范导致插入失败；缺乏真实业务场景经验，难以模拟合理的用户偏好和兑换行为。 | 仔细阅读数据库；使用在线 JSON 校验工具确保字段格式合法；参考主流汽车平台（如汽车之家、懂车帝）的用户交互逻辑，结合项目需求合理虚构典型用户数据；与后端开发同学及时沟通，确认字段语义和业务边界。 |
| 102300408高榕苓 | 前端礼品数据结构与后端接口字段不一致，初次对接时兑换列表及历史信息展示为空。 登录功能改为真实接口后，浏览器因跨域限制阻止请求，导致无法获得 token。 | 阅读后端 PointsController 与实体定义，对照 API 文档统一 GiftExchange、GiftCard 的字段命名与请求体结构。 在 Vite 开发服务器配置 /api 代理并将 axios 基础路径改为相对地址，开发环境通过代理转发请求，成功避开 CORS 限制。 |
| 102300432邹皓 | 用户的购车预算等初始化信息无法正确传递给LLM对其进行初始化，对话过程中LLM未能获取到正确信息。 | 添加多处调试日志，给出折中解决办法，移除了对系统消息的过滤，现在系统消息也会存储到数据库中。在getChatDetail方法中添加了过滤逻辑，通过检查消息内容是否以特定文本开头来识别系统消息。过滤掉系统消息后返回给用户，确保用户不会看到冗长的系统提示。系统消息仍然存储在数据库中，保证AI能够获取到必要的上下文信息。这样既能满足功能需求（AI正确获取用户信息），又能保证用户体验（用户界面不会暴露系统消息给用户）。 |
| 102300432陈昊 | 此前未学习过Vue框架的使用，对Vue框架的环境配置不太熟悉。不了解华为云仓库的使用方法，上传代码与下载代码不太熟练。 | 上网搜寻相关资料进行学习并进行相关的练习。与小组成员进行协作探讨，不懂的地方向小组成员讨教。 |
9. PSP表格
- 102300107陈沁怡
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划（包括下列1点） | 40 | 20 |
| • Estimate | • 估计这个任务需要多少时间 | 40 | 30 |
| Development | 开发（包括下列8点） | 600 | 660 |
| • Analysis | • 需求分析（包括学习新技术） | 30 | 40 |
| • Design Spec | • 生成设计文档 | 40 | 40 |
| • Design Review | • 设计复审 | 20 | 30 |
| • Coding Standard | • 代码规范（为目前的开发制定合适的规范） | 10 | 20 |
| • Design | • 具体设计 | 100 | 100 |
| • Coding | • 具体编码 | 200 | 220 |
| • Code Review | • 代码复审 | 50 | 40 |
| • Test | • 测试（自我测试、修改代码、提交修改） | 150 | 140 |
| Reporting | 报告（包括下列3点） | 200 | 200 |
| • Test Report | • 测试报告 | 50 | 60 |
| • Size Measurement | • 计算工作量 | 30 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结并提出过程改进计划 | 120 | 120 |
| 合计（Planning+Development+Reporting） | 840 | 810 |
- 102300121潘剑华
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划（包括下列1点） | 40 | 30 |
| • Estimate | • 估计这个任务需要多少时间 | 40 | 30 |
| Development | 开发（包括下列8点） | 600 | 650 |
| • Analysis | • 需求分析（包括学习新技术） | 30 | 30 |
| • Design Spec | • 生成设计文档 | 40 | 50 |
| • Design Review | • 设计复审 | 20 | 30 |
| • Coding Standard | • 代码规范（为目前的开发制定合适的规范） | 10 | 10 |
| • Design | • 具体设计 | 100 | 120 |
| • Coding | • 具体编码 | 200 | 200 |
| • Code Review | • 代码复审 | 50 | 50 |
| • Test | • 测试（自我测试、修改代码、提交修改） | 150 | 160 |
| Reporting | 报告（包括下列3点） | 200 | 200 |
| • Test Report | • 测试报告 | 50 | 40 |
| • Size Measurement | • 计算工作量 | 30 | 40 |
| • Postmortem & Process Improvement Plan | • 事后总结并提出过程改进计划 | 120 | 120 |
| 合计（Planning+Development+Reporting） | 840 | 880 |
- 102300207郑晗希
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划（包括下列1点） | 40 | 35 |
| • Estimate | • 估计这个任务需要多少时间 | 40 | 35 |
| Development | 开发（包括下列8点） | 600 | 520 |
| • Analysis | • 需求分析（包括学习新技术） | 30 | 40 |
| • Design Spec | • 生成设计文档 | 40 | 35 |
| • Design Review | • 设计复审 | 20 | 15 |
| • Coding Standard | • 代码规范（为目前的开发制定合适的规范） | 10 | 10 |
| • Design | • 具体设计 | 100 | 80 |
| • Coding | • 具体编码 | 200 | 180 |
| • Code Review | • 代码复审 | 50 | 40 |
| • Test | • 测试（自我测试、修改代码、提交修改） | 150 | 120 |
| Reporting | 报告（包括下列3点） | 200 | 180 |
| • Test Report | • 测试报告 | 50 | 45 |
| • Size Measurement | • 计算工作量 | 30 | 25 |
| • Postmortem & Process Improvement Plan | • 事后总结并提出过程改进计划 | 120 | 110 |
| 合计（Planning + Development + Reporting） | 840 | 735 |
- 102300211陈国明
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划（包括下列1点） | 50 | 50 |
| • Estimate | • 估计这个任务需要多少时间 | 50 | 50 |
| Development | 开发（包括下列8点） | 560 | 570 |
| • Analysis | • 需求分析（包括学习新技术） | 60 | 60 |
| • Design Spec | • 生成设计文档 | 30 | 30 |
| • Design Review | • 设计复审 | 10 | 20 |
| • Coding Standard | • 代码规范（为目前的开发制定合适的规范） | 10 | 10 |
| • Design | • 具体设计 | 100 | 100 |
| • Coding | • 具体编码 | 200 | 200 |
| • Code Review | • 代码复审 | 40 | 30 |
| • Test | • 测试（自我测试、修改代码、提交修改） | 150 | 120 |
| Reporting | 报告（包括下列3点） | 200 | 180 |
| • Test Report | • 测试报告 | 50 | 60 |
| • Size Measurement | • 计算工作量 | 30 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结并提出过程改进计划 | 120 | 100 |
| 合计（Planning+Development+Reporting） | 810 | 800 |
- 102300405杨雅婷
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划（包括下列1点） | 40 | 30 |
| • Estimate | • 估计这个任务需要多少时间 | 40 | 30 |
| Development | 开发（包括下列8点） | 580 | 600 |
| • Analysis | • 需求分析（包括学习新技术） | 60 | 60 |
| • Design Spec | • 生成设计文档 | 40 | 30 |
| • Design Review | • 设计复审 | 20 | 20 |
| • Coding Standard | • 代码规范（为目前的开发制定合适的规范） | 10 | 10 |
| • Design | • 具体设计 | 100 | 130 |
| • Coding | • 具体编码 | 200 | 190 |
| • Code Review | • 代码复审 | 50 | 60 |
| • Test | • 测试（自我测试、修改代码、提交修改） | 100 | 100 |
| Reporting | 报告（包括下列3点） | 200 | 150 |
| • Test Report | • 测试报告 | 60 | 30 |
| • Size Measurement | • 计算工作量 | 30 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结并提出过程改进计划 | 110 | 100 |
| 合计（Planning+Development+Reporting） | 820 | 780 |
- 102300408高榕苓
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划（包括下列1点） | 40 | 25 |
| • Estimate | • 估计这个任务需要多少时间 | 40 | 25 |
| Development | 开发（包括下列8点） | 600 | 410 |
| • Analysis | • 需求分析（包括学习新技术） | 30 | 35 |
| • Design Spec | • 生成设计文档 | 40 | 35 |
| • Design Review | • 设计复审 | 20 | 20 |
| • Coding Standard | • 代码规范（为目前的开发制定合适的规范） | 10 | 10 |
| • Design | • 具体设计 | 100 | 60 |
| • Coding | • 具体编码 | 200 | 170 |
| • Code Review | • 代码复审 | 50 | 30 |
| • Test | • 测试（自我测试、修改代码、提交修改） | 150 | 50 |
| Reporting | 报告（包括下列3点） | 200 | 95 |
| • Test Report | • 测试报告 | 50 | 25 |
| • Size Measurement | • 计算工作量 | 30 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结并提出过程改进计划 | 120 | 50 |
| 合计（Planning+Development+Reporting） | 840 | 530 |
- 102300432邹皓
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划（包括下列1点） | 40 | 30 |
| • Estimate | • 估计这个任务需要多少时间 | 40 | 30 |
| Development | 开发（包括下列8点） | 600 | 505 |
| • Analysis | • 需求分析（包括学习新技术） | 30 | 40 |
| • Design Spec | • 生成设计文档 | 40 | 40 |
| • Design Review | • 设计复审 | 20 | 10 |
| • Coding Standard | • 代码规范（为目前的开发制定合适的规范） | 10 | 5 |
| • Design | • 具体设计 | 100 | 50 |
| • Coding | • 具体编码 | 200 | 150 |
| • Code Review | • 代码复审 | 50 | 30 |
| • Test | • 测试（自我测试、修改代码、提交修改） | 150 | 180 |
| Reporting | 报告（包括下列3点） | 200 | 185 |
| • Test Report | • 测试报告 | 50 | 120 |
| • Size Measurement | • 计算工作量 | 30 | 15 |
| • Postmortem & Process Improvement Plan | • 事后总结并提出过程改进计划 | 120 | 50 |
| 合计（Planning+Development+Reporting） | 840 | 720 |
- 102300432陈昊
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划（包括下列1点） | 40 | 20 |
| • Estimate | • 估计这个任务需要多少时间 | 40 | 20 |
| Development | 开发（包括下列8点） | 600 | 650 |
| • Analysis | • 需求分析（包括学习新技术） | 30 | 40 |
| • Design Spec | • 生成设计文档 | 40 | 20 |
| • Design Review | • 设计复审 | 20 | 20 |
| • Coding Standard | • 代码规范（为目前的开发制定合适的规范） | 10 | 10 |
| • Design | • 具体设计 | 100 | 120 |
| • Coding | • 具体编码 | 200 | 300 |
| • Code Review | • 代码复审 | 50 | 40 |
| • Test | • 测试（自我测试、修改代码、提交修改） | 150 | 100 |
| Reporting | 报告（包括下列3点） | 200 | 150 |
| • Test Report | • 测试报告 | 50 | 30 |
| • Size Measurement | • 计算工作量 | 30 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结并提出过程改进计划 | 120 | 100 |
| 合计（Planning+Development+Reporting） | 840 | 820 |
10. 极限编程总结
基于大语言模型的购车决策软件顺利开发完成，完成了基础功能和附加功能1礼品积分兑换模块构建。
组长附言：
这次项目的经历与大家最初接触实践课程相比有很大进步改善。但是本次极限编程项目小组成员协作能力需要提升，需要加强自学能力，项目开发过程中Git版本控制工具使用几乎都不熟练，经常出现成员随意修改文件，将存在错误的代码添加到代码仓库中的情况。组长在指导组员学习使用各种工具上花费了超过编码的时间，大家必须加强学习，Git帮助版本控制是非常有利于团队协作开发的。
其次，团队成员自身要加强学习，提升技术水平，部分成员对于分配的简单前端模块，只能够完成简单界面设计，具体功能实现和界面样式美化存在不足。
本次任务实际的后端全部由组长构建实现，前端也参与了几乎60%的工作量，并且前后端服务器部署均要组长实现。这与最初给大家分配的任务量出现了很大偏差，希望组员们能加强自己的能力，再接再励。
最后，组长想和组员们说，这门实践课程不是为了给大家带去压力，而是为了让大家了解学习一个软件项目是如何运作的，自己亲身参与其中，边做边学。我们其中不乏有很大部分成员是第一次接触前后端分离的项目或是第一次参与完整项目开发，很多地方存在困难可以理解。但是请记住，只要学有所得，大家的努力就有意义，这门实践课程的付出将会是大家迈向新高度的台阶，晴空的成员们，加油！
...全文
请发表友善的回复…
发表回复
