思考题讲课教案

思考题：

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）是在系统分析员在系统设计阶段，对实际构建的系统分析综合后，提取逻辑模型的一个过程，它更关注于过程内数据的处理，而把具体处理数据的物理过程，物理分布忽略。实际上，最初始的数据流程图标准图元只有四个！实体，过程，数据流，数据的存储。并且，数据流的分析过程是逐步对实际过程求精的，从顶层数据流图，到分层数据流图，数据流，过程类型也逐步增加，直到形成最后的数据字典和底层数据流图。需要注意的是数据流图和程序设计中的程序流程图（Flow Chat）是不同的，数据流图关心的是企业业务系统中的数据处理加工的客观过程，并不关心未来电子化处理的加工过程；数据流图中流动的只是数据，并没有控制过程，但在程序流程图当中，必须有控制逻辑。

流程图是流经一个系统的信息流、观点流或部件流的图形代表。在企业中，流程图主要用来说明某一过程。这种过程既可以是生产线上的工艺流程，也可以是完成一项任务必需的管理过程。

例如，一张流程图能够成为解释某个零件的制造工序，甚至组织决策制定程序的方式之一。这些过程的各个阶段均用图形块表示，不同图形块之间以箭头相连，代表它们在系统内的流动方向。下一步何去何从，要取决于上一步的结果，典型做法是用“是”或“否”的逻辑分支加以判断。

流程图是揭示和掌握封闭系统运动状况的有效方式。作为诊断工具，它能够辅助决策制定，让管理者清楚地知道，问题可能出在什么地方，从而确定出可供选择的行动方案。

3、怎样写符合规范的数据流图和数据词典？

答：1.应适当的为数据流、加工、数据存储以及外部实体命名，名字应该反映该成分的实际含义，避免使用空洞的名字。

2.一个加工的输出数据流，不应与输入数据流同名，及时他们的组成完全相同。

3.允许一个加工有多条数据流流向另一个加工，也允许一个加工有两条相同的输出

数据流流向不同的加工。

4.保持父图与子图的平衡。也就是说，父图中的某加工的输入输出流必须与他的子图的输入输出数据流在数量上和名字上相同。值得注意的是，如果父图中的一个输入（输出）数据流对应于子图中的几个输入（输出）数据流，而子图中组成这些数据流的数据项的全体正好是父图中的这一个数据流，那么他们仍然算是平衡的。

5.在自顶向下的分解过程中，若一个数据存储首次出现时，只与一个加工有关系，那么这个数据存储应作为这个加工的内部文件而不必画出。

6.保持数据守恒，也就是，一个加工的所有输出数据流中的数据必须能从该加工的输出流中直接获得，或者通过该加工能产生的数据。

7.每个加工必须既有输入数据流，又有输出数据流。

8.在整套数据流图中，每个数据存储必须既有读的数据流，又有写的数据流。但是在某张子图中，可能只有读没有写，或者只有写没有读。

4、怎样组织对该工作的评审？

答：对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

思考题

1．系统设计和需求分析的关系是什么？两者必须先后关联吗？

答：系统设计时把需求分析变换成软件表示的过程，主要包含两个阶段：软件体系结构设计和部件级设计阶段。前者为概要设计，后者为详细设计。系统设计是将需求分析转化为数据结构和软件，进而将软件体系结构性元素转化为软件部件的过程性描述，得到软件详细的数据结构和算法的过程。因此，系统设计时基于需求分析的。两者必须是先后关联，如果不这样，系统设计的盲目的，会导致这个工程失去目标和方向，最终导致失败。

2．怎样描绘系统的体系结构？

答：体系结构的描述有多种风格：数据位中心的体系结构；数据流风格的体系结构；调用和返回风格的体系结构；面向对象风格的体系结构；层次式风格的体系结构。

3．怎样绘制符合规范的流程图。

答：首先要对整个系统流程有清晰的认识，其次要使用合适的绘图软件帮助实现，最后要对绘好的流程图进行检查，保证逻辑的清晰正确。

思考题

1．简述详细设计阶段的主要任务。

答：（1）为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程性描述；

（2）确定每一模块使用的数据结构；

（3）确定模块接口的细节，包括对系统外部的接口和用户界面，对系统内部其它模块的接口，以及模块输入数据、输出数据及局部数据的全部细节。

在详细设计结束时，应该把上述结果写入详细设计说明书，并且通过复审形成

正式文档。交付给下一阶段（编码阶段）的工作依据。

（4）要为每一个模块设计出一组测试用例，以便在编码阶段对模块代码（即程序）进行预定的测试，模块的测试用例是软件测试计划的重要组成部分，通常应包

括输入数据，期望输出等内容。

2．简述详细设计说明书的主要内容。

答：数据流向，页面方向，逻辑关系，输入/输出。

3．怎样组织对设计阶段工作的评审？

答：建议一：分层次评审

我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：

目标性需求：定义了整个系统需要达到的目标；

功能性需求：定义了整个系统必须完成的任务；

操作性需求：定义了完成每个任务的具体的人机交互；

目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。

建议二：正式评审与非正式评审结合

正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通

过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。两种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这两种方式。

建议三：分阶段评审

应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。

分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。

思考题

1．为什么说测试只能证明程序有错误，不能证明程序的正确性？

答：系统测试是管理信息系统开发过程中十分重要的环节。尽管在系统开发周期的各个阶段均采取了严格的技术审查，但依然难免留下差错，这些差错如果没有在投入运行前的系统测试阶段被发现并纠正，问题迟早会在运行中暴露出来，到那时要纠正错误将会付出更大的代价。

测试只能证明程序有错误而不能证明程序没有错误。人们经常会认为测试的目的是为了说明软件是没有问题的，因此程序编完后，只要找几个数据，使程序能够走通就完成了测试任务。这种认识不仅不正确，而且是十分有害的。因为出于这个目的，人们会自觉或不自觉地寻找容易使程序通过的测试数据，回避那些易于暴露软件错误的测试数据，致使隐藏的错误不被发现。恰恰相反，系统测试是以找错误为目的，我们不是要证明程序无错，而是要精心选取那些易于发生错误的测试数据，要以十分挑剔的态度去寻找程序的错误。这种关于测试目的的观念对于测试工作是有很大影响的。实践证明，由于人类思维的严密性是有限度的，加之开发人员主观、心理、经验等方面的因素，一般大型的软件在测试前是不可能没有错误的，因此测试的目的就是发现程序的错误。

2．简述软件测试的对象和内容。

答：需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。

软件测试主要工作内容是验证和确认，下面分别给出其概念：

验证是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。

1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程；

2.程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程；

3.评市、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是

否和规定的需求相一致进行判断和提出报告。

确认是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件。

1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确

性；

2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问

题。

3．试总结软件测试策略。

答：软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。

思考题

1．软件工程标准化的意义是什么?都有哪些软件工程标准?

答：为什么要积极推行软件工程标准化工作，其道理是显而易见的。仅就一个软件开发项目来说，有多个层次、不同分工的人员相配合，在开发项目的各个部分以及各开发阶段之间也都存在着许多联系和衔接问题。如何把这些错综复杂的关系协调好，需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时，需要进行阶段评审和验收测试。投入运行的软件，其维护工作中遇到的问题又与开发工作有着密切的关系。软件的管理工作则渗透到软件生存期的每一个环节。所有这些都要求提供统一的行动规范和衡量准则，使得各种工作都能有章可循。

软件工程的标准化会给软件工作带来许多好处，比如：

·可提高软件的可靠性、可维护性和可移植性；

·可提高软件的生产率；

·可提高软件人员的技术水平；

·可提高软件人员之间的通信效率，减少差错和误解；

·有利于软件管理；有利于降低软件产品的成本和运行维护成本；

·有利于缩短软件开发周期。

根据中国国家标准GB/T 15538-1995《软件工程标准分类法》，软件工程标准的类型有：·过程标准：如方法、技术、度量等。

·产品标准：如需求、设计、部件、描述、计划、报告等。

·专业标准：如职别、道德准则、认证、特许、课程等。

·记法标准：如术语、表示法、语言等。

2．请说明软件文档的作用?

答：文档在软件开发人员、软件管理人员、维护人员、用户以及计算机之间的有着多种桥梁作用。软件开发人员在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据，这个作用是显而易见的。软件开发过程中软件开发人员需制定一些工作计划或工作报告，这些计划和报告都要提供给管理人员，并得到必要的支持。管理人员则可通过这些文档了解软件开发项目安排、进度、资源使用和成果等。软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料，我们称此为用户文档。以上三种文档构成了软件文档的主要部分。

·哪些需求要被满足，即回答“做什么?”

·所开发的软件在什么环境中实现以及所需信息从哪里来，即回答“从何处?”

·某些开发工作的时间如何安排，即回答“何时干?”

·某些开发(或维护)工作打算由“谁来干?”

·某些需求是怎么实现的?

·为什么要进行那些软件开发或维护修改工作?

3．软件开发项目生存期各阶段包含哪些文档?

答：软件开发项目生存期各阶段应包括的文档包括如下：

可行性研究报告；项目开发计划；软件需求说明书；数据要求说明书；测试计划；概要设计说明书；详细设计说明书；用户手册；操作手册；测试分析报告；开发进度月报；项目开发总结；程序维护手册。