Desenvolvimento com engenharia: um caso de sucesso

Sidnei Feliciano

No início de março de 2007 recebemos na área administrativa uma solicitação da Ouvidoria para o desenvolvimento de um sistema que controlasse as mais de 8000 manifestações que recebiam anualmente, gerando um resultado estatístico do que foi realizado, acompanhando o encaminhamento e as soluções dos problemas apresentados.

No processo de análise, a primeira etapa foi o estudo de viabilidade. Procuramos sistemas que pudessem atender à necessidade, inclusive em outros Tribunais. Não encontramos nenhum que se adequasse. Esta pesquisa se extendeu por cerca de um mês na busca, teste e análise de softwares.

Decidiu-se, então, iniciar o projeto do software. Após diversas entrevistas com a equipe da Ouvidoria, modelamos uma série de casos de uso e documentamos em mais de 15 especificações. A documentação foi produzida toda com o MS-Word, inclusive os protótipos de tela.

Para auxiliar no processo de análise e aperfeiçoamento dos modelos, produziu-se um site em HTML permitindo que o usuário visualizasse os resultados e a interação das telas. A ferramenta utilizada foi o NetObjects Fusion.

Produziu-se também como resultado desta etapa um modelo UML (Unified Modeling Language) conceitual, no qual podia-se mapear o contexto em que se inseria o sistema de Ouvidoria no ambiente estrutural do SIGA. Usamos o NetBeans como ferramenta UML para a geração dos modelos conceituais.

Esta etapa da análise, arquitetura e projeto da especificação durou cerca de 4 meses de muita modelagem e conversa com o usuário.

Com a aprovação dos requisitos, entregamos a documentação para apreciação do Rafael para que este identificasse o nível de complexidade de cada artefato e pudesse estimar o tempo para implementar cada um.

Já que não possuímos uma referência de métrica de software (como o cálculo de pontos de função), optamos por definir três níveis de complexidade: fácil, médio e difícil, atribuindo para cada situação uma quantidade de dias para realização.

Também encadeamos os artefatos na sequência necessária, como por exemplo, primeiro fazer o módulo de cadastro de manifestações, para depois fazer o módulo de encaminhamento.

Como ferramenta adicional para esta etapa, utilizamos o MS-Project.

Produzimos então, com a ajuda do MS-Project, três cronogramas: um para o desenvolvedor (mais apertado), um para o gestor do projeto e um outro mais longo para o usuário. Desta maneira, teríamos facilidade para gerenciar as dificuldades características da nossa área (atraso de cronograma é ruim especialmente para o usuário).

O Rafael foi alocado para o sistema de Ouvidoria logo após concluir algumas implementações no SIGA. Um situação não foi prevista no cronograma: as férias em dezembro do Rafael. Contudo, este imprevisto não afetou o projeto, recaindo na gestão do cronograma do gestor. O prazo para a entrega ao usuário é em março e o Rafael, depois que voltou de férias, está para liberar o sistema para a fase de testes.

Acredito que teremos a capacidade de entregar o sistema dentro do prazo. E ainda, vencendo um paradigma que sempre me assustou: o problema do cronograma que nunca é cumprido.

Confio este sucesso na metodologia empregada, oriunda de uma área na qual acredito que devemos nos apegar mais: a Engenharia de Software.