• 1.30 MB
  • 2022-04-29 14:13:34 发布

实用软件工程第3版课后习题答案_IT168文库.doc

  • 39页
  • 当前文档由用户上传发布,收益归属用户
  1. 1、本文档共5页,可阅读全部内容。
  2. 2、本文档内容版权归属内容提供方,所产生的收益全部归内容提供方所有。如果您对本文有版权争议,可选择认领,认领后既往收益都归您。
  3. 3、本文档由用户上传,本站不保证质量和数量令人满意,可能有诸多瑕疵,付费之前,请仔细先通过免费阅读内容等途径辨别内容交易风险。如存在严重挂羊头卖狗肉之情形,可联系本站下载客服投诉处理。
  4. 文档侵权举报电话:19940600175。
'《实用软件工程》第3版习题参考答案习题11.1开发文档都有哪些?用图示表示它们之间的关系。开发文档包括目标程序、源程序、详细设计说明书、概要设计说明书、需求规格说明书、用户需求报告、软件合同,它们之间的关系如下图所示。1.2简述软件工程研究的内容。软件工程研究的内容包括软件开发方法、软件开发模型、软件支持过程和软件管理过程。其中软件开发方法的内容又涵盖市场调研、正式立项、需求分析、项目策划、概要设计、详细设计、编程、测试、试运行、产品发布、用户培训、产品复制、销售、实施、系统维护、版本升级。常用的软件开发模型有瀑布模型、迭代模型、增量模型和原型模型。软件支持过程由所支持的CASE工具组成,常用的CASE工具有PowerDesigner和RationalRose。软件管理过程主要有CMMI、ISO9000、微软企业文化和敏捷文化现象。1.3详细解释软件的定义、程序的定义及软件工程的定义。软件的定义:软件=程序+数据+文档。这里的程序是指程序系统。这里的数据不仅包括初始化数据、测试数据,而且包括研发数据、运行数据、维护数据,也包括软件企业积累的项目工程数据和项目管理数据中的大量决策原始记录数据。这里的文档指的是软件开发过程中的分析、设计、实现、测试、维护文档、管理文档。现在有一种新提法正在引起关注,这种提法是:软件=知识+程序+数据+文档。程序是计算机为完成特定任务而执行的指令的有序集合。从应用的角度可理解为:面向过程的程序=算法+数据结构面向对象的程序=对象+信息面向构件的程序=构件+构架软件工程是研究软件开发和软件管理的一门工程学科。1.4软件工程的7+1条基本原理有什么现实意义? 软件工程的7条基本原理是在面向过程的程序设计时代(结构化时代)提出来的,但在面向数据和面向对象的程序设计的今天,它仍然有效。并且在军事上的实时跟踪监控系统中有很好的应用,而且随着软件的开发和管理的进步,它将不断完善和充实。请读者注意,作者在书中又新加入了第8条基本原理:软件工程中的二八定律,这是对基本原理的补充与发展。1.5读者认同“4种开发方法”的方法论和“五个面向”的实践论吗?为什么?“四种开发方法”是指“面向过程的方法、面向对象的方法、面向数据的方法、形式化方法”。面向过程的方法来源于面向过程的程序设计;面向对象的方法来源于面向对象的程序设计;面向数据的方法就是面向元数据的方法,它来源于关系数据库程序设计;形式化方法来源于离散数学中的集合运算和逻辑运算。四种方法各适用于不同的场合,各有优缺点,互相促进,构成开发方法论的多极化世界。“五个面向理论”是指“面向流程分析、面向数据设计、面向对象实现、面向功能测试、面向过程管理”,它是在综合“四种开发方法”各自的优点之后提出的软件工程实施理论,是对前者的继承与发展。总之,上述提法既精彩又实用。1.6怎样理解软件工程的支持过程和管理过程?软件工程的支持过程是由支持软件生存周期各个阶段的生产工具所组成的。就是说将一个软件的生存周期划分为市场调研、立项、需求分析、策划、概要设计、详细设计、编程、单位测试、集成测试、运行、维护这几个过程。在这些过程中,需要配套相应的工具来支持,比如需求分析工具、设计工具、实现工具、测试工具、维护工具、配置工具,开发环境等。1.7CASE工具、软件开发环境SDE、软件工程环境SEE三者之间有何联系与区别?CASE(ComputerAidedSoftwareEngineering)是一组工具和方法的集合,一般提供给个人使用,可以辅助软件开发生命周期各阶段进行软件开发。它在软件开发/维护过程中提供计算机辅助支持和工程化方法,CASE技术分为两类,一类是支持软件开发过程本身的技术,另一类是支持软件开发过程管理的技术。软件开发环境SDE(SoftwareDevelopmentEnvironment)指在基本硬件和宿主软件的基础上,为支持系统软件和应用软件的工程化开发和维护而使用的一组软件。它由软件工具和环境集成机制构成,前者用以支持软件开发的相关过程、活动和任务,后者为工具集成和软件的开发、维护及管理提供统一的支持。软件配置管理工具、面向行业领域开发的业务基础平台,都是软件开发环境的例子。软件工程环境SEE(SoftwareEngineeringEnvironment)一般提供给团队使用,它是以软件工程为依据,支持典型软件生产的系统。SEE具有以下特点:(1)强调支持软件生产的全过程。(2)强调大型软件的工业化生产。(3)以集成和剪裁作为主要技术路径,实现软件工业化生产的目标。(4)标准化。软件生产走向工业化需要建立相应的工业标准。软件工程环境的例子有北大青鸟系统,RationalRose等。三者的相同点是:都是软件过程的支持工具,其目的都是为了加快软件开发效率,提高软件开发质量。三者的不同点是:它们的功能强弱、使用范围、使用背景不尽相同。1.8是否存在这样一种现象:搞系统软件的公司不需要采用CMMI或ISO9001模式?CMMI或ISO900 1模式只适用于搞应用软件的企业?如果是,是为什么?如果不是,又是为什么?不是。因为CMMI和ISO9000模式规定了严格的管理制度、文档和评估软件能力与成熟度等级的一套标准,它们几乎包括了所有的IT的企业,只是一些优秀的企业自己内部形成特有的企业管理文化,但是它们并不排斥CMMI和ISO9000模式,甚至还充分肯定CMMI和ISO9000体系。1.9敏捷文化现象是什么意思?敏捷文化现象是指好的开发过程应该可以在保证质量的前提下,做到文档适度、度量适度和管理适度,并且根据敏捷文化能迅速做出自我调整,实现企业效益的最大化。1.10“轻载过程改进模型”(敏捷文化现象)能代替或战胜“重载过程改进模型”CMMI吗?不能。因为轻载过程改进模型只适用于少于12人的项目,对个人的素质要求很高,成功的大型复杂案例并不多,它特别适合于中小型软件企业,以及中小型软件项目。而重载过程改进模型CMM/CMMI在某种程度上包容了轻载过程改进模型,它对整体的素质要求很高,适合于所有的IT企业。1.11什么叫软件危机?通过本章的学习,你认为应该怎样克服软件危机?所谓软件危机,就是在软件开发和维护过程中所遇到一系列难以控制的问题。“软件危机”这个专业术语的首次出现,是1968年NATO(NorthAtlanticTreatyOrganization,北约)的计算机科学家,在联邦德国召开的国际学术会议上提出的。为了克服软件危机,同样是在1968年,北约科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头,讨论和制定摆脱“软件危机”的对策。就在那次会议上,第一次提出了软件工程(SoftwareEngineering)这个专业术语。当时人们的想法是:若借用建筑工程或机器制造工程的思想、标准、规范、规程去开发软件与维护软件,也许能克服软件危机。以后的实践证明:用工程的方法开发软件与维护软件是个好主意,但是要完全克服软件危机,还有许多其他工作要做。例如,将软件公司纳入CMMI的过程改进轨道,就能真正克服软件危机。1.12试述信息系统的定义及信息系统的基本内容。利用计算机网络技术、数字通信技术与数据库技术实现信息采集和处理的系统,称为信息系统。由此不难发现:凡是与数据库技术有关的应用系统,都可以看成信息系统。因为数据库是组织与存储信息的最好方式,除此之外,目前还没有找到其他更好的方式。信息系统由社会环境、网络环境、数据环境和程序环境四部分组成。社会环境指企事业单位的管理规程、工作规范、信息标准、业务流程、业务规则和人员素质。网络环境指互联网Internet、企业网Intranet或局域网的软/硬件设施。数据环境指信息系统的数据模型及数据库服务器上的数据操作。程序环境指客户端用户界面操作与应用服务器上的业务功能操作。不管是网络环境、数据环境还是程序环境,都要进行系统集成。这里特别强调社会环境,人们常说,信息系统建设不仅是一项计算机工程,而且是一项社会工程,就是这个道理。1.13解释下列名词:开发文档、管理文档、初始化数据、元数据、过程、过程改进。开发文档主要由项目组书写,用于指导软件开发与维护;管理文档主要由软件工程管理部门书写,用于指导软件管理和决策。 初始化数据是为软件系统提供运行条件的必备数据。元数据是关于数据的数据,组织数据的数据。过程是指软件生命周期(LifeCycle)中的时间序列。过程作为一个时间序列,自然有起始点和终止点。例如,可将一个软件的生命周期划分为市场调研、立项、需求分析、策划、概要设计、详细设计、编程、单体测试、集成测试、运行、维护、退役几个过程,前一过程的终止点就是后一过程的起始点。过程与阶段(Phase)有关,阶段与里程碑(Milestone)有关。某些重要里程碑上的文档(通过评审和审计之后)又称为基线(Baseline)。例如,《软件需求分析规格书》、《软件设计说明书》,它们都是基线。过程改进是指利用过程改进模型CMMI,对软件组织内部的过程管理进行优化。习题22.1软件生命周期是什么含义?它与软件生命周期模型有何关系?软件生命周期划分为市场调研、立项、需求分析、策划、概要设计、详细设计、编程、单体测试、集成测试、运行、维护、退役几个过程,前一过程的终止点就是后一过程的起始点。软件生命周期与软件生命周期模型有关:不同的生命周期模型,可能对应着不同的生存周期。生存周期不同,该软件的开发阶段划分、评审次数、基线标准都有所不同,甚至维护方法都有所区别。2.2为什么说“软件生命周期模型是指在整个软件生命周期中,软件开发过程应遵循的开发路线图。或者说,软件生命周期模型是软件开发全部过程、活动和任务的结构框架”?事实上,任何生命周期模型都是生命的路线图。特别,软件生命周期模型是软件生命的路线图。这里使用路线图,是为了将深奥的理论通俗化,实用化。2.3为什么要选择软件开发模型?软件开发模型与软件生命周期有什么关系?因为软件开发模型是软件工程研究的5大内容之一,它虽然不是软件工程研究的重点,但是在宏观上特别重要。软件公司的项目组在开发一个大项目或产品时,首先在技术上必须选择一个开发模型,使开发模型非常适合这个项目或产品的生存周期;随后通过对生存周期的裁减,给出适合于本项目或产品的软件生存周期定义。2.4简述瀑布模型、增量模型、迭代模型、原型模型、XP等模型的优缺点。软件开发模型比较表序号模型名称优点缺点适用范围1瀑布模型简单好学逆转性差面向过程开发2增量模型可以分阶段提交有时用户不同意系统可拆卸和组装3迭代模型需求可变风险大有高素质软件团队4原型模型开发速度快不利于创新已有产品的原型5螺旋模型需求可变建设周期长庞大、复杂、高风险项目6喷泉模型提高开发效率不利于项目的管理面向对象开发7XP模型提高开发效率不适合大团队、大项目小团队,小项目2.5软件公司的CMMI过程改进模型与软件开发模型有关吗?为什么? 无关。因为CMMI管理体系是一种过程与质量管理模型,它是适应于任何软件开发模型的,或者说它与任何开发模型无关。开发模型本身只是规定了软件生存周期中的若干步骤或阶段,便于开发人员去开发与维护,它并没有规定管理人员的过程管理方法与任务。为此,CMMI管理体系规定采取阶段评审和不符合项的动态跟踪制度,只有前一阶段的不符合项全部改正后,才允许开发人员进入后一阶段的工作。所谓不符合项,就是在评审中发现的问题项,它与Bug既有联系,又有区别。对于这些不符合项,软件管理部门要列出表格,记录在案,确定责任人,限定改正时间,动态跟踪到底。2.6请调查你周围的软件公司采用哪几种软件开发模型进行软件开发。周围的软件公司采用的软件开发模型有瀑布模型、增量模型、迭代模型、原型模型。其中瀑布模型和原型模型是这些软件公司最常用的,其次是增量模型,最后是迭代模型。2.7软件开发模型对你今后的工作,到底具有什么指导意义?当我们进入IT企业参与软件开发或管理时,若能掌握软件开发模型知识,就会很快了解当前的项目或产品应该采用什么开发模型,由此确定该软件的生存周期和当前项目组的开发状态与进度,从而很快知道项目组成员的工作,也能使自己很快融入该项目组,快速适应IT企业文化,并很快进入角色。2.8你对“生命周期模型裁剪指南”有什么看法?“生存周期模型裁剪指南”是IT企业或软件组织内部根据软件开发模型的普遍原则,结合本单位的开发经验和行业特点的具体实际定制出来的。它有针对性地对选定的软件开发模型中定义的生存周期,进行恰当地裁剪。所谓裁剪,就是对原模型中定义的内容进行增、改、删,去掉对本单位或者本项目不适合的部分,增加对本单位或者本项目适用的内容,同时进一步细化。这样可以缩短开发时间,减少开发成本,具有非常现实的意义。2.9“图书馆信息系统”的开发选用什么开发模型合适?“图书馆信息系统”的开发选用瀑布模型比较合适。因为瀑布模型开发阶段清晰,便于评审、审计、跟踪、管理和控制,而且“图书馆信息系统”在一定程度上符合瀑布模型的条件:(1)它在开发时间内需求没有变化或很少变化。(2)分析设计人员对应用领域很熟悉。(3)低风险项目。(4)用户使用环境比较稳定。(5)用户除提出需求以外,很少参与开发工作。2.10请详细说明瀑布模型与迭代模型之间的关系。在宏观上,迭代模型是动态模型,瀑布模型是静态模型。一方面,迭代模型需要经过多次反复迭代,才能形成最终产品。另一方面,迭代模型的每一次迭代,实质上都是执行一次瀑布模型,都要经历初始、精化、构造、移交4个阶段,走完瀑布模型的全过程。在微观上,迭代模型与瀑布模型都是动态模型。迭代模型与瀑布模型在每一个开发阶段(初始、精化、构造、移交)的内部,都有一个小小的迭代过程,只有经历这一迭代过程,该阶段的开发工作才能做细做好。瀑布模型与迭代模型之间的这种微妙关系,如下图所示。 图瀑布模型与迭代模型之间的关系由图可见,在迭代和瀑布模型中,你中有我、我中有你。瀑布模型与迭代模型之间的关系,反映了人们对客观事物的认识论:要认识与掌握某一客观事物,必须经历由宏观到微观的多次反复的过程。只有从宏观上反复迭代几次,才能看清全貌,掌握事物的宏观发展规律。只有从微观上反复迭代几次,才能吃透每个细节,掌握事物的微观发展规律。习题33.1为什么说立项(或签订合同)是一切项目的源头,也是软件项目的源头?立项的过程就是软件企业决定是否去开发某个项目或产品的过程。只有立项完成以后企业领导部门才会下达“任务书”,开发部门开始组成开发团队,成立项目组。3.2立项的具体表现形式是什么?企业的市场销售部门在市场调研的基础上,分析该产品是否有市场前景,以及企业是否有能力开发出该产品,并具体列出系统的功能、性能、接口和运行环境等方面的需求情况,当前客户群和潜在客户群情况,以及投入产出分析,然后写出立项建议书,召开立项论证会,决定是否立项。3.3《立项建议书》的编制者为什么主要是软件公司的市场销售人员,而不是开发人员?软件开发出来终归要推向市场的,软件能不能被市场接受是软件开发成功的标准。市场销售人员长期和市场客户打交道,他们最了解客户和市场的需求,最知道什么样的产品具有巨大商机。3.4为什么将项目的市场前景、功能、性能、接口、风险作为《立项建议书》的主要内容?一切软件项目或软件产品,都是为了实现用户需求中的“功能、性能、接口”三项具体目标。软件是否有市场前景,是软件开发是否成功的标志,有了市场软件才能带来利润。风险分析是对开发此软件的政策风险、环境风险、技术风险、技能风险等进行分析,这对公司按时保质保量地完成软件开发,是必不可少的。3.5什么叫风险分析?技能风险与技术风险有何区别?这里的风险分析是指软件立项过程中对产品开发、销售等可能出现的风险进行分析。分析方法是将一个大风险化解为多个小风险,然后再一个个克服小风险。技术风险是指采用新技术的风险程度。技能风险是指项目组成员掌握新技术的风险程度。两者的区别在于一个是说新技术(如新的开发工具,新的设计思想)本身的风险,一个是说人员要掌握这种新技术的风险。 3.6行业领域业务专家与产品经理有何异同?行业领域业务专家是精通某行业领域业务的人,在讲标时能把投标书的内容准确、生动地表述出来,使客户心服口服。而产品经理是某产品需求分析和概要设计的经理或专家,主要负责产品的立项、需求、设计和销售等业务。两者的相同点是:必须精通该产品的功能、性能和接口。不同点是:前者突出熟悉产品的应用业务领域,后者突出熟悉产品的需求与设计。3.7《合同》、《任务书》、《立项建议书》三者有何异同?有何关系?合同是与固定客户签订的协议书,签订合同后软件公司启动该项目的开发,该软件被称为“订单软件”。立项建议书是相对“非订单软件”而言的,是相关人员对立项过程的书面描述。任务书是企业决定开发某个软件时,对此任务的具体部署情况,以书面的形式表达出来,包括正文和附件。只有立项建议书或合同签订以后才能下达任务书,三者都是软件开发的源头。3.8下达任务的时间和方法是什么?满足以下三个条件中的任意一个,即可下达任务书:(1)企业已签订了项目《合同》。(2)《立项建议书》已通过了评审。(3)作为特殊情况,软件组织的上级下达了某个项目的指令性软件开发计划。例如,有跨组织、跨部门的某个大系统项目,软件的需求由它的系统总体设计组分配。下达任务书的方法是:(1)下达一份《任务书》的正文。包括任务的下达对象、内容、要求完成的日期、决定投入的资源、必要时包括任命项目经理(技术经理和产品经理)、其他保证措施、奖惩措施等。《任务书》的正文可长可短,若合同或立项建议书很详细,则正文可短。若合同或立项建议书很粗略很短,则正文应该详细,当然也应该很长。(2)下达一份《任务书》的附件。一般情况下它就是软件《合同》或《立项建议书》,如果是指令性计划,它的格式和内容,也应与《合同》或《立项建议书》基本相同,即附件的内容应覆盖系统的功能点列表、性能点列表、接口列表、资源需求列表、开发进度列表、阶段评审列表等。3.9请进行社会调查,收集材料,用事实说明“立项就是决策”的道理。2003年初冬,山东某软件公司的老总在西安出差,发现西安市的大中型餐厅基本上都有电子点菜系统,客人一点菜,信息马上出现在厨房大师傅眼前,大师傅马上炒菜,服务员很快上菜,他感到很有意思。后来一打听,这个“餐饮系统”是北京某软件公司开发的。于是这位老总又飞到北京,拜访了“餐饮系统”的开发公司,了解到该公司经济效益不错,而且还到几家餐饮店去就餐,亲身体验“餐饮系统”的使用情况,收集用户意见。返回山东后,老总拍着脑袋决定马上立项,快速开发本公司的“餐饮系统”。不到三个月,“餐饮系统”开发完毕,但是在后来的两年中,该系统在山东某市总共只卖出两套,投入与产出比是5︰1。这是为什么?就是因为该城市是中等城市,不像北京、西安是大城市,“餐饮系统”的客户群,实在是少得可怜。立项就是决策,IT企业的决策必须按照决策程序进行,没有决策程序就要先制定决策程序,不能一个人拍脑袋定决策。 3.10试述《商业MIS开发任务书》的优缺点及需要如何改进。选作题,课外作业。3.11请在老师的指导下,选定一个项目,写出一份《立项建议书》。选作题,课外作业。3.12对软件项目和产品的“功能、性能、接口”三项指标如何理解?一切项目或产品都是为了解决自身的“功能、性能、接口”问题,软件项目或产品更是这样。所以,从软件立项、需求、设计、编程、测试、维护,自始至终都要毫不动摇地坚持“功能、性能、接口”三项指标。3.13请用PowerPoint工具制作一份“图书馆信息系统”的投标书,并进行试讲。选作题,课外作业。3.14按照老师建议的其他实践项目,2~3人一组,完成项目的《立项任务书》和《投标书》,并进行《投标书》讨论与试讲。选作题,课外作业。习题44.1为什么需求分析特别重要?需求分析特别重要,是因为:(1)许多大型应用系统的失败,最后均归结到需求分析:要么获取需求的方法不当,使得需求分析不到位或不彻底,导致开发者反复多次地进行需求分析,致使设计、编码、测试无法顺利进行;要么客户配合不好,导致客户对需求不确认,或客户需求不断变化,同样致使设计、编码、测试无法顺利进行。(2)需求分析的输出文档是《用户需求报告》,它既是软件生存周期中的第一个里程碑,又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线,是三者共同工作的基础,是项目Alpha测试和Beta测试的准则,是供方交付产品和需方验收产品的依据。(3)需求分析要占用整个软件开发时间或工作量的30%左右。(4)需求获取中的错误,属于软件开发中的早期错误,它会在后续的设计和实现中进行发散式的传播。根据以上4个原因,IT企业的高层经理,对需求分析特别重视,常常派经验最丰富的人员去作项目需求。正因为如此,“系统分析员”才是软件行业中的最高技术职称。4.2需求分析的目的是什么?需求分析的难点在哪里?软件需求分析,其目的是用于说明软件产品或软件项目需要满足的条件和限制。在软件工程项目中首先要获取用户的需求,通过对软件需要的提取、分析、文档化及验证,为进一步的设计和实现提供依据。需求分析的难点是:在系统的功能、性能和接口方面,开发者与客户达成完全一致的需求,让客户最终签字确认,并保证在项目验收前,需求相对稳定不变。万一需求有一点变化,双方必须履行“需求变更管理程序”,而变更管理程序在签订合同时已经做了规定。要知道,合同是具有法律效力的。 4.3需求分析的理论基础有哪些?需求分析的理论基础有:什么是软件需求;软件需求需要量化;需求是一个过程;需求过程中的角色;需求过程是一个迭代的过程;需求来源等6条理论基础。4.4为什么说需求过程是一个迭代过程?由于人们对客观事物的认识是不断深化的,所以需求过程是一个迭代过程,每次迭代提供更高质量和更详细内容的软件需求。这种迭代会给项目带来一定的风险,上一次迭代的设计实现可能会因为需求不足而被推翻。在很多情况下,对需求的理解会随着设计过程和实现过程的深入而不断深化,这也会导致在软件生命周期的后期,重新修订软件需求。原因可能来自于错误的分析,客户环境和业务流程的改变,市场趋势的变化等。无论是什么原因,软件分析师应认识到需求变化的必然性,并采取相应的措施,减少需求变更对软件系统的影响。4.5为什么说需求分析是面向流程的?系统的功能、性能、接口、界面都是在流程中动态实时的反映出来。在所有的流程(物流、人流、资金流、信息流、单据流、报表流、数据流)中,数据流最重要,也最具有代表性。因为在计算机网络系统内,一切流程都表现为数据流,或者说是数据流在不同方向的投影。而流程是动态的、实时的。所以说,需求分析是面向流程的。4.6需求分析的基本思路是什么?需求分析的思路,是从用户的功能需求(系统需要做什么)出发,由系统的业务流程和数据流程导出系统的业务模型和功能模型,识别出系统的元数据和中间数据,为今后设计数据模型做好充分准备。同时,对系统的软、硬件环境配置,开发工具,开发工期,费用,开发进度,培训,系统风险进行评估。4.7解释术语:元数据、实体、中间数据。元数据是组织数据的数据,描述数据的数据,关于数据的数据。实体(指实体集或实体型),是一组相关元数据的集合。中间数据(有的书上称为查询数据)是组织统计数据的数据,描述统计数据的数据,关于统计数据的数据。4.8为什么说元数据的分析与识别是需求分析的议题之一?元数据是组织数据的数据,描述数据的数据,关于数据的数据。通俗地讲,元数据就是信息系统中实体名及其属性名的集合,或者说就是基表的表名与字段名的集合。由于信息系统的设计与实现,都是面向元数据的,所以说元数据的分析与识别是需求分析的议题之一。元数据分析的出发点是业务模型和功能模型,落脚点是系统中的实体及其属性,是企事业单位的数据模型中的所有元素。4.9元数据与中间数据之间,有什么关系?请举例说明。元数据与中间数据间的关系是一种因果关系。元数据对应原始单据,中间数据对应查询、统计、报表。元数据将原始单据中录入的数据组织起来变成基表中的记录,这些记录称为基础数据。中间数据将输出数据组织起来变成中间表中的记录,这些记录称为统计数据。 中间表中的记录是由基表中的记录派生(推导、加工、处理)出来的,为了叙述简单,我们说“中间数据是由元数据派生出来的”。例如,人力资源系统中的员工基本情况表中的“姓名、性别、出生日期、文化程度、毕业学校、身份证号”等是元数据,而通过统计后得出的软件开发部1980年以后出生的人员情况表中的“姓名、性别、文化程度、毕业学校”,它们是中间数据。4.10业界存在哪三种需求分析方法?你认为哪一种方案更好?业界存在三种需求分析方法:面向功能分析、面向对象分析、面向数据分析。以上这三种方法,各自适用于不同的目标系统。目前时尚的方法是面向对象,包括面向主体和面向方法。总的来说,对于系统软件和应用软件来说,面向功能需求分析的方法简单明了,而面向对象的需求分析方法则复杂抽象。对于以关系数据库为平台的信息系统软件来说,面向数据需求分析方法的特点是抓住了本质。但是,这三种分析方法都离不开面向流程分析这根总线:功能、对象、数据都是在流程中产生的,又都是为流程服务的。4.11需求管理过程的目标和内容是什么?需求管理的目标,是保证软件项目或产品满足客户在软件功能、性能、接口三个方面的需求。需求管理过程的内容,主要包括需求确认、需求评审、需求追踪和需求变更活动管理。4.12为什么对需求文档要进行同行评审?同行评审,是软件工作产品验证的活动,其目的是为了及早和高效地从软件工作产品中识别并消除缺陷。重点在于发现软件工作产品中的缺陷。另外,由于进行同行评审,使大量人员对软件系统中原本不熟悉的部分更加了解,因此同行评审还提高了项目的连续性,培训了后备人员。4.13《用户需求报告》与《需求分析规格说明书》有何差异?(1)用户需求报告是对外的,需求规格说明书是对内的。用户需求报告是站在用户(使用者)的角度、用他们可以看懂的语言(比如自然语言)写的,需要用户签字确认。需求规格说明书则不同,它是对内的,不需要用户签字确认。它是站在开发者的角度、可以采用形式化或半形式化的语言进行描述。(2)一般来说,用户需求报告是合同的产物,需求规格说明书是立项建议书的产物。用户需求报告是对合同而言的。需求规格说明书是对立项建议书而言的。(3)由用户需求报告可产生需求规格说明书。签完合同后,一般是先写出用户需求报告,后写出需求规格说明书。当需求报告由用户签字确认后,需求规格说明书很快就出来了。4.14怎么理解“不符合项”?为什么要对它进行跟踪管理?不符合项是指没有满足要求的项,不一定是错误,跟Bug是不同的。跟踪的意思在于,获得需求目前的实现状态,确保用户所有的需求都得到满足。可靠的跟踪信息可为需求变更、系统维护、关键成员离开、系统再设计和类似系统设计等很多方面,提供参考和指导,并可以减少风险和提高项目成功率。4.15为什么说“ 只考虑目标系统是什么、而不考虑目标系统怎么做的需求分析观点,是片面的、表面的、不可取的”?因为有些需求分析问题,在需求分析阶段开发者感觉不出来,到了设计阶段才会感觉出来,此时才发现设计的资料不够、条件缺少,即需求没有完全到位,需要做第二次需求分析。所以说,“只考虑目标系统是什么、而不考虑目标系统怎么做的需求分析观点,是片面的,表面的,不可取的”。从这一点看,需求分析过程是一个迭代过程。4.16需求描述有哪几种工具?你喜欢用哪一种?为什么?需求描述的工具包括数据流图、业务流程图、用况图、时序图、用户交互图、数据模型图和功能需求列表、性能需求列表、接口需求列表、界面需求列表等。选择哪一种描述工具,主要取决于问题域的本质特征。不同的软件,对分析要求的严格程度不同。我喜欢业务流程图,它包括了物流、资金流、信息流,即业务操作模型,重点是业务操作的流水步骤。业务模型表示了与系统有关的人、设备、其他子系统之间的业务关系和费用关系,它是经过业务流程重组、再创和优化后,并且得到企业领导确认的业务流程图。绘制这个图的工具可以是Office办公软件。4.17如果你是项目经理,怎样组织项目组成员,对学院图书资料室信息管理系统进行需求分析?并将该系统的功能需求列表详细列出。选作题,课外作业。4.18在主讲老师的组织下,学生以项目组为单位,选取瀑布模型或快速原型模型,采用项目组成员最熟悉的数据库管理系统和面向对象的编程工具,开发“图书资料室信息系统”这个小项目,要求文档书写齐全、前台界面美观简单、后台数据库维护方便,并尽量使它产品化。选作题,课外作业。4.19如果你是软件公司的系统分析师,你将怎样进行需求分析?选作题,课外作业。习题55.1为什么说计划只是策划的一个结果?软件策划,或者软件计划,英文都是Planning。但是,策划包含有出谋划策和做计划两个意思。策划是一个过程,是一系列活动。计划是一份文档,是一个结果。所以说,计划只是策划的一个主要结果或成果。5.2简述软件策划的步骤。软件策划的4个步骤是:步骤步骤名称步骤内容1估计软件工作产品的规模、工作量、费用及所需的资源软件工作产品,包括需求规格说明书、概要设计说明书、详细设计说明书、源代码、测试计划和测试报告、质量保证计划、软件配置管理计划、里程碑及评审计划。每个工作产品所需的工作量(人年)、费用及其所需的其他资源,都要量化 2制定时间表包括开发进度时间表和日历进度时间表:软件开发计划、质量保证计划、软件配置管理计划、测试计划、评审计划3鉴别和评估风险政策风险、资源风险、市场突变风险、技术风险和技能风险等4与相关的组或人协商策划中的有关约定策划的结果要实事求是,要得到各有关方面的同意和认可5.3软件策划要实现的具体目标是什么?软件策划是项目跟踪和监控的基础,是项目经理和高层经理管理项目的依据。软件策划要实现的具体目标有三个。(1)对供项目策划和跟踪用的三个软件估计已建立文档。这三个估计是:——工作产品规模估计——工作量及成本估计——计算机资源估计(2)软件项目活动和约定是有计划的,并已建立文档。这里的活动,包括开发活动和管理活动。这里的约定,是指对项目的各种标准、规范、规程的约束。(3)受影响的组和个人,同意他们对软件项目的约定。受影响的组和个人有:——软件工程组(项目组)——软件估计组——系统测试组——质量保证组——配置管理组——合同管理组——文档支持组其中有的组可能只有一个人。5.4为什么在策划过程中要考虑到受影响的组和个人?受影响的组主要有:软件工程组(项目组)、软件估计组、系统测试组、质量保证组、配置管理组、合同管理组、文档支持组等,这些小组的活动始终贯穿于整个软件工程的全过程,对软件项目的成败有着至关重要的作用,是保证软件产品质量的关键所在,任何一个组的疏忽,都有可能影响到整个软件产品的开发进度。5.5怎样理解软件项目进行策划的时机?国际上通用的做法是,先做需求分析,后做软件策划。至少策划要在软件《合同》/《立项建议书》和《任务书》之后。而且,软件策划要在《用户需求报告》之后,在《规格说明书》/《设计说明书》之前。5.6简述软件策划的方法。到目前为止,软件策划的方法仍然是采用经验数据加结构化方法,这些方法有三个要点:(1)粒度由粗到细的分解:自顶向下、逐步细化、逐项逐条逐日安排计划。(2)粒度由细到粗的综合:自底向上、逐步归纳、逐日逐周逐月安排计划。(3)同类项目经验数据类比法、同行专家协商策划法。软件策划是以用户确认的需求为基础,以软件组织内部的软件标准为依据,把组织内部类似项目的成功经验作为策划时的参考。 5.7软件策划的上游和下游各是什么?上游是需求分析,下游是软件设计。5.8定义软件过程是什么含义?所谓定义软件过程,就是根据选定的生命周期模型,规定软件的开发阶段,及每一阶段的工作步骤和文档标准等内容。5.9软件估计是什么含义?所谓软件估计,指对软件项目进行量化估计,并记录估计结果的过程。软件估计是软件度量的一部分,它既是软件策划的核心,又是软件策划的重点与难点。5.10简述对软件工作产品规模进行量化估计的方法。到目前为止,在IT企业中常用的软件项目规模估计方法有以下4种:第一种估计方法:希腊古都法。希腊古都法是最流行的专家评估技术,在没有历史数据的情况下,这种方式适用于评定过去与将来。它鼓励参加者就问题相互讨论。这项技术,要求有多种软件相关经验的人参与,互相说服对方。第二种估计方法:类比法。类比法适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目,通过新项目与历史项目的比较得到规模估计。它的结果的精确度取决于历史项目数据的完整性和准确度。第三种估计方法:功能点估计法。功能点(实体数、构件数、屏幕数、报表数、文档数)测量,是在需求分析阶段基于系统功能的一种规模估计方法。第四种估计方法:无礼估计法。无礼估计法对各个项目活动的完成时间,按三种不同情况估计:一个产品的期望规模、一个最低可能估计、一个最高可能估计。用这三个估计得到一个产品的期望规模和标准偏差。5.11简述软件工作产品成本费用的估计方法。软件工作产品成本费用估计方法是:序号估计方法估计单位(元)方法说明1直接的劳务费人民币开发人员的工资和福利2管理费人民币技术管理和行政管理人员的工资和福利3差旅费人民币售前、售中、售后的人员差旅费4计算机使用费人民币网络设备的折旧费和房租水电费5其他招待费和公关费人民币控制在总费用的15%以内5.12项目跟踪与监督的基础是什么?在项目策划阶段,要为开发计划制定严格的审批流程。开发计划在经过组织批准生效后,将成为进行项目跟踪与监督的基础。5.13软件开发计划应包括哪些内容?《软件开发计划书》是软件策划的输出文档,它包括如下10个方面的内容: (1)软件项目的目的、范围、目标和对象。(2)软件生存周期的选择与裁剪。(3)确定软件开发和维护的规范、方法和标准。(4)软件工作产品的确定。(5)对工作产品规模的估计。(6)对工作量和成本的估计。(7)关键计算机资源的估计和使用情况。(8)项目的进度、里程碑和评审计划。(9)风险的识别和评估。(10)项目工程设施和工具的计划。5.14软件工作产品和软件产品有何异同?软件工作产品是指开发过程中每个阶段的文档、数据和程序,即每个开发阶段的输出制品。软件产品是指软件开发与测试工作已经完工,并且可投入市场销售的软件产品。由此可见,软件产品是最后一个阶段的软件工作产品。5.15名词解释:直接人工、直接费用、间接成本、制造费用、管理费用、不可预见费用。直接人工:是指直接参与软件产品开发的相关的程序员、系统分析员等项目组成员。直接费用:是指与软件开发有着直接关系的日常开销,如员工的薪金、福利、劳保、日常餐饮费用、差旅费用等。间接成本:是指与软件开发没有直接关系的日常开销,如招待费、器材损耗等。制造费用:企业生产车间为制造产品和提供劳务而发生的各项间接费用,包括折旧费、修理费、物料消耗费等。管理费用:是指企业行政管理部门为组织经营管理活动而发生的各项费用,包括公司办公经费、工会经费、职工教育经费、审计费、诉讼费、排污费、绿化费、税金、土地使用费、土地损失补偿费、技术转让费、坏账损失,存货盘亏、毁损和报废(减盘盈)费用。不可预见费用:是指在软件开发过程中,由于某些意想不到的因素造成了软件开发成本的提高。5.16怎样理解软件中的度量,它有何作用?软件中的度量,是指对大量测量数据的统计分析。度量是按规定在项目进行过程中,需要采集的度量数据,以便量化地反映项目的进展情况,为管理者提供对项目进展的适当的可视性,同时度量数据是项目过程改善的基础数据,它们存放在测量数据库中。5.17请设计以下策划管理文档:项目周报、项目月报、里程碑报告、重大事件报告、软件开发计划评审报告、项目计划变更申请表、计划更改与批准记录。(1)项目周报是:起始日期终止日期项目名称项目经理本周计划进度本周实际进度本周成绩本周问题下周应对措施对资源的要求 (2)项目月报是:起始月份终止月份项目名称项目经理本月计划进度本月实际进度本月成绩本月问题下月应对措施对资源的要求(3)里程碑报告是:里程碑名称评审日期项目名称项目经理里程碑优点里程碑问题(4)重大事件报告是:事件名称事件日期项目名称项目经理事件原因事件处理结果(5)软件开发计划评审报告是:项目名称项目经理评审阶段软件开发计划第次评审评审组组长评审时间评审地点评审组成员不符合项跟踪记录不符合项名称不符合项内容限期改正时间实际改正时间测试合格时间测试员签字审计员签字评审意见评审结论(6)项目计划变更申请表是:计划变更理由变更申请日期项目名称项目经理(7)划更改与批准记录是:更改次数批准日期项目名称项目经理变更评审日期变更起始日期原计划版本号现计划版本号5.18在老师的指导下,写出一份“图书馆信息系统”的《软件开发计划书》。参考本书的“图书馆信息系统”一章,按照《软件开发计划书》参考模板书写即可,在此省略。 5.19如果你是软件企业的项目经理,根据实际情况,如何用4种不同的估计方法,对软件产品规模进行量化估计?(1)在没有历史数据的情况下,Delphi法是最流行的专家评估技术。(2)在有历史数据的情况下,类比法适合于评估一些与历史项目在应用领域、环境和复杂度方面相似的项目,通过新项目与历史项目的比较得到规模估计。(3)在需求分析时,若系统的功能点非常清楚,则可用功能点法。据统计发现,对一个软件产品的开发,功能点对项目早期的规模估计很有帮助。(4)任何时候都可采用无礼估计法。无礼估计法类似于体育比赛中的跳水、体操、花样游泳、花样滑冰等项目的评判打分方法。它对各个项目活动的完成时间,按三种不同情况估计:·一个产品的期望规模。·一个产品的最低可能估计。·一个产品的最高可能估计。可由这三个估计,得到一个产品期望规模和标准偏差。习题66.1业务模型、功能模型、数据模型各是什么含义?三者之间有什么关系?功能模型是描述系统能做什么,即对系统的功能、性能、接口和界面进行定义。业务模型是描述系统在何时、何地、由何角色、按什么业务规则去做,以及做的步骤或流程,即对系统的操作流程进行定义。数据模型是描述系统工作前的数据来自何处,工作中的数据存到什么地方,工作后的数据放到何处,以及这些数据之间的关联,即对系统的数据结构进行定义。功能模型和业务模型是在需求分析时建模,是两个基本点。数据模型是一个中心,在设计时建模。功能模型和业务模型给数据模型提供数据与维护数据,数据模型支持功能模型和业务模型的正常运行。通常,数据模型建模用PowerDesigner,ERWin或OracleDesigner工具实现;功能模型用功能点列表(或用况图)表示;业务模型用自然语言加上流程图(或顺序图)表示。信息系统的业务模型就是系统的操作流程和业务规则,功能模型就是系统的功能菜单和用户界面,数据模型就是系统的数据结构和数据字典。6.2说明数据库与数据库管理系统的差别。数据库管理系统DBMS是一个系统软件,它是专门管理用户的数据的。数据库是一个应用软件,它是用户数据的存放地方,专门支持用户软件的运行的。6.3你是怎样通俗地理解数据库设计范式理论的?第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解。第二范式:2NF是对记录的唯一性约束,要求记录有唯一标识,即实体的唯一性。进一步讲,在数据库设计时,作为唯一性标志的主键,最好是一个字段,而不是组合字段,这就是主键的原子性。现在的关系数据库管理系统,都提供唯一标识ID类型的字段,就是为了实现主键的原子性。第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。 其他更高级的范式:BCF,4NF,5NF等各级范式,研究的内容是解决实体本身的原子性问题,只要实体本身不可再分解了,即实体原子化了,就从根本上符合了BCF,4NF,5NF范式的要求。由此可见:“只要实现了属性、主键、实体三者的原子化,就从根本上符合了各级范式的要求”。这就是范式理论的实质!数据库设计规范化理论的实质,就是引导并帮助设计人员实现“实体、属性、主键的原子化”。6.4什么是原始数据?什么是原始单据?什么是信息源?三者之间有何关系?原始数据是要采集并录入的数据,是软件系统中未加工处理的数据。记录原始数据的单据,称为原始单据。产生原始数据的地点,称为信息源。即信息源产生的数据,称为原始数据。由此可见,原始数据、原始单据、信息源,这三个东西,是站在三个不同角度,描述同一个东西。6.5什么是实体?它与原始单据有什么关系?实体或实体集是一组相关元数据的集合。一般而言,实体来源于原始单据,即实体蕴涵于原始单据之中。6.6基本表、代码表、中间表、临时表,它们有何异同?数据库是表的集合,表由字段组成,表中存放着记录。由于记录的数据可以是原始数据、信息代码数据、统计数据和临时数据4种,所以又可将表划分为基本表、代码表、中间表和临时表4种。存放原始数据的表,称为基本表。存放信息代码数据的表,称为代码表。存放统计数据的表,称为中间表(又称为查询表)。存放临时数据的表,称为临时表。6.7为什么说:“只有基本表对应的实体才是真正的实体,才能出现在E-R图上。中间表、临时表不对应实体,因此也不应出现在E-R图上。代码表很简单,在E-R图上可省略”?因为基本表中的信息,是信息源产生的信息。只有信息源产生的信息,才是客观存在的实体的信息,所以只有基本表对应的实体才是真正的实体,才能出现在E-R图上。因为中间表、临时表不是存放原始信息的表,而是存放查询信息或临时信息的表,所以中间表、临时表不对应实体,因此也不应出现在E-R图上。因为代码表很简单,在E-R图上可省略。如果不加以省略,就会显得E-R图复杂繁琐,使人得不到要领。6.8数据库设计的基本模式有哪些?站在IT企业的数据库开发角度上讲,数据库设计的核心设计模式只有两个:一个是“第三者插足”模式,另一个是“行变列”模式。6.9显式与隐式的“第三者插足”模式,它们之间有何异同?当两个实体之间存在多对多关系时,必须在它们之间插入第三个实体,以化解这种多对多关系。由于插入的实体,可能是强实体,也可能是弱实体,所以“第三者插足”模式,又分为“强实体插足”模式和“弱实体插足”模式两种。 所谓强实体插足模式,就是不需要增加一个新实体,已有的“明细实体”就能够扮演“第三者”的角色。该模式的详细情况,将在6.4节中介绍,本节只介绍“弱实体插足”模式。所谓弱实体插足模式,就是要公开增加一个新的弱实体,使其扮演“第三者”的角色。该模式是一种最常见、最抽象、最难发现的数据库设计模式。它的特点是:由于两个多对多关系实体之间的关联实体,没有独立的业务处理需求,因而不存在实实在在的关联实体,所以需要另外增加第三个抽象的实体,作为它们之间的关联实体。这个抽象的关联实体,实质上就是一个复杂关系,称为弱实体。该弱实体,就是原来两个多对多关系实体之间笛卡儿积的子集。该设计模式,被称为“弱实体插足”模式。显式与隐式的“第三者插足”模式,都是为了解决实体之间的多对多问题。6.10“列变行”模式的实质是什么?数据库设计中“列变行”模式的实质,是解决实体本身的原子化问题。也就是说,是解决数据库设计符合BCF,4NF,5NF的问题。6.11请说明“第三者插足”模式和“列变行”模式之间的关系。“第三者插足”模式是为了解决关系的原子化问题。这里的关系原子化,是指表之间的关系都是一对多关系。“列变行”模式之间,都是为了解决实体本身的原子化问题。也就是说,是解决数据库设计符合BCF,4NF,5NF的问题。“第三者插足”模式和“列变行”模式,是进行规范化数据库设计的两只手,我们要两手抓,两手都是硬。6.12请说明三个模型思想的优缺点。三个模型建模思想的优点是简单、直观、通俗、易懂、易学、易用,非常适合于关系数据库管理系统(RDBMS)支持的信息系统。在这三个模型的支持下,运用强大的面向对象编程语言,以及软件组织内部的业务基础平台、类库、构件库等财富,软件开发在技术上就能顺利实现。事实上,不管是系统软件还是应用软件开发,都有一个建模问题,而且三个模型的建模思想,也适用于系统软件建模。“三个模型”既是一种软件建模思想,又是一种建模方法,它不但告诉人们应该在什么时候、用什么方法、去建立什么模型,而且告诉人们这三个模型之间的关系,以及如何用这三个模型去解决实际问题。“用例图、时序图、活动图和类图”等UML图形,只是实现“功能模型、业务模型和数据模型”的工具而已。三个模型的建模,目前只能覆盖需求分析和设计两个阶段,不能覆盖整个软件生存周期。业务模型和功能模型主要适合在软件需求阶段建模,数据模型主要适合在软件设计阶段建模。当然,这三个模型对软件实现、软件测试两个阶段,也具有重要指导意义。例如,功能模型中的三个列表,既是软件实现和软件测试的出发点,又是它们的归宿。6.13请说明数据库设计的步骤与方法。数据库设计的10个步骤是:设计步骤设计内容第1步将原始单据分类整理,理清原始单据与输出报表之间的数据转换关系及算法,澄清一切不确定的问题第2步 从原始单据出发,划分出各个实体,给实体命名,初步分配属性,标识出主键或外键,理清实体之间的关系第3步进行数据库概念数据模型CDM设计,画出实体关系图ERD,定义完整性约束第4步进行数据库物理数据模型PDM设计,将概念数据模型CDM转换为物理数据模型PDM第5步在待定的数据库管理系统上定义表空间,实现物理建表与建索引第6步定义触发器与存储过程第7步定义视图,说明数据库与应用程序之间的关系第8步数据库加载与测试:向基表中追加记录,对数据库的功能、性能进行全面测试第9步数据库性能优化:从数据库系统的参数配置、数据库设计的反规范化过程的两个方面,对数据库的性能进行优化第10步数据库设计评审:从数据库的整体功能与性能两个方面,请同行专家评审评价习题77.1软件设计的输入与输出是什么?对于签订合同的项目,软件设计的输入是《用户需求报告》/《需求规格说明书》,输出是《概要设计说明书》和《详细设计说明书》。对于立项的项目,软件设计的输入是《需求规格说明书》,输出是《概要设计说明书》和《详细设计说明书》。7.2为什么说“软件设计以面向元数据为主,以面向功能和面向对象为辅。而软件的编程实现则以面向对象为主,以面向元数据和面向功能为辅”?软件设计注重宏观上框架的设计,软件实现注重微观上和框架内的设计。根据“面向流程分析、面向数据设计、面向对象实现、面向功能测试、面向过程管理”的实施理论,软件设计主要方法以面向数据为主,以面向功能和面向对象为辅,重点设计数据的存储方式、加工处理方式和传输方式。而软件编程实现的主要方法则以面向对象为主,以面向数据和面向功能为辅,因为面向对象是当今的流行编程方法,它具有可复用、好维护的特性。7.3《概要设计说明书》和《详细设计说明书》有何区别?《概要设计说明书》,一是要覆盖《需求规格说明书》的全部内容,二是要作为指导详细设计的依据。它注重框架上的设计,它是软件系统的总体结构设计、全局数据库(包括数据结构)设计、外部接口设计、功能部件分配设计、部件之间的内部接口设计,它要覆盖需求规格说明书中的功能点列表、性能点列表、接口列表。《详细设计说明书》,一是要覆盖概要设计说明书的全部内容,二是要作为指导程序设计的依据,它注重微观上和框架内的设计,它是各子系统的公用部件实现设计、专用部件实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计和其他详细设计等。两者的设计者不同,在一般情况下,《概要设计说明书》是由系统设计师负责,《详细设计说明书》则由高级程序员负责。7.4怎么理解“软件概要设计是系统总体结构设计或系统架构设计”?软件概要设计用以描述系统最顶层的结构和组织形式,表示出软件系统各个组成部分的功能及其互相之间的接口关系,所以概要设计是系统总体结构设计或系统架构设计。 7.5怎么理解“软件详细设计是子系统和模块实现设计”?软件详细设计用于详细描述每个部件的内部结构,用以指导程序人员编写代码,便于每个部件能够得以顺利实现。当这些部件都实现了之后,将它们组装起来就实现了子系统或模块。7.6请用面向过程详细设计中的程序流程图,描述求,以及求。(1)使用程序流程图,描述求。(2)使用程序流程图,描述求。7.7请用面向过程详细设计中的程序设计语言PDL和PAD图两种方法,来描述求 (N≥1)。(1)程序设计语言PDL:读入N置S的值为0,置I的值为1当I<=N时,执行:使S=S+I*I*I使I=I+1打印S(2)PAD图:readN;S=0;I=1;I<=N;S=S+I*I*I;I=I+1PrintS;7.8请说明“三层结构”与“三个模型”之间的关系。三个模型从根本上满足了B/A/S(Browser/Application/Server)三层结构的需求:B层(又称浏览层)对应功能模型,A层(又称业务逻辑层)对应业务模型,S层(又称数据库服务器层)对应数据模型。这真是一种奇妙的、天衣无缝的巧合!7.9请说明“三层结构”的工作原理。三层之间,通过各自提供的接口来访问,比如用户想登录并操作系统,在表示层输入用户名和密码,表示层会收集相关的数据传递给业务层,业务层将数据经过一些处理和封装之后,再传递给数据层,数据层执行相应数据库中表的操作,并将结果返回业务层,业务层再返回表示层,表示层再显示给用户看。对登录信息和操作信息,都是这样分层处理、协调工作的。业务层与数据层的信息交换采取“批发方式”,业务层与表示层的信息交换采取“零售方式”。7.10请说明“三层结构”的优点。①三层之间的低耦合,互不干扰,哪一层出了问题就去找哪一层解决。同时,由于同一层内的各个类之间,也是低耦合,所以不会出现Bug现象。②三层结构减少了客户机的工作量,提高了网络系统的运行效率。③三层结构有利于系统的维护和升级,各个层的维护,互不影响。例如,修改表示层,不会影响用业务层;修改业务层,也不会影响用数据层。而且,所有层的维护与修改,都是在服务器上进行,不需要到用户现场出差。7.11模块(构件)实现设计包括哪些内容? 模块、构件与部件、组件基本上是一个意思,有时会认为部件和组件的粒度比构件大一些或范围广一些。上述定义有三个特点:第一个特点是构件要被明确标识,即有一个被调用的名字;第二个特点是构件应该可复用,不可复用的只能称为模块或子系统,第三个特点是构件是软件制品,在宏观上软件制品可以是项目计划、成本估计、体系结构、需求模型、设计模型、程序代码、窗口界面、文档、数据结构、测试用例等。在微观上的构件,通常是指程序代码级的构件。这种构件在技术上的三个流派是Sun的Java平台、Microsoft的COM+平台、IBM的CORBA平台。构件具有接口标准、通信协议、同步和异步操作。可执行的构件独立于编程语言,具有版本兼容性。构件库是组织管理构件的仓库,它提供构件的入库、出库、查询功能。构件有两种级别:可执行文件级和源代码级。可执行文件级别上的构件是已通过编译的构件,因而与语言无关。源代码级别上的构件实际上只是构件模板,可以用多种语言实现,当然与语言有关。构件还可以分成可见构件和非可见构件,可见构件是在屏幕上看得见、拖得动、可修改的控件,非可见构件是在系统内部运行的构件。在详细设计说明书中已对新增构件的功能和算法进行了详述,此处只要将详细设计翻译为源程序即可。在大型软件企业内部,新增构件的实现及构件库的管理是软件实现的重要内容。构件库管理系统用于构件储存、构件检索、构件浏览和构件管理。因此,构件库管理系统的主要功能是:构件的分类入库与存储,按用户需求在构件库中浏览或检索构件,对不再使用的构件进行删除,对构件使用情况的统计与评价。7.12怎么理解“详细设计是面向模块的,不是面向组织结构或部门单位的”?一个组织或单位,根据角色的不同授权,可以挂上不同的模块或部件。一个优秀的软件,不会因企事业单位内部的组织结构变动,而导致软件不能使用。因此详细设计是面向模块的,不是面向组织结构或部门单位的。7.13为什么软件设计要遵守“抽象、分解与模块化,低耦合、高内聚,封装,接口和实现分离”的设计原理?当前,软件设计过程仍然是一个非确定性过程,经常是摸着石头过河。不同的设计人员对相同的问题可以得到不同的设计方案。由于设计过程是一个启发式过程,不是确定性过程,因此不可能得到一个完全可预测的结果。为此,只能规定一些设计原理或原则,供设计人员共同遵守。这些原理或原则是“抽象、分解与模块化、低藕合高内聚、封装、接口和实现分离”。7.14你怎样理解面向对象设计步骤?由于在面向对象中,需求分析、架构设计(概要设计)、详细设计(部件实现设计)三个阶段使用的描述工具都是UML,所以考虑面向对象设计的步骤或过程,就要将面向对象的需求分析、架构设计、详细设计融为一个整体,捆绑在一起考虑。事实上,这一过程是一个连续的、互相联系的、互相渗透的、反复迭代循环的、逐步细化的过程。下面,在三层结构背景下,以“功能模型、业务模型、数据模型”作为建模方法论,以UML和Visio作为建模工具,从宏观上来说明面向对象设计的具体步骤,如下图所示。对于微观上的设计步骤,因各种软件项目的具体内容不同,以才及各个项目组人员的设计风格不同,其微观设计步骤也千变万化,在此不进行介绍。 面向对象设计的步骤图7.15你怎样理解“面向元数据方法用在数据库服务器层次上系统的设计与实现,面向对象方法用在除数据库服务器层次之外的其他层次上系统的设计与实现,面向过程方法用在其他两种方法本身内部函数的设计与实现”?上述提法是实事求是的。我们知道,所谓的“面向过程的方法是传统的软件工程方法,面向对象的方法是现代软件工程方法”的观点是肤浅的。这三种方法不是互相孤立、毫无联系、彼此对立的,而是互相帮助、取长补短、彼此有关的。三种设计方法各有所长,所以各有应用空间。又各有所短,所以各有局限性。我们只能扬长避短、为我所用。一般而言,对于一个大型信息系统的建设,由于其分析、设计、实现、测试、维护的重点是数据库服务器上的数据,所以在实施的过程中,在宏观上仍然要遵守“五个面向”的实施理论,即“面向流程分析、面向数据设计、面向对象实现、面向功能测试、面向过程管理”。7.16评审记录表设计合理吗?你有何改进意见?到目前为止,还看不出设计上有什么问题,因此没有改进意见。7.17完成“图书馆信息系统”的《概要设计说明书》和《详细设计说明书》。课外作业,在此省略。 习题88.1软件测试的目的和目标是什么?简单明了地说,软件测试的目的就是发现软件缺陷。但同时还要时刻牢记在心的是:软件测试的目标是尽可能早地发现软件缺陷,并确保其得以修复。这里的缺陷,包括Bug和不符合项。8.2什么是软件缺陷?我们说,符合下列五个规则之一的就是软件缺陷:(1)软件未达到产品说明书(需求报告或需求说明书)标明的功能;(2)软件出现了产品说明书指明不会出现的错误;(3)软件未达到产品说明书未指明但应达到的目标;(4)软件功能超出产品说明书所指明的范围;(5)软件测试人员认为软件难以理解、不易使用、速度缓慢,或者最终客户认为不好。8.3试举例说明软件测试的原则。(1)尽早开展测试工作;(2)完全测试不可能,把握最优测试量;(3)严防寄生虫现象;(4)严防杀虫剂现象;(5)并非所有的软件缺陷都能修复;(6)难以说清楚的软件缺陷;(7)产品说明书不断变化;(8)软件测试人员在产品小组中不受欢迎。8.4试阐述软件测试V模型的思想、不足之处和改进方法。软件测试V模型的基本思想,如图所示。我们可以初步了解,左侧是开发阶段,右侧是测试阶段。开发阶段先从定义软件需求开始,然后要把这些需求不断地转换到概要设计和详细设计中去,最后形成程序代码。测试阶段是在代码编写完成以后,先作单元测试开始,然后是集成测试、系统测试和验收测试。对V模型的进一步阐述是:当需求分析完成后,验收测试计划也应完成。当概要设计完成后,系统测试计划也应完成。当详细设计完成后,集成测试计划也应完成。当编码完成后,单元测试计划也应完成。可见,V模型提高了测试的时间与地位。 软件测试V模型以上的测试V模型,一般只适合于瀑布开发模型,若对迭代开发模型,就显得不足了。实际工作中,V模型只是提高了测试工作的地位,具体测试方法,仍然是黑白盒子法。8.5试说出几种软件测试的分类方法。软件测试分类的实质,是软件测试技术的分类。测试工作中采用不同的测试技术,就产生了不同的测试类型,相继也产生了很多的测试类型术语,大概有以下几种。(1)动态测试:通过运行程序开展测试工作,即软件测试人员通过使用软件来找出缺陷;(2)静态测试:不通过运行程序来开展测试工作;(3)黑盒测试:又叫功能测试(FunctionalTesting);(4)白盒测试:可以理解为对程序执行路径的测试;(5)通过测试:简单的说,就是验证软件至少能做什么,而不会考查其能力有多强;(6)失败测试:纯粹是为了验证软件在某一条件下,是否会出现异常、停止工作等现象而进行的测试;(7)负载/压力测试:一方面,可以通过减少软件需要的资源,来测试软件运行的最低配置或者最低资源需求;另一方面,可以正常提供软件需要的资源,但是通过不断加重软件要处理的任务,来测试软件在正常配置下具有的能力指标;(8)易用性测试:易用性测试的目的很明确,即简单易用,但是标准不容易确定;(9)其他测试:如边界值测试、兼容性测试、回归测试、Alpha测试和Beta测试等。8.6试说出黑盒测试和白盒测试的区别和联系。黑盒测试又称功能测试。在这里,盒子指的是被测试的软件,“黑盒”就是只知道被测试软件的外部情况,主要是界面和接口,被测试软件的内部逻辑结构和数据结构,对测试人员来说是不可见的,主要关注被测试软件的功能实现。白盒测试就是对程序执行路径的测试,又叫做玻璃盒测试(GlassBoxTesting)、透明盒测试(ClearBoxTesting)、结构化测试(StructuredTesting)、开放盒测试(OpenBoxTesting)、基于代码的测试(Code-BasedTesting)等。黑盒测试和白盒测试的联系是:一般宏观上用黑盒测试,微观上用白盒测试,系统集成人员用黑盒测试方法对系统进行测试,构件开发人员用白盒测试方法对构件进行测试,这是常用的测试方法。8.7黑盒测试和白盒测试各自的依据是什么?黑盒测试的依据是用户需求分析报告中的功能点列表、性能点列表和接口列表。白盒测试的依据是软件详细设计说明书。8.8软件测试工作中的关键问题是测试用例设计,这种说法对吗?为什么?对!测试用例是最底层的测试计划,是一切测试的基础。8.9简述实用软件测试的流程。实用软件测试流程可以分5步展开:(1)理解、验证和分解需求。(2)编写测试计划(包括测试设计)。(3)测试执行。 (4)专项测试。(5)编写测试报告。8.10小组分工,分解“图书管理系统”其他功能点,编写测试功能点列表。课外作业,自行解决。8.11同学分组,分配各种软件测试角色,利用现有资源,拟编写一份“图书管理系统”的测试计划。由于“图书馆信息系统”的功能点比较多,笔者先列举几个功能点作为例子,其他的测试功能点列表可同理得到,如下表所示。测试功能点列表编号功能名称测试功能点序号测试功能点描述1图书入库信息录入1.1输入没有重复的图书编号和条形码,出现输入成功对话框1.2输入有重复的图书编号、条形码,出现输入失败对话框1.3输入有重复的条形码,出现输入失败对话框1.4输入空的信息,出现输入为空,请重新输入对话框2查询读者信息2.1输入读者的正确编号后,出现查询成功,出现该读者信息的结果2.2输入读者的错误编号后,出现查询失败,没有此读者对话框2.3输入空的信息,出现查询失败,请输入读者信息对话框3读者网上登录3.1输入正确的网上注册姓名和网上注册口令,出现系统主页面3.2输入正确的网上注册姓名和错误的网上注册口令,出现登录失败对话框3.3输入错误的网上注册姓名和正确的网上注册口令,出现登录失败对话框3.4输入错误的网上注册姓名和网上注册口令,出现登录失败对话框3.5输入空的信息,出现登录失败对话框3.6登录失败对话框,能够显示对客户有建议性的提示信息8.12如果条件允许,针对“图书管理系统”的一个功能点编写代码,进行测试,编写测试报告。课外作业,自行解决。8.13评估自己是否适合从事软件测试工作,如何进一步提高自己的职业素质和专业素质?给自己制定一个成长目标。软件测试职业素质要求,包括如下几个方面的内涵:(1)有敬业精神;(2)打破砂锅问到底;(3)追求完美;(4)有编程经验; (5)有行业知识;(6)是故障排除能手;(7)有创造性;(8)对事物的属性判断准确;(9)老练稳重;(10)不要硬着头皮干活,完不成的工作,一定事先说明,干不好还不如不干。技能提高方法包括如下几个方面的内涵:(1)网络、论坛、群组交流;(2)同事之间共享经验,和开发人员沟通;(3)干一件事,总结一次,提高一步;(4)时刻想着测试工作,即使身处异地不在测试工作台旁边;(5)争取人人参加各种正规培训的机会。专业测试人员应该具备的技术条件:(1)熟悉多种开发工具;(2)多种OS;(3)多种自动化测试工具;(4)精通测试方法(白盒,黑盒);(5)熟练地撰写测试文档;(6)熟悉软件开发流程、测试流程细节、相关测试标准如CMM。专业测试人员应当具有的其他非技术条件:(1)很强的沟通能力;(2)有耐心、细致、敏锐的观察力,分析能力;(3)崇高的职业道德。结论:自己适合从事软件测试工作,上述诸点就是我的成长目标。8.14解释下列名词:调试、测试、纠错、单元测试、集成测试、系统测试、验收测试、静态测试、动态测试、第三方测试、压力测试、回归测试、测试经理、测试设计人员、测试执行人员、软件需求、测试需求、测试用例。调试是对程序错误进行定位。软件调试是在有问题的程序中设置断点,通过观察断点处的程序运行状态,来缩小问题代码的范围,进而捕获到问题的准确位置,并加以修正,最终解决问题。测试是寻找软件错误。纠错是对定位后的错误进行改正。单元测试就是小规模的模块测试。集成测试就是新对加入软件系统的模块,进行合成测试。系统测试是由软件公司测试部门,对全部集成后的软件系统进行全面测试。验收测试是由客户根据用户需求报告,对软件系统进行全面测试。静态测试是不运行被测试的程序,对软件进行测试。动态测试是运行被测试的程序,对软件进行测试。第三方测试有时又叫啄木鸟测试。其测试方人员,既不是甲方人员、也不乙方人员。压力测试是在严峻、极端的环境中,对软件进行测试。回归测试是在软件改错之后,再用改错前的测试用例,对该软件进行测试。测试经理是对软件测试全面负责的人。测试设计人员是对测试方案、测试用例进行设计的人。 测试执行人员是执行测试用例的人。软件需求是用户需求报告中的软件功能、性能、接口需求。测试需求是将软件需求分解后,形成的面向测试的需求。测试用例,是按照测试需求而设计出来、可具体的执行的测试用例。每一项软件需求都会分解为多个测试需求,每个测试需求都会设计出多个测试用例。这种分解或转换关系,如下图所示。习题99.1请读者谈谈对“软件产品分类”的看法。软件产品分为三类:(1)不需要客户化的软件产品。(2)只需要少量客户化工作的产品。(3)需要重新做业务流程规范和需求规格定义的软件产品。针对这三类不同的软件产品,有三种不同的发布和实施方法。在实施过程中,也要根据三类不同产品的特点,制定不同的实施策略,由实施工程师组织实施。9.2怎样解释“客户化”和“初始化”两个名词的含义及关系?客户化是指按照客户的实际情况,对软件产品的功能、性能、接口做适当的改动。初始化是指按照客户的实际情况,对软件产品的代码表(又称数据字典)进行初始化,即将客户的各种信息编码录入到相应的代码表中,如单位代码、部门代码、物资代码、设备代码、商品代码、科目代码、岗位代码等。此外,初始化还包括数据库中所有基本表的数据加载,即所有基本表中记录的录入工作。初始化工作简单,客户化工作复杂。客户化工作中自然包含了初始化工作,初始化工作只是客户化中的一小部分。9.3软件项目与软件产品有什么不同?软件产品是指不局限于特定业务领域、能被广大用户直接使用的软件系统,如操作系统、编译系统、工具系统、通用财务系统等。软件项目是指针对特定业务领域、需提供业务流程重组与优化的软件系统,如MIS,ERP,电子商务、自动跟踪控制系统等,它们一般叫做软件项目。9.4软件产品发布的方式有哪几种?不管是哪类软件产品,其产品发布的方式有下面几种:(1)聘请各有关领导、新闻媒体记者和大客户代表,召开新闻发布会,宣布产品的优点,描述其市场前景,现场演示介绍,厂商给嘉宾和客人赠送产品资料和纪念品。(2)在报纸、刊物、电视台、电台上做广告,宣传软件产品。(3)在各种交易会、展览会、博览会上租用摊位,展示软件产品。9.5三类软件产品的发布策略有何差异? 第一类不需要客户化的软件产品,在软件产品发布时只需要一份广告,它为客户准备的文档资料只是一份用户指南,而且这份用户指南不是随意赠送的,必须与产品一起打包销售。第二类只需少量客户化的软件产品,在软件产品发布时除了一份广告之外还要准备一份赠送给客户的文档资料,它是一份软件产品客户化的宣传方案。它的“用户安装手册”、“用户使用手册”、“系统管理员手册”也不是随意赠送的,必须与产品一起打包销售。第三类需要重新做业务流程规范和需求规格定义的软件产品,在软件产品发布时除了一份广告之外,还有一份准备赠送给客户的资料是行业应用软件框架,或是行业应用软件解决方案,该份资料不太详细,不会暴露软件企业的技术机密。9.6售前工程师为什么应该是该产品所属行业的行业领域专家?因为售前工程师是产品经理和产品形象的代表。在投标过程中,是由售前工程师向招标单位进行讲解,为了能把产品功能和特点清楚而流利地表达出来,让招标单位和客户感到满意,售前工程师必须掌握和精通产品行业的行业领域知识,所以说售前工程师应该是该产品所属行业的行业领域专家。9.7怎样理解“软件工程的覆盖范围包括了售前、售中、售后三个阶段的工作”?软件工程的售前工作是制订投标书,讲解投标书,主持技术谈判,参与合同签约,制订初步实施计划。售中工作是安装调试产品,产品的客户化,用户培训,产品验收交付。售后工作是产品日常维护,客户信息反馈。由上面各阶段的工作任务可以知道,售前、售中、售后三个阶段是相互联系的,不可分割的工作流程。只有进行售前阶段的工作,进行投标、签订合同,才有售中阶段的安装调试产品和产品交付。也只有经过售中阶段,才能有售后阶段的产品维护等工作。售前、售中、售后覆盖了软件工程的范围。9.8怎样理解实施工程师的职责与素质?实施工程师职责主要包括以下几个方面:产品安装调试、产品客户化、用户培训教育、产品验收交付。实施工程师必须具备以下素质:首先,对于不需要客户化的软件产品,实施工程师将光盘上的软件产品安装到用户系统上即可。如果用户需要培训,用用户指南作为教材进行定期培训。其次,对于只需要少量客户化的产品,实施工程师首先要进行调查和需求分析,在与客户达成完全一致的书面需求修改意见且经过评审和批准之后,再对软件的产品文档和程序进行修改和测试。同时还要保证文档与程序的一致性。最后,当软件实施工程师遇到要重新做业务流程再造和需求规格定义的软件产品时,实施工程师的职责相当于项目经理或者需要成立项目组,指定项目经理,运用原形法重新做业务流程规范和需求规格定义,在此过程中要与用户进行互动,以确保开发出来的产品与用户需求的一致性。9.9请编写一份“图书管理系统”的实施计划。实施计划根据具体项目的规模、大小的不同而不同,笔者仅给出编写实施计划的具体模板以供读者参考。项目实施计划模板1.实施计划 1.1工作任务的分解与人员分工[对于“图书馆信息系统”开发中需完成的各项工作,从需求分析、设计、实现、测试直到维护,包括文件的编制、审批、打印、分发工作,用户培训工作,软件安装工作等,按层次进行分解,指明每项任务的负责人和参加人员。]1.2接口人员[说明负责接口工作的人员及他们的职责。]1.3进度[对于需求分析、设计、编码实现、测试、移交、培训和安装等工作,给出每项工作任务的预定的开始日期、完成日期及所需资源,规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件。]1.4预算[逐项列出此开发项目所需要的劳务及经费的预算和来源。]1.5关键问题[逐项列出能够影响整个项目成败的关键问题、技术难点和风险,指出这些问题对项目的影响。]9.10怎样理解“软件维护是一种面向用户提供的服务”?在激烈的软件产品市场竞争中,同类软件产品的价格、功能、性能、接口都是不相上下的,那么用户如何选择呢?软件厂商要推销自己的产品,推销的焦点就是服务。谁的售后服务及时、到位,谁的产品就可能占领市场。现在流行一句话:“卖软件就是卖服务”。9.11传统软件维护要讨论的问题有哪些?传统软件维护要讨论的问题有:什么叫软件维护?软件维护分哪几类?维护过程有哪些?什么叫结构化维护?什么叫可维护性?维护有副作用吗?9.12怎样理解“在国际上,一般是大厂商做产品,小厂商做项目”?第一,小软件公司一般都是先做项目,然后集成项目的优点,形成一个产品,即产品来自于项目的积累。积累到一定程度,小公司就变成大公司了。第二,通常情况下,做一个真正通用的产品,它在需求获取、人员配置、环境测试、文档编写、市场运作等方面都需要较大的人力、物力和财力的投资,在这方面,小厂商是不具备的,只有大公司才能办得到。9.13怎样理解“任何厂商做项目的目的,都是为了做产品”?从技术上讲,厂商的产品来自于大量的多个同类项目共性的提炼。从市场上讲,只有提炼出产品,厂商才能获取较大的利润。所以任何厂商做项目的目的,都是为了做产品。9.14怎样理解“软件产品客户化”和“软件项目产品化”?软件产品客户化是指软件产品在推销和实施时,还要不断地满足、完善客户提出的要求。软件项目产品化是指任何软件厂商做项目的目的,都是为了做产品,只有这样才能扩大厂商的市场规模,扩大软件企业的规模,从而实现从小厂商做项目到大厂商做产品的过渡。9.15传统软件维护分哪几大类?传统软件维护分四大类,分别是:纠错性维护;适应性维护;完善性维护;预防性维护。 9.16简述软件维护的工作程序。软件维护的工作程序与软件开发的工作程序相仿。其工作程序是:维护的需求分析、维护的设计、修改程序代码、维护后的测试、维护后的试运行、维护后的正式运行、维护过程的评审和审计。9.17什么叫结构化维护和非结构化维护?结构化维护的前提是软件产品或软件项目必须有完善的文档,并且文档与程序代码互相匹配,两者完全一致。在这样的前提下,维护不但会比较省力,而且维护后可以用原来的测试用例进行回归测试。相反,若软件产品或软件项目只有程序而没有文档,或文档很不规范,很不齐全,对这样的软件进行维护,我们称为非结构化维护。9.18可维护性的软件应具备什么性质?所谓软件的可维护性,就是维护人员理解、掌握和修改被维护软件的难易程度。可维护性的软件,必须具备下列4条性质:可理解性、可测试性、可修改性和可移植性。9.19软件维护的副作用表现在哪4个方面?(1)使编码更加混乱,程序结构更加不清晰,可读性更差,而且有连锁反应。(2)数据结构是系统的骨架,修改数据结构是对系统伤筋动骨的大手术,在数据冗余与数据不一致方面,可能顾此失彼。(3)需要与用户协商,一旦有疏忽,可使系统发生意外。(4)对结构化维护要严防程序与文档的不匹配。9.20面向缺陷维护的内容是什么?面向缺陷维护的内容是:该软件产品能够正常运行,可以满足用户的功能、性能、接口需求,只是维护前在个别地方存在缺陷,用户不是非常满意。克服缺陷的方法是修改程序,也就是通常说的只修改程序,不修改数据结构。9.21面向功能维护的内容是什么?面向功能维护的内容是:该软件产品在功能、性能、接口上存在某些不足,不能满足用户的某些需求,因此需要增加某些功能、性能、接口。解决这些不足的方法是,不但要修改设计,而且也要修改程序,也就是通常说的,既要修改数据结构,又要修改编码。9.22两层结构和三层结构的软件维护方法有什么不同?两层结构(客户机/服务器)的软件维护方法是,将客户机和服务器上两部分软件分开维护。三层结构(客户机/应用服务器/数据库服务器)的软件维护方法是,软件维护在系统后台服务器上借助网络运行实现,使得软件的安装与升级,不需要到用户现场进行,在互联网上就可以实现一切维护工作,对用户来说就变成了一个完全透明的过程,不用再担心光盘上的安装或软盘的损伤。9.23软件维护与软件产品版本升级有什么关系? 一般而言,版本号中小圆点的左一位,表示该软件产品的第几个版本。版本号中小圆点的右一位,表示该版本的大修改次数。版本号中小圆点的右二位,表示该版本的小修改次数。只要当该软件产品的运行环境发生大改变时,或者该软件产品的功能变化超过30%时,其版本号中小圆点的左一位才能升级。例如,若维护前的版本号为V1.00,则维护后的版本号为V2.00。9.24怎样理解软件产品的版本号?软件产品的版本号,记录了该软件产品的修改次数和修改幅度大小。初始版本号一般是V1.00,其后每大改一次,版本号中小圆点的右一位加1。每小改一次,版本号中小圆点的右二位加1。特大修改后,版本号中小圆点的左一位加1。9.25怎样理解迭代模型RUP对软件维护的影响?UML的功能覆盖整个软件的开发周期,从需求分析开始,直到软件的发布、实施和维护为止,因而它对传统意义下的维护工作产生重大影响。UML把软件生存周期定义为4个主要阶段:初始、细化、构造、移交。经过这4个阶段的历程被称为一个开发周期,自动产生一个周期内的所有文档,从而生成一个软件产品。首次经历这4个阶段称为该产品的初开发周期,除非该产品的生命终止,否则它将重复初始、细化、构造和移交这4个阶段,从而演化为下一代产品,这就是对旧有产品的维护,也是新产品的升级换代,也就是开发周期的演化,也就是UML对软件维护工作的影响。9.26请设计“软件维护管理文档”的格式。表格式设计的理论基础是关系数据库设计的范式理论。一般而言,一个表由表头和表体两部分组成,共性的数据项放在表头,个性的数据项放在表体。只要懂得上述道理,任何复杂的表格均可设计出来。“软件维护管理文档”的格式设计,如表所示。(1)用户意见反馈表所属产品编号:反馈人:反馈日期:意见分类编号意见描述用户姓名(2)用户意见分类整理表所属产品编号:整理人:整理日期:意见分类编号意见描述同类意见出现次数(3)维护申请单所属产品编号:申请人:申请日期:维护分类编号维护描述批准日期维护日期(4)产品缺陷统计表所属产品编号:统计人:统计日期: 缺陷分类编号缺陷描述出现次数依此类推,可以将维护文档中各种表设计好,在此不再一一举例。习题1010.1CMMI本身内容丰富,是一所软件管理大学校,您同意这个观点吗?为什么?同意。因为CMMI是全球软件管理经验的总结与提炼,而且各个级别的目标明确、条文详细、措施有力。CMMI不但是技术管理的典范,而且吸取了发达国家政治体制、司法体制、民主体制的管理思想,集成了社会科学和自然科学两个方面的管理精华,应用到软件工程的管理上来。20多年来它在印度的实践也证明了它是一所软件管理大学校。10.2CMMI的5个级别各有哪些特征?SW-CMM的5个级别分别为:初始级(CMM1):组织内部是人治,是英雄创造历史。可重复级(CMM2):项目管理级,在组织内部重复使用项目管理的经验。已定义级(CMM3):组织级管理,在组织内部已经达到了法律化管理,由项目组级管理发展到组织级管理,13个KPA已制度化和法律化,组织级法律框架健全,工程过程和管理过程已文档化,软件测量数据库已开始建立。已管理级(CMM4):定量管理或数据管理,在组织内部已经达到了定量化管理,实现了定量的数据级管理,产品和项目级管理的经验已定量化,组织级过程管理已标准化和定量化,软件测量数据库已发挥量化管理的作用。优化级(CMM5):组织已经达到了循环优化和与时俱进。10.3CMMI的文档体系由哪三部分组成?CMMI的实施步骤是什么?整个CMMI过程体系文件可分成三个层次:总体文件、过程文件和支撑文件。(1)总体文件。它描述CMMI体系的总体实施方案,包括组织的策略方针、远景目标与阶段目标、流程概述、生命周期及裁减指南、度量系统、责任矩阵、体系文件清单等。(2)过程文件。它以过程定义为中心,描述过程的具体活动:什么人、什么时候、做什么事,这是整个CMMI体系的主体部分。组织的标准过程中,每一个过程包含多个活动,每一个活动对应的内容如下表所示。CMMI过程文件中每个活动对应的内容活动名称活动内容目标定义本过程的目标角色职责本过程中涉及的角色及其职责入口准则什么条件会触发本过程的启动输入文档、资源和数据活动及其步骤本过程有关活动的处理步骤输出文档、资源和数据出口准则什么条件会触发本过程的结束 软件度量工作量、缺陷数量、变更次数、问题个数、建议个数等(3)支撑文件。它提供具体的实施方法,包括各种各样的规程、规范、准则、指南、表格、模板、检查表和工具,如.NET编码规范、配置管理工具使用指南、项目开发计划模板等。支撑文件发挥了操作说明书的作用,其内容如下表所示。CMMI的支撑文件的内容支撑名称支撑内容规程针对过程文件中的某些重要活动,详细描述其实施步骤,规程的要素可以参考过程指南针对规程文件中的某些实施步骤,给出更具实际意义的指导规范对于某些重要活动或步骤的实现方法进行标准化推荐模板项目实施过程中,某些活动的执行需要生成文档;模板文件为这些文档的编写提供了参考和指导检查表项目实施过程中,某些活动的执行需要生成文档;模板文件为这些文档的编写提供了参考和指导软件组织内部的所有开发文档和管理文档,都必须根据这三部分文档规定的格式来编写。所有文档的封面和目录,都必须用中英文进行双语说明。因为CMMI主任评估师大部分来自英语国家,而且评估通过后,要报美国SEI组织批准备案。CMMI的实施步骤是:第1步,进行基本知识的培训。第2步,成立工作小组。第3步,建立文档体系。第4步,进行内部模拟评审。第5步,确定正式评估的工作步骤。第6步,进行正式评估。第7步,根据评估结果改进软件过程。10.4怎样理解“如果你对过程域吃透了,用好了,你就成为CMMI的内行了”?为了学好、用好CMMI,推荐“过程域是纲,纲举目张”的办法。对于CMMI1.2版本,要以它的22个过程域为纲(主线),以特定目标、特定实践、共性目标、共性实践为目,去熟悉每个级别中的内容,从内容中去发现内涵。作为第一步,先熟悉CMMI阶段模型ML2中的7个PA,为了实现每个过程域的目标(包括特定目标和共性目标),要规划每个PA对应的关键实践(包括特定实践和共性实践)及工作产品,然后在组织内实施,以改善软件管理过程。10.5软件配置管理的目的是什么?通俗地讲,软件配置管理的目的,就是为了做到“三个有利于”:有利于配置项的综合管理,有利于基线的变更管理,有利于版本的升级管理,以保证所交付的软件版本产品能够满足需求规格说明书中的各项具体要求,节省人力、物力资源,加强安全与保密工作。科学地讲,软件配置管理的目的,就是为了建立和维护在整个软件生存周期内软件产品的完整性。10.6配置项标识是配置管理的基础。请读者设计一套配置项的标识方案。只要你理解了标识两个字,设计一套配置项的标识方案就不难了。标识设计有两个要点,一是标识的唯一性,二是标识的规律性。唯一性就是各不相同,规律性就是便于查找与检索。事实上,软件产品版本号就是一套标识方案,我们用此方案来标识配置项。为此,规定如下: 产品名称.配置项名称.版本标识号其中版本标识号定义为X1X2.X3X4.X5X6X1X2两位标识大版本号,X3X4两位标识中版本号,X5X6两位标识小版本号。对于小项目或小产品,只要用一位标识大版本号、用一位标识中版本号、用一位标识小版本号即可。10.7什么是配置项?什么是配置管理?软件配置管理中的基本单元,称为软件配置项。在开发过程中,将软件的文档、程序、数据进行分割与综合,以利于软件的定义、标识、跟踪、管理,使其最终形成受控的软件版本产品,这一管理过程称为软件配置管理。10.8这里讲的“版本”,泛指配置项的版本,当然包括软件工作产品的版本和最终交付给顾客的软件产品版本。怎样理解这句话?可以这样理解:配置项的粒度可大可小,无论大小,都必须有标识,没有标识就找不到控制对象,就无法控制它。10.9在VSS中,怎样理解“存取控制通过配置管理中的三个库加以实现”?存取控制通过配置管理中的3个库加以实现,这3个库都属于配置管理库,它们分别是:(1)软件开发库DL(DevelopmentLibrary)。它是项目组开发人员的“个人配置库”,专门记录每个人每次上机的工作状态,存放每个人工作产品,动态跟踪个人工作轨迹。(2)软件基线库BL(BaselineLibrary)。它是“项目组的团队配置库”,存放团队配置项,即存放项目组公用的软件工作产品。(3)软件产品库PL(ProductLibrary)。它是“软件组织的配置库”,存放公司的最终软件产品版本。以上3个库都有不同的操作权限,DL库由程序员个人操作,BL库由项目组的配置管理员操作,PL库由公司的配置管理员操作。10.10“Checkout—Edit—Checkin”操作是什么意思?它与配置管理工具有什么关系?“Checkout—Edit—Checkin”,这是配置管理工具的基本操作,这种操作是对3个库而言的。对每一个库中的内容进行操作(比如增、删、改),要先将操作内容从库中取出,放入内存缓冲区,这一动作叫做“Checkout”。当操作(Edit)完成后,又要将本次操作的内容放入相应的库中,这一动作叫做“Checkin”。值得注意的是,每次Checkout后,相应库中原来的内容仍然保留着。每次Checkin后,也不会覆盖原来的内容,这就自动保存了可供追踪的轨迹。以“Checkout—Edit—Checkin”操作为基础,以版本控制为中心、进行软件配置项的标识、跟踪与管理的电子工具,就是配置管理工具。程序员只能在软件开发库上作“Checkout—Edit—Checkin”操作。10.11软件配置管理员的职责有哪些?配置管理员是一个工作岗位,专业软件公司有一名专职的配置管理员,他的工作职责是:(1)与项目经理一起,识别出项目的所有基线,并标识出这些基线及其所属的配置项,再根据有关规范和规程制定配置管理计划。 (2)在配置管理服务器上建立配置管理库,作为配置管理的工作仓库,并对仓库进行管理和维护。(3)配置项变更控制。(4)基线变更控制。工作程序与配置项变更控制相同。(5)最终软件版本产品的生成控制。(6)对配置项、基线、软件版本产品进行跟踪和审计,并编制配置管理活动报告,供高级经理、项目经理、相关组和个人阅读。(7)定期或事件驱动方式,对软件开发人员进行配置管理知识培训。(8)配置管理工具的安装,包括服务器端的安装和客户端的安装,配置管理服务器的日常维护。10.12简述软件质量的定义。所谓软件质量,就是供方提供的软件产品满足用户明确和隐含需求的能力特性的总和。10.13针对软件质量保证问题,最有效的办法是什么?通常,人们将“质量标准”、“配置管理”、“测试测量”作为质量管理的三大支柱,而将“SQA计划”、“SQA进度”、“SQA评审和审计”作为质量管理三大要素。软件质量保证是一个质量管理过程,基本思想是以事前预防为主,以事后测试和纠偏为辅,采取标本兼治的方法,且以治本为主。为此,要从“事前、事中、事后”三个层次上对软件质量进行控制。归根结底一句话:软件质量保证的最有效的办法是软件质量过程管理,因为质量蕴涵在过程之中。10.14怎样理解“软件质量保证措施应以提前预防和实时跟踪为主,以事后测试和纠错为辅”?事前的预防措施,是指制定软件过程开发规范和软件产品质量标准,对软件生产和管理人员进行这方面的知识和技能的定向培训。事中的跟踪措施,是指按照CMM/CMMI或ISO9000的过程管理思想,对软件过程和软件产品的质量控制提供可视性管理。事后的纠错措施,是指对软件工作产品和软件产品加强评审和检测。评审是在宏观上把握方向,在微观上挑剔细节,找出不符合项。检测是为了发现Bug,改正错误。10.15怎样理解“项目”和“项目管理”?项目是一次性的多任务工作,它具有确定的开始日期、结束日期、工作范围、经费预算、质量标准,以及特定的功能、性能和接口要求。项目管理是为了实现项目目标,运用相关的知识、技能、方法与工具,对项目的计划、进度、质量、成本、资源进行管理和控制的活动。10.16请将“软件项目经理的十项工作程序”用流程图画出来。流程图如下图所示。 10.17如何理解和实践项目经理对程序员的八项要求?(1)团队协作精神的训练和要求现在的软件开发不再是个人英雄主义打天下的时代,尤其是像微软这样的大软件公司,一个软件都是由几百人甚至几千人共同合作完成的,没有团队精神是无法想象的。(2)数据库和数据结构分析与设计能力的训练和要求程序员不但要学会看懂数据库和数据结构,而且要逐渐学会分析与设计数据库和数据结构。只有这样,初级程序员才能成长为高级程序员,高级程序员才能逐渐成长为系统分析员。(3)文档习惯的训练和要求良好的文档是正规研发流程中非常重要的环节,作为程序员,30%的工作时间写技术文档是很正常的,而作为高级程序员和系统分析员,这个比例在70%以上。(4)规范化代码编写能力的训练和要求良好的编写习惯,不但有助于代码的移植和纠错,也有助于不同技术人员之间的协作。代码具有良好的可读性,是程序员的基本工作需求。(5)复用性能力的训练和要求复用性设计、模块化思维,就是要程序员在完成任何一个功能模块或函数的时候,要多想一些,不要局限在完成当前任务的简单思路上,想想看该模块是否可以脱离这个系统存在,是否可以通过简单的参数修改方式,在其他系统和应用环境下直接引用,这样就能极大地避免重复性的开发工作。(6)测试习惯的训练和要求程序员在每段程序代码、每个构件或每个子模块完成后都进行认真的测试,就可以尽量将一些潜在的Bug问题尽早地发现和解决,这样对整个开发进程将会有很大的促进。(7)学习和总结能力的训练和要求程序员是很容易被淘汰、很容易落伍的职业,因此,程序员必须不断跟进新技术,学习新技能,随时总结,找到自己的不足,逐步提高自己。(8)引导程序员由“丑小鸭”变成“白天鹅” 项目经理要鼓励程序员将编程的实践经验上升到软件的抽象理论,又将软件的抽象理论返回到编程实践。引导与鼓励程序员超过项目经理,使“丑小鸭”变成“白天鹅”。10.18“科学技术上的发明、创造和成功,一半来自于童心童趣,一半来自于奋发图强”,读者有这方面的追求、知识、经历和体会吗?牛顿发现万有引力、瓦特发明蒸气机就是这样的例子。希望我将来会有这方面的体会。10.19请说明软件企业的工作流。(1)立项工作流第一步,市场调研,由市场人员书写调研报告,市场部经理签字确认。第二步,根据市场利润和开发成本,由副总经理/总工程师组织市场和开发人员,评审调研报告。第三步,评审通过后,由总经理/副总经理/总工程师签字立项。第四步,将立项报告通知软件开发部经理,由软件开发部经理组建立项目组。(2)下达任务工作流第一步,公司级指令性任务或部门间协作任务,由总工程师将任务下达给部门经理。第二步,部门经理将任务下达给项目经理。第三步,项目经理将任务下达给所属员工。(3)汇报工作流第一步,员工每日向项目经理汇报工作进度。第二步,项目经理每日向部门经理汇报项目进度。第三步,部门经理每周向总经理/副总经理/总工程师汇报项目进度。(4)开发工作流第一步,项目立项后,项目组进行需求调研,按需求功能模块向市场部报价。第二步,市场部按功能模块报单价与客户谈判并签订合同。第三步,合同生效后,项目组到客户方进行详细需求分析,书写用户需求报告。第四步,有合同的项目需求报告必须获得用户签字确认,无合同的项目需求报告由部门经理主持需求报告评审会,评审通过后签字确认。第五步,项目经理根据需求报告,制订详细开发计划,交部门经理签字确认。第六步,项目组进行数据库设计和模块实现设计,按规范书写设计说明书,并提交给部门经理。第七步,部门经理主持设计评审会,评审通过后签字确认。第八步,项目经理组织员工编程实现。第九步,项目完成编程和集成测试后,测试部门进行Alpha测试,由测试员书写并提交Alpha测试报告。第十步,项目经理向部门经理提交下列文档:用户需求报告、设计说明书、用户指南、Alpha测试报告和程序,申请项目验收。第十一步,部门经理审核上述文件和程序,合格后向总工程师报告,请求项目验收。第十二步,总经理/副总经理/总工程师主持项目验收,各有关部门经理参加,现场演示系统,并在验收单上签字确认。(5)结项(结题)工作流第一步,项目组制作出下列三种光盘:文档加源程序光盘、可执行程序光盘、演示光盘。第二步,项目经理写出项目总结报告交给总经理/副总经理/总工程师,并在服务器上清除该项目所有文档和程序。 第三步,所有母盘一式两份,分别保存到两个不同的物理空间中,注册入库。第四步,由总经理/副总经理/总工程师批准结项。END////////////'