梁爽｜2021软件代码开发技术作业三｜综合系统开发——需求分析

这个作业属于哪个课程 软件代码开发技术
这个作业要求在哪里 综合系统开发----需求分析
这个作业的目标 1. 在实践中练习UML语言的使用
2. 在实践中练习Git与版本管理
3. 在实践中学习和练习有关的开发技术
4. 在实践中练习文档的撰写与规范
5. 在开发中对代码规范等软件开发技术进行实践
6. 在实践中体验软件项目管理带来的好处

git链接：https://github.com/lsCoding666/ServiceHirePlatform

Issues 截图

博客园截图

目录

需求规格说明书

1. 引言

1.1 项目背景

一家公司提供服务出租，自身有一些员工，另外还有很多自由职业者作为服务商存在。公司目前使用Excel工作表来管理他们的客户（自由职业者），时间表等。Excel解决方案无法很好地进行扩展。它无法应对多用户使用的场景，也不提供安全和审计日志。因此他们决定构建一个新的基于Web的解决方案。以下是核心要求：

  • 搜索自由职业者分类的功能
  • 用于存储联系自由职业者的不同渠道的解决方案
  • 搜索项目分类的功能
  • 搜索客户分类的功能
  • 维护合同中自由职业者的时间表

1.2 问题定义

一家公司提供服务出租服务，他们需要一个平台来管理他们的人员信息（包括公司员工信息和自由职业者信息）、客户信息、项目信息、合同信息。

  • 人员信息包括人员id、人员姓名、人员性别、联系方式、是否为自由职业者等信息，如果这个员工是自由职业者，还需要管理他们的分类信息。
  • 客户信息包括客户的id、姓名、性别、分类、联系方式等信息。
  • 项目信息包括项目id、名称、类别、项目的正文信息、立项日期、预计结项日期、结项日期、项目甲方人员信息、合同id。项目人员信息包括：项目需要的人员id。如果项目中有自由职业者的话，还需要管理合同中自由职业者的上班时间安排信息。
  • 合同信息包括：合同id、合同的签署日期、合同正文、项目乙方人员、开始日期和结束日期等信息。

公司管理员可以通过安卓客户端来对这些信息进行管理和查看所有的审计信息。

  • 审计信息：操作者id、做了什么操作、操作的结果、附加信息。

客户可以在这个平台上查看自己的项目和合同。

自由职业者和职员可以在这个平台上查看自己的项目和合同。

客户、职员、自由职业者都可以进行自主注册和登录、修改个人信息。管理员只能系统默认生成和管理员自己手动创建。

2. 需求分析

2.1 系统需求

2.1.1 功能需求

  1. 存储信息：人员信息、人员类别信息、客户信息、项目信息、项目甲方人员信息、项目乙方人员信息、合同信息、合同中的自由职业者上班时间安排信息、审计信息。

  2. 信息管理：人员信息的查看、更新、增加、删除；客户信息的查看、更新、增加、删除；发布项目、修改项目、结束项目、删除项目、修改项目；签署合同；添加审计信息。

    • 公司管理员可以通过安卓客户端来对这些信息进行管理和查看所有的审计信息。

    • 客户可以在这个平台上查看自己的项目和合同。

    • 自由职业者和职员可以在这个平台上查看自己的项目和合同。

    • 客户、职员、自由职业者都可以进行自主注册和登录、修改个人信息。管理员只能系统默认生成和管理员自己手动创建。

2.1.2 数据需求

  1. 输入数据

    • 人员信息：人员id、人员姓名、人员性别、电话号码、微信号码、QQ号码、邮箱地址、住址，分类信息、角色信息
    • 人员类别信息：类别id、类别名称
    • 客户信息：客户id、客户姓名、客户性别、电话号码、微信号码、QQ号码、邮箱地址、客户类别
    • 项目信息：项目id、项目名称、项目正文、立项日期、结项日期、合同id、项目类别
    • 项目甲方人员信息：项目id、人员id
    • 项目乙方信息：项目id、客户id
    • 合同信息：合同id、合同签署日期、合同正文、开始日期、结束日期
    • 合同中自由职业者的时间信息：项目id、人员id、开始上班时间、结束上班的时间

  2. 输出数据：

    • 审计信息：操作者id、操作内容（操作了哪个接口）、操作结果、备注

    • 做相关操作的对应的输入信息。比如创建项目输入项目信息、项目人员信息后如果成功创建项目了就输出这两个信息。

2.1.3 可用性需求

  • ui布局合理，简单易用
  • 前端输入格式做校验
  • 报错格式统一

2.1.4 运行环境

  • 客户端
    • 操作系统：安卓 5.0+
  • 服务端
    • Ubuntu 18.04 64位
    • 应用服务器：Tomcat
    • 数据库：Mysql 8.0

2.1.5 性能需求

  1. 联机处理人员信息、客户信息、项目信息、合同信息、审计信息。
  2. 各个角色能对有权限的信息及时的进行修改、添加、删除等操作。时间小于5秒

2.2 分析建模

2.2.1 数据流图

L0层数据流图

L1层数据流图

L2层数据流图

2.2.2 实体联系

  1. 实体以及属性

    • 人员：人员id、人员姓名、人员性别、电话号码、微信号码、QQ号码、邮箱地址、住址、角色id、分类id
    • 人员类别：类别id、类别名称
    • 人员角色：角色id、角色名称
    • 客户：客户id、客户姓名、客户性别、电话号码、微信号码、QQ号码、邮箱地址、客户分类id
    • 客户类别：客户类别id、客户类别名称
    • 项目：项目id、项目名称、项目正文、立项日期、结项日期、合同id、分类id
    • 项目类别：类别id、类别名称
    • 项目甲方人员安排：项目id、人员id
    • 项目乙方信息：项目id、客户id
    • 合同：合同id、合同名称、合同签署日期、合同正文、开始日期、结束日期
    • 自由职业者时间安排：项目id、人员id、开始上班时间、结束上班的时间

  2. 实体间的联系

    • 一个甲方人员对应n个项目，一个项目对应m个甲方人员
    • 一个项目对应1个合同
    • 一个项目对应n个自由职业者时间安排
    • 一个乙方客户对应n个项目，一个项目对应n个乙方客户
    • 一个项目对应1个项目分类
    • 一个人员对应1个人员分类

  3. 系统ER图

2.2.3 领域模型

2.2.3.1 实体的定义
  • 人员：包括普通职员和自由职业者、管理员。通过角色id进行区分
  • 员工：公司的全职员工
  • 自由职业者：公司的非全职员工
  • 客户：公司项目的乙方
  • 项目：公司的工作任务
  • 合同：甲方（公司）与乙方（客户）签署的一项共同的协议
  • 时间表：自由职业者的工作时间安排
  • 联系方式：联系人员、客户的渠道
  • 审计记录：所有角色的操作日志
2.2.3.2 领域模型

根据业务场景和业务逻辑，得到以下的领域模型：

2.2.4 对象模型

2.2.4.1 类图

2.2.5 用例模型

用例图

2.2.4.2 用例描述

3. 总体设计

3.1系统设计

3.1.1 系统流程图

3.1.2 物理元素清单

  • 硬件
    • 服务器一台
    • 移动设备若干
  • 软件
    • 数据库：Mysql 8.0：服务租用平台数据库
    • Tomcat：跑后端服务
    • 服务租用平台
    • 登录注册程序
    • 人员管理程序
    • 客户管理程序
    • 项目管理程序
    • 审计程序

3.2 软件设计

3.2.1 HIPO图

3.2.2 数据库逻辑结构

带实线下划线的是主键，带虚线的是外键

  • 人员：人员id、人员姓名、人员性别、电话号码、微信号码、QQ号码、邮箱地址、住址、角色id、分类id
  • 人员类别：类别id、类别名称
  • 人员角色：角色id、角色名称
  • 客户：客户id、客户姓名、客户性别、电话号码、微信号码、QQ号码、邮箱地址、客户分类id
  • 客户类别：客户类别id、客户类别名称
  • 项目：项目id、项目名称、项目正文、立项日期、结项日期、合同id、项目分类id
  • 项目类别：类别id、类别名称
  • 项目甲方人员安排：项目id、人员id
  • 项目乙方信息：项目id、客户id
  • 合同：合同id、合同名称、合同签署日期、合同正文、开始日期、结束日期
  • 自由职业者时间安排：项目id、人员id、开始上班时间、结束上班的时间

4. 详细设计

4.1 过程设计

4.2 人机界面设计

软件项目管理——项目时间安排表

项目时间安排表

任务名称 活动名称 预期活动工期 预计开始时间 预计结束时间 矫正后活动工期 矫正后开始时间 矫正后结束时间 实际完成时间
需求开发 3个工作日 2021/5/3 2021/5/5 3个工作日 2021/5/3 2021/5/5 2021/5/4
需求获取 1个工作日 2021/5/3 2021/5/3 1个工作日 2021/5/3 2021/5/3 2021/5/3
需求分析 2个工作日 2021/5/3 2021/5/4 1个工作日 2021/5/3 2021/5/3 2021/5/3
撰写需求规格说明书 2个工作日 2021/5/4 2021/5/5 2个工作日 2021/5/3 2021/5/4 2021/5/3
需求验证 1个工作日 2021/5/5 2021/5/5 2个工作日 2021/5/4 2021/5/5 2021/5/4
总体设计 1个工作日 2021/5/3 2021/5/6 1个工作日 2021/5/3 2021/5/6 2021/5/4
开发标准确定 1个工作日 2021/5/6 2021/5/6 1个工作日 2021/5/3 2021/5/3 2021/5/4
架构设计 1个工作日 2021/5/6 2021/5/6 1个工作日 2021/5/3 2021/5/3 2021/5/4
单元模块设计 1个工作日 2021/5/6 2021/5/6 1个工作日 2021/5/3 2021/5/3 2021/5/4
详细设计 3个工作日 2021/5/7 2021/5/9 以下活动提前2天 2021/5/5 2021/5/7
过程设计 3个工作日 2021/5/7 2021/5/9
人机交互界面设计 3个工作日 2021/5/7 2021/5/9
实现 14个工作日 2021/5/10 2021/5/23 以下活动提前2天
后端—数据库设计 1个工作日 2021/5/10 2021/5/10
后端——架构搭建 1个工作日 2021/5/10 2021/5/10
后端——登录注册 1个工作日 2021/5/11 2021/5/11
后端——人员管理 2个工作日 2021/5/12 2021/5/13
后端——客户管理 2个工作日 2021/5/14 2021/5/15
后端——项目管理 4个工作日 2021/5/16 2021/5/19
后端——审计 2个工作日 2021/5/20 2021/5/21
前端——架构搭建 1个工作日 2021/5/11 2021/5/11
前端——登录注册 1个工作日 2021/5/12 2021/5/12
前端——人员管理 1个工作日 2021/5/14 2021/5/14
前端——客户管理 1个工作日 2021/5/16 2021/5/16
前端——项目管理 3个工作日 2021/5/20 2021/5/22
前端——审计 1个工作日 2021/5/23 2021/5/23
部署上线 1个工作日 2021/5/23 2021/5/23
测试 7个工作日 2021/5/24 2021/5/31 以下活动提前2天
单元测试 2个工作日 2021/5/24 2021/5/25
集成测试 2个工作日 2021/5/26 2021/5/27
系统测试 2个工作日 2021/5/28 2021/5/29
测试总结 1个工作日 2021/5/30 2021/5/31
验收 3个工作日 2021/6/1 2021/6/3 以下活动提前2天
验收测试 2个工作日 2021/6/1 2021/6/2
产品交付 1个工作日 2021/6/3 2021/6/3

矫正计算方法

本人认为，没有开始干活之前对于项目的进展的预测存在的较大的不确定性。而且以我的开发经验制定了这份时间安排表，目前看起来是已经比较合理了，暂时不需要矫正。如果需要矫正后面再补。

暂定的矫正算法是：

  • 如果发现某一个活动所需要的工期比实际的短，那么也就是说后面的工期都能往前推，
  • 工期比预计的短说明这个活动比较简单，那么后面这个活动对应的实现和测试时间都根据情况进行相应的按比例缩短（提前+对应的活动工期缩短）
  • 某一个活动工期比预计的长同理，就是后面的顺延+对应的有关活动工期延长
posted @ 2021-05-04 09:07  lsgdut  阅读(305)  评论(0)    收藏  举报