全部科目 > 信息系统监理师 >
2009年上半年 上午试卷 综合知识
第 2 题
知识点 开发文档   开发人员   人员沟通   项目管理  
关键词 沟通   开发   文档   项目管理   信息系统  
章/节 信息管理  
 
 
在开发信息系统时,用于系统开发人员项目管理人员沟通的主要文档是(2)。
 
  A.  系统开发合同
 
  B.  系统设计说明书
 
  C.  系统开发计划
 
  D.  系统测试报告
 
 




 
 
相关试题     GB/T16680—1996 

  第35题    2012年上半年  
根据《计算机软件文档编制规范》,不属于应用系统开发文档的是(35)。

  第35题    2013年下半年  
软件工程中,(35)不属于用户文档的内容。

  第32题    2013年上半年  
按照软件版本管理的一般规则,通过评审的文档的版本号最可能是(32)。

 
知识点讲解
· 开发文档
· 开发人员
· 人员沟通
· 项目管理
 
        开发文档
        开发文档是描述软件开发过程,包括软件需求、软件设计、软件测试、保证软件质量的一类文档,开发文档也包括软件的详细技术描述(程序逻辑、程序间相互关系、数据格式和存储等)。开发文档起到如下5种作用:
        (1)是软件开发过程中包含的所有阶段之间的通信工具,它们记录生成软件需求、设计、编码和测试的详细规定和说明。
        (2)描述开发小组的职责。通过规定软件、主题事项、文档编制、质量保证人员以及包含在开发过程中任何其他事项的角色来定义做什么、如何做和何时做。
        (3)用作检验点而允许管理者评定开发进度。如果开发文档丢失、不完整或过时,管理者将失去跟踪和控制软件项目的一个重要工具。
        (4)形成了维护人员所要求的基本软件文档。这些支持文档可作为产品文档的一部分。
        (5)记录软件开发的历史。
        基本的开发文档有可行性研究和项目任务书;需求规格说明;功能规格说明;设计规格说明,包括程序和数据规格说明;开发计划;软件集成和测试计划;质量保证计划、标准、进度;安全和测试信息。
 
        开发人员
        ①多媒体软件:项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
        ②多媒体电子出版物:策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
 
        人员沟通
        人员沟通在“风暴期”中显得尤为重要。因为在这个阶段,大家有可能质疑系统规划与管理师的能力。如果系统规划与管理师是在这个团队里被提拔上来的,大家对他还比较了解。但如果系统规划与管理师此时面对的是一个全新的团队,且员工的风格又大部分都是技术型的,对系统规划与管理师的能力也不太了解,那么,此时的系统规划与管理师就要多利用自己在管理上的优势,不断与要完成关键指标的员工保持密切沟通,多听、多问、多了解员工的想法,看看他们在执行过程中遇到什么困难,是否需要帮助。
        在这个阶段,系统规划与管理师一定要想办法在一两件自己擅长的事情上,建立自己在团队中的威望,让大家感到系统规划与管理师是有能力的,也能为大家解决一些问题。系统规划与管理师一定要有人际敏感度,就是要处理好与团队成员之间的关系,因为时间短、任务重,大家的压力都很大,如果能一起挺过这一关,就将为后续的合作打下良好的基础。
        在现实IT服务项目当中,经常会出现一种情况,即整个IT服务团队长期驻扎在客户现场,有的员工从一招进来就进入该项目,平时只有开会或费用报销时才回一趟公司,一个项目结束后,又很快被派到另外一个项目上,还是重复以前的工作状态。一段时间后,对客户的了解比对自己公司或组织的了解还深。因此,这些员工很容易被组织忽略,他们也往往缺少对公司企业文化、价值观的了解,所以流失率相对较高。其实这样的员工随时处于风暴期当中,如果系统规划与管理师的关注度不够,处理不当,很容易造成人员流失,再次陷入匆忙的招人/调人、工作交接或和客户解释工作的旋涡中,所以,系统规划与管理师需要对他们多关注,尤其是在他们需要组织帮助、需要系统规划与管理师帮助的时候。那么,他们平时不经常在公司内,系统规划与管理师怎样才能知道他们对公司或组织的需求呢?
        很简单,系统规划与管理师可以多花些时间主动与这些员工进行沟通。定期召开现场会议或电话会议,随时向他们传达公司或部门近期发生的大事,以及客户对他们工作的评价,往往员工很在意客户通过第三方给他们的评价。在此,系统规划与管理师一定要注意的是,这种反馈要以正面的信息为主,如果客户提出来的确有需要改进之处,那系统规划与管理师也要站在员工的角度一起想办法解决问题,而非刻板的传达客户的不满。此外,系统规划与管理师一定要与这个团队的小组长多沟通,因为平时大部分时间,异地团队是靠这个小组长来带领的,他的一言一行对整个团队影响非常大。
        除此之外,系统规划与管理师也可以不定期地去客户现场看望他们,从情感上照顾他们,让他们亲身感受到被重视的感觉。
        还有一种实际情况是“小团体”现象。通常遇到这种情况,系统规划与管理师都很头疼,尤其是在风暴期,如果没有处理好这个问题,系统规划与管理师就会有被架空的风险。“解铃还须系铃人”,这个系铃人就是这个小团体的精神领袖,他们往往以资格老或能力强而取信于众。所以,遇到这种情况,系统规划与管理师首先要切忌一个思维定式,即“只要是小团体,就肯定是不好的”,其实未必如此,仔细分析,小团体的凝聚力往往非常强,执行力也非常强,如果这个团队能在正确的方向上贡献他们的聪明才智,这时不但没必要去打散他们,甚至可以对其中做得比较好的员工给予一些鼓励,请他介绍自己的成功经验,往往这些员工在介绍成功经验时,就会意识到自己成功的特殊性,系统规划与管理师可通过不断让小团队的个人分享成功的方式,让他们多与其他团队成员进行更多的交流。
        如果小团队的方向与整个项目团队乃至整个组织的方向不一致,而且系统规划与管理师与“系铃人”多次沟通还没效果,系统规划与管理师就要考虑是否在工作分配或岗位分配上做些调整。总而言之,一切出发点都是以组织和团队的整体利益为主,而非系统规划与管理师的个人判断。
 
        项目管理
        构建嵌入式系统是一项复杂的任务,尤其是涉及到很多人员共同长期工作的时候。为了使嵌入式项目开发获得成功,必须对系统开发项目的工作范围、花费的工作量(成本)、可能遇到的风险、进度的安排、要实现的任务、经历的里程碑以及需要的资源(人、硬/软件)等做到心中有数,而项目管理可以提供这些信息。项目管理的过程一般包括初启、计划、执行、监控、结项,项目管理的范围覆盖整个系统生命周期过程。
               管理范围
               有效的项目管理集中于4P,即人员(People)、产品(Product)、过程(Process)和项目(Project)。必须将人员组织起来以有效地完成产品构建工作;必须和客户及其他利益相关者很好地沟通,以便了解产品的范围和需求;必须选择适合于人员和产品的过程;必须估算完成工作任务的工作量和工作时间,从而制订项目计划。
               “人的因素”非常重要,在所有项目中,最关键的因素是人员,涉及项目管理人员、高级管理人员、开发人员、客户和最终用户。人员能力成熟度模型(People Capability Maturity Model,PCMM)针对人员定义了以下关键实践域:人员配备、沟通与协调、工作环境、业绩管理、培训、报酬、能力素质分析与开发、个人事业发展、工作组发展以及团队精神或企业文化培育等。PCMM成熟度达到较高水平的组织,更有可能实现有效的项目管理事件。
               在制订项目计划之前,首先确定产品的目标和范围,考虑可选的解决方案,识别技术和管理上的限制。如果没有这些信息,就无法进行合理(精确)的成本估算,也无法进行有效的风险评估和适当的项目任务划分,更无法制定可管理的项目进度计划来给出意义明确的项目进展标志。确定产品的目标只是识别出产品的总体目标,而不用考虑如何实现这些目标。确定产品的范围是识别出产品的主要数据、功能和行为特性,并且应该用量化的方式界定这些特性。然后开始考虑备选解决方案,不讨论细节,使管理者与参与开发的人员根据特定的约束条件选择相对最佳的方案,约束条件有产品的交付期限、预算限制、可用人员、技术接口以及其他各种因素。
               开发过程提供了一个框架,一小部分框架活动适用于所有的项目,多种不同的任务集合使得框架活动适合于不同项目的特性和项目团队的需求。普适性活动(如质量管理、配置管理、测量等)覆盖了过程模型,独立于任何一个框架活动,且贯穿于整个过程之中。
               为了成功地管理项目,需要有计划、可控制,这样才能管理复杂的系统开发;需要了解可能会出现的各类问题以便加以避免。可以采用的方法有:
               (1)在正确的基础上开始工作。
               (2)保持动力。
               (3)跟踪进度。
               (4)做出正确的决策。
               (5)进行事后分析。
               成本估算
               系统开发成本估算主要指系统开发过程中所花费的工作量及相应的代价。为了使开发项目能够在规定的时间内完成,而且不超过预算,成本预算和管理控制是关键。项目开发成本的估算主要靠分解和类推的手段进行。分解技术是将项目分解成一系列较小的、容易理解的问题进行估算。常用的分解技术有:基于问题的估算、基于代码行(LOC)估算、基于功能点(FP)的估算、基于过程的估算、基于用例的估算。选择或结合使用分解技术,进行成本估算。基本的成本估算方法有如下几种。
               (1)自顶向下估算方法。估算人员参照以前完成的项目所耗费的总成本(或总工作量)来推算将要开发的系统的总成本(或总工作量),然后把它们按阶段、步骤和工作单元进行分配。
               自顶向下估算方法的主要优点是对系统级工作的重视,所以估算中不会遗漏集成、配置管理等系统级事务的成本估算,且估算工作量小、速度快。其缺点是不清楚低级别上的技术性困难,而这些困难将会使成本上升。
               (2)自底向上估算方法。自底向上估算方法是将待开发的系统细分,分别估算每一个子任务所需要的开发工作量,然后将它们加起来,得到系统的总开发量。这种方法的优点是对每一部分的估算工作交给负责该部分工作的人来做,所以估算较为准确。其缺点是缺少对各项子任务之间相互联系所需要工作量和与开发有关的系统级工作量的估算,因此预算往往偏低。
               (3)差别估算方法。差别估算方法是将开发项目与一个或多个已完成的类似项目进行比较,找出与某个相类似项目的若干不同之处,并估算每个不同之处对成本的影响,导出开发项目的总成本。该方法的优点是可以提高估算的准确度,缺点是不容易明确“差别”的界限。
               除以上方法外,还有许多方法,大致可分为三类:专家估算法、类推估算法和算式估算法。
               (1)专家估算法。该方法依靠一个或多个专家对要求的项目做出估算,其精确性取决于专家对估算项目的定性参数的了解和他们的经验。
               (2)类推估算法。在自顶向下的方法中,它是将估算项目的总体参数与类似项目进行直接比较得到结果;在自底向上方法中,类推是在两个具有相似条件的工作单元之间进行。
               (3)算式估算法。专家估算法和类推估算法的缺点在于它们依靠带有一定盲目性和主观性的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响,用于估算的方法有两种基本类型:由理论导出和由经验导出。
               典型的成本估算模型主要有动态多变量普特南(Putnam)模型和层次结构的结构性成本模型(Constructive Cost Model,COCOMO)的升级模型COCOMOII等。普特南模型基于软件方程,它假设在软件开发的整个生命周期中有特定的工作量分布。COCOMOII模型层次结构中有三种不同的估算选择:对象点、功能点和源代码行。
               风险分析
               新的系统建立时,总是存在某些不确定性。例如,用户要求是否能确切地被理解?在项目最后结束之前要求实现的功能能否建立?是否存在目前仍未发现的技术难题?在项目出现严重延期时是否会发生一些变更?等等。风险是潜在的,需要识别、评估发生的概率、估算其影响、并制定实际发生时的应急计划。
               风险分析在项目管理中具有决定性作用。当在软件工程的环境中考虑风险时,主要关注以下三个方面。一是关心未来。风险是否会导致项目失败;二是关心变化。用户需求、开发技术、目标机器以及所有其他与项目有关的实体会发生什么变化;三是必须解决需要做出选择的问题,即应当采用什么方法和工具,应当配备多少人力,在质量上强调到什么程度才满足要求等。
               风险分析实际上是贯穿软件工程中的一系列风险管理步骤,其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。
               进度管理
               进度安排包括把一个项目所有的工作分解为若干个独立的活动,并描述这些活动之间的依赖关系,估算完成这些活动所需的工作量,分配人力和其他资源,制定进度时序。进度的合理安排是如期完成软件项目的重要保证,也是合理分配资源的重要依据,因此进度安排是管理工作的一个重要组成部分。有两种安排软件开发项目进度的方式:
               (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图不能反映任务之间的并行关系。



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

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