软件开发模型（精选十篇）
软件开发模型（精选十篇）
软件开发模型 篇1
敏捷开发, 它是一种软件开发方法学, 可以应对客户快速变更的需求, 用来替代以文件驱动开发的瀑布模型。敏捷开发与传统开发过程的最大的不同之处在于它强调以人为核心, 团队有激情、有活力能够适应需求的不断变化。随着敏捷开发的流行, 越来越多的公司开始采用敏捷开发技术。Scrum模型是敏捷开发的一种, 它是一种迭代的增量化过程, 用于产品开发或工作管理, Scrum中发布产品的重要性高于一切。开发软件就像开发新产品, 无法一开始就能定义软件产品最终的规程, 过程中需要研发、创意、尝试错误, 所以没有一种固定的流程可以保证方案成功。
它的框架如下图所示:主要包括三种角色和四个会议。三种角色指图中的Product Owner、Scrum Master、Team Member;四个会议包括周期计划会、每天例会、周期展示会、周期回顾会。Backlog:可以预知的所有任务, 包括功能性的和非功能性的所有任务。
Sprint:一次迭代开发的时间周期, 一般以2-4周为一个周期, 在这段时间内, 开发团队需要完成一个制定的backlog, 并且最终成果是一个增量的, 可以交付的产品。每个Sprint周期可能包含全部的开发阶段, 如需求分析、设计、编写代码、测试、整合以及产品部署。
Sprint Backlog:一个sprint周期内所需要完成的任务。
Product Owner:该角色负责产品的远景规划, 平衡各方面的利益, 确定不同的产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。
Scrum Master:负责监督整个Scrum进程, 修订计划的一个团队成员。负责指导开发团队进行Scrum开发与实践。它也是开发团队与产品拥有者之间交流的联络点。
Team Member:即项目成员, 包括业务员, 开发员, 测试员, 一般5-8个人为1个Team.
Sprint Planning Meeting:在启动每个sprint前召开。一般为一天时间 (8小时) 。该会议需要制定的任务是产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块, 确定好这个Product Backlog的任务优先级。另外, 该会议还需详细地讨论如何能够按照需求完成这些小功能模块, 制定的这些模块的工作量以小时计算。
Daily Scrum Meeting:开发团队成员召开, 一般为15分钟。每个开发成员需要向Scrum Master汇报三个项目:昨天完成了什么?是否遇到了障碍?今天要做什么?通过该会议, 团队成员可以相互了解项目进度。
Sprint Review Meeting:在每个Sprint结束后, 这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。
Sprint Retrospective Meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。
Scrum的开发过程包括以下几个点:1.将整个产品的backlog分解成Sprint Backlog, 这个Sprint Backlog是按目前的人力物力可以完成的。2.召开sprint planning meeting, 划分确定这个Sprint内需要完成的任务, 标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的, 并不是按人天计算。3.进入sprint开发周期, 在这个周期内, 每天需要召开Daily Scrum meeting。4.整个sprint周期结束, 召开Sprint review meeting, 将成果演示给Product Owner。5.团队成员最后召开Sprint retrospective meeting, 总结问题和经验。6.这样周而复始, 按照同样的步骤进行下一次Sprint。
对敏捷开发的思考:作为一种开发模式敏捷开发同样需要面对众多挑战。大项目的拆分意味着更多子项目的出现, 如何协调这些同步或异步推进的子项目, 合理的资源调配将变得更加复杂。人的重要性尤其重要。减少人员流动和项目变更对整个项目影响成为一大挑战。
软件质量度量模型探讨 篇2
关键词：质量度量；模型
中图分类号：TP311.52 文献标识码：A文章编号：1007-9599 (2011)05-0000-01
Software Quality Measurement Model
Fan Xuedong
(Xi'an Institute of Foreign Affairs,Xi’an710077,China)
Abstract:With the growth demand for software projects,software
development process and quality metrics research is very active.How grasp goos software measure model relationship between analysis and software process,it is extremely important.As software measure system model used in the software development process,software quality improvement and protection value of a positive reality.In this paper,do the quality control of measurement model.
Keywords:Quality measure;Mode
一、度量体系模型分析：
目前计算机行业普遍认为：软件工程度量的方式分直接度量和间接度量两种：1.直接度量：对过程的直接度量包括度量投入的成本、完成的工作量等等；对产品的直接度量包括产生的代码行数LOC、文档的页数、缺陷数/千代码行、软件执行速度等等。2.间接度量：软件的正确性、效率、可靠性、可维护性、可用性等难以直接度量。一般通过对其他项目直接度量的结果进行分析，获取对本项目的间接度量结果。
从另一个方面看，软件度量又可以分为面向规模的度量、面向功能的度量、面向个人的度量。面向规模的度量用以收集与直接度量有关的软件工程输出的信息和质量信息；面向功能的度量提供直接度量的尺度；面向个人的度量收集个人工作方式与效率方面的信息。可以根据面向规模的基本度量数据作一些简单的计算分析，进行面向规模的生产率、质量和单位成本的间接度量，例如：生产率=KLOC/人月；质量=错误数/KLOC；单位成本=成本数/KLOC。坚持度量并记录度量结果，积累组织的历史数据。利用这些历史数据，能够更科学地把握自己的工程能力，对工程项目作出更为精确的估算。使用KLOC作为关键度量准则已经有大量的案例，并且许多著名的度量模型也直接以KLOC作为输入；但是，这种方法不适应采用非过程化语言开发的实践，对于项目估算也存在不便，因为在项目开发初期，也没有现成的KLOC数据可用。随着面向对象方法的应用，也有人提出了以系统的对象数作为基本度量单位进行规模度量的方法。面向功能的度量是对软件和软件开发过程的一种间接度量方法。这种方法并不把注意力集中在生产结果(KLOC)上，而是以软件应当满足的“功能性”、“实用性”作为度量原始依据。
二、软件质量度量
软件质量特性可以定义为一种层次模型。ISO9000标准中，中国国家软件产品标准中都对软件的质量及其度量要素进行了规定和描述。软件产品质量度量贯穿于软件工程过程的始终。产品交付前的质量度量为评价设计、编码、测试工作提供了一个量化根据。这一阶段的质量度量包括程序复杂性度量、模块有效性度量等；软件交付后，在运行维护阶段进行的度量主要关注软件中残存的反映可靠性的差错数和系统可维护性方面。
度量软件质量的标准是用户对软件的需求，不符合需求的软件便不具备质量。标准的软件工程过程中，定义了一系列开发准则，用来指导软件人员用工程化方法开发软件，若不遵循这些准则，软件质量就得不到保证。质量定义中所提到的“需求”，既包括明确定义了的需求，也包括隐含的需求。因此，软件的可扩充性、可维护性就成了支持实现隐含需求的质量指标。度量软件产品的质量，除了严格度量最终产品的质量之外，还应包含对需求分析产品、设计产品、编码产品、测试产品等所有软件产品的全面度量。软件质量的定性、定量度量，可在开发过程中，结合各项技术产品的度量来进行。如对需求分析产品完备性，设计产品对需求项覆盖程度，编码产品对设计实现情况，测试用例对需求项的覆盖情况，模块聚合度、耦合度情况的度量，都可以作为间接的质量度量方法。在许多软件质量度量方法中，使用最广泛的是事后度量或验收度量，它包括对产品的正确性、可维护性、完整性和可用性的度量。(1)正确性：软件是否能正确地执行所要求的功能。可以用缺陷数/KLOC来度量；在产品交付后，根据标准的时间周期(一般为一年)，按照反馈的用户报告中的缺陷数进行度量。(2)可维护性：利用平均变更时间MTTC(Mean Time To Change)间接度量软件的可维护性。(3)完整性：这个属性反映软件系统抗拒针对它的安全攻击(事故或人为)的能力。完整性 = ∑(1－危险性×(1－安全性))。其中，危险性指一定时间内特定攻击发生的概率，安全性是排除特定类型攻击的概率。两者都可以从估算或历史数据中得出。(4)可用性：即“用户友好性”。可以从四个角度度量：学习应用软件所花费的代价；为达到有效使用软件所花费的时间；使用软件带来的生产率净增值；通过问卷调查得到的用户的主观评价。还要注意度量陷阱。卡尔•威格在其《软件度量的十大陷阱》一文中总结了软件度量应该避免的十大陷阱：1.缺乏管理承诺；2.度量得太多太早；3.度量得太少太晚；4.度量了错误的事项；5.度量定义不严密；6.度量用于评估个人；7.度量用于激励而非理解；8.仅仅收集但不使用数据；9.缺乏沟通和培训；10.曲解度量数据。
对软件生产率和软件质量的度量，管理者能够建立改进软件工程过程目标。从而对整个开发组织的工作产生直接的影响。从另一个角度来看，充分地了解工作能力的现状，就有可能确立正确的改进目标。所以，必须通过对能力、效率、质量的度量进行度量数据的收集、计算与分析，并且将历史度量数据、当前度量数据进行集成，建立工程过程的“度量基线”，利用基线来评估各类改进工作的效用，估算新项目的规模、工作量、预测成本、质量指标。度量基线由以往的软件开发项目收集到的度量数据构成。有人将其称之为“数字化的经验”。
三、结论
模型驱动的软件开发模式研究 篇3
1模型驱动架构的概念
模型驱动架构(MDA)是由对象管理组织(OMG)提出的一种新的软件体系结构开发的框架,并且模型驱动架构是一种基于UML、XML、CWM以及MOF等一系列的工业标准模型的软件开发架构,支持机器的可读和高度抽象的软件与模型的可视化设计、交换以及存储,且这些模型都是以标准化的方式进行存储,并独立于实现技术。模型驱动架构不仅把建模语言用作是一种设计语言,还用作是一种编程语言,并让模型在软件开发中扮演一种极其重要的角色,一切都是模型就是模型驱动架构的基本思想。然后通过架构性的分离来使软件的可重用性、可维护性、互操作性、可编制性以及轻便性实现,并将软件的开发效率提高。
2模型驱动的软件体系结构
在模型驱动架构中,模型成了软件开发的主干及核心, 不再只是一种辅助沟通的工具和描绘系统,而且从不同的视角可以用不同的模型对一个系统进行描述。因此,MDA中将这些模型分为了以下3个结构。
2.1 CIM(计算无关模型)
通常所讲的“业务模型”就是指计算机无关模型,这个层次的模型就只是对商务知识和过程进行详细的表述,在如何用软件来实现商务过程方面毫无涉及,所以,用于构造计算机无关模型的语言就需要将用来规定过程、过程间依赖、 相关部门以及参与者等方面的术语统统包含进去。
2.2 PIM(平台无关模型)
这一层次的模型将如何用软件来实现商务过程方面进行了详细的表述,并将一些与基础功能毫无关系的技术细节进行了去除,所以,用于构造平台无关模型的语言不仅要抽象性较高,与具体的细节能够互相脱离,必须还要能对系统的动态行为与静态结构进行精准的建模;
2.3 PSM(平台相关模型)
这一层次的模型是与代码一级最贴近的,能够将特定技术对软件系统功能具体的实现进行详细的描述,所以,用于构造平台相关模型的语言不仅必须要有一定的扩展性,还必须要具备足够的精确性,这样才能使与各种实现技术紧密挂钩的要求得到有效的满足。
通过模型映射机制对模型之间进行相互的映射,因而使模型的可追溯性得到了有效的保证。
3模型驱动的软件开发步骤分析
1. 将应用程序中的业务需求进行确定;
2. 利用模型驱动软件开发的专用建模工具将业务模型的UML图形,即PIM画出来,并注意不管使用的目标平台是什么, 画出来的UML模型都是相同的,因为这个UML模型是核心的业务组件和服务的代表,与任何具体实现它的开发技术都毫无关系。
3. 将应用程序的UML图形,即PSM画出来,并注意在这个UML模型图中,不仅指定与某种技术相关,而且还有某些特定技术的元素包含在内。所以,在进行绘制时,可以选择手工建模,也可以通过MDA建模工具将它的大部分生成后, 再将需要进行特制的地方来手工调试;
4. 最后利用模型驱动的软件开发工具进行应用程序代码的生成工作,并对UML无法进行建模的细节开展填补工作。
4模型驱动的软件开发模式研究
4.1模型驱动的软件开发生命周期
虽然从整体上看,模型驱动的软件开发生命周期较传统软件开发生命周期相比,并无较大的差别,但是软件系统的建模行为驱动了模型驱动的软件开发的生命周期,在这整个的开发过程中都在围绕着模型的创建及变换而开展,所以两者之间最大的差别就是,在完整实现模型驱动架构之后,软件开发生命周期的焦点从“代码”逐渐向“模型”进行转移, 并且逐渐的会将转移的层次向更高层次进行提升。
4.2模型驱动的软件开发工具的更新
相较于传统的软件开发过程来说,在模型驱动下的软件开发过程中也会对软件的开发工具产生一定的影响,因此, 在模型驱动的软件开发过程中主要有PIM分析员、变换定义开发者以及PSM创建者三组人,使用的工具是新的或者是更好的。
早在传统软件开发模式中就已经有了PIM分析员这组人, 而且为他们提供服务的建模工具已经有很多了。现在的大多数的建模工具在读写UML模型时,都能通过标准交换格式来进行读写,但是对于PIM分析员来说,还必须要支持各种UML图表之间信息流、模型各个部分的整合以及模型的检查的工具组,但更好的建模语言还是PIM分析员最需要的。
变换定义开发者在创建、编辑以及测试变换定义的时候, 需要一种新型的IDE。因为复用变换定义是模型驱动的软件开发的最终目标,而且主要是通过国际组织统一管理相关规范,因此,既不会有太多人会参与到变换定义开发中,也不会有太多的选择工具出现在变换定义开发中。
PSM创建者在进行软件开发时主要使用的是变换工具, 而且相应的,这些变换工具一些功能是必须要具备的。
1)在一个平台上能够让应用程序架构、不同实现策略以及编码模式进行灵活的转换;
2)在不同实现平台间能够进行选择;
3)能够对标准的领域特定蓝图或者是模型提供支持;
4)插入多种变换定义和建模语言的开发性功能能够有效具备;
5)能够与维护工具,如性能调整工具、代码维护、需求管理、测试工具、工作流自动化等,以及其他软件开发自动集成。而且,PSM创建者为了软件系统生成的高效性,对正在使用的变换定义必须要将少部分进行调整。
4.3模型驱动的软件开发活动与参与者发生的变更
模型驱动的软件开发模式较传统软件开发模式相比来说, 模型驱动的软件开发过程中,仍然要先将需求找出来,并对其进行表示,还需要对系统进行测试和部署,所以说,开发过程中还是有很多的地方并未改变。但是改变较大的就是软件分析、软件设计以及软件编码这3个阶段的活动,以及3类参与到模型驱动的软件开发过程中参与者的角色。
1)在软件分析阶段;首先需要由一组PIM分析领域的专业人员组成的PIM分析员将一个PIM开发出来,并且问题域的需要实现的功能、业务范围以及由业务需要和业务模型来进行驱动是PIM分析员主要关注的。同时,为了保证该模型的精确性和完整性,在完成本阶段之后,应该将PIM进行充分的验证。
2)在软件设计阶段;PSM创建者需要将PIM变换为一个或者是多个PSM。所以,PSM需要非常的了解在不同的系统架构、不同的平台所使用的变换工具的变换定义;对开发的目标平台和系统架构进行确定;对确保实现服务质量的责任进行承担;对变换定义和PIM的改变做出相应的反应也是PSM创建者的重要任务。
3)在PSM开发的整个过程中,最重要的参与者就是变换定义开发者,因为整个过程中,变换定义都会被PSM创建者使用。而且,变换定义开发者在传统的软件开发模式中是不存在的。
5结语
软件开发模型 篇4
引言
在中国软件行业发展的近30年中，集成能力成熟度模型CMMI(Capability Maturity Model Integration)已经在国内的软件企业广泛实施并探索出有效的实施方法，越来越多软件企业通过实施CMMI来规范企业管理体系，提升软件产品质量。
随着中国汽车电子的飞速发展，汽车与软件的联系越来越紧密，已成为汽车创新发展不可缺少的因素之一。为了在有限资源范围内最大限度地提高主机厂自主开发的软件质量，必须引入CMMI管理体系指导软件开发。
1.CMMI概述及应用现状
CMMI起源于美国政府和军工软件企业的一些成功经验及实践。2002年1月，由美国、卡内基-梅隆大学与美国国防工业协会共同开发研制并发布的CMMI 1.1版本，标志着CMMI模型的正式启用。其研究目的主要是提高软件行业开发能力，帮助企业建立适合企业自身发展的软件开发质量保证体系，从而保证软件产品能及时、高效地输出到客户。另外，通过不断积累和发展使软件开发向着流水线方向发展、帮助企业节省开发成本也是CMMI的重要目的。CMMI按企业软件的成熟度共分为5级22个过程域，分别为初始级、可重复级、已定义级、量化管理级、优化管理级。
自1999年起，中国软件企业开始接受并逐步推广CMMI体系，通过学习和不断探索，已经在软件开发标准化方面取得了一定进展。据SEI统计，通过评估的软件公司对项目的估计与控制能力提升了40%～50%，生产率提高了10%～20%，软件产品出错率下降超过1/3[1]。截至2011年底，包括IBM中国、宝信软件、东软集团等在内的28家企业通过了CMMI5级认证。如今，已有越来越多软件企业通过了CMMI认证，主要涉及计算机、手机软件等相关行业。随着汽车电子的快速发展，其规模和复杂度也日益提高，汽车嵌入式软件与其它行业软件相比有着更高的质量要求，其对响应速度及安全性的要求更高。
2.CMMI软件开发模型
CMMI开发模型(CMMI For Development)是在产品与服务开发活动中处理问题的最佳实验[2]，此模型涵盖了工程学科共有的开发与维护活动，涉及产品开发的过程均可利用此模型来进行过程改进，包括银行、计算机软硬件、航空航天、国防等在内的各个领域。CMMI开发模型包含16个核心过程域及5个开发活动特有的过程域，这5个关于开发活动特有的实践包括：需求开发、技术解决方案、产品集成、验证和确认。
CMMI指出，CMMI的本质是软件管理工程的一部分[3]。就目前CMMI发展总体情况而言，SPI(Software Process Improvement)是软件管理工程的核心问题。对软件过程进行改进，可高效、高质量和低成本地开发软件，能够通过过程监控管理达到提高开发质量、减少产品缺陷、减少退货、提高用户满意度等目的，对于提高软件产品质量与生产率、缩短上市时间也能够起到重要的指导作用。
3.CMMI软件过程改进实施
汽车软件因其特殊的应用领域，不同于一般软件产品，其对产品的安全性和可靠性有着严格要求。因此汽车软件不仅需要一般的软件工程方法、软件质量管理手段来提高软件可靠性，为了满足针对性，首先要结合自身特点，如组织结构、工作范围、公司状况来明确当前需要改进的地方。选择合适的方法，从人力、物力上保证，对CMMI模型进行合理裁剪，避免周期过长、程度不够深入以及无法实施等问题。
3.1支撑V模型开发的完善工具链
通常的产品开发模式是，开发工作从客户的需求定义开始，经过系统设计、软硬件架构设计到单元开发完成为止，将工程参数层层分解，需求逐步细化，最终形成软件代码。在该过程中首要的因素是各级理解必须正确，然后是追溯开发过程没有产生遗漏。当前业内流行的开发方式是V模型，不但满足了一般的开发需求，还将测试和验证过程加入开发迭代。
V模型的价值在于其非常明确地描述了测试阶段与开发过程期间的对应关系，工程开发人员往往期望有一款工具既能够支持V模型的工程开发需求，也能够实现测试和验证自动化。然而在业界，这样的工具往往属于大型企业的秘密，不会出售，一般软件也往往只解决流程问题，而无法解决技术整合问题。因此，泛亚汽车技术中心摸索开发了一系列自主工具，既能在流程上符合V模型开发方式，又能整合各层次的技术资源和分类工具，彻底实现了一个完整的工具开发链路，具有很高的产业价值。
3.2基于AUTOSAR架构的分工和交付物管理协作模式
随着团队的扩大以及更细的人员分工，制定一套标准的开发流程能够显著降低开发成本，缩短开发周期。从制定各个里程碑开发节点出发，到软件需求理解、软件架构设计、软件编码及建模，再到软件集成测试，每个开发活动都有明确的输入需求、交付物以及对应人员。创建符合CMMI的软件开发流程关键，还在于在项目开发大节点有相应的质量阀评审，若评审不通过，则需要对交付物采取补救措施。
AUTOSAR(Automotive Open System Architecture，汽车开放系统架构)由全球汽车制造商、部件供应商及其它电子、半导体和软件系统公司联合建立，是目前汽车厂商统一、开放的软件架构，但国内应用此架构开发的汽车厂商还不多，都还处于初级阶段。企业应基于AUTOSAR架构原理，根据专业工作细化结果，结合团队自身特点，制定相应措施以达到提高开发效率、缩短开发周期的效果;另一方面，还应强化软件架构设计及软件集成的执行，从软件架构流程确保整个项目开发的统一设计，再逐步细化到各个子模块的实现中，同时确保所有交付物都通过专家评审，力保在软件设计之初就发现问题，从而有效降低开发成本;此外，通过软件持续集成、统一发布，控制开发节奏，驱动开发进展，逐步完善软件成熟度。图1为基于AUTOSAR软件架构的软件开发流程。
3.3软件质量目标定义
软件开发的质量管理主要细分为质量保证及质量控制两类活动。其中，质量保证是针对开发过程开展的活动，质量目标包括评审度量指标、评审投入比例、过程失控度目标等。质量控制主要是针对测试及验证活动，定义的主要度量指标包括项目测试收束目标、测试逃逸率以及逃逸的千行代码缺陷率。最常用的3个质量目标定义如表1所示。
3.4软件度量制度建立
项目的健康化发展离不开对缺陷数据的统计，通过统计可知道项目的薄弱点，也能对项目进行横向比对。Mantis系统是软件行业最常使用的bug跟踪系统，在原有的统计功能上可通过定制化统计功能将上述3个指标(未修复不符合项平均Open时间、未解决不符合项数及过程失控度)通过二次开发纳入Mantis统计中，从而能够实时监控软件bug的状态;另外，通过Mantis系统能够对问题的各个纬度进行统计，包括问题的状态、项目、严重性、报告阶段、处理员等，通过这些数据能够清晰了解项目目前的缺陷状态，若出现超标和即将超标的情况，QA(Quality Assurance)人员将及时对项目报警，分析原因并采取相应措施，使项目处于一个健康状态。图2为应用Mantis软件对bug进行处理的流程。
4.结语
浅谈软件生命周期模型及其选择 篇5
关键词 软件生命周期 瀑布型 快速原型
中图分类号：TP31 文献标识码：A
1瀑布模型
虽然瀑布模型仍然存在很多的问题有待解决，但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照：需求->分析->设计->编码->测试的阶段进行，每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以组织相关的评瀑布模型的优点仍然是可以保证整个软件产品较高的质量，保证缺陷能够提前的被发现和解决。采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性.但对于前期需求不明确，而又很难短时间明确清楚的项目则很难很好的利用瀑布模型。另外对于中小型的项目，需求设计和开发人员往往在项目开始后就会全部投入到项目中，而不是分阶段投入，因此采用瀑布模型会导致项目人力资源过多的闲置的情况，这也是必须要考虑的问题。审核验证，只有在评审通过后才能够进入到下一个阶段。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。
（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
2螺旋模型
首先螺旋模型是遵从瀑布模型的，即需求->架构->设计->开发->测试的路线。螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的，通过将瀑布模型的多个阶段转化到多个迭代过程中，以减少项目的风险。
螺旋模型的每一次迭代都包含了以下六个步骤：
（1）决定目标
（2）替代方案和约束识别和解决
（3）项目的风险评估技术方案和替代解决方案开发
（4）本次迭代的交付物和验证迭代产出的正确性
（5）计划下一次迭代
（6）提交下一次迭代的步骤和方案
螺旋模型是隨着项目成本投入不断增加，风险逐渐减小的，以帮助我们加强项目的管理和跟踪，在每次迭代结束后都需要对产出物进行评估和验证，当发现无法继续进行下去时可以及早的终止项目。
螺旋模型复杂的地方在于尽责，专心和知识渊博的管理。因为对于每一次迭代都要制定出清晰的目标，分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情。
3增量迭代模型
迭代式模型是RUP（RationalUnifiedProcess，统一软件开发过程，统一软件过程）推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
迭代和瀑布的最大的差别就在于风险的暴露时间上。“任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。”由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。
4快速原型（RapidPrototype）模型
快速原型模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。
上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。现总结如下：
（1）在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型。
（2）在用户无信息系统使用经验，需求分析人员技能不足情况下一定要借助原型。
（3）在不确定性因素很多，很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型。
（4）在需求不稳定情况下尽量采用增量迭代模型。
（5）在资金和成本无法一次到位情况下可以采用增量模型，软件产品分多个版本进行发布。
（6）对于完全多个独立功能开发可以在需求阶段就分功能并行，但每个功能内都应该遵循瀑布模型。
（7）对于全新系统的开发必须在总体设计完成后再开始增量或并行。
（8）对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型。
（9）增量，迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口准则。
参考文献
[1] （美）MichaelHoward&（美）SteveLipner.软件安全开发生命周期（中译本扫描版）.电子工业出版社，2008.01.
[2] 张向宏.软件生命周期质量保证与测试.电子工业出版社，中国软件评测中心组编，2009.05.01.
软件开发模型 篇6
图形平台作为EMS/DTS/DMS等多种电力自动化系统的核心技术必须满足电力系统软件一体化[1,2,3]、智能化[4]和标准化[5,6,7,8,9]的发展方向。为此,笔者以通用图模库一体化模型为核心,以分层设计为手段,对图形平台进行重构,提出并设计了统一架构的通用电力软件图形软件开发平台——Sophic图形软件开发平台,并以此为基础,完成监控、调度、稳控、配网等多种电力产品图形平台的快速构建和功能开发。
1 图形软件开发平台的整体架构
1.1 概述
电力应用软件产品类型众多,每个系统均有各自的图形界面。在整个电力系统自动化软件的设计体系中,图形平台始终处于一个比较特殊的位置。一方面图形界面作为表示层,与最终用户打交道,各应用产品的图形平台可以根据实际用途设计特定的表现形式,并可以设计成不同的风格和功能。另一方面,各应用产品的图形平台也具有许多共性,功能需求时有交叉,需要充分考虑重用的必要性,避免某种单一设计所导致的重复开发[10]。
为满足这些看似矛盾的需求,目前还没有哪个厂家能提供统一的解决方案。南瑞继保在总结各系统的不同特点和图形共性需求的基础上,提出了大平台的概念,就是提供针对电力应用系统的通用图形支持包,并允许各电力应用系统根据各自的特点在图形支持包上构建具有各自特点的不同的图形应用和交互界面[11]。对于监控、调度、电量计费系统等规模或模型差异度比较大的系统,完全基于这个通用的图形支持包来开发,既缩短系统的开发周期,提高系统的稳定性,又方便系统交换信息,实现信息共享。
基于上述思路分析,监控、调度等系统的需求相似度很高,面向的是一个电力系统的不同局部或不同侧面。因此,改变常规的电力系统软件开发模式,将各种图形平台的底层共性部分抽象为统一的开发框架和开发资源,建立同构的电力图形软件开发平台,如图1所示。
与常规一体化系统相比,该开发方式所获得的最大好处在于,既可以获得公共平台的共性支持,又可以根据各自特点独立创建窗体框架,开发特殊功能。
1.2 多层体系
为获得最大程度的扩展性,将整个图形平台划分为3个层次,如图2所示。
a.基础层:适用于所有图形类产品开发需求,以连接为例,笔者认为连接特性是属于基础层的通用定义,并设计了连接点、连接线以及连接形等基础图形元素。
b.领域层:适用于所有电力图形类产品的开发需求,仍以连接为例,本层提供了电网中连接线路的设计,连接线路就是以连接线的物理属性和电力设备的电力属性合并在一起的图模库一体化的对象。
c.应用层:提供对应某种特定需求的电力图形产品,例如调度图形工具、潮流图形分析工具等。根据领域层提供的连接线路的特性和功能,在应用层实现了根据数据库中的网络模型,半自动生成潮流图的工作界面和工作流程。
从上述层次看,基础层和领域层构成图形软件开发平台,用于图形工具自身的开发;而应用层提供的是应用图形平台,用于应用界面的开发和工程界面的实现,也就是各种图形编辑器、图形浏览器、曲线工具等各种界面工具。
1.3 模块关系
Sophic图形软件开发平台,就其产物而言,就是一系列通过类库扩展和组件封装,提供具有特定产品特性的标准C++框架。其主要模块如图3所示。
2 通用图模库一体化的设备模型
图模库一体化[12,13,14]使维护人员利用直观的主接线图来生成模型,在当前的电力图形系统中广泛使用,成为图形系统的一项基础功能。
在上文中,明确定位Sophic图形软件开发平台是用于开发各种电力系统应用软件的图形平台的开发平台。为此,提出通用图模库一体化模型的设计,充分利用Sophic电力支撑平台体系的支持,在提取模型最大程度共性的同时,满足各系统中模型的差异性,使图形软件开发平台真正适用于不同应用系统中。
2.1 Sophic电力应用支撑平台体系
Sophic图形软件开发平台是Sophic电力应用支撑平台体系的一个重要组成部分。Sophic平台包括图形平台、数据平台、网络平台等各种底层支持,见图4。这些松散的平台可支持在各种环境下独立使用,但是在构建大型分布式电力应用系统的时候,这些平台支持通过内部关联设计形成一个整体性的平台,充分满足实时性和扩展性的需求。
2.2 Sophic数据库平台中的对象描述
Sophic数据库平台是完全面向对象的实时数据库平台,支持类之间的继承、聚合关系,能够构造复杂的结构模型,可直接定义和存储IEC61970中的公共信息模型(CIM)的类及其关系[15,16]。在这个面向对象的数据模型中,每个对象都存在一个对象标识和对象描述。以开关设备为例,在Sophic数据库中,这个设备的对象描述为
进一步用标识变量进行泛化处理,这个设备的模型描述可用下面方式表述:
2.3 通用图模库一体化的设备模型
设备图元是图模库一体化的基础单元,设备图元定义包括了图元的形态定义和模型定义,图形软件开发平台中的模型定义并不设定任何具体的模型如IEC61970 CIM模型,或者是IEC61850一次设备模型,而是通过可配置项形式的模型模板来进行设置。
对于图形软件开发平台中的设备而言,设备的模型是一个变量。到了产品开发层,以调度为例,一次设备模型以CIM标准在数据库中建模,这个变量通过配置定义工具用上文中的模型描述来定义,因此在调度画面工具中,图元对应的就是CIM的模型定义。
以开关为例,其定义包括2个方面内容,一个是图元形态,记录了在图元工具中所绘制的多种形态、端点等信息,另一方面是图元应用,记录图元在各种应用系统中的模型对应关系,这种对应关系,例如,在SCADA模型中,其对应描述为
在PAS模型中,其对应描述为
根据各应用模型数据库路径定义,将厂站、电压等级等实际参数带入变量,可明确定位该设备。这种不同应用的设备模型差异性处理方式也可以应用于不同系统的模型差异中。
通用图模库一体化设备模型的设计使设备拓扑、模型创建成为通用功能,也是电力图形软件开发平台的领域层在基础层上的重要扩展。
2.4 图模库一体化的开发体系
在Sophic图形软件开发平台的开发体系中,不同的开发层次,图形模型和模型层次也存在对应关系,如图5所示。
2.4.1 图形软件开发平台
整个图形软件开发平台构建于跨平台的QT类库基础之上,基础图形层和电力图形层均属于平台的内容。
a.基础图形层对应图2中的通用图形支持包,在这个层次内,定义了通用的图形对象和数据集,图形对象可与任意数据源相关联,例如实时数据库、历史数据库或数据文件等。
b.电力图形层对应图2中电力系统支持包,在这个层次内,集成Sophic实时库的支持,定义了在通用的设备模型定义方式,可关联不同应用模型的数据库对象。通过这种方式,构建出图模库一体化的设备图形对象。
2.4.2 电力应用图形产品
应用图形产品基于图形软件开发平台开发,利用图形软件开发平台的通用框架以及图模库一体化设计的设备对象,通过编程和配置的方式,能很快构建出一个基本的图形运行和编辑工具。例如,调度图形编辑工具和运行工具,也被称作调度图形平台。在这个工具中,图形平台面对的不再是通用型的设备数据对象描述,而是具体的应用数据模型,可以进行自动化的集成度高的操作开发,或者开发具有产品特色的功能。例如,设备查询界面、遥控操作过程等。同时界面本身也可以根据实际使用场景定制成各种式样。AGC、SCADA、PAS、DTS等各种应用可以在调度图形平台的基础上进行应用界面功能开发。
2.4.3 工程实施
以调度图形平台为例,同一个调度图形平台应用到不同工程现场,需要通过配置和工程化的工作,使其成为定制化的系统,才能满足实际用户需求。这时对应的数据库对象的模型信息也是用户电网的实际模型。
3层架构的开发层次构成了Sophic图形平台的整个开发体系,这个逐层构建图模库一体化的体系可覆盖电力系统自动化领域内的所有图形需求。尤其是图形软件开发平台的设计,统一了领域内各种图形工具的基础,并为领域内新的监控分析工具提供图形界面的快速构建和开发手段。
3 图形软件开发平台的主要特点
3.1 快速构建上层应用图形平台
Sophic图形软件开发平台提供了一系列窗口框架、窗体、控件部件以及各种支持类和函数,应用图形平台的开发者可通过编程方式很快搭建具有基本交互功能的电力图形界面工具。并可在此基础上进行上层功能开发。
电力图形界面工具本身可以是一个已经完善的图形交互系统,也可能是支持多应用扩展开发的一体化应用图形平台。
3.2 可持续发展的底层平台
Sophic图形平台通过分层设计,获得强大的扩展性支持。跟随电力自动化应用软件系统一体化、智能化、标准化的趋势,Sophic图形软件开发平台中可不断加入可视化、脚本、标准等各种支持,这个扩展可自然被应用图形平台所继承。应用图形平台可以此为基础,近一步完善或开发上层功能,实现对需求的快速响应。
3.3 私有特性和公共功能的统一
在这个图形软件开发平台基础上,各种应用系统图形平台可以构建为一体化的图形系统,也可以根据各自特点分别构建。这些图形平台在获得更多定制的自由的同时,也获得通用功能的支持,例如国际化[17]。在Sophic图形软件开发平台开发的图形产品可实现从界面到画面内容的多语言的在线切换。
3.4 可视化及强大的决策扩展机制
图形软件开发平台的一个核心关系是决策。决策约定了图元的某种要素根据相关数据条件变化进行显示变化的规则,是联系数据和图形的重要纽带。一个图元可支持多种决策,如颜色决策、符号决策、线型决策等。在线运行状态下,根据数据变化和决策约定,图元显示也呈现出不同内容和效果。Sophic图形软件开发平台提供开放性的扩展机制,使更多图形要素纳入决策影响范围,满足智能电网对于高级决策的需求。同样,Sophic图形软件开发平台提供了可视化功能的基础支持。
3.5 丰富的SVG支持
Web支持是Sophic图形软件开发平台的基础支持,SVG(Scable Vector Graphic)文件是W3C制定的基于XML的可缩放矢量语言描述规范,图形平台从底层即实现了与画面显示相配合的SVG的支持[18,19]。
a.支持画面互动操作支持:SVG文件中的图元对象化使每个图元均可支持操作。对于复杂的具有在线互动要求的组件(如层次表、Tab页等),SVG提供了内嵌式组件操作支持,可支持滚动条、对象树等的操作,使Web上的SVG互动表现与C/S方式一致。
b.支持各种复杂的画面效果:满足各种画面渲染效果的需求,达到SVG画面质量无损失,使Web上的SVG显示效果与C/S方式一致。
4 图形软件开发平台应用实例
笔者基于Sophic图形软件开发平台开发了PCS9000电力调度集成系统、PCS9002配电自动化系统和PCS9700变电站监控系统的图形界面工具,并完成了相应应用的交互界面的开发。例如,调度中的AGC、SCADA、PAS、DTS等,配网中的DA、GIS等,实现了完整的自动化系统。
3种自动化系统各自强调了各自应用场景和复杂程度的差异性,系统中的图形编辑工具、图形运行工具等各种图形工具的工作界面、工作流程等各方面具有各自特点,并在应用中获得好评。
5 结语
基于风险管理的软件开发过程模型 篇7
风险这个词有着非常悠久的历史,几乎是与人类文字同时出现。现在,风险的概念也日趋广泛,很多学科中都有这个概念。当然,不同种类的学科的研究目的不同,故对于风险的定义也是不同的。本文主要讨论软件开发过程中的风险。
风险,有着不确定的特性,但是并非所有不确定的事物都是风险。而软件开发过程中的风险,指的是在软件开发过程中,或者在软件项目的管理活动中,项目管理人员不希望发生的、消极的结果发生的可能性。
软件开发过程中的风险是软件项目预期结果的一种概率事件,这个可能性是以概率或者概率区间来表示的,而结果可以用一些确定的值或者值区间来表示。预期结果与软件开发的环境、所掌握的知识、开发状态等方面有关。既然风险是一种概率事件,则可以有多种表述方式,可以是区间概率、点概率,甚至可以是按特性描述的概率大小。预期结果可能会有一些负面的效果,结果的相对大小与多方面因素有关,例如项目决策者的主观认定、利害人、决策人等。
在软件开发项目管理中,风险可以用实体的概念来描述,那么实体之间的联系和实体的属性可以用来描述风险的相关性质。风险实体可以表述为一个三元组
风险管理是贯穿于软件项目开发生命周期的全过程的,它的目的是为了保障软件开发项目按照计划进行。它对软件开发的策略、工具、技术和方法进行整合,对风险评估、计划、排序和监督活动进行控制,是项目管理非常重要的组成部分。
风险管理是系统全面的、明确的,而且与常规的软件项目管理是相容的。风险管理可以根据开发类型、项目种类与客户类型灵活选择,这样就满足了系统全面性的要求。而与常规管理的相容性使得风险管理与常规项目管理避免出现矛盾,可以充分利用项目开发资源,是动态进行风险管理的必要条件。
2. 软件开发过程中的风险管理
在软件开发过程中,风险管理起着非常重要的作用,故进行风险管理时需要遵循特定的步骤。首先对风险进行定义,或者说是风险识别。然后,进行风险评估。风险评估需要考虑风险的破坏能力、风险对整个项目的影响还有风险发生可能性。对风险进行正确的评估后,就要考虑对策面对风险。制定风险对策时,要综合风险的多方面,最好可以确定不同风险的优先程度,针对不同的优先级别来考虑降低风险发生的概率,最后再考虑风险发生时的应对措施。确定风险对策后,就是风险跟踪阶段,这个阶段贯穿于开发的各个任务中,进行风险更新和风险跟踪。每个任务结束后,还要对风险进行总结。软件项目的风险管理具体流程如下图所示。经过上述流程,就可以对项目进行有效的风险管理,尽最大可能性使得项目失败的概率降到最低。
首先,对风险进行识别。这个阶段产生的是一个所有可能风险的列表,要求清晰、无二义性,同时要求写出风险说明。这就需要项目组的所有成员共同讨论,尽可能多的找出可能存在的风险,以及与风险相关的属性,例如风险所关联的领域、风险发生的条件,还有风险发生以后可能会带来的损失。
风险识别的意义在于,系统化的明确可能对项目计划造成威胁的因素。通过风险识别,可以找到已知的或者可预测的风险,项目管理者经过一些活动可以控制这些风险,甚至避免这些风险。一般的风险可以分为两类,特定性风险和一般性风险。特定性风险的识别比较困难,只有那些对项目环境、技术、人员非常熟悉的人才能意识到。为了识别出特定性风险,一般会对整个软件范围和项目计划做出说明解释,这样就可以直观的了解到项目的哪些特点可能会遭到风险威胁。而一般性风险,是指普遍存在的,对于任何软件开发项目而言,都是一个潜在的威胁。
对整个软件项目计划和软件范围了解后,就可以根据项目的特点对可能存在的风险进行识别,然后进行分类。一般风险分为四类,需求风险,管理风险,质量风险和技术风险。对于任何一大类的风险,可以继续进行细化。举例来说,需求风险就可能包括新业务的出现对于整个系统性能影响等等;管理风险可以包括很多不确定因素,使得开发计划难以掌控等;技术风险则可以包括新技术的出现,使得项目中采用的技术很快落伍淘汰或者对项目难度估计偏差引发技术资源不足等。
第二步,就是对识别出的风险进行排序,排序的依据是风险的优先级。风险的优先级是按照风险对项目的影响程度和风险发生的概率来确定的,风险的值越大,则风险的优先级越高。一种风险优先级的确定方法就是先根据风险对项目的影响程度和风险发生概率来确定两个值,然后优先级就是两个值的乘积。
第三步,根据第二步确定的所有风险的优先级别,选择值较大的前几个作为主要应对风险,然后针对这些主要应对风险确定风险处理计划。在确定风险处理计划的时候,要考虑到如下几个方面:风险研究,确定是否取得了与该风险有关的最大信息量;风险接受,当风险确实发生时,能否接受它所带来的后果;风险躲避,能否通过特定方法躲避风险,例如修改项目的范围;风险转移,可否利用一些措施,将风险转移到其他的团队、其他项目或者其他组织个人;减轻风险,是否存在一些方法措施,使得风险产生的影响范围减少或者风险发生的概率降低;确定风险应急方案,在确定了风险应急方案以后,能否将风险发生后产生的影响降到最低。
在将上述问题考虑清晰后,便可以指定风险应急方案或者风险减低方案,同时,设置风险应急方案的激活或者触发条件,并分配指定的负责人来进行处理。
风险分析活动的目的都是相同的,就是为项目风险处理策略的建立进行辅助。软件开发对于风险有两类方法,主动或者被动。若采取主动的方法,则避免风险是最好的策略。这样就可以利用建立风险缓解计划来达到避免风险的目的,也就是指定风险对策。
不同的风险项目有着不同的特点,故就需要建立不同的风险监控策略来应对。例如,针对技术风险,可以采用如下策略,分析关键技术,避免在软件开发周期中技术很快落后;在整个项目开发过程中,要一直不停对风险因素的相关信息进行收集,这样就可以减少过度依赖合作公司,特别的对于延续性比较强的软件项目来说,将合作公司的技术进行吸收学习使其转变为自己的技术,这样就可以避免因为与合作公司的合同终止而带来的风险和对项目的影响,还可以降低项目投入成本。应对开发人员离职风险,要在项目开始时,就做好这方面的准备,进行后备力量的储备,一旦有开发人员离开时,项目能继续进行,而且进度不会被打乱;建立一种机制,并制定一些文档标准,保证开发文档的及时产生;对于关键的技术性岗位,要有后备人员储备,保证项目的顺利进行。
第四步,在主要风险的处理计划确定以后,为了确保风险处理计划的准确地执行,项目组成员应该对风险影响和条件的变化以后应急措施的触发事件进行定期监控。一方面来讲,当风险应急计划被触发时,项目组应该立即采取应急方案,这样可以避免造成更大的损失。而从另一方面讲,当风险状态的变更时,风险责任人应及时进行交流,报告风险减轻计划的执行情况。
第五步,控制风险。当应急计划触发条件发生时,风险应急方案得到执行。在一段时间以后,要对风险的状态进行总结归档,这样可以为下一次风险分析提供依据。
在这个软件开发过程模型中,项目组的成员可以通过上述流程,风险描述、风险分析和风险跟踪,从而达到风险控制的目的。从风险管理的整个流程图上可以看到,这种风险管理模型的首要位置是预防风险发生,其次是风险发生时执行的风险处理方案。这样,就可以通过预防措施预防可以预见的风险,而实施过程中遇到的风险,可以由预先制定的方案进行控制和管理。
在实际应用过程中,这个软件开发模型中各个阶段的任务分配可以根据软件项目的具体情况进行适当的调整,但是,风险管理方面的工作确是必不可少的。提高软件项目的成功率、降低软件项目的开发风险是这个模型提出的目的。在大型的软件开发过程或者项目中,采用这个模型来进行风险管理是可行的。随着软件开发过程的向前推进,软件可以得到用户和开发者更好的理解,用户会提出更明确的需求,从而避免了一定的风险。但是,对于小型项目的软件开发,这个开发过程模型反而会增加一些成本,甚至会浪费一些不必要的时间。所以,针对不同项目的特点,可以对本模型进行修改简化。
3. 总结
在软件项目的开发过程中,风险管理作用非常大,它不仅是处理危机的最有效的方法,而且还可以减少甚至是防止项目中潜在的问题和影响。在一个软件开发项目周期中,团队的项目管理人员应该在风险预防和风险反应间达到一种和谐。当风险出现的时候,风险管理可以让你做出最快速的反应,并提供一种成熟稳重的解决方案,从而将风险对这个项目造成的影响降到最低。相反,当风险没有出现的时候,风险管理的作用是,让你通过科学的分析方法,将风险发生的概率降到最低,后者将风险转移,从而减少风险可能造成的损失。
总而言之,在软件项目的开发过程中,为了保证软件的高质量高可靠性,一般都会对项目进行风险管理,包含风险分析、预测、评估和监控等方面。通过这一系列操作进行的风险管理,可以使得项目进行的更加稳定平和,增加了项目组各个成员对项目顺利成功、如期完成的信心,还可以获得对项目的跟踪和控制的能力。由此可以看出,风险管理在项目管理中有着非常重要的地位,对软件项目进行有效的风险管理是整个软件项目开发过程顺利完成非常重要的保证。
参考文献
[1]梅宏.软件工程.实践者的研究方法(第5版).机械工业出版社,2002.
[2]陶华亭.软件工程.高等教育出版社,2004.1.
[3]何芳,张李义.信息系统开发过程的风险评价.武汉:武汉水利电力大学学报,1999,32(5):110-112.
[4]郑人杰,殷人昆,陶永雷.实用软件工程(第2版).清华大学出版社,2001.
[5]Ronald P.Higuera,Yacov Y.Haimes.Software RiskManagement.CMU/SEI-96-TR-012 ESC-TR-96-012.
[6]Hall E.M.,王海鹏等译.风险管理——软件系统开发方法.北京:清华大学出版社,2002.
[7]张李义.信息系统开发的动态风险模糊估测方法.北京:系统工程理论与实践,2001,(10):88-92.
基于软件复用的开发模型的研究 篇8
关键词：软件复用,构件,开发模型,江苏校园招聘网
1 引言
软件复用(Software reuse,又称软件重用或软件再用)是在开发一种新的应用系统时,重复使用以前开发活动中曾经积累或使用过的软件资源,利用现有的软件成分来构造新的软件系统的过程。利用软件复用技术,可以提高软件开发的效率和质量。可以被复用的软件成分称作可复用构件。软件复用能够提高软件生产率,减少开发和系统维护的代价,提高系统间的互操作性。
软件复用可分为黑盒(Black-Box)复用和白盒(White-Box)复用。黑盒复用指直接使用已有构件,不需要对构件做任何修改;白盒复用指根据用户需求先对已有构件进行适应性修改,然后再使用。实践中,白盒复用更常出现,因为组成新软件的模块在功能上或多或少与已有构件有一些区别。
本文中的实例———江苏校园招聘网二期各地市分站的建设就是以一期主站的部分为构件的白盒复用过程。
2 构件与复用
软件复用是通过软件构件来实现的,软件构件技术(Software Component Technology)是支持软件复用的核心技术,它的出现很大程度上促进了软件复用技术的发展。
构件(Component,又称组件)是指应用系统中可以被明确标识的软件制品,它可以是需求分析和设计阶段的产品、代码、测试案例、文档或者软件开发过程中的其它产品。可复用构件(Reusable Component)是指具有相对独立的功能和复用价值的构件,可被其它系统的开发者复用,以开发新的软件系统的构件。江苏校园招聘网二期建设中用到的可复用构件是由一期主站的部分代码,组件与系统复用而成。
软件开发过程中的复用有三种:
1)代码复用
代码复用是指利用已经存在的程序代码来满足当前的需要。编程语言从低级到高级的发展过程就是代码复用率越来越高的发展过程,同时也是从无意识的复用到有意识的大量
复用发展的过程。汇编语言可以通过转移指令来偶然复用代码。C语言中出现了函数,可以有意识的将常用的功能表示为函数而提高了复用率。
2)组件复用
本文中所说的组件是指能够在一种或多种开发环境中被当作类使用的程序块。组件复用是以面向对象开发技术为基础的。面向对象技术中,对象是开发模式的基本成分,是可复用构件的雏形。类是具有一组相同数据结构和相同操作的对象的集合。类和对象都是系统构成的基本单位,以它们为构件符合新系统的要求。招聘网站一期系统中,每一个类几乎都代表着程序员能够进行数据库操作的对象的集合,以这些类和对象为复用构件能大大减轻二期开发中的工作量和提高系统的开发效率。
3)系统复用
随着软件系统不断庞大和复杂,一个软件系统中往往包含着许多小系统,小系统中可能还包含更小的系统。系统复用就是指开发新系统时复用以前的小系统,或者是替换或修改以前系统中的一个或几个小系统使新系统满足客户需要。软件产品线就是系统复用的结果,如Microsoft公司的SQL Server就包括个人版、标准版、开发版和企业版。实例中二期系统的大部分用户界面设计,后台管理员操作界面设计和数据库操作的设计都是以一期主站系统为原型的构件复用。
3 基于软件复用的开发模型
软件复用的过程如下:
复用成分的获取、管理和利用是构成软件复用的3个基本要素。复用成分的获取包括将现有的软件成分抽象成可复用的,以便构成新的软件系统,以及从复用成分库中选取某个具体问题的可复用成分。复用成分的管理完成对复用成分库的组织,以便有效地组织、管理和扩充软件复用成分。复用成分的利用是获取和管理的目的所在,包括根据需要选择抽象的可复用成分,并对其进行适应性修改,以将其集成到现行开发的软件系统中去。
基于软件复用的开发模型是建立在软件复用过程的基础之上,如图1所示。模型中的6步是:(1)认识到有可能复用的机会;(2)分解、抽象;(3)分类并建立复用构件库;(4)检索与选择复用构件;(5)对复用构件具体化;(6)重新组装成新软件。
4 实例应用
江苏校园招聘网是江苏省教育厅投资,由我校开发,为江苏高校毕业生就业提供的电子招聘平台。在为期半年的一期主站开发完成之后,投资方提出了开发期限两个月的二期系统建设的方案。面对工作量不小于一期主站开发的地市分站方案,复用技术成为该项目的不二选择。
随着二期系统按时交付与投资方并得到了投资方的肯定,证明了复用技术在软件开发过程中的正确性和重要性:不仅大大减少了新系统的开发工作量,提高了开发效率,而且由于复用技术用户在使用主站和分站时丝毫不会感到是在使用两个不同的系统,提高了系统的使用连贯性和视觉的统一性。
根据软件复用的开发模型可设计出招聘网一期到二期的复用过程,如图2所示。此过程严格的依照上图模型中的步骤和复用方法,科学并全面地完成了网站分站的的设计。
江苏校园招聘网是由三大模块组成:客户界面模块,后台管理模块和数据库操作模块。软件复用模型的完成给我们提供了一个复用的思想和方法,要完成对具体系统的集体操作还需要对手中的项目进行仔细的分析和研究。要完成这个系统的复用只需要完成三个模块的复用即可,如图3所示。第一步:对一期系统结构进行分析并找出可复用于二期的模块;第二步:对复用构件具体化并根据客户要求进行相应的重新编程修改;第三步:对已经修改好的模块进行重新组装。
5 结论
该文对软件复用技术作了详细的讲述,并以江苏校园招聘网为例对软件复用的开发模型应用进行了详细的研究。
展望未来,软件复用技术和活动将变得系统化和规范化,会出现更多的组织使用复用技术,涌现特定领域的可复用软件构件工厂,形成支持领域或领域间复用软件的开发标准等。软件复用将越来越成为软件开发中的重要技术手段。
参考文献
[1]张海藩.软件工程导论[M].4版.北京:清华大学出版社,2003.
[2]杨芙清,梅宏,李克勤.软件复用与软件构件技术[J].电子学报,1999,27(2):68-75.
[3]王少峰.软件复用技术研究[J].计算机工程与设计,2000,21(5):10-15.
[4]吴明晖.基于构件的框架开发方法及其特定域应用[J].计算机工程,1999,25(10):86-87.
[5]秦扬,陈良宽,蒋韬.软件构件化在MIS系统开发中的应用[J].电脑开发与应用,1999,5(12):9.
软件开发模型 篇9
基于CMMI软件成熟度模型和实际软件开发过程,软件开发的主要过程分为几个阶段:RD(需求开发)、RU(需求理解)、SD(系统设计)、PD(概要设计)、DD(详细设计)、COD(编码)、UT(单元测试)、IT(集成测试)、ST(系统测试)和QC阶段。软件项目的一个关键目标就是质量,ST阶段的缺陷密度是项目质量的关键度量项[1]。但是,在ST阶段发现的缺陷往往是由其他之前的阶段引入的,这些可能引入缺陷的阶段包括COD、DD、IT、PD等[2]。我们使用了Crystal Ball工具对相关数据进行了敏感度分析,包括ST、COD和DD阶段的缺陷引入对于项目的质量目标都有相当的影响。
为了达成软件开发的质量目标,我们必须想办法控制各阶段引入的缺陷数量。从敏感度分析结果上看,COD阶段的缺陷密度对于QC指标的影响比较大,同时,如果能在ST阶段更多地发现和处理实际已经存在的软件缺陷,QC目标达成的可能性会大大增加。
各阶段引入的缺陷数量也与软件程序本身的复杂度有关,在软件测试的概念里,圈复杂度用来衡量一个模块判定结构的复杂程度,数量上表现为独立路径条数,即合理的预防错误所需测试的最少路径条数,圈复杂度大则说明代码可能质量低且难于测试和维护[3]。经验表明:一般圈复杂度越高,Bug发生的可能性越高。
圈复杂度过高会造成下列问题:
1. 复用困难。代码复杂度过高,说明一个函数内覆盖的逻辑过多,程序耦合性(各个模块之间接口的复杂度)较高,所以也不易于移植复用。
2.测试困难。圈复杂度代表路径覆盖的条数,即case数。所以,需要更多的测试才能覆盖一个复杂度较高的程序。
3.易读性差。代码复杂度过高的程序不易于阅读。
4.缺陷率高。一般复杂度越高,缺陷密度越高。代码复杂度过高的程序,变更时更容易产生缺陷。
从图1的两个例子中,我们可以使用一种简单的方法来计算两段程序的圈复杂度。在Example 1中,while循环圈复杂度加1,if语句圈复杂度加1,每个&&语句圈复杂度加1,总体程序执行圈复杂度加1,圈复杂度总和为5。在Example 2中,if语句圈复杂度加1,else语句圈复杂度加1,总体程序执行圈复杂度加1,圈复杂度总和为3。这种方法的基本计算原则是:程序中出现下列关键字的次数再加1,关键字主要包括for、if、while、switch、&&、||、goto和case等。
以上是比较简单的圈复杂度计算方法,另外一种计算方法是利用有向图理论(Sequense)计算由一段代码演化来的有向图中线性独立的路径的个数,来得出圈复杂度的数值。
圈复杂度=E-N+2(1)
其中,E:程序流程有向图中边的个数;N:程序流程有向图中节点的个数。
目前可以使用的计算圈复杂度工具有:
1. JAVA平台:PMD静态分析源代码工具(付费)、JavaNCSS(开源)、CheckStyle(付费);
2.. NET平台:FxCop(开源)、NDepend(付费);
3.C/C++平台:QAC(付费)、Source Monitor(开源)。
我们在实际的项目开发中主要使用Source Monitor开源工具,进行函数圈复杂度研究和统计。
基于之前对于项目开发者能力水平和软件圈复杂度的研究,我们尝试进行数据收集分析并构建COD阶段引入缺陷密度、ACV(C语言技术&编码)和圈复杂度之间的数学预测模型。
基于ACV和圈复杂度建立COD引入缺陷模型构建的目标如下:
1.在项目策划或者COD阶段活动之前,项目经理参考此模型调配项目组成员、安排项目级培训,策划在设计阶段控制圈复杂度,并基于此进行程序设计工作。
2. COD阶段开始后,项目管理人员可以根据代码复杂度管理表中的相关要求进行实际圈复杂度数据的收集,并利用此模型进行预测,进行COD过程中的动态编码控制,适当降低系统和程序文件的圈复杂度。
基于上述的研究目标进行了建模方法的研究,确定了相应的预测前提和思路。
1.通过对动态PPM中数据的敏感度计算结果,COD阶段的引入缺陷数对项目质量的敏感度最大,对项目质量目标的达成有较大的影响。
2. 同时根据相关专家前期对COD阶段引入缺陷数及相关因素的相关性分析结论,COD阶段引入缺陷数与代码规模、圈复杂度、开发人员职级平均值有较强的相关性。
3. 基于上述结论和成果,考虑选择使用开发人员的具体关键能力预测COD阶段缺陷数量,以期待获得更加可控的PPM模型,采用回归分析的方法建立预测模型。
在基础数据收集方面,为了保证数据的同质性,选择同一业务线相关项目进行分析,保证模型的针对性和有效性。实际选择A业务线,基于2008年度至2010年度20余个项目数据进行分析。
使用MiniTab 15.1软件中的Pearson计算方法计算了上述相关数据的相关性,最终发现COD引入缺陷密度、项目平均圈复杂度和编码&C能力均值有较强的相关性,而项目有效代码行数与COD引入缺陷密度无明显的相关性。
基于模型建立的思路和统计分析结果,初步设定数学模型的公式为:
其中,Y:COD阶段引入缺陷密度;X1:项目平均圈复杂度;X2:ACV—项目COD阶段所有开发人员的关键能力项(编码&C)的平均值。
在相关性分析的基础上,使用MiniTab 15.1进行回归分析,能够初步得到COD阶段引入缺陷密度Y、项目平均圈复杂度X1和项目COD阶段所有开发人员的关键能力项(编码&C)的平均值X2之间的数学关系。
通过回归方法得到最后的回归方程为:
从最后的回归方程中我们可以推断:
1.项目COD阶段所有开发人员的关键能力项(编码&C)的平均值X2越大,COD阶段引入的缺陷密度就越小,那么项目的总体质量就会越好;
2.项目平均圈复杂度X1越小,COD阶段引入的缺陷密度就越小,那么项目的总体质量就会越好。
下面是使用MiniTab 15.1工具进行回归分析的结果。
利用上述模型我们可以在合适的项目中进行应用,比如我们可以在项目策划阶段就开始使用模型,通过计算同类项目的平均圈复杂度、拟进入项目组的开发成员的C&编码能力水平来对项目质量进行预测(COD阶段引入缺陷密度)。
如果预测的项目质量目标没有达到客户和组织的要求,项目经理可以根据情况调整项目组的成员,将在C&编码能力方面具有更高水平的人员调入项目,以便减少在COD阶段引入的缺陷数量,降低COD阶段引入缺陷密度。同时,我们还可以在系统设计、概要设计和详细设计阶段不断优化软件设计水平,通过降低程序圈复杂度的方式提升项目质量,降低COD阶段引入的缺陷数量和缺陷密度。
在COD阶段开始之前项目经理或者技术总监可以通过模型预测COD阶段的缺陷密度,如果发现项目质量存在高风险的问题可以提前采取措施进行缺陷预防。
以上提到基于能力的项目质量预测模型在车载导航软件开发中具有一定的普遍意义,相关的分析思路和模型建立的方法可以被应用到软件开发的其他业务领域之中。通过质量预测模型的建立和应用,组织可以不断定量分析、控制其质量目标的制定和达成。
摘要：本文论述了基于ACV-Average Competency Value和系统圈复杂度系数构建COD阶段缺陷预测模型的过程和思路,通过建立的预测模型软件项目管理者可以预测预先设定的项目QCD目标实现概率,提前预测风险并适时增强项目团队的开发力量。
关键词：ACV,圈复杂度,缺陷预测模型
参考文献
[1]Jamaiah H.Yahaya,Aziz Deraman.Measuring the Unmeasurable Characteristics of Software Product Quality[J].IJACT,2010,2(4):95-106.
[2]Hajar Mat Jani,Salama A.Mostafa.Implementing Case-Based Reasoning Technique to Software Requirements Specifications Quality Analysis[J].IJACT,2011,3(1):23-31.
浅析软件质量和能力成熟度模型 篇10
关键词 软件质量 软件质量管理模型 能力成熟度模型 CMM
中图分类号：TP31 文献标识码：A
0引言
随着移动互联网的兴起，目前国内软件产业已经蓬勃发展，拥有很大的规模。软件产品质量也受到了越来越多来自各个行业软件公司的关注。软件能力成熟度就是对于软件组织在定义、实施、度量、控制和改善其软件过程的时间中各个发展阶段的模块，其核心就在于把软件开发视为一个有序可控的过程。可以把软件能力成熟度视为保证软件产品质量的一种过程控制能力。
1软件质量概念的提出
在信息如此发达的当代社会，软件质量的重要性被越来越多的人所接受。近几年，软件质量研究一直是软件研究发展较快的新方向。这是因为在软件实践的过程当中，我们积累了很多的经验，需要加以概括并总结成知识，抽象为科学，这样可以让其他人遵循其中的规律，从而可以更好地实践软件过程。另一方面，人们在软件开发的过程当中，会有许多失败的经验，这就迫使人们不得不进入这一领域，研究软件质量的概念和模型，研究影响软件质量的因素，研究如果通过这些因素来控制软件的质量。
2如何提高软件质量
软件质量管理在上世纪70年代软件危机之后被引起重视，其发展从早期的成品测试、度量发展到对产品形成过程的质量和保证，人们为解决软件危机做出了许多方面的努力。概括地说，有三类方法可以用来改进软件质量：控制软件生产过程、提高软件生产者组织性和软件生产者个人能力。
（1）净化软件工程：就是通过统计的方法来维护软件工程管理过程，其特点是：劳动质量管理，重视开发过程当中的定量分析，这一方法按照原义解释就是指干干净净生产，以提高产品质量。
（2）评估软件能力成熟度：用软件能力成熟度模型来评估软件生产组织研制软件能力的成熟度。CMM是从软件生产的组织过程角度，来评估其生产能力和技术水平。软件能力成熟度分5级。
（3）提高软件生产力和个人技能：用个人软件过程作为一个工具和方法，它给软件工程师提供了测试和分析工具，并帮助软件工程师理解自己的软件生产水平和技巧高低，以求得到提高。
3软件质量管理模型与标准
目前国外较为成熟的质量模型除ISO 9000和CMM外，还有国际标准SPICE，TickIT，Six Sigma，Trillium等。
3.1 ISO 9000质量标准
ISO 9000是一个质量系统标准系列，它包含了综合的质量管理概念和指南，是现代质量管理和质量保证理论结晶，也是在实际开发过程中所总结出的经验教训。
ISO9000软件标准系列包含如下内容：
ISO 9000 - 《质量管理体系–基础和术语》
ISO 9001 - 《质量质量体系–要求》
ISO 9004 - 《质量管理体系–业绩改进指南》
ISO 9011 - 《质量和环境管理体系审核指南》
常用的ISO构架框图如图1：
3.2 CMM
1993年，美国防部在卡内基梅隆大学的软件研究院正式发表了能力成熟度。这是评估软件生产部门软件生产能力成熟度的模型，是从软件生产组织过程角度来评估其达到的水平等级。该等级分为5级，分别为：
5级-优化。过程变化管理、技术变化管理、缺点防止；
4级-管理。软件质量管理、过程定量化管理；
3级-确定。仔细观察、整体协调、软件生产工程、集成软件管理、训练规划、组织过程确定、组织过程中心点
2级-重复。软件构形管理、软件质量保证、软件合同管理、软件工程跟踪和统筹、软件工程计划、需求管理
1级-初始。经验和个人行为。
3.3 ISO-SPICE
ISO-SPICE是ISO和IEC（国际电子技术委员会）共同制定的关于软件过程评估框架的国际标准。该框架包含了软件项目过程中的计划、管理、监督、控制和改进，这些过程涉及软件的获取、供应、开发、操作、发展和支持等。它提供了一个结构化的过程来进行软件过程的质量评估。
4结论
软件质量是一复杂的系统工程问题，换句话说，它必须要用系统的方法来研究。软件过程是以个人智力为基础的有组织的团队行生产活动。用全面质量管理的思想方法，把软件研制和运用过程系统科学地管理起来，这个就是软件质量管理观点和思路。要将软件开发作为一个系统工程来进行过程管理的根本原因在于影响软件质量因素太多，太复杂，难以控制。所以我们才要将整个软件过程给控制起来，其中主要包括确定系统需求、软件需求、初步设计、详细设计、编程、测试等等。
参考文献
[1] 毛明志，詹瑾，黄春贤.软件质量管理综述[J]. 科技管理研究，2006.9.
[2] 徐瑞恩，深入探讨软件成熟度模型[J].软件世界，2001.04.25.
