需求分析与系统设计1

需求分析与系统设计第一章软件过程本章的意图是在一个综述性的层次上来描述软件开发过程中的一些策略方面的问题。第一章软件过程1.1软件开发的本质1.2系统规划1.3软件生命周期的阶段1.4软件开发方法1.1软件开发的本质在涉及IS（信息系统）管理的文献中有许多关于项目失败、超出期限和预算、解决方案错误、系统不可维护等例子。由StandishGroup做的经常被引用的CHAOS研究报告1998年版声称，几乎有四分之三的软件项目由于上述原因中的一种或多种而失败。首先要了解的是：什么使得软件项目失败？项目出现问题的症结所在以及处理的方法是什么？为了解决这些问题，我们必须首先理解软件开发的本质。在一篇目前已经成为经典的文章中，Brooks（1987）指出了软件工程的本质和意外因素。软件工程的本质蕴涵在软件本身的固有困难中。我们只能承认这些困难，它们并不是一旦有了突破或有了“银弹”就可以解决的。根据Brooks的说法，软件工程的本质是软件固有的复杂性、一致性、可变性和不可见性的产物。软件的这4点“基本的困难”确定了软件开发中的一个不变事实。这个不变事实简要地指明软件是开发作为一种创造性活动的产品，是由工匠而不是美术家创作的工艺品或艺术品。在通常情况下，软件不是重复性制造活动的产物。一旦理解了这个不变事实，人们就应该着手解决软件工程的偶然因素——由于软件生产实践带来的困难能够由人工干预来解决。我们将各种“偶然的困难”归结为3类：1.投入者。2.过程。3.建模语言和工具。1.1软件开发的本质1.1.l软件开发的不变事实1.1.2投入者1.1.3过程1.1.4建模语言和工具1.1.l软件开发的不变事实软件是开发出来的而不是制造出来的。当然，不能否认软件工程的进展为开发实践带来了很多确定的因素，但是（不像传统工程那样）软件项目的成功仍然无法保证。一个组织不可能找到一个软件包能够使它的核心业务活动自动生成。电话公司的核心业务是电话技术，而不是人力资源或者会计。能够使一个组织运作（并具有竞争力）必须从零开发（或从存在的遗留系统中再开发），“标准软件包创建了一个适当的游戏场，但竞争必须来自其他的地方。”当然，在任何情况下，开发过程都应该利用构件技术。构件是一个具有良好设计功能（服务）和对其他构件的通信协议（接口）的软件的可执行单元。我们可以通过配置构件来满足应用需求。当前，最有影响的构件技术有：对象管理组（OMG）的公共对象请求代理体系结构（CORBA）。Microsoft的分布式构件对象模型（DCOM）。Sun的企业级JavaBeans（EJB）。软件包、构件以及一些相似的技术并没有改变软件生产的本质。尤其是，需求分析与系统设计的原理和任务仍然保持不变。最终的软件产品可以由标准和定制的构件组装而成，但“组装过程”还是一门艺术。坦率地说，我们甚至没有“备件”来替换“使用中”的系统的残缺构件。1.1.2投入者投入者是那些与软件项目之间存在利害关系的人。任何被这个软件系统影响或者影响系统开发的人都是投入者。其中有2种主要的投入者：客户（用户或系统所有者）。开发人员（分析员、设计员、程序员等）。我们倾向于使用术语客户而不是用户。从系统开发的角度看，区别两者肯定是有充分依据的。第一，客户是给开发付钱的人，负责制定决策。第二，即使客户有错，客户的需求也不能由开发者任意改变或拒绝，任何矛盾的、不可行的或不合法的需求都必须与客户再次进行协商。信息系统是社会系统，它们由人（开发者）为人（客户）开发，软件项目的成功由社会因素确定，技术是第二位的。有许多技术水平不高的系统在为客户工作并使客户获益，反之就不是这样，一个对客户没有任何觉察的或真实的益处的系统将被放弃，不管其技术上如何顶尖。在通常情况下，软件失败的主要原因可以追溯到投入者的因素。在客户方面，项目失败是因为：客户的需要被误解或没有被完全捕捉。客户需求变化得过于频繁。客户没有准备为项目提交足够的资源。客户不想与开发人员合作。客户具有不现实的期望。系统不再对客户有利。项目还会由于开发者不能胜任这项任务而失败。随着软件复杂度的增加，人们越发地认识到开发者的技能和知识非常关键。好的开发者能够给出一个好的解决方案，杰出的开发者可以给出更好的方案，因为它更快也更便宜。就像出自FredBrooks的那句著名的俏皮话：“杰出的设计来自杰出的设计者。”开发者的优秀和责任心是提高软件质量和生产率的关键。为了保证软件产品能成功地交给客户，更重要地，从中取得来自生产率提高的效益，软件组织必须采取一些明显的涉及开发者的措施：雇佣最好的开发者。为现有的开发者提供继续培训和教育的机会。鼓励开发者之间进行信息交换和交互，使他们互相促进。通过消除障碍并将努力引导到生产工作来激励开发者。提供一个令人鼓舞的工作环境。使个人目标和组织策略及目标相一致。强调团队工作。1.1.3过程软件开发过程确定以促进开发小组内部合作的活动和组织的程序，使得能交给客户一个性能优良的产品。过程模型包括：说明执行活动的次序。说明需要交出什么样的制品，以及什么时候交出。将活动和制品分配给开发者。提供监控项目进程、评估产出和计划未来项目的准则。开发过程无法标准化或编成法典自动地被组织接受，每个组织必须定义自己的过程模型或将一个通用的过程模板客户化，如由Rational软件公司提供的被称为Rational统一过程的那个模板。组织所采用的过程必须与它的开发文化、社会动力、开发人员的知识和技能、管理的实践、客户的期望、项目的大小甚至应用领域的种类等方面相一致。因为所有的这些因素都是易变的，组织应为每个软件项目改变它的过程模型并创建过程模型的一个变形。例如，根据开发人员对建模方法和工具的熟悉程度，项目进行过程中可能需要含有特殊的培训课程。项目的大小对过程影响可能最大。在小项目中（10个左右开发人员），可能根本不需要形式化的过程，这样的小组可以非形式地交流并响应变化。而在大项目中，一个非形式化的通信网络肯定不够，而用于控制开发的良定的过程就是必需的了。1.1.3过程1.1.3.l迭代式和增量式开发1.1.3.2能力成熟度模型1.1.3.3ISO90001.1.3.1迭代式和增量式开发现代软件开发过程总是迭代增量的。系统模型通过分析、设计和实现这样一些阶段得到精化和转换——细节在连续的迭代时加进去，必要时还要进行更新和改进，而且软件模块的增量式的版本维持了用户的满意度，井提供对仍在开发之中的模块的重要反馈。就像Rational统一过程所陈述的那样“迭代过程就是涉及管理可执行的版本流的过程，增量过程则是涉及系统体系结构连续集成以产生这些版本的过程，其中每个新的版本都在其他版本基础上嵌入了增量的改进。”迭代式和增量式过程是否成功在早期系统体系结构模块的识别时就能断定。这些模块应该是小规模、高度一致而且具有最小的重叠（耦合）度的，其中模块的执行次序也很重要。一些模块如果它们依赖于仍在开发中模块的信息或计算的话也许就不能执行。迭代式和增量式开发如果不能控制项目的实际进程就可能退化为“专门的处理”，除非它是有计划和有控制的。1.1.3.2能力成熟度模型从事软件生产的组织都面临一个重要的挑战，即改进它的开发过程。很自然地，为了进行过程改进，组织必须了解当前过程的问题是什么。能力成熟度模型（CMM）是一个流行的用于过程评估和改进的方法。CMM由美国匹兹堡的卡内基·梅隆大学的软件工程研究所（SEI）给出，起初被美国国防部用来评估来竞标国防合同的组织的IT能力，现在已被美国和其他地方的IT业广泛地使用。CMM基本上就是一个交给组织填写的问卷，这个问卷后面有一个验证和证明过程，这个过程为填表的组织赋予CMM的五个级别中的一个级别，级别越高，组织的过程成熟度越好。图1-1定义了这五个级别，并附上了每个级别主要特征的简短描述，而且指明了当组织需要达到更高的级别时，其过程改进的主要范围。Arthur称成熟度级别是“通向软件卓越的阶梯”，这个阶梯上的5个台阶分别是混沌、项目管理。方法和工具、度量和连续质量改进。经验表明，要按这个成熟度的尺度向上进一级要花几年的时间，大多数组织处于第1级，有一些达到第2级，达到第5级的寥寥无几。下面一些问题展示了这项任务的困难：软件质量保证功能是否有独立于软件开发项目管理的管理报告渠道？涉及软件开发的每个项目是否都具有软件配置控制功能？对那些在没有制定合同承诺的情况下的软件开发的管理评价是采用正式的过程吗？有正式的过程来产生软件开发日程吗？有正式的过程来估计软件开发的成本吗？’有收集软件代码和测试错误的统计吗？资深管理是否有一种机制作为对软件开发项目状态的常规评价？有一种机制用来控制软件需求的改变吗？1.1.3.3ISO9000除了CMM外，还有其他的过程改进模型，特别受到关注的是国际标准化组织开发的关于质量标准的ISO9000系列。ISO标准应用到质量管理和过程中，以生产出具有品质保证的产品。ISO标准是通用的，可以应用到任何工业和所有类型的业务中，包括软件开发。ISO9000标准的主要承诺是：如果过程正确，则该过程的产出（产品或服务）也将是令人满意的，“质量管理的目的就是要通过按照将质量建造成产品，而不是按照将质量试验成产品的方式，来生产具有品质保证的产品。”按照我们前面对过程的讨论，ISO标准并没有强制性的或规定的过程，这些标准提供的是关于什么是必须完成的、而不是活动怎样执行的模型。请求ISO认证（也称为注册）的组织必须说明它所做的、做它所说的、演示它已经做的。一个ISO认证的组织的敏感性测试即使当它的全部劳动力都被替换了，它也应该能够制造出具有品质的产品，或者提供具有品质的服务。为了这个目标，这个组织一定要记录和整理它的所有活动，并为每个过程规定成文的步骤，包括当出现错误时或者客户抱怨时要如何做的活动。与CMM认证一样，ISO认证只有在ISO注册员实地检查后才能批准。这些检查还要按一定规律的间隔重复进行。组织被迫进入一个模式，它是通过提供客户要求的产品和服务所确保的竞争力。1.1.4建模语言和工具投入者和过程是成功的3个因素中的2个。第3个因素由建模语言和一些工具组成，为制品建模需要通信（语言）和文档化（工具）。开发人员需要一种语言来创建可视化的和其他形式的模型，以及与客户和其他开发人员进行的讨论。这个语言应该支持各个抽象层次上模型的构造，以在不同程度上详细表示所提出的解决方案。这个语言应该具有强的可视构件，按照流行的说法是“一幅画胜似千言万语”。它还应该具有较强的说明语义，即它应该支持在“描述性”语句中捕获“过程性”含义，说出“什么”需要做而不是“怎样”去做。开发人员也需要一个CASE工具（计算机辅助软件工程），CASE工具使得在一个中央资源库中存储和检索模型、并在计算机屏幕上对模型进行图形和文本的操作成为可能。理想的情况是：资源库应该为共享的多个用户（即多个开发者）提供模型的存取手段。CASE资源库的典型功能是：模型的协同存取。支持开发人员之间的合作。存储模型的多种版本。标识版本之间的区别。允许在不同模型中共享同一个概念。检查模型的一致性和完整性。生成项目报告和文档。生成数据结构和程序代码（正向工程）。从存在的实现中产生模型（逆向工程）等等。1.1.4建模语言和工具l.1.4.l统一建模语言1.1.4.2CASE和过程改进1.1.4.1统一建模语言“UML是一个通用的可视化建模语言，它可以用来说明软件系统制品及其可视化、构造和文档化。”UML由Rational软件公司开发，以统一早期方法和表示法中好的特性。1997年，对象管理组织（OMG）批准它为标准建模语言。从那时起，UML得到了进一步完善，并且已经被IT业界广泛采用。虽然后来Rational又提出了一个与之相应的过程，称为Rational统一过程，但UML仍然独立于任何软件开发过程。不过，非常清楚的是，一个采用UML的过程必定支持面向对象方法来进行软件生产。UML不适用于老式的结构化方法，这种方法使