Elementos Essenciais do Processo

Tópicos
  1. Visão - Desenvolver uma Visão
  2. Plano - Gerenciar o Plano
  3. Riscos - Diminuir Riscos e Monitorar os Problemas Relacionados
  4. Caso de Negócio - Examinar o Caso de Negócio
  5. Arquitetura - Projetar uma Arquitetura de Componentes
  6. Protótipo - Construir e Testar o Produto Incrementalmente
  7. Avaliação - Avaliar os Resultados Regularmente
  8. Controles de Mudanças - Gerenciar e Controlar Mudanças
  9. Suporte ao Usuário - Implementar um Produto Utilizável
  10. Processo - Adotar um Processo que se Ajuste ao Projeto

Orientação Adicional:


IntroduçãoPara o início da página

O importante para alcançar o sutil equilíbrio entre a entrega de um software de qualidade e a rapidez nessa entrega (o paradoxo do software!) é compreender os elementos essenciais do processo e seguir determinadas diretrizes para sua adaptação, a fim de satisfazer, da melhor maneira possível, as necessidades específicas do projeto. Esse procedimento deve ser realizado de acordo com as melhores práticas testadas e aprovadas na indústria, ajudando assim os projetos de desenvolvimento de software a serem bem-sucedidos.   

A seguir, temos a descrição dos princípios essenciais de um processo de software eficiente.

1. Visão - Desenvolver uma VisãoPara o início da página

Em particular, desenvolver uma Visão clara é importante para desenvolver um produto que atenda às necessidades reais de seus  investidores.

No RUP, o artefato Visão captura requisitos de nível muito alto e restrições de design para fornecer ao leitor um entendimento do sistema a ser desenvolvido. Ele fornece informações para o processo de aprovação do projeto e está, portanto, diretamente relacionado ao Caso de Negócio. Comunica os fundamentais "por que e o que" relacionados ao projeto e funciona como um calibre com base no qual todas as decisões futuras devem ser validadas.

O conteúdo da Visão, juntamente com quaisquer outros artefatos de requisitos relacionados, deve responder às perguntas a seguir, que podem ser divididas em artefatos separados e mais detalhados, conforme necessário:

  • Quais são os termos-chave? (Glossário)
  • Que problema estamos tentando resolver? (Declaração do Problema)
  • Quem são os investidores? Quem são os usuários? Quais são as suas necessidades?
  • Quais são as características do produto?
  • Quais são os requisitos funcionais? (Casos de Uso)
  • Quais são os requisitos não funcionais?
  • Quais são as restrições de design?

O desenvolvimento de uma visão clara e de um conjunto compreensível de requisitos é a essência da ../../process/workflow/ovu_req.htm -- This hyperlink in not present in this generated websitedisciplina Requisitos e da Boa Prática: Gerenciar Requisitos. Isso envolve analisar o problema, entender as necessidades dos investidores, definir o sistema e gerenciar os requisitos à medida que são alterados.   

2. Plano - Gerenciar o Plano

"O produto só é tão bom quanto o plano para o produto" (FIS96).

Conceber um novo projeto; avaliar o escopo e risco; monitorar e controlar o projeto; planejar e avaliar cada iteração e fase - estes elementos são a "essência" da ../../process/workflow/ovu_mgm.htm -- This hyperlink in not present in this generated websitedisciplina Gerenciamento de Projeto.

Um Plano de Desenvolvimento de Software reúne as informações necessárias para gerenciar o projeto. Ele é utilizado para fazer o planejamento do projeto e planejar as necessidades de recursos e para acompanhar o progresso do planejamento. Ele trata de áreas como:  organização do projeto, planejamento, orçamento e recursos. Também pode incluir planos para gerenciamento de requisitos, gerenciamento de configuração, resolução de problemas, garantia de qualidade, avaliação e teste e aceitação do produto.

Em um projeto simples, muitos desses tópicos podem ser abrangidos por uma ou duas sentenças cada um. Por exemplo, o planejamento de gerenciamento de configuração pode simplesmente declarar: "No final de cada dia, o conteúdo da estrutura de diretórios do projeto será compactado, copiado em um disco de zip etiquetado e datado, marcado com um número de versão e colocado no arquivamento central".

O formato dos artefatos de planejamento não é tão importante quanto as atividades de planejamento e as idéias contidas.  Não importa a aparência dos planos ou as ferramentas utilizadas para construí-los.  Conforme dito por Dwight D. Eisenhower, "O plano não é nada; o planejamento é tudo."

3. Riscos - Diminuir Riscos e Monitorar os Problemas Relacionados

É essencial identificar e combater os itens de risco mais alto no início do projeto e acompanhá-los, juntamente com outros problemas relacionados.  A Lista de Riscos foi projetada para capturar os riscos aparentes para o sucesso do projeto. Ela identifica, em ordem decrescente de prioridade, os eventos que poderiam levar a um resultado negativo significativo.

Juntamente com cada risco, deve haver um plano para diminuí-lo.  Isso serve como um ponto focal para planejar atividades do projeto e é a base para a organização das iterações.

4. Caso de Negócio - Examinar o Caso de Negócio

O Caso de Negócio fornece as informações necessárias, de um ponto de vista de negócios, para determinar se compensa, ou não, investir no projeto.

A finalidade principal do Caso de Negócio é desenvolver um plano econômico para realizar a Visão do projeto. Uma vez desenvolvido, o Caso de Negócio é usado para fazer uma avaliação precisa do Retorno do Investimento (ROI) fornecido pelo projeto. Ele fornece a justificativa para o projeto e estabelece suas restrições econômicas. Fornece informações para os tomadores de decisão econômica sobre o valor do projeto e é utilizado para determinar se o projeto deve continuar.

A descrição não deve se aprofundar nos itens específicos do problema, mas deve criar um argumento convincente a favor da necessidade do produto. Ela deve ser breve, no entanto, para que seja facilmente compreendida e lembrada por todos os membros da equipe. Em marcos críticos, o Caso de Negócio é reexaminado para verificar se as estimativas do retorno e do custo esperados ainda são precisas e se o projeto deve continuar

5. Arquitetura - Projetar uma Arquitetura de ComponentesPara o início da página

No RUP (Rational Unified Process), a arquitetura de um sistema de software (em um determinado ponto) é a organização ou estrutura dos componentes significativos do sistema que interagem por meio de interfaces com componentes constituídos de componentes e interfaces sucessivamente menores. Quais são as partes principais? E como elas se ajustam?  Temos uma estrutura na qual o restante do software pode ser incluído?

Para falar e tirar conclusões sobre a arquitetura do software, primeiro defina uma representação de arquitetura, uma forma de descrever aspectos importantes de uma arquitetura. Esta descrição é capturada no Documento de Arquitetura de Software, que apresenta a arquitetura em várias visualizações.

Cada visualização arquitetural trata de um conjunto específico de interesses, específicos dos investidores no processo de desenvolvimento: usuários finais, designers, gerentes, engenheiros de sistema, mantenedores e assim por diante. Isso serve como um meio de comunicação entre o arquiteto de software e outros membros da equipe do projeto, com relação a decisões significativas do ponto de vista da arquitetura, tomadas a respeito do projeto.

Definir uma arquitetura candidata, refinar a arquitetura, analisar o comportamento e projetar componentes do sistema são a "essência" da disciplina Análise e Design e da Boa Prática: Utilizar Arquiteturas de Componentes.

6. Protótipo - Construir e Testar o Produto IncrementalmentePara o início da página

O RUP é uma abordagem iterativa de criação, de teste e de avaliação de versões executáveis do produto, a fim de afastar os problemas e resolver os riscos e as questões o mais cedo possível.

Construir e testar incrementalmente os componentes do sistema são a "essência" das disciplinas Implementação e ../../process/workflow/ovu_test.htm -- This hyperlink in not present in this generated website Teste e da Boa Prática: Desenvolver Iterativamente.

7. Avaliação - Avaliar os Resultados Regularmente

A comunicação aberta contínua com dados objetivos originados diretamente de atividades em andamento e as configurações do produto em desenvolvimento são importantes em qualquer projeto.  As avaliações de status regulares fornecem um mecanismo para tratar, comunicar e resolver problemas de gerenciamento, problemas técnicos e riscos do projeto.  Além de identificar os problemas, é necessário designar cada um deles a uma data de expiração e a uma pessoa responsável pela resolução.  Isso deve ser acompanhado e atualizado regularmente, conforme necessário.

Essas imagens fornecem informações ao gerente de projeto sobre o andamento. Embora o período possa variar, a função de determinação precisa capturar o histórico do projeto e tomar decisões para remover qualquer obstáculo ou gargalo que impeça o andamento.

A Avaliação de Iteração captura os resultados de uma iteração, o grau em que os critérios de avaliação foram atendidos, as lições aprendidas e as alterações do processo a serem implementadas.

A Avaliação de Iteração é um artefato essencial da abordagem iterativa. Dependendo do escopo e risco do projeto e da natureza da iteração, ela pode variar de um simples registro de demonstração e de resultados a um registro de revisão de teste formal e completo.

O importante aqui é o foco nos problemas do processo, bem como nos problemas do produto: "Quanto antes você alcançá-los, mais tempo terá para superá-los."

8. Controles de Mudanças - Gerenciar e Controlar MudançasPara o início da página

Assim que o primeiro protótipo for colocado diante dos usuários (e muitas vezes antes disso), as alterações serão solicitadas. (Uma daquelas certezas da vida.) Para controlar essas mudanças e gerenciar eficazmente o escopo do projeto e as expectativas dos investidores, é importante que todas as mudanças em quaisquer artefatos de desenvolvimento sejam propostas por meio de Controles de Mudanças e gerenciadas com um processo consistente.

As Solicitações de Mudança são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das Solicitações de Mudança é que elas fornecem um registro de decisões e, devido a seu processo de avaliação, garantem que os impactos da possível mudança sejam compreendidos por todos os membros da equipe do projeto. As Solicitações de Mudança são essenciais para o gerenciamento do escopo do projeto, bem como para a avaliação do impacto das mudanças propostas.

Gerenciar e controlar o escopo do projeto, à medida que as mudanças ocorrem em todo o ciclo de vida do projeto, e ao mesmo tempo manter a meta de considerar todas as necessidades dos investidores e atendê-las ao máximo possível - esta é a "essência" da disciplina Gerenciamento de Configuração e Mudanças e da Boa Prática: Controlar Mudanças.

9. Suporte ao Usuário - Implementar um Produto UtilizávelPara o início da página

A finalidade de um processo é produzir um produto utilizável.  Todos os aspectos do processo devem ser adaptados considerando essa meta.  O produto é normalmente mais do que apenas o software.  No mínimo, deve haver um Guia do Usuário, talvez implementado por meio da ajuda on-line.  Também é possível incluir um Guia de Instalação e as Notas sobre o Release.  Dependendo da complexidade do produto, os materiais de treinamento também podem ser necessários, bem como uma lista de materiais juntamente com qualquer pacote do produto.

10. Processo - Adotar um Processo que se Ajuste ao ProjetoPara o início da página

É essencial que seja escolhido um processo que se ajuste ao tipo de produto que está sendo desenvolvido. Mesmo depois que um processo é escolhido, ele não deve ser seguido às escuras - o bom senso e a experiência devem ser aplicados para configurar o processo e as ferramentas para atender às necessidades da organização e do projeto.

A adaptação de um processo para um projeto é uma parte importante da ../../process/workflow/ovu_env.htm -- This hyperlink in not present in this generated website disciplina Ambiente.

Para obter informações adicionais sobre como adaptar o RUP ao projeto e à organização, consulte: ../../process/workflow/environm/co_polpr.htm -- This hyperlink in not present in this generated websiteConceitos: Adaptação do RUP.

ConclusãoPara o início da página

Os "elementos essenciais" acima fornecem um meio de avaliar rapidamente um processo e identificar áreas em que o aprimoramento é mais vantajoso.  É importante explorar o que ocorrerá se um desses elementos essenciais for ignorado.  Por exemplo:

  • Sem visão? Você pode perder o rumo e ser facilmente confundido em desvios.
  • Sem processo? Sem um processo comum, a equipe pode ter comunicações e compreensões errôneas sobre quem vai fazer o quê e quando.
  • Sem plano? Você não conseguirá acompanhar o andamento.
  • Sem lista de riscos? Você pode estar se concentrando nas questões erradas atualmente e pode explodir em uma mina inesperada daqui a cinco meses.
  • Sem caso de negócio? Você se arrisca a perder tempo e dinheiro no projeto. Ele pode ser cancelado ou ir por água a baixo.
  • Sem arquitetura? Você pode não conseguir lidar com questões de comunicação, de sincronização e de acesso a dados, conforme elas surgem. Pode haver problemas com a capacidade de ajuste e o desempenho.
  • Sem produto (protótipo)? Assim que possível, coloque um produto na frente do cliente. O simples acúmulo de papéis não garante a você ou ao cliente que o produto será bem-sucedido e aumenta o risco de overruns de orçamento e planejamento e/ou de defeito direto.
  • Sem avaliação? Não finja que não é com você. É importante encarar a verdade. Quão próximo você realmente está do prazo? Das metas em qualidade ou do orçamento? Todas as questões estão sendo adequadamente acompanhadas?
  • Não há solicitações de mudança? Como você acompanha as solicitações dos investidores? Como você as prioriza? E impede que as de prioridade mais baixa passem despercebidas?
  • Sem suporte ao usuário? O que acontece quando um usuário tem uma pergunta e não consegue entender como utilizar o produto?  Com que facilidade se obtém ajuda?

Esses "elementos essenciais" também fornecem uma introdução para cada uma das disciplinas do RUP e para muitas de suas boas práticas



Rational Unified Process   2003.06.15