电子公文传输系统团队项目

电子公文传输系统团队项目

目录

团队作业（一）：团队展示

参考邹欣老师的博客《现代软件工程讲义 4 团队和流程》和《现代软件工程讲义 5 团队合作的阶段》，在接下来的时间里，我们将尝试以团队为单位完成一些任务。

任务一：团队组建

  • 5-8人一组，建立团队
  • 认真选择你的队友，不必限于同一个寝室/班级
  • 组建团队后，选出一名队长，并确定队名
  • 每个团队新建一个博客园账号，之后将以团队为单位，撰写并提交博客

任务二：团队展示

使用团队博客园账号，每队发表一篇随笔，内容包括：

  • 队员姓名与学号（标记组长）
  • 队名：要求有亮点与个性
  • 队员风采：介绍每一位队员的风格、擅长的技术、编程的兴趣、希望的软工角色、一句话宣言等
  • 团队的首次合照：有图有真相，合照风格可以发挥创意
  • 团队的特色描述，主要描述有别于其他所有团队的特点或核心竞争力，言简意赅
  • 可参考福州大学团队展示作业，如：【软件工程实践 · 团队项目】 第一次作业，充分发挥本小组成员的创意.

其他

  • 本次作业提交截止时间为本周日23:59
  • 队长或队员在自己的博客中附上团队博客的链接，并在此处提交
  • 每队提交一份即可

团队作业（二）：需求分析

任务一：基础技能

  • 初步熟悉团队git的协作方式。项目后续的代码、文档都要通过github增量式管理。实现文档的版本化和增量式管理。
  • 初步确立团队任务计划，将团队的任务计划添加到github的团队项目issues里。后续根据时间进度，在每个阶段统计open/closed的统计情况，同时通过工具自动生成燃尽图。（ 生成燃尽图的方式可参考使用Github生成燃尽图）
  • 采访老师或有开发经验的学长，访谈他们关于项目开发经验、团队组织方式、团队成员协作、时间周期安排等包括但不限于上述内容的采访。采访前，准备好相应的提纲，做好功课。

任务二：需求分析

  • 参考蓝墨云班课中资源，撰写本项目的《需求规格说明书》，并提交至码云。
  • 各小组发表一篇随笔，内容为：撰写《需求规格说明书》的工作流程、组员分工和组员工作量比例。
  • 在随笔中附《需求规格说明书》的Git链接（markdown文件及pdf文件，tip：pdf可由markdown转pdf工具得到）。

《需求规格说明书》要求：

  1. 参考《软件需求规格说明书》国标规范文本，撰写对应项目的软件需求规格说明书。
  2. 除形式上满足规范文本要求外，整体内容必须围绕项目实质展开，对所要开发的项目确保尽力做到清晰完整准确。
  3. 采用分层形式描述，随着“层”的深入，描述的内容细节越具体。
  4. 使用一致的图形符号和文字描述内容。
  5. 所有的缩写须事先定义。
  6. 图文并茂，通篇文档有一个统一的样式风格（对于该md文件，要求团队内每个人都需进行相应的commit，作为团队开发的第一次尝试）。
  7. 将自己置于读者的立场——如果对软件项目不熟悉的人员，通过阅读这份文档，能否完全读懂软件要做什么。
  8. 访问软件项目的真实用户，确保软件真正体现用户的需求，为软件最终可用奠定基础。
  9. 需求规格说明书里描述的细分功能、边界范围等，限定于本学期期末验收时能达到的功能，最终答辩验收将对照需求规格说明书进行。 亮点以及未来预期完成的功能，可在需求规格说明书里独立专章描述。
  10. 团队协作，加强分工，需要描述每个成员的具体分工及占整个文档任务的工作量比例。
  11. Checklist:
  • 引言(5 ')
  • 用户场景（15 '）
  • 类图（10 '）
  • 界面原型（15 '）,建议使用墨刀
  • 功能描述（20 '）
  • 验收验证标准（20 '）
  • 文档的图表、文字、样式统一且符合规范（15 '）

其他

  • 本次作业提交截止时间为本周日23:59
  • 组长或组员在自己的博客中附上团队博客的链接，并在此处提交
  • 每队提交一份即可，在博客中注明本次博客撰写人

团队作业（三）：确定分工

  1. 修改完善上周提交的需求规格说明书，并在博客中描述：上次的《需求规格说明书》初稿有哪些不足？修改需同时体现在Github的MarkDown文件与PDF中。（提示：功能考虑不全或需求文档描述缺少的地方。）（5'）

  2. 讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。（5'）

  3. 通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。(10')

  4. 进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。（15'）

  5. 确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：（15'）

    • 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
    • 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
    • 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。

  6. 描述组员在上述任务中的分工和工作量比例。

  7. 以上内容发表成一篇随笔，Alpha 版本的发布时间安排在5月下旬，请各个团队注意时间结点，尽快开始开发。

  8. 附录

团队作业（四）：描述设计

同学们已经做了需求的分析，也做了详细的系统设计，画过了一些小小的类图/用例图，对自己要做什么应该有比较清晰的认识了。接下来，我们要怎么做便成了问题。有同学会说，我大概已经知道怎么做了，在脑海里比划着，很多东西都有大致的想法，45度仰头思考片刻，有了一张宏伟的蓝图，感觉差不多可以施工了。

等等！好像不是自己一个人干，旁边还有几个身手不错的搭档，况且这对一个人来说，工作量还是很大的，那就大伙分工合作吧，给大家讲讲自己的蓝图，然后开始分工：

  • 张三做前端
  • 李四做后端
  • 王五来搞数据库
  • ...

大家热火朝天地干起了属于自己的活，若干天后，某些部分功能做得差不多了，感觉可以试试，说我们来整合联调一下：

  • 接口怎么是这样的？跟我想的不一样啊
  • 不是应该有个XXX类吗？
  • 这里不是应该用多态吗？
  • 不对，你的调用顺序错了！
  • 我要的数据没有啊！
  • ...

哪里出问题了呢？很显然是沟通问题，一个人的想法和理解，即使自己觉得很完整，很美好，但是能让别人理解一致吗？不见得，同一件事情，如果不沟通清楚，两个人的理解可能是千差万别的，所以需要有充分的沟通，尽可能减少歧义的沟通。

沟通要借助工具，我们日常使用自然语言沟通，也是一种工具，只是这种工具常常存在歧义，那么我们用什么能更加准确地描述自己的设计呢？这里推荐UML给大家。

至于UML的基础知识，课上我们讲过了。这里个人理解：把UML作为一种沟通工具来使用。沟通什么呢？沟通设计思想。

问题既然抛出来了，一个团队如何去描述讨论结果，并且确认大家理解一致，我们可能需要用到：

  • 用例图
  • 时序图
  • 状态图
  • 活动图

要做什么？

  • 大家准备如何分工合作
  • 找到自己负责部分的核心（或最复杂）模块做UML练习

博客模板

  1. 团队分工（5分）

描述团队的每个成员分别完成了UML图的哪些部分，可以选择多种方式呈现，推荐泳道图。

  1. UML（需求规格说明书里已经练习过了整个系统的UML设计，这里不需要对整个系统建模，只需要每个团队成员找到自己负责部分的核心或最复杂模块做UML练习）（20分）
  • 用例图（必选）
  • 类图（必选）
  • 活动图（必选）
  • 状态图（必选）

注：对于每个图，需描述对应的是系统哪部分、这部分面临什么样的问题、这样的设计解决了哪些问题？

  1. 工具选择（大家可以共享经验，相互推荐，谈谈为什么选择这个工具）（5分）
  • 最快的可以手画在纸上，拍照上传，后面再电子化
  • 推荐用上课讲过的WhiteStarUML
  • Visio
  • ROSE
  • 搜索选择其它工具（包括一些在线工具）...

因为一个团队为完成一个项目，为了信息完整，须将每个人的成果汇集到一篇博客中，由组长提交到作业中。

团队作业（五）：冲刺总结

冲刺（7次 Scrum）

团队在日期区间[10-15周]内，任选7天进行冲刺，冲刺当天发布一篇随笔，共7篇。具体的博文规范如下：

  • 第 1 篇 Scrum 冲刺博客对整个冲刺阶段起到领航作用，应该主要包含四个部分的内容：
    • 各个成员在 Alpha 阶段认领的任务
    • 明日各个成员的任务安排
    • 整个项目预期的任务量（使用整数表示，与项目预估的总工作小时数一致。比如项目A预估需120小时才能完成，则任务量为120。）
    • 团队成员贡献值的计算规则
  • 第 2-6篇 Scrum 冲刺博客是冲刺阶段的主要产出，主要包含四个部分的内容：
    • 各个成员今日完成的任务（如果完成的任务为开发或测试任务，需给出对应的Github代码签入记录截图；如果完成的任务为调研任务，需给出对应的调研总结博客链接；如果完成的任务为学习技术任务，需给出学习总结博客链接）
    • 各个成员遇到的问题
    • 明日各个成员的任务安排
    • 各个成员今日对项目的贡献量（使用整数表示，如无产出则为0，整个冲刺阶段所有成员的贡献量总和应与项目预期任务量相近）
  • 第 7篇 Scrum 冲刺是对冲刺阶段的总结，主要包含两个部分的内容：
    • 各个成员今日完成的任务（要求同上）
    • 项目的发布说明，主要包含：本版本的新功能，软件对运行环境的要求，系统已知的问题和限制，软件的发布方式以及发布地址。

除上述博客内容外，每次 Scrum 冲刺博客都需要提供当天站立式会议照片一张，发布项目燃尽图，并描述项目整体的进展情况。

参考博客：

http://www.cnblogs.com/ruangong3165/p/6048364.html
http://www.cnblogs.com/CSLaker/p/6079765.html

欢迎关注“rocedu”微信公众号(手机上长按二维码)

做中教，做中学，实践中共同进步！

rocedu

如果你觉得本文对你有帮助，请点一下左下角的“好文要顶”和“收藏该文”

posted @ 2020-10-06 07:28  娄老师  阅读(3292)  评论(1)  编辑  收藏  举报