需求分析与系统设计.ppt

需求分析与系统设计 第一章 软件过程 本章的意图是在一个综述性的层次上来描述软件开发过程中的一些策略方面的问题。 第一章 软件过程 1.1软件开发的本质 1.2系统规划 1.3软件生命周期的阶段 1.4软件开发方法 1.1软件开发的本质 在涉及 IS（信息系统）管理的文献中有许多关于项目失败、超出期限和预算、解决方案错误、系统不可维护等例子。由Standish Group做的经常被引用的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种主要的投入者： 客户（用户或系统所有者）。 开发人员（分析员、设计员、程序员等）。 我们倾向于使用术语客户而不是用户。从系统开发的角度看，区别两者肯定是有充分依据的。第一，客户是给开发付钱的人，负责制定决策。第二，即使客户有错，客户的需求也不能由开发者任意改变或拒绝，任何矛盾的、不可行的或不合法的需求都必须与客户再次进行协商。 信息系统是社会系统，它们由人（开发者）为人（客户）开发，软件项目的成功由社会因素确定，技术是第二位的。有许多技术水平不高的系统在为客户工作并使客户获益，反之就不是这样，一个对客户没有任何觉察的或真实的益处的系统将被放弃，不管其技术上如何顶尖。 在通常情况下，软件失败的主要原因可以追溯到投入者的因素。在客户方面，项目失败是因为： 客户的需要被误解或没有被完全捕捉。 客户需求变化得过于频繁。 客户没有准备为项目提交足够的资源。 客户不想与开发人员合作。 客户具有不现实的期望。 系统不再对客户有利。 项目还会由于开发者不能胜任这项任务而失败。随着软件复杂度的增加，人们越发地认识到开发者的技能和知识非常关键。好的开发者能够给出一个好的解决方案，杰出的开发者可以给出更好的方案，因为它更快