ξ 1.2 软件开发问题的症状和根本原因
☆ 失败项目的一些共同症状:
① 对于最终用户的需求理解得不够精确;
② 不能处理需求变更;
③ 模块之间不兼容;
④ 软件不易维护和扩展;
⑤ 对项目的严重缺陷发现较晚;
⑥ 软件质量低劣;
⑦ 软件性能让人无法接受;
⑧ 团队中人员按各自的开发方式工作,项目难以重构;
⑨ 一个不可靠的构造和发布过程。
☆ 失败项目的根本原因:
① 特别的需求管理;
② 模糊和不精确的交流;
③ 脆弱的架构;
④ 过度复杂;
⑤ 未检测出需求、设计和实现中的不一致;
⑥ 测试不足;
⑦ 对项目状况的评估过于主观;
⑧ 未解决存在的风险;
⑨ 无法控制变化的传播;
⑩ 自动化程度不足。
ξ 1.3 最佳的软件实践
☆ 软件开发最佳实践:
① 迭代开发:传统软件开发常使用瀑布模型,它将项目生命周期划分为需求分析阶段、设计阶段、编码和单元测试阶段、子系统测试阶段和系统测试阶段。该模型将项目开发各个阶段线性排列一直到项目结束,在项目交付使用前,很难拿出看得见的东西与用户沟通,而我们在开发系统的时候,往往是:“在看到东西之前,用户也不知道自己要的是什么东西”。瀑布模型的危害还表现为可能掩盖项目中存在的真正风险,而当你发现时已经太晚了。
迭代开发可以提供的解决软件开发问题的方案:
⑴ 可以在生命周期早期发现严重的需求理解错误,这是还可以修正这些错误;
⑵ 这种方法允许并鼓励用户反馈信息,从而抽取出系统的真正需求;
⑶ 这种方法使开发团队将注意力集中到项目中最关键的问题上,并屏蔽掉那些分散他们对项目中真正风险的注意力的问题。
⑷ 持续的、迭代的测试可以为项目状况给出客观的评估;
⑸ 需求、设计和实现中的不一致能够在早期被发现;
⑹ 在整个项目的生命周期中可以更加平均地分配整个团队,尤其是可以平均分配测试团队的工作量;
⑺ 团队可以在过程中总结经验教训,不断地改善开发过程;
⑻ 在整个生命周期中,项目相关人员可以通过具体证据来了解项目情况。
② 管理需求:需求在软件开发的生命周期中是具有动态性的。管理动态需求应至少包含三项活动:
⑴ 抽取、组织系统所需要的功能和约束并将其文档化;
⑵ 估计需求的变化并评估这些变化所带来的影响;
⑶ 跟踪并记录所做出的权衡和决定。
管理需求可以提供的解决软件开发问题的方案:
⑴ 在需求管理中构造原则性方法;
⑵ 人员之间的交流建立在已定义的需求之上;
⑶ 区分需求优先级,并进行过滤与跟踪;
⑷ 可以对功能和性能做出客观的评估;
⑸ 不一致性会尽早检测出来;
⑹ 借助适当的工具支持,使用与外部文档的自动连接,可以为系统的需求、属性和轨迹提供库支持。
③ 应用基于构件的架构
使用基于构件的架构可以提供的解决软件开发问题的方案:
⑴ 构件有利于创建灵活性强的架构;
⑵ 模块化可以清晰地分离出系统中易于变化的元素;
⑶ 通过应用标准化的框架和商业上可获取的构件使复用更加容易;
⑷ 构件为配置管理提供一个非常自然的基础;
⑸ 可视化建模工具为基于构件的开发提供自动化的支持。
④ 为软件建立可视化模型
为软件建立可视化模型可以提供的解决软件开发问题的方案:
⑴ 通过用例和场景可以无二义性地详细说明行为;
⑵ 通过模型可以无二义性地理解软件设计;
⑶ 暴露出非模块化的和不灵活的架构;
⑷ 必要时可以隐藏细节;
⑸ 无二义性地设计可以更容易地反映出不一致性;
⑹ 高质量的应用程序应从好的设计开始;
⑺ 可视化建模工具提供对UML建模的支持。
⑤ 对软件的质量进行持续的验证
对软件的质量进行持续的验证可以提供的解决软件开发问题的方案:
⑴ 对于项目状况的评估是客观而非主观的,因为我们评价的是测试结果而非书面文档;
⑵ 这个客观的评估可以暴露出需求、设计和实现中的不一致;
⑶ 测试和验证工作关注的是高风险区域,因此增加了这些区域的质量水平和效率;
⑷ 可以尽早发现缺陷,从根本上降低修复他们的代价;
⑸ 自动化测试工具提供了对功能、可靠性和性能的测试。
⑥ 控制需求变更
控制需求变更以提供的解决软件开发问题的方案:
⑴ 定义需求变更的工作流,且需求变更的工作流是可重复的;
⑵ 变更请求使交流更加清晰;
⑶ 独立的工作空间减少了并行工作的团队成员之间的相互干扰;
⑷ 变更率统计表为客户评估项目状况提供了很好的度量;
⑸ 工作空间包含了所有制品,这样有利于保持一致性;
⑹ 变更的传播是可评估和可控制的;
⑺ 可以在一个健壮的、可定制的系统中维护变更。
ξ 1.4 小结
第一章看完,提出了六点软件开发的最佳实践。
第一是迭代开发,要做到从需求到发布的小增量迭代开发,必须要借助一些工具,比如版本控制工具、每日构建工具、自动化测试工具以及完善的缺陷跟踪机制,否则开发将陷入混乱无序的状态。
第二是动态需求管理,这里着重强调动态两个字,因为一个软件系统的开发,从头到尾,需求不变的情况几乎从来没有过。可以说第六点控制软件的变更和第二点是一个意思。正确评估需求变动对系统的影响,控制变动的传播。
对于第三点,我还是持保留意见的。面向构件的开发像空中楼阁一样,目前还看不到什么成熟的应用,COM晦涩复杂,从来就没有流行过;EJB最近更是备受质疑,事实也证明EJB2的技术并不怎么成功。一个应用确实应该有一个良好的基础框架,但不一定是面向构件的,模块化也确实是很好的思路,但粒度是否应该控制在构件一级,个人表示怀疑。
第四为建模,没什么好说的,上UML就可以了。
第五为对软件的质量进行持续的验证,在迭代开发中,每次迭代都应该进行严格的测试,确保本次迭代中测试发现的缺陷最终都被关闭。质量验证至少包含三个方面:对代码质量的验证、确保性能满足要求以及实现与需求保持一致。
归纳一下,到目前为之,我对RUP最佳软件实践的理解应该是:小增量迭代开发、动态需求管理、良好的基础框架、UML建模和持续的质量验证。