Java软件工程与项目案例教程(三).ppt
《Java软件工程与项目案例教程(三).ppt》由会员分享,可在线阅读,更多相关《Java软件工程与项目案例教程(三).ppt(64页珍藏版)》请在三一文库上搜索。
1、Java软件工程 与项目案例教程 (三),主要内容,1、软件需求分析概述 2、软件需求分析过程 3、项目案例,3.1 软件需求分析概述,需求分析是整个项目开发流程的第一个环节,它是在用户和软件开发组之间建立对用户的共同理解,由软件开发组进行分析、精化并详细描述后,按文档规范编写出软件需求规格说明书(Software Requirement Specification,SRS)的过程。 软件需求分析特别重要。在软件工程的历史中,很长时间里人们一直认为需求分析是整个软件工程中简单步骤,但在过去十几年中越来越多的人认识到它是整个过程中最关键的一个过程。只有通过软件需求分析,才能把软件功能和性能的总体
2、概念描述为具体的软件需求规格说明,从而奠定软件开发的基础。许多大型应用系统的失败,最后均归结到需求分析的失败:要么获取需求的方法不当,使得需求分析不到位或不彻底,导致开发者反复多次地进行需求分析,致使设计、编码、测试无法顺利进行;要么客户配合不好,导致客户对需求不确认,或客户需求不断变化,同样致使设计、编码、测试无法顺利进行。 特点: (1)用户与开发人员很难进行交流 (2)用户的需求是动态变化的 (3)系统变更的代价呈非线性增长,3.2 软件需求分析过程,3.2.1 什么是软件需求 从根本上讲,软件需求就是为了解决现实世界中的特定问题,软件必须展现的属性。 软件需求的组成关系如下图,软件需求
3、的属性包括可验证性、优先级、唯一性和定量化。 可验证性 可验证性是软件需求的基本属性。软件需求必须是可验证的,否则软件的评审和测试就没有相应的依据。 优先性 软件需求具有优先级,应该能够在有限的资源(资金、人员、技术)情况下进行取舍。 唯一性 软件需求应唯一地标识出来,以便在软件配置管理和整个软件生命周期中进行管理。 定量化 软件需求应尽可能地表述清楚,没有二义性,进行适当的量化,应避免含糊、无法测试、无法验证的需求出现。软件质量的可靠性和用户界面的友好性等非功能性需求的量化尤为重要。例如,系统应支持2000个并发用户,系统回应时间应低于10秒,这就是需求的量化。,3.2 软件需求分析过程,3
4、.2.2 需求过程中的角色如下图所示:,3.2 软件需求分析过程,3.2.3 需求过程迭代 软件需求分析是一个不断认识和逐步细化的过程。该过程将软件计划阶段所确定的软件范围(工作范围)逐步细化到可详细定义的程度,并分析出各种不同的软件元素,然后为这些元素找到可行的解决办法。需求过程要适应客户和项目的环境,并作为配置项纳入配置管理。 当前的软件业面临着巨大竞争压力,要求软件企业有更低的构建成本和更短的开发周期。有些项目受环境的影响很大,有些项目是对原有项目的升级,有些项目客户要求在指定的架构下完成。在项目初期,客户不能完全确定需要什么,对计算机的能力和限制不甚了解,所以需求过程很难是一步到位的过
5、程。随着项目的深入,需求将随时间变化而发生变化。 因此,需求过程是一个迭代的过程,每次迭代提供更高质量和更详细的软件需求。这种迭代会给项目带来一定的风险,上一次迭代的设计实现可能会因为需求不足而被推翻。但是,系统分析师应根据项目计划,在给定的资源条件下得到尽可能高质量的需求。,3.2 软件需求分析过程,3.2.4 需求的来源 (1)系统目的 (2)行业知识 (3)软件涉众 (4)运行环境 (5)组织环境 软件涉众: 应充分考虑不同软件涉众的需求,如果只强调某一角色的需求,忽略其他角色的需求,往往将导致软件系统的失败。系统分析师应从不同涉众的角度去识别、表述他们的需求。用户的文化差异、客户的组织
6、结构,常常会是系统难以正常实施的原因。,3.2 软件需求分析过程,3.2.5 需求获取的方法 (1)实地参加 (2) 开调查会 (3)请专人介绍 (4)面谈 (5)设计调查表请用户填写 (6)查阅记录,3.2 软件需求分析过程,3.2.6 软件需求的表达 如何有效地表达软件需求?我们这里建议使用用例建模技术。用例建模技术是 10 多年来最重要的需求分析技术,在保障全球各类软件的成功开发中发挥了极其重要的作用. 实践证明,用例技术是迄今为止最为深刻,准确和有效的系统功能需求描述方法. 功能需求是指系统输入到输出的映射以及它们的不同组合,任何功能必然要通过外部环境与系统之间的交互才能完成,因此,我
7、们可以在内容和形式上把用例和系统的功能需求等同起来。 用例建模技术不同于结构化功能分解的特点有: 1)显式地表达用户的任务目标层次,突出系统行为与用户利益间的关系; 2)通过描述执行实例情节(交互行为序列、正常/非正常事件流)能够完整地反映软件系统用以支持特定功能的行为; 3)以契约(前/后置条件等)的形式突出了用户和系统之间常常被忽略的背后的关系; 4)部署约束等非功能需求与系统行为直接绑定,能够更准确地表达此类需求。,3.2 软件需求分析过程,基于用例的需求表达体系如下图3-2所示 基于用例的需求表达体系,3.2 软件需求分析过程,1、用例图 (1)用例图概述 用例建模技术离不开用例图。在
8、UML中,用例图又叫做用况图,有时又称为Use Case 图。它用于定义系统的行为、展示角色(系统的外部实体,即参入者)与用例(系统执行的服务)之间的相互作用。用例图是需求和系统行为设计的高层模型,它以图形化的方式描述外部实体对系统功能的感知。用例图从用户的角度来组织需求,每个用例描述一个特定的任务,如表3-2所示。 表3-2用例图概述,3.2 软件需求分析过程,用例模型可以在不同层次上建立,具有不同的粒度。 (2)用例层次 我们把用例划分为3个目标层次:概要层,用户目标层和子功能层,并通过引入巧妙的Why/How技术帮助分析者找到合适的目标层次,从而可以有效地把握用例的粒度(真正的用例最终应
9、落实到用户目标层)。 值得注意的是,我们在实践中应该尤其关注用户目标层用例.引入概要层用例的主要目的是为了包含一个或多个用户目标层用例,为系统提供全局功能视图,提出子功能层用例则是为了表达用户目标层用例的具体实现步骤。 (3)用例范围 根据范围的不同,用例可分为业务用例和系统用例两种 1)业务用例 -在业务中执行的一系列动作,这些动作为业务的个体主角产生具有可见价值的结果 -实质是业务流程 -可以分为核心业务用例,支持业务用例,管理业务用例 -主要包括业务角色,业务活动,业务实体,业务规则 2)系统用例 -是系统执行的一系列动作,这些动作将生产特定主角可观测的结果值 -主要包括系统角色和系统的
10、一系列的交互过程,3.2 软件需求分析过程,3.2 软件需求分析过程,如果某个SuD或者用例的范围包含了人以及由人组成的团队,部门,组织的活动,那么针对这个SuD写出的用例必然是业务用例;如果该SuD仅仅是一些软件,硬件,机电设备或由它们组成的系统,并不涉及到人的业务活动,那么根据这个SuD写出来的就是系统用例。 (4)用例关系 1)角色和角色之间 -继承关系:表示子类角色将继承父类角色在用例中所能担任 的角色 2)角色和用例之间 -使用关系:表示角色将使用用例提供的服务 3)用例和用例之间 -包含关系: 通常是指一个大的用例包含了几个小的用例,几个小的用例组成一个大的用例。 -扩展关系: 基
11、于扩展点之上的两个独立用例,扩展用例为基本用例的实例增添新的行为,其实质是扩展事件流的延伸,两个用例本身都是独立的。 -继承关系: 父用例可以特化形成一个或多个子用例,这些子用例代表了父用例比较特殊的形式。子用例继承父用例的所有结构、行为和关系。,3.2 软件需求分析过程,表现几种关系的实例如下图3-3: 图3-3 用例关系实例,3.2 软件需求分析过程,2、用例描述 用例模型除了绘制用例图外,还要对用例进行描述,也就是详细展开每个用例的内容。用例描述可以是文字性的,也可以用活动图进行说明。文字性的用例描述模板如表3-3所示。以“借书登记”为例,其具体的用例描述如表3-4所示。 右表 用例描述
12、模板,3.2 软件需求分析过程,右表 借书登记用例描述,3.2 软件需求分析过程,3、用例优先级 (1)为什么要设定需求的优先级 每一个具有有限资源的软件项目必须理解所要求的特性、使用实例和功能需求的相对优先级。设定优先级意味着权衡每个需求的业务利益和它的费用,以及它所牵涉到的结构基础和对产品的未来评价。项目经理必须权衡合理的项目范围和进度安排、预算、人力资源以及质量目标的约束。 设定优先级有助于项目经理解决冲突、安排阶段性交付,并且做出必要的取舍。 当客户的期望很高、开发时间短并且资源有限时,必须尽早确定出所交付的产品应具备的最重要的功能。 建立每个功能的相对重要性有助于规划软件的构造,以最
13、少的费用提供产品的最大功能。 当采用渐增式开发方式时,设定优先级就特别重要,因为在开发过程中,交付进度安排很紧,并且日期不可改变。必须排除或推迟一些不重要的功能。 (2)系统分析员的态度和做法 在需求分析阶段,分析人员应该明确的提出需求的优先级和处理策略,并在软件需求规格说明书中明确说明。 应当在项目的早期阶段设定优先级,这有助于逐步作出相互协调的决策,而不是在最后阶段匆忙决定。,3.2 软件需求分析过程,你评价优先级时,应该看到不同需求之间的内在联系,以及它们与项目业务需求的一致性。 在判断出需求的低优先级之前,如果开发人员已经实现了将近一半的特性和功能,那这将是一种浪费,这个责任应该由分析
14、人员承担。 (3)设定优先级的方法 与在客观世界人们对事务的分类习惯与方法相一致,系统需求的优先级设定分成三类。例如: 高、中、低; 基本的、条件的、可选的、 3、2、1 。 具体描述见下表3-5:,表3-5 系统需求的优先级分类,3.3 项目案例,3.3.1 学习目标 理解软件需求分析的概念及其重要性。 掌握需求分析中的用例建模技术。 掌握软件需求的表达和软件需求规格说明书的编写。 3.3.2 案例描述 本案例体现了真实的软件需求规格说明书文档。该eGov电子政务项目文档展现了功能和非功能需求及其文档的标准格式,通过它我们可以更好地熟悉和理解软件需求的表达。 3.3.3 案例要点 在实际工作
15、中,我们需要将需求分析过程通过软件需求文档记录下来。软件需求文档虽然可以有各种不同的格式,但它的主要内容包括用例描述和界面导航图。,3.3 项目案例,3.3.4 案例实施 eGov电子政务项目需求规格说明书 1.引言 1.1 编写目的 此需求规格说明书对项目的背景、范围、验收标准和需求等信息进行说明,包括功能性需求和非功能性需求,确保对用户需求的理解一致。 预期的读者有(甲方)的需求提供者、项目负责人、相关技术人员等,北京亚思晟商务科技有限公司(乙方)的项目组成员,包括项目经理、客户经理、分析/设计/开发/测试等人员。 1.2 背景 电子政务系统是基于互联网的应用软件。在研究中心的网上能了解到
16、已公开发布的不同栏目(如新闻、通知等)的内容,各部门可以发表栏目内容(如新闻、通知等),有关负责人对需要发布的内容进行审批。其中,有的栏目(如新闻)必须经过审批才能发布,有的栏目(如通知)则不需要审批就能发布。系统管理人员对用户及其权限进行管理。,3.3 项目案例,1.3 定义 无 1.4 参考资料 电子政务系统理论和实践 2.任务概述 2.1 目标 电子政务系统是基于互联网的应用软件,通过此系统可以实现权限分配、内容管理和审核等核心业务,实现政府及事业单位组织结构和工作流程的优化重组,超越时间、空间和部门分隔的限制,建成一个精简、高效、廉洁、公平的运作模式,以便全方位地向社会提供优质、规范、
17、透明、符合国际水准的管理与服务。该软件系统是一项独立的软件,整个项目外包给北京亚思晟商务科技有限公司来开发管理。 2.2 用户的特点 本软件的最终用户为组织内的日常使用者,操作人员和维护人员有较高的教育水平和技术专长,同时使用的用户数量初步估计为几百人。,3.3 项目案例,2.3 假定和约束 假定此系统为自包含的,不过分依赖其他外部系统。本项目的开发期限为3个月。 3.需求规定 3.1 对功能的规定 整体功能用例图(Use Case Diagram),见图1。,3.3 项目案例,图1,3.3 项目案例,3.1.1 一般用户浏览的内容管理:首页显示及其他页面 首页显示是数据量最大的一页,是为所有
18、模块展示内容的部分。从该页还可以登录进入管理等后端功能模块。 如图2所示,最上面为头版头条栏目,左栏下部为职能部门通知,右栏下部为综合新闻类等,左栏上部为用户登录入口。,3.3 项目案例,图2,3.1.2 系统管理 系统管理是给系统管理人员使用的,主要包括以下功能模块:登录、栏目业务设置、栏目权限设置、用户管理设置。,3.3 项目案例,一、登录 1用例描述 (1)角色:注册用户(用户和管理员) (2)前提条件:无 (3)主事件流: 用户登录该网站的登录页面(E1); 显示登录页面信息,如用户名,密码; 输入用户名和密码,单击“登录”按钮(E2); 验证登录信息; 加载用户所拥有的权限信息,并显
19、示在页面上。 (4)异常事件流: E1:键入非法的标识符,指明错误。 E2:用户账号被管理员屏蔽,无法登录。 2用户界面图,图3,3.3 项目案例,输入正确的用户名和密码后进入系统管理的入口页面(见图4)。,图4,3.3 项目案例,二、栏目业务设置 1用例描述 (1)角色:管理员 (2)前提条件:用户必须完成登录的用例 (3)主事件流: 当用户登录该网站(E1)后,单击“栏目业务设置”链接; 进入栏目业务设置页面; 设置每个栏目的内容管理(S1)和内容审核(S2)(单击内容管理图标会更改)。 (4)分支事件流: S1:设置内容管理。 3.1.1 单击“内容管理”链接 3.1.2 内容管理和内容
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Java 软件工程 项目 案例 教程
链接地址:https://www.31doc.com/p-2775846.html