201771010110-孔维滢-实验四 软件项目案例分析

实验四

项目	内容
课程班级博客链接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/
这个作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
我的课程学习目标	学习团队软件项目流程（TSP）、团队成员协作要求。掌握敏捷流程原则及相关概念。
这个作业在哪些方面帮助我实现学习目标	软件项目流程（TSP）、团队成员协作要求和敏捷流程原则及相关概念
结对方学号-姓名	王志成-201771010130
结对方本次博客作业链接	https://www.cnblogs.com/847118824wang/p/12675836.html

任务一：实验三优秀案例

学习小组：杨野&汪慧和小组

1. 博客链接：https://www.cnblogs.com/http-www-whh0601-cnblogs-com/p/12553743.html
   https://www.cnblogs.com/2017xinghui/p/12554158.html

2. GitHub仓库链接：https://github.com/yy202901582/DieaseSubmitSystem

3. 博客评论：
   

4. 功能运行及总结

   • 该项目基本实现了四大功能，查询、填报、图表统计显示、提醒。
     

   • (1)实现了个人信息填报
     

   • (2)实现了按姓名查询信息 按学院查询信息、查询感染人员
     

   • (3)实现了分类统计柱状图显示，按学院统计、按身份（教师、学生）统计、按月统计、按日统计、按症状统计、按地域统计
     

   • (4)实现了按时提醒的功能，输入特定的时间，就会按时提醒
     

5. 未实现的功能和bug

   • 没有实现时间段内的查询

任务二

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

1. 软件项目团队特点：
   (1)具有明确且有挑战性的共同目标

   一个具有明确的而且有挑战性目标的团队比目标不明确或不具有很大的挑战性目标的团队效率高得多，作为系统设计人员很清楚的知道在什么时候要做到什么，什么时候开始做，什么时候必须完成，为了完成工作必须面临哪些挑战，怎么解决这些困难等为设计出一个高质量的软件项目提供了重要保证，而模模糊糊的去设计一个系统或模模糊糊的就去编写代码是非常危险的，而且会为此付出高昂代价，因此高效的软件开发团队具有挑战性的共同目标。

   (2)团队具有很强的凝聚力

   在一个高效的软件开发团队中，成员们凝聚为一个整体共同进行工作，他们是相互支持、互相交流、互相尊重的，而不是相互推卸责任、保守、相互指责的，在一些散乱的开发团队中往往存在这样的问题，一些程序员是比较保守的，明明知道另外的模块中需要用到一段与自己已经编写完成但有些难度的程序代码，他也不愿拿出来给其它程序员共享，不愿与系统设计人员交流，这样给项目的进度造成了些不可度量的因素。

   (3)具有融洽的交流环境

   在一个开发团队中，每个人行使自己的职责，如需求分析人员制定需求规格说明、系统设计人员做系统概要设计和详细设计、项目经理配置项目开发环境并且制定项目计划等，但每个人的工作不可能做到完美的，如系统概要设计的文档可能有个别地方词不达意，做详细设计的时候就可能会造成误解，项目经理制定计划时可能忽略了某种风险的存在而造成执行者过于紧张的压力等等情况都需要大家通过交流、反馈的手段然后协商解决的，因此高效的软件开发团队是具有融洽的交流环境的，而不是那种简单的命令执行式的。

   (4)具有共同的工作规范和框架

   高效软件开发团队具有规范性及共同框架的工作，对于项目管理具有规范的项目开发计划，对于分析设计具有规范和统一框架的文档及审评标准，对于代码具有程序规范条例，对于测试有规范且可推理的测试计划及测试报告等等。并且所有成员都明白自己的职责，知道必须完成什么计划？由谁来完成？什么时候开始？什么时候结束？按什么顺序？等，总之一个高效的开发团队无论是工作内容还是工作流程都具有不同程度的规范性和标准风格的框架。

   (5)采用合理的开发过程

   软件的开发不同于一般商品的研发和生产，开发过程中会面临着各种难以预测的风险，比如需求的变化、人员的异动、技术的瓶颈、同行的竞争等，高效的软件开发团队往往是采用了合理的开发过程去控制开发过程中的风险、提高软件的质量、降低开发费用，这样的团队会根据自身的必要程度决定要执行哪些工作？如配置管理、资源管理、版本控制、代码控制等，团队还合理的分划并定义开发过程的里程碑，决定每项活动内容的底线和审评标准，决定各项活动的先后关系或迭代的关系等。总之高效的软件开发团队的开发过程的原则是高效率、高质量、低成本。

2.软件团队的模式

 (1)一窝蜂模式：像小朋友踢球一样，球在哪里，人就一窝蜂跟在哪里
     优点：欢乐而随意
     缺点：这种团队模式很难存活，并不是一种好的团队模式

 (2)主治医师模式：像在手术台一样，有一个主刀医师，其他人负责协助主刀医师
     优点：初衷很好，一个软件团队中，有首席程序员，负责主要模块的设计和编码，其他人尽可能从各个方面支持他的工
     缺点：在一些学校的软工课上，这种模式逐渐退化成“一个学生干活，其他学生打酱油”

 (3)明星模式：主治医师模式运用到极点
     优点：对“明星”个人的成长进步可能会有所帮助
     缺点：团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低

 (4)社区模式：由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬
     优点：“众人拾柴火焰高”，成功案例：开发和维护Linux操作系统的社区，成功案例往往需要严格的代码复审和签入的质量控制
     缺点：“只烤火，不拾柴”，“拾到的柴火质量太差”

 (5)业余剧团模式：团队中各人扮演各人的角色
     优点：在业余玩票、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论
     缺点：在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。

 (6)秘密团队：有一些软件项目在秘密状态下进行，别人不知道他们具体在做什么
     优点：团队内部有极大的自由，较高的热情，没有外界的干扰。
     缺点：不可能成为普遍模式，只会针对个别项目。

 (7)特工团队：软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题
     优点：效率高
     缺点：对成员的知识面要求十分广，较为针对技术人员，不可能成为普遍模式

 (8)交响乐团模式：各司其职，想交响乐队一样
     优点：各司其职，重在执行
     缺点：呆板

 (9)爵士乐模式：与交响乐模式存在相当多的对立
     优点：领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结
     缺点：人员不能太多

 (10)功能团队模式：具备不同能力的同事们平等协作公共完成一个功能
      优点：效率高
      缺点：每个小组必须与其他小组就编程规范达成一致

 (11)官僚模式：脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次向上
      优点：有助于技术的交替与互补
      缺点：容易掺杂一些追名逐利，往往会使团队效率大打折扣

3.瀑布模型及变形

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

优点：

1）为项目提供了按阶段划分的检查瀑布模型查点。
2）当前一阶段完成后，只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：

1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
5）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

• 温斯顿指出，要让产品成功，最好把这个模型走两遍，先有一个模拟版本（Simulation of FinalProduct），在此基础上收集反馈，改进各个步骤，并交付一个最终的版本
  

4.渐进交付流程

史蒂夫·迈克康奈尔（Steve McConnell）在1996年总结的，但是它其实已经很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的evolution循环中。[开发→发布→听取反馈→根据反馈做改进]

5.敏捷流程
优点：

1）敏捷开发的高适应性，以人为本的特性。更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

缺点：

由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。

6.卡内基梅隆大学（CMU）软件工程学院总结的TSP原则

• TSP建立的基本原则

(1) 在遵循定义好的过程并得到快速反馈时，学习是最重要的;
(2) 高效团队的协同工作存在- -些基本的共性，如具体又一致的目标、良好的工作支撑环境和强有力的指导等;
(3)在面临软件开发的实际问题时，讨论、分析并最终得到了有效的解决方案的同时，软件开发人员获益匪浅。

• 描述内容

(1)如何规划和管理-.个软件开发团队;
(2)如何制定团队工作所需要的策略;
(3)如何定义和确定团队中每个角色的职责;
(4)如何为团队中每个成员分配不同的角色;
(5)团队机器不同角色在整个开发过程的不同阶段应该做些什么，如何更好地

• 作用

(1)如何协调团队成员之间的任务，并跟踪报告团队整日的任务进度;
(2)采用哪些方法提高团队的协作能力。

7.讨论截图

任务三

1.作业发布账号链接https://www.cnblogs.com/PureMan6/p/10739662.html
2.GitHub链接https://github.com/swearitagain/EduCnblogs2.0
3.选择该团队的理由

• 这是一款能够真正在手机端使用的软件，有一定基数的用户下载体验量，我对于参与移动应用开发的经验极少，而且这学期我有一门课程设计就和设计APP有关，希望可以从中有所收获。

4.项目团队成员的分工合作情况总结

• 这款软件的开发总共有6人，首先PM有两人组成，然后六个人分别分配不同的任务，来完成博客撰写；项目规划、文件调查、每日例会、监督；代码编写、构建相关框架、增加功能、修改功能、APP发布、软件测试等。每个人分工明确，同时一些分工由两个或三个人一起完成，任务分配均匀，很好的运用了功能团队模式。

5.项目的软件项目过程特点（TSP）评价

• 该项目明确的的体现了软件项目过程特点，在团队中每个人都有明确的职责，分工合理，每个人在每个阶段的任务有相应的任务，每个阶段的任务汇报有明确的时间，很好的体现了七点原则：
  

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

• 包含代码规范文档
  

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

• 首先打开软件后显示登录界面，提供登陆及登录验证功能
  

• 登录后显示个人主页，可以查看个人博客
  

• 选择班级进入班级主页，可以查看班级公告、作业、博文、投票
  

• 选择班级作业，可以查看作业要求、提交作业
  

• 主页可查看个人信息、日成提醒、收藏列表、浏览记录、设置、退出登录等
  

8.存在的bug

• 忘记密码操作时按返回键只能直接退出应用
• 浏览记录一直为空，不显示浏览过的历史记录
• 查看班级作业的提交列表时无显示
  

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

• 我认为这个项目很有开发的价值，一般博客园只能在网页端登录，手机大小与页面大小时常不匹配，而且方便了我们可以随时在手机上查看博客园里的各种信息，还有可以不用特地登录网站提交作业，极大地方便了用户，如果完善一些功能，修改一些错误，加强软件安全防护，会是一个成熟的软件。所以这个项目值得继续开发。

任务四

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

任务	内容
实验1	60min
实验2	70min
实验3	90min

总结

请谈谈完成本次作业的感受和体会。

通过本次实验，我学习到了团队软件项目流程（TSP）、团队成员协作要求，并掌握了敏捷流程原则及相关概念。也掌握了软件开发中的不同的开发流程如：瀑布模型，渐进交付和敏捷流程。在今后的学习中我也会将这些知识融入到实际操作中，完善自己的专业知识，提升实战能力。同时通过学习其他团队的程序代码，使我也学习了很多新的知识，通过比较，我认识到了自己的不足，学习到了很多相关的知识和技巧，将来可以吸取经验，对于今后有关的学习任务积累经验。