作业2

这是我所了解过的一个软件开发团队的开发流程：

基本流程：需求分析-概要设计-详细设计-软件编码-软件测试-软件交付-客户验收-开发人员维护-项目重构：

需求分析：

一个软件没有出现之前，只是有一部分人会有一个想法，需要一个这样的东西，用来管理什么，有想法的出现就会有需求，就会找软件公司需求分析师来商量，这个时候相关人员开始动工，需求分析是听完要求以后会将大概的功能描述一下，用Word或者Axure画出一个简单的Demo给用户看，经过几次确认以后需求分析师会最后确认功能是不是完善的，确认了以后进行我们的下一步。

概要设计：

这个功能主要是干嘛的呢？很多的公司觉得没必要，其实是很有必要的，这个就是相当于先规划一下怎么顺利的开发出软件，对于软件来说就是软件的处理逻辑，大概的一个流程是怎么走的，大概需要哪些模块，怎么运行，需要大概多少接口，后期怎么维护等问题，这样才可以进行下一步。

详细设计：

有人觉得这是最难的一步，详细设计主要是用来确认细节的，接口的名字啊，控制器的名字啊，多少个控制器，谁来调用谁，这个不可以有错，因为后期开发人员是需要看这个开发的，你怎么起名字，他们就怎么写，所以这里出错也就意味着编码的时候也会错，最后会有一份详细设计书出现，就会写出具体的开发流程。

软件编码：

很多人觉得这个就是搬砖，看着设计书就直接写就可以了，理论是这样的，但是为什么还有很多的bug出现呢？很大一部分原因并不是设计的原因（当然也有可能），很大原因是不规范造成的，还有就是是不是一个项目组的人可以协作处理代码，怎么做可以提高编码的效率，这些问题都是在编码的时候出现的问题。这要涉及的每一个开发人员的编码是否规范。

软件测试：

这也是重要的一步，不可能说写好直接就给用户用了，这个是不现实的，需要做的是先给测试部门进行系统的测试，这个测试不是按照用户的想法来的，会很暴力，举个栗子，一个按钮，正常的用户使用的时候会直接点击一次，看到效果就可以了，但是测试的时候不是，他们会疯狂的点击，知道他们觉得这个世界上不会有人比他们暴力的时候他们会停止，当然这是一个好的测试人员，很多的测试不会是这样的，他们觉得正常使用没问题就是没事的，其实一个软件好不好，很大一部分在于测试人员的测试力度。最后写一份测试报告就可以了。

软件交付：

测试结束以后没有任何的问题的话，就可以编写用户使用指南了。

客户验收：

交付后客户简单的测试以后觉得符合自己的要求，就可以收货交钱了。

开发人员维护：

不是说验收以后就没事了，一个软件很多时候是在用一段时间以后才会出问题的，所以会一直需要人来维护他们，当然不是说只是出问题才会维护的，主要的原因是软件会根据不同的需要更改功能，这样的过程也是维护的过程。

项目重构：

这个是一个项目如果出现了新的技术，功能没有改变的时候，为了用户体验，例如之前是SSH写的，但是运行的速度很低，用SpringBoot，大家都在用，用户反映很好，那么这个时候就需要项目重构了，用新的技术将之前的功能重新实现。

最喜欢的团队类型：

业余剧团模式 (Amateur Theater Team):

这样的团队在每一个项目（剧目）中, 不同的人会挑选不同的角色。在下一个剧目中, 这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中, 这样的事情经常发生。

交响乐团模式：交响乐团门类齐全，各司其职，演奏都靠谱，同时看指挥；当某个软件领域处于稳定成长阶段时时比较适用。

我们在这门课中最应该采取交响乐团模式。

交响乐团模式的优劣：首先团队人员可以按照已经制定好的规章进行工作，并且对自己的工作很熟悉，每个人都知道自己能干什么，团队需要你干什么，能把每个人放到合适的位置，而只有一个决策者的好处就是执行力十分强大，不会出现较大的分歧，即使个别人员出现什么差错，也可以根据之前制定好的补救措施及时进行补救。然而，有利必然有弊，在这种相对稳定的模式下，一旦出现打破稳定的情况出现，例如说出现了大面积的差错，无法即使解决或者之前根本没有考虑过有这种情况发生，那么整个团体就有可能面临崩溃。同时这种模式我认为只适用于一个已经稳定的团体，如果是对一个经常会出现变动的团体来说，这种模式下的人员缺乏相互之间的交流。