201771010107-冯志霞 实验四 软件项目案例分析

项目	内容
课程班级博客链接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
我的课程学习目标	通过案例分析学习别人项目的开发过程，补足自己专业技能的不足，并且掌握团队开发模式
这个作用在哪些方面帮助我实现学习目标	1.更好的学习团队项目如何开展，并且将团队优势极大化2.更好的进行团队交流
结对方学号-姓名	201771010114-李晓菁
接对方本次博客作业链接	https://www.cnblogs.com/li-xiaojing/p/12664749.html

任务一 ：在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价。

选择案例：王之泰&韩腊梅组

案例作业博客链接 https://www.cnblogs.com/hanlamei/p/12574378.html
案例作业项目仓库链接 https://github.com/YHwzt/Query-system-web

对案例项目成果进行评价，具体要求如下：

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

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

（3）系统运行截图

• 注册
  

• 录入信息
  

• 后台信息可视化展示
  

• 高级查询
  

存在的bug

（4）软件功能总结

系统可采集学生疫情有效信息；
学生在前端提交信息到后台；
各学院指定负责人登录系统，可查看学生填报的所有汇总数据
负责人可根据学生的姓名，学院，地址查找相关信息
负责人能够增删改查学生的信息
每日十点之后停止填报
负责人通过【导出】可获取疫情数据的EXCEL文件
负责人可通过可视化方式查看各学院已填报和未填报学生统计情况和关键疫情数据统计情况
填报提醒功能通过邮件的方式定时向学生及负责人发送疫情填报提醒

(5).符合（2）要求的系统运行截图、软件功能总结；附加分要求：若测试发现案例代码存在bug，截图为证，一个bug得2分，本次作业附加分最高不超过10分；
当我给我自己发送邮件时，得到的却是垃圾邮件，这就说明还未过qq邮箱那一关，需要改进

(6)符合（3）要求的总结，代码运行存在的问题截图为证。

• 问题与不足：
  博客作业符合作业的要求但是我觉得GUI界面不是很美观，需要继续改进。
• 存在的bug:
  其导出excel的时候,导出的查询数据在同一行。
  
  （7）总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。
• 本组的项目为实现提醒填报的功能
• 本组导出的excel文件也不是竖向的，横向，并且当时没有注意这个问题，砍了别人的评论才意识到

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

1. 软件项目团队的特点：
   （1）团队有一致的集体目标，团队要一起去完成这个目标，一个团队的成员不一定要同时工作。
   （2）团队成员有各自的分工，互相依赖合作，共同完成任务。
   2.软件团队的模式：
   主治医师模式：各司其职，为主治医师服务。
   明星模式：主治医师模式的极点。
   社区模式：每个人参与自己感兴趣的方向。
   业余剧团模式:每个团队在不同的项目会挑选不同的角色。
   秘密团队：每个人在秘密条件下进行。
   特工团队：有特殊技能的专业人士。
   交响乐团模式：交响乐团的演奏模式。
   爵士乐模式：与交响乐队模式对立。
   功能团队模式：具备不同能力的人平等协作。
   官僚模式：小头目-->中头目-->大头目。
   3.软件开发流程：经过和结对伙伴讨论我们认为软件开发流程是为了提高软件开发、运营和维护的效率，是在最短的时间内，效益最大化。我们的软件基本上和功能团队模式相近，但有不同，我们在协作过程中，确实在各司其职，做自己擅长的，能做得出来的部分，但是又在整体中不断的更改，所以具体模式也没有一个定义。
   4.典型软件过程模型：
   （1）瀑布模型是出现最早，使用最广泛的开发流程模型。它适用与产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；产品模块之间的接口、输入和输出能很好的用形式化的方法定义和验证；使用的技术非诚成熟，团队成员都很熟悉这些技术；负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。它的变形有：1）生鱼片模型：各个相邻模块像生鱼片那样部分重叠，这个模型解决了各个步骤之间分离的缺点。2）大瀑布带着小瀑布：为了解决不同子系统之间进度不一，技术要求迥异，需要区别对待的问题，引入了子瀑布模型。
   （2）统一流程（RUP）：它将软件开发的各个阶段整合在一个统一的框架里，要完成一个复杂的软件项目，团队的各种成员要在不同的阶段做不同的事情，这些不同类型的工作在RUP中叫做规程或者工作流。RUP把软件开发分成四个阶段，一个大阶段结束称为一个里程碑。四个阶段分别为：初始阶段（生命周期目标里程碑）、细化阶段（生命周期结构里程碑）、构造阶段（初始功能里程碑）、交付阶段（产品发布里程碑）。
   （3）渐进交付的流程：
   1）MVP：最小可行产品，或者最小功能集。它将产品最核心的功能用最小的成本实现出来，然后快速征求用户意见。为了突出核心功能，别的辅助功能可以不用考虑或者用别的平台提供的服务来代替。
   2)MBP:最强最美产品，对用户的需求非常了解，或是产品团队比用户更加了解用户的需求，将最全最美的产品展现出来，赢得用户。
   （4）敏捷流程：敏捷开发的原则有：尽早并持续地交付有价值的软件以满足顾客需求，欢迎需求的变化，并利用这种变化来提高用户的竞争优势，关注技术和设计，才能越来越敏捷等等。在Scrum 方法论中提出：1）Product Backlog：积压的工作、待解决的问题、产品订单。（2）Sprint Backlog：当前的冲刺需要解决的事情。3）冲刺。在此期间通过Scrum Meeting（每日例会）来依次报告昨天都做了什么工作、今天的工作计划以及遇到的问题等等。

TSP原则：

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

讨论截图

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

（1）团队项目作业发布,账号链接
（2）团队项目,github链接
（3） 陈述你选择该团队项目进行分析的理由。

• 项目的目标人群是手机使用者，所以使用了比较好操作的人机交互界面。
• 项目实现使用手机对家庭财产进行管理，具有传统的手工财产管理所无法比拟的优点，比如：记录和查找更加方便，信息存储量大，可靠性和保密性好，它实现了登陆模块、 成员管理模块、 收入管理模块、支出管理模块、 综合管理模块等，实现了经济上的可行性，操作上的可行性和技术上的可行性。
• 加入了对用户具有诱导性的按键设计，使得用户在初次使用的时候就会使用，这对于受众人群的使用是非常便捷，易操作的。
• 这是一款APP的开发，对于现在的学生来讲非常需要一款理财产品来束缚自己，所以出于好奇也想使用一下这个APP。
  （4）结合项目系列博客文档，总结项目团队成员的分工合作情况。
  该项目团队一共有四人组成。各成员大致分工情况如下：

成员	主要任务
杨XX	设计问卷调查问题并总结、进行系统设计、编码、、模块测试、发布产品
焦XX	进行需求分析生成说明书、进行功能分析、编码规范说明 、编码测试、模块测试
王XX1	学习使用新工具、绘制各类关系图、页面布局、模块测试、安装模拟器进行总体测试
王XX2	人员分工、撰写系概要书、总结每次例会内容、模块测试、设计问卷调查产品使用感进行功能改进设计
(5)结合项目系列博客文档，评价项目的软件项目过程特点（TSP）。
软件项目过程特点：

• 使用妥善定义的流程，流程中的每一步都是可以重复的、可以衡量结果的，在项目开始时便制定了项目流程，使用wps进行工作记录，并按照该流程进行开发。
• 团队的各个成员对团队的目标、角色、产品都有统一的理解，团队成员进行商议，研讨之后确定了成员分工，以及产品定义。
• 尽量使用成熟的技术和做法，项目使用了Visio、Rational Rose、PowerDesign等现有的软件和技术。
• 尽量多的收集数据（包括对团队不利的数据），并用数据来帮助团队做出理性的决定，进行了问卷调查，对于用户对产品的使用感进行了分析并改进功能。
• 制定切合实际的计划和承诺，团队计划要由负责具体执行的角色来制定（而不是从上级而来），通过每日立会每位成员进行每日工作的总结和今日切实可行的工作计划。
• 增加团队的自我管理能力（没有发现）。
  (6)观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？（TSP）。

GitHub仓库包含代码规范文档

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

• 第一个bug为用户登录界面（没有用户注册界面录）
  
• 第二个bug为登录成功后的界面（感觉没有按需所做因为题目和内容不太适应题目是理财APP，内容显示为员工管理不太合适吧）
  
• 员工信息添加界面
  
• 员工信息修改界面
  
• 员工信息删除界面
  
• 员工工资管理界面（该界面可以管理财务）
  
• 部门管理界面（对于人员所属部门进行了分类，没有看到进行部门划分后的权限有所不同）
  

使用体验：

该款APP首先打开后并没有注册界面就直接登录，用户体验感不是很好，从密码存储在数据库，并没有进行加密操作，不够安全。基本功能还算是全面有相应人员的增删改查，但是我和结对伙伴没有理解既然是家庭理财APP为什么有员工信息这一界面。重点界面是进行工资管理的界面，将底薪、奖金等输入后会核算出实发工资金额，将其保存，还有最后一个人事管理的界面，区分了部门等。这更像是一个企业的财务部对员工工资进行管理的APP。

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

我觉得该项目不值得继续开发，从社会效益考虑：现在的社会趋势对于大多数家庭或者学生来说，一款理财产品在日常开销中是非常需要的，但毕竟是与财产相关的app这安全性就不容小觑；经济可行性：开发产品就有一定的成本投入，如果后期带来的效益不足以投入目前所要付出的成本，这本身就没有开发的必要了。况且目前微信小程序是流行趋势，使用也更加方便，成本也较低；从技术可行性角度考虑：该项目在GitHub仓库中已经提供了代码编码规范，所以对于之前代码的理解是没有太大问题的，但是由于之前的功能并不完善，所以开发耗时较大。

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

任务	耗时
任务一	2h
任务二	3h
任务三	5h
任务四	1.5h

五、完成本次作业的感受和体会。

本次作业由任务一通过案例项分析，我看到自己项目与别的同学项目之间的差距，自己编码的风格，代码设计风格，以及代码规范等方面都存在很大问题，借鉴他人的项目我可以学到很多知识，不仅仅是技术的提示也有习惯的改变等等任务二学习到软件项目团队的特点、软件团队的模式、瀑布模型、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则，这些内容虽说现在还没有完全理解，在于同伴的的讨论过程中也大致有所领悟；任务三我们选择的家庭理财APP个人觉得这种小众产品虽说没有再续开发的意义，但是他一方面也反应了现代人的特点，在某种程度上还是有督促我们养成合理消费，健康理财的理念。