任务1 团队项目需求分析改进
a.分析《教室借用系统需求规格说明书》初稿不足。
- 通过我们的分析,我们发现我们在上次需求规格说明书中有以下不足:
1.需求描述建模不完整,如没有最基本的类图,在UML的静态机制中类图是一个重点,它不但是设计人员关心的核心,更是实现人员关注的核心
2.需求分析的获取过于单一,我们只通过问卷调查的方法获取了用户需求,其实还可以通过访谈,场景分析等方法获取用户需求
3.需求规格文档不够完整
b.功能分析的四个象限。
- 根据四象限原理,可以划分为两种不同类型的功能:
根据功能的完备程度,划分为:①杀手功能 / ②外围功能
根据需求的有限程度,划分为:①必要需求 / ②辅助需求
(1).杀手功能:开发组织所独有的优势功能。
(2). 外围功能:普遍性的功能。
(3). 必要需求:用户需要优先级为最高的需求
(4). 辅助需求:锦上添花的需求,而非必要的需求
![]()
c. 编制团队项目的WBS
一个团队项目要在一段时间内完成诸多任务,若要满足用户需求,实现团队目标,完成需求分析后,编制项目WBS(Work Breakdown Structure,即工作分解结构,是根据项目目标把工作分解成许多层次分明的、可交付成果的工作任务,然后用逻辑图形或树形结构表示出来),是团队项目有序管理的工作依据。
![]()
看板图
燃尽图
任务分配图
d. 团队成员估计各自任务所需时间
|
|
|
| 团队成员 |
具体分工 |
所需时间 |
| 葸铃 |
后台开发、数据库设计 |
88小时 |
| 巩定定 |
后台开发、系统测试 |
90小时 |
| 吴兰兰 |
前端设计、数据库设计 |
86小时 |
| 张仲桃 |
前端设计、系统测试 |
90小时 |
e. 团队项目Github仓库链接
Github仓库链接: 软件需求规格说明书改进
任务2 团队项目系统设计
系统结构图:
![]()
E-R图:
![]()
类图:
![]()
用例图:
![]()
任务4
a.陈述团队项目的系统设计过程、系统设计方法与建模工具
- 1.设计过程:在系统设计之前,我们针对上次团队项目需求规格说明书的不足,应用面向对象分析方法(OOA)进行了修改与完善。因为如果需求分析不到位,就无法清晰的明确设计目标,一切都变得盲目,甚至无从下手。紧接着就开始了我们的软件系统的设计,设计内容主要包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、UI界面等内容,在总体规划好之后,参考国标GB8567——88编写了《软件系统概要设计说明书》,并对接下来要做的工作进行明确的分工,为实现我们的软件系统做好准备。
- 2.设计方法:采用结构化设计方法。该方法适合于软件系统的总体设计和详细设计,特别是将一个复杂的系统转换成模块化结构系统,该方法具有它的优势。在使用过程中可将结构化设计方法与结构化分析(SA)方法及编程阶段的结构化程序设计方法(SP)前后衔接起来
- 3.建模工具:Visio完成需求UML模型的绘制
b.团队成员在系统设计的具体分工及占整个系统设计文档任务的工作量比例
|
|
|
| 团队成员 |
具体分工 |
工作量比例 |
| 葸铃 |
编制团队项目的WBS |
27% |
| 巩定定 |
撰写团队项目软件系统设计说明书 |
26% |
| 吴兰兰 |
团队需求说明书的改进 |
25% |
| 张仲桃 |
画出功能分析的四个象限、撰写博客 |
22% |
c.团队项目系统设计心得
- 1.通过本次团队的项目系统设计,我们发现系统总体设计和需求分析之间有非常紧密的关系,需求分析的结果是系统总体设计的依据。一般是需要先进行需求分析后再进行系统总体设计,需求分析作为系统设计的输入,系统设计的目标是为了实现用户需求。把用户需求转换为系统需求,所以需求分析实质上做的是理解用户的想法并描述出来,系统设计是把描述的需求转换落地的方案。
- 2.另外,从本次项目系统设计的过程中,我们明白了拿到一个大的项目时需要先对它进行分解,再对每个小模块进行详细划分和设计,这样做的好处就是目标明确、思路清晰、一个小模块出错不会影响其他模块,方便修改。再者,团队合理分工也很重要,这会使得效率提升很多,但在做的过程中也需要小组成员的共同协作,共同探讨与研究。