universidade do vale do itajaÍ centro de ciÊncias ...siaibib01.univali.br/pdf/bruno hasse...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
MÓDULO EDUCACIONAL PARA SISTEMAS WEB:
ESTUDO DE CASO COM ANÁLISE DE PONTOS DE FUNÇÃO
por
Bruno Hasse
Itajaí (SC), dezembro de 2013
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
MÓDULO EDUCACIONAL PARA SISTEMAS WEB:
ESTUDO DE CASO COM ANÁLISE DE PONTOS DE FUNÇÃO
Área de Engenharia de Software
por
Bruno Hasse
Relatório apresentado à Banca Examinadora
do Trabalho Técnico-científico de Conclusão
do Curso de Ciência da Computação para
análise e aprovação.
Orientadora: Adriana Gomes Alves. M.Eng.
Itajaí (SC), dezembro de 2013
Dedico este trabalho aos meus pais que apoiaram e acreditaram em mim e a
Márcia Antunes Pereira, pessoa que escolhi para seguir comigo por toda a vida.
AGRADECIMENTOS
Gostaria de agradecer a todos que contribuíram de alguma forma para o
desenvolvimento deste trabalho, em especial aos meus pais Harri Hasse e Janete Hasse, aos
meus irmãos Daniel Hasse e Fernanda Hasse Cabral, a minha namorada Márcia Antunes
Pereira, a minha orientadora Adriana Gomes Alves, aos meus avaliadores Jefferson Seide
Molléri e Fabiane Barreto Vavassori Benitti, aos meus amigos Haissam Yebahi, Pedro Ivo de
Borba Galimbert Rodriguês, Igor Avila, Ricardo Alexandre Nunes Pereira e Marcos João da
Silva, aos meus colegas de faculdade Felipe Simoni Dalcin, Hugo Leonnardo Blasckwsky
Tessaro, Ícaro Jarriee Marcon Boesing e Lucas Alves Selliach e ao sócio-proprietário da
2reach, Bruno Torquato.
“Penso, logo existo.”
- René Descartes
RESUMO
HASSE, Bruno. Módulo Educacional para Sistemas Web: Estudo de Caso com Análise
de Pontos de Função. Itajaí, 2013. 89 páginas. Trabalho Técnico-científico de Conclusão de
Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e
do Mar, Universidade do Vale do Itajaí, Itajaí, 2013.
O mercado atual de desenvolvimento de software está em crescimento acelerado, empresas
estão em busca de processos de gerência de projetos para obter sucesso e excelência nos
produtos desenvolvidos. Na fase de levantamento de requisitos, os envolvidos no projeto não
possuem conhecimento completo das características do produto que permita contabilizar sua
futura dimensão. Nesses casos é necessário estimar usando modelos de medição com menor
margem de erro às necessidades de comunicação e informação do projeto. Medição de
software é uma das mais simples e menos custosa medida de garantia de qualidade para o
sucesso do projeto de software, sendo possível saber se características de produto atendem ou
não o padrão de qualidade estipulado, auxiliando na tomada de decisão e no acompanhamento
de tarefas através de estimativas para determinar o esforço ou tempo para sua realização.
Acadêmicos e empresas que desejam adotar métricas não possuem uma ferramenta
educacional para apoio a aprendizagem de Análise de Pontos de Função, mas para realizar o
cálculo de pontos de função existem ferramentas web como o Sizify, porém, seu foco é no
analista de métricas, aquele que já conhece a técnica. O projeto propôs um módulo
educacional em forma de tutorial para o Sizify e um modelo de módulo educacional aplicável
em sistemas web. No desenvolvimento é utilizado Javascript por ser uma linguagem de
programação executada no cliente e ser de fácil inserção em sistemas web, o armazenamento
é feito por um XML, nele é armazenado o tutorial no qual o Javascript realiza a leitura. Foram
efetuados testes com dois sistemas, a avaliação resultou que a solução é capaz de auxiliar no
aprendizado de APF e que o padrão de tutorial pode ser inserido em qualquer sistema web que
utiliza HTML como linguagem de marcação.
Palavras-chave: Métricas de software. Análise de Pontos de Função. Software educacional.
ABSTRACT
The current market of software development is growing quickly, companies are seeking
project management processes to achieve success and excellence in the developed products.
In the phase of requirements elicitation, project stakeholders do not have complete knowledge
about the product’s technical features that allows to account for its future size. In these cases
it is necessary to estimate using measurements models with lower error related to the
communication’s needs and project information. Software measurement is one of the simplest
and least costly measure of quality assurance for the success of the software project , being
able to know whether product’s technical features meet or not the quality standard
established, helping to make decisions and monitoring of tasks through estimates to determine
the effort or time for the performance. College students and companies that wish to adopt
metrics do not have an educational tool to support the learning of Function Point Analysis,
however to perform the calculation of function points there are web tools like Sizify, though,
its focus is on metrics analyst, that one who already knows the technique.. The proposed
project desires to create an educational module like a tutorial for Sizify and propose a model
of educational module that is applicable in web systems. Javascript is used in the development
by being a programming language executed on the client and because it’s easy to insert in
web systems, the storage is made by a XML, in which is stored the tutorial that Javascript
performs the readout. Tests were made with two systems, the evaluation resulted that the
solution is able to help in the APF learning and the tutorial standard can be inserted in any
web system which uses HTML as a markup language.
Keywords: Software metrics. Function Point Analysis. Educational software.
LISTA DE FIGURAS
Figura 1. Visão geral do processo de contagem de pontos de função ...................................... 26
Figura 2. Fórmula para o projeto de desenvolvimento ............................................................. 34 Figura 3. Fórmula aplicada depois da instalação ...................................................................... 35 Figura 4. Fórmula para projeto de melhoria no momento do projeto....................................... 35 Figura 5. Fórmula para projeto de melhoria a partir da instalação do projeto ......................... 36 Figura 6. Tela de uma contagem do APFPlus. ......................................................................... 37
Figura 7. Tela de uma contagem do Metric Studio. ................................................................. 38 Figura 8. Interface da ferramenta Sizify ................................................................................... 39 Figura 9. Análise ordenadas por organização e aplicação no Sizify. ....................................... 40
Figura 10. Configurações iniciais do Sizify ............................................................................. 41 Figura 11. Listando funções do tipo dado no Sizify. ................................................................ 42 Figura 12. Tutorial em execução no Service Studio. ................................................................ 46 Figura 13. Tutorial em execução Microsoft Office Word 2007 com Ribbon Hero 2. ............. 47
Figura 14. Diagrama de casos de uso ....................................................................................... 50 Figura 15. Modelo conceitual do arquivo de dados.................................................................. 53 Figura 16. Desenvolvimento com a ferramenta NetBeans. ...................................................... 55 Figura 17. Visão geral das tecnologias web. ............................................................................ 56
Figura 18. Teste com Sizify - Seleção do tutorial. ................................................................... 61 Figura 19. Teste com Sizify - Página incorreta. ....................................................................... 62
Figura 20. Teste com Sizify - Leitura e avaliação. ................................................................... 63 Figura 21. Teste com Sizify - Instrução para avançar. ............................................................. 64 Figura 22. Teste com Sizify - Fim do tutorial. ......................................................................... 65
Figura 23. Teste com Gepron Ouvidoria - Leitura e avaliação. ............................................... 68
Figura 24. Teste com Gepron Ouvidoria - Instrução para avançar. ......................................... 69 Figura 25. Termo de compromisso. .......................................................................................... 74 Figura 26. Termo de licenciamento de uso de software. .......................................................... 75
Figura 27. E-mail de Guilherme Siqueira Simôes. ................................................................... 76 Figura 28. Protótipo referente ao UC01. .................................................................................. 86 Figura 29. Protótipo referente à primeira etapa do UC02. ....................................................... 87
Figura 30. Protótipo referente à segunda etapa do UC02. ........................................................ 88 Figura 31. Protótipo referente à terceira etapa do UC02. ......................................................... 89
Figura 32. Protótipo referente ao UC03. .................................................................................. 90
LISTA DE TABELAS
Tabela 1. Conversão de ALI e AIE .......................................................................................... 29
Tabela 2. Conversão de EE e CE .............................................................................................. 32 Tabela 3. Conversão de SE ....................................................................................................... 32 Tabela 4. Níveis de influência das CGS ................................................................................... 33 Tabela 5. Perguntas da pesquisa de satisfação aplicada no teste com Sizify ........................... 67
LISTA DE QUADROS
Quadro 1. Complexidade funcional de ALI e AIE .............................................................. 30
Quadro 2. Complexidade funcional de EE .......................................................................... 33
Quadro 3. Complexidade funcional de CE e SE ................................................................. 33
Quadro 4. UC01 - Habilitar módulo educacional ................................................................ 52
Quadro 5. UC02 - Estudar através do tutorial ..................................................................... 53
Quadro 6. UC03 – Desabilitar módulo educacional ............................................................ 54
Quadro 7. Descrição das tags do arquivo de dados do tutorial............................................ 56
Quadro 8. XML Schema do arquivo de dados .................................................................... 60
Quadro 9. Lição 1 do arquivo de dados aplicado no teste com o Sizify ............................. 61
Quadro 10. Resultado da pesquisa de satisfação aplicada no teste com o Sizify ................ 69
Quadro 11. Lição 1: O método ............................................................................................ 79
Quadro 12. Lição 2: Tipo de contagem ............................................................................... 79
Quadro 13. Lição 3: Escopo e Fronteira da aplicação ......................................................... 80
Quadro 14. Lição 4: Funções de dados................................................................................ 80
Quadro 15. Lição 5: Arquivos Lógicos Internos (ALI) ....................................................... 81
Quadro 16. Lição 6: Arquivos Lógicos Internos (ALI) – Parte 2........................................ 81
Quadro 17. Lição 7: Arquivos de Interface Externa (AIE) ................................................. 81
Quadro 18. Lição 8: Arquivos de Interface Externa (AIE) – Parte 2 .................................. 81
Quadro 19. Lição 9: Determinando a complexidade das funções de dados ........................ 82
Quadro 20. Lição 10: Determinando a complexidade das funções de dados – Parte 2 ....... 82
Quadro 21. Lição 11: Determinando a complexidade das funções de dados – Parte 3 ....... 82
Quadro 22. Lição 12: Determinando a complexidade das funções de dados – Parte 4 ....... 82
Quadro 23. Lição 13: Função de Transação ........................................................................ 83
Quadro 24. Lição 14: Entrada Externa ................................................................................ 83
Quadro 25. Lição 15: Determinando a complexidade de Funções de Transação................ 84
Quadro 26. Lição 16: Consulta Externa .............................................................................. 84
Quadro 27. Lição 17: Consulta Externa – Parte 2 ............................................................... 84
Quadro 28. Lição 18: Determinando a complexidade da Consulta Externa ....................... 85
Quadro 29. Lição 19: Saída Externa .................................................................................... 85
Quadro 30. Lição 20: Saída Externa – Parte 2 .................................................................... 85
Quadro 31. Lição 21: Determinando a complexidade da Saída Externa ............................. 85
Quadro 32. Lição 22: Resultados ........................................................................................ 85
Quadro 33. Lição 1: O Gepron ............................................................................................ 86
Quadro 34. Lição 2: Realizar manifestação......................................................................... 86
Quadro 35. Lição 3: Listar abertas ...................................................................................... 87
LISTA DE ABREVIATURAS E SIGLAS
AIE Arquivos de Interface Externa
ALI Arquivos Lógicos Internos
APF Análise de Pontos de Função
AR Arquivos Referenciados
BFPUG Brazilian Function Point Users Group
CE Consultas Externas
CGS Características Gerais do Sistema
CPM Counting Practices Manual
EE Entradas Externas
FA Fator de Ajuste
HTML HyperText Markup Language
IFPUG International Function Point Users Group
LOC Lines of Code
NESMA Netherlands Software Metrics Association
PDF Portable Document Format
PF Ponto de Função
RF Requisito Funcional
RN Regra de Negócio
RNF Requisito Não-Funcional
SE Saídas Externas
TD Tipos de Dados
TR Tipo de Registros
TTC Trabalho Técnico-científico de Conclusão de Curso
UCP Use Case Points
UML Unified Modeling Language
UNIVALI Universidade do Vale do Itajaí
URL Uniform Resource Locator
W3C World Wide Web Consortium
XML eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................................... 15 1.1 PROBLEMATIZAÇÃO ....................................................................................................... 18
1.1.1 Formulação do Problema ................................................................................................ 18 1.1.2 Solução Proposta ............................................................................................................. 18 1.2 OBJETIVOS ........................................................................................................................ 19 1.2.1 Objetivo Geral ................................................................................................................. 19 1.2.2 Objetivos Específicos ....................................................................................................... 19
1.3 METODOLOGIA ................................................................................................................ 20 1.4 ESTRUTURA DO TRABALHO .......................................................................................... 21
2 FUNDAMENTAÇÃO TEÓRICA ........................................................................................ 22 2.1 MÉTRICAS DE SOFTWARE .............................................................................................. 22
2.1.1 Métricas orientadas por tamanho ................................................................................... 23 2.1.2 Métricas orientadas por casos de uso ............................................................................. 24 2.1.3 Métricas orientadas por função ...................................................................................... 24
2.2 ANÁLISE DE PONTOS DE FUNÇÃO ............................................................................... 26 2.2.1 Tipo de contagem, Escopo e Fronteira da aplicação ...................................................... 27
2.2.2 Funções do tipo dado ...................................................................................................... 28 2.2.3 Funções do tipo transação .............................................................................................. 29
2.2.4 Fator de Ajuste ................................................................................................................ 32 2.2.5 Ajustando pontos de função ............................................................................................. 34
2.3 FERRAMENTAS PARA CONTAGEM DE PONTOS DE FUNÇÃO .................................. 36 2.3.1 APFplus ........................................................................................................................... 36 2.3.2 Metric Studio ................................................................................................................... 37
2.3.3 Sizify ................................................................................................................................ 38 2.4 SOFTWARE EDUCACIONAL ........................................................................................... 42
2.4.1 Concepções de aprendizado ............................................................................................ 43 2.4.2 Tipos de software educacional ........................................................................................ 44 2.5 FERRAMENTAS SIMILARES ............................................................................................ 45
3 DESENVOLVIMENTO ....................................................................................................... 48 3.1 DEFINIÇÕES DO PROJETO ............................................................................................ 48
3.1.1 Análise de requisitos ........................................................................................................ 48
3.1.2 Diagramas de Casos de Uso ........................................................................................... 50 3.1.3 Modelo do arquivo de dados ........................................................................................... 53 3.2 TECNOLOGIAS E FERRAMENTAS .................................................................................. 55
3.2.1 NetBeans .......................................................................................................................... 55 3.2.2 Javascript ........................................................................................................................ 56
3.2.3 XML ................................................................................................................................. 57 3.3 APRESENTAÇÃO DA FERRAMENTA .............................................................................. 60 3.3.1 Seleção do tutorial ........................................................................................................... 60 3.3.2 Leitura e avaliação .......................................................................................................... 62 3.3.3 Instrução para avançar ................................................................................................... 63
3.3.4 Resultado ......................................................................................................................... 64 3.4 TESTES E AVALIAÇÃO ..................................................................................................... 65
3.4.1 Testes com o Sizify ........................................................................................................... 66 3.4.2 Testes com o Gepron Ouvidoria ...................................................................................... 68
4 CONCLUSÕES ..................................................................................................................... 70 4.1 TRABALHOS FUTUROS ................................................................................................... 71
Apêndice A. TUTORIAL UTILIZADO NO TESTE COM O SIZIFY ................................ 77
Apêndice B. TUTORIAL UTILIZADO NO TESTE COM O GEPRON OUVIDORIA ..... 84
Apêndice C. PROTÓTIPOS DE TELAS PARA IMPLEMNETAÇÃO DO PROJETO ..... 86
15
1 INTRODUÇÃO
O mercado atual de desenvolvimento de software está em crescimento acelerado, as
empresas estão em busca de processos de gerência de projetos para obter sucesso e excelência
nos produtos desenvolvidos. De acordo com o relatório publicado pela Standish Group Report
(2011), somente 32% dos projetos de software foram bem sucedidos, ou seja, entregues
dentro do escopo, prazo e custo. Nesse contexto, gestores buscam o aprimoramento de
técnicas relacionadas à engenharia de software para conseguir planejar e obter controle, dentre
diversas técnicas estão os conceitos capazes de estimar o tamanho do software e conseguir
determinar se os objetivos do projeto são realistas e controláveis.
Na fase de levantamento de requisitos, os envolvidos no projeto não possuem
conhecimento completo das características do produto que permita contabilizar sua futura
dimensão, nesses casos é necessário estimar usando modelos de medições com menor
margem de erro às necessidades de comunicação e informação do projeto (VAZQUEZ;
SIMÕES; ALBERT, 2003).
A coleta de medidas feita por um engenheiro de software desenvolve métricas de
modo que indicadores sejam obtidos, estes então fornecem profundidade na visão do processo
de software e possibilitam o ajuste para tornar o produto melhor. Ao longo de um projeto as
medições podem contribuir no controle do mesmo, na avaliação da produtividade e no
controle de qualidade (PRESSMAN, 2006).
Gerentes de projetos podem estar diante do problema de estimativa de produtividade
de engenheiros de software e necessitam de recursos para definir o custo ou o prazo de
projeto, para informar decisões de investimento ou para verificar se melhorias no processo ou
de tecnologia foram eficazes (SOMMERVILLE, 2007).
No início da década de 70, a IBM desenvolvia projetos em diversas linguagens de
programação tornando inviável uma análise conjunta de produtividade usando os modelos de
contagem baseados em linhas de código, Allan Albrecht foi encarregado de medir estes
projetos. No final da década de 70, Albrecht publicou sua pesquisa sobre Análise de Pontos de
Função (APF), um método padrão de medir o tamanho funcional do software do ponto de
vista do usuário baseado fundamentalmente no projeto lógico e independente de linguagem de
programação (VAZQUEZ; SIMÕES; ALBERT, 2003; MECENAS, 2009).
16
Segundo Vazquez, Simões e Albert (2003), com a ascensão da técnica em 1986, surgiu
a necessidade de promover a manutenção de software com o uso de pontos de função e um
melhor gerenciamento dos processos de desenvolvimento. Diante dessas ausências, pessoas e
empresas de diversos países criaram uma entidade sem fins lucrativos denominada
International Function Point Users Group (IFPUG). Em 1990 o IFPUG com o objetivo de
padronização da técnica, lançou a primeira versão do Counting Practices Manual (CPM), um
guia detalhando todo o procedimento para aplicação da métrica, atualmente na Versão 4.3.1.
No Brasil o uso da técnica se popularizou significativamente no início da década de
90, devido ao crescente número de contratos públicos baseados em pontos de função e a busca
das organizações por qualidade no desenvolvimento de software, o Brazilian Function Point
Users Group (BFPUG) foi criado para ser o representante oficial do IFPUG no Brasil e prover
a troca de experiências entre os profissionais, palestras e também o exame de certificação
(VAZQUEZ; SIMÕES; ALBERT, 2003).
Segundo Mecenas (2009), as organizações vêm se beneficiando com o uso da APF em
ações como:
Determinar o tamanho da aplicação utilizando todas as funcionalidades incluídas no
pacote de software adquirido;
Avaliar se determinado pacote da aplicação atende especificamente os requisitos da
organização;
Medir em processos de análise de qualidade e produtividade as unidades de um
produto de software;
Estimar o desenvolvimento e a manutenção do software a fim de descobrir os
custos e recursos necessários para tal;
Comparar o tamanho funcional de softwares similares de diferentes fabricantes.
Segundo Ferreira e Hazan (2010), gestores vêm utilizando a métrica para o
planejamento de projetos de software com intuito de saber se a mão-de-obra interna da
organização é suficiente ou é preciso contratar empresas ou profissionais no mercado.
Auditores também estão se baseando na contagem em casos de contratação de
desenvolvimento de software com preço definido na fase inicial de especificação, em algumas
vezes o projeto sofre mudanças não previstas durante sua construção e altera o custo para a
17
empresa contratada, cabendo ao auditor quantificar o tamanho implantado e informar aos
responsáveis.
Com a crescente demanda de projetos de software, também há o surgimento de outras
técnicas de contagem, estas vêm sendo utilizadas em conjunto com APF ou isoladas, dentre as
técnicas estão Pontos por Caso de Uso (UCP, de Use Case Points) e Linhas de código-fonte
(LOC, de Lines of Code) representando as métricas orientadas a casos de uso e métricas
orientadas a tamanho respectivamente (SOMMERVILLE, 2002).
Segundo Freire (2003), UCP é um método similar à técnica de pontos de função que
usa dos casos de uso principais do sistema para estimar o tamanho do software através de um
conjunto de métricas e modificadores. Conforme Sommerville (2002), LOC é uma métrica de
produtividade que usa a contagem do número de linhas de código-fonte para determinar
principalmente a produtividade dos envolvidos.
UCP e LOC possuem alguns problemas que fizeram optar por APF na execução deste
trabalho, segundo Pressman (2006) técnicas de LOC dependem da linguagem de programação
e possuem dificuldades para estimar o tamanho antes da codificação do projeto, já Aguiar
(2002) diz que projetistas possuem variação na formulação do caso de uso por não haver
padrões universais, implicando na obtenção de estimativas confiáveis utilizando UCP.
Segundo Sommerville (2002), os atributos referentes à contagem não-funcional do
software é uma desvantagem de APF, pois as características do sistema utilizadas para tal
finalidade podem não se aplicar corretamente em questão de complexidade ou estão
desatualizadas com novas tecnologias. A nomenclatura utilizada pela contagem de PF (Pontos
de Função) também é uma deficiência, quando novatos ou profissionais que não utilizam a
técnica com freqüência se deparam com siglas e nomes como Tipos de Registros de um
Arquivo de Interface Externa, recorrem a manuais e a cartilhas de consulta rápida para
auxiliá-los durante o processo.
Apesar das desvantagens, empresas e órgãos do governo vêm adotando as métricas de
software orientadas por ponto de função para dimensionar softwares, prova disso está no
Roteiro de Métricas de Software do SISP (Sistema de Administração dos Recursos de
Tecnologia da Informação, antigamente chamado de Sistema de Informática do Serviço
Público), neste documento é possível observar como o governo federal adota APF na
contratação de empresas para desenvolvimento e manutenção de software, não obstante o
18
Ministério do Planejamento, Orçamento e Gestão junto a Secretaria de Logística e Tecnologia
da Informação emitiram a portaria nº 31, de 29 de novembro de 2010, contendo a
recomendação do uso da métrica de pontos de função em contratos públicos (MINISTÉRIO
DO PLANEJAMENTO, ORÇAMENTO E GESTÃO, 2012).
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
A professora e orientadora deste trabalho Adriana Gomes Alves, observou durante as
aulas da disciplina de Engenharia de Software do curso de Ciência da Computação desta
universidade, dificuldade dos alunos em concluir uma contagem de PF, notou-se também que
a dificuldade em realizar a tarefa estava na complexidade das regras de APF. Simões (2013)
também relata que durante os treinamentos ministrados por sua empresa, observa-se
dificuldade em compreender os conceitos, principalmente em analisar o software do ponto de
vista do usuário1. Visto que a adoção de APF vem crescendo, o ensino da técnica passa a ser
um fator de grande importância na formação profissional.
1.1.2 Solução Proposta
Durante pesquisas sobre ferramentas que já realizavam contagens de pontos de função,
foi encontrado o Sizify, uma ferramenta web voltada para o público corporativo, mantida pela
2Reach, depois de contatos feitos com a empresa, surgiu a oportunidade de implementar um
módulo educacional com o objetivo de ensinar a teoria da contagem de pontos de função
durante a prática no software Sizify.
Como o Sizify é uma ferramenta comercial, optou-se por desenvolver um módulo
educacional que não interfira no código-fonte da aplicação, nessas condições este trabalho não
só irá desenvolver um módulo educacional como irá propor um modelo de ferramenta
educacional que pode ser utilizada em outros sistemas web.
A 2reach firmou um termo de compromisso com a UNIVALI para garantir que este
trabalho não seja prejudicado por falta de cooperação e acesso a ferramenta, este termo está
em anexo a este trabalho como Anexo A.
1 O Anexo C apresenta o e-mail na íntegra.
19
Diante do problema exposto, esse trabalho propõe que seja desenvolvido um módulo
educacional sob forma de tutorial que apóie a aprendizagem de APF, tendo como foco
principal o ensino teórico a partir da prática na ferramenta Sizify.
Este módulo educacional teve sua implementação realizada em linguagem de
programação interpretada pelo cliente e os dados são armazenados por arquivos padronizados
por linguagem de marcação dentro do servidor, sendo assim, o tutorial se torna independente
da linguagem de programação e do banco de dados do software alvo, dessa forma o modelo
proposto poderá ser utilizado por outros sistemas web.
1.2 OBJETIVOS
Esta subseção apresenta as metas e características necessárias para alcançar os
objetivos definidos para a solução do problema.
1.2.1 Objetivo Geral
Desenvolver um módulo educacional baseado em tutorial para apoio a aprendizagem
da metodologia de APF e propor um modelo de ferramenta educacional que possa ser
utilizado por sistemas web que utilizam HTML como linguagem de marcação.
1.2.2 Objetivos Específicos
Estudar e descrever os tipos de métricas de software;
Estudar e descrever os conceitos de Análise de Pontos de Função;
Elaborar um modelo de software tutorial para sistema web;
Elaborar a especificação e modelagem da ferramenta proposta;
Pesquisar os conceitos e tecnologias necessários à implementação do sistema;
Implementar a ferramenta de acordo com o projeto elaborado;
Efetuar testes visando à validação das funcionalidades e o atendimento aos
requisitos especificados;
Avaliar a ferramenta com os alunos da disciplina de Engenharia do Software da
UNIVALI no sistema Sizify;
Documentar o desenvolvimento e os resultados do sistema.
20
1.3 METODOLOGIA
Nesta seção é apresentada uma descrição da metodologia utilizada para atingir cada
um dos objetivos alcançados até o momento.
Estudar e descrever os tipos de métricas de software: nesta fase foram
utilizados livros para realizar uma descrição e análise dos tipos de métricas,
suas qualidades, deficiências e aplicações.
Estudar e descrever os conceitos de Análise de Pontos de Função: nesta fase
foram utilizados livros, artigos científicos, site de empresas que prestam
consultorias de APF e sites dos grupos que dão manutenção na técnica, foi
possível descrever a técnica, identificar como a contagem é feita pelos analistas
de métricas, empresas e órgãos do governo e os benefícios em aplicar APF.
Elaborar um modelo de software tutorial para sistema web: nesta fase foram
pesquisados as concepções de aprendizagem e os tipos de software educacional
para então propor um modelo de módulo educacional aplicável em qualquer
sistema web.
Elaborar a especificação e modelagem da ferramenta proposta: nesta fase foi
utilizada a ferramenta Enterprise Architect para fazer o levantamento de
requisitos e a modelagem dos casos de uso, nesta fase também foi feita a
estrutura dos arquivos de dados e os protótipos do sistema.
Pesquisar os conceitos e tecnologias necessários à implementação do sistema:
nesta fase foi pesquisado na internet uma linguagem de marcação para manter
os arquivos de dados no servidor e uma linguagem de programação que
execute no cliente e possa ser incluída em qualquer sistema web, após a
pesquisa foi definido o XML como linguagem de marcação e Javascript como
linguagem de programação para o desenvolvimento deste trabalho.
Implementar a ferramenta de acordo com o projeto elaborado: esta fase
consistiu em programar a ferramenta proposta utilizando o software NetBeans
7.2.1 com a linguagem Javascript e o framework jQuery 1.9.
Elaborar tutorial para análise de pontos de função: após a implementação da
ferramenta, o tutorial que tem o propósito de ensinar um aprendiz a realizar
contagens de PF foi elaborado utilizando o modelo XML projetado.
21
Efetuar testes visando à validação das funcionalidades e o atendimento aos
requisitos especificados: fase de testes foi realizada durante toda a fase de
desenvolvimento, mas ao fim da implementação da ferramenta foram
realizados testes com diferentes estudos de caso com o objetivo de detectar
falhas de codificação e problemas com o layout em múltiplos navegadores.
Avaliar a ferramenta com os alunos da disciplina de Engenharia do Software
da UNIVALI no sistema Sizify: esta fase foi realizada após a conclusão da fase
de testes, os alunos da disciplina de Engenharia de Software da UNIVALI
foram observados realizando uma contagem de PF com o auxílio do módulo
educacional.
Documentar o desenvolvimento e os resultados do sistema: Por fim foi
realizada a produção textual do documento do TTC, este documento possui a
fundamentação teórica, os resultados do desenvolvimento, os testes realizados
e a conclusão final do trabalho. Um artigo científico foi produzido baseado no
documento final do TTC.
1.4 ESTRUTURA DO TRABALHO
No primeiro capítulo do trabalho é apresentada a Introdução envolvendo descrição
geral, problematização, solução, objetivo geral e específicos, e a metodologia usada na
produção do trabalho.
O segundo capítulo trata a Fundamentação Teórica. Nela são abordadas as métricas de
software, análise de pontos de função, a ferramenta Sizify, os tipos de softwares educacionais
e ferramentas similares.
O Capítulo 3 descreve o Desenvolvimento, nele são apresentadas as definições do
projeto como requisitos funcionais, requisitos não funcionais e regras de negócio, em seguida
são apresentados os casos de uso que descrevem o funcionamento das atividades no sistema
por meio dos cenários, após o projeto definido é apresentada a ferramenta e documentado
todos os testes realizados.
O quarto e último capítulo traz as Conclusões referente ao desenvolvimento deste
trabalho e trabalhos futuros.
22
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda os conceitos necessários para projetar e desenvolver o módulo de
apoio à aprendizagem. A seção 2.1 apresenta o estudo sobre Métricas de Software, seus
benefícios e os tipos de métricas. Na seção 2.2 é abordada a Análise de Pontos de Função,
contendo seus conceitos, vantagens na sua aplicabilidade e as regras para chegar ao número
de pontos de função de uma contagem. A seção 2.3 apresenta as ferramentas que realizam a
contagem de PF e o detalhamento do sistema Sizify. Os tipos de software educacional e as
concepções de aprendizagem adotadas por sistemas que utilizam uma abordagem educacional
estão descritos na seção 2.4. Por fim, a seção 2.5 apresenta duas ferramentas similares
utilizadas para realizar o projeto da solução proposta.
2.1 MÉTRICAS DE SOFTWARE
Com a crescente competitividade entre empresas de desenvolvimento de software, as
organizações vêm pesquisando formas de concluir seus projetos dentro dos custos e prazos
planejados. Gestores buscam o aprimoramento de suas práticas de engenharia de software
com foco na melhoria de processos, contexto em que a medição de software se torna
fundamental (BARCELLOS, 2011).
A medição de software é uma contagem de recursos ou atributos de um sistema para
gerar um valor numérico, esse valor comparado com análises históricas da mesma técnica,
pode ser uma ferramenta importante para tirar conclusões sobre processos e qualidade de
software (SOMMERVILLE, 2007).
Pressman (2006, p. 349) define que qualidade de software é “a satisfação de requisitos
funcionais e de desempenho explicitamente declarados, normas de desenvolvimento
explicitamente documentados e características implícitas que são esperadas em todo o
software desenvolvido profissionalmente”.
Medição de software é uma das mais simples e menos custosa medida de garantia de
qualidade para o sucesso do projeto de software. Sendo possível saber se características de
produto atendem ou não o padrão de qualidade estipulado, auxiliando na tomada de decisão e
no acompanhamento de tarefas através de estimativas para determinar o esforço ou tempo
para sua realização. (ABREU; ARAÚJO; MOTA, 2010).
23
Para que as organizações se beneficiam com seu programa de métricas, é necessário
que sua aplicação seja voltada para apoiar a tomada de decisão na área técnica e de negócios,
por exemplo, um gestor pode utilizar informações vindas de medições para identificar e
corrigir problemas previamente ou realizar uma comunicação mais eficiente com seus
colaboradores (BARCELLOS, 2011).
Barcellos (2011) enfatiza também que como qualquer outra ferramenta gerencial ou
técnica, a aplicação de uma métrica não garante o alcance dos objetivos. Não há também uma
métrica que se encaixe em todas as aplicações do mercado, cada técnica possui
particularidades e sua concepção foi baseada em determinadas características.
Pesquisadores buscam uma única métrica de software, algo que muitos acreditam ser
impossível de alcançar, pois toda medida possui um ponto de vista sobre complexidade e é
proposta levando em consideração diferentes atributos de um sistema, cabe a um especialista
analisar a organização e seus projetos e justificar o uso de determinada métrica (PRESSMAN,
2006).
Os especialistas possuem um grande acervo de técnicas facilmente calculadas,
entendidas e testadas, elas são divididas em três grupos que podem ser utilizadas em conjunto
ou separadamente, sendo o grupo de técnicas orientadas por tamanho, técnicas orientadas a
casos de uso e o de técnicas orientadas por função. (ABREU; ARAÚJO; MOTA, 2010).
2.1.1 Métricas orientadas por tamanho
As métricas relacionadas a tamanho estão associadas ao tamanho do resultado de uma
atividade, sendo assim as técnicas por tamanho apresentam dependências quanto ao modo de
desenvolvimento do software. (SOMMERVILLE, 2007).
Essas técnicas podem ser usadas para saber o tamanho de uma aplicação já
desenvolvida ou estimar o esforço para desenvolver um produto, a sua popularização deve ao
fato da facilidade de obter as informações, por exemplo, número de linhas do código-fonte, e
de apresentar medidas, por exemplo, custo por LOC, defeitos por LOC e erros por LOC
(ABREU; ARAÚJO; MOTA, 2010).
Conforme Sommerville (2007), com LOC foi possível obter informações de
produtividade dos programadores na época em que os programas eram perfurados em cartões,
pois sabia que o número de linhas de código-fonte correspondia ao número de cartões na
24
caixa de programa. Com a ascensão das linguagens Java e C++, os softwares passaram a ser
escritos de diversas formas podendo ter várias declarações em uma linha, comentários e
comandos executáveis.
Pressman (2006) afirma que as métricas envolvendo apenas o tamanho do código-
fonte não são aceitas como melhor modo para medir o processo de desenvolvimento por
depender da linguagem de programação, por penalizar programas curtos e bem projetados e
por ser difícil de estimar o tamanho de um software a ser produzido nas fases iniciais do ciclo
de vida.
2.1.2 Métricas orientadas por casos de uso
O caso de uso é definido no início do processo de software, como acontece com a
métrica orientada por função, sendo possível obter estimativas antes que atividades de
desenvolvimento sejam iniciadas. Os casos de uso são independentes de linguagens de
programação e o tamanho da aplicação é proporcional ao número de casos de uso
(PRESSMAN, 2006).
Após o detalhamento dos casos de uso, é feita uma contagem dos atores, classificação
dos casos de uso, ajustes conforme os fatores de complexidade técnica e os fatores ambientais
(VIEIRA, 2007).
Os casos de uso descrevem as funções e características do sistema, parecendo ser uma
boa técnica de estimativa, mas não há padronização para escrita de um caso de uso, analistas
podem detalhar ou simplificar casos de uso em um mesmo projeto, outro fator relevante é que
para que a medição seja feita, o projeto deve ser modelado baseado em Unified Modeling
Language (UML) (PRESSMAN, 2006).
2.1.3 Métricas orientadas por função
Métricas orientadas a função utilizam uma medida da funcionalidade entregue pelo
software como um valor, sendo que as funcionalidades devem se basear na visão de negócio
do usuário. Por calcular a funcionalidade entregue, a técnica não varia de acordo com a
linguagem de programação e não depende da modelagem UML (SOMMERVILLE, 2007).
A unidade de medida do software é ponto de função (PF), uma unidade que não se
refere diretamente a custo, produtividade ou esforço, é simplesmente uma medida do tamanho
25
funcional do software. Para derivar produtividade, estimar esforço e custo, é preciso que
sejam incluídos dados históricos ou modelos de estimativas na análise (VAZQUEZ; SIMÕES;
ALBERT, 2003).
APF é o processo chamado para obtenção do tamanho funcional de um software, ou
seja, a quantidade PF que pode ser contada. Diversos métodos de APF foram desenvolvidos
com características distintas e para padronizar estes métodos, grupos de usuários de métricas
de software de todo o mundo se uniram para a criação da norma ISO/IEC 14143:2007 que
garante que todos os métodos sejam baseados em conceitos similares de tamanho funcional
(MECENAS, 2009).
Segundo Mecenas (2009), os objetivos de APF podem ser expressos como:
A funcionalidade deve ser medida de acordo com o que o usuário solicita e
recebe;
O desenvolvimento e manutenção de software deve ser medido
independentemente da tecnologia utilizada na implementação;
O processo de contagem dos pontos deve ser simples o bastante para minimizar
o trabalho gasto no processo de medição;
O resultado do processo de contagem deve retornar uma medida consistente
entre projetos e organizações.
A contagem dos pontos de função segue um padrão e as principais técnicas de
estimativa de projetos de desenvolvimento de software descrevem que o tamanho de um
software é de suma importância para determinar o esforço, prazo e custo nas fases iniciais do
projeto (VAZQUEZ; SIMÕES; ALBERT, 2003).
Diante dos benefícios listados acima, a adesão da comunidade e a facilidade de
contagem, este trabalho irá focar nas métricas orientadas a função, mais especificamente o
processo de Análise de Pontos de Função. Razão esta tendo em vista que as métricas
orientadas a tamanho possuem problemas quanto à dependência da linguagem de
programação e pela dificuldade de obter métricas antes da fase de desenvolvimento e por
métricas orientadas a casos de uso não possuírem uma padronização na escrita de casos de uso
e dependerem da modelagem UML.
26
2.2 ANÁLISE DE PONTOS DE FUNÇÃO
O processo de APF pode ser descrito resumidamente na Figura 1, onde são definidas
as dependências da técnica para chegar à contagem final. Para determinar o tamanho do
software é necessário informar atributos presentes no resultado final do software, mas que
podem ser verificados antes, durante ou depois de todo o processo de desenvolvimento. Os
atributos representam funcionalidades de processamento e armazenamento dos dados que
estão presentes no software (VAZQUEZ; SIMÕES; ALBERT, 2003).
Figura 1. Visão geral do processo de contagem de pontos de função
Fonte: Mecenas (2009).
Para que a contagem possa ser verificada é necessário que seja definido um propósito,
significa então que antes de aplicar a técnica, os analistas precisam saber o porquê que estão
usando APF. Essa resposta pode ser, por exemplo, uma contagem para remunerar um
fornecedor de acordo com o software entregue por ele, ou então uma contagem motivada para
estimativas de custo dos softwares em desenvolvimento na empresa (VAZQUEZ; SIMÕES;
ALBERT, 2003).
27
2.2.1 Tipo de contagem, Escopo e Fronteira da aplicação
Antes de dar início a contagem dos atributos do sistema, é necessário analisar o
propósito do cálculo para definir algumas propriedades da análise, sendo o tipo de contagem,
o escopo e a fronteira da aplicação (MECENAS, 2009).
Segundo Vazquez, Simões e Albert (2003), o primeiro passo para a contagem é
determinar o tipo de contagem, os três tipos são os seguintes:
Projeto de desenvolvimento
Projeto de melhoria
Aplicação instalada
A contagem de pontos de função de um projeto de desenvolvimento mede a
funcionalidade entregue ao usuário final na sua primeira instalação, sendo assim, neste tipo
também estão inclusos as funções de conversão de dados para o software em desenvolvimento
caso seja necessário. Na sequência, em projetos de melhoria são contadas todas as
modificações solicitadas pelos usuários durante o desenvolvimento ou depois da instalação de
uma aplicação que foi feita uma contagem anteriormente. Por fim, o cálculo de pontos de
função de uma aplicação instalada se refere às funcionalidades existentes por uma aplicação já
concluída, seu número de PF muda de acordo com os projetos de melhorias caso solicitado
(VAZQUEZ; SIMÕES; ALBERT, 2003; MECENAS, 2009).
A primeira parte do segundo passo é definir o escopo da contagem da aplicação, na
qual determina o conjunto de funções incluídas no processo, podendo conter todas as
funcionalidades, apenas funcionalidades utilizadas pelo usuário ou apenas funcionalidades
específicas como relatórios, cadastros, etc. (MECENAS, 2009).
Definido o escopo, o segundo passo é concluído quando a fronteira da aplicação é
identificada, ou seja, quando são delimitadas as funções e dados do software medido do
mundo exterior, nesse passo o analista deve se basear no ponto de vista do usuário e na visão
de negócio, não em considerações técnicas (VAZQUEZ; SIMÕES; ALBERT, 2003).
28
2.2.2 Funções do tipo dado
São denominadas funções do tipo dado todas as funcionalidades entregues ao usuário
para atender sua necessidade de dados internos e externos à aplicação, essas funcionalidades
são classificadas em Arquivos Lógicos Internos (ALI) e Arquivos de Interface Externa (AIE)
(VAZQUEZ; SIMÕES; ALBERT, 2003).
O termo arquivo significa um conjunto de dados relacionados logicamente e
reconhecido pelo usuário, sendo assim um arquivo de APF pode conter uma ou mais tabelas
de um banco de dados ou um ou mais arquivos do sistema operacional, pois a forma de
implementação não é relevante para definição das funções do tipo dado (VAZQUEZ;
SIMÕES; ALBERT, 2003).
2.2.2.1 Arquivo Lógico Interno
Um ALI é um conjunto de dados logicamente relacionados ou informações de
controle, esses dados devem estar dentro da fronteira da aplicação e devem ser identificados
pelo usuário. O ALI deve guardar os dados que são mantidos por funções transacionais, onde
manter significa adicionar, editar ou eliminar esses dados (MECENAS, 2009).
Uma informação de controle é um dado que pode alterar o comportamento de uma
função do tipo transação, como por exemplo, uma tela de configuração de preferência que
determina quais campos devem ser exibidos durante um cadastro (VAZQUEZ; SIMÕES;
ALBERT, 2003).
2.2.2.2 Arquivo de Interface Externa
Como o ALI, o AIE também é um conjunto de dados logicamente relacionados ou
informações de controle que são identificados pelo usuário, mas os dados estão fora da
fronteira da aplicação, ou seja, esses arquivos são ALI de outra aplicação (MECENAS, 2009).
Tanto para um ALI quanto para um AIE, é necessário que pelo menos uma função do
tipo transação esteja relacionada ao arquivo para que ele exista, ou seja, se um arquivo está na
contagem e não está sendo mantido por nenhuma função transacional, esse arquivo não deve
fazer parte da contagem (MECENAS, 2009).
29
2.2.2.3 Determinação da complexidade
Para determinar a complexidade de um ALI ou AIE, é preciso saber quantos Tipos de
Dados (TD) e Tipo de Registros (TR) cada arquivo contém.
O TD é um campo único no arquivo e reconhecido pelo usuário, quando duas
aplicações mantêm ou referenciam um ALI ou um AIE, deve-se contar somente o tipo de
dado utilizado pelo software em análise (VAZQUEZ; SIMÕES; ALBERT, 2003).
TR é um subgrupo de tipos de dados, para cada tipo de dado deve haver um tipo de
registro, cada tipo de registro adicional deve ser avaliado se essa relação entre as duas
entidades de dados não está relacionada com apenas uma instância de uma entidade
relacionada (MECENAS, 2009).
O Q uadro 1 mostra a complexidade funcional de um arquivo, a primeira coluna traz a
quantidade de tipos de registro e a primeira linha informa a quantidade de tipos de dados, o
cruzamento da linha com a coluna resulta na complexidade que é convertida na Tabela 1
(MECENAS, 2009).
Quadro 1. Complexidade funcional de ALI e AIE 1 a 19 TDs 20 a 50 TDs 51 ou mais TDs
1 TR Baixa Baixa Média
2 a 5 TRs Baixa Média Alta
6 ou mais TRs Média Alta Alta
Fonte: Mecenas (2009).
Tabela 1. Conversão de ALI e AIE
Complexidade funcional Pontos de função não ajustados
Baixa 7
Média 10
Alta 15
Fonte: Mecenas (2009).
2.2.3 Funções do tipo transação
Funções do tipo transação representam a funcionalidade entregue ao usuário para
processamento dos dados pela aplicação, elas são classificadas em Entradas Externas (EE),
Consultas Externas (CE) ou Saídas Externas (SE). Toda função transacional é um processo
elementar, ou seja, é a menor unidade de atividade significativa do usuário e quando
concluída sua execução deve manter a aplicação em estado consistente (MECENAS, 2009;
VAZQUEZ; SIMÕES; ALBERT, 2003).
30
2.2.3.1 Entrada Externa
Uma EE processa dados ou altera informações de controle através de ações vindas de
fora da fronteira da aplicação, durante a ação pelo menos um ALI ou uma informação de
controle deve sofrer alguma alteração ou processamento (MECENAS, 2009).
Segundo Vazquez, Simões e Albert (2003), são exemplos de uma EE:
Transações que recebem dados de fora da fronteira da aplicação com intuito de
manter um ou mais ALI;
Janelas que permitem incluir, alterar e excluir registros em arquivos, sendo que
nesses casos são considerados três EE;
Atualização de bases cadastrais com arquivos de movimento através de
processamento em lotes.
Vazquez, Simões e Albert (2003) também cita exemplos de funcionalidades que não
são uma EE:
Telas de autenticação;
Telas com filtro de relatórios e consultas;
Menus.
2.2.3.2 Consulta Externa
Uma CE envia dados ou informações de controle para fora da fronteira da aplicação,
sua aplicação deve ser restrita a exibir informações através de recuperação de dados ou
informações de controle. Durante a recuperação de uma requisição, não deve ser feito nenhum
processamento contendo fórmulas, cálculos ou geração de dados derivados. Na execução de
uma CE não é alterado nenhum ALI e nem o comportamento do sistema (MECENAS, 2009).
Conforme Vazquez, Simões e Albert (2003), são exemplos de uma CE:
Telas de Ajuda;
Telas de autenticação que não contenha criptografia;
Menus gerados dinamicamente baseados em informações de controle;
31
Relatórios que contenham apenas uma recuperação da base de dados.
Ainda Vazquez, Simões e Albert (2003), não são exemplos de CE:
Listagens que contenham totalizadores, cálculos matemáticos ou dados
derivados;
Menus estáticos.
2.2.3.3 Saída Externa
Uma SE vai além da simples recuperação de dados, para ter uma Saída Externa é
necessário que haja processamento das informações, podendo conter cálculos matemáticos,
fórmulas, totalizadores, derivação dos dados, enfim, qualquer operação que processe dados ou
informações de controle e envie para fora da fronteira da aplicação (MECENAS, 2009).
Não necessariamente o processamento dos dados deve ser apresentado ao usuário, à
lógica de processamento pode também incluir, editar ou excluir dados de um ALI ou alterar o
comportamento do sistema (VAZQUEZ; SIMÕES; ALBERT, 2003).
Segundo Vazquez, Simões e Albert (2003), podem ser uma SE:
Telas de autenticação com criptografia;
Consultas com cálculos ou dados derivados;
Relatório com totalizadores;
Relatórios que atualizam arquivos.
Ainda Vazquez, Simões e Albert (2003), não pode ser uma SE:
Telas de Ajuda;
Consultas ou relatórios que não apresentam um totalizador, não atualizam
arquivos, não possuem cálculo ou não modificam o comportamento do sistema.
2.2.3.1 Determinação da complexidade
Para determinar a complexidade de uma função do tipo transação, deve ser contato o
número de Arquivos Referenciados (AR) e o número de TD. Um AR é um ALI lido ou
mantido por uma função transacional ou um AIE lido por uma função do tipo transação. O TD
32
segue a definição utilizada nas funções do tipo dado, sendo um TD um campo único
reconhecido pelo usuário (VAZQUEZ; SIMÕES; ALBERT, 2003).
Como ocorre nas funções de dados, primeiro é analisado qual a complexidade da
função para posteriormente quantificar os pontos de função, o Quadro 2 apresenta a
complexidade de uma EE e o Quadro 3 representa a complexidade de uma CE e SE
(MECENAS, 2009).
Quadro 2. Complexidade funcional de EE 1 a 4 TDs 5 a 15 TDs 16 ou mais TDs
0 a 1 AR Baixa Baixa Média
2 ARs Baixa Média Alta
3 ou mais ARs Média Alta Alta
Fonte: Mecenas (2009).
Quadro 3. Complexidade funcional de CE e SE 1 a 5 TDs 6 a 19 TDs 20 ou mais TDs
0 a 1 AR Baixa Baixa Média
2 a 3 ARs Baixa Média Alta
4 ou mais ARs Média Alta Alta
Fonte: Mecenas (2009).
Para conversão da complexidade em pontos de função, é utilizada a Tabela 2 para
conversão de EE e CE e a Tabela 3 para conversão de SE (MECENAS, 2009).
Tabela 2. Conversão de EE e CE
Complexidade funcional Pontos de função não ajustados
Baixa 3
Média 4
Alta 6
Fonte: Mecenas (2009).
Tabela 3. Conversão de SE
Complexidade funcional Pontos de função não ajustados
Baixa 4
Média 5
Alta 7
Fonte: Mecenas (2009).
2.2.4 Fator de Ajuste
Segundo Mecenas (2009), fator de ajuste (FA) é o nome dado ao valor obtido através
dos 14 itens predefinidos na APF, esses itens são denominados Características Gerais do
Sistema (CGS). Cada CGS é relacionada a um conjunto de descrições e é determinado um
33
nível de influencia, no final das atribuições dos itens, o fator de ajuste pode alterar o número
de pontos de função em 35% para baixo ou para cima. São os itens de influência:
1. Comunicação de Dados;
2. Processamento Distribuído;
3. Performance;
4. Configuração Altamente Utilizada;
5. Volume de Transações;
6. Entrada de Dados On-Line;
7. Eficiência do Usuário Final;
8. Atualização On-Line;
9. Complexidade de Processamento;
10. Reutilização;
11. Facilidade de Instalação;
12. Facilidade de Operação;
13. Múltiplos Locais;
14. Facilidade de Mudanças.
Cada CGS pode receber uma pontuação de 0 a 5 conforme a Tabela 4, ao final da
atribuição do nível de influência de todos os itens, os pontos são somados e atribuídos ao
Total de Influência (TDI), para então aplicar a fórmula VFA = (TDI x 0,01) + 0,65. Onde
VFA é Valor do Fator de Ajuste (VAZQUEZ; SIMÕES; ALBERT, 2003).
Tabela 4. Níveis de influência das CGS
Pontuação Grau de influência
0 Nenhuma influência
1 Influência mínima
2 Influência moderada
3 Influência média
4 Influência significativa
5 Grande influência
Fonte: Vazquez, Simões e Albert (2003).
Quando a técnica foi inventada não havia as 14 CGS, o IFPUG em 1984 resolveu
incluir os itens de influência para atender alguns fatores não funcionais da aplicação, mas em
34
2002 o FA se tornou opcional para que a APF da IFPUG pudesse ser aceita como uma
medição funcional do ISO/IEC 14143 (VAZQUEZ; SIMÕES; ALBERT, 2003).
Ainda segundo Vazquez, Simões e Albert (2003), dentre muitas críticas aos itens de
influência estão:
Desatualização das opções que determinam o grau de complexidade de cada
CGS;
Ambigüidade na interpretação dos itens;
Falta de requisitos que não são contemplados por nenhuma das CGS;
Atribuição de pesos de 0 a 5 para todos os itens, sendo que em determinados
casos isso pode não ser a realidade.
2.2.5 Ajustando pontos de função
Como último passo para obter os pontos de função é necessário aplicar fórmulas de
acordo com o tipo de contagem: projeto de desenvolvimento, projeto de melhoria ou
aplicação instalada (VAZQUEZ; SIMÕES; ALBERT, 2003).
Em projetos de desenvolvimento pode haver necessidade de implementar funções de
conversão de dados do sistema legado para o sistema desenvolvido, essas funções de
conversão são incluídas na primeira contagem antes da implantação com intuito de saber o
número de pontos de função do projeto de desenvolvimento, após a implantação do sistema é
realizado uma nova contagem a fim de saber o número de pontos de função da aplicação
(VAZQUEZ; SIMÕES; ALBERT, 2003).
Sendo assim, a fórmula para o projeto de desenvolvimento é apresentada na Figura 2,
onde DFP é o número de pontos de função do projeto, UFP é o número de pontos de função
não ajustados das funcionalidades da aplicação, CFP é o número de pontos de função das
funções de conversão e VAF é o valor do fator de ajuste.
Figura 2. Fórmula para o projeto de desenvolvimento
Fonte: Mecenas (2009).
35
A fórmula aplicada depois da instalação é apresentada na Figura 3, onde AFP é o
número de pontos de função ajustados da aplicação, ADD é o número de pontos de função
não ajustados das funcionalidades instaladas e VAF é o fator de ajuste (MECENAS, 2009).
Figura 3. Fórmula aplicada depois da instalação
Fonte: Mecenas (2009).
Os projetos de melhoria envolvem além do fator de ajuste, as funcionalidades
incluídas no projeto, ou seja, funções incluídas, alteradas ou excluídas após a entrega da
aplicação e funcionalidades convertidas para o projeto, ou seja, funções utilizadas para
conversão de dados no momento da instalação da aplicação (MECENAS, 2009).
A fórmula para obter os pontos de função do projeto de melhoria no momento do
projeto é representada pela Figura 4, onde EFP é o número de pontos de função do projeto de
melhoria, ADD é o número de pontos de função não ajustados referentes às funções incluídas
pelo projeto, CHGA é o número de pontos de função não ajustados referentes às funções
alteradas pelo projeto, CFP é o número de pontos de função não ajustados referentes às
funções de conversão do projeto, VAFA é o fator de ajuste depois da conclusão do projeto,
DEL é o número de pontos de função não ajustados referentes às funções excluídas pelo
projeto e VAFB é o fator de ajuste da aplicação antes do início do projeto (MECENAS,
2009).
Figura 4. Fórmula para projeto de melhoria no momento do projeto
Fonte: Mecenas (2009).
Para representar os pontos de função a partir da instalação do projeto de melhoria é
necessário aplicar outra fórmula, sendo descrita na Figura 5, onde AFP é o número de pontos
de função da aplicação após a instalação, UFPB é o número de pontos de função da aplicação
antes do início do projeto, ADD é o número de pontos de função não ajustados referentes às
funções incluídas pelo projeto, CHGA é o número de pontos de função não ajustados (atuais)
referentes às funções alteradas pelo projeto, CHGB é o número de pontos de função não
ajustados (anteriores) referentes as funções alteradas pelo projeto, DEL é o número de pontos
36
de função não ajustados referentes as funções excluídas pelo projeto e VAFA é o fator de
ajuste calculado para o projeto (MECENAS, 2009).
Figura 5. Fórmula para projeto de melhoria a partir da instalação do projeto
Fonte: Mecenas (2009).
Contagem de PF de uma aplicação instalada não envolve nenhuma variável a não ser o
número de pontos de função não ajustados multiplicados pelo fator de ajuste da aplicação
(VAZQUEZ; SIMÕES; ALBERT, 2003).
Para realização destes cálculos e cadastros dos arquivos e funções, é possível utilizar
planilhas para salvar as contagens, porém, apesar de ser uma ferramenta prática de manipular,
essas planilhas geralmente são armazenadas em pastas e não geram nenhum relatório para
facilitar uma análise histórica ou uma avaliação da produtividade de um analista.
2.3 FERRAMENTAS PARA CONTAGEM DE PONTOS DE FUNÇÃO
Para que haja um controle e gerenciamento das contagens efetuadas por um analista,
empresas de desenvolvimento de software criaram ferramentas que auxiliam nessas tarefas e
centralizam as informações em um único software.
As subseções seguintes descrevem algumas ferramentas que realizam contagem de PF,
para o desenvolvimento do módulo educacional, este projeto deve utilizar uma ferramenta que
possa ser tutorada, ou seja, que possa rodar o módulo educacional sem interferir no seu
código-fonte. As restrições para que isso aconteça é a forma que a ferramenta é desenvolvida,
sendo que esta deve rodar na plataforma web e deve utilizar HTML como linguagem de
marcação.
2.3.1 APFplus
Umas das aplicações encontradas no mercado para gerenciar contagens de PF foi o
APFplus, este software foi desenvolvido por Ivan Mecenas, autor do livro Análise de Pontos
de Função – Estudo Teórico, Crítico e Prático, utilizado neste trabalho como referência
bibliográfica.
37
O APFplus é um software instalado na máquina do usuário, possui diversas
funcionalidades para controle e análise das contagens de PF conforme Figura 6, porém, possui
restrições quanto a plataforma não ser web e por isso não pôde ser utilizado como um sistema
tutorado.
Figura 6. Tela de uma contagem do APFPlus.
Fonte: APFPlus (2013).
2.3.2 Metric Studio
Outra ferramenta disponível no mercado para contagens de PF é o Metric Studio,
mantida pela TSA Quality, possui as funcionalidades básicas para chegar ao resultado de uma
contagem com muita facilidade. O Metric Studio possui uma interface simples e algumas
restrições na versão gratuita, mas como acontece com o APFplus, o Metric Studio é instalado
e não possui uma versão web para realizar uma análise, a Figura 7 apresenta a interface da
ferramenta.
38
Figura 7. Tela de uma contagem do Metric Studio.
Fonte: TSA Quality (2013).
2.3.3 Sizify
Por fim, a última ferramenta encontrada para APF foi o Sizify, um sistema web
mantido pela 2Reach e disponível gratuitamente para testes. Esta por ser a única solução que
utiliza HTML como linguagem de marcação e roda na plataforma web, foi escolhida para
executar o módulo educacional. A partir de contatos efetuados com a 2Reach, foi firmado
uma parceria em que eles se dispuseram a fornecer o sistema para que o módulo educacional
fosse testado e avaliado
O Sizify é web, lançado em 2011 no 6º Congresso Internacional de Medição e Análise
de Software. Seu objetivo foi sanar um problema que a empresa detectou durante análises, foi
constatado então que muitos analistas possuíam diversas planilhas para realizar o cálculo e
não conseguiam se organizar em meio a tantas contagens, a Figura 8 mostra a tela de entrada
do software (SIZIFY, 2013).
39
Figura 8. Interface da ferramenta Sizify
Fonte: Sizify (2013).
Antes de dar início a uma análise por pontos de função no Sizify, é necessário que
cadastre uma organização e uma aplicação, depois desse passo o usuário pode vincular todas
as análises dentro da aplicação que deseja conforme a Figura 9.
40
Figura 9. Análise ordenadas por organização e aplicação no Sizify.
Fonte: Sizify (2013).
O Sizify foi desenvolvido exclusivamente para realizar cálculo de PF, o usuário tem
quatro opções no menu que conseguem conduzi-lo até uma contagem. Apesar da ferramenta
já estar em funcionamento, sua versão atual está em fase de testes beta e suporta a Versão
4.2.1 e 4.3.1 do CPM do IFPUG, além do padrão de contagem proposto pelo IFPUG, o Sizify
fornece dois outros métodos de contagem da Netherlands Software Metrics Association
(NESMA), sendo estes os métodos por Estimativa e Indicativa, conforme mostra a Figura 10.
Este trabalho não irá abordar os métodos de contagem propostos pela NESMA por não
contemplar padrão aceito internacionalmente, sendo assim, o tutorial que foi desenvolvido
aborda apenas o método de contagem do IFPUG.
41
Figura 10. Configurações iniciais do Sizify
Fonte: Sizify (2013).
As funções do tipo dado e do tipo transação ficam acessíveis no menu lateral após o
cadastro de uma análise, a complexidade dos arquivos e funções ficam visíveis logo após o
cadastro, a Figura 11 apresenta a exibição da tela de funções de dado, a tela das funções de
transação são semelhantes, tendo como única diferença os botões de cadastro de EE, CE e SE.
Como o Sizify se baseia nos manuais de contagem mais recentes, os itens de
influência não estão disponíveis para cadastro, se houver a necessidade de algum ajuste, essa
informação pode ser inserida em um campo numérico a porcentagem de ajuste e em um
campo de texto a justificativa.
O resultado da contagem pode ser exportado em Excel, PDF e em uma versão para
impressão em HTML, os dados exibidos se referem à complexidade da análise em pontos de
função e a quantidade de cada função.
42
Figura 11. Listando funções do tipo dado no Sizify.
Fonte: Sizify (2013).
O foco da ferramenta está no analista de métricas, e partindo deste princípio o usuário
já tem conhecimento da técnica de APF, sendo assim profissionais experientes possuem
facilidade de trabalhar no software e são eficientes para realizar um cálculo, por outro lado,
um iniciante teria dificuldades em fazer uma análise.
Atualmente a equipe que mantém o Sizify oferece treinamentos presenciais em
organizações que desejam adotar a métrica e não possuem conhecimento para tal. Para
aproximar usuários iniciantes da técnica, a ferramenta poderia adotar um módulo educacional
para complementar o ensino em universidades e facilitar o aprendizado de usuários
corporativos geograficamente distantes.
2.4 SOFTWARE EDUCACIONAL
A educação vem sofrendo uma revolução com a união da comunicação e a tecnologia,
que coloca os professores diante do desafio de aprender a lidar com a insegurança do contato
com o novo, em especial a internet, pois a partir da rede mundial de computadores é possível
proporcionar experiências inovadoras com objetivo pedagógico (JUCÁ, 2006).
43
A definição do termo software educacional possui uma discussão quanto ao o que é
considerado um aplicativo educativo, podendo ser considerado um software educacional todo
aquele programa aplicado em um contexto de ensino-aprendizagem, sendo assim, tanto o
software que foi desenvolvido com um propósito educacional quanto o software aplicativo
que não foi desenvolvido com propósito educacional estão incluídos no termo (JUCÁ, 2006).
Um software aplicativo pode ser um editor de texto, editor gráfico, banco de dados,
planilha eletrônica, enfim, todo aquele sistema que não foi desenvolvido com finalidade
educativa, mas se inserido em um contexto de ensino-aprendizagem se torna uma ferramenta
para ensino (TAJRA, 2008).
A diferença do software aplicativo para o software educacional está na abordagem
pedagógica inserida durante seu desenvolvimento, isto é, quando um software aplicado ao
ensino é projetado, ele precisa contemplar requisitos que descrevem qual o ambiente para sua
aplicação, o público-alvo, qual a concepção de aprendizado e sua classificação de
aprendizagem (TAJRA, 2008).
2.4.1 Concepções de aprendizado
Segundo Teixeira (2001), cada professor pode assumir concepções de ensino na sala
de aula, o resultado esperado para qualquer que seja a concepção é que o aluno tenha
aprendido ou que ele tenha o conhecimento necessário para desenvolver seu aprendizado. O
software educacional também deve possuir alguma concepção de aprendizado quanto ao
modo de cumprir seu objetivo educativo, as concepções podem ser divididas em cinco
modelos:
Receptiva: o conhecimento adquirido pelo aluno é realizado através de
memorização de conteúdo e acumulação de aprendizado;
Assimilação: o aluno apropria-se do novo conhecimento através de
conhecimentos anteriores;
Descoberta: o foco é voltado para que o aluno aprenda com esforço próprio
através de experimentos e trabalhos práticos;
Substituição de conhecimentos: durante a vida do aluno é feita uma construção
de conhecimento, esses conhecimentos são considerados informais por não
44
atenderem aos critérios de conhecimento científico e então são substituídos
para que atendam a esses critérios;
Construção: o conhecimento prévio de aluno é utilizado para construção de
novos conhecimentos, assim, o aprendizado ocorre através de mudanças de
conceitos evoluindo os já existentes.
2.4.2 Tipos de software educacional
Os softwares educacionais podem ser classificados em quatro tipos de acordo com a
sua funcionalidade, podendo ser tutoriais, de exercitação e prática, simuladores ou jogos
educacionais, podem também possuir mais de uma classificação, por exemplo, ser um
software tutorial e de exercitação e prática (TEIXEIRA, 2001).
Os programas tutoriais fornecem ao aluno diversas informações através de lições e
verificam se ele compreendeu aquilo que foi fornecido, essa verificação garante que durante o
aprendizado o aluno consiga assimilar e aprender aquilo que foi exposto. Cada aluno possui
um ritmo de aprendizado, com softwares tutoriais é possível que esse ritmo seja mais
dinâmico e imposto pelo aluno (JUCÁ, 2006).
Um tutorial deve ser uma sequência de informações logicamente interligadas, durante
sua execução o usuário deve responder a atividades para uma avaliação de cada etapa, estes
fatores levam a condução do aprendiz ao aprendizado previamente planejado pelo tutorial. O
processo de aprendizado bem sucedido deve conter quatro fases: motivação, retenção,
aplicação e retroalimentação. Essas fases resumem a sequência de um tutorial para atingir seu
objetivo pedagógico (GALVIS, 1988 apud RAMOS, 1996).
Softwares de exercitação e prática não fornecem informações para o aprendizado, o
foco está no treinamento de um conteúdo já conhecido pelo aluno, dessa forma o professor
pode explicar conceitos em sala de aula e posteriormente utilizar o software. Sistemas de
exercício ou prática podem fornecer exemplos, gravar os acertos e erros e exibir a correção
em caso de erro (JUCÁ, 2006).
Programas educacionais do tipo simulador criam uma situação que se parece com a
realidade do aluno, essa situação pode ser criada de acordo com a ação do usuário, isso instiga
o aprendizado do aluno por meio de análise, testes e hipóteses criadas do ambiente gerado. O
ambiente virtual simulado é utilizado para ensinar temas complexos ou inviáveis de observar,
45
por exemplo, o movimento de translação da terra ao redor do sol (JUCÁ, 2006; TEIXEIRA,
2001).
Por fim, os jogos educacionais são os mais atrativos entre os estudantes, essa
modalidade de software educacional promove um ambiente em que o jogador age de forma a
alcançar um objetivo, o contexto inserido pode ser tanto para ensinar um assunto de uma
disciplina básica do ensino fundamental ou praticar e fortalecer o raciocínio lógico. Similar
aos simuladores, os jogos também podem criar uma situação parecida com a realidade, porém,
jogos dispõem de mais controle e entretenimento para o jogador (JUCÁ, 2006).
Este trabalho optou por software educacional tutorial, essa modalidade fará com que o
aluno tenha o aprendizado controlado, a sequência de conteúdos estimula o aprendiz a pensar
como foram realizadas as etapas anteriores para poder concluir a etapa atual.
A escolha do software educacional do tipo tutorial com a concepção receptiva fará
com que o assunto seja entregue controladamente para o aprendiz, dessa forma o próprio
aluno determina seu ritmo, mas assimilando as informações devidamente organizadas.
Portanto, o módulo educacional proposto no Capítulo 3 será um software educacional
do tipo tutorial que usará a forma receptiva de concepção de aprendizagem, a execução do
módulo educacional será feita sobre um software comercial de pontos de função denominado
Sizify e os tutoriais a serem planejados abordarão o método de contagem proposto pelo
IFPUG, junto a isso foi necessário buscar soluções que já possuem o objetivo ou propósito
similar à deste projeto.
2.5 FERRAMENTAS SIMILARES
A primeira e principal solução encontrada para este trabalho foi da OutSystems, esta
empresa desenvolve um ambiente integrado de desenvolvimento chamado Service Studio que
possui foco em desenvolvimento ágil de aplicações web e mobile.
O Service Studio possui uma funcionalidade de tutorial com propósito similar deste
trabalho, de ensinar a teoria durante a prática no software, a Figura 12 ilustra como é
apresentado o tutorial para o usuário e a ordem que as atividades devem ser realizadas, todas
essas atividades recebem apontamentos de uma flecha.
46
Figura 12. Tutorial em execução no Service Studio.
Fonte: OutSystems (2010).
Durante as pesquisas foi descoberto que essa funcionalidade da OutSystems era fruto
de um trabalho de mestrado da Universidade Técnica de Lisboa em que o autor tinha como
propósito diminuir a curva de aprendizado dos usuários do Service Studio, sendo essa a
principal diferença do objetivo da dissertação do mestrado e deste trabalho, pois nesse
trabalho o objetivo está em apoiar a aprendizagem de um determinado assunto utilizando um
software, no caso, ensinar APF através do Sizify (FERNANDES, 2011).
Outra ferramenta que possui o propósito similar ao resultado deste trabalho é o Ribbon
Hero, ele é um complemento dos softwares do pacote Office da Microsoft, seu objetivo é
melhorar o conhecimento dos recursos disponíveis nas novas versões dos softwares da
Microsoft e fazendo isso em forma de jogo.
47
Apesar de não ter muita similaridade quanto ao objetivo, o propósito é parecido quanto
a ensinar determinado assunto a partir de uma ferramenta, neste caso é possível aprender a
gerar gráficos, tabelas, entre outros recursos de aplicativos de escritório. A Figura 13 mostra
como o Ribbon Hero orienta e interage com o usuário durante o ensino.
Figura 13. Tutorial em execução Microsoft Office Word 2007 com Ribbon Hero 2.
Fonte: Produção do próprio autor.
As ferramentas são implementações para soluções específicas e não podem ser
adaptadas para nenhum outro problema. A proposta deste projeto é além de criar uma
ferramenta para auxílio na aprendizagem de APF, propor um componente capaz de ser
inserido em qualquer sistema web que utilize HTML como linguagem de marcação. Não foi
encontrada durante as pesquisas nenhuma solução web que realize de forma similar a
implementação descrita no Capítulo 3.
48
3 DESENVOLVIMENTO
Neste capítulo é apresentado o projeto do módulo de apoio à aprendizagem para APF
que rodará sobre o software Sizify e em sistemas web que utilizam HTML como linguagem
de marcação. Nas seções seguintes são apresentadas as definições gerais do projeto, as
tecnologias utilizadas, a apresentação da ferramenta e os testes com os usuários.
3.1 DEFINIÇÕES DO PROJETO
Esta seção aborda as definições do projeto que foram utilizadas para a implementação
da ferramenta, dentre as definições estão os requisitos funcionais, requisitos não funcionais,
regras de negócio, casos de uso, modelo do arquivo de dados e protótipos de tela.
3.1.1 Análise de requisitos
A análise de requisitos foi realizada levando em conta atributos de um software
educacional do tipo tutorial, para o desenvolvimento deste módulo é necessário haver
avaliações ao final de cada lição, o aluno também deve saber quais lições já percorreu, quais
questões obteve acerto e erro e ter liberdade para parar o tutorial em qualquer momento. Nas
subseções seguintes são apresentados os requisitos funcionais, não-funcionais e as regras de
negócio.
3.1.1.1 Requisitos funcionais
Os requisitos funcionais (RF) descrevem interações entre o software e seu ambiente e
como o software deve se comportar de acordo com certa ação (PFLEEGER, 2004).
RF01. O sistema deve permitir ao usuário habilitar/desabilitar o módulo
educacional;
RF02. O sistema deve permitir ao usuário selecionar o estudo de caso;
RF03. O sistema deve permitir ao usuário ler um texto explicativo e avançar
para a próxima lição;
RF04. O sistema deve permitir ao usuário ver quais lições já foram concluídas;
RF05. O sistema deve permitir ao usuário responder a avaliação da lição atual
do tutorial;
49
RF06. O sistema deve permitir ao usuário visualizar o tempo gasto para
realizar o tutorial e a porcentagem de acerto das questões;
RF07. O sistema deve permitir ao usuário interagir com a ferramenta tutorada
conforme solicitado pela lição.
3.1.1.2 Requisitos não-funcionais
Um requisito não-funcional (RNF) descreve uma restrição no software com o intuito
de limitar alternativas para solucionar um problema (PFLEEGER, 2004).
RNF01. O armazenamento do tutorial deve ser em linguagem de marcação;
RNF02. O tutorial deve ser desenvolvido em linguagem de programação
interpretada pelo cliente;
RNF03. O tutorial não pode influenciar em mais de 5 segundos no
carregamento da página;
RNF04. O tutorial deve ter acesso somente ao conteúdo HTML do sistema
tutorado;
RNF05. O armazenamento das lições executadas pelos usuários devem ser
armazenadas por COOKIES;
RNF06. O sistema deve permitir ao usuário sair, minimizar, maximizar e
mover a janela do módulo educacional.
A decisão da utilização de COOKIES para o armazenamento das respostas foi baseado
tendo em vista que os tutoriais serão programados para serem executados em um curto espaço
de tempo, mas dessa forma quando o usuário apagar os COOKIES ou trocar de computador,
as informações referentes ao tutorial em execução serão perdidas e o usuário deverá executar
as lições desde o início novamente. Esta alternativa também foi adotada para deixar o tutorial
independente da plataforma/software sobre a qual está rodando.
3.1.1.3 Regras de negócio
As regras de negócio (RN) se referem à aplicação do sistema podendo determinar
características e restrições de ações do software (SOMMERVILLE, 2007).
50
RN01. O usuário só pode ir para a próxima lição se responder corretamente a
pergunta da lição atual;
RN02. As opções de respostas das lições devem ser listadas de forma aleatória;
RN03. O estudo através do tutorial se dará por meio de estudos de caso;
RN04. O sistema deve suportar diversos estudos de caso;
RN05. O tutorial deve exibir três alternativas de resposta quando houver
avaliação na lição.
3.1.2 Diagramas de Casos de Uso
Um caso de uso é feito de acordo com o diálogo do sistema e o usuário ou um sistema
externo, esse diálogo descreve como será determinada funcionalidade que o sistema deve
implementar (PFLEEGER, 2004). A Figura 14 exibe os casos de uso e os atores da
ferramenta, de um lado o aluno executando as tarefas e do outro o sistema tutorado recebendo
as ações.
Figura 14. Diagrama de casos de uso
Dos Quadros 4 ao 6 apresentam os cenários dos casos de uso exibidos na Figura 14,
segundo Pfleeger (2004), os cenários de um caso de uso identificam todos os eventos que há
possibilidade de ocorrer e as suas respostas do sistema.
O primeiro caso de uso apresentado se refere à habilitação do módulo educacional,
essa atividade é essencial para o início do tutorial, quando habilitado é exibida uma janela
51
com os tutoriais disponíveis para navegar. Após a seleção do tutorial a ferramenta faz a leitura
do arquivo de dados e inicia o tutorial conforme é apresentado no Quadro 4.
Quadro 4. UC01 - Habilitar módulo educacional
Requisitos e Regras RF01, RF02 e RN04
Precondições A ferramenta tutorada está aberta
Pós-condições O módulo educacional foi habilitado
Cenários
Habilitar módulo
educacional
{principal}
1. O aprendiz clica em "Habilitar módulo educacional";
2. O sistema tutorado injeta o tutorial no seu código-fonte;
3. O módulo educacional apresenta um quadro informando os
tutoriais disponíveis;
4. O aprendiz seleciona o tutorial desejado e confirma;
5. O sistema faz a leitura do tutorial e encaminha para a primeira
lição.
Não confirma tutorial
{alternativo}
No passo 4, se o aprendiz cancelar a seleção do tutorial:
4.1 Retorna ao passo 3.
Próximo caso de uso descreve a navegação através do tutorial selecionado, após
habilitar o módulo educacional e selecionar o tutorial desejado o usuário deve seguir as
orientações exibidas na janela do tutorial. As orientações são exibidas dentro de lições, para
cada lição há um texto explicativo do conteúdo, uma avaliação do que foi explicado e por fim
uma seta apontando qual ação o usuário deve realizar. O Quadro 5 descreve as interações
entre o aprendiz e o sistema tutorado no decorrer do tutorial.
52
Quadro 5. UC02 - Estudar através do tutorial
Requisitos e Regras RF03, RF04, RF05, RF06, RF07, RN01, RN02, RN03 e RN05
Precondições O módulo educacional está habilitado
Pós-condições O aprendiz finalizou o tutorial
Cenários
Estudar através do
tutorial
{principal}
1. O aprendiz faz a leitura do texto explicativo da lição;
2. O aprendiz responde avaliação:
2.1. O aprendiz faz a leitura da pergunta;
2.2. O aprendiz seleciona uma resposta;
2.3. O módulo educacional informa que a resposta está
correta e libera o botão de Avançar.
3. O módulo educacional apresenta o texto instrucional
indicando o que o aprendiz deve fazer no sistema tutorado;
4. O aprendiz realiza a ação onde o tutorial fez a marcação;
5. Caso não seja a última lição, o módulo educacional carrega a
próxima lição e retorna ao passo 1, caso contrário, executa os
seguintes passos:
5.1. O módulo educacional exibe o tempo total para
realizar o tutorial e a porcentagem de acertos do
aprendiz;
5.2. O aprendiz visualiza as estatísticas
5.3. O módulo educacional exibe os tutoriais.
5.4 O caso de uso é encerrado
Resposta incorreta
{exceção}
No passo 2, se o usuário errar a resposta:
2.1. O sistema informa que a resposta está incorreta e tacha a
alternativa escolhida;
2.2. Retorna ao passo 2.
Ação incorreta
{exceção}
No passo 4, se o aprendiz realizar uma ação incorreta:
4.1 O módulo educacional informa que a ação está incorreta e
coloca o texto instrucional em negrito;
4.2 Retorna ao passo 3.
Por fim, o último caso de uso se refere à ação de desabilitar o módulo educacional,
essa atividade simplesmente fecha a janela que exibe o tutorial, o Quadro 8 descreve como
ocorre esse processo.
Quadro 6. UC05 – Desabilitar módulo educacional
Requisitos e Regras RF01
Precondições O módulo educacional está habilitado
Pós-condições O módulo educacional está desabilitado
Cenários
Desabilitar módulo
educacional
{principal}
1. O aprendiz clica em "Desabilitar módulo educacional";
2. O sistema tutorado retira o módulo educacional do código-
fonte.
O Apêndice C apresenta os cinco protótipos de tela que exemplificam o
funcionamento do tutorial no software Sizify relacionando-os com os casos de uso, estes
53
protótipos foram criados com auxílio de uma ferramenta gráfica, mas já simulando a interface
do módulo educacional.
3.1.3 Modelo do arquivo de dados
Para o desenvolvimento deste projeto, optou-se por escolher tecnologias que
funcionem independente da linguagem de programação e do banco de dados do software
sobre o qual roda o tutorial, i.e. o Sizify. O modelo de dados proposto para a ferramenta
educacional será feito em uma linguagem de marcação armazenada no servidor da aplicação.
Conforme mostra o modelo conceitual na Figura 15, o modelo de dados proposto será
responsável por manter os tutoriais, cada tutorial contém lições e essas lições devem conter o
título, o endereço da página no formato de Uniform Resource Locator (URL), um texto
explicativo contendo a teoria da técnica de APF aplicada na lição, uma imagem se necessário,
uma avaliação contendo uma questão de múltipla escolha, o texto instrucional referente à ação
que o usuário deve fazer após responder a avaliação, o tipo da ação a ser executada podendo
ser um clique em um botão ou link (click), alteração do valor de um campo de seleção ou
botão de checagem (change) ou uma tecla pressionada em um campo de texto ou em uma área
de texto com múltiplas linhas (keyup), por fim, os elementos HTML que serão apontados para
o usuário.
Figura 15. Modelo conceitual do arquivo de dados
54
Para o bom funcionamento do tutorial é necessário que todas as informações estejam
organizadas corretamente, no Quadro 9 é descrito que tipo de informação estará presente em
cada tag no modulo educacional, onde apresenta NC significa “não contém”, ou seja, que a
tag armazena apenas outras tags ao invés de um valor.
Quadro 7. Descrição das tags do arquivo de dados do tutorial
Campo Tipo Tag Descrição
Tutoriais NC <Tutoriais> Contém a lista de tutoriais
Tutorial NC <Tutorial> Contém os atributos referentes ao tutorial
Código Inteiro <TutorialId> Valor inteiro para identificar o tutorial
Nome Texto <Nome>
Nome do tutorial exibido no topo do módulo
educacional
Lições NC <Licoes> Contém a lista de lições
Lição NC <Licao> Contém os atributos referentes à lição
Código Inteiro <LicaoId> Valor inteiro para identificar a lição
Título Texto <Titulo>
Título da lição exibido abaixo do título do
tutorial
Endereço Texto <Endereco> Endereço da página onde a lição é exibida
Texto
explicativo
Texto <TextoExplicativo>
Texto explicativo da lição
Imagem Texto <Imagem>
Endereço da imagem que compõe o texto
explicativo
Avaliação Texto <Avaliacao> Questão de avaliação da lição
Respostas NC <Respostas>
Contém a lista de respostas da avaliação da
lição
Resposta NC <Resposta> Contém os atributos referentes à resposta
Valor Inteiro <Valor> Valor inteiro da resposta
Legenda Texto <Legenda> Texto visível da resposta
Correta Booleano <Correta> Valor de verdadeiro ou falso para resposta
Texto
instrucional
Texto <TextoInstrucional>
Texto para instruir como prosseguir para
próxima lição
Elementos NC <Elementos> Contém lista de elementos
Elemento NC <Elemento>
Contém os atributos referentes ao elemento
HTML apontado
Código Inteiro <ElementoId> Valor inteiro para identificar a elemento
Identificador Texto <Identificador> Seletor da tag HTML da aplicação
Ação Texto
<Acao>
Tipo da ação que deve ser feita na aplicação:
Click: clicar em um botão ou link.
Change: alterar o valor de um campo de
seleção ou botão de checagem.
Keyup: pressionar tecla em um campo de
texto ou em uma área de texto com múltiplas
linhas.
Valor Texto <Valor> Valor verificado após a ação
55
3.2 TECNOLOGIAS E FERRAMENTAS
Para o desenvolvimento do módulo de apoio a aprendizagem foi necessária a
utilização de uma ferramenta de desenvolvimento, uma linguagem de programação com um
framework e dois plugins, uma linguagem de estilo e a linguagem de marcação para
armazenamento, os quais são descritos a seguir.
3.2.1 NetBeans
A ferramenta de desenvolvimento utilizada neste trabalho foi o NetBeans, a escolha
foi feita a partir de uma busca de uma ferramenta que desse suporte às tecnologias utilizadas
no projeto, verificou-se então que o NetBeans alerta sobre falhas no código, realiza identação
automática, completava automaticamente o código e é opensource. A Figura 16 mostra como
foi o desenvolvimento do módulo de apoio à aprendizagem na ferramenta.
Figura 16. Desenvolvimento com a ferramenta NetBeans.
56
3.2.2 Javascript
Para realizar o desenvolvimento do módulo foi necessário utilizar uma linguagem de
programação que fosse executada no lado do cliente (Figura 17) e que não interferisse no
código da aplicação que utiliza o tutorial.
Figura 17. Visão geral das tecnologias web.
Fonte: Scorchsoft (2012)
A linguagem Javascript possui um número reduzido de tipos básicos, é interpretada
pelo navegador, a tipificação é dinâmica, suporta os conceitos básicos de programação:
decisão, laço de repetição, funções, recursividade e exceções, também possui recursos
avançados como listas dinâmicas contendo valores de tipos diferentes e manipulação do DOM
(Document Object Model) (SILVA, 2010).
Apesar de o Javascript possuir todos os recursos necessários para desenvolver esse
projeto, foi verificado que era possível otimizar o desenvolvimento através de um framework,
com o jQuery seria possível manipular os elementos HTML, atribuir estilos no módulo de
apoio a aprendizagem e ler o arquivo de dados com mais facilidade sem ter perda significativa
de desempenho.
Com a utilização do jQuery foi possível incluir dois plugins, o jquery.cookie.js para
criar, editar, recuperar e apagar os COOKIES utilizando apenas uma linha de código e o
jqfloat.js para criar um efeito de flutuação na flecha do módulo de apoio a aprendizagem. Para
gerar a janela do módulo foi necessário atribuir propriedades gráficas por jQuery através da
linguagem CSS (Cascading Style Sheets).
57
Utilizando esses recursos é possível ter grande integração entre as bibliotecas e os
COOKIES, pois todas as tecnologias conseguem se comunicar sem que haja interferência da
tecnologia utilizada pelo software que está incorporando o módulo educacional.
3.2.3 XML
Tendo os recursos de desenvolvimento definidos foi necessário utilizar um modo de
armazenamento que fosse independente de servidor e que fosse lido pelo jQuery, dentre as
opções viáveis esteve o XML.
Segundo Deitel (2003), o XML é um recurso acessível aos desenvolvedores por ser
simples de implementar, as linguagens de programação já possuem scripts para sua
manipulação e as aplicações podem ser diversas. Uma das aplicações do XML é o
armazenamento de dados, a principal vantagem é que ele pode ser lido por qualquer
linguagem de programação e não depende de instalação para seu funcionamento.
Para validar os campos do arquivo de dados foi utilizado um XML Schema, conforme
Quadro 10, neste formato é possível verificar o tipo aceito de cada atributo, se os elementos
são obrigatórios ou então se é permitido uma sequência de dados ou apenas um elemento.
58
Quadro 8. XML Schema do arquivo de dados <?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.w3schools.com"
xmlns="http://www.w3schools.com"
elementFormDefault="qualified">
<xs:element name="Tutoriais">
<xs:complexType>
<xs:sequence>
<xs:element name="Tutorial">
<xs:attribute name="TutorialId" type="xs:integer" use="required" />
<xs:attribute name="Nome" type="xs:string" use="required" />
<xs:element name="Licoes">
<xs:complexType>
<xs:sequence>
<xs:element name="Licao">
<xs:attribute name="LicaoId" type="xs:integer" use="required" />
<xs:attribute name="Titulo" type="xs:string" use="required" />
<xs:attribute name="Endereco" type="xs:string" use="required" />
<xs:attribute name="TextoExplicativo" type="xs:string" />
<xs:attribute name="Imagem" type="xs:string" />
<xs:attribute name="Avaliacao" type="xs:string" />
<xs:element name="Respostas">
<xs:complexType>
<xs:sequence>
<xs:element name="Resposta">
<xs:attribute name="Valor" type="xs:integer" use="required" />
<xs:attribute name="Legenda" type="xs:string" use="required" />
<xs:attribute name="Correta" type="xs:boolean" use="required" />
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:attribute name="TextoInstrucional" type="xs:string" use="required" />
<xs:element name="Elementos">
<xs:complexType>
<xs:sequence>
<xs:element name="Elemento">
<xs:attribute name="ElementoId" type="xs:integer" use="required" />
<xs:attribute name="Identificador" type="xs:string" use="required" />
<xs:attribute name="Valor" type="xs:string" />
<xs:element name="Acao" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value-"click"/>
<xs:enumeration value="change"/>
<xs:enumeration value="keyup"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
59
O Quadro 11 exemplifica o que foi descrito no XML Schema exibindo apenas a lição
1, essa lição faz parte do tutorial aplicado no teste com os alunos da disciplina de Engenharia
de Software.
Quadro 9. Lição 1 do arquivo de dados aplicado no teste com o Sizify <Licao>
<LicaoId>1</LicaoId>
<Titulo>O método</Titulo>
<Endereco>/</Endereco>
<TextoExplicativo>
Análise de Pontos de Função é o método padrão para medir o software do
ponto de vista do usuário pela quantificação da funcionalidade fornecida.
A aplicação da técnica pode beneficiar para estimativa de custos e
recursos de um projeto ou até mesmo para verificação do tamanho e
benefícios de uma melhoria num software.
@enter@
A contagem pode ser realizada antes da codificação do software e não
depende da linguagem da programação, ou seja, é possível ter os Pontos de
Função (PF) de uma aplicação apenas com os Requisitos Funcionais do
Usuário.
</TextoExplicativo>
<Avaliacao>Um dos objetivos da Análise de Pontos de Função é:</Avaliacao>
<Respostas>
<Resposta>
<Valor>1</Valor>
<Legenda>Calcular quantas tabelas um sistema terá</Legenda>
<Correta>false</Correta>
</Resposta>
<Resposta>
<Valor>2</Valor>
<Legenda>Medir a funcionalidade que o usuário solicita e
recebe</Legenda>
<Correta>true</Correta>
</Resposta>
<Resposta>
<Valor>3</Valor>
<Legenda>Ajudar no processo de depuração de um software</Legenda>
<Correta>false</Correta>
</Resposta>
</Respostas>
<TextoInstrucional>
Após responder a pergunta da lição o módulo educacional te indicará o
que deve ser feito. Nesse tutorial nós vamos realizar uma Análise de
Pontos de Função de um Sistema de Pedidos.
@enter@
Clique em "Nova Análise" para prosseguir.
</TextoInstrucional>
<Elementos>
<Elemento>
<ElementoId>0</ElementoId>
<Identificador>#bt-newana</Identificador>
<Valor></Valor>
<Acao>click</Acao>
</Elemento>
</Elementos>
</Licao>
60
3.3 APRESENTAÇÃO DA FERRAMENTA
A seção anterior elencou todas as tecnologias necessárias para implementar este
projeto, essa seção apresenta todas as funcionalidades desenvolvidas relacionadas aos
identificadores dos respectivos requisitos funcionais e regras de negócio abordados na
Seção 3.1.
3.3.1 Seleção do tutorial
Para dar início é necessário que o módulo educacional esteja habilitado, por padrão
essa opção já vem habilitada. A seguir o usuário escolhe um estudo de caso que está no
arquivo de dados (RF02, RF03 e RN04; ver Subseção 3.1.1) e clica em Iniciar tutorial,
conforme Figura 18.
Ainda na Figura 18 é possível observar no círculo pontilhado vermelho que há três
opções de janela, a primeira opção se refere à posição do módulo. Ao clicar neste botão o
módulo é movido para o lado oposto do navegador e essa preferência fica salva em COOKIE
para as próximas lições.
A segunda opção se refere a minimizar e maximizar o módulo, ao clicar neste botão o
módulo é ocultado e a opção de maximizar é exibida, essa opção apenas esconde o módulo
temporariamente, pois ao mudar de tela a janela volta a aparecer.
A terceira e última opção é responsável por desabilitar o módulo de apoio a
aprendizagem, ao clicar neste botão o módulo é ocultado e todos os três botões desaparecem
dando lugar a uma única opção de habilitar (RF01), além de quando a janela está desabilitada
nenhuma leitura é realizada no arquivo de dados.
61
Figura 18. Teste com Sizify - Seleção do tutorial.
Após ter clicado em Iniciar tutorial, o módulo educacional recupera a primeira lição
do estudo de caso, verifica qual o endereço desta lição e redireciona o usuário à página
correta, se o usuário sair da página da lição atual, o módulo apresenta uma mensagem
informando que o usuário não está na página correta e disponibiliza um botão para voltar a
página anterior conforme mostra a Figura 19.
62
Figura 19. Teste com Sizify - Página incorreta.
3.3.2 Leitura e avaliação
Com o tutorial iniciado o módulo exibe em qual lição o usuário está (RF04), o título e
o texto explicativo, após realizar a leitura deve-se então responder a avaliação (RF05)
conforme Figura 20, lembrando que as respostas estão ordenadas aleatoriamente (RN02) e
que se o usuário errar, a opção é tachada e desabilitada, tendo que selecionar outra opção até
escolher a resposta correta.
63
Figura 20. Teste com Sizify - Leitura e avaliação.
3.3.3 Instrução para avançar
A Figura 21 mostra o que acontece após ter respondido corretamente a avaliação, no
círculo amarelo é possível ver o texto instrucional gerado pelo módulo educacional,
paralelamente a isso os elementos HTML que devem ter interação com o usuário são
mapeados, após o mapeamento o módulo exibe uma seta no primeiro elemento e insere uma
borda no mesmo, destacado pelo círculo pontilhado vermelho, ao realizar a ação solicitada, a
flecha é direcionada para outro elemento até concluir todos os passos, com os passos feitos o
módulo carrega uma nova lição e exibe para o usuário.
Vale ressaltar que nem todas as lições possuem avaliação, pode haver situações onde é
necessário apenas instruir o usuário a realizar uma determinada ação, nesses casos o texto
instrucional é exibido e a flecha é apontada em determinado elemento sem que o usuário
tenha que passar pelo texto explicativo e pela avaliação.
64
Figura 21. Teste com Sizify - Instrução para avançar.
3.3.4 Resultado
Ao término de todas as lições, o módulo apresenta uma estatística do desempenho do
usuário, conforme Figura 22, dentre as informações exibidas estão o tempo total para realizar
todas as lições do tutorial (RF06) e o número e porcentagem de acertos das avaliações na
primeira, segunda e terceira tentativa, estas estão realçadas pelo círculo pontilhado vermelho.
Depois de verificar o rendimento, o usuário pode iniciar um novo tutorial, se não
possuir outro tutorial, o módulo educacional apresenta uma mensagem informando que não há
tutoriais disponíveis. O módulo de apoio à aprendizagem não permite que o usuário repita o
mesmo tutorial para não ter duplicidade de dados na aplicação.
65
Figura 22. Teste com Sizify - Fim do tutorial.
3.4 TESTES E AVALIAÇÃO
Nesta seção são apresentados os testes a fim de detectar defeitos e identificar
melhorias no módulo educacional. Para avaliar o funcionamento da ferramenta deste trabalho
foram realizados testes com a aplicação de análise de pontos de função, denominada Sizify e
em um software da empresa MBR11, chamado Gepron Oficinas.
Apesar de não estar inserido nos objetivos deste trabalho, foi realizado outro teste para
verificar se o módulo educacional pode ser utilizado por outro sistema web, sendo este
realizado em parceria com a empresa MBR11, uma empresa de tecnologia sediada em
Itapema que desenvolve soluções para órgãos públicos. Para este teste foi criado um tutorial
reduzido apenas para avaliar todas as funcionalidades do módulo de apoio à aprendizagem.
Para os testes com o Sizify, a 2reach disponibilizou sem custo, trinta licenças para
usuários nomeados para utilizarem o sistema até junho de 2014, conforme Anexo B. Das 30
licenças foram utilizadas 14 destas conforme abaixo:
66
Duas licenças para administrar os usuários, sendo uma para o desenvolvedor
do módulo educacional e outra para a orientadora deste trabalho;
Duas licenças para os avaliadores deste trabalho realizarem testes e
apresentarem suas conclusões;
Dez licenças para os alunos de Ciência da Computação que realizaram o
tutorial de APF.
3.4.1 Testes com o Sizify
O tutorial desenvolvido para ser aplicado no teste com o software Sizify foi criado a
partir da fundamentação teórica deste trabalho, o estudo de caso em questão foi o Sistema de
Pedidos, neste estudo de caso o usuário consegue visualizar todos os passos da APF em um
assunto com baixa curva de aprendizado, a sequência das lições está no Apêndice A.
O grupo de usuários escolhido para a avaliação foi à turma de Engenharia de Software
do sétimo período do curso de Ciência da Computação da UNIVALI, sendo composto por dez
acadêmicos e todos aceitaram realizar o teste.
O módulo educacional não apresentou nenhum problema, a leitura do arquivo de
dados e a indicação pra primeira lição foram realizadas com sucesso. Ao realizar a ação da
segunda lição, o Sizify apresentou uma mensagem informando que ocorreu um erro no
servidor, esse problema foi reportado a 2reach que informou que está verificando o ocorrido.
Foram identificados dois problemas durante a execução do teste que dificultou a
realização da avaliação conforme planejado. Ao determinar o escopo e a fronteira da
aplicação, detectou-se uma falha em que era necessário cadastrar duas vezes as funções de
dados, o problema pôde ser corrigido retirando uma linha do código que restringia as ações
dos botões após a ação determinada pelo módulo educacional. Ao determinar a complexidade
das funções de dados, identificou-se uma falha que desabilitava o campo de texto após digitar
corretamente o valor solicitado, visto que o campo não estava sendo habilitado na próxima
instrução, a solução encontrada foi retirar outra linha do código.
Apesar dos problemas durante a execução, a conclusão obtida através da observação
dos usuários durante a avaliação foi de satisfação, visto que todos os avaliadores seguiram as
67
orientações do módulo educacional e liam atentamente as informações do texto explicativo a
fim de acertar as avaliações na primeira tentativa.
No fim da avaliação, foi solicitado aos testadores que respondessem uma pesquisa de
satisfação, com o intuito de identificar se os usuários conseguiram sanar as dúvidas que
tinham em APF com a ajuda do módulo educacional, a Tabela 5 apresenta o número, a
questão e as possíveis respostas.
Tabela 5. Perguntas da pesquisa de satisfação aplicada no teste com Sizify
Nº Pergunta Resposta
1 As informações presentes no tutorial que você acabou de realizar são
suficientes para entender Análise de Pontos de Função?
Sim ou Não
2 O objetivo do Módulo de Apoio a Aprendizagem é auxiliar no ensino
de Análise de Pontos de Função na pratica em uma ferramenta
comercial. O objetivo foi cumprido?
Sim ou Não
3 Você teve dificuldades em manusear o Módulo de Apoio a
Aprendizagem?
Sim ou Não
4 Você encontrou algum bug durante o tutorial? Sim ou Não
5 Dê uma nota de 0 a 10 para o Módulo de Apoio a Aprendizagem: 0 a 10
6 Descreva suas sugestões e críticas: Livre
Ao analisar as respostas foi realizado um levantamento para quantificar as respostas
dadas pelos usuários (Quadro 12), onde as células da linha superior representam o número da
pergunta, as células da primeira coluna representam o usuário e a células da última linha
refere-se ao totalizador de cada questão, também foram analisadas as críticas e sugestões,
sendo que três dos levantamentos realizados foram propostos em trabalhos futuros na Seção
4.1.
Quadro 10. Resultado da pesquisa de satisfação aplicada no teste com o Sizify Nº 1 Nº 2 Nº 3 Nº 4 Nº 5
1 Sim Sim Não Sim 8
2 Sim Sim Não Sim 9
3 Sim Sim Não Não 10
4 Sim Sim Não Sim 8
5 Sim Sim Não Sim 9
6 Sim Sim Sim Sim 8
7 Sim Sim Sim Sim 8
8 Sim Sim Não Sim 8
9 Sim Sim Não Sim 9
10 Sim Sim Sim Sim 8
100% (sim) 100% (sim) 70% (não) 10% (não) Média: 8,5
Fonte: Produção do próprio autor.
68
Quatro testadores informaram que não deram a nota máxima pelos bugs encontrados
durante o teste, já o único usuário a dar a nota máxima se manifestou dizendo que o propósito
foi atingido e que o módulo educacional cumpriu seu objetivo em auxiliar o ensino de APF.
3.4.2 Testes com o Gepron Ouvidoria
Dentre as aplicações da MBR11 está o módulo de Ouvidoria, este tem o objetivo de
gerenciar as manifestações da comunidade e centralizar a comunicação entre os responsáveis.
Esta avaliação foi realizada por onze usuários, escolhidos sem um critério específico,
tendo como testadores quatro estudantes de Administração, cinco estudantes e um bacharel
em Ciência da Computação e um estudante de Tecnologia em Sistemas para Internet. O teste
foi realizado individualmente e cada usuário teve a tarefa de cadastrar uma manifestação de
um requerente anônimo e visualizar a lista de manifestações não resolvidas, a sequência das
lições está no Apêndice B.
A Figura 23 mostra como foi exibido o módulo educacional durante o teste no
software Gepron Ouvidoria, as lições foram projetadas para ensinar o papel do ouvidor e
como ele pode visualizar as manifestações no sistema.
Figura 23. Teste com Gepron Ouvidoria - Leitura e avaliação.
69
Apesar do software da MBR11 possuir duas bibliotecas Javascript e 10 complementos
dessas bibliotecas, o módulo de apoio à aprendizagem executou sem problemas gráficos e
realizou apontamentos exatamente nos locais mapeados, a Figura 24 exibe o apontamento
sendo feito em um campo no Gepron Ouvidoria.
Figura 24. Teste com Gepron Ouvidoria - Instrução para avançar.
Neste teste não foi solicitado uma pesquisa de satisfação e sim uma opinião ao término
das três lições, nove dos onze testadores disseram que não tinham nenhuma consideração a
fazer, pois o tutorial estava claro e entenderam o papel da ouvidoria, um testador disse que a
janela do módulo educacional poderia usar cores que chamasse mais a atenção do usuário,
outro testador disse que prefere utilizar livros e consultas na internet ao invés de seguir
tutoriais.
70
4 CONCLUSÕES
O objetivo deste trabalho foi de apoiar a aprendizagem da metodologia de Análise de
Pontos de Função (APF) através da ferramenta Sizify utilizando o módulo de apoio a
aprendizagem e a partir disso propor um modelo de tutorial que possa ser inserido em
sistemas web que utilizam HTML como linguagem de marcação.
A ferramenta resultante se mostrou útil para ser aplicada em diversas soluções que
possuem alta complexidade na execução de determinada tarefa, estas tarefas podem ser
executadas na prática e a curva de aprendizado diminuir.
Na fundamentação teórica (Capítulo 2), foram analisadas as métricas de software e
mais detalhadamente a Análise de Pontos de Função, a técnica em se mostrar consistente, de
importância em contratos do governo e utilizada em projetos em empresas privadas. Também
foi apresentado o software Sizify e como um software educacional deveria ser implementado
para auxiliar no ensino e por fim foram analisadas duas ferramentas similares que serviram de
referência para o desenvolvimento da ferramenta.
No desenvolvimento da solução proposta (Capítulo 3), levantaram-se requisitos e
modelagem da ferramenta, criou-se também um modelo de arquivo de dados a ser utilizado
pelo módulo educacional e os protótipos de tela. Ainda no capítulo foram elencadas as
tecnologias necessárias para implementar a ferramenta.
A escolha do Javascript deu-se por ser uma linguagem de programação executada no
cliente e facilmente incluída no código do sistema que deseja usar o módulo educacional. A
utilização do framework jQuery agilizou o desenvolvimento por simplificar o código
Javascript e ter uma grande comunidade presente na internet.
Para armazenamento foram pesquisadas algumas formas de manter o tutorial, o XML
se mostrou uma opção relevante devido a sua portabilidade entre plataformas e sua
padronização internacional. O XML é um padrão recomendado pelo W3C, órgão de
padronização da internet.
No fim do capítulo foi ainda apresentada à ferramenta e os testes que foram realizados
para saber se a solução satisfaz os usuários em utilizá-la para aprender determinado assunto,
71
os testes se mostraram bastante satisfatórios e algumas observações foram destinadas a
trabalhos futuros.
Pode-se concluir que todos os objetivos foram cumpridos, avaliando a versão final do
trabalho, a solução proposta teve seu foco mais direcionado ao módulo educacional para
sistemas web do que para o aprendizado de pontos de função propriamente dito, visto que a
solução resultante pode ser aplicada em muitos sistemas até mesmo dentro da UNIVALI. Mas
mesmo assim a utilização de APF nos testes serviu para mostrar que assuntos com
complexidade elevada para estudantes poderiam ser simplificados através da solução.
Além de tudo, a realização pessoal foi extremamente gratificante, pois foi possível
criar uma solução envolvendo HTML, CSS, Javascript e XML, ter uma visão mais crítica
quanto à análise de sistemas e compreender a importância dos testes com os usuários, além de
conhecer empresários, desenvolvedores e pesquisadores da área de métricas de software.
4.1 TRABALHOS FUTUROS
Como este trabalho teve o objetivo de criar um módulo de apoio à aprendizagem e
propor um módulo educacional para sistemas web, sugere-se que possam ser dados dois
caminhos para futuros trabalhos.
O primeiro caminho seria aprimorar os tutoriais em APF de forma que sejam
contempladas as contagens de projetos de melhoria e de aplicação instalada, além de fazer
com que o usuário explore melhor a gestão de prazo e custo a partir de uma análise, este
caminho pode ser feito através de novos estudos de caso.
O outro caminho seria o aprimoramento do módulo educacional para sistemas web,
isso poderia ser feito através da adequação da solução para um plugin jQuery que possa ser
configurado de acordo com a necessidade e preferência do programador contemplando
também uma funcionalidade para enviar os resultados do tutorial por e-mail.
Ainda seguindo a linha do aprimoramento do módulo educacional, poderia ser
desenvolvido um software que fizesse a geração do arquivo de dados a partir de cliques nos
locais dos elementos que receberão apontamentos sem que haja a necessidade de modificar o
XML diretamente.
72
REFERÊNCIAS
ABREU, T. C.; ARAÚJO M. A. P.; MOTA, L. S. Métricas de software: como utilizá-las no
gerenciamento de projetos de software. Revista Engenharia de Software Magazine, Rio de
Janeiro, v. 21, p. 51-55, 2010.
AGUIAR, Maurício. Pontos de função ou pontos por caso de uso? Como estimar projetos
orientados a objetos. Developer’s Magazine, Rio de Janeiro, jun. 2003. Disponível em:
<http://www.bfpug.com.br/Artigos/UCP/Aguiar-
Pontos_de_Funcao_ou_Pontos_por_Caso_de_Uso.pdf>. Acesso em: 13 mar. 2013.
BARCELLOS, Monalessa P. Métricas de software: um importante pilar da melhoria de
processos de software. Revista Engenharia de Software Magazine, Rio de Janeiro, v. 24, p.
31-36, 2010.
DEITEL, Harven M. XML, como programar. Porto Alegue: Bookman, 2003.
FERNANDES, João F. N. Softening the Learning Curve of Software Development Tools.
2011. Disponível em: < https://dspace.ist.utl.pt/bitstream/2295/1066690/1/dissertation.pdf>.
Acesso em: 10 out. 2013.
FERREIRA, R.; HAZAN, C. Uma aplicação da análise de pontos de função no
planejamento e auditoria de custos de projetos de desenvolvimento de sistemas. Marinha
e SERPRO, Rio de Janeiro, maio 2010. Disponível em:
<https://www4.serpro.gov.br/wcge2010/artigos/Artigo-
Uma%20Aplicacao%20da%20Analise%20de%20Pontos%20de%20Funcao%20no%20Planej
amento%20de%20Auditoria%20e%20Custos%20de%20Projetos%20de%20Desenvolvimento
%20de%20Sistemas.pdf>. Acesso em: 14 mar. 2013.
FREIRE, Herval. Calculando estimativas: o Método de Pontos de Caso de Uso. Developer’s
Magazine, Rio de Janeiro, v. 78, fev. 2003. Disponível em:
<http://pt.scribd.com/doc/4484908/Pontos-de-Caso-de-Uso>. Acesso em 13 mar. 2013.
JUCÁ, Sandro C. S. A relevância dos softwares educativos na educação profissional.
Ciências & Cognição, ano 03, v. 08, 2006. Disponível em: <
http://www.cienciasecognicao.org/revista/index.php/cec/article/view/571/359>. Acesso em:
13 maio 2013.
MECENAS, Ivan. Análise de pontos de função - Estudo Teórico, Crítico e Prático. Rio de
Janeiro: Alta Books, 2009.
MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO. Roteiro de Métricas de
Software do SISP: versão 2.0. – Brasília, 2012. Disponível em:
<http://www.governoeletronico.gov.br/biblioteca/arquivos/roteiro-de-metricas-de-software-
do-sisp-versao-2.0/view>. Acesso em: 01 jul. 2013.
PFLEEGER, Shari L. Engenharia de software: teoria e prática. São Paulo: Prentice Hall,
2004.
PRESSMAN, Roger S. Engenharia de software. São Paulo: MCGRAW-Hill, 2006.
73
RAMOS, Edla M. F. Educação e informática - reflexões básicas. Graf & Tec, Florianópolis,
v. 0, n. 0, p. 11-26, 1996.
SCORCHSOFT. 2012. A Basic Web Technology Overview. Disponível em:
<http://www.scorchsoft.com/blog/web-technologies-overview/>. Acesso em: 10 out. 2013
SILVA, Maurício Samy. JavaScript - Guia do programador. São Paulo: Novatec Editora,
2010.
SIMÕES, Guilherme S. Publicação Eletrônica [mensagem pessoal]. Mensagem recebida por
<[email protected]> em 7 dez. 2013.
SIZIFY. Conheça o Sizify. Disponível em: <http://www.sizify.net/br/features/>. Acesso em:
15 abr. 2013
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison-Wesley, 2007.
STANDISH GROUP. The Standish Group Report: Chaos. The Standish Group
International Inc., v. 1, p. 2-8, 2011.
TAJRA, Sanmya F. Informática na Educação: novas ferramentas pedagógicas para o
professor na atualidade. São Paulo: Érica, 2008.
TEIXEIRA, Jaqueline F. Uma discussão sobre a classificação de software educacional.
Ano. Disponível em <http://www.ccuec.unicamp.br/revista/infotec/artigos/jacqueline.html>
Acesso em: 15 maio 2009.
VAZQUEZ, C.; SIMÕES, G.; ALBERT, R.. Análise de pontos de função: medição,
estimativas e gerenciamento de projetos de software. São Paulo: Érica, 2003.
VIEIRA, Everton L. Uso do conceito de passos obrigatórios para aprimorar o processo de
contagem do método “Pontos de Caso de Uso”. 2007. Disponível em: <
http://www.bfpug.com.br/Artigos/UCP/Everton%20Luiz%20Vieira.pdf>. Acesso em: 22 abr.
2013.
74
ANEXO A. TERMO DE COMPROMISSO
Figura 25. Termo de compromisso.
75
ANEXO B. TERMO DE LICENCIAMENTO DE USO
Figura 26. Termo de licenciamento de uso de software.
76
ANEXO C. E-MAIL DE GUILHERME SIQUEIRA
SIMÕES
Bruno Hasse <[email protected]>
TCC sobre APF
Guilherme Siqueira Simões <[email protected]> Sat, Dec 7, 2013 at 1:31
PM
To: Bruno Hasse <[email protected]>
Cc: "[email protected]" <[email protected]>
Prezado Bruno,
Agradeço o contato.
Não recordo de algum artigo que aborde a dificuldade de ensino de APF. Talvez isso seja bom pois seu
trabalho trará inovação.
Nos nossos treinamentos o que percebo como maior dificuldade em algumas pessoas para assimilar os
conceitos corretamente é olhar do ponto de vista do usuário, que é a base da APF. Muitas pessoas não
conseguem se desvincular da implementação do projeto quando estão fazendo a APF. O que irá provocar
erros significativos.
Outro ponto também comum de dificuldade é de algumas pessoas entenderem que Esforço e Tamanho
Funcional (PFs) são grandezas distintas (embora relacionadas). Confunde-se muito PFs com Horas.
Temos um fórum de discussão que talvez seja útil para você obter informações de outros
colegas: http://br.groups.yahoo.com/group/livro-apf/
E caso tenha interesse em avaliar outros trabalhos sobre APF, temos uma lista
em http://fattocs.com/pt/citacoes
Em 7 de dezembro de 2013 11:32, Bruno Hasse <[email protected]> escreveu:
Bom dia, estou finalizando meu trabalho de conclusão de curso, este trabalho é voltado ao ensino de APF,
essa deficiência foi identificada pela minha orientadora durante a disciplina de engenharia de software do
curso de ciência da computação, porém, os avaliadores pediram que eu busque artigos ou relatos sobre a
dificuldade no ensino de APF.
Vocês da Fatto possuem algum documento para me auxiliar nesse problema?
Atenciosamente
Bruno Hasse
--
[]s
Guilherme Siqueira Simões
www.linkedin.com/in/guilhermesimoes
FATTO Consultoria e Sistemas
www.fattocs.com
Estimativa, Medição e Requisitos de Software
Fones: (61) 4063-7484 / (11) 4063-4658
(21) 4063-5311 / (27) 98111-7505
Figura 27. E-mail de Guilherme Siqueira Simôes.
77
APÊNDICE A. TUTORIAL UTILIZADO NO TESTE COM O
SIZIFY
Do Quadro 13 ao 34 é descrito como foi a interação dos alunos com a ferramenta
durante o teste do Sizify, dentre os campos exibidos nos quadros estão o título, avaliação,
resposta correta, respostas incorretas e o texto instrucional, não estão presentes as
informações de apontamento nos elementos HTML.
Quadro 11. Lição 1: O método Texto explicativo Análise de Pontos de Função é o método padrão para medir o software do
ponto de vista do usuário pela quantificação da funcionalidade fornecida. A
aplicação da técnica pode beneficiar para estimativa de custos e recursos de
um projeto ou até mesmo para verificação do tamanho e benefícios de uma
melhoria num software.
A contagem pode ser realizada antes da codificação do software e não
depende da linguagem da programação, ou seja, é possível ter os Pontos de
Função (PF) de uma aplicação apenas com os Requisitos Funcionais do
Usuário.
Avaliação Um dos objetivos da Análise de Pontos de Função é:
Resposta correta Medir a funcionalidade que o usuário solicita e recebe
Resposta incorreta Calcular quantas tabelas um sistema terá
Resposta incorreta Ajudar no processo de depuração de um software
Texto instrucional Após responder a pergunta da lição o módulo educacional te indicará o que
deve ser feito. Nesse tutorial nós vamos realizar uma Análise de Pontos de
Função de um Sistema de Pedidos.
Clique em "Nova Análise" para prosseguir.
Quadro 12. Lição 2: Tipo de contagem Texto explicativo O primeiro passo para a contagem é determinar o tipo de contagem, podendo
ser um Projeto de desenvolvimento, Projeto de melhoria ou uma Aplicação
instalada.
A contagem de pontos de função de um projeto de desenvolvimento mede a
funcionalidade entregue ao usuário final na sua primeira instalação, sendo
assim, neste tipo também está incluso as funções de conversão de dados para
o software em desenvolvimento caso seja necessário. Na sequência, em
projetos de melhoria são contadas todas as modificações solicitadas pelos
usuários durante o desenvolvimento ou depois da instalação de uma
aplicação que foi feita uma contagem anteriormente. Por fim, o cálculo de
pontos de função de uma aplicação instalada se refere às funcionalidades
existentes por uma aplicação já concluída, seu número de PF muda de
acordo com os projetos de melhorias caso solicitado.
Avaliação Nesse tutorial você vai contar os pontos de função de uma aplicação que
ainda não foi implementada, que tipo de contagem deve ser escolhida?
Resposta correta Projeto de desenvolvimento
Resposta incorreta Projeto de melhoria
Resposta incorreta Aplicação instalada
Texto instrucional Para cadastrar a análise clique no primeiro botão "+Nova", então digite
"UNIVALI" no primeiro campo e "Sistema de Pedidos" no segundo, por fim
clique em "Salvar".
78
Quadro 13. Lição 3: Escopo e Fronteira da aplicação Texto explicativo Após ser definido o tipo de contagem é necessário determinar o escopo da
contagem, na qual determina o conjunto de funções incluídas no processo,
podendo conter todas as funcionalidades, apenas funcionalidades utilizadas
pelo usuário ou apenas funcionalidades específicas como relatórios,
cadastros e etc.
Fixado o escopo, próximo passo é limitar a fronteira da aplicação, ou seja,
quais as funções de dados são mantidas pelo software e quais não fazem
parte do domínio da aplicação, nesse passo o analista deve se basear no
ponto de vista do usuário e na visão de negócio, não em considerações
técnicas.
Avaliação No Sistema de Pedidos que você vai analisar neste tutorial não mantém o
arquivo de Vendedor, isso quer dizer que:
Resposta correta O arquivo de dados de Vendedor está fora da fronteira da aplicação
Resposta incorreta O arquivo de dados de Vendedor está dentro da fronteira da aplicação
Resposta incorreta O arquivo de dados de Vendedor não pode ser utilizado pela aplicação
Texto instrucional O nosso Sistema de Pedidos é uma contagem de um projeto em
desenvolvimento em que é contado todas as funcionalidades existentes e o
arquivo de Vendedores não faz parte da contagem pois é disponibilizado por
outro sistema.
Para prosseguir digite no escopo da contagem "Todas as funcionalidades do
sistema de pedidos" e em Fronteira "O arquivo de Vendedor está fora da
fronteira da aplicação por ser mantido por outro sistema da UNIVALI", por
fim clique em "Salvar".
Quadro 14. Lição 4: Funções de dados Texto explicativo São denominadas funções de dados todas as funcionalidades entregues ao
usuário para atender sua necessidade de dados internos e externos à
aplicação, essas funcionalidades são classificadas em Arquivos Lógicos
Internos (ALI) e Arquivos de Interface Externa (AIE).
O termo arquivo significa um conjunto de dados relacionados logicamente e
reconhecido pelo usuário, sendo assim um arquivo de APF pode conter uma
ou mais tabelas de um banco de dados ou um ou mais arquivos do sistema
operacional, pois a forma de implementação não é relevante para definição
das funções do tipo dado. A figura abaixo mostra como as funções de dados
interagem com as funções de transação.
Avaliação Um arquivo é definido como:
Resposta correta Um grupo de dados logicamente relacionados
Resposta incorreta Um requisito de persistência de dados
Resposta incorreta Uma tabela do banco de dados do sistema
Texto instrucional Para dar início ao cadastro dos arquivos clique em "Funções de Dados".
79
Quadro 15. Lição 5: Arquivos Lógicos Internos (ALI) Texto explicativo Um ALI é um conjunto de dados logicamente relacionados ou informações
de controle, esses dados devem estar dentro da fronteira da aplicação e
devem ser identificados pelo usuário. O ALI deve guardar os dados que são
mantidos por funções transacionais, onde manter significa adicionar, editar
ou eliminar esses dados.
Uma informação de controle é um dado que pode alterar o comportamento
de uma função do tipo transação, como por exemplo, uma tela de
configuração de preferência que determina quais campos devem ser exibidos
durante um cadastro.
Avaliação No Sistema de Pedidos que você está contado, o arquivo de Nota Fiscal é
mantido pela aplicação e o arquivo de Vendedores é lido pelo Sistema de
Pedidos, mas é mantido por outra aplicação da UNIVALI, que tipo de
arquivos devem ser cadastrados?
Resposta correta Um ALI para Nota Fiscal e um AIE para Vendedor
Resposta incorreta Um AIE para Nota Fiscal e um ALI para Vendedor
Resposta incorreta 2 ALIs para Nota Fiscal e Vendedor
Texto instrucional Legal, agora que você sabe que os dados armazenados pela aplicação
contada são considerados ALI, cadastre o arquivo de Nota Fiscal clicando
em "Novo ALI".
Quadro 16. Lição 6: Arquivos Lógicos Internos (ALI) – Parte 2 Texto instrucional O Impacto é utilizado nas contagens de melhoria então não é preciso se
preocupar com essa opção.
Digite "Nota Fiscal" no nome do ALI e clique em "Salvar".
Quadro 17. Lição 7: Arquivos de Interface Externa (AIE) Texto explicativo Como o ALI, o AIE também é um conjunto de dados logicamente
relacionados ou informações de controle que são identificados pelo usuário,
mas os dados estão fora da fronteira da aplicação, ou seja, esses arquivos são
ALI de outra aplicação.
Tanto para um ALI quanto para um AIE, é necessário que pelo menos uma
função do tipo transação esteja relacionada ao arquivo para que ele exista, ou
seja, se um arquivo está na contagem e não está sendo lido ou mantido por
nenhuma função transacional, esse arquivo não deve fazer parte da
contagem.
Avaliação Qual a principal diferença entre um ALI e um AIE?
Resposta correta Um AIE é lido e não pode ser mantido pela aplicação contada
Resposta incorreta Um AIE é lido e mantido pela aplicação contada
Resposta incorreta Um AIE é mantido e não pode ser lido pela aplicação contada
Texto instrucional Como foi descrito na Fronteira da aplicação, o arquivo de Vendedor é
mantido por outro sistema da UNIVALI clique em “Novo AIE” para iniciar
o cadastro.
Quadro 18. Lição 8: Arquivos de Interface Externa (AIE) – Parte 2 Texto instrucional Selecione a opção de "Não quero associar este AIE a um ALIagora..." pois
não há uma contagem em que os Vendedores fazem parte, digite "Vendedor"
no nome e clique em "Salvar".
80
Quadro 19. Lição 9: Determinando a complexidade das funções de dados Texto explicativo Para determinar a complexidade de um ALI ou AIE, é preciso saber quantos
Dados Elementares Referenciados (DER) e Registros Lógicos Referenciados
(RLR) cada arquivo contém.
O DER é um campo único no arquivo e reconhecido pelo usuário, quando
duas aplicações mantêm ou referenciam um ALI ou um AIE, deve-se contar
somente o tipo de dado utilizado pelo software em análise. RLR é um
subgrupo de tipos de dados, para cada tipo de dado deve haver um tipo de
registro, cada tipo de registro adicional deve ser avaliado se essa relação
entre as duas entidades de dados não está relacionada com apenas uma
instância de uma entidade relacionada.
Avaliação Os dados que compõem a nota fiscal são nome do cliente, CNPJ e endereço,
também estão presentes os itens da nota, sendo que cada item é composto
por quantidade, descrição e preço unitário. Quantos RLR e DER possui o
arquivo Nota Fiscal?
Resposta correta 2 RLR's e 6 DER's
Resposta incorreta 1 RLR e 6 DER's
Resposta incorreta 6 RLR's e 1 DER
Texto instrucional Para determinar a complexidade do ALI, clique em "Nota Fiscal".
Quadro 20. Lição 10: Determinando a complexidade das funções de dados – Parte 2 Texto instrucional Como uma nota fiscal possui os dados da nota em si e os itens pertencentes a
ela, cadastre dois Registros Lógicos Referenciados, clique em "Novo RLR",
digite "Nota Fiscal", clique em “Salvar” e repita o processo para "Item".
Faça o cadastro dos Dados Elementares Referenciados clicando em "Novo
DER", digite "Nome do cliente" e clique em "Salvar", agora repita o
procedimento de novo DER para "CNPJ", "Endereço", "Quantidade",
"Descrição" e "Preço unitário". Finalize clicando em "Funções de Dados".
Quadro 21. Lição 11: Determinando a complexidade das funções de dados – Parte 3 Texto instrucional Determine a complexidade da AIE clicando em "Vendedor".
Quadro 22. Lição 12: Determinando a complexidade das funções de dados – Parte 4 Texto instrucional Para o registro clique em "Novo RLR", digite "Vendedor" e clique em
"Salvar".
Para os dados clique em "Novo DER",digite "Matrícula" e clique em
"Salvar", repita o processo com"Nome", "Meta" e "Data de nascimento".
81
Quadro 23. Lição 13: Função de Transação Texto explicativo Funções do tipo transação representam a funcionalidade entregue ao usuário
para processamento dos dados pela aplicação, elas são classificadas em
Entradas Externas (EE), Consultas Externas (CE) ou Saídas Externas (SE).
Toda função transacional é um processo elementar, ou seja, é a menor
unidade de atividade significativa do usuário e quando concluída sua
execução deve manter a aplicação em estado consistente.
Avaliação O Sistema de Pedidos possui um ALI de Nota Fiscal e um AIE de Vendedor,
a aplicação é composta por uma função de emissão de nota fiscal, outra
função de listagem dos vendedores e uma última de um relatório de nota
fiscal por vendedor. Quantas Funções de Dados e Funções de Transação a
aplicação possui?
Resposta correta Duas Funções de Dados e três Funções de Transação
Resposta incorreta Duas Funções de Transação e três Funções de Dados
Resposta incorreta Seis Funções de Dados
Texto instrucional Iniciando o cadastro das funcionalidades entregues ao usuário, clique em
"Nova Função de Transação".
Quadro 24. Lição 14: Entrada Externa Texto explicativo Uma EE processa dados ou altera informações de controle através de ações
vindas de fora da fronteira da aplicação, durante a ação pelo menos um ALI
ou uma informação de controle deve sofrer alguma alteração ou
processamento.
Avaliação Qual a principal intenção de uma entrada externa?
Resposta correta Atualizar um arquivo lógico interno
Resposta incorreta Atualizar um arquivo lógico interno ou um arquivo de interface externa
Resposta incorreta Atualizar um arquivo de interface externa
Texto instrucional As funções básicas do sistema são de emissão e relatório de nota fiscal e
listagem de vendedores. Primeiro cadastre a emissão de nota fiscal, digite
"Emitir Nota Fiscal" no nome da função, selecione a opção "EE" da
classificação e em seguida clique em "Salvar".
82
Quadro 25. Lição 15: Determinando a complexidade de Funções de Transação Texto explicativo As regras e definições de complexidade e contribuição são determinadas
pela quantidade de DER (Dado Elementar Referenciado) e ALR (Arquivo
Lógico Referenciado).
Deve-se contar um ALR para cada ALI mantido e/ou para cada ALI ou AIE
durante o processamento função do tipo transação Contar um DER para cada
campo não-repetido e reconhecido pelo usuário e/ou uma mensagem do
sistema para indicar a ocorrência de erro durante o processamento,
confirmando que esse processamento foi completo ou verificando que esse
processamento deverá continuar.
Avaliação Você deverá determinar a complexidade da Emissão da Nota Fiscal,
considerando que o arquivo de dados mantido é de Nota Fiscal e os campos
presentes são CNPJ, Nome do cliente, Endereço, Quantidade e Descrição,
Preço unitário também possui uma mensagem perguntando se deseja
realmente gravar a nota fiscal e um botão de gravar. Quantos DERs e ALRs
possui essa transação?
Resposta correta 1 ALR e 8 DERs
Resposta incorreta 1 ALR e 6 DERs
Resposta incorreta 3 ALR e 6 DERs
Texto instrucional Para determinar a complexidade da Emissão de Nota Fiscal você deve clicar
em "Novo ALR", depois em "+ Nova", em seguida digitar "Nota Fiscal" e
por fim clicar em "Salvar".
Para cadastrar os DERs você deve clicar em "Novo DER", clique em "+
Nova", digite "CNPJ" e clique em "Gravar". Repita esse procedimento para
"Nome do cliente", "Endereço", "Quantidade", "Descrição", "Preço
unitário", "Mensagem de confirmação" e "Botão de Gravar". Observe que foi
cadastrado além dos campos que estão presentes no formulário de emissão
da nota, a mensagem de confirmação e o botão de gravar, pois esses dados
fazem parte da transação.
Quadro 26. Lição 16: Consulta Externa Texto instrucional Clique em "Nova Função de Transação" para cadastrar uma Consulta
Externa.
Quadro 27. Lição 17: Consulta Externa – Parte 2 Texto explicativo Uma CE envia dados ou informações de controle para fora da fronteira da
aplicação, sua aplicação deve ser restrita a exibir informações através de
recuperação de dados ou informações de controle. Durante a recuperação de
uma requisição, não deve ser feito nenhum processamento contendo
fórmulas, cálculos ou geração de dados derivados. Na execução de uma CE
não é alterado nenhum ALI e nem o comportamento do sistema.
Avaliação Qual a principal intenção de uma consulta externa?
Resposta correta Enviar dados para fora da fronteira da aplicação por meio de simples
recuperação de dados de um arquivo
Resposta incorreta Alterar o comportamento do sistema
Resposta incorreta Atualizar arquivos lógicos internos
Texto instrucional Temos uma recuperação de dados, no nome digite "Listar Vendedores",
selecione "CE", clique em "Inclusão" e "Salvar".
83
Quadro 28. Lição 18: Determinando a complexidade da Consulta Externa Texto instrucional Para determinar a complexidade da Listagem de Vendedores você deve
clicar em "Novo ALR", depois em "+ Nova", em seguida digitar "Vendedor"
e por fim clicar em "Salvar".
Para cadastrar os DERs você deve clicar em "Novo DER", clique em "+
Nova", digite "Matrícula" e clique em "Gravar". Repita esse procedimento
para "Nome", "Meta" e "Data de nascimento". Como este caso é somente
uma recuperação de dados, os DERs são somente as informações presentes
na lista.
Quadro 29. Lição 19: Saída Externa Texto instrucional Clique em "Nova Função de Transação" para cadastrar uma Saída Externa.
Quadro 30. Lição 20: Saída Externa – Parte 2 Texto explicativo Uma SE vai além da simples recuperação de dados, para ter uma Saída
Externa é necessário que haja processamento das informações, podendo
conter cálculos matemáticos, fórmulas, totalizadores, derivação dos dados,
enfim, qualquer operação que processe dados ou informações de controle e
envie para fora da fronteira da aplicação.
Não necessariamente o processamento dos dados deve ser apresentado ao
usuário, a lógica de processamento pode também incluir, editar, excluir
dados de um ALI ou alterar o comportamento do sistema.
Avaliação Qual a principal diferença entre uma saída externa e uma consulta externa?
Resposta correta A saída externa deve ter processamento das informações extraídas
Resposta incorreta A consulta externa deve ter processamento das informações extraídas
Resposta incorreta Não existe nenhuma diferença
Texto instrucional Para a extração de dados com processamento digite no nome "Relatório de
Nota Fiscal por Vendedor", selecione "SE" e "Salvar".
Quadro 31. Lição 21: Determinando a complexidade da Saída Externa Texto instrucional Para determinar a complexidade do Relatório de Nota Fiscal por Vendedor
você deve clicar em "Novo ALR", depois em "+ Nova", em seguida digitar
"Vendedor" e por fim clicar em "Salvar", repita o processo para "Nota
Fiscal" também.
Para cadastrar os DERs você deve clicar em "Novo DER", clique em "+
Nova", digite "Nome do vendedor" e clique em "Gravar". Repita esse
procedimento para "Total vendido", "Quantidade vendida" e "Nome do
cliente da última venda".
Quadro 32. Lição 22: Resultados Texto instrucional Você chegou ao fim do tutorial, a tabela de complexidade apresenta todas as
funções com seus pontos de função, para visualizar seu rendimento das
questões respondidas clique em "Home".
84
APÊNDICE B. TUTORIAL UTILIZADO NO TESTE COM O
GEPRON OUVIDORIA
Os Quadros 35, 36 e 37 descrevem como foi a interação dos usuários com a
ferramenta durante o teste do Gepron Ouvidoria, dentre os campos exibidos nos quadros estão
o título, avaliação, resposta correta, respostas incorretas e o texto instrucional, não estão
presentes as informações de apontamento nos elementos HTML.
Quadro 33. Lição 1: O Gepron Texto explicativo O Gepron é uma aplicação destinada a empresas que desejam controlar
determinados procedimentos com intuito de gerar informação para tomada
de decisão, gerenciamento e organização.
A Ouvidoria tem a função de receber críticas, sugestões, reclamações e deve
agir de forma imparcial no sentido de mediar conflitos entre as partes.
Avaliação Qual a finalidade do Gepron?
Resposta correta Controlar procedimentos da empresa para gerar informação
Resposta incorreta Realizar limpeza dos arquivos temporários do computador
Resposta incorreta Formatar o computador dos usuários
Texto instrucional Após responder a pergunta da lição o módulo educacional te indicará o que
deve ser feito. Nesse tutorial você irá realizar uma manifestação para a
Ouvidoria.
Clique em "Adicionar" para prosseguir.
Quadro 34. Lição 2: Realizar manifestação Texto explicativo O ouvidor tem o papel de mediar às manifestações e cobrar respostas dos
responsáveis o mais breve possível.
Os responsáveis recebem notificações de novos registros e podem retornar a
manifestação com uma solução ou encaminhar o registro para outro setor.
Avaliação Qual o papel do ouvidor?
Resposta correta Controlar as manifestações de modo que sejam resolvidas o mais rápido
possível
Resposta incorreta Resolver todos os possíveis problemas de uma organização imediatamente
Resposta incorreta Atender telefonemas e passar para os responsáveis
Texto instrucional A manifestação a ser registrada se refere a um mau atendimento de um
médico em um posto de saúde, selecione a origem "Pessoalmente", o tipo
"Reclamação" e digite no assunto "Péssimo atendimento do médico Fulano
de Tal".
Na descrição informe que "O médico Fulano de Tal me tratou com
desrespeito dizendo que eu estava fingindo ter dor ao invés de me examinar
corretamente", por fim selecione o grupo "Saúde", o subgrupo "Atenção
Básica", o destinatário "Marcos João da Silva" e clique em "Salvar".
85
Quadro 35. Lição 3: Listar abertas Texto explicativo Ao registrar uma manifestação a Ouvidoria, o responsável pelo setor ou o
ouvidor recebem uma notificação informando novo registro, a manifestação
então é tramitada pelos setores até que a solução é comunicada ao requerente
pelo ouvidor.
Avaliação Ao registrar uma manifestação o sistema:
Resposta correta Encaminha o registro ao responsável pelo setor e este retorna com a solução
Resposta incorreta Comunica todos os usuários que existe uma manifestação pendente na
Ouvidoria
Resposta incorreta Resolve automaticamente baseado no histórico de manifestações
Texto instrucional Parabéns, você acaba de registrar uma manifestação no sistema de
Ouvidoria, para finalizar o tutorial você deve clicar em "Listar Abertas" para
visualizar seu registro.
86
APÊNDICE C. PROTÓTIPOS DE TELAS PARA
IMPLEMNETAÇÃO DO PROJETO
A Figura 28 apresenta uma janela apenas pedindo para que o usuário selecione um
tutorial destacado no círculo vermelho tracejado na figura, essa janela é exibida quando o
aluno habilita o módulo educacional. Além da possibilidade de selecionar o tutorial estão
disponíveis as opções de minimizar a janela e fechar o módulo educacional, sendo que estes
estão posicionados no canto superior direito.
Figura 28. Protótipo referente ao UC01.
Após a escolha do tutorial, o módulo educacional abre a primeira lição com o texto
explicativo destacado pelo círculo vermelho tracejado na figura e a questão de avaliação e as
respostas destacados pelo círculo amarelo, o propósito da avaliação é instigar o aluno a pensar
e pesquisar, pois a resposta correta da questão não estará inserida no texto explicativo, dessa
forma fará o aluno refletir sobre o conteúdo exposto conforme a Figura 29.
87
Figura 29. Protótipo referente à primeira etapa do UC02.
Caso ele tenha errado a resposta, o módulo educacional deixa o texto da questão
selecionada tachado e informa que ele deve tentar novamente, ao selecionar a resposta correta,
o módulo educacional exibe o botão de avançar destacado pelo círculo vermelho tracejado na
figura, conforme a Figura 30.
88
Figura 30. Protótipo referente à segunda etapa do UC02.
A Figura 31 representa o fim de uma lição, o módulo educacional apresenta o texto
instrucional destacado pelo círculo amarelo na figura, nele está contido como o aluno deve
proceder para avançar para a próxima lição, além do texto, uma flecha destacada pelo círculo
vermelho tracejado na figura, apontará onde o aluno deve realizar a ação. A ação pode ser um
clique em um determinado botão, o preenchimento de um campo de texto ou o clique em uma
caixa de seleção.
89
Figura 31. Protótipo referente à terceira etapa do UC02.
Ao final do tutorial o módulo educacional parabeniza o usuário pelo término de todas
as lições e informa seu rendimento no tutorial, informando quantidades de questões
respondidas corretamente na primeira, segunda e terceira tentativa, também informa o tempo
para conclusão do tutorial destacado pelo círculo vermelho tracejado na figura. Logo abaixo
dos rendimentos do usuário são listados outros tutoriais destacados pelo círculo amarelo na
figura, conforme a Figura 32.
90
Figura 32. Protótipo referente ao UC03.