201971010259 张圆圆 实验四 团队作业1：软件研发团队组建

项目	内容
课程班级博客链接	2022年春软件工程课程班(2019级计算机科学与技术)
作业要求链接	实验四 团队作业1：软件研发团队组建
团队名称	Typhoon-Team
我的课程学习目标	* 仔细阅读《现代软件工程—构建之法》第12章内容 * 实验三作业互评 *组建软件项目研发团队
这个作业在哪些方面帮助我实现学习目标	* 通过阅读《现代软件工程—构建之法》中的第12章，对代码风格规范、代码设计规范、代码复审、结对编程等概念有了更加深入的了解 * 通过实验三作业的互评，对其他同学项目的运行使用，对自己的项目进行了完善修改 * 组建了软件项目研发团队，便于以后的课程学习
团队博客链接	Typhoon-Team 实验四 团队作业1：软件研发团队组建

任务1：浏览班级博客园中提交《实验三 软件工程结对项目》作业，任选一个认为完成质量较高的小组项目成果，对其进行评价与学习#

1. 对博文作业进行阅读，并结合评分要求进行评论。#

评论作业	具体要求
评论博客链接	201971010231-毛玉贤 实验三 结对项目—《{0-1}KP 实例数据集算法实验平台》项目报告
评论内容	1. 博文结构：整体博客结构完整，条理清晰，各个任务都有详细的叙述，排版也很好，博客界面美化很好看，值得推荐。 2. 博文内容：正文内容完成了所要求的实验内容，从不同的方面描述了此次实验项目，写的详细完整，便于别人阅读查看。在项目的具体软件设计介绍中，对每一部分算法功能都进行了一一介绍，介绍详细且易于理解，并通过图表的形式对项目功能算法进行了详细的描述，让人一目了然，对于项目各个模块所用到的函数也通过流程图的形式进行了介绍，值得学习借鉴。博主可以考虑将每一个算法介绍，算法流程图，算法核心代码都一一对应集中在一起，可能更利于查看及理解，（PS：小小建议，现在这样也很好）。 3. 博文结构与PSP中“任务内容”列的关系：博主在博客中所写到的项目实现流程与PSP的主要流程基本保持一致，可见博主是按照PSP来完成此次项目的，博客正文结构完整，逻辑性较好，对于项目整体描述很详细，值得学习。 4. PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究：博主在PSP中的实际完成需要的时间数据比计划完成需要的时间较长，在前期计划阶段所用时间较短，但在对实际编程所需时间的把控不太好，项目开发编码阶段所需时间较长，可能是编程方面有一定的阻力，对于原先未接触过遗传算法，并需要将不同功能模块集合到一起，可能使得项目开发编码阶段所需时间加长。 总结 ： 博主及结对同伴对于此次项目的整体完成度较高，博客内容充实且详细，通过图像的方式介绍相关算法内容，清晰明了，值得学习，博主在项目开发过程中，可考虑与同伴一起将项目划分成不同模块进行编码设计，可能会提高项目开发编码效率。
项目Github仓库	Algrithm_platform

2. 克隆任务3项目源码到本地机器，阅读并运行代码，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。#

• 克隆Algrithm_platform项目源码到本地机器

• 代码核查表

项目	内容
概要部分
代码符合需求和规格说明么？	符合需求和规格说明，实现了实验所要求全部功能
代码设计是否考虑周全？	考虑周全，基本考虑了所有需求设计功能
代码可读性如何？	可读性较好 ，对关键代码进行了注释
代码容易维护么？	较容易维护，整体项目代码通过不同的代码来完成不同的项目功能，对于功能进行修改时，不会影响到其他功能
代码的每一行都执行并检查过了吗？	对项目代码都已执行并检查过
设计规范部分
设计是否遵从已知的设计模式或项目中常用的模式？	遵守
有没有硬编码或字符串/数字等存在？	有
代码有没有依赖于某一平台，是否会影响将来的移植？	移植影响较小
开发者新写的代码是否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以通过调用而不用全部重新实现？	未用到
有没有无用的代码可以清除？	有
代码规范部分
修改的部分符合代码标准和风格么？	基本符合
具体代码部分
有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？	已处理所出现错误
参数传递有无错误，字符串的长度是字节的长度还是字符的长度，是从0开始计数还是从1开始计数	无错误出现；字符的长度；从0开始
边界条件是如何处理的？switch语句和default分支是如何处理的？循环有没有可能出现死循环？	通过前提假设分析推导边界条件；可能出现死循环
有没有使用断言来保证我们认为不变的条件真的得到满足？	否
对资源的利用，是在哪里申请，在哪里释放的？有无可能存在资源泄露？有没有优化的空间？	使用程序语句进行申请、释放；不存在资源泄露；有优化空间
数据结构中有没有用不到的元素？	无
效能
代码的效能如何？最坏的情况是怎么样的？	效能较好；最坏情况下界面显示不完整
代码中，特别是循环中是否有明显可优化的部分？	无，目前未找到
对于系统和网络的调用是否会超时？如何处理？	不会超时，系统运行较快
可读性
代码可读性如何？有没有足够的注释？	对关键代码均有注释，可读性较好
可测试性
代码是否需要更新或创建新的单元测试？	需要

3. 阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：#

A. 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片

• 使用过程：在本地pycharm软件中，或者在cmd窗口运行程序，就可出现程序主界面，在主界面上方的导航栏中，有导入数据，算法求解，绘制图形，排序，日志记录相应的菜单栏，选择相应的功能，就会跳转到相应的功能界面，选择要进行0-1背包问题求解的数据，即可得到相应的结果。

• 使用软件照片

  • 主界面

    

  • 使用动态规划算法求解

    

  • 使用贪心算法求解
    

  • 物品价值重量比排序
    

  • 绘制散点图

  

  • 绘制柱形图

  

  • 日志记录查看
    

B. 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？

项目	内容
要求的功能是否已解决	所要求的功能基本完成
优点	* 数据量：可以从数据库直接选择数据，也可自己导入数据，便于用户操作，可处理较多的数据 * 界面：清晰明了，界面美化很好看 * 功能：该项目所实现功能较为完善
缺点	* 数据量：在部分界面，面对较多的数据时，不能求得其正确结果展示 * 界面：界面较小，主界面大小固定，不利于用户使用 * 功能：功能基本都已实现，但项目通过不同方式运行（如cmd窗口），部分功能出现故障，可能是运行环境不一致导致
改进意见	在进行项目测试时，可以在多个运行环境或者多个电脑中均测试运行，可减少项目出现故障的可能性，大大提高项目的实用性，对于界面，可以尽量设置大一些，方便用户查看使用

C. 从 学历、年龄、专业、爱好、收入等方面概括实验三任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求都是什么？

• 典型用户群特征

调查方面	用户特征
学历	高中以上学历
年龄	18岁及以上
专业	理工科专业
爱好	对于编程，算法设计感兴趣的人
收入	用户群体可能为学生，或者已步入社会的上班人员，所以收入不限
表面需求	需要了解及学习贪心算法，遗传算法，动态规划，回溯算法来解决0-1背包问题
潜在需求	学习所使用各个算法的基本思想，了解学习使用不同算法解决问题的效率所存在的差异

4. 经过（1）-（3）的工作，给评价作业选择一个结论:a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐,并写出理由。#

  经过对所选择小组实验三项目的克隆，并在本地运行使用，通过选择不同数据对各个算法的测试使用，所得出实验结果基本正确，该项目基本上完成了实验三所要求的功能，该组对于此次项目的博文内容的编写也很详细，对于实验三完成度较高，综上所述，对该评价作业给出 d) 好，不错 的结论。

5. 结合（1）—（3）的评论体会，迭代改进本小组实验三的任务3。#

  结合上述项目的评价测试，我们对于本小组实验三的项目进行了以下的迭代改进。

• 界面美化修改（将原先界面重新进行了背景美化，对于界面布局中的字体大小样式进行了修改，对部分图标显示也进行了修改）

• 贪心算法修改（对于原先数据量大，贪心算法所求解有部分问题，重新进行了修改）

• 项目迭代改进后GitHub项目信息

  • commits操作

  

  • Fork操作

  

  • Releases操作

  

任务2：团队组建#

1. 在实验三结对基础上，结对小组两两自由组合，组建软件项目研发团队#

• 团队名称：Typhoon-Team
• 团队成员组成

成员学号	成员姓名	个人博客地址	备注
201971010259	张圆圆	墨柒BYG	PM
201971010116	姜婷	Jiokie
201971010135	孙得弘	不爱敲代码的Conner

• 团队介绍

成员	风格	擅长技术	编程兴趣	希望的承担的软工角色	宣言
张圆圆	对一切充满热情	Java，移动应用开发设计	算法编程学习，网络编程学习	项目后端设计及开发	自律努力,未来可期
姜婷	灵活多变	Python、web页面设计	算法、前端设计	项目测试、前端设计	凡事不等等。
孙得弘	态度积极，吃苦耐劳	python，算法设计	前端设计	技术兼管理型SE	励精图治，发奋图强

2. 申请开通团队博客，提交团队信息，将团队博客加入到班级博客#

• 团队博客链接：Typhoon-Team
• 提交团队信息
  
• 将团队博客加入到班级博客
  

3.阅读《现代软件工程—构建之法》第5章内容#

• 软件团队的模式

  • 主治医师模式( Chief Programmer Team, Surgical Team )
      在这样的软件团队中，有首席程序员(ChiefProgrammer),他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作( 后备程序员、系统管理员、工具开发、编程语言专家、业务专家)。
  • 明星模式( Super-star Model )
       主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，如何让团队的利益最大化，而不是明星的利益最大化?如何让团队的价值在明星陨落之后仍然能够保持?是这个模式要解决的问题。
  • 社区模式 ( Community Model )
      社区模式的好处是“众人拾柴火焰高”，但“社区” 并不意味着“随意”，一些成功的社区项目(例如开发和维护Linux操作系统的社区)，都有很严格的代码复审和签人的质量控制。
  • 业余剧团模式( Amateur Theater Team )
      这样的团队在每一个项目(剧目)中,不同的人会挑选不同的角色。在下一个剧目中，这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥(导演)的指导和安排。
  • 秘密团队 ( Skunk Work Team )
      一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。这种模式的好处是:团队内部有极大的自由，较高的热情,没有外界的干扰。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。
  • 特工团队( SWAT )
       软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。特工团队满足了人们对于“Mastery” ( 精通某一领域) 这种内在驱动因素的需求，能在某一领域达到“专家”、“高手” 的地位，一出手就能解决难题，这也是对技术人员非常有吸引力的。
  • 交响乐团模式( Orchestra )
    • 家伙多，门类齐全。
    • 各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。
    • 演奏都靠谱，同时看指挥的。
    • 演奏的都是练习过多次的曲目,重在执行。
  • 爵士乐模式( Jazz Band )
      和交响乐团相比，这种模式有以下特点:
    • 不靠谱。他们演奏时都没有谱子。
    • 没有现场指挥。
    • 也有模式，迈尔斯(姑且称之为架构师)先用小号吹出主题，其余人员根据这个主题各自即兴发挥;最后迈尔斯加入，回应主题，像是对曲子的总结。
    • 人数较少。
  • 功能团队模式( Feature Team )
      很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。
  • 官僚模式( Bureaucratic Model )
       这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。

• 开发流程

  • 写了再改模式( Code-and-Fix )
    这个流程好处在于不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来,写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
    • “只用一次”的程序
    • “看过了就扔”的原型
    • 一些不实用的演示程序
  • 瀑布模型( Waterfall Model )
    在软件工程实践中的局限性在于:
    • 各步骤之间是分离的， 但是软件生产过程中的各个步骤不能这样严格分离出来
    • 回溯修改很困难甚 至不可能，但是软件生产的过程需要时时回溯
    • 最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用
  • Rational Unified Process统一流程( RUP )
      从瀑布模型开始的各种模型都有一个共同点:重计划，重事先设计，重文档表达。这一类的方法中集大成者要算Rational统一流程( Rational Unified Process，RUP) 。RUP把软件开发的各个阶段整合在-一个统一的框架里。要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在RUP中叫做规程( Discipline )或者工作流( Workflow)。
  • 老板驱动的流程( Boss- Driven Process )
    • 当软件订单的获得不是主要靠技术实力，而是靠个人关系，或者暗箱操作的时候，老板的能力决定了一个团队是否能获得订单，既然软件的具体功能并不重要( 或者哪个团队做水平都差不多)，那么老板说做什么就做什么。
    • 在大型企业内部，软件功能往往由行政体系来决定。
    • 有些老板比一般技术人员更懂市场和竞争。
    • 软件团队尚未成熟，不懂得如何独立地进行需求分析，不懂得如何对行政领导有技巧地说“不”，也不知道如何说服利益相关者同意并支持正确的项目方向。既然不能驱动团队成员，那只能靠外力来驱动了。

• 渐进交付的流程( Evolutionary Delivery)，MVP和MBP

  • 不断演进的evolution循环

  

  • MVP
      Minimum Viable Product,最小可行产品，又称为Minimal Feature Set,最小功能集。具体的做法是:把产品最核心的功能用最小的成本实现出来( 或者描绘出来)，然后快速征求用户意见。

• TSP的原则

  • 使用妥善定义的流程，流程中的每- - -步都是可以重复、可以衡量结果的。
  • 团队的各 个成员对团队的目标、角色、产品都有统一的理解。
  • 尽量使用成熟的技术和做法。
  • 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
  • 制定切合实际的计划 和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)
  • 增加团队的自我管理能力。
  • 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)

4.阅读《现代软件工程—构建之法》第7章，理解MSF的9点基本原则#

1. 推动信息共享与沟通( Foster open communications )
    所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。对牵涉到的技术机密、安全性等信息要采取必要的保护措施。

2. 为共同的远景而工作( Work toward a shared vision )
    同心同德,兄弟同心，其利断金,明确项目的目标，目标不是空泛的，它应该对项目成员每天的工作都有指导作用。

3. 充分授权和信任( Empower team mebers )
    在一个高效的团队中，所有成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。类似地，团队的顾客(包括内部和外部的顾客)也认为团队能兑现承诺，并进行相应的规划。

4. 各司其职， 对项目共同负责( Establish clear accountability and shared responsibility )
    每个角色在其职责范围内的失败都会导致整个项目的失败，而且各个角色的工作都是互相渗透、互相依赖的。这种互相依赖的方式也鼓励团队成员在自己本职之外为其他领域做贡献。

5. 交付增量的价值( Deliver incremental value )
    重视商业价值，提供渐进的价值，怎样衡量一个项目的成功?并不是最酷的技术，而是商业的成功。一个项目的商业价值只有在它被成功地发布并运行时才能体现出来。

6. 保持敏捷，预期和适应变化( Stay agile, expect and adapt change )
    软件工程，唯一不变的是变化。不要幻想客户的需求会在第一时刻很明确，然后保持不会变，但这其中的变化是预期变化，不是期望变化。除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题，这些都要求我们团队保持敏捷的身段。

7. 投资质量( Invest in quality )
    对质量的重视，引发对质量的投资，引发对人、过程和工具的投资。

8. 学习所有的经验( Learn from all experiences )
    在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题。

9. 与顾客合作( Partner with internal and external customers
    MSF强调产品团队与顾客的交流与合作，并不是产品团队拿到合同之后，就闭门造车，直到产品完成才告诉用户，给他们一个惊喜(通常“惊”大于“喜”)。项目当然是项目团队成员做的，但是项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”:的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事。

5.组建团队企业微信群#

任务3：完成《实验四 团队作业1：软件研发团队组建》博文作业#

1.记录完成《实验四 团队作业1：软件研发团队组建》各项任务实际花费的时间#

任务内容	计划共完成的时间(min)	实际完成时间(min)
团队初步组建	30	60
组长的选定	25	15
实验内容分工规划	35	40
创建企业微信群	8	5
开通团队博客	20	30
博客互评	35	45
选择实验三项目运行	80	90
迭代更新小组实验三项目	70	95
阅读《构建之法》	80	90
团队博客编写	280	320
反思及总结	30	20

2. 反思及总结#

  在此次团队组建中，寻找团队人员花费时间较多，但最终建立了一个三人软件项目开发小组，团队成员之间都相互熟悉了解，对于以后项目开发过程中的项目交流打下了很好的基础，在此次团队中，担任小组组长，将会不断学习，提高自身能力，与团队成员一起学习成长，在以后的团队合作中共同努力，完成以后学习中的各个任务。