软考（高项）系统分析师--论软件开发模型及应用

---

前言

本文对系统分析师，软件开发模型及其应用文章进行展示，可以拷贝后直接粘贴到word 文档中。

---

一、前期准备：

• 项目主体功能
• 项目背景
• 常用的软件开发模型：瀑布模型；原型模型；螺旋模型；V模型；喷泉模型；等

二、论文部分:

摘要：
	2022年12月，通过公开招标的方式，我所在公司中标x集团地产公司，设计系统的开发工作；我有幸作为系统分析师，参与该项目的分析与设计工作；改系统主要包括，个人工作台，标准化管理，项目管理，系统管理4大功能模块；该项目对设计工作的各个流程进行标准化模块管理，建立线上标准化产品库，并且联动成本系统和运营系统，对标准化模块进行成本赋能，结合营销导向定位，精准解决项目痛点，提高项目利润；同时标准化的管理流程，提高工作效率，减少管理成本。

	该项目于2023年11月，历时11个月，正式交付运行至今，受到客户的一致好评；由于该系统成本系统和运营系统的中间层，对系统的可靠性和性能都有较高要求。本文结合笔者的实际工作经验，对项目的开发模型及应用进行论述；首先，根据开发模型的特点以及综合考虑到需求方面，小组成员的经验和技术，经过项目组成员的开会讨论，我们决定使用RUP 模型进行开发；其次，根据RUP模型的特定，我们将项目开发分为4个阶段和若干迭代，在项目早期尽可能的消除风险；最后，论述笔者在本项目的经验经验总结，不足以及改进方法；

项目背景：
	x集团地产公司下，有x个局院；由于历时原因及行业特点，每个局院都建立了自己的项目管理，集中采购，ERP等系统；目前行业系统的建设方式有国内软件，国外软件，以及自己局院各自开发的系统；这些系统或基于各自单位的业务需求，或基于特级资质的基本要求，各单位系统之间尚未有效集成，无法确保数据从产生到使用的及时性和准确性；在业务层面上各单位的应用水平差异大，基本功能模块类似，重复投资；在数据层面上，各单位主数据不一致，出现指标同名不同义，同义不同名，相同指标口径计算不一致，各单位系统数据孤立；从技术层面上，各单位技术平台水平差异大，多数单位系统架构落后，给集成，升级和维护造成困难；从运维层面上来说各单位的运维能力不足，未能建立完善的运维体系；基于此个局院地产需要统一建立一套系统；

	2022年12月，通过公开招标的方式，我所在公司中标x集团地产公司，设计系统的开发工作；我有幸作为系统分析师，参与该项目的分析与设计工作；改系统目的是实现，地产设计研发，项目管理全过程的规范化，动态化管控；改系统主要包括个人工作台，标准化管理，项目管理，系统管理4个模块；其中个人工作台，用于登录用户用于查看代办任务，公告信息等；标准化管理模：将产品设计标准化管理，对设计管理过程中用到的数据进行在线化标准化管理；项目管理模块：对项目设计业务的全过程进行管理，运用分级管控模式，实现设计全专业的计划流管控；系统管理：实现对用户权限及基础字典进行管理；

过度：
	在开发过程中，我们常用的有瀑布模型，原型模型，敏捷开发模型，RUP统一过程模型；其中，瀑布模型特点是自上而下，依次执行，前一过程的产出物是后一过程的输入物，该模型适应于需求明确的场景，因为其结构化的特点，后期对于需求的变动和数据的变动难以应对；
其中，原型模型特点是给出客户原型，然后经过客户评审，评审通过之后进行实现，适应于需求不明确的场景，因为其经过客户的评审，后续用户对实现的功能容易接受，不过改模型并没有很好的对其风险进行考虑；RUP统一过程模型也是一种迭代模型，改模型在前期就尽可能的消除风险点。经过项目组成员的讨论最终确定使用RUP统一过程模型进行项目的开发，我们将项目开发分为4个阶段和若干迭代，在初始阶段通过和领导层用户进行访谈，确定项目的主体功能，通过需求联合会议对不明确的需求进一步进行讨论，最终形成需求规格说明基线文档，并通过客户的审核；在细化阶段根据系统的模块，使用B/S架构，微服务模块，将整体服务拆分为系统设置，项目管理，标准化管理，个人工作台4个小服务，分为3次迭代，根据用户的需求，确定系统的体系架构；在构建阶段：分为4次迭代，3个开发小组并行开发，对所有用例完成集成测试，和系统测试，主要模块达到10%的路径覆盖；移交阶段，首先根据用户的需求使用程序进行历史数据的迁移，然后部署Beta 版本，进行测试和修改，并对用户进行培训，最终协助用户完成系统的验收。下文主要对RUP的前3个阶段进行论述；

正文：
	初始化阶段，包括一个迭代，4周时间。首先，我们通过访谈x集团公司几位高层领导的方式，获取到了项目预期的功能，并且获取到了在招标文档没有明确的系统性能要求；其次，我们邀请x集团的中层领导，以及核心研发人员，进行线上会议，对一些有争论的需求，进行讨论，从而完成需求的确定；其中我们着重讨论了x个局院，对于各自数据存储的要求，并结合实际，确定每个局院各自存储本局院的数据，可以在技术层面上对各个局院的数据进行汇总整理，出具数据的可视化图形报表；最后，通过数据流图，功能原型，来分析确定需求，并排出需求的优先级，形成《需求的规格说明书》的初稿，并通过用户的评审。

	精细化阶段，包括3个迭代，每个迭代耗时三周。系统整体使用BS架构，采用微服务模式进行项目的开发；对于每个迭代都完成一个原型，消除一个主要风险。分别是：多个局院使用同一套系统，如何保证数据的隔离，及对多个局院的数据进行报表统计；对接上下游系统的接口如何保证数据的安全及接口性能要求满足；各个系统怎么能确保数据主键id的唯一性，从而保证数据可以顺利入湖；这里特别指出对于数据的隔离体系，用户提出多个局院数据可以放入同一个库使用局院编码进行区分，通过实际测试发现，改方案不能满足接口的性能要求以及违背项目的易维护性要求，我们提出了一种新的数据隔离体系，使用多数据源动态切换来实现数据隔离，开发新的模型，并且通过测试验证新的体系满足性能及易维护性的要求，最终客户接受了我们的方案。我们更新了需求规格说明书软件体系结构文档，并通过用户的评审。


	构建阶段，我们分为3个小组并行开发，包括5个迭代，每个迭代耗时五周。分别是：设计系统人员的单点登录，并根据用户角色展示不同的数据操作权限，进行操作权限隔离；为不同的业务建立对应指标标准库，初始化指标的标准模版，完成指标的标准化定义；完成核心业务如项目管理下的，楼栋地块管理，分期计划轨道，面积指标，产品适配，成果管理等功能；对接下游系统的审批流程及推送对审批通过的指标进行数据推送；个人工作台展示代办任务及公告信息，是其可以可以进行在线办公；每次迭代都将成果展示给客户，使用户了解项目的进度和功能，并收集客户端的反馈，及时调整开发。开发完成对所有用例完成集成测试和系统测试，主模块达到了10%的路径覆盖，出具测试报告，确保了项目的功能。改阶段结束后向用户提供项目的Beta 版本。

	移交阶段：包括一个迭代，四周时间；首先通过程序对用户的原有项目及分期数据进行迁移；其次，部署Beta 版本供用户测试，收集用户反馈，对系统的缺陷及时进行修改；最后，对用户进行了培训，并配合用户完成系统的验收。

结尾：
	从2020年12月项目开始，历时11个月，该项目于2023年11月正式上线运行至今，受到了客户的一直好评；在本次项目中，我对RUP 开发模型有了更加深刻的学习和体会，对RUP的四个过程有了更加清晰的认识；，众人拾柴火焰高，一个项目的成功上线离不开团队的每一位成员的辛勤付出。同时也意识到随着用户需求的演变，对应软件开发的模型也在逐步演变，一些新的软件开发模型也在应运而生，如敏捷开发，极限编程等，不同的开发模型有着各自的特点，我还需要积极学习更多的开发模型，总结各个开发的优缺点及使用场景，在未来的软件分析与设计中更好的进行应用和实践。