第二章 - 软件开发过程

软件生命周期与开发过程

• 软件开发过程（software development process）又叫做软件开发生命周期（software development life cycle, SDLC），是软件产品开发的任务框架和规范，又可以简单的称为软件生命周期及软件过程。
• 可重复的、可预测的过程能够提升软件生产的效率和质量。（过程改进）
• 生命周期是软件开发的宏观上的框架，软件过程则涉及到软件开发的流程等管理细节，在框架稳定的前提下允许对软件过程进行裁剪。
• 4种不同类型的生命周期：顺序式、迭代式、增量式以及敏捷式。

软件生命周期

• 过程管理主要采用的是一种“分而治之”的思想，即将整个软件的生命周期划分成软件定义、软件开发和运行维护三个主要的时期，每个时期再细分为具体的阶段，分别对应明确的任务。

1. 可行性分析与开发计划：是否值得开发（较高层次的需求分析和设计），技术可行性、经济可行性和社会可行性，描述所提出的解决方案和方案的可行性，并拟定开发计划。
2. 需求分析：软件开发后续阶段的基础，应对需求进行变更管理，除功能需求外还要对系统设计有影响的非功能性需求加以识别和分析，输出是一份“需求规格（Specification）说明书”的文档。
3. 软件设计：设计可分为概要设计和详细设计，此阶段的输出分别为“概要设计说明书”和“详细设计说明书”，尽可能保证系统设计结构在整体上的稳定性。
4. 程序编码：翻译成某种计算机语言实现的程序代码。(要忠于设计)
5. 软件测试：环节可分为单元测试、集成测试及系统测试。方法主要包括黑盒和白盒方法。
6. 软件维护：
   • 改正性维护：诊断和改正在使用过程中发现的软件错误；
   • 适应性维护：修改软件以适应环境的变化；
   • 完善性维护：根据用户的要求改进或扩充软件使它更完善；
   • 预防性维护：修改软件为将来的维护活动预先做准备。
   • 软件维护是软件生命周期的最后一个阶段，也是持续时间最长，花费最多的一个阶段，软件工程学的一个目的就是提高软件的可维护性，降低维护的代价。

传统生命周期模型

• 顺序的将生命周期阶段组织起来，严格按照需求、分析、设计、编码和测试的阶段进行。
• 瀑布模型、原型模型、增量模型。
• 最基本和有效的可供选择的软件开发模型。

瀑布模型（*）

• 最广泛
• 阶段间具有顺序性和依赖性，文档驱动，前一阶段输出的文档为下一阶段的输入文档
• 推迟实现，不急于编写代码：尽可能的理解和掌握系统需求，清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。
• 质量保证的观点：
  • 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
  • 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
• 传统瀑布模型图示：
  
• 缺点：
  • 不希望有“变化”，变化来的越晚，付出的代价越高。
  • 设计阶段过多的假设，导致理想化、一厢情愿的东西过多。(用户只参与需求)
  • 文档驱动，静态
• 优点：
  • 强迫开发人员使用规范方法
  • 严格规定阶段提交的文档
  • 要求质量保证小组验证各阶段产品
• 实际瀑布模型：
  
  • 计划驱动，在对系统整体的把控和协调上，具有优势，因此适合规模较大的系统或分布式开发模式。

快速原型模型（*）

• 快速原型模型（Rapid Prototype）的主要作用是在用户和开发者之间起到“桥梁”的作用。

• 快速原型模型的特点：
  • 对系统进行简单和快速的分析，快速构造一个软件原型
  • 用户和开发者在试用或演示原型过程中加强沟通和反馈，通过反复评价和改进原型，减少双方的误解，降低缺陷引入的几率，降低由于需求不明确带来的开发风险和提高软件质量，获取到用户真正的需求。
  • 快速原型中可以尝试运用未来系统中需要的新技术，提前测试一些性能上的要求是否能够达到预期。减少在后续的设计和编码阶段出现相同错误的可能性。
• 缺点：
  • 所选用的开发技术和工具不一定是实际项目的需要。
  • 快速建立起来的模型可能由于不符合各种开发规范，再加上不断的修改，质量一般都比较差，通常在实际开发过程中会完全抛弃之前建立起来的原型系统。
• 适用于：需求不明确的软件

增量模型

• 也称为渐增模型。把软件产品作为一系列增量构件来设计、编码、集成和测试。
• 每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
• 使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。(滚雪球方式)
  
• 对比瀑布模型：
  • 瀑布模型： 力求一次性给用户完整的系统。
  • 增量模型：逐步增加系统功能。
  • 需要开放的架构设计。

螺旋模型

• 螺旋模型的基本思想是使用原型及其它方法尽量降低风险 ： 在每个阶段之前都增加了风险分析过程的快速原型模型。
• 特别适合于大型复杂的系统。螺旋模型沿着螺线进行若干次迭代，四个象限代表了不同的活动。
  • 原型模型可以在一定程度上降低风险，但对有些风险也无能为力。
  • 需要专业的风险评估人员。

制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
风险分析：分析评估所选方案，考虑如何识别和消除风险；
实施工程：实施软件开发和验证；
客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：
螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。因此，这种模型往往适应于内部的大规模软件开发；
如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目；
软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。
该模型的每个螺旋迭代首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，这个过程有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段的迭代。

喷泉模型（*）

• 迭代是OO开发过程的主要特性。
• 喷泉模型是典型的面向对象生命周期模型。
• “喷泉” 体现了面向对象软件开发过程迭代和无缝的特性。
• 为避免喷泉模型的过分无序，把一个线性过程作为总目标。
  
• 迭代：逐步求精
• 阶段间没有明显的界限－面向对象的思想保证了各个阶段开发的一致性。

敏捷宣言（*）

• 迭代式开发
• 增量交付
• 开发团队和用户反馈推动产品开发
• 持续集成
• 开发团队自我管理

敏捷宣言：

• 个体和互动胜过流程和工具；
• 工作的软件胜过详尽的文档；
• 客户合作胜过合同谈判；
• 响应变化胜过遵循计划。

• 增量开发的方式即分批分期的交付用户产品，通过增量开发来应对软件产品之外的不确定因素（风险）。
• 敏捷方法建议先实现必要性的用户案（用）例（用户故事），体现出软件的价值，然后在后续版本中对功能进行细化，使得我们的软件产品的所有功能都能够达到相同的用户体验水平。
  • “用例”是指一件用户通过系统完成的有价值的目标，它不是一个具体的功能。
    
• 迭代的开发方式：
  • 但用户的需求往往无法立刻稳定。
  • 迭代的思想就是当对需求还没有信心的时候，不指望构建的软件正是客户所想要的，但可以先构建后修改，通过多次反复找到真正客户需要的软件。（逐步求精）
• 优势：
  • 精确
  • 质量
  • 速度
  • 丰厚的投资回报率
  • 高效的自我管理团队
• 敏捷开发更适合规模中小、需求变化频繁的系统开发，并且强调团队的作用，所以更适合集中式的开发模式。

敏捷开发模型：极限编程（XP）（*）

• eXtreme Programming
• 主要目的是降低需求变化的成本
• 崇尚的开发方法：
  • 客户代表与开发团队紧密融合
  • 结对编程（pair-programming）
  • 开发流程：编写用户故事、架构规范、实施规划、迭代计划、代码开发、单元测试、验收测试
  • 积极接受变化
• 价值观/原则：
  • 互动交流。团队成员不是通过文档来交流，文档不是必须的。
  • 反馈。客户的实际使用、功能测试、单元测试等都能为开发团队提供反馈信息。同时，开发团队也可以通过估计和设计用户案例的方式将信息反馈给客户。
  • 简单。XP提倡简单的设计、简单的解决方案。XP总是从一个简单的系统入手，并且只创建今天（而不是明天）需要的功能模块。因为它认为，创建明天需要的功能模块可能会由于需求的变化而成为浪费。
  • 勇气。XP在这一点所要达到的目的是鼓励一些应对较高风险的良好做法。例如，它要求程序员尽可能频繁地重构代码，必须删除过时的代码，不解决技术难题就不罢休，等等。
  • 团队。XP提倡团队合作，相互尊重。XP以建立并激励团队为一项重要任务。同时它把互相尊重和实际的开发习惯相结合。比如，为了尊重其他团队成员的劳动成果，每个人不得将未通过单元测试的代码集成到系统中。因此，每个人的代码质量必须过关。
• 核心做法：
  • 小规模，频繁的版本发布，短迭代周期
  • 测试驱动开发（Test-driven development）：TDD，测试先行
  • 结对编程（Pair programming）：开发+审查
  • 持续集成（Continuous integration）
  • 每日站立会议（Daily stand-up meeting）
  • 共同拥有代码（Collative code ownership）：每个人都负责
  • 系统隐喻（System metaphor）：设计的系统的全局视图

敏捷开发模型：SCRUM过程（*）

• Scrum注重过程，XP注重实践
• 需求被定义为产品需求积压（product backlogs）
• 开发过程分为多个冲刺（Sprint）周期
• 燃尽图（burn down）是一个公开展示的图表，显示当前冲刺中未完成的数目
  
• SCRUM角色：
  • 产品拥有者（Product Owner）：产品远景规划，平衡利益相关者利益，确定产品积压的优先级等。它是开发团队和客户间的联络点。
  • 利益相关者（Stakeholder）：客户或最终用户代表，收集编写产品需求，审查项目成果等。
  • 专家（Scrum Master）：指导进行Scrum开发与实践，是开发团队与产品拥有者间的联络点。
  • 团队成员（Team Member）：项目开发人员。

DevOps过程

• DevOps：开发(Development)和运维(Operations)，源于敏捷开发过程，遵从基本的敏捷宣言，强调了“个体和交互胜过流程和工具”的作用，但却不受限于某一种软件过程，甚至是在瀑布模型中也会发挥作用。
• DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保证部门之间的沟通、协作与整合。
• 强调开发和运维必须紧密合作。
• DevOps的核心目标是自动化和可持续交付。
• 实现全生命周期的工具全链路打通与自动化、跨团队的线上协作能力，从而全面提高生产环境的可靠性、稳定性、弹性和安全性。
• 纵向集成打通了应用全生命周期
• 横向集成打通了架构、开发、管理、运维等部门墙