201771030103-Chen Zhengli experiment four software project case analysis

project content
Course Class Blog Link https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
This job request link https://www.cnblogs.com/nwnu-daizh/p/12616341.html
My course learning objectives 1. Learning team software project process (TSP), team member collaboration requirements. 2. Master the agile process principles and related concepts.
In what ways does this assignment help me achieve my learning goals 1. Improve the ability to read other people's programs 2. Master the general process of team project development and corresponding requirements 3. Related skills for editing blogs
Student ID-Name 201771030106-Ge Jiacheng
Link the other party to this blog assignment link https://www.cnblogs.com/luor/p/12670178.html

1. The purpose and requirements of the experiment

(1) Learning team software project process (TSP), team member collaboration requirements.

(2) Master the principles of agile processes and related concepts.

2. Experimental content and steps

Task 1: In the homework with a score of 100 points or more in Experiment 3, choose one as a case to evaluate the results of the case project. The specific requirements are as follows:

(1) Read and comment on case blog assignments. The main points of comments include: the relationship between the blog post structure, blog post content, blog post structure and the “task content” column in the PSP, and post the above comments to the blog comment area of ​​the case assignment.

(2) Clone the case project source code to the local machine, read the project code specification document and run the code, summarize the problems in the code operation, and experience whether the case blog post is helpful for the project code understanding.

  • clone code to local

  • Operation results and existing problems

(3) Summarize the problems and deficiencies of the blog operation and code design in the third experiment of this group, list the bugs in the code, unimplemented functions, etc.

Task 2: Collaborate with the three partners of the experiment to learn: Read chapters 5-6 of "Modern Software Engineering-The Method of Construction", understand and master the characteristics of the software project team, understand the model of the software team, and understand the waterfall with the theoretical content Models and their transformations, progressive delivery processes, agile processes and other typical software process model characteristics, understand and appreciate the TSP principles summarized by the Carnegie Mellon University (CMU) School of Software Engineering;

  • 1. Features of the software team:

(1) The team has a consistent collective goal, and the team must accomplish this goal together.

(2) Team members have their own division of labor, rely on each other and cooperate to complete tasks.

  • 2. Software team mode
A swarm mode, attending physician mode, star mode, community mode, amateur theater mode, secret team, secret agent team, symphony orchestra mode, jazz mode, functional team mode, bureaucratic mode.
  • 3. Software development process:

3.1. Code-and-Fix mode is written: there is not necessarily a requirement document, write the code directly, and make changes directly when there are problems or changes in requirements

3.2. Waterfall Model

  • limitation:

(1) The steps are separated, but the steps in the software production process cannot be separated strictly.

(2) Retrospective modification is difficult or impossible, but the process of software production requires time to retrospect.

(3) The final product does not appear until the end, but software customers and even software engineers need to know the prototype of the product and try it out as early as possible.

  • Scope of application:

(1) If the definition of the product is very stable, but the correctness of the product is very important, it needs to be verified every step.

(2) The interface, input and output between product modules can be well defined and verified by formal methods.

(3) The technology used is very mature, and team members are familiar with these technologies.

(4) The sub-teams responsible for each part belong to different institutions or in different geographic locations, and it is impossible to communicate frequently.

  • Various deformations of the waterfall model:

(1) Sashimi model: The adjacent modules partially overlap like sashimi. Disadvantages: It is impossible to determine whether and when the previous phase will end.

(2) Big waterfall with small waterfall: In order to solve the different progress between different subsystems, the technical requirements are very different, and the problem needs to be treated differently. Disadvantages: more difficult.

  • 3.3. Unified Process (RUP)

The master of various models (such as waterfall model, etc.) that emphasizes planning, prior design, and document expression. RUP integrates all stages of software development into a unified framework.

  • RUP procedures (workflow):

(1) Business modeling: UML and other languages

(2) Demand

(3) Analysis and design

(4) Implementation

(5) Test

(6) Deployment

(7) Configuration and change management

(8) Project management

(9) Environment

  • RUP software development stage:

(1) Initial stage

(2) Refinement stage

(3) Construction stage

(4) Delivery stage

  • 3.4. Boss-Driven Process

  • 3.5. Progressive delivery process, MVP and MBP

    Progressive delivery process: development-> release-> listen to feedback-> make improvements based on feedback

    MVP即最小可行产品,又称最小功能集。具体做法是把产品最核心的功能用最小的成本实现出来(或者描绘出来),然后快速征求用户意见。可以适用于新创立的企业在市场不确定的情况下来检验产品是否可行。

    MVP的指导思想与渐进交付类似,但是它更强调更早获得用户反馈,为此可以在产品完成之前就发布,它也强调产品的核心价值(产品最区别于竞争产品的地方),为了突出核心功能,别的辅助功能可以不考虑或者用别的平台提供的服务来代替。

    MBP即最强最美产品,对用户需求了然于心,或者产品团队比用户更了解用户的需求,把产品最全、最美的形态展现出来,一举征服用户。一般应用于时间比较充裕,客户要求标准比较严格,开发团队在此之前做了大规模的市场调研摸清用户需求。

  • 4.TSP原则

(1)使用妥善定义的流程,流程中的每一步都是可以重复、可以衡量结果的。

(2)团队的各个成员对团队的目标、角色、产品都有统一的理解。

(3)尽量使用成熟的技术和做法。

(4)尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。

(5)制定切合实际的计划和承诺,团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。

(6)增加团队的自我管理能力。

(7)专注于提高质量,争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。

  • 5.事后诸葛亮会议、Postmortem:
软件开发完成后进行的事后分析。对产品开发过程进行回顾并对其进行分析,总结不足之处,进而得出改进方案。
  • 6.敏捷流程开发的原则:
(1)尽早并持续地交付有价值的软件以满足顾客需求。

(2)敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。

(3)经常发布可用的软件,发布间隔可以从几周到几个月,能短则短。

(4)业务人员和开发人员在项目开发过程中应该每天共同工作。

(5)以有进取心的人为项目核心,充分支持信任他们。

(6)无论团队内外,面对面的交流始终是最有效的沟通方式。

(7)可用的软件是衡量项目进展的主要指标。

(8)敏捷流程应 能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去。

(9)只有不断关注技术和设计,才能越来越敏捷。

(10)保持简明一尽可能简化工作量的技艺 一 极为重要。

(11)只有能自我管理的团队才能创造优秀的架构、需求和设计。

(12)时时总结如何提高团队效率,并付诸行动。

  • 7.敏捷的步骤:

第一步:找出完成产品需要做的事情——Product Backlog

第二步:决定当前的冲刺(Sprint)需要解决的事情——Sprint Backlog

第三步:冲刺。期间团队通过每日例会(Scrum Meeting)进行面对面交流,所有人向同伴报告进度。Scrum Master根据项目情况,用简明的图表展现整个项目的进度(燃尽图Burn Down Chart、看板图Kanban)

第四步:得到软件的一个增量版本,发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

  • 8.敏捷的团队:

(1)自主管理:自己挑选任务、每次冲刺结束后总结经验并改进

(2)自我组织:每个人联合起来对项目负责

(3)多功能型:项目的测试、说明书等由每个人负责

  • 9.敏捷流程的经验教训:

(1)敏捷宣言表明的是一些优先级, 不必当作圣旨或者教条来争论。

(2)Serum Master 不是一个官, 而是一个没有行政权力的沟通者,就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master,大多行不通。

(3)一些项目需要很多暗箱操作和政治角力才能搞定,Scrum会把这些矛盾都摆到明处。这有好处,也有风险。

(4)在复杂的项目里,要让一线团队成员做决定。

(5)创业公司的团队其实经常是运行在某种快节奏的敏捷的模式中(只不过大家太忙,没工夫论证自己到底有多么敏捷)。

(6)在Scrum 计划阶段的估计不是一个“合同”,领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint,这样即使不准的估计也不会有大的损害。

(7)不要和管理层谈“流程”,他们只关心“结果”。

(8)在大型团队、跨地区的团队,或者复杂项目中,Scrum 并没有非常完美的答案,Scrum的创始人也承认这一点。

  • 讨论任务2截图:
  • QQ聊天截图

  • 在文本文件中互相交流学习情况

结对方学习成果

自己学习成果

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

1. 2016级计算机科学与工程学院软件工程 (西北师范大学)

2. 2019秋福大软件工程实践Z班 (福州大学)

3. 2019春季计算机学院软件工程 (北京航空航天大学)

我们选择的是:2019春季计算机学院软件工程 (北京航空航天大学)

(一). 团队项目作业发布账号链接:https://www.cnblogs.com/LightOfFuture/

(二). 团队项目仓库GitHub链接:https://github.com/ThinMoon/ESchool

(三). 选择该团队项目进行分析的原因:

  1. 由于我们平常与学校内的人员接触较多,因此想选择外校学院的团队项目进行学习;

  2. 由于在外校的团队项目中,移动应用程序开发较多,而我们对移动应用开发不够熟悉,因此选择了其他的团队项目;

  3. 经过大致浏览,所有的团队项目中,这一个团队的项目我们较为感兴趣,比较贴近我们的校园生活。

(四)项目团队成员分工合作情况

  • 1.团队的角色,管理,合作
(1)团队的每个角色是如何确定的,是不是人尽其才?
 答:角色是当初在进队伍后大家自己选择的。人尽其才的话,由于我们组组长是比较有代码能力的,在后端工作上很大依赖于他,要是当时把任务多分派下去,感觉人力资源能得到更大的利用。  

(2)团队成员之间有互相帮助么?

 答:有,主要是在前端彼此和后端彼此,然后组长给了我们很多帮助。  

(3)当出现项目管理、合作方面的问题时,团队成员如何解决问题?

 答:项目管理方面的问题主要通过开会讨论解决,合作方面一般是由合作双方自行商讨。

  • 2.团队成员分工

(五)项目的软件项目过程特点(TSP)

(1)团队的各个成员对团队的目标、角色、产品都有统一的理解。

(2)分工明确,团队成员的自我管理能力强。

(3)团队各个成员在每次学习中都会总结学习成果以及第二天的学习计划。

(4)团队成员掌握技术水平不一致,人尽其才,项目中的技术是使用成熟的技术;

(六)该团队项目github仓库的源代码文件结构,是否包含代码规范文档?(TSP)

  • 该团队的Github页面如下图所示,并没有包含代码规范文档

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

- clone该团队项目到本地

  • 该团队在Github中提供数据不完整,在做了相应的完善后,运行结果如下:

  • 数据库设计图

  • 数据库详细设计

  • 测试运行结果

  • 项目主页界面如下图:

  • 用户登录界面如下图:

  • 发现的Bug如下:

  • 在用户的注册流程中,将基本信息填写完成的情况下点击注册将生产错误图1,身份证号码一栏的数据没有传输至后台,在检查了项目代码之后发现在网页中发生错误图2。

用户注册界面如下:

错误图1

错误图2

  • 在正常登录用户后,用户的个人页面如下面两张图,可见用户的信息没有同步显示在前端网页中。

![](https://img2020.cnblogs.com/blog/1946992/202004/1946992-20200410211418147-1422612861.jpg)

除了上述出现的问题外,还存在其他的Bug和可优化内容。

(八)评价该团队项目是否值得继续开发,并陈述理由

    这个团队项目主要研发的是顺风车、校园兼职、代取快递,能满足当代大学生的实际需求,大部分学生因为懒惰或者特殊情况而需要代取包裹,家庭经济比较困难和需要锻炼自己能力的同学就非常需要校园兼职这个平台来寻找合适的工作,没有人不需要出门办事打车的,综合所有的因素,这个项目能满足当前市场的需求,因此这一项目值得进一步开发,如果能扩展更多的功能最好。
  • 完成《实验四 软件项目案例分析》各项任务实际花费的时间
内容 计划花费时间(h) 实际花费时间(h)
总计 32 48
任务1 10 18
任务2 5 6
任务3 15 20
任务4 2 4

四.总结

    此次试验的目的是学习团队软件项目流程(TSP)、团队成员协作要求。并掌握敏捷流程原则及相关概念。通过阅读《现代软件工程—构建之法》第5-6章内容了解且掌握了相关的概念,理解并掌握了软件团队的特点以及在团队协作过程中应该注意的事项,浏览并其他同学\团队的博客并测试优秀案例,从中获益匪浅,同时也能清楚自己和同学之间的差距,在以后的学习中会更加注意对内容的理解。

Guess you like

Origin www.cnblogs.com/chenzhengli-/p/12669822.html