Introdução

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 no segmento de mercado, 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ão

Em particular, desenvolver uma Visão clara é importante para desenvolver um produto que atenda às necessidades reais dos   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. Ele comunica os principais questionamentos 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 Disciplina de requisitos e o princípio Equilibrar Prioridades do Investidor que Compete. 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 para o Plano

"O produto será apenas 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 disciplina de 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 nele.  Não importa a aparência dos planos ou as ferramentas utilizadas para construí-los.  Como disse Dwight D. Eisenhower, "O plano não é nada; o planejamento é tudo."

3. Riscos:  Mitigar Riscos e Rastrear 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 percebidos 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ócios:  Examine o Caso de Negócios

O Caso de Negócios 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 ROI (Retorno do Investimento) 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:  Projete uma Arquitetura de Componente

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 juntas?  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, 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 de Análise e de Design e o princípio Elevar Nível de Abstração.

6. Protótipo:  Progressivamente Construir e Testar o Produto

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 de Implementação  e Teste e o princípio Demonstrar Valor Iterativamente.

7. Avaliação:  Acessar 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.  Avaliações regulares de status fornecem um mecanismo para endereçar, comunicar e resolver problemas de gerenciamento, problemas técnicos e riscos do projeto.Além de identificar os problemas, é necessário designar a cada um deles uma data de expiração e 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 recuperar o terreno perdido."

8. Controle de Mudanças:  Gerenciar e Controlar Alterações

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.

Os Controles de Mudança são usados para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem dos Controles de Mudança é que eles 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. Os Controles de Mudanças 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 enquanto mantém a meta de considerar todas as necessidades dos investidores e atendê-las ao máximo possível - esta é a "essência" da disciplina de Gerenciamento de Mudanças e de Configuração e o Material de Suporte: Controlar Alterações.

9. Suporte ao Usuário:  Implementar um Produto Utilizável

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. As atividades associadas formam a disciplina de Implementação. 

10. Processo:  Adotar um Processo que se Ajuste ao Projeto

É 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 disciplina de Ambiente.

Para obter informações adicionais sobre como adaptar o RUP ao projeto e à organização, consulte: Conceito: Adaptação do RUP.

Conclusão

Os "elementos essenciais" acima fornecem um meio de avaliar rapidamente um processo e identificar áreas onde 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 um dos Agrupamentos de Disciplinas: Disciplinas de RUP do RUP e suporta seus Princípios Chave.