Uma primeira proposta de modelo de aplicação prática para ER foi proposta pelo autor desta dissertação (MOTTA, 2012). Este modelo foi construído com foco nos sistemas baseados em Web, utilizando princípios da ER e do desenvolvimento ágil.
As metodologias ágeis propõem a obtenção de resultados de forma prática e em um período menor de tempo do que as demais metodologias. Fazem isso tirando o foco do processo e colocando no produto, considerando a qualidade final do produto mais importante do que os métodos utilizados (BASSI FILHO, 2008).
O Manifesto Ágil, origem dos métodos ágeis, apresenta quatro valores fundamentais (SATO, 2007): (i) os indivíduos e suas interações são mais importantes do que procedimentos e ferramentas; (ii) o funcionamento do software é mais importante do que documentação abran- gente; (iii) a colaboração dos clientes é mais importante do que a negociação de contratos; (iv) a capacidade de resposta a mudanças é mais importante do que um plano pré-estabelecido.
O método utilizado pelo modelo é a Programação Extrema, ou XP. Seus valores funda- mentais de comunicação, simplicidade, feedback, coragem e respeito são as referências para as funcionalidades do aplicativo. Apesar de não gerarem uma documentação tão detalhada, os métodos ágeis fornecem documentação suficiente para a gestão do sistema, e em um tempo bastante reduzido.
O Método XP defende que a comunicação intensa entre os envolvidos reduz os proble- mas no projeto. Neste sentido, o aplicativo resultante do modelo deveria rodar na Internet, fi- cando disponível para acesso a qualquer hora para qualquer um dos interessados. Desta forma, mesmo que o cliente estiver sem tempo para uma reunião com o gerente de projeto, ele poderá acompanhar e interagir com projeto sempre que desejar.
Como as partes envolvidas acompanham e interagem com o projeto através de um mesmo ambiente, o feedback é constante entre todos. A estrutura de análise gerada pelo modelo objetiva facilitar a tomada de decisões, pois com informações claras e organizadas a equipe tem mais facilidade de tomar ou mudar suas decisões.
2.4.1 Técnicas de levantamento de requisitos usadas no modelo
O modelo faz uso das seguintes técnicas de levantamento de requisitos: (i) entrevista; (ii) questionário; (iii) análise de documentos; (iv) reuniões. As entrevistas são conversas com perguntas previamente planejadas que irão definir os requisitos iniciais do sistema, seu formato “pergunta-resposta” fornece uma abordagem que facilita os primeiros contatos com o cliente. O registro da entrevista pode ser feito em um editor de texto, tornando o processo rápido e simples e ainda permitindo que ao final de cada entrevista o documento gerado seja enviado ao entrevistado para revisão.
Após as entrevistas podem surgir especificações vagas ou que necessitam de consulta a um grande número de usuários. Para esses casos, são aplicados questionários, preferencial- mente apenas com questões objetivas, usando questões subjetivas apenas quando não houver uma resposta objetiva para a questão. A aplicação dos questionários deve ser feita em ambiente on-line, de forma a adequar-se aos locais e horários dos envolvidos.
A análise de documentos busca informações através de normas, formulários, documen- tos de sistemas legados e qualquer outro tipo de documento envolvido na rotina que está sendo especificada. Essas informações são usadas para preencher lacunas deixadas pelos envolvidos nas etapas anteriores. No entanto, quando se trata de normas ou leis, deve-se partir direto para a análise documental, pois dificilmente um usuário conseguirá transmitir seu conteúdo através de outra técnica de levantamento de requisitos.
A reunião é uma técnica focada em grupos de stakeholders, trabalhando em um ambi- ente compartilhado, onde diferentes envolvidos expressam suas opiniões sobre suas necessida- des e também sobre as necessidades apresentadas pelos outros. Isso permite verificar se os re- quisitos coletados com os indivíduos estão de acordo com a necessidade da empresa. Como as etapas anteriores já geraram vários requisitos para alimentar o aplicativo, o próprio modelo gerado pode ser usado para documentar a reunião, de forma que as decisões tomadas sejam imediatamente refletidas no projeto.
2.4.2 Prototipação
Para auxiliar os processos de análise, o modelo sugere o uso da técnica de prototipação, dividida em duas etapas: (i) protótipo não operacional e (ii) protótipo operacional.
O protótipo não operacional possui apenas as interfaces de entrada e saída de dados, sem realizar nenhum processamento, visando demonstrar o comportamento básico do sistema de forma rápida e com um custo bastante reduzido. Ao navegar por este protótipo, o usuário tem uma visualização mais amigável dos requisitos especificados para o sistema, auxiliando o mesmo na validação, correção e descarte destes requisitos e também na adição de novos.
Após a validação dos requisitos envolvidos no primeiro protótipo, é o momento de cons- truir um protótipo que realize o processamento, o protótipo operacional. Neste ponto já se tem conhecimento das entradas do sistema e quais devem ser as respostas para estas ações. O pro- tótipo operacional ajuda a definir a forma como o sistema irá tratar esses dados, incluindo as restrições que devem ser obedecidas pelo software.
Para aumentar a eficiências e reduzir custos durante esta etapa, são construídos vários protótipos operacionais, cada um abordando uma funcionalidade ou um conjunto de funciona- lidades do sistema. Isso facilita tanto o processo de validação por parte do usuário, quanto a correção de erros por parte da equipe de desenvolvimento.
2.4.3 Estrutura do modelo de aplicação
O uso de uma ferramenta de apoio viabiliza uma boa gestão dos requisitos do sistema (PRESSMAN, 2011). Com base nos conceitos abordados pelo modelo foi criado um aplicativo de gestão de requisitos usado no levantamento, análise, validação e gestão dos requisitos.
Os requisitos são manipulados apenas pela equipe de desenvolvimento, mas todos os envolvidos podem solicitar alterações a qualquer momento. A participação constante do cliente no processo de desenvolvimento do sistema traz mais segurança à equipe de desenvolvimento e ao próprio cliente, pois permite o refinamento dos requisitos de forma prática e ágil. O apli- cativo permite documentar as definições dos requisitos do sistema e suas alterações ao longo do desenvolvimento do sistema.
Inicialmente, o nível mais alto de agrupamento dos dados do modelo era o projeto. No entanto, após a aplicação da proposta em projetos reais, houve a necessidade de inclusão de um nível de organização acima do projeto, o sistema. Esta alteração surgiu devido ao sistema em desenvolvimento agrupar vários projetos ao longo da construção de suas funcionalidades, cada um com especificações, recursos e cronogramas próprios. O modelo ficou organizado da se- guinte forma:
a) O sistema, nível mais alto de agrupamento, engloba todos os projetos que compõe o de- senvolvimento de suas funcionalidades;
b) O projeto de desenvolvimento, especificado e gerenciado pelo modelo, possui como atri- butos: cliente, nome do projeto, gerente do projeto, resumo, fase, data de cadastro e equipe de desenvolvimento do projeto;
c) Os objetivos do projeto;
d) Estrutura e funcionalidades, organização e definições das especificações do sistema, con- tendo: (i) módulos ou processos do sistema, (ii) submódulos ou tarefas do sistema, (iii) requisitos funcionais ligados aos módulos ou submódulos, (iv) requisitos não funcionais do sistema como um todo, (v) perfis de acesso aos módulos e submódulos, (vi) quadro de requisitos divididos por estado (em aberto, em andamento, com pendência ou concluído). e) O cronograma do projeto dividido por módulos, com descrição de prazos e custos, e de-
finição explícita da ordem de prioridade existente entre os módulos;
f) As demandas, canal de comunicação para que o cliente possa interagir com o projeto, demandando alterações de quaisquer itens do projeto. Serve também como registro destas alterações, podendo ser usada para justificar eventuais atrasos.