《软件工程需求分析精.ppt》由会员分享,可在线阅读,更多相关《软件工程需求分析精.ppt(29页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件工程需求分析第1页,本讲稿共29页2一、软件工程(一、软件工程(2 2):迭代模型:迭代模型迭代模型:不断迭代 用例驱动、架构优先软件过程模型典型优先完成核心部分不断向外扩展,可能要修正部分核心代码,但总体而言,核心逐步稳定,并不断扩大范围统一分析、设计、编码理念:OOA、OOD、OOP统一建模语言:UML采用瀑布模型:需求分析 客户确认设计 客户确认 编码单元测试集成客户确认用例图:表示系统的功能,并支持其操作者第2页,本讲稿共29页3一、软件工程(一、软件工程(3 3):结构化与面向对象的理念区别):结构化与面向对象的理念区别理念区别:考虑问题的视角完全不同问题1问题2问题3问题4 解
2、决问题1解决问题2解决问题3简单映射简单演进存在交叉问题变更可能导致系统崩溃不支持迭代所有问题必须事前明确开发过程中,无法和客户确认基本要到开发完成,才能确定是否解决问题很多到最后才发现需要变更 影响全局抽象支持迭代核心逐步稳定并扩大次要问题可以逐步明确不断发布新版本,客户不断确认不断确认变更,影响范围有限结构化思维,OO编程语言类识别错误类继承错误仍不支持迭代无法形成稳定的核心变更将导致全局影响第3页,本讲稿共29页4一、软件工程(一、软件工程(4 4):解决方法):解决方法问题定义及可行性研究核心需求分析OOA架构指导关键需求1关键需求2次要需求N设计,客户确认编码集成集成测试设计,客户确
3、认编码集成集成测试设计,客户确认编码集成集成测试功能测试部署、维护 可行性研究核心需求规格说明书、UI原型关键是用例图、活动图架构指导书关键是逻辑架构图和规范需求规格说明书迭代详细设计说明书迭代关键是类图、对象关系图DB、UI类代码及单元测试报告集成集成测试报告功能测试报告QC部署方案、维护计划评审评审评审每日构建评审关键:迭代,含需求迭代 类识别 核心识别 每日构建,阶段性确认 核心逐步稳定并扩大第4页,本讲稿共29页5一、软件工程(一、软件工程(4 4):解决方法):解决方法SAADDEVQCQAPMREQ0.6REQ0.7REQ0.8REQ0.9REQ1.0V0.6V0.7V0.8V0.
4、9V1.0AD0.6AD0.7AD0.8AD0.9AD1.0QC0.6QC0.7QC0.8QC0.9QC1.0尽快START客户确认第5页,本讲稿共29页6二、可行性分析二、可行性分析工作内容:v进度安排/里程碑确定v人员配置、资源投入v开发环境、配置管理v项目规范、沟通管理v风险识别及规避措施关键点:v和客户确定阶段性成果的交付、内部评审、客户评审v识别项目风险,针对技术风险和客户进行沟通v明确项目范围v去除不可行的需求或技术v对不明确需求进行调研可行性分析的目的,使项目:v成本可行、效益可行v进度可行v资源配置可行v客户需求可行v技术要求可行、质量可行v社会环境、市场、政策可行v同时识别出
5、项目风险,加以控制第6页,本讲稿共29页7三、需求分析(三、需求分析(1 1):建立逻辑模型):建立逻辑模型需求规格说明书要素:项目目标、组织架构、功能需求、性能需求、部署环境、可靠性需求、安全性要求及权限模型、UI需求、进度要求、资源投入、成本约束、边界/接口、使用者、现状关键点:v进一步明确项目范围v去除不可行的需求或技术v对不明确需求进行调研工作内容:v最核心问题必须明确,次要问题可以迭代v采用合适的分析工具v编制需求规格说明书需求迭代需求评审需求说明书完整、清晰:需求覆盖、描述完整一致性:上下文无冲突,无二义性可行性:需求可行、技术可行接口:识别系统边界需求覆盖限制、假设风险识别目的:
6、目标一致 需求覆盖 通过UI原型更容易需求理解 通过UI原型更容易客户确认需求 识别、控制风险 作为项目计划的输入需求调研:收集、细化需求分析:原型、优化需求评审、客户确认:改进、认同第7页,本讲稿共29页8三、需求分析(三、需求分析(2 2):结构化分析方法):结构化分析方法问题1问题2问题3问题4v v v v解决问题1v解决问题2v解决问题3v简单映射vIPO表v一般采用瀑布模型v存在交叉v问题变更可能导致系统崩溃v不支持迭代v所有问题必须事前明确v开发过程中,无法和客户确认v基本要到开发完成,才能确定是否解决问题v很多到最后才发现需要变更,影响全局分析工具:自顶向下 数据流图DFD 场
7、景描述 活动图、状态图、时序图 E-R图ERD 层次图HIPO 数据字典DD:属性、取值范围等 IPO图/表 UI原型 物理部署层次图HIPO数据字典ER图1:1M:N1:N数据流图时序图活动图第8页,本讲稿共29页9三、需求分析(三、需求分析(3 3):面向对象分析方法):面向对象分析方法问题1问题2问题3问题4v支持迭代v核心逐步稳定并扩大v次要问题可以逐步明确v不断发布新版本,客户不断确认v不断确认变更,影响范围有限分析工具:自顶向下、自底向上 用例图use case:用例模型 场景描述 状态图、活动图、时序图:动态模型,和“结构化”相同 类/对象关系图 HIPO图:和“结构化”相同 数
8、据字典DD:属性、取值范围等,和“结构化”相同 IPO图/表:和“结构化”相同 UI原型,有时会有技术原型:和“结构化”相同 部署图、构件图:静态模型 类图、对象图、包:静态模型2、抽象自顶向下 DB1、抽象自底向上类识别/设计是关键低耦合:不要逻辑耦合类类高内聚用例图顶层用例图包类关系图物理部署图第9页,本讲稿共29页10三、需求分析(三、需求分析(4 4):面向对象分析):面向对象分析DEMODEMO项目目标项目范围Actor及接口组织架构图功能图/树功能:用例图查询:IPO表统计:IPO表权限模型数据字典DD数据流图场景描述流程:活动图、时序图、状态转换图UI原型部署图其他:性能需求、运
9、行环境、可靠性需求、安全性要求、进度要求、资源投入、成本约束、现状第10页,本讲稿共29页11四、架构设计四、架构设计v表示层WEBv业务逻辑层IBLLv数据访问层IDALv数据存储层DB实体类Entity公共类Utility描述了框架和一般性规范v技术路线v物理、逻辑分布v逻辑架构及包设计v会话安全v权限设计v事务处理v日志处理v异常处理vUI框架v边界/接口v扩展性中大型系统的架构设计尤为重要,中大型系统的架构设计尤为重要,架构设计不合理,将导致迭代失败架构设计不合理,将导致迭代失败应重点考虑应用扩展性、逻辑架构和分布应重点考虑应用扩展性、逻辑架构和分布第11页,本讲稿共29页12五、概要
10、设计五、概要设计v类识别v类之间的联系:类图及包设计v数据存储层/数据访问层/业务逻辑层/界面层的设计v实体类/公共类的设计v数据流识别vDB第12页,本讲稿共29页13六、详细设计六、详细设计vUI设计vDB设计v各层类的伪代码及包v外部接口设计第13页,本讲稿共29页14七、测试七、测试&部署部署&维护维护测试:代码审查:技术主管、PM或程序员交叉检查单元测试:程序员自身集成测试:程序员自身功能测试:QC,界面、功能正确性、需求满足度每日构建部署:编制部署计划、数据迁移、部署、试用情况维护:BUG修正、代码/界面微调QA:过程管控:规范、文档、质量、进度、成本等第14页,本讲稿共29页15
11、八、常见困难(八、常见困难(1 1):结构化思维,):结构化思维,OOOO编程语言编程语言v结构化思维以功能划分作为解决问题的主线,基本上不会分析功能之间的关系,即思考的是某项功能的实现来解决某些问题v结构化思维不存在“对象抽象”的思考过程v结构化思维中编程的先后次序是以功能优先级排序,和迭代开发的核心确定方法和结果不一定相同v成功进行迭代开发的前提是:核心的确定,而结构化思维将导致核心偏离,从而不真正支持迭代低耦合类类高内聚交叉1234没有核心抽象失败v类识别错误v无法形成稳定的核心v变更将导致全局影响v仍不支持迭代v类继承错误v结构化思维结构化思维vOOOO编程语言编程语言第15页,本讲稿
12、共29页16八、常见困难(八、常见困难(2 2):迭代概念错误):迭代概念错误 v没有找到“核心问题”,错误将“次要问题”作为核心v变更导致“核心”崩溃v错误的简单“增加”第16页,本讲稿共29页17八、常见困难(八、常见困难(3 3):类识别错误,抽象有问题):类识别错误,抽象有问题低耦合类类高内聚交叉1234没有核心抽象失败自认为技术水平高的人简单编码,不思考的人解决问题不完整抽象不合理、错误集成失败须遵循统一的架构第17页,本讲稿共29页18八、常见困难(八、常见困难(4 4):任务指派错误):任务指派错误v简单的任务指派:任务没有排序任务负责人1A2BNAv按核心级别指派:先完成核心
13、任务核心级负责人10A20BNNA任务指派者要有“全局观”第18页,本讲稿共29页19八、常见困难(八、常见困难(5 5):关键需求发生变化、关键需求不明确):关键需求发生变化、关键需求不明确不管是哪种软件开发模型核心需求发生变化,都是灾难性的核心需求不明确时,要尽快明确,有时可以做个较小的“技术原型”,以加速明确核心需求,由于“技术原型”较小,投入的成本不大,可以丢弃?STOP第19页,本讲稿共29页20八、常见困难(八、常见困难(6 6):迭代模型下各项工作的启动次序及输出):迭代模型下各项工作的启动次序及输出v需求说明书不断迭代v设计说明书不断迭代v程序不断迭代V0.6V1.0采用瀑布模
14、型:需求分析设计编码单元测试集成各项工作同步启动第20页,本讲稿共29页21八、常见困难(八、常见困难(7 7):工作量的评估):工作量的评估需求分析及设计编码及测试工程施工MSS25%70%5%BSS50%40%10%OSS20%40%40%第21页,本讲稿共29页22八、常见困难(八、常见困难(8 8):客户关系、客户确认):客户关系、客户确认v项目经理不做客户关系:失败v各阶段不做客户确认:失败v不和客户定期沟通:失败v不和客户定期确认研发成果:失败v不重视部署能力、上线、验收、培训计划:失败第22页,本讲稿共29页23九、售前与销售的矛盾(九、售前与销售的矛盾(1/51/5)销售们一味
15、的要求售前提交技术资料、提交报价文件,但经常“无功而返”解决之道:了解销售过程,抓住销售各阶段的工作重点,要求销售们做好关键工作,售前做好配合STEP 1:客户项目组织STEP 2:确认我们的位置STEP 3:询问我们的销售计划STEP 4:了解销售计划的执行情况,做好售前配合销售目标:清晰的、可度量的、时间限定性的销售活动涉及资源投入,售前投入就是其中一种搜尋並篩選目標設訂拜訪時間表發展成交關鍵除了努力,最好再加一點運氣至少已接觸 1位成交關鍵 銷售基礎 鞏固/升級Best Few 應保守的預估成交時間訂 單 取 得篩選條件In FunnelAbove Funnel1)对客户进行“漏斗筛选”
16、2)对客户“收窄”,形成压力 G+2 G+3.确认对我们的“支持”第23页,本讲稿共29页24九、售前与销售的矛盾(九、售前与销售的矛盾(2/52/5)STEP 1:客户项目组织如果:1)销售们完全不清楚项目组织的:没有见过相关人员 售前对此项目支持的优先级可以比较低,要求销售们先和客户沟通2)销售们没有接触过EB,要求他们尽快拜访EB,了解EB的想法 售前可以提交简单通用的技术描述人员可能的影响人EBXXXYYYTBXXXUBXXXCOACHXXX第24页,本讲稿共29页25九、售前与销售的矛盾(九、售前与销售的矛盾(3/53/5)STEP 2:确认我们的位置我必需作那些改變,以消除憂慮?是
17、否需要改變,以為鞏固?確定的結果不確定的結果停停驚驚 慌慌太棒了太棒了安安 穩穩舒舒 服服OK顧顧 慮慮不舒服不舒服 擔擔 心心 擔擔 憂憂 陶陶 醉醉50%100%0%懂得询问:销售们判定的依据,如果EB都没有见过面,则我们的位置不能高于70%第25页,本讲稿共29页26九、售前与销售的矛盾(九、售前与销售的矛盾(4/54/5)STEP 3:询问我们的销售计划銷售進展階段銷售進展階段影影響響決決策策深深淺淺UBTBEB評評 分分*熱情的擁護 -+5*大力的支持 -+4*支 持 -+3*有興趣 -+2*認知相同 -+1*應該不會拒絕 -1*不感興趣 -2*作負面的評價 -3*抗拒你的建議 -4
18、*支持你的對手 -5销售形态销售形态GTEKOC1)不同阶段,工作重点不同、投入资源的力度不同2)不同人,不同阶段工作内容不同,不同“形态和评分”时工作内容也不同,必要时“收窄,形成压力或表态”第26页,本讲稿共29页27九、售前与销售的矛盾(九、售前与销售的矛盾(5/55/5)STEP 4:了解销售计划的执行情况,做好售前配合A94 John King06/16/2001Before 8/15 close.500 PC/25 Server Router x n,Switch.Rev 6.5MNew T(-)Wang GMZhang DirLi MgrCheng VPT+2G+2G+4*,*,
19、*,*T-46/166/16狼性狼性狼群:协助勤奋独占性:只有0和100狠:拆竞争对手的台销售员特质销售员特质善于询问谈别人感兴趣的事积极成交,尽快close耐心相信直觉,马上做成败在于人,感性,待人真诚不轻言放弃第27页,本讲稿共29页28十、售前的十、售前的“成就感成就感”I WINYOU WIN 經濟掌控經濟掌控經濟掌控經濟掌控 -EB-EB-有效運用資金有效運用資金有效運用資金有效運用資金-投資報酬率投資報酬率投資報酬率投資報酬率-獲利能力獲利能力獲利能力獲利能力-低價取得商品低價取得商品低價取得商品低價取得商品 銷售引導銷售引導銷售引導銷售引導 CoachCoach-獲得認同獲得認同
20、獲得認同獲得認同-自我成就感自我成就感自我成就感自我成就感 技術導向技術導向技術導向技術導向 -TB-TB-穩定性高穩定性高穩定性高穩定性高-最佳的解決方案最佳的解決方案最佳的解決方案最佳的解決方案-取得規格最佳的商品取得規格最佳的商品取得規格最佳的商品取得規格最佳的商品 使用單位使用單位使用單位使用單位 -UB-UB-較大的彈性較大的彈性較大的彈性較大的彈性-穩定性高穩定性高穩定性高穩定性高-獲得最佳服務獲得最佳服務獲得最佳服務獲得最佳服務-最佳的解決方案最佳的解決方案最佳的解決方案最佳的解決方案成果成果加深影響力加深影響力加深影響力加深影響力更多彈性更多彈性提昇地位提昇地位鞏固權力鞏固權力
21、小小虛榮小小虛榮獲得認同獲得認同赢赢:更多的是人内心的:更多的是人内心的“感受感受”第28页,本讲稿共29页29十一、项目管理的售前配合十一、项目管理的售前配合阶段主要工作项售前配合项目启动项目计划:进度、人员、风险控制、质量保障1)项目经理负责总体2)销售配合项目经理3)核心需求由售前负责,由SA分析4)进入需求迭代后,由项目组负责核心需求需求分析核心设计架构设计、UI原型、DB设计、功能模块设计需求迭代需求调研和分析设计迭代设计编码迭代源代码及单元测试测试迭代测试用例、测试结果、BUG列表、需求跟踪矩阵部署上线部署方案、数据割接方案、接口协调初验测试报告、初验报告终验试运行情况报告、终验报告PM:外部协调:外部协调+内部管控内部管控【不断确认不断确认】【客户关系客户关系】【重视部署重视部署】第29页,本讲稿共29页