杨根兴 软件过程改进与敏捷方法

1,499
-1

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,499
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

杨根兴 软件过程改进与敏捷方法

  1. 1. 敏捷之旅 · 上海 软件过程改进与敏捷方法 杨根兴 博士 / 研究员 / 博导 上海市软件行业协会 秘书长 华东理工大学、上海交通大学 教 授 中国软件测评机构联盟 常务副理事长 上海市计算机软件评测重点实验室 学术委员会主任 (上海计算机软件技术开发中心) 2010 年 11 月 13 日
  2. 2. 上海市计算机软件评测重点实验室 (SSTL) ( WWW.SSTL.ORG.CN ) 软件产品 评测 系统评测 与调优 网络测试 国家标准 制订 质量体系 咨询 质量测试 培训 测试与 QA 外包 专业 能力 软 件 生 命 周 期 需求 设计 开发 测试 运维 QA 外包、测试服务 SQA 驻场服务 CMMI 咨询服务 需求管理、产品评审 功能审计、节点控制 性能测试调优 系统健康检查 质量保证平台 项目监控平台 测试管理平台 有经验的专业团队 产品评测 系统测试 QA 咨询 外包服务 评测管理
  3. 3. 上海市计算机软件评测重点实验室 (SSTL) ( WWW.SSTL.ORG.CN )
  4. 4. 上海市计算机软件评测重点实验室 (SSTL) ( WWW.SSTL.ORG.CN ) <ul><li>为信息系统高效、稳定、健康上线运行保驾护航! </li></ul><ul><ul><li>质量保证与测试的成功案例: </li></ul></ul><ul><ul><ul><li>上海证券交易系统 3GSS 项目质量保证 </li></ul></ul></ul><ul><ul><ul><li>农行上海分行质量体系建设咨询 </li></ul></ul></ul><ul><ul><ul><li>中国大地财产保险:系统测试与咨询 </li></ul></ul></ul><ul><ul><ul><li>上海世博会票务系统测试 </li></ul></ul></ul><ul><ul><ul><li>上海市公安局系统测试 </li></ul></ul></ul><ul><ul><ul><li>上海电力系统测试 </li></ul></ul></ul><ul><ul><ul><li>…… </li></ul></ul></ul>
  5. 5. 报告内容 <ul><li>1. 软件过程模型面临的挑战 </li></ul><ul><li>2. 软件过程的线性与非线性 </li></ul><ul><li>3. 软件过程与文化背景 </li></ul><ul><li>4. 软件开发的主体是人 </li></ul><ul><li>5. 过程改进与敏捷方法 </li></ul>
  6. 6. 1. 软件过程模型面临的挑战 <ul><li>随着软件“时间、成本、交付”的压力,不少软件企业的过程体系流于形式,即使有了一大堆规范也很少参照,软件质量问题依旧存在。究其原因,有以下方面: </li></ul><ul><ul><li>软件的交付期越来越短; </li></ul></ul><ul><ul><li>软件的规模越来越大; </li></ul></ul><ul><ul><li>软件需求的不确定性已成为现实; </li></ul></ul><ul><ul><li>软件的变更越来越多且越来越频; </li></ul></ul><ul><ul><li>软件企业的成本压力越来越大。 </li></ul></ul>
  7. 7. 2. 软件过程的线性与非线性 软 件 生 命 周 期 计划 评审 需求 评审 设计 评审 节点 控制 交付物 评审 功能 审计 UAT 测试 单元 测试 集成 测试 系统 测试 UAT 测试 场景 测试 建立长效机制: 依据规范、建立一套体系,如: CMMI3 过程 测试 体系 需求 设计 开发 测试 运维
  8. 8. 瀑布型
  9. 9. 软件开发 V 模型 用户 需求获取 需求描述 需求分析 需求规约 设计 设计规约 详细设计 模块设计书 编程 程序 单元测试 已测试模块 集成 已集成软件 集成测试 软件 确认测试 已确认软件 运行测试 软件产品 ① 测试案例②集成计划③建立文档 ① ① ① ① ① ① ② ③ 评审 评审 评审 评审 静态检查 评审 评审 评审 评审
  10. 10. 增量型( Incremental) <ul><li>构造一系列可执行的中间版本 (Version by Version) </li></ul>
  11. 11. 螺旋型
  12. 12. Agile Lifecycle . . Release 1.4 . . Release 1.3 . Release 1.2 2 - 6 weeks Adapt to change Initiate project Product vision Project goals, constraints Coarse-grain requirements Coarse-grain estimates Iteration & release plans . Rel 1.1 Production Project Status Daily stand-up meetings Review Iteration Develop Product Increment Deliver product increments Production-quality product Plan Iteration
  13. 13. 2. 软件过程的线性与非线性 <ul><li>软件企业不是从主观上排斥已建立的过程体系,而是从客观上无法遵循。因为,软件过程实际上是一种非线性过程,需要 一种适应双向多次交流、多轨并行、实时迭代的 过程模型。 </li></ul><ul><li>特别是软件服务化的趋势明显,有三个方面值得我们关注: </li></ul><ul><ul><li>一是软件与硬件的融合 </li></ul></ul><ul><ul><li>二是软件与服务的融合 </li></ul></ul><ul><ul><li>三是软件与网络的融合 </li></ul></ul><ul><li>软件的开发已不再是一个单纯的软件问题,而是一个融合产品、服务产品的开发问题 ,对软件过程模型提出了挑战。 </li></ul>
  14. 14. 2. 软件过程的线性与非线性 规划 分析 设计 实施 运行 变更 时间维 知识维 逻辑维 明确问题 选择目标 系统综合 系统分析 优化评价 系统决策 系统实施 基本技能 专业基础 标准规范 文档模板 技术工具 模型方法 霍尔的三维方法论
  15. 15. 3. 软件过程与文化背景 <ul><li>目前,软件工程的过程模型基本上是从欧美引进的,也增加了不少日本的元素,其文化背景是明显的。因此,过程模型的引入相对容易,但文化的引入实为困难。 </li></ul><ul><li>有一次接待台南软件代表团时,谈到 CMMI 对中国文化的适应性问题,我提出了一个 Chinese CMMI ( CCMMI )的观点,得到台南软件代表团同胞的一致响应,可谓同根同祖、血脉相通。 </li></ul>
  16. 16. 3. 软件过程与文化背景 <ul><li>欧美的文化从本质上讲,是一种“责任认同”文化,有规程就应该遵循。日本文化从本质上看,是一种长官意志,部下只能回答“是”,实质上也是一种“责任认同”文化。 </li></ul><ul><li>中国的文化,在文革前是提倡孔子的“克己复礼”,文革中是“最高指示”,改革开放后各种文化并存,更多体现了一种“个性”文化,目前正在倡导“和谐”和“包容性”文化。 </li></ul><ul><li>不同的文化背景应该产生不同的软件工程的过程模型。 这也是不能照搬照抄、引进消化再创新的道理。 </li></ul>
  17. 17. 4. 软件开发的主体是人 <ul><li>软件开发的主体是人,而不是过程。 试图把软件开发工程师作为制造业生产线上的工人进行管理,是一种极大的认识错误。导致过程执行的心理障碍。 </li></ul><ul><li>软件开发是一项高智力的劳动 ,靠软件开发的人去完成。而人的思想丰富,其行为具有不确定性,办事很难保持一致,善于从实例中学习工作。 </li></ul><ul><li>过程体系规定的是一种刻板的过程 ,需要人去遵循;遵循的不好,需要不断地强化评审和检查,从而增加了软件的成本。 </li></ul><ul><li>充分发挥人的创造性和协作精神 ,加强沟通的条件和建立有效的沟通机制,是我们需要关注的,而不是一味地加强“监管”措施。 </li></ul>
  18. 18. 5. 过程改进与敏捷方法 <ul><li>5.1 沟通 </li></ul><ul><li>软件开发是个人智慧的产物,更是团队合作的成果。人的思维具有跳跃性和非线性特征,团队中的沟通成为项目成败的关键因素。沟通除了个人的主动性外,更需要沟通的环境、机会、频度、共同理解的语言符号、机制等条件的建立。 </li></ul><ul><li>这实际上是敏捷方法中的 Daily Stand-Up Meetings 的含义。 </li></ul>
  19. 19. 5. 过程改进与敏捷方法 <ul><li>5.2 需求 </li></ul><ul><ul><li>需求沟通 :引导、导读、例会、 DEMO 等 </li></ul></ul><ul><ul><li>需求变更: </li></ul></ul><ul><ul><ul><li>敏捷方法是规避需求变更风险的好方法; </li></ul></ul></ul><ul><ul><ul><li>项目开始时就应进行需求变更风险的评估; </li></ul></ul></ul><ul><ul><ul><li>项目中发生变更。首先要判断此变更的提出者是否是客户的权威要求,再判断此变更是否超出项目的范围,然后再走变更流程。 </li></ul></ul></ul>
  20. 20. 5. 过程改进与敏捷方法 <ul><li>5.3 文档编写 </li></ul><ul><ul><li>代码的文档化。 一本规范的编码手册,是有经验软件企业的标志。 </li></ul></ul><ul><ul><li>变文档编写为文档改写。 文档的编制不仅要有模板框架,而更有用的是案例模板。 </li></ul></ul>
  21. 21. 5. 过程改进与敏捷方法 <ul><li>5.4 文档与设计的一致性 </li></ul><ul><li>文档与设计的一致性追溯矩阵 </li></ul>--- 2 1 修订 标志 变更 标志 测试 用例: No 源代码标识: 子系统、单元 设计文档: 章、节、段 三级 需求 二级 需求 一级 需求 需求 No
  22. 22. 5. 过程改进与敏捷方法 <ul><li>5.5 评审 </li></ul><ul><li>软件评审作为软件质量的一种有效的监督检查手段,评审的目的是找出开发成果物中的缺陷,但评审又是最费时间成本的。软件工程的专家提出了诸如 “审查” 、“ 结对编程”、“小组评审”、“ 同行桌面检查”、“ 传阅”、“ 轮换评审”、“走查”、 “同行评审”和“临时评审” 等许多方法。 </li></ul><ul><li>在敏捷方法的一个开发周期中应提倡“同行评审”和“临时评审”,一个小版本发布时可采用团队的“小组评审”,以降低评审的成本。 </li></ul>
  23. 23. 5. 过程改进与敏捷方法 <ul><li>5.6 知识共享 </li></ul><ul><ul><li>团队中、企业中实现知识共享是企业成熟的表现,软件企业最有价值的是知识的积累。知识共享是一种文化,企业应该营造知识共享的氛围和推进机制。 </li></ul></ul><ul><ul><li>目前,大部分企业仅把基线文档入库,作为配置管理的手段。这是远远不够的。其实, 知识的片断 有时显得更为重要、更为有用与实用。 </li></ul></ul><ul><ul><li>人是最容易在反面教材中获得教育的。因此,建立 缺陷知识库 十分重要。 </li></ul></ul>
  24. 24. 银弹?! 全靠实践! 在实践中创新! 结语:
  25. 25. <ul><li>请批评、指正! </li></ul>谢谢各位! 杨根兴, [email_address] , 13916304463
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×