• 1. 目录1 需求分析是软件项目的立足之本 2 需求分析阶段的团队组织 3 需求管理 4 需求分析阶段的项目管理
  • 2. 为什么要做需求管理?一天,一家爱斯基摩人来找你帮忙做一个杯子。 要求:这个杯子在使用时要能适应北极的环境。 这家人承诺:杯子做好后会有高额的酬谢。你心里想:所谓适应北极环境。北极的地面很硬。那应该做一个结实的杯子。于是你历经千辛万苦做出了:爱斯基摩人不断摇头,决定一分钱也不付给你。最后你才知道,他们需要一个拿着不冻手的杯子。他们的真实需求是这样的:
  • 3. 为什么要做需求管理?客户不知道自己要什么 客户:塑料杯、木头杯、还是橡胶杯,我也不知道! 客户知道自己要什么,但表达不清 客户提要求:使用时要能适应北极的环境。 我们经常会对客户的要求产生错误的理解 我们的理解:他一定要一个结实的杯子!我们不能知其然,而不知其所以然。要做好需求管理。
  • 4. 什么是《需求规格说明书》?《需求规格说明书》概念 软件开发项目中用于明确定义系统需求的文档。 需求规格说明书的作用 开发者与用户间事实上的技术合同书 开发者下一步设计和编码的基础 测试验收目标系统的依据
  • 5. 功能性需求:用来描述系统所应提供的功能和服务 系统功能 输入输出 异常 非功能性需求:不直接与系统的具体功能相关的一类需求 安全性 可扩展性 响应时间《需求规格说明书》的构成
  • 6. 用例详细描述 - 格式前置条件 用例开始时会发生什么 事件流 用例执行的各个步骤 后置条件 用例结束时会发生什么
  • 7. 用例详细描述 – 示例前置条件:系统管理员登录系统 事件流: 1、系统管理员在系统菜单中选择“用户管理”时用例开始 2、系统管理员可以增加一个系统用户 3、系统管理员可以根据用户名查询系统用户 4、对于每一个用户 a)系统管理员可以查看该用户的详细信息 b)系统管理员可以为该用户分配角色 c)系统管理员可以删除该用户 循环结束。 后置条件:系统管理员执行的用户管理动作生效
  • 8. 为什么要用静态原型法?遇到下面的问题,你该怎么办? 耗时耗力地完成了系统,用户却说这根本不是他想要的? 系统完成了,可用户突然说,能不能换套系统界面? 项目开发完一半了。用户说,你说 开发完一半了,给我演示看看?静态原型法可以帮助我们避免这些问题。
  • 9. 什么是静态原型法?以少量代价快速地构造一个可执行的软件系统模型 使用户和开发人员可以 较快地确定需求
  • 10. 静态原型法的实施快速建立一套用户界面原型 体现主要的功能(操作命令的使用) 提供基本的界面风格(菜单格式、输出格式) 原型的表现工具 HTML MS Visio MS PowerPoint ...
  • 11. 需求管理小结用例详细描述中的前置条件、后置条件和事件流分别是什么含义? 在项目开发过程中使用静态原型法有什么好处? 什么是《需求规格说明书》?
  • 12. 为什么要做设计?一天,上帝来到小王的家里,请他帮忙制作两个人! 小王理解了上帝的需求,没有做设计,直接开始动手。 做到一半之后,小王发现越做越不对,然后 反复的修改,疲惫不堪… 最后期限到来,上帝来向小王要人。小王面带羞涩的 将他的工作成果拿给上帝…想象一下此时上帝的表情!
  • 13. 什么是软件设计?软件需求:系统“做什么?” 上帝要求:我要做两个人(软件系统)! 软件设计:系统“怎么做?” 人的骨架(系统框架)应该怎么做... 人的大脑(系统数据库)应该怎么做... 人的皮肤(系统界面)应该怎么做... 人的性格(系统性能)应该怎么做...设计的目标就是使所设计的系统能够被开发方 顺利地实现,并且恰如其分地满足用户的需求
  • 14. 概要设计 描绘出软件的概貌 详细设计 在概要设计的基础上再将其细化,得到一个非常接近于源代码的设计表达形式 软件设计的两个阶段软件设计详细设计概要设计
  • 15. 软件概要设计概要设计 系统设计:系统具体的技术方案,与其他系统的接口方式 系统设计需要考虑到: 硬件环境、软件环境、网络环境 用户操作水平 团队技术能力 开发时间限制 结构设计:确定程序是由哪些模块组成的,各模块分别完成什么样的功能,它们之间存在着什么样的关系概要设计的核心是系统框架设计
  • 16. 软件详细设计(1)详细设计的核心是将业务模型映射到技术模型 业务模型 技术模型 执行 select book_name from sys_book where book_no = [书籍编号] and book_status = '已预订' and book_subscribe_stu_no <> [学生借书卡编号]。如果查询到1条记录,则抛出异常,异常信息为:“图书《[图书名称]》已经被预订,不能借出。”;否则,继续处理。 学生到图书馆申请借书,图书管理员登录图书管理系统。首先, 检查这本书是否已经被预订了,如果已被预订则不能借出。
  • 17. 软件详细设计(2)详细设计还包括 实现某一功能时,具体包含哪些类、方法、类。以及类之间的关系和调用顺序 对应的界面如何展示,如何交互,界面间如何切换 核心算法的伪代码 数据库设计的工作
  • 18. 5.1 需求分析是软件项目的立足之本需求分析是整个软件项目开展工作的基础,需求分析质量的好坏,直接关系到软件项目交付成果的客户满意度,甚至整个项目的成败。 如果需求分析工作做的不扎实,无论设计阶段工作完成得如何出色、软件编码质量如何高,其结果将只会给用户带来失望,给开发者带来失败的苦恼。
  • 19. 1.软件需求在软件项目中的作用:
  • 20. 2.需求分析主要工作内容刻画出软件系统的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束条件; 建造软件体系结构,分解软件系统模块,建造软件处理的数据、界面和处理流程的设计模型; 提交需求分析说明书,形成软件项目管理过程的第一个里程碑成果。
  • 21. 3.需求分析阶段的主要任务问题分析(即如何获取需求?) 需求描述(即如何定义需求?) 需求的验证
  • 22. 这一阶段,系统分析人员应该将自己对客户需求及问题的理解与自己所拥有的软件开发经验结合起来,以便发现哪些需求是由于用户的片面理解和短期行为所提出的不合理的要求,哪些要求是由于尚未提出但拥有真正价值的潜在要求。(1)问题分析
  • 23. 以需求模型为基础,考虑问题的软件可解性,生成需求规格说明书和初步的用户手册。 需求规格说明书包含对目标系统外部行为的完整描述、需求验证标准以及用户对系统在性能、质量、对维护性等方面的要求。 用户手册则包括用户界面描述以及有关目标系统使用方法的初步构想。(2)需求描述
  • 24. (3)需求验证分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明书进行复核,以确保软件需求的全面性、精确性、一致性、可行性以及用户的认同,并使用户和软件设计人员对需求规格说明及用户手册的理解达成共识,达成对目标系统理解的一致性。一旦发现遗漏和模糊点,必须进行检查,尽快更正。
  • 25. 4.软件需求的抽象层次
  • 26. 一组完整的软件需求包含5项内容:(1)系统的输入 (2)系统的输出 (3)系统的功能 (4)系统的属性 (5)系统环境的属性
  • 27. 系统需求的描述语言 结构化语言 是对自然语言格式化,依赖于定义标准格式或模板来表达需求描述 表现能力强 易于理解 一致性约束 控制结构 图形化显示 仍然有一定 程度的二义性;细致程度欠缺 名称说明 优点 缺点 过程设计语言 PDL 源于像Java或Ada这样的程序设计语言,包含附加的、更抽象的构造来提高其表达能力 通过软件工具进行语法和语义检查 表达系统功能的能力不足 使用的符号只有具有程序设计背景的人才能理解
  • 28. 系统需求的分类 (1) 功能需求 (2)非功能需求 (3)领域需求
  • 29. 非 功 能 需 求 产品需求 可用性需求   效率需求 性能需求 空间需求 可靠性需求   可移植性需求   机构需求 交付需求   实现需求   标准需求   外部需求 互操作需求   道德需求   立法需求 隐私需求 安全性需求
  • 30. 5.需求分析一般包含4个过程(1)系统分析员和用户开展面对面的交流,记录用户提供的信息,即开展获取活动; (2)需求分析员处理从用户那里获取的信息并理解它们,把他们分成不同的类别,并将客户需求同可能的软件需求相联系,即开展分析活动; (3)系统分析人员将客户需求信息结构化,编写成文档和示意图,形成需求规格说明书; (4)组织用户代表评审文档并纠正存在的错误,完成需求的验证工作。
  • 31. 6.需求分析的工作模式需求三步法: 第一步:“访谈式” 第二步: “诱导式” 第三步: “确认式”
  • 32. 第一步:“访谈式”和具体用户方的领导层、业务层人员进行访谈式沟通,主要目的从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、硬件环境、软件环境、现有系统等具体情况,建立起良好的沟通渠道和方式。 针对具体的职能部门,最好能制定本次项目的接洽人。
  • 33. 图 需求分析第一阶段角色及工作流程用户方分析人员项目经理 支持 确认 执行 反馈 协调 协同 监督输出结果 访谈备忘录 调查结果 业务流程报告 …… 配合 请求/计划需求 分析 第一 阶段组织构架 业务流程 软硬件环境 现有的运行系统 用户的需求描述访谈、发放调查表格
  • 34. 第二步:“诱导式”是在分析人员已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等信息的基础上,结合现有的硬件、软件实现方案,做出简单的用户流程和操作界面,同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段,和用户一起探讨业务流程设计的合理性、准确性、方便性、习惯性和操作性。
  • 35. 配合 审查 执行 反馈 协调 协同 监督输出结果 访谈备忘录 调查分析报告 业务流程反馈报告 …… 确认 请求/计划需求 分析 第二 阶段用户方分析人员项目经理诱导、演示、模拟组织构架 业务流程 软硬件环境 现有的运行系统 用户的需求描述图 需求分析第二阶段角色及工作流程
  • 36. 在前两个阶段成果的基础上,进行具体的流程细化,数据项的确认阶段。 这个阶段的分析人员需要完成明确的业务流程报告、数据项描述,最好能够提供修改后的DEMO系统,并能清晰地向用户描述系统的业务流程设计目标。 用户可以通过审查业务流程报告、数据项描述以及通过操作开发方提供的DEMO系统,提出反馈意见,并对已经完成并可接受的报告、文档签字确认。第三步:“确认式”
  • 37. 配合 确认 执行 提交 协调 协同 审查输出结果 原始演示系统 调查分析报告 提议 请求/计划需求 分析 第三 阶段用户方分析人员项目经理诱导、演示、模拟业务流程报告 软件环境报告 现行系统接口报告 用户的需求描述图 需求分析第三阶段角色及工作流程
  • 38. 7.软件需求文档软件项目客户 了解软件项目能够提供的软件产品,检查软件需求是否满足需要 项目管理人员 根据需求文档制定项目的开发计划和软件过程,初步预测资源的使用 软件开发人员 理解要开发的产品及具体要开发的内容 软件测试人员 验证软件系统是否满足了预期的要求 软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系 软件发布人员 在需求文档的基础上编写用户文档,如用户手册 使用对象 需求文档的作用 软件培训人员 在需求文档的基础上编写培训材料
  • 39. 8. 需求分析阶段性成果需求分析的重要阶段性成果有: (1) 用户需求说明书 (2) 需求分析模型文档 (3) 需求规格说明书
  • 40. 《用户需求说明书》与《需求规格说明书》的主要区别1)前者主要采用自然语言来表达用户需求,其内容相对于后者而言比较粗略,不够详细。 2)后者是前者的细化,更多地采用计算机语言和图形符号来刻画需求,即将开发的软件产品的需求,产品需求是软件系统设计的直接依据。
  • 41. 软件需求规格SRS说明书作用: 内容: 大纲:
  • 42. 5.2 需求分析阶段的团队组织由于需求分析是需要开发方与用户方密切协作的一个工作阶段,所以,本阶段的团队管理包含项目参与双方团队的管理工作。
  • 43. 项目管理 委员会项目经理软件开发方项目经理用户方软件开发质量检测配置管理系统分析业务职能部技术部质量部需求分析团队组织模型
  • 44. 1.在需求分析阶段参与项目的人员及工作职责如下(1)项目经理:负责需求分析阶段项目进度的安排和控制;参与项目的各种资源调度; (2)系统分析人员:完成软件需求说明书的编制任务。 (3)程序员:完成原型系统的开发工作. (4)质量管理人员:负责组织有关人员完成对需求分析工作的质量审核需求说明书的评审工作。
  • 45. (5)配置管理人员:对于通过评审的需求说明书纳入软件的配置管理项; (6)用户方的技术人员:用户方参与项目的技术负责人员,通过与系统分析人员的沟通,确定系统的技术实现方案。要求该人员具有对需求说明书中系统技术方案的最终签字认可权; (7)用户方的业务人员:用户方参与项目的业务负责人员,经过与系统分析人员的沟通,确定未来软件系统实现的具体功能和业务模型。要求该类人员对需求说明说中的业务需求具有最终签字认可的权利.1.在需求分析阶段参与项目的人员及工作职责如下
  • 46. 把所有与需求直接相关的活动统称为“需求工程”。 需求工程的活动分为两大类:  一类属于需求开发;    需求开发的目的是:通过调查与分析,获取用户需求并定义产品需求。  另一类属于需求管理:    需求管理的目的是:在用户与开发人员方对需求有着共同理解的基础上,维护需求的完整性和一致性,并控制需求的变更5.3 需求管理
  • 47. 需求开发需求获取需求分析需求定义需求验证需求管理需求跟踪需求变更控制版本管理需求复用 需求工程需求工程结构图需求工程
  • 48. 5.3.1 需求开发 需求开发的过程有4个主要活动: 需求获取 需求分析 需求定义(规格说明) 需求验证
  • 49. 1.需求获取的主要方法需求获取是需求工程的主体。 对于所建议的软件产品,获取需求是一个从了解、理解到确定不同用户需要和限制的过程。 需求获取的困难有: (1)分析人员知识领域的缺乏 (2)用户对需求描述不清 (3)对需求理解上的偏差 (4)需求变更
  • 50. (1)基于调查的需求获取方法 (2)基于用例的需求获取方法 (3)基于原型法的需求获取方法 需求获取的方法
  • 51. (1)需求调查准备。一般围绕以下3个中心进行: 首先,要确定需求调查的内容; 其次,应当确定需求调查的方式; 最后,确定调查的时间、地点和人员等 (2)进行需求调查并记录。 (3)分析用户的需求信息并撰写《用户需求说明书》 (4)进行需求确认工作。需求调查工作流程
  • 52. 案例研究—学生管理系统 我系准备设计学生管理系统的软件,以解决日益复杂的学生管理的复杂度问题。本案例目的是实施数据库的规划设计;按照事实发现的步骤,应该如何进行呢?
  • 53. 案例说明——事实的发现与收集 1、  明确组织结构和组织工作的基本流程。 方法: 查阅组织的发展历程和历史;查阅组织的具体结构。 根据对于现在学生管理的基本情况,我们大致可以得到如下的组织结构图:
  • 54. 案例说明——事实的发现与收集2、确认组织的目的和软件的目标 方法: 与组织首席领导进行正式谈话 目的: 取得组织领导的信任,明确软件的边界 谈话对象: 系总支书记 具体内容: n      您现在设立这个软件项目的主要目的是什么? n      有哪些数据让您特别头疼?或者最占用你的日常工作时间呢? n      你希望软件可以帮助你解决哪些方面的问题?
  • 55. 案例说明——事实的发现与收集定义任务目标: 收集、存储和控制本系学生在管理过程中产生的相关数据,支持面向不同用户的学生数据查询和数据操作工作。 软件基本边界: 单机;学生个体以及学生组织管理
  • 56. 案例说明——事实的发现与收集3、  确定软件信息系统的任务目标 方法: 这个阶段重要的任务是与软件系统中所可能涉及到的人员进行引导性的对话,自由提问是这个阶段的方式。 目的: 这个阶段的目的和任务就是确定软件的操作角色和视图
  • 57. 案例说明——事实的发现与收集具体内容: (1)总支书记   通常一天里面你会做那些学生工作呢? 您需要软件系统迅速告诉您哪些事情呢? 一些日常的基本数据您是怎样获得的呢?谁来完成这些具体的事情?
  • 58. 案例说明——事实的发现与收集(2)辅导员 请描述您每天的具体工作? 你经常和哪些数据打交道?需要使用哪些类型的报告?格式我可以复印一下吗? 系里面给你的任务主要是什么?你是如何完成的?
  • 59. 案例说明——事实的发现与收集维护(录入、更新和删除)学生基本情况 维护(录入、更新和删除)宿舍卫生检查基本情况 维护(录入、更新和删除)学生第二课堂情况 维护(录入、更新和删除)学生上课情况信息 维护(录入、更新和删除)成绩信息 维护(录入、更新和删除)组织发展信息 维护(录入、更新和删除)班级活动情况信息 维护(录入、更新和删除)学会综合量化信息 实现对以下的学生信息的查询: 学生基本信息、班级基本情况、学生违纪情况、学生成绩情况、组织发展情况、学生上课情况、学生综合量化情况 得到对于软件系统的基本任务目标:
  • 60. 案例说明——事实的发现与收集4、系统的边界定义 目的: 确定软件系统的应用范围和边界以及它的主要用户的视图。(一个特定类型的软件应用视图必须支持一个特定的工作角色或者是业务范围) 方法: 在软件系统开发生命周期的这个阶段,开发人员应当和用户交流以澄清前一个阶段所获得的数据
  • 61. 案例说明——事实的发现与收集学生管理数据库的系统边界:
  • 62. 案例说明——事实的发现与收集收集数据库系统的用户视图更多的信息: 在询问中你需要密切关注以下的问题: n       数据库中具体的表应该有哪些具体类型的信息? n       特定用户经常进行什么样的操作? n       什么事务对于当前的业务操作非常重要? n       什么时候应该进行严格的事务运行机制? n       数据库的高峰期、正常期和低谷期一般是何时? n       数据库需要哪种类型的安全机制和数据库存储机制? n       是否存在只有某些用户的敏感数据? n       哪些数据需要经常做备份?需要保存哪些历史数据? n       对于数据库的网络和共享有哪些要求?
  • 63. 案例说明——事实的发现与收集经过调研,得到以下的数据库用户的视图: 总支书记: l       查询所有的班级信息, l       查询所有的学生个人信息, l       查询所有的成绩信息, l       查询所有的考勤、宿舍卫生、奖励和惩罚, l       查询所有的学生组织培养信息 l       查询各种统计数据和量化考核数据
  • 64. 案例说明——事实的发现与收集辅导员: l 检索、维护(录入、更新和删除)给定班级的数据 l 检索、维护(录入、更新和删除)给定班级的学生数据 l 检索、维护(录入、更新和删除)给定班级的学生考勤数据 l 检索、维护(录入、更新和删除)给定班级的学生宿舍卫生、奖励和惩罚数据 学生: 检索个人考试、考勤、宿舍卫生、组织培养情况、 个人量化考核、 维护个人的登陆信息、检索班级信息以及相关的统计信息 普通用户: l 检索班级信息以及相关的统计信息
  • 65. 案例说明——事实的发现与收集5、软件系统的事实调查说明书 作为软件信息系统的说明书,应该详细描述以下的具体内容(仅仅涉及到事实调查的情况,不应该涉及到软件的理论设计):      数据库初始化大小     数据库增长速度及日志文件增长     记录查找的类型和主要使用 系统表     网络和数据共享需求     性能     安全性     备份和恢复     用户界面     合法问题
  • 66. 案例说明——事实的发现与收集一、软件系统的大小 u     我系在校学生1800人,分布于52个自然班级中;每个班级平均学生35——45人; u     现在有辅导员8人; u     平均每班级有学生干部12人; 二、 软件用户的增长速度 u     一般而言,每个学期将会有5名学生退学或者休学;每月的注册人数不会超过学生人数的上限
  • 67. 案例说明——事实的发现与收集三、 软件信息使用频度 u     查询班级情况,每天25次; u     查询学生基本情况,每天800次 u     查询学生相关情况,每天1200次 四、网络和共享访问需求 u     辅导员办公室必须安全的与总支书记办公室的软件应用服务器相连; u     系统必须支持同时100人在线访问;
  • 68. 案例说明——事实的发现与收集五、性能 u     每天上班时间要求单个记录查询时间在1秒; 高峰期为5秒; 六、安全性 u     数据库必须有口令保护 u     每个用户必须根据身份分配到一个特定的用户视图的 数据库访问权限,主要包括:总支书记、辅导员、 学生、普通用户 七、备份和恢复 数据库设定在每周六半夜12点进行自动备份
  • 69. 5.3.2 结构化的分析方法——数据流与数据字典 主要学习结构化程序设计的基本设计思路: 数据流 数据字典
  • 70. 一、数据流图1、定义 (DFD,Data Flow Diagram) 描述逻辑模型的图形工具,表示数据在系统内的变化,描绘信息在系统中流动和处理的情况。 2、作用: 分析MIS在运行过程中数据的流动变化以及软件应该处理的方式。
  • 71. 3. DFD的主要符号表示区别: 数据存储是处于静态的数据,包括基本表、视图和存储过程。数据流是处理动态中的数据。 注意: 通常数据流图中忽略出错的处理,通常也不包括具体的内部数据处理。数据流图的绘制基本思想就是描画“做什么”,而千万不要考虑“怎么做”。
  • 72. 4. DFD的主要处理步骤第四步:最后考虑数据流和数据的存储。第一步:从问题描述中提取数据流图的四种成分。第二步:首先考虑数据的起点和终点;第三步:接下来考虑数据的处理;
  • 73. 5. 功能建模和信息流 基于 计算机 的系统输入信息信息流模型输出信息外部实体外部实体外部实体输入信息外部实体外部实体输出信息输出信息
  • 74. 人事工资管理系统的顶层DFD(概图)范例人 事 部 门人事工资 管理系统会 计 部 门职工出缺勤报表 职工出缺勤信息职工工资信息职工工资报表职 工职工基本信息 职工工资单
  • 75. 职工基本 信息管理 子系统1.0人 事 部 门会 计 部 门职 工职工出缺勤信息职工基本信息职工工资信息3.0职工出缺 勤管理 子系统2.0职工工资管理子系统职工出缺勤报表职工出缺勤信息职工工资信息职工工资报表职工基本信息职工工资单人事工资管理系统0层DFD范例
  • 76. 建立职工 出缺勤信息3.1职工出缺勤信息职工基本信息职工 出缺勤报表职工 出缺勤信息人事工资管理系统1层DFD:加工3.0的分解图3.2制作职工出缺勤信息 统计表
  • 77. 外部实体数据流过程(加工)数据存储条目查 询请求查询可用条目1客户目录产品条目库存条目可用条目查询结果目的地响应来源触发器动作DFD的主要元素
  • 78. 二、数据流图定义及基本组成分析(一)数据流图定义: 就是组织中信息运动的抽象,是管理信息系统模型的主要形式。它与对系统的物理描述无关,只是用一种图形及与此相关的注释来表示系统的逻辑功能,即所开发的系统在管理信息处理方面要做什么。
  • 79. (4)数据流:与所描述系统信息处理功能有关的各类信息的载体,是各加工环节进行处理和输出的数据集合。(二)数据流图由四种基本成分组成(1)外部项(外部实体):外部项在数据流图中表示所描述系统的数据来源和去处的各种实体或工作环节。这些实体或环节向所开发的系统发出或接收信息。系统开发不能改变这些外部项本身的结构和固有属性。(2)加工(数据加工):又称数据处理逻辑,描述系统对信息进行处理的逻辑功能。(3)数据存储:逻辑意义上的数据存储环节,即系统信息处理功能需要的,不考虑存储物理介质和技术手段的数据存储环节。二、数据流图定义及基本组成分析
  • 80. 三.绘制数据流图的主要原则 (5)数据流图绘制过程,就是系统的逻辑模型的形成过程,必须始终与用户密切接触。(1)明确系统界面,一张数据流图表示某个子系统或某个系统的逻辑模型。(2)自顶向下逐层扩展。在调查研究的基础上,明确所描述的系统与各部实体的信息联系。绘出最高层的数据流图——关联图。在关联图中,所描述的系统当作一个数据加工项,着重描述系统与外部实体的联系。然后确定系统的几个主要的综合性的逻辑功能,绘制顶层数据流图。其中每个逻辑功能由一个数据加工符号描述。顶图可进一步分解,其中某些或者所有的数据加工项可分解为数个数据加工项,这样就形成第一层数据流图。依次逐层向下扩展,直到最底层的数据流图表示了所有具体的数据加工功能和输入输出关系。(3)合理布局。数据流图各种符号买布局合理,分布均匀、整齐、清晰,使读者一目了然。 (4)数据流图只反映数据流向,数据加工和逻辑意义上的数据存储。
  • 81. 四.绘制数据流图的主要步骤(5)重复步骤(4),直到逐层分解结束。 分解结束的标志是:对于每一个最底层的加工,即各层数据流图中不做进一步分解的加工,其逻辑功能已足够简单、明确和具体。(1)确定所开发系统的外部项(外部实体),即系统的数据来源和去处。(2)确定整个系统的输出数据流和输入数据流,把系统作为一个加工环节,画出关联图。一般应把数据来源置于图的左侧,数据去处置于国的右侧。(3)确定系统的主要信息处理功能,按此将整个系统分解成几个加工环节(子系统)。(4)根据自须向下,逐层分解的原则,对上层图中全部或加工环节进行分解。
  • 82. 四.绘制数据流图的主要步骤(9)将正规的数据流图提交系统分析负责人复审。(6)对某图进行检查和合理布局,主要检查分解是否恰当、彻底,DFD中各成分是否有遗漏、重复、冲突之处,各层DFD及同层DFD之间关系是否正确及命名、编号是否确切、合理等。对错误与不当之处进行修改。(7)和用户进行交流,在用户完全理解数据图内容的基础上征求用户的意见。(8)用计算机或其它制图,编辑工具画出正规的数据流图。
  • 83. 五.绘制数据流图的几点注释(4)命名。数据流图上的成分一般都要命名,命名的原则为:(l)关于自顶向下,逐层分解。数据流图的绘制过程,是系统分析过程的重要组成部分,这一过程自顶向下,逐层分解,就是由系统外部至系统内部,由总体到局部、由抽象到具体的系统逻辑模型建立过程。在数据流图分解中,要保持各层成分的完整性与一致性。(2)数据流必须通过加工,即送去加工或从加工环节发出。不通过加工环节的数据流不在数据流图上表示。(3)数据存储环节一般作为数据库与软件结合的界面来安排。①名称要反映被命名成分的真实和全部的意义;②名称要意义明确,易理解,无歧义,不会造成错觉和混乱;③加工的名称一般以(动词十宾语)或(名词性定语十动名词)为宜,以明确反映信息处理的逻辑功能;④避免使用不反映实际内容的空洞词汇;⑤进出数据存储环节的数据流如内容和存储者的数据相同,可采用同一名称。
  • 84. 五.绘制数据流图的几点注释 同样,下层图上的数据流或数据存储是由上层图的某个成分的分解而得,则父项与子项的编号要体现数据流图分解的完整性与一致性的原则。(5)编号 每个数据加工环节和每张数据流图都要编号。按逐层分解的原则,父图与子图的编号要有一致性,一般子图的图号是父图上对应加工的编号。如顶层图的图号为0,其中各加工环节按1,2,3编号,顺序编号,1号加工环节分解后的子加工技1.l,1.2,1.3……,编号,依次类推。 数据流与数据存储环节也要进行编号以便于编写,分析与维护。编号方法原则上与加工环节的编号方法相同。为避免混淆,可在数据流与数据存储编号的第一位数字前冠以不同的字符以示区别。如数据流符号冠以F,数据存储符号冠以D。
  • 85. 五.绘制数据流图的几点注释 (7)数据流图的局限性 数据流图从总体上描述系统的逻辑功能,系统内各部分的信息联系及与系统外各有关事物的联系,反映系统中信息运动的规律,是系统逻辑模型的主要描述形式。数据流图清晰,明了,容易理解,使人对描述系统的逻辑功能和各部分的数据联系有一目了然的感觉,便于交流。但数据流图在描述系统逻辑功能和有关信息内容的细节方面仍存在较大的局限性。如:①难以在数据流图上标志出数据流,数据存储和加工以及外部项的具体内容;②不能反映系统中的决策与控制过程;③难以对系统中人机交互过程以及信息的反馈与循环处理进行描述。(6)只画所描述的系统稳定工作情况下的数据流图。数据流图不描述系统启动时或结束工作时功能和数据流运动规律处于变动状态的情况。
  • 86. 分层DFD实例(1)对考生送来的报名单进行检查; (2)对合格的报名单编好准考证号后将准考证送给考生,并将汇总后的考生名单送给阅卷站; (3)对阅卷站送来的成绩单进行检查,并根据考试中心制定的合格标准审定合格者; (4)制作考生通知单(含成绩及合格/不合格标志)送给考生; (5)按地区进行成绩分类统计和试题难度分析,产生统计分析表。一个简单的考务处理系统功能描述:
  • 87. 顶层数据流图考 生考务 处理系统考 试 中 心阅卷站不合格报名单报名单准考证考生通知单成 绩 清 单合格标准错误成绩 清单考生名 单统计分析表
  • 88. 报名单考生通知单0层数据流图考生名册准考证不合格 报名单考生名 单成统计分析表绩清单合 格 标 准成绩清单错误登记 报名单1统计成绩2
  • 89. 一层数据流图 (a)报名单考生名册考生名单不合格 报名单合格 报名单准考证检查 报名单1.1编准考证号1.2登记 考生1.3
  • 90. 一层数据流图 (b)检查 成绩清单2.1审定 合格者2.2正确 成绩清单制作 通知单2.3分析 试题难度2.5考生 通知单合格 标准难度 分析表分类 统计表考生名册分析 统计成绩2.4成绩清单错误 成绩清单试题得分清单经审定的 成绩清单
  • 91. S2132.22.12.33.13.2 顶层 (不编号)0层1层
  • 92. 案例2:图书馆在线系统顶层数据流图 查询注册信息图书分类标准新书入库 查 询 图书馆在线系统 管理员 读 者下载图书分类标准
  • 93. 一层数据流图 分类信息下载请求注册信息在馆图书数据库查询读者信息请求1. 图书分类2. 下 载3. 查 询查询在馆图书信息请求查询新书请求读者信息库4. 读者注册返回信息图书分类标准新购图书
  • 94. 二层数据流图 图书信息图书信息按入库时间查询按作者查询请求按书名查询请求按类别查询请求查询请求3.查询子图3.1查询方式检验3.2 在馆图书查询3.3 新品图书查询3.4 读者信息查询按作者名查询请求读者信息查询请求读者信息库读者信息在馆图书数据库
  • 95. 二层数据流图读者库修改的读者信息删除的读者编号读者信息录入修改读者信息请求删除读者信息请求编辑读者信息请求4.读者注册子图 4.1编辑类型检验4.2添加读者信息4.3删除读者信息4.4修改读者信息
  • 96. 三层数据流图图书信息图书信息图书信息书 名作者名按作者按书名图书类别按类别3.2.1查询方式检验3.2.2按类别查询3.2.3按书名查询3.2.4按作者查询3.2在馆图书查询子图 查询请求在馆图书数据库
  • 97. DFD可以用来表示一个系统或软件在任何层次上的抽象。 较大型软件系统DFD分成多层(子图、父图概念),可以表示数据流和功能的进一步的细节。小结:
  • 98. 二.数据字典 (DD,DataDictionary) DD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义,使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解。
  • 99. 数据字典的作用 DFD中的数据流、数据存储表示某个有组织的数据集合,它们要由SA的其他描述工具-需求字典(数据字典)来描述,包括: 词条描述 数据流描述 加工逻辑说明
  • 100. 数据字典的主要内容和基本要求1.数据词典描述的主要内容有:数据结构、数据流、数据元素、数据存储、加工外部项,其中数据元素组成和数据流的解释是基本成分。 2.编写数据词典的基本要求 (l)对数据流图上各种成分的定义必须明确,易理解、唯一。 (2)命令、编号与数据流图一致,必要时可增加编码,方便查询检索,维护和统计报表。 (3)符合一致性与完整性的要求,对数据流图上的成分定义与说明无遗漏项。 (4)格式规范,风格统一,文字精炼,数字与符号正确。 注意数据字典中数据结构、数据流、数据存储可以直接抽象出来话ER图
  • 101. 第一部分:词条描述中使用的符号 操作符 含义描述 = 定义为 + 与(顺序结构) {...} 重复(循环结构) 〔..|..〕 或(选择结构) 〔.. , .. 〕 ( ... ) 任选 m..n 界域 *...,* 注释符
  • 102. 限制重复次数举例:{ 35 或53{ }表示允许重复3-5次{ }33 或33{ }表示恰好重复 3 次{ }{ }{ }1表示至少出现 1 次表示允许重复0至任意次
  • 103. F1:航班信息文件={航空公司名称+航班号 +起点+终点+日期 +起飞时间+降落时间} 航空公司名称=2{字母}4 航班号=3{十进制数字}3 字母=“A”…“Z” 十进制数字=“0”…“9” 起点=终点=1{汉字}10 起飞时间=降落时间=时+分 时=“00”…“23”  分=“00”…“59” 日期=年+月+日 年=[2000|2001|2002|2004] 月=“01”…“12”  日=“01”…“31”
  • 104. 重复项:起点=终点=1{汉字}10 航空公司名称=2{字母}4 航班号=3{十进制数字}3 组合项:日期=年+月+日 起飞时间=降落时间=时+分 选择项:年=[2000|2001|2002|2004] 原数据项:字母=“A”…“Z” 十进制数字=“0”…“9” 时=“00”…“23”  分=“00”…“59” 月=“01”…“12”  日=“01”…“31”
  • 105. 存折=户名+所号+帐号+开户日期+性质 +(印密)+1{存取行}50 户名=2{字母}24 所号=“001”..“999” (注:储蓄所编码,规定三位数字) 帐号=“00000001”..“99999999” (注:帐号规定由八位数字组成) 开户日期=年+月+日 性质=“1”..“6” (注:“1”表示普通户,“5”表示工资户等) 印密=“0”(注:印密在存折上不显示) 存取行=日期+(摘要)+指出+存入+余额 +操作+复核
  • 106. 年=[2001|2002|2003|2004] 月=“01”..“12”  日=“01”..“31” 摘要=1{字母}4(注:表明该存取是存?是取? 还是换?) 支出=金额(注:金额规定不超过9999999.99元) 存入=金额 余额=金额  金额=“0000000.01”..“9999999.99” 操作=“00001”..“99999” 复核=“00001”..“99999” 字母=[“a”..“z”|“A”..“Z”
  • 107. 第二部分:数据流条目给出DFD中某个数据流的定义, 通常包括: 数据流标识 数据流来源 数据流去向 数据流的数据组成 流动属性描述:频率、数据量
  • 108. 购 书 单发票领书单审查并 开发票开领 书单无效书单学生12各班学生 用 书 表举例:学生教材存量表
  • 109. 数据流条目说明举例数据流名:发票 别名: 无 简述: 学生购书时填写的项目 来源: 学生 去向: 加工1“审查并开发票” 组成: (学号)+姓名+{书号+数量} 数据流量:1000次/周 高峰值:开学期间1000次/天
  • 110. 数据流条目(数据存储说明)对某个文件的定义,包括: 文件名 描述 数据结构 数据存储方式 关键码 存取频率和数据量 安全性要求
  • 111. 数据存储条目说明举例文件名:库存记录 别名: 无 简述:存放库存所有可供货物的信息 组成:货物名称+编号+生产厂家 +单价+库存量 组织方式:索引文件,以货物编号为 关键字 查询要求:要求能够立即查询
  • 112. 数据项条目(数据元素词条)不可再分解的数据单位,包括: 名称 描述 数据类型 长度(精度) 取值范围及缺省值 计量单位 相关数据元素及数据结构
  • 113. 数据项条目说明举例数据项名:货物编号 别名:G-No,G-num 简述:本公司的所有货物的编号 类型:字符串 长度:10 取值范围及含义: 第1位:[J|G] (进口/国产) 第2∼4位:LB01.. LB29 (类别) 第5∼7位:“A00”..“A99” (规格) 第8∼10位:“001”..“999”(品名编号)
  • 114. 购书单缺书单销售采购12第二层DFD(0层) 教材购销系统 教材存量表学 生F1缺书登记表F2书库 保 管 员进书通知教材入 库信息领书单
  • 115. 第三部分:加工条目(加工逻辑说明) 加工类条目即数据处理描述,也称为小说明。描述实现加工的策略而不是实现加工的细节。 小说明可认为是DD的组成部分。也可在DD中只定义说明每个加工的组成(每个处理分解成多少小处理),而在小说明中详细描述它的处理逻辑.用以下三种工具: 过程描述语言(PDL—Procedural Description Language) 判定表 判定树
  • 116. 第三部分:加工条目(加工逻辑说明)用以下三种工具: 过程描述语言(PDL—Procedural Description Language) 判定表 判定树 层次方框图 Warnier图 IPO图
  • 117. (1)过程描述语言介于自然语言和形式语言之间的一种半形式语言,使用有限的词汇和有限的语句来描述加工逻辑。 它的结构可分成两层: 外层:用来描述控制结构,采用顺序、选择、重复三种基本结构。 内层:一般采用祈使语句的自然语言短语,使用数据字典中的名词和有限的自定义词
  • 118. 处理名:核实订票处理(MHGP3200MD) 编号: 3.2 激活条件:收到取订票信息 处理逻辑:1 读订票旅客信息文件 2 搜索此文件中是否有与输入信息中姓名及身份证号相符的项 IF 有 THEN 判断余项是否与文件中信息相符 IF 是 THEN 输出已订票信息 ELSE 输出未订票信息 ELSE 输出未订票信息 执行频率: 实时
  • 119. (2)判定表例如:某数据流图中有一个“确定保险类别”的加工,指的是申请汽车驾驶保险时,要根据申请者的情况确定不同的保险类别。 加工逻辑为: 如果申请者的年龄在21岁以下,要额外收费; 如果申请者是21岁以上并是26岁以上的女性,适用于A类保险; 如果申请者是26岁以下的已婚男性,或者26岁以上的男性,适用于B类保险; 如果申请者是21岁以下的女性或26岁以下的单身男性适用于C类保险; 除此之外的其他申请者都适用于A类保险。
  • 120. (2)判定表提取问题中的条件:年龄、性别、婚姻。 标出条件的取值条件名取值符号取值数m年龄年龄≤21 21<年龄<26 年龄≥26C Y Lm1=3性别男 女M Fm2=2婚姻未婚 已婚S Em3=2
  • 121. (2)判定表计算所有条件的组合数N。N= =3×2×2 提取可能争取的动作或措施。适用于A类保险、B类保险、C类保险,额外收费共四种。 制作判定表 完善判定表 缺少判定采取的动作 有冗余的列
  • 122. 制作判定表123456789101112年龄CCCCYYYYLLLL性别FFMMFFMMFFMM婚姻SESESESE SESEA类保险√√√√B类保险√√√√C类保险√√√√额外收费√√√√
  • 123. 合并后的判定表134578911年龄CCCYYYLL性别FMMFMMFM婚姻--SE--SE----A类保险√√B类保险√√√C类保险√√√额外保险√√√
  • 124. (3)判定树判定树是判定表的变形,一般情况下它比判定表更直观,且易于理解和使用年龄>21未婚—C类保险且额外收费已婚—B类保险且额外收费未婚—C类保险已婚—D类保险年龄≤21C类保险收额外收费A类保险B类保险21<年龄≤26年龄>26年龄≤21确保保险类别男性女性
  • 125. (4)层次方框图 层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框,它代表完整的数据结构,下面的各层矩形框代表这个数据的子集,最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。
  • 126. (4)层次方框图 例如,描绘一家计算机公司全部产品的数据结构可以用图中的层次方框图表示。这家公司的产品由硬件、软件和服务三类产品组成,软件产品又分为系统软件和应用软件,系统软件又进一步分为操作系统、编译程序和软件工具……。
  • 127. (5) Warnier图 用Warnier图可以表明信息的逻辑组织 软件产品系统软件应用软件操作系统(P1) 编译程序(P2) 软件工具编译程序(P3) 测试驱动程序(P4) 设计辅助工具(P5)
  • 128. (6) IPO图 IPO图是输入/处理/输出图的简称 ,它的基本形式是在左边的框中列出有关的输入数据,在中间的框内列出主要的处理,在右边的框内列出产生的输出数据 图 IPO图的一个例子 图 改进的IPO图
  • 129. 第三部分:PowerDesignerPowerDesigner 简介 PowerDesigner 是 Sybase 公司的 CASE 工具集,使用它可以方便地对管理信息系统进行分析设计,它几乎包括了数据库模型设计的全过程。利用 PowerDesigner 可以制作数据流程图、概念数据模型、物理数据模型,可以生成多种客户端开发工具的应用程序,还可为数据 仓库制作结构模型,也能对团队设计模型进行控制。 PD,Rose,Visio 的比较 ROSE 一般用来构件系统模型,很好用。 PowerDesigner 用来建立数据库模型。 Visio 画流程图和界面还是不错的,至于数据库建模和软件建模;呵呵,还是不好用。第一节、 PowerDesigner介绍
  • 130. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍PowerDesigner 的 4 种模型文件:    概念数据模型 (CDM) 物理数据模型 (PDM) 面向对象模型 (OOM) 业务程序模型 (BPM)
  • 131. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍
  • 132. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍一、业务程序模型 (BPM-business process model) BPM 是从业务合伙人的观点来看业务逻辑和规则的概念模型,使用一个图表描述程序,流程,信息和合作协议之间的交互作用。
  • 133. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍二、概念数据模型 (CDM-conceptual data model) CDM 表现数据库的全部逻辑的结构,与任何的软件或数据储藏结构无关。一个概念模型经常包括在物理数据库中仍然不实现的数据对象。 它给运行计划或业务活动的数据一个正式表现方式。
  • 134. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍三、物理数据模型 (PDM) PDM 叙述数据库的物理实现。 在PDM图形设计中 ,你可以真实的设计物理实现的每个细节。 这一环节,允许对具体的数据库应用团见进行涉及和规划实现,同时也可以进行逆向工程,实现对已有的数据库进行重新规划设计。
  • 135. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍四、面向对象模型 (OOM) 一个 OOM 包含一系列包,类,接口 和他们的关系。 这些对象一起形成所有( 或部份) 软件系统的逻辑的设计视图的类结构。 一个 OOM 本质上是软件 系统的一个静态的概念模型。
  • 136. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍 CDM、PDM 和 OOM 之间的关系
  • 137. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍五、使用 PowerDesigner 环境
  • 138. 第四部分:PowerDesigner 第一节、 PowerDesigner介绍五、使用 PowerDesigner 环境
  • 139. 第四部分:PowerDesigner 第二节、 业务处理模型
  • 140. 第四部分:PowerDesigner 第二节、 业务处理模型0层模型绘制图形
  • 141. 第四部分:PowerDesigner 第二节、 业务处理模型第一步:绘制基本起始点和处理模块第二步: 对数据流 进行定义。1层模型绘制图形
  • 142. 第四部分:PowerDesigner 第二节、 业务处理模型1层模型绘制图形