201771010124-王海珍-实验四 软件项目案例分析

项目	内容
课程班级博客	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
做业要求	http://www.javashuo.com/article/p-bkupgxcc-ns.html
课程学习目标	经过分析优秀的做业案例，掌握本身的不足之处。经过合做学习，理解合做的重要性
这个做业在哪些方面帮助我实现学习目标	体验软件项目开发中的两人合做，练习结对编程，掌握Github协做开发程序的操做方法。
结对方学号-姓名	201771010126-王燕
结对方本次博客连接	<https://www.cnblogs.com/wy201771010126/p/12677569.html>

实验内容和步骤：

任务一：实验三优秀案例推荐：王之泰&韩腊梅组

案例做业博客连接：http://www.javashuo.com/article/p-rpvmwiux-ns.html

案例做业项目仓库连接：https://github.com/YHwzt/Query-system-web

（1）对案例博文做业进行阅读并进行评论评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系，并将以上评论内容发布到案例做业的博客评论区。

（2）克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。

将案例方的代码克隆至本地进行运行

 

 

而后进行代码运行，截图以下

上面是登陆界面

进行信息的添加

进行采集信息的统计

信息的展现

 以上案例实现的功能：

1，可采集全校各种师生员工疫情信息；

2，各二级部门疫情防控工做负责人可查看本部门人员疫情汇总，并提供高级查询功能进行多属性组合查询和可视化统计功能；

3，学校防控办指定负责人登陆《西北师范大学疫情防控信息统计》子系统，可浏览全部人员填报汇总数据清单，利用【高级查询】可进行数据组合筛选，系统以图形化方式展现各学院已填报和未填报学生统计状况和关键疫情数据统计状况，可【导出】查询列表的EXCEL文件；

4，附加功能：定时填报提醒

此案例的功能实现全面，彻底按照老师的要求，实现了全部的功能，另外还实现 了附加功能，相比较 来讲 算是作得很完美的，因此相比来讲，我认为此案例是很值得我来参考学习一下的。

（3）总结本组实验三博客做业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。

我认为此案例很完美没有多少不足，可是也有一些不完美的地方，好比，仓库中的代码在clone以后没有出现问题可是在导入eclipse的时候有一些问题，导不进去，最后在请教同窗和查询相关资料以后直接在 idea打开才行，着让不少参考者有了很大 的问题，由于打不开，会认为本身的eclipse配置有问题，或者代码有问题。

 

代码规范基本没有问题，功能实现也比较全面。

任务2：与实验三结对伙伴协做学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特色、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特色，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；

1，软件项目团队的特色

（1）团队应该拥有共同的目标；

（2）团队应该合理分工协做；

（3）高度的凝聚力是是团结的保证；

（4）团队成员相互信息；

（5）有效的沟通；

2，软件团队的模式：软件团队有不少不一样的模式。

（1），如下是几种模式以及他们的优缺点：

1.一窝蜂模式：像小朋友踢球同样，球在哪里，人就一窝蜂跟在哪里

优势：欢乐而随意

缺点：这种团队模式很难存活，并非一种好的团队模式

2.主治医师模式：像在手术台同样，有一个主刀医师，其余人负责协助主刀医师

优势：初衷很好，一个软件团队中，有首席程序员，负责主要模块的设计和编码，其余人尽量从各个方面支持他的工做

缺点：在一些学校的软工课上，这种模式逐渐退化成“一个学生干活，其余学生打酱油”

3.明星模式：主治医师模式运用到极点

优势：对“明星”我的的成长进步可能会有所帮助

缺点：团队模式强调的是团队的做用，而不是我的的独角戏，这种模式显然违背了团队模式的初衷，效率也很低

4.社区模式：由不少志愿者参与，每一个人参与本身感兴趣的项目，贡献力量，大部分人不拿报酬

优势：“众人拾柴火焰高”，成功案例：开发和维护Linux操做系统的社区，成功案例每每须要严格的代码复审和签入的质量控制

缺点：“只烤火，不拾柴”，“拾到的柴火质量太差”

5.业余剧团模式：团队中各人扮演各人的角色

优势：在业余玩票、培训的环境中，每一个人均可以尝试不一样角色，你们能够比较平等地讨论

缺点：在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。

6.秘密团队：有一些软件项目在秘密状态下进行，别人不知道他们具体在作什么

优势：团队内部有极大的自由，较高的热情，没有外界的干扰。

缺点：不可能成为广泛模式，只会针对个别项目。

7.特工团队：软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题

优势：效率高

缺点：对成员的知识面要求十分广，较为针对技术人员，不可能成为广泛模式

8.交响乐团模式：各司其职，想交响乐队同样

优势：各司其职，重在执行

缺点：呆板

9.爵士乐模式：与交响乐模式存在至关多的对立

优势：领导给出一个主题，而后成员们百花齐放，各显本领，快收尾时再总结

缺点：人员不能太多

10.功能团队模式：具有不一样能力的同事们平等协做公共完成一个功能

优势：效率高

缺点：每一个小组必须与其余小组就编程规范达成一致

11.官僚模式：脱胎于大机构的组织架构，几我的报告给一个小头目，几个小头目报告给中头目，依次向上

优势：有助于技术的交替与互补

缺点：容易掺杂一些追名逐利，每每会使团队效率大打折扣

（2），和小组成员讨论团对模式

3，典型软件过程模型特色

所谓软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。对一个软件的开发不管其大小，咱们都须要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、须要的控制，以及要交付的产品的特色。一个错误模型的选择，将迷失咱们的开发方向。

模型名称	技术特色	适用范围
瀑布模型	简单，分阶段，阶段间存在因果关系，各个阶段完成后都有评审，容许反馈，不支持，用户参与，要求预先肯定需求	需求易于完善定义且不易变动的软件系统
快速原型模型	型 不要求需求预先完备定义，支持用户参与，支持需求的渐进式完善和确认，可以适应用户需求的变化	需求复杂、难以肯定、动态变化的软件系统
增量模型	软件产品是被增量式地一块块开发的，容许开发活动并行和重叠	技术风险较大、用户需求较为稳定的软件系统
迭代模型	不要求一次性地开发出完整的软件系统，将软件开发视为一个逐步获取用广需求、完善软件产品的过程	需求难以肯定、不断变动的软件系统
螺旋模型	结合瀑布模型、快速原型模型和迭代模型的思想，并引进了风险分析活动	需求难以获取和肯定、软件开发风险较大的软件系统
RUP	可改造、扩展和剪裁：能够对它进行设计、开发、维护和发布；强调迭代开发	复杂和需求难以获取和肯定的软件系统；软件开发项目组拥有丰富的软件开发和管理经验

 

瀑布模型 

瀑布模型（经典生命周期）提出了软件开发的系统化的、顺序的方法。其流 程从用户需求规格说明开始，经过策划、建模、构建和部署的过程，最终提供一 个完整的软件并提供持续的技术支持。

优势：

1. 强调开发的阶段性，各阶段具备顺序性和依赖性

2. 强调早期调研和需求分析，推迟编码实现的观点

3.  提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法能够 在该摸板下有一个共同的指导

 

缺点：

1. 文档驱动，用户没法及时了解产品的状况

2. 依赖早期调研和需求分析，很难适应在许多项目开始阶段必然存在的不肯定 性。

3.  流程单一，必需要完成前一阶段的任务，才能进行下一阶段，开发过程当中的 成功经验没法用于本产品。

4.  测试在后期引入，对于系统存在的重大缺陷，若是在可执行程序评审以前没 有被发现，将可能形成重大损失。

5. 组织庞大，人员闲置。

增量过程模型

 

增量过程模型包括增量模型、RAD 模型。

（一）增量模型 增量过程模型以迭代的方式运用瀑布模型，把软件产品做为一系列的增量构件来设计、编码、集成和测试。

每一个构件由多个相互做用的模块构成，而且可以完成特定的功能。使用增量模型时，第一个增量每每是核心功能。

 

优势：

1.能在较短的时间内向用户提交可完成部分工做的产品。

2.逐步增长产品功能可使用户有充裕的时间学习和适应新产品，从而减小一个 全新的软件可能给客户组织带来的冲击。

3. 规避技术风险

4. 可并行开发构件，加快开发的进度

 

缺点：

1.  没有考虑软件的总体质量和长期的可维护性。

2.  大部分状况是不合适的操做算法被采用目的为了演示功能，不合适的开发工 具被采用仅仅为了它的方便，还有不合适的操做系统被选择等等。

3.  因为达不到质量要求产品可能被抛弃，而采用新的模型从新设计

 

RAD模型

RAD  模型是一种侧重于短暂的开发周期的增量软件过程模型，它是瀑布模 型的“高速”变体，经过基于构建的构建方法实现快速开发。

开发团队可以在很是短的时间内创造出“全功能系统”

 

优势：

1．开发速度快，质量有保证。

2．对信息系统特别有效。

 

缺点：

1.  对于大型的可伸缩的项目，RAD 须要大量的人力资源来建立多个相对的独立 的 RAD 团队

2.  若是开发者和用户没有为短期内急速完成整个系统作好准备，RAD 项目将会失败。

3.  若是一个系统不能合理的模块化，RAD 构件创建会有不少问题。

4.  若是系统需求是高性能，而且须要经过调整构件接口的方式来提升性能，不 能采用 RAD 模型

5.  技术风险很高的状况下

 

演化过程模型

 

演化过程模型包括原型开发，螺旋模型，协同开发模型。

（一）原型开发 从需求收集开始，开发者和客户在一块儿定义软件的整体目标，标识已知的需求而且规划出须要进一步定义的区域。

而后是“快速设计”，它集中于软件中那些 对客户可见的部分的表示，这将致使原型的建立，并由客户评估并进一步精化待 开发软件的需求。

逐步调整原型使其知足客户的需求，这个过程是迭代的。其流 程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、而后回头 往复循环直到客户对原型满意为止。

因为这种模型可让客户快速的感觉到实际 的系统（虽然这个系统不带有任何质量的保证），因此客户和开发者都比较喜欢 这种过程模型（对于那些仅仅用来演示软件功能的公司而言或历来不考虑软件质

量和不惧怕长期维护的公司而言）。

优势：

一、能让人（开发者或客户）很快见到产品，有成就感。

二、能渐进地启发客户提出新的要求或任务。

 

缺点：

一、 没有考虑软件的总体质量和长期的可维护性。

二、 大部分状况是不合适的操做算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操做系统被选择等等。

三、 因为达不到质量要求产品可能被抛弃，而采用新的模型从新设计。

 

螺旋模型

螺旋模型是一种演进式软件过程模型，结合了原型的迭代性质和瀑布模型的系统性和可控性的特色，具备快速开发愈来愈完善软件版本的潜力。

开发步骤：沿螺线自内向外，每旋转一圈便开发出更为完善的一个新的软件版本。

例如，在第一圈，肯定了初步的目标、方案和限制条件之后，转入右上象限，对风险进行识别和分析。

若是风险分析代表，需求有不肯定性，那么在右下 的工程象限内，所建的原型会帮助开发人员和客户，考虑其它开发模型，并对需求作进一步修正。客户对工程成果作出评价以后，给出修正建议。

在此基础上需 再次计划，并进行风险分析。在每一圈螺线上，风险分析的终点作出是否继续下 去的判断。

假如风险过大，开发者和用户没法承受，项目有可能终止。多数状况 下沿螺线的活动会继续下去，自内向外，逐步延伸，最终获得所指望的系统。

 

优势：

1. 强调风险

2. 强调阶段质量

3. 提供纠错的机会

 

缺点：

1. 每一个阶段都要提出被选方案，进行风险分析，研发周期长，效率低

2. 必需要转业的风险分析人员的参与

 

 

 

统一过程模型

 

统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件 过程框架，由 UML 方法和工具支持。它是一种增量模型，定义了五个阶段：

 

a、起始阶段，包括用户沟通和计划活动，强调定义和细化用例

b、 细化阶段，包括用户沟通和建模活动，重点是建立分析和设计模型。

c、构件阶段，细化模型设计，并将设计模型转化为软件构件实现

d、 转化阶段，将软件从开发人员传递给最终用户，并由用户完成 beta 测试和验 收测试 

e、生产阶段，持续地监控软件的运行，并提供技术支持。

 

优势：

1. 任何功能开发后就进入测试过程，及早进行验证

2. 早期风险识别，采起预防措施

 

缺点：

1. 需求必须在开始以前彻底弄清楚，否怎有可能在架构上出现错误

2. 必须有严格的过程管理，以避免使过程退化为原始的试→错→改模式

3．若是不加控制的让用户过早接触没有测试彻底，版本不稳定的产品可能对用 户和开发团队都带来负面的影响

四、理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则

（1）使用妥善定义的流程，流程中的每一步都是能够重复、能够衡量结果的。

（2）团队的各个成员对团队的目标、角色、产品都有统一的理解。

（3）尽可能使用成熟的技术和作法。

（4）尽可能多地收集数据(也包括对团队不利的数据),并用数据来帮助团队作出理性的决定。

（5）制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。

（6）增长团队的自我管理能力。

 任务3：请与实验三结对伙伴协商，在如下三个班级中选择一个高质量的团队项目案例进行协做学习，要求追踪该团队项目发布全部博客做业，下载项目软件代码。

1. 2016级计算机科学与工程学院软件工程 (西北师范大学)

2. 2019秋福大软件工程实践Z班 (福州大学)

3. 2019春季计算机学院软件工程 (北京航空航天大学)

 用过讨论决定选择西北师范大学的的进行学习，选择的缘由主要是，相比较来讲，第一是本身学校的，学习水平差距不是很大，容易理解，相比较其余两个学校的本身学校的更能理解。

 

 

 

 

 

结合项目系列博客文档，总结项目团队成员的分工合做状况（4分）；

这个分工看似合理，可是每一个人参与的环节不同，有的同窗除了文档部分其余部分，没有参与，而有些同窗除了编码部分为参与文档部分，者相对来讲也是一种重心偏移的现象。

结合项目系列博客文档，评价项目的软件项目过程特色（TSP):

TSP把人员分红小组领导者、开发经理、计划经理、质量／生产经理，以及技术支持经理(注意这点和RUP的雷同）,要求各我的员严格记录在软件开发过程当中的每一步，好比程序的Bug率，使用的时间等等。

观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？

clone该团队的代码查看，发现包含代码规范文档。

下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展现截图

以上是代码运行的结果截图。咱们讨论运行发现的bug有：

（1）.在功能展现部分：请假管理模块中，请假审核状态修改显示成功，可是并无发生改变，多是功能不完整或者不健全的缘由。
（2）.在数据链接部分：当看到老师经过请假审核后，学生却没法看到请假已经经过的状态。
（3）.性能部分：学生能够自行修改权限，没有将 老师的权限展现出来，也没有完善学生的权限。

评价该团队项目是否值得继续开发，并陈述理由？

项目值得继续开发，可是此项目的完成度较低，在功能，数据链接，性能等部分都有或多或少的问题，建议先完善问题，再进一步作好更进一步的开发工做，学生考勤管理系统，加一些签到打卡的功能。

 

 

 

 以上是我和伙伴儿一块儿添加修改的管理系统，以此作个对照。

 

记录完成《实验四 软件项目案例分析》各项任务实际花费的时间

 

实验任务	花费时间
任务一	3h
任务二	2h
任务三	5.5h
任务四	1h

5，请谈谈完成本次做业的感觉和体会。

本次做业主要学习其余的优秀做业为主，而学习优秀做业的同时也是对本身的能力的一种提高和进步，看了优秀做业的代码和博文结构内容等等，以为本身仍是有不少须要学习的地方，本身的代码也不够完整，并且也没有优秀案例的规范，如此这些都是须要在后期增强的地方，因此这次优秀案例分析也让我了解到了本身的欠缺，须要在什么地方下功夫。