软件工程基础与案例教程 课件全套 窦万峰 第1-4部分 软件工程基础- 软件维护与项目管理

软件工程基础与案例教程

(微课视频版)第一部分：软件工程理论基础什么是软件工程？软件工程的思想是什么？软件工程有哪些基本原理和原则？软件过程与过程模型的关系是什么？什么是敏捷软件开发？如何进行用例建模？第1章软件工程概述内容提要：关于软件关于软件工程软件工程基本原理与基本原则软件工程范型软件工程基本活动1.1关于软件软件概念：三要素：软件=程序+文档+数据软件特性：复杂性一致性退化性易变性移植性高成本软件开发技术演化软件技术发展阶段。1946年到60年代初：个体手工方式。结构化和面向对象程序设计阶段。60年代初到80年代初：小组化生产，出现软件危机。软件工程阶段。20世纪90年代中期至今：把工程化的思想引入到软件开发中，结构化方法的发展，规模化软件开发。面向对象方法学发展，软件定制和满足客户需求。发展趋势软件服务：云服务、大数据服务多样性：中间件开放性：新型中间件平台1.2关于软件工程软件危机的出现问题：如何开发软件如何维护软件表现：规模大、复杂度增加供需差增大价格昂贵开发速度慢质量难以保证案例软件危机解决途径重视需求分析，明确与确切表达需求重视与客户沟通与交流统一的、公认的方法论和规范指导重视设计和实现过程的资料充分的检测工作软件工程概念软件工程运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必须的相关文件资料。软件工程是为了经济地获得能够在实际机器上有效运行的可靠软件而建立和使用的一系列完善的工程化原则。软件工程是开发、运行、维护和修复软件的系统方法。软件工程三要素工程化思想把软件看作是一个工程产品两个方面：软件开发技术软件工程管理原因：缺乏软件过程控制能力能力成熟模型（CapabilityMaturityModel）体现:工程化管理软件工程管理1.3软件工程基本原理与原则基本原理推迟实现逐步求精分解与抽象信息隐蔽质量保证基本原则分阶段的软件开发坚持进行阶段评审实行严格的产品控制采用先进的程序设计技术明确责任开发小组的人员应少而精不断改进开发过程1.4软件工程范型结构化开发范型特征：结构化技术要么面向行为，要么面向数据构成结构化开发范型的技术包括：结构化分析（SA）结构化设计（SD）结构化编程（SP）结构化测试（ST）结构化维护（SM）1.4软件工程范型面向对象范型特征：将对象视作一个融合了数据及在其上操作的行为的、统一的软件组件。技术包括：面向对象分析（OOA）面向对象设计（OOD）面向对象编程（OOP）面向对象测试（OOT）面向对象维护（OOM）优势：对象的概念符合业务或领域的客观实际维护容易1.5软件工程基本活动沟通计划建模实现部署维护管理过程改进小结软件工程的是主旨以工程化的思想进行软件开发，以生产高质量和高效率的软件。软件工程化思想的核心是，把软件看作是一个工程产品。软件工程方法学分别是结构化开发范型和面向对象开发范型。第2章软件过程与模型内容提要软件生存周期软件过程与框架软件过程选择与评估软件能力成熟度模型软件过程模型传统的软件过程模型面向对象过程模型2.1软件生存周期软件也有一个从生到死的过程，这个过程一般称之为软件的软件生存周期或生命周期（SoftwareDevelopmentLifeCycle）软件生存周期可划分为定义、开发和运行三个时期，每个时期又细分为若干个阶段。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。软件生存周期包括问题定义与可行性分析、软件项目计划、需求分析、软件设计、实现与测试、运行与维护等阶段，每个阶段有包含一系列的活动。2.2软件过程与框架定义：软件过程是为了开发出软件产品，或者是为了完成软件工程项目而需要完成的有关软件工程的活动通常使用生存周期模型简洁地描述软件过程层次：软件工程是一门建立在以质量焦点为基础的层次化综合技术过程:定义阶段和管理方法:技术支持工具:自动化实施支持软件过程框架与管理定义：框架是实现整个软件开发活动的基础，并且那些与过程有关的角色、职责的定义以及实现也都离不开框架的支持两个方面的内容组织及管理框架技术及工具框架软件过程环境组织、管理的角色和职责技术环境软件过程框架组织与管理框架：过程改进活动及角色与职责技术与工具框架：技术及自动化活动工具框架活动：沟通策划建模构建部署软件过程框架包括一组普适的过程、活动和任务。具体包括：系统语境的过程协议过程组（2个过程，13个活动，52个任务）项目过程组（7个过程，23个活动，72个任务）技术过程组（11个过程，26个活动，64个任务）组织上项目使能过程组（5个过程，15个活动，48个任务）针对软件开发的过程软件实现过程组（7个过程，7个活动，39个任务）软件支持过程组（8个过程，25个活动，68个任务）软件复用过程组（3个过程，14个活动，62个任务）整个系统的生存周期包括了43个过程、123个活动和405项任务。2.3软件过程选择与评估软件过程选择把软件看成产品，必然注重软件的质量，决定了软件过程、周期和成本。产品依赖过程，其就是过程定义的一系列活动和任务的结果。软件产品越复杂，其开发周期也越长，开发成本越高。当软件比较复杂，开发周期比较长（一般持续一年及以上），开发成本比较高时，团队就要选择重型软件过程，比如螺旋模型或者统一过程模型等。当软件较为简单或需求比较稳定时，一般开发周期也比较短（三个月以内），开发人员也比较少（一般4-8人），这样的软件就可以采用轻型软件过程，比如极限编程方法或者瀑布模型等。软件过程评估产品与过程选择软件过程过程评估CMMI/CMMISO9001:2000个人软件过程团队软件过程个人软件过程（PSP）PSP0是PSP的个人度量过程，其目的是建立个体过程基线。PSP1是个人规划过程，引入了基于估计的计划方法PROBE，用自己的历史数据来预测新程序大小和开发时间，并使用线性回归方法估计参数，确定置信区间以评价预测的可信程度。PSP2是个人质量管理，根据程序的缺陷建立检测表，按照检测表进行设计复查和代码复查，以便及早发现缺陷，使修复缺陷的代价最小。PSP3的目标是把个体开发小程序所能达到的生产效率和生产质量，延伸到大型程序。团队软件过程(TSP)TSP采用了循环递增的开发策略，整个软件生产过程由多个循环出现的开发周期组成，每个开发周期划分出若干个相对独立的阶段。TSP提供了如下方法：计划评审设计和编码标准设计和代码评审方法缺陷评审质量分析2.4软件能力成熟度模型CMM(CapabilityMaturityModel)是指“能力成熟度模型”CMM是由美国卡内基－梅隆大学的软件工程研究所（SEI）开发的软件成熟度模型。思想：管理软件过程的方法不当引起的问题，导致新软件技术的运用并不会自动提高软件的生产率和质量。CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架。能力成熟度模型集成（CMMI--CapabilityMaturityModelIntegration）是CMM模型的最新版本。什么是CMM？为企业的发展规定过程成熟级别，分为5级（Version1.0）：初始级（Initial）：一般企业皆具有可重复级（Repeatable）：成功经验可以重复定义级（Defined）：一套完整的企业过程，人员自觉遵守（培训）管理级（Managed）：过程&产品可度量和控制优化级（Optimizing）：过程持续改进从无序到有序、从特殊到一般、从定性管理到定量管理、最终达到动态优化CMM基本内容2.Repeatable1.Initial3.Defined4.ManagedDisciplinedProcessStandard,ConsistentProcessPredictableProcessContinuouslyImprovingProcessUnpredictableandpoorlycontrolledCanrepeatpreviouslymasteredtasksProcesscharacterized,fairlywellunderstoodProcessmeasuredandcontrolledFocusonprocessimprovement5.OptimizingProjectManagementIntegratedEngineeringProcessProductandProcessQualityManagingChangeDisorder

Disciplined

Predictable

Immature

Mature

CMM基本内容关键过程域KPA：代表一组相关的工作（活动）。每个KPA都有一个确定的目标，完成该目标即认为过程能力的提高。一般特性CF（CommonFeatures）：进一步细分KPA的工作。五个特性：承诺（commitment）准备（ability）执行（activity）度量分析（measurement&analysis）验证（verifyingimplementation）CMM的五个级别Level1：初始级过程无序且不可见OutInCMM的五个级别Level2：可重复级Milestone可见，按计划开发CMM的五个级别Level2的6个KPA：侧重于管理需求管理（RequirementsManagement）软件项目计划（SoftwareProjectPlanning）软件项目的跟踪和监控（SoftwareProjectTackingandOversight）软件子合同管理（SoftwareSubcontractManagement）软件质量保证（SoftwareQualityAssurance）软件配置管理（SoftwareConfigurationManagement）CMM的五个级别Level3：定义级每个阶段的内部活动可见标准过程和项目定义过程裁剪CMM的五个级别Level3的7个KPA：工程过程＋企业理念机构过程关注（OrganizationProcessFocus）机构过程定义（OrganizationProcessDefinition）培训计划（TrainingProgram）集成软件管理（IntegratedSoftwareManagement）－过程裁剪和定义软件产品工程（SoftwareProductEngineering）－过程执行组间协调（IntergroupCoordination）对等审查（PeerReviews）CMM的五个级别Level4管理级过程可度量，预测值与结果之间的偏差可控CMM的五个级别Level4的2个KPA：预测＋量化管理定量过程管理（QuantitativeProcessManagement）－过程度量软件质量管理（SoftwareQualityManagement）－产品度量CMM的五个级别Level5优化级过程动态调整、新技术的采用CMM的五个级别Level5的3个KPA：动态优化缺陷预防（DefectPrevention）技术改变管理（TechnologyChangeManagement）过程改变管理（ProcessChangeManagement）能力成熟度模型集成CMMI--CapabilityMaturityModelIntegration是CMM模型的最新版本。CMMI有两种表示方法：和软件CMM一样的阶段式表现方法连续式的表现方法过程管理项目管理工程支持CMMI的目标是质量、时间表和最低的成本关键实践CMM结构CMM标准的使用软件过程的改进(SPI，SoftwareProcessImprovement)软件过程评估(SPA，SoftwareProcessAssessment)软件能力评价(SCESoftwareCapabilityEvaluation)2.5软件过程模型把软件生命周期中各项开发活动的流程用一个合理的框架—开发模型来规范描述，这就是软件过程模型,也称为软件生命周期模型.软件过程模型是一种就是软件过程抽象.软件过程模型是从一个特定的角度表现一个过程，一般使用直观的图形标识软件开发的过程，主要根据软件的类型、规模，特别是软件的开发方法、开发环境等多种因素确立过程模型。2.6传统的软件过程模型瀑布模型增量模型螺旋模型瀑布模型瀑布模型将软件生命周期划分为软件计划、需求分析和定义、设计、实现、测试、运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈.瀑布模型示意图瀑布模型它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的。每个阶段都会产生循环反馈各个阶段产生的文档是维护软件产品时必不可少的，没有文档的软件几乎是不可能维护的。瀑布模型是一种文档驱动的过程模型瀑布模型特点顺序性和依赖性推迟实现质量保证的观点是一种线性模型强调文档的作用增量模型增量模型（IncrementalModel）也称为渐增模型，是在项目的开发过程中以一系列的增量方式开发系统。软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.增量方式包括：增量开发：以一定的时间间隔开发部分工作软件增量提交：以一定的时间间隔增量方式向用户提交工作软件及相应文档增量模型融合了线性顺序模型的基本成份和原型实现模型的迭代特征。增量模型分为渐增模型和原型模型渐增模型是瀑布模型的变种，有两类渐增模型：增量构造模型：它在瀑布模型基础上，对一些阶段进行整体开发，对另一些阶段进行增量开发。前面的开发阶段按瀑布模型进行整体开发，后面的开发阶段按增量提交。演化提交模型：它在瀑布模型的基础上，所有阶段都进行增量开发，也就是说不仅是增量开发，也是增量提交。增量构造模型需求分析设计编码1测试1测试2编码2编码3测试3螺旋模型螺旋模型（SpiralModel）是结合了瀑布模型和快速原型模型的迭代开发模型强调了其他模型均忽略了的风险分析：风险识别风险分析风险控制特别适合于大型复杂的系统每一个周期都包括需求定义、风险分析、工程实现和评审螺旋模型示意图螺旋模型活动四个象限分别代表了以下活动：制定计划：确定软件目标，选定实施方案，确定项目开发的限制条件；风险分析：分析评估所选方案，考虑如何识别和消除风险；实施工程：实施软件开发和验证；客户评估：评价开发工作，提出修正建议，制定下一步计划。螺旋模型是风险驱动的模型2.7面向对象过程模型面向对象是一种的程序设计方法，或者说它是一种程序设计范型。基本思想是使用对象，类，继承，封装，消息等基本概念来进行程序设计。面向对象的要素：抽象：强调实体的本质、内在的属性，忽略一些无关紧要的属性。类实现了对象的数据（即状态）和行为的抽象，是对象的共性的抽象。封装性：指所有软件部件内部都有明确的范围以及清楚的外部边界。共享性：面向对象的特征：对象惟一性；分类性；继承性；多态性（多形性）。构件集成模型构件集成模型是基于构件的开发模型构件集成模型：整个系统模块化复用构件库中的软件构件构件集成模型是演化形的，开发过程是迭代的5个阶段：软件的需求分析和定义体系结构设计构件库建立应用软件构建测试和发布构件集成模型需求分析和定义体系结构设计构件库建立测试和发布应用软件构建1：N统一过程Asoftwaredevelopmentprocess：是一个将用户需求转化为软件系统所需要的活动的集合。Aprocessframework：一个简单的过程，也是一个通用的过程框架。Component-based：软件构件+接口Thestandard--employingtheUML（UnifiedModelingLanguage）use-casedrivenarchitecture-centriciterativeandincremental发展过程1967:apredecessorofObjectory1976-80:formalization&generalization1997:Objectory4.11987-95:Objectory1.0-3.8SDLAbook:TheUnifiedProcessAproduct:TheRationalUnifiedProcess1998:UnifiedProcessOMTBoochRational’sbestpractices:KruchtenRoyceandmanyothersTheNextIndustryStandardASoftwareDevelopmentProcessSoftwaredevelopmentistheprocessofdevelopingsoftwarefromrequirements.NeworchangedrequirementsNeworchangedsystemSoftwareDevelopmentProcess统一过程是用况驱动的用况模型(usecasemodel)要素:用户（user）用况（usecase）动作（action）用况驱动（use-casedriven）：用况可以驱动开发过程：用况不只是确定系统需求的工具，还能驱动系统设计、实现和测试的进行。不能孤立地选择用况统一过程是以构架为中心的软件构架包含了系统中最重要的静态和动态特征构架刻画了系统的整体设计，突出系统的重要特征构架的价值依赖于执行该任务的人的素质过程可以帮助构架设计师确定正确的目标用况和构架的关系：用况对应功能构架对应表现形式用况和构架相互影响，并必须进化统一过程是以构架为中心的构架设计师应遵循的四个步骤：针对通用用况，创建一个粗略的构架轮廓处理已经确定的重要用况子集用况完善继续上述过程…统一过程是迭代和增量的划分为袖珍项目（mini-project）:一个增量的迭代过程迭代是指工作流中的步骤,迭代过程必须是受控的目标：处理一组过程,风险分析做法：标识与描述用况选定构架创建设计选择构件实现设计验证PhasesintheSoftwareLifecycleTheUnifiedProcesshasfourphases:Inception—DefiningthescopeoftheprojectElaboration—Planning,specifyingfeaturesanddesigningarchitectureConstruction—BuildingtheproductTransition—TransitioningtheproductintoitsusercommunitytimeInceptionElaborationConstructionTransitionMajormilestones统一过程模型统一过程（UnifiedProcess，UP)是风险驱动的、基于用况技术的、以架构为中心的、迭代的、可配置的软件开发流程。统一过程是以用况驱动的，以构架为中心，迭代和增量的过程。统一过程是一个软件开发过程，是一个通用的过程框架：初始细化构造移交统一过程的四个阶段统一过程五个核心工作流需求捕获(RequirementsCapture)：致力于开发正确的系统分析(Analysis)：更精确地理解需求设计(Design)：深入理解与非功能性需求和约束相联系的问题实现(Implementation)：实现系统与集成测试(Test)：验证实现的结构核心工作流软件开发的四个要素人员项目产品过程人员至关重要开发过程影响人员角色会发生变化角色实例项目创造产品三要素：一系列变化一系列迭代组织模式产品不仅仅是代码软件系统制品系统包含一组模型什么是模型？视图模型内部模型间的关系过程指导项目过程：一个模板过程过程实例软件开发过程工作流过程具体化过程的价值工具用况驱动开发统一过程的目标：指导开发人员有效地实现并实施满足客户需求的系统。效率：成本、质量、交付时间用况驱动开发RequirementsAnalysis&DesignImplementationTestUseCasesbindtheseworkflowstogether模型用况模型分析模型设计模型实现模型实施模型测试模型小结大多数软件开发过程都有一个共同的软件过程框架软件开发模型是指软件开发全部过程、活动和任务的结构框架，表达软件开发全过程，规定了要完成的主要活动和任务，用来作为软件项目工作的基础。软件过程分为个人软件过程PSP和团队软件过程TSP。CMM为软件企业的过程能力提供了一个阶梯式的改进框架，包括初始级、可重复级、已定义级、可管理级和优化级5个级别。软件过程模型的选择取决于软件的特性和开发团队的特性。对于开发大型复杂的软件，建议采用重型软件过程模型，如螺旋模型、统一过程模型等；对于需求稳定或简单的软件，建议采用轻型软件过程模型，如极限编程、瀑布模型等。第3章敏捷软件工程方法内容提要：敏捷软件工程过程SCRUM软件开发过程极限编程结对编程3.1敏捷软件工程过程敏捷不是一个过程，是一类过程的统称。敏捷方法的两大主要特征：对“适应性”的强调对“人”的关注做法：快速响应:引入迭代式的开发手段将整个软件生命周期分解为若干个小的迭代周期获取切实有效的客户反馈提出12条基本原则敏捷开发12条原则我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。围绕被激励起来的个体来构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。敏捷开发12条原则(续)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。工作的软件是首要的进度度量标准。敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。不断地关注优秀的技能和好的设计会增强敏捷能力。

简单是最根本的。

最好的构架、需求和设计出于自组织团队。

每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。3.2SCRUM软件开发过程Scrum是一种迭代式增量软件开发过程，适合于敏捷软件开发。Scrum的基本假设：开发软件就像开发新产品，无法一开始就能定义软件产品最终的方案，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证方案成功。Scrum有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。Scrum角色主管产品负责人开发团队Scrum术语订单backlog:可以预知的所有任务，包括功能性的和非功能性的所有任务。冲刺sprint:一次跌代开发的时间周期。冲刺订单sprintbacklog:一个sprint周期内所需要完成的任务。主管scrumMaster:负责监督整个Scrum进程，修订计划的一个团队成员。时间盒time-box:一个用于开会时间段。冲刺计划会sprintplanning会议每日立会DailyScrum会议冲刺评审会Sprintreview会议冲刺反思会Sprintretrospective会议实施Scrum的过程分解产品订单成冲刺订单召开冲刺计划会议进入冲刺开发周期，每天需要召开立会整个冲刺周期结束，召开冲刺评审会团队召开冲刺反思会。。。以上循环进行Scrum文档产品订单文档冲刺订单文档燃尽图3.3极限编程极限编程（eXtremeProgramming，XP）是一种软件工程方法学，是敏捷开发中最富有成效的方法学之一由KentBeck在1996年提出具有强沟通、简化设计、迅速反馈等特点适合于规模小、进度紧、需求不稳定、开发小项目的小团队。极限编程特点：XP模型是“轻量型”或“灵活”的软件过程模型与面向对象语言结合的开发方案“专家协作”的开发方式，解决难点问题重视客户反馈核心有四个要点：交流简单反馈勇气交流开发人员与客户的交流开发人员之间的交流使用结对编程开发人员与管理人员的交流简单设计的简单编码的简单注释的简单测试的简单反馈客户对软件的反馈测试代码对功能代码的反馈先测试，后编程勇气接受任务的勇气XP常见问题XP适合于小型项目（10人左右）?结对编程，搭档如何安排?实施结对编程、集体代码所有权之后，如何考核单个开发人员？

993.4结对编程

(PairProgramming

)什么是结对编程结对编程(Pair-Programming)是XP中非常重要的实践之一。定义：两个人坐在同一台计算机前面，使用相同的键盘和鼠标来开发同样的一个模块，一个称为驾驶者(Driver)，负责代码的键入，另外一个称为领航员(Navigator)，负责监看与决策，包括低级错误和方向性的错误。当出现的一个问题对其中一个人来说，难以解决，而恰好是另外一个人的强项的时候，那么角色就会发生转换。PairProgramming的角色(Role)DriverTheonewhotypesNavigatorTheonewhowatchestheback角色可以互换的疑问：一个程序两个人写是不是一种浪费（可是两份工资，双倍资源哦）？编程从来是一个人的活动。学校里这么教的，一直以来也是做么做的。我不喜欢被人盯着工作，这样我不自在，无法工作。这个笨家伙老是问问题，他/她不会看书么？我都无法专心工作了。

……另一方面：

PairProgramming被很多的大师级程序员推崇；不少大学都展开对PairProgramming的研究，并得到正面的结论；很多尝试过的Developer都开始喜欢PairProgramming。PairProgramming的疑问PairProgramming和SoloProgramming的比较一些研究数据：

1999年，UniversityofUath.两组学生，一组独自工作，一组PairProgramming。不间断的CodeReview1.PeerCodeReview，即程序员之间的互相Review缺乏DesignReview不能持久,定时CodeReview对需求和设计的不了解导致无法实现有效的Review2.TeamCodeReview什么时候开会做Review？不可能Team天天开会无法对所有的设计和Code进行Review面子问题效率低传统开发过程的Review（例如印度的InfoSys公司）的问题：不间断的CodeReview

提供不间断的Designreview，UnitTestReview，CodeReview，DocumentReview，避免了效果差的TeamCodeReview，也比抽查式的PeerCodeReview有更好的质量。 PairProgramming中，任何一段代码都至少被两双眼睛看过，两个脑袋思考过。代码被不断的Review。

编程方式避免cowboy式的编程好代码的衡量标准：可读性和可维护性对大部分的商业项目来说，更主要的顾虑是成本。好的代码可以减少修改的成本。互相督促可以提高代码的可读性。

以人为本同伴的潜在压力(PeerPressure)。PairProgramming的过程也是一个互相督促的过程。由于这种督促的压力，使得程序员更认真的工作。每个人每天的有效工作时段不超过3-4个小时。PairProgramming中Driver和Navigator的互换可以让程序员轮流工作，从而避免出现过度思考而导致观察力和判断力出现偏差。潜意识的有利竞争。当人在一个团队中工作，总是下意识的努力展现自己的优点。工作及时得到同伴的肯定，自信心和成就感(Self-Satisfaction)增强。觉得工作是一件愉快(Enjoyable)的事情。结对建议ExtremeProgramming对实施的程序员提出了更高的要求。这种要求不是技术水平，也不是学历水平也不是工作经验。这种要求是对一个人的心智，道德，修养的更高要求。程序员的四怕：

1)怕自己看上去傻

2)怕被认为是没用的

3)怕自己变的不重要（过时）

4)怕自己不够好PairProgramming中，编码不再是私人的工作，而是一种公开的“表演”。程序员的代码，工作方式，技术水平都变得公开和透明。开发人员素质

一个XP开发人员具备这样一些基本素质：诚实，公正，开明，勇敢和谦卑！在这些素质的基础之上，才是对技术水平，能力和天分等的要求。诚实

公正开明勇气

谦卑具备这些素质才能克服“四怕”，才能成为一个成熟和专业的Developer。如何结对编程Driver–写设计文档(Classdiagram等)，进行编码(UnitTestandBusinessObject)等XP开发流程。Navigator–审阅Driver的文档、Driver对编码等开发流程的执行；考虑UnitTest的覆盖程度；是否需要和如何Refactoring；帮助Driver解决具体的技术问题。Driver和Navigator不断轮换角色，不要连续工作超过一小时，每一小时休息15分钟。Navigator要控制开发时间。

111没有结对编程就没有XPPairProgramming是XP所有的Practices中最被争议和被认为是最难接受。PairProgramming是获得XP最大价值的关键。没有PairProgramming,无法实现有效的ContinuousCodeReview,代码质量下降。没有PeerPressure，流程的执行很容易出现偏差。没有PairProgramming，Communication很容易弱化，进而影响Teamwork。PairProgramming象XP流程中的粘合剂，把各个环节连接起来实现最大的价值。

112没有结对编程就没有XP这是引进XP时最难被接受的规则。但如果在采用其它XP的惯例和规则时，抛弃PairProgramming，那么会面对以下问题：如何进行有效的DesignReview如何进行有效的CodeReview如何保证代码质量如何保证流程的执行如何增进Communication如何进行Cross-Training如何增强TeamworkDistributedPairProgramming分布式的PairProgramming:两个Programmers身处不同的物理位置，通过Sharing软件来实现PairProgramming。需要Sharing软件能提供桌面共享，文字交谈，语音交谈，甚至是视频交流。目前这种方法还没有被认可，主要出现在学校的关于XP的研究项目中.面临的问题：Internet的网路延迟工作时段的约定PairProgramming和SoloProgramming的比较比较研究项目后的问卷调查发现：PairProgramming能用较少的时间生产更高质量的代码。PairProgramming的学生们认为自己比一个人的时候更勤奋和更聪明的工作，因为不想让自己的partner失望。PairProgramming的学生认为自己比一个人的时候更专著,紧凑和由纪律的工作，而且是持续的（因为来自Partner的Pair-Pressure）。而独立工作的学生也可以专著和紧凑的工作，但往往不持续。PairProgramming的学生对自己的工作更有信心和成就感。PairProgramming的学生觉得工作很愉快，很愿意很partner一起工作。在紧张时间安排和繁重的工作压力下，独自工作的学生很容易蜕变为没有纪律的Programmer。PairProgramming是个渐进的过程有效率的PairProgramming不是一天就能做到的。PairProgramming是一个相互学习，相互磨合的一个渐进过程。Developers需要时间来适应这种新的开发模式。刚开始的PairProgramming很可能不比SoloProgramming有更高的效率。但适应后的Pairs的开发质量和开发时间都比SoloProgramming有大幅度的改善。结对编程优势：可以减少风险可以使团队生产效率更高是知识传播的最好途径可以打造出最佳的合作团队。可以生成更好的代码三个方面的应用：教育学结对学习工业界结对开发与编程分布式结对编程环境结对编程与测试驱动开发测试驱动开发（TestDrivenDevelopment,TDD）思想：开发之前首先完成测试用例编写；然后编写代码和测试；测试通过后即需增加新功能。优势：测试优先，保证质量结合结对编程结对编程与代码重构重构就是代码的重新设计。目的：得到好的代码和架构，易修改、易理解适应需求结对编程：审查代码理解代码反馈结对编程与简单设计简单设计：达到目前需求即可结对编程可以达到简单结对编程方法面对面结对编程分布式结对编程小结软件工程是一种层次化技术，包括过程、技术和工具。软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程框架定义了若干个小的框架活动，为完整的软件开发过程建立了基础。软件过程框架的通用过程框架活动包括沟通、计划、建模、构建和部署。敏捷方法是一组敏捷实践技术的总称，包括极限编程、Scrum方法、结对编程等等。第4章

需求获取内容提要关于用户需求和软件需求需求获取过程基于会谈的需求获取方法基于调查的需求获取方法基于场景的需求获取方法基于用例的需求获取方法4.1关于用户需求和软件需求用户需求：业务需求与源于系统的特定领域的需求用户需求是站在用户角度描述软件必须要完成的业务需求，通过使用实例文档或场景说明中予以详细描述。软件需求：从软件角度来看，用户希望软件能够完成哪些功能和受到哪些约束，称为软件需求功能需求：描述系统预期提供的功能或服务非功能需求：指那些不直接与系统具体功能相关的一类需求业务需求领域需求反映应用领域的基本问题，直接影响到系统的可用性。例如：图书馆系统的功能需求基于标准用户界面将一些文档输出到本地打印机或网络打印机上，但因为版权限制，这些文档打印之后应立即删除。功能需求软件系统的功能需求描述可以有许多方式：文字描述图表表示功能需求可以以不同的详细程度反复编写和细化功能需求描述应该完整而且一致和准确完整性意味着用户所需的所有的服务应该全部给出描述一致性意味着需求描述不能前后矛盾准确性是指需求不能出现模糊和二义性的地方4.2需求获取过程需求获取主要是理解客户需要什么、分析要求、评价可行性、协商合理的方案、无歧义地详细说明方案、确认规格说明、管理需求以至将这些需求转化为可行系统.过程包括：沟通导出需求精化需求可行性研究与客户和用户协商编写需求规格说明验证需求管理需求沟通业务领域的共利益者（如业务管理人员，市场营销人员，产品管理人员）定义业务用例确定市场的范围初略地可行性分析确定项目范围的工作说明导出需求导出需求应理解问题范围问题：系统的边界，是客户和开发者共同关心的部分理解问题：确定业务需求、需求冲突、说明有歧义和不可测试的需求易变问题：分清需求稳定部分和易变部分收集活动：识别真正的客户/用户正确理解客户的需求耐心听取客户意见和思考尽量使用符合客户语言习惯的表达精化需求开发一个精确的技术模型，用以说明软件的功能、特征和约束。精化是一个分析建模动作，由一系列建模和求精任务构成定义了问题的信息域，功能域和行为域可行性研究可行性研究的目的是确定用最小的代价，在尽可能短的时间内确定问题是否能够解决可行性研究的输入是系统的一个框架描述和高层逻辑模型输出是一份需求开发评价报告，对需求工程和系统开发是否值得做的具体建议和意见三个问题：系统是否符合机构的总体要求？系统是否可以在现有的技术条件、预算和时间限制内完成？系统能否把已存在的其他系统集成？与客户和用户协商调节冲突和问题需求排序识别和分析与每项需求相关的风险、开发工作量、成本和交付时间编写软件需求规格说明一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或以上各项的任意组合。软件需求规格（SRS，SoftwareRequirementSpecification）是需求分析任务的最终“产品”，它是客户、管理者、分析工程师、测试工程师、维护工程师交流的标准和依据。软件需求规格描述了系统的数据、功能、行为、性能需求、设计约束、验收标准、以及其他与需求相关的信息。SRS模板，包括用户需求和系统需求（表4-1）需求规格文档标准（表4-1）1引言1.1编写目的1.2项目背景（单位和与其他系统的关系）1.3定义（专门术语和缩写词）2任务概述2.1目标2.2运行环境2.3条件限制3数据描述3.1静态数据3.2动态数据3.3数据库描述3.4数据字典3.5数据采集

4功能需求

4.1功能划分4.2功能描述5性能需求5.1数据精确度5.2时间特性5.3适应性6运行需求5.1用户界面5.2硬件接口5.3软件接口5.4故障处理7其他需求（检测或验收标准、可用性、可维护性可移植性、安全保密性）验证需求验需求证对需求文档和制品进行质量评估，确保需求说明准确、完整.包括以下内容：正确性一致性完整性可行性必要性可检验性需求的可跟踪性最后签字确认管理需求管理需求是组织、控制和文档化需求的系统方法.建立基线以便在客户和开发人员之间构建一个约定.需求管理从标识开始，建立跟踪表.需求跟踪表可以跟踪需求的特征、来源、依赖、子系统和接口等关系.4.3基于会谈的需求获取方法非正式会谈：提出一些可自由回答的问题.正式会谈：提出一些事先准备好的议题.情景分析：需求分析从对场景的评论中得到信息，然后再将其以形式化方式表示出来。使用用例建立原型界面序列执行过程视点分析接受系统服务的当前银行客户；银行间自动柜员机有互惠协议的其他银行的代表；从该系统中获得管理信息的银行支行管理者；负责系统日常运转和处理客户意见的支行柜台职员；负责系统和客户数据库集成的数据库管理者；负责保证系统信息安全的银行信息安全管理者；将该系统视为银行市场开拓手段的银行市场开发部；负责硬件和软件维护及升级的硬件和软件维护工程师多视点的需求分析过程视点识别：包括发现接收系统服务的视点和发现提供给每个视点的特别服务。视点组织：包括组织相关的视点到层次结构中，通用的服务放在较高的层次，并被较低层次的视点继承。视点文档编写：包括对被识别的视点和服务描述的精炼。视点系统映射：包括在面向对象设计中通过封装在视点中的服务信息识别对象。4.4基于调查的需求获取方法制定调查表可靠可信分析4.5基于场景的需求获取方法分析员与项目相关人员共同识别出情景，并捕获这些情景的细节把细节加入到一个纲要的需求描述中时，情景特别有用情景是对交互实例片断的描述，每个情景可能包含一个或多个交互，它们能在不同的细节层次上提供不同类型的情景信息情景开始于一个框架，在导出过程中，细节被逐渐增加，直到产生交互的一个完整的描述情景内容在情景开始部分有一个系统状态描述；关于标准事件流的描述；关于哪儿会出错，以及如何处理错误的描述；有关其他可能在同一时间进行的活动的信息；在情景完成后系统状态的描述场景名：取款参与者：银行客户场景描述：1．插入有效的银行卡；2．ATM机验证该银行卡；3．系统要求输入银行卡密码，用户输入密码；4．系统通过网络向银行内部系统请求验证密码；5．若验证通过，系统请求选择业务，选择取款；6．系统要求输入取款金额，比如1000元；7．系统验证是有足够的现金，并请求验证银行内部服务器处理取款；8．若处理成功，系统计算钞票数目，并送出现金；9．用户取走现金；10．系统打印凭条，用户取走凭条；11．系统退出银行卡，用户取走银行卡。4.6基于用例（用况）的需求获取方法需求捕获的目标：发现真正的需求以适用于用户、客户和开发人员的方式加以表示系统用户表示为一个参与者参与者在与用例进行交互时使用系统用例向参与者提供某些有价值结果而执行一些动作序列用例分析过程用例建模分析开发活动图开发泳道图用例分析用例着眼于为用户增加价值，提供了一种捕获功能需求的系统且直观的方法，可驱动整个开发过程。用例从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。要开始开发用例，应列出特定参与者执行的功能或者活动。用例模型帮助客户、用户和开发人员在如何使用系统方面达成共识。用例图描述部分用例模型，显示带有联系的用例和参与者的集合POS机系统用例建模POS机系统是电子收款机系统，通过计算机化用于处理销售和支付，记录销售信息。该系统包括计算机、条码扫描仪、现金抽屉等硬件，以及使系统运转的软件和为不同服务的应用程序提供接口。POS机系统为例说明用例建模分析过程。POS机系统的问题描述收银员可以记录销售商品信息，系统计算总价。收银员能够通过系统处理支付，包括现金支付、信用卡支付和支票支付。经理还能处理顾客退货。系统要求具有一定的容错性，即如果远程服务（如库存系统）暂时中断，系统必须仍然能够获取销售信息并且至少能够处理现金付款。POS机必须支持日益增多的各种的客户终端和接口，比如多种形式的用户图形界面、触摸屏输入、无线PDA等。系统需要一种机制提供灵活的处理不同客户独特的业务逻辑规则和定制能力。POS机系统部分用例图用例图用例图包括：参与者、用例、关联和边界四个要素。参与者：用小人形表示用例：用椭圆表示关联：用直线表示说明参与者驱动某个用例边界：用矩形框表示，说明系统关注点。开发用例用例使用非正式的描述性风格编写，也可以使用某个结构化的格式编写，有些格式更强调描述的直观性。用例不同部分说明用例名称以动词开始描述用例名称范围要设计的系统级别“用户目标”或者是“子功能”主要参与者调用系统，使之交付服务渋众及其关注点关注该用例的人，及其需要前置条件开始前必须为真的条件成功保证成功完成必须满足的条件主成功场景典型的、无条件的、理想方式的成功场景扩展成功或失败的替代场景特殊需求相关的非功能性需求技术和数据变元素不同的I/O方法和数据格式发生频率影响对实现的调查、测试和时间安排杂项未决问题等用例场景用例名称：处理一次销售范围：POS机应用级别：用户目标主要参与者：收银员涉众及其关注点：收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。售货员：希望自动更新销售提成顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即便在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。前置条件：收银员必须经过确认和认证。成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，生成票据，记录支付授权的批准。主成功场景1.顾客携带所购商品或服务到收银台通过POS机付款。2.收银员开始一次新的销售交易。3.收银员输入商品条码。4.系统逐步记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复3~~4步，直到输入结束。5.系统显示总额和计算折扣。6.收银员告知顾客总额，并请顾客付款。7.顾客付款，系统处理支付。8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。9.系统打印票据。10.顾客携带商品和票据离开。开发活动图UML活动图通过提供特定的场景内交流的图形化表示来补充用例。活动图符号：两端为半圆形的矩形表示一个特定的系统功能箭头表示通过系统的流判定菱形表示判定分支水平线、分叉点和连接表示并发活动对象节点表示活动对象活动图通常能够既表示控制流又表示数据流。UML活动图代替传统的数据流图（DataFlowDiagram）表示法处理销售用例活动图泳道图UML泳道图（swimlane）是活动图的一种有用的变形可以让建模人员表示用例所描述的活动图，同时看哪个参与者或分析类对活动矩形所描述的活动负责。泳道用纵向分割图的并列条形部分表示，就像游泳池中的泳道，也称特定分区。UML泳道图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值。泳道图小结需求分析也称为需求工程，是一个非常重要而有很复杂的，需要交替进行，反复迭代的过程。从用户角度看，需求分为业务需求和用户需求，从软件角度看，需求分为功能需求和非功能需求。需求分析过程分为沟通、导出需求、精化需求、可行性研究、与客户和用户协商、编写规格说明、验证需求和管理需求等活动。需求获取方法主要包括会谈、调查表、场景分析和用例分析等。用例建模根据外部使用者从使用系统或业务分析出发，抽取出系统的业务需求和领域要求，并精化为系统的需求。用例模型包括用例视图模型、用例场景和用例活动图或泳道图。第二部分结构化软件工程范型结构化软件分析与设计要建立哪些模型？概要设计与详细设计的关系是什么？软件概要设计主流的技术是什么？软件详细设计主流的技术是什么？软件测试包括哪些过程和主要技术？关注一下问题内容提要：结构化分析概述结构化分析模型数据流分析方法数据建模分析方法状态分析方法结构化分析过程软件需求规格说明文档第5章结构化分析结构化分析（SA，StructuredAnalysis）方法是20世纪70年代，由E.Yourdon等人倡导的一种适用于大型数据处理系统的、面向数据流的需求分析方法。结构化分析方法是一种传统的软件建模技术，其过程是创建描述信息内容和数据流模型，依据功能和行为对系统进行划分，并描述必须建立的系统要素。5.1结构化分析概述充分理解问题开发快速原型描述软件需求建立软件高层模型确定软件需求优先级验证软件需求结构化需求分析指导性活动结构化分析方法是一种半形式化的分析与建模技术，其过程包括对软件相关的各种信息进行分析,抽取其本质特征,创建描述数据、功能和行为的模型。结构化分析模型的主要目标：描述客户的需要；为软件设计建立基础；定义在软件完成后可以确认的一组需求。5.2结构化分析模型系统模型从以下不同的角度表述系统：从外部来看，它是对系统分析上下文或系统环境建模；从行为上看，它是对系统行为建模；从结构上看，它是对系统的体系结构和系统处理的数据结构建模。结构化的需求分析模型：系统行为模型：数据流模型，用来描述系统中的数据处理过程状态转换模型，用来描述系统如何对事件做出响应实体—关系模型：关心的是寻找系统中的数据及其之间的关系，却不关心系统中包含的功能。5.2结构化分析模型数据字典实体-关系图数据流图加工规约数据对象描述状态转换图控制规约结构化分析模型结构分析模型结构的核心是数据字典（DD，DataDictionary），包含了软件使用或生产的所有数据对象描述的中心库。分析模型结构的中间层有三种视图：数据流图（DFD，DataFlowDiagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。实体—关系图（E-RD，Entity-RelationshipDiagram）描述数据对象间的关系，用来进行数据建模活动的记号。状态转换图（STD，StateTransitionDiagram）指明作为外部事件的结果，系统将如何动作。分析模型结构的外层是规约描述：在实体—关系图中每个数据对象的属性可以使用数据对象来描述。在数据流图中出现的每个加工/处理的功能描述包含在加工规约中。软件控制方面的附加信息包含在控制规约中结构化分析模型组成面向数据流的建模是一种结构化需求分析方法，简称数据流分析方法数据流分析方法采用自顶向下逐层分解，描绘满足用户要求的软件模型表示：数据流图：描述系统处理过程数据字典：模型中的数据信息集合5.3数据流分析方法数据源点或终点变换数据的处理数据存储数据流或或或数据流图：表示软件的行为模型数据字典是分析模型中出现的所有名字的一个集合，并包括有关命名实体的描述数据字典有以下两个作用：它是所有名字信息管理的有效机制作为连接软件分析、设计、实现和进化阶段的开发机构的信息存储数据字典应该由四类元素的定义组成：数据流数据流分量数据存储处理对于处理，可用输入—处理—输出（IPO，Input-Process-Output）视图描述更方便数据字典应对组成的数据元素定义进行自顶向下的分解。分解的原则是：当包含的元素不需要进一步定义，且每个和工程有关的人都清楚时为止数据字典中应该包括关于数据的信息：一般信息（名字、别名、描述等）定义（数据类型、长度、结构等）使用特点（值的范围、使用频率、使用条件、使用方式、条件值等）控制信息（用户、使用特点、改变数、使用权等）分组信息（文档结构、从属结构、物理位置等）三种类型的任意组合定义数据字典中的任何条目。顺序：顺序连接两个或多个分量元素。一般用加号表示顺序连接关系。选择：从两个或多个可选的分量元素中选取一个。选择运算符用方括号表示，对于多个可供选择的元素，用“|”符号分隔。例如，[A-1|A-2|A-3]表示三个可选数据元素。重复：描述的分量元素重复零次或多次。例如，

都表示数据元素A的下限为1，上限为5。数据字典数据流分析步骤数据流图要素分析：根据问题确定数据的源点、终点、数据流、数据存储和处理等。构建数据流图：根据数据流图要素绘制数据流图。建立数据字典：对数据流分析中所涉及的所有要素进行详细的规格描述。一个工厂采购部每天需要一张定货报表。零件的入库、出库事务通过计算机终端输入给定货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次定货。定货的零件数据有：零件编号、名称、数量、价格、供应者等。数据流分析：数据源点：仓管员（负责入库或出库事务给定货系统）；数据终点：采购员（接收每天的定货报表）；数据流：事务，定货；数据存储：定货信息，库存清单；处理：处理事务，产生报表。例5.1订货软件的数据流图画基本系统模型采购员事务定货报表仓管员订货系统第1次求精第2次求精数据字典卡片方式示例名字：订货报表别名：订货信息描述：每天一次需要订货的零件表定义：订货报表=1{零件信息}50

其中：

零件信息=零件编号+零件名称+数量+价格+1{供应者}3

分量定义：

零件编号=8位字符；

零件名称=20位字符；

数量=[1|2|3|4|5]；

价格={数值类型}；

供应者=24位字符位置：输出到打印机软件建模的一个重要方面就是要定义系统处理的逻辑结构。最广泛采用的数据建模技术是实体-关系模型，它描述数据实体、关联及实体属性。实体关系模型可用ERD（Entity-RelationshipsDiagram实体关系图）来表示：实体关联实体属性基数5.4数据建模分析方法例5.2图书馆管理系统实体关系图1借还记录预约记录借/还/续借

1M10..510包含预约借书者图书书目借书者：借书证号、姓名、性别、借书数、最大借书数、罚金金额、有效期。图书：书号、ISBN号、状态。书目：ISBN号、书名、作者、出版社、摘要、目录、丛书名、收藏数、在馆数、预约数。借还记录：书号、借书证号、借出日期、应还日期、续借次数。预约记录：ISBN号、借书证号、预约日期。实体属性状态分析方法主要任务是建立软件的状态模型。状态模型是一种描述系统对内部或者外部事件响应的行为模型。它描述系统状态和事件，以及事件引发系统在状态间的转换。这种模型适用于描述实时系统。状态机建模方法步骤：系统状态、行为与事件分析构建状态图5.5状态分析方法状态模型一般采用状态转换图（简称状态图）的标记方法状态图描述了系统中某些复杂对象的状态变化状态是可观察的行为模式，用圆角矩形表示；变迁表示状态的转换，用箭头表示；事件是引发变迁的消息，用箭头上的标记表示。状态图还可以用事件后的方括号表示先决条件，只有当这个条件为真时，才会发生状态变化；用状态自身的弧线箭头表示先决条件不为真时，状态不会改变。状态转换图问题描述在一幢有m层的大厦中安装一套n部电梯的产品，按照下列条件求解电梯在各楼层之间移动的逻辑关系：每部电梯有m个按钮，每一个按钮代表一个楼层。当按下一个按钮时该按钮指示灯亮，同时电梯驶向相应的楼层，当到达相应楼层时指示灯熄灭。除了最底层和最高层之外，每一层楼都有两个按钮分别指示电梯上行和下行。按下按钮后指示灯就开始亮，当电梯到达此楼层时指示灯熄灭，电梯暂停并执行开门和关门动作，并向所需要的方向移动。当电梯无升降运动时，关门并停在当前楼层。电梯系统状态分析电梯在运行过程一般具有下列状态：空闲:无请求时,电梯处于休息状态；暂停:上下乘客时,电梯处于暂停，开门和关门；上行:电梯处于向上运行状态；下行:电梯处于向下运行状态；处于第一层:初始启动,电梯会在第一层等待状态；向第一层移动：长时间

处于空闲时，电梯移动到第一层。

状态事件及行为分析电梯控制系统的事件有：向上：驱动电梯向上运行；向下：驱动电梯向下运行；停止：停止电梯运行；无请求：没有乘客请求乘坐电梯；长时间无请求：长时间没有乘客请求乘坐电梯。绘制电梯对象的状态图问题描述绘制数据流图确定计算机化部分定义数据定义处理逻辑定义物理资源确定输入和输出规格确定数据规模、格式、硬件要求编写规格说明书5.6结构化分析过程1、问题描述图书销售店从各出版社购买图书，并将其销售给大学、公司和个人客户。书店库存流行的图书，并根据需要订购其他图书。书店提供大学订购服务，并根据客户和订购量提供优惠。现在书店希望实现计算机化管理，将如何做？分析上述问题，确定需要有哪些商务功能（入账、出账和库存），系统是批处理方式还是联机方式，硬件设备情况，实现计算机化管理的目的是什么等目标。可以看出，其目的是为了销售图书和图书管理以及账目管理。例5.4书店图书销售软件结构化分析步骤

2、绘制数据流图系统的自动化方案选择，取决于客户的投资和目标。一般必须利用成本—效益分析对数据流图各个部分的操作分析决定以批处理方式还是以联机方式执行。

本例的第一个方案是以批处理方式处理出账、订购图书，用联机方式处理订单的有效性检查、聚集订单和开发货清单；第二个方案是除发货票据使用联机方式或批处理方式外，其余都用联机方式。3、确定需要计算机化部分本例的数据流和数据存储有“订单”、“图书数据”、“顾客数据”、“账目”、“发货清单”等等。4、定义数据确定了产品的数据元素，就可以分析每个处理具体做什么了。例如，分析“生成账目”中“给教育部门打折扣”细节。5、定义处理逻辑加工逻辑也称为过程说明，用于描述数据流图中加工逻辑的处理算法或过程处理逻辑的描述软件需求分析的描述通常采用一种规范的需求规格文档。需求规格说明文档，即软件需求规格说明书（SoftwareRequirementSpecification，SRS）是需求分析任务的最终“产品”。需求规格说明文档的读者5.7软件需求规格说明文档SRS描述要求SRS应满足以下各个方面的描述要求：l只叙述软件的外部行为l定义软件实现上的约束l是容易改变的l成为软件维护人员的参考工具l记录软件的整个生命周期l应对未料到的事件给出可接受的反应SRS标准内容SRS各个部分的简要介绍。（1）引言部分。陈述关于计划文档的背景和为什么需要该软件，解释软件是如何与其他软件协同工作的。（2）任务概述。陈述软件的目标、运行环境和软件的规模等。（3）数据描述。给出软件必须解决的问题的详细描述，并记录了信息内容和关系、输入/输出数据及其结构。（4）功能描述。给出解决问题所需要的每个功能，包括每个功能的处理过程、设计约束等。（5）性能需求。描述性能特征和约束，包括时间约束、适应性等。（6）运行需求。给出交互的用户界面要求，与其他软/硬件的接口，以及异常处理等。（7）其他需求。给出软件维护性各个方面的要求。结构化分析方法是一种自顶向下，逐步分解的面向数据和数据流的建模方法。结构化分析模型工具有数据流图、数据字典、实体关系图和状态转换图等。数据流图和数据字典常用于结构化分析，用于描述软件的数据处理及其流程的信息，它们一起被称为软件逻辑模型。实体关系图和状态转换图辅助描述软件所涉及的实体动态变化行为。小结内容提要结构化设计概述软件设计过程结构化设计原理模块独立性度量软件结构化设计软件详细设计第6章结构化设计6.1结构化设计概述软件设计是把软件需求“变换”为用于构造软件的蓝图。所以，它的“输入”是需求分析各种模型元素，“输出”是软件设计模型和描述。软件设计的目标是对将要实现的软件的体系结构、数据模型、软件模块间的接口，以及所模块采用的算法给出详尽的描述。软件设计任务：数据设计体系结构设计接口设计构件设计总体设计，也称为概要设计，软件结构设计，或高层设计。分析需求规格说明模块划分，形成具有预定功能的模块组成结构表示出模块间的控制关系给出模块之间的接口软件详细设计，也称为（模块）过程设计，或低层设计。设计模块细节确定模块所需的算法和数据结构等6.2软件设计过程方案设计方案选取推荐最佳方案功能分解和软件结构设计数据库设计编制设计文档审查和复审软件概要设计步骤详细设计是为软件概要设计阶段给出的软件结构图中的各个模块设计处理过程的细节，确定模块所需的算法和数据结构等。详细设计主要描述每个模块或构件的设计细节，主要包括模块或构件的处理逻辑、算法、接口等。详细设计的内容包括：（1）模块或构件描述：描述模块或构件的功能，以及需要解决的问题，这个模块或构件在什么时候可以被调用，为什么需要这个模块或构件。（2）算法描述：确定模块或构件的处理算法和步骤，包括公式、边界和特殊条件，甚至参考资料等。（3）数据描述：描述模块或构件内部的数据结构。详细设计可采用流程图、PDL语言、盒图、判定表等描述算法的图、表和伪代码来表示。设计过程不应该受“隧道视野”的限制设计对于分析模型应该是可跟踪的设计不应该从头做起