为软考准备的论文！！

2019年上半年软考成绩出来查完松了一口气，也在预料之中论文涉险过关。虽然没压中题目不过使用的案例和相关的点都一样，硬着头皮写完。
去年的架构论文昏昏沉沉的两个小时才写了1900字，这回龙飞凤舞写居然提前15分钟写完了。把文章公布出来仅供参考，案例是不能再用了。

论软件开发模型的应用
摘要：
软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。针对不同的项目使用不同的开发模型能够有效的提高项目成功率。
本文将结合某省级《机动车驾驶员计时培训系统》的开发过程介绍，如何在中型的管理系统中使用“统一过程过程模型UP“与”敏捷开发方法（SCRUM）“，并结合面向服务的微服务开发方法完成整个软件项目。在该项目中本人担任系统规划、分析及架构设计的工作。本文将着重讨论统一过程模型UP与敏捷开发方法SCRUM在项目中的各实施步骤和取得的效果。最后本文还将讨论本项目开发时碰到的困难和存在的问题。
正文：
2017年初本人接受了某公司的委托负责组织人员开发某省的《机动车驾驶员计时培训系统》。项目包含了软件部分、车载终端部分、服务器、网络、安装调试等。项目使用范围涵盖省级主管部门、所有地级市以上的驾考培训机构和主管部门。本人在该项目中除了负责部分组织协调工作以外，主要负责软件部分的需求分析和架构设计工作。该系统需要按照交通运输部2016年修订的《机动车驾驶员计时培训系统平台技术规范》来进行开发。该项目的中标公司是一家负责交通路网工程的公司，并没有太多的软件开发背景，造成了后期运维相当困难。公司高层决定基于这一项目培养自己的软件开发和运维团队。本人在基于以上相关因素初步确定了软件的开发模型和系统架构。
传统的软件开发模型有瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型、统一过程模型、敏捷开发方法。最早的瀑布模型严格遵循工程化的思想，规划、分析、设计、评审、构建、验收、交付每一步都需要上一步的结果做为输入。原型模型则是快速开发一个小型版本并不断演化或抛弃，对于规模不大，需求不明确的项目有较好的效果。螺旋模型则是瀑布模型和原型模型的综合强调了风险的控制。喷泉模型是早期的面向对象开发模型，核心特点是迭代，分析、设计、编码等活动的边界不明显允许交叉进行。统一过程模型UP是一套完整的开发组织方式，核心是用例驱动、架构为中心、迭代与增量。分为初始、细化、构建、交付四个阶段。敏捷方法同样也是基于面向对象的，强调的是可工作的软件强于繁琐的文档，并且敏捷方法提出了许多实用性的软件开发方法。敏捷方法可以做为统一过程模型的一个补充来使用。
针对本项目的特点我们确定了采用统一过程模型UP与敏捷开发SCRUM结合的方式进行。
在仔细阅读了《技术规范》后得到了两点结论，一、规范中已经将《监管服务平台》和《计时平台》所应具有的功能描述得比较详尽。可以直接将文件中的相关说明直接转化为用例。这就符合UP中用例为中心的思想。二、《技术规范》中将个省级平台中的静态数据同步接口全部统一成为restful的方式，并且强调了采用事件驱动的方式进行。基于这点决定了该系统的中心架构是基于事件驱动的微服务架构。这也符合UP模型的以架构为中心的思想。
敏捷方法SCRUM的核心是用户故事，不同于传统的用例、用户故事可以是一个较为模糊的需求描述，在开发时将分析与设计的权利都赋予具体的设计人员，在例如预约教练、预约考试、支付管理、刷卡、刷脸、登记等受众面广、强调用户体验的功能时，能够更快的发布新版本。
遵循UP模型分为下面四个阶段
在初始阶段
1.识别系统的主要参与者，通过分析《技术规范》中所要求的功能模块整理出主要参与者如：全国驾培平台、省级交管部门、市级交管部门、驾驶培训机构、教练车终端、教练、学员等。识别主要参与者的目的是为了更好的划定系统边界。
2.确定项目边界，制定大体的开发计划。在这个阶段的工作对于项目的成败非常关键。在调研时发现各市级交管部门已经有在运行的计时培训系统但规则和管理范围都不一致，且系统管理的范围也不一致。因此为了防止需求蔓延在与省级交管部门开会时就明确了，所有教练车终端数据直接通过Socket通讯方式传输给省级平台不再直接与原市级平台对接，市级平台通过省级平台统一的restful接口获取数据，原有市级平台的改造由各地市负责不列入此项目。类似的项目风险在第一轮与第二轮迭代中还有很多，此处不一一列举。
3.定立系统的业务模型、建立系统目标里程碑完成初始阶段。订立目标就是建立省级监管服务平台、和省级计时平台，全省教练车终端与省级计时平台时时通讯。两个平台与相关的系统有统一的静态通讯接口。
在细化阶段首先制定需求获取方案。监管部门相关人员采用访谈、开会等方式进行。对于驾驶培训机构相关人员采用采样、观摩、问卷调查等方式进行。然后需求分析阶段进一步细化参与者和用例，并确定用例之间关系。确定了系统的总体框架后利用效用决策树将系统的基础服务和重要服务构件排序，确定开发顺序并分配开发小组。将例如车载认证、场地同步、终端学时同步、地图GIS绘制等服务列为关键的高风险点重点开发并提供备选方案；将培训机构、教练车、教练、学员的服务等列为优先开发的基础服务；将监督、投诉、评价等列为非重点服务，将预约、收费、检查等列为第三方服务。最后制定出详细的开发进度表。
在系统构建阶段，在此阶段大部分的服务采用敏捷开发SCRUM的方式分小组进行。敏捷开发做为统一过程模型的补充我们在此项目中主要经借鉴了SCRUM几个方法。一、用户故事。在细化阶段并不能将所有的用例都一一细化，需求获取、分析在开发阶段常常也一直在迭代进行，因此需要在一些服务开发时将分析的权利放到设计师头上，充分发挥软件设计师和前端设计师的作用。二、使用燃尽图代替甘特图等繁重的项目管理文档，同时也避免了口头汇报工作的不准确性。三、站立会议每天的短暂会议可以了解小组成员开发时碰到的困难以便按能力和兴趣重新分配任务。或成员间提供技术帮助。
我们按照开发计划将受众面广、并发高的20%的功能做为第一轮分析、设计和构建的重点，由核心小组的成员完成。剩余80%的功能由有经验的软件设计师和前端工程师带领在校学生或实习生完成。这样安排原因有两点，一、本项目整体是基于面向对象的方法学进行开发的。对于使用关系数据库开发项目经验越丰富的开发者面向过程的思维就难以转变，会造成项目代码严重依赖数据结构。这与我们采用的微服务架构相背。采用实习生可以将“系统结构存在与对象之间，数据库只是对象的持久化工具”的思想灌输给他们，也有利于培养后期运维队伍。二、采用校企合作或实习生可以有效降低工资成本。
交付阶段我们在关键服务完成80%的时候就开始与在部分地市开始与车载终端的安装进行部署与联调。在第二与第三轮迭代完成全部的安装、测试工作。在此阶段同时将一些开发人员转成后期维护人员，专门阅读文档和编写测试用例。
本系统在2017年10月份完成主体功能，2018年初随车载终端在部分地市联合调试运营，2018年底完成了一期投资所要求的所有功能服务。由于该项目是与驾校合作从学员培训费中回收投资成本，因此后期的运维团队格外重要。基于前面所采用的开发策略，后期的维护人员直接从开发人员中转换过来保证了技术连续性这也是本项目的一大特点。
虽然本项目采用面向对象的方法和敏捷开发来应对需求变化但开发过程中还是由于政策变化导致了部分服务完全重构。在做系统的分析和设计时都是基于《技术规范》，该规范还是以面向过程的方法为核心，假定系统已经存在来规定系统应该做什么，这样导致我们前期抽象用例时有很多不准确的地方，带到开发阶段导致迭代次数过多发布了一些无用的版本。但总体来说项目还是较为成功的。