专心做可以提升自己的事情
学习并拥有更好的技能
成为一个值得交往的人
实线箭头表示开发过程,虚线箭头表示维护过程
瀑布模型的一个变体,描述了测试阶段的活动与开发阶段相关活动(包括需求建模、概要设计、详细设计、编码)之间的关系
- 可强迫开发人员采用规范化的方法
- 严格地规定了每个阶段必须提交的文档
- 要求每个阶段交出的所有产品都必须是经过验证的
快速原型是快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集
- 有助于满足用户的真实需求
- 原型系统已经通过与用户的交互而得到验证,据此产生的规格说明文档能够正确地描述用户需求
- 软件产品的开发基本上是按线性顺序进行
- 因为规格说明文档正确地描述了用户需求,因此,在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工
- 开发人员通过建立原型系统已经学到了许多东西,因此,在设计和编码阶段发生错误的可能性也比较小,这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性
- 快速原型的突出特点是“快速”。开发人员应该尽可能快地建造出原型系统,以加速软件开发过程,节约软件开发成本
原型的用途是获知用户的真正需求,一旦需求确定了,原型可以抛弃,当然也可以在原型的基础上进行开发
使用增量模型开发软件时,把软件产品作为一系列的增量构件来设计、编码、集成和测试
每个构件由多个相互作用的模块构成,并且能够完成特定的功能
螺旋模型将瀑布模型与快速原型模型结合起来,并且加入两种模型均忽略了的风险分析
螺旋模型的基本思想是,使用原型及其他方法来尽量降低风险
——定义在该阶段的目标,弄清对过程和产品的限制条件,制订详细的管理计划,识别项目风险,可能还要计划与这些风险有关的对策
——针对每一个风险进行详细分析,设想弱化风险的步骤
——评价风险之后选择系统开发模型
——评价开发工作,确定是否继续进行螺线的下一个循环。如果确定要继续,则计划项目的下一个阶段的工作
螺旋模型是风险驱动的,因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识,否则将出现真正的风险:当项目实际上正在走向灾难时,开发人员可能还以为一切正常
典型的面向对象生命周期模型
“喷泉”一词体现了迭代和无间隙特性
代表不同阶段的圆圈相互重叠,这明确表示两个活动之间存在重叠
1.业务建模工作流 用商业用例为商业过程建立文档
2.需求工作流 目标是描述系统应该做什么,确保开发人员构建正确的系统。为此,需明确系统的功能需求和非功能需求(约束)
3.分析和设计工作流 其目标是说明如何做。结果是分析模型和设计模型
4.实现工作流 用分层的方式组织代码的结构,用构件的形式来实现类,对构件进行单元测试,将构件集成到可执行的系统中
5.测试工作流 验证对象之间的交互、是否所有的构件都集成了、是否正确实现了所有需求、查错并改正
6.部署工作流 制作软件的外部版本、软件打包、分发、为用户提供帮助和支持
初始阶段主要关注项目计划和风险评估,其目的是确定是否值得开发目标信息系统
细化阶段关心定义系统的总体框架,其目标是:细化初始需求(用况)、细化体系结构、监控风险并细化它们的优先级、细化业务案例以及制订项目管理计划
构造阶段是建立系统,构造信息系统的第1个具有操作质量的版本,以能够交付给客户进行测试的版本结束,有时称为测试版本
以发布完整的系统而终止,其目标是确保信息系统真正满足客户的需求
基于构件的软件工程(component-based software engineering,CBSE)是强调使用可复用的软件“构件”来设计和构造基于计算机的系统的过程
考虑的焦点是“集成”,而不再是“实现”
这样做的基础是假定在很多大型软件系统中存在足够多的共性,使得开发可复用的构件来满足这些共性是可行的
当软件团队使用传统的需求获取技术确定了待开发软件的系统需求时,该过程开始
体系结构设计完成后,并不立即进行详细设计任务,而是针对每一系统需求考虑以下问题:
- 1.现有的商品化构件(commercial off-the-shelf,COTS)是否能够实现该需求?
- 2.内部开发的可复用构件是否能够实现该需求?
- 3.可用构件的接口与待构造系统的体系结构是否相容?
不考虑构件的开发技术,基于构件的开发模型由以下步骤组成
1.对于该问题领域的基于构件的可用产品进行研究和评估
2.考虑构件集成的问题
3.设计软件架构以容纳这些构件
4.将构件集成到架构中
5.进行充分的测试以保证功能正常
对象管理组织发布了公共对象请求代理体系结构(OMG/CORBA),一个对象请求代理提供了多种服务,使得可复用构件(对象)可以与其他构件通信
微软公司开发了构件对象模型(COM),此模型提供了构件的规格说明,在Windows操作系统,一个应用系统中可以使用不同厂商生产的构件
JavaBean构件系统是一个可移植的、平台独立的、使用Java程序设计语言开发的CBSE基础设施
个体和交互胜过过程和工具
可工作软件胜过宽泛的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
(1)我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
(2)即使在开发的后期,也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
(3)经常交付可运行软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
(4)在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
(5)围绕有积极性的个人构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
(6)在团队内部,最富有效果和效率的信息传递方法是面对面交谈。
(7)可运行软件是进度的首要度量标准。
(8)敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一种长期、稳定的开发速度。
(9)不断地关注优秀的技能和好的设计会增强敏捷能力。
(10)简单是必要的。 (11)好的架构、需求和设计出自于自组织团队。
(12)每隔一定时间,团队会反省如何才能更有效地工作,并相应调整自己的行为。
基本能力
共同目标
精诚合作
决策能力
自我组织
相互信任和尊重
模糊问题解决能力
eXtreme Programming,XP ---使用最广泛的敏捷过程
XP包含了策划、设计、编码和测试4个框架活动的规则和实践
开始于建立“用户故事”
敏捷团队评估每一个故事并给出成本(cost)
故事被分组用于可交付增量
对发布日期做出承诺
在第一个发行版本(软件增量)之后,“项目速度” 用于帮助建立后续发行版本(软件增量)的发布日期
XP设计严格遵循KIS(keep it simple, 保持简洁)原则,通常更愿意使用简单设计而不是更为复杂的表述
严格遵守KIS原则
鼓励使用CRC(类-责任-协作者)卡片
在设计中遇到困难, XP推荐立即建立这部分设计的可执行原型,实现并评估设计原型
鼓励“重构”—一种迭代的改进内部程序设计的方法
建议在开始编码之前为每一个故事开发一系列单元测试
鼓励 “结对编程”
所有的 单元测试每天都要执行。
“验收测试” 由客户定义,将着眼于客户可见的、可评审的系统级的特征和功能
自适应软件开发(adaptive software development,ASD),作为构建复杂软件和系统的一项技术,其基本概念着眼于人员合作和团队自组织
(1)思考:思考过程中,开始项目规划并完成自适应循环策划。自适应循环策划通过使用项目开始信息,来确定项目所需的一系列软件增量发布循环。
(2)协作:受激励的人员以超越其聪明才智和独创成果的方式共同工作,协作方法是所有敏捷方法中不断重现的主旋律。
(3)学习:当ASD团队成员开始开发作为自适应循环一部分的构件时,其重点是在完成> (1)思考:思考过程中,开始项目规划并完成自适应循环策划。自适应循环策划通过使用项目开始信息,来确定项目所需的一系列软件增量发布循环。
(2)协作:受激励的人员以超越其聪明才智和独创成果的方式共同工作,协作方法是所有敏捷方法中不断重现的主旋律。
(3)学习:当ASD团队成员开始开发作为自适应循环一部分的构件时,其重点是在完成循环的过程中学习尽可能多的东西。循环的过程中学习尽可能多的东西。