《RUP导论》笔记(一)

原创 2006年06月15日 11:00:00

ξ 1.2 软件开发问题的症状和根本原因

 

失败项目的一些共同症状:

  ① 对于最终用户的需求理解得不够精确;

② 不能处理需求变更;

③ 模块之间不兼容;

④ 软件不易维护和扩展;

⑤ 对项目的严重缺陷发现较晚;

⑥ 软件质量低劣;

⑦ 软件性能让人无法接受;

⑧ 团队中人员按各自的开发方式工作,项目难以重构;

⑨ 一个不可靠的构造和发布过程。

 

失败项目的根本原因:

① 特别的需求管理;

② 模糊和不精确的交流;

③ 脆弱的架构;

④ 过度复杂;

⑤ 未检测出需求、设计和实现中的不一致;

⑥ 测试不足;

⑦ 对项目状况的评估过于主观;

⑧ 未解决存在的风险;

⑨ 无法控制变化的传播;

⑩ 自动化程度不足。

 

ξ 1.3 最佳的软件实践

 

软件开发最佳实践:

 ① 迭代开发:传统软件开发常使用瀑布模型,它将项目生命周期划分为需求分析阶段、设计阶段、编码和单元测试阶段、子系统测试阶段和系统测试阶段。该模型将项目开发各个阶段线性排列一直到项目结束,在项目交付使用前,很难拿出看得见的东西与用户沟通,而我们在开发系统的时候,往往是:“在看到东西之前,用户也不知道自己要的是什么东西”。瀑布模型的危害还表现为可能掩盖项目中存在的真正风险,而当你发现时已经太晚了。

迭代开发可以提供的解决软件开发问题的方案:

⑴ 可以在生命周期早期发现严重的需求理解错误,这是还可以修正这些错误;

⑵ 这种方法允许并鼓励用户反馈信息,从而抽取出系统的真正需求;

⑶ 这种方法使开发团队将注意力集中到项目中最关键的问题上,并屏蔽掉那些分散他们对项目中真正风险的注意力的问题。

⑷ 持续的、迭代的测试可以为项目状况给出客观的评估;

⑸ 需求、设计和实现中的不一致能够在早期被发现;

⑹ 在整个项目的生命周期中可以更加平均地分配整个团队,尤其是可以平均分配测试团队的工作量;

⑺ 团队可以在过程中总结经验教训,不断地改善开发过程;

⑻ 在整个生命周期中,项目相关人员可以通过具体证据来了解项目情况。

 

 ② 管理需求:需求在软件开发的生命周期中是具有动态性的。管理动态需求应至少包含三项活动:

  ⑴ 抽取、组织系统所需要的功能和约束并将其文档化;

  ⑵ 估计需求的变化并评估这些变化所带来的影响;

  ⑶ 跟踪并记录所做出的权衡和决定。

管理需求可以提供的解决软件开发问题的方案:

⑴ 在需求管理中构造原则性方法;

⑵ 人员之间的交流建立在已定义的需求之上;

⑶ 区分需求优先级,并进行过滤与跟踪;

⑷ 可以对功能和性能做出客观的评估;

⑸ 不一致性会尽早检测出来;

⑹ 借助适当的工具支持,使用与外部文档的自动连接,可以为系统的需求、属性和轨迹提供库支持。

 

③ 应用基于构件的架构

 使用基于构件的架构可以提供的解决软件开发问题的方案:

   ⑴ 构件有利于创建灵活性强的架构;

   ⑵ 模块化可以清晰地分离出系统中易于变化的元素;

   ⑶ 通过应用标准化的框架和商业上可获取的构件使复用更加容易;

   ⑷ 构件为配置管理提供一个非常自然的基础;

   ⑸ 可视化建模工具为基于构件的开发提供自动化的支持。

 

④ 为软件建立可视化模型

为软件建立可视化模型可以提供的解决软件开发问题的方案:

   ⑴ 通过用例和场景可以无二义性地详细说明行为;

⑵ 通过模型可以无二义性地理解软件设计;

⑶ 暴露出非模块化的和不灵活的架构;

⑷ 必要时可以隐藏细节;

⑸ 无二义性地设计可以更容易地反映出不一致性;

⑹ 高质量的应用程序应从好的设计开始;

⑺ 可视化建模工具提供对UML建模的支持。

 

⑤ 对软件的质量进行持续的验证

对软件的质量进行持续的验证可以提供的解决软件开发问题的方案:

  ⑴ 对于项目状况的评估是客观而非主观的,因为我们评价的是测试结果而非书面文档;

⑵ 这个客观的评估可以暴露出需求、设计和实现中的不一致;

⑶ 测试和验证工作关注的是高风险区域,因此增加了这些区域的质量水平和效率;

⑷ 可以尽早发现缺陷,从根本上降低修复他们的代价;

⑸ 自动化测试工具提供了对功能、可靠性和性能的测试。

 

⑥ 控制需求变更

控制需求变更以提供的解决软件开发问题的方案:

  ⑴ 定义需求变更的工作流,且需求变更的工作流是可重复的;

⑵ 变更请求使交流更加清晰;

⑶ 独立的工作空间减少了并行工作的团队成员之间的相互干扰;

⑷ 变更率统计表为客户评估项目状况提供了很好的度量;

⑸ 工作空间包含了所有制品,这样有利于保持一致性;

⑹ 变更的传播是可评估和可控制的;

⑺ 可以在一个健壮的、可定制的系统中维护变更。

 

ξ 1.4 小结

 

第一章看完,提出了六点软件开发的最佳实践。

第一是迭代开发,要做到从需求到发布的小增量迭代开发,必须要借助一些工具,比如版本控制工具、每日构建工具、自动化测试工具以及完善的缺陷跟踪机制,否则开发将陷入混乱无序的状态。

第二是动态需求管理,这里着重强调动态两个字,因为一个软件系统的开发,从头到尾,需求不变的情况几乎从来没有过。可以说第六点控制软件的变更和第二点是一个意思。正确评估需求变动对系统的影响,控制变动的传播。

对于第三点,我还是持保留意见的。面向构件的开发像空中楼阁一样,目前还看不到什么成熟的应用,COM晦涩复杂,从来就没有流行过;EJB最近更是备受质疑,事实也证明EJB2的技术并不怎么成功。一个应用确实应该有一个良好的基础框架,但不一定是面向构件的,模块化也确实是很好的思路,但粒度是否应该控制在构件一级,个人表示怀疑。

第四为建模,没什么好说的,上UML就可以了。

第五为对软件的质量进行持续的验证,在迭代开发中,每次迭代都应该进行严格的测试,确保本次迭代中测试发现的缺陷最终都被关闭。质量验证至少包含三个方面:对代码质量的验证、确保性能满足要求以及实现与需求保持一致。

 

归纳一下,到目前为之,我对RUP最佳软件实践的理解应该是:小增量迭代开发、动态需求管理、良好的基础框架、UML建模和持续的质量验证。

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

[startrelatedarticles]

{relatedtitle}

{relateddes}
[endrelatedarticles] [startrelatedarticlesdownload]

{relatedtitle}

  • {relateposttime}
  • {relatesize}
  • 下载
[endrelatedarticlesdownload] [startrelatedarticlesad1]

{relatedtitle}

{relateddes}
[endrelatedarticlesad1] [startrelatedarticlesad2] [endrelatedarticlesad2]
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)