软件开发周期（共10篇）
软件开发周期 篇1
当用户使用软件的时候, 发现软件的功能与自己的需求不一致, 往往第一个反应就是:这需求是怎么做的?其实, 每个人都知道做软件要做需求分析, 然而很多人对需求分析的重视程度却不够。由于前期的需求做得不充分而导致的后果, 只有到软件测试和交付的时候才显现出来, 而这个时候再纠正, 代价就相当惨重了。下面就以笔者做过的一些欧美项目中成功和失败的经验为例, 探讨一下软件开发周期中的需求分析。
一什么是需求分析
结构化软件开发一般分为分析、设计、开发、测试、验收与运行等阶段。开发前, 会进行前期的可行性研究;在运行开始以后, 还要进行后期维护。需求分析是结构化开发中的重要阶段。通常情况下, 国内软件开发公司在做欧美和日本的项目时, 对前期的可行性研究参与得较少, 一般都是对方已经做完可行性研究, 国内软件开发公司从需求分析开始做起, 直到软件开发后的运行和维护。
所谓“需求分析”, 是指对要解决的问题进行详细的分析, 弄清楚客户的需求, 包括需要输入什么数据, 要得到什么结果, 最后应输出什么, 等等。可以说, 软件工程当中的“需求分析”就是确定要计算机“做什么”。
二需求分析的重要性
从需求分析的定义上, 就可以看出需求分析在软件开发过程中的重要性了。需求分析做得不对, 后面的步骤做得再好, 也只能是南辕北辙, 无法满足客户的要求。研究表明, 改正产品付诸应用后所发现的一个需求方面的缺陷, 比在需求阶段改正这个错误要多付出大约100倍的成本。而另一项研究发现, 在需求开发阶段发现的一个错误, 平均仅需要花30分钟修复, 但若在系统测试时发现则需要5—17个小时来修复。
只有通过软件需求分析, 才能把软件功能和性能的总体概念描述为具体的软件需求规格说明, 从而奠定软件开发的基础。软件需求分析工作也是一个不断认识和逐步细化的过程。该过程将软件设计阶段所确定的软件范围逐步细化到可详细定义的程度, 并分析出各种不同的软件元素, 然后为这些元素找到可行的解决方法。
先以笔者之前做的加拿大项目失败的需求分析为例。由于和客户签订了合同, 5个月必须交付软件, 开发时间紧迫, 导致项目计划时做需求分析的时间只给了2周时间 (理由是客户的文档已经提供好了, 照着做即可) 。结果, 由于前期对客户文档理解得不是很清楚, 导致开发进行到3个月的时候发现需求上有争议。在和客户确认后得出结论:如果要满足客户的要求, 则需要对整体架构进行修改。虽然最后按期交付了软件, 但是整个项目组最后两个月每天都在加班, 包括周末, 而且软件质量也没有得到客户的充分认可。
再以之前做过的一个美国项目为例。笔者作为需求分析人员在软件开发开始阶段到美国与客户做软件需求分析。在了解客户需求的同时, 笔者尽量了解客户为什么要这么做, 帮客户一起想需求, 以便我们开发的软件能够更好地为客户服务。每天开完会后, 笔者把客户的需求整理好, 发给国内的同事进行研究分析, 建立简单的基础模型并研究技术可行性。需求分析结束回国后, 笔者保持每周至少3次电话会议与客户进行沟通, 随时了解客户的需求。正因为在前期阶段进行了这种细致的需求分析, 项目组在很少加班的情况下, 不但按时交付了项目, 并且得到客户的充分认可。
三软件需求分析的任务
需求分析所要做的工作是深入描述软件的功能和性能, 确定软件设计的限制范围和软件同其他系统元素的接口细节, 定义软件的其他有效性需求。
分析员通过需求分析, 逐步细化对软件的要求, 描述软件要处理的数据域, 并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示。在软件开发结束后, 制定的软件需求规格说明还要为评价软件质量提供依据。这里需提到很重要的一点是, 需求分析后的软件需求规格说明书上一定要有客户的确认签字, 这是必不可少的环节, 关系到以后软件开发的成败。
通常, 软件开发项目是要实现目标系统的物理模型, 即确定待开发软件系统的系统元素, 并将功能和数据结构分配到这些系统元素中, 它是软件实现的基础。但是, 目标系统的具体物理模型是由它的逻辑模型经实例化, 即具体到某个业务领域而得到的。与物理模型不同, 逻辑模型忽视实现机制与细节, 只描述系统要完成的功能和要处理的数据。作为目标系统的参考, 需求分析的任务就是借助当前系统的逻辑模型导出目标系统的逻辑模型, 解决目标系统的“做什么”问题。通常用数据流图、E-R图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
在软件分析过程中, 应尽可能地让更多的人参与进来, 而不仅仅是软件分析师自己。在之前的美国项目中, 在前期分析时软件开发的核心技术人员和测试人员就已经进入项目组, 每天技术人员会对分析的结果提出技术实现的难点以及改进的方法, 笔者在随后的会议上就会和客户进行讨论, 尽量在满足客户需求的同时, 使用更简单可行的技术, 这样就为以后的开发奠定了基础, 使开发时的工作量大大减少。测试人员也在需求时提出从测试角度看到的问题, 同样在需求分析阶段得到解决, 节省了大量的开发时间。
四进行需求分析的注意事项
1.需求分析是分析人员与用户共同的责任。用户必须对软件功能和性能提出初步要求, 并澄清一些模糊概念。而需求分析人员则要认真了解用户的要求, 细致地进行调查分析, 把用户“做什么”的要求最终转换成一个完全的、精细的软件逻辑模型, 并写出软件的需求规格说明, 准确地表达用户的要求。在加拿大的项目中, 由于时间紧迫, 一些模糊问题没有及时澄清, 导致最后返工, 影响了项目进度。
2.需求分析阶段研究的对象是软件项目的用户要求。需要注意的是, 必须理解用户的各项要求, 但又不能全盘接受所有的要求。因为并非所有用户的要求都是合理的。对其中模糊的要求需要进行澄清, 然后才能决定是否采纳。对于那些无法实现的要求应向用户做出充分的解释, 以求谅解。在美国的项目中, 针对客户提出的需求, 了解客户的意图后, 发现技术上实现有很大难度。我们了解到这个需求对客户来说不是十分重要, 于是和客户商量出一个折中的解决方案, 绕过技术难点, 并且没有降低客户满意度。
3.分析人员要使用符合客户语言习惯的表达, 应主动积极了解客户业务和相关知识。需求讨论集中于业务需求和任务, 因此要使用术语。客户应将有关术语教给分析人员, 而客户不一定要懂得计算机行业的术语。由于通常情况下客户对计算机术语了解不多, 需求分析人员应该尽量将计算机术语转化成通俗易懂的语言, 这样便于和客户沟通。而对于客户方面的术语, 一方面不懂的时候一定要问;另一方面也要多学习。笔者在美国做的项目涉及航空制造业, 在去美国之前特意花了一些时间在网上浏览相关材料以及工业术语, 在进行需求分析的时候确实起到了一定的作用。
4.对用户进行正确分类。组织中的用户在很多方面存在差异, 根据用户的特点, 可对用户进行一定的分类。将用户分类并归纳各自特点, 详细描述他们的个性特点及任务状况, 将有助于需求的获取和分析。不同的问题需要询问不同的人, 对于操作细节的问题, 要和实际负责操作的用户进行沟通;而对于关乎全局的问题, 则要和相应的管理层用户进行沟通。这是项目管理中的一个重要组成, 叫做“干系人分析”。在做需求分析之前干系人分析一定要做好。笔者到美国前, 曾通过美国方面的联系人、本公司的销售人员等, 把整个项目中每个人的角色都已经分析清楚。到了美国后, 知道有什么问题问什么人, 不知道问谁的时候找到总负责人, 不但节省了大量时间, 而且避免了很多可能出现的问题。
综上所述, 需求分析是软件开发周期中的重要阶段, 关系到软件开发的成败。我们在软件开发中应该充分重视这一阶段, 尽量将问题在这一阶段解决好, 为后期的软件开发打好坚实的基础, 使项目能够保质保量的完成。
软件开发周期 篇2
软件过程定义了软件开发中采用的方法。软件工程是集成计算机软件开发的过程、方法和工具的学科。
软件工程的一般视图：定义阶段（做什么）、开发阶段（如何做）、支持阶段（变化）。线性顺序模型
有时被称为“传统生存周期或瀑布模型”。
活动包括：系统/信息工程和建模、软件需求分析、设计、代码生成、测试、支持 为什么线性模型有时候不能奏效？
建议：虽然线性模型经常被嘲笑为“旧式的”，但是，在需求被很好理解的情况下，它仍然是一种合理的方法。缺点：
1、实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。
2、经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。
3、客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。
4、采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去，有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。
优点：
1、它提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。
2、虽然有不少缺陷但比在软件开发中随意的状态要好得多。
瀑布模型将软件开发活动分为需求分析、设计、编码、测试等几个阶段，这几个阶段是对工程活动的划分，瀑布模型没有再涉及其它方面的活动，因此瀑布模型关注于工程活动。
关于选取开发模型
有时开发模型的选取不是很容易判断的，这里面有时不单是需求及开发的问题，对于开发商有开发周期、开发费用的问题，对于用户同样有内部计划、公司发展计划等因素进行影响。
一般来说对于应用开发―――为客户开发软件，客户在开发及测试完毕软件后就要实际开始使用，那么就使用瀑布模型。
当然在需求明确的情况下自然也要使用瀑布模型
对于自主开发及客户需求不明并有较长的设计时间―――可以用演化模型。
而螺旋模型适于适合于大型软件开发，吸收了“演化”概念，不过有时也用于用户需求不明的情况下。当然还有其他开发模型，没有在本文讨论。名词定义：
瀑布模型：规定了各项软件工程活动。包括：制定开发计划、进行需求分析和说明、软件设计、程序编码、测试及维护。
特点：自上而下，相互衔接的固定次序，如瀑布流水、逐级下落。
演化模型：第一次只是试验开发，其目标只在于探索可行性，弄清软件需求;第二次则在此基础上获得较为满意的软件产品，通常把一次得到的试验性产品称“原型”。特点：减少由于软件需求不明确而给开发带来的风险。
螺旋模型：将瀑布模型及演化螺旋模型结合起来，并且加入被两种模型都忽略了的风险分析，弥补了两者的不足。
瀑布模型的特点：
① 瀑布模型为软件的开发和维护提供了一种有效有管理模式，对保证软件产品的质量有重要的作用；
② 可根据这一模式制定出开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段，有效地对整个开发过程进行指导； ③ 在一定程度上消除非结构化软件、降低软件的复杂度、促进软件开发工程化方面起到显著作用；
④ 瀑布模型缺乏灵活性、无法通过开发活动来澄清本来不够确切的需求，这将导致直到软件开发完成时发现所开发的软件并非是用户所需求的。原型实现模型
原型实现范型定义： 需求收集 快速设计
原型实现模型是迭代的，是帮助客户或开发者理解需求的，总体上讲，并不是交付一个最终产品系统。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统（虽然这个系统不带有任何质量的保证），所以客户和开发者都比较喜欢这种过程模型（对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质量和不害怕长期维护的公司而言）。缺点：
1、没有考虑软件的整体质量和长期的可维护性。
2、大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
3、由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。
优点：
1、如果客户和开发者达成一致协议：原型被建造仅为了定义需求，之后就被抛弃或者部分抛弃，那么这种模型很合适了。
2、迷惑客户抢占市场，这是一个首选的模型。
原型实现仍然是软件工程的一个有效范型。关键是定义开始时的游戏规则，即客户和开发者达成一致：原型被建造仅是为了定义需求，之后就被抛弃了（或至少部分被抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。
建议：当你的客户有一个合理的续签，但对细节没有任务线索时，先开发一个原型。
原型模型则主要是为了解决需求获取的难题而创建原型用于需求的获取和确认，再将需求转化为软件系统，其主要内容集中在软件开发本身，因此原型模型也关注于工程活动。RAD模型
快速应用开发（Rapid Application Development、RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。是线性顺序模型的一个“高速”变种，通过使用基于构件的建造发放赢得了快速开发。如果需求理解的好而且约束了项目的范围，利用这种模型可以很快的创建出功能完善的“信息系统”。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。RAD过程强调的是复用，复用已有的或开发可复用的构件。实际上RAD采用第四代技术。基于构件的软件工程（不理解）适用范围：
如果需求理解得很并且约束了项目范围。主要适用于信息系统应用，包括以下阶段：业务建模、数据建模、过程建模、应用生成、测试及反复。
业务建模工作流程与其他工作流程的关系如下：
业务模型是需求工作流程的一种重要输入，用来了解对系统的需求。
业务实体是分析设计工作流程的一种输入，用来确定设计模型中的实体类。
缺点：
1、只能用于信息系统。
2、对于较大的项目需要足够的人力资源去建造足够的RAD组。
3、开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。
4、这种模型对模块化要求比较高，如果有哪一功能不能被模块化，那么建造RAD所需要的构件就会有问题。
5、技术风险很高的情况下不适合这种模型。
优点：
1、开发速度快，质量有保证。
2、对信息系统特别有效。演化软件过程模型
演化模型是迭代的。它的特征是：使软件工程师渐进地开发逐步完善的软件版本。
5.1 增量模型
增量模型融合了线性顺序模型的基本成分（重复的应用）和原型实现的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都做为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断从复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
缺点：
1、至始至终开发者和客户纠缠在一起，直到完全版本出来。
优点：
1、人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人力实现下一个增量。
2、当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。
3、具有一定的市场。
增量模型将瀑布模型的顺序化和多次迭代相结合，每个增量开发都是一次瀑布模型的过程，强调每一个增量均发布一个可运行版本，以满足客户和市场的需要。增量模型主要考虑当需要快速推出可运行的版本，而该版本不需要完整的功能时，在工程活动上的解决方案，因此增量模型也关注于工程活动。
5.2 螺旋模型
这是一个演化软件过程模型，它将原型实现的迭代特征和线性顺序模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。在每一个迭代中，被开发系统的更加完善的版本逐步产生。螺旋模型被划分为若干框架活动，也称为任务区域。典型地，有3到6个任务区域：
1、客户交流：建立开发者和客户之间有效通信所需要的任务。
2、计划：定义资源、进度、及其它相关项目信息所需要的任务。
3、风险分析：评估技术的及管理的风险所需要的任务。
4、工程：建立应用的一个或多个表示说需要的任务。
5、构造及发布：构造、测试、安装和提供用户支持所需要的任务。
6、客户评估：基于对在工程阶段产生的或在安装阶段实现的软件表示的评估，获得客户反馈所需要的任务。
这是一个相对较新的模型，它的功效还需要经历若干年的使用方能确定下来。
缺点：
1、需要相当的风险分析评估的专门技术，且成功依赖于这种技术。
2、很明显一个大的没有被发现的风险问题，将会导致问题的发生，可能导致演化的方法失去控制。
3、这种模型相对比较新，应用不广泛，其功效需要进一步的验证。
优点：
1、对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。
螺旋模型的主要贡献在于明确提出迭代概念和风险的问题，并指出在项目定义、需求、设计等阶段均存在风险，需要重点考虑，并通过多次迭代的原型主动诱发风险。风险管理不属于工程活动的范围，但我们仍然认为螺旋模型的主要内容是工程方面的：因为对于非工程活动，螺旋模型仅考虑了风险问题，而风险管理仅是非工程活动的一个小部分，不足以依此推断螺旋模型主要关注于非工程活动。
5.3 WINWIN螺旋模型
螺旋模型提出了强调客户交流的一个框架活动。该活动的目标是从客户处诱导项目需求。在理想情况下，开发者简单地询问客户需要什么,而客户提供足够的细节进行下去。不幸的是这种情形很少发生。在现实中，客户和开发者进入一个谈判过程，客户被要求在成本和应市之间的约束下平衡功能、性能、和其它产品或系统特征。最好的谈判追求“双赢”结果，也就是说通过谈判客户获得大部份系统的功能，而开发者则获得现实的和可达到的预算和时限。对客户的交流定义了下面的活动：
1、系统或子系统的关键“风险承担者”的标识。
2、风险承担者的“赢条件”的确定。
3、风险承担者的赢条件谈判，以将它们协调为一组满足各方考虑的双赢条件。
缺点：
1、需要额外的谈判技巧。
优点：
1、客户和开发者达到一种平衡。
5.4 并发开发模型
这种模型关注于多个任务的并发执行，表示为一系列的主要技术活动、任务及它们的相关状态。并发过程模型是由客户要求、管理决策、评审结果驱动的。该模型不是将软件工程活动限定为一个顺序的事件序列，而是定义了一个活动网络。网络上的每一个活动均可于其它活动同时发生。这种模型可以提供一个项目的当前状态的准确视图。
缺点：暂时无
优点：
1、可用于所有类型的软件开发，而对于客户/服务器结构更加有效。
2、可以随时查阅到开发的状态。基于构件的开发模型
面向对象的技术为软件工程的基于构件的过程模型提供了技术框架。面向对象模型强调了类的创建、类的封装了的数据、操纵该数据的算法。一般来讲经过合适的设计和实现，面向对象的类可以在不同的应用及基于计算机的系统的体系结构中复用。基于构件的开发模型融合了螺旋模型的许多特征，它本质上是演化形的，要求软件创建的迭代方法。然而基于构件的开发模型是利用预先包装好的软件构件（有时成为类）来构造应用。
开发活动从候选类的标识开始，这一步是通过检查将被应用系统操纵的数据及用于实现该操纵的算法来完成的。相关的数据和算法被封装成一个类。
缺点：
1、过分依赖于构件，构件库的质量影响着产品质量。
优点：
1、构件可复用。提高了开发效率。
2、采用了面向对象的技术。形式化方法模型
形式化方法模型包含了一组活动，他们导致了计算机软件的数学规约。形式化方法使得软件工程师们能够通过应用一个严格的数学符号体系来规约、开发、和验证基于计算机的系统。这种方法的一个变种，称为净室软件工程，已经被一些组织所采用。在开发中使用形式化方法时，它们提供了一种机制，能够消除使用其它软件过程模型难以克服的很多问题。二义性、不完整性、不一致性能被更容易地发现和纠正，而不是通过专门的评审，是通过对应用的数学分析。形式化方法提供了可以产生无缺陷软件的承诺。
缺点：
1、开发费用昂贵（对开发人员需要多方面的培训），而且需要的时间较长。
2、不能将这种模型作为对客户通信的机制，因为客户对这些数学语言一无所知。
3、目前还不流行。
优点：
1、形式化规约可直接作为程序验证的基础，可以尽早的发现和纠正错误（包括那些其它情况下不能发现的错误）。
2、开发出来的软件具有很高的安全性和健壮性，特别适合安全部门或者软件错误会造成经济损失的开发者。
3、具有开发无缺陷软件的承诺。第四代技术
一系列的软件工具的使用，是第四代技术的特点。这些工具有一个共同的特点：能够使软件工程师们在较高级别上规约软件的某些特征，然后根据开发者的规约自动生成源代码。我们知道，软件在越高的级别上被规约，就越能被快速的建造出程序。软件工程的4GT模型集中于规约软件的能力：使用特殊的语言形式或一种采用客户可以理解的术语描述待解决问题的图形符号体系。和其它模型一样，4GT也是从需求收集这一步开始的，要将一个4GT实现变成最终产品，开发者还必须进行彻底的测试、开发有意义的文档，并且同样要完成其它模型中同样要求的所有集成活动。总而言之，4GT已经成为软件工程的一个重要方法。特别是和基于构件的开发模型结合起来时，4GT模型可能成为当前软件开发的主流模型！
缺点：
1、用工具生成的源代码可能是“低效”的。
2、生成的大型软件的可维护性目前还令人怀疑。
3、在某些情况下可能需要更多的时间。
优点：
1、缩短了软件开发时间，提高了建造软件的效率。
浅谈软件生命周期模型及其选择 篇3
关键词 软件生命周期 瀑布型 快速原型
中图分类号：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.
软件开发周期 篇4
关键词：软件安全,生命周期,SDL,CLASP,安全接触点
0、引言
软件只有在满足了保密性、完整性和可用性以及不可否认性等安全属性的情况下才被认为是安全的, 然而现实中大多数软件都不足够安全, 包含一些可被有恶意企图的人利用的安全缺陷。传统的软件开发生命周期中很少考虑安全属性, 导致在软件开发阶段引入安全脆弱性。
安全软件工程将安全考虑集成到软件开发过程的每一个阶段来避免安全缺陷[1]。将一系列安全设计原则、安全最佳实践及专家经验组合起来, 形成了软件安全开发生命周期。目前比较有影响力的有微软的SDL[2] (Security Development Lifecycle) , OWASP的CLASP[3] (Comprehensive, Lightweig ht Application Security Process) 方法和McGraw的安全接触点方法[4]。
1、软件安全开发生命周期简介
Common Criteria (国际通用的软件安全评估准则) 中的生命周期模型安全保障类ALC:Life–cycle support指出:为开发和维护一个评估目标使用一个生命周期模型并不能确保评估目标就能满足所有的安全需求, 可能选定的模型不够充分, 对评估目标的益处并不能观察到, 但使用一个已被众多专家或标准组织认可的生命周期模型将提升待评估目标满足安全需求的机会。
1.1 微软的SDL方法
微软的安全开发生命周期SDL是一个业界领先的软件安全保障过程。通过与实际的开发方法相结合, SDL将安全和隐私方面的考虑很早就集成到开发中, 并贯穿整个开发过程。
1.2 OWASP的CLASP方法
该生命周期模型是一个由一系列安全活动驱动的, 基于角色组织的安全推进实践过程模型。它通过一些正式的安全最佳实践将安全属性以一种结构化、可重复和可测量的方式整合进软件开发组织的现有或者新开动的软件开发生命周期中。
1.3 McGraw的安全接触点方法
McGraw强调应该使用工程化的方法来实施软件安全, 即在整个软件开发生命周期中都要确保将安全作为软件的一个有机组成部分。支持该模型的三根支柱是风险管理、软件安全的接触点和安全知识。
以上提到的各种开发模型都提供了涵盖整个开发生命周期的一系列活动, 这些模型也都经过了实践的检验。
2、各模型的分阶段对比
每一个开发周期模型都处于不断演化进步的过程中, 本文对比所选用的版本是能获取到的最新版。微软的SDL选用的是版本5.2, CLASP选用的是版本1.2, McGraw依据的是[4]。下面从各个开发阶段所进行活动的角度来对三种模型做对比。
2.1 项目启动阶段
三种模型都认为应该对项目组成员进行安全培训:SDL中安全培训是基础性工作, 开发成员必须了解基本安全概念, 每年至少参加一门安全培训课程, 并为开发人员提供了入门培训套件, 其中含有14个用于安全开发过程的简要的、独立划分的指导方针;CLASP中基本的安全培训面向所有项目成员, 此外针对不同角色还需要进行专门的培训;安全接触点方法提供了知识管理的框架, 通过该框架加速安全知识的传播。在该阶段三种方法也都提到建立安全团队, 分配安全任务:SDL中要求建立安全领导团队, 任命安全顾问担任开发团队和安全团队沟通的桥梁;CLASP中建议任命专门的安全管理人员, 并且为其他开发人员角色也分配了相应的安全任务;安全接触点方法中要求建立软件安全组以专门负责处理安全问题;三种模型也都认为需要为软件构建过程中的安全实践活动建立安全评估标准, 以衡量活动实施的成效。但具体如何建立标准和怎样衡量, SDL和安全接触点方法都没有详细说明, 而CLASP方法阐述了可以使用哪些评估标准、以怎样的方式进行评估, 并且提出应建立评估收集和报告策略, 对评估标准也应周期性更新。此外, SDL和安全接触点方法都认为应提供贯穿整个生命周期过程的追踪工具以便能随时获取安全风险的状态。
2.2 需求分析阶段
三种方法都认为应使用文档描述安全需求, 记录业务层和功能需求对安全的考虑。CLASP方法和安全接触点方法还通过详细描述误用例来将潜在的风险和安全相关决定向利益相关者传达。SDL方法认为在把时间投入到设计和实现之前, 应该搞清处理安全和隐私数据的代价花费, 因为隐私风险增加了开发和支持成本。在识别系统的功能方面的同时, 也需要强制执行安全风险评估并进行隐私影响分级。CLASP提出应该在需求文档中详细描述对软件运行环境的安全假设和需求, 识别客户组织的全局安全策略, 保证软件产品的适应性以及与其他软件产品的相容性。
2.3 设计阶段
SDL在该阶段主张建立和遵循设计的最佳实践:在功能性规格说明书中描述产品的安全特性, 在设计规格说明书中描述怎样实现安全功能需求。实行风险分析和威胁建模来识别待构建软件中的脆弱性。微软还提供了威胁建模工具来辅助这个过程的实施。CLASP把该阶段区分为架构层面和设计层面:在架构层面上识别系统资源和信任边界理清安全需求, 识别用户角色和对资源的操控能力来表达访问控制需求;在设计层面上进行如下的一系列活动:识别攻击面来描述系统的访问入口, 应用安全设计原则来稳固系统设计, 对安全解决方案进行研究和评估, 使用安全属性来对设计类图的数据域进行安全策略注解, 描述数据库资源的默认安全配置, 对后续阶段报告的安全事件进行处理, 进行系统需求和设计的安全分析。接触点方法在该阶段认为应该使用文档记录各种前提假设, 确定可能的攻击。对系统体系结构进行风险分析, 解释系统设计的瑕疵, 对它们进行风险等级评估, 并开始进行降低风险的活动。
2.4 编码实现阶段
SDL主张建立、交流和遵循开发安全代码的有效实践, 以便在软件开发的早期发现和移除安全和隐私问题。为用户创建处理安全和隐私问题的文档和工具以便于用户合理安全的部署该程序。CLASP通过对函数的输入参数和输出进行正当性验证和错误处理来进行接口契约的实现, 以此来提供单元级的语义输入验证;详细描述资源策略和安全技术并编码实现文档中需要的安全功能需求。三种方法都主张应该对编写的代码进行安全评审:SDL主张使用最新版本的编译器和支持工具以及源代码分析工具来检测代码的安全性。CLASP通过执行代码的安全评审来发现在实现阶段引入的安全漏洞。安全接触点方法在该阶段使用静态分析工具来自动进行源代码的安全审核。
2.5 测试阶段
三种方法都认为应进行安全测试:SDL进行安全测试主要用来处理两大方面的安全关注:1确保软件的机密性、完整性和可用性都得到了满足。2.确保那些可能导致安全漏洞的事件都得到了处理。CLASP通过进行识别、实现和执行安全测试来发现代码评审中未发现的安全问题和操作环境可能引起的安全风险, 并且将其作为一种纵深防御的机制来发现设计、规格说明文档和实现中的缺陷。通过验证资源的安全属性来确保软件遵循了先前制定的安全策略。接触点方法主张进行两种策略的安全测试:1.用标准功能测试技术来进行安全功能性测试。2.以攻击模式、风险分析结果和滥用案例为基础进行基于风险的安全测试。SDL通过进行安全推进活动来对威胁模型进行更新、执行代码评审和测试, 及对文档进行彻底的评审和编辑。安全推进活动的目的是发现漏洞而不是修正它们, 修正漏洞在执行安全推进活动之后进行。安全接触点方法认为在软件完成并且已经安装在操作环境中之后需要进行渗透测试, 但这个阶段修改缺陷的代价往往太过昂贵, 渗透测试的真正价值在于它能探测在其最终操作环境中的运行状况。
2.6 软件发布和维护阶段
SDL认为在将软件产品发布给用户之前, 需要进行最终的安全评审和隐私评审来确定软件已经达到足够安全可以发布的程度, 否则可能推迟产品的发布。CLASP认为应执行代码签名来让用户可以验证软件的出处和完整性。安全接触点方法认为应该仔细地配置和定制软件应用的部署环境来增强其安全状态, 操作人员应该认真地设置和监视实际部署的系统, 设置事件日志记录和事件监视机制。三种方法都有这样的共识:任何发布的软件都可能含有未知的安全和隐私缺陷, 即使开发人员已经尽了最大的努力。SDL认为软件开发团队应该制定紧急状况响应计划做好准备以应对可能出现的安全漏洞。在软件发布之后, 产品开发团队必须在出现安全或隐私问题之后立即做出响应, 修正软件漏洞提供安全更新服务;CLASP提出在软件发布之后一旦出现安全问题要及时同两类角色做好沟通, 一是要同客户做好沟通, 消除不利影响, 二是同组织内外的安全专家研究有效的应对之道;安全接触点方法也认为应该对攻击的出现做好准备, 并及时清除攻击后出现的混乱状况。
3、各模型的对比分析
经过对比我们可以发现, CLASP进行的安全相关活动最多, 共有24个, 而安全接触点方法仅提供了7个最重要的安全活动, SDL提供了14个安全相关活动。但一个软件开发方法的有效性不仅仅取决于进行的安全活动数量, 而且进行更多的安全活动必然耗费更多的人力和时间, 基于成本收益分析也应该进行那些耗费资源少却可以收益大的安全活动。安全接触点方法认为处理软件安全的方法不应过于庞杂且应该易于采用, 即使采用部分方法, 也依然能够对软件安全产生巨大的影响, 该方法对七个安全接触点进行了安全贡献排序, 如不能全部采用七个安全接触点, 也应首先采取安全贡献大的接触点。CLASP也允许软件组织对其进行活动裁剪, 它提供了12-14个高或者非常高影响力的安全活动, 如果采取这些安全活动, 将在耗费比较少的时间和人力的情况下依然可以取得比较好的安全收益。微软为采取SDL的软件组织定义了四个成熟度等级, 分别是基本级别、标准级别、高等级别和动态级别, 软件组织可以逐步地改变自己的软件开发方式。
本文采取了瀑布模型的分阶段组织形式进行研究, 事实上三种模型都不限制其可以被整合进的开发模型。微软提供了将SDL与一般开发生命周期模型结合的方法, 在与敏捷开发结合上也提供了详细的说明。CLASP中的安全活动是按照人员在项目中的角色来组织的, 因此可以灵活地适应多种开发模型。接触点方法中的接触点是作用到软件工件上, 而大多数软件过程都描述了创建这些软件工件的方法。因此对已有的软件开发生命周期模型进行改编使得其包含安全接触点也不困难。
通过以上的对比可以得出, 一个优秀的安全软件开发生命周期模型有如下的共同特点:1.重视安全培训和教育;2.建立安全团队, 明确安全责任分工;3.将安全最佳实践进行整合, 各个开发流程平稳过渡;4.重视安全工具的使用;5.在产品发布曝出安全漏洞之后及时响应。
4、结束语
在开发安全关键软件如需要处理客户敏感信息的软件、需要利用网络沟通的软件和需要运行在商业环境下的软件时, 需要考虑采用软件安全开发生命周期。本文所讨论的三种软件安全开发生命周期既有很多共性的部分, 也有很多差异性的部分, 软件组织应根据自身实际, 对现有的软件开发过程依据这些典型模型制定改进计划和衡量方法, 持续不断地提升开发和管理水平以保障软件产品具有足够高的安全性, 减少后期维护成本。
参考文献
[1]Khan M, Zulkernine M.A Survey on Requirements andDesign Methods for Secure Software Development[R].School of Computing, Queen’s University, Kingston, On-tario, Canada, 2009, 08.
[2]Lipner S, Howard M.Microsoft Security DevelopmentLifecycle[R].http://www.microsoft.com/security/sdl.LastAccessed April 2012.
[3]OWASP CLASP Project.Comprehensive, lightweightapplication security process[R].http://www.owasp.org/in-dex.php/Category:OWASP_CLASP_Project.Last Ac-cessed March 2012.
[4]McGraw G.软件安全——使安全成为软件开发必需的部分[M].周长发, 马颖华, 译.北京:电子工业出版社, 2008, 04.
软件开发周期 篇5
[关键词]Mathematica 椭圆积分 大摆角运动 周期
[中图分类号]G633.7 [文献标识码]A [文章编号] 16746058（2016）050052
一、引言
摆动是最基本的物理现象，单摆是高中物理的一个重要实验，可用来展现多种力学现象。对于单摆，教材通过推导得出摆角小于5度时，其运动规律近似为简谐振动，并直接给出其周期公式T0=2πl/g，这里l是摆长，g是重力加速度。但是当摆角大于5度时，其周期为多少？能不能通过什么方法计算出来？这个问题有不少人想过，但大多数都束手无策，原因有以下两点：（1）实际单摆在做大摆角运动时，由于各种阻力作用，其摆角减小较快，因此很难用实验的方法准确测量较大摆角下的周期；（2）大摆角单摆的运动方程为非线性微分方程，很难用高中数学求其周期，但是周期可以用数学中的椭圆积分来表示。椭圆积分是数学中的一个特殊函数，对高中学生来说极为陌生。Mathematica软件中有专门的内部数学函数可以计算椭圆积分。本文尝试用Mathematica软件得出不同摆角下的周期值。
二、较大摆角下单摆周期的推导
众所周知，单摆在摆动过程中，必须满足能量守恒。为了讨论方便，本文以摆球下摆到最低点时，摆球重力等于摆球运动所需向心力情况下的摆角为讨论的最大摆角，由此有：mg=mv2/l；由机械能守恒有：mgl（1-cosα）=mv2/2。从上面两式可得单摆的“最大”摆角为60度。
以摆角α（角度°）为横坐标，以约化周期T/T0为纵坐标，画出图像如下图所示。人教版物理选修3-5标注中给出“用高等数学进行计算：偏角为15度时与公式相差0.5%，23度时相差1%，”与本方法所得的结论完全吻合。
[参考文献]
梅宇航，董平.基于MATLAB的单摆初始摆角的讨论[J].中学物理，2009（6）：21-24.
软件开发周期 篇6
关键词：Pro/E软件,零件特征,新品开发
在现代制造行业中, 面向市场的生产自动化正在飞速发展。这主要在于生产自动化能节省大量的劳动力, 改善人们的劳动条件, 更能提高制造业的竞争能力。即对于市场变化的响应能力与响应速度, 包括提高生产效率, 提高产品质量, 降低产品成本, 缩短产品周期, 加速产品更新换代等。随着我国制造业的发展, 在一些拥有一定的先进技术和经济实力的企业, CAD/CAM技术已在开发应用方面取得成就。如利用Pro/E软件开发产品。Pro/E软件将三维零件设计, 二维图生成, 组件和装配图设计建立在同一数据平台上, 任意一个环节作更改, 其余环节作相应改变。零件三维图设计完后, 就可以进行模具的设计。因此与传统产品设计相比, 利用Pro/E软件开发产品, 能提高产品设计质量, 减少设计错误, 缩短产品开发周期, 加速产品的更新换代。
在Pro/E软件中, 更改零件特征的尺寸, 则零件大小和工程图装配图自动作相应改变。因此巧妙地设计好零件的每一个特征, 只要更改特征尺寸的大小或重新定义特征的形状, 就可以很快的开发出一个全新的零件或产品, 大幅缩短新品开发周期。现以电动刷为例具体说明。
右图为电动刷三维图, 开发电动刷新品的要求为:
1) 要求刷体长, 宽, 厚可变;
2) 要求刷头间距相等, 间距可变, 刷头个数可变;
3) 要求刷头顶角可变, 刷头厚度与刷体相同;
4) 要求刷头顶点在一条直线或曲线上, 直线位置和角度可变, 曲线形状可变。
根据以上新品开发的要求, 用Pro/E软件来设计零件的每一个特征, 设计好的零件只需改变一个或几个尺寸, 或重新定义某一特征, 就能自动生成一个新的产品。零件设计步骤以及技巧如下 (使用2000i版本) :
1) 创建基础特征即刷体
步骤:Feature→Create→Protrusion→Extrude→Done→O ne Side→Done→选FRONT为草绘面→选TOP为顶面, 草绘刷体截面, 以Blind作为深度选项即可完成刷体特征。
2) 创建曲线特征
步骤:Datum→Curve→Sketch→Done→选TOP为草绘面→Okay→选FRONT作底面→画直线
技巧: (1) 画此直线是为了使刷头顶点保持在一条直线上;
(2) 使直线两个端点与刷体上下两边对齐, 这样改变刷体长度, 直线长度跟着改变, 使刷体长度始终与直线在刷体长度方向的投影等长;
(3) 标注直线端点与RIGHT面的距离和直线与FRONT面的夹角以满足产品设计要求。
3) 创建点特征
步骤:Datum→Point→On Curve→Length Ratio→选取直线上一个点, 输入值0。
4) 创建点的阵列特征
步骤:Feature→Pattern→选取点特征→选取点的值0→输入其增量值0.2→输入阵列个数5, 共出现五个点。
技巧:此处创建点特征并作点的阵列, 是为后面刷头阵列作准备。这样能保证点距相等, 并能很方便的改变点距和点的个数。
5) 创建刷头特征
步骤:Create→Protrusion→Exture→Done→Use Pre→Okay, 画刷头截面, 使刷顶与点PNT0对齐, 标注顶角, 生成成功后输入深度, 用Up to Surface, 选取刷体顶面。
技巧: (1) 使刷头顶点与PNT0对齐, 这样能保证所有刷头顶点在一条直线或曲线上, 改变点距和点的个数, 刷头距离和个数跟着改变, 这样新品的设计将会很方便。
(2) 输入刷头的高度时要用Up to Surface并选取刷体顶面, 这样能保证刷头与刷体等厚度, 当改变刷体厚度时, 刷头厚度跟着改变, 始终保证两者厚度相等。
6) 创建刷头阵列特征
步骤:Feature→Pattern→选刷头特征→Ref Pattern→Done, 由于已有点的阵列, 此处刷头的阵列用Ref Pattern。
至此电动刷三维零件图已设计完成。只要更改 (Modify) 特征尺寸的大小, 一件新的电动刷零件几分钟就能完成, 及其方便快捷。
要将刷头顶点连成的直线改成曲线或Spline线, 只需重定义Curve线即可。
步骤:Redifine→选取直线特征→选取Section重定义→画新的Curve线或Spline线→用几何工具 (Geom Tools) 中Replace命令将新的Curve线取代直线, 切记不能用删除直线再画新的Curve线的方法, 否则子特征刷头也会一同被删除。左图为直线改成Spline线后的三维图。
在系列产品开发设计过程中, 掌握Pro/E软件的应用技巧, 可大大缩短新产品开发周期, 从而加速产品的更新换代, 提高市场竞争能力。
参考文献
机载软件生命周期环境选择概述 篇7
关键词：机载软件,DO-178B,生命周期环境,工具鉴定
民用飞机机载软件在安全性上的严格要求, 使得其除了在功能、性能上的要求之外, 要求其必须在流程和目标上符合DO-178B[1]的规定[2]。DO-178B作为机载软件开发的适航标准, 约束着机载软件开发的开发、验证、配置管理和质量保证等方面。相对于其它行业商用软件的开发过程, 机载软件对于软件生命周期材料的置信度水平有着严格的要求。简言之, 只有达到了DO-178B中的附件中10张表的目标, 才能够判定机载软件产品达到了适航要求, 才有在SOI审查中获取适航当局认可的可能性。
在机载软件项目筹划过程中, 除了要对机载软件开发项目的范围、目标和资源进行统计和估算外, 同样作为机载软件开发的重要基础的是软件生命周期环境的规划和选择。软件生命周期环境是生产高质量软件的重要因素。软件生命周期环境选择不当会对软件质量产生不利影响, 造成项目的风险甚至是项目失败的结局。
软件生命周期环境的核心是开发工具、编译工具和验证工具。工具选择的基本原则是“选择需求开发和限制引入错误机会的设计方法、工具和程序设计语言以及保证能检测到引入错误”的验证方法。除此之外, 工具及其集合可能带来的流程重入, 适航上的要求等也是关键的影响因素。这些考虑可能影响到:生命周期环境的完整性、工具的有效性和效率、工具鉴定工作量、流程与工具的配合等等。本文拟对机载软件生命周期环境的选择考虑因素作出概述, 供机载软件开发时构建软件生命周期环境参考。
一、生命周期环境选择的考虑
1.1开发环境选择的考虑
软件产品依赖于软件开发环境的能力和质量。生命周期环境中的工具是否有其它型号上的适航经历, 是否有软件供应商的可鉴定支持包关系到将来适航是否具有可行性。在供应商的可鉴定支持下, 是否对于该工具有合格使用指南, 且使用方所提交证据的多寡, 也是在工具之间进行选择的考量因素。软件之间是否具备较好的协同和衔接特性, 是否容易与其它工具软件进行搭配和形成完整的生命周期环境。由于工具本身的内因性特点, 有时也会引起软件产品本身的诸多的错误或者隐性缺陷。例如, 某些建模软件在自动生成代码时, 会引入大量的模式代码, 这样就对后期的覆盖率分析带来麻烦, 而有的工具则刻意用C代码实现了面向对象的一些概念, 在软件验证阶段将会带来巨大的麻烦。对于某些带有配置选项的工具, 还要定义一定的使用规则和检查手段, 这也是工具选择时需要注意的。
1.2语言和编译程序考虑
源代码进入编译器进行编译、链接、生成目标码, 目标码翻译为二进制机器码。优化是一个编译的必经环节。未经优化的目标码将是不可能执行的。不同优化等级, 又会在性能和功能之间进行平衡。源代码在编译器中进行优化, 会对目标码的结构、执行顺序等等进行调整, 可能会引起目标码和源代码之间追踪性的丧失。编译器还会在目标码层次上进行必要的代码补充, 例如在中断服务程序执行期间, 会自动关闭中断使能, 在中断服务结束后, 又会自动开启中断使能。那么这些必要的代码可能都无法追溯到源代码。所以在选择编译软件的同时还要考虑如下的方面:
■编译器的优化特性;
■A级软件要求对编译器产生不能追踪到源代码的目标码要进行验证;
■编译选项的更改将引起软覆盖率分析的重入;
编译器的优化性能将使得软件产品在运行效率和空间占用方面产生良好均衡。对于A级软件, 不能追踪到源代码的目标码的验证工作量多寡是考虑因素。任何编译选项的改变都可能对目标码产生影响, 进而引起覆盖率分析结果的变化。
1.3软件测试环境
软件测试阶段除了要完成对代码的静态检查和动态测试, 还有可能对A级软件的目标码进行覆盖率分析。软件测试阶段的工具除了在目标机上直接进行测试, 还有可能对设计阶段的模型进行仿真。依赖于不同模型软件工具的不同, 对仿真工具有不同的要求。由于仿真器和目标机之间的不一致所到影响到的测试结果, 需要在目标机上进行重做。所以仿真器的能力及其与真件的差异需在建立测试环境时予以考虑。
在覆盖率分析阶段, 由于测试用例的补充和覆盖率数据的递增, 应用测试管理工具能够维护有效测试用例的选择效率。
1.4软件工程管理工具
对于软件配置管理中的同行评审和变更管理等要求, 由于变更的范围和影响的差别, 变更的裁定、执行和验证亦需要一定的工具支持, 才能将配置管理计划中定义的流程充分制度化。对于异地协同的团队来说, 支持远程异地协同的配置管理方式也是非常必要的。
对于软件工程管理来说, 为保证软件需求开发、概要设计、详细设计、集成综合、验证确认工作的充分有序进行, 也同时需要相关的工具支持项目的推进。
二、主要工具支撑
软件开发工具的发展促成了软件开发的高速度和高质量。工具的发展从单项工具的开发逐步向集成工具的开发发展。软件开发方法的有效应用也必须得到相应工具的支持, 否则方法将难以有效地实施。工具的完善和发展将促进软件开发方法的进步和完善[3]。根据机载软件项目的典型性, 一般应具备如下的工具支持:
■需求开发工具:需求的开发、追踪、基线维护和评审状态维护;
■架构建模工具:概要设计、架构设计与行为定义;
■设计建模工具:详细设计、低级需求开发;
■代码生成工具:模型代码生成、手工代码融合支持;
■追溯性管理工具:需求、设计、测试追溯性支持;
■静态代码检查工具:源代码编码标准符合性检查;
■动态代码测试工具:功能测试、覆盖率测试;
■编译工具:目标机可执行文件生成;
■可加载格式文件生成工具:机载软件加载格式生成;
■测试管理工具:测试用例、测试脚本、测试结果和测试平台集成;
■配置管理工具:版本管理、基线管理、变更管理;
■项目管理工具:项目计划、估算、风险控制、成本合算、质量保证;
■仿真验证工具:半实物仿真、仿真激励。
软件工程环境是全面支持软件开发过程的软件工具集合。对于上述的工具, 有些无需购买专门软件, 在成本和效率的权衡下可配备开源工具。在拥有上述的工具支持下, 最好能够通过脚本或者某一个工具为中心进行工具链的整合, 为开发人员配备一揽子的开发解决方案。
三、工具鉴定的考虑
按照DO-178B的要求, 凡是某项活动因为工具的原因得以取消、减少或者自动进行, 并且输出无需另外验证时, 那么就需要进行工具鉴定。工具鉴定的目标是确保工具提供必须的适航置信度, 这种置信度能够等效于所取消、减少或者自动进行的这些活动所带来的置信度。换言之, 软件开发和验证工具的研制流程和机载软件是类似的。按照工具鉴定的要求确定的工具类型:软件开发工具和软件验证工具, 其中软件开发工具可能会引入错误, 这是因为开发工具的产物会进入产品中。而软件验证工具的产物不会进入产品, 但是却会对错误进行误判或者漏判。在工具鉴定过程中, 若是不能确定工具的类型, 则需按照开发工具进行鉴定。显然, 软件开发工具的鉴定更加严格和复杂。同时, DO-178B也规定, 进行工具鉴定的工具研发过程亦需遵循软件配置管理过程和软件质量保证过程, 亦需进行工具鉴定。开发工具的鉴定准则包括:DO-178B定义的开发过程目标要在工具的开发过程中进行满足;工具的软件等级原则上等同于所生产软件的等级;申请人要在工具验证阶段验证其输出及工具相关的问题;由于工具软件的系统需求是工具操作需求, 那么工具鉴定自然就取消了诸如对于目标机符合性、可验证性、追踪性的需求。
验证工具的鉴定准则是仅需验证通过正常条件下工具符合工具操作要求的证明来实现即可。
另外, 工具开发过程中, 开发工具要按照CC1类进行配置管理, 而验证工具按照CC2类进行配置管理。
四、结论
机载软件生命周期环境的选择牵涉到开发计划和开发执行, 影响到软件适航审定, 必须对软件工具的工作要求和适航需求进行综合考虑, 才能够支撑机载软件全生命周期任务的顺利完成。
参考文献
[1]DO-178B.Software Considerations in Airborne Systems and Equipment Certification[S].RTCA/EUROCAE, 1992.
[2]岳庆敏.软件适航认证与DO-178B, 航空制造技术[J].北京旋极信息技术股份有限公司, 2011.
软件开发周期 篇8
1 功能要求
系统要能够存储设备的历史检修时间、周期数据，并自动生成下一次设备检修计划;具备与其他应用软件交互的功能，可导入外部的数据文件，并导出系统内的各种数据;还要能够提供各类查询、汇总等高级应用功能。
系统应为B/S结构，操作人员通过浏览器登录系统进行操作，以减少使用人员软件安装、维护的工作量。系统至少要包含设备台账管理、设备周期管理、储备计划管理、检修计划管理、检修历史管理及查询交互六大功能。
设备台账管理功能主要管理设备台账信息。系统以设备为单元编制检修计划。
设备周期管理功能主要管理设备的周期信息。设备周期分为单一周期及可变周期两类。单一周期为设备预防性试验、大修及改造的周期。可变周期为设备进行状态检修时所采用的各种周期。
储备计划管理功能主要用于编排下一轮检修计划。此计划汇总了所有纳入周期管理的设备下一轮进行的检修计划。储备计划按年度分摊，全部计划执行完成后，再由系统生成下一轮储备计划。
检修计划管理功能主要管理当前年度进行的检修计划，其来自储备计划中当前年度需实施的计划。年度计划分摊到季度、月度计划，并最后细分到周计划进行实施。此项功能管理计划的生成、下达、变更及实施情况。
检修历史管理功能主要管理设备的历史检修情况。设备的初始历史检修数据由外部导入。经由系统管理检修计划后，系统根据使用人员填报的完成情况更新设备历史检修数据。
查询交互功能主要用于系统使用人员对设备历史检修情况、未来的检修计划进行各种查询、汇总、导入、导出。
2 系统设计思路
系统通过设备周期、历史检修时间累加生成设备的下一轮检修计划，并汇总其他方面要求的计划，逐步分解，最后以周计划为单位实施，并记录计划的执行情况。依此流程，周而复始进行周期管理。
3 系统设计原则
简化输入原则。系统中需要的数据可以一次输入、共享使用。无法由系统生成的数据由使用人员输入，可以由系统生成的数据不需人工输入。同样的数据，使用人员只需输入一次，不需重复输入。同时，向系统输入的数据以导入为主，手工修改为辅。凡需导入数据的，均提供Excel导入功能。
友好交互原则。系统使用界面友好，操作简单，提供各种查询、汇总功能，方便使用人员查询，并可导出系统内生成的各种数据。
自动优化原则。系统应能根据事先设定的原则，进行设备检修计划优化。
4 系统业务流程
总体流程分为导入设备周期、导入设备台账、导入检修历史、生成检修计划、生成储备计划、生成年度计划、生成季度计划、生成月度计划、生成周计划、填写完成情况等10个环节。
导入设备周期、导入设备台账、导入检修历史3个环节为系统初次使用时进行的初始化工作。后7个环节用于实现周期管理。
生成检修计划环节主要生成年度、季度、月度及周计划。生成年度、季度、月度检修计划的流程包含编制、下达及变更三步。周计划的管理流程在此基础上再增加实施步骤。
(1）计划编制：
首先汇总储备计划中当前年度的检修计划，生成年度计划，再由使用人员调整定稿。依此类推，生成季度、月度及周计划。
(2）计划下达：
检修计划无误后，即予以下达。计划一经下达后，便不能再进行修改。实施过程中需要调整时，可通过计划变更进行。
(3）计划变更：
用于调整实际计划的执行。计划变更主要为新增、延期、取消三类。
计划新增是指在已下达的计划中新增内容。如果新增系统中有的计划，可以在系统中选择。系统中没有的计划，可以通过导入或手工进行填报。
对于延期的计划，如果可以确定延期时间的，直接填报新的计划时间。无法确定的，则不予安排，供编制后续计划时选择。
对于取消的计划，直接填写相关信息后即可取消。只有确认不再进行的计划，才可取消。如果已知后续仍将进行的，应进行延期。
(4）计划实施：
检修计划以周计划为单位实施。使用人员定期在系统内填写实施情况。内容分完成(按计划执行的)、延期及取消三种。系统将计划完成的时间作为检修历史数据进行记录。
5 系统数据库结构
后台数据库总共包含8个数据表，具体为：
设备台账表：记录所有纳入设备周期管理的设备台账。
设备周期表：记录设备的类别及对应的周期。其包含了设备的预试(含状态检修)、大修及技改周期。
专项计划表：记录由于各类管理要求产生的检修计划。主要记录设备的消缺、反事故技术措施及培训计划。
储备计划表：储备计划包含周期检修计划、专项计划。
检修计划表：用于记录已列入当年的检修计划。其内容为储备计划中检修期为当年的所有检修计划。
检修历史表：用于记录计划的实施情况。
延期表：记录检修计划中延期、取消的计划及相关原因。
缩短模具开发周期的方法研究 篇9
1 模具开发的项目管理实施方法
项目管理是一种为了在确定的时间范围内, 完成一个既定的项目, 通过一定的方式合理地组织有关人员, 并有效地管理项目中的所有资源 (人员、设备等) 与数据, 控制项目进度的系统管理方法。
模具厂有冲模工程部与塑模工程部。冲模工程部管辖四个项目组, 塑模工程部为三个。模具任务分配方式以竞标为主, 必要时协商分配。每个项目组设有一个项目经理、约两个设计员、四个工艺师和四个左右的钳工, 工艺师包括模具制造工艺与数据编程人员。而其它的各种生产设备及操作员的调度由生产部的调度员统筹安排。如果项目组之间有资源需求的冲突而调度员不能解决时由厂领导仲裁。
厂内员工可通过竞职方式担任项目经理, 选拔项目经理有三项标准: (1) 了解模具开发的所有工序内容; (2) 熟悉模具开发过程中的常见问题及解决方法; (3) 有较强的判断和决策能力, 善于管理和用人。
项目管理的内容之一就是要确定项目经理应担负的职责。本厂项目经理的职责有: (1) 负责组织项目组在厂内竞标、承接新项目; (2) 负责与客户交涉, 包括确定产品细节、接受客户修改产品设计的要求、反映需要与客户协商才能解决的问题; (3) 检查产品的工艺性, 如果产品工艺性存在问题, 则向客户反馈; (4) 制定具体的项目进度计划; (5) 负责对承接项目的全过程、全方位的质量控制、进度跟踪及内外协调工作; (6) 负责完成组内评审及对重大方案、特殊结构、特殊用途的模具的会审; (7) 负责组内成员的工作分配、培训及考核; (8) 对组内成员的过失行为负责; (9) 负责在组内开展 “四新”技术的应用与技术攻关项目的立项、组织、实施等各项工作; (10) 及时解决新模具在维修期内的各项整改及维修。
厂领导根据项目完成的时间、质量与成本考核项目经理。然后由项目经理考核项目组内员工, 使责、权、利落实到每一位员工, 有效调动了员工积极性并显著减少以前反复出现的问题。
2 模具开发的并行工程实施方案
并行工程是缩短产品开发周期、提高质量与降低成本的有效方法。实施并行工程有助于提高产品设计、制造、装配等多个环节的质量。并行工程的核心是面向制造与装配的设计 (DFMA) [1]。在模具开发中实施并行工程就是要进行产品及模具的可制造性与可装配性检查。
DFMA工具的开发是并行工程的工作重点之一。在以往的DFMA方法研究与系统实现中[1], DFMA工具被动地对CAD输出的产品特征进行评价, 而不能在CAD系统产生具体产品特征前即在概念设计阶段加以指导, 使CAD系统要经过多次设计―检查―再设计循环才能求得满意解。通过对产品与模具的可制造性与可装配性的检查, 就从源头消除了后续工序可能遇到的困难, 大大减少出现缺陷和返工的可能性。
3 模具的模块化设计方法与系统研究
缩短设计周期并提高设计质量是缩短整个模具开发周期的关键之一。模块化设计就是利用产品零部件在结构及功能上的相似性, 而实现产品的标准化与组合化。大量实践表明, 模块化设计能有效减少产品设计时间并提高设计质量。因此本文探索在模具设计中运用模块化设计方法。
3.1 模具模块化设计的特点
模具的零部件在结构或功能上具有一定的相似性, 因而有采用模块化设计方法的条件, 但目前模具设计中应用模块化设计方法的研究报道还很少见。与其它种类的机械产品相比, 模具的模块化有几项明显特点。
3.1.1 模具零件的空间交错问题
模具零件在三维空间上相互交错, 因此难于保证模块组合后没有发生空间干涉;难于清晰地进行模块划分。
笔者采取以下办法来克服这个问题: (1) 利用Pro/E (或UGII等三维软件) 的虚拟装配功能检测干涉; (2) 按结构与功能划分相结合。模块划分就是部件划分并抽取共性过程。结构相对独立的部件按结构进行划分, 设计出所谓的结构模块;而在空间上离散或结构变化大的部件则按功能划分, 设计出所谓的功能模块。这样划分并进行相应的程序开发后, 结构模块的结构可由结构参数为主, 功能参数为辅简单求得;而对于功能模块, 可由功能参数为主, 结构参数为辅出发进行推理, 在多种多样的结构形式中做出抉择。
3.1.2 凸凹模及某些零部件外形无法预见
某些模具零件 (如凸凹模) 的形状和尺寸由产品决定因而无法在模块设计时预见到, 所以只能按常见形状设计模块 (如圆形或矩形的冲头) , 适用面窄;某些模具零件 (如冲压模的工件定位零件) 虽然互相配合执行某一功能, 但它们的空间布置难寻规律与共性, 因此即使按功能划分也不能产生模块。
3.2 模具模块化设计的实施
为了实施模块化设计, 并证明以上方法的可行性, 笔者基于Pro/E二次开发, 开发出一套模具模块化CAD系统。系统分两大部分:模块库与模块库管理系统。
3.2.1 模块库的建立
模块库的建立有三个步骤:模块划分、构造特征模型和用户自定义特征的生成。标准零件是模块的特例, 存在于模块库中。标准零件的定义只需进行后两步骤。
模块划分是模块化设计的第一步。模块划分是否合理, 直接影响模块化系统的功能、性能和成本[3]。每一类产品的模块划分都必须经过技术调研并反复论证才能得出划分结果。
模块设计完成后, 在Pro/E的零件/装配 (Part/Assembly) 空间中手工建构所需模块的特征模型, 运用Pro/E的用户自定义特征功能, 定义模块的两项可变参数:可变尺寸与装配关系, 形成用户自定义特征 (User-Defined Features, UDFs) 。生成用户自定义特征文件 (以gph为后缀的文件) 后按分组技术取名存储, 即完成模块库的建立。
3.2.2 模块库管理系统开发
系统通过两次推理, 结构选择推理与模块的自动建模, 实现模块的确定。第一次推理得到模块的大致结构, 第二次推理最终确定模块的所有参数。通过这种途径实现模块“可塑性”目标。
在结构选择推理中, 系统接受用户输入的模块名称、模块的功能参数和结构参数, 进行推理, 在模块库中求得适用模块的名称。如果不满意该结果, 用户可指定模块名称。在这一步所得到的模块仍是不确定的, 它缺少尺寸参数、精度、材料特征及装配关系的定义。
在自动建模推理中, 系统利用输入的尺寸参数、精度特征、材料特征与装配关系定义, 驱动用户自定义特征模型, 动态地、自动地将模块特征模型构造出来并自动装配。自动建模函数运用C语言与Pro/E的二次开发工具Pro/TOOLKIT开发而成。UDFs的生成方法及参数驱动实现自动建模的程序见参考文献[4]。
4 总结
由于采取了上述措施, 靖远煤业集团公司机械制修厂某一新品种空调的模具从设计到验收只需三个月就完成了, 按可比工作量计算, 开发周期比以前缩短了约1/4, 而且模具质量和成本都有所改善, 明显增强企业竞争力。
摘要：介绍了靖远煤业集团公司机械制修厂模具实施项目管理与并行工程的经验, 论述了模块化设计方法在模具设计中应用的特点, 研究了模具模块化CAD系统的开发技术。
关键词：模具,开发周期,CAD系统
参考文献
[1]王知衍译.面向制造与装配的产品设计.北京:机械工业出版社, 1999.
[2]张林宣, 童秉枢, 王春河, 等.一种实用的综合集成DFA系统的研究.清华大学学报 (自然科学版) , 1998, 38 (11) :69-72.
[3]姜慧.机械产品模块划分方法的研究.制造技术与机床, 1999, (3) :7-9.
软件开发周期 篇10
软件工程监理是指依法设立且具备相应资质的工程监理单位, 它受业主单位的委托, 依据国家的有关法律法规、技术标准和信息系统工程监理合同, 对信息系统工程项目实施监督管理。目前, 我国软件工程监理处还处在刚刚起步的阶段, 相关的标准和规范还比较缺乏。在软件工程监理关系中, 业主 (建设单位) 授予监理方对项目的管理和控制权力, 监理单位代表业主从事项目管理活动。一些监理公司依据有关的信息技术规范和软件工程项目合同规定, 凭借着自己的行业经验进行监理工作, 但对软件项目监理的操作比较零散, 难以形成1个系统的监理评估体系。本文, 笔者在仔细的研究分析软件工程特点的基础上, 论证了业主和软件工程承包商之间增加监理的必要性, 建立了软件工程监理量化评估模型。
二、软件工程监理在软件工程生命周期中各个阶段的作用
1. 软件工程的全生命期。
根据ISO的相关定义, 软件工程的全生命期分为实施阶段、使用阶段和维护阶段, 其中实施阶段又可进一步地细分为准备、设计和施工。结合我国的实际情况, 软件工程的生命周期有4个阶段。第1个阶段是“诞生”阶段。第2个阶段系统进入决策阶段, 一旦系统通过决策, 系统就进入第2个阶段。第2阶段即设计阶段, 在该阶段抽象出系统模型。第3个阶段是实施阶段, 即系统投入开发和施工阶段。第4个阶段是运营维护阶段, 即系统投入运行的阶段。
2. 软件工程监理在软件工程的全生命期中的作用。
软件工程监理是软件工程领域的一种质量管控方式, 是独立于甲、乙双方的第三方机构。它为软件工程提供的规划与组织、协调与沟通、控制与管理、监督与评价等方面的服务, 其目的是利用监理单位的经验和专业技术保证软件工程的成功。软件工程监理应该在软件工程的设计阶段之后所有的阶段进行相应的监理, 以反映软件工程在过程中的实际情况。软件工程的全生命期监理如图1所示。
三、软件工程监理评估模型
1. 软件工程监理评估维度模型的建立。
信息化工程监理的目标是实现利益。在软件工程监理评估过程中, 业主和软件工程承包商签订合同后, 就形成了二元关系。监理的作用是可以减缓双方当事人的不对称压力。因此, 第三方监理的出现是必然的。监理方、业主和开发方形成了三元组织关系。软件工程监理虽然增加了项目的成本, 但是从长远的角度来看, 监理的存在提高了项目成功的几率, 降低了社会净资产的流失。监理规范的管理方法、手段和流程, 保证了项目的质量, 降低了项目维护费用。软件工程监理的目标是:在一定的时间和成本范围内, 软件项目达到了质量规定的要求。软件工程监理评估维度模型如图2所示。
2. 软件工程监理评估。
在软件工程监理过程中, 需要进行不断的评估, 因此, 需要通过数据分析的方式, 量化最终的结果。软件工程监理是典型的外包工程, 其评估模型公式如下:
其中, SSE代表软件工程监理评估质量。C1代表在第1个里程碑时, 费用花费了多少。CD1代表在第1个里程碑时, 预算花费了多少。CD2代表在第2个里程碑时, 费用花费了多少。C2代表在第2个里程碑时, 预算花费的数值。根据项目的里程碑数量一直累加到的第i个里程碑时的情况, 表示当前计算到的里程碑。在软件工程项目中, 呈现的趋势是越来越多的项目需要有工程中的权重因子, 也就是说在不同的里程碑中, 其关心对象的重要程度是不同的。软件工程项目中权重影响因素如图3所示。
下面, 给出软件工程监理评估模型的第2个量化计算公式:
目前, 我国的软件工程项目建设风险较大, 建设市场还需要进一步地规范。为了减少软件工程建设的风险, 规范软件工程建设市场, 保证业主和承建单位双方的利益, 对软件工程建设进行有组织、规范化的监理评估就显得尤为迫切和重要。
四、软件工程监理的必要性和发展趋势
软件工程技术在最近10年取得了飞速的发展, 如今在各行各业纷纷投入了大量的资金进行信息化建设, 工业自动化控制系统、企业ERP系统、数字化校园系统等软件工程项目在不断地涌现, 但是, 由于软件工程监理的起源、发展以及相关的法规制度还不是很完备, 对于软件工程的监理远远不能和成熟的建筑工程监理相比, 所以, 今后软件工程监理的发展还有很大的空间, 在软件工程项目中, 软件工程监理将会起到越来越重要的作用。软件工程监理的发展趋势如图4所示。
1. 规范有序的竞争机制。
目前, 国内的软件工程监理市场比较混乱, 企业间的竞争在很大程度上是依靠关系的竞争和价格的竞争, 大量监管单位为了承揽业务而竞相压价, 甚至采取给回扣和好处费等不正当手段来争取客户, 这是由于国内软件工程监管市场还不是很规范, 有关部门应该规范监理企业间的竞争, 逐步改善不规范竞争的情况, 形成规范有序的竞争机制。
2. 行业技术创新能力差。
信息项目监理虽然经过近10年的努力, 至今仍然面临着实践方面的困难, 还不能很好地将国内外先进的经验和中国的具体情况相结合, 与欧美国家的大型监理企业相比, 在监理整体思想和基础理论等方面都存在相当大的差距。
3. 信息监理企业规范化。
很多信息项目监理单位本身的制度都不健全, 管理松散, 只关心利润, 不重视技术和服务, 使得项目的监理质量低下, 监理企业规范化程度参差不齐, 监理企业规模偏小, 资本不够雄厚, 很难和国内外大企业直接竞争, 所以, 监理企业规范化程度不高的现状必须进行改进。
4. 信息项目监理企业规模扩大。
当前的软件监理单位, 其规模都不大, 从业人员的经验和水平相对较低, 很多监理公司为了降低成本, 往往是接到项目之后, 才进行监理人员的聘用, 这就造成了监理项目质量的不稳定, 因此, 需要扩大软件信息项目监理企业的规模, 以促进整个行业水平的提高。
5. 信息项目监理费用偏低。