作业要求
| 这个作业属于哪个课程 | 软件工程1916-W(福州大学) |
| 这个作业要求在哪里 | 项目Alpha冲刺 |
| 团队名称 | 基于云的胜利冲锋队 |
| 项目名称 | 云评：高校学生成绩综合评估及可视化分析平台 |
| 这个作业的目标 | alpha阶段总结 |
团队成员信息
| 队员学号 | 队员姓名 | 个人博客地址 | 备注 |
|---|---|---|---|
| 221500201 | 孙文慈 | https://www.cnblogs.com/swc221500201/ | |
| 131601207 | 陈序展 | https://www.cnblogs.com/chenxuzhan/ | |
| 221600414 | 冯凯 | https://www.cnblogs.com/codingkai/ | 队长 |
| 221600415 | 傅德泉 | https://www.cnblogs.com/dqblog/ | |
| 221600416 | 黄海山 | https://www.cnblogs.com/hhs-blog/ | |
| 221600417 | 黄乐兴 | https://www.cnblogs.com/hlxing/ | |
| 221600439 | <script> | https://www.cnblogs.com/aaaaaaaaaaaaaa/ |
设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
1.福州大学软件工程实践这门课程主要依托于博客园进行作业的线上发布、提交等环节，但由于博客园自身功能的限制，对于每次学生提交的博客及作业的成绩和统计分析往往需要老师和助教通过在Excel表格上进行许多繁琐且重复的操作才能完成，这种人工进行统计与分析的方式不仅极大的占用了助教和老师的时间，也导致同学无法直观清晰的看到自己的成绩与能力分析。我们的软件就是为了解决在实践教学中的这一痛点问题。
2.我们软件的定义是比较清楚的。
3.对于典型用户和典型场景有较清晰的描述，我们与该门课程的老师进行了多次的交流，确定了较为明确的需求。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们alpha阶段的目标是登录、注册、新建评分维度、新建班级、编辑班级、加入班级的对应功能，我们完成了所有计划的功能，按照原计划交付时间交付了，原计划并没有计划用户数量。
- 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上一个阶段相比，团队软件工程的质量提高了，主要是在于团队成员之间互相合作的默契度提高以及任务的分配更为合理，成员完成度更好。主要通过功能的完成度来衡量。
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
因为我们目前整个系统还未完成，因此用户量还无法统计。用户对重要功能的接受程度和我们事先的预想基本一致。我们离目标更近了。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我们对于需求的分析不够细致，导致前后端在某些功能出现了不统一的现象。如果历史重来一遍，我们会更加细致的分析我们的需求。
计划
- 是否有充足的时间来做计划?
团队相信好的计划规划，会避免中期走弯路，节省时间成本，所以安排了足够的时间做计划。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
同事各抒己见，在小问题上尊重队长和代码能力较强同学的想法。在大问题上，为尊重每位同学的意见，在详细阐述想法后全员投票，票出决定。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本完成。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有。
- 是否每一项任务都有清楚定义和衡量的交付件?
是。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
否，项目前端设计最早是让一位同学主要负责，但是成果并不是很能让人满意，导致后面重构代码。还是没有了解好队员的能力，是否需要协作，不是独自完成，过程也需要更多监督。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
一般在一天之内，当天完不成的任务，确保要在第二天之内加班完成，不能拖太久，否则会影响整体的项目进度。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划应该能够按时或者提前完成，因为alpha阶段我们已经对后期的工作做了整体的部署规划，部分beta阶段的任务已经完成。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了提前规划的重要性，在项目过程中，需要及时跟进队友手里的工作，把关质量，而不是最后不行重新来过。
资源
- 我们有足够的资源来完成各项任务么?
有，我们的前端和后端开发同学都有足够的项目经验和技术能力应对需求设计，项目开发和文档编写任务。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
根据以前开发类似项目的经验，估计目前各类任务的时间；经过估计时间和实际时间的比较，误差精度在一天以内。
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间，人力和软件/硬件资源基本足够，因为我们开发的同学都有一定的项目经历，对于前端和后端的开发框架比较熟悉，并且拥有阿里云服务器部署项目，加上在五一假期时间有充足完成开发测试工作；对于不需要编程的资源没有低估难度，因为这个课程对于这方面的要求较高，所以我们团队在这方面提供了足够的重视，并且也花费了较多的时间。
- 你有没有感到你做的事情可以让别人来做（更有效率）?
没有，因为我们各司其职，分工明确，在分配任务的时候充分考虑到了每个人擅长的方面。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在任务开始前总以为有较多的时间来完成任务，结果造成了前期拖延，后期忙碌的现象；改进:严格按照计划时间表来完成任务，不把今天的事情拖到明天做。
变更管理
- 每个相关的员工都及时知道了变更的消息?
可以。所有的变更消息均发布在QQ群之当中，并且都会进行口头的传递。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
评估功能的实现成本以及重要性。尽量实现项目中的关键性功能，对于一些实现难度大，花费时间超过课程结束时间的，暂时采取推迟。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
前端页面美观，用户体验良好；实现需求文档中的功能，并且功能能有一定的可靠性和容错性。
- 对于可能的变更是否能制定应急计划?
可以，小组每个成员都有相对应的任务，遇到可能的变更，会进行一定的协调和组员商讨，保证项目能够持续进行。
- 员工是否能够有效地处理意料之外的工作请求？
可以。员工都比较认真负责，包容一定范围的需求变更。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们提升了对变更请求的处理能力。如果再来一遍，我们会多经常沟通交流，理解相互之间的难处，提升团队的开发效率。
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
1.原型设计在项目原型设计答辩前一周完成的，由负责前端的同学完成的，是合适的时间，合适的人。
2.数据库和系统设计在项目原型需求最终确定之后完成的，由负责后端的同学完成的，是合适的时间，合适的人。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有些需求不是很明确，团队跟“客户”约了时间重现确认了需求。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
团队运用了junit进行单元测试，JProfile来进行性能分析，使用IDEA作为集成开发环境。UML文档和现在的大体上一样，有些不一样的部分后来已经有所更改。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
评分和作业模块涉及的数据内容比较多，分散在多张表里面，BUG比较多，在发布之前已经修复。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
使用eslint进行代码质量控制，代码整体架构和规范都有着严格的要求。
测试/发布
- 团队是否有一个测试计划？为什么没有？
团队对项目的功能模块做了集成测试，对每个类做了单元测试。
- 是否进行了正式的验收测试？
alpha阶段的功能进行了测试，正式的验收测试将在项目完成之后进行。
- 团队是否有测试工具来帮助测试？
使用postman进行接口测试.
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
十分有用，可以在开发过程中查找不足，及时做相关的修改优化。
- 在发布的过程中发现了哪些意外问题？
生产环境和开发环境的配置差异，使得项目在部署的时候存在配置问题，无法启动web服务器，之后修复了BUG并顺利发布。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1+1>2，团队整体的力量不只是每个人能力的累加，团队成员之间密切的配合可以使得整个项目的开发进度大大加快。如果历史重来，我们团队可能会在前期需求方面做更加细致的调研。
团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
根据每个成员擅长的技能和个人意愿进行分配，每个成员都得到了满意的岗位。
- 团队成员之间有互相帮助么？
成员之间互帮互助，有不懂的地方，大家都会热心的去帮助解决。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
开会讨论产生解决办法。
总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
可重复级(Repeatable)档次。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
创造阶段
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
大家配合更加默契，项目开发逐渐走上正轨。
- 你觉得目前最需要改进的一个方面是什么?
项目整体实现细节有待优化。
- 其它软件工具的应用，应该如何提高？
边学边用，在实践中掌握。
- 项目文档的质量如何提高？
团队整体强制使用同一的规范进行约束，后期再进行文档复审。
感谢环节
-
陈序展：感谢fk同学对我的帮助，因为我是初次接触Vue框架，学习和使用过程中遇到一些问题，冯凯同学每次都会热心地帮我解决问题。
-
冯凯：感谢团队的每一位成员，大家在项目合作期间都各司其职，认真对待自己负责的任务，期间大家都很配合其他人的工作，为项目的顺利开发打下了基础，希望大家能够再接再厉。
-
黄海山：感谢fk同学每天为我们提供详细的任务需求，使得开发任务清晰明确，效率高。每天都会认真地整理我们汇总的博客资料，还会耐心地指出其中的不足，提供修改建议。
-
黄乐兴：感谢codingKai对我的帮助。在这次项目中，组长规划了每个组员的工作，并定下了一个又一个的DDL，让我能有一定的压迫感，更加高效地去编写程序。当我遇到困难后，组长也会耐心地引导我，为我提供一定的帮助。
交换组员的工作交接和培训方案
工作交接：
- 新来的成员在之前的团队中负责的部分和本团队“离职”的成员在业务上基本一致，因此web端的基本功还是有的，只需要对vue框架的使用和团队的代码规范做进一步要求和学习即可。
培养计划
- 学习vue框架的使用和组件化开发
- 熟悉项目的接口的对接
- 对项目的代码规范做要求，保证新编写的代码完全符合本团队的代码规范
- 对界面的整体样式做统一要求，保证新开发的界面的样式和原来的样式基本一致
alpha阶段总结开会照片
