O ciclo de desenvolvimento inclui fases e iterações. Entre as fases e iterações, é possível criar e reutilizar artefatos de desenvolvimento. Os relacionamentos podem existir entre os artefatos de desenvolvimento. Também é possível referenciar e usar artefatos de desenvolvimento que foram criados em outros ciclos de desenvolvimento. Esses artefatos de desenvolvimento poderão estar nos Web sites ou em repositórios customizados.
Recursos poderão conter arquivos de artefatos de desenvolvimento ou referências a eles. Por exemplo, um artefato remoto poderá ser transferido por upload para o repositório de recursos como um artefato de recurso. Por outro lado, o artefato de recurso poderá ser uma referência para um artefato remoto no repositório onde estiver armazenado. O conjunto adequado de artefatos e relacionamentos serão exibidos no repositório de recursos. Equipes poderão acessar o repositório para controlar, procurar e visualizar cenários de uso sobre os recursos.
É possível usar os fluxos de trabalho que estejam incluídos no produto ou então é possível criar fluxos de trabalho adicionais para o repositório.
No nível de ativo, os requisitos para os ciclos de vida principal e de comunidade são herdados pelo ciclo de vida de ativo. Os gerenciadores de ciclo de vida podem incluir requisitos para o ativo para complementar os requisitos especificados pelos administradores de repositório e de comunidade.

Por exemplo, um gerenciador de ciclo de vida pode decidir convidar revisores adicionais para um ativo específico. Eles também poderão ajustar como uma política será configurada, para que corresponda melhor aos requisitos de um recurso em particular.
Quaisquer mudanças feitas na configuração do ciclo de vida de um ativo são aplicadas apenas a esse ativo. Suas mudanças não se aplicam a outros ativos na comunidade que estão usando o mesmo ciclo de vida principal ou de comunidade. Se você fizer frequentemente os mesmos ajustes nos recursos, poderá solicitar a um administrador de comunidade que ajuste o ciclo de vida no nível de comunidade.
Se um recurso que tenha sido submetido a uma comunidade não satisfez os requisitos do ciclo de vida ou outros processos de revisão customizados, o recurso entrará em um ciclo de vida simples que tenha dois estados: Submetido e Aprovado. O proprietário do recurso e todos os administradores são os gerenciadores do ciclo de vida do recurso.
É possível modificar o ciclo de vida de um recurso que tenha entrado no ciclo de vida implícito, mas não é possível modificar esse ciclo de vida para todos os recursos em uma comunidade.
É possível enviar um recurso ao ciclo de vida de aposentadoria de qualquer estado do ciclo de vida. Enquanto o recurso estiver no ciclo de vida de aposentadoria, seus gerenciadores de ciclo de vida poderão modificar o ciclo de vida de aposentadoria para aquele recurso. Em qualquer um desses estados do ciclo de vida é possível restaurar o recurso. Ao restaurar o recurso, ele é reenviado para a comunidade. Ele entrará no primeiro estado do ciclo de vida apropriado com base no tipo de recurso ou nas categorias do recurso.
Nas versões do produto anteriores a 7.2, é possível gerenciar o desenvolvimento de recursos com o passar do tempo usando os processos de revisão Revisões de ativo. Na versão 7.2 ou posterior, é possível usar ciclos de vida para desenvolver recursos com o passar do tempo.
| Processos de revisão (V7.1.1.1 ou anterior) | Ciclos de vida (V7.2 ou posterior) | |
|---|---|---|
| Número de estados e de transições | Está incluído um fluxo de trabalho. Por outro lado, é possível usar o IBM Rational ClearQuest para usar um fluxo de trabalho diferente. | É possível fazer a escolha de vários fluxos de trabalho integrados que tenham números diferentes de estados e de transições. Por outro lado, é possível usar o IBM Rational Team Concert para fazer mais estados e transições. |
| Flexibilidade dos estados | Cada estado tem uma limitação associada às permissões que não possam ser modificadas. Por exemplo, apenas os proprietários do recurso e administradores podem visualizar o recurso no estado Rascunho. | Para cada estado, é possível customizar permissões, revisores e políticas. |
| Transições | Os usuários devem solicitar manualmente a mudança de estados de um recurso. | É possível criar condições complexas que controlam quando um recurso pode se mover de um estado para o outro. Transições também podem ocorrer automaticamente se o recurso atender as condições que forem especificadas. |
| Quem guia os recursos através do ciclo de vida | Ao criar um processo de revisão, você cria uma comissão de revisão ou uma lista de usuários que dá aprovação final sobre a revisão do recurso. É possível modificar as permissões da comissão de revisão modificando o papel da Comissão de Revisão integrada para a sua comunidade. | Quando um ciclo de vida é criado, você designa gerenciadores de ciclo de vida que podem ajustar o ciclo de vida para ativos individuais e convidar mais revisores. Gerenciadores de ciclo de vida possuem um conjunto de permissões pré-definido Funções Adicionais para Ciclos de Vida de Recurso que não pode ser modificado. |
| Quem revisa os recursos | No estado de Revisão, os revisores podem visualizar e votar nos recursos e podem acessar os fóruns de um recurso. É possível selecionar revisores ao configurar o processo de revisão. A comissão de revisão de um recurso pode selecionar revisores enquanto o recurso estiver no estado de Revisão de Plano. | Para qualquer estado em um ciclo de vida, é possível incluir revisores que podem visualizar e comentar sobre ativos e opcionalmente modificar e votar sobre os ativos. |
| Como funcionam as políticas | Processos de política devem ser configurados separados dos processos de revisão. Geralmente uma política é configurada para ser executada antes que seja tentada uma ação no recurso. Quando uma política falha, você não pode tomar essa ação. Por exemplo, uma política pode ser executada antes que um recurso seja aprovado, submetido a revisão, excluído, tornado obsoleto ou arquivado. | Políticas são componentes importantes dos ciclos de vida. É possível configurar políticas para que sejam executadas em qualquer estado, em vários períodos. Por exemplo, uma política pode ser executada cada vez que um recurso é modificado enquanto estiver em um estado específico. Ou, uma política poderá ser executada em um horário específico depois do recurso entrar em um estado específico. É possível usar os resultados das políticas para controlar quando os recursos podem mudar de um estado para outro. |
| Limitar acesso a recursos antigos ou fora de uso | Os estados Aposentado e Arquivado são acessíveis apenas a partir de recursos nos estados em que se encontram e nos Aprovados. | Recursos em qualquer estado de qualquer ciclo de vida poderão entrar em um ciclo de vida de aposentadoria a qualquer momento. |
A seguinte figura mostra um exemplo de um fluxo de trabalho para um ciclo de vida de recurso. Um fluxo de trabalho contém os estados e as ações para um tipo de recurso e pode ser configurado como parte de um ciclo de vida de recurso para controle. É possível aplicar políticas a ações específicas no fluxo de trabalho e especificar quem está autorizado a concluir cada ação ou que possa fazer parte de um processo de revisão.

O desenvolvimento de recurso é cíclico: como parte de um fluxo de trabalho de recurso, um recurso pode passar por vários estados em seu ciclo de vida. Para um dado tipo de recurso, cria-se um modelo de controle para controlar os usuários e os grupos que possam enviar, revisar, aprovar ou rejeitar e publicar recursos. Conforme se altera um recurso e se faz iterações, o ciclo de desenvolvimento se move através dos seguintes estágios: