Após uma abordagem geral da análise e projeto orientados a objetos no artigo anterior, hoje vamos entrar em detalhes na fase de concepção do processo unificado (RUP).

A fase de concepção corresponde à primeira etapa do processo unificado, nela devemos gerar alguns artefatos para estudar a viabilidade do sistema. Nessa fase que vamos decidir se o sistema deve ser desenvolvido do zero, se podemos utilizar algo pronto e adaptar ou ainda se devemos desistir do mesmo, esta última acontece, na maioria das vezes, por não se chegar a um acordo entre a empresa desenvolvedora e o cliente com relação a custo ou outros fatores.

Essa fase não deve durar muito tempo, pois geralmente nela não se tem um contrato firmado entre as partes envolvidas.

No processo unificado (RUP) a fase de concepção tem algumas similaridades com a fase de iniciação do PMBoK (Project Management Body of Knowledge), pois ambas estudam o escopo inicial do projeto. O PMBoK possui dois processos na fase de iniciação, a proposta e o termo de abertura. Os artefatos da fase de concepção do RUP, que vamos ver mais adiante, ajudam a definir quais informações irão nesses documentos, por isso essas fases andam em paralelo em uma organização que deseja trabalhar tanto com o RUP, como metodologia de desenvolvimento, quanto o PMBoK para gerência de projetos.

O primeiro artefato da concepção é a descrição geral do projeto, ou sumário executivo. Nesse documento, o analista faz uma breve descrição do sistema, contendo os interesses do cliente, não é necessário descrever detalhadamente o funcionamento dos processos nessa fase, bastam uma ou duas páginas. As entrevistas iniciais com o cliente podem ajudar a elaborar esse documento e a identificar os requisitos do sistema.

Com a descrição geral feita, precisamos identificar os requisitos do sistema, tanto funcionais como não-funcionais. A diferença básica entre esses dois grandes grupos de requisitos é que nos funcionais, definimos O QUE o sistema DEVE fazer e nos não-funcionais, COMO o sistema DEVE fazer.

Alguns artefatos opcionais que podem ser fundamentais, dependendo do sistema, são:

• Glossário: Definição de termos utilizados para evitar conflitos entre aquilo que o analista quis dizer e o que o cliente realmente entendeu;
• Análise de riscos: Esse é um artefato muito importante para identificar possíveis riscos que possam acontecer durante o projeto. Devem ser levados em consideração, a possível causa, a probabilidade e o impacto. O PMBoK possui uma seção que trata somente sobre esse assunto, ele divide o gerenciamento dos riscos em seis processos: o planejamento da gestão de riscos, a identificação, a análise quantitativa e qualitativa, o planejamento de resposta aos riscos identificados e o monitoramento e controle;
• Protótipo e provas: Pode haver a necessidade de elaborar alguns protótipos de telas para esclarecer requisitos estão pendentes. Lembrando que esse procedimento deve ser realizado se tiver tempo disponível e se for realmente necessário.

O levantamento de requisitos nesse momento deve ser focado apenas com os requisitos que compõem os principais processos da empresa. Os requisitos funcionais podem ser classificados em evidentes, aqueles que o usuário interage diretamente, e ocultos, em que não existe o conhecimento explícito do usuário.

Provavelmente os requisitos funcionais terão alguma particularidade que deve ser identificada nos requisitos não-funcionais, que são restrições do sistema. Esses requisitos podem ser classificados por obrigatoriedade, sendo obrigatório ou desejado, e por permanência, sendo permanente ou transitório.

Os requisitos não-funcionais ainda podem ser classificados por atributos:

• Usabilidade: Consistência na interface, ajudas, estéticas, materiais para treinamento, acessibilidade, fatores humanos, etc;
• Confiabilidade: Tratamento de falhas, possibilidade de previsão, não erros de programação;
• Desempenho: Velocidade, eficiência, precisão, tempo de recuperação, tempo de resposta, uso de recurso, etc;
• Configurabilidade: O que pode ser configurado pelos usuários do sistema;
• Suportabilidade: Extensibilidade, adaptabilidade, compatibilidade, instalação, regionalização;
• Interface: Arquitetura da informação;
• Segurança: Permissões de usuários do sistema;
• Implementação: Linguagem, banco de dados, componentes, sistemas operacionais, etc;
• Empacotamento: Forma de entrega do sistema;
• Físicos: Material, peso, tamanho;
• Legais: Assessoria jurídica, cumprimento de leis;

Com os principais requisitos identificados, precisamos agora organizá-los. É nesse momento que os casos de uso de alto nível são descobertos, aqui devemos identificá-los atribuindo a eles os atores envolvidos e suas referências com os requisitos.

As referências cruzadas são usadas para garantir a rastreabilidade dos requisitos, tornando muito importante quando nos deparamos com a mudança dos requisitos, uma situação muito comum na maioria dos projetos. Através desse procedimento temos como saber o impacto que aquela mudança vai ocasionar, e criar um plano para tratar essa situação.

A organização dos requisitos também deve ser feita através das funções de conceitos, nesse caso pode ser necessário elaborar um modelo conceitual preliminar, para associar os conceitos.

Outra organização que deve ser feita é a das consultas e relatórios, que, na maioria dos casos, são as mais importantes, mas também as mais simples. Aqui devemos listar as consultas mais complexas e suas referências cruzadas.

É bom lembrar que o processo unificado trabalha com ciclos iterativos, a partir da fase de elaboração, por isso devemos planejar esses ciclos já na fase de concepção. Esse planejamento contém alguns itens importantes como, a estimativa de esforço, que pode ser feita utilizando técnicas de análise por pontos de função (APF) ou análise por casos de uso (UCP).

No planejamento também devemos ter em mente os casos de uso mais importantes, para priorizar seu desenvolvimento no ciclo iterativo. Podemos levar em consideração dois pontos importantes, o grau de complexidade e o grau de importância dos casos de uso.

Craig Larman, o pai da AOO (Análise Orientada a Objetos), criou algumas perguntas para ajudar no escalonamento dos casos de uso, são elas:

• Representa impacto direto na receita?
• Processo primário na linha de negócio?
• Requer suporte à persistência e provoca impacto no projeto de arquitetura?
• Oferecem rapidamente quantidade significativa nas informações?
• Funções de alto risco, críticas com relação ao tempo ou complexas?

Conforme as respostas das perguntas, temos como escalonar os casos de uso e priorizar o desenvolvimento.

Além disso, não podemos deixar de analisar os recursos disponíveis para o projeto, por isso é necessário a criação de um cronograma de execução e custos, que deve conter a duração dos ciclos iterativos. É recomendado que nesse momento sejam utilizadas técnicas de gerenciamento de tempo previstas no PMBoK.

Agora você deve estar pensando que são elaborados muitos documentos antes mesmo de começar o desenvolvimento. Com certeza, dependendo do projeto, alguns desses documentos não precisam ser feitos, mas precisamos ter em mente, que isso tudo é feito para garantir a qualidade do projeto, o tempo gasto agora é mais barato do que o tempo gasto na fase de construção do sistema.

Acaba por aqui nossa fase de concepção, em um próximo artigo estarei mostrando as próximas fases do processo unificado. Até a próxima.

This entry was posted on Monday, November 24th, 2008 at 8:07 am and is filed under Análise de Sistemas. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.