需求分析与系统设计课件

需求工程需求分析与系统设计 需求工程需求分析与系统设计 1整体概述概述二点击此处输入相关文本内容概述一点击此处输入相关文本内容概述三点击此处输入相关文本内容整体概述概述二概述一概述三2关于本课程l课程的本质l听课的要求l作业的要求l与后继课程的关系l考试关于本课程课程的本质3第一章 软件过程 本章目标是从总体上描述软件开发过程中的若干策略问题，介绍支撑现代软件开发的过程和方法。l了解软件开发的本质、社会基础，以及业务系统的开发为何不能完全基于严格的工程和科学原则。l学习软件过程标准（CMM、ISO 9000、ITIL）及服从框架（COBIT）。l获得策略系统规划和方法（SWOT、VCM、BPR、ISA）的知识，以确保业务目标能够确定信息系统项目。l认识到信息系统之间具有很大的差异，这种差异取决于信息系统能够满足的管理水平及其所具有的竞争优势。l了解软件开发的结构化方法与面向对象方法的差异。l学习软件开发生命周期的各个阶段及跨越生命周期的活动。l了解现代及新兴的软件开发模型方法（螺旋模型、IBM Rational统一过程、模型驱动的体系结构、敏捷软件开发及面向方面的软件开发）。l了解7个实例研究，这些实例用于作为贯穿全书的例子和练习。第一章 软件过程 本章目标是从总体上描述软件4第一章 软件过程 1.1软件开发的本质 1.2系统规划 1.3三级管理系统 1.4软件开发生命周期 1.5开发模型与方法 1.6实例研究的问题陈述 第一章 软件过程 1.1软件开发的本质 51.1软件开发的本质 在关于信息系统（information system，IS）管理的文献中，充满了项目失败、逾期和超预算、有缺陷的解决方案，以及不可维护的系统等例子。虽然大量引用Standish Chaos报告（声称有70的软件项目失败）是有些夸张，但毋庸置疑的是，许多“成功的”系统（换句话说，就是已经付款并交付给用户的系统）被可靠性、性能、安全性、可维护性及其他问题所困扰。1.1软件开发的本质 在关于信息系统（6 为了了解这些问题的原因，我们首先需要了解软件开发的本质。在一篇有代表性的论文中，阐述了软件工程的本质问题和意外事件。软件工程的本质问题体现在软件本身所固有的困难中，我们只能承认这些困难没有获得突破性进展或“银弹”的方法。按照Brooks的说法，软件工程的本质问题是由软件固有的复杂性、一致性、可变性和不可见性所导致的。1.1软件开发的本质 为了了解这些问题的原因，我们首先需要7 软件的“本质困难”定义了软件开发的不变事实。不变事实声明软件是一种创造性开发行为的产品由工匠而不是优秀艺术家所完成的行为意义上的一种工艺品或艺术品。在典型的情况下，软件并不是制造业重复性行为的结果。1.1软件开发的本质 软件的“本质困难”定义了软件开发的不8 一旦理解了软件开发的不变事实，人们就应该能够处理软件工程的意外事件由于软件生产实践而带来的困难，可以由人为的干涉来解决。可以将各种“意外困难”分为3类：l利益相关者。l过程。l建模。1.1软件开发的本质 一旦理解了软件开发的不变事实，人们就91.1软件开发的本质 l1.1.l软件开发的不变事实 l1.1.2软件开发的“意外事件”l1.1.3开发还是集成 1.1软件开发的本质 1.1.l软件开发的不变事实 101.1.1软件开发的不变事实 一些重要的软件特性不易受到人为因素的影响，这些特性在所有的软件项目中都保持不变，并需要在项目中得到承认。软件开发的任务是确保不变事实不会失去控制，并且不要对项目施加任何过多的负面影响。1.1.1软件开发的不变事实 一些重要111.1.1软件开发的不变事实 软件本身就是复杂的。在现代软件系统中，复杂性不过是软件规模（如以代码行表示）的函数，以及组成软件产品的构件之间相互依存关系的函数。1.1.1软件开发的不变事实 软件本身就121.1.1软件开发的不变事实 软件的复杂性随着软件的应用领域的性质不同而不同。通常情况下，计算密集型应用领域的软件系统比数据密集型应用领域的软件系统的复杂性要低。数据密集型应用系统包括电子商务，它是本书的主题。这样的系统处理大量数据和业务规则，而这些数据和业务规则往往是不一致或不明确的。构建能够容纳所有业务数据、规则和特殊情况的软件一贯是困难的。1.1.1软件开发的不变事实 软件的复131.1.1软件开发的不变事实 Brooks认为，另外3个重要特性（一致性、可变性及不可见性）加重了这种困难。应用软件必须与其所基于的特定硬件软件平台相符合（一致），也必须与现有的信息系统相符合，并集成在一起。因为业务过程和需求是在不断变化的，所以在建立应用软件时必须能够容纳变化。尽管应用软件提供了可见的输出，但是负责输出的代码通常深深地隐藏在“不可见”的程序语句、二进制代码库，以及周边的系统软件中。1.1.1软件开发的不变事实 Broo141.1.1软件开发的不变事实 软件是开发出来的，而不是成批制造出来的（Pressman 2005）。当然，我们不能否认，虽然软件工程的发展为开发实践引入了更多的确定性，但是并不能保证软件项目的成功。这可以与传统的工程分支相对比，如土木工程或机械工程。在传统的工程中，产品（人工制品）是以数学般的精确来设计，然后利用机械和生产线来制造（通常为成批制造）的。1.1.1软件开发的不变事实 软件是开151.1.1软件开发的不变事实 一旦将软件产品开发出来，就能够以最小的代价复制（成批制造），但是对于企业信息系统这种情况，从来都不需要复制软件。每个系统都是独特的，并且是为特定企业开发的。困难在于开发，而并不在于成批制造。因此，整个软件生产的成本都在于它的开发。1.1.1软件开发的不变事实 一旦将软161.1.1软件开发的不变事实 为了降低软件开发的工作量和成本，软件产业以可复用软件构件的形式提供了部分解决方案，在开发过程中可以利用这些构件。我们所面临的挑战是，将该解决方案的一个个小的部分组装成一个连贯的企业系统，以满足复杂业务过程的需要。1.1.1软件开发的不变事实 为了降低软171.1.1软件开发的不变事实 软件实践鼓励从可定制的软件框架或软件包商用成品软件（commercial off-the-shelf，COTS）解决方案或企业资源规划（enterprise resource planning，ERP）系统来进行系统开发。然而，软件框架只能提供常规的财务、制造或人力资源系统。这些常规的解决方案必须要适应企业所期望和需要执行的特定业务过程。必须要对这些业务过程进行定义，然后开发系统模型。虽然所强调的重点由“从零开始的开发”转变到了“通过定制的软件框架进行开发”，但是在这两种情况下，软件开发的真正本质仍然是相同的。1.1.1软件开发的不变事实 软件实践鼓181.1.1软件开发的不变事实 必须为每个系统的最终解决方案创建概念性构想（模型），以确保这些构想能够满足组织的特定需要。一旦创建了这些概念性构想，就可以对软件框架的功能性进行定制，以符合概念性构想。编程任务可能有所不同，但是需求分析和系统设计活动与那些从头开发的软件类似。毕竟，一个概念性构想（模型）在许多可能的表示（实现）下是相同的。1.1.1软件开发的不变事实 必须为每个191.1.1软件开发的不变事实 同样重要的是，一个组织不可能找到一个软件框架来自动实现它的核心业务活动。电话公司的核心业务活动是电话技术，而不是人力资源或财务。因此，支持核心业务活动的软件很少有机会依赖软件构件或框架。此外，支持其他业务活动（如财务）的软件必须包含有针对性的或独特的解决方案，来为组织提供竞争优势。就如Szyperski所评述的：“标准软件包创建了一个公平的比赛场地，竞争只能来自其他领域。”1.1.1软件开发的不变事实 同样重要201.1.1软件开发的不变事实 在各种情形下，开发过程都应该利用构件技术。构件是软件的一个可执行单元，具有明确定义的功能服务）及与其他构件之间的通信协议 （接口）。可以对构件进行配置来满足应用需求。最具影响力和最直接的竟争构件技术标准是Sun的J2EEEJB和Microsoft的NET。面向服务的体系结构（Service-Oriented Architecture，SOA）的相关技术提倡由服务也就是运行的软件实例（而不是构件；必须在运行构件之前加载、安装、组合、部署和初始化）来构建系统。1.1.1软件开发的不变事实 在各种情形211.1.1软件开发的不变事实 软件包、构件、服务以及类似的技术并没有改变软件生产的本质问题，尤其是需求分析与系统设计的原则和任务保持不变。能够把标准的和客户定制的构件组装成最终的软件产品，而这个“组装”过程仍然是一门艺术。正如Pressman所说：我们甚至没有软件“备件”来代替正在运行的系统中破损的构件。1.1.1软件开发的不变事实 软件包、221.1.2软件开发的“意外事件”软件开发的不变事实定义了软件生产的本质问题，并引发了软件生产中的最大挑战。极 为重要的是，软件开发中的“意外事件”并不会增加软件产品的复杂性，也不会产生软件产 品的可支持性的潜在缺乏。可支持性（适应性）由3个系统特征组成的集合来定义，包括软件的可理解性、可维护性和可伸缩性（可扩展性）。1.1.2软件开发的“意外事件”软件231.1.2软件开发的“意外事件”软件开发的意外事件大部分可以归因于信息系统即社会系统这样的事实。它的成功或失败依赖于：人、他们对系统的接受或支持、用于开发的过程、管理措施、软件模型技术的利用等。1.1.2软件开发的“意外事件”软件开241.1.2软件开发的“意外事件”l1.1.2.1利益相关者 l1.1.2.2过程l1.1.2.3建模 1.1.2软件开发的“意外事件”1.1.2.1利益相关者 251.1.1.1利益相关者 利益相关者是在软件项目中存在利害关系的人。任何受到系统影响或对系统开发产生影响的人，都是利益相关者。有两组主要的利益相关者：l客户（用户或系统所有者）。l开发者（分析员、设计员、程序员等人1.1.1.1利益相关者 利益相关者是在261.1.1.1利益相关者 在一般的交流中，术语“用户”通常是指“客户”。我们不能否认这样的事实：术语“客户”能够更好地反映期望的含义。首先，客户是为开发付款并负责决策的人。其次，即使客户并不总是正确的，开发者也不能随意改变或拒绝客户的需求对于任何冲突的、不可行的或非法的需求，都必须与客户再次协商。1.1.1.1利益相关者 在一般的交流中271.1.1.1利益相关者 信息系统是社会系统，它们是由人（开发者）为人（客户）开发的。软件项目的成功由社会因素所决定技术则是次要的。技术低劣的系统在为客户工作并使客户获益，这样的例子有很多，反之则不然。对客户没有好处（被认为的或实际上的）的系统将会被抛弃，无论它具有多么辉煌的技术。1.1.1.1利益相关者 信息系统是社会281.1.1.1利益相关者 在典型的情况下，软件失败的主要原因可以追溯到利益相关者。在客户端，项目失败是因为：l客户的需求被误解了，或者没有被完全捕获。l客户的需求改变得过于频繁。l客户没有准备为项目提供足够的资源。l客户不想与开发者合作。l客户怀有不切实际的期望。l系统不再对客户有利。1.1.1.1利益相关者 在典型的情况下291.1.1.1利益相关者 项目也会因为开发者的不胜任而失败。随着软件复杂性的增加，人们越来越认识到，开发者的技能和知识是至关重要的。良好的开发者能够交付一个可接受的解决方案；卓越的开发者能够更快、更廉价地交付一个更优越的解决方案。如同Fred Brooks的名言：“伟大的设计来源于伟大的设计者。”1.1.1.1利益相关者 项目也会因为开301.1.1.1利益相关者 开发者的杰出和投入是最能够促进软件质量和生产力的因素。为了确保软件产品能够成功地交付给用户，而且更重要的是使用户从中获得生产效益，软件组织必须对开发者使用正确的管理措施，即：l雇佣最好的开发者。l为现有的开发者提供持续的培训和教育。l鼓励开发者之间进行信息交流和互动，使他们互相促进。l通过排除阻力以及将他们的精力引导到生产性工作中，来激励开发人员。l提供一个令人振奋的工作环境（这往往比偶尔加薪更重要）。l将个人目标同组织策略和目标统一起来。l强调团队工作。1.1.1.1利益相关者 开发者的杰出和311.1.1.2过程 软件过程定义在软件生产和维护中所使用的活动和组织程序。过程的目标是在开发中管理和改进协作并维持团队，使团队能够向客户交付符合质量要求的产品，并在以后对产品提供适当的支持。1.1.1.2过程 软件过程定义在软321.1.1.2过程 一个过程模型：l声明了所执行活动的次序。l详细说明要交付哪些开发的人工制品，以及什么时候交付。l将活动和人工制品分配给开发者。l提供用来监控项目进展、评估结果和规划未来项目的标准。1.1.1.2过程 一个过程模型：331.1.1.2过程 不同于建模和编程语言，软件过程不易被标准化。每个组织必须开发属于它自己的过程模型，或者对通用的过程模板进行定制，例如著名的Rational统一过程”（Rational Unified Process，RUP）模板。软件过程是组织的整体业务过程的一个重要组成部分，它决定了组织在市场中的独特性和竞争能力。1.1.1.2过程 不同于建模和编程语341.1.1.2过程 组织所采用的过程必须符合其开发文化、社会动态、开发者的知识和技能、管理方法、客户的期望、项目规模，甚至是应用领域的种类。由于所有这些因素都是可变的，组织可能需要将它的过程模型多样化，并且为每个软件项目创建变体。例如，依据开发者对建模方法和工具的熟悉程度，可能需要在过程中加入专题培训课程。1.1.1.2过程 组织所采用的过程必须351.1.1.2过程 项目规模有可能对过程产生最大的影响。在小项目中（10个人左右的开发者），也许根本不需要正式的过程。这样的小团队可能会不拘形式地进行沟通，并且对变化做出响应。然而在大项目中，一个非正式的通信网络是不够的，因此为了控制开发而明确定义的过程是必要的。1.1.1.2过程 项目规模有可能对过361.1.1.2过程 l1.1.2.2.l 迭代和增量过程 l1.1.2.2.2 能力成熟度模型 l1.1.2.2.3 ISO 9000系列质量标准l1.1.2.2.4 ITIL框架l1.1.2.2.5 COBIT框架1.1.1.2过程 1.1.2.2.l 迭代和增量过程 371.1.2.2.l 迭代和增量过程 现代软件开发过程总是迭代和增量的。系统模型通过分析、设计和实现阶段而逐步完善和改造。在连续的迭代中增加细节，必要时还引入了变更和改进，而软件模块的增量版本则保持了用户的满意度，并且为尚在开发中的模块提供重要的反馈。1.1.2.2.l 迭代和增量过程 现381.1.2.2.l 迭代和增量过程 可执行代码的构造是以程序块的形式交付给客户，每次的下一个构造都是在之前构造上的增量。作为由系统必须满足的一套功能性的用户需求所决定的增量，并不会扩大项目的范围。迭代是短期的在数周中而非数月。用户反馈是频繁的，规划是持续的，变更管理是生命周期中至关重要的一个方面，度量标准和风险分析的定期收集设定了连续迭代的议程。1.1.2.2.l 迭代和增量过程 可执391.1.2.2.l 迭代和增量过程 这个迭代和增量过程有各种各样的变体，具有特殊意义的变体包括：l螺旋模型。lRational统一过程（the Rational Unified Process，RUP）。l模型驱动的体系结构（ModelDriven Architecture，MDA）。l敏捷开发过程。l面向方面的软件开发。1.1.2.2.l 迭代和增量过程 这个迭代和增量过程401.1.2.2.l 迭代和增量过程 由Boehm定义的螺旋模型，作为较新模型的参考点，包含了上面列出的3个模型。RUP是一个相对灵活的过程，它提供了一个支持环境（称作RUP平台），用各种各样的文本模板、概念解释、开发思路等来指导开发者。MDA基于可执行规格说明的观点由模型和构件生成软件。敏捷开发提出了一个框架，在这个框架中，人与团队的协作被认为比规划、文档及其他形式更加重要。面向方面的开发引入了有关横切关注点（方面）的正交思想，并主张为这些关注点生产单独的软件模块。每个方面（如软件的安全性、性能或并发性）被视为一个独立的开发问题，但是也必须谨慎地与系统其余的部分集成（编织）在一起。1.1.2.2.l 迭代和增量过程 由B411.1.2.2.l 迭代和增量过程 迭代和增量过程的成功是以对系统体系结构模块的早期识别为基础的。这些模块应当有相似的规模、高度的内聚和极小的重叠（耦合）。实现模块的次序也很重要。如果模块依赖于其他尚在开发的模块中的信息或计算，那么它们可能无法发布。除非对迭代和增量开发进行规划和控制，否则过程会沦为不能控制项目实际进度的“特别黑客”。1.1.2.2.l 迭代和增量过程 迭代421.1.2.2.2 能力成熟度模型 对每个组织来说，从事软件生产的一个主要挑战是改进其开发过程。当然，要引入过程改进，组织就必须了解在当前的过程中所存在的问题。能力成熟度模型（capability maturity model，CMM）是一种用来进行过程评估和改进的流行方法。1.1.2.2.2 能力成熟度模型 对431.1.2.2.2 能力成熟度模型 CMM已经由位于美国匹兹堡的卡内基一梅隆大学的软件工程学院（SEI）详细说明。它原先被美国国防部用于评估组织的IT能力，以竞标国防合同。目前在美国及其他地方广泛应用于IT行业。1.1.2.2.2 能力成熟度模型 CM441.1.2.2.2 能力成熟度模型 从本质上说，CMM是一个由IT组织填写的问卷调查表。问卷随后进行核查和认证，并将组织分配到5个CMM级别中的一个。级别越高，组织的软件过程越成熟。图1-1定义了这些级别，给出了每个级别主要特征的简短描述，并且指明了组织为了达到更高级别，而需要进行过程改进的主要领域。1.1.2.2.2 能力成熟度模型 从本451.1.2.2.2 能力成熟度模型1.1.2.2.2 能力成熟度模型461.1.2.2.2 能力成熟度模型 Arthur将成熟度级别称为“通向软件卓越的楼梯”。楼梯上的5个台阶是：混乱、项目管理、方法和工具、度量以及持续的质量改进。经验表明，要上升一个成熟度级别需要数年的时间。大部分组织位于第1级，一些组织位于第2级；而位于第5级的组织寥寥无几。1.1.2.2.2 能力成熟度模型 Ar471.1.2.2.2 能力成熟度模型 下面的几个问题显示了任务的艰巨。一个组织想要达到CMM的第2级，就必须对这些问题（以及更多问题）做出肯定的答复：l软件质量保证功能是否有独立于软件开发项目管理的管理报告渠道？l是否为涉及软件开发的每个项目都提供了软件配置的控制功能？l在制定合同承诺前，是否有正式过程，用于每个软件开发的管理审查？l是否有制定软件开发进度表的正式程序？l是否有估算软件开发成本的正式程序？l是否对软件代码和收集的测试错误进行统计？l高层管理是否有对软件开发项目状况进行定期审查的机制？l是否有控制软件需求变更的机制？1.1.2.2.2 能力成熟度模型 下面的几个问题显481.1.2.2.3 ISO 9000系列质量标准 除了CMM，还有其他过程改进模型，特别受关注的是由国际标准化组织开发的ISO 9000质量标准系列。ISO标准应用于质量管理和过程，以生产优质产品。这些标准是通用的它们应用于任何行业和所有业务类型，包括软件开发。1.1.2.2.3 ISO 9000系列质量标准 491.1.2.2.3 ISO 9000系列质量标准 ISO 9000标准系列的主要前提是：如果过程是正确的，那么过程的结果（产品或服务）也将是正确的。“质量管理的目标是通过在产品中建立质量而不是测试质量来生产优质的产品”。1.1.2.2.3 ISO 9000系列质量标准 501.1.2.2.3 ISO 9000系列质量标准 按照我们前面关于过程的讨论，ISO标准并不强制执行或具体指定过程。标准提供了必须完成什么的模型，而不是必须怎样执行活动的模型。一个组织请求ISO认证（也称为注册），就必须说明它是做什么的，做它所说明的事情，并且证明它已经做了。1.1.2.2.3 ISO 9000系列质量标准 511.1.2.2.3 ISO 9000系列质量标准 对于由ISO认证的组织来说，一个试金石是即使它的全部劳动力被替换掉了，它也应该能够生产优质产品或提供优质服务。为了这个目标，组织必须文档化并记录它的所有正式活动，必须为每个活动定义书面程序，包括当出现错误时或客户抱怨时需要做什么。1.1.2.2.3 ISO 9000系列质量标准 521.1.2.2.3 ISO 9000系列质量标准 同CMM一样，只有ISO注册员进行现场审核后，才能批准ISO认证。之后，每隔一段时间将定期重复这些审核。客户要求产品和服务的供应商通过认证，通过这种明确规定的竞争实力，组织被推动到这种认证体系之中。许多国家已经采用了ISO 9000作为他们的国家标准，这在欧洲尤为普遍。1.1.2.2.3 ISO 9000系列质量标准 531.1.2.2.4 ITIL框架 从业务的视角来看，软件（或信息技术通常说IT）是一种正在快速成为商品的基础架构服务。IT对早期采纳者来说，仍然是竞争优势的主导来源，但是这种优势的时间跨度比以往缩短了很多。原因有很多，包括开源软件的存在、商业软件的免费教育许可、迭代和增量软件开发的周期缩短等。1.1.2.2.4 ITIL框架 从业务541.1.2.2.4 ITIL框架 越来越多的软件仅仅是对业务解决方案的服务支持。我们所讨论的是解决方案（服务）的交付，而不仅仅是软件或系统的交付，业务和软件之间相互影响的强度正是我们所需要的。需要对已交付的解决方案进一步管理。解决方案管理是指IT解决方案供应管理的所有方面，这个事实在IT基础架构库（IT Infrastructure Library，ITIL）被最广泛使用和接受的、用于IT服务管理的最佳实践的框架中得到了公认。1.1.2.2.4 ITIL框架 越来551.1.2.2.4 ITIL框架 “对IT管理者的挑战，是在业务合作伙伴中协调和工作，来提供高质量的IT服务。这个目标必须要达到，同时降低整体总拥有成本（total cost of ownership，TCO），并且经常增加频率、复杂性和变化量IT管理就是高效率地和有效地全面利用4P：人（People）、过程（Process）、产品（Product）（工具和技术）及合作伙伴（Partner）（供应商、销售商和外包机构）。”1.1.2.2.4 ITIL框架 “对I561.1.2.2.4 ITIL框架 图1-2介绍了作为一项持续的服务改进方案（continuous service improvement programme，CSIP）、用来实现解决方案管理的ITIL方法。CSIP方案以实现高水平业务目标的决心为起点，接着检查是否已经达到了里程碑（可交付），并通过巩固已达到的改进和持续任务循环而保持发展势头。1.1.2.2.4 ITIL框架 图1-571.1.2.2.4 ITIL框架1.1.2.2.4 ITIL框架581.1.2.2.4 ITIL框架 在策略规划和业务模型的使用中确定高水平的业务目标，在当前组织状况的背景下分析目标，以此来评估需要填补的差距。这样的IT组织成熟度的评估应包括：内部审查、外部基准和针对行业标准（如ITIL、CMM或ISO 9000）的过程审查。1.1.2.2.4 ITIL框架 在策略591.1.2.2.4 ITIL框架 一旦完成了差距评估报告，就需要为CSIP制定业务实例。业务实例应当识别“速赢”（如果有的话），但是首先应当确定支持业务目标的具体短期目标，作为可度量目标。配备了这些初步信息后，一个过程改进规划就产生了。该规划确定了应遵循的范围、方法和过程，以及CSIP项目的职权范围。1.1.2.2.4 ITIL框架 一旦完601.1.2.2.4 ITIL框架 CSIP的进展和性能评估依据一套可度量的里程碑、可交付性、关键性的成功因素（critical success factor，CSF），以及关键绩效指标（key Performance indicator，KPI）。虽然包括直接关系到商业利益的测量和度量是重要的，但是我们必须记得，优质业务的改进取决于软件质量因素。1.1.2.2.4 ITIL框架 CSI611.1.2.2.5 COBIT框架 ITIL致力于处理方案交付和管理的操作方面。COBIT（Control Objectives for Information and related Technology，控制目标信息和相关技术）是一个服从框架，并致力于处理解决方案管理的控制方面（COBIT 2000）。1.1.2.2.5 COBIT框架 IT621.1.2.2.5 COBIT框架 ITIL，CMM和ISO 9000是过程标准，这些标准规定了组织在管理过程方面的要求，以提供优质的产品或服务。相比之下，COBIT则是一个产品标准，它侧重于一个组织需要做什么，而不是需要如何去做。1.1.2.2.5 COBIT框架 ITI631.1.2.2.5 COBIT框架 COBIT的目标对象并不是软件开发者，而是高级IT经理、高级业务经理和审计师。“由于它的级别高，覆盖面广，并且因为它基于许多现有的实践，常将COBIT称为集成器，将分散的实践组织到一起，而同样重要的是，它帮助将这些各种各样的IT实践连接到业务需求中去。”1.1.2.2.5 COBIT框架 CO641.1.2.2.5 COBIT框架 COBIT框架是相当具有规定性的。它将相关的IT工作组织到4个领域：l规划与组织。l获取与实现。l交付与支持。l监控。1.1.2.2.5 COBIT框架 COBIT框架是相651.1.2.2.5 COBIT框架 将控制目标分配到这些领域。有34个高级别的控制目标。同这些目标关联在一起的是一个审计指标，它依据COBIT推荐的318个详细控制目标来评估IT过程。这些目标是为保证管理和改进建议而服务的。1.1.2.2.5 COBIT框架 将控661.1.2.2.5 COBIT框架 第1个领域规划与组织是系统规划活动（13节）。它把IT看作是组织策略和战术规划的一部分，关系到确定IT如何能够以最佳方式对业务愿景和目标的实现做出贡献，也着眼于实现IT功能的短期规划。它评估现有系统，进行可行性研究，分附资源，建立信息体系结构模型，着眼于技术方向、系统体系结构、迁移策略、IT功能的组织布置、数据和系统的所有权、人事管理、IT业务预算、成本和效益调整、风险评估、质量管理等。1.1.2.2.5 COBIT框架 第1671.1.2.2.5 COBIT框架 第2个领域获取与实现关系到IT策略的实现。它指出了满足业务目标和客户需求的自动化解决方案，确定IT解决方案必须通过开发实现，还是可以通过获取得到。并提出软件开发过程或获取过程。此领域不仅关注应用软件，也关注技术基础架构，描述了开发、测试、安装和维护规程、服务要求和培训资料，并提出了变更管理措施。1.1.2.2.5 COBIT框架 第2681.1.2.2.5 COBIT框架 第3个领域交付与支持包含IT服务的交付、由应用系统进行的数据的实际处理（称为应用控制），以及必要的IT支持过程。它定义服务级别协议，管理第三方服务，处理性能和工作量，承担持续服务的职责，确保系统安全，连接成本统计系统，教育和培训用户，帮助和建议客户，管理系统配置，处理问题和事件，管理数据、设备和操作。1.1.2.2.5 COBIT框架 第3个691.1.2.2.5 COBIT框架 第4个领域监控随着时间的推移，对IT过程的质量及是否符合控制需求进行评估。此领域监控过程，评估性能指标和客户满意度，考虑内部控制机制的充分性，获得关于安全性、服务效果、遵守法律和职业道德的独立保证等。1.1.2.2.5 COBIT框架 第4701.1.2.3建模 利益相关者和过程是成功三要素中的两个，第3个要素是软件建模即软件开发活动，这些活动被看作是软件人工制品的建模。模型是来自现实的抽象，是现实的抽象表示。被实现和运行的系统也是现实的模型。1.1.2.3建模 利益相关者和过程是711.1.2.3建模 对人工制品建模必须进行沟通（使用语言）和文档化（使用工具）。开发者需要一种语言来创建可视化模型和其他模型，并与客户和同事进行讨论。语言应允许在不同抽象层面上构建模型，在不同的细节层面上来表现所提出的解决方案。按照“一张图片胜过千言万语”的流行说法，语言应当具有强大的可视化构件，还应当具有强大的说明性语义也就是说，它应当允许在“说明性的”语句中捕获“程序上的”含义。我们应该能够通过说明需要做“什么”，而不是需要“如何”去做，来进行沟通。1.1.2.3建模 对人工制品建模必须721.1.2.3建模 开发者还需要工具，或者更合适的说法是，为软件开发过程提供的先进的、基于计算机的环境。这样的工具和环境称为计算机辅助软件工程（ComputerAssisted Software Engineering，CASE）。CASE使得在中央存储库中实现模型的存储和检索成为可能，并在计算机屏幕上进行模型的图形和文字操作。在理想的情况下，存储库应当能够为共享的多个用户（多个开发者）提供对模型的访问。1.1.2.3建模 开发者还需要工具，731.1.2.3建模 CASE存储库的典型功能有：l协调对模型的访问。l促进开发者之间的合作。l存储模型的多个版本。l识别版本间的区别。l允许在不同的模型中共享相同的概念。l检查模型的一致性和完整性。l生成项目报告和文档。l生成数据结构和程序代码（正向工程）。l从已有的实现中生成模型（逆向工程）。1.1.2.3建模 CASE存储库的典型功能有：741.1.2.3建模 要注意的是，CASE所生成的程序只是一个代码骨架算法还需要由编程人员以通常的方式进行编码。1.1.2.3建模 要注意的是，CAS751.1.2.3建模 l1.1.2.3.1 统一建模语言 l1.1.2.3.2 CASE和过程改进 1.1.2.3建模 1.1.2.3.1 统一建模语言 761.1.2.3.1 统一建模语言 “统一建模语言（Unified Modeling Language，UML）是一种通用的、可视化的建模语言，用于对软件系统的人工制品进行详细说明、可视化、构造和文档化。它捕获对必须构建的系统的决策和理解，用于理解、设计、浏览、配置、维护和控制该系统的相关信息。它准备为所有的开发方法、生命周期阶段、应用领域和媒体所使用。”1.1.2.3.1 统一建模语言 “统一建771.1.2.3.1 统一建模语言 现在已是IBM一部分的Rational软件公司开发了UML，它统一了早期方法和表示法中最佳的特征。1997年，对象管理组织（Object Management Group，OMG）批准UML作为一种标准的建模语言。从那时起，UML就被IT产业所接受和广泛接纳并进一步开发。UML 20版本在2005年被OMG采纳。1.1.2.3.1 统一建模语言 现在已781.1.2.3.1 统一建模语言 尽管Rational提出了匹配过程，称为Rational统一过程（Rational Unified Process，RUP），但UML独立于任何软件开发过程。采用UML的过程必须支持一种面向对象的方法来进行软件生产。UML并不适合老式的结构化方法，该方法导致系统由过程式编程语言来实现，例如COBOL。1.1.2.3.1 统一建模语言 尽管R791.1.2.3.1 统一建模语言 UML也独立于实现技术（只要它们是面向对象的），这使得UML在支持开发生命周期的详细设计阶段方面有点不足。然而，同样的道理，它确实使UML对实现平台中的特异性和频繁变化富有弹性。1.1.2.3.1 统一建模语言 UM801.1.2.3.1 统一建模语言 UML语言结构允许为系统的静态结构和动态行为建模。系统被建模为一套合作的对象（软件模块），这些对象响应外部事件来执行为客户（用户）带来利益的任务。特定的模型强调系统的某些方面，而忽略了在其他模型中被强调的那些方面。集成在一起的一套模型提供了对系统的完整描述。1.1.2.3.1 统一建模语言 UML811.1.2.3.1 统一建模语言 UML模型可分为3组：l状态模型描述静态数据结构。l行为模型描述对象协作。l状态变化模型描述随着时间的推移，系统所允许的状态。1.1.2.3.1 统一建模语言 UML模型可分为3组：821.1.2.3.1 统一建模语言 UML也包含少量的体系结构构造，为了迭代和增量开发而对系统进行模块化。然而，UML并不主张任何特定的、系统能够或应当遵守的体系结构框架，这样的框架会定义系统构件的分层结构，并详细说明它们需要如何进行通信，因此，会与UML作为通用语言的目标相矛盾。1.1.2.3.1 统一建模语言 UML831.1.2.3.2 CASE和过程改进 过程改进远不只是引入新的方法和技术。事实上，在一个过程成熟度的低级别中，为组织引进新的方法和技术，更多的情况是弊大于利。1.1.2.3.2 CASE和过程改进 841.1.2.3.2 CASE和过程改进 当CASE技术作为集成环境应用时，就是一个很好的例子，这个集成环境为了生产出新的设计产品而允许多个开发者合作，并共享设计信息。这样的CASE环境强行施加了某些过程，那么开发团队就必须服从利用该技术。然而，如果开发团队在以前没能改进其过程，那么它极不可能吸收由CASE工具所规定的过程。结果，由新技术所提供的潜在的生产力和质量增益将无法实现。1.1.2.3.2 CASE和过程改进 851.1.2.3.2 CASE和过程改进 这项评论并非是说CASE技术是具有风险的业务，它只是用于驱动整个开发过程，并且在开发团队没有准备好接受该过程时，才是有风险的。然而，对于那些在自己的本地工作站上工作的个体开发者来说，在工具内部使用同样的CASE方法和技术总会带来个体生产率和质量的改进。在课堂上使用铅笔和纸对软件人工制品建模可能是有意义的，但是对于真正的项目来说，从来都没有意义。1.1.2.3.2 CASE和过程改进 861.1.3开发还是集成 今天，只是使手工过程自动化来开发新的软件系统几乎是不存在的。大部分开发项目取代或扩展了现存的软件解决方案，或将它们集成为更大的、提供新的自动化水平的解决方案。因此，集成开发（相对于“从零开始”的应用开发的立场）所进行的是使用相同迭代生命周期方法和生产相同软件产品模型，差别就在于所强调的集成层次和使能技术。1.1.3开发还是集成 今天，只是使手工871.1.3开发还是集成 我们将集成方法分为3大类型：l面向信息和或面向门户的集成。l面向接口的集成。l面向过程的集成。1.1.3开发还是集成 我们将集成方法分为3大类型：881.1.3开发还是集成 面向信息的集成依赖于源应用系统和目标应用系统之间的信息交换。这是在数据库或应用程序接口（application programming interface，API）层次上的集成，这种集成使信息具体化，以供其他应用程序使用。1.1.3开发还是集成 面向信息的集成依891.1.3开发还是集成 面向门户的集成可以看作是一种特殊的面向信息的集成，将来自多个软件系统的信息具体化到一个共同的用户界面，具有代表性的是Web浏览器的门户。区别是面向信息的集成关注信息的实时交换，而门户则需要对来自后台系统的具体化的信息进行人为干预。1.1.3开发还是集成 面向门户的集成可901.1.3开发还是集成 面向接口的集成将应用接口（即通过接口抽象定义的服务）连接在一起。接口显示了一个应用系统向其他应用系统所提供的有益服务。面向接口的集成并不需要所参与的应用系统的详细业务过程可见。服务的供给可以是信息的（当提供数据时），或者是事务的（当提供一项功能时）。前者的确是一种基于信息集成的变种，而后者则需要修改源应用系统和目标应用系统，或者有可能导致一个新的应用系统（合成的应用系统）。1.1.3开发还是集成 面向接口的集成911.1.3开发还是集成 面向过程的集成是将应用系统连接在一起，方法是在现有应用系统的已有过程集和数据集的顶部定义一个新的过程层。可以论证，这是一个最终的集成方案，使新的过程逻辑从参与应用系统的应用逻辑中分离出来，并可能产生一种新的解决方案，将以前手工执行的任务自动化。面向过程的集成开始于建立新的过程模型，并假设被集成的应用系统的内部过程完全可见。面向过程的集成具有战略高度，旨在提升现有的业务过程，并带来竞争优势。1.1.3开发还是集成 面向过程的集成921.2系统规划 必须对信息系统项目进行规划，必须为初期的开发、改进或者排除而进行识别、分类、排序和选择。问题是，哪种IS技术和应用系统对业务的回报价值最大？在理想的情况下，所做的决定应当以定义良好的业务策略和仔细且有条不紊的规划为基础。1.2系统规划 必须对信息系统项目进行931.2系统规划 可以通过各种策略规划、业务建模、业务过程重组、策略调整、信息资源管理或诸如此类的过程来决定业务策略。所有这些方法承担了研究组织中基本业务过程的任务，目的是为业务确定长远的洞察力，然后优先考虑能够通过使用信息技术而得以解决的业务问题。1.2系统规划 可以通过各种策略规划、941.2系统规划 这就是说，有许多组织特别是许多小型组织并没有明确的业务策略。这样的组织有可能会通过简单地识别当前最迫切需要处理的业务问题来决定信息系统开发。当外部环境或内部业务情况发生变化时，将不得不对现有的信息系统进行修改，甚至替换。这样的运作模式允许小型组织快速地重新对当前情况集中精力，利用新的机会和抵制新的威胁。1.2系统规划 这就是说，有许多组织951.2系统规划 大型组织经受不起业务方向的不断改变。事实上，它们往往因在同一业务线上的其他组织而决定方向。在某种程度上，它们能够为当前的需要塑造环境。然而，大型组织也必须仔细地考虑到未来，它们必须使用基于规划的方法来识别开发项目。在典型的情况下，大型项目需要长时间来完成。它们太过麻烦，以至于不易被改变或替换。它们需要容纳，甚至是瞄准未来的机会和威胁。1.2系统规划 大型组织经受不起业务方961.2系统规划 系统规划可以通过多种方式来制定。一种传统的方法称为SWOT优势、劣势、机会、威胁（strength，weakness，opportunity，threat）。另一种流行的策略基于VCM价值链模型（value chain model）。用于制定业务策略的更加现代的方法称为BPR业务过程重组（business process re-engineering）。也可以通过使用为ISA信息系统体系结构（information system architecture）而设计的蓝图来评估一个组织的信息需求，这样的蓝图可以通过对描述性框架进行类比而获得，这在IT以外的学科中已经得到证明，例如建筑业。1.2系统规划 系统规划可以通过多种方971.2系统规划 所有的系统规划方法都有一个重要的共同点：它们关心效果（做正确的事）而不是效率（做事正确）。“更有效率”意味着可以使用现有的或更少的资源，以更快的速度完成相同的工作。“更有效果”意味着使用可选择的资源和想法来做一个更好的工作，也可以意味着通过创新来实现竞争优势。1.2系统规划 所有的系统规划方法都有981.2系统规划 l1.2.1 SWOT方法 l1.2.2 VCM方法 l1.2.3 BPR方法l1.2.4 ISA方法1.2系统规划 1.2.1 SWOT方法 991.2.1 SWOT方法 SWOT（优势、劣势、机会、威胁）方法以调整组织的优势、劣势、机会和威胁的方式来进行IS开发项目的识别、分类、排序和选择。这是一个从确定组织使命开始的、自顶向下的方法。1.2.1 SWOT方法 SWOT（优势1001.2.1 SWOT方法 使命陈述捕获了一个组织的独特性质，并详细说明它未来的愿景。在一个良好的使命陈述中，重点在于客户的需要，而不在于组织所交付的产品或服务。1.2.1 SWOT方法 使命陈述捕获了1011.2.1 SWOT方法 使命陈述和根据它开发的业务策略考虑了公司在管理、生产、人力资源、财务、市场和研发等领域中的内部优势和劣势。这些优势和劣势必须被认可、同意并优先考虑。一个成功的组织对它当前的优势和劣势要有良好的理解，以指导其业务策略的发展。1.2.1 SWOT方法 使命陈述和根1021.2.1 SWOT方法 优势的例子包括：l品牌和专利的拥有。l在客户和供应商中良好的口碑。l资源或技术的专有权。l由于生产量、私有的专门技能、专有权利或伙伴关系而带来的成本优势。1.2.1 SWOT方法 优势的例子包括：1031.2.1 SWOT方法 劣势通常是潜在优势的缺乏。劣势的例子包括：l不可靠的现金流。l员工的劣等技术基础和对一些关键员工的依赖。l欠佳的营业地点。1.2.1 SWOT方法 劣势通常是潜在优势的缺乏。劣势1041.2.1 SWOT方法 对内部的企业优势和劣势的识别是成功业务规划的一个必要条件，而不是充分条件。组织在真空中无法运作它依赖于外部的经济、社会、政治和技术因素。组织必须了解可利用的外部机会和可避免的外部威胁，这些是组织无法控制的因素，但对它们的认识是决定组织目的和目标的基础。1.2.1 SWOT方法 对内部的企业优1051.2.1 SWOT方法 机会的例子包括：l新的、更少限制的规章，撤除贸易壁垒。l策略联盟、合资或合并。l作为新市场的互联网。l竞争对手的溃败，以及因此而导致的市场开放。1.2.1 SWOT方法 机会的例子包括：1061.2.1 SWOT方法 任何对环境带有负面影响的改变都是威胁。威胁的例子包括：l与竞争对手的价格战的潜在性。l技术的变更超越了能够消化吸收的能力范围。l产品或服务上新的税收障碍。1.2.1 SWOT方法 任何对环境带有负面影响的改变1071.2.1 SWOT方法 组织在任何指定的时间都追求一个或几个极少量的长远目标。目标通常是长期的（3-5年），甚至是“永恒的”。典型目标的例子是：改进客户满意度、引进新的服务、解决竞争威胁，或增加对供应商的控制。每个策略目标必须与具体的目标联系在一起，该目标通常表现为年度目标。例如，“改进用户满意度”的目标可以由更快地（譬如说在两周内）履行客户订单的目标而得到支持。1.2.1 SWOT方法 组织在任何指定1081.2.1 SWOT方法 目的和目标需要管理策略和实现这些策略的具体政策。这种管理手段会调整组织结构、分配资源，并确定发展项目，包括信息系统。图l-3显示了与SWOT分析有关的概念及其关联和派生规则。SWOT矩阵定义了一个组织在市场中的位置，并且将组织的能力与其运行所处的竞争环境相匹配。1.2.1 SWOT方法 目的和目标需要1091.2.1 SWOT方法1.2.1 SWOT方法1101.2.2 VCM方法 VCM（价值链模型）通过分析组织中完整的活动链（从原材料到销售及运送给客户的最终产品）来评估竞争优势。在价值链方法中，产品或服务是将价值转交给客尸的媒介。用“链”来比喻生动地说明了：其中一个链接弱，将导致整个链的崩溃。模型的目的是理解哪种价值链配置将产生最大竞争优势。IS开发项目可以针对哪些环节、操作、分配渠道、销售方式等给出最具竞争力的优势。1.2.2 VCM方法 VCM（价值链模1111.2.2 VCM方法 在最初的VCM方法中，组织的职能分为基本活动和支持活动。基本活动对最终产品创造或增加了价值，它们分为5个连续的阶段：l1）内部物流接受对产品或服务的投入。l2）操作使用投入来创造产品或服务。l3）外部物流将产品或服务分销给买家。l4）销售和市场引导买家购买产品或服务。l5）服务维护或提高产品或服务的价值。1.2.2 VCM方法 在最初的VCM方法中，组织的职能1121.2.2 VCM方法 这5个阶段利用相关的信息技术，并且得到有关的各类信息系统的协助，例如：l1）为内部物流服务的仓储系统。l2）为操作服务的计算机制造系统。l3）为外部物流服务的运送和调度系统。l4）为销售和市场服务的订购和发票系统。l5）为服务而服务的设备维护系统。1.2.2 VCM方法 这5个阶段利用相关的信息技术，1131.2.2 VCM方法 支持活动并不增加价值，至少不直接增加价值。它们仍然是基础的，却不丰富产品。支持活动包括：行政管理和基础架构、人力资源管理、研发，以及大家很熟悉的IS开发。1.2.2 VCM方法 支持活动并不增加1141.2.2 VCM方法 VCM是对策略规划和确定IS开发项目有利的工具，反之亦然。无所不在的计算机化促进了业务改变，并且依次创造了效率、成本的降低和竞争优势。换句话说，IT能够转换一个组织的价值链，在IT和VCM之间可以建立自我加强的循环。1.2.2 VCM方法 VCM是对策略规1151.2.2 VCM方法 Porter和Millar指出了一个组织可以利用IT机会的5个步骤：ll）评估产品和过程的信息强度。l2）评估IT在产业结构中的角色。l3）识别那些能够使IT创造竞争优势的方式，并对其排序。l4）考虑IT如何能够创建新业务。l5）制定一份利用IT的规划。1.2.2 VCM方法 Porter和Millar指出了1161.2.3 BPR方法 要使用系统规划的BPR（业务过程重组）方法一般基于这样一个前提：当今的组织必须彻底地改造自己，并丢弃那些现在正在使用的功能分解、分层结构和操作原则。这个概念由Hammer、Davenport和Short引入，它立即引起了人们的兴趣和争议。1.2.3 BPR方法 要使用系统规划的1171.2.3 BPR方法 大多数现代组织被编入关注功能、产品或区域的纵向单元。这些结构和工作风格可以追溯到18世纪和Adam Smith的劳动力分工原则，以及随之而产生的工作分裂。业务过程被定义为“采取一种或多种输入、并创造对客户有价值的输出的活动集合”，没有任何一个雇员或部门会对这样的业务过程负责。1.2.3 BPR方法 大多数现代组织1181.2.3 BPR方法 BPR挑战了Smith的劳动力分工的产业原则、分层控制和规模经济。在当今世界，组织必须能够迅速地适应市场变化、新技术、竞争因素和客户的要求等。1.2.3 BPR方法 BPR挑战了Sm1191.2.3 BPR方法 业务过程必须跨越许多部门僵化的组织结构的观点已经过时。组织必须关注业务过程，而不是个别的任务、工作、人员或部门功能。这些过程横向跨越了业务，并且在与客户的交互点上结束。“过程企业和传统组织之间最明显的区别是过程所有者的存在”。1.2.3 BPR方法 业务过程必须跨1201.2.3 BPR方法 BPR的主要目的是在组织中从根本上重新设计业务过程（因此，有时将BPR称为过程再设计）。必须对业务过程进行识别、流程化和改进。在工作流图中对过程文档化，并经历了工作流分析。工作流捕获了业务过程中的事件、文档和信息流，并且可以用来计算这些活动所花费的时间、资源和成本。1.2.3 BPR方法 BPR的主要目的1211.2.3 BPR方法 Davenport和Short给BPR推荐了一种方法，此方法具有5个步骤：ll）确定业务愿景与过程目标（业务愿景来自使命陈述；目标专注于成本和时间的减少、质量改进、员工激励和知识获取等）。l2）确定要再造的过程。l3）了解并度量现有过程（为了避免过去的错误，并为过程再设计及过程改进建立基线）。l4）识别信息技术（IT）杠杆，以及它们如何能够影响过程再设计和改进。l5）为新过程设计并建造原型（原型是一个工作流系统，是迭代和增量开发的主题）。1.2.3 BPR方法 Davenport和Short1221.2.3 BPR方法 在组织中实现BPR的主要障碍在于需要向传统的纵向管理结构中嵌入一个横向过程。一个严肃的BPR首先需要改变组织，目的是使作为基础组织单元的开发团队成为中心，这些团队负责一个