201771010127-王艳 实验四 软件项目案例分析

项目	内容
课程班级博客链接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
这个作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
我的课程学习目标	学习团队软件项目流程（TSP）,了解团队成员协作要求；掌握敏捷流程原则及相关概念
这个作业在哪些方面帮助我实现学习目标	软件项目流程、团队成员如何分工以及协作等方面
结对方学号-姓名	201771010128-王玉兰
结对方本次博客作业链接	https://www.cnblogs.com/wang963/p/12651227.html

• 任务一：在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价，具体要求如下：

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

  汪慧和&杨野组：

  案例作业博客链接：https://www.cnblogs.com/http-www-whh0601-cnblogs-com/p/12553743.html

  案例作业项目仓库链接：https://github.com/yy202901582/DieaseSubmitSystem

  评论如下：

  

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

  

  • 信息填报：提供老师或学生进行疫情信息填报

  

  • 查找信息：通过姓名等查找某教师或学生

  
  

  • 查看某学院学生疫情信息：通过学院名查看某学院目前教职工以及学生的疫情信息
    
  • 查看某地区学生疫情信息：通过地名查看当地学生以及教师疫情信息
    
  • 查看教职工疫情信息：查看当前所有填报信息的教职工疫情情况
    
  • 柱状图显示：用柱状图显示当前各学院填报情况
    
  • 饼状图显示：用饼状图显示当前各学院填报情况
    
  • 提醒填报功能：设置闹钟后，会在指定时间提醒填报
    
    
    代码可以顺利运行，也能较好实现所需功能，在读了案例博文后再运行项目时，方便了对项目的理解，基本没有问题。
    系统功能总结：
    （1）师生可登录系统进行疫情信息的填报；
    （2）二级防疫部门人员可进行疫情信息的填报；
    （3）二级防疫部门负责人可可根据姓名进行模糊查询，根据姓名、学院、感染情况以及地区进行准确查询，可根据出现的字段生成相应的统计图；
    （4）设定时间后自动提醒进行信息填报。
    总体而言，很好的实现了基础功能，此外添加了提醒的附加功能，但实现提醒功能时，到了截止时间依然会弹出提醒对话框，但是总体功能很完善。
    
    
  • 总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。
    总结：该组实验三博客作业博文内容简明，逻辑清晰，基本没有问题。代码设计方面，项目代码可读性比较好，稍微复杂的地方也做了相应注释。但是代码中多少存在一些无用的代码，若加以修正效果会更好。
    代码中存在的bug：运行提醒功能相关代码时，我设定的时间是11:57，但是在时间截止后，提醒页面任然会弹出。
    
    未实现的功能：该项目的数据写在txt文件中，在eclipse中进行读取，没有实现导出数据到excel文件中。

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

  • 软件项目团队的特点：
    （1）团队有一致的集体目标并且要一起去完成这个目标，完成目标期间，每个成员不一定要同时进行工作；
    （2）团队成员有各自的分工，互相依赖合作，共同完成任务。
  • 软件团队的模式：

  （1）一窝蜂模式：像小朋友踢球一样，球在哪里，人就一窝蜂跟在哪里。
  优点：欢乐而随意；
  缺点：这种团队模式很难存活，并不是一种好的团队模式。
  （2）主治医师模式：在这种模式的团队中，有首席程序员，主要负责处理主模块的设计和编码，要求其他成员从各种角度支持首席程序员的各项工作。
  优点：理想情况下可以完美地完成工作；
  缺点：这种模式逐渐退化成只有带头的一个人干活，其他人跟着划水。
  （3）明星模式：简言之就是将主治医师模式运用到极点，就蜕化成了明星模式。
  优点：对“明星”个人的成长进步有所帮助；
  缺点：违背了团队模式的初衷，效率很低。
  （4）社区模式：这种模式的团队中，会有很多志愿者参与，每个人参与自己感兴趣的项目，贡献自己的力量。在这种模式下，也有很严格的代码复审和签入的质量控制。
  优点：“众人拾柴火焰高”，开发和维护Linux操作系统的社区的生工案例表明，严格的代码复审和签入的质量控制极其重要；
  缺点：“只烤火，不拾柴”或者“拾到的柴火质量太差”。
  （5）业余剧团模式：在这种模式的团队中，不同的人会挑选不同的角色。在另外一个项目中，他们可能又会换一个完全不同的角色类型。每个人在团队中都要听从一个领导者的指导和安排。
  优点：每个人都可以尝试不同角色，大家可以比较平等地讨论；
  缺点：在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。
  （6）秘密团队：这些软件项目在秘密状态下进行，团队内部有极大的自由，不用向外界介绍项目进展等相关情况。
  优点：比较自由，较高的热情，没有外界的干扰；
  缺点：不可能成为普遍模式，只能针对个别项目而言。
  （7）特工团队：团队中的队员由专业人士组成，负责解决一些刺手而又紧迫性的问题。
  优点：效率高；
  缺点：对成员的知识面要求十分广，较为针对技术人员，不可能成为普遍模式。
  （8）交响乐团队模式：应用这种模式的软件一般处于稳定成长的阶段，且一般为大型软件公司采用。
  优点：各司其职，重在执行；
  缺点：呆板。
  （9）爵士乐模式：这种模式一般在项目开始时领导给出主题，在项目快结束时再将大家的想法和成果总结在一起。
  优点：项目进展过程中成员们百花齐放，各显本领；
  缺点：人员不能太多。
  （10）功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。
  优点：效率高；
  缺点：每个小组必须与其他小组就编程规范达成一致。
  
  （11）官僚模式：这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，小头目报告给中头目，依次而上。
  优点：有助于技术的交替与互补；
  缺点：容易掺杂一些追名逐利，往往会使团队效率大打折扣；

  • 瀑布模型
    瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，最终得到软件产品。瀑布模型的核心思想是按工序将问题简化，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，依次逐级下落。
    瀑布模型适用于以下范围：
    1.如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；
    2.产品模块之间的接口、输入和输出能很好地用形式化的方法定义和验证；
    3.使用的技术非常成熟，团队成员都很熟悉这些技术；
    4.负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。

  瀑布模型的各种变形
  （1）生鱼片模型
  这个模型解决了各个步骤之间分离的缺点，但是对于上一个阶段的结束时间并不明确，不利于下一阶段开展的计划。
  （2）大瀑布带着小瀑布模型
  为了解决不同子系统之间进度不一，技术要求迥异，需要区别对待的问题，因此引入了子瀑布模型。在这种瀑布群下，要把各个子系统统一到最后做系统测试的阶段，难度比较大。另外，在这样的开发流程中，用户只有到了最后才能看到结果，因此等待时间过长。

  渐进交付流程：
  渐进交付流程是史蒂夫.迈克康奈尔在1996年总结的，但是它其实已经很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的循环中:[开发→发布→听取反馈→根据反馈做改进]
  
  敏捷流程:
  敏捷开发流程是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发的流程。符合敏捷价值观和原则的开发方法包括：极限编程，Scrum，精益软件开发，动态系统开发方法，特征驱动开发，水晶开发等等。
  我认为各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素，而敏捷开发流程强调的是人的能动性。通过这种相互合作的开发模式，通常来说项目团队肯定是基本可以很好的完成项目的。
  TSP原则：
  TSP原则侧重于帮助开发团队改善其质量和生产率，以使其更好的满足成本及进度的目标。TSP结合了CMM的管理方法和PSP的工程技能，用于指导软件工程师如何将个体过程结合进小组软件过程，并将后者与组织甚至整个管理系统相联系。它通过告诉管理层如何支持和授权项目小组来坚持高质量的工作，并且依据数据进行项目管理来向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。
  TSP要遵循以下七个原则：
  （1）使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的；
  （2）团队的各个成员对团队的目标、角色、产品都有统一的理解；
  （3）尽量使用成熟的技术和做法；
  （4）尽量多地收集数据（也包括对团队不利的数据）,并用数据来帮助团队做出理性的决定；
  （5）制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）；
  （6）增加团队的自我管理能力；
  （7）专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。
  截图：
  
  
  
  

• 任务3：在班级博客园，有很多高校的软件工程课程要求同学们完成团队项目，请与实验三结对伙伴协商，在以下三个班级中选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。

  1. 2016级计算机科学与工程学院软件工程 (西北师范大学)
  2. 2019秋福大软件工程实践Z班 (福州大学)
  3. 2019春季计算机学院软件工程 (北京航空航天大学)
     我选择进行学习项目案例的班级是：2019春季计算机学院软件工程 (北京航空航天大学)
  • 团队项目作业发布账号链接：https://www.cnblogs.com/PureMan6/default.html?page=6
  • 团队项目仓库github链接：https://github.com/swearitagain/EduCnblogs2.0
  • 陈述选择该团队项目进行分析的理由：

  一开始我想着三个班级都大概看一下，选择一个自己感兴趣的项目来运行。结果发现西北师范大学班级项目运行出的结果不太全面，福州大学基本都是C语言，但是我c语言比较弱，可能代码也读不太懂。最后在浏览北京航空航天大学的班级时发现了这个团队项目，刚好上学期也选修了Android课程，就仔细读了该团队的博客，发现他们的项目做的是博客园手机APP续写，作为一个需要经常在博客园交作业的孩子来说这就显得非常有必要了，因为出门在外的时候手机浏览器访问博客园实在是太不方便了；此外他们的项目并且已经发布了，感觉……很厉害，所以就选择了这个项目进行分析。

  • 结合项目系列博客文档，总结项目团队成员的分工合作情况：

  邵旭哲：PM，主要负责所有博客撰写；
  蒋锋，陈治齐，胡俊崧：开发人员；
  吴枫：测试人员；
  吴昊：开发（任务没有其他开发人员那么多），负责开会。
  项目进展过程中，在不同阶段又有不同的分工：
  
  
  该团队要求开发人员保证将自己需要实现的功能进行测试后在交付，同时每个队员之间保证彼此的沟通，防止其中一人进度滞后。当某一段时间工作量太大时，可以找协助人员分担。此外，任务没完成时，要相应扣分，可以很好地调动队员积极性。在不同阶段，每个人都有不同的任务，这样进行任务分配，保证了每个人都能参与到其中，发挥自己应有的水平，我认为这样安排十分合理。

  • 结合项目系列博客文档，评价项目的软件项目过程特点（TSP）：
    （1）该软件项目在实现过程中，在一开始就明确了要做的项目是什么，需要实现的功能是什么；
    （2）团队根据负责具体执行的的角色制定了详细的计划，队员对于项目目标以及产品有人都十分明确；
    （3）此外，制定了项目计划以及奖罚制度，有助于增加团队的自我管理能力；
    （4）同时要求每个队员在将自己完成的任务进行测试后再交给下一个队员继续进行工作，这样能够在早期就发现问题并及时改正，不会造成各做各的，最后才发现问题再去弥补的局面。
    这样的软件项目过程特点符合规范要求，十分合理，也是我们在后期进行团队项目时需要去学习的。
  • 观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
    
    该项目团队github仓库的源代码文件结构中，并未包含代码规范文档（好像我之前看的项目基本都没有代码规范文档~）
  • 下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图。
    由于手机需要使用Android版，因此我是用模拟器来运行这个项目的。
    下载项目到本地：
    
    运行项目：
  • 主页面：显示我所提交的博客
    
  • 点击查看：
    
  • 我的班级：显示我所在班级发布的任务
    
  • 我：个人信息设置
    
    相应功能基本都可以正常使用，如点击浏览记录：
    
    使用体验：
    首先在登录APP后，第一感觉是这款博客园APP页面很直观，底部状态栏明确显示了可选择的内容；这款APP基本满足了用户在使用博客园时所需的基本需要；整体感觉比较好，打开时在我的模拟器上稍微有卡顿，相比之前运行的程序速度算是比较快了；还有就是有黑暗模式可选择，符合人性化的需求。
    功能性bug：
    1.部分页面在黑暗模式下面没有渲染：
    
    比如在黑暗模式下查看博文：
    
    2.在我设置了黑暗模式后，再去查看我的博文时，显示身份已经过期，需要重新登录，同时还出现网络连接错误的问题，但我的网络此时其实并没有问题。
    
    3.登录使用网站的页面在登录成功后会显示授权码页面，而这个授权码本应该进行隐藏。
    
    4.退出登录后，一直会交替弹出对话框：身份信息过期和网络请求失败。
    
  • 评价该团队项目是否值得继续开发，并陈述理由？
    我认为这个团队项目值得继续开发，因为这个项目虽然还存在着一些bug，但是能够发布到市场就足以说明这个项目的可行性，也表明这个项目在一定程度上市可以满足用户需求的。而且若是出门在外，需要使用博客园时，手机浏览器的体验感很不好，因此相比网页端使用博客园，手机端会方便很多。

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

  任务一：90分钟
  任务二：300分钟
  任务三：240分钟
  任务四：220分钟

完成本次作业的感受和体会。
本以为本次作业不做项目会相对容易，因此刚开始没有去管这个作业，第三天才开始进行，但是随着每个任务慢慢完成，越到后面越发现这次作业需要理解的东西很多，在浏览其他学校的团队作业时，发现团队项目并不是只完成这个项目就可以了，在项目开始前要做很多准备，比如项目进度计划、成员分工与合作等等。在运行别人的项目时，感叹了无数遍，感觉实在太厉害……通过这次作业，相比项目实战，我收获了更多。在后面的团队项目中，我会把这次学到的东西加以运用，使项目更好的完成。