Este estudo de caso é o Capítulo V da minha monografia de Especialização em Engenharia de Software. Espero que possa ser útil de alguma forma para o leitor.
Introdução
Este capítulo apresenta um estudo de caso prático de estimação num contexto comum de um projeto de desenvolvimento de software em uma empresa a fim de ilustrar a aplicação dos conceitos apresentados neste trabalho.
Contexto
Uma empresa de desenvolvimento de software trabalha primariamente com softwares “de prateleira” (Commercial Off-The-Shelf – COTS) e faz adaptações sob demanda para seus diversos clientes no segmento financeiro. Um projeto de desenvolvimento pode ser criado quando se identifica a necessidade de um novo sistema ou a partir da solicitação de clientes para implementação de novas funcionalidades ou modificações nas já existentes.
Os sistemas são desenvolvimentos na plataforma Java com arquitetura web, onde o usuário acessa através de um navegador web. A arquitetura dos sistemas adota o padrão Model-View-Controller (MVC). O model (modelo) consiste em um conjunto de componentes que disponibiliza serviços que realizam cálculos, atualizam as entidades do sistema e fazem integrações com outros sistemas. A view (visão) consiste num conjunto de tecnologias para geração de interfaces web exibidas no navegador do usuário a partir dos dados do model. O controller (controlador) consiste em um componente que recebe ações e dados do usuário, atualiza o model e redireciona o usuário para a view adequada.
No início de um projeto, a elicitação dos requisitos é realizada por um analista de negócios, que cria o artefato chamado de Especificação de Requisitos de Software (ERS). A ERS pode conter, além dos requisitos, o design da solução. O design pode ser feito pelo analista de negócios quando este entende da solução ou por um Analista de Sistemas da equipe. Então o gerente do projeto, cujo papel é geralmente desempenhado pelo coordenador da equipe que irá desenvolver o software, faz o planejamento e a estimação inicial.
No planejamento, o gerente cria um cronograma, que pode um gráfico de Gantt contendo as atividades de desenvolvimento e testes para cada funcionalidade da ERS. A partir dessas informações é possível negociar o prazo com o cliente e alocar a equipe de acordo com o esforço necessário.
O processo de desenvolvimento da empresa pode ser no modelo Waterfall ou iterativo, dependendo do tamanho do projeto e da necessidade do cliente. Porém, o desenvolvimento não é incremental, sendo a implementação das funcionalidades simplesmente distribuída sequencialmente pelo projeto.
Detalhes do projeto
Uma nova funcionalidade de “estorno de aditamento” de contrato financeiro foi solicitada em um dos sistemas da empresa. Um novo projeto foi iniciado para tratar esta demanda.
Um aditamento consiste em uma alteração contratual realizada a partir do segundo mês de vigência do contrato, pois alterações dentro do mês de entrada não caracteriza um aditamento.
Um estorno de aditamento consiste em desfazer as alterações realizadas no processo de aditamento considerando todos os impactos nas integrações com outros sistemas e restaurando todos os aspectos originais do contrato antes do aditamento.
O diagrama a seguir ilustra os casos de uso relacionados a aditamento:
Figura 12 – Casos de Uso do projeto do Estudo de Caso
Ambos os conceitos são de domínio da equipe, pois funcionalidades semelhantes já foram implementadas diversas vezes, porém sem registros de tempo das atividades realizadas, de modo que não há dados históricos para a estimação no projeto atual.
Como há somente uma funcionalidade no projeto, o desenvolvimento seguirá o modelo Waterfall. Os requisitos serão elicitados, depois serão feitos o design e o planejamento de todo o projeto, seguidos pela estimação do esforço. Após o desenvolvimento da nova funcionalidade, uma versão executável do sistema será enviada para testes e então disponibilizada para o usuário final.
Correções serão realizadas durante a fase de testes internos da empresa e também, quando problemas ocultos forem encontrados durante os testes de aceitação dos usuários finais do sistema.
Análise e Design da Solução
O estorno de aditamento consiste em desfazer o aditamento de um contrato, portanto foi realizado um levantamento da funcionalidade de aditamento já existente e verificou-se que ela afeta vinte e duas entidades do sistema cujos dados são armazenados em tabelas no banco de dados. Logo, o estorno deverá restaurar o estado de todas essas tabelas. O diagrama de sequência abaixo ilustra, em alto nível, o processo de estorno de aditamento:
Figura 13 – Diagrama de Sequência da funcionalidade de Estorno de Aditamento
A fim de restaurar o estado anterior de uma entidade é necessário que exista um histórico de alterações. Algumas entidades já possuem tal histórico, enquanto doze delas não. Entretanto, as entidades que não possuem informações históricas não serão modificadas para minimizar o impacto nas demais funcionalidades do sistema. Tabelas de dados históricos auxiliares serão criadas, contendo os mesmos atributos de entidade e a data em que ocorreu a alteração. A funcionalidade de aditamento será alterada de modo que os dados anteriores de todas as entidades modificados sejam armazenados nessas tabelas de dados históricos.
No aditamento, uma interface de integração com um sistema de contabilidade é acionada através de serviços de componentes de software. No estorno do aditamento, deve ser acionado o serviço correspondente para gerar o efeito contrário do aditamento anterior.
Além disso, conforme o padrão dos sistemas da empresa, esse tipo de funcionalidade contará com duas interfaces com o usuário. A interface de pesquisa de contratos listará os contratos que foram aditados, contendo alguns filtros e uma tabela com o resultado, a qual permitirá selecionar um dos contratos para a realização do estorno. A interface de confirmação do estorno exibirá os dados do contrato após a seleção de um dos contratos na pesquisa e permitirá a confirmação do estorno do aditamento.
Os componentes do model do sistema deverão disponibilizar o serviço de pesquisa dos contratos aditados com os devidos filtros e o serviço principal que efetuará o estorno do aditamento do contrato selecionado. Os serviços serão acionados pelos controllers, que, por sua vez, acionarão as views para exibir as interfaces do usuário.
O cenário de uso básico do sistema está representado no Diagrama de Atividades abaixo:
Figura 14 – Diagrama de Atividades da funcionalidade de Estorno de Aditamento
Estimação através da técnica de Pontos de Função
Através dos dados da análise e do design da funcionalidade de estorno de aditamento, obteve-se a tabela abaixo, a qual contém as entradas necessárias para a técnica de estimação por pontos de função:
Tabela 7 – Tabela com contagem de Pontos de Função do Estudo de Caso
| Valor do Domínio | Contagem | Simples | Médio | Complexo | |||||
|---|---|---|---|---|---|---|---|---|---|
| Entradas Internas | 2 | x | 3 | 4 | 6 | = | 6 | ||
| Saídas Externas | 2 | x | 4 | 5 | 7 | = | 8 | ||
| Consultas Externas | 1 | x | 3 | 4 | 6 | = | 6 | ||
| Arquivos Lógicos Internos | 1 | x | 7 | 10 | 15 | = | 15 | ||
| Arquivos de Interface Externa | 0 | x | 5 | 7 | 10 | = | 0 | ||
| Contagem Total | 35 |
Existem duas Entradas Internas, que são as duas interfaces com o usuário, pois tanto na pesquisa quanto na tela de confirmação o usuário deve interagir com a tela. As duas interfaces também são Saídas Externas, pois exibem dados dos contratos aditados. Elas são consideradas simples por possuírem poucos dados de entrada. Além disso, existe uma Consulta Externa, que consiste na integração com o sistema de contabilidade através do acionamento de um serviço de retorno imediato, a qual é considerada complexa por possuir mais um conjunto de dados com mais de quinze elementos. Além disso, existe um Arquivo Lógico Interno, isto é, apenas um conjunto de dados identificável pelo usuário. Apesar de vinte e duas tabelas ordinárias serem afetadas, mais as doze tabelas de dados históricos que deverão ser criadas, as diversas rotinas CRUD reutilizadas e criadas não acrescentam complexidade. Por último, não existem Arquivos de Interface Externa.
Os seguintes fatores de ajuste (Fi) foram identificados:
- item 4, desempenho crítico, com valor 3;
- item 5, ambiente intensamente utilizado, com valor 2;
- item 10, processamento complexo, com valor 5.
Aplicando os valores obtidos na equação da técnica de estimação utilizada, o valor total de pontos de função resultante foi de 26,25.
É necessário multiplicar os pontos de função por um fator de horas por ponto de função de modo a estimar o esforço. Embora não haja dados históricos para apoiar a estimação no projeto atual, é possível estimar com base em dados médios registrados por organizações reconhecidas.
O Brazilian Function Point Users Group (BFPUG, 2013) apresenta diversas medidas de horas por ponto de função. Para a plataforma Java, as médias variam de 10 a 60 horas por pontos de função. Considerando a estimativa mais otimista, a funcionalidade de estorno de aditamento demandaria cerca de 260 horas de trabalho ou, utilizando como base o número de 160 horas de trabalho em um mês, o desenvolvimento levaria pouco mais de um mês e meio, contando com um desenvolvedor.
Com base no total de pontos de função estimados, é possível ainda derivar a estimação do tamanho do software em linhas de código (LOC). Pressman (2006, p. 505) apresenta uma tabela onde a linguagem Java possui uma média de 63 linhas por pontos de função. Assim, pode-se estimar o desenvolvimento de 1.653,75 linhas de código para a funcionalidade de estorno de aditamento.
Análise dos resultados
A estimativa de esforço obtida através da técnica de estimação por pontos de função é razoável quando comparada com o julgamento de um especialista, isto é, alguém com conhecimento sobre o software e o requisito em questão.
Entretanto, caso o desenvolvimento da funcionalidade do estudo de caso fosse realizado por um desenvolvedor com pouca experiência ou pouco conhecimento do software, a estimação deveria ser feita com base num número de horas por ponto de função mais pessimista.
Conclusão
O estudo de caso ilustra uma situação comum das empresas de desenvolvimento de software e exemplifica a aplicação de uma técnica de estimação de software.
A análise crítica do resultado de uma estimação é importante para evitar que equívocos no detalhamento das funcionalidades gerem grandes distorções. Caso o resultado gere desconfiança no estimador, deve-se revisar cada passo da estimação.
Além disso, embora coeficientes genéricos como a média de horas por pontos de função possam ser utilizados inicialmente, é essencial registrar os dados do desenvolvimento para uso em estimações futuras a fim de se obter um coeficiente mais adequado para o cálculo de esforço, que resulte em estimativas mais próximas à realidade no contexto do projeto e da equipe.
