 |
|
|
|
|
|
迭代开发需要一种不同的观点
本文来自 Rational Edge ：RUP 的专家解释了被软件开发项目成员需要的职责和观点上的改变，并且介绍了成功的从传统的瀑布型方法向迭代方法转变的客户案例。 |
|
|
|
2004年4月29日 |
|
| |
克服采用迭代开发时的文化挑战
来自Rational Edge: 很多组织都理解尽早缓解风险、用户驱动的开发和其它迭代开发范例等的价值。但是由于文化和操作上的障碍，他们怀疑他们的组织能不能采用这些最佳实践。本文将描述和提出一些方法来应对在你采用迭代开发时可能会遇到的挑战。 |
|
|
|
2004年10月15日 |
|
| |
模型驱动体系结构介绍，第三部分: MDA 如何影响迭代开发过程
本文来自于 Rational Edge：作为迭代开发框架，Rational Unified Process 或称为 RUP，足够灵活地适应多种项目管理方式。随着基于 RUP 的团队开始采用模型驱动体系架构（model-driven architecture，MDA）策略，为成功地采用 MDA，他们需要了解 RUP 中的哪些任务、工件和阶段需要特别关注。 |
|
|
|
2005年8月1日 |
|
| |
Rational Edge: 旅程！一个度假者的迭代开发指南
本文来自于 Rational Edge：如果您或您知道的人怀疑迭代的及增量的软件开发方法的生命力和价值，那么你们所需要的也许是用于了解基本概念的，并且是你们都熟悉的框架。本文中，Laura Rose 将走出软件领域，介绍一种迭代项目的形式：越野旅程。 |
|
|
|
2006年9月14日 |
|
| |
Rational Edge: 书评：管理迭代开发项目
本文来自于 Rational Edge：这是一篇关于一本新书的非常精彩的评论，详细说明了执行迭代项目管理的必要实践和过程。 |
|
|
|
2006年11月13日 |
|
| |
RUP 迭代开发计划的两种方法
从项目管理的角度来看，RUP 的开发中对于迭代计划的开发和管理是保证成功交付项目的关键。好的迭代开发计划可以有效降低项目的风险，提高团队的协作，提高项目开发效率。本文总结了两种开发迭代计划的方法，并对比两者的适用情况，以期对应用 RUP 的项目管理人员提供借鉴。 |
|
|
|
2009年5月14日 |
|
| |
一个学习案例: 使用 IBM Rational Unified Process 作为方法框架
本文来源于 2003 年 Rational 用户大会的一个演讲稿，这个学习案例的研究讨论了一个公司成功的开发和部署以 IBM RUP 作为过程框架的迭代开发方法的真实经验。实现一个标准的过程和这个过程为开发组织提供的未来机会也将在本文中被关注。 |
|
|
|
2004年4月1日 |
|
| |
从瀑布型开发到迭代型开发的转变
本文来自 Rational Edge ：一个理想的迭代开发方法模型在很多方面与理想的瀑布开发模型有着根本上的不同。但是，从实际来说，没有一个团队严格的应用了每一种开发方法模型。本文解释了为什么开发团队决定逐步的从类似瀑布型的开发方法转变成更加类似迭代开发的方法，同时也概述了能够帮助这种转变的步骤。 |
|
|
|
2004年5月20日 |
|
| |
迭代化软件开发技术
这篇 IBM Rational 的白皮书讲述了传统软件开发过程的缺点和迭代开发过程的优点，并详细的介绍了迭代开发在风险和项目管理上起到的作用。 |
|
|
|
2004年9月16日 |
|
| |
架构蓝图--软件架构 "4+1" 视图模型
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。 |
|
|
|
2005年1月1日 |
|
| |
使用 RUP 管理小型项目和团队
来自 Rational Edge：软件项目管理者常常认为 Rational Unified Process（即大家所熟知的RUP），不适用于有限规模的软件项目。本文提供了在整个迭代开发阶段均遵循RUP，从而获益匪浅的两个小项目的典型示例。 |
|
|
|
2005年10月19日 |
|
| |
科学“证明”的本质与软件开发
来自 Rational Edge：“软件开发前沿”的作者通过解释科学，理论，和实验的本质阐述了软件测试和迭代开发的科学基础。 |
|
|
|
2006年2月15日 |
|
| |
科学“证明”的本质与软件开发
软件开发前沿的作者通过解释科学、理论和实践的本质阐述了软件测试和迭代开发的科学基础。 |
|
|
|
2006年2月17日 |
|
| |
测试人员对 RUP 四个阶段的贡献：另一种观点
本文来自于 Rational Edge：在对软件迭代开发生命周期中的测试人员的作用进行探讨的同时，作者考虑，除了 RUP 测试规程中提供的描述，测试人员还能如何对项目做出广泛的贡献。 |
|
|
|
2006年6月15日 |
|
| |
迭代测试的谬论与事实
本文来自于 Rational Edge：软件测试专家Laura Rose将会质疑和揭穿一些广泛流传的关于迭代开发和迭代测试通常的一些荒谬的言论。她将解释迭代开发原则是如何解决这些通常的误解的，并会把你带到测试方法的真正道路上。 |
|
|
|
2006年6月15日 |
|
| |
Rational Edge: 成功的度量标准：RUP 和科学的方法
本文来自于 Rational Edge：如果您的基于 RUP 的项目比较成功，您怎样知道您的团队所使用的 RUP 是这个项目成功的原因呢？这里 Gary Pollice 提出了一个可以科学地度量几个迭代开发技术的方法。 |
|
|
|
2006年9月14日 |
|
| |
Rational Edge: 过程引入的反模式——如何避免一个过程对您的影响
本文来自于 Rational
Edge：在一个软件开发组织中处理过程采用问题有合适的方法，也有不合适的方法。在本文里作者指出了一些常见的错误，即通常被看作是反模式（anti-pattern）,是由项目领导者在过渡到迭代开发方法时所造成的。 |
|
|
|
2007年2月12日 |
|
| |
迭代生命周期中的工件审查
本文出自于 Rational Edge：审查是一种提高瀑布模型项目的质量的好方法。但对于迭代项目来说，我们想要短的周期来做该工作。这篇引人兴趣的文章重新考虑了迭代开发生命周期中审查的角色。 (The Rational Edge) |
|
|
|
2008年2月15日 |
|
| |
将项目从瀑布式转为迭代过程
本文来自于 Rational Edge：通常，坚定地相信迭代化方法的软件开发者必须为那些出于各种原因而坚持使用传统的瀑布方法理念的客户服务。本文就是讨论如何帮助那些人改变观念，转为使用Rational Unified Process。 |
|
|
|
2006年7月14日 |
|
| |
Rational Edge: 使 RUP 的剪裁简单化：引入职责矩阵和工件流
本文来自于 Rational Edge：作者提出了一项将 Rational 统一过程进行剪裁的技术，以适应软件项目具体需求，即使外聘的 RUP 专家不熟悉本公司及其文化。 |
|
|
|
2006年11月13日 |
|
| |
Rational Edge: 书评：使用 IBM Rational 统一过程进行项目管理
本文来自于 Rational Edge：一篇书评，有关于 R. Dennis Gibbs 的使用 RUP 管理软件开发团队的非常有用的书。 |
|
|
|
2006年12月14日 |
|
| |
Rational Edge: 利用基于 RUP 的方法开发数据仓库 —— 第 1 部分：初始阶段
本文来自于
Rational Edge：这个分为两部分的系列文章概述了如何将基于 IBM Rational 统一过程（RUP）
的方法用到数据仓库（data
warehouse，DW）项目中，这些项目可以在遇到最终用户的需求变更时，交付高质量解决方案，从而减少您的商业及技术风险。本文概述了与传统、串行的 DW
开发方法相关的问题，介绍了 RUP 的渐进式的方法是如何更加适合 DW 开发的，并且概述了这种项目的初始阶段。 |
|
|
|
2007年1月15日 |
|
| |
Rational Edge: 度量项目的健康性，第 3 部分
在一个项目的产品化阶段中，适当的度量将有助于确保把开发解决方案的成功配置应用到生产环境中去。这个由三个部分组成的系列中最后一部分也会讨论管理嵌入在一个计划中的项目。 |
|
|
|
2007年7月16日 |
|
| |
Rational Edge: 精益开发治理的最佳实践，第 1 部分
本文是介绍 IBM Rational 的治理现代软件开发工作的推荐方法的系列文章中的第 1 篇，本文探究了精益治理的使命和原则，以及一个个项目的成功所需的组织和项目涉众的协作。 (The Rational Edge) |
|
|
|
2007年8月15日 |
|
| |
Rational Edge: Oz 大陆上的瀑布
理解在采用迭代、增量的软件开发实践中出现障碍时，IBM Rational 服务组织是如何面对以及帮助客户解决这些障碍的。 (The Rational Edge) |
|
|
|
2007年8月15日 |
|
| |
Rational Edge: 精益开发治理的最佳实践，第 2 部分
本文是系列文章中的第二篇，介绍了 IBM Rational 的治理现代软件开发工作的推荐方法，本文将介绍必要的过程组成，以及要使用的最佳度量标准。 (The Rational Edge) |
|
|
|
2007年9月17日 |
|
| |
Rational Edge: 是什么让软件变得如此之难？
与传统意义上的工程相比，软件工程向开发者提出了独特的挑战。开发者们不能依靠物理学第一定律和硬科学来开发可靠的、可重复的实践方法。这些实践方法只能通过经验而非科学来得到。本文探讨了其中的原因。 (The Rational Edge) |
|
|
|
2007年10月15日 |
|
| |
Rational Edge: 精益开发治理的最佳实践，第 3 部分
本系列文章的第 3 部分介绍了治理现代软件开发工作的 IBM Rational 推荐方法，本文提出了精益软件开发治理中要采用的角色和职责，以及政策和标准。 (The Rational Edge) |
|
|
|
2007年10月15日 |
|
| |
Rational Edge: 在降低风险的情况下更快地交付系统：RUP 的宏观迭代维度
组织可以通过向迭代的原始概念中添加宏观的维度来扩展 RUP 的能力。引用 O'Neill 的话，“使用演进 —— 多重的，重叠地通过 RUP 生命周期 —— 可以减少风险，大大加快投放市场的时间，并且改进资源分配”。O'Neill 还提出了描述这个宏观迭代维度的实例。 (The Rational Edge) |
|
|
|
2007年11月15日 |
|
| |
敏捷 RUP：来自实战中的经验
本文来自于 Rational Edge：这三篇简短的文章是分别由 IBM Rational 思想领导者们所撰写的，它们描述了为什么 IBM Rational 统一过程或者简称为 RUP 不仅自身是正确的，而且包含了那些需要成功地度量敏捷技术的团队的许多指导方针。 (The Rational Edge) |
|
|
|
2008年3月15日 |
|
| |
开发环境架构师的兴起
本文来自于 Rational Edge：开发环境不同于传统上软件架构师角色所关注的领域。阅读本文并且了解为什么从软件开发项目的体系架构视角来说，这个领域应当被强调为一个关键的组成要素。 (The Rational Edge) |
|
|
|
2008年5月15日 |
|
| |
Web 应用程序首先应该是应用程序
本文来自于 Rational Edge：通过本文了解一个大学教授在工作中如何以克服诱惑，而不将 Web 应用程序视为采用所有最新和最时髦技术（wizz-bang technology）的机会。相反，他已经学会了让他的学生关注业务应用的基础 —— 这种同样可以在业务设置应用得很好的方法。 (The Rational Edge) |
|
|
|
2008年5月15日 |
|
| |
一个项目经理对 RUP 的评论
本文来自于 Rational Edge：阅读 IBM Rational 统一过程（Rational Unified Process, RUP）如何补充项目管理知识体系（Project Management Body of Knowledge，PMBOK），以及精通 PMBOK 的项目经理如何理解并使用 RUP 来支持其项目经理（Project Manager，PM）的角色。 (The Rational Edge) |
|
|
|
2008年5月15日 |
|
| |
敏捷实践报告：用于系统测试的模型
本文出自于 Rational Edge：许多公司将敏捷的开发实践作为提高产品的质量和及时交付产品的方法。如何在敏捷的开发环境中最佳地执行系统测试策略，是每个公司和团队都希望能回答的问题。 (The Rational Edge) |
|
|
|
2008年6月16日 |
|
| |
技巧性与可控性： OpenUP 与 Eclipse Way
本文来自 Rational Edge：学习 Eclipse Way 的特性，OpenUP 的深入内容，以及灵活团队开发工具的最佳方案。 (The Rational Edge) |
|
|
|
2008年8月18日 |
|
| |
书摘 ——来自 Software Project Manager's Bridge to Agility
本文来自于 Rational Edge： 阅读关于迁移到敏捷软件开发的最新书籍之一其中的一个篇章。 (The Rational Edge) |
|
|
|
2008年8月18日 |
|
| |
演示：敏捷的致命弱点
本文来自于 Rational Edge：敏捷宣言（ Agile Manifesto ）和其它敏捷指导方针建议要有频繁的产品演示，比如在每次迭代结束的时候。但是大多数这种建议都太宽泛而且不具体，使得开发团队必须自己从尝试和错误中学习。这篇文章提供了丰富的实践知识，如关于敏捷项目上在什么时候，怎样，以及按照什么顺序来执行演示。 (The Rational Edge) |
|
|
|
2008年12月18日 |
|
| |
利用 IBM Rational Suite AnalystStudio 进行迭代需求管理
本文解释了IT部门在定义和处理项目需求时面临的问题。它说明了如何利用需求管理解决方案解决这些问题。它解释了为什么高效的IT管理需要这样的解决方案。它解释了IBM Rational Suite AnalystStudio如何满足迭代需求管理的挑战。 |
|
|
|
2005年4月7日 |
|
| |
什么是迭代化开发？－－第一部分：从开发人员的角度
来自 Rational Edge：本文为三篇连载之一，论述了软件开发项目团队成员如何进行迭代的，增量的工作方式。作者介绍了隐含在迭代式增量开发方案背后的理论基础，并探索了团队成员应用此类方法的经验。 |
|
|
|
2005年5月31日 |
|
| |
美国国防部体系架构框架（Department of Defense Architectural Framework，DoDAF）使用的 IBM Rational 方法 —— 第 2 部分：系统视图
本文来自于 Rational Edge：本文是两部分系列中的第二篇，描述了美国国防部（DoD）体系架构（DoDAF）的系统视图（System View，SV）和技术标准视图（Technical Standard View，TV）产品。第一部分文章介绍了 DoDAF 概述并描述了运作视图（Operational View，OV）产品。 |
|
|
|
2006年6月15日 |
|
| |
Rational Edge 电子月刊: 2006 年 8 月 期刊内容
来自 Rational Edge 电子月刊中文版：面向中国 Rational 用户和爱好者的中文电子月刊。 |
|
|
|
2006年9月15日 |
|
| |
Rational Edge: 对复杂的单元测试使用模拟对象
本文来自于 Rational Edge：为创建使用模拟对象的单元测试，使用相对简单的技术产生更多的无缺陷代码。 |
|
|
|
2006年12月14日 |
|
| |
Rational Edge 电子月刊: Rational Edge: 2007 年 2 月 期刊内容
来自 Rational Edge 电子月刊中文版：面向中国 Rational 用户和爱好者的中文电子月刊。 |
|
|
|
2007年3月16日 |
|
| |
一种简单实用的迭代化开发方法
迭代化开发做为一种软件开发方法，已经逐渐的得到应用。本文的目的是介绍一种可实践操作的迭代化开发方法，这种开发方法描述了如何以一种简单实用的方法来进行迭代化开发。通过采用本文所描述的迭代化开发的这种方法，能够降低项目组引入迭代化开发的难度和复杂度，从而尽可能的保证迭代化开发使用成功。 |
|
|
|
2007年8月23日 |
|
| |
书评 —— Programming Erlang Software for a Concurrent World
本文出自于 Rational Edge：阅读 Joe Armstrong 的关于用 Erlang 语言进行程序设计的新书如何成为寻求解决并行问题的程序员的无价资源。 (The Rational Edge) |
|
|
|
2008年2月15日 |
|
| |
IBM Rational 红皮书简介
本文来自于 Rational Edge: 如果您还不熟悉 IBM Rational 红皮书 (IBM Redbooks)，这篇文章将向您介绍这些与图书篇幅相当的技术文档，它们是专门用于帮助您理解 IBM Rational 技术和部署 IBM Rational 产品与解决方案。 (The Rational Edge) |
|
|
|
2008年4月15日 |
|
| |
敏捷测试的最佳实践，第 1 部分: 敏捷的实质
本文讲述了作者在两年的敏捷测试和开发工作中的经验和体会。从敏捷的实质，敏捷测试的方法和过程，到如何帮助传统团队转变为敏捷团队做了详细阐述。本文是系列的第一篇文章，着重讲述敏捷实质。 |
|
|
|
2008年4月21日 |
|
| |
敏捷测试的最佳实践，第 2 部分: 方法与实践
本文讲述了作者在两年的敏捷测试和开发工作中的经验和体会。从敏捷的实质，敏捷测试的方法和过程，到如何帮助传统团队转变为敏捷团队做了详细阐述。本文是系列的第二篇文章，着重讲述敏捷测试的方法和过程。 |
|
|
|
2008年5月23日 |
|
| |
IBM Rational Self Check for Software Teams 入门简介
本文出自于 Rational Edge：阅读新的 IBM Rational Self Check for Software Teams 如何帮助您实现自评估以帮助提高团队敏捷性。取代了团队之外的人执行的量度和/或评估，Self Check 授权软件工程师定义并讨论他们自己的重要数据，并改进过程。 (The Rational Edge) |
|
|
|
2008年6月16日 |
|
| |
敏捷测试的最佳实践，第 3 部分: 向敏捷测试转变
本文讲述了作者在两年的敏捷测试和开发工作中的经验和体会。从敏捷的实质，敏捷测试的方法和过程，到如何帮助传统团队转变为敏捷团队做了详细阐述。本文是系列的第三篇文章，着重讲述如何帮助传统团队转变为敏捷团队。 |
|
|
|
2008年6月30日 |
|
| |
Jazz 系列: 开始使用迭代计划
迭代计划组件提供了一种有趣的方法来帮助您计划和执行项目中的开发迭代。由于迭代计划基于针对相关里程碑的工作项，从而使得此计划任务非常交互式、活泼和有趣。 |
|
|
|
2008年7月9日 |
|
| |
通过 Jazz 和 IBM Rational Team Concert 进行测试管理
本文将介绍使用 IBM Rational ClearQuest 和 IBM Rational Team Concert 管理测试资产的两种方法。Team Concert 包括集成的工作条目、源控制、以及编译管理支持等，适用于小型和中型的团队。IBM Rational 于 2008 年出推出 Jazz 技术平台，这是第一个基于 Jazz 平台的产品。 |
|
|
|
2008年7月17日 |
|
| |
Rational 的技术支持方法
本文来自于 Rational Edge：阅读 IBM Rational 的两位领导人是如何描述面向潜在客户领域的团队所面临的挑战和实践，从而促进业务取得成功。 (The Rational Edge) |
|
|
|
2008年12月18日 |
|
| |
敏捷环境下的领导力问题
本文来自于 Rational Edge：如今关于敏捷软件开发无处不在的观点已经得到了大家的公认，但在敏捷开发团队新背景下，关于什么是领导力的特征尚未得出公论。通过本文了解一位敏捷开发技术的长期支持者关于敏捷开发领导人所担负角色和特点的观点。 (The Rational Edge) |
|
|
|
2009年4月27日 |
|
| |
Hello World: 学习如何在 Rational Modeling Extension for Microsoft .NET V7 中使用转换并行开发 UML 模型和 C# 代码
IBM Rational 建模产品为您提供了简单的 C# 应用程序开发工具，它能帮助您可视化已有代码，建模组件，并且可以在模型和 C# 代码之间转换元素。在这篇教程中，您将会从学习如何向 Eclipse 工作台中导入一个 .NET 解决方案开始。您会捕获您的应用程序设计的 UML 模型，建立一个转换配置，然后运行一个 UML 到 C# 的转换，产生 C# 代码，以便今后使用 Microsoft Visual Studio 进行开发。 |
|
|
|
2007年8月23日 |
|
| |
Jazz 入门教程
通过本教程，您将了解 Jazz 平台的基础知识和一些主要的 Jazz 组件。这些入门知识可以帮助您掌握 Jazz 平台，您甚至可以将本教程作为指南加以使用。 |
|
|
|
2008年5月8日 |
|
| |
体验 Jazz，体验 Rational Team Concert Express
本教程将通过一个实例来介绍开发团队怎样以 Rational Team Concert Express (RTCE) 为开发工具和协作平台来进行敏捷的软件开发。通过本教程，您将了解 Jazz 平台和第一款基于 Jazz 平台技术开发的商业产品 Rational Team Concert Express 的基础知识。通过这些入门知识，您可以掌握如何运用 Rational Team Concert Express，抢先体验最新的软件协作开发方式。 |
|
|
|
2008年5月26日 |
|
| |
如何使用 IBM Rational Method Composer 为 IBM Rational Team Concert 文档化您的团队过程
本篇教程指导您如何在 IBM Rational Team Concert 客户机中配置 IBM Rational Method Composer 使用同一个 Eclipse 实例（shell-sharing），并上载由 Rational Method Composer 为 Jazz Team Server 生成的过程模板。 |
|
|
|
2008年11月20日 |
|
| |
使用 Rational Team Concert 实现企业应用协同开发
本教程简单介绍了一个企业应用案例 Tanggula，并介绍了采用协同应用生命周期管理工具 Rational Team Concert 去配置和完成协同开发的基础以实现应用案例的基本要求：设置和创建项目、团队和过程；计划一个迭代（包括了迭代计划与工作项目的创建）。 |
|
|
|
2008年12月15日 |
|
| |
