Requisitos - XIII

Análise

A etapa de análise é a etapa na qual se faz o levantamento da necessidade existente e define-se de que forma o software a ser criado deverá solucionar esta necessidade.

Em alguns ambientes os desenvolvedores tem o mal costume de pular a etapa de análise passando diretamente a etapa de desenvolvimento. Isso causa frequentemente falhas na definição do software, ou seja, descobre-se após o desenvolvimento que o que foi feito não atende a necessidade existente.

Divisões da etapa de análise

• Levantamento de informações
• Desenho de processo (Use Cases)
• Modelagem de Dados (MER)
• Modelagem do sistema
• Prototipação
• Definições finais

Levantamento de Informações (Analista de Requisitos e de Sistema)

Nesta etapa o analista realiza o levantamento de informações com o usuário. O analista faz uso de muitas entrevistas com o usuário para descobrir as necessidades existentes.

• O analista deve estar atento as informações fornecidas pelo usuário, cada detalhe mencionado por usuário as vezes pode resultar em mudanças no planejamento que o analista já estava realizando.
• O analista não deve se confundir quando o usuário tentar indicar como algo deve ser feito fisicamente (estrutura de tabela, tela, programas, etc.). O usuário não tem conhecimento técnico para fazer essa indicação, o analista deve extrair do usuário apenas as especificações ligadas ao negócio da empresa.
• Nem sempre o usuário tem todas as informações que o analista precisa. Muitas vezes o usuário tem uma informação sobre o seu trabalho no momento, mas a diretoria tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de conhecimento do usuário. Assim sendo o analista deve consultar outras pessoas além dos usuários da aplicação.

Desenho de Processo

• O desenho de processo é realizado com os dados colhidos no levantamento de informações. É uma demonstração gráfica da forma de funcionamento do negócio descrito pelo usuário.
• O desenho de processo é utilizado para apresentar o resultado do levantamento ao usuário. Na verdade as duas etapas são recorrentes, caso o usuário identifique erros no desenho de processo volta-se ao levantamento para acerta-los e assim consecutivamente até que o usuário aprove o desenho de processo.

Modelagem de Dados

Tendo o desenho de processo sido realizado parte-se para o modelo de dados. A criação do modelo de dados irá novamente se utilizar das informações obtidas durante o levantamento, mas poderá também ter necessidade de novas informações e obrigar o analista a retornar para a etapa de levantamento.

• O modelo de dados não é tão compreensível para um usuário leigo como o desenho de processo, portanto apresenta-lo ou não ao usuário pode ser uma decisão do analista.
• O modelo de dados deve ser dividido em lógico e físico, um estando mais próximo das características do negócio enquanto o outro demonstrando características físicas do banco de dados.
• O analista de sistemas nem sempre é um DBA, portanto o modelo de dados deve ser aprovado pela equipe de administradores de dados.
• Tendo o modelo de dados sido aprovado gera-se um script 0 do banco de dados, o script inicial deste banco
• Toda futura alteração do modelo de dados deve  ter a aprovação do DBA, que aproveita seu conhecimento das alterações para se preparar para a fase de implantação. As alteração são realizadas na forma de scripts evolutivos do banco de dados de forma a complementarem o script 0. Assim sendo ganha-se uma sequencia histórica de mudanças realizadas no banco de dados.

Modelagem do Sistema

Feita a modelagem de dados, modela-se o sistema que irá manipular esses dados. Pode-se utilizar DFDs, típicos da análise estruturada, ou diagramas de classe e Sequências, típicos da análise orientada a objetos.

• Obtêm-se como resultado desta etapa descrições gráficas dos módulos que serão gerados no sistema, quer sejam formulários/funções em aplicações estruturadas quer sejam classes/componentes em aplicações orientadas a objeto.
• Todas as etapas de análise são interligadas. A modelagem do sistema pode afetar todas as etapas anteriores, eventualmente exigindo que o analista retorne ao levantamento.
• É papel do analista, durante este processo, realizar suposições sobre diversas situações de negócio que porventura o usuário não tenha imaginado, garantindo assim que o sistema funcione de forma flexível mesmo frente a situações inesperadas. 

Prototipação

Feita a modelagem do sistema parte-se então para a construção do protótipo.

• O protótipo é um modelo das telas do sistema que tem por intenção obter do usuário a aprovação da navegabilidade do sistema e da forma como suas funcionalidades serão visualmente implementadas. 

Definições finais

Tendo obtido a aprovação do usuário para o desenho de processo e o protótipo a fase de análise encontra-se concluída em sua etapa mais formal.

Da fase de análise obtêm-se definições sobre como serão as fases seguintes:

• A partir das definições de análise é possível desenvolver um cronograma de execução
• A partir do cronograma e das necessidades do usuário é possível prever o pessoal que deverá ser envolvido nas fases seguintes do projeto (qtd. Desenvolvedores)
• A partir das informações acima é possível fazer uma previsão de custo do projeto e a partir desta informação a diretoria identifica sua real viabilidade.

Curiosidades sobre a etapa de análise

A etapa de análise na verdade não termina. Mesmo durante as etapas seguintes a análise continua a ocorrer,  se aprofundando mais tecnicamente no sistema. Eventualmente descobre-se na etapa de codificação novas características do negócio que alteram definições feitas em análise.

• O analista é, em geral, um gerente de projetos. Após a etapa de análise ele estará gerenciando os desenvolvedores na execução da especificação do sistema.
• O analista é em geral um já foi um desenvolvedor, mas que adquiriu um linguajar de negócios que permite que ele se comunique com os usuário na mesma língua destes, podendo desta forma extrair informações durante o levantamento.
• Quando desenvolvedor é comum que o analista não esteja 100% atualizado com as tecnologias atuais. 

Desta forma nem sempre o analista consegue realizar as melhores opções em termos de tecnologia para o projeto e, nos piores casos, o analista chega a ter dificuldade de falar com os desenvolvedores. Neste caso é necessária a presença de um outro personagem, o arquiteto do sistema, que tem por finalidade definir as tecnologias a serem aplicadas para execução do projeto, definir as metodologias de desenvolvimento a serem usadas pelos desenvolvedores e fazer a tradução entre o analista e os desenvolvedores quando necessário. 

A equipe de suporte deve trabalhar em conjunto do analista ou do arquiteto do projeto na definição física do projeto, iniciando uma especificação de equipamentos que serão necessários ao projeto.

Grande Abraço,

Gilberto Ribeiro.