1、1,一、软件工程（1）：瀑布模型,瀑布模型：严格遵循软件生命周期文档驱动里程碑审查启动下一阶段必须是上一阶段工作已完成,软件过程模型典型,问题定义及可行性研究需求分析架构设计概要设计详细设计编码、代码审核及单元测试集成测试部署维护,2,一、软件工程（2） ：迭代模型,迭代模型：不断迭代用例驱动、架构优先,软件过程模型典型,优先完成核心部分 不断向外扩展，可能要修正部分核心代码，但总体而言， 核心逐步稳定，并不断扩大范围统一分析、设计、编码理念：OOA、OOD、OOP 统一建模语言：UML采用瀑布模型：需求分析 客户确认设计 客户确认编码单元测试集成客户确认,用例图：表示系统的功能，并支持其操作
2、者,3,一、软件工程（3）：结构化与面向对象的理念区别,理念区别：考虑问题的视角完全不同,存在交叉 问题变更可能导致系统崩溃 不支持迭代 所有问题必须事前明确 开发过程中，无法和客户确认 基本要到开发完成，才能确定是否解决问题 很多到最后才发现需要变更影响全局,抽象,支持迭代 核心逐步稳定并扩大 次要问题可以逐步明确 不断发布新版本，客户不断确认 不断确认变更，影响范围有限,结构化思维，OO编程语言 类识别错误 类继承错误 仍不支持迭代 无法形成稳定的核心 变更将导致全局影响,4,一、软件工程（4）：解决方法,可行性研究核心需求规格说明书、UI原型 关键是用例图、活动图架构指导书 关键是逻辑架
3、构图和规范需求规格说明书迭代 详细设计说明书迭代 关键是类图、对象关系图 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,二、可行性分析,工作内容： 进度安排
4、/里程碑确定 人员配置、资源投入 开发环境、配置管理 项目规范、沟通管理 风险识别及规避措施,关键点： 和客户确定阶段性成果的交付、内部评审、客户评审识别项目风险，针对技术风险和客户进行沟通明确项目范围去除不可行的需求或技术对不明确需求进行调研,可行性分析的目的，使项目： 成本可行、效益可行 进度可行 资源配置可行 客户需求可行 技术要求可行、质量可行 社会环境、市场、政策可行 同时识别出项目风险，加以控制,7,三、需求分析（1）：建立逻辑模型,需求规格说明书要素： 项目目标、组织架构、功能需求、性能需求、部署环境、可靠性需求、安全性要求及权限模型、UI需求、进度要求、资源投入、成本约束、边界
5、/接口、使用者、现状,关键点： 进一步明确项目范围 去除不可行的需求或技术 对不明确需求进行调研,工作内容： 最核心问题必须明确，次要问题可以迭代 采用合适的分析工具 编制需求规格说明书,需求迭代,需求评审,需求说明书,完整、清晰：需求覆盖、描述完整 一致性：上下文无冲突，无二义性 可行性：需求可行、技术可行 接口：识别系统边界 需求覆盖 限制、假设 风险识别,目的：目标一致需求覆盖通过UI原型更容易需求理解通过UI原型更容易客户确认需求识别、控制风险作为项目计划的输入,8,三、需求分析（2）：结构化分析方法,一般采用瀑布模型 存在交叉 问题变更可能导致系统崩溃 不支持迭代 所有问题必须事前明
6、确 开发过程中，无法和客户确认 基本要到开发完成，才能确定是否解决问题 很多到最后才发现需要变更，影响全局,分析工具：自顶向下数据流图DFD场景描述活动图、状态图、时序图E-R图ERD层次图HIPO 数据字典DD：属性、取值范围等IPO图/表UI原型物理部署,数据字典,ER图,数据流图,时序图,9,三、需求分析（3）：面向对象分析方法,支持迭代 核心逐步稳定并扩大 次要问题可以逐步明确 不断发布新版本，客户不断确认 不断确认变更，影响范围有限,分析工具：自顶向下、自底向上用例图use case：用例模型场景描述状态图、活动图、时序图：动态模型，和“结构化”相同类/对象关系图HIPO图： 和“结
7、构化”相同 数据字典DD：属性、取值范围等，和“结构化”相同IPO图/表：和“结构化”相同UI原型，有时会有技术原型：和“结构化”相同部署图、构件图：静态模型类图、对象图、包：静态模型,2、抽象 自顶向下,DB,1、抽象 自底向上,类识别/设计是关键,用例图,顶层用例图,包,类关系图,物理部署图,10,三、需求分析（4）：面向对象分析DEMO,项目目标 项目范围 Actor及接口 组织架构图 功能图/树 功能：用例图 查询：IPO表 统计：IPO表 权限模型 数据字典DD 数据流图 场景描述 流程：活动图、时序图、状态转换图 UI原型 部署图 其他：性能需求、运行环境、可靠性需求、安全性要求、
8、进度要求、资源投入、成本约束、现状,11,四、架构设计,表示层WEB 业务逻辑层IBLL 数据访问层IDAL 数据存储层DB,实体类Entity 公共类Utility,描述了框架和一般性规范 技术路线 物理、逻辑分布 逻辑架构及包设计 会话安全 权限设计 事务处理 日志处理 异常处理 UI框架 边界/接口 扩展性,中大型系统的架构设计尤为重要， 架构设计不合理，将导致迭代失败 应重点考虑应用扩展性、逻辑架构和分布,12,五、概要设计,类识别 类之间的联系：类图及包设计 数据存储层/数据访问层/业务逻辑层/界面层的设计 实体类/公共类的设计 数据流识别 DB,13,六、详细设计,UI设计 DB设
9、计 各层类的伪代码及包 外部接口设计,14,七、测试&部署&维护,测试： 代码审查：技术主管、PM或程序员交叉检查 单元测试：程序员自身 集成测试：程序员自身 功能测试：QC，界面、功能正确性、需求满足度 每日构建,部署： 编制部署计划、数据迁移、部署、试用情况,维护： BUG修正、代码/界面微调,QA： 过程管控：规范、文档、质量、进度、成本等,15,八、常见困难（1）：结构化思维，OO编程语言,结构化思维以功能划分作为解决问题的主线，基本上不会分析功能之间的关系， 即思考的是某项功能的实现来解决某些问题 结构化思维不存在“对象抽象”的思考过程 结构化思维中编程的先后次序是以功能优先级排序，
10、和迭代开发的核心确定方法 和结果不一定相同 成功进行迭代开发的前提是：核心的确定，而结构化思维将导致核心偏离， 从而不真正支持迭代,交 叉,1,2,3,4,没 有 核 心,抽象失败,16,八、常见困难（2）：迭代概念错误,没有找到“核心问题”，错误将“次要问题”作为核心 变更导致“核心”崩溃,错误的简单“增加”,17,八、常见困难（3）：类识别错误，抽象有问题,交 叉,1,2,3,4,没 有 核 心,抽象失败,自认为技术水平高的人,简单编码，不思考的人,解决问题不完整,抽象不合理、错误,集成失败,须遵循统一的架构,18,八、常见困难（4）：任务指派错误,简单的任务指派：任务没有排序,按核心级别
11、指派：先完成核心,任务指派者要有“全局观”,19,八、常见困难（5）：关键需求发生变化、关键需求不明确,不管是哪种软件开发模型 核心需求发生变化，都是灾难性的核心需求不明确时，要尽快明确，有时可以做个较小的“技术原型”，以加速明确核心需求，由于“技术原型”较小，投入的成本不大，可以丢弃,？,STOP,20,八、常见困难（6）：迭代模型下各项工作的启动次序及输出,需求说明书不断迭代 设计说明书不断迭代 程序不断迭代,V0.6,V1.0,采用瀑布模型：需求分析设计编码单元测试集成,各项工作同步启动,21,八、常见困难（7）：工作量的评估,22,八、常见困难（8）：客户关系、客户确认,项目经理不做客
12、户关系：失败 各阶段不做客户确认：失败 不和客户定期沟通：失败 不和客户定期确认研发成果：失败 不重视部署能力、上线、验收、培训计划：失败,23,九、售前与销售的矛盾（1/5）,销售们一味的要求售前提交技术资料、提交报价文件，但经常“无功而返” 解决之道：了解销售过程，抓住销售各阶段的工作重点，要求销售们做好关键工作，售前做好配合 STEP 1：客户项目组织 STEP 2：确认我们的位置 STEP 3：询问我们的销售计划 STEP 4：了解销售计划的执行情况，做好售前配合,销售目标：清晰的、可度量的、时间限定性的 销售活动涉及资源投入，售前投入就是其中一种,1）对客户进行“漏斗筛选” 2）对客
13、户“收窄”，形成压力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
14、,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
15、,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 耐心 相信直觉，马上做 成败在于人，感性，待人真诚 不轻言放弃,28,十、售前的“成就感”,經濟掌控 - EB - 有效運用資金 - 投資報酬率 - 獲利能力 - 低價取得商品,銷售引導 Coach - 獲得認同 - 自我成就感,技術導向 - TB - 穩定性高 - 最佳的解決方案 - 取得規格最佳的商品,使用單位 - UB - 較大的彈性 - 穩定性高 - 獲得最佳服務 - 最佳的解決方案,成果,赢：更多的是人内心的“感受”,29,十一、项目管理的售前配合,PM：外部协调+内部管控 【不断确认】 【客户关系】 【重视部署】,
