（计算机应用技术专业论文）面向中小型企业应用开发的软件过程研究与实现.pdf

摘要 摘要 随着对软件需求的快速发展，如何提高软件生产过程的效能，以便能更快、 更省的交付高质量的软件产品，越来越成为软件开发突出的问题。近年来国内 对中小型企业应用系统需求的快速增长，越发加剧了这个矛盾。拥有良好的软 件过程成为解决这一问题的关键因素。目前大多数企业仍在沿用瀑布模型，而 瀑布模型对需求变化和需求不明确的不适用导致了诸多软件项目归于失败。虽 然随着面向对象技术的发展，出现了以架构为中心、用例驱动、迭代开发的 r a t i o n a l 统一过程( r i j p ) ，但由于其更适用大型和超大型软件项目，而使得中 小型项目，特别是中小型企业应用软件的开发，无法分享其先进技术特性。 为了解决这一问题，本文提出了一种适用于中小型企业应用开发的软件过 程。本文论述的软件过程，以瀑布模型为基础，将r u p 的三个特性演化融合进 来而成为；瀑布模型为基干，在各阶段内多次迭代从而逼近、达到里程碑，使 用业务驱动和结合应用框架的软件过程。不放弃瀑布模型，从而最大限度的保 护了现有的以瀑布模型为基础的过程资产。为了有效钻取业务需求，本文将开 发周期划分成四个阶段，并在需求定义和基本设计阶段内分别进行迭代，从而 有效规避了需求变化和不明确的风险。在需求分析和定义的手法上，本文将需 求划为三个层次、使用由粗到细的分析方法来建立需求模型。针对企业应用的 具体特点，本文放弃了使用“用例图”的方法，而是提出了用“活动图”定义 业务的方法，并运用模型转化的观点，以之作为最初的业务模型来驱动整个软 件开发的进行。为了能将需求定义和基本设计阶段的面向数据分析衔接到详细 设计阶段的面向对象设计上，本文提出了结合“应用框架”的方法，从而将数 据分析套在了对象( 类) 设计上。作为软件过程的一个重要外延，本文亦指出 了应用框架的设计目标，并以n e t 平台为例给出了应用框架详细的机能定义。 通过运用到一个实际的软件开发项目p m s 之后，我们和其他项目的每千行 代码的b u g 数进行比对，结果表明，本过程有效的提高了软件制品的质量，特 别是在控制严重错误和需求理解偏差方面有明显的表现。 因此本过程能提高中小型企业应用开发的制品质量，从而提高过程效能。 这符合国内软件开发的现状和需求，具有较好的工程价值。 关键词：软件过程；业务驱动；迭代开发；模型驱动；面向对象；应用框架； c m m a b s t r a c t a b s t r a c t w i t ht h er a p i dd e v e l o p m e n to ft h es o l t w a r er e q u i r e m e n t s h o wt oi m p r o v et h e e f f i c i e n c yo ft h es o r w a r ed e v e l o p m e n tp r o c e s sa n dh o w t od e l i v e rb e t t e rs o r w a r e p r o d u c t i sb e c o m i n gah o ti s s u e i nt h ed o m e s t i c ，t h er a p i dg r o w t ho ft h er e q u i r e m e n t f o rr e e d i u m s m a l lb u s i n e s sa p p l i c a t i o ns y s t e mm a k e st h i si s s u ee v e nm o r ei m p o r t a n t o n eo ft h ek e yp o i n t sf o rs o l v i n gt h i sp r o b l e mi su s i n gag o o ds o f t w a r ep r o c e s s w a t e r f a l lm o d u l eh a sb e e nu s e di nm a j o r i t yb u s i n e s sa tp r e s e n t , b u ti t su n c e r c a i n w a n da m b i g u i t yi nt h er e q u i r e m e n tp h a s el e a d st oal o to fp r o j e c t s f a i l u r e r u pr i s e s u pw i t ht h ed e v e l o p m e n t o fo b j e c to r i e n t e dt e c h n o l o g y , b u ti ts u i t sl a r g ep r o j e c tb e t t e r , s of o rm e d i u m s m a l lp r o j e c t ，i t sa d v a n t a g ec a n tb et a k e n i no r d e rt os o l v et h ep r o b l e mm e n t i o n e da b o v e ，t h i sp a p e rp u t sf o r w a r da s o f t w a r ep r o c e s sw h i c hs u i t st h em e d i u m s m a l lb u s i n e s sa p p l i c a t i o nd e v e l o p m e n t t h i ss o r w a r ep r o c e s sh a sf c a t u r e sl i k eb a s i n go nw a t e r f a l lm o d u l e m a k i n gs e v e r a i i t e r a t i o n si ne a c hp h a s e ，u s i n gb u s i n e s sd r i v e nm o d u l ea n dc o m b i n i n ga p p l i c a t i o n f r a m e w o r k n o ta b a n d o n i n gw a t e r f a l im o d u l ec a nt a k ei t se x i s t i n ga f f l u e n ta s s e t s f o r g e t t i n gc l e a r e rb u s i n e s sr e q u i r e m e n t ，t h ep a p e rd i v i d e st h ew a t e r f a l lm o d u l ei n t of o u r p h a s e sa n dm a k e ss e v e r a li t e r a t i o n sd u r i n gr e q u i r e m e n t d e f i n ep e r i o da n db a s i c d e s i g np e r i o ds e p a r a t e l y , s ot h er i s ko fr e q u i r e m e n t su n c e r t a i n t ya n da m b i g u i t yi s d i s s o l v e d i nr e q u i r e m e n tp h a s e ，t h ep a p e rp u t si ti n t ot h r e el a y e r st h e nu s e st h e m e t h o do f f r o mr o u g ht or e d e dt ob u i l dr e q u i r e m e n tm o d u l e a i m i n ga tt h es p e c i a l t y o fb u s i n e s sa p p l i c a t i o n ，t h i sp a p e rp u t sf o r w a r dam e t h o do fd e f i n i n gb u s i n e s sw i t h a c t i v i t yd i a g r a mi n s t e a do fu s ec a s ed i a g r a ma n dac o n c e p t i o no fm o d u l ec o n v e r s i o n t od r i v es o f t w a r ed e v e l o p m e n t i no r d e rt oj o i nd a t ao r i e n t e da n a l y s i sw i t ho b j e c t o r i e n t e dd e s i g n ，t h i sp a p e rb r i n g sf o r w a r dt h ei d e ao fc o m b i n gw i t ha p p l i c a t i o n f r a m e w o r k t h i sp r o c e s sh a sb e e na p p l i e dt oar e a ls o f t w a r ep r o j e c tp m s ，c o m p a r i n gw i t h o t h e rp r o j e c t sb yb u g ，t h es t a t i s t i cd a t as h o w st h a tt h i sp r o c e s sr e a l l yi m p r o v e st h e a r t i c l eq u a l i t y , e s p e c i a l l yi nt h ep a r to f e r r o rc o n t r o la n dr e q u i r e m e n tu n d e r s t a n d i n g t os u mu p ，t h i sp r o c e s sc a l li m p r o v et h ep r o d u c tq u a l i t ya n de f f i c i e n c yi nt h e m e d i u m s i n a i lb u s i n e s sa p p l i c a t i o nd e v e l o p m e n t ，w h i c hr e a c ht h er e q u i r e m e n to f s o f t w a r ed e v e l o p m e n ti nd o m e s t i c t h i sp r o j e c th a sap r e f e r a b l ee n g i n e e r i n gv a l u e k e yw o r d s ：s o f t w a r ep r o c e s s ；i t e r a t i o nd e v e l o p m e n t ；m o d e l d r i v e nd e v e l o p m e n t ； o b j e c t - o r i e n t e d ；a p p l i c a t i o nf r a m e w o r k ；c m m 图目录 图目录 图1 1m s f 小组模型4 图1 - 2m s f 过程模型5 图2 1 生命周期模型转化图l o 图2 2 过程适用对象示意图1 1 图2 - 3 瀑布模型生命周期图1 2 图2 - 4r u p 生命周期图1 5 图2 5r u p 建立的上下文1 7 图2 6r u p 线性步骤2 0 图2 7r u p 连续步骤2 1 图2 8r u p 迭代步骤2 2 图2 - 9r u p 的动态特性2 3 图3 1 瀑布迭代型生命周期示意图3 2 图3 - 2 功能性需求分析u m l 。3 5 图3 3 非功能性需求分析u m l 图3 5 图3 - 4 界面及数据设计u m l 图4 2 图3 5 运用设计u m l 图4 2 图3 - 6 详细设计u m l 图5 l 图3 7 编码测试u m l 图5 3 图4 1 过程和框架关系图5 5 图5 1 需求定义阶段各次迭代工数合计柱图6 6 图5 2 基本设计阶段各次迭代工数合计柱图6 6 图5 3b u g 数比对柱图6 7 v i 表目录 表目录 表格3 1 需求定义阶段成果物一览表3 6 表格3 - 2 基本设计阶段成果物一览表4 2 表格3 3 详细定义阶段成果物一览表5 1 表格3 4 编码测试阶段成果物一览表5 3 表格4 1 应用框架分层要求一览表5 6 表格4 - 2 应用框架数据库支持一览表5 6 表格4 3 应用框架数据绑定利用要求一览表5 6 表格4 - 4 应用框架数据校验要求一览表5 7 表格4 5 应用框架界面模式要求一览表5 7 表格4 - 6 应用框架消息显示要求一览表5 7 表格4 7 应用框架出错处理要求一览表5 8 表格4 8 应用框架报表支持要求一览表5 8 表格4 - 9 应用框架数据导入要求一览表5 8 表格4 1 0 应用框架数据导出要求一览表。5 9 表格4 1 1 应用框架安全性要求一览表5 9 表格4 1 2 应用框架异常处理要求一览表5 9 表格4 1 3 应用框架用户权限管理要求一览表5 9 表格4 1 4 应用框架主数据管理要求一览表6 0 表格4 1 5 应用框架邮件要求一览表6 0 表格4 1 6 应用框架批处理要求一览表一6 0 表格4 1 7 应用框架系统日志要求一览表6 0 表格4 1 8 应用框架工作流要求一览表。6 1 表格4 1 9 应用框架工具辅助要求一览表6 1 表格5 1p m s 项目需求定义阶段w b s 表6 3 表格5 - 2p m s 项目基本设计阶段w b s 表6 4 表格5 3 各次迭代工数统计表6 5 表格5 - 4b u g 数比对表6 7 i x 第一章绪论 第一章绪论 1 1 研究背景及内容 目前，软件的趋势是朝着更庞大、更复杂和更多样化的系统在发展。特别 是在企业应用领域，随着计算机的性能逐年增强，价格逐年走低，企业利用计 算机系统提高生产效率、降低运营管理成本的期望也随之增大。同时，这种趋 势也受到用于信息交流的i n t e r a c t 用途扩展的影响，从纯文本到格式化的文本， 到图片，到图标，到多媒体。随着对一种软件产品及其在某些方面可能有所提 高的后续版本的了解，软件厂商( 开发商) 对更为复杂的软件系统的渴望也在 增加。人们希望软件能够更好的满足需求，但这使得软件变得更加复杂。 而同时，用户对软件交付周期缩短的期望也随着对软件功能增强的期望一 同提高。对于市场而言，谁能够在更短的时间内交付满足客户需要的软件产品， 谁就更能够赢得市场竞争的胜利。 然而，要实现上述彼此制约的两个目标，具有相当大的难度。如今多数的 开发人员、软件公司仍然沿用着3 0 年前的方法来开发软件系统，这样开发软件 的过程不能满足尽可能快地开发功能更强大、更复杂的软件系统的需求。这就 是问题的根本所在。在这样的行业背景下，改进开发方法和过程，使之更适合 市场的需要，便变得更具有工程和市场的双重价值。 本文的研究着眼于国内软件产业主要以中小型的公司为主体、中小型的软 件项目占据巨大份额的现实，力求通过对既有软件过程( 即瀑布模型) 的优缺 点分析，以及对先进方法( 即r u p ) 的分析，融合创新，设计和定义一种面向 中小型企业应用开发的更有效的软件过程，达到提高软件制品质量的目的，从 而提高软件过程的效能。 1 2 国内外研究现状 软件过程的工程性很强，近年来以大量的工程实践为基础，业界进行了很 好的理论概括和总结，出现了很多富有代表性的工业产品，诸如i b m 的统一过 程r u p 、m i c r o s o f t 的m s f 、以及c m us e i 的c m m 。 1 2 1i b mr a t i o n a l 统一过程 u m l 是现今最为成熟的软件建模技术和语言。但u m l 的三位创始人在创 建u m l 的开始阶段，就开始认识到软件开发除了需要建模技术和语言之外， 第一章绪论 还需要一个更高层次，能够指导软件开发人员进行开发活动的开发过程方法学。 u m l 三友之一i v a rj a c o b s o n 在加入r a t i o n a l 之前，致力于开发能用于软件开 发活动的软件过程，这就是其过程产品o b j e c t o r y 。o b j e c t o r y 过程在被r a t i o n a l 收购之后，得到了进一步的发展，被命名为r a t i o n a lo b j e c tp r o c e s s ( r o p ) 。同 u m l 一样，在这个发展过程中也融入了其他优秀软件过程的精髓。1 9 9 8 年， r o p 被正式命名为r a t i o n a lu n i f i e dp r o c e s s ( r i j p ，r a t i o n a l 统一过程) ，并且 将u m l 作为其建模语言。由此r a t i o n a l 统一过程成为了业界最为成熟和成功 的软件开发过程【i 】。 定义并采用可复用的软件开发过程是软件开发成功的关键因素，这个过程 必须具备高效率、低返工和解决冲突等特点。r a t i o n a l 统一过程( r u p ) 为这样 的过程提供了一个框架，其关键组件能够表达和包含任何软件过程，能够准确 的描述在什么时候、应该由谁、进行什么样的开发活动、产生什么样的结果， 以确保按时提交高品质的软件产品；r u p 采用二维结构进行描述，时间维相关 的概念有阶段、迭代、里程碑等，内容维相关概念有工作流、角色、活动、工 件等；作为业界广泛使用的软件开发过程标准，r u p 可以精准、全面的定义整 个软件开发过程，每个角色完成指定的活动、每个活动产生合格的工件、每个 工件拥有相关的指南、模板和检查点。 r u p 发展到今天已经相当的完备，而且i b m 收购r a t i o n a l 后又进一步推动 了r u p 的裁剪特性，以便能够更好的适应各种软件项目的多样性。但是，由于 r u p 过于庞重，更适合开发周期在以年为单位的软件项目上。m m 公司也在致 力于将p u p 小型化，不过由于其先天的特征，r u p 的优势在面向中小型的软件 项目时，恰恰变成了弱势。 实际上，业界也进行了很多尝试，将r u p 经过剪裁以适应小型的应用。但 其2 个根本性问题，无法通过剪裁加以克服： l 、r u p 是彻底的面向对象方法学的产物，而面向对象的分析在面对小型应 用时，远没有面向数据( 过程) 的分析和设计方法来的快速、有效率。面向对 象更适合大型复杂系统的重用构建。而面向数据( 过程) 的方法相比较更直接， 更适合小型系统的快速开发。 2 、尽管其“大周期”的迭代方式使得整个软件开发对于应对需求的变化和 不确定性的能力趋于完美，但由于企业应用更多情况是以“项目”的形式开展， 而非“产品”的形式。这样，大周期的迭代，难以界定一个向客户明确需求规 格的界线，而频繁的变动需求势必引起软件开发项目预算的变更，在实际操作 2 第一章绪论 中，软件开发商难以和客户进行项目金额的调整，这样实际上使得软件开发商 和客户都缺少足够的动力去使用r u p 来作为项目的过程模型。 1 2 2m i c r o s o f ts o l u t i o nf r a m e w o r k m i c r o s o f t 解决方案框架( m s f ) 是一种成熟的、系统的技术项目方法，它基 于一套制定好的原理、模型、准则、概念、指南，以及来自m i c r o s o f t 的、经过 检验的做法。m i c r o s o f t 解决方案框架提供了一个适应性的框架，用于以更快的 速度、更少的人员、更少的风险来成功地交付信息技术解决方案，同时取得更 高质量的结果。m s f 会帮助小组直接解决导致项目失败的大多数常见原因，以 提高成功率、解决方案的质量和业务影响。m s f 就是创建用来处理技术项目和 环境动态特性的，它能够提高项目实施过程中适应持续变化的能力【2 】。 m s f 被叫做框架而不是方法是有特定原因的。和规定性的方法不同，m s f 提供了一个灵活的和可伸缩的框架，其适应能力能够满足任何项目( 不论其规 模和复杂性) 的要求，以规划、构建和部署业务驱动的技术解决方案。m s f 的 观点是，没有哪个单一的结构或者过程能够适应所有项目的环境和要求。尽管 如此，但是它也认为：对指导的需求是存在的。作为一个框架，m s f 就提供了 这样一种指导，而不会强迫实施很多限制性的细节，否则这只会将其用处限制 到有限范围的项目方案里。m s f 组件能够被单独应用或者共同应用，以提高下 列类型项目的成功率： 夺软件开发项目，包括移动、w e b 和电子商务应用程序、w e b 服务、大 型机以及n 层项目等。 夺基础结构部署项目，包括桌面部署、操作系统升级、企业消息传递部署、 配置和操作管理系统部署。 打包的应用程序集成项目，包括个人生产效率套件，企业资源计划 ( e r p ) ，以及企业项目管理解决方案。 夺任何以上项目的复杂组合。 第一章绪论 图1 1 m s f 小组模型 m s f 把重点放在了“人员和过程”的管理以及大多数项目会碰到的技术元 素上。m s f 的一个基础原理是学习所有的经验。这一原理在m s f 过程模型里的 关键里程碑上得到了充分的应用【3 】。 m s f 的核心有八个基础原理： 推动开放式沟通 为共同的前景而工作 赋予小组成员权力 建立清晰的责任和共同的职责 关注交付业务价值 保持灵巧，预测变化 质量投资 学习所有的经验 这些原理共同传达了m s f 观点，构成了一种统一方法的基础，这一方法用 来组织项目所需的人员和过程，以便交付技术解决方案。它们是m s f 结构和应 用的基础。尽管每个原理都已经显示出了自身的优势，但是它们很多都是相互 依存的，因为其中任何一个的应用都对另一个的成功起到了支持作用。在依次 应用的时候，它们建立了一个稳固的基础，使得m s f 能够很好地适用于规模、 复杂程度和类型都不相同的多种项目。 每个项目都要经过一个生命周期，这是一个包含项目里所有活动的过程， 而这些活动的发生要到项目结束并过渡到操作状态才会结束。生命周期模型的 主要功能是建立活动进行的顺序。正确的生命周期模型能够简化项目，并帮助 确保每一个步骤都会让项目更加接近成功。如图l - 2 。 4 第一章绪论 图1 - 2 m s f 过程模型 与其说m s f 是一个软件过程，更不如说它是一个技术框架，尽管它包含的 内容远超过了框架。但是，正如上文所叙述的，m s f 的着眼点并不是向r u p 那 样提供一个大而全的软件过程或者开发方法学，其更多的是让软件开发商从 m i c r o s o f t 的经验中共同分享。它的通用特征意味着在任何规模的软件开发上， m s f 都是可适用的，也就意味着在任何规模上，都不具有明显的优势。另外， 对于软件需求的变化和不确定，m s f 实际上予以了回避。 l - 2 3s e i 的c m m 1 9 8 7 年美国c a r n e g i em e l l o n 大学软件工程研究所( c m u s e i ) 以 w s h u m p h r e y 为首的研究组发表了c m m p s p t s p 技术，为软件管理工程开辟 了一条新的途经。c m m ( c a p a b i l i t ym a t u r i t ym o d e l 能力成熟度模型) 的本质是软 件管理工程的一个部分。它是对于软件组织在定义、实现、度量、控制和改善 其软件过程的进程中各个发展阶段的描述。他通过5 个不断进化的层次来评定 软件生产的历史与现状。软件管理工程的发展，在经历了从7 0 年代开始以结构 化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化 生产时代，到9 0 年代中期，以c m m 模型的成熟模型和日益为市场接受为标志， 已经进入以过程成熟模型c m m 、个体软件过程p s p 和群组软件过程t s p 为标 志的以过程为中心的时代，而软件发展第三个时代，及软件工业化生产时代， 从9 0 年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础， 已经渐露端倪，软件生产转向以改善软件过程为中心，是世界各国软件产业或 迟或早都要走的道路【4 】。 软件过程改善是当前软件管理工程的核心问题。5 0 多年来计算事业的发展 使人们认识到要高效率、高质量和低成本地开发软件，必须改善软件生产过程。 软件管理工程走过了一条从7 0 年代开始以结构化分析与设计、结构化评审、结 构化程序设计以及结构化测试到9 0 年代中期以过程成熟模型c m m 、个体软件 第一章绪论 过程p s p 和群组软件过程t s p 为标志的以过程为中心向着软件过程技术的成熟 和面向对象技术、构件技术的发展为基础的真正软件工业化生产的道路。软件 工业已经或正在经历着“软件过程的成熟化”，并向“软件的工业化”渐进过渡。 规范的软件过程是软件工业化的必要条件。 软件过程研究的是如何将人员、技术和工具等组织起来，通过有效的管理 手段，提高软件生产的效率，保证软件产品的质量。c m m 框架用5 个不断进化 的层次来评定软件生产的历史与现状：其中初始层是混沌的过程，可重复层是 经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件 过程，优化层是能持续改善的软件过程 s l 。任何单位所实施的软件过程，都可能 在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这5 个层次中 的某一个层次。而在某个层次内部，也有成熟程度的区别。在c m m 框架的不同 层次中，需要解决带有不同层次特征的软件过程问题。因此，一个软件开发单 位首先需要了解自己正处于哪一个层次，然后才能够对症下药地针对该层次的 特殊要求解决相关问题，这样才能收到事半功倍的软件过程改善效果。任何软 件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进 化。而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已 经具备的能力还必须得到保持与发扬。 软件产品质量在很大程度上取决于构筑软件时所使用的软件开发和维护过 程的质量。软件过程是人员密集和设计密集的作业过程：若缺乏有素训练，就 难以建立起支持实现成功是软件过程的基础，改进工作亦将难以取得成效。c m m 描述的这个框架正是勾列出从无定规的混沌过程向训练有素的成熟过程演进的 途径。 作为一个过程的框架模型，c m m 无疑是最成功的。但是，它没有给出具体 的过程定义( 当然，这不属于它研究的范畴) 。因此，各个企业可以参照c m m 模型来进行过程的改进，但在具体问题上，比如“如何定义一个面向中小型企 业应用的软件过程”，还是需要另辟蹊径。 1 3 本文组织结构 本文分为六章。 第l 章绪论，介绍了本文的研究背景和国内外研究现状。 第2 章过捏遮让，详细阐述了本过程的设计思想和特点。 第3 章过狸定竖，给出了本过程的具体定义。 第4 章廑用框塞，配合本过程的实际运用，定义了应用框架的基本需求。 6 第一章绪论 第5 章塞践廑用，对本过程的在软件开发项目中的实际运用进行介绍。 第6 章总结与展望，总结论文的研究成果，并对进一步的研究提出建议。 1 4 本文的研究成果 本文完成了面向中小型企业应用开发的软件过程的设计和定义，并给出了 配合该过程的应用框架的机能定义。具体的说，包括以下几个方面。 1 4 1 业务驱动特征的需求分析方法 本过程根据企业应用的特点，使用u m l 活动图来定义业务模型( 而非r u p 的用例图) 。活动图更能表现企业应用中大量的业务流程，而输入、输出活动的 对象，则在模型驱动思想的指导下，从业务实体演变成数据实体、主数据乃至 数据库设计。这种面向数据的分析，比较容易的将业务对象映射到了数据库， 显得直观和直接，特别适用于中小规模的企业应用。在需求定义时，本过程将 业务模型( 活动图) 作为输入，使用用例图分成三个层次逐步分析细化需求。 1 4 2 循环迭代渐进的分析设计过程 本过程没有使用r u p 的大周期迭代，而是将整个生命周期划分成四个阶段： 需求定义、基本设计、详细设计和编码测试，并在各个阶段内，特别是前两个 阶段内进行循环迭代，从而达到明确实现各个里程碑的目的。和瀑布模型相比 较，明显的提高了对需求变化及不明确的适应能力。每次迭代，都是在受控的 情况下进行，具有工数和周期的收敛性，而不会导致项目的失控。 1 4 3 结合应用框架的软件开发过程 以统一、综合的视点看待，本过程将应用框架作为过程的一个重要构成部 件予以考虑。两者相辅相成，构筑了一个有机的整体。结合应用框架的要求， 使得软件过程在详细设计阶段必须紧密考虑既定的应用框架，而应用框架的设 计则必须考虑软件过程在详细设计阶段的步骤方法以及输出。面向数据的分析， 最终要转为面向对象的编程，这个衔接本过程依靠结合应用框架的方法予以了 良好的解决。 1 4 4 给定应用框架的特征需求 鉴于过程和应用框架的紧密联系，本过程给出了配套的应用框架的特征需 求( 机能) 。从使用者的角度，规约了应用框架应当具备的功能的最小集合。应 用框架的实现可以根据制定的特征需求的规格在n e t 平台上予以实现。( 但具体 的实现不属于本文要论述的范畴) 7 第二章过程设计 第二章过程设计 本章给出了过程的设计目标和适用对象，并详细分析了传统的瀑布模型的 优缺点，以及r u p 的优缺点。通过融合c m m ，本过程以瀑布模型为基础，吸 收r u p 的先进特性，形成了自己的鲜明特点。 2 1 设计目标 什么是过程? 过程是为了达到给定目标所实施的一系列步骤，简单的说， 过程就是做什么。软件过程是指软件开发人员开发和维护软件及相关产品( 如 项目计划、设计文档、代码、测试用例和用户手册) 的一套行为、方法、实践 及变换过程嘲。好的过程导致好的结果，这是过程管理的中心思想。 软件过程管理的重要前提是软件产品质量的好坏主要取决于开发和维护该 产品所使用的软件过程质量。有效的软件过程可将人员、工具和方法进行有机 结合。对软件过程的研究、设计、再造、改进的根本目的，是希望得到更好、 更合适的过程( 包括规程、方法、工具) ，从而提高软件制品的质量以及生产效 率。这就是本过程的设计目标。 2 2 设计思想 从设计目标出发，本过程的设计遵循了以下的设计思想的指导。另一方面， 这些设计思想也鲜明的表征了本过程的特点。 l 、将瀑布模型和r u p 的最佳实践融合的视点。 2 、在面向对象技术和面向数据技术之间的平衡和衔接的视点。 3 、解决特定领域特定问题的视点。 4 、将软件开发过程看作模型的依次转换过程的视点。 5 、将软件过程、应用框架和人综合考虑的视点。 以下各小节依次论述各个视点。 2 2 1 融合瀑布和r u p 的视点 尽管瀑布模型有着这样或者那样的缺点，但多年的应用积累了大量基于瀑 布模型的过程资产，完全放弃瀑布转向其他的比如r u p 方法，软件企业似乎难 以痛下决心。加之r u p 并非完美无缺，过于庞大复杂使得企业应用成本过高， 加之彻底的面向对象化，学习成本亦非常可观。因此，本过程寻求在两者之间 取得平衡，一方面充分的利用瀑布模型既有的简洁特点，以及其大量的实践积 第二章过程设计 累，另一方面，针对它的弱点，特别是在需求阶段的问题，利用r u p 的特性给 予充分的弥补。 本过程依然使用瀑布模型的阶段划分，不同之处在于每个阶段内进行适当 的迭代循环，从而确保特别是需求定义的正确。 2 2 2 平衡o o 和d o 的视点 所谓o o ，即面向对象的方法，面向对象( o b j e c to r i e n t e d , o o ) 是当前计算机 界关心的重点，它是9 0 年代软件开发方法的主流。面向对象的概念和应用已超 越了程序设计和软件开发，扩展到很宽的范围。如数据库系统、交互式界面、 应用结构、应用平台、分布式系统、网络管理结构、c a d 技术、人工智能等领 域。 面向对象分析方法( o b j e c t - o r i e n t e d a n a l y s i s ，o o a ) ，是在一个系统的开发 过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。o o a 与结 构化分析有较大的区别。o o a 所强调的是在系统调查资料的基础上，针对0 0 方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分 析。 面向对象设计( o b j e c t o r i e n t e dd e s i g n ，o o d ) 方法是o o 方法中一个中间 过渡环节。其主要作用是对o o a 分析的结果做进一步的规范化整理，以便能够 被o o p 直接接受。面向对象设计( o o d ) 是一种软件设计方法，是一种工程化 规范。这是毫无疑问的。o o d 就是“根据需求决定所需的类、类的操作以及类 之间关联的过程”。o o d 的目标是管理程序内部各部分的相互依赖。为了达到这 个目标，o o d 要求将程序分成块，每个块的规模应该小到可以管理的程度，然 后分别将各个块隐藏在接口( i n t e r f a c e ) 的后面，让它们只通过接口相互交流。 比如说，如果用o o d 的方法来设计一个服务器客户端( c l i e n t s e r v e r ) 应用， 那么服务器和客户端之间不应该有直接的依赖，而是应该让服务器的接口和客 户端的接口相互依赖。这种依赖关系的转换使得系统的各部分具有了可复用性。 如果要复用某一个程序块，只要实现必须的接口就行了。o o d 是一种解决软件 问题的设计范式( p a r a d i g m ) ，一种抽象的范式。使用o o d 这种设计范式，我们 可以用对象( o b j e c t ) 来表现问题领域( p r o b l e md o m a i n ) 的实体，每个对象都 有相应的状态和行为。 d o ，即面向数据( 过程) 的方法，和结构化方法是同样的。传统的观点， 程序就是算法加数据。面向对象是从面向数据、过程的方法上发展起来的。d o 有着简单、清晰的特点，在特定的应用中，仍旧具有比o o 更明显的优势。另外， 9 第二章过程设计 传统的开发方法积累了大量的过程资产如何继续利用，也是应当考虑的。 所以，本过程的设计本着结合两者优势的思想出发，充分发挥两者的专长， 以达到平衡结合。 2 2 3 解决特定问题的视点 本过程不追求设计一个如同瀑布模型或者r u p 那样通用的软件过程，而是 针对特定领域中的特定问题进行研究，通过对瀑布模型和r u p 的“继承”，从实 际出发，灵活融合、运用其他先进的软件工程技术，以提高软件生产的效率、 质量为目标，最终提出解决此特定领域的特定问题的解决方案。 2 2 4 模型依次转化的视点 依照模型驱动设计( m d d ) 的视点，我们将整个软件开发周期，看作是一 系列的模型按照某种规则依次转化，最终变成产品的过程，如图2 - l 。 需 求 模 现型 实 世分 界 业 析 设 务 模 计 问 模 型 模 题 型 、 型 域定 义 模 型 v 实部 现署 模 模 型型 图2 1 生命周期模型转化图 2 3 适用对象 正如“设计思想”和“设计目标”所叙述的，本过程的设计所考虑的并非 是作为一个通用的“一般过程”，而是作为一个解决针对特定领域、特定问题的 “特殊过程”。总的来说，本过程的适用对象是中小规模的企业应用开发。对于 在此之外的其他软件应用开发类型，本过程仍旧具有良好的参考价值。 1 0 第二章过程设计 卜嚣怒等， jl i 1本过程 l 图2 - 2 过程适用对象示意图 而对于大规模的开发类型，由于本过程的精简特征，会导致风险的加大， 另一方面，由于所选取的应用框架的局限，甚至可能导致项目的失败。因此。 从谨慎的态度出发，不建议将本过程运用在大规模的开发类型上。 所谓企业应用( e n t e r p n s e a p p n c 撕0 n ) m ，通常具有以下特征： 夺以数据为中心，通常使用关系数据库 夺具有明显的流程处理特征口1 从规模上考虑，本过程适用中小规模的应用开发，人月数通常在3 吡5 0 0 人 月。 2 4 瀑布模型的沿用 2 4 l 瀑布模型概述 瀑布模型其实并不新，它在1 9 7 0 年前后就已经出现了，但是大部分开发者 对瀑布模型只有一个模糊的概念。从本质来讲，它是一个软件开发过程，通过 一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段 都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返 回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶 段，这也是瀑布开发名称的由来唧。 这一模型存在很多变体，每种只是在阶段名称上略有区别，但是。总体来 第二章过程设计 讲，瀑布开发模型可以分为六个不同的阶段，如图2 3 所示。 图2 - 3 瀑布模型生命周期图 1 需求分析 虽然是第一步，但是这一步至关重要，因为它包含了获取客户需求与定义 的信息，以及对需要解决的问题所能达到的最清晰的描述。分析包含了理解客 户的商业环境与约束，产品必需实现的功能，产品必需达到的性能水平，以及 必需实现兼容的外部系统。 在这一阶段所使用的技术包括采访客户、使用案例和软件特色的“购物清 单”。分析阶段的结果通常是一份正式的需求说明书，这也是下一阶段的起始信 息资料。 2 设计 这一步包括了“定义硬件和软件架构、组件、模块、界面和数据等来满足 指定的需求。”它包括了硬件和软件架构的定义，确定性能和安全参数，设计数 据存储容器和限制，选择集成开发环境( i d e ) 和编程语言，并指定异常处理、 资源管理和界面连接性的策略。 这一阶段还强调了用户接口的设计，包括与浏览和可用性相关的问题，这 一阶段的输出结果是一份或多份设计说明书，这些说明书将在下一阶段使用。 3 实现 这一步包含了根据设计说明书来构建产品，通常，这一阶段是由开发团队 第二章过程设计 来执行的，开发团队包括了程序员、界面设计师和其他的专家，他们使用的工 具包括编译软件、调试软件、解释软件和媒体编辑软件。 这一阶段将生成一个或多个产品组件，它们是根据每一条编码标准而编写 的，并且经过了调试、测试并进行集成以满足系统架构的需求。对于大型开发 团队而言，我建议使用版本控制工具来追踪代码树的变化，这样在出现问题的 时候可以还原以前的版本。 4 测试 在这一阶段，独立的组件和集成后的组件都将进行系统性验证以确保没有 错误并且完全符合第一阶段所制定的需求。一个独立的质量保证小组将定义“测 试实例”来评估产品是完全实现了需求还是只有部分满足。 有三种测试方法可以使用：对独立的代码模块进行单元测试；对集成产品 进行系统测试；以及客户参与的验收测试。如果发现了缺陷，将会对问题进行 记录并向开发团队反馈以进行修正。在这一阶段，还有产品文档会经过准备、 评估并发布，比如用户手册等。 5 安装 在产品通过测试并且被鉴定为符合需求的产品后，就会进入到安装阶段， 这一阶段包括了在客户站点进行系统或产品的安装和使用，这可以通过互联网 或者物理媒介进行，通常交付使用的产品都带有正式的版本号，这为今后的产 品升级提供了便利。 6 维护 这一阶段发生在安装之后，包括了对整个系统或某个组件进行修改以改变 属性或者提升性能，这些修改可能源于客户的需求变化或者系统使用中没有覆 盖到的缺陷，通常，在维护阶段对产品的修改都会被记录下来并产生新的发布 版本( 称作“维护版本”并伴随升级了的版本号) 以确保客户可以从升级中获 益。 2 4 2 瀑布模型优势 上述的瀑布模型为软件开发人员提供了众多优势，首先，这个阶段性的软 件开发模型规定了以下规则：每个阶段都有指定的起点和终点，过程最终可以 被客户和开发者识别( 通过使用里程碑) ，在编写第一行代码之前充分强调了需 求和设计，这避免了时间的浪费以及跳票的风险，同时还可以尽可