Relatório Maquina de Turing

...

O intuito desse trabalho é mostrar a aplicação da metodologia UML através de um estudo de caso, utilizando também conceitos e metodologias de Análise de pontos de função (APF) para estimativa de custo e prazo para o desenvolvimento de um software, e a linguagem orientada objeto.

- ESTUDO DE CASO

O estudo de caso proposto (Anexo A) diz respeito a um grupo de amigos que, após um reencontro, decidem criar uma empresa de desenvolvimento de soluções em tecnologia da informação (TI). A oportunidade que esse grupo de amigos se deparam é a de um edital lançado publicado por um órgão federal para a contratação da modelagem de um sistema de estimativa e medição funcional de projetos de software.

- Analise do problema e soluções existentes

Os sistemas atualmente disponíveis ao órgão federal são basicamente planilhas ou aplicações móveis incipientes, o que não traz agilidade nem confiança nos resultados obtidos, já que planilhas são susceptíveis a alterações por parte do usuário, além de não serem tão dinâmicas e interativas como softwares e aplicativos, e aplicativos incipientes geralmente estão em fase de teste e podem conter erros ou soluções reduzidas.

Como solução, o grupo de amigos escolheu método da FPA como métrica para estimativa e medição funcional de projetos de software, e a metodologia UML para definição e gerenciamento do sistema.

A primeira etapa da análise do problema consistiu em um brainstorming para coleta de entendimento sobre o problema proposto e possíveis soluções. Uma tabela “Processo de Resolução de Problemas” foi gerado através das discussões em grupo (Apêndice A), e as próximas etapas para a solução do problema e desenvolvimento do sistema foram definidas.

2.2 Levantamento e validação dos Requisitos

O desejo do usuário Órgão Federal é que seja criado um sistema que estime e meça projetos de softwares, visando atender, de forma continuada, às necessidades desse órgão em processos de contratação de produtos e serviços de software, sendo assim foram definidos os seguintes requisitos funcionais:

- Permitir ao usuário a entrada dos elementos de contagem: AIE, ALI, SE, EE, CE; cada tipo de elementos de contagem pode ter quantas ocorrências forem necessárias pelo sistema que o usuário está estimando.

- Permitir ao usuário a entrada do valor unitário (valor/ponto de função), esforço (ponto de função/hora), número de programadores que trabalharão no projeto, horas de dedicação, e seleção da linguagem a ser utilizada;

- Permitir ao usuário determinar a complexidade de cada tipo funcional, baseado na contagem dos Tipos de Elementos de Dados (DET) e Tipos de Elementos de Registro (RET);

- O sistema deve correlacionar os DET e RET de forma a obter o grau de complexidade;

- Permitir ao usuário entrar com os pesos das 14 Características Gerais do Sistema (CGS);

- O sistema deve calcular o grau de influência e o Fator de Ajuste do Valor (VAF);

- O sistema deve calcular o valor do ponto de função ajustado;

- Sistema deve cadastrar e guardar análises ou projetos, bem como todas as informações atribuídas à mesma;

- Sistema deve permitir a alteração das informações cadastradas;

- Sistema deve permitir a geração de relatório em tela e impresso para cada projeto cadastrado, informando dados mais relevantes como dados cadastrais, número de pontos de função ajustado, custo e tempo.

Como requisitos não funcionais, podemos destacar:

- Sistema deve ser interativo e seguir as etapas para cálculo de pontos de função;

- Ferramenta deve ser de fácil manuseio e autoexplicativo;

- Aplicação dos diagramas UML

- Atores do sistema

Foi identificado apenas um ator para o sistema em questão, que foi chamado de “Usuário”. Este ator tem a função de cadastrar os sistema e projetos aos quais deseja-se estimar o custo e tempo de desenvolvimento, além de cadastrar as informações necessárias para a efetuação dos cálculos, que são feitos de forma subsequente pelo sistema. Cabe também ao autor excluir projetos já salvos, altera-los, e solicitar relatórios.

- Diagrama de casos de uso

Para melhor visualização e entendimento do sistema, bem como sua interação com o usuário e entre si, foi feito o diagrama de caso de uso, apresentado através da figura 1.

Conforme supracitado, o sistema apresenta apenas um ator, que interage com o sistema com as funções de cadastrar sistema, cadastrar CGS, cadastrar funções de dados e transação, e fazendo consultas, sendo as três primeiras interações essenciais para o cálculo de PF, prazo e custo. Todos os outros casos de uso são de interação do sistema entre si para o cálculo de custo e prazo, e para geração dos relatórios quando requeridos.

Para melhor descrever todas as interações possíveis entre usuário – sistema e sistema – sistema, foi feito a análise alto nível para cada caso de uso, especificando a ação do ator, e a resposta que o sistema deve retornar, bem como os cursos alternativos de eventos, os pré-requisitos de interface e as pós-condições. A análise de alto nível pode ser encontrada no Apêndice B.

[pic 2]

Figura 1 - Diagrama de caso de uso

- Diagrama de classes

Um diagrama de classes foi desenvolvido e refinado para melhor entendimento das classes e suas associações, além de seus principais atributos e operações, propiciando uma visão mais aprofundada do sistema, necessária para o desenvolvimento do software solicitado.

Três classes principais foram definidas, sendo elas as classes “Sistema”, “CGS Sistema”, e “Funções Tipo Dados e Transações”, sendo está última a classe responsável pelo cálculo de custo e prazo, utilizando como base de dados informações contidas nas outras duas classes.

Todas as três classes devem receber informações do usuário e armazena-las no banco de dados, atribuindo