您好,欢迎访问三七文档
思考题:1、软件项目开发首先要做的事是什么?答:首先要做的事软件需求分析,它是一个对用户的需求进行去粗取精、去伪存真、正确理解,然后把它用软件工程开发语言(形式功能规约,即需求规格说明书)表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题,建立软件的逻辑模型,编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求,设计建立相应的软件系统的体系结构,并将整个系统分解成若干个子系统或模块,定义子系统或模块间的接口关系,对各子系统进行具体设计定义,编写软件概要设计和详细设计说明书,数据库或数据结构设计说明书,组装测试计划。2、你认为该软件应具备的最重要的特性是什么?答:方便用户使用,功能界面友好,考虑各种特殊情况,有效避免发生异常。3、你认为怎样分工是最合理的?答:为保障软件工程的顺利实施,建立合理的角色管理体系是整个软件工程管理中一个重要的方面。我们采用角色分工的方法,首先划清角色职责,在具体的项目实施过程中为每位成员分配角色(根据项目规模和人员情况,可以一人兼多个角色和多人充当一个角色),以保证项目开发过程的各个环节责任明确、分工到人。角色数量与公司规模和项目规模有关,一般设置为项目经理、需求分析工程师、系统设计工程师、高级软件工程师、软件编码工程师、测试设计工程师、测试工程师、软件支持工程师8个角色。通过划分软件工程角色,可以根据技术员的技能安排相关的任务,可以有目的的培训或招聘相关技能的人才,可以有重点的稳定高级人才,防止人员流动带来的风险。我有什么类型的业务,我就需要什么样的人,而不是,我有什么样的人,我就做什么样的业务。如果没有明确的角色划分,就没有合理的职责分配,一个人几乎什么都需要掌握(学习是有成本的),当他达到一定的水平之后,自然就追求更高的待遇,他具备高级软件工程师的水平,但我们更需要程序员,我们应该提供什么样的待遇呢?我们需要什么样的人,我们就提供什么样的待遇。在传统的项目小组中,我们往往安排技术高超、经验最丰富的程序员做项目经理,这是一个误区,技术高超、经验丰富的人应该做系统分析和设计,他是技术专家,这是他的特长,项目经理应该是一个管理、协调和客户关系专家,有时,二者可以是一个人,但决不是一个角色,在大的项目中,二者更应当分开。技术人员一般不善于处理客户关系,很多项目的失败就是因为客户关系处理不好造成的。一个人到底是什么角色,是在项目中根据项目特点和个人技能临时确定的,并不一定代表一个人的能力和未来,是因事就人,而不是因人就事。思考题:1、软件项目计划主要完成什么工作?答:软件项目计划主要完成如下工作:1.确定范围对该软件项目的综合描述,定义起所要做的工作以及性能限制,它包括:(1)项目目标;(2)主要功能;(3)性能限制;(4)系统接口;(5)特殊要求;(6)开发概述。2.分配资源。(1)人员资源;(2)硬件资源;(3)软件资源;(4)其他。3.进度安排。进度安排的好坏往往会影响整个项目的按期完成,因此这一环节是十分重要的。制定软件进度与其他工程没有很大的区别,其方法主要有:(1)工程网络图;(2)Gantt图;(3)任务资源表;(4)成本估算;(5)培训计划。2、你认为项目开发计划中的最重要的问题是什么?答:在项目开发流程中,影响项目成败的关键因素是需求分析和系统设计,需要由经验丰富的技术人员从事,但公司中具有这种技能的人往往不够,导致项目小组中无法进行职责分配,往往大家一块去调研、一块做设计、一块做编码,导致需求和设计风险较大、开发效率较低、开发成本较高,软件质量得不到保证。鉴于这种情况,我们可以成立软件工程小组、技术支持小组和客户服务小组三个可复用的组织,他们分别从事不同的工作,由不同技能的人组成,一个人可以参与多个组织。它们都为项目小组服务,并安排人员参与不同的项目小组,提供不同的技能,在某一方面可以做的更好。一个项目小组一般由软件工程小组和客户支持小组的部分成员,以及几名程序员临时组成,项目结束后,项目小组也随即解体。3、你认为项目计划怎么对软件开发有意义?答:制订软件项目计划的目的在于建立并维护软件项目各项活动的计划,软件项目计划其实就是一个用来协调软件项目中其它所有计划,指导项目组对项目进行执行和监控的文件。一个好的软件项目计划可为项目的成功实施打下坚实的基础。软件项目有其特殊性,不确定因素多,工作量估计困难,项目初期难于制定一个科学、合理的项目计划,制定一个好的计划,可以让客户了解你的目的和客户的是不是一致,不会导致做无用功的可能。所以,制定一个项目计划对软件开发是很有意义的。思考题:1、需求分析在软件开发中真的有那么重要吗?答:需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求。关键的问题是一定要编写需求文档。需求的另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。有些需求分析专家拓展了这个概念:“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性:需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性,是在开发过程中对系统的约束。从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的“需求”术语存在,真正的“需求”实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。所以,需求分析在软件开发中是必不可少的。2、分析系统流程图,流程图和数据流图的区别和各自的特点。答:系统流程图是在系统分析员在做系统构架阶段,或者说,在接触实际系统时,对未来构建的信息处理系统的一种描述。这种描述是相对简单且完全的,涉及到未来系统中使用的处理部件,如磁盘,显示器,用户输入以及处理过程的先后顺序表示等,标准的系统流程图应该有10种图元,具体的有国家标准。当然,系统流程图还可以用来表示现有的信息系统处理过程涉及的各个部件以及次序。系统流程图是描绘物理系统的传统工具.它的基本思想是用图形符号以黑盒子形式描述系统里面的每个部件(程序,文件,数据库,表格,人工过程等等).系统流程图表达的是信息在系统各部件之间流动的情况,而不是对信息进行加工处理的控制过程,因此尽管系统流程图使用的某些符号和程序流程图中使用的符号相同,但是它确是物理流程图而不是程序流程图数据流程图(DFD)是在系统分析员在系统设计阶段,对实际构建的系统分析综合后,提取逻辑模型的一个过程,它更关注于过程内数据的处理,而把具体处理数据的物理过程,物理分布忽略。实际上,最初始的数据流程图标准图元只有四个!实体,过程,数据流,数据的存储。并且,数据流的分析过程是逐步对实际过程求精的,从顶层数据流图,到分层数据流图,数据流,过程类型也逐步增加,直到形成最后的数据字典和底层数据流图。需要注意的是数据流图和程序设计中的程序流程图(FlowChat)是不同的,数据流图关心的是企业业务系统中的数据处理加工的客观过程,并不关心未来电子化处理的加工过程;数据流图中流动的只是数据,并没有控制过程,但在程序流程图当中,必须有控制逻辑。流程图是流经一个系统的信息流、观点流或部件流的图形代表。在企业中,流程图主要用来说明某一过程。这种过程既可以是生产线上的工艺流程,也可以是完成一项任务必需的管理过程。例如,一张流程图能够成为解释某个零件的制造工序,甚至组织决策制定程序的方式之一。这些过程的各个阶段均用图形块表示,不同图形块之间以箭头相连,代表它们在系统内的流动方向。下一步何去何从,要取决于上一步的结果,典型做法是用“是”或“否”的逻辑分支加以判断。流程图是揭示和掌握封闭系统运动状况的有效方式。作为诊断工具,它能够辅助决策制定,让管理者清楚地知道,问题可能出在什么地方,从而确定出可供选择的行动方案。3、怎样写符合规范的数据流图和数据词典?答:1.应适当的为数据流、加工、数据存储以及外部实体命名,名字应该反映该成分的实际含义,避免使用空洞的名字。2.一个加工的输出数据流,不应与输入数据流同名,及时他们的组成完全相同。3.允许一个加工有多条数据流流向另一个加工,也允许一个加工有两条相同的输出数据流流向不同的加工。4.保持父图与子图的平衡。也就是说,父图中的某加工的输入输出流必须与他的子图的输入输出数据流在数量上和名字上相同。值得注意的是,如果父图中的一个输入(输出)数据流对应于子图中的几个输入(输出)数据流,而子图中组成这些数据流的数据项的全体正好是父图中的这一个数据流,那么他们仍然算是平衡的。5.在自顶向下的分解过程中,若一个数据存储首次出现时,只与一个加工有关系,那么这个数据存储应作为这个加工的内部文件而不必画出。6.保持数据守恒,也就是,一个加工的所有输出数据流中的数据必须能从该加工的输出流中直接获得,或者通过该加工能产生的数据。7.每个加工必须既有输入数据流,又有输出数据流。8.在整套数据流图中,每个数据存储必须既有读的数据流,又有写的数据流。但是在某张子图中,可能只有读没有写,或者只有写没有读。4、怎样组织对该工作的评审?答:对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。思考题1.系统设计和需求分析的关系是什么?两者必须先后关联吗?答:系统设计时把需求分析变换成软件表示的过程,主要包含两个阶段:软件体系结构设计和部件级设计阶段。前者为概要设计,后者为详细设计。系统设计是将需求分析转化为数据结构和软件,进而将软件体系结构性元素转化为软件部件的过程性描述,得到软件详细的数据结构和算法的过程。因此,系统设计时基于需求分析的。两者必须是先后关联,如果不这样,系统设计的盲目的,会导致这个工程失去目标和方向,最终导致失败。2.怎样描绘系统的体系结构?答:体系结构的描述有多种风格:数据位中心的体系结构;数据流风格的体系结构;调用和返回风格的体系结构;面向对象风格的体系结构;层次式风格的体系结构。3.怎样绘制符合规范的流程图。答:首先要对整个系统流程有清晰的认识,其次要使用合适的绘图软件帮助实现,最后要对绘好的流程图进行检查,保证逻辑的清晰正确。思考题1.简述详细设计阶段的主要任务。答:(1)为每个模块确定采用的算法,选择某种适当的工具表达算法的过程,写出模块的详细过程性描述;(2)确定每一模块使用的数据结构;(3)确定模块接口的细节,包括对系统外部的接口和用户界面,对系统内部其它模块的接口,以及模块输入数据、输出数据及局部数据的全部细节。在详细设计结束时,应该把上述结果写入详细设计说明书,并且通过复审形成正式文档。交付给下一阶段(编码阶段)的工作依据。(4)要为每一个模块设计出一组测试用例,以便在编码阶段对模块代码(即程序)进行预定的测试,模块的测试用例是软件测试计划的重要组成部分,通常应包括输入数据,期望输出等内容。2.简述详细设计说明书的主要内容。答:数据流向,页面方向,逻辑关系,输入/输出。3.怎样组织对设计阶段工作的评审?答:建议一:分层次评审我们知道用户的需求是可以分层次的,一般而言可以分成如下的层次:目标性需求:定义了整个系统需要达到的目标;功能性需求:定义了整个系统必须完成的任务;操作性需求:定义了完成每个任务的具体的人机交互;目标性需求是企业的高层管理人员所关注的,功能性需求是企业的中层管理人员所关注的,操作性需求是企业的具体操作人员所关注的。对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求,可能会很容易地导致“捡了芝麻,丢了西瓜”的现象,如果让高层的管理人员也去评审那些操作性需求,无疑是一种资源的浪费或者就会出现案例三的情形。建议二:正式评审与非正式评审结合正式
本文标题:49思考题
链接地址:https://www.777doc.com/doc-4482958 .html