信息系统项目管理师考试辅导教程(第3版)第2章软件工

“软件工程”这个概念最早是在1968年召开的一个当时被称“软件危机”的会议上提出的。自1968年以来，该领域已经取得了长足的进步。软件工程的发展已经极大地完善了我们的软件，使我们对软件开发活动也有了更深的理解。开发一个具有一定规模和复杂性的软件系统和编写一个简单的程序大不一样。其间的差别，借用Boodi的比喻，如同建造一座大厦和搭一个狗窝的差别。大型的、复杂的软件系统的开发是一项工程，必须按工程学的方法组织软件的生产与管理，必须经过计划、分析、设计、编程、测试、维t等一系列的软件生命周期阶段。这是人们从软件危机中获得的最重要的教益，这一认识促使了软件工程学的诞生。软件工程学就是研究如何有效地组织和管理软件开发的工程学科。IEEE在1983年将软件工程定义为：软件工程是开发、运行、维护和修复软件的系统方法。著名的软件工程专家Boehm于1983年提出了软件工程的7条基本原理：(1)用分阶段的生命周期计划严格管理；(2)坚持进行阶段评审；(3)实行严格的产品控制；(4)采用现代程序设计技术；(5)结果应能清楚地审查；(6)开发小组的人员应该少而精；(7)承认不断改进软件工程实践的必要性。软件工程方法学包含3个要素：方法、工具和过程。方法是指完成软件开发的各项任务的技术方法；工具是指为运用方法而提供的软件工程支撑环境；过程是指为获得高质量的软件所需要完成的一系列任务的框架。根据考试大纲，在软件工程基础知识方面，要求考生掌握以下知识点：•软件需求分析与定义；•软件设计、测试与维护；•软件复用；•软件质量保证及质量评价；•软件配置管理；•软件开发环境；•软件过程管理。本章主要介绍软件需求分析与定义，软件设计、测试与维护，软件质量保证及质量评价，软件配置管理，软件开发环境和软件过程管理方面的知识，有关软件复用的知识将在第3章介绍。2.1软件需求分析与定义根据StandishGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在这些高达74%的不成功项目中，有约60%的失败是源于需求问题，也就是差不多有一半的项目都遇到了这个问题，这一可怕的现象不得不让我们对需求分析引起高度的重视。2.1.1软件需求与需求过程1.什么是软件需求那么什么是软件需求呢软件需求就是系统必须完成的事，以及必须具备的品质具体来说，软件需求包括功能需求、非功能需求和设计约束3方面内容。(1)功能需求：是指系统必须完成的那些事，即为了向它的用户提供有用的功能,产品必须执行的动作。(2)非功能需求：是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。(3)设计约束：也称限制条件、补充规约，这通常是对解决方案的一些约束说明’例如必须采用国有自主知识版权的数据库系统,必须运行在UNIX操作系统之下等。另外，在大量与需求相关的书籍、文章中有一些诸如业务需求、•用户需求之类的词语，把很多读者搞得术语混淆，下面我们一起来看看这些概念。(1)业务需求（BusinessRequirement):是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。(2)用户需求（UserRequirement):是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。(3)系统需求（SystemRequirement):是从系统的角度来说明软件的需求，它包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有设计约束。也就是说，这分别对应于需求的3个不同的层次，从目标到具体，从整体到局部，从概念到细节。这些不同层次、不同类型的需求描述之间的关系如图2-1所示。2.需求工程需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程，通常包括需求开发和需求管理两大工作。(1)需求开发：包括需求捕获、需求分析、编写规格说明书和需求验证四个阶段。在这个阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际用户任务和目标，以及这些任务所支持的业务需求、分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型、对需求进行评审等工作。(2)需求管理：通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。而对于需求工程而言，最重要的还是需求开发，而需求开发总结起来就是包括需求捕获、需求分析、需求规格化、需求验证4个环节。需求捕获是为了收集需求信息，需求分析则是在需求捕获的基础上进行分析、建立模型，然后将其进行规格化形成《软件需求规格说明书》，最后再通过客户和管理层进行验证。需求规格化的工作就是编制《软件需求规格说明书》，具体的方法和注意事项请参考有关文档编制的相关章节。而需求验证的工作则包括组织一个由不同代表组成的小组，对需求规格说明书和相关模型进行审查；以需求依据编写测试用例，确认测试做好准备；在需求的基础上，起草第一份用户手册；确定合格标准，也就是让用户描述什么样的产品才算是满足他们的要求和适合他们使用的。2.1.2需求调查与问题定义需求调查与问题定义是看上去简单，做起来难的一件事。在很多人的印象中，需求调查，就是找用户聊聊说说，记个笔记。其实需求调查是否科学，准备是否充分，对调查出来的结果影响很大，这是因为大部分客户无法完整地讲述需求，而且也不可能看到系统的全貌。要想做好需求调查，必须清楚地了解3个问题。•What：应该搜集什么信息。•Where：从什么地方搜集这些信息。•How：用什么机制或者技术来搜集这些信息。接下来，我们就对这三个部分的内容进行一些更加详细的说明与描述。1-要捕获的信息一方面，需求分析员应该知道，从宏观的角度来看，要捕获的信息包括三大类：一是与问题域相关的信息（如业务资料、组织结构图、业务处理流程等)；二是与要求解决的问题相关的信息；三是用户对系统的特别期望与施加的任何约束信息。这样才能够有的放矢，不会顾此失彼。另外一方面，需求分析员在开展具体需求捕获工作时，应该做到在此之前明确自己需要获得什么信息，这样才有可能获得所需信息，才知道工作进展是否顺利，是否完成了目标。2.信息的来源除了要明确地知道我们需要什么方面的信息，还要知道它们可以从哪里获得。通常情况下，这些需要的信息会藏于客户、原有系统、原有系统用户、新系统的潜在用户、原有产品、竞争对手的产品、领域专家、技术法规与标准里。面对这么多种可能，在具体的实践中该从何下手呢其实也很简单，首先从人的角度来说，应该首先对涉众（也就是风险承担人、项目干系人）进行分类，然后从每一类涉众中找到1〜2名代表；而对于文档、产品而言，则更容易有选择地查阅。结合前面讲述的内容，在制订需求捕获计划的时候，不妨列出一个表格，左边写上想了解的信息，右边跟上认可能的来源，这样就能够建立一一对应的关系，使得需求捕获工作更加有的放矢，也更加高效。3.需求捕获技术当我们知道需要去寻找什么信息，并且也找到了信息的来源地，接下来就需要选择合适的技术进行需求捕获了。在此，我们列举出一些最常用的需求捕获技术。(1)用户访谈。用户访谈是最基本的一种需求捕获手段，也是最基本的一种手段。其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。准备问题：进行用户访谈之前，最好先对要询问的问题进行一些准备。准备的方法是围绕着想要获取的信息展开，设计一系列的问题，按顺序组织起来。而且还要预先准备好记录方式，主要包括本人记录、第三人记录或者是录音/录像的形式，不过采用录音/录像的方式应该征得被访谈者的同意，而且这种方法虽然看上去比较有效，不容易丢失信息，但这也会给后面的整理工作带来一定的工作量和难度。访谈时的技巧：在访谈时一定要注意措辞得当，在充分尊重被访谈者的基础上，尽量避免出现“我不知你在说什么”，“我是来帮助你更好地工作”这样的言语，否则将会破坏访谈的气氛，从而使访谈的效率大打折扣。在访谈时一定要注意保持轻松的气氛，选择客户有充时间的时段$行，在说话、问问题时应该尽量采用易于理解、通俗化的语言。另外，值得注意的是，分析人员应该在进行访谈之前进行一些相关领域的知识培训，充分阅读相关材料，以保证自己有较专业的理解与认识，让被访谈者能够信任你。应该询问的问题：在设计询问的问题时，应该考虑：自己的问题是否相关回答是否正式对方是回答这些问题的合适人选吗是否问了过多的问题是否还有更多的问题要问被访者？另外，还可以在询问过程中询问被访者还希望自己问他什么问题，还应该见哪些人总的来说，用户访谈具有良好的灵活性，有较宽广的应用范围，但是也存在着许多困难，诸如客户经常较忙，难以安排到时间；面谈时信息量大，记录较困难；沟通需要很多技巧，同时需要分析员有足够的领域知识；另外，在访谈时会遇到一些对于组织来说比较机密和敏感的话题。因此，这看似简单的技术，也需要分析人员拥有足够多的经验和较强的沟通能力。(2)用户调查。正如前面讲到的，用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常较广，不可能一一访谈。因此，我们就需要借助“用户调查”这一方法，通过精心设计要问的问题，然后下发到相关的人员手里，让他们填写答案。这样可以有效地克服前面提到的两个问题。但是与用户访谈相比，用户调查最大的不足就是缺乏灵活性；而且双方未见面，分析人员无法从他们的表情等其他动作来获取一些更隐性的信息;还有就是客户有可能在心理上会不重视一张小小的表格，不认真对待从而使得反馈的信息不全面。基于上述原因，因此较好的做法是将这两种技术结合使用。具体地讲，就是先设计问题，制作成用户调查表，下发填写完后，进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作补充。(3)现场观摩。俗话说得好，百闻不如一见，对于许多较为复杂的流程和操作而言，是比较难以用言语表达清楚的，而且这样做也会显得很低效。针对这一现象，分析团队可以就一些较复杂、较难理解的流程、操作采用现场观摩的方法来获取需求。具体来说，就是走到客户的工作现场，一边观察，一边听客户的讲解，甚至可以安排人员跟随客户工作一小段时间。这样就可以使得分析人员更加直观地理解需求。(4)•文档考古。对于一些数据流程比较复杂的，工作表单较多的项目，有时是难以通过说，或者通过观察来了解需求细节的。这个时候就可以借助于“文档考古”的方法，也就是对历史存在的一些文档进行研究，考古一词正是形象地说明了其主要的工作重心是结合已经填写完毕的、也就是带有数据的文件、表单、报告，从中获得所需的信息。不过当你准备采用该方法时，也要记住这个方法的主要风险，那就是历史的文档可能与新系统的流程、数据有一些不吻合的地方，并且还可能承载一些原有系统的缺陷。要想有效地避免和发现这些问题，需要分析人员能够运用自己的聪明才智，将其与其他需求捕获技术结合对照。还有一个负面因素就是，这些历史的文档中记载的信息有可能涉及客户的商业秘密，因此对数据信息的保密也是分析人员基本的职业道德。(5)联合讨论会。这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数6〜18人，召开时间1〜5小时。在会议之前，应该将与讨论主题相关的材料提前分发给所有要参加会议的人。在会议开始之后，首先应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议的最初，就是针对所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，第三步则是大家在此基础上对新的解决方案进行一番设想，在过程中将这些想法、问题、不足之处记录下来，形成一个要点清单。第四步就是针对这个要点清单进行整理，明确优先级，并进行评审。这种联合讨论