Caso de Desenvolvimento		 O caso de desenvolvimento descreve o processo de desenvolvimento escolhido para ser seguido no projeto.
Tópicos

Explicação Início da página

Expresso em termos de modelagem de negócios, o processo de desenvolvimento de software é um processo de negócios, ao passo que o produto Rational Unified Process (RUP) é um processo de negócios genérico, destinado à engenharia de software orientada a objetos. Um caso de desenvolvimento é uma configuração estática do produto RUP; ou seja, é um processo de negócios destinado à engenharia de software adaptada a projetos, organizações e produtos específicos. O caso de desenvolvimento enfoca o que fazer e como fazê-lo.

Um caso de desenvolvimento mostra como o RUP genérico se aplica ao contexto de sua organização. Isso significa que você modifica o processo e adapta a terminologia.

Um caso de desenvolvimento também fornece uma visão geral do processo a ser seguido, algo que seja compreendido por todos os participantes do projeto. O caso de desenvolvimento deve consultar o RUP e outras diretrizes ou guias de estilo para obter informações detalhadas.

A configuração do processo é a atividade que implica obter um caso de desenvolvimento a partir do processo mais geral apresentado no RUP. Para obter um exemplo de um caso de desenvolvimento, consulte Exemplo: Caso de Desenvolvimento.

O engenheiro de processo é responsável pela configuração do processo, decidindo qual será a aparência do processo de desenvolvimento, "instalando" o caso de desenvolvimento na organização de desenvolvimento (equipe, projeto ou empresa) e ensinando aos desenvolvedores como usá-lo.

Lembre-se de que a introdução de um novo processo de desenvolvimento (como o RUP) em uma organização é sempre um risco. Avalie constantemente as vantagens de uma nova técnica em comparação com o custo da introdução das mudanças. Considere a possibilidade de introduzir uma mudança do ponto de vista gerencial e técnico.

Uma vez configurado o caso de desenvolvimento pelo engenheiro de processo, o gerente do projeto cria instâncias e o executa em um determinado projeto. Esse procedimento geralmente é denominado execução do processo.

À medida que o processo se desenrola, são aprendidas muitas lições, que são usadas pelo engenheiro de processo como feedback para aprimorá-lo.

Elementos Variáveis nos Processos de Engenharia de Software Início da página

Esta seção descreve os elementos integrantes de um processo que provavelmente serão modificados, personalizados, adicionados ou suprimidos de um determinado caso de desenvolvimento.

  • Disciplinas
    Raramente um projeto de software deixará totalmente de incluir uma das disciplinas (como Análise e Design, Implementação e assim por diante). Em casos excepcionais, é possível que algumas disciplinas (como, por exemplo, Requisitos ou Implantação) tenham sido executadas por outras organizações. No entanto, o mais provável é que fluxos de trabalho específicos sejam modificados nas ou através das disciplinas.  
  • Artefatos
    É muito mais provável que os projetos se diferenciem pelos artefatos que têm de produzir, atualizar e liberar. Em uma das pontas de uma linha imaginária de projetos, imagine um projeto sem qualquer documentação escrita, que mantenha eletronicamente apenas um pequeno número de artefatos, que seja suportado por ferramentas de design, de programação, de teste e planilhas, e que apenas libere o software e a documentação eletronicamente em disco, em CD ou pela World-Wide Web. Na outra ponta, há projetos que devem produzir e manter um conjunto muito mais amplo de documentos impressos por razões contratuais, reguladoras ou organizacionais. Em alguns casos, modelos inteiros poderão ser omitidos.
  • Atividades
    É provável que as atividades variem devido a duas razões, no mínimo. As atividades que utilizam artefatos como entrada e que produzem (ou atualizam) artefatos como saída são afetadas pela modificação desses artefatos. Se algum artefato ou algum elemento de informação em um artefato não for mais necessário, as etapas correspondentes poderão ser suprimidas ou modificadas de forma significativa. As atividades também são modificadas para introduzir determinadas técnicas, métodos e ferramentas pertencentes ao domínio específico do aplicativo ou a seus conhecimentos específicos de desenvolvimento, como, por exemplo, etapas de design, linguagens de programação, ferramentas para geração automática de códigos, técnicas de medição e assim por diante.

Em um nível mais detalhado, outros elementos do processo podem ser modificados, adicionados ou suprimidos:

  • Etapas das atividades
  • Diretrizes e orientações referentes às atividades
  • Notações, como o uso de subconjuntos da UML ou o uso de estereótipos para lidar com alguma necessidade específica de alguns (ou de todos os) modelos
  • Pontos de verificação para inspeções e revisões
  • Papéis
  • Ferramentas de suporte para automatizar algumas atividades
  • Mudanças de terminologia para, por exemplo, adaptar o processo ao contexto organizacional

Em resumo, o engenheiro de processo deve tomar inúmeras decisões para elaborar um caso de desenvolvimento fora do RUP que esteja perfeitamente adaptado. É possível que um caso de desenvolvimento tenha de ser adaptado para que possa tirar proveito de determinadas práticas e padrões da empresa que já tenham sido estabelecidos com êxito, como documentos, terminologia e assim por diante.

Configurações Difíceis Início da página

Certas formas de configuração são difíceis de implementar e precisam ser consideradas com muito cuidado. Por exemplo:

  • Mudanças na arquitetura do processo
    Uma ampla reestruturação das atividades de modo a englobá-las em outro conjunto de disciplinas a fim de atender às exigências de um processo ou de uma organização existente pode levar a um esforço muito grande para um ganho muito pequeno. Geralmente, é mais prático simplesmente estabelecer um mapeamento para avaliar se todos os aspectos são abordados pelo RUP. Lembre-se de que as disciplinas não são fases executadas em seqüência, mas sim contêiners de atividades, sendo executadas repetidas vezes em cada iteração e, normalmente, ao mesmo tempo em uma iteração.
  • Mudanças na terminologia
    Embora a substituição de uma palavra por outra possa parecer um exercício trivial no processamento de texto, essas mudanças devem ser consideradas com muito cuidado. No domínio da engenharia de software, geralmente as organizações utilizam a mesma palavra com significados ligeiramente diferentes ou palavras diferentes com o mesmo significado. Mudanças isoladas no RUP podem levar a um processo de difícil compreensão. Uma solução é criar uma "tabela de tradução" da terminologia, que faça a correspondência entre a terminologia do RUP e a da organização.

Entre os exemplos de palavras perigosas estão sistema, fase, papel, atividade, modelo e documento.

Se os resultados do processo forem captados em um idioma diferente do inglês, os problemas de terminologia serão mais complexos quando for necessário traduzir para esse outro idioma as descrições de artefatos, documentos, relatórios e possivelmente outras partes do RUP.

Delegação de Responsabilidades no Processo Início da página

O caso de desenvolvimento não precisa capturar todo o processo. Na verdade, muitas das responsabilidades e decisões sobre o processo (principalmente sobre os artefatos) são delegadas a participantes do projeto de desenvolvimento de software. Por exemplo, se você tiver um gerente de projeto muito bom e experiente, poderá deixar a cargo dessa pessoa a tarefa de decidir que planos serão elaborados e como isso será feito. Da mesma maneira, alguns gerentes de projeto não estão preocupados com a forma como cada membro da equipe projetará a sua parte do sistema, contanto que a funcionalidade esperada seja apresentada a tempo e com um nível razoável de qualidade.

Uma das razões para que se tenha uma descrição do processo é que várias pessoas possam compartilhar as informações. Se não for este o caso, o custo de se manter a descrição do processo poderá ser muito alto. Por isso, você pode optar por não ter (ou manter) a descrição do processo referente a uma ou várias disciplinas. Isso não significa que você não esteja concentrando esforços nessa disciplina específica nem tampouco que você não a considere importante. Por exemplo, você pode empregar um excelente gerente de testes, fornecer todo o suporte possível, mas deixar a cargo desse gerente a tarefa de decidir como irá trabalhar e que artefatos produzirá.

Representação de um Caso de Desenvolvimento On-line Início da página

Um caso de desenvolvimento pode ser representado de várias maneiras diferentes:

Uma ou Várias Páginas da Web

É mais fácil representá-lo como um documento do Microsoft Word. No entanto, é recomendável que você represente o caso de desenvolvimento como uma ou várias páginas da Web com hyperlinks para o RUP quando necessário. Consulte Kit de Ferramentas: Adição de Vínculos Externos para o Rational Unified Process para obter mais detalhes sobre como adicionar hyperlinks. Se você tiver desenvolvido um produto de processo específico de uma organização com base no RUP, o caso de desenvolvimento terá hyperlinks para ele. Consulte Conceitos: Configuração do Processo para obter mais detalhes.

É recomendável que você integre o caso de desenvolvimento ao seu site de projeto da Web, caso tenha um. Consulte Kit de Ferramentas: Trabalho com Sites de Projeto na Web.

Um Site da Web com Ferramentas de Navegação

Você pode criar o caso de desenvolvimento como um site da Web com ferramentas de navegação, como o RUP on-line. Ou seja, você pode usar ferramentas de desenvolvimento para a Web como o Microsoft® FrontPage® e as ferramentas do RUP. Para obter informações específicas sobre como desenvolver páginas da Web, consulte Kit de Ferramentas: Guia de Estilo do Rational Unified Process. Consulte também Kit de Ferramentas do Engenheiro de Processo para ter acesso aos mentores de ferramentas que descrevem como usar o FrontPage e as ferramentas do RUP. 

É recomendável que você integre o caso de desenvolvimento ao seu site de projeto da Web, caso tenha um. Consulte Kit de Ferramentas: Trabalho com Sites de Projeto na Web.

Integrado ao RUP On-line

Também é possível integrar o caso de desenvolvimento ao RUP on-line. Para fazer isso, modifique a árvore de navegação e adicione uma nova entrada ao Caso de Desenvolvimento e às diretrizes específicas do projeto. Consulte Kit de Ferramentas: Modificação da Árvore de Navegação para obter detalhes. No entanto, observe que essa abordagem não é muito vantajosa, já que você acaba adaptando o RUP ao projeto quando adiciona informações específicas do projeto a ele. Essa abordagem só é recomendável se o RUP on-line for usado em um único projeto.

Copyright  (c) 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process