需求分析与系统设计.ppt

《需求分析与系统设计.ppt》由会员分享，可在线阅读，更多相关《需求分析与系统设计.ppt（138页珍藏版）》请在装配图网上搜索。

1、需求分析与系统设计,第一章 软件过程,本章的意图是在一个综述性的层次上来描述软件开发过程中的一些策略方面的问题。,第一章 软件过程,1.1软件开发的本质 1.2系统规划 1.3软件生命周期的阶段 1.4软件开发方法,1.1软件开发的本质,在涉及 IS（信息系统）管理的文献中有许多关于项目失败、超出期限和预算、解决方案错误、系统不可维护等例子。由Standish Group做的经常被引用的CHAOS研究报告1998年版声称，几乎有四分之三的软件项目由于上述原因中的一种或多种而失败。首先要了解的是：什么使得软件项目失败？项目出现问题的症结所在以及处理的方法是什么？,为了解决这些问题，我们必须首先理

2、解软件开发的本质。在一篇目前已经成为经典的文章中，Brooks（1987）指出了软件工程的本质和意外因素。软件工程的本质蕴涵在软件本身的固有困难中。我们只能承认这些困难，它们并不是一旦有了突破或有了“银弹”就可以解决的。根据Brooks的说法，软件工程的本质是软件固有的复杂性、一致性、可变性和不可见性的产物。,软件的这4点“基本的困难”确定了软件开发中的一个不变事实。这个不变事实简要地指明软件是开发作为一种创造性活动的产品，是由工匠而不是美术家创作的工艺品或艺术品。在通常情况下，软件不是重复性制造活动的产物。,一旦理解了这个不变事实，人们就应该着手解决软件工程的偶然因素由于软件生产实践带来的困

3、难能够由人工干预来解决。我们将各种“偶然的困难”归结为3类： 1.投入者。 2.过程。 3.建模语言和工具。,1.1软件开发的本质,1.1.l软件开发的不变事实 1.1.2投入者 1.1.3过程 1.1.4建模语言和工具,1.1.l软件开发的不变事实,软件是开发出来的而不是制造出来的。当然，不能否认软件工程的进展为开发实践带来了很多确定的因素，但是（不像传统工程那样）软件项目的成功仍然无法保证。,一个组织不可能找到一个软件包能够使它的核心业务活动自动生成。电话公司的核心业务是电话技术，而不是人力资源或者会计。能够使一个组织运作（并具有竞争力）必须从零开发（或从存在的遗留系统中再开发）， “标准

4、软件包创建了一个适当的游戏场，但竞争必须来自其他的地方。”,当然，在任何情况下，开发过程都应该利用构件技术。构件是一个具有良好设计功能（服务）和对其他构件的通信协议（接口）的软件的可执行单元。我们可以通过配置构件来满足应用需求。当前，最有影响的构件技术有： 对象管理组（OMG）的公共对象请求代理体系结构（CORBA）。 Microsoft的分布式构件对象模型（DCOM）。 Sun的企业级JavaBeans（EJB）。,软件包、构件以及一些相似的技术并没有改变软件生产的本质。尤其是，需求分析与系统设计的原理和任务仍然保持不变。最终的软件产品可以由标准和定制的构件组装而成，但“组装过程”还是一门艺

5、术。坦率地说，我们甚至没有“备件”来替换“使用中”的系统的残缺构件。,1.1.2投入者,投入者是那些与软件项目之间存在利害关系的人。任何被这个软件系统影响或者影响系统开发的人都是投入者。其中有2种主要的投入者： 客户（用户或系统所有者）。 开发人员（分析员、设计员、程序员等）。,我们倾向于使用术语客户而不是用户。从系统开发的角度看，区别两者肯定是有充分依据的。第一，客户是给开发付钱的人，负责制定决策。第二，即使客户有错，客户的需求也不能由开发者任意改变或拒绝，任何矛盾的、不可行的或不合法的需求都必须与客户再次进行协商。,信息系统是社会系统，它们由人（开发者）为人（客户）开发，软件项目的成功由社

6、会因素确定，技术是第二位的。有许多技术水平不高的系统在为客户工作并使客户获益，反之就不是这样，一个对客户没有任何觉察的或真实的益处的系统将被放弃，不管其技术上如何顶尖。,在通常情况下，软件失败的主要原因可以追溯到投入者的因素。在客户方面，项目失败是因为： 客户的需要被误解或没有被完全捕捉。 客户需求变化得过于频繁。 客户没有准备为项目提交足够的资源。 客户不想与开发人员合作。 客户具有不现实的期望。 系统不再对客户有利。,项目还会由于开发者不能胜任这项任务而失败。随着软件复杂度的增加，人们越发地认识到开发者的技能和知识非常关键。好的开发者能够给出一个好的解决方案，杰出的开发者可以给出更好的方案

7、，因为它更快也更便宜。就像出自Fred Brooks的那句著名的俏皮话：“杰出的设计来自杰出的设计者。”,开发者的优秀和责任心是提高软件质量和生产率的关键。为了保证软件产品能成功地交给客户，更重要地，从中取得来自生产率提高的效益，软件组织必须采取一些明显的涉及开发者的措施： 雇佣最好的开发者。 为现有的开发者提供继续培训和教育的机会。 鼓励开发者之间进行信息交换和交互，使他们互相促进。 通过消除障碍并将努力引导到生产工作来激励开发者。 提供一个令人鼓舞的工作环境。 使个人目标和组织策略及目标相一致。 强调团队工作。,1.1.3过程,软件开发过程确定以促进开发小组内部合作的活动和组织的程序，使得

8、能交给客户一个性能优良的产品。过程模型包括： 说明执行活动的次序。 说明需要交出什么样的制品，以及什么时候交出。 将活动和制品分配给开发者。 提供监控项目进程、评估产出和计划未来项目的准则。,开发过程无法标准化或编成法典自动地被组织接受，每个组织必须定义自己的过程模型或将一个通用的过程模板客户化，如由Rational软件公司提供的被称为Rational统一过程的那个模板。,组织所采用的过程必须与它的开发文化、社会动力、开发人员的知识和技能、管理的实践、客户的期望、项目的大小甚至应用领域的种类等方面相一致。因为所有的这些因素都是易变的，组织应为每个软件项目改变它的过程模型并创建过程模型的一个变形

9、。例如，根据开发人员对建模方法和工具的熟悉程度，项目进行过程中可能需要含有特殊的培训课程。 项目的大小对过程影响可能最大。在小项目中（10个左右开发人员），可能根本不需要形式化的过程，这样的小组可以非形式地交流并响应变化。而在大项目中，一个非形式化的通信网络肯定不够，而用于控制开发的良定的过程就是必需的了。,1.1.3过程,1.1.3.l迭代式和增量式开发 1.1.3.2能力成熟度模型 1.1.3.3 ISO 9000,1.1.3.1迭代式和增量式开发,现代软件开发过程总是迭代增量的。系统模型通过分析、设计和实现这样一些阶段得到精化和转换细节在连续的迭代时加进去，必要时还要进行更新和改进，而且

10、软件模块的增量式的版本维持了用户的满意度，井提供对仍在开发之中的模块的重要反馈。,就像Rational统一过程所陈述的那样“迭代过程就是涉及管理可执行的版本流的过程，增量过程则是涉及系统体系结构连续集成以产生这些版本的过程，其中每个新的版本都在其他版本基础上嵌入了增量的改进。”,迭代式和增量式过程是否成功在早期系统体系结构模块的识别时就能断定。这些模块应该是小规模、高度一致而且具有最小的重叠（耦合）度的，其中模块的执行次序也很重要。一些模块如果它们依赖于仍在开发中模块的信息或计算的话也许就不能执行。迭代式和增量式开发如果不能控制项目的实际进程就可能退化为“专门的处理”，除非它是有计划和有控制的

11、。,1.1.3.2能力成熟度模型,从事软件生产的组织都面临一个重要的挑战，即改进它的开发过程。很自然地，为了进行过程改进，组织必须了解当前过程的问题是什么。能力成熟度模型（CMM）是一个流行的用于过程评估和改进的方法。 CMM由美国匹兹堡的卡内基梅隆大学的软件工程研究所（SEI）给出，起初被美国国防部用来评估来竞标国防合同的组织的IT能力，现在已被美国和其他地方的IT业广泛地使用。,CMM基本上就是一个交给组织填写的问卷，这个问卷后面有一个验证和证明过程，这个过程为填表的组织赋予CMM的五个级别中的一个级别，级别越高，组织的过程成熟度越好。图1-1定义了这五个级别，并附上了每个级别主要特征的简

12、短描述，而且指明了当组织需要达到更高的级别时，其过程改进的主要范围。,Arthur 称成熟度级别是“通向软件卓越的阶梯”，这个阶梯上的 5个台阶分别是混沌、项目管理。方法和工具、度量和连续质量改进。经验表明，要按这个成熟度的尺度向上进一级要花几年的时间，大多数组织处于第1级，有一些达到第2级，达到第5级的寥寥无几。,下面一些问题展示了这项任务的困难： 软件质量保证功能是否有独立于软件开发项目管理的管理报告渠道？ 涉及软件开发的每个项目是否都具有软件配置控制功能？ 对那些在没有制定合同承诺的情况下的软件开发的管理评价是采用正式的过程吗？ 有正式的过程来产生软件开发日程吗？ 有正式的过程来估计软件

13、开发的成本吗？ 有收集软件代码和测试错误的统计吗？ 资深管理是否有一种机制作为对软件开发项目状态的常规评价？ 有一种机制用来控制软件需求的改变吗？,1.1.3.3 ISO 9000,除了CMM外，还有其他的过程改进模型，特别受到关注的是国际标准化组织开发的关于质量标准的 ISO 9000系列。 ISO标准应用到质量管理和过程中，以生产出具有品质保证的产品。 ISO标准是通用的，可以应用到任何工业和所有类型的业务中，包括软件开发。,ISO 9000标准的主要承诺是：如果过程正确，则该过程的产出（产品或服务）也将是令人满意的，“质量管理的目的就是要通过按照将质量建造成产品，而不是按照将质量试验成产

14、品的方式，来生产具有品质保证的产品。” 按照我们前面对过程的讨论，ISO标准并没有强制性的或规定的过程，这些标准提供的是关于什么是必须完成的、而不是活动怎样执行的模型。请求ISO认证（也称为注册）的组织必须说明它所做的、做它所说的、演示它已经做的。,一个ISO认证的组织的敏感性测试即使当它的全部劳动力都被替换了，它也应该能够制造出具有品质的产品，或者提供具有品质的服务。为了这个目标，这个组织一定要记录和整理它的所有活动，并为每个过程规定成文的步骤，包括当出现错误时或者客户抱怨时要如何做的活动。 与CMM认证一样，ISO认证只有在ISO注册员实地检查后才能批准。这些检查还要按一定规律的间隔重复进

15、行。组织被迫进入一个模式，它是通过提供客户要求的产品和服务所确保的竞争力。,1.1.4建模语言和工具,投入者和过程是成功的3个因素中的2个。第3个因素由建模语言和一些工具组成，为制品建模需要通信（语言）和文档化（工具）。 开发人员需要一种语言来创建可视化的和其他形式的模型，以及与客户和其他开发人员进行的讨论。这个语言应该支持各个抽象层次上模型的构造，以在不同程度上详细表示所提出的解决方案。,这个语言应该具有强的可视构件，按照流行的说法是“一幅画胜似千言万语”。它还应该具有较强的说明语义，即它应该支持在“描述性”语句中捕获“过程性”含义，说出“什么”需要做而不是“怎样”去做。 开发人员也需要一个

16、CASE工具（计算机辅助软件工程），CASE工具使得在一个中央资源库中存储和检索模型、并在计算机屏幕上对模型进行图形和文本的操作成为可能。理想的情况是：资源库应该为共享的多个用户（即多个开发者）提供模型的存取手段。,CASE资源库的典型功能是： 模型的协同存取。 支持开发人员之间的合作。 存储模型的多种版本。 标识版本之间的区别。 允许在不同模型中共享同一个概念。 检查模型的一致性和完整性。 生成项目报告和文档。 生成数据结构和程序代码（正向工程）。 从存在的实现中产生模型（逆向工程）等等。,1.1.4建模语言和工具,l.1.4.l统一建模语言 1.1.4.2 CASE和过程改进,1.1.4.

17、1统一建模语言,“UML是一个通用的可视化建模语言，它可以用来说明软件系统制品及其可视化、构造和文档化。” UML由 Rational软件公司开发，以统一早期方法和表示法中好的特性。1997年，对象管理组织（OMG）批准它为标准建模语言。从那时起，UML得到了进一步完善，并且已经被IT业界广泛采用。 虽然后来Rational又提出了一个与之相应的过程，称为Rational统一过程，但UML仍然独立于任何软件开发过程。不过，非常清楚的是，一个采用UML的过程必定支持面向对象方法来进行软件生产。UML不适用于老式的结构化方法，这种方法使系统用过程式程序设计语言来实现，如 COBOL。,UML还独立

18、于实现技术（只要它们是面向对象的），这使得UML在支持开发生命周期的详细设计阶段方法方面不很充分，缺了一点什么。但出于同样的理由，这一点也使UML对实现平台的经常变化具有包容能力。 UML的语言成分支持系统的静态结构建模和动态行为建模。系统被构造为一组合作的对象（软件模块）的集合，这些对象响应外部事件执行为客户（用户）带来利益的任务。单个的模型强调系统的某个方面而忽略其他模型所强调的那些方面，所有模型合到一起提供系统的完整描述。,UML模型可以分为3组： 状态模型（描述静态数据结构）。 行为模型（描述对象合作）。 状态变化模型（描述与时间有关的系统所允许出现的状态）。 UML还包含一些体系结构

19、的成分，支持系统模块化以利于迭代增量式开发。,1.1.4.2 CASE和过程改进,过程改进大大超越了新的方法和技术的引入。事实上，在过程成熟度低的层次上，为组织引入新的方法和技术，其弊大于利。 CASE技术是一个很好的例子。一个集成的 CASE工具能够支持多个开发人员的合作和共享设计信息，以产生新的设计制品。这样的 CASE工具强加在确定的过程上迫使开发组必须利用这个技术。但是，如果这个开发组没有能力去改进它的过程，它要吸纳这个由CASE工具指明的过程是绝对不可能的。结果，由这项新技术带来的潜在的生产率和质量的提高就不能实现。,上面的讨论不应该误导读者认为CASE技术是“充满风险的事”。它是说

20、，如果你试图用它来驱动整个开发组，但这个开发组并没有作好遵循这个过程的准备时，它也许不能带给你预期的好处。当然，对那些在他们自己的局部工作站上采用这项技术的个体开发人员来说，同样的CASE方法和技术总会带来个人生产率和质量的改进。用纸和笔画的建模软件构件在课堂上有意义，但在真实项目中就不是这样了。,1.2系统规划,信息系统项目必须是有规划的。为了初始的开发、改进或者也许是消除，这些规划必须被识别、分类、排序和选择。问题是：哪种IS技术和应用将给业务带来最大的价值？理想地，关于走哪条路的决策应该以业务策略为基础、以细致而有条理的规划为基础。,业务策略可以通过各种过程来确定，如策略规划、业务建模、

21、业务过程再设计工程、策略调整、信息资源管理或其他类似的东西。解释这些方法之间的区别不是我们这里的目的，所有这些方法的目的都在于给业务确定一个长期的视点，并研究组织中的基本业务过程，然后对那些能够通过使用信息技术来解决的过程进行优化。说明了这些就己经足够了。,这就是说，有许多组织，特别是许多小组织没有明确的业务策略。这样的组织很可能只是简单地识别那些迫切需要解决的问题，来确定信息系统的开发。一旦外部环境或内部业务情况发生变化，存在的信息系统就不得不跟着改变。当然，这些方法虽然有明显的缺点，但它也使得这些小组织能够很快地关注它们当前的状况或者利用新的机会，或者断然排除新的威胁。,大组织经受不起业务

22、方向的经常变化。实际上，它们经常为相同业务方向的其他组织指引方向。在某种程度上，它们能创造环境来满足它们当前的需求。当然，大组织不得不非常仔细地洞察它们的未来，它们必须采用基于规划的方法来确认开发项目，这些典型的大型项目需要一个相对长的时期来完成。它们是如此的庞大以致于很难轻易地被改变或者替代，它们需要适应或甚至把握未来的机遇和威胁。,有许多不同的方法可以用来开展系统规划。一种传统的方法被称为SWOT（Strength，Weakness，Opportunity，Threat）：另一个流行的策略以VCM（ Value Chain Model）为基础：开发业务策略更现代的方法被认为是 BPR（Bu

23、siness Process Reengineering）。一个组织对信息的需要也能够通过采用 ISA（Information System Architecture）的蓝图来评估，这样的蓝图可以对非IT行业（例如建筑行业）被证明是成功的描述性框架进行类比而得到。,所有系统规划方法有一个共同的特性，即它们关心效果（做正确的事情）而不关心效率（正确地做事）。有效地做一件错误的事情并不好。,1.2系统规划,1.2.1 SWOT方法 1.2.2 VCM方法 1.2.3 BPR方法 1.2.4 ISA方法 1.2.5三个管理层次的系统,1.2.1 SWOT方法,SWOT（ Strength，Weakn

24、ess，Opportunity，Threat）方法通过对组织的优势、弱点、机会和威胁进行排比的方式来支持识别、分类、排序和选择IS开发项目，这是一种从确定组织的使命开始、自顶向下的方法。,关于使命的陈述捕捉了组织的惟一特征，表明它要在未来处于何处的视点。一个好的使命的陈述应将重点放在客户需要上，而不是组织要提供的产品和服务上。 关于使命的陈述和由此导出的业务策略考虑到在管理、生产、人力资源、财务、市场、研发等方面的内部优势和弱点，在这些优势和弱点之间必须认真地协商、达成一致并进行优化。一个成功的组织总是能够识别当前的优势和弱点集，并由此引导它的业务策略的发展。,识别组织内部的优势和弱点对成功的

25、业务规划来说是必要条件而不是充分条件。组织不是在真空中运作，它依赖于经济、社会、政治和技术的因素，组织必须了解能被利用的外部机遇和应该避免的外部威胁，这是一个组织无法控制但必须了解的因素，对决定组织的目标和目的来说它们是最本质的。,组织在任何给定的时刻都追求一个或几个目标，而目标一般是长期的（35年）、甚至是“无限长的”，一般的目标示例为改进客户满意度、引入新的服务、应付竟争威胁、增加对供应商的控制等等，每个策略性目标必须与一个特定的目的关联起来，且通常表示为一个年度目的。例如，目标“改进客户满意度”可以由达到更快地（比如在两个星期内）处理客户定单的目的来支持。,目标和目的都需要管理策略和实现

26、这些策略的管理政策。这样的管理手段就要调整组织结构、分配资源和确定发展项目（包括信息系统等）。,1.2.2 VCM方法,VCM（价值链模型）通过分析组织中完整的活动链（从原材料到最终产品卖出和送到客户手中）来评估竞争优势。用价值链的比喻增强这个观点，只靠单独的一个弱链会引起整个链的崩溃。,这个模型用于理解哪个价值链结构将产生最大的竞争优势，IS开发项目因而能着眼于给出最大竞争优势的那些片段、操作、销售渠道、营销方法等等。 在最初的VCM方法中，组织的功能被分为基本活动和支持活动，基本活动创建或为最终产品增加价值，它们分为5个连续的步骤：（1）调入后勤（2）操作（3）调出后勤（4）销售和市场（5

27、）服务。,支持活动不（至少是不直接）增加价值，它们仍然是基本的但并不充实产品。支持活动包括：（l）行政管理和基础设施，（2）人力资源管理，（3）研究和发展，以及也许并不令人吃惊的，（4）IS开发。 VCM是IS规划的有用的工具，而无处不在的计算机化能支持业务的变化，这反过来又促进了竞争优势。换句话说， IT可以转换组织的价值链，从而一个IT和 VCM的自我强化循环可以被建立。,Porter和 Millar指明一个组织可以用来拓展 IT机遇的五个步骤： 1.评估产品和过程的信息密度。 2.评估IT在产业结构中的作用。 3.标识和排序IT能够创造竞争优势的方式。 4.考虑IT如何创造新的业务。 5

28、.开发利用IT的规划。,1.2.3 BPR方法,BPR（业务过程再设计工程）方法用于系统规划是基于这样一个假设的：当今的组织必须重新为自身投资，而丢弃那些现在正在使用的功能分解、层次结构和操作原理。 这个概念由 Hammer（ 1990）和 Davenport and Short引入，并立即引起了业界的兴趣，同时也引发了争论。,当前大多数的组织采用垂直的单元结构，它关心功能、产品或区域，这种结构和工作方式可以追溯到18世纪和Adam Smith的劳动力划分和由此产生的工作分段原理。没有一个雇员或部门负责定义“一个拥有一种或多种输入并创造一个对客户有价值的输出的活动集”的这样一个业务过程。 BP

29、R是对Smith关于劳动力划分、层次控制和规模经济的产业原理的一个挑战。在当今世界中，组织必须能够迅速适应市场变化、新的技术、竞争性的因素和客户需要等等。,业务过程必须跨越多个部门的这种僵化的组织结构已经过时。组织必须关注业务过程，而不是个体的任务、工作、人员或部门功能。这些过程水平地穿越业务并终止于与客户的交互点上。“过程企业和传统组织最明显的区别是过程拥有者的存在性” 。,BPR的主要目的是重新设计组织中的业务过程（因此BPR有时被认为是过程重设计）。业务过程必须被识别、流程化并得到改进。这些过程可以用工作流图来描述并进行工作流分析。工作流捕获业务过程中的事件、文档和信息流。这些过程还可以

30、用来计算这些活动所需的时间、资源和成本。,在组织中实现BPR的主要障碍是需要在传统的纵向管理结构中嵌入横向的过程。BPR的最初阶段要求围绕着作为基本组织单元的开发组来改变组织，这些开发组负责一个或多个从头到尾的业务过程。,彻底的改变常常是不可接受的。传统的结构不可能在一个晚上就改变过来，彻底的推动可能遇到反抗，从而有损BPR的潜在利益。在这种情形下，组织仍能够从业务过程建模和改进的努力中（而不是再设计工程中）得到好处。业务过程改进（BPI）这个术语就用来表示这样的一个阶段。,一旦定义了业务过程，过程所有者就要求IT支持进一步改进这些过程的效率。由此而引发的 IS开发项目就集中在实现所标识的工作

31、流上了。 BPR的效率和 IT有效性的组合能够在所有组织性能的现代度量标准上（如质量、服务、速度、开销、价格、竞争优势和灵活性等方面）产生戏剧性的改进。,1.2.4 ISA方法,不同于上面已经描述的方法， ISA（信息系统体系结构）是一个自底向上的方法，为IS解决方案提供一个中性的体系结构框架，它可以适合于不同的业务策略。因而，ISA方法不包括系统规划方法，它只简单地提供了能影响大多数业务策略的框架。,ISA框架由一个有 30个单元的表来表示，这个表划分为五行（标号从1到 5）六列（标号从A到F），其中，行表示用于复杂工程产品构造的不同视角，如信息系统，这些视角来自“这个游戏的”五个主要参与者

32、，即五个IS参与者： 1.规划者（决定系统的范围）。 2.所有者（定义企业概念模型）。 3.设计者（说明系统物理模型）。 4.构建者（提供详细技术方案）。 5.承包者（提供系统构件）。,六列表示每个参与者操作的六个不同的描述或体系结构模型。像视角一样，这些描述互相之间是不同的，但在本质上又是相互关联的。它们分别提供了每个参与者考虑的问题的六个答案： A.这件事情由什么组成？（即在IS中的数据）。 B.这件事情如何起作用？（即业务过程）。 C.这件事情位于何处？（即处理构件的位置）。 D.谁与这件事情一起工作？（即用户）。 E.这件事情什么时候出现？（即事件和状态的调度）。 F.这件事情为什么发

33、生？（即企业的动机）。,这30个单元中不同视角和描述的组合为IS开发提供了建立完整体系结构的强大的术语层次，纵向的视角首先在不同的详细程度上，但更重要的是它们本质上的不同，它们展示了不同的建模表示以及不同的模型强调了参与者的不同视点。同样，横向的描述也是由于不同的原因而设置的，它们每个都对应了上述六个问题之一的答案。,ISA最有吸引力的特征是提供了对业务情况和资源将来的变化来说可能是足够灵活的一个框架，这是因为ISA方案不是从特定的业务策略中来的，它是一个IS系统的完整描述的框架。它从已经确定的学科的经验中导出，其中有些学科具有千余年的历史（如古典建筑学）。,1.2.5三个管理层次的系统,与系

34、统规划相关的是认识到组织具有三个管理层次： 1.策略上。 2.战术上。 3.运作上。,这三个管理层次为一个惟一决策核心、一组明确的IS应用需求以及IT需求的一种特殊支持。系统规划的任务是定义IS应用和IT方案的混合体，这个混合体要求对一个特定时间下的组织是最有效的 。,为组织提供最大收益的IS应用和IT方案处于策略层，但它们同样又是最难实现的它们使用“非常前沿的”技术并且要求非常有技巧的特殊设计。毕竟这是能够使组织具有市场竞争优势的系统。,在这个层次的另外一端，支持运作管理层的系统是非常日程化的、使用常规的数据库技术。并且经常是通过客户化一个已有的软件包而得到的。这些系统不可能提供竞争的优势，

35、但没有它们，这个组织将不能正常运作。,每个现代的组织都有一套运作层的系统，但只有管理得最好的组织才有一个集成的策略层IS应用的集合。用于为高层策略和战术决策制定的数据存储和检索的主要技术被认为是数据仓库。,1.3软件生命周期的阶段,软件开发遵循一个生命的周期。这个术语是如此地流行，以致于常常被缩写成一个词：生命周期。生命周期是为每个开发项目而进行和管理的活动的一个有序集合。其中的过程和方法就成为生命周期实现的机制。这个生命周期标识出随软件产品进程而发展的一个个阶段：从最初的开始到逐步执行至结束。,软件开发生命周期可以在不同阶段的粒度层面上提出。在粗粒度层面上，生命周期可以只包含三个阶段： 1.

36、分析。 2.设计。 3.实现。,分析阶段专注于系统需求。需求在这里被确定并说明。系统的功能和数据模型被开发并集成在一起，非功能需求以及其他系统约束也被捕捉出来。 设计阶段可以划分成两个主要的子阶段：体系结构设计和详细设计。特别地，需要解释用来集成用户界面和数据库对象的客户机/服务器程序的设计。需要提出影响系统的可理解性、可维护性和可扩展性等各种设计方面的问题并文档化。 实现阶段包含客户机应用程序和服务器数据库的编码，强调增量迭代式的实现过程。设计模型和客户机应用和服务器数据库的实现之间的双向工程对产品的成功发布是基本的。,在细粒度层面上，生命周期可以划分为下面七个阶段： 1.需求确定。 2.需

37、求规格说明。 3.体系结构设计。 4.详细设计。 5.实现。 6.集成。 7.维护（和最后逐步结束）。,一些作者还将规划和测试作为两个附加的阶段。按照我们的观点，这两个重要的活动并不是独立的生命周期阶段，因为它们跨越了整个生命周期。一个软件项目管理计划首先在这个过程的早期规划出来，在规格说明阶段被丰富，并且在生命周期的其余阶段得到进化。同样地，测试在实现之后是最密集的，但它还适用于在每个其他阶段产生的软件制品。,1.3软件生命周期的阶段,1.3.l需求确定阶段 1.3.2需求规格说明阶段 1.3.3体系结构设计阶段 1.3.4详细设计阶段 1.3.5实现阶段 1.3.6集成阶段 1.3.7维护

38、阶段 1.3.8软件生命周期中的项目规划 1.3.9软件生命周期中的度量标准 1.3.10软件生命周期中的测试,1.3.l需求确定阶段,Kotonya and Sommerville将需求定义为“系统服务或约束的陈述”。一个服务陈述描述相对于一个个体用户或者相对于整个的用户群这个系统应该如何运行。对于后一种情况，一个服务陈述实际上定义一个必须在任何时间都服从的业务规则。一个服务陈述还可以是一些系统必须执行的计算。约束陈述表示系统行为或者系统开发的限制。,需求确定阶段的任务是和客户一起确定、分析和协商需求。这个阶段涉及从客户处采集信息的各种技术，这是一个通过与用户的结构化和非结构化面谈、问卷、文

39、档和表格的研究、录像等方法进行概念扩展的过程。需求阶段最后的技术是进行方案的快速成型，以便困难的需求可以澄清并且避免误解。 需求分析包括开发者和客户之间的协商，这个步骤对消除矛盾和过度需求以及对遵守项目预算和到期日期来说都是必需的。,需求阶段的产品是需求文档，这个文档大多数是叙述性正文文档，并带有一些非形式化的图形和表。没有形式化的模型包含在内，也许除了一些容易和流行的表示法，这些表示法能够很容易被客户理解并且能够辅助开发者和客户之间的沟通。,1.3.2需求规格说明阶段,需求规格说明阶段始于开发者开始使用一种特定的方法（如 UML）对需求进行建模。一个CASE工具被用来输入、分析和文档化这些模

40、型。作为一个结果，需求文档由图形模型和CASE生成的表格得到进一步的丰富。基本上，规格说明文档代替了需求文档。 面向对象分析中的两个最重要的规格说明技术是类图和用例图。这些是对数据和功能进行规格说明的技术。典型的规格说明文档还将描述其他的需求，如性能、外观、可用性、可维护性、安全性、政策和合法需求。,规格说明模型能够并且将会重叠。它们允许所提出的方案可以从许多不同的角度来看，以便这个方案的特定方面能被强调和分析。需求的一致性和完整性也被仔细地检查。 理想地，规格说明模型应该独立于系统要被实施的硬件软件平台。硬件软件的考虑对建模语言的词汇（因此表达能力）会强加很大的限制。而且，客户难以理解这样的

41、词汇，从而妨碍了开发者客户之间的沟通。 这就是说，事实上，有一些约束陈述是强加给开发者的硬件软件方面的考虑。而且，客户自己也可能表达他们与特定硬件软件技术相关的需求，或者甚至会要求使用某种特定的技术。这里的经验是：只要可以就避免硬件软件的考虑。,1.3.3体系结构设计阶段,规格说明文档就像是开发者和客户之间为了这个软件产品的交付而形成的合同。它列出了这个软件产品必须满足的所有需求。规格说明现在交给了系统体系结构师和设计人员去开发系统体系结构及其内部工作的低层模型。设计根据系统将要赖以实现的软件硬件平台来进行。,以其模块为根据的系统描述被称为体系结构设计。体系结构设计包括对关于这个系统的客户机和

42、服务器方面的方案策略的决策。 每个模块（用例）的内部工作的描述被称为详细设计。它为每个模块开发详细算法和数据结构，这些算法和数据结构被裁剪来适应基本实现平台的所有（强化的和阻碍的）约束。,体系结构设计涉及解决方案策略的选择以及系统的模块化。解决方案策略需要决定客户机 （用户界面）和服务器（数据库）等问题，以及“粘合”客户机和服务器所需要的中间件。关于基本构件（模块）的决策与解决方案策略相对无关，但模块的详细设计必须适应于所选择的客户机服务器解决方案。,客户机服务器模型经常被扩展，以提供一个三层的体系结构，这里应用逻辑构成一个独立的层次。这个中间层是一个逻辑层，并且可能由也可能不由独立的硬件来支

43、持。应用逻辑是一个过程，这个过程能够在客户机或者服务器上运行，即它可以被编译进客户机或者服务器过程中，并且由 DLL（动态链接库）、 API（应用程序设计接口）和 RPC（远程过程调用）等来实现。,1.3.4详细设计阶段,体系结构设计依据模块来描绘这个产品，详细设计描述每个模块。在典型的IS开发过程中，模块要么分配给一个客户机构件，要么分配给一个服务器构件，应用设计人员负责前者，数据库设计人员则开发后者。 用户界面（客户机）设计必须适应由特定的 GUI接口设计者提供的 GUI设计指南，这样的设计指南一般作为电子GUI文档（如 Windows 2000）的一部分在线提供。,面向对象GUI设计的主

44、要原理是用户控制而不是程序控制。程序响应随机产生的用户事件，并且提供必要的软件支持。其他的GUI设计原理都是从这个事实出发的。（当然，“用户控制”原理不应该教条地使用，程序还将验证用户的特权并且可能会不允许某些用户的行为。） 数据库设计定义数据库服务器的对象，大多数可能是关系型的（或者可能是由向对象的）服务器。其中的一些对象是数据容器（表、视图等），而其他一些对象为过程（存储过程、触发器等）。,1.3.5实现阶段,信息系统的实现涉及为买来的软件进行安装，以及为客户定义的软件进行编码。它还涉及其他重要活动，如测试和产品数据库的装入、测试、用户培训、硬件问题等等。 典型的实现队伍的组织要区分两组程

45、序员：一组负责客户机程序设计，而另一组负责服务器数据库程序设计。客户机程序实现窗口、应用逻辑并且在需要的时候调用服务器数据库程序（存储过程）。保证数据库一致性以及事务处理正确性的责任就落在服务器程序的身上了。,在真正的迭代增量式开发中，用户界面的设计经常引起实现的变化。应用程序选择要实现窗口的不同表现形式，来保持与供应商的GUI原理一致、辅助程序设计或者提高用户的生产率。 同样，服务器数据库实现可能要迫使设计文档的改变，不可预见的数据库问题、存储过程和触发器编程中的困难、并发的问题、与客户机过程集成、性能的调整等等，都只是设计必须修改的部分原因。,1.3.6集成阶段,增量式开发蕴涵着软件模块的

46、增量式集成。这个任务并不是无关紧要的。对大型系统来说，模块集成可能比早期生命周期的任何一个阶段（包括实现阶段）都要花费更多的时间和精力。正如 Aristotle注意到的：“整体比部分的总和还要多”。,模块集成必须在软件生命周期一开始就仔细地规划。独立实现的软件单元必须早在系统分析阶段就标识出来，然后在体系结构设计期间再详细解决，实现的次序必须使增量式的集成能平缓地进行。 增量式集成的主要困难来自模块之间交织在一起的相互依赖关系。在设计良好的系统中，这样的模块之间的耦合度应该最小。然而，经常是两个模块互相依赖，致使它们都不能独立工作。,如果我们要在其他模块准备好之前必须交付一个模块怎么办呢？回答

47、是先写一段特殊的程序代码，来“填补空白”，从而使得所有的模块可以被集成起来。用来模拟遗漏模块的程序被称为是残桩模块。 不像传统的以主程序为基础的软件系统，在现代面向对象的事件驱动的系统中，没有中央智能（主程序）。在现代系统中，没有清晰定义的集成结构。一般的自顶向下或者自底向上的集成策略都不适合于现代系统。,面向对象系统必须为集成而设计，所以每个模块都应该尽可能独立，而且模块之间的相关性应该在分析和设计阶段就标识出来并被最小化。理想的情况下，每个模块都应该作为一个对特定的客户需要的响应，从而成为一个独立的处理线程。作为代用品的残桩模块的使用应该尽可能避免。如果没有设计好，集成阶段就会引起混乱，并

48、将导致整个开发项目的失败。,1.3.7维护阶段,当每个增量的软件模块和最后的整个软件产品被交付给客户时，维护紧接着就开始进行。维护不仅仅是软件生命周期固有的部分。就IT人员的时间和工作量来说，它占据生命周期中的大部分。Schach估计生命周期67的时间要花在软件维护上。,维护由三个不同的阶段组成： 1.内务型维护。 2.自适应型维护。 3.改善型维护。,内务型维护涉及保持系统的用户可用性和可操作性所必须的日常维护。自适应型维护涉及系统操作的监控和检查、调整系统的功能以满足变化的环境，以及使系统适应于满足性能和吞吐量的要求。改善型维护涉及系统的重新设计和修改，以适应新的或者本质上改变了的需求。

49、最后，软件系统的继续维护变成不可支持的，然后这个系统就不得不被淘汰。系统的淘汰通常是由于对系统的可用性很难再进行什么工作了。这个软件可能仍然有用，只不过它已经变得不可维护了。,淘汰软件的四个原因： 1.提出的改变超出了改善型维护的直接能力范围。 2.系统已经超出了维护所控制的范围，并且变化的结果无法预料。 3.缺乏文档作为将来软件扩展的依据。 4.实现硬件软件平台必须被替换而没有可用的移植方法。,1.3.8软件生命周期中的项目规划,有一条熟悉的格言说，如果你不能规划一件事，你就不能做这件事。规划跨越软件项目的生命周期，一旦系统规划活动为组织确定了业务策略并且软件项目被标识时，规划就开始了。项目

50、规划估计项目的可交付性、成本、时间、风险、里程碑和资源需求，它还包括对开发方法、开发过程、开发工具、开发标准、开发队伍组织等的选择。,项目规划是一个不定的目标，它不是做好之后就一成不变的事情。在一些固定约束的框架内，项目规划随生命周期而进化。 一般的约束有时间和费用。每个项目都有明确的交付时间和紧张的预算，项目规划的首要任务之一是在时间、预算和其他约束之下评估项目是否可行。如果可行，这些约束就被文档化，并且以后只能通过一个正式的批准过程来改变。,项目可行性按要考虑的几个因素来评估： 操作可行性重新解决当项目被标识时就在系统规划被提出的问题。它研究所提出的系统将如何影响组织结构、过程和人员。 经

51、济可行性评估项目的成本和效益（也被认为是成本效益分析）。 技术可行性评估所提出的技术方案的实用性和技术技能、专业知识和资源的可用性。 进度表可行性评估项目时间表的合理性。,并不是所有的约束都已知，或者可以在项目启动时就被估计出来，另外的约束将在需求阶段被发现并且将经历可行性研究，这些包括法律的、合同的、政治的和安全性的约束。 经过可行性评估，项目计划将被构造并且将组成项目和过程管理的指南。,项目规划要解决的问题包括： 项目范围。 项目任务。 指导和控制项目。 质量管理。 度量标准和度量。 项目安排。 资源分配（人员、物资和工具）。 人员管理。,1.3.9软件生命周期中的度量标准,测量开发时间和

52、工作量，以及采取其他与项目制品相关的度量标准，事实上是项目和过程管理的一个重要方面。虽然它是个重要的方面，但在较低成熟度的组织中却常常被忽略。它的代价太高。没有度量它的过去，组织也不能够准确地规划它的未来。,度量标准通常是在软件质量和复杂度的范围内进行讨论，它们作用到软件产品的质量和复杂度上。度量标准用于测量像正确性、可靠性、有效性、完整性、可用性、可维护性、灵活性以及可测试性等这样一些质量的因素。例如，可以通过度量故障和故障之间的频率和严重程度，通过输出结果的准确性，以及从故障中恢复的能力等方面，来评估软件的可靠性。 度量标准另一个同等重要的应用是度量生命周期不同阶段的开发模型（开发的产品）

53、。然后它被用来估计过程的有效性，并改进不同生命周期阶段的工作质量。,典型度量标准是： 需求变化率（直到需求阶段结束时，改变了的需求所占的比率），这可以反映从客户处获取需求的困难。 需求阶段结束以后的需求变化率，这可以指明一个质量很差的需求文档。 对系统中的“热点”和“瓶颈”的预测（用户试图执行该软件产品原型中不同功能的频率）。 由 CASE工具产生的规格说明文档的大小，以及其他来自 CASE资源库的更详细的度量标准，如类模型中类的个数。如果加上一些以前已经知道完成所需时间和成本的项目，这个度量标准就为预测将来项目的时间和成本提供了一个理想的规划“数据库”。 故障的统计记录：故障什么时候出现在产

54、品中，以及什么时候被发现和纠正。这可以反映质量保证、审查过程和测试活动的全面性。 在认为测试单元对集成和交付给客户是可接受的之前，进行测试的平均次数。这可以反映程序员的调试过程。,1.3.10软件生命周期中的测试,像软件规划或者度量标准的采用一样，测试也是跨越软件生命周期的活动。它不是一个在实现之后的独立阶段。在软件产品实现以后才开始测试我们己经做的东西就太迟了。那时修正生命周期早期阶段的错误所带来的损失的将是巨大的。,测试活动应该仔细地规划。首先，测试案例必须被确定，测试案例（或者测试计划）定义在试图“打碎”这个软件模型或者产品中要进行的测试步骤。 对需求文档中描述的每个功能模块（用例）都应

55、该定义测试案例，将测试案例关联到用例，这才建立了一条测试和用户需求之间的可跟踪路径。要成为可测试的，软件制品必须是可跟踪的。,每个开发者测试自己开发出来的产品是很自然的，然而原来的开发者多少会被他们先前为生产这个软件制品而做的工作蒙住了眼睛。 要达到更好的效果，应该由第三方进行系统的测试。这个任务可以交给软件质量保证 （SQA）小组，这个小组应该包括一些最好的开发人员，他们的工作就是测试，而不是开发。然后由SQA小组（不是原来的开发人员）担负起确保产品质量的贡任。,我们在开发的早期所做的测试越多，得到的回报就越好。需求、规格说明以及任何文档（包括程序源代码）都能够用正式审查的方式来测试（即所谓

56、的走查和检查）。 正式的审查是认真准备的会议，它针对文档或者系统的某个特定部分，由指定的审查员事先研究一份文档，然后提出各种问题。这个会议决定其中的问题事实上是否就是错误，但并不试图对这个问题提供一个直接的解决方案，然后，原来的开发人员将会解决这个问题。如果这个会议是友好的并且避免了互相指责，那么这个“小组的协同作用”将使得许多错误在早期就被检测并改正。,一旦发布软件原型和软件产品的第1个版本，基于执行的测试就能够进行。有两种基于执行的测试： 对应规格说明的测试（黑盒测试）。 对应代码的测试（白盒或者玻璃盒测试）。,对应规格说明的测试把程序本身看做一个黑盒子，除了输入和输出以外，其他的都不知道

57、。给定某个输入，产生的结果就用来分析看是否存在错误。对应规格说明的测试对发现不正确的或者丢失的需求特别有用。 对应代码的测试“看透”程序逻辑以导出练习程序中各种执行路径所需要的输入。对应代码的测试是对应规格说明测试的一种补充，这两种测试旨在发现不同类型的错误。,增量式开发不仅蕴涵着软件模块的增量式集成，而且还蕴涵着增量式或者回归测试。回归测试是在以前提交的软件模块已经被增量地扩展之后，以前的测试案例在同样的基线数据集上的再次执行。其假设是老的功能应该保持不变，并且不应该由于扩展而被破坏。,回归测试能够用捕捉回放工具来支持，这个工具支持捕捉用户与程序的交互并且在没有用户干涉的情况下回放出来。回归

58、测试的主要困难是基线数据集被强化。增量式开发不只是扩展过程程序逻辑，它还要扩展（并且修改）基本数据结构。一个被扩展后的软件产品可能强化对基线数据集的变化，因此消除对结果的敏感性比较。,1.4软件开发方法,“软件革命”已经为软件产品的工作方式引入了一些明显的变化。特别是，软件已经变得更具有交互性，而且程序的任务和行为可以动态地适应用户的需求。,过去类似COBAL程序的过程逻辑非常灵活，并且不负责意料之外的事件。一旦开始运行，程序就按比较确定的方式执行直至完成。偶尔，程序可能从用户那里要求一些信息，并且走过不同的执行分支。通常，与用户的交互是受限制的，并且不同执行路径的个数是预先固定的。起控制作用

59、的是程序，不是用户。 随着现代GUI（图形用户界面）的出现，事情就发生了戏剧性的变化。 GUI程序是事件驱动的，并且是由用户操纵键盘、鼠标或者其他输入设备产生的事件，它按随机的、不可预测的方式运行。,在GUI环境中，用户在很大程度上控制着程序的执行，而不是相反的情况。在每个事件的后面，总有一个软件对象知道在程序执行的当前状态下如何为这个事件服务。一旦这个服务被完成，控制权便被返还给用户。 程序风格的不同要求软件开发的方法也不同。传统的软件由称作为结构化方法的技术来开发，而现代GUI系统则要求面向对象程序设计，并且对象方法是设计这种系统的最好方法。,1.4软件开发方法,1.4.l结构化方法 1.

60、4.2面向对象方法,1.4.l结构化方法,系统开发的结构化方法早在20世纪80年代就很流行（并且被标准化），这个方法主要基于两种技术：过程建模的DFD（数据流图）和数据建模的ERD（实体关系图）。 结构化方法是以功能为中心的，并已将DFD作为驱动开发的动力。近来，由于关系数据库模型流行的直接结果，DFD在结构化开发中的重要性已经减弱，开发方法已经变为以数据为中心，其重点放在ERD上。,DFD和ERD的组合给出了相对完整的分析模型，它在独立于软件硬件考虑的抽象层次上，捕捉所有的系统功能和数据。这种分析模型随后转换为一个设计模型，并通常是用关系数据库的术语来表达，然后跟着的是实现阶段。,分析和设计

61、的结构化方法用许多特性来刻画，其中的一些无法与现代的软件工程相比： 这种方法倾向于按次序以及变换的方式，而不是选代增量的方式（即这种方法不支持通过迭代求精和增量式的软件提交而产生的无缝开发过程）。 这种方法倾向于提交灵活的解决方案，来满足所确定的、但将来难以扩大规模和扩展业务功能的集合。 这种方法基本上都是从零开始进行开发，它不支持以前存在的构件的复用。,该方法的这样一种逐步变换的本质带来了相当的风险，即对用户需求的错误理解将沿着开发过程而传播。这种风险还会由于需要逐步放弃分析模型的相对描述性的语义而渐进产生设计模型和实现代码中的过程式方案而加剧（这是因为在语义上它比基本的设计和实现模型要丰富

62、得多）。,1.4.2面向对象方法,用于系统开发的面向对象方法流行于20世纪90年代，对象管理组织（ OMG）批准了它的一个标准UML。 与结构化方法相比，面向对象方法更加以数据为中心，它围绕类模型进行演化。在分析阶段，类不需要拥有定义的操作，而只有属性就可以。UML中用例的日益重要表示重点稍稍从数据转向了功能。,有这样一个感觉，即开发人员使用面向对象方法是因为对象范例技术上的优点，如抽象、封装、复用、继承、消息传递、多态性等，这些技术特征能够带来更强的代码和数据的可复用性、更少的开发时间、程序员生产率的增长、软件质量的提高、更强的可理解性等等。 在吸引人的同时，对象技术的这些优点在实际中并不总

63、是能够体现出来。然而，我们今天确实在使用对象技术，而已明天仍将使用它们。其原因在于我们不得不需要由现代图形用户界面（GUI）所支持的事件驱动的新型程序设计风格。,对象技术流行的另外一个原因是，我们不得不解决新型的涌现式应用的需要以及解决应用的积压的最好方式。两者都需要采用对象技术的最重要的新型应用是工作组计算和多媒体系统。通过已经为人们所熟知的“对象打包”概念来停止应用的积压的增长的思想已被证明既有吸引力又是可行的。,系统开发的对象方法遵循迭代增量式的过程，单个模型（以及单个设计文档）通过分析。设计和实现阶段被逐步地“充实”。细节在不断的迭代中被加进去，变化和精化在需要的时候引入，并且所选模块

64、的增量式交付维护了用户的满意度井反馈给其他模块。,逐步精化式的开发是可能的，因为所有的开发模型（分析、设计和实现）语义上都很丰富，并且基于同一种“语言”基本的词汇在本质上是相同的（类、属性、方法、继承、多态性等等）。注意，如果实现是基于关系型数据库的话，还需要进行一个复杂且有风险的变换（因为关系模型的基本语义相对而言比较弱）。,对象方法避免了结构化方法最重要的缺陷，但也带来了一些新的问题。 分析阶段在一个非常高的抽象层次上进行。 项目管理非常困难。 不断增大的方案复杂性。,分析阶段在一个非常高的抽象层次上进行，并且如果实现服务器方案要求一个关系型数据库的话，概念及其实现之间的语义距离就会相当显

65、著。虽然分析和设计可以按迭代增量式的方式进行，但开发总会进入实现阶段，而这个阶段需要变换为关系数据库。如果实现平台是一个对象或者是对象关系型数据库，则从设计出发的变换会容易得多。,项目管理非常困难。过去，管理者用定义清晰的工作来分解结构、可交付性以及阶段之间的转折点来度量开发进程。但在通过“逐步精化”的对象开发中，各开发阶段之间没有清晰的边界，而目一项目文档也是连续进化的。对这个困难有一种吸引力很大的解决方案，它将整个项目划分为小的模块，并且通过这些模块频繁的可执行版本（这些版本中有一些是内部的，其他一些则是被交付的）来管理进程。,对象方法的另一个主要问题关系到不断增大的方案复杂性，这反过来会影响软件的可维护性和可扩展性。,但对象方法带来的困难并没有改变这个事实，即 Arthur Clarke的说法“未来不是往常那样”。我们不会回到旧日的批量COBAL应用的过程型风格程序设计上。IS开发项目的所有投入者都知道因特网、电子商务、计算机游戏以及其他的交互式应用。 新型软件应用建造起来会更加复杂，结构化方法对这种任务是不合适的。面向对象方法是我们目前惟一知道的能驾驭新型事件驱动的高度交互式软件开发的方法。,再见！ Good bye,