需求分析与系统设计1

《需求分析与系统设计1》由会员分享，可在线阅读，更多相关《需求分析与系统设计1（138页珍藏版）》请在金锄头文库上搜索。

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

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

3、就应该着手解决软件工程的偶然因素 由于软件生产实践带来的困难能 够由人工干预来解决。我们将各种“偶 然的困难”归结为3类：l1.投入者。l2.过程。l3.建模语言和工具。 1.1软件开发的本质 l1.1.l软件开发的不变事实 l1.1.2投入者 l1.1.3过程 l1.1.4建模语言和工具 1.1.l软件开发的不变事实软件是开发出来的而不是制造出 来的。当然，不能否认软件工程的进 展为开发实践带来了很多确定的因素 ，但是（不像传统工程那样）软件项 目的成功仍然无法保证。 一个组织不可能找到一个软件包 能够使它的核心业务活动自动生成。 电话公司的核心业务是电话技术，而 不是人力资源或者会计。能够

4、使一个 组织运作（并具有竞争力）必须从零 开发（或从存在的遗留系统中再开发 ）， “标准软件包创建了一个适当的游 戏场，但竞争必须来自其他的地方。” 当然，在任何情况下，开发过程 都应该利用构件技术。构件是一个具有 良好设计功能（服务）和对其他构件的 通信协议（接口）的软件的可执行单元 。我们可以通过配置构件来满足应用需 求。当前，最有影响的构件技术有：l对象管理组（OMG）的公共对象请求 代理体系结构（CORBA）。lMicrosoft的分布式构件对象模型（ DCOM）。lSun的企业级JavaBeans（EJB）。 软件包、构件以及一些相似的技 术并没有改变软件生产的本质。尤其 是，需求分

5、析与系统设计的原理和任 务仍然保持不变。最终的软件产品可 以由标准和定制的构件组装而成，但“ 组装过程”还是一门艺术。坦率地说， 我们甚至没有“备件”来替换“使用中” 的系统的残缺构件。 1.1.2投入者 投入者是那些与软件项目之间存 在利害关系的人。任何被这个软件系 统影响或者影响系统开发的人都是投 入者。其中有2种主要的投入者：l客户（用户或系统所有者）。l开发人员（分析员、设计员、程序员 等）。 我们倾向于使用术语客户而不是 用户。从系统开发的角度看，区别两 者肯定是有充分依据的。第一，客户 是给开发付钱的人，负责制定决策。 第二，即使客户有错，客户的需求也 不能由开发者任意改变或拒绝，

6、任何 矛盾的、不可行的或不合法的需求都 必须与客户再次进行协商。 信息系统是社会系统，它们由人 （开发者）为人（客户）开发，软件 项目的成功由社会因素确定，技术是 第二位的。有许多技术水平不高的系 统在为客户工作并使客户获益，反之 就不是这样，一个对客户没有任何觉 察的或真实的益处的系统将被放弃， 不管其技术上如何顶尖。 在通常情况下，软件失败的主要原 因可以追溯到投入者的因素。在客户方 面，项目失败是因为：l客户的需要被误解或没有被完全捕捉。l客户需求变化得过于频繁。l客户没有准备为项目提交足够的资源。l客户不想与开发人员合作。l客户具有不现实的期望。l系统不再对客户有利。项目还会由于开发者

7、不能胜任这 项任务而失败。随着软件复杂度的增 加，人们越发地认识到开发者的技能 和知识非常关键。好的开发者能够给 出一个好的解决方案，杰出的开发者 可以给出更好的方案，因为它更快也 更便宜。就像出自Fred Brooks的那句 著名的俏皮话：“杰出的设计来自杰出 的设计者。” 开发者的优秀和责任心是提高软件质量 和生产率的关键。为了保证软件产品能成功地 交给客户，更重要地，从中取得来自生产率提 高的效益，软件组织必须采取一些明显的涉及 开发者的措施：l雇佣最好的开发者。l为现有的开发者提供继续培训和教育的机会。l鼓励开发者之间进行信息交换和交互，使他们 互相促进。l通过消除障碍并将努力引导到生

8、产工作来激励 开发者。l提供一个令人鼓舞的工作环境。l使个人目标和组织策略及目标相一致。l强调团队工作。1.1.3过程 软件开发过程确定以促进开发小组内 部合作的活动和组织的程序，使得能交给 客户一个性能优良的产品。过程模型包括 ：l说明执行活动的次序。l说明需要交出什么样的制品，以及什么时 候交出。l将活动和制品分配给开发者。l提供监控项目进程、评估产出和计划未来 项目的准则。 开发过程无法标准化或编成法典 自动地被组织接受，每个组织必须定 义自己的过程模型或将一个通用的过 程模板客户化，如由Rational软件公司 提供的被称为Rational统一过程的那个 模板。 组织所采用的过程必须与

9、它的开发文化 、社会动力、开发人员的知识和技能、管理的 实践、客户的期望、项目的大小甚至应用领域 的种类等方面相一致。因为所有的这些因素都 是易变的，组织应为每个软件项目改变它的过 程模型并创建过程模型的一个变形。例如，根 据开发人员对建模方法和工具的熟悉程度，项 目进行过程中可能需要含有特殊的培训课程。项目的大小对过程影响可能最大。在小 项目中（10个左右开发人员），可能根本不需 要形式化的过程，这样的小组可以非形式地交 流并响应变化。而在大项目中，一个非形式化 的通信网络肯定不够，而用于控制开发的良定 的过程就是必需的了。 1.1.3过程 l1.1.3.l迭代式和增量式开发 l1.1.3.

10、2能力成熟度模型 l1.1.3.3 ISO 9000 1.1.3.1迭代式和增量式开发 现代软件开发过程总是迭代增量 的。系统模型通过分析、设计和实现 这样一些阶段得到精化和转换细 节在连续的迭代时加进去，必要时还 要进行更新和改进，而且软件模块的 增量式的版本维持了用户的满意度， 井提供对仍在开发之中的模块的重要 反馈。 就像Rational统一过程所陈述的 那样“迭代过程就是涉及管理可执行的 版本流的过程，增量过程则是涉及系 统体系结构连续集成以产生这些版本 的过程，其中每个新的版本都在其他 版本基础上嵌入了增量的改进。” 迭代式和增量式过程是否成功在 早期系统体系结构模块的识别时就能 断

11、定。这些模块应该是小规模、高度 一致而且具有最小的重叠（耦合）度 的，其中模块的执行次序也很重要。 一些模块如果它们依赖于仍在开发中 模块的信息或计算的话也许就不能执 行。迭代式和增量式开发如果不能控 制项目的实际进程就可能退化为“专门 的处理”，除非它是有计划和有控制的 。 1.1.3.2能力成熟度模型 从事软件生产的组织都面临一个重要的 挑战，即改进它的开发过程。很自然地，为 了进行过程改进，组织必须了解当前过程的 问题是什么。能力成熟度模型（CMM）是 一个流行的用于过程评估和改进的方法。CMM由美国匹兹堡的卡内基梅隆大学 的软件工程研究所（SEI）给出，起初被美 国国防部用来评估来竞标

12、国防合同的组织的 IT能力，现在已被美国和其他地方的IT业广 泛地使用。CMM基本上就是一个交给组织填 写的问卷，这个问卷后面有一个验证 和证明过程，这个过程为填表的组织 赋予CMM的五个级别中的一个级别， 级别越高，组织的过程成熟度越好。 图1-1定义了这五个级别，并附上了每 个级别主要特征的简短描述，而且指 明了当组织需要达到更高的级别时， 其过程改进的主要范围。 Arthur 称成熟度级别是“通向软 件卓越的阶梯”，这个阶梯上的 5个台 阶分别是混沌、项目管理。方法和工 具、度量和连续质量改进。经验表明 ，要按这个成熟度的尺度向上进一级 要花几年的时间，大多数组织处于第1 级，有一些达到

13、第2级，达到第5级的 寥寥无几。 下面一些问题展示了这项任务的困难：l软件质量保证功能是否有独立于软件开发 项目管理的管理报告渠道？l涉及软件开发的每个项目是否都具有软件 配置控制功能？l对那些在没有制定合同承诺的情况下的软 件开发的管理评价是采用正式的过程吗？l有正式的过程来产生软件开发日程吗？l有正式的过程来估计软件开发的成本吗？l有收集软件代码和测试错误的统计吗？l资深管理是否有一种机制作为对软件开发 项目状态的常规评价？l有一种机制用来控制软件需求的改变吗？1.1.3.3 ISO 9000 除了CMM外，还有其他的过程改 进模型，特别受到关注的是国际标准 化组织开发的关于质量标准的 I

14、SO 9000系列。 ISO标准应用到质量管理 和过程中，以生产出具有品质保证的 产品。 ISO标准是通用的，可以应用 到任何工业和所有类型的业务中，包 括软件开发。 lISO 9000标准的主要承诺是：如果过程 正确，则该过程的产出（产品或服务） 也将是令人满意的，“质量管理的目的就 是要通过按照将质量建造成产品，而不 是按照将质量试验成产品的方式，来生 产具有品质保证的产品。”l按照我们前面对过程的讨论，ISO标准 并没有强制性的或规定的过程，这些标 准提供的是关于什么是必须完成的、而 不是活动怎样执行的模型。请求ISO认 证（也称为注册）的组织必须说明它所 做的、做它所说的、演示它已经做

15、的。一个ISO认证的组织的敏感性测试即 使当它的全部劳动力都被替换了，它也应 该能够制造出具有品质的产品，或者提供 具有品质的服务。为了这个目标，这个组 织一定要记录和整理它的所有活动，并为 每个过程规定成文的步骤，包括当出现错 误时或者客户抱怨时要如何做的活动。与CMM认证一样，ISO认证只有在 ISO注册员实地检查后才能批准。这些检 查还要按一定规律的间隔重复进行。组织 被迫进入一个模式，它是通过提供客户要 求的产品和服务所确保的竞争力。1.1.4建模语言和工具 投入者和过程是成功的3个因素中的2 个。第3个因素由建模语言和一些工具组 成，为制品建模需要通信（语言）和文档 化（工具）。开发

16、人员需要一种语言来创建可视化 的和其他形式的模型，以及与客户和其他 开发人员进行的讨论。这个语言应该支持 各个抽象层次上模型的构造，以在不同程 度上详细表示所提出的解决方案。 这个语言应该具有强的可视构件，按 照流行的说法是“一幅画胜似千言万语”。 它还应该具有较强的说明语义，即它应该 支持在“描述性”语句中捕获“过程性”含义， 说出“什么”需要做而不是“怎样”去做。开发人员也需要一个CASE工具（计算 机辅助软件工程），CASE工具使得在一个 中央资源库中存储和检索模型、并在计算 机屏幕上对模型进行图形和文本的操作成 为可能。理想的情况是：资源库应该为共 享的多个用户（即多个开发者）提供模型 的存取手段。 CASE资源库的典型功能是：l模型的协同存取。l支持开发人员之间的合作。l存储模型的多种版本。l标识版本之间的区别。l允许在不同模型中共享同一个概念。l检查模型的一致性和完整性。l生成项目报告和文档。l生成数据结构和程序代码（正向工程）。l从存在的实现中产生模型（逆向工程）等 等。1.1.4建模语言和工具 ll.1.4.l统一建模语言 l1.1.4.2 CAS