唐山外贸网站建设,网站keywords标签怎么写,哪个网站可以接工程做,青岛通力建设集团网站个人总结#xff0c;仅供参考#xff0c;欢迎加好友一起讨论 文章目录 架构 - 软件工程考点摘要软件工程概述软件能力成熟度模型软件过程模型瀑布模型原型化模型增量模型螺旋模型喷泉模型V模型迭代与增量的概念CBSD基于构件的模型#xff08;构件组装模型/基于构件的软件开发… 个人总结仅供参考欢迎加好友一起讨论 文章目录 架构 - 软件工程考点摘要软件工程概述软件能力成熟度模型软件过程模型瀑布模型原型化模型增量模型螺旋模型喷泉模型V模型迭代与增量的概念CBSD基于构件的模型构件组装模型/基于构件的软件开发RAD模型快速应用开发模型统一过程RUP/UP敏捷开发方法 逆向工程净室软件工程CSE需求工程需求开发主线目标需求分类需求获取需求分析结构化分析方法 - SASA - 数据字典DDSA - 数据流图DFDSA - 状态转换图STDSA - E-R图/实体联系图 面向对象的分析方法 - OOAOOA - UMLOOA - UML 41视图OOA - 用例模型与分析模型需求分析工具使用用例建模系统需求数据建模与分析过程建模面向对象分析与建模 需求定义形成需求规格需求确认与验证 需求管理支持保障定义需求基线需求的状态需求变更管理需求变更管理过程需求风险需求跟踪 系统设计软件设计软件架构设计用户界面设计/人机界面设计结构化设计概要设计内聚类型与耦合类型 面向对象的设计类的分类设计原则 软件测试测试类型测试阶段系统测试软件调试软件度量 遗留系统演化策略新旧系统的转换策略数据转换和迁移影响软件可维护性的因素软件维护类型 架构 - 软件工程
考点摘要
软件能力成熟度模型★★软件过程模型★★★★基于构件的软件工程★★逆向工程★净室软件工程★需求工程★★系统分析与设计★★软件测试★★系统运行与软件维护★
第二版架构新教材里对应第5章相关概念和定义改动的比较多尤其是对于软件工程阶段的划分传统的软件设计的阶段划分等新教材里都删除了也缺少了测试用例设计、运行维护阶段内容而且还将需求工程软件测试软件维护相关内容加入进来。
软件工程概述
相关软件工程还可以参考系分 - 软件工程
软件开发生命周期
软件定义时期包括可行性研究和详细需求分析过程任务是确定软件开发工程必须完成的总目标具体可分成问题定义、可行性研究、需求分析等。软件开发时期就是软件的设计与实现可分成概要设计、详细设计、编码、测试等。软件运行和维护就是把软件产品移交给用户使用。
软件系统的文档可以分为用户文档和系统文档两类用户文档主要描述系统功能和使用方法并不关系这些功能是怎样实现的系统文档描述系统设计、实现和测试等各方面的内容。
软件工程过程是指为获得软件产品包括以下4个方面活动
P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。D(Do)—―软件开发。开发出满足规格说明的软件。C(Check)——软件确认。确认开发的软件能够满足用户的需求。A(Action)―—软件演进。软件在运行过程中不断改进以满足客户新的需求。
软件系统工具通常可以按软件过程活动将软件工具分为
软件开发工具需求分析工具、设计工具、编码与排错工具、测试工具等。软件维护工具版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。软件管理和软件支持工具项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
软件设计四个活动
数据设计架构体系结构设计人机界面接口设计过程设计。
软件能力成熟度模型
软件能力成熟度模型Capability Maturity Model for SoftwareCMM
初始级特点软件过程的特点是杂乱无章有时甚至很混乱几乎没有明确定义的步骤项目的成功完全依赖个人的努力和英雄式核心人物的作用。可重复级特点建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性有必要的过程准则来重复以前在同类项目中的成功。过程域软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理已定义级特点管理和工程两方面的软件过程已经文档化、标准化并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来发和维护软件。过程域同行评审、组间协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程集点已管理级特点制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制。过程域软件质量管理和定量过程管理优化级特点加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。过程域过程更改管理、技术改革管理和缺陷预防
软件能力成熟度模型集成Capability Maturity Model Integration for SoftwareCMMI
CMMI是在CMM的基础上发展而来的。
初始级特点过程不可预测且缺乏控制已管理级特点过程为项目服务过程域需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证已定义级特点过程为组织服务过程域需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境定量管理特点过程已度量和控制过程域组织过程性能、定量项目管理优化级特点集中于过程改进和优化过程域组织级改革与实施、因果分析和解决方案
软件过程模型 开发方法比开发模型要来得大一号。结构化开发方法对应V模型和瀑布模型面向对象开发方法对应喷泉模型统一方法模型敏捷模型面向服务的模型。 所有面向服务的模型都是以面向对象为基础的。 瀑布模型
瀑布模型也称为生命周期法是生命周期法中最常用的开发模型一般将软件开发分为可行性分析计划、需求分析、软件设计概要设计、详细设计、编码含单元测试、测试、运行维护等几个阶段规定了它们自上而下、相互衔接的固定次序如同瀑布流水逐级下落。如图 瀑布模型特点
从上一项开发活动接受该项活动的工作对象作为输入。利用这一输入实施该项活动应完成的工作内容。给出该项活动的工作成果作为输出传给下一项开发活动。对该项活动的实施工作成果进行评审。若其工作成果得到确认则继续进行下一项开发活动;否则返回前一项甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件
瀑布模型有利于大型软件开发过程中人员的组织与管理有利于软件开发方法和工具的研究与使用从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明上述各项活动之间并非完全是自上而下的而是呈线性图示因此瀑布模型存在严重的缺陷
由于开发模型呈线性所以当开发成果尚未经过测试时用户无法看到软件的效果。这样软件与用户见面的时间间隔较长也增加了一定的风险。在软件开发前期未发现的错误传到后面的开发活动中时可能会扩散进而可能导致整个软件项目开发失败。在软件需求分析阶段完全确定用户的所有需求是比较困难的甚至可以说是不太可能的。
原型化模型
原型化模型主要针对事先不能完整定义需求的软件开发是在快速开发一个原型的基础上根据用户在调用原型的过程中提出的反馈意见和建议对原型进行改进获得原型的新版本重复这一过程直到演化成最终的软件产品。 原型法认为在很难一下子全面准确地提出用户需求的情况下原型应当具备的特点如下
实际可行。具有最终系统的基本特征。构造方便、快速造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。
有关原型化方法/模型的内容
软件原型是所提出的新产品的部分实现建立原型的主要目的是为了解决在产品开发的早期阶段的需求不确定的问题其目的是明确并完善需求、探索设计选择方案、发展为最终的产品。原型模型比较适合需求不够明确的项目。
原型有很多种分类方法。从原型是否实现功能来分软件原型可分为水平原型和垂直原型两种。水平原型也称为行为原型用来探索预期系统的一些特定行为并达到细化需求的目的。水平原型通常只是功能的导航但并未真实实现功能。水平原型主要用在界面上。垂直原型也称为结构化原型实现了一部分功能。垂直原型主要用在复杂的算法实现上。
从原型的最终结果来分软件原型可分为抛弃型原型和演化型原型。抛弃型原型也称为探索型原型是指达到预期目的后原型本身被抛弃。抛弃型原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。演化型原型为开发增量式产品提供基础是螺旋模型的一部分也是面向对象软件开发过程的一部分。演化型原型主要用在必须易于升级和优化的项目适用于Web项目。
有些文献把原型分为实验型、探索型和演化型。探索型原型的目的是要弄清对目标系统的要求确定所希望的特性并探讨多种方案的可行性。实验型原型用于大规模开发和实现之前考核方案是否合适规格说明是否可靠。进化型原型的目的不在于改进规格说明而是将系统建造得易于变化在改进原型的过程中逐步将原型进化成最终系统。
还有些文献也把原型分为抛弃式原型、演化式原型和递增式原型。
原型法适合于用户没有肯定其需求的明确内容的时候。它是先根据已给的和分析的需求建立一个原始模型这是一个可以修改的模型在生命周期法中需求分析成文档后一般不再多修改。
在软件开发的各个阶段都把有关信息相互反馈直至模型的修改使模型渐趋完善。在这个过程中用户的参与和决策加强了最终的结果是更适合用户的要求。
这种原型技术又可分为三类抛弃式、演化式和递增式。这种原型法成败的关键及效率的高低在于模型的建立及建模的速度。 增量模型
增量模型融合了瀑布模型的基本成分重复的应用和原型实现的迭代特征。增量模型采用随着时间的进展而交错的线性序列每一个线性序列产生软件的一个可发布的增量“。当使用增量模型时第一个增量往往是核心的产品也就是说第一个增量实现了基本的需求但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复直到产生最终的完善产品。
增量模型强调每一个增量均发布一个可操作的产品。如图 增量模型像原型实现模型和其他演化方法一样本质上是迭代的。但与原型实现不同的是增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的可拆卸版本但它们确实提供了为用户服务的功能并且提供了给用户评估的平台。增量模型的特点是引进了增量包的概念无须等到所有需求都出来只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求还需要更改但只要这个增量包足够小其影响对整个项目来说是可以承受的。
采用增量模型的优点是人员分配灵活刚开始不用投入大量人力资源如果核心产品很受欢迎则可以增加人力实现下一个增量当配备的人员不能在设定的期限内完成产品时它提供了一种先推出核心产品的途径这样就可以先发布部分功能给客户对客户起到镇静剂的作用。此外增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且不能很好地处理就必须做全盘的系统分析不能很好的进行模块划分。增量模型将功能细化、分别开发的方法适用于需求经常改变的软件开发过程。
螺旋模型
螺旋模型将瀑布模型和原型化演化模型相结合它综合了两者的优点并增加了风险分析。它以原型为基础沿着螺线自内向外旋转每旋转一圈都要经过制订计划、风险分析、实施工程、客户评价等活动并开发原型的一个新版本。螺旋模型强调了风险分析特别适用于庞大而复杂的、高风险的系统。经过若干次螺旋上升的过程得到最终的系统如图需求在项目刚开始的时候往往会比较模糊而随着项目的进行会慢慢的明确下来也就是需求有渐进明细的特点。 喷泉模型
喷泉模型对软件复用和生命周期中多项开发活动的集成提供了支持主要支持面向对象的开发方法是一种以用户需求为动力以对象作为驱动的模型。喷泉一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中分析、设计和编码之间不存在明显的边界如图 V模型
在开发模型中测试常常作为亡羊补牢的事后行为但也有以测试为中心的开发模型那就是V模型。V模型只得到软件业内比较模糊的认可。V模型宣称测试并不是一个事后弥补行为而是一个同开发过程同样重要的过程如图 V模型是最具有代表意义的测试模型它是瀑布模型的变种它在瀑布模型的基础上加强了测试反映了测试活动与分析和设计的关系。V模型中左边下降的是开发过程阶段右边上升部分是测试过程的各个阶段。V模型的软件测试策略既包括低层测试又包括了高层测试低层测试是为了源代码的正确性高层测试是为了使整个系统满足用户的需求。V模型存在一定的局限性它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。让测试工作贯穿于始终。
V模型强调软件幵发的协作和速度将软件实现和验证有机地结合起来在保证较高的软件质M情况下缩短开发周期。V模型适合企业级的软件幵发它更淸楚地揭示了软件开发过程的特性及其本质。
V模型的价值在于它非常明确地表明了测试过程中存在的不同级别并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系
单元测试的主要目的是针对编码过程中可能存在的各种错误。例如用户输入验证过程中的边界值的错误。集成测试的主要目的是针对详细设计中可能存在的问题尤其是检查各单元与其他程序部分之间的接口上可能存在的错误。系统测试主要针对概要设计检查系统作为一个整体是否有效地得到运行。例如在产品设置中是否达到了预期的高性能。验收测试通常由业务专家或用户进行以确认产品能真正符合用户业务上的需要。
迭代与增量的概念 CBSD基于构件的模型构件组装模型/基于构件的软件开发
构件Component组件是一个具有可重用价值的、功能相对独立的软件单元。基于构件的软件开发ComponentBased Software DevelopmentCBSD模型是利用模块化方法将整个系统模块化并在一定构件模型的支持下复用构件库中的一个或多个软件构件通过组合手段高效率、高质量地构造应用软件系统的过程。
基于构件的开发模型融合了螺旋模型的许多特征本质上是演化型的开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立其中构件库包括了构件获取和构件管理、应用软件构建、测试和发布5个阶段组成。如图 CBSE的构件应该具备的特征
可组装性所有外部交互必须通过公开定义的接口进行。可部署性构件总是二进制形式的能作为一个独立实体在平台上运行。文档化用户根据文档来判断构件是否满足需求。独立性可以在无其他特殊构件的情况下进行组装和部署。标准化符合某种标准化的构件模型。
CBSE的构件的组装顺序
顺序组装按顺序调用己经存在的构件可以用两个已经存在的构件来创造一个新的构件。层次组装被调用构件的“提供”接口必须和调用构件的“请求”接口兼容。叠加组装多个构件合并形成新构件新构件整合原构件的功能对外提供新的接口。
构件作为重要的软件技术和工具得到了极大的发展这些新技术标准和工具有Microsoft的DCOM/COMSun的EJBOMG的CORBA等。基于构件的开发活动从标识候选构件开始通过搜索已有构件库确认所需要的构件是否已经存在如果已经存在就从构件库中提取出来复用如果不存在就采用面向对象方法开发它。在提取出来的构件通过语法和语义检查后将这些构件通过胶合代码组装到一起实现系统这个过程是迭代的。
基于构件的开发方法使得软件开发不再一切从头开始开发的过程就是构件组装的过程维护的过程就是构件升级、替换和扩充的过程其优点是构件组装模型导致了软件的复用提高了软件开发的效率构件可由一方定义其规格说明被另一方实现然后供给第三方使用构件组装模型允许多个项目同时开发降低了费用提高了可维护性可实现分步提交软件产品。缺点是由于采用自定义的组装结构标准缺乏通用的组装结构标准引入具有较大的风险可重用性和软件高效性不易协调需要精干的、有经验的分析人员和开发人员一般的开发人员插不上手客户的满意度低过分依赖于构件构件库的质量影响着产品质量。
RAD模型快速应用开发模型
快速应用开发Rapid Application DevelopmentRAD模型是一个增量型的软件开发过程模型强调极短的开发周期。RAD模型是瀑布模型的一个“高速”变种通过大量使用可复用构件采用基于构件的建造方法赢得快速开发。如果需求理解得好且约束了项目的范围利用这种模型可以很快地创建出功能完善的“信息系统“。其流程从业务建模开始随后是数据建模、过程建模、应用生成、测试及反复。瀑布模型和CBSDComponent-Based Software Development基于构建的软件开发模型的综合开发模型如图 RAD模型各个活动期所要完成的任务如下
业务建模以什么信息驱动业务过程运作要生成什么信息谁生成它信息流的去向是哪里由谁处理可以辅之以数据流图。数据建模为支持业务过程的数据流找数据对象集合定义数据对象属性与其他数据对象的关系构成数据模型可辅之以E-R图。过程建模使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除、查找即细化数据流图中的处理框。应用程序生成利用第四代语言4GL写出处理程序重用已有构件或创建新的可重用构件利用环境提供的工具自动生成并构造出整个应用系统。测试与交付由于大量重用一般只做总体测试但新创建的构件还是要测试的。
与瀑布模型相比RAD模型不采用传统的第三代程序设计语言来创建软件而是采用基于构件的开发方法复用已有的程序结构如果可能的话或使用可复用构件或创建可复用的构件如果需要的话。在所有情况下均使用自动化工具辅助软件创造。很显然加在一个RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到三个月的时间内完成那么它就是RAD的一个候选者。每一个主要功能可由一个单独的RAD组来实现最后再集成起来形成一个整体。
RAD模型通过大量使用可复用构件加快了开发速度对信息系统的开发特别有效。但是像所有其他软件过程模型一样RAD方法也有其缺陷
并非所有应用都适合RAD。RAD模型对模块化要求比较高如果有哪一项功能不能被模块化那么建造RAD所需要的构件就会有问题如果高性能是一个指标且该指标必须通过调整接口使其适应系统构件才能赢得RAD方法也有可能不能奏效。开发者和客户必须在很短的时间完成一系列的需求分析任何一方配合不当都会导致RAD项目失败。RAD只能用于信息系统开发不适合技术风险很高的情况。当一个新应用要采用很多新技术或当新软件要求与已有的计算机程序有较高的互操作性时这种情况就会发生。
统一过程RUP/UP RUP的特点
用例驱动需求分析、设计、实现和测试等活动都是用例驱动的。以体系结构为中心包括系统的总体组织和全局控制、通信协议等。是一个多维的结构会采用多个视图来描述。迭代与增量把整个项目开发分为多个迭代过程。在每次选代中只考虑系统的一部分需求进行分析、设计、实现、测试和部署等过程;每次迭代是在己完成部分的基础上进行的每次增加一些新的功能实现以此进行下去直至最后项目的完成。
RUP中有4个阶段
统一软件开发过程定义了四种开发阶段它们按照过程顺序分别是起始阶段细化阶段构建阶段和交付阶段其中在构建阶段主要产生的文档有设计模型。
初始阶段项目蓝图文档核心需求关键特征主要约束用例模型项目计划
细化阶段完成架构设计淘汰高风险元素
构造阶段UML模型测试用例
交付阶段可运行的软件产品用户手册用户支持计划。
RUP中有9个核心工作流 RUP的工作流程分为两部分核心工作流程与核心支持工作流程。核心工作流程在项目中的流程包括业务需求建模、分析设计、实施、测试、部署核心支持工作流程在组织中的流程包括环境、项目管理、配置与变更管理。 RUP软件开发生命周期是一个二维的软件开发模型RUP中有9个核心工作流如下
业务建模理解待开发系统所在的机构及其商业运作确保所有参与人员对待开发系统所在的机构有共同的认识评估待开发系统对所在机构的影响。需求定义系统功能及用户界面使客户知道系统的功能使开发人员理解系统的需求为项目预算及计划提供基础。分析与设计把需求分析的结果转化为分析与设计模型。实现把设计模型转换为实现结果对开发的代码做单元测试将不同实现人员开发的模块集成为可执行系统。测试检查各子系统之间的交互、集成验证所有需求是否均被正确实现对发现的软件质量上的缺陷进行归档对软件质量提出改进建议。部署打包、分发、安装软件升级旧系统培训用户及销售人员并提供技术支持。配置与变更管理跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。项目管理为软件开发项目提供计划、人员分配、执行、监控等方面的指导为风险管理提供框架。环境为软件开发机构提供软件开发环境即提供过程管理和工具的支持。
敏捷开发方法 XP极限编程
XP是一种轻量敏捷、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比其最大的不同在于
以代码驱动的规则其重要的文档是源代码。在更短的周期内更早地提供具体、持续的反馈信息。迭代地进行计划编制首先在最开始迅速生成一个总体计划然后在整个项目开发过程中不断地发展它。依赖于自动测试程序来监控开发进度并及早地捕获缺陷。依赖于口头交流、测试和源程序进行沟通。倡导持续的演化式的设计。依赖于开发团队内部的紧密协作。尽可能达到程序员短期利益和项目长期利益的平衡。
四大价值观
沟通加强面对面沟通简单不过度设计反馈及时反馈勇气接受变更的勇气
XP是一种近螺旋式的开发方法它将复杂的开发过程分解为一个个相对比较简单的小周期:通过积极的交流、反馈以及其他一系列的方法开发人员和客户可以非常清楚开发进度、变化待解决的问题和潜在的困难等并根据实际情况及时地调整开发过程。
XP提倡测试先行为了将以后出现bug的几率降到最低。
XP一些对费用控制严格的公司中的使用非常有效。
水晶方法
水晶系列方法与XP方法一样都有以人为中心的理念但在实践上有所不同。其目的是发展一种提倡“机动性的”方法包含具有共性的核心元素每个都含有独特的角色、过程模式、工作产品和实践。
水晶方法探索了用最少纪律约束而仍能成功的方法从而在产出效率与易于运作上达到一种平衡。
开放式源码
开放式源码程序开发人员在地域上分布很广【其他方法强调集中办公】。
并列争求法
并列争球法SCRUM是一种迭代的增量化过程把每段时间如30天一次的迭代称为一个“冲刺”Sprint并按需求的优先级别来实现产品多个自组织和自治的小组并行地递增实现产品。
并列争求法SCRUM明确定义了的可重复的方法过程侧重于项目管理。。
特征驱动开发方法
特征驱动开发方法FDD是一个迭代的开发模型。认为有效的软件开发需要3个要素人、过程和技术。有5个核心过程开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。定义了6种关键的项目角色项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。
功用驱动开发方法FDD编程开发人员分成两类首席程序员和“类”程序员。
ASD方法
ASD方法其核心是三个非线性的、重叠的开发阶段猜测、合作与学习。
动态系统开发方法
动态系统开发方法DSDM倡导以业务为核心。
逆向工程
逆向工程的特点是从已有的程序中抽取数据结构体系结构和程序设计信息。
它的流程为现有系统 → 逆向工程 → 考虑新需求 → 正向工程 → 新系统。
软件的逆向工程是一个恢复设计的过程从现有的程序中抽取数据体系结构和过程设计信息。逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述在大多数情况下抽象层次越高完备性就越低。 领域级抽象级别最高完备性最低实现级抽象级别最低完备性最高。
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程
重构restructuring重构是指在同一抽象级别上转换系统描述形式。设计恢复design recovery设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。逆向工程reverse engineering逆向工程是分析程序力图在比源代码更高抽象层次上建立程序的表示过程逆向工程是设计的恢复过程。正向工程forward engineering正向工程是指不仅从现有系统中恢复设计信息而且使用该信息去改变或重构现有系统以改善其整体质量。再工程re-engineering再工程是对现有系统的重新开发过程包括逆向工程、新需求的考虑过程和正向工程三个步骤。
逆向工程恢复信息的方法方法导出信息用户指导下的搜索与变换方法实现级、结构级变换式方法实现级、结构级、功能级基于领域知识的方法功能级、领域级铅板恢复法实现级、结构级
净室软件工程CSE
净室即无尘室洁净室也就是一个受控污染级别的环境。
使用盒结构规约或形式化方法进行分析和设计建模并且强调将正确性验证而不是测试作为发现和消除错误的主要机制。
使用统计的测试来获取认证被交付的软件的可靠性所必须的出错率信息。它是一种强调正确性的数学验证和软件可靠性的认证的软件工程模型其目标和结果具有非常低的出错率。
技术手段 统计过程控制下的增量式开发控制迭代 基于函数的规范和设计盒子结构 定义3种抽象层次行为视图黑盒 有限状态机视图状态盒 过程视图明盒 正确性验证净室工程的核心 统计测试和软件认证使用统计学原理总体太大时必须采用抽样方法
缺点
太理论化正确性验证的步骤比较困难且耗时。开发小组不进行传统的模块测试这是不现实的。脱胎于传统软件工程不可避免带有传统软件工程的一些弊端。
需求工程
相关需求工程还可以参考系分 - 需求工程
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。 需求开发主线目标
需求分类 需求分类
业务需求业务需求是指反映企业或客户对系统高层次的目标要求通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围。用户需求用户需求描述的是用户的具体目标或用户要求系统必须能完成的任务。也就是说用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式对用户使用的场景scenarios进行整理从而建立用户需求系统需求系统需求是从系统的角度来说明软件的需求包括功能需求、非功能需求和设计约束等。
质量功能部署QFD
它是一种将用户要求转化成软件需求的技术其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标QFD将软件需求分为三类分别是常规需求、期望需求和意外需求。
基本需求也叫常规需求用户认为系统应该做到的功能或性能实现越多用户会越满意。期望需求用户想当然认为系统应具备的功能或性能但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现会让用户感到不满意。意外需求意外需求也称为兴奋需求是用户要求范围外的功能或性能但通常是软件开发人员很乐意赋予系统的技术特性实现这些需求用户会更高兴但不实现也不影响其购买的决策。
需求获取
需求获取方法方法特点收集资料把与系统有关的、对系统开发有益的信息收集起来。阅读历史文档对收集数据性的信息较为有用。用户访谈1对1-3有代表性的用户了解主观想法交互好。成本高要有领域知识支撑。问卷调查用户多无法—一访谈成本低。现场观摩针对较为复杂的流程和操作。参加业务实践有效地发现问题的本质和寻找解决问题的办法。联合需求计划(JRP)高度组织的群体会议各方参与了解想法消除分歧交互好成本高。情节串联板(原型法)一系列图片通过这些图片来讲故事。抽样调查/采样基于数理统计降低成本快速获取。样本大小a*(可信度系数/可接受的错误)2注:a一般取0.25 用户访谈是最基本的一种需求获取手段其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题有针对地进行而非结构化则是只列出一个粗略的想法根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行毕竟不可能把什么都一一计划清楚应该保持良好的灵活性。 用户访谈具有良好的灵活性有较宽广的应用范围。但是也存在着许多困难例如用户经常较忙难以安排时间面谈时信息量大记录较为困难沟通需要很多技巧同时需要系统分析师具有足够的领域知识等。另外在访谈时还可能会遇到一些对于企业来说比较机密和敏感的话题。因此这看似简单的技术也需要系统分析师具有丰富的经验和较强的沟通能力。 问卷调查与用户访谈相比问卷调查可以在短时间内以低廉的代价从大量的回答中收集数据问卷调查允许回答者匿名填写大多数用户可能会提供真实信息问卷调查的结果比较好整理和统计。但是问卷调查最大的不足就是缺乏灵活性其他缺点还有 ① 双方未见面系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息用户也没有机会立即澄清对问题有含糊或错误的回答。 ② 用户有可能在心理上会不重视一张小小的表格不认真对待从而使得反馈的信息不全面。 ③ 调查表不利于对问题进行展开的回答无法了解一些细节问题。 ④ 回答者的数量往往比预期的要少无法保证用户会回答问题或进一步说明所有问题。 抽样调查/采样是指从种群中系统地选出有代表性的样本集的过程通过认真研究所选出的样本集可以从整体上揭示种群的有用信息。对于信息系统的开发而言现有系统的文档文件就是采样种群。当开始对一个系统做需求分析时查看现有系统的文档是对系统有初步了解的最好方法。但是系统分析师应该查看哪些类型的文档当文档的数据庞大无法一一研究时就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时上面介绍的采样技术同样适用。通过采样技术选择部分而不是选择种群的全部不仅加快了数据收集的过程而且提高了效率从而降低了开发成本。另外采样技术使用了数理统计原理能减少数据收集的偏差。 但是由于采样技术基于统计学原理样本规模的确定依赖于期望的可信度和已有的先验知识很大程度上取决于系统分析师的主观因素对系统分析师个人的经验和能力依赖性很强要求系统分析师具有较高的水平和丰富的经验。 联合需求计划JRP JRP是一种相对来说成本较高的需求获取方法但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起通过有组织的会议来讨论需求。通常该会议的参与人数为618人召开时间为15小时。 JRP的主要意图是收集需求而不是对需求进行分析和验证。实施JRP时应把握以下主要原则 ① 在JRP实施之前应制订详细的议程并严格遵照议程进行。 ②按照既定的时间安排进行。 ③尽量完整地记录会议期间的内容。 ④在讨论期间尽量避免使用专业术语。 ⑤充分运用解决冲突的技能。 ⑥会议期间应设置充分的间歇时间。 ⑦鼓励团队取得一致意见。 ⑧保证参加JRP的所有人员能够遵守事先约定的规则。
需求分析
需求分析一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性因此需要分析人员把杂乱无章的用户要求和期望转化为用户需求这就是需求分析的工作。
需求分析的任务
绘制系统上下文范围关系图创建用户界面原型分析需求的可行性确定需求的优先级为需求建立模型创建数据字典使用QFD质量功能部署) 结构化分析方法 - SA
结构化分析方法SA的核心是数据字典。围绕这个核心有三个层次的模型分别是数据模型功能模型行为模型状态模型。
结构化分析的步骤如下
分析业务情况做出反映当前物理模型的数据流图Data Flow DiagramDFD。推导出等价的逻辑模型的DFD。设计新的逻辑系统生成数据字典和基元描述。建立人机接口提出可供选择的目标系统物理模型的DFD。确定各种方案的成本和风险等级据此对各种方案进行分析。选择一种方案。建立完整的需求规约。 结构化分析方法SA是数据流和控制流常用手段是数据流图DFD和数据字典。 SA - 数据字典DD
数据字典是需求分析建立模型的核心。是为数据流图中的每个数据流、文件、加工以及组成数据流或文件的数据项做出说明。
数据字典有4类条目数据流、数据项、数据存储和基本加工。包括了数据元素数据结构数据流加工逻辑和外部实体。如下图 SA - 数据流图DFD
数据流图DFD是用数据流图表示功能模型DFD说明系统所完成功能从数据传递和加工的角度利用图形符号通过逐层细分描述系统的各个部件的功能和数据在他们之间传递的情况来说明系统所完成的功能。如下图 其中DFD还会有“顶层DFD图”和“0层DFD图”。
如上图有如下几种“图元”描述 另附一个错误的DFD图如下 如上图错误
加工3.1.2有输入但是没有输出称之为“黑洞”。加工3.1.3有输出但没有输入。称之为“奇迹”。加工3.1.1中输入不足以产生输出我们称之为“灰洞”。
SA - 状态转换图STD
用状态转换图表示行为模型STD通过描述系统的状态和引起系统状态转换的事件来表示系统的行为指出做为特定事件的结果将执行哪些动作。如下图 SA - E-R图/实体联系图
ER图主要描述实体属性以及实体之间的关系。另外ER模型是结构化时代的模型与产物在面向对象和UML中是没有的。如下图 什么是弱实体 举例说明在人事管理系统中职工子女的信息就是以职工的存在为前提的子女实体是弱实体子女与职工的联系是一种依赖联系。所以职工是实体也可以成为强实体。 强实体与弱实体的联系只能是11或1N。 面向对象的分析方法 - OOA
相关的几个概念对象属性[数据] 方法[操作] 对象ID/标识ID类[详细见下]实体类/控制类/边界类实体类往往和数据库有对应的关系是不是数据类型控制类衔接实体类和边界类的类边界类在一个系统的边界上和外部进行沟通的类这三个类似于MVC模型之间的关系它们的思想是一样的继承与泛化复用机制它是一种紧耦合。因为当父类变的时候子类不得不变。继承是对已有实例的特征稍作改变就生成其他的实例。封装隐藏对象的属性和实现细节仅对外公开接口多态不同对象收到同样的信息产生不同的结果接口一种特殊的类它只有方法定义没有对方法的实现重载一个类可以有多个同名的参数类型不同的方法。函数同名但参数不一样是其特点消息和消息通信消息是异步通信的覆盖与重写子类的同名方法覆盖父类的同名方法组合与聚合聚合关系汽车部件和整车的关系整体与部分生命周期不同组合关系部门与公司的关系。公司倒闭的话部门也完完整体与部分生命周期相同
OOA大致上遵循如下5个基本步骤
确定对象和类。这里所说的对象是对数据及其处理方式的抽象它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述它包括如何在一个类中建立一个新对象的描述。确定结构。结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系整体-部分结构反映整体和局部之间的关系。确定主题。主题是指事物的总体概貌和总体分析模型。确定属性。属性就是数据元素可用来描述对象或分类结构的实例可在图中给出并在对象的存储中指定。确定方法。方法是在收到消息后必须进行的一些处理方法:方法要在图中定义并在对象的存储中指定。对于每个对象和结构来说那些用来增加、修改、删除和选择的方法本身都是隐含的虽然它们是要在对象的存储中定义的但并不在图上给出而有些则是显示的。
OOA - UML
OOA需求分析的UML统一建模语言与平台和语言无关由基本构造块规则和公共机制构成。 UML基本构造块之事物【重要组成部分】结构事物最静态的部分包括类接口协作用例活动类构件和节点行为事物代表时间和空间上的动作包括消息动作次序连接分组事物看成是个盒子如包和构件注释事物UML模型的解释部分。描述说明和标注模型的元素
UML基本构造块之关系【把事物紧密联系在一起】依赖关系一个事物发生变化影响另一个事物包含关系和扩展关系都属于依赖泛化关系特殊一般关系特殊元素的对象可替换一般元素的对象关联关系描述了一个链链是对象之间的连接实现关系接口与类之间的关系一个类指定了由另一个类保证执行的契约
UML基本构造块之图【多个相互关联的事物的集合】静态图结构图类图描述一组类接口协作和它们之间的关系。对象图描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用画出来的对象图往往不会只有一个对象。构件图也叫组件图是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口端口以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。部署图表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统内存CPU等不在它范畴内它只解决开发的系统如何去部署的问题。制品图描述计算机中一个系统的物理结构。制品包括文件数据库和类似的物理比特集合。包图将某些类放入“包”中通过包图来组织业务概念图。组合结构图展示该部分内容“内部”参与者的配置情况。这个图不常用。动态图行为图用例图系统与外部参与者的交互。描述一组用例参与者及他们之间的关系的图。顺序图强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。通信图也叫协作图它强调的是相互之间关系是顺序图的另外一种表达。定时图消息跨越不同对象或角色的实际时间。交互图的一种。交互概览图活动图与顺序图的结合。这个图不常用。活动图类似程序流程图表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流它专注于系统的动态视图它对系统功能建模和业务流程建模特别重要并强调对象间的控制流程。状态图从某个物品的状态是如何变化的角度来展示流程。 UML规则是构造块如何放在一起的规定包括为构造块命名给一个名字以特定含义的语境即范围怎样使用或看见名字即可见性事物如何正确、一致地相互联系即完整性运行或模拟动态模型的含义是什么即执行。
UML公共机制是指达到特定H标的公共UML方法主要包括规格说明详细说明、修饰、公共分类通用划分和扩展机制4种。规格说明是事物语义的细节描述它是模型真正的核心UML为每个事物设置了一个简单的记号还可以通过修饰来表达更多的信息UML包括两组公共分类类与对象类表示概念而对象表示具体的实体)、接门与实现接口用来定义契约而实现就是具体的内容)扩展机制包括约束扩展了UML构造块的语义允许增加新的规则或修改现有的规则、构造型扩展UML的词汇用于定义新的构造块和标记值扩展了UML构造块的特性允许创建新的特殊信息来扩展事物的规格说明。
UML中的概念
类是描述具有相同属性、方法、关系和语义的对象的集合一个类实现一个或多个接口。接口是指类或构件提供特定服务的一组操作的集合接口描述了类或构件的对外的可见的动作。构件是物理上或可替换的系统部分它实现了一个接口集合。提供一组接口的实现是组成事物的元素。包是用于把元素组织成组的通用机制它一个构件的抽象化的概念是把类元按照一定的规则分成组或称为模块。用例是描述一系列的动作产生有价值的结果。协作定义了交互的操作是一些角色和其它事物一起工作提供一些合作的动作这些动作比事物的总和要大。节点是一个物理元素它在运行时存在代表一个可计算的资源通常占用一些内存和具有处理能力。
OOA - UML 41视图 现有的UML再有的UML视图 UML采用41视图来描述软件和软件的开发过程其中进程视图绘制了所设计的并发与同步结构部署视图表示软件到硬件的映射和分布结构UML中的类图可以用来表示41视图中逻辑视图最终形成用例视图用来得到需求分析模型。 “41”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。
“41”视图模型具有普遍适用性实践证明能在许多大型项目中成功运用。
OOA - 用例模型与分析模型
在OOA的需求分析中图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线其中用例模型采用用例图来构建分析模型用类型表示。其它细节情况也可以建立其它交互图。 案例分析中用例图和类图经常考到 需求分析工具
使用用例建模系统需求
用例建模来源于面向对象建模技术但该技术也在非对象开发环境中比较流行用例建模技术对传统的系统分析和设计工具进行了补充例如数据建模和过程建模 也提供了架构决策和用户界面设计决策的基础。
用例建模促进并鼓励了用户参与具有如下优点
提供了捕捉功能需求的工具。有助于将系统分解为更易于管理的小块。提供了与用户以及其他关心系统的关联人员进行交流的工具。辅助估计项目范围、投入和进度。提供了需求跟踪的工具。提供了确定数据对象或实体的起点。提供了设计用户和系统接口的功能规格说明。
为了决定用例的重要性项目经理或者系统分析员将填写用例分级和评估矩阵并使用来自关联人员和开发团队的输入构造用例依赖关系图。
1、项目经理使用称为用例分级和评估矩阵决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是
对架构设计的重要影响。容易实现但包含重要功能。包含有风险、时间紧迫或复杂的功能。需要大量的研究或者新的、有风险的技术。包含主要的业务功能。将增加或者减少费用。
2、有些用例依赖于其他用例其中一个用例使系统处于一种状态该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点
系统事件及其状态的图形化表述有利于对系统功能的理解。有助于确定遗漏的用例。通过描述哪个用例更关键并需要最高优先权有助于推动项目管理。
数据建模与分析
数据建模是一种为数据库定义业务需要的技术因为数据模型最终要实现成数据库所以数据建模有时称为数据库建模。下图是一个简单的数据模型称为实体关系图。
数据建模的系统概念
实体属性数据类型、域、默认值键关系
如何构造数据模型
获取实体。构造上下文数据模型包含基本业务实体及它们之间的自然关系。基于键的数据模型确定每个实体的键。泛化层次体系父实体、子实体。具有完整属性的数据模型。分析数据模型规范化第一范式、第二范式、第三范式。将数据需求映射到地点数据–地点–CRUD矩阵。
过程建模
过程建模源自传统的软件工程方法可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。
过程建模的系统概念
外部代理常见的同义词包括外部实体。数据存储是一个数据的“仓库”同义词包括文件和数据库。过程即处理是在输入数据流或条件上执行或者对输入数据流或条件做出响应的工作同义词是转换。分解图、层次图。注意避免过程中三种常见的错误1有输入没有输出黑洞2)有输出但没有输入奇迹3)输入不足以产生输出灰洞如输入一个雇员地址输出一张财务报表。数据流所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。
如何构造过程模型
构造上下文数据流图0号数据流图。构造系统功能分解图。事件响应或用例清单构建分解图后下一步是确定系统必须响应什么业务事件外部事件、时序事件、状态事件。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。事件分解图把事件处理过程增加到分解图中。事件图以分解图为提纲可以为每个事件过程绘制一个事件图。构造系统图从原始的上下文图中的单个过程“爆炸”出来在单张图中显示了系统的所有事件显示了子系统的所有事件。 构造基本图具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图每个基本过程都是内聚的也就是说仅完成一件事。完成规格说明对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述并写进资料库中。对于过程内部的逻辑描述我们可以使用结构化英语自然英语编程逻辑用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的即业务策略使用结构化英语不容易表达此时可以使用决策表。
面向对象分析与建模
面向对象分析涉及到定义信息系统的静态和动态行为模型而非定义数据和过程模型这是传统开发方法的特点。对象的标识对象的数据部分属性对象的行为。
需求定义形成需求规格 需求定义的过程也就是形成需求规格说明书SRS的过程通常有两种需求定义的方法分别是严格定义方法和原型方法。
严格定义法的特点所有需求都能够被严格定义开发人员和用户之间能够准确而清晰的交流采用图形文字能够充分体现最终系统。
原型法并非所有的需求都能在开发前被准确的说明项目参加者之间通常存在交流上的困难需要实际的可供用户参与的系统模型有合适的系统开发环境反复是完全需要和值得提倡的需求一旦确定就应该遵从严格的方法。
需求确认与验证 需求规格说明书SRS的需求验证也称为需求确认其活动是为了确定以下几个方面的内容
SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。需求是完整的和高质量的。需求的表示在所有地方都是一致的。需求为继续进行系统设计、实现和测试提供了足够的基础。
需求验证包括了需求评审和需求测试。
需求评审包括了正式评审和非正式评审。需求验证是需要做用户签字确认但往往实施起来比较困难因为需求验证时签字就要负责任它是验收的标准之一此时的规格说明书SRS就是需求基线。需求的评审需要用户的参与。
需求测试不是运行类的测试而是设计测试用例进行测试比如告诉你输入是什么输出是什么所以更加接近于想像性测试它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而以功能需求为基础SA方法或者从用例派生出来OO方法的测试用例可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例即不是真正执行的测试用例它们可以发现SRS中的错误、二义性和遗漏还可以进行模型分析以及作为用户验收测试的基础。在正式的系统测试中还可以将它们细化成测试用例。
需求管理支持保障
在软件需求工程中需求管理贯穿于整个过程中它的最基本的任务就是明确需求并使项目团队和用户达成共识即建立需求基线。另外还要建立需求跟踪能力联系链确保所有用户需求都被正确地应用并且在需求发生变更时能够完全地控制其影响范围始终保持产品与需求的一致性。
需求管理是可重复级的一个关键过程域其目标是为软件需求建立一个基线供软件开发及其管理使用使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动包括控制需求基线保持项目计划与需求一致控制单个需求和需求文档的版本情况管理需求和联系链之间的联系或管理单个需求和项目其他可交付物之间的依赖关系跟踪基线中需求的状态。
定义需求基线
需求开发的结果应该有项目视图和范围文档、用例文档和SRS以及相关的分析模型。经评审批准这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定它是需求开发和需求管理之间的桥梁。
基线是一个软件配置管理的概念它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义基线是指已经通过正式评审和批准的规约或产品它可以作为进一步开发的基础并且只能通过正式的变更控制系统进行变化。在软件工程范围内基线是软件开发中的里程碑其标志是有一个或多个软件配置项的交付且已经经过正式技术评审而获得认可。例如SRS文档通过评审其中的错误已经被发现并纠正则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》GB/T 12505-1990的规定基线可以分为功能基线、指派基线和产品基线三种通过评审后的SRS软件需求规格说明书属于指派基线。
需求的状态 在需求状态的变化中项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求如果不是通过有管理的处理过程就有可能因为疏忽而被遗漏。同时也应关注被交付的需求因为可交付物是项目的成果体现而可交付物的主要内容就是对需求的实现。
需求变更管理 CCB变更控制委员会也成配置控制委员会 要让变更有序进行首先需要有一个统一的单位来负责这个单位一般叫变更控制委员会Change Control Board也叫配置控制委员会Configuration Control Board。CCB由项目干系人中有代表性的人员组成人数没有限制一个人也可以。CCB有能力在管理上做出承诺对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构一般不参与具体的变更执行工作。 需求变更管理过程 问题分析和变更描述。当提出一份变更提议后需要对该提议做进一步的问题分析检查它的有效性从而产生一个更明确的需求变更提议。变更分析和成本计算。当接受该变更提议后需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认应该进行是否执行这一变更的决策。变更实现。当确定执行该变更后需要根据该变更的影响范围按照开发的过程模型执行相应的变更。在计划驱动过程模型中往往需要回溯到需求分析阶段开始重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中往往会将需求变更纳入到下一次迭代的执行过程中。
常见的需求变更策略
所有需求变更必须遵循变更控制过程。对于未获得批准的变更不应该做设计和实现工作。变更应该由项目变更控制委员会决定实现哪些变更。项目风险承担者应该能够了解变更的内容。绝不能从项目配置库中删除或者修改变更请求的原始文档。每一个集成的需求变更必须能跟踪到一个经核准的变更请求以保持水平可追踪性。
需求风险
带有风险的做法有①无足够用户参与。②忽略了用户分类。③用户需求的不断增加。④模凌两可的需求。⑤不必要的特征。⑥过于精简的SRS。⑦不准确的估算。
变更产生的原因①外部环境的变化。②需求和设计做的不够完整。③新技术的出现。④公司机构重组造成业务流程的变化。
需求跟踪 SRS中的每个软件配置项的需求到其涉及的系统或子系统需求都要具有双向可追踪性。所谓双向跟踪包括正向跟踪和反向跟踪正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点反向跟踪也称为逆向跟踪是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。
系统设计
相关系统设计还可以参考系分 - 系统设计
系统设计是系统分析的延伸与拓展。系统分析阶段解决“做什么”的问题而系统设计阶段解决“怎么做”的问题。同时它也是系统实施的基础为系统实施工作做好铺垫。合理的系统设计方案既可以保证系统的质量也可以提高开发效率确保系统实施工作的顺利进行。
系统设计阶段又称为物理设计阶段它是信息系统开发过程中一个非常重要的阶段。其任务是根据系统规格说明书中规定的功能要求考虑实际条件具体设计实现逻辑模型的技术方案也就是设计新系统的物理模型为下一阶段的系统实施工作奠定基础。
系统设计的主要内容包括概要设计和详细设计。概要设计又称为系统总体结构设计它是系统开发过程中很关键的一步其主要任务是将系统的功能需求分配给软件模块确定每个模块的功能和调用关系形成软件的模块结构图即系统结构图。在概要设计中将系统开发的总任务分解成许多个基本的、具体的任务为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。根据任务的不同详细设计又可分为多种例如网络设计、代码设计、输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。
软件设计
软件设计包括体系结构设计、接口设计、数据设计和过程设计。
结构设计定义软件系统各主要部件之间的关系开发一个模块化的程序结构并表示出模块间的控制关系。数据设计将模型转换成数据结构的定义。高质量数据设计将改善程序结构和模块划分降低过程复杂性。接口设计人机界面设计软件内部、软件和操作系统间以及软件和人之间如何通信。过程设计系统结构部件转换成软件的过程描述。
软件架构设计
软件架构 软件体系结构
架构设计就是需求分配即将满足需求的职责分配到组件上。
相关架构设计还可以参考软件架构设计
用户界面设计/人机界面设计 以上三条原则由著名用户界面设计专家Theo Mandel博士所创造通常称之为人机交互的“黄金三原则”。另外在设计用户界面时还需要保证界面的合理性和独特性有效进行组合注重美观与协调恰到好处地提供快捷方式注意资源协调等。
结构化设计
结构化设计Structured DesignSD是一种面向数据流的方法它以SRS和SA阶段所产生的数据流图和数据字典等文档为基础是一个自顶向下、逐步求精和模块化的过程。SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构分为概要设计和详细设计两个阶段其中概要设计的主要任务是确定软件系统的结构对系统进行模块划分确定每个模块的功能、接口和模块之间的调用关系详细设计的主要任务是为每个模块设计实现的细节。
概要设计
概要设计又称为系统总体结构设计它是系统开发过程中很关键的一步其主要任务是将系统的功能需求分配给软件模块确定每个模块的功能和调用关系形成软件的模块结构图即系统结构图。
系统结构图Structure ChartSC又称为模块结构图它是软件概要设计阶段的工具反映系统的功能实现和模块之间的联系与通信包括各模块之间的层次结构即反映了系统的总体结构。
人们在解决复杂问题时使用的一个很重要的原则就是将它分解成多个小问题分别处理在处理过程中需要根据系统总体要求协调各业务部门的关系。在SD中这种功能分解就是将系统划分为模块模块是组成系统的基本单位它的特点是可以自由组合、分解和变换系统中任何一个处理功能都可以看成一个模块。
模块的四个要素
输入和输出模块的输入来源和输出去向都是同一个调用者即一个模块从调用者那儿取得输入进行加工后再把输出返回调用者。处理功能指模块把输入转换成输出所做的工作。内部数据指仅供该模块本身引用的数据。程序代码指用来实现模块功能的程序。
前两个要素是模块的外部特性即反映了模块的外貌后两个要素是模块的内部特性。在结构化设计中主要考虑的是模块的外部特性其内部特性只做必要了解具体的实现将在系统实施阶段完成。
在SD方法中系统由多个逻辑上相对独立的模块组成在模块划分时需要遵循如下原则
保持模块大小适中尽可能减少调用的深度宽度也不宜过高扇入/扇出系数合理多扇入少扇出单入口单出口模块的作用域应该在模块内功能应该是可预测的模块独立性原则高内聚低耦合
内聚类型与耦合类型 面向对象的设计
面向对象的设计OOD是面向对象的分析OOA的延续其基本思想包括抽象、封装和可扩展性其中可扩展性主要通过继承和多态来实现。在OOD中数据结构和在数据结构上定义的操作算法封装在一个对象之中。由于现实世界中的事物都可以抽象出对象的集合所以OOD方法是一种更接近现实世界、更自然的系统设计方法。 类的分类 对象问的关系有组合聚合继承等 Use-A依赖关系 IS-A继承关系 IS-PART-OF聚合组合一种聚合对应的语义是“is a member of” 设计原则
在OOD中可维护性的复用是以设计原则为基础的。常用的OOD中原则包括单一原则、幵闭原则、里氏替换原则、依赖倒置原则、组合/聚合复用原则、接口隔离原则和最少知识原则等。这些设计原则首先都是面向复用的原则遵循这些设计原则可以有效地提高系统的复用性同时提高系统的可维护性。
单一职责原则设计目的单一的类。开放-封闭原则对扩展开放对修改封闭。即尽量在不修改原有代码的情况下进行扩展。里氏替换原则子类可以替换父类父类可以替换成子类程序的行为没有变化。软件实体如果使用的是一个基类对象那么一定适用于其子类对象而且觉察不出基类对象和子类对象的区别。依赖倒置原则抽象不应该依赖于细节细节要依赖于抽象而不是具体实现。针对接口编程不要针对实现编程。组合/聚合复用原则又称为合成复用原则要尽景使用组合/聚合关系少用继承。接口隔离原则使用多个专门的接口而不使用单一的总接口。最少知识原则也称为迪米特法则是指一个软件实体应当尽可能少地与其他实体发生相互作用。
软件测试
相关软件测试还可以参考系分 - 系统测试与维护
尽早、不断的进行测试程序员避免测试自己设计的程序既要选择有效、合理的数据,也要选择无效、不合理的数据修改后应进行回归测试尚未发现的错误数量与该程序已发现错误数成正比
测试类型 测试阶段 系统测试 软件调试
测试是发现错误调试是找出错误的代码和原因。
调试需要确定错误的准确位置确定问题的原因并设法改正改正后要进行回归测试。
调试的方法有蛮力法、回溯法从出错的地方开始向回找、原因排除法找出所有可能的原因逐一进行排除具体包括演绎法、归纳法、二分法。
软件度量
软件的两种属性外部属性指面向管理者和用户的属性可直接测量一般为性能指标。内部属性指软件产品本身的的属性如可靠性等只能间接测量。
McCabe度量法又称为环路复杂度假设有向图中有向边数为m节点数为n则此有向图的环路复杂度为m-n2。
注意m和n代表的含义不能混淆可以用一个最简单的环路来做特殊值记忆此公式另外针对一个程序流程图每一个分支边连线就是一条有向边每一条语句语句框就是一个顶点。
遗留系统演化策略
遗留系统Legacy System是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。
对遗留系统评价的目的是为了获得对遗留系统的更好的理解这是遗留系统演化的基础是任何遗留系统演化项目的起点。主要评价方法包括度量系统技术水准、商业价值和与之关联的企业特征其结果作为选择处理策略的基础。 改造策略高水平、高价值区即遗留系统的技术含量较高本身还有极大的生命力。系统具有较高的业务价值基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短称这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求对遗留系统本身不做改变数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。继承策略低水平、高价值区即遗留系统的技术含量较低已经满足企业运作的功能或性能要求但具有较高的商业价值目前企业的业务尚紧密依赖该系统。称这种遗留系统的演化策略为继承。在开发新系统时需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性新老系统必须并行运行一段时间再逐渐切换到新系统上运行。集成策略高水平、低价值区即遗留系统的技术含量较高但其业务价值较低可能只完成某个部门或子公司的业务管理。这种系统在各自的局部领域里工作良好但对于整个企业来说存在多个这样的系统不同的系统基于不同的平台、不同的数据模型形成了一个个信息孤岛对这种遗留系统的演化策略为集成。淘汰策略低水平、低价值区即遗留系统的技术含量较低且具有较低的业务价值。对这种遗留系统的演化策略为淘汰即全面重新开发新的系统以代替遗留系统。完全淘汰是一种极端性策略一般是企业的业务产生了根本变化遗留系统已经基本上不再适应企业运作的需要或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价发现将遗留系统完全淘汰开发全新的系统比改造旧系统从成本上考虑更合算。
新旧系统的转换策略 在实施新旧系统转换时转换的策略通常有三种
直接转换策略适用于新系统不太复杂或现有系统完全不能使用的场合新系统在转换之前必须经过详细而严格的测试。并行转换策略新系统和现有系统并行工作一段时间经过这段时间的试运行后再用新系统正式替换下现有系统。分段转换策略分段转换策略也称为逐步转换策略这种转换方式是直接转换方式和并行转换方式的结合采取分期分批逐步转换。一般比较大的系统采用这种方式较为适宜它能保证平稳运行费用也不太高或者现有系统比较稳定能够适应自身业务发展需要或新旧系统转换风险很大例如在线订票系统、银行的中间业务系统等也可以采用分段转换策略。分段转换策略的优点是新旧系统的转换震动比较小用户容易接受。但由于是采用渐进方式导致新旧系统的转换周期过长同时由于需求的变化给新系统的稳定造成比较大的影响。而且分段转换策略对系统的设计和实现都有一定的要求在转换过程中需要开发新旧系统之间的接口还需要制订阶段性的转换目标和计划。
数据转换和迁移
数据迁移的主要方法大致有三种分别是系统切换前通过工具迁移、系统切换前采用手工录入和系统切换后通过新系统生成。 数据迁移的实施可以分为三个阶段分别是数据迁移前的准备、数据转换与迁移和数据迁移后的校验。其中准备工作要做好以下7个方面的工作
待迁移数据源的详细说明包括数据的存放方式、数据量和数据的时间跨度。建立新旧系统数据库的数据字典对现有系统的历史数据进行质量分析以及新旧系统数据结构的差异分析。新旧系统代码数据的差异分析。建立新旧系统数据库表的映射关系对无法映射字段的处理方法。开发或购买、部署ETL工具。编写数据转换的测试计划和校验程序。制定数据转换的应急措施。
在数据迁移完成后需要对迁移后的数据进行校验。数据迁移后的校验是对迁移质量的检查同时数据校验的结果也是判断新系统能否正式启用的重要依据。可以通过以下两种方式对迁移后的数据进行校验
对迁移后的数据进行质量分析。新旧系统查询数据对比检查。
影响软件可维护性的因素 【可理解性】是指通过阅读源代码和相关文档了解软件的功能和如何运行的容易程度。 【可修改性】是指修改软件的难易程度。 【可测试性】是指验证软件程序正确的难易程度。 可测试性好的软件通常意味着软件设计简单复杂性低。因为软件的复杂性越大测试的难度也就越大。 【可靠性】一个软件的可靠性越高需要维护的概率就会越低。 【可移植性】是指将软件从一个环境移植到新的的环境下正确运行的难易程度。 软件运行环境的变化是软件维护的一种常见情形可移植性好的软件会降低维护的概率
软件维护类型
软件的维护并不只是修正错误为了满足用户提出的增加新功能修改现有功能以及一般性的改进要求和建议需要进行完善性维护他是软件维护的重要组成部分。
改正性维护【修BUG】也称正确性维护指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误【修正bug、错误】。适应性维护【应变】指使应用软件适应环境变化【外部环境、数据环境】而进行的修改。完善性维护【新需求】扩充功能和改善性能而进行的修改。预防性维护【针对未来】为了适应未来的软硬件环境的变化应主动增加预防性的新的功能以使系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能以适应将来报表格式的变化。
