软件工程需求分析.ppt_第1页
软件工程需求分析.ppt_第2页
软件工程需求分析.ppt_第3页
软件工程需求分析.ppt_第4页
软件工程需求分析.ppt_第5页
已阅读5页,还剩24页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1,一、软件工程(1):瀑布模型,瀑布模型:严格遵循软件生命周期 文档驱动 里程碑审查 启动下一阶段必须是上一阶段工作已完成,软件过程模型典型,问题定义及可行性研究需求分析架构设计概要设计详细设计编码、代码审核及单元测试集成测试部署维护,2,一、软件工程(2) :迭代模型,迭代模型:不断迭代 用例驱动、架构优先,软件过程模型典型,优先完成核心部分 不断向外扩展,可能要修正部分核心代码,但总体而言, 核心逐步稳定,并不断扩大范围 统一分析、设计、编码理念:OOA、OOD、OOP 统一建模语言:UML 采用瀑布模型:需求分析 客户确认设计 客户确认 编码单元测试集成客户确认,用例图:表示系统的功能,并支持其操作者,3,一、软件工程(3):结构化与面向对象的理念区别,理念区别:考虑问题的视角完全不同,存在交叉 问题变更可能导致系统崩溃 不支持迭代 所有问题必须事前明确 开发过程中,无法和客户确认 基本要到开发完成, 才能确定是否解决问题 很多到最后才发现需要变更 影响全局,抽象,支持迭代 核心逐步稳定并扩大 次要问题可以逐步明确 不断发布新版本,客户不断确认 不断确认变更,影响范围有限,结构化思维,OO编程语言 类识别错误 类继承错误 仍不支持迭代 无法形成稳定的核心 变更将导致全局影响,4,一、软件工程(4):解决方法,可行性研究 核心需求规格说明书、UI原型 关键是用例图、活动图 架构指导书 关键是逻辑架构图和规范 需求规格说明书迭代 详细设计说明书迭代 关键是类图、对象关系图 DB、UI 类代码及单元测试报告 集成 集成测试报告 功能测试报告QC 部署方案、维护计划,评审 评审 评审 每 日 构 建 评审,关键: 迭代,含需求迭代 类识别 核心识别 每日构建,阶段性确认 核心逐步稳定并扩大,5,一、软件工程(4):解决方法,REQ0.6,REQ0.7,REQ0.8,REQ0.9,REQ1.0,V0.6,V0.7,V0.8,V0.9,V1.0,AD0.6,AD0.7,AD0.8,AD0.9,AD1.0,QC0.6,QC0.7,QC0.8,QC0.9,QC1.0,尽快START,客户确认,6,二、可行性分析,工作内容: 进度安排/里程碑确定 人员配置、资源投入 开发环境、配置管理 项目规范、沟通管理 风险识别及规避措施,关键点: 和客户确定阶段性成果的交付、内部评审、客户评审 识别项目风险,针对技术风险和客户进行沟通 明确项目范围 去除不可行的需求或技术 对不明确需求进行调研,可行性分析的目的,使项目: 成本可行、效益可行 进度可行 资源配置可行 客户需求可行 技术要求可行、质量可行 社会环境、市场、政策可行 同时识别出项目风险,加以控制,7,三、需求分析(1):建立逻辑模型,需求规格说明书要素: 项目目标、组织架构、功能需求、性能需求、部署环境、可靠性需求、安全性要求及权限模型、UI需求、进度要求、资源投入、成本约束、边界/接口、使用者、现状,关键点: 进一步明确项目范围 去除不可行的需求或技术 对不明确需求进行调研,工作内容: 最核心问题必须明确,次要问题可以迭代 采用合适的分析工具 编制需求规格说明书,需求迭代,需求评审,需求说明书,完整、清晰:需求覆盖、描述完整 一致性:上下文无冲突,无二义性 可行性:需求可行、技术可行 接口:识别系统边界 需求覆盖 限制、假设 风险识别,目的: 目标一致 需求覆盖 通过UI原型更容易需求理解 通过UI原型更容易客户确认需求 识别、控制风险 作为项目计划的输入,8,三、需求分析(2):结构化分析方法,一般采用瀑布模型 存在交叉 问题变更可能导致系统崩溃 不支持迭代 所有问题必须事前明确 开发过程中,无法和客户确认 基本要到开发完成,才能确定是否解决问题 很多到最后才发现需要变更,影响全局,分析工具:自顶向下 数据流图DFD 场景描述 活动图、状态图、时序图 E-R图ERD 层次图HIPO 数据字典DD:属性、取值范围等 IPO图/表 UI原型 物理部署,数据字典,ER图,数据流图,时序图,9,三、需求分析(3):面向对象分析方法,支持迭代 核心逐步稳定并扩大 次要问题可以逐步明确 不断发布新版本,客户不断确认 不断确认变更,影响范围有限,分析工具:自顶向下、自底向上 用例图use case:用例模型 场景描述 状态图、活动图、时序图:动态模型,和“结构化”相同 类/对象关系图 HIPO图: 和“结构化”相同 数据字典DD:属性、取值范围等,和“结构化”相同 IPO图/表:和“结构化”相同 UI原型,有时会有技术原型:和“结构化”相同 部署图、构件图:静态模型 类图、对象图、包:静态模型,2、抽象 自顶向下,DB,1、抽象 自底向上,类识别/设计是关键,用例图,顶层用例图,包,类关系图,物理部署图,10,三、需求分析(4):面向对象分析DEMO,项目目标 项目范围 Actor及接口 组织架构图 功能图/树 功能:用例图 查询:IPO表 统计:IPO表 权限模型 数据字典DD 数据流图 场景描述 流程:活动图、时序图、状态转换图 UI原型 部署图 其他:性能需求、运行环境、可靠性需求、安全性要求、进度要求、资源投入、成本约束、现状,11,四、架构设计,表示层WEB 业务逻辑层IBLL 数据访问层IDAL 数据存储层DB,实体类Entity 公共类Utility,描述了框架和一般性规范 技术路线 物理、逻辑分布 逻辑架构及包设计 会话安全 权限设计 事务处理 日志处理 异常处理 UI框架 边界/接口 扩展性,中大型系统的架构设计尤为重要, 架构设计不合理,将导致迭代失败 应重点考虑应用扩展性、逻辑架构和分布,12,五、概要设计,类识别 类之间的联系:类图及包设计 数据存储层/数据访问层/业务逻辑层/界面层的设计 实体类/公共类的设计 数据流识别 DB,13,六、详细设计,UI设计 DB设计 各层类的伪代码及包 外部接口设计,14,七、测试&部署&维护,测试: 代码审查:技术主管、PM或程序员交叉检查 单元测试:程序员自身 集成测试:程序员自身 功能测试:QC,界面、功能正确性、需求满足度 每日构建,部署: 编制部署计划、数据迁移、部署、试用情况,维护: BUG修正、代码/界面微调,QA: 过程管控:规范、文档、质量、进度、成本等,15,八、常见困难(1):结构化思维,OO编程语言,结构化思维以功能划分作为解决问题的主线,基本上不会分析功能之间的关系, 即思考的是某项功能的实现来解决某些问题 结构化思维不存在“对象抽象”的思考过程 结构化思维中编程的先后次序是以功能优先级排序,和迭代开发的核心确定方法 和结果不一定相同 成功进行迭代开发的前提是:核心的确定,而结构化思维将导致核心偏离, 从而不真正支持迭代,交 叉,1,2,3,4,没 有 核 心,抽象失败,16,八、常见困难(2):迭代概念错误,没有找到“核心问题”,错误将“次要问题”作为核心 变更导致“核心”崩溃,错误的简单“增加”,17,八、常见困难(3):类识别错误,抽象有问题,交 叉,1,2,3,4,没 有 核 心,抽象失败,自认为技术水平高的人,简单编码,不思考的人,解决问题不完整,抽象不合理、错误,集成失败,须遵循统一的架构,18,八、常见困难(4):任务指派错误,简单的任务指派:任务没有排序,按核心级别指派:先完成核心,任务指派者要有“全局观”,19,八、常见困难(5):关键需求发生变化、关键需求不明确,不管是哪种软件开发模型 核心需求发生变化,都是灾难性的 核心需求不明确时,要尽快明确,有时可以做个较小的“技术原型”,以加速明确核心需求,由于“技术原型”较小,投入的成本不大,可以丢弃,?,STOP,20,八、常见困难(6):迭代模型下各项工作的启动次序及输出,需求说明书不断迭代 设计说明书不断迭代 程序不断迭代,V0.6,V1.0,采用瀑布模型:需求分析设计编码单元测试集成,各项工作同步启动,21,八、常见困难(7):工作量的评估,22,八、常见困难(8):客户关系、客户确认,项目经理不做客户关系:失败 各阶段不做客户确认:失败 不和客户定期沟通:失败 不和客户定期确认研发成果:失败 不重视部署能力、上线、验收、培训计划:失败,23,九、售前与销售的矛盾(1/5),销售们一味的要求售前提交技术资料、提交报价文件,但经常“无功而返” 解决之道:了解销售过程,抓住销售各阶段的工作重点,要求销售们做好关键工作,售前做好配合 STEP 1:客户项目组织 STEP 2:确认我们的位置 STEP 3:询问我们的销售计划 STEP 4:了解销售计划的执行情况, 做好售前配合,销售目标:清晰的、可度量的、时间限定性的 销售活动涉及资源投入,售前投入就是其中一种,1)对客户进行“漏斗筛选” 2)对客户“收窄”,形成压力 G+2 G+3 确认对我们的“支持”,24,九、售前与销售的矛盾(2/5),STEP 1:客户项目组织,如果: 1)销售们完全不清楚项目组织的:没有见过相关人员 售前对此项目支持的优先级可以比较低,要求销售们先和客户沟通 2)销售们没有接触过EB,要求他们尽快拜访EB,了解EB的想法 售前可以提交简单通用的技术描述,25,九、售前与销售的矛盾(3/5),STEP 2:确认我们的位置,50%,100%,0%,懂得询问:销售们判定的依据,如果EB都没有见过面,则我们的位置不能高于70%,26,九、售前与销售的矛盾(4/5),STEP 3:询问我们的销售计划,影響決策深淺,UB,TB,EB,評 分,* 熱情的擁護 - +5 * 大力的支持 - +4 * 支 持 - +3 * 有興趣 - +2 * 認知相同 - +1 * 應該不會拒絕 - - 1 * 不感興趣 - - 2 * 作負面的評價 - - 3 * 抗拒你的建議 - - 4 * 支持你的對手 - - 5,销售形态,G T EK OC,1)不同阶段,工作重点不同、投入资源的力度不同 2)不同人,不同阶段工作内容不同,不同“形态和评分”时工作内容也不同,必要时“收窄,形成压力或表态”,27,九、售前与销售的矛盾(5/5),STEP 4:了解销售计划的执行情况,做好售前配合,A94,John King,06/16/2001,Before 8/15 close. 500 PC/25 Server Router x n,Switch Rev 6.5M,New T ( - ),Wang GM Zhang Dir Li Mgr Cheng VP,T + 2 G + 2 G + 4,*,* *,*,* *,T -4,狼性 狼群:协助 勤奋 独占性:只有0和100 狠:拆竞争对手的台,销售员特质 善于询问 谈别人感兴趣的事 积极成交,尽快close 耐心 相信直觉,马上做 成败在于人,感性,待人真诚 不轻言放

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论