系统分析师论文范文-论软件开发模型的选择与应用

【#第一文档网# 导语】以下是®第一文档网的小编为您整理的《系统分析师论文范文-论软件开发模型的选择与应用》，欢迎阅读！

论软件开发模型的选择与应用

【摘要】

2010年3月1日至12月20日，我参加了“数据安全访问平台”项目的开发，担任项目经理的工作。该项目是某行业用户“数据中心二期”建设的主要内容，目标是：建立数据统一访问接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段。由于该系统是所有应用的基础平台，对系统的可靠性与性能有较高要求，同时由于没有成熟的现有系统作为参照，该项目存在较高的风险。 本文结合作者实践，讨论了在该项目中的对软件开发模型的选择和应用。首先，根据开发模型的选择原则和本项目在需求方面、技术方面和开发人员方面的特点，我们选择了RUP模型；其次，根据RUP模型，我们将开发划分为4个阶段和若干迭代，在早期迭代中消除主要的风险；最后描述了自己准备从两个方面适应近期软件开发模型的演变。 【正文】

一、项目概述 “数据安全访问平台”是某行业用户“数据中心二期”建设的主要内容。在一期建设中已建成数据的统一存储和统一分发框架。但存在以下问题：无法获得应用用户对数据库的操作日志；开发人员对数据库的使用不规范，查询的结果集过大，导致数据库的性能大幅下降；应用直接使用数据库的登录数据库，存在着一定的安全隐患。“数据安全访问平台”的目标是：建立数据统一访问接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段。 该项目具有较高的业务需求风险和技术风险。由于没有成熟系统作为参照，该项目需求不是很明确。用户有需要解决的问题，但是这些问题如何具体解决，用户说不清楚。同时系统的涉及甲方多个利益相关方，各方对系统的安全和审计功能、运行维护、可靠性、性能和易用性有着不同的观点，某些观点之间还存在冲突。同时系统作为“数据中心”的基础设施之一，所有的应用系统都要通过本系统完成数据库访问。系统的可靠性和性能直接影响到应用系统的正常运行。 2010年3月1日至2010年12月20日，我参加了“数据安全访问平台”项目的开发，担任项目经理的工作。项目组采用了一个精简的RUP的开发模型，在初始化阶段与细化阶段，项目核心成员（3人）完成了需求规格说明书和架构设计，并通过一个抛弃型原型和三个演化型原型（经过性能测试），验证了软件架构能完成满足用户的功能性和非功能性需求，顺利通过用户评审。 整个系统


分为6个子系统，包括JDBC驱动封装子系统、ADO.Net驱动封装子系统、WebService接口子系统、管理配置网站、存储子系统（SQL Server2005数据库，存储配置信息）和监控子系统（数据库网络协议分析与连接控制）。在构造阶段，并加入9个新的开发与测试人员，项目组分为3个开发小组，进行并行开发。 二、开发模型的选择 常见的开发模型主要瀑布模型、敏捷模型和RUP模型。瀑布模型是线性模型，而后两者是迭代模型。线性模型适用于需求明确且稳定的情况；而迭代模型适用于需求具有动态性的情况。敏捷模型与RUP模型都是迭代模型，但是两者对待风险控制上的态度上有本质的差别。敏捷认为，在项目的后期的迭代中，进行较大的需求变更和架构变更是可行的；而RUP认为，在早期迭代中要消除主要的需求风险和技术风险，否则在后期，若两者有大的变动，会影响软件开发的进度和质量。根据我们的经验，更认可RUP对于风险控制的观点。 我们选择开发模型原则是：若项目需求是稳定且明确的，考虑选择瀑布模型，否则考虑选择迭代模型；在迭代模型中，若项目没有较大的技术风险，并且参与开发的人数较少，水平较高，考虑选择敏捷模型，否则考虑选择RUP模型。 根据前期的调研和分析，我们认为该项目具有以下特点： 较高的需求风险：由于没有成熟系统作为参照，该项目需求不是很明确。用户有需要解决的问题，但是这些问题如何具体解决，用户说不清楚。同时系统的涉及甲方多个利益相关方，各方对系统的安全和审计功能、运行维护、可靠性、性能和易用性有者不同的观点，某些观点之间还存在冲突。 较高的技术风险：系统是“数据中心”的基础设施，所有的应用系统都要通过本系统完成数据库访问，系统的可靠性和性能直接影响到应用系统的使用。而系统的体系结构对可靠性和性能有重要的影响。 开发人员特点：核心成员3人，具有较强的技术能力。但由于工作量较大，会分成三个开发小组进行并行开发，同时会加入9名的开发与测试人员，这些成员大都具有2到3年的开发经历，经验不是很丰富，不能承担较关键的任务。 根据项目特定和选择开发模型的原则，我们认为在该项目中RUP是很适合的，最终选择了该模型。 三、开发模型的具体使用 我们将整个项目划分为包括初始化阶段、精化阶段、构造阶段和移交阶段。 初始化阶段，包括一个迭代，三周时间，核心开发人员参与。首先，我们采用用户访谈、用户调查和联合讨论会方式捕获用户需求，详细了解不同利益相关方对系统的预期目标，捕获了在招标书中没有明确的性能需求。其次，我们专门召开一次联合讨论会，在会上由各利益相关方经过讨论统一意见，确定需求优先级。最后，对需求进行分析，确定了项目的目标、特性和用例模型，采用Rational RequisitePro设置了特性和用例的优先级、跟踪性和重要性等属性，完成了《需求规格说明书》初稿，并通过用户评审。 精化阶段，包括三个迭代，每个迭代四周，核心开发人员参与。每个迭代都完成一个原型，消除一个主要


的风险，分别是：用户提出的访问接口的体系结构是否能满足性能要求；访问接口的具体使用形式（类库、函数原型等）是否易于开发人员使用；安全和审计信息的配置界面是否符合用户习惯。这里特别指出通过对第一个原型的性能测试，发现用户提出的体系结构不能满足性能的要求，我们提出一个新的体系结构方案，并开发的新原型，通过测试验证该新结构能满足性能需求，用户接受了我们的方案。该阶段更新需求规格说明书和软件体系结构文档，并完成用户对其的评审。 构造阶段，包括四个迭代，每个迭代五周，分成三个开发小组，加入9名开发与测试人员。本阶段各个开发小组进行并行开发，完成所有的用例并进行了集成测试与系统测试，主要模块都达到了100%的路径覆盖。在该阶段引入了集成构建，每天及时验证软件质量。每次迭代的成果都给用户进行了演示，使用户及时了解项目的进度，并获得用户的反馈，及时调整开发。该阶段结束时，向用户交付了系统的Beta版本。 移交阶段，包括一个迭代，4周时间。由于用户只要求新开发的应用系统使用本系统，不存在老应用移植的情况，因此移交阶段较为简单。本阶段，首先，在该用户提供的测试环境中部署Beta版本，对系统进行Beta测试。其次，开发小组对出现的缺陷做修改，增加文档和培训资料，并对用户进行了培训。最后，配合用户进行了验收测试。 四、开发模型的演变与如何适应 近期软件开发模型出现了新的演变趋势，出现了敏捷开发模型，包括极限编程、特征驱动开发、Scrum等多个开发模型。敏捷开发模型把关注焦点从传统的计划驱动，基于过程的方法转移到更轻量、适应性更强的方法，其主要特征包括：是一种轻量过程，采用短的迭代周期，主动使用户参与到需求工作中，依赖于隐式知识而非文档，主动适应需求快速变更，进行简单设计，经常进行集成和回归测试。 对于开发模型的演变，我准备从两个方面：积极学习新的开发模型，掌握其优缺点和应用场合；对于在软件开发中遇到的问题，积极思考，在保证项目成功的前提下，从相对较小的实践开始，应用新的开发模型。

本文来源：https://www.dy1993.cn/98A.html