| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/2018CST |
| 这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/14660499.html |
| 团队名称 | 玛卡巴卡小分队 |
| 团队的课程学习目标 | （1）实验三作业互评 （2）组建软件项目研发团队 |
| 这个作业在哪些方面帮助我实现学习目标 | （1）通过实验三两人结对总结的经验，完成实验四，壮大队伍形成四人团队 （2）在人际交流方面，与团队成员之间不断地展开学习、经验等方面的探究，逐渐熟悉彼此 |
| 团队博客 | https://group.cnblogs.com/181179/admin/member/ |
任务1：
1.博客评论
| *名 | 博客链接 | 评论内容 |
|---|---|---|
| *傲羊 | https://www.cnblogs.com/xiuhai/p/14655767.html | 博文结构： (1)整体结构很清晰，对于实验要求的内容完成度较高 (2)我个人建议，可以通过段落让博文结构更有层次感，也可以快速看清哪一部分的内容对应的是哪一项作业要求 博客内容： (1)通过你的博文内容，可以很清楚的知道你对《现代软件工程—构建之法》第3-4章的内容有认真阅读，对结对方的要求较高，是一种很好的现象 (2)博文中代码部分的注释较少，很难一眼看出具体这段代码的含义 总结： PSP中的内容不够详细，但是可以明确的发现在实验开始到结束的过程中，计划完成所需时间与实际完成所需时间的差大概是970分钟，结合我自己的项目计划所需时间与时间完成所需时间的时间差不难发现，有些时候可能是对自己过于自信导致计划失误，建议下次不要浪费时间，对自己的能力等方面有清楚的认识。 |
| *子豪 | https://www.cnblogs.com/yzh8626/p/14655102.html | 博文结构： (1)整体结构明确，但是没有很好的使用段落标题，具体表现在“任务一、二、三”标题不明显 (2)个人建议可以加一点在阅读过程中觉得很有用，对自己启发比较大的摘抄的句子以表格或者其他方式表现出来 博客内容： (1)通过你的博文内容，再结合你的结对对象的内容，可以清楚的知道你们确实形成了结对方，在讨论过程中有做记录，这是很值得我学习的地方 (2)博文内容相对你的结对对象的比较少，可以写出自己的想法，也希望总结部分可以更多一点 总结： 你们俩的结对真正实现了1+1>2的效果，具有“契约精神”，在面对困难时并没有抛弃对方，反而经过讨论而解决，相信你也从实验三中收获了不少除课本以外的知识以及友情等，也希望你们可以继续保持现在的状态，成为更好的自己。 |
 |
||
 |
2.代码复审
| 复审部分 | 提出问题 | 执行情况 |
|---|---|---|
| 概要部分 | 1）代码符合需求和规格说明么？ 2）代码设计是否考虑周全？ 3）代码可读性如何？ 4）代码容易维护么？ 5）代码的每一行都执行并检查过了吗？ |
1）符合 2）周全 3）清晰易懂 4）容易 5）否 |
| 设计规范部分 | 1）设计是否遵从已知的设计模式或项目中常用的模式？ 2）有没有硬编码或字符串/数字等存在？ 3）代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到 Win64 ) ？ 4）开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？ 5）有没有无用的代码可以清除? |
1）是 2）有 3）代码由C#编写，可能会影响移植 4）是，用已有的Library/SDK/Framework中的功能实现 5）有 |
| 代码规范部分 | 修改的部分符合代码标准和风格吗？ | 符合 |
| 具体代码部分 | 1）有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？ 2）参数传递有无错误，字符串的长度是字节的长度还是字符(可能是单/双字节)的长度，是以0开始计数还是以1开始计数？ 3）边界条件是如何处理的？switch语句的default分支是如何处理的？循环有没有可能出现死循环？ 4）有没有使用断言(Assert)来保证我们认为不变的条件真的得到满足? 5）对资源的利用，是在哪里申请，在哪里释放的?有无可能存在资源泄漏（内存、文件、各种GUI资源、数据库访问的连接，等等)？有没有优化的空间？ 6）数据结构中有没有用不到的元素? |
1）已处理 2）无错误，字符的长度，从0开始计数 3）通过前提分析推导出边界条件 4）否 5）自动申请释放，不会存在资源泄露，有优化的空间 6）有 |
| 效能 | 1）代码的效能（Performance）如何？最坏的情况是怎么样的？ 2）代码中，特别是循环中是否有明显可优化的部分？ 3）对于系统和网络的调用是否会超时？如何处理？ 4）代码可读性如何？有没有足够的注释？ |
1）效能一般，数据量过大可能会学院很长的运行时间而得不到结果 2）无 3）如果超时，重新调用 4）结构清晰，但注释较少 |
| 可测试性 | 代码是否需要更新或创建新的单元测试？ | 否 |
3.代码克隆及运行
由于无法打开.exe文件而下载.NET 5.0 SDK
| 结对双方 | Github地址 | 出现的bug |
|---|---|---|
| 30112 *傲羊 30133 *子豪 |
客户端 服务器端 |
（1）需要下载.NET 5.0 SDK （2）对英语没学好的我来说很不友好，可以选择语言（不算bug） （3）会出现莫名其妙的程序不响应事件，因为没有做多线程处理 （4）会出现某些按键无法使用的情况 （5）服务器的那一端可以看到客户端用户的密码（不安全） |
 |
||
 |
||
 |
||
 |
4.阅读《现代软件工程—构建之法》第5章内容
5.1 非团队和团队
团队与非团队的区别是什么？（1）团队是一群志同道合的人聚集在一起专注于某一件事，互相鼓励，不离不弃，具有“契约精神”；（2）非团队是一群乌合之众，可以随时一拍而散，各自行动，对其他人不理不顾，只在乎自己利益最大化，不在乎是否会影响其他人。
5.2 软件团队的模式
一窝蜂模式：一群人关注同一样事物，不观察其他成员如何做，没有明确的分工、方向等，浪费时间。
演变形式：
-
主治医师模式(Chief Programmer Team,Surgical Team)
就像在手术台上那样，有一个主刀医师,其他人（麻醉,护士,器械）各司其职，为主刀医师服务。这样的软件团队中,有首席程序员(Chief Programmer)，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作(后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。
缺点：在一些学校的软工课上，这一模式往往退化为“一个学生干活，其余学生跟着打酱油”。 -
明星模式(Super-star Model)
主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化？如何让团队的价值在明星陨落之后仍然能够保持？是这个模式要解决的问题。真正有巨大成就的明星都能意识到团队的作用，迈克尔·乔丹说过，“Talent wins games, teamwork wins championship.”一些摇滚乐团的团队成员个性非常突出，团队时时都处于解体的边缘。
缺点：可能会出现一个成员过于优秀，带不动其他成员而随时在解散的边缘徘徊
-
社区模式(Community Model)
社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴；或者捡到的柴火质量太差，最后火也就熄灭了。“社区”并不意味着“随意”，一些成功的社区项目（例如开发和维护Linux操作系统的社区)，都有很严格的代码复审和签入的质量控制。
缺点：每一个软件项目都需要明确的分工，如何分工？如何给每个成员分配等额的、擅长的工作是团队组长最需要考虑的，否则会造成成员做着不擅长的工作而导致工作质量差。
-
业余剧团模式(Amateur Theater Team)
这样的团队在每一个项目（剧目）中，不同的人会挑选不同的角色。在下一个剧目中，这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。在业余玩票、培训的环境中，每个人可以尝试不同角色，大家还可以比较平等地讨论。但是在竞争性强烈、创造性要求高的团队，不会存在完美的民主气氛，就像职业足球比赛，每个人的责任都不可或缺，但是不会每个人都有同样的控球时间。
缺点：听从团队组长的安排，虽然每个人都可以挑战自己，但是每个人的学习能力有一定的差距，可能会造成由于一人学习能力低于其他人而导致软件项目完成延期。
-
秘密团队(Skunk Work Team)
一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。苹果公司1980年代在研发
Macintosh之后的系统时，就有两三个团队在不同时期进入秘密状态开发。21世纪的一些创业团队也是处于类似状态。这种模式的好处是：团队内部有极大的自由，较高的热情，没有外界的干扰（不用每周给别人介绍项目进展，听领导的最新指示等等）。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。缺点：团队成员中必须人人都具有较强的自觉性，形成互相敦促，互相进步的局面，否则会造成软件项目迟迟无法交付而引起的经济等方面损失。
-
特工团队(SWAT)
就像电影电视中的特工组“加里森敢死队”等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决Y2K问题。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。特工团队满足了人们对于“Mastery”（精通某一领域）这种内在驱动因素的需求，能在某一领域达到“专家”、“高手”的地位，一出手就能解决难题，这也是对技术人员非常有吸引力的。
-
交响乐团模式(Orchestra)
特点：（1）家伙多，门类齐全
（2）各司其职，各自有专门场地，演奏期间每一聊天、走动等现象
（3）演奏都靠谱，同时看指挥
（4）演奏的都是联系过多次的曲目，重在执行
-
爵士乐模式(Jazz Band)
特点：（1）不靠谱，演奏时没有谱子
（2）没有现场指挥，平时有编曲者协调和指导乐队。
（3）也有模式，架构师先用小号吹出主题，然后他到一旁抽烟去了，其余人员根据这个主题各自即兴发挥；最后架构师加入，回应主题，像是对曲子的总结。
（4）人数较少
（5）强调个性化的表达，强有力的互动，对变化的内容给予有创意的回应。
-
功能团队模式(Feature Team)
很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。
在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系。大型软件公司里的不少团队都是采用这种模式。这些功能小组也称为 Feature Crew，小组内的交流频繁。
-
官僚模式(Bureaucratic Model)
这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目,依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种结构有一重大隐患，在做绩效评估的时候，各个小老板、中老板都要为自己手下的弟兄们争名夺利，而有意无意地忽略了全局最优的绩效评估标准，导致很多无谓的算计、纠结、甚至有人会贬低别的团队的贡献。
5.3 开发流程
-
写了再改模式(Code-and-Fix)
这个流程的好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
- “只用一次”的程序
- “看过了就扔”的原型
- 一些不实用的演示程序
-
瀑布模型(Waterfall Model)
当软件行业还在年幼的时期，它从别的成熟行业（硬件设计,建筑工程）借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循：分析→设计→实现（制造）→销售→维护，这个
流程。由于在“硬”行业中产品一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程。- 各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来
- 回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯
- 最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用“最终产品直到最后才出现”是很令人头痛的局限性。
-
Rational Unified Process 统一流程(RUP)
-
老板驱动的流程(Boss-Driven Process)
-
渐进交付的流程(Evolutionary Deliverry)，MVP和MBP
- MVP——Minimum Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。
- 正如所有的方法论那样，MVP也有它的适用范围，和它相对应的，是Maximal Beautiful Product（最强最美产品，MBP）的思路，如果对用户的需求了然于心，或者产品团队比用户更了解用户的需求，为何不把产品最全、最美的形态展现出来，一举征服用户？
-
TSP的原则
5.阅读现代软件工程—构建之法》第12章内容
-
软件的使用过程
- 首先打开下载好的压缩包文件，但是由于没有下载.NET 5.0 SDK造成报错；处理后用户先得注册才可以登录，否则会报错；登录后由于某些按键没有处理完全，导致出现了客户端未响应现象。但是值得肯定的是，*傲羊和 *子豪运用了服务器和客户端做出一个独立的程序这一点是很值得我学习的。
- 首先打开下载好的压缩包文件，但是由于没有下载.NET 5.0 SDK造成报错；处理后用户先得注册才可以登录，否则会报错；登录后由于某些按键没有处理完全，导致出现了客户端未响应现象。但是值得肯定的是，*傲羊和 *子豪运用了服务器和客户端做出一个独立的程序这一点是很值得我学习的。
-
总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
- 软件产品基本解决了功能需求，但是无法承受过大的数据量。
- 优点：每个功能都很详细的标明，用户需要什么功能可以自行处理
- 缺点：同一类功能零散的放在页面上，导致页面不整洁，不美观
- 改进方法：可以利用下拉框解决功能按钮杂乱的问题；用户注册和登录页面一样，可以稍微改进为注册页面复杂，登录页面简洁
-
从职业、学历、年龄、专业、爱好、收入等方面概括任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？
典型用户可能集中在年龄段大约在14—20岁的高中（女）生或者50岁以上的老年人，这部分人群比较喜欢能快速找出所需要的按键功能，爱好肯定不是网络游戏，对计算机不太感兴趣的人。他们表面可能只是想通过软件产品完成自己需要的结果，但是潜在却是对计算机的不了解而导致对稍微复杂的页面的恐惧。
-
经过（1）—（3）的工作，你们一定有充分的理由给评价作业选择一个结论:
- a) 非常不推荐
- b) 不推荐
- c) 一般
- d) 好，不错 √
- e) 非常推荐
-
改进后的本小组实验三任务3的Github仓库链接：https://github.com/xwt721/SoftwareProject
fork
clone
pull request
总结
通过查看其他团队的软件工程项目以后明显发现了我们团队的不足，而且在比较过程中也发现了其他团队没有想到的点，这样不仅可以及时互相帮助纠正错误，还可以在软件开发过程中尽量避免这种错误再次出现，保证项目的质量。
在读了《构建之法》第5章、第12章以后对于团队的概念最为深刻，如何做好一个项目真正取决于你在这个团队中担任的角色，你有没有很好的发挥你这个角色的作用等等，希望在未来的道路上，我和我的团队共同奔赴美好而又快乐的生活！
