文章目录

• 一、实训介绍
• • 1.1 实训目的
  • 1.2 角色职责分配
  • • 产品经理
    • 项目经理
    • IT 总监
    • 后端程序员
    • 前端程序员
    • 测试人员
  • 1.3 实训过程
• 二、实训记录
• • Day 1 需求文档
  • Day 2 项目管理文档
  • Day 3 数据库设计、接口设计和详细设计
  • Day 4 前后端编码和测试
  • Day 5 使用手册与评估
• 三、实训总结

一、实训介绍

本次软件工程实训是我们专业大四开设的一门课程，是大四学年唯一的一门实践课。从 9月5日 ~ 9月9日，共5天时间，前四天早上8点20到晚上9点20，最后一天早上8点20到下午4点，共 50+ 课时，其中大部分时间是我们小组讨论。正式结束，共五天时间。

小组成员共有三位：

• 龙 L 同学
• 浩 H 同学
• 超 C 同学（我）

正常情况下一个小组是六个人来着，不过老师说可以自由组队，最后没有剩下的同学了，就我们三人组成了一队，然后本次实训中是一人同时分担两个角色。（超累的）

本次实训的内容接下来会进行说明，简单理解就是模拟企业中一个软件产品开发的整个流程，我们各自分担不同的角色，担任不同的职责，当然只是开发一个小Demo，达不到企业中真正的水准，主要是以熟悉为主。

以上是关于本次实训的简单介绍，接下来我将以老师提供的资料为主，对本次实训的内容、过程、收获进行总结。

1.1 实训目的

1.提升软件开发综合能力

• 使用需求分析，项目管理，模型设计，软件编码，测试等技能进行软件综合开发。

2.提升沟通与合作方法

• 具备良好的团队意识、团队合作与沟通、团队协调或组织能力，能够在多学科背景下的团队中根据需要承担成员或负责人的角色。

3.熟悉软件文档的书写

• 能够依照相关的工程标准或行业规范，进行大数据系统工程相关工程技术文档（如需求分析 告、项目管理文档、数据库文档、接口文档、系统测试文档等）的撰写与交流表达。

总结： 除了编码能力外，还需要提升软件开发过程中其他步骤的能力，同时加强沟通能力以及提升各种文档的撰写能力。

1.2 角色职责分配

如上表，我们三人每个人都有两个角色，而每个角色的任务不仅仅是 “工作职责” 里的内容那么轻松，接下来我根据老师给的资料对每个角色的具体任务进行汇总。

产品经理

项目经理

IT 总监

后端程序员

前端程序员

测试人员

1.3 实训过程

我们本次实训共有五天时间，是以线上的形式，正好将实训分为了五个过程，每天轮到一个过程，这五个过程分别如下：

1. 产品设计
2. 项目管理
3. 设计与软件编码
4. 软件评测
5. 考评（由老师按一定指标综合评判打分，每个小组自评出一位最佳员工）

每天实训开始前段时间，老师会花1-2个小时时间进行讲解，关于今天需要熟悉的角色与职责，包括今天小组要完成的任务。在所有过程中，我们小组使用 语雀 记录所有文档，这个用起来很方便，支持协同操作，而且可以导出为 docx、md、pdf 等多种格式。

通过图表可以看出，我们主要就只有管理员用例，在整个系统中共有三个角色，分别是顾客、司机和管理员，其中顾客和司机都是被管理的对象，没有操作，本套系统皆由管理员来进行操作。

除了上述的 UML 用例图，产品经理 H 同学还设计了图中每个用例的文档，以登录用例为例：

通过 UML 用例图设计、UML 用例说明 和 原型图设计，一个需求文档的雏形就出现了，这份由产品经理设计出来的需求文档接下来需要交给项目经理，由项目经理进行整个项目阶段的分工安排。

最后记录一下上面过程中我们做错的以及值得注意的地方：

1. 切忌不要一来就进行数据库设计。

在产品经理进行需求分析阶段是不考虑数据库设计的，这是 IT 总监的工作，是在项目经理安排工作后进行的操作，这里我们应该先确立选题，然后辅助产品经理撰写好需求文档，之后通过 UML 用例图就能知道需要几张表，每张表大概需要哪些字段了。

2. 需求文档中切忌不能出现英文的字段

关于UML用例说明需注意，里面有提到一些属性，比如在登录的时候，提到了用户名和密码，这些其实就是在数据库设计时要参考的因素，数据库设计肯定是按照需求文档来设计的。如果发生差异了就需要申请需求变更，这个特别麻烦。我们不能将 username、password 这种英文的字段，类似数据库里表的字段写到需求文档，因为在需求分析过程中，还没有进行数据库设计，我们所讨论的属性都只是根据需求来的。

因为登录需要用户名和密码，所以产品经理就将其写到登录的用例说明中，这个阶段是完全不考虑数据库设计的，所有属性都直接用中文来表示。

3. 分清 UML 用例说明和原型图的作用

UML 用例图是在 IT 总监进行数据库设计、接口设计、详细设计时用到的。

原型图是前端在进行页面设计时用到的。

这两个对之后的软件设计有着重要作用，所以不能随便修改，否则就引起需求变更了，需求变更需要由 项目经理 到客户那进行审批，我们光是模拟就觉得很麻烦了。

其实在设计过程中，我们怕时间来不及，在第一天我们就在确立技术选型了，后端采用 Spring Boot + Swagger，前端就 Vue2 + Element UI，之前我学了一小段时间，比较熟悉。

本来我们打算使用 Ruoyi 脚手架的，但是下载过后发现里面内容涉及的太多了，不好删除，后来还是干脆直接从零开始了。

Day 2 项目管理文档

项目经理 L 同学在获得产品经理输出的需求文档后，负责分配任务给 IT 总监、后端和前端。

项目管理文档的目录如下：

有了具体的工作安排以后，接下来就是人力资源分配：

业绩管理就是根据每个人所完成的工作包来计算的，它是根据上面的监管跟踪 来统计每个人工作包完成情况。

成本估计又是根据业绩管理表格来的，每个工作包的预计工时、实际工时、日新和实际成本都需要记录到这里面。

最后就是需求变更记录和计划变更处理部分。

当客户需要变更需求时，向项目经理进行申请，而项目经理就将这些记录写道文档中，同时是需要进行审批的。

而计划变更处理则是在整个过程中，如果有因为某些原因延期或者其他情况，都需要记录在这个表格中。

综上，项目经理的职责还是挺多的， L 同学负责项目经理还有测试，工作量非常大。

在这里需要注意的地方就是：文档一定要按照标准来编写，而且项目经理要随时变更文档内容，根据实际情况来填写，负责整个项目流程的管理，还是非常关键的。

除了项目经理的职责外，其实在这个过程中我们就已经开始编码了，就是怕后面来不及敲，在真实企业中还是听项目经理的安排比较好，不然容易累到秃头。

Day 3 数据库设计、接口设计和详细设计

这一天主要是 IT 总监来负责的，需要写三份文档，而且需注意，这里的文档必须完全按照需求文档来写，不能根据自己的想法来写。

数据库文档需设计 ER图、具体的关系表和常量设计。

ER 图最好是下面这种形式的，中文的，这样方便非编码人员理解。

数据库文档最后一部分就是常量设计，其实这里不仅仅设计数据库了，还涉及了前后端，我们有的字段是 enum 枚举类型，那么相当于枚举我们就设计了对应的常量，这样方便前后端在进行交互时统一信息。

比如 MAN 表示男性，WOMAN 表示女性。

接下来，IT 总监需设计的第二个文档就是接口设计，其中还需要确立项目的技术架构。

这部分是我参照 上资料撰写的，就直接放出来了：

IT 总监最后的工作是详细设计，这个过程描述了每一个接口具体是怎样实现的，可以使用时序图、活动图、流程图、协作图等图形来表示，这里我选择了比较清楚的时序图，例如：管理员登录

三、实训总结

这次时间安排得比较紧，就只花了五天时间来做，还好我们三个都是执行力比较好的，另外两位同学执行力都比我高，而我也是尽力在做，最终能及时完成软件就很不错了，也算是给大四一个圆满的交代了，接下来我们大四没有课咯，就剩下专业实习和体测。

本次实训的小伙伴，包括我，我们的关系都挺好的，所以在交流上没什么问题，就算有分歧也能很快解决，俗话说三个臭皮匠顶一个诸葛亮，我们三这波配合的可以，除了团队配合以外，我还收获了软件开发流程的大致理解，通过这一段经历，可以口述出软件开发的大致流程了，而且是凭实践来的，不需要去硬记，这种感觉挺好的。

或许将来不一定会走这条路吧，但是这一次经历非常值得，也为我们的大四开了一个好头，接下来继续加油~