全部科目 > 系统集成项目管理工程师 >
2010年下半年 下午试卷 案例
第 1 题
知识点 进度管理计划   招募   编码   编码阶段   调试   进度管理   设计阶段   需求分析   需求分析阶段   政府   中标  
 
 
某信息系统集成公司(承建方)成功中标当地政府某部门(建设方)办公场所的一项信息系统软件升级改造项目。项目自2月初开始,工期1年。承建方项目经理制定了相应的进度计划,将项目工期分为四个阶段:需求分析阶段计划8月底结束;设计阶段计划9月底结束;编码阶段计划11月底结束;安装、测试、调试和运行阶段计划次年2月初结束。当年2月底,建设方通知承建方,6月至8月这3个月期间因某种原因,无法配合项目实施。经双方沟通后达成一致,项目仍按原合同约定的工期执行。
由于该项目的按时完成对承建方非常重要,在双方就合同达成一致后,承建方领导立刻对项目经理做出指示:(1)招聘新人,加快需求分析的进度,赶在6月之前完成需求分析;(2) 6月至8月期间在本单位内部完成系统设计工作。
项目经理虽有不同意见,但还是根据领导的指示立即修改了进度管理计划招募了新人,要求项目组按新计划执行,但项目进展缓慢。直到11月底项目组才刚刚完成需求分析和初步设计。
 
问题:1.1   除案例中描写的具体事项外,承建方项目经理在进度管理方面可以采取哪些措施?
供选择答案(将正确选项的字母填入答题纸对应栏内):
A、开发抛弃型原型 B、绩效评估 C、偏差分析
D、编写项目进度报告 E、确认项目范围 F、发布新版项目章程
问题:1.2   (1)基于你的经验,请指出承建方领导的指示中可能存在的风险,并简要叙述进行变更的主要步骤。
(2)请简述承建方项目经理得到领导指示之后,如何控制相关变更。
问题:1.3   针对项目现状,请简述项目经理可以采用的进度压缩技术,并分析利弊。




 
 
 
知识点讲解
· 进度管理计划
· 招募
· 编码
· 编码阶段
· 调试
· 进度管理
· 设计阶段
· 需求分析
· 需求分析阶段
· 政府
· 中标
 
        进度管理计划
        根据项目需要,进度管理计划可以是正式或非正式的,非常详细或高度概括的,其中应包括合适的控制临界值。
        在项目进度管理计划中,可规定如下内容:
        .项目进度模型制定:需要规定用于制定项目进度模型的进度规划方法论和工具。
        .准确度:需要规定活动历时估算的可接受区间,以及允许的应急储备数量。
        .计量单位:需要规定每种资源的计量单位,例如,用于测量时间的人时数、人天数或周数;用于计量数量的米、升、吨等。
        .组织过程关联:WBS为进度管理计划提供了框架,保证了与估算及相应进度计划的协调性。
        .项目进度模型维护:需要规定在项目执行期间如何在进度模型中更新项目状态、记录项目进展。
        .控制临界值:是在需要采取某种措施前,允许出现的最大偏差,通常用偏离基准计划的某个百分数来表示。需要规定偏差临界值,用于监督进度绩效。
        .绩效测量规则:需要规定用于绩效测量的挣值管理(EVM)规则或其他测量规则。例如,确定完成百分比的规则、用户考核进展和进度管理的控制账户、进度绩效测量指标等。
        .报告格式:需要规定各种进度报告的格式和报告频率。
        .过程描述:对每个进度管理过程进行书面描述。
 
        招募
        如果执行组织不能提供完成项目所需的人员,就需要从外部获得所需的服务,这可能包括雇佣独立咨询师,或把相关工作分包给其他组织。
 
        编码
               编码过程
               在给定了软件设计规格说明书后,下一步的工作就是编写代码。一般来说,编码工作可以分为四个步骤:
               (1)确定源程序的标准格式,制订编程规范。
               (2)准备编程环境,包括软硬件平台的选择,包括操作系统、编程语言、集成开发环境等。
               (3)编写代码。
               (4)进行代码审查,以提高编码质量。为提高审查的效率,在代码审查前需要准备一份检查清单,并设定此次审查须找到的bug数量。在审查时,要检查软件规格说明书与编码内容是否一致;代码对硬件和操作系统资源的访问是否正确;中断控制模块是否正确等。
               编码准则
               在嵌入式系统中,由于资源有限,且实时性和可靠性要求较高,因此,在开发嵌入式软件时,要注意对执行时间、存储空间和开发/维护时间这三种资源的使用进行优化。也就是说,代码的执行速度要越快越好,系统占用的存储空间要越小越好,软件开发和维护的时间要越少越好。
               具体来说,在编写代码时,需要做到以下几点:
               .保持函数短小精悍。一个函数应该只实现一个功能,如果函数的代码过于复杂,将多个功能混杂在一起,就很难具备可靠性和可维护性。另外,要限制函数的长度,一般来说,一个函数的长度最好不要超过100行。
               .封装代码。将数据以及对其进行操作的代码封装在一个实体中,其他代码不能直接访问这些数据。例如,全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性,提高了对象的内聚性,使封装后的代码对其他行为的依赖性较小。
               .消除冗余代码。例如,将一个变量赋给它自己,初始化或设置一个变量后却从不使用它,等等。研究表明,即使是无害的冗余也往往和程序的缺陷高度关联。
               .减少实时代码。实时代码不但容易出错、编写成本较高,而且调试成本可能更高。如果可能,最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。
               .编写优雅流畅的代码。
               .遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜,而且能捕捉到通过传统测试检查不到的各种问题。
               编码技术
                      编程规范
                      在嵌入式软件开发过程中,遵守编程规范,养成良好的编程习惯,这是非常重要的,将直接影响到所编写代码的质量。
                      编程规范主要涉及的三方面内容:
                      .命名规则。从编译器的角度,一个合法的变量名由字母、数字和下画线三种字符组成,且第一个字符必须为字母或下画线。但是从程序员的角度,一个好的名字不仅要合法,还要载有足够的信息,做到“见名知意”,并且在语意清晰、不含歧义的前提下,尽可能地简短。
                      .编码格式。在程序布局时,要使用缩进规则,例如变量的定义和可执行语句要缩进一级,当函数的参数过长时,也要缩进。另外,括弧的使用要整齐配对,要善于使用空格和空行来美化代码。例如,在二元运算符与其运算对象之间,要留有空格;在变量定义和代码之间要留有空行;在不同功能的代码段之间也要用空行隔开。
                      .注释的书写。注释的典型内容包括:函数的功能描述;设计过程中的决策,如数据结构和算法的选择;错误的处理方式;复杂代码的设计思想等。在书写注释时要注意,注释的内容应该与相应的代码保持一致,同时要避免不必要的注释,过犹不及。
                      性能优化
                      由于嵌入式系统对实时性的要求较高,因此一般要求对代码的性能进行优化,使代码的执行速度越快越好。以算术运算为例,在编写代码时,需要仔细地选择和使用算术运算符。一般来说,整数的算术运算最快,其次是带有硬件支持的浮点运算,而用软件来实现的浮点运算是非常慢的。因此,在编码时要遵守以下准则:
                      .尽量使用整数(char、short、int和long)的加法和减法。
                      .如果没有硬件支持,尽量避免使用乘法。
                      .尽量避免使用除法。
                      .如果没有硬件支持,尽量避免使用浮点数。
                      下图是一个例子,其中两段代码的功能完全一样,都是对一个结构体数组的各个元素进行初始化,但采用两种不同的方法来实现。下图(a)采用数组下标的方法,在定位第i个数组元素时,需要将i乘以结构体元素的大小,再加上数组的起始地址。下图(b)采用的是指针访问的方法,先把指针fp初始化为数组的起始地址,然后每访问完一个数组元素,就把fp加1,指向下一个元素。在一个奔腾4的PC上,将这两段代码分别重复10 700次,右边这段代码需要1ms,而左边这段代码需要2.13ms。
                      
                      算术运算性能优化的例子
 
        编码阶段
        . 可靠性测试(含于单元测试);
        . 排错;
        . 调整可靠性活动计划;
        . 收集可靠性数据;
        . 明确后续阶段的可靠性活动的详细计划;
        . 编制可靠性文档。
 
        调试
        调试的任务就是根据测试时所发现的错误,找出原因和具体的位置,进行改正。调试主要由程序开发人员来进行,谁开发的程序就由谁来进行调试。常用的调试方法有试探法、回溯法、对分查找法、归纳法和演绎法。
 
        进度管理
        进度安排包括把一个项目所有的工作分解为若干个独立的活动,并描述这些活动之间的依赖关系,估算完成这些活动所需的工作量,分配人力和其他资源,制定进度时序。进度的合理安排是如期完成软件项目的重要保证,也是合理分配资源的重要依据,因此进度安排是管理工作的一个重要组成部分。有两种安排软件开发项目进度的方式:
        (1)系统最终交付日期已经确定,系统开发部门必须在规定期限内完成;
        (2)系统最终交付日期只确定了大致的年限,最后交付日期由软件开发部门确定。
        进度安排的常用图形描述方法有Gantt图(甘特图)和PERT(Program Evaluation&Review Technique,项目计划评审技术)图。
        (1)Gantt图。Gantt图中横坐标表示时间(如时、天、周、月、年等),纵坐标表示任务,图中的水平线段表示一个任务的进度安排,线段的起点和终点对应在横坐标上的时间分别表示该任务的开始时间和结束时间,线段的长度表示完成该任务所持续的时间。当日历中同一时段中存在多个水平条时,表示任务之间的并发。下图所示的Gantt图描述了三个任务的进度安排。该图表示:任务1首先开始,完成它需要12周时间;任务2在2周后开始,完成它需要18周;任务3在12周后开始,完成它需要10周。
        
        Gantt图实例
        Gantt图能清晰地描述每个任务从何时开始,到何时结束,任务的进展情况以及各个任务之间的并行性;但是它不能清晰地反映出各任务之间的依赖关系,难以确定整个项目的关键所在,也不能反映计划中有潜力的部分。
        (2)PERT图。PERT图是一个有向图,其基本符号如下图所示。
        
        PERT图的基本符号
        PERT图中的有向弧表示任务,可以标上完成该任务所需的时间,图中的结点表示流入结点的任务已结束,并开始流出结点的任务,这里把结点称为事件。只有当流入该结点的所有任务都结束时,结点所表示的事件才出现,流出结点的任务才可以开始。事件本身不消耗时间和资源,它仅表示某个时间点。每个事件有一个事件号及出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始;最迟时刻表示从该事件出发的任务必须在此时刻之前开始,否则整个工程就不能如期完成。每个任务还可以有一个松弛时间(slack time),表示在不影响整个工期的前提下,完成该任务有多少机动时间。为了表示任务间的关系,图中还可以加入一些空任务(用虚线有向弧表示),完成空任务的时间为0。
        PERT图的一个实例如下图所示,该图所表示的工程可分为12个任务,事件号1表示工程开始,事件号11表示工程结束(完成所有任务需要23个时间单位)。松弛时间为0的任务构成了完成整个工程的关键任务,其事件流为1→2→3→4→6→8→10→11,也就是说,这些任务不能拖延,否则整个工程就不能在23个时间单位内完成。
        
        PERT图示例
        PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间,还给出了任务之间的关系,即哪些任务完成后才能开始另外一些任务,还可以找出如期完成整个工程的关键任务。任务的松弛时间则反映了完成任务时可以推迟其开始时间或延长其所需完成的时间。PERT图不能反映任务之间的并行关系。
 
        设计阶段
        设计阶段监理进行质量控制的要点如下。
        (1)了解建设单位的建设需求和对信息系统安全性的要求,协助建设单位制定项目质量目标规划和安全目标规划。
        (2)对各种设计文件提出设计质量标准。
        (3)进行设计过程跟踪,及时发现质量问题,并及时与承建单位协调解决。审查阶段性成果,并提出监理意见。审查承建单位提交的总体设计方案,审查承建单位对关键部位的测试方案。
        (4)协助承建单位建立质量保障体系。
        (5)协助承建单位完善现场质量管理制度。
        (6)组织设计文件及设计方案交底会,制定质量要求标准。
 
        需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在10.3节中进行详细介绍。
        (3)面向问题域的分析(Problem Domain Oriented Analysis, PDOA)方法。PDOA更多地强调描述,而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素,是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图,但不同的是上下文图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段,并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程,明确各个部门之间的业务关系和每个业务处理的意义,为业务流程的合理化改造提供建议,为系统的数据流程变化提供依据。
               业务流程分析的步骤如下:
               (1)通过调查掌握基本情况。
               (2)描述现有业务流程(绘制业务流程图)。
               (3)确认现有业务流程。
               (4)对业务流程进行分析。
               (5)发现问题,提出解决方案。
               (6)提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               数据流图
               DFD是结构化分析中的重要方法和工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,一般将它作为需求说明书的组成部分。
               
               业务流程图符号
               DFD从数据传递和加工的角度,利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。具体来说,DFD的主要作用如下:
               (1)DFD是理解和表达用户需求的工具,是系统分析的手段。由于DFD简明易懂,理解它不需要任何计算机专业知识,因此通过它同客户交流很方便。
               (2)DFD概括地描述了系统的内部逻辑过程,是系统分析结果的表达工具,因而也是系统设计的重要参考资料,是系统设计的起点。
               (3)DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。
               在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况,用一个DFD是不够的。稍微复杂的实际问题,在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的DFD反映这种结构关系,能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1,第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,它的上层图称为父图,在它下一层的图则称为子图。
               
               分层数据流图
               概括地说,画DFD的基本步骤,就是“自顶向下,逐层分解”。检查和修改的原则如下:
               (1)DFD中的所有图形符号只限于前述4种基本图形元素。
               (2)顶层DFD必须包括前述4种基本元素,缺一不可。
               (3)顶层DFD中的数据流必须封闭在外部实体之间。
               (4)每个加工至少有一个输入数据流和一个输出数据流。
               (5)在DFD中,需按层给加工框编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
               (6)规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               (7)可以在DFD中加入物质流,帮助用户理解DFD。
               (8)图上每个元素都必须有名字。
               (9)DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合,也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD,数据字典难以发挥作用;没有数据字典,DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起,才能共同构成系统的规格说明。
               数据字典的设计包括:数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息:名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言、判定树及判定表。
               (1)结构化语言:介于自然语言和形式语言之间的一种半形式语言,在自然语言基础之上加了一些限度,使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
 
        需求分析阶段
        . 确定软件的可靠性目标;
        . 分析可能影响可靠性的因素;
        . 确定可靠性的验收标准;
        . 制定可靠性管理框架;
        . 制定可靠性文档编写规范;
        . 制定可靠性活动初步计划;
        . 确定可靠性数据收集规范。
 
        政府
        政府信息系统以电子政务为主要形式,是指政府机构在其管理和服务职能中运用现代网络技术打破传统行政机关的时间、空间和部门分隔的制约,使各级政府的各项监管更加严密,服务更加便捷,涉及政府机关、各团体、企业和社会公众,主要包括机关办公政务网、办公政务资源网、公众信息网和办公政务信息资源数据库几个部分。
        (1)安全级别高。政务信息数据中,有些关乎国家、政府部门、地方政策和利益,比个人或商务信息更为敏感;有些属于大规模的基础设施,比如档案、城建数据;有些具有服务特性,比如医保、社保、公积金、房屋交易等信息;加之电子政务行使政府职能的特点易导致政府信息系统受到各种攻击,包括黑客组织、犯罪集团和信息战时期的信息对抗等国家行为的攻击,因此,其安全问题尤其是数据安全应被重点关注。
        (2)业务的不间断运维需求高。政府信息系统面向社会提供外部服务,如出入境审批系统、身份证申领系统等,都必须在故障出现后以最短的时间恢复业务运行,否则导致业务受理停止,大量人员等待,大量紧急任务无法处理,影响政府办事效率和形象。
        (3)例行运维亟须加强。我国政府部分信息系统存在管理松散,制度不严明,执行乏力现象,包括内部信息外泄,个人下载或运行游戏、炒股、聊天、视频软件,甚至非法修改IP地址,卸载杀毒软件,不仅严重违反纪律,更易影响到关键应用的性能质量,因此,日常运维管理亟须加强。
 
        中标
        中标人的投标应当符合下列条件之一:
        (1)能够最大限度地满足招标文件中规定的各项综合评价标准。
        (2)能够满足招标文件的实质性要求,并且经评审的投标价格最低。但是投标价格低于成本的除外。
        评标委员会经评审,认为所有投标都不符合招标文件要求的,可以否决所有投标。依法必须进行招标的项目的所有投标被否决的,招标人应当重新招标。
        在确定中标人前,招标人不得与投标人就投标价格、投标方案等实质性内容进行谈判。评标委员会成员应当客观、公正地履行职务,遵守职业道德,对所提出的评审意见承担个人责任。评标委员会成员不得私下接触投标人,不得收受投标人的财物或其他好处。评标委员会成员和参与评标的有关工作人员不得透露对投标文件的评审和比较、中标候选人的推荐情况,以及与评标有关的其他情况。
        中标人确定后,招标人应当向中标人发出中标通知书,并同时将中标结果通知所有未中标的投标人。中标通知书对招标人和中标人具有法律效力。中标通知书发出后,招标人改变中标结果的,或者中标人放弃中标项目的,应当依法承担法律责任。招标人和中标人应当自中标通知书发出之日起30日内,按照招标文件和中标人的投标文件订立书面合同。招标人和中标人不得再行订立背离合同实质性内容的其他协议。招标文件要求中标人提交履约保证金的,中标人应当提交。
        依法必须进行招标的项目,招标人应当自确定中标人之日起15日内,向有关行政监督部门提交招标投标情况的书面报告。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2025 All Rights Reserved
软考在线版权所有