|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需求是指由项目接受的或项目产生的产品和产品构件需求，包括由组织征集的对项目的需求。有技术性的，也有非技术性的。
|
|
|
|
需求管理的目的是确保各方对需求的一致理解；管理和控制需求的变更；从需求到最终产品的双向跟踪。
|
|
|
|
|
|
需求工程是所有与需求直接相关的活动的通称，它的活动可分为两大类：需求开发和需求管理。
|
|
|
|
需求开发的目的是通过调查和分析获取用户需求并定义产品需求。
|
|
|
|
需求基线：软件项目需求开发的结果应该有项目视图和范围文档、用例文档、软件需求规格说明及相关分析模型，经评审批准，这些文档就定义了开发工作的需求基线。
|
|
|
|
|
|
.需求获取。与用户进行交流，捕捉、分析用户对目标系统的需求，提炼出符合解决问题的用户需求，产生《用户需求说明书》。
|
|
|
|
.需求分析。对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。
|
|
|
|
.需求定义。根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。
|
|
|
|
.需求验证。指开发方和用户共同对需求文档评审，经双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
|
|
|
|
需求管理和需求开发密切合作，需求开发涉及把项目关系人的需要转换成产品需求和决定如何在各个产品构件之间安排或分配需求；需求管理要收集需求的变更和变更的理由，并且维持对原有需求和所有产品及产品构件需求的双向跟踪。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
除了文本，每个功能需求应该有一些相关的信息或属性与之相联系。这些属性在它的预期功能性之外为每个需求建立了一个上下文和背景资料。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
9.3.1节从用户的观点对系统进行了用例建模，但获得了用例并不意味着分析的结束，还要对需求进行深入研究，获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信实现系统行为（动态模型）。
|
|
|
|
为了使模型独立于具体的开发语言，需要把注意力集中在概念性问题上而不是软件技术问题上，这些技术的起始点就是领域模型。领域模型又称为概念模型或域模型，也就是找到代表那些事物与概念的对象，即概念类。概念类可以从用例模型中获得灵感，经过完善将形成分析模型中的分析类。在迭代开发过程中，每一个用例对应一个类图，描述参与这个用例实现的所有概念类，用例的实现主要通过交互图来表示。
|
|
|
|
|
|
（1）发现领域对象，定义概念类。发现类的方法有很多种，其中最广泛应用的莫过于“名词动词法”。它的主要规则是从名词与名词短语中提取对象与属性；从动词与动词短语中提取操作与关联；而所有格短语通常表明名词应该是属性而不是对象。
|
|
|
|
（2）识别对象的属性。属性是描述对象静态特征的一个数据项。可以与用户进行交谈，提出问题来帮助寻找对象的属性。属性是概念类所拥有的特性，从概念建模的角度看，属性越简单越好，要保持属性的简单性，应该做到4个方面：仅定义与系统责任和系统目标有关的属性；使用简单数据类型来定义属性；不使用可由其他属性导出的属性（冗余属性）；不为对象关联定义属性。最后，要对属性加以说明，包括名称和解释、数据类型，以及其他的一些要求。
|
|
|
|
（3）识别对象的关系，包括建立类的泛化关系、对象的关联关系。理清类之间的层次关系，决定类之间的关系类型，确定关系的多重性和角色的导向性。多重性指定所在类可以实例化的对象数量（重数），即该类的多少个对象在一段特定的时间内可以与另一个类的一个对象相关联；导向性表示可以通过关联从源类导向到目标类，也就是说给定关联一端的对象就能够容易并直接地得到另一端的对象。
|
|
|
|
（4）为类添加职责。找到了反映问题域本质的主要概念类，而且还理清它们之间的协作关系之后，我们就可以为这些类添加其相应的职责。类的职责包括两个主要内容，分别是类所维护的知识、类能够执行的行为。可以使用状态图来描述系统中单个对象的行为。
|
|
|
|
（5）建立交互图。多个对象的行为通常采用对象交互来表示，UML 2.0提供的交互图有顺序图、交互概览图、通信图和定时图。每种图出于不同视点对行为有不同的表现能力，其中最常用的是顺序图，几乎可以用在任何系统的场合。顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线，其中消息是顺序图的灵魂。
|
|
|
|
：在整个开发的过程中，分析模型是不断演变的，最初的分析模型主要是围绕着领域知识进行的，对现实的事物进行建模。而后，则不断地加入设计的元素，演变成为运行于计算机上的架构和结构。其演变过程中最主要的变化体现在以下3个方面：
|
|
|
|
（1）根据鲁棒分析和交互分析的结果，补充类的属性和操作，不断地细化其内容，更细致地刻化类之间的关联关系，以便体现代码的核心。
|
|
|
|
（2）添加许多与计算机实现相关的技术类，以体现系统的实现结构。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。
|
|
|
|
建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。
|
|
|
|
作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。
|
|
|
|
如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。
|
|
|
|
（1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
|
|
|
|
（2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
|
|
|
|
（3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
|
|
|
|
另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
|
|
|
|
：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
①多媒体软件：项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
|
|
|
|
②多媒体电子出版物：策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
|
|
|
|
（1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
|
|
|
|
（2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
|
|
|
|
（3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
|
|
|
|
|
|
（5）如有必要，可开发一个原型系统以验证用户的需求。
|
|
|
|
|
|
|
|
（1）功能需求。所开发的软件必须具备什么样的功能。
|
|
|
|
（2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
|
|
|
|
（3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
|
|
|
|
|
|
需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
幻灯片视图功能为用户提供了各种适应不同使用情况的操作界面，其中包括普通视图、幻灯片浏览视图、幻灯片放映视图。当启动PowerPoint时，系统默认的是普通视图工作方式。
|
|
|
|
|
|
普通视图也称为编辑视图。在该视图工作方式下，可进行演示文稿的编辑和制作，如输入文字、绘制图形和插入图片、插入声音和视频、设置动画及切换效果、设置超链接等。普通视图有4个工作区域，如上图所示。
|
|
|
|
.大纲／幻灯片工作区：位于窗口的左侧，可通过单击“大纲”选项卡或“幻灯片”选项卡在幻灯片文本大纲或幻灯片缩略图之间切换。
|
|
|
|
.主工作区：位于窗口的中部，用于显示和编辑当前幻灯片。
|
|
|
|
.任务窗格：位于窗口的右侧，提供常用命令的窗口。主要操作包括创建新演示文稿；选择幻灯片的版式；选择设计模板、配色方案和动画方案；创建自定义动画；设置幻灯片切换等。
|
|
|
|
|
|
|
|
在该视图方式下，可以放映演示文稿中的所有幻灯片。若幻灯片添加了切换效果，则会播放出来；若为幻灯片中的对象设置了动画效果，则在放映时即可展现动画效果。设置的超链接只有在幻灯片放映视图中才有效。
|
|
|
|
|
|
在该视图方式下，可以观察演示文稿的全局并了解演示文稿的风格，还可以调整演示文稿的顺序。可以对幻灯片进行选择、复制、删除、隐藏等操作，设置幻灯片的切换效果。
|
|
|
|
|
|
|
|
|
|
|
|
|
