ads:
UNIVERSIDADE PAULISTA
AVALIAÇÃO DA QUALIDADE DE SOFTWARE
APLICADO COMO FERRAMENTA DE APOIO
DIDÁTICO COM BASE NA NORMA ISO 9126
LEO BRUNSTEIN
Dissertação apresentada ao Programa de
Mestrado em Engenharia de Produção – Vice-
Reitoria de Pesquisa e Pós-Graduação da
Universidade Paulista - UNIP, para obtenção do
título de mestre em Engenharia de Produção.
Área de Concentração: Gestão da Informação
SÃO PAULO
2007
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
UNIVERSIDADE PAULISTA
AVALIAÇÃO DA QUALIDADE DE SOFTWARE
APLICADO COMO FERRAMENTA DE APOIO
DIDÁTICO COM BASE NA NORMA ISO 9126
LEO BRUNSTEIN
Dissertação apresentada ao Programa de
Mestrado em Engenharia de Produção – Vice-
Reitoria de Pesquisa e Pós-Graduação da
Universidade Paulista - UNIP, para obtenção do
título de mestre em Engenharia de Produção.
Área de Concentração: Gestão da Informação
Orientador: Prof. Dr. Mauro de Mesquita Spinola
SÃO PAULO
2007
ads:
Brunstein, Leo
Avaliação da Qualidade de Software Aplicado como Ferramenta de Apoio
Didático com Base na Norma ISO 9126 / Leo Brunstein.
157p.
Dissertação (mestrado) – Universidade Paulista. Programa de Pós-graduação
em Engenharia de Produção. São Paulo, 2007.
Área de concentração: Gestão da Informação.
Orientador: Prof. Dr. Mauro de Mesquita Spinola.
1. Qualidade de software; 2. Norma ISO 9126; 3. Didática; 4. Software
didático; 5. Software educativo; 6. Custeio ABC.
UNIVERSIDADE PAULISTA
AVALIAÇÃO DA QUALIDADE DE SOFTWARE APLICADO COMO
FERRAMENTA DE APOIO DIDÁTICO COM BASE NA NORMA ISO 9126
Dissertação apresentada ao Programa de
Mestrado em Engenharia de Produção – Vice-
Reitoria de Pesquisa e Pós-Graduação da
Universidade Paulista - UNIP, para obtenção do
título de mestre.
Área: Gestão da Informação
Orientador: Prof. Dr. Mauro de Mesquita Spinola
LEO BRUNSTEIN
Aprovado em:
BANCA EXAMINADORA
_____________________________________/___/___
Prof. Dr. Mauro de Mesquita Spinola
Universidade Paulista - UNIP
_____________________________________/___/___
Prof. Dr. Marcelo Schneck de Paula Pessoa
Universidade Paulista - UNIP
_____________________________________/___/___
Prof. Dr. Nilton Nunes Toledo
Universidade de São Paulo - USP
DEDICATÓRIA
A meu pai, em especial;
A minha mãe, em particular;
A minha irmã, pelo incentivo;
A meu filho, com satisfação;
A minha esposa, com amor.
AGRADECIMENTOS
Em especial, à atenção e às críticas a este trabalho e à compreensão nos momentos
de dificuldade que me dispensaram os professores Dr. Marcelo Schneck de Paula
Pessoa, Dr. Nilton Nunes Toledo, e Dr. Oduvaldo Vendrametto, e em particular ao
meu orientador, Dr. Mauro de Mesquita Spinola, pela grande contribuição durante
todo o processo, desde a elaboração até a entrega definitiva deste trabalho.
À coordenação, demais professores e a todos os funcionários da estrutura
administrativa do curso, que sempre foram cordiais e cooperaram muito durante o
desenvolvimento deste trabalho.
Ao meu pai, por ter-me incentivado na carreira acadêmica, sendo sempre o meu
maior referencial nesta escolha, sempre acompanhando e compartilhando os frutos
dessa iniciativa, que aqui representa mais um passo de grande importância em
minha vida.
À dedicação e paciente trabalho de revisão de Lia Ana Trzmielina.
À compreensão e ao apoio de familiares, e a todos, que de forma direta ou indireta,
acompanharam e incentivaram a realização deste trabalho.
“A proa e a popa de nossa Didática será investigar e descobrir o método
segundo o qual os professores ensinem menos e os estudantes aprendam mais;
haja menos barulho, menos enfado, menos trabalho inútil e, ao contrário, haja mais
recolhimento, mais atrativo e mais sólido progresso.” (Comênio, João Amós.
Didáctica Magna; tratado da arte universal de ensinar tudo a todos.)
Calouste Gulberkian, Lisboa, 1966.
RESUMO
Com a crescente utilização de software como ferramenta de apoio didático nas mais
diversas áreas de conhecimento, faz-se necessário atentar para a finalidade didática
e a adequação à matéria de ensino em sala de aula. Isto porque, ainda hoje,
professores e instituições de ensino utilizam-se de produtos de software
desenvolvidos para outras finalidades, adaptando seu uso para a aplicação em sala
de aula. Neste caso, ficam algumas questões: Este software atinge os objetivos
didáticos em sua aplicação? Os alunos estão satisfeitos com a utilização, facilitação
do aprendizado e a exploração do assunto proporcionado pelo software? O software
funciona corretamente, é eficiente como ferramenta de apoio ao ensino e atende às
questões técnicas específicas para o hardware utilizado? A Norma ISO 9126,
destinada à avaliação da qualidade de software, foi escolhida como base
fundamental para este trabalho, por permitir responder de forma satisfatória a estas
questões, entre tantas outras. Esta Norma é ampla e ao mesmo tempo tão
específica quanto se queira. Ela contempla a avaliação da qualidade de software por
três pontos de vista: a visão da equipe de desenvolvimento do software, a do usuário
e a do gerente. Para este trabalho essas visões foram aplicadas respectivamente
para as questões técnicas, de aplicação e didáticas do software, ou seja, a visão da
equipe de desenvolvimento sobre o software, a visão dos alunos sobre a aplicação
do software em sala de aula e a visão do professor sobre a eficiência didática do
software. Assim, a Norma ISO 9126 é utilizada como base para o desenvolvimento
da metodologia de avaliação de software aplicado em sala de aula como ferramenta
de apoio didático. Esta metodologia resulta em pontuações para cada ponto de vista
da avaliação do software, permitindo saber, em cada caso, se o software atinge
níveis de pontuações como: Insuficiente, Regular, Bom ou Excelente (orientação da
Norma ISO 9126). Com isso, os pontos fortes e fracos do software são indicados,
como também, as prioridades de melhorias e correções a serem realizadas (se for o
caso). Os resultados apurados auxiliam na decisão final sobre a aceitação ou
rejeição do software avaliado ou, ainda, de sua continuidade de uso em sala de aula
ou não.
Palavras-chave: Qualidade de software; Norma ISO 9126; Didática; Software
didático; Software educativo; Custeio ABC.
ABSTRACT
With the increasing use of software as didactic support tool in the most diversified
knowledge areas, it is necessary to consider the didactic objectives and adapt the
materials to the classroom setting. This is necessary because, still today, professors
and educational institutions utilize software intended for different usages, adapting
them for application in the classroom. In this case, some questions arise: Does the
software reach the educational objectives in its application? Are the students
satisfied with the utilization, simplification in learning and the in-depth study of the
subject allowed by the software? Does the software function properly, is it efficient as
a teaching support tool and does it attend to the technical issues specific to the
hardware utilized? The ISO 9126 Norm, intended to evaluate software quality, was
chosen as a fundamental basis for this project, because it allows for satisfactory
responses to these questions and others. This Norm is broad and at the same time
as specific as one wants. It contemplates the evaluation of software quality through
three points of view: the point of the team that produced the software, the user’s point
of view, and the manager’s point of view. For this paper, those standpoints were
applied, respectively, to the technical questions of application and didactics of the
software, the standpoint of the software production team, the standpoint of the
students in respect to the application of the software in the classroom, and the
standpoint of the teacher, in respect to the educational effectiveness of the software.
Thus, the ISO 9126 Norm is utilized as the basis for the development of a
methodology for the evaluation of software applied in classroom as an educational
tool. This methodology results in scores for each point of view of the evaluation of the
software, allowing to know, in each case, if the software reaches levels of scoring
such as: insufficient, satisfactory, good, or excellent (ISO 9126 Norm orientation).
Being so, the strong and the weak points of the software will be pinpointed, as well
as priorities of improvements and corrections to be carried out (if need be). The
results will favor in the final decision on the acceptance or rejection of the evaluated
software, and also on the continuity or not of its usage in classroom.
Keywords: Software quality; ISO 9126 Norm; Didactics; Didactic software;
Educational software; ABC Cost.
LISTA DE FIGURAS
Figura 1 Áreas de estudo de um software para aplicação didática......................... 27
Figura 2 Áreas de estudo da dissertação................................................................ 28
Figura 3 Esquema didático (adaptado de Mattos, 1960)................. ..................... .. 39
Figura 4 Componentes do processo didático e do processo de ensino
(LIBÂNEO, 2004)...................................................................................................... 39
Figura 5 Método lógico e método didático (adaptado de Mattos, 1960)............... .. 42
Figura 6 Valor medido e nível de pontuação........................................................... 57
Figura 7 Escala para a métrica e exemplo de valor de referência adotado.......... .. 79
Figura 8 Custeio ABC, visão geral da técnica.........................................................104
Figura 9 Modelo de custos ABC adaptado pelo autor........................................... ..105
Figura 10 Tela principal do software................................................ ..................... ..110
Figura 11 Gráfico de vínculos (modelo ABC completo)................... ..................... ..111
Figura 12 Gráfico das atividades (análise dos custos indiretos por atividade)........112
Figura 13 Gráfico de vínculos “parcial” (análise de um departamento)...................113
LISTA DE TABELAS
Tabela 1 Apontamentos de Oliveira (2001) sobre software educativo.................. .. 30
Tabela 2 Apontamentos de Mattos (1960) sobre didática..... .................................. 34
Tabela 3 Apontamentos de Nérici (1993) sobre material didático.............. ............. 44
Tabela 4 Características e subcaracterísticas da Norma ISO 9126........... ............. 58
Tabela 5 Avaliador e finalidade da avaliação para cada ponto de vista da Norma. 61
Tabela 6 Subcaracterísticas avaliadas conforme o perfil do avaliador....... ............. 62
Tabela 7 Finalidade da avaliação para cada subcaracterística da Norma
segundo o autor................................................................................ .......... ............. 68
Tabela 8 Modelo para avaliação da aplicação de um software didático pelos
alunos.......... ............................................................................................... ............. 73
Tabela 9 Modelo para totalizar os pontos avaliados pelos alunos... ..................... .. 76
Tabela 10 Média final das avaliações da aplicação de um software didático....... .. 77
Tabela 11 Modelo para a média das avaliações com referência à Norma. ............. 81
Tabela 12 Referências para a definição de relacionamento entre os subitens
avaliados e as subcaracterísticas da Norma.... ....................................................... 82
Tabela 13 Modelo para avaliação da qualidade de um software didático pelos
pontos de vista da equipe de desenvolvimento e dos alunos, com base na
Norma ISO 9126....................................................................................................... 85
Tabela 14 Avaliação dos requisitos básicos de qualidade de um software
didático pelos pontos de vista da equipe de desenvolvimento e dos alunos,
com base na Norma ISO 9126.... ..................................................... .......... ............. 89
Tabela 15 Modelo para avaliação didática de um software didático pela visão
do professor, com base na Norma ISO 9126.............. .......... .................................. 92
Tabela 16 Modelo de avaliação das pontuações finais de um software
didático avaliado pelos três pontos de vista com base na Norma ISO 9126......... .. 98
Tabela 17 Total de pontuações das avaliações dos alunos.. ..................................122
Tabela 18 Média final das avaliações da aplicação do software didático................123
Tabela 19 Relação da avaliação dos alunos com as subcaracterísticas da Norma.125
Tabela 20 Avaliação dos requisitos básicos de qualidade do software didático
pelos pontos de vista da equipe de desenvolvimento e dos alunos, com base na
Norma ISO 9126............................................................................... ..................... ..127
Tabela 21 Pontuações e observações sobre o software por subcaracterística da
Norma.......... ............................................................................................... .............137
Tabela 22 Modelo para avaliação didática do software didático pela visão do
professor, com base na Norma ISO 9126................................................................ 139
Tabela 23 Avaliação completa das pontuações obtidas do software didático
avaliado.....................................................................................................................143
SUMÁRIO
1 INTRODUÇÃO E OBJETIVOS...................................................... ...................... 13
1.1 Apresentação do tema ..................................................... ...................... 14
1.2 Objetivos.......................................................................... ...................... 15
1.3 Importância....... ............................................................... ...................... 15
1.3.1 Software didático................................................ ...................... 17
1.3.2 Norma ISO 9126....................................................................... 21
1.3.3 Custos ABC........................................................ ...................... 23
1.4 Esclarecimentos............................................................... ...................... 24
1.5 Estruturação..................................................................... ...................... 26
2 SOFTWARE DIDÁTICO .............................................................. ...................... 29
2.1 Software educativo................................................................................. 29
2.2 Didática............................................................................ ...................... 32
2.3 Ensino-aprendizagem...................................................... ...................... 37
2.4 Processo de ensino e processo didático................................................ 38
2.5 Comunicação, linguagem, método e material didático.... ...................... 40
2.6 Avaliação qualitativa e quantitativa.................................. ...................... 46
3 QUALIDADE DE SOFTWARE............................................................................. 48
3.1 Necessidade de se avaliar um software................................................. 48
3.2 Aspectos relevantes para a definição da metodologia de avaliação...... 51
3.3 Sobre a Norma ISO 9126...... .......................................... ...................... 54
3.4 A avaliação segundo a Norma ISO 9126......................... ...................... 56
3.5 Pontos de vista segundo a Norma ISO 9126................... ...................... 58
4 METODOLOGIA DE AVALIAÇÃO....................................................................... 60
4.1 Sobre a metodologia de avaliação................................... ...................... 60
4.1.1 A avaliação e o perfil do avaliador..................... ...................... 61
4.1.2 As subcaracterísticas essencialmente técnicas e da aplicação 64
4.1.3 Os requisitos básicos......................................... ...................... 68
4.1.4 A ordem de aplicação das avaliações................ ...................... 70
4.2 Aplicando a metodologia de avaliação............................ ...................... 70
4.2.1 Determinação dos requisitos básicos................. ...................... 71
4.2.2 Preparação para a avaliação dos alunos........... ...................... 72
4.2.3 Aplicação de testes e a avaliação dos alunos.... ...................... 74
4.2.4 Cálculo das médias das avaliações dos alunos. ...................... 76
4.2.5 Relacionando a avaliação dos alunos com a Norma................ 80
4.2.6 Pontuação das avaliações essencialmente técnicas e da
aplicação...... .......................................... ..................... ...................... 83
4.2.7 Avaliação e pontuação pelo ponto de vista didático................. 90
4.2.8 Pontuações finais e nível de pontuação............. ...................... 96
4.2.9 Julgamento das avaliações................................ ...................... 99
5 APLICAÇÃO DA METODOLOGIA DE AVALIAÇÃO ..................... ......................103
5.1 Conceitos de custos ABC e ABM..... ......................................................103
5.1.1 Modelo de custos ABC proposto pelo autor....... ......................104
5.1.2 Sobre o software...... .......................................... ......................106
5.1.3 Desenvolvimento do software....... ..................... ......................107
5.1.4 Aplicação do software........................................ ......................109
5.2 A aplicação da metodologia de avaliação ..................... ......................114
5.2.1 Determinação dos requisitos básicos................. ......................114
5.2.2 A avaliação da aplicação do software pelos alunos...................121
5.2.3 Cálculo das médias das avaliações dos alunos. .......................122
5.2.4 Relacionando a avaliação dos alunos com a Norma.................125
5.2.5 Avaliação pela equipe de desenvolvimento....... .......................126
5.2.6 Avaliação técnica e da aplicação com base nos
requisitos básicos....................................................... .......................129
5.2.7 Avaliação e pontuação pelo ponto de vista didático..................138
5.2.8 Pontuações finais do software e para os três pontos de vista...142
5.2.9 Julgamento das avaliações................................ .......................144
6 CONCLUSÃO...... .......................................................................... .......................148
6.1 Sobre a dissertação.... ............................................................................148
6.2 Contribuição..... ............................................................... .......................150
6.3 Sobre a metodologia de avaliação e sua aplicação......... .......................151
6.4 Trabalhos futuros........ ..................................................... .......................152
REFERÊNCIAS...... .......................................................................... .......................154
GLOSSÁRIO............................................................................................................157
13
1 INTRODUÇÃO E OBJETIVOS
A motivação para a pesquisa que gerou este trabalho nasceu da necessidade
de se obter uma metodologia clara e objetiva, que avaliasse de forma eficaz um
software de custos ABC (Activity-Based Costing), desenvolvido e aplicado pelo autor
em vários cursos deste gênero.
A questão principal, além de se avaliar um software específico, seria avaliar a
adequação de um software para a aplicação didática, respondendo à pergunta:
como avaliar a qualidade de um software adotado como ferramenta de apoio
didático?
Assim, é apresentada neste trabalho uma metodologia de avaliação da
qualidade de software utilizado como ferramenta de apoio didático. A Norma ISO
9126 é utilizada como base para esta avaliação, considerando a apreciação dos três
entes fundamentais envolvidos diretamente com software, a saber: a equipe de
desenvolvimento de software (ou a entidade que a represente), os alunos (usuários
finais) e o professor (um especialista ou uma equipe formada pela instituição de
ensino que o represente).
Os resultados gerados determinam as pontuações que indicam a adequação
ou inadequação do software avaliado diante dos objetivos da avaliação.
As avaliações utilizadas neste processo permitem uma análise de pontos
onde o software deva ser melhorado ou mesmo modificado, visando a uma nova
versão, caso tenha sido aceito, ou ainda, para um futuro enquadramento como
“adequado” se rejeitado.
No caso da avaliação ser realizada em mais de um software, aqueles que
forem aprovados quanto à sua adequação poderão ser diferenciados pela pontuação
final e, também, através das pontuações obtidas nas avaliações dos três entes
fundamentais (equipe de desenvolvimento, alunos e professor), determinando qual o
software, entre os selecionados, que é o mais apropriado à aplicação desejada.
14
1.1 Apresentação do tema
Quando um software é aplicado como ferramenta de apoio didático em sala
de aula, é necessário avaliá-lo considerando o envolvimento da equipe de
desenvolvimento de software, dos alunos e do professor. Cada um apresenta uma
visão e objetivos bem distintos em relação à mesma aplicação; por exemplo: para a
equipe de desenvolvimento, o software deve atender a seus requisitos técnicos
definidos quando de sua elaboração e, ao final, apresentar uma qualidade tal que
permita o seu bom funcionamento. Para o aluno, o software deve ser de fácil
operação, permitindo o melhor aproveitamento de seu tempo para o aprendizado, e
também ser claro e objetivo em relação ao assunto tratado, possibilitando a
verificação prática daquilo que se aprendeu na teoria. Para o professor, o software
deve atender a objetivos didáticos, auxiliar no processo de ensino e servir de apoio
eficaz ao processo de aprendizagem dos alunos.
Desta forma, é fundamental que a avaliação da qualidade de um software e
de sua aplicação seja feita pelos três pontos de vista: equipe de desenvolvimento,
alunos e professor. Assim, é indicada a aplicação de três avaliações, uma para cada
ponto de vista.
Estas avaliações indicam os pontos onde o software deva ser melhorado ou
mesmo adaptado, para que o mesmo venha a atender de forma satisfatória aos
objetivos almejados. Após as avaliações, uma pontuação final é obtida para cada
ponto de vista e, também, para o software como um todo. Com estas pontuações é
possível concluir quanto à adequação ou não deste software para a aplicação
didática.
15
1.2 Objetivos
O objetivo deste trabalho é desenvolver uma metodologia de avaliação da
qualidade de software utilizado como ferramenta de apoio didático em sala de aula.
Faz parte dos objetivos desta metodologia de avaliação contemplar:
• Uma avaliação técnica, executada por técnicos, que pontue o software
e as suas questões técnicas, para análise detalhada de seus pontos
fortes e fracos, favorecendo ou não a sua aprovação;
• Uma avaliação da aplicação em sala de aula, executada pelos alunos,
que pontue o software e as questões da aplicação deste software em
sala de aula, para análise detalhada dos pontos fortes e fracos,
favorecendo ou não a sua aprovação;
• Uma avaliação didática, executada pelo professor ou uma equipe que o
represente, que pontue o software e as questões didáticas deste
software, para análise detalhada dos pontos fortes e fracos,
favorecendo ou não a sua aprovação;
• Uma pontuação final para o software, com base nas três pontuações
anteriores, que aponte o software avaliado como aprovado ou
rejeitado, seja para a continuidade de seu desenvolvimento, aquisição
ou continuidade de uso em sala de aula.
Para a validação desta metodologia de avaliação, o autor apresenta uma
aplicação com a utilização de um software de custos ABC, desenvolvido
especificamente para ser aplicado em cursos desta natureza. Com base na Norma
ISO 9126, o software é avaliado pela equipe de desenvolvimento, pelos alunos e
pelo professor.
1.3 Importância
Uma vez que é crescente a utilização de software como ferramenta de apoio
didático nos mais diversos cursos e áreas de ensino, torna-se essencial avaliá-los de
forma ampla e direcionada às questões de qualidade.
16
Nem todo software aplicado em sala de aula foi desenvolvido para a
finalidade didática. Diferentemente de software utilizado no ensino fundamental, que
normalmente é desenvolvido com finalidade didática, no nível superior o software
aplicado geralmente vem de uma empresa ou é adquirido no comércio. Portanto, é
direcionado a aplicações técnicas, comerciais, empresariais e outras que não as
aplicações didáticas. Este fato faz com que alguns não apresentem, por exemplo,
facilidade no manuseio, simplificação no lançamento das informações, foco no
assunto tratado em sala de aula e recursos específicos dirigidos ao aprendizado.
Vindos de fora do ambiente de ensino, é razoável que eles sejam ricos em
detalhes necessários para a finalidade a que foram desenvolvidos, mas que podem
desviar o foco do assunto abordado em aula. Um software que troque informações
com outro software (integrado) é um exemplo disso: em uma aula sobre fluxo de
caixa, um simples “contas a pagar”, que necessite de lançamentos de dados
contábeis por estar interligado com um sistema de “contabilidade”, interfere no foco
do assunto da aula, pois a visualização de informações sem relação com o que se
está estudando pode desviar a atenção do aluno, gerar dúvidas, causar esforços
desnecessários para se obter a resposta desejada, prejudicar o aprendizado e,
conseqüentemente, o bom andamento da aula.
Assim, a contribuição desejada para este trabalho está em iniciar um largo e
longo caminho a ser percorrido por futuros pesquisadores, no sentido de se criar
uma metodologia de avaliação de software aplicado com finalidade didática em sala
de aula, de forma a se obter:
1. Uma pontuação que determine a adequação ou a inadequação de um
software avaliado diante de questões didáticas;
2. Uma relação do que pode ser melhorado ou modificado em um
software, visando ao seu aprimoramento didático para a próxima
versão, ou, do mesmo modo, o que é necessário para torná-lo
“adequado” em uma avaliação futura (pós-modificações), considerando
as questões de qualidade técnicas do software e de sua aplicação em
17
sala de aula;
3. Uma análise que permita selecionar um software entre vários que
concorram a uma mesma aplicação, através de suas pontuações finais
e, também, pela análise das pontuações obtidas para cada um dos
pontos de vista (equipe de desenvolvimento, alunos e professor);
4. Uma metodologia de avaliação que seja abrangente o suficiente, de
modo a permitir a análise de qualquer software que venha a ser
aplicado em sala de aula, em qualquer área do conhecimento;
5. Uma mudança de visão no planejamento e na produção de software
voltado à aplicação didática, através da conscientização de
professores, alunos e profissionais da área de desenvolvimento de
software, possibilitando um planejamento mais adequado e um
desenvolvimento do produto final com foco em uma futura avaliação
didática, que venham a contribuir com a renovação e o aprimoramento
da qualidade de ensino e, também, com o aprendizado de um modo
geral.
A contribuição deste trabalho está em desenvolver uma metodologia de
avaliação que contemple todos estes aspectos, permitindo, assim, uma avaliação
ampla e direcionada às questões de qualidade.
1.3.1 Software didático
Atualmente software está presente no ambiente escolar das mais variadas
formas, desde a sua utilização para a simples apresentação de uma aula, até o uso
intensivo pelos alunos em salas com computadores. Por outro lado, é comum
observar a presença de equipamentos portáteis trazidos pelos alunos para as salas
de aula nos cursos de nível superior e, não menos comum, a utilização da Internet
para pesquisas e para a confecção de trabalhos completos em grupo, ainda que
estes grupos não tenham se reunido de forma presencial uma única vez.
18
Essas constantes transformações que a escola vem sofrendo são fatos
inegáveis e que apontam para a necessidade de se verificar se a escola está
interagindo, na sua finalidade educacional, de forma eficiente com estas novas
tecnologias. A questão primordial é que o aluno está em contato com o mundo e
também com o mercado de trabalho e, quando se dirige à escola, espera encontrar
os mesmos recursos tecnológicos que encontra fora dela. Neste contexto, estaria a
escola hoje sendo eficaz?
Ainda hoje a escola é entendida como um centro detentor e transmissor de
conhecimentos, cujo principal agente é o professor. No relato de Bianchetti (2001),
“A escola está sendo pressionada a assumir efetivamente a função de desafiar e
subsidiar a construção de conhecimento, pois na condição de apenas transmissora
continuará perdendo espaço e justificação histórico-social”. Com as novas
tecnologias de informação e comunicação, os profissionais e as instituições que
permanecem atuando como simples transmissores de conhecimentos, ou
intermediadores, estão cada vez mais perdendo espaço e valor, e tendem a
desaparecer com o tempo. Bianchetti relaciona esta situação, em particular a do
professor-transmissor, com profissionais que passaram ou estão passando por
necessidade de migração em suas atividades, como por exemplo, os datilógrafos,
caixas de banco e telefonistas. No entanto, quanto a isso, Oliveira (2001) cita que, “a
utilização dessas tecnologias não nos autoriza a pensar que nesse novo contexto a
figura do professor venha a se tornar desnecessária”.
Segundo Hilst (1994), “a educação superior deve colocar-se como alavanca
central do desenvolvimento da sociedade e da economia, equilibrando os desafios
tecnológicos com os compromissos educativos”. E complementa: “poderíamos dizer
que precisamos da tecnologia e a tecnologia de que necessitamos não é nada
utópica, é muito real e está bem próxima de nós”. O uso de software para a
aprendizagem é uma realidade que precisa ser avaliada quanto aos objetivos
educacionais a que se propõe. Hoje, esta aprendizagem não se restringe apenas ao
ambiente escolar. “Existe toda uma tecnologia de ponta que a escola pode utilizar
dentro e fora de seu espaço físico” (MASETTO, 1997).
19
As pesquisas realizadas por Bianchetti (2001), nesse momento de constantes
mudanças, evidenciam questões onde o saber, o ser e o querer mesclam-se
formando o trabalhador ideal para a empresa. O perfil deste trabalhador consiste
num conjunto de atitudes, entre as quais, as mais apreciadas são: sociabilidade,
disponibilidade, capacidade de envolvimento nos problemas e soluções da empresa.
E conclui que:
“as principais críticas e os maiores questionamentos ao sistema
formal de ensino não se voltam apenas aos aspectos cognitivos
relacionados ao desempenho da função especializada do técnico ou
engenheiro. Embora tenham sido feitas referências a defasagens neste
sentido, a tônica das críticas e questionamentos volta-se para a
(in)capacidade dos trabalhadores em assimilar a nova cultura da empresa
no tocante às transformações em processo, especialmente as tecnológicas,
que são mais visíveis.” (BIANCHETTI, 2001)
O grande desafio da escola atual está em alinhar as suas diretrizes, seus
recursos e métodos com a realidade com que o aluno se depara em seu dia-a-dia.
Sem este alinhamento, não há uma conexão do mundo real com o ensino, o que faz
com que este se torne entediante. Segundo Masetto (1997), “ao centrar a
construção do conhecimento somente sobre o livro didático, a escola cria um
ambiente de aprendizagem parado no tempo, fora de contexto e desinteressante”.
A escola vem passando por constantes adaptações, em particular quanto às
questões da preparação do trabalhador para o mercado de trabalho. A explicação
disso está no fato de que até a década de 70 a postura generalizada era a de que
escola e empresa pertenciam a mundos diferentes e não conciliáveis. Assim, o ser
do pensamento estava na escola e o ser da produção na empresa. Entretanto, e de
acordo com novas necessidades empresariais, buscou-se formas de aproximar este
saber acadêmico do mundo da produção. A questão seria identificar o saber tácito
dos trabalhadores de forma a gerar um processo pedagógico. Sobre isso, Bianchetti
(2001) complementa, citando o movimento da dupla afirmação e dupla negação, que
é ao mesmo tempo, negar e manter o velho e negar e incorporar o novo, ou seja:
“aprender a aprender” e “aprender a desaprender”. Nesse contexto, enquadra-se a
adaptação dos trabalhadores a uma nova versão do software, ressaltando o autor
que “na medida em que na informática – base da organização da vida/trabalho hoje
– predomina o interesse pela última versão do software e do hardware, estamos
20
sendo desafiados a conviver com o efêmero”. Portanto, a escola está sendo
desafiada a revisar suas formas de atuação e assumir novas funções. Quanto ao
ensino superior, Bianchetti (2001) ainda comenta que “em relação à universidade,
além da preocupação com a formação para uma determinada profissão, está sendo
requisitada uma preparação para que o egresso assuma, na empresa ou no setor
em que vier a trabalhar, uma postura de empreendedor”. Este fato é comprovado
hoje, pelo recente surgimento e grande crescimento dos cursos de graduação de
curta duração (em torno de dois anos), que são essencialmente voltados à formação
de empreendedores para mercados específicos.
Olhando para o mercado de trabalho atual e as constantes e intensas
mudanças devidas às novas tecnologias, Oliveira (2001) afirma que “este novo
contexto exige do trabalhador características nunca antes pensadas, como as de
raciocínio lógico, responsabilidades para com o processo de produção e iniciativa
para resolução dos problemas emergentes”. A escola não pode e não deve ignorar o
fato de que ao incluir um software como ferramenta de apoio à aprendizagem ela
estará preparando o aluno para o mundo real, aproximando-o desta realidade
através de simulações e recursos outros que facilitem e proporcionem este
aprendizado, de forma objetiva, atual e agradável.
“À luz da Didática moderna, cada professor devidamente habilitado,
partindo de diretrizes metodológicas seguras e atualizadas, pode e deve
organizar seu próprio método, empenhando nisso seu saber, sua
experiência e sua imaginação criadora. O bom professor é aquele que está
na busca constante de um método melhor, mais adequado e eficaz, um
método que enquadre realisticamente os princípios, as sugestões e as
normas flexíveis da moderna técnica de ensino às realidades concretas e
imediatas em que se situa o seu trabalho.” (MATTOS, 1960)
Neste contexto, um software didático deve permitir ao professor uma
flexibilidade tal, de modo que ele possa explorá-lo de diversas formas, realística e
criativamente, segundo seus objetivos.
Masetto (1997) observa que um livro-texto pode ser utilizado como um dos
recursos para a aprendizagem, mas não deve ser esta a única fonte de informações.
Assim como um livro didático, cujo principal objetivo é servir de apoio ao processo
de ensino-aprendizagem, um software didático também deve ser encarado como
21
meio e não como fim.
“É lamentável observar que uma abordagem mecanicista vem
fundamentando a utilização do software educativo pelas instituições de
ensino, ratificando a continuidade da prática docente empirista. Essa
realidade se coloca na contramão das expectativas geradas quanto à
utilização das novas tecnologias no processo de ensino-aprendizagem.”
(OLIVEIRA, 2001)
O que se observa é uma grande distância entre o que a sociedade
tecnológica produz e o que a escola utiliza, apesar de se saber que os inventores
destas novas tecnologias saíram de dentro desta mesma escola. Desta forma, é
imprescindível que a escola reveja sua postura, também quanto aos métodos de
ensino até então adotados, pois de outra maneira corre o risco de negar pelo
desuso, ou mau uso, o que ela mesma ajudou a criar.
“É fato que a formação do engenheiro atualmente está envolvendo
não apenas as habilidades técnicas, mas o desenvolvimento de atitudes,
posicionamentos éticos e outras habilidades, às quais o conhecimento dos
estilos de aprendizagem pode dar grande contribuição, uma vez que o
domínio das técnicas (partes) não garante a formação do engenheiro como
um todo (sistema). Além disso, esta informação pode ser muito útil aos
docentes, no planejamento de atividades alternativas que favoreçam a
aprendizagem ativa (jogos e simulações) e a aprendizagem colaborativa por
meio, por exemplo, do trabalho em equipe, habilidade valorizada pelo
mercado de trabalho. Tal como afirmado por Felder e Silverman (1998),
Keirsey e Bates (1984) e Kolb (1984), a diversificação das atividades dentro
de sala de aula tem o objetivo de atingir os diferentes estilos de
aprendizagem, contribuindo também, para uma formação mais global do
futuro engenheiro.” (FREITAS, DORNELLAS e BELHOT, 2006)
Portanto, ter em mãos uma metodologia que permita avaliar um software de
forma clara e objetiva, como uma ferramenta didática apropriada para o uso no
processo de ensino-aprendizagem, em particular no ensino superior, é de
fundamental importância para os dias de hoje.
1.3.2 Norma ISO 9126
A escolha da Norma ISO 9126 deu-se, principalmente, pelo fato de esta
Norma apontar para vários aspectos da qualidade de software, de forma ampla e
com liberdade para se avaliar com a visão e com o nível de detalhamento
desejados, permitindo, ainda, o aprofundamento desta análise tanto quanto se
22
queira. Segundo Rocha et al. (2001), “Mais recentemente, a norma ISO 9126 surgiu
como uma importante tentativa de consolidar as diferentes visões da qualidade em
um modelo como norma internacional”.
A Norma abrange não somente a questão da qualidade de produto de
software, mas também a qualidade da aplicação, o que a torna essencial para este
trabalho, uma vez que é justamente na aplicação que está o foco principal das
preocupações de professores e alunos em relação à utilização de software em sala
de aula.
Além disso, esta Norma é amplamente utilizada até os dias de hoje. Como
exemplo, ela é parte integrante do desenvolvimento pelo ITI (Instituto Nacional de
Tecnologia da Informação) do “Guia de Avaliação da Qualidade de Produto de
Software” (GUIA ITI, 2001), que tem por finalidade avaliar produtos de software sob
o ponto de vista de um usuário final. Outro exemplo, é que esta Norma foi aplicada
em uma dissertação de mestrado atual, que se destina à avaliação da qualidade de
software educacional (GLADCHEFF, 2001). Neste trabalho, optamos pela utilização
direta da Norma ISO 9126.
A Norma permite realizar a avaliação sob a visão do usuário, que é a visão do
aluno, portanto, fundamental para um software que é aplicado como ferramenta de
apoio ao aprendizado. Por outro lado, a Norma contempla a visão da equipe de
desenvolvimento, que é uma visão técnica voltada ao produto de software, que deve
atender à qualidade esperada de sua aplicação em sala de aula, facilitando e não
comprometendo o aprendizado. E, finalmente, a Norma também permite a avaliação
sob a visão do gerente, que é uma visão estratégica e que, no caso de um software
voltado à aplicação didática, é a visão do professor quanto aos objetivos didáticos da
aplicação.
Oliveira (2001) observa que:
“no caso de o usuário ser o sistema educacional, seria interessante
que o software passasse por comissões avaliadoras, o que viabilizaria a
indicação do produto como adequado, ou não, para ser utilizado na rede
escolar. É importante também que cada escola proceda à avaliação do
software, tendo em vista a apreciação de seus professores, no que se refere
23
à adequabilidade do uso desse instrumento como ferramenta de apoio ao
seu trabalho educacional e considerando o seu próprio projeto pedagógico.
Vale a pena ressaltar que essas comissões devem ser constituídas por
educadores e especialistas capazes de, num esforço multidisciplinar, avaliar
a possibilidade efetiva de contribuição do produto para a prática
pedagógica. É importante destacar ainda que a participação de estudantes
nessas comissões, com o seu olhar de usuário, pode vir a ser um
termômetro da aceitação do software educativo pelo seu público-alvo”.
Uma vez que não é suficiente avaliar um software para aplicação didática por
apenas um destes pontos de vista, e a Norma permite explorar estas questões por
todos estes ângulos diferenciados, decidiu-se aplicá-la como base fundamental para
a definição das avaliações de software neste trabalho. Deste modo, as avaliações
serão realizadas sob o ponto de vista da equipe de desenvolvimento, dos alunos e
do professor.
1.3.3 Custos ABC
Custos ABC é o tema do software apresentado neste trabalho, que apesar de
não ser o foco central desta pesquisa, é um tema atual e de significativa importância
para as empresas. Segundo Martins (2003), “no processo de redução de custos e
despesas o uso do ABC é imbatível”.
Devido ao elevado crescimento dos custos fixos em relação aos custos
variáveis, observados nas últimas décadas, principalmente pelo emprego de novas
tecnologias e, também, pelo aumento da complexidade dos processos produtivos
originados em parte por uma demanda maior de produtos diferenciados, fez-se
necessário desenvolver um novo sistema de custeio que melhor apropriasse os
custos fixos aos objetos de custeio. Neste sentido, na década de 80 surgiu o ABC, e
permanece até hoje como uma metodologia eficaz na apropriação dos custos
indiretos (custos fixos), levando-se em conta as atividades e as complexidades dos
processos que antes eram ignoradas, sendo portanto, um método mais acurado e
apropriado para a maioria dos casos encontrados nas empresas ainda hoje.
O método de custeio baseado em atividades, ou ABC tem sido cada vez mais
utilizado e, por isso, tem-se feito necessário que os cursos de engenharia de
24
produção transmitam não só os conceitos básicos, mas também a forma correta da
aplicação desta metodologia.
Da mesma forma, tem-se enfocado cada vez mais a gestão em custos ou
ABM (Activity-Based Management). O método de custeio ABC objetiva o cálculo dos
custos propriamente ditos, enquanto o ABM analisa e destaca os valores parciais e
totais apontados pelo ABC, de modo a auxiliarem nas questões gerenciais, sejam de
controle ou para a tomada de decisões. Como exemplo, temos o cálculo de
indicadores do trabalho indireto (administração, serviços, manutenção, controle de
qualidade, entre outros); o que não é comum ser realizado nas empresas, onde os
indicadores se concentram nas questões produtivas e financeiras.
Uma aplicação é apresentada neste trabalho, com base em um software de
custos ABC, desenvolvido e aplicado pelo autor como ferramenta de apoio didático a
cursos desta mesma natureza, em particular para o ensino superior.
1.4 Esclarecimentos
A metodologia de pesquisa é feita com base nos apontamentos de
importantes autores sobre cada tema: Didática, Qualidade de Software, Norma ISO
9126 e Custos ABC (tema da aplicação utilizada nesse trabalho). A partir desse
levantamento é delineada a definição da metodologia de avaliação.
Os autores da área educacional, em geral, denominam um software
desenvolvido e utilizado para aplicação didática como "software educativo". Este
termo é largamente utilizado quando citam um software aplicado no ensino
fundamental. Isto se dá, pois, nesse nível de ensino, um software normalmente é
dirigido ao aprendizado do aluno como em um livro-texto, ou seja, com início, meio e
fim bem determinados, apresentando pouca ou nenhuma flexibilidade quanto à sua
manipulação e a simulações dentro do assunto abordado. Também, são foco de
interesse as questões específicas, como cores, sons, efeitos e o roteiro, por
exemplo.
25
Nesta pesquisa, utiliza-se amplamente o termo “software didático” – que é um
software educativo – para destacá-lo de um software que seja dirigido com pouca
flexibilidade em sua aplicação, como em casos extremos, nos quais até o professor
não necessite estar presente. A finalidade deste trabalho é avaliar o software como
ferramenta de apoio didático, ou seja, a interação: professor – tema/software –
alunos. Um exemplo está em cursos de nível superior, para os quais um software
deve ter flexibilidade de uso e possibilitar simulações. As questões específicas não
necessariamente são foco deste tipo de software, porém, podem estar presentes.
No decorrer deste trabalho, o termo “professor” é amplamente citado; no
entanto, o autor assim o fez para não citar repetidas vezes esta frase: professor, um
especialista ou sua instituição de ensino. A figura do professor não é
necessariamente a de um único professor, ela é generalizada por poder indicar uma
equipe formada pela instituição de ensino, como por exemplo, a participação direta
ou indireta de vários professores, técnicos, especialistas ou empresas certificadoras.
Este trabalho desenvolve uma metodologia de avaliação de software aplicado
em sala de aula, que seja abrangente e adaptável a aplicações específicas. Um
exemplo de aplicação específica seria a utilização de um software para compor
partituras e executá-las, onde as questões de qualidade dos recursos multimídia são
fundamentais. De outro modo, o mesmo ocorre para situações onde cores, alta
definição, recursos 3D (efeitos tridimensionais), interação eletrônica ou automatizada
são essenciais. Sobre avaliações específicas de software educativo existem vários
estudos, como é o caso da dissertação de Gladcheff (2001) e do livro de Rocha et
al. (2001), entre outros. O “Guia de Avaliação da Qualidade de Produto de Software”
(GUIA ITI, 2001) é bem específico e utiliza-se também da Norma ISO 9126, e reforça
a questão da flexibilidade quando da avaliação pela Norma, quando cita que
“Algumas questões podem ser modificadas, outras eliminadas e/ou novas questões
podem ser acrescentadas de acordo com a especificação do produto de software a
ser avaliado”.
A metodologia aqui apresentada permite que a avaliação seja tão específica
quanto se queira, portanto, dependendo dos objetivos e das necessidades da
avaliação. Em geral, nestas avaliações mais específicas há uma grande
26
preocupação com vários itens que têm importâncias diferentes, conforme a
aplicação destino, como é o caso já citado da apresentação de cores e sons,
recursos gráficos e de imagem, entre outros. Assim, cabe a quem irá aplicar esta
metodologia definir quão específica deva ser a sua avaliação, no todo ou em alguns
itens em particular.
1.5 Estruturação
O presente capítulo traz uma introdução sobre o tema, os objetivos deste
trabalho, a importância do tema escolhido e algumas considerações sobre a
metodologia de avaliação.
O segundo capítulo apresenta os conceitos da área educacional necessários
para se definir um software como didático, e permitir, ao mesmo tempo, obter
subsídios para a concretização de uma metodologia que venha a avaliá-lo a
contento diante de uma aplicação com finalidade didática.
O terceiro capítulo apresenta as questões sobre qualidade de software,
consideradas para o desenvolvimento desta mesma metodologia de avaliação, com
base na Norma ISO 9126.
O quarto capítulo apresenta a metodologia estruturada para a avaliação da
qualidade de software aplicado em sala de aula, em três avaliações distintas
conforme os três pontos de vista citados na Norma: equipe de desenvolvimento,
usuários e gerente, que nesta metodologia são representados respectivamente pela
equipe de desenvolvimento, alunos e professor.
O quinto capítulo apresenta uma aplicação da metodologia de avaliação para
um software utilizado como ferramenta de apoio didático em um curso de custos
ABC. São apresentados os conceitos de custos ABC, incluindo ABM, o modelo de
custos proposto pelo autor, uma breve descrição sobre o software didático avaliado
e, a apresentação e discussão dos resultados desta aplicação.
27
Finalmente, o sexto capítulo apresenta as conclusões, com um breve histórico
sobre o desenvolvimento deste trabalho e sugestões para trabalhos futuros.
Figura 1 Áreas de estudo de um software para aplicação didática
A estrutura básica deste trabalho está representada na Figura 1, onde se
observa que a intersecção das três linhas de pesquisa – didática, Norma ISO 9126 e
tema do software – formam o foco desta dissertação. A intersecção entre as linhas
de pesquisa representa a sustentação de uma área na fundamentação do que é
apresentado na outra.
A questão didática auxilia na compreensão do assunto e no apoio à
metodologia quanto a se avaliar um software para aplicação didática. A questão da
qualidade de software permite a avaliação da qualidade, fundamentada na Norma
ISO 9126, diante dos três pontos de vista (equipe de desenvolvimento, alunos e
professor). E, finalmente, a questão do tema do software, que é o assunto específico
da aplicação à qual o software se destina, e que será avaliado quanto à sua
adequação.
Neste trabalho o tema do software avaliado é “custos ABC”. A Figura 2
representa as áreas de pesquisa, considerando-se a aplicação da metodologia de
avaliação descrita no capítulo quinto.
Didática
No
rma
ISO 9126
Tema do
Software
28
Figura 2 Áreas de estudo da dissertação
Didática
Norma
ISO 9126
Custos
ABC
29
2 SOFTWARE DIDÁTICO
Neste capítulo são apresentados os conceitos da área educacional que
contribuem para a elaboração de uma metodologia para a avaliação da aplicação de
um software como ferramenta de apoio didático em sala de aula. Para tanto, reuniu-
se uma série de contribuições de autores que discutem conceitos e idéias
fundamentais do processo educativo. Sem estas contribuições, o termo “software
didático” permaneceria muito abrangente; ao mesmo tempo, poderia ser mantido o
mito de que qualquer software aplicado em sala de aula seja por si só didático.
O autor esclarece que preferiu utilizar o termo “software didático” como
ferramenta de apoio e não de ensino, ao invés de “software educativo”. Nesta
segunda categoria estão incluídos os instrumentos tecnológicos autodidáticos nos
quais se dispensa, muitas vezes, inclusive a presença do professor, e que são
comumente utilizados no nível fundamental. O foco deste trabalho está na avaliação
da interação: professor – tema/software – alunos, o que foge ou é pouco explorado
neste tipo de software. No entanto, é importante ressaltar que um software didático
não deixa de ser um software educativo, por estar inserido em contextos de ensino-
aprendizagem.
A partir das considerações deste capítulo é desenvolvida parte da
metodologia de avaliação para este trabalho.
2.1 Software educativo
Segundo Oliveira (2001):
“o que caracteriza um software como educacional é a sua inserção
em contextos de ensino-aprendizagem. Assim, nessa perspectiva, um
determinado programa de computador pode ser considerado um produto
educacional se adequadamente utilizado pela escola, mesmo que não tenha
sido produzido com a finalidade de uso do sistema escolar”.
O autor adaptou e reuniu vários apontamentos de Oliveira (2001) em uma
única tabela (Tabela 1). O motivo disso está em apresentar algumas questões
30
básicas sobre software educativo, sua diferenciação em relação a software
aplicativo, sua evolução na utilização em educação e as suas características para o
seu planejamento, desenvolvimento e avaliação.
Tabela 1 Apontamentos de Oliveira (2001) sobre software educativo
Item Apontamentos
Software Educativo ou
Programa Educativo
(CourseWare)
Finalidade Didática
1º
Software
Educacional
Software Aplicativo
Finalidade Empresarial
(mesmo aplicado no contexto didático,
não é um software educativo)
Ênfase na lógica e no
conteúdo: treino em
respostas consideradas
corretas
O primeiro tipo de software educativo
desenvolvido para se aplicar em
educação foi o CAI – Computer Assisted
Instruction (Instrução Assistida por
Computador) – na década de 1960
Capacidade de
acumulação/utilização
de novas
informações:
interação progressiva
com o usuário
A partir da década de 1970, os
chamados “sistemas inteligentes”
(pesquisas em inteligência artificial)
começaram a ser incorporados pela área
educacional, mas até hoje não atingiram
o sucesso esperado
2º
Evolução do
Software Educativo
Interação com o
usuário: perspectiva
construtivista de
simulações, desafios e
jogos educativos
Permite um melhor aproveitamento
pedagógico. São exemplos o tutorial, a
simulação e os jogos educacionais
3º
Parâmetros a serem
considerados para a
definição dos
critérios de
produção e
avaliação de um
software educativo
Conteúdo
Fundamentação
Interação aluno,
software educativo, Programação
professor
Definição e presença de uma fundamentação pedagógica que
permeie todo o seu desenvolvimento
Finalidade didática, por levar o aluno/usuário a “construir”
conhecimento relacionado com seu currículo escolar
Interação entre aluno/usuário e programa, mediada pelo professor
Facilidade de uso, uma vez que não se deve exigir do aluno
conhecimentos computacionais prévios, mas permitir que qualquer
usuário, mesmo que em um primeiro contato com a máquina, seja
capaz de desenvolver suas atividades
4º
Características de
um Software
Educativo
Atualização quanto ao estado da arte
Fonte: Adaptado de Oliveira (2001)
31
Comentários sobre os itens da Tabela 1:
1º. Software educacional – Um software aplicado em sala de aula
servindo de apoio ao processo de ensino-aprendizagem, não é
necessariamente um software educativo. Software educativo é
aquele que foi desenvolvido para que o aluno construa
determinados conhecimentos sobre a matéria de ensino, ou seja,
com objetivos didáticos. Um software aplicativo pode ser um
software educacional, desde que utilizado em sala de aula com
finalidade didática, mas não é um software educativo, uma vez que
não foi desenvolvido para esse fim. Por exemplo, planilhas
eletrônicas e bancos de dados. Portanto, o software aplicativo não
se enquadra no contexto de software educativo, ainda que possa
ser utilizado em procedimentos didáticos, o que o descaracteriza
para a finalidade de análise e avaliação deste trabalho.
2º. Evolução do software educativo – Atualmente, o software
educativo que é mais utilizado e eficiente para a educação, é o do
tipo de interação com o usuário (tutoriais, simulações e jogos
educativos). Os tutoriais possibilitam o acesso do usuário ao
conteúdo didático e propõem questões às quais ele deve reagir ou
responder. A grande limitação é a interação restritiva com o usuário
pela análise de respostas a questões abertas ou a questões fora
dos limites do que foi programado. A simulação não é novidade na
educação, utilizada principalmente para a compreensão dos
fenômenos e a comprovação de leis (física e biologia, por exemplo);
ela permite ao professor promover ambientes de intensa
interatividade, motivação e produtividade, ao mesmo tempo em que
avalia o processo de ensino-aprendizagem (momento mais rico
para intervenções pedagógicas). Os jogos educacionais, por sua
vez, que têm na sua essência a aprendizagem com prazer e a
criatividade com diversão, objetivam a intensa interatividade com o
usuário, de modo a cativar o interesse dos alunos em temas muitas
vezes difíceis de se abordar pelos recursos tradicionais.
32
3º. Parâmetros a serem considerados para a definição dos
critérios de produção e avaliação de um software educativo –
No diagrama apresentado nesse item, a fundamentação
pedagógica é o alicerce principal de um software educativo, que
tem como objetivos: especificar o conteúdo a ser contemplado,
definir os requisitos para a programação e atingir a finalidade
didática de disponibilizar satisfatoriamente a interação aluno –
software educativo – professor. Assim, com a devida mediação
do professor, esse software deve ser capaz de ampliar a interação
entre o aluno e o conteúdo.
4º. Características de um software educativo – Estas características
permeiam o estudo desse trabalho, que se destina a software
educativo aplicado em sala de aula como ferramenta de apoio ao
ensino em sala de aula.
2.2 Didática
O que realmente deve ser entendido quando se diz que um software é
didático? Para responder a esta questão, é importante compreender o que a didática
representa. O termo “didática” é amplamente discutido na literatura contemporânea,
conforme as citações a seguir.
Segundo Nérici (1993):
“didática é o estudo do conjunto de recursos técnicos que tem em
mira dirigir a aprendizagem do educando, tendo em vista levá-lo a atingir um
estado de maturidade que lhe permita encontrar-se com a realidade, de
maneira consciente, eficiente e responsável”.
Define, assim, didática como o estudo dos procedimentos destinados a
orientar a aprendizagem do educando de maneira eficiente.
33
Já para a educadora Candau (2005), a didática pode ser entendida como
“reflexão sistemática e busca de alternativas para os problemas da prática
pedagógica”, ou seja, deve ser flexível e aberta a modificações constantes dadas as
necessidades e condições apresentadas na relação de ensino-aprendizagem. Neste
sentido, um software pode facilitar a apreensão de conceitos e estruturas
complexas, ajudando o docente a concretizar idéias e fenômenos abstratos. Pode,
por exemplo, apresentar simulações da realidade que seriam impraticáveis num
ambiente tradicional de aula, como os efeitos resultantes no clima de diversas
regiões do planeta conforme a variação das condições de temperatura, umidade
relativa do ar e velocidade dos ventos; ou ainda, a simulação dos efeitos no espaço
da aplicação da teoria da relatividade de Einstein.
Etimologicamente, a palavra didática vem do grego didaktiké, e quer dizer a
arte de ensinar. Com o tempo, o significado deixou de ter a conotação de arte, o que
lhe dava uma característica muito subjetiva, dependente, sobretudo, do estilo e da
forma de cada professor conduzir o processo educativo. Evoluiu, assim, à categoria
de ciência, e pesquisas começaram a ser desenvolvidas com a preocupação de
buscar melhores formas de ensinar.
O autor adaptou e reuniu vários apontamentos de Mattos (1960) em uma
única tabela (Tabela 2), com a intenção de apresentar algumas questões básicas de
didática que podem ser relacionadas diretamente com o desenvolvimento de
software para a finalidade de uma aplicação didática.
34
Tabela 2 Apontamentos de Mattos (1960) sobre didática
Item Apontamentos
Didática Tradicional Didática Moderna Resposta
A quem se ensina? Quem aprende? Aluno
Quem ensina? Com quem o aluno aprende?
Mestre
Para que se ensina? Para que o aluno aprende? Objetivo
O que se ensina? O que o aluno aprende? Matéria
1º
Comparação
entre Didática
Tradicional e
Moderna
Como se ensina? Como o aluno aprende? Método
Como planejar a marcha dos trabalhos, tornando-os mais rendosos?
Como incentivar e motivar os alunos a estudarem com afinco e a aprende-
rem eficazmente, modificando sua atitude e aperfeiçoando sua conduta?
Como orientar com segurança os alunos na marcha da aprendizagem,
garantindo-lhes a compreensão e a assimilação, aplainando-lhes as
dificuldades e abrindo-lhes novas perspectivas culturais?
Como organizar um plano eficaz de trabalhos práticos e aplicá-lo com
segurança e proveito?
2º
Alguns dos
Problemas
Fundamentais
da Didática
Como garantir a integração e fixação ou consolidação dos produtos da
aprendizagem?
Sincretismo inicial – noções vagas, confusas e errôneas
Focalização analítica –
cada parte do todo é examinada, identificada nos
seus pormenores e nas suas particularidades
Síntese integradora – os pormenores são deixados em segundo plano,
firmam-se as perspectivas da essencialidade, do relacionamento e da
importância dos princípios, dados e fatos já analisados, integrando-os
num todo coerente e virtualmente significativo
3º
Quatro Etapas
para o
Aprendizado
Consolidação ou fixação – por meio de exercícios e repasses
interativos, o que foi aprendido analítica e sinteticamente é ex professo
reforçado ou fixado, de modo a tornar-se uma aquisição definitiva na
mente do aluno
Do mais fácil para o mais difícil
Do mais simples para o mais complexo
Do mais próximo e imediato para o mais remoto e mediato
4º
Condução da
Aprendizagem
dos Alunos
Do concreto para o abstrato
Análise (que vai do todo para suas partes componentes)
Síntese (que vai das partes para o todo)
Indução (que vai do singular ou particular para o universal)
5º
Método Lógico
Dedução (que vai do universal para o particular ou singular)
Recursos: são os meios materiais de que dispomos para conduzir a
aprendizagem dos alunos; por exemplo: material escolar
Técnicas: são maneiras racionais (comprovadas experimentalmente
como sendo eficazes) de conduzir uma ou mais fases da aprendizagem;
por exemplo: a técnica da motivação e a técnica dos meios audiovisuais
6º
Elementos do
Método
Didático
Procedimentos: são segmentos ou seqüências de atividade docente em
determinada fase do ensino, por exemplo, o procedimento da demons-
tração e o procedimento de organização e aplicação de testes objetivos
Fonte: Adaptado de Mattos (1960)
35
Comentários sobre os itens da Tabela 2:
1º. Comparação entre Didática Tradicional e Moderna – Na Didática
Tradicional o foco é o ensino; portanto, cada assunto é transmitido
com a preocupação básica de se ensinar bem, de forma dirigida, e
sem a preocupação de vincular a realidade do dia-a-dia do aluno ao
aprendizado. Essa forma de ensinar não é mais adequada nos dias
de hoje, onde o aluno naturalmente traz o seu dia-a-dia para a sala
de aula, e espera adquirir conhecimentos práticos para utilização,
imediata ou futura, no meio profissional onde atua. Na Didática
Moderna o foco é o aluno; portanto, é clara a preocupação de se
trazer a realidade do aluno para a sala de aula, permitindo, assim,
um aprendizado coerente e mais proveitoso. Quanto ao
planejamento de um software didático, é essencial fazê-lo na ótica
da Didática Moderna.
2º. Alguns dos Problemas Fundamentais da Didática – Olhando
para cada apontamento desse item, observa-se que a introdução de
um software como ferramenta de apoio nesse processo pode
auxiliar satisfatoriamente a responder cada uma dessas questões.
Por exemplo, um software didático, aplicado para os alunos
resolverem alguns exercícios em sala de aula, poderá ser um
desafio motivador para todos, pois eles procurarão chegar aos
resultados através do que aprenderam em sala de aula, cativar a
atenção pelo uso e ampliar o interesse, por apresentar recursos
para análises mais complexas e visualizações gráficas muito
próximas à realidade (muitas vezes impraticáveis sem o apoio de
um software). Tais possibilidades permitem ao professor explorar e
aprofundar mais o assunto através de simulações, com posterior
verificação de seus impactos nos resultados.
3º. Quatro Etapas para o Aprendizado – Um software didático pode
contribuir em muito com as etapas de aprendizagem, uma vez que
pode ser utilizado parcial e gradativamente, até que seja utilizado
36
de forma plena para a consolidação do assunto. Um software
didático é essencialmente parte integrante da quarta etapa de
aprendizagem, a de “consolidação”, uma vez que a sua função
primordial não é a de ensinar, mas a de servir de ferramenta de
apoio a exercícios, a esclarecimentos gerais e principalmente à
fixação do assunto.
4º. Condução da Aprendizagem dos Alunos – Essa dinâmica é
facilmente observada em software de um modo geral, pois que as
condições de simulação da realidade, dos recursos audiovisuais e
de tempo de execução que lhe são natos, ampliam, em muito, as
possibilidades de testes, verificações e análises; que, em alguns
casos, seriam impraticáveis em uma aula sem o uso deles.
5º. Método Lógico – Um software, que por si só é essencialmente um
produto da lógica (estruturado e construído de forma a responder a
programações internas, a seqüências, a comandos e a funções pré-
programadas), evidentemente, pode ser indicado como ferramenta
para apresentação de qualquer método lógico.
6º. Elementos do Método Didático – Conforme os objetivos visados
em cada caso e a natureza específica da matéria de ensino, o
método dará maior ou menor ênfase a um destes três elementos
básicos (recursos, técnicas e procedimentos); nunca, porém,
excluirá totalmente qualquer um deles. Na composição de todo o
método didático eles estarão em proporção variável,
desempenhando funções bem definidas no processamento da
aprendizagem. Um software didático é um recurso utilizado com
técnicas de ensino, dentro de procedimentos pré-estabelecidos
para a aprendizagem. Assim, de acordo com esses três elementos,
um software didático se enquadra como um método didático.
Um software didático, que tem por finalidade ser um instrumental educativo,
tanto em relação ao seu conteúdo (matéria), quanto à sua forma (método), busca
37
atender a esta questão: como o aluno aprende? Na evolução das teorias
educacionais, da tradicional à moderna, encontra-se a Escola Tecnológica, cuja
preocupação está centrada na organização racional dos meios de ensino em função
da eficiência do produto. Neste contexto, tanto professor como alunos encontram-se
na posição de executores de tarefas. É nesta corrente de idéias que surge a figura
do programador, que é o organizador das estratégias de ensino com base
tecnológica. Deste modo, um software didático se aproxima da teoria da Escola
Tecnológica, já que é essencialmente uma ferramenta para a “execução de tarefas”,
pré-definidas por meio de programação e projetado de forma a possibilitar a devida
análise dos resultados esperados.
2.3 Ensino-aprendizagem
Diferentes modos de ensinar devem ser adequados a diferentes modos de
aprender, uma vez que o ser humano não absorve e nem processa informações de
forma padronizada. Cada indivíduo assimila e processa informações de uma
maneira única e peculiar; sendo assim, diferentes modos de ensinar devem ser
adequados a diferentes modos de aprender.
Nesta lógica, a didática não se restringe a proposições teóricas, já que, como
afirma Masetto (1997):
“...ela aplica os conhecimentos que produz para resolver problemas
e questões que surgem no dia-a-dia da escola e do espaço de aula. As
teorias se apresentam válidas enquanto solucionam problemas da prática
pedagógica. Caso contrário, a própria realidade questiona a teoria exigindo
novos aprofundamentos, pesquisas e estudos”.
Portanto, teoria e prática devem ser consideradas de forma que se atinja o
objetivo final que é a aprendizagem. Um software pode apresentar uma flexibilidade
tal que permita algumas alternativas em seu uso, de forma que, não se adequando
os alunos ao primeiro formato apresentado, outras opções de exposição de
conteúdo podem ser utilizadas de acordo com o perfil e as necessidades dos
participantes. Um exemplo seria a utilização de gráficos como representação visual
dos resultados, contrapondo a apresentação destes valores em tabelas. A presença
38
do professor no momento da utilização do software fará a mediação necessária para
atingir a aprendizagem pretendida entre todos os alunos.
2.4 Processo de ensino e processo didático
Uma questão pertinente à didática é como preparar bem uma aula, fazendo
com que os alunos se interessem pela matéria, motivando-os a estudarem,
despertando e mantendo suas atenções, com o objetivo de que aprendam. Assim,
um software didático deve se enquadrar como uma ferramenta que possa promover
o interesse geral, despertar, manter a atenção, motivar e facilitar o aprendizado,
servindo de forma eficaz aos objetivos da aula.
Segundo Mattos (1960):
“temos, portanto, na Didática, dois binômios fundamentais a
considerar: primeiro o binômio humano ou personalógico, constituído pela
personalidade do mestre e a de seus alunos em ativa e fecunda integração;
segundo, o binômio cultural, constituído pela matéria e pelo método, a
serviço dos agentes do binômio personalógico, em vista dos objetivos a
serem por eles atingidos. Será sempre uma grave deturpação da
perspectiva didática atribuir importância ou ênfase exagerada à matéria ou
ao método como se fossem os dados únicos ou decisivos da situação; na
realidade, os componentes do binômio cultural (matéria e método)
desempenham no plano educativo a função necessária mas auxiliar de
instrumentalidades educativas”.
Quanto a software didático, que tem por finalidade ser um instrumental
educativo, ele não pode abster-se de estar profundamente envolvido com a matéria
e o método a que se propõe. Instrumento do binômio humano, essencialmente um
software didático é parte do binômio cultural, participando diretamente no alcance
dos objetivos didáticos, referências essas encontradas no esquema didático de
Mattos (Figura 3).
39
Figura 3 Esquema didático (Adaptado de Mattos, 1960)
Libâneo (2004) comenta que:
“o processo de ensino é impulsionado por fatores ou condições
específicas já existentes ou que cabe ao professor criar, a fim de atingir os
objetivos escolares, isto é, o domínio pelos alunos de conhecimentos,
habilidades e hábitos e o desenvolvimento de suas capacidades cognitivas.
O professor planeja, dirige, organiza, controla e avalia o ensino com
endereço certo: a aprendizagem ativa do aluno, a relação cognitiva entre o
aluno e a matéria de estudo”.
Figura 4 Componentes do processo didático e do processo de ensino (LIBÂNEO, 2004)
OBJETIVOS
ALUNOS
MESTRE
MATÉRIA
MÉTODO
Binômio
Humano
Binômio
Cultural
condições específicas de
aprendizagem
objetivos e conteúdos
do sistema escolar
objetivos
conteúdos
condições
métodos e
organização
ensino
aprendizagem
domínio de conhecimentos,
habilidades, hábitos e
desenvolvimento das capacidades
inserção e atuação nas diversas
esferas da vida social (prática social)
condições específicas de
ensino
40
Os componentes do processo didático e do processo de ensino encontram-se
na Figura 4.
Continuando, Libâneo (2004), cita que:
“técnicas, recursos ou meios de ensino são complementos da
metodologia, colocados à disposição do professor para o enriquecimento do
processo de ensino. Atualmente, a expressão ‘tecnologia educacional’
adquiriu um sentido bem mais amplo, englobando técnicas de ensino
diversificadas, desde os recursos da informática, dos meios de
comunicação e os audiovisuais até os de instrução programada e de estudo
individual e em grupos”.
O emprego de software didático não deve se resumir simplesmente à sua
aplicação direta, mas, sim, a uma ampla preocupação com a finalidade e a eficiência
de sua utilização como complemento ao ensino, ou seja, como ferramenta de
estímulo e de facilitação do aprendizado.
2.5 Comunicação, linguagem, método e material didático
Segundo Nérici (1993):
“a linguagem didática se inclui no capítulo da comunicação que,
neste caso, poderia denominar-se comunicação didática. Comunicação,
etimologicamente, significa tornar comum. De fato, quando algo é
comunicado de uma pessoa para outra, esse algo torna-se comum às duas
pessoas”.
Quanto ao processo de comunicação, Nérici destaca que os quatro elementos
fundamentais no caso do ensino são:
• Transmissor (professor ou aparelhagem);
• Receptor (educando);
• Mensagem (conteúdo);
• Meio (som, escrita, desenho, gráfico, gesto, expressão fisionômica
ou outro recurso qualquer simbolizando algo).
Um software didático é um meio de comunicação e, como tal, faz parte da
linguagem didática. Com os recursos audiovisuais próprios do conjunto software e
41
hardware, é por intermédio do software didático que o conteúdo da matéria de
ensino é transmitido aos alunos, contribuindo, assim, para o efetivo sucesso da
comunicação professor-educando. Segundo Mattos (1960), “Método”
(etimologicamente “metá-hodós”: caminho para atingir a meta) é o contrário da ação
casual, dispersiva e desordenada.”, envolvendo as seguintes questões
fundamentais:
• Qual o objetivo ou resultado a ser atingido?
• Qual a matéria que iremos utilizar?
• Quais os meios ou recursos materiais que poderemos utilizar?
• Quais os procedimentos mais adequados que, dentro das
circunstâncias, poderemos aplicar?
• Qual a ordem ou seqüência mais racional e eficiente na qual
deveremos escalonar os recursos e procedimentos para atingir o
objetivo com segurança, economia e alto rendimento?
• Qual o tempo de que dispomos e qual o ritmo que devemos imprimir
aos nossos trabalhos para atingirmos os objetivos previstos dentro do
tempo desejado?
Estas questões devem ser dirigidas a qualquer software a ser desenvolvido
que tenha finalidade didática e, também, consideradas diante de um software em
desenvolvimento quanto à sua adequação. Assim, podemos concluir que um
software didático faz parte de um método, podendo ser aplicado dentro de uma
metodologia de ensino.
Os elementos básicos do método didático de Mattos (1960) são:
• A linguagem didática – que é o meio necessário de comunicação,
esclarecimento e orientação de que se utiliza o professor para dirigir os
alunos na sua aprendizagem;
• Os meios auxiliares e o material didático – que são o instrumental de
trabalho que o professor e os alunos precisam utilizar para ilustrar,
demonstrar, concretizar, aplicar e registrar os fatos estudados;
42
• A ação didática – que é a ativação do estudo pelos trabalhos, exer-
cícios, debates, demonstrações e outras atividades realizadas em aula.
Software didático, uma vez aplicado em aula, faz parte da linguagem didática
como meio de comunicação, esclarecimento e orientação para a aprendizagem; é
um meio auxiliar e também parte integrante do material didático como instrumental
de trabalho; e uma ferramenta para a ação didática, pois motiva a participação dos
alunos através dos exercícios que possibilita realizar. Desta forma, por estar incluído
nos três elementos básicos, um software didático faz parte do método didático.
O método lógico é estabelecido nas leis do pensamento e raciocínio para
descobrir a verdade ou confirmá-la mediante conclusões certas e verdadeiras; por
ser próprio das inteligências como as dos cientistas, pesquisadores, filósofos e
pensadores; é regido por procedimentos rigorosos. A despeito das diferenças, os
métodos didático e lógico são complementares, tendo em vista que o método
didático prepara os alunos para se utilizarem, progressivamente, dos procedimentos
do método lógico, desde o nível básico de aprendizagem, até mesmo ao superior. A
representação abaixo é uma adaptação dessa idéia de Mattos (1960) pelo autor
(Figura 5):
Figura 5 Método lógico e método didático (adaptado de Mattos, 1960)
O material didático é, no ensino, a ligação entre a palavra e a realidade. O
ideal seria que toda aprendizagem se efetuasse em situação real de vida. Não
sendo isso possível, o material didático tem por fim substituir a realidade,
representando-a da melhor forma possível, de maneira a facilitar a sua intuição por
parte do aluno. Neste caso, um software didático passa a ter também a função de
Educação Infantil Ensino Fundamental Ensino Médio Ensino Superior
100%
75%
50%
25%
0%
MÉTODO LÓGICO
MÉTODO DIDÁTICO
43
material didático.
Com a evolução contínua de hardware e de software, as velocidades e os
recursos de processamento e armazenamento aumentam e a manipulação e
apresentação de recursos audiovisuais são ampliadas e mais sofisticadas. Desse
modo, a princípio, não há restrições da aplicação de um software didático como
parte integrante do material didático.
Nérici (1993) evidencia que
“não é a quantidade de material didático nem a sua sofisticação que
devem interessar, e sim o seu uso adequado, de forma provocante,
desafiante, com o fio mor de desencadear o funcionamento dos processos
mentais, notadamente o da reflexão do educando”.
O autor adaptou e reuniu vários apontamentos de Nérici (1993) em uma única
tabela (Tabela 3). O motivo disso está em apresentar algumas questões sobre
material didático que podem orientar o planejamento e desenvolvimento de software
como ferramenta de apoio didático.
44
Tabela 3 Apontamentos de Nérici (1993) sobre material didático
Item Apontamentos
Ser adequado ao assunto da aula.
Ser de fácil apreensão e manejo.
1º
Material Didático
como auxiliar
eficiente do
ensino
Estar em perfeito estado de funcionamento, em se tratando,
principalmente, de aparelhos, pois nada mais diverte e dispersa a
turma do que os “enguiços” nas demonstrações.
Aprimorar o educando na realidade que se queira ensinar, dando
noção mais exata dos fenômenos ou fatos em estudo.
Motivar os trabalhos escolares.
Facilitar a percepção e compreensão dos fatos e conceitos em estudo.
Concretizar e ilustrar o que esteja sendo exposto verbalmente.
Economizar esforços para a compreensão de fatos e conceitos.
Auxiliar a fixação da aprendizagem pela impressão mais viva e
sugestiva, através do material didático.
Dar oportunidade de manifestação de aptidões e de desenvolvimento
de habilidades específicas com o manuseio de aparelhagem e
elaboração de materiais outros de ensino por parte do educando.
Despertar e prender a atenção.
Auxiliar a formação da imagem e a sua retenção.
Favorecer o ensino baseado na observação e experimentação.
Facilitar a apreensão sugestiva e ativa de um tema ou de um fato em
estudo.
Ajudar a formar imagens corretas, uma vez que cada um pode
perceber a informação oral ou escrita segundo a sua capacidade de
discriminação, discernimento e suas experiências anteriores.
Ajudar a melhor compreender as relações das partes, o todo de um
tema, objeto ou fenômeno.
Auxiliar a formar conceitos exatos, principalmente com referência a
temas de difícil observação direta.
Tornar o ensino mais ativo e concreto, bem como mais próximo da
realidade.
Dar oportunidade de melhor análise e interpretação do tema em
estudo, visando a um fortalecimento do espírito crítico.
Reduzir o nível de abstração, para apreensão de uma mensagem.
Facilitar a comunicação da escola com a comunidade e melhor
conhecimento da sua realidade.
Dar sentido mais objetivo e realístico do meio que envolve o educando
e a escola, no qual o educando terá de atuar.
2º
Objetivos
aparentes do
Material Didático
Favorecer a aprendizagem e a sua retenção.
45
Item Apontamentos
Aprendizagem e
retenção que
proporcionam
Por meio do paladar – 1%
Por meio do tato – 1,5%
Por meio do olfato – 3,5%
Por meio da audição – 11%
Por meio da visão – 83%
Retenção
Se aprende lendo – 10%
Se aprende escutando – 20%
Se aprende vendo – 30%
Se aprende vendo e ouvindo – 50%
Se aprende ouvindo, e a seguir, discutindo – 70%
Se aprende ouvindo, e a seguir, realizando – 90%
Procedimentos de
ensino (retenção
após 3 horas)
Oral – 70%
Visual – 72%
Audiovisual – 82%
3º
Material Didático
e o
favorecimento da
aprendizagem e
de sua retenção
Procedimentos de
ensino (retenção
após 3 dias)
Oral – 10%
Visual – 20%
Audiovisual – 65%
Fonte: Adaptado de Nérici (1993)
Comentários sobre os itens da Tabela 3:
1º. Material Didático como auxiliar eficiente do ensino – Em cada
um dos três apontamentos, pode-se verificar a sua relação direta
com software, que essencialmente deve ser adequado ao assunto
para o qual foi desenvolvido, de fácil operação e manuseio, além de
não apresentar falhas durante as suas aplicações. Dessa forma, um
software didático apresenta-se com a função de um material
didático diante de sua aplicação em sala de aula.
2º. Objetivos aparentes do Material Didático – Pela observação
detalhada em cada apontamento, percebe-se que um software a
ser aplicado como ferramenta de apoio didático em sala de aula
enquadra-se perfeitamente como auxiliar direto para o alcance
desses objetivos. De outro modo, pode-se considerar esses
apontamentos como um roteiro didático essencial para o sucesso
do mesmo.
46
3º. Material Didático e o favorecimento da aprendizagem e de sua
retenção – Conforme as estatísticas apresentadas, a utilização de
recursos audiovisuais pode proporcionar um ótimo aprendizado e
também uma ótima retenção do assunto. Por similaridade, o mesmo
se dá com software, onde os recursos audiovisuais estão presentes
e podem ser amplamente explorados, facilitando, em muito, a se
atingir os objetivos didáticos esperados.
“As incompatibilidades existentes em sala de aula podem ser,
muitas vezes, explicadas pela divergência entre o modo usado pelo
professor para ensinar e as diferentes maneiras de aprender dos
estudantes. Esse desequilíbrio entre a preferência por ensinar e aprender,
normalmente gera situações desagradáveis e comportamentos
improdutivos, como alunos desatentos, desinteressados ou demonstrando
falta de compromisso e responsabilidade. O que não se percebe é que essa
desmotivação é conseqüência da falta de conhecimento, por parte do
professor, da existência de diversas formas de aprendizagem dentro da sala
de aula. Uns aprendem vendo e ouvindo, outros agindo e refletindo,
estabelecendo comparações ou construindo modelos matemáticos.
Conforme alertam Felder e Silverman (1988) o aprendizado do aluno
depende em parte de sua habilidade inata e preparo prévio e, em parte da
compatibilidade entre seu modo preferido de aprender e o modo do
professor ensinar.” (FREITAS, DORNELLAS e BELHOT, 2006)
Segundo Oliveira (2001), “é de esperar, portanto, que um software seja capaz
de ampliar as interações entre o aluno e o conteúdo, com a devida mediação do
professor”.
2.6. Avaliação qualitativa e quantitativa
“Enquanto testar e medir se restringem aos aspectos quantitativos, avaliar
envolve a verificação de mudanças qualitativas do comportamento do aluno” (Piletti
apud Martins, 2006). Similarmente, alunos, a equipe de desenvolvimento de
software e professores, podem avaliar qualitativamente um software didático e sua
aplicação. A partir dessas avaliações, pode-se gerar pontuações quantitativas, que
serão determinantes para as decisões posteriores sobre o software e sua aplicação.
47
No que se refere à avaliação de processos didáticos, Martins (2006) cita que,
“por ser o ensino um processo que tem em vista a aquisição de
conhecimentos e habilidades que impliquem a mudança de comportamento
de quem dele participa, encontramos na avaliação um elemento
fundamental desse processo. É através da avaliação que se poderá verificar
até que ponto o ensino tem alcançado os resultados pretendidos. Ao
mesmo tempo, ela oferece subsídios para a alteração do processo, quando
os objetivos visados não são alcançados”.
A equipe de desenvolvimento é fundamental na produção de software didático
e, portanto, deverá estar alinhada com os objetivos educacionais dele. Segundo
Oliveira (2001), “a avaliação de um software educativo é um processo que se inicia
antes mesmo da sua criação. No momento em que a equipe produtora do software é
escolhida, os critérios básicos que direcionarão seu desenvolvimento e que servirão
conseqüentemente como parâmetros para a sua avaliação inicial estarão refletidos
no perfil daquele grupo”.
Segundo Masetto (1997), “em termos de sala de aula, a avaliação abrange o
desempenho do aluno, do professor e a adequação do programa”. De forma similar,
avaliando-se um software didático, ele abrange a utilização eficiente pelos alunos, o
apoio didático de seus recursos ao professor e a adequação do assunto que trata
para a sua finalidade.
A avaliação de um software didático, além do que já foi descrito, deve
também contemplar a avaliação de qualidade de software, pois se o mesmo não
funcionar perfeitamente e não for fácil de operar, em menor ou maior escala
prejudicará todo o processo didático a que foi destinado. Da mesma forma, a
avaliação de um software didático pelo professor é fundamental, uma vez que este
software deve atender adequadamente aos objetivos didáticos de sua aplicação.
Uma vez fundamentadas as questões didáticas, a seguir são analisados
aspectos referentes à qualidade de software.
48
3 QUALIDADE DE SOFTWARE
Este capítulo apresenta uma visão geral das necessidades de avaliação de
software aplicado como ferramenta de apoio em sala de aula, aspectos da Norma
ISO 9126 quanto à avaliação da qualidade de software, e finalmente, as indicações
da Norma de como fazer a avaliação.
3.1 Necessidade de se avaliar um software
Com o desenvolvimento e aplicação de software em vários cursos, tornou-se
necessário avaliá-los sob vários aspectos, de modo a obter uma visão clara e
objetiva de sua eficiência na aplicação e de sua qualidade como produto de
software.
As questões pertinentes a este trabalho envolvem problemas complexos,
como por exemplo: as questões técnicas do software a ser avaliado, as questões de
sua aplicação em sala de aula para os alunos e as questões didáticas necessárias
para a aplicação deste software pelo professor. Segundo Reel (1999), sistemas
baseados em software são excepcionalmente complexos.
É importante conhecer estas complexidades e entender as questões que
envolvem a qualidade de software e de sua aplicação, principalmente na visão de
quem o utiliza, para melhor definir a avaliação. Quando um software é aplicado
como ferramenta didática, espera-se que o mesmo corresponda satisfatoriamente
tanto em seu aspecto funcional quanto à visão do assunto que ele aborda. Software,
por ser uma ferramenta de simulação por excelência, exige um grande poder de
abstração por parte de seus analistas, de forma a traduzir em um ambiente restrito
(hardware + software), uma representação próxima da realidade a que se propõe
construir.
Segundo Matsubara (1996), a missão fundamental da engenharia é controlar
a complexidade. Os sistemas por nós construídos são tão complexos que nós não
podemos esperar compreender toda a sua complexidade de uma só vez. No
49
entanto, como engenheiros, usamos a abstração e a decomposição, a qual permite-
nos selecionar o foco de nossa atenção, retendo, contudo, uma compreensão
apropriada do sistema como um todo. Mas a abstração e a decomposição são
noções muito gerais, que não dizem explicitamente como decompor e como abstrair.
Mesmo sem saber como abstrair de forma explícita e de como aplicar
coerentemente os resultados desta abstração ao software, a abstração sempre
estará presente, inclusive, em software voltado ao ensino. Não basta que um
software apenas responda aos comandos e apresente resultados esperados; é
preciso que ele incorpore uma ampla visão do assunto, permita uma fácil
assimilação de conceitos e, fundamentalmente, contribua com o aprendizado. A
complexidade do produto de software unida à necessidade de atender às
expectativas do cliente tem sido tema de grande preocupação dos usuários.
Segundo Weidenhaupt et al. (1998), os usuários encaram um cenário significante de
problemas gerenciais ainda não tratados adequadamente pela teoria ou na prática, e
estão exigindo soluções para estes problemas.
Para o usuário, um software é como uma “caixa preta”, na qual ele utiliza as
funções disponibilizadas, sem conhecer o que está por dentro. O que se espera é
que um software atenda satisfatoriamente às suas necessidades e expectativas, o
que nem sempre ocorre. Segundo Matsubara (1996), a questão permanece: como
nós podemos oferecer aos clientes o controle sobre decisões estratégicas de
implementação de uma forma elegante, sem causar mais problemas do que os que
nós estamos tentando resolver?
No caso deste trabalho, o cliente é o aluno (usuário), que utiliza um software
como ferramenta de apoio ao aprendizado. No caso de software aplicado em cursos,
a visão do usuário é de fundamental importância, pois é para ele que o mesmo é
desenvolvido. Conhecendo os problemas complexos que envolvem a elaboração,
produção e implantação de software, e a dificuldade em se entender e corresponder
às necessidades do usuário, é preciso desenvolver um modelo que minimize o
impacto de possíveis falhas advindas deste cenário. Segundo Maiden e Ncube
(1998), a característica mais importante de um modelo é a inclusão das complexas
interdependências entre as interações do usuário, das funções internas do sistema e
50
de sua arquitetura. Deste modo, um modelo possibilita uma base analítica para a
modelagem de dependências críticas de um produto, a compreensão de como um
produto de software trabalha, e um estudo sobre possíveis mudanças para este
produto.
No entanto, segundo Lawrence (1998), a principal saída é uma compreensão
coletiva do problema do cliente. A especificação é somente uma representação, um
modelo desta compreensão.
Modelar as necessidades não necessariamente corresponde a entender os
problemas do cliente. Assim, ainda que todos os envolvidos com um software
dediquem seus esforços para que não ocorram falhas, provavelmente lacunas ou
novas necessidades serão contempladas durante o seu desenvolvimento ou mesmo
após a sua implantação. Estes fatos costumam surgir diante da dificuldade de
entendimento de alguns clientes quanto às limitações de um produto de software.
Segundo Reel (1999), gerentes, usuários, desenvolvedores e projetistas devem ter
expectativas muito realísticas. No caso de seus clientes não terem dado atenção,
lembre a eles que no dia-a-dia um sistema não vai resolver todos os seus problemas
e que provavelmente novas necessidades serão criadas.
As dificuldades em se atender com exatidão às expectativas do cliente quanto
aos resultados da aplicação de um software, unidas às falhas habituais em software,
reforçam ainda mais a necessidade de se avaliar a sua qualidade. Segundo Reel
(1999), nós ainda não melhoramos a nossa capacidade de obtermos sucesso, ao
passar de forma consistente uma idéia para um produto. De fato, estudos recentes
documentam que, enquanto a taxa de falha nos esforços de desenvolvimento de
software melhoraram nos últimos anos, o número de projetos que passam por
problemas graves chega a quase 50%.
Uma das causas de ocorrerem tantas falhas em software está relacionada às
dificuldades encontradas pelos desenvolvedores em padronizar os seus processos e
produtos utilizados na produção dos mesmos. Segundo Fenton (1996), a
padronização não será uma surpresa para qualquer um que tenha buscado uma
evidência quantitativa sobre a eficácia de um método ou ferramenta da engenharia
51
de software. No entanto, o que nos tem preocupado mais é que, geralmente,
padrões da engenharia de software são escritos de uma tal forma que nós nunca
poderemos determinar se eles foram eficazes ou não.
Como usualmente um cliente não tem controle quanto à produção de
software, somente com uma metodologia adequada para avaliação da qualidade de
um produto de software, e a sua aplicação, será possível obter algumas respostas,
como as que permitam a identificação de falhas generalizadas e que também
possibilitem a tomada de decisões por parte do cliente. Uma visão mais clara da
qualidade desta “caixa preta”, que representa um software implantado na
perspectiva do usuário, torna-se essencial. Segundo Kitchenham e Pfleeger (1996),
uma boa definição deve nos levar a medir “qualidade” de uma forma significativa.
Medições nos deixam saber se nossas técnicas realmente melhoram nosso
software, e também como a qualidade do processo afeta a qualidade do produto.
Esta concepção está integrada com a necessidade de uma avaliação que
focalize a necessidade do cliente e o objetivo da aplicação (ferramenta de apoio ao
curso), o que é parte integrante do objetivo deste trabalho.
3.2 Aspectos relevantes para a definição da metodologia de avaliação
No caso de software educacional, segundo Rocha et al. (2001), estes devem
ser escolhidos e elaborados de acordo com as teorias de aprendizagem que
diferenciam cada ambiente educacional. Assim, temos ambientes educacionais mais
ou menos interativos, que exigem maior ou menor grau de participação dos
aprendizes e um controle maior ou menor do aluno no processo de construção do
conhecimento. A dificuldade para definir a qualidade de um software educacional
baseia-se no fato de não ser este um conceito peculiar ao software.
Para Pressman (2002), a qualidade de software é uma combinação complexa
de fatores que variarão de acordo com diferentes aplicações e clientes que a
solicitam. Neste trabalho, referem-se à aplicação didática, professores e alunos.
52
Quanto à metodologia de avaliação, algumas questões precisam ser
respondidas: Como avaliar um produto de software utilizado como ferramenta
didática? Como saber se a sua aplicação é eficaz e adequada aos objetivos do
curso a que foi destinado?
Para responder a estas questões, é preciso partir da definição de um software
(requisitos e objetivos) para, então, ser feita uma confrontação entre o que se definiu
e o que se obteve com a aplicação.
Todo software necessariamente passa por uma fase de elaboração e análise,
que quanto mais refinada for, maior a possibilidade do software atender
corretamente ao objetivo a que foi proposto. Esta elaboração compreende os
requisitos do software que muitas vezes são pobres ou não contemplam a visão dos
usuários finais, motivo de alguns problemas que corriqueiramente encontramos em
software. Assim, os requisitos devem compreender os itens pertinentes ao produto
de software, como também as necessidades do usuário. Segundo Maiden e Ncube
(1998), um pré-requisito para uma seleção eficaz de um produto é a concordância
entre uma ou mais características de cada candidato a produto, com uma ou mais
exigências do cliente. Nesta concordância está, em essência, um relacionamento
entre um problema e uma solução em potencial para aquele problema. Para fazer
isto eficazmente, os engenheiros de requisitos devem moldar não somente as
exigências do cliente, mas também cada produto de software.
Se os requisitos não forem bem definidos, não há como se avaliar se um
produto de software é adequado ou não. Torna-se difícil corrigir rumos durante o
processo de desenvolvimento, porque o caminho conseqüentemente não é claro.
Segundo Reel (1999), um grande problema em gerenciar o desenvolvimento de um
determinado software é apontar onde você está em seu programa. Quanto completo
está um módulo? Quanto tempo ainda vai levar para finalizar os módulos X, Y, e Z?
Estas são questões difíceis de responder, mas elas devem ser respondidas. Se você
não sabe onde você está em relação ao programa, você não pode ajustar e nem
trazer as coisas novamente para o seu rumo.
Neste mesmo raciocínio, segundo Kitchenham e Pfleeger (1996), se você é
53
um desenvolvedor de software, gerente, ou responsável pela manutenção, a
qualidade está freqüentemente em sua mente. Mas o que realmente você entende
por qualidade de software? A sua definição é adequada? O software que você
produz é melhor ou pior do que você gostaria que ele fosse?
Como manter o desenvolvimento de um software de acordo com o que se
quer atingir? Segundo Clavadetscher (1998), usuários deveriam ter um painel de
controle dos requisitos para poderem preservar a base original de suas exigências.
A proposta de Clavadetscher é que o próprio cliente tenha um
acompanhamento daquilo que encomendou conforme seus requisitos. Nesta mesma
linha de pensamento, segundo Maiden e Ncube (1998), as especificações de
requisitos devem ser suficientes para possibilitar uma seleção eficaz de um produto
mais completo em relação às necessidades do usuário.
Assim, os requisitos devem contemplar a visão do usuário (aluno). Além
disso, é o usuário que deverá avaliar a aplicação do software com mais propriedade.
Segundo Lawrence (1998), os clientes têm a responsabilidade de dizer: “Sim, isto é
o que eu quero” ou “Não, isto não é o que eu quero” quando questionados sobre a
aprovação de um projeto. Esta é a essência da prototipagem: mostrar aos usuários
um exemplo bem próximo do sistema, para que possamos descobrir se estamos
indo pelo caminho certo.
Portanto, além das questões de qualidade no planejamento, no
desenvolvimento e na conclusão de um produto de software, há essencialmente a
questão da visão do usuário diante das suas expectativas em relação à aplicação do
software. A princípio, todo o esforço destinado ao produto de software é realizado no
sentido de atender aos objetivos definidos para o software. Segundo Kitchenham e
Pfleeger (1996), para avaliar ou melhorar a qualidade de software em sua
organização, você deve definir os aspectos de qualidade que lhe interessam, e
então decidir como vai medi-los. Pela descrição de como medir a qualidade, você
torna mais fácil para outras pessoas compreenderem o seu ponto de vista e
relacionarem as suas noções com as delas. Finalmente, a sua noção de qualidade
deve estar relacionada com as metas do negócio. Somente você pode determinar se
54
um bom software é um bom negócio.
Neste sentido, a metodologia de avaliação de um software deve atender aos
objetivos do negócio (ambiente e finalidade para o qual o software foi desenvolvido),
e não apenas ser uma ferramenta rígida de avaliação que pode determinar vários
aspectos importantes da qualidade de um software, mas não necessariamente
apontar para o objetivo do negócio ao qual o software foi destinado.
Outra questão é a visão de qualidade sob a ótica da equipe de
desenvolvimento. Esta equipe é certamente a mais indicada para avaliar itens
específicos e de nível técnico do produto de software. Segundo Kitchenham e
Pfleeger (1996), enquanto o usuário vê o produto por fora, a visão de qualidade do
produto olha para dentro dele, considerando as características inerentes ao produto.
Segundo Rocha et al. (2001), a Norma ISO 9126 apresenta um conjunto de
características de qualidade aplicável a qualquer produto de software. Entretanto,
produtos em domínios de aplicações específicos e as diferentes tecnologias
utilizadas no desenvolvimento de produtos de software implicam características
específicas que determinam a qualidade desses produtos.
As citações anteriores, confrontadas com as finalidades deste trabalho,
sugerem em primeiro lugar uma definição dos requisitos de um software que se
deseja aplicar em sala de aula, com base na Norma ISO 9126, para, em seguida,
aplicar uma avaliação com a visão do usuário e também com a visão da equipe de
desenvolvimento. Deste modo, analisando e cruzando as informações obtidas, o
software avaliado será julgado quanto à sua aceitação ou não, bem como os pontos
a serem melhorados para uma futura avaliação.
3.3 Sobre a Norma ISO 9126
A Norma ISO 9126 trata especificamente da avaliação da qualidade de
produto de software.
55
Qualidade de software, segundo Rocha et al. (2001), pode ser vista como um
conjunto de características que devem ser alcançadas em um determinado grau
para que o produto atenda às necessidades de seus usuários. É por meio desse
conjunto de características que a qualidade de um produto de software pode ser
descrita e avaliada.
Esta Norma veio consolidar uma série de modelagens anteriores destinadas à
avaliação da qualidade de produto de software. Ainda segundo Rocha et al. (2001),
os trabalhos mais importantes e pioneiros neste contexto são os de Boehm (1978) e
McCall (1977), cujos modelos apresentam uma hierarquia de características que
contribuem para a qualidade do produto.
A Norma ISO 9126 é adequada ao propósito de avaliação deste trabalho, por
estar voltada também à visão do usuário, sem abandonar a visão do produto de
software. Quanto a isso, segundo Kitchenham e Pfleeger (1996), diferentemente de
recentes modelos americanos, a estrutura da Norma ISO está completamente
hierárquica – cada subcaracterística está relacionada a uma única característica.
Estas subcaracterísticas relacionam aspectos de qualidade que são visíveis para o
usuário, tanto quanto para as propriedades internas do software.
A Norma ISO 9126 não especifica em detalhes os critérios de avaliação, o
que por um lado pode parecer arbitrário; no entanto, é preciso lembrar que o nível de
abstração que envolve a produção de software, e os mais diversos objetivos de
análise que podem existir sobre um mesmo software, necessitam de critérios de
avaliação sem um direcionamento específico. Se assim fosse, algumas avaliações
ficariam comprometidas por um eventual foco que distorcesse a finalidade específica
de sua análise. Segundo Kitchenham e Pfleeger (1996), há a falta de uma decisão
apropriada de qual critério adotar para um fator em particular. Assim, a seleção de
características de qualidade e subcaracterísticas pode parecer arbitrária. Não há
uma descrição de como as métricas para o nível mais baixo (chamado por
‘indicadores’ na Norma ISO 9126) são compostas dentro de uma avaliação global
das características de qualidade de nível mais alto.
Mesmo assim, deve-se procurar realizar esta avaliação de forma acurada e
56
de modo a obter resultados mais precisos. Quanto à questão da qualidade a ser
avaliada com base na Norma ISO 9126 e pela visão do usuário, comentam
Kitchenham e Pfleeger (1996) que alguns especialistas em qualidade sugerem que
todos os aspectos de qualidade citados pelos usuários precisam ser considerados
durante a definição e a avaliação. Isto corresponde à definição de qualidade da
Norma ISO: ”qualidade é a totalidade das características de uma entidade, que lhe
confere a capacidade de satisfazer necessidades explícitas e implícitas”.
Ainda sob a ótica do usuário, que no caso deste trabalho é parte essencial,
continuam Kitchenham e Pfleeger (1996), enquanto que a visão transcendental é
etérea, a visão do usuário é mais concreta, pois traz a solo firme as características
do produto que apontam para as necessidades do usuário. Esta visão de qualidade
avalia o produto no contexto do trabalho e pode compor uma visão altamente
personalizada. Para uma meta de confiabilidade e desempenho, a visão do usuário
é inerente; a partir daí, métodos “burros” avaliam o comportamento do produto com
respeito a perfis operacionais (isto é, para padrões esperados de uso e
funcionalidade). A usabilidade do produto também está voltada para a visão do
usuário: pesquisas em laboratórios observam como usuários interagem com os
produtos de software.
Por suas características voltadas à avaliação técnica e de aplicação, a
Norma abrange todas as perspectivas necessárias para um produto de software
voltado para aplicação didática. Portanto, a Norma ISO 9126 atende
satisfatoriamente aos objetivos deste trabalho.
3.4 A avaliação segundo a Norma ISO 9126
“Para se avaliar a qualidade de um produto por algum método
quantitativo, é necessário um conjunto de características de qualidade que
descreva o produto e forme a base para a avaliação. Esta Norma define
essas características de qualidade para produtos de software e é dirigida
àqueles envolvidos com aquisição, desenvolvimento, uso, suporte,
manutenção ou auditoria de software” (Norma ISO 9126).
57
O procedimento de avaliação, constante da Norma, indica três passos:
medição, pontuação e julgamento. Na medição, as métricas escolhidas são
aplicadas ao software, e apura-se o resultado através de médias ponderadas. Na
pontuação, os resultados (valores medidos), determinam o seu nível, como indica a
Figura 6. No julgamento, um conjunto de níveis pontuados é sintetizado, de forma a
verificar se este resultado atinge o objetivo da análise. O resultado desta síntese irá
apontar para a rejeição ou aceitação, ou para a não-liberação ou liberação do
produto de software.
Figura 6 Valor medido e nível de pontuação
Fonte: Norma ISO 9126
Quanto à pontuação, a norma apresenta um exemplo, onde indica os níveis
de pontuação: Insuficiente, Regular, Bom e Excelente, sendo que o nível insuficiente
é considerado como “insatisfatório”, e os demais como “satisfatórios”; como
apresentado na Figura 6.
“A Norma adota a avaliação de qualidade de software através de
seis características e cada uma com suas respectivas subcaracterísticas.
Características de qualidade de software é um conjunto de atributos de um
produto de software, através do qual sua qualidade é descrita e avaliada.
Uma característica de qualidade de software pode ser detalhada em
múltiplos níveis de subcaracterísticas” (Norma ISO 9126).
As seis características que descrevem a qualidade de software são:
funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e
portabilidade. As características e suas subcaracterísticas são apresentadas na
Tabela 4, onde o autor, para facilitar as referências a estes itens dentro deste
trabalho, classifica as características com a inicial “C” e as subcaracterísticas com
Insuficiente
Regular
Valor medido
Escala para a métrica Níveis de Pontuação
Insatisfatório
Excelente
Bom Nível pontuado
Satisfatório
58
“S”, sendo que a ordem seqüencial numérica que se segue, obedece à ordem
hierárquica da Norma.
Tabela 4 Características e subcaracterísticas da Norma ISO 9126
Característica
Item Subcaracterística
S.1.1 Adequação
S.1.2 Acurácia
S.1.3 Interoperabilidade
S.1.4 Conformidade
C.1
Funcionalidade
S.1.5 Segurança de acesso
S.2.1 Maturidade
S.2.2 Tolerância a falhas
C.2
Confiabilidade
S.2.3 Recuperabilidade
S.3.1 Inteligibilidade
S.3.2 Apreensibilidade
C.3
Usabilidade
S.3.3 Operacionalidade
S.4.1 Comportamento em relação ao tempo
C.4
Eficiência
S.4.2 Comportamento em relação aos recursos
S.5.1 Analisabilidade
S.5.2 Modificabilidade
S.5.3 Estabilidade
C.5
Manutenibilidade
S.5.4 Testabilidade
S.6.1 Adaptabilidade
S.6.2 Capacidade para ser instalado
S.6.3 Conformidade
C.6
Portabilidade
S.6.4 Capacidade para substituir
Fonte: Adaptação da Norma ISO 9126
3.5 Pontos de vista segundo a Norma ISO 9126
A avaliação poderá variar dependendo do ponto de vista com o qual se está
avaliando. A Norma prevê isto – “A importância de cada característica de qualidade
também varia dependendo do ponto de vista considerado” (Norma ISO 9126) –, e
apresenta três pontos de vista diferentes: a visão do usuário, a da equipe de
desenvolvimento e a do gerente. Segundo a Norma ISO 9126,
“a visão do usuário em relação à qualidade do produto de software
pode incluir questões como: As funções requeridas estão disponíveis no
59
software? Quão confiável é o software? Quão eficiente é o software? O
software é fácil de usar? Quão fácil é transferir o software para outro
ambiente? A visão da equipe de desenvolvimento está voltada a verificar as
características quanto à aplicação dos requisitos iniciais e também em
relação à manutenção. A visão do gerente é geral, mas ele pretende
otimizar qualidade dentro das limitações de custo, recursos humanos e
prazos”.
Para um software didático, o autor entende que os três pontos de vista são
fundamentais e complementares, pois o que os diferencia é que a visão do gerente é
estratégica e a visão do usuário está voltada à aplicação do software, enquanto que
a visão da equipe de desenvolvimento é essencialmente técnica. Dentro deste
contexto, para um software ser didático, ele deve atender às estratégias do
professor, aos objetivos da aplicação em sala de aula e apresentar qualidade técnica
satisfatória como software. Assim, os resultados destas três avaliações distintas
permitirão uma análise mais específica de um software, de sua aplicação e de sua
finalidade, apontando aspectos que não apareceriam em uma única avaliação,
considerando apenas um dos pontos de vista.
A metodologia de avaliação para um software didático, desenvolvida neste
trabalho, segue estas orientações da Norma quanto às avaliações, às pontuações e
aos pontos de vista, o que é apresentado no capítulo a seguir.
60
4 METODOLOGIA DE AVALIAÇÃO
Neste capítulo é apresentada a metodologia para a avaliação da qualidade de
software aplicado como ferramenta de apoio didático em sala de aula.
Esta metodologia foi desenvolvida com base na Norma ISO 9126, que é
específica para a avaliação da qualidade de um produto de software, mas que
permite uma avaliação mais ampla voltada à visão da equipe de desenvolvimento,
do usuário e também a do gerente, que neste trabalho são, respectivamente, a visão
da equipe de desenvolvimento, a dos alunos e a do professor.
Assim, a avaliação de um software didático que seja avaliado pelos três
pontos de vista resultará na pontuação de sua qualidade técnica, da qualidade de
sua aplicação e de sua qualidade didática.
Desta forma, serão apurados os pontos fortes e também os pontos fracos
deste software por todos os aspectos fundamentais de um software a ser aplicado
em sala de aula. Finalmente, esta análise completa resultará na aceitação ou
continuidade de uso deste software didático, ou ainda, na rejeição ou na
descontinuidade de uso do mesmo.
A parte didática desta avaliação também é feita sob a Norma, relacionando as
questões didáticas necessárias para um software didático, seguindo a orientação de
avaliação da qualidade de software apontado pela Norma.
Inicialmente, há a necessidade de se esclarecer alguns aspectos do
desenvolvimento da metodologia de avaliação; em seguida, a partir do tópico 4.2, é
apresentada a metodologia de avaliação propriamente dita.
4.1 Sobre a metodologia de avaliação
Para a finalidade de se avaliar a qualidade de software aplicado como
ferramenta de apoio didático em sala de aula, deve-se definir o objetivo de cada
61
avaliação diante de cada ponto de vista. Assim, a avaliação do ponto de vista da
equipe de desenvolvimento deve ter por finalidade apresentar uma avaliação técnica
da qualidade deste software, a avaliação do ponto de vista do usuário deve ter por
finalidade apresentar uma avaliação da aplicação deste software, e a avaliação do
ponto de vista do gerente deve ter por finalidade apresentar uma avaliação
estratégica da aplicação deste software, que por ser didático, envolve as questões
didáticas do professor. A Tabela 5 apresenta estes pontos de vista, quem avalia e a
finalidade da avaliação.
Tabela 5 Avaliador e finalidade da avaliação para cada ponto de vista da Norma
Ponto de vista Avaliador Finalidade
Equipe de desenvolvimento
Equipe de desenvolvimento Avaliação Técnica
Usuário Alunos Avaliação da Aplicação
Gerente Professor Avaliação Didática
Fonte: Autor
A avaliação pela Norma poderia ser feita integralmente para cada ponto de
vista; no entanto, por se tratar de um software com finalidade didática e existirem
três avaliadores distintos com visões distintas, o autor optou por adotar as três
avaliações com base na Norma ISO 9126, destacando, em cada uma, apenas as
subcaracterísticas que serão avaliadas adequadamente conforme o perfil de seus
avaliadores. Com isso, ainda que avaliadas separadamente em avaliações distintas
e também por avaliadores distintos, todas as características e subcaracterísticas da
Norma acabam sendo avaliadas e pontuadas no final.
4.1.1 A avaliação e o perfil do avaliador
Considerando os avaliadores – equipe de desenvolvimento, alunos e
professor, e seus respectivos pontos de vista – observamos que algumas
subcaracterísticas não podem ou não fazem sentido em ser avaliadas por um ou até
dois destes avaliadores. Por exemplo: ainda que os alunos fossem técnicos em
informática, não teriam acesso às linhas de código de programação do software
62
aplicado, ou seja, não têm como avaliar questões essencialmente técnicas, como é
o caso de se avaliar, por exemplo, as subcaracterísticas: “interoperabilidade”,
“segurança de acesso” e “modificabilidade”. Assim, os alunos avaliarão somente as
subcaracterísticas que qualquer aluno tenha condições de avaliar (direta ou
indiretamente), inclusive, aqueles que estão tendo contato pela primeira vez com um
computador. O professor por sua vez é quem tem a visão estratégica do software,
independentemente de ter conhecimentos técnicos em informática; no entanto, é ele
quem participa diretamente na elaboração dos requisitos do software didático a ser
avaliado, ou seja, na definição das avaliações da equipe de desenvolvimento e a dos
alunos. Portanto, é ele quem indicará ou será questionado pela equipe de
desenvolvimento sobre algumas questões técnicas necessárias, como, por exemplo,
se o software deverá ser executado em mais de um ambiente. Deste modo, a
avaliação essencialmente técnica fica apenas para a equipe de desenvolvimento,
como era de se esperar. Resta a avaliação didática, que será realizada no final pelo
próprio professor, onde, em seguida, analisará as três avaliações de um software
didático, confrontando-as com seus objetivos.
Assim, as subcaracterísticas da Norma para a avaliação de um software
didático conforme o perfil do avaliador, ficam distribuídas como apresentado na
Tabela 6.
Tabela 6 Subcaracterísticas avaliadas conforme o perfil do avaliador
Avaliador Perfil Subcaracterísticas
Equipe de desenvolvimento Técnico Essencialmente técnicas
Alunos Usuário Voltadas à aplicação
Professor Didático Voltadas à aplicação
Fonte: Autor
As subcaracterísticas voltadas à aplicação de um software didático são
destinadas ao professor e aos alunos, pois, apesar de avaliarem as mesmas
subcaracterísticas, os objetivos das avaliações são diferentes: enquanto o professor
avaliará os objetivos didáticos desta aplicação, os alunos avaliarão a aplicação deste
software em sala de aula para a matéria de estudo lecionada.
63
O critério adotado pelo autor foi separar as subcaracterísticas essencialmente
técnicas (aquelas a que somente a equipe de desenvolvimento tem acesso e
condições de avaliar), daquelas que são voltadas à aplicação de um software
didático (aquelas a que o professor e os alunos têm acesso e condições de avaliar).
Isto não quer dizer que a avaliação do professor fica restrita e não abrange as
questões técnicas, pois este mesmo professor participa na definição dos requisitos
deste software, inclusive dos requisitos técnicos, como por exemplo, se este
software deve interagir com algum banco de dados disponível em rede.
As subcaracterísticas consideradas essencialmente técnicas para um
software didático, segundo o autor, são:
• As subcaracterísticas: “maturidade”, “tolerância a falhas” e
“recuperabilidade”, pertencentes à característica “confiabilidade”;
• As subcaracterísticas: “comportamento em relação ao tempo” e
“comportamento em relação aos recursos”, pertencentes à
característica “eficiência”;
• As subcaracterísticas: “analisabilidade”, “modificabilidade”,
“estabilidade” e “testabilidade”, pertencentes à característica
“manutenibilidade”;
• As subcaracterísticas: “adaptabilidade”, “capacidade para ser
instalado”, “conformidade” e “capacidade para substituir”, pertencentes
à característica “portabilidade”;
• Isoladamente as subcaracterísticas: “interoperabilidade” e “segurança
de acesso”, pertencentes à característica “funcionalidade”.
As demais subcaracterísticas, segundo o autor, são consideradas somente
para a avaliação da aplicação de um software didático, uma vez que entende que a
avaliação dos alunos para estas subcaracterísticas é a mais adequada como
avaliação de uma aplicação de software em sala de aula. Do mesmo modo, para
essas mesmas subcaracterísticas, cabe somente ao professor avaliar quanto às
questões didáticas. As subcaracterísticas voltadas a aplicação, são:
64
• As subcaracterísticas: “adequação”, “acurácia” e “conformidade”,
pertencentes à característica “funcionalidade”;
• As subcaracterísticas: “inteligibilidade”, “apreensibilidade” e
“operacionalidade”, pertencentes à característica “usabilidade”.
É importante ressaltar que o enfoque didático foi utilizado nessa seleção entre
as subcaracterísticas, uma vez que, considerando apenas o ponto de vista da
equipe de desenvolvimento para a avaliação de um software, todas as
subcaracterísticas devem ser avaliadas pela equipe de desenvolvimento, o que não
é o caso.
4.1.2 As subcaracterísticas essencialmente técnicas e da aplicação
As justificativas da escolha pelo autor dessas subcaracterísticas como
essencialmente técnicas ou da aplicação são apresentadas a seguir nos grupos de
características e suas respectivas subcaracterísticas de qualidade de software, texto
em negrito; à frente, as breves questões adaptadas pelo autor para o entendimento
de cada ponto de verificação da Norma (questões das subcaracterísticas com base
na Tabela 13), e, por fim, em itálico, o texto referente às justificativas. Para efeito de
simplificação e melhor visualização, os itens relativos às características e
subcaracterísticas estão indicados respectivamente pelas iniciais “C” e “S”; e os
números na seqüência correspondem à sua ordem hierárquica de apresentação,
conforme estão dispostos na Norma.
• C.1. Funcionalidade: O software atende a seu propósito e às necessidades
especificadas? Contém subcaracterísticas com questões essencialmente
técnicas e da aplicação.
• S.1.1. Adequação: O software atende e é apropriado para as tarefas
especificadas? É preferível que os alunos avaliem este item em razão de
suas expectativas quanto à apresentação e à forma como o software
didático trata a matéria de estudo, verificando, assim, pelo uso, a sua
adequação. Portanto, esta é uma questão da aplicação do software em
sala de aula. Quanto ao lado técnico da questão, é indicado que a equipe
65
de desenvolvimento teste o software junto com o professor, para
providenciar eventuais acertos antes da aplicação do software em sala de
aula.
• S.1.2. Acurácia: O software gera resultados corretamente, efeitos ou
conforme o acordado? Aqui também é preferível que os alunos avaliem,
uma vez que nada mais frustrante que os resultados ou efeitos
apresentados por um software com finalidade didática, não estarem de
acordo com o que se esperava quanto ao assunto tratado. Portanto, esta é
uma questão da aplicação do software em sala de aula. Quanto ao lado
técnico da questão, é indicado também que a equipe de desenvolvimento
teste o software junto com o professor, para providenciar eventuais
acertos antes da aplicação do software em sala de aula.
• S.1.3. Interoperabilidade: O software interage com sistemas
especificados? Questão essencialmente técnica.
• S.1.4. Conformidade: O software está de acordo com as normas,
convenções ou regulamentações previstas em leis e descrições similares,
relacionadas à aplicação? O próprio item informa que a questão é voltada
à aplicação do software.
• S.1.5. Segurança de acesso: O software evita acesso não autorizado,
acidental ou deliberado a programas e dados? Questão essencialmente
técnica.
• C.2. Confiabilidade: O software mantém seu nível de desempenho sob
condições estabelecidas durante um período de tempo estabelecido? Contém
apenas subcaracterísticas com questões essencialmente técnicas.
• S.2.1. Maturidade: Qual a freqüência de falhas por defeitos que o
software apresenta? Questão essencialmente técnica, não cabe ao
usuário fazer medições.
• S.2.2. Tolerância a falhas: O software mantém um nível de desempenho
especificado nos casos de falhas no software ou de violação nas
interfaces especificadas? Questão essencialmente técnica.
• S.2.3. Recuperabilidade: O software restabelece seu nível de
desempenho em caso de falha e recupera os dados diretamente afetados;
em que tempo e com que esforço? Questão essencialmente técnica.
66
• C.3. Usabilidade: É fácil para o usuário utilizar o software? Contém apenas
subcaracterísticas com questões da aplicação.
• S.3.1. Inteligibilidade: O usuário reconhece com facilidade no software o
conceito lógico e sua aplicabilidade? Questão da aplicação do software em
sala de aula.
• S.3.2. Apreensibilidade: O usuário aprende com facilidade a aplicação do
software? Questão da aplicação do software em sala de aula.
• S.3.3. Operacionalidade: O usuário opera e controla cada operação do
software com facilidade? Questão da aplicação do software em sala de
aula.
• C.4. Eficiência: É satisfatório o relacionamento entre o nível de desempenho
do software e a quantidade de recursos usados em condições estabelecidas?
Contém apenas subcaracterísticas essencialmente técnicas.
• S.4.1. Comportamento em relação ao tempo: É satisfatório o tempo de
resposta do software, o tempo de processamento e velocidade na
execução de suas funções? Questão essencialmente técnica, onde
também é indicado que a equipe de desenvolvimento teste o software
junto com o professor para providenciar eventuais acertos antes da
aplicação do software em sala de aula.
• S.4.2. Comportamento em relação aos recursos: É satisfatória a
quantidade de recursos usados pelo software e a duração de seu uso na
execução de suas funções? Questão essencialmente técnica, onde
também é indicado que a equipe de desenvolvimento teste o software
junto com o professor, para providenciar eventuais acertos antes da
aplicação do software em sala de aula.
• C.5. Manutenibilidade: É fácil fazer modificações específicas no software?
Contém apenas subcaracterísticas com questões essencialmente técnicas.
• S.5.1. Analisabilidade: É fácil de diagnosticar deficiências ou causas de
falhas, ou identificar partes a serem modificadas no software? Questão
essencialmente técnica.
• S.5.2. Modificabilidade: É fácil de modificar o software, remover seus
defeitos ou adaptá-lo a mudanças ambientais? Questão essencialmente
técnica.
67
• S.5.3. Estabilidade: É baixo o risco de efeitos inesperados ocasionados
por modificações no software? Questão essencialmente técnica.
• S.5.4. Testabilidade: É fácil de se validar o software modificado? Questão
essencialmente técnica.
• C.6. Portabilidade: O software é facilmente transferido de um ambiente para
outro? Contém apenas subcaracterísticas com questões essencialmente
técnicas.
• S.6.1. Adaptabilidade: O software é facilmente adaptado a ambientes
diferentes especificados, sem a necessidade de aplicação de outras ações
ou meios além daqueles fornecidos para essa finalidade pelo software
considerado? Questão essencialmente técnica.
• S.6.2. Capacidade para ser instalado: É fácil de se instalar o software
num ambiente especificado? Questão essencialmente técnica.
• S.6.3. Conformidade: O software está consonante com os padrões ou
convenções relacionados à portabilidade? Questão essencialmente
técnica.
• S.6.4. Capacidade de substituir: O software facilmente substitui outro
software, no ambiente estabelecido por esse outro software? Questão
essencialmente técnica.
Para melhor visualizar esta divisão para a avaliação da Norma, a Tabela 7
apresenta as características e subcaracterísticas da Norma e aponta na coluna
“Avaliação” o termo “Aplicação” para as subcaracterísticas voltadas à aplicação de
um software didático – a serem avaliadas pelos alunos e depois pelo professor – e o
termo “Técnica” para as subcaracterísticas essencialmente técnicas – a serem
avaliadas pela equipe de desenvolvimento.
68
Tabela 7 Finalidade da avaliação para cada subcaracterística da Norma segundo o autor
Característica Item Subcaracterística Avaliação
S.1.1
Adequação
Aplicação
S.1.2
Acurácia
Aplicação
S.1.3
Interoperabilidade
Técnica
S.1.4
Conformidade
Aplicação
C.1
Funcionalidade
S.1.5
Segurança de acesso
Técnica
S.2.1
Maturidade
Técnica
S.2.2
Tolerância a falhas
Técnica
C.2
Confiabilidade
S.2.3
Recuperabilidade
Técnica
S.3.1
Inteligibilidade
Aplicação
S.3.2
Apreensibilidade
Aplicação
C.3
Usabilidade
S.3.3
Operacionalidade
Aplicação
S.4.1
Comportamento em relação ao tempo
Técnica
C.4
Eficiência
S.4.2
Comportamento em relação aos recursos
Técnica
S.5.1
Analisabilidade
Técnica
S.5.2
Modificabilidade
Técnica
S.5.3
Estabilidade
Técnica
C.5
Manutenibilidade
S.5.4
Testabilidade
Técnica
S.6.1
Adaptabilidade
Técnica
S.6.2
Capacidade para ser instalado
Técnica
S.6.3
Conformidade
Técnica
C.6
Portabilidade
S.6.4
Capacidade para substituir
Técnica
Fonte: Autor
4.1.3 Requisitos básicos de um software didático
Para preparar o processo de avaliação de um software didático, primeiro é
necessário definir os requisitos deste software.
Segundo Rocha et al. (2001):
“Entendemos ‘requisitos de software’ como sentenças que
expressam as necessidades dos clientes e que condicionam a qualidade do
software. A especificação dos requisitos de um produto de software implica
a determinação de requisitos não-funcionais, entre os quais incluem-se os
requisitos de qualidade que são difíceis de definir. A qualidade de software
é multidimensional, sendo assim, os requisitos de qualidade entram em
69
conflito e os benefícios em atingi-los não são fáceis de medir. Entretanto,
essa é uma atividade fundamental para a garantia da qualidade do produto
e para a verificação do atendimento dos requisitos do usuário”.
Para Pressman (2002) os requisitos de software são a base a partir da qual a
qualidade é medida, portanto, a falta de conformidade aos requisitos significa falta
de qualidade. Aponta também a relação entre o desenvolvedor e o cliente, onde
ambos têm um papel ativo na definição dos requisitos, o cliente indicando o que quer
(às vezes de forma nebulosa) e o desenvolvedor, agindo como indagador, consultor
e solucionador de problemas.
Em um software didático a ser desenvolvido, os requisitos são parte
integrante de seu desenvolvimento, enquanto que, para um software didático
adquirido ou a ser adquirido, os requisitos servem de referência para a avaliação da
qualidade do produto de software e de sua aplicação. Analisando diretamente cada
subcaracterística da Norma ISO 9126, descrevendo respectivamente para cada uma
delas o que se espera ou se deseja do software didático a ser avaliado, são obtidos
os seus requisitos básicos.
O autor utiliza o termo “requisitos básicos” para diferenciá-los dos requisitos
necessários para o desenvolvimento de qualquer software, que são ricos em
detalhes e envolvem complexidades específicas que existem independentemente da
finalidade do mesmo. No caso deste trabalho, os requisitos básicos podem ser os
mais gerais, porém, sem deixar de apontar as necessidades essenciais da finalidade
do software, uma vez que o objetivo não é “desenvolver o software” e, sim, obter
referências para uma avaliação adequada quanto à aplicação didática.
Apesar de a equipe de desenvolvimento não analisar os requisitos básicos
destinados à avaliação dos alunos (avaliação da aplicação do software em sala de
aula), a mesma pode analisá-los no caso de um processo de desenvolvimento de
um software didático que será avaliado. A finalidade disso é a de melhor direcionar
este desenvolvimento aos objetivos da aplicação, o que pode ser feito por meio de
orientações e testes realizados conjuntamente com o professor.
70
4.1.4 A ordem de aplicação das avaliações
O autor sugere uma ordem para executar as avaliações, uma vez que esta
mesma ordem foi adotada nesta metodologia de avaliação. Porém, vale ressaltar
que apenas a avaliação pelo ponto de vista do professor precisa ser feita após a
avaliação dos alunos, isto porque, para a avaliação do professor, é fundamental que
a aplicação do software tenha sido acompanhada em detalhes quanto às questões
didáticas. Já as questões técnicas que a equipe de desenvolvimento irá avaliar
podem ser feitas independentemente das outras, em qualquer ordem, uma vez que
estas não dependem da aplicação.
Quanto à ordem sugerida, primeiro, o software é avaliado pelos alunos quanto
da sua aplicação, que deve favorecer, entre outras coisas, o aprendizado do aluno
com a visibilidade do assunto e seus conceitos, além de facilitar as operações, as
consultas e a análise dos resultados. Em seguida, é realizada a avaliação da equipe
de desenvolvimento quanto à qualidade do produto de software, que deve garantir,
entre outras coisas, que ele atenda corretamente aos comandos básicos e às
operações, funcionando bem e apresentando adequadamente o tema para o qual foi
desenvolvido, sem comprometer o bom andamento da aula e nem os resultados
esperados. Por fim, o software é avaliado quanto a “ser didático”, com base no
acompanhamento da aplicação em sala de aula e análise da avaliação dos alunos.
Assim, a união e a análise das avaliações realizadas apontará se este software é
satisfatoriamente adequado como ferramenta de apoio didático ao curso em questão
ou não.
Todos estes fatores devem ser considerados e avaliados, seja para a adoção
e aplicação de um novo software didático, ou ainda, para verificar as condições e as
necessidades de melhoria de um que já esteja sendo aplicado.
4.2 Aplicando a metodologia de avaliação
Esta parte é destinada ao entendimento e a seqüência de aplicação da
metodologia de avaliação.
71
4.2.1 Determinação dos requisitos básicos
Este passo é referente à determinação pelo professor dos requisitos básicos
de um software didático a ser avaliado como produto de software.
A determinação dos requisitos básicos de um software didático é o primeiro
passo para se iniciar o processo de avaliação, pois são esses requisitos que servirão
de referência sobre o que um software didático a ser avaliado, deve apresentar e
corresponder de forma satisfatória. Quanto aos requisitos básicos, é importante
ressaltar que estes requisitos devem compreender o tema do software para a área
de conhecimento à qual é destinado, no entanto, não deve haver a preocupação de
apontar questões didáticas, pois a própria avaliação didática cuidará disso (tópico
4.2.7). Trata-se portanto, apenas de se determinar os requisitos básicos que sejam
técnicos e também os voltados aos alunos (aplicação em sala de aula).
Para facilitar o entendimento e orientar quanto a determinação dos requisitos
básicos de um software didático como produto de software, é utilizada a Tabela 13,
(apenas como referência e não para preenchimento - ignorar os campos para as
pontuações), que apresenta as subcaracterísticas de qualidade de software da
Norma ISO 9126, seguida de breves questões adaptadas pelo autor para o
entendimento de cada ponto de verificação da Norma (as subcaracterísticas). Estes
requisitos básicos devem ser anotados em uma lista à parte, em um relatório, por
exemplo (como o apresentado no tópico 4.1.2), para serem analisados no passo de
pontuação da avaliação (tópico 4.2.6) servindo de base para a pontuação final de
algumas subcaracterísticas e a análise detalhada de todas.
Feito isso, apesar de a equipe de desenvolvimento já poder avaliar o
software, o autor deixou esta avaliação para ser feita após a avaliação dos alunos,
uma vez que na própria Tabela 13, apresentada mais adiante, compreende as duas
avaliações (equipe de desenvolvimento e alunos). Desta forma, a seqüência
apresentada nesta metodologia de avaliação torna-se mais clara e objetiva.
72
4.2.2 Preparação para a avaliação dos alunos
Este passo é referente à elaboração pelo professor da avaliação a ser
aplicada para os alunos.
Segundo Nielsen (1997), na aplicação de questionários ao invés de
entrevistas, você deve utilizar perguntas fechadas para que elas sejam fáceis de ser
entendidas e, também, saber antecipadamente quais dados precisa e o que você
planeja fazer com eles. Os questionários são de grande valia para se obter um
retorno da apreciação geral do usuário; você pode repeti-los em intervalos regulares
para medir as mudanças nas atitudes dos usuários.
Para se adotar uma avaliação em forma de um questionário, pode-se fazer o
uso de apontamentos em cada item por alternativas qualitativas, do tipo: Insuficiente,
Regular, Bom e Excelente – esta é uma forma direta, de fácil entendimento e
indicada pela Norma. Assim, sabendo antecipadamente “o que se quer medir” e “por
que este item deve ser medido”, a avaliação terá um conteúdo coerente com a sua
finalidade e os resultados obtidos apontarão para medidas de correção ou tomadas
de decisão mais precisas.
A constante inovação tecnológica e as variadas mudanças nas operações e
processos das empresas, devido especialmente à alta competitividade imposta pelos
mercados, podem levar à obsolescência de um software caso ele não seja
atualizado de forma a acompanhar as novas necessidades do usuário. Assim, é
preciso acompanhar estas mudanças que podem ser sinalizadas por variações
observadas nas avaliações atuais em relação às anteriores.
A avaliação de um software didático pelos alunos (Tabela 8), foi elaborada
pelo autor com o objetivo de se apurar a eficiência da aplicação de um software pelo
ponto de vista dos alunos. Os itens a serem avaliados foram separados em grupos e
subgrupos de análise (itens e subitens respectivamente), de forma estratégica, para
se obter as pontuações sobre vários aspectos do software. A principal preocupação
foi que os alunos identificassem com facilidade os vários itens da avaliação ao terem
utilizado o software por completo.
73
Tabela 8 Modelo para avaliação da aplicação de um software didático pelos alunos
Item Subitem Insuficiente
Regular Bom Excelente
Apresentação
Operação
Facilidade de uso
Telas
Cadastros
Gráficos
Relatórios
Visualização
Ajuda (help)
Visão do assunto
Aprendizado
Exemplos
Co
mplemento
ao curso
Aplicação prática
Software didático
Avaliação
geral
Software comercial
Fonte: Autor
O subitem “Software comercial”, contido no item “Avaliação geral”, foi
colocado na avaliação pelo autor apenas para se obter uma apreciação dos alunos
em relação à possibilidade da aplicação deste software em seu ambiente de
trabalho. Não faz parte desta metodologia avaliar se o software pode se transformar
em um produto comercial ou não, de modo que este item não é relacionado a
nenhum outro dentro deste trabalho.
O modelo de avaliação aplicado aos alunos (Tabela 8) foi elaborado pelo
autor; no entanto, cada professor deve optar entre adotar este mesmo modelo,
adaptá-lo ou desenvolver outro que melhor represente a sua necessidade de análise
da aplicação do software em sala de aula perante os alunos. A idéia principal é que
os alunos avaliassem o software sem qualquer referência à Norma. Preocupando-se
com que esta avaliação fosse simples e direta naquilo que pretendia saber sobre o
software avaliado pelos alunos, o autor cuidou que as médias obtidas dos subitens
pudessem ser relacionadas com as subcaracterísticas da Norma, permitindo, assim,
realizar a pontuação da aplicação do software pelo ponto de vista do usuário.
74
Cada modelo de avaliação deve ser elaborado conforme o objetivo de análise
que se deseja obter com ele, observando-se também se esta avaliação deve ser
mais abrangente ou mais específica. Por exemplo, se o software utiliza recursos
multimídia e se deseja conhecer a apreciação dos alunos quanto a isso, basta criar
uma ou mais questões para que estes itens sejam pontuados, independentemente
de se relacionarem com as subcaracterísticas da Norma ou não (como é o caso do
subitem “Software comercial”, sem nenhuma relação com a Norma). Se houver
necessidade de se alterar o modelo de avaliação da Tabela 8, as alterações
correspondentes devem ser feitas nas Tabelas 9, 10 e 11, a serem apresentadas a
seguir. Ainda nesse caso, se na elaboração do modelo de avaliação se identificar
alguma relação com as subcaracterísticas da Norma, evidentemente esta deve ser
considerada e a Tabela 11 deve ser atualizada quanto a isso, particularmente na
coluna “Subcaracterísticas da Norma que têm relação com o subitem avaliado pelos
alunos”.
Observe que não há, a princípio, qualquer indicação para os alunos de que
este questionário tenha relacionamento com as subcaracterísticas da Norma
voltadas à aplicação. Este relacionamento existe, foi considerado na elaboração
desta avaliação e será apresentado no tópico 4.2.5.
4.2.3 Aplicação de testes e a avaliação dos alunos
Esta etapa corresponde ao passo de medição do processo de avaliação
citado na Norma ISO 9126 para o ponto de vista dos alunos.
Para obter as avaliações dos alunos é necessário realizar testes de aplicação
deste software em sala de aula. Caso isso não seja possível, pois a avaliação será
feita para um software didático a ser adquirido, portanto, não sendo aplicado em sala
de aula em situação real de uso, o professor ou uma equipe adequada podem testá-
lo e avaliá-lo no lugar dos alunos.
Para o teste, a sala de aula deve estar preparada antecipadamente e o
75
professor deve determinar se nestes testes o software didático já deverá estar
instalado nos computadores ou se serão instalados pelos próprios alunos. Neste
trabalho, o software já se encontrava instalado para a imediata utilização dos alunos
ao início da aula.
É indicado ao professor que, inicialmente, faça uma explanação sobre o
software didático e que utilize um roteiro comum para que todos acompanhem a
forma de operar o software e o entendimento de como o assunto é tratado por este
software.
Também é importante que os alunos tenham realizado um exercício completo
sem o uso do software e que, nesta aula, o utilizem para trabalharem no mesmo
exercício e chegarem à mesma solução. Fazendo isso, os alunos já estarão a par do
assunto e do exercício, dando maior atenção à operação do software, à fixação do
assunto, aos ensinamentos adicionais e às simulações que o professor apresentar,
além de melhorar o rendimento da aula.
Ao final, um tempo desta aula deve ser destinado à aplicação da avaliação
dos alunos.
Os alunos devem ser orientados a manter em branco os itens que, no
entendimento deles, não foram vistos ou que não haveria como se avaliar naquele
momento. Além disso, eles também devem ser informados que não precisam se
identificar, favorecendo, assim, que as avaliações sejam imparciais.
O modelo de avaliação da aplicação de um software didático (Tabela 8), deve
ser entregue a cada aluno para a sua avaliação em sala de aula.
Terminados os testes e com todas as avaliações em mãos, inclusive as de
outras turmas onde os testes foram realizados, o professor deve agrupá-las para dar
seqüência ao próximo passo.
76
4.2.4 Cálculo das médias das avaliações dos alunos
Esta etapa dá continuidade ao passo de medição do processo de avaliação
citado na Norma ISO 9126 para o ponto de vista dos alunos.
Com um grupo de avaliações em mãos, há a necessidade de se calcular a
média das avaliações em cada subitem e, conseqüentemente, a média final de cada
item.
Na Tabela 9 devem ser totalizadas as quantidades de pontos atribuídos pelos
alunos por tipo de apreciação a cada subitem (Insuficiente, Regular, Bom e
Excelente), e na coluna “TOTAL”, a soma total destes pontos atribuídos a cada
subitem. Apenas os subitens pontuados devem ser contados e considerados. Assim,
pode ocorrer que um ou mais subitens não totalizem a quantidade de avaliações
distribuídas, justamente por falta da avaliação de alguns subitens por parte dos
alunos.
Tabela 9 Modelo para totalizar os pontos avaliados pelos alunos
Item Subitem Insuficiente
Regular Bom Excelente TOTAL
Apresentação
Operação
Facilidade de uso
Telas
Cadastros
Gráficos
Relatórios
Visualização
Ajuda (help)
Visão do assunto
Aprendizado
Exemplos
Complemento
ao curso
Aplicação prática
Software didático
Avaliação
geral
Software comercial
Fonte: Autor
77
Na Tabela 10, devem ser preenchidas as médias ponderadas de cada
subitem na coluna “média final”. Para tanto, os subitens avaliados pelos níveis de
pontuação: Insuficiente, Regular, Bom e Excelente, devem receber respectivamente
os pesos 1, 2, 3 e 4, portanto, multiplicando-se a quantidade de pontos aplicados a
cada subitem (colunas Insuficiente, Regular, Bom e Excelente da Tabela 9) pelos
pesos de cada nível de pontuação (respectivamente 1, 2, 3 e 4). Em seguida, deve-
se somar estes resultados e dividi-los pela quantidade total de pontuações dos
respectivos subitens (coluna TOTAL da Tabela 9). A Tabela 10 deve ser preenchida
com estas médias calculadas para cada subitem. A média de cada item é a média
simples das médias de seus subitens correspondentes. Para obtê-las, soma-se
todas as médias de seus respectivos subitens e divide-se pelo número de seus
subitens que foram pontuados. Na coluna “item” (Tabela 10) no campo de cada item,
há a indicação para colocar o valor de média obtido.
Tabela 10 Média final das avaliações da aplicação de um software didático
Item Subitem Média final
Apresentação
Operação
Média ____
Facilidade de uso
Telas
Cadastros
Gráficos
Relatórios
Visualização
Média ____
Ajuda (help)
Visão do assunto
Aprendizado
Exemplos
Complemento
ao curso
Média ____
Aplicação prática
Software didático
Avaliação
geral
Software comercial
Aplicação do Software
Média Final ____
Fonte: Autor
A média final da aplicação do software é a média simples das médias dos
itens. Por exemplo, se os itens “Operação”, “Visualização” e “Complemento ao
78
Curso” receberem respectivamente as médias 2, 3 e 2,5, a média final da aplicação
do software é: (2 + 3 + 2,5) / 3 = 2,5.
É importante ressaltar que esta avaliação é específica da aplicação do
software didático em sala de aula, com o modelo de avaliação desenvolvido pelo
professor, ou seja, neste ponto não há qualquer relação aparente com a Norma ISO
9126. Assim, apenas os valores das médias finais obtidas para os subitens serão
considerados na seqüência desta metodologia de avaliação, como será apresentado
no tópico 4.2.5, para a obtenção das pontuações da aplicação. As médias dos itens
e a média final da aplicação do software não são utilizadas além deste ponto nesta
metodologia de avaliação; no entanto, servem para indicar os itens de menores
médias, que contêm os respectivos subitens que causaram essas mesmas médias,
a fim de analisá-los; como também, a média final da aplicação neste ponto da
avaliação para análise.
Para que qualquer item analisado do software e inclusive o próprio software
possa ser considerado como adequado ou inadequado, um valor de referência deve
ser adotado pelo professor. Este valor de referência é como um valor “mínimo para
aceitação” e não deve ser adotado como uma nota de corte, pois ainda que o
software não atinja o valor desejado em sua pontuação final, esta pontuação pode
estar bem próxima do valor de referência e na região indicada como Satisfatório,
segundo a Norma (Figura 6). Na prática, este software pode vir a ser aceito, com a
ressalva das melhorias necessárias para uma nova versão. De outro modo, este
valor de referência reflete o nível de exigência desejado para a qualidade de um
software didático e de todos os seus itens avaliados. Para a determinação desse
valor de referência, a Figura 6 foi tomada como base e uma escala para a métrica foi
adotada pelo autor, com intervalo de medição variando de 0,25 em 0,25 pontos,
iniciando em 1 e terminando em 4 (de Insuficiente a Excelente), como pode ser visto
na Figura 7, além de um exemplo de valor de referência adotado por um professor,
que nesse caso é o valor 3 (três).
Os níveis de pontuação da Norma ficam desta forma: Insuficiente para valores
de 1 a 1,74; Regular de 1,75 a 2,49; Bom de 2,5 a 3,24 e Excelente de 3,25 a 4.
Com a escala para a métrica definida dessa forma, obtém-se dentro de cada nível
79
de pontuação três faixas distintas, que servem como um subnível, indicando para
cada nível de pontuação: menos, médio ou mais (primeira, segunda e terceira faixa,
respectivamente, como apresentado na Figura 7). Por exemplo, a pontuação 1,85
aponta para o nível de pontuação Regular subnível menos (Regular menos), pois
está na primeira faixa do nível de pontuação Regular, que vai de 1,75 a 1,99. No
caso de ser 2,15, por estar na segunda faixa de seu nível de pontuação, pode-se
ignorar o subnível médio e considerar apenas o nível de pontuação como Regular,
ao invés de Regular médio. Com 2,35, na terceira faixa, seria Regular mais.
Figura 7 Escala para a métrica e exemplo de valor de referência
Fonte: Adaptado da Norma ISO 9126
A área superior destacada na Figura 7, a partir do valor de referência, aponta
para a região onde as pontuações obtidas indicam que o item avaliado é adequado,
enquanto que a região abaixo desta indica que o item avaliado é inadequado. Um
item avaliado como inadequado não indica necessariamente que este item não
funcione bem ou prejudique a aplicação do software; este item apenas não atingiu a
pontuação mínima desejada. Outro motivo pode estar na determinação dos
requisitos básicos, já que, apesar do software corresponder a situações atuais, pode
deixar de corresponder a estas em um futuro próximo. Se isso for estipulado nos
requisitos básicos, é certo que a pontuação desses itens serão menores do que se
só fossem consideradas as situações atuais. É o caso, por exemplo, da
subcaracterística adaptabilidade ser pontuada tecnicamente como inadequada,
apesar de atender o que está definido nos requisitos básicos do software, que seria
funcionar em apenas um determinado ambiente; no entanto, é bem provável que em
breve o software venha a ter a necessidade de funcionar em outro ambiente, e que
Insuficiente
Regular
Insatisfatório
Excelente
Bom
Satisfatório
4,00
1,75
2,50
3,25
Escala para a métrica
Níveis de Pontuação
Adeq
uado
Inadequado
Valor de
Referência: 3,00
1,00
Faixas
:
menos, médio, mais
+
-
Intervalo
:
de 0,25 em 0,25 pontos
80
isto seja estipulado nos requisitos básicos desse software. Assim, a adequação ou
inadequação resultante dependerá de como os requisitos básicos serão
determinados, ou seja, se serão contemplados cenários futuros, externos ou outros.
Uma aplicação para o valor de referência é a análise individual de cada item
avaliado, incluindo as características e subcaracterísticas, o software para cada
ponto de vista e o software didático como um todo, da seguinte forma: os valores
das médias e pontuações obtidos podem ser usados para priorizar melhorias, ou
seja, ordenando estas médias e pontuações em ordem crescente de valor, os itens
que apresentem os menores valores serão os primeiros a serem analisados, e assim
por diante, até que todos os itens que necessitem de melhorias ou ações corretivas
sejam analisados. Os demais itens com valores iguais ou superiores ao valor de
referência, que estão dentro do nível de pontuação desejado e, a princípio, não
necessitam de uma atenção maior, podem ser analisados para que atinjam um nível
de pontuação ainda maior, objetivando a melhoria contínua do software.
Com a Tabela 10 preenchida com as médias, segue-se para o próximo passo.
4.2.5 Relacionando a avaliação dos alunos com a Norma
Esta etapa dá continuidade ao passo de medição do processo de avaliação
citado na Norma ISO 9126, para o ponto de vista dos alunos.
O modelo da Tabela 11 deve receber as médias finais apuradas na Tabela
10, portanto, estas devem ser transportadas diretamente para a coluna “Média das
avaliações” respectivamente para os seus subitens. A coluna “Subcaracterísticas da
Norma que têm relação com o subitem avaliado pelos alunos” faz a relação direta
das médias finais dos subitens avaliados pelos alunos com as subcaracterísticas da
Norma que têm relação a cada subitem. Cada item pode receber a média simples
das médias das avaliações de seus subitens. Apesar desses valores de média não
serem utilizados nessa metodologia de avaliação, esses mesmos valores podem ser
verificados pelo professor para a finalidade de análise, no caso da avaliação da
aplicação apresentar pontuação abaixo do valor de referência.
81
Tabela 11 Modelo para a média das avaliações com referência à Norma
Item Subitem
Média das
avaliações
Subcaracterísticas da Norma que têm relação
com o subitem avaliado pelos alunos
Apresentação S.1.1 Adequação, S.3.3 Operacionalidade
Operação
Facilidade
de uso
S.3.3 Operacionalidade
Telas
S.1.1 Adequação, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade
Cadastros
S.1.1 Adequação, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.3 Operacionalidade
Gráficos
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade
Relatórios
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade
Visualização
Ajuda (help) S.1.1 Adequação, S.3.2 Apreensibilidade
Visão do
assunto
S.1.4 Conformidade, S.3.1 Inteligibilidade,
S.3.2 Apreensibilidade
Aprendizado S.3.1 Inteligibilidade
Exemplos
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade,
S.3.3 Operacionalidade
Complemento
ao curso
Aplicação
prática
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade,
S.3.3 Operacionalidade
Software
didático
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade,
S.3.3 Operacionalidade
Avaliação
Geral
Software
comercial
“Sem efeito”
Fonte: Autor
Para o caso de se incluir ou alterar subitens no modelo de avaliação dos
alunos (Tabela 8), essa relação da tabela 11 necessita ser revisada, pelo menos
para estes itens novos ou alterados. A idéia é que os alunos, ao avaliarem as
questões deste modelo (Tabela 8), indiretamente, sem saber, estarão pontuando
todas as subcaracterísticas da Norma voltadas à aplicação de um software didático
pelo ponto de vista dos alunos. Apenas as subcaracterísticas voltadas à avaliação
da aplicação pelo ponto de vista dos alunos (Tabela 8) foram consideradas para
82
essa relação com a Norma, por se tratar de uma avaliação voltada à aplicação do
software.
Quanto a essa relação, dos subitens com as subcaracterísticas da Norma, o
autor analisou cada subitem e os relacionou com as subcaracterísticas da Norma a
que a avaliação deste subitem remeteria (Tabela 11). Neste caso, mais de um
subitem pode apontar para uma mesma subcaracterística. Para a definição deste
relacionamento, o autor apresenta na Tabela 12 as referências utilizadas, onde,
através da análise destas referências para cada subitem, o autor apontou as
subcaracterísticas que têm relação a cada um deles.
Tabela 12 Referências para a definição de relacionamento entre os subitens avaliados e as
subcaracterísticas da Norma.
Subcaracterísticas voltadas à aplicação Foco Considerando
S.1.1
Adequação: O software atende e é apropriado para as
tarefas especificadas?
Software
Didático
Se contém as funções
para executar o que
é preciso
S.1.2
Acurácia: O software gera resultados corretamente,
efeitos ou conforme o acordado?
Software
Didático
Se resulta no que se
espera de acordo com
resultados conhecidos
S.1.4
Conformidade: O software está de acordo com as
normas, convenções ou regulamentações previstas em
leis e descrições similares, relacionadas à aplicação?
Software
Didático
Se está de acordo com
conceitos relacionados
ao tema da aplicação
S.3.1
Inteligibilidade: O usuário reconhece com facilidade
no software o conceito lógico e sua aplicabilidade?
Usuário
(aluno)
Se o aluno reconhece
o conceito lógico e
sua aplicabilidade
S.3.2
Apreensibilidade: O usuário aprende com facilidade a
aplicação do software?
Usuário
(aluno)
Se o aluno aprende
com facilidade a
aplicação do software
S.3.3
Operacionalidade: O usuário opera e controla cada
operação do software com facilidade?
Usuário
(aluno)
Se é fácil para o aluno
operar e controlar cada
operação do software
Fonte: Autor
Com a Tabela 11 preenchida, é dada a seqüência para o próximo passo.
83
4.2.6 Pontuação das avaliações essencialmente técnica e da aplicação
Esta etapa corresponde ao passo de pontuação do processo de avaliação
citado na Norma ISO 9126, para os pontos de vista da equipe de desenvolvimento e
dos alunos.
As médias das avaliações apontadas por subitem na Tabela 11 devem ser
consideradas para cada subcaracterística relacionada a este subitem, ou seja, nesta
mesma tabela deve-se pegar o valor de cada média calculada para cada subitem
(coluna “Média das Avaliações”), e somar este valor de média uma vez para cada
subcaracterística apontada na coluna ao lado (coluna “Subcaracterísticas da Norma
que têm relação com o subitem avaliado pelos alunos”). Assim, cada
subcaracterística terá um valor acumulado das médias que recebeu de cada subitem
onde estava relacionada. Dividindo-se este valor acumulado pela quantidade de
médias que acumulou, obtém-se a média simples de cada subcaracterística. Estas
médias devem ser transportadas para as correspondentes subcaracterísticas na
Tabela 13, que são as pontuações das subcaracterísticas da aplicação do software
didático pelo ponto de vista dos alunos. Assim, na última coluna desta tabela, no
campo “Pontuação:” de cada uma dessas subcaracterísticas, deve ser colocado o
valor desta pontuação.
As subcaracterísticas essencialmente técnicas devem ser diretamente
pontuadas pela equipe de desenvolvimento na Tabela 13 (ponto de vista da equipe
de desenvolvimento segundo a Norma ISO 9126), pontuando conforme entenderem
ser mais adequado para cada subcaracterística que avaliarem, dentro do critério de
valores 1, 2, 3, 4 ou “NA”, respectivamente, Insuficiente, Regular, Bom, Excelente ou
Não se Aplica. O apontamento “Não se Aplica” (NA), é para o caso de ocorrer, por
qualquer motivo, que alguma subcaracterística não precise ser avaliada, ou ainda,
que seja indiferente esta avaliação para ela. É importante ressaltar que, mesmo
sendo indiferente avaliar alguma subcaracterística em um primeiro momento, no
futuro ela pode vir a ser necessária; como, por exemplo, se a utilização do software
didático tornar-se incompatível para um novo ambiente que venha a ser solicitado.
Assim, é razoável que haja a preocupação em se avaliar as questões mais
84
prováveis, visando a necessidades futuras, uma vez que a evolução de hardware e
de software é constante.
As características devem receber a média simples de suas subcaracterísticas
pontuadas (Tabela 13), completando assim o preenchimento de toda a Norma com
as respectivas pontuações, contendo a avaliação da equipe de desenvolvimento e a
dos alunos.
85
Tabela 13 Modelo para avaliação da qualidade de um software didático pelos pontos de vista da
equipe de desenvolvimento e dos alunos, com base na Norma ISO 9126
Características e Subcaracterísticas
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA
= Não se Aplica
C.1 Funcionalidade Pontuação:
S.1.1
Adequação:
O software atende e é apropriado para as tarefas especificadas?
Pontuação:
S.1.2
Acurácia:
O software gera resultados corretamente, efeitos ou conforme o acordado?
Pontuação:
1 2 3 4 NA
S.1.3
Interoperabilidade:
O software interage com sistemas especificados?
S.1.4
Conformidade: O software está de acordo com as normas, convenções ou
regulamentações previstas em leis e descrições similares, relacionadas à
aplicação?
Pontuação:
1 2 3 4 NA
S.1.5
Segurança de acesso
O software evita acesso não autorizado, acidental ou deliberado a programas e
dados?
C.2 Confiabilidade Pontuação:
1 2 3 4 NA
S.2.1
Maturidade:
Qual a freqüência de falhas por defeitos que o software apresenta?
1 2 3 4 NA
S.2.2
Tolerância a falhas: O software mantém um nível de desempenho especificado
nos casos de falhas no software ou de violação nas interfaces especificadas?
1 2 3 4 NA
S.2.3
Recuperabilidade: O software restabelece seu nível de desempenho em caso de
falha e recupera os dados diretamente afetados, em que tempo e esforço?
C.3 Usabilidade Pontuação:
S.3.1
Inteligibilidade
O usuário reconhece com facilidade no software o conceito lógico e sua
aplicabilidade?
Pontuação:
S.3.2
Apreensibilidade
O usuário aprende com facilidade a aplicação do software?
Pontuação:
S.3.3
Operacionalidade
O usuário opera e controla cada operação do software com facilidade?
Pontuação:
C.4 Eficiência Pontuação:
1 2 3 4 NA
S.4.1
Comportamento em relação ao tempo: É satisfatório o tempo de resposta do
software, o tempo de processamento e velocidade na execução de suas funções?
1 2 3 4 NA
S.4.2
Comportamento em relação aos recursos: É satisfatória a quantidade de
recursos usados pelo software e a duração de seu uso na execução de suas
funções?
86
C.5 Manutenibilidade Pontuação:
1 2 3 4 NA
S.5.1
Analisabilidade: É fácil de diagnosticar deficiências ou causas de falhas, ou para
identificar partes a serem modificadas no software?
1 2 3 4 NA
S.5.2
Modificabilidade: É fácil de modificar o software, remover seus defeitos ou
adaptá-lo a mudanças ambientais?
1 2 3 4 NA
S.5.3
Estabilidade
É baixo o risco de efeitos inesperados ocasionados por modificações no software?
1 2 3 4 NA
S.5.4
Testabilidade
É fácil de se validar o software modificado?
C.6 Portabilidade Pontuação:
1 2 3 4 NA
S.6.1
Adaptabilidade: O software é facilmente adaptado a ambientes diferentes
especificados, sem a necessidade de aplicação de outras ações ou meios além
daqueles fornecidos para essa finalidade pelo software considerado?
1 2 3 4 NA
S.6.2
Capacidade para ser instalado:
É fácil de se instalar o software num ambiente especificado?
1 2 3 4 NA
S.6.3
Conformidade:
O software está consonante aos padrões ou convenções relacionados à
portabilidade?
1 2 3 4 NA
S.6.4
Capacidade para substituir: O software facilmente substitui outro software, no
ambiente estabelecido por esse outro software?
Pontuação Final do Software Didático – Avaliação da Aplicação
(Média Simples das Subcaracterísticas Voltadas à Aplicação que foram Pontuadas)
Pontuação
da Aplicação
Pontuação Final do Software Didático – Avaliação Técnica
(Média Ponderada das Subcaracterísticas Voltadas à parte Técnica que foram Pontuadas)
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
Qtde
Total de
Pontos:
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação
Técnica
Pontuação Final do Software Didático – Avaliação do Produto de Software
(Média Simples das Pontuações da Aplicação e Técnica)
Pontuação
Produto de
Software
Fonte: Autor
Após as pontuações estarem lançadas, será preciso calcular a pontuação da
aplicação (resultante da avaliação feita pelos alunos), a pontuação técnica
(resultante da avaliação da equipe de desenvolvimento) e a pontuação do software
didático como produto de software (considerando os dois pontos de vista anteriores).
87
Para tanto, existem as indicações nos quadros no final da Tabela 13 que são
destinados a isso.
Para o cálculo da pontuação da aplicação, basta calcular a média simples das
subcaracterísticas voltadas à aplicação que foram pontuadas, e colocar o resultado
no campo “Pontuação da Aplicação”.
Para o cálculo da pontuação técnica, devem ser consideradas apenas as
subcaracterísticas essencialmente técnicas que foram pontuadas. O quadro para o
cálculo da pontuação técnica é mais complexo, pois se trata de uma pontuação que
utiliza média ponderada. Nesse quadro há espaços (campos) para serem
preenchidos com as quantidades referentes às pontuações realizadas para as
subcaracterísticas essencialmente técnicas, e para registrar os valores parciais dos
cálculos até que se chegue na pontuação final. Para os cálculos após a pontuação
de todos os itens de cada subcaracterística essencialmente técnica pela equipe de
desenvolvimento, a seguinte seqüência deve ser executada:
• Para cada subcaracterística essencialmente técnica, soma-se a
quantidade de seus respectivos itens que receberam pontuação com
os valores de 1, 2, 3 ou 4. Os itens que foram pontuados com “NA”
(não se aplica) ou se porventura ficaram sem pontuação, não devem
constar dessa soma. Esta soma deve ser lançada no espaço apontado
como “Quantidade de Itens Pontuados”.
• Após isto, há a indicação para se apontar a quantidade total de pontos
(campo “Qtde Total de Pontos”) e os espaços devem ser preenchidos
com as quantidades de pontuações realizadas para os valores 1, 2, 3 e
4 (Insuficiente, Regular, Bom e Excelente) individualmente, cada um
em sua respectiva coluna. Para uma simples conferência, a soma das
quantidades de cada um deve dar a mesma quantidade total apontada
no campo “Qtde de Itens Pontuados”.
• Na seqüência, no espaço do “Somatório Pontos x Peso”, deve-se
multiplicar a quantidade de pontuações de cada valor de pontuação ao
seu respectivo peso, e estes valores devem ser somados. Se, por
exemplo, as pontuações ocorressem da seguinte forma: 2 como
88
Insuficiente (valor 1 à Peso 1), 4 como Regular (valor 2 à Peso 2), 5
como Bom (valor 3 à Peso 3) e 1 como Excelente (valor 4 à Peso 4),
o cálculo seria este: 2 x 1 + 4 x 2 + 5 x 3 + 1 x 4 = 29.
• Continuando, o espaço “Somatório Pontos x Peso / Qtde de Itens
Pontuados”, nada mais é que o cálculo da média ponderada das
pontuações. Portanto, o valor obtido no campo “Somatório Pontos x
Peso” deve ser dividido pela quantidade de pontuações que está no
campo “Qtde de Itens Pontuados”. Continuando o exemplo anterior,
bastaria fazer a seguinte conta: 29 / 12 = 2,42. O resultado da soma
dividido pela quantidade de itens. Este seria o valor da pontuação
técnica. Por fim, basta apontá-lo no espaço da coluna final “Pontuação
Técnica:”, que indica para o software avaliado a pontuação técnica de
2,42 pelo ponto de vista da equipe de desenvolvimento, respectivo ao
nível de pontuação Regular mais (Figura 7).
A pontuação do software didático como produto de software é obtida pela
média simples das pontuações da aplicação e técnica. Essa pontuação não é a
pontuação final do software didático, pois falta considerar a avaliação didática, ou
seja, a avaliação pelo de vista do professor (Tabela 15).
As pontuações obtidas para cada subcaracterística na Tabela 13 devem ser
transportadas para a Tabela 14, no campo “Pont.” (abreviação de pontuação), assim
como as pontuações das características, que devem ser colocadas abaixo de sua
descrição, dentro do espaço correspondente.
É importante que o professor junto com a equipe de desenvolvimento faça
anotações que justifiquem todas as pontuações aplicadas a cada subcaracterística
em relação ao que se pede nos requisitos básicos do software. Estas podem ser
detalhadas, em especial para a equipe técnica, e podem apresentar uma
observação sucinta que aponte de modo geral o que se apurou, pois o professor não
necessariamente tem conhecimentos de informática a nível técnico e o mesmo se dá
com outras pessoas ou grupos que venham a discutir sobre os resultados da
avaliação do software. A idéia é que a equipe de desenvolvimento guarde para ela
89
as observações detalhadas (faz parte de seu serviço), e as observações sucintas
sejam descritas no campo “Observações sobre o software” da Tabela 14.
Tabela 14 Avaliação dos requisitos básicos de qualidade de um software didático pelos pontos de
vista da equipe de desenvolvimento e dos alunos, com base na Norma ISO 9126
Característica Item Subcaracterística Pont. Observações sobre o software
S.1.1
Adequação
S.1.2
Acurácia
S.1.3
Interoperabilidade
S.1.4
Conformidade
C.1
Funcionalidade
Pontuação: ____
S.1.5
Segurança de acesso
S.2.1
Maturidade
S.2.2
Tolerância a falhas
C.2
Confiabilidade
Pontuação: ____
S.2.3
Recuperabilidade
S.3.1
Inteligibilidade
S.3.2
Apreensibilidade
C.3
Usabilidade
Pontuação: ____
S.3.3
Operacionalidade
S.4.1
Comp. em relação ao tempo
C.4
Eficiência
Pontuação: ____
S.4.2
Comp. em rel. aos recursos
S.5.1
Analisabilidade
S.5.2
Modificabilidade
S.5.3
Estabilidade
C.5
Manutenibilidade
Pontuação: ____
S.5.4
Testabilidade
S.6.1
Adaptabilidade
S.6.2
Capacidade para ser instalado
S.6.3
Conformidade
C.6
Portabilidade
Pontuação: ____
S.6.4
Capacidade para substituir
Produto de
software
____
Fonte: Autor
Estas observações apontadas na Tabela 14, indicarão de forma sucinta qual o
problema encontrado em uma subcaracterística ou o porquê de ela estar de acordo
com os requisitos básicos. O nível de detalhamento obtido até aqui com todas as
90
informações e análises já feitas, irá contribuir muito quando for preciso verificar
especificamente problemas, condições de melhoria no software e onde é preciso
tomar providências e como, quanto ao desenvolvimento do software para a sua
aplicação em sala de aula.
As pontuações apresentadas por característica mesclam a avaliação técnica
com a da aplicação e não compreendem a avaliação didática. Essas médias das
características são válidas, porém, somente para a avaliação de um software
didático como produto de software e, também, para serem consideradas em uma
análise mais específica do mesmo. Não é separada aqui a média das características
conforme o ponto de vista, o que será feito na Tabela 16. Além disso, falta o ponto
de vista didático e, por conseqüência, a pontuação final do software didático
considerando os três pontos de vista.
Com esses resultados, tem-se a avaliação final da qualidade de um software
didático pelas questões essencialmente técnicas e pelas questões da aplicação em
sala de aula, ou seja, a avaliação de um produto de software. No entanto, essa
avaliação não está totalmente individualizada por ponto de vista, que é o caso de
algumas características como “Funcionalidade”, onde há subcaracterísticas da
aplicação e técnicas. Além da pontuação distinta por ponto de vista (Tabela 16),
resta a avaliação didática desse software, que é apresentada a seguir.
4.2.7 Avaliação e pontuação pelo ponto de vista didático
Esta etapa dá continuidade aos processos de medição e pontuação citadas
na Norma ISO 9126, para o ponto de vista do professor.
A tabela de avaliação didática pelo ponto de vista do professor para um
software didático (Tabela 15), foi definida pelo autor de modo a abranger as
questões didáticas a serem avaliadas para este software.
Para a definição desta tabela em forma de um questionário didático, que
dispusesse as questões didáticas de um software, o autor agrupou vários
91
apontamentos dos autores citados neste trabalho no capítulo 2 e os adaptou em
questões, para servirem de referência para uma avaliação didática, como também,
elaborou suas próprias questões onde entendeu ser necessário.
Cabe ao professor, pontuar cada questão na Tabela 15. Além das
pontuações: 1, 2, 3 e 4, respectivamente, Insuficiente, Regular, Bom e Excelente, há
um campo intitulado “NA”, que significa “não se aplica”, para o caso de a questão a
ser avaliada não corresponder às necessidades de avaliação do professor ou, ainda,
não ter como ser avaliada para o software didático naquele momento.
92
Tabela 15 Modelo para avaliação didática de um software didático pela visão do professor, com base
na Norma ISO 9126
Subcaracterísticas voltadas à aplicação do software didático
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.1.1. Adequação
1 2 3 4
N
A
1
Auxilia o processo de ensino-aprendizagem
2
Faz a ligação entre a teoria e a prática de forma adequada
3
Apresenta uma seqüência de forma racional e eficiente
4
É adequado quanto aos dados da matéria e ao assunto da aula
5
Favorece o ensino baseado na observação e experimentação
6
É atualizado quanto ao estado da arte
7
Faz a ligação de conhecimentos científicos e a realidade do dia-a-dia do aluno
8
Permite ao aluno entrar em contato com situações concretas de sua vida fora da
escola
9
Diminui as dificuldades dos alunos e abre novas perspectivas culturais
10
Possibilita atividades que direcionem o aluno à compreensão e assimilação da
matéria
11
Permite a aplicação adequada para exercícios do tipo “estudo de caso”
12
Prepara adequadamente o aluno para o mercado de trabalho
13
Prepara adequadamente o aluno como cidadão
14
Faz parte adequadamente das estratégias adotadas pelo professor
15
É adequado à capacidade e limitações reais dos alunos (estabelece exigências e
expectativas que os alunos possam cumprir)
16
Promove o interesse geral estimulando o aprendizado
17
Desperta e mantém a atenção
18
Incentiva o aluno a perguntar e apresentar questões que o envolvam
19
É desafiador, suscitando e mobilizando a atividade do aluno
20
Serve de ferramenta de apoio a exercícios, a esclarecimentos gerais e à fixação
do assunto
21
Inicia concretamente o estudo de uma unidade que envolva determinadas
operações ou processos a serem aprendidos
22
Funciona como recurso de transposição do tema do plano verbal e simbólico para
o plano real, da palavra para a realidade da ação
23
Apresenta todas as informações necessárias de forma adequada
24
Possibilita inclusões, alterações e exclusões de dados de forma adequada
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
Qtde
Total
de
Pontos:
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação:
93
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.1.2. Acurácia
1 2 3 4
N
A
1
Está de acordo com os objetivos de ensino adotados
2
Serve de forma eficaz aos objetivos da aula
3
Realiza satisfatoriamente os procedimentos de demonstração, organização e
aplicação de testes objetivos
4
Permite a análise dos resultados de forma adequada
5
Permite ao professor uma flexibilidade tal, de modo a explorá-lo de diversas
formas, realística e criativamente, segundo seus objetivos
6
Atinge os objetivos almejados de maneira segura, econômica e eficiente
7
Suplementa a palestra ou explanação verbal do professor, tornando-a mais real e
concreta
8
Proporciona a recapitulação e comprovação dos conhecimentos teóricos já
adquiridos
9
Os exercícios aplicados apresentam os resultados esperados com exatidão
10
Apresenta a modelagem de forma correta
11
A apresentação da impressão de dados e relatórios estão corretos
12
Possibilita a verificação parcial ou gradativa das informações
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
Qtde
Total
de
Pontos:
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação:
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.1.4. Conformidade
1 2 3 4
N
A
1
Está de acordo com as normas, convenções ou regulamentações previstas em
leis e descrições similares, relacionadas à aplicação
2
Fornece o modelo e as normas concretas da ação a executar
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
Qtde
Total
de
Pontos:
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação:
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.3.1. Inteligibilidade
1 2 3 4
N
A
1
Facilita a percepção e compreensão dos fatos e conceitos em estudo
2
Facilita a apreensão sugestiva e ativa de um tema ou de um fato em estudo
3
Ajuda a melhor compreender as relações das partes, o todo de um tema, objeto
ou fenômeno
4
Auxilia a formar conceitos exatos, principalmente com referência a temas de difícil
observação direta
94
5
Atende ao desenvolvimento das capacidades cognitivas dos alunos
6
Orienta com segurança os alunos para a compreensão e a assimilação
7
Permite ao aluno relacionar o que está aprendendo com os conhecimentos e
experiências que já possui
8
O conceito lógico e sua aplicabilidade são facilmente verificados
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
Qtde
Total
de
Pontos:
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação:
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.3.2. Apreensibilidade
1 2 3 4
N
A
1
Propicia a retenção do assunto de forma adequada
2
Propicia ao aluno o domínio de conhecimentos, habilidades e hábitos
3
Possibilita atividades que direcionem o aluno à compreensão e assimilação da
matéria
4
Possibilita ao professor estimular, orientar e facilitar o aprendizado dos alunos
5
Facilita o ensino do professor
6
Facilita o aprendizado do aluno
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
Qtde
Total
de
Pontos:
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação:
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.3.3. Operacionalidade
1 2 3 4
N
A
1
O usuário opera e controla cada operação do software com facilidade
2
O esforço do professor para aplicá-lo é adequado
3
O esforço do aluno em utilizá-lo é adequado
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
Qtde
Total
de
Pontos:
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação:
Pontuação Final do Software Didático – Avaliação Didática
(Média Simples de todas as Subcaracterísticas que foram Pontuadas)
Pontuação
Didática
Fonte: Autor
Após as pontuações estarem lançadas na Tabela 15, será preciso calcular a
pontuação didática final que o software obteve. Para tanto, existem as indicações
95
para cálculos em quadros ao final de cada grupo de subcaracterísticas, e o campo
“Pontuação Didática” no final da tabela, para se dar a pontuação da avaliação do
professor.
Para o cálculo final da pontuação didática do software, basta calcular a média
simples das pontuações das subcaracterísticas que foram pontuadas, e colocar o
resultado no campo “Pontuação Didática”.
Diante das avaliações apresentadas, pode surgir a seguinte dúvida: As
questões técnicas, porém usuais em software, como a utilização de recursos
multimídia, cores e a instalação do software, por exemplo, não deveriam estar
presentes para o professor avaliar em sala de aula, ou mesmo os alunos, inclusive
considerando as características e subcaracterísticas técnicas que as comportariam?
A princípio, sim. Mas por ser o ponto de vista do professor um ponto de vista
estratégico, e que nesse caso está relacionado a questões didáticas, não. De outro
modo, além do que já foi relatado sobre isso, pode-se considerar que:
• O professor participa diretamente na determinação dos requisitos
básicos do software, o que faz com que as questões técnicas como as
que foram colocadas façam parte destes requisitos, pois o professor
sabe que necessitará destes recursos.
• A sugestão é que os requisitos básicos sejam determinados junto com
a equipe de desenvolvimento, que por si só irá questionar o professor
sobre os recursos que este software deva contemplar ou não. Por
exemplo, as questões de segurança de acesso e de portabilidade para
outros ambientes.
• A avaliação técnica destes itens é suficiente, pois se os equipamentos
e ambientes em que o software será instalado e utilizado forem os que
estão especificados pela equipe técnica, sobram duas opções caso
ocorram problemas: a equipe de desenvolvimento não foi eficiente na
habilitação destes recursos para o software ou, por motivos mecânicos,
eletrônicos ou outros, a utilização destes recursos foi comprometida.
Neste último caso, não se trata de falha do software ou de sua
aplicação, e sim de cuidados preliminares que se deve ter no local
96
onde ele está sendo aplicado, como a manutenção correta e periódica
dos equipamentos.
Portanto, o autor entende que o professor, que é o mais envolvido em todo o
processo, pois determina os requisitos básicos (técnicos e da aplicação), desenvolve
o modelo de avaliação dos alunos para a aplicação em sala de aula, realiza a
avaliação didática e participa ou efetivamente faz o julgamento do software didático,
abrange com isso e tem em mãos toda e qualquer informação sobre o software
(desde que as tenha contemplado devidamente segundo seus objetivos).
Neste ponto, as três avaliações foram concluídas, a da equipe de
desenvolvimento, a dos alunos e a do professor. Passou-se então à pontuação geral
do software, considerando as avaliações pelos três pontos de vista.
Com a pontuação de cada subcaracterística pelos pontos de vista da equipe
de desenvolvimento, dos alunos e a do professor, falta calcular as pontuações finais
de vários itens e determinar o nível de pontuação obtido para o software didático
avaliado, como segue.
4.2.8 Pontuações finais e nível de pontuação
Esta etapa dá continuidade ao passo de pontuação do processo de avaliação
citado na Norma ISO 9126, para os três pontos de vista.
Para obter as pontuações finais do software didático avaliado, é preciso
transportar a pontuação de todas as subcaracterísticas pontuadas na Tabela 13
(ponto de vista da equipe de desenvolvimento e dos alunos), como também as
pontuações das subcaracterísticas da Tabela 15 (ponto de vista do professor) para a
Tabela 16. As pontuações das subcaracterísticas a serem transportadas para a
Tabela 16, devem ser lançadas nas colunas correspondentes aos pontos de vista
pelos quais receberam as pontuações. Assim, as pontuações das subcaracterísticas
da Tabela 13, serão lançadas para as mesmas subcaracterísticas na coluna
“Técnica” (para as subcaracterísticas essencialmente técnicas) ou na coluna
97
“Aplicação” (para as subcaracterísticas voltadas à aplicação), sendo que as
pontuações das subcaracterísticas pontuadas na Tabela 15, serão lançadas
respectivamente na coluna “Didática”.
Uma vez lançadas as pontuações para as subcaracterísticas na Tabela 16,
passa-se a realizar os “Cálculos para as Características”, onde cada característica
deve receber a média simples de suas respectivas subcaracterísticas, pontuadas por
ponto de vista.
Nos “Cálculos para os Pontos de Vista”, cada ponto de vista recebe a média
simples das suas respectivas características pontuadas.
E para o “Cálculo Final para o Software Didático”, este deve receber a média
simples dos três pontos de vista.
98
Tabela 16 Modelo de avaliação das pontuações finais de um software didático avaliado pelos três
pontos de vista com base na Norma ISO 9126.
Pontuação por Ponto de Vista
Característica Item Subcaracterística
Técnica Aplicação
Didática
S.1.1 Adequação
S.1.2 Acurácia
S.1.3 Interoperabilidade
S.1.4 Conformidade
C.1
Funcionalidade
S.1.5 Segurança de acesso
S.2.1 Maturidade
S.2.2 Tolerância a falhas
C.2
Confiabilidade
S.2.3 Recuperabilidade
S.3.1 Inteligibilidade
S.3.2 Apreensibilidade
C.3
Usabilidade
S.3.3 Operacionalidade
S.4.1 Comp. em relação ao tempo
C.4
Eficiência
S.4.2 Comp. em relação aos recursos
S.5.1 Analisabilidade
S.5.2 Modificabilidade
S.5.3 Estabilidade
C.5 Manutenibilidade
S.5.4 Testabilidade
S.6.1 Adaptabilidade
S.6.2 Capacidade para ser instalado
S.6.3 Conformidade
C.6
Portabilidade
S.6.4 Capacidade para substituir
Ponto de Vista
Cálculos para as
Características
Item Característica
Técnica Aplicação
Didática
C.1 Funcionalidade
C.2 Confiabilidade
C.3 Usabilidade
C.4 Eficiência
C.5 Manutenibilidade
Médias das
Pontuações por
Característica e por
Ponto de Vista
C.6 Portabilidade
Ponto de Vista
Cálculos para os Pontos de Vista
Técnica Aplicação
Didática
Pontuações Finais por Ponto de Vista
Cálculo Final para o Software Didático
Software Didático
Pontuação Final do Software Didático Avaliado
Fonte: Autor
99
Uma vez obtidas todas as pontuações de um software didático através da
Tabela 16, passa-se ao julgamento, como segue.
4.2.9 Julgamento das avaliações
Esta etapa corresponde ao passo de julgamento do processo de avaliação
citado na Norma ISO 9126.
O julgamento determinará a rejeição ou a aceitação do software didático e
sua continuidade ou descontinuidade de uso em sala de aula; no entanto, a análise
dos dados obtidos nas avaliações pode indicar as melhorias e correções
necessárias para este software, caso ele seja aceito mesmo com ajustes a serem
feitos. De outra forma, se rejeitado, estes apontamentos indicarão onde concentrar
os esforços para que o software possa vir a ser aceito em uma nova avaliação, se
for o caso.
Somente os valores apontados na Tabela 16 servirão de base para o
julgamento. Aqui cabe um esclarecimento, pois, com tantas avaliações, tabelas e
resultados apurados até se chegar à Tabela 16, poder-se-ia considerar que apenas
a sua avaliação não fosse suficiente para um julgamento. Esta tabela, porém,
apresenta uma visão geral, mas completa, daquilo que é essencial para se avaliar a
qualidade de um software didático, ou seja, a pontuação final de todas as
características e subcaracterísticas para cada ponto de vista, do software didático
para cada um dos pontos de vista e do software didático como um todo.
Além disso, ao se obter pontuações abaixo do valor de referência em alguns
itens da Tabela 16, pode-se analisar as respectivas avaliações desses itens
constantes das tabelas anteriores, a fim de se verificar, em detalhes, qual ou quais
foram as causas mais prováveis e o que poderia ser feito. Se forem obtidas
pontuações iguais ou acima do valor de referência, pode-se fazer o mesmo no
sentido de buscar um aumento de pontuação, visando à melhoria destes itens. De
outro modo, durante a aplicação da metodologia de avaliação, todos estes itens já
100
estarão destacados pelo próprio processo descrito até agora. Portanto, a Tabela 16
é suficiente para o julgamento, ou seja, para se aceitar ou rejeitar o software didático
avaliado.
O autor definiu cinco etapas para o julgamento de um software didático, que
compreendem quatro análises de apoio para o julgamento – da análise mais geral à
análise mais específica – e o julgamento final, conforme é apresentado:
1. Análise da pontuação de um software didático como um todo. Na
Tabela 16, o item “Pontuação Final do Software Didático Avaliado”
aponta para a pontuação obtida pelo software didático. Se a pontuação
do software didático for igual ou superior ao valor de referência definido
pelo professor, o software didático poderá ser aceito ou continuado seu
uso; senão, poderá ser rejeitado ou descontinuado seu uso. Para a
decisão final de aceitar ou rejeitar um software didático, é preciso
considerar também outras pontuações que são referenciadas nos itens
seguintes (2, 3 e 4), que podem contribuir para a decisão de aceitação
ou de rejeição deste software (item 5). Além das pontuações, há
questões externas a serem consideradas, como: custos, recursos
humanos e prazos (conforme cita a Norma ISO 9126); mas também há
questões quanto à qualidade no atendimento às solicitações de
alterações no software, no atendimento de chamadas urgentes e de
limitações contratuais, por exemplo, entre outras que podem levar à
decisão de se rejeitar um software, ainda que pela pontuação obtida
este software pudesse ser aceito. Pela pontuação recebida, obtém-se o
nível de pontuação do software didático (Figura 7), que também pode
auxiliar no julgamento.
2. Análise das pontuações de cada avaliação de um software
didático por ponto de vista. Na Tabela 16, no item “Pontuações
Finais por Ponto de Vista”, está calculada a pontuação obtida para
cada ponto de vista (técnica, aplicação e didática). Uma vez obtidas as
pontuações para cada ponto de vista, basta compará-las com o valor
de referência. Os pontos de vista que tenham sua pontuação final
101
iguais ou superiores a este valor podem ser considerados como
adequados, enquanto que os que estiverem abaixo, inadequados.
Porém, pode ocorrer de um ou dois pontos de vista estarem abaixo do
valor de referência, enquanto que o software didático pode vir a ser
“aceito” pela sua pontuação obtida. Neste caso, se aceito, é importante
considerar as correções e melhorias necessárias que devem ser feitas,
de forma a elevar os níveis de pontuação destes pontos de vista, pelo
menos até atingirem o valor de referência em uma próxima versão do
software. O nível de pontuação de cada ponto de vista também pode
auxiliar no julgamento.
3. Análise das características de um software didático por ponto de
vista. Na Tabela 16, no item “Médias das Pontuações por
Característica e por Ponto de Vista”, estão calculadas as pontuações
finais de cada característica para cada ponto de vista (itens de “C.1” a
“C.6”). As características que apresentem pontuações abaixo do valor
de referência em determinados pontos de vista devem ser observadas
em especial, pois podem ser responsáveis pela baixa pontuação do
ponto de vista a que pertencem. Conseqüentemente, também podem
estar resultando na redução da pontuação final do software didático
avaliado.
4. Análise das subcaracterísticas de um software didático por ponto
de vista. Na Tabela 16, nos itens de “S.1.1” a “S.6.4”, que apontam
suas respectivas subcaracterísticas, estão lançadas as pontuações
finais de cada uma para cada ponto de vista. As subcaracterísticas que
apresentem pontuações abaixo do valor de referência devem ser
analisadas, visando à sua melhoria, correção ou adequação; inclusive,
por esta pontuação indicar um possível problema ou inadequação. Este
nível de análise permite a identificação de problemas ou necessidades
de estudos específicos nestas subcaracterísticas. O autor sugere que
as subcaracterísticas sejam ordenadas em ordem crescente de valor,
de forma que as subcaracterísticas com as menores pontuações sejam
analisadas primeiramente. No aprofundamento desta análise, a coluna
102
“Observações para o software” da Tabela 14 pode ser utilizada; ou,
mais detalhadamente, os comentários feitos anteriormente a esta
tabela quanto aos requisitos básicos avaliados junto com a equipe de
desenvolvimento.
5. Julgamento de um software didático. Considerando as pontuações
atingidas pelo software didático avaliado, as pontuações das
avaliações de cada ponto de vista, as pontuações das características
para cada ponto de vista e, também, as pontuações das
subcaracterísticas para cada ponto de vista (Tabela 16), e, além disso,
as questões específicas indicadas nos itens anteriores (1, 2, 3 e 4), o
julgamento pode ser realizado. A análise dos resultados pode ser feita
diante desta vasta gama de informações; para tanto, há a possibilidade
de se analisar os resultados de uma forma ampla ou específica,
visando a acertos e melhorias, ou não, considerando os fatores
externos às avaliações ou não, e, assim, decidir por aceitar ou rejeitar
o software didático avaliado, continuar ou descontinuar seu uso.
Para a validação desta metodologia de avaliação, foram realizadas duas
aplicações de um software didático pelo autor, pontuado e avaliado pelos três pontos
de vista que são apresentados no capítulo 5, a seguir.
103
5 APLICAÇÃO DA METODOLOGIA DE AVALIAÇÃO
Neste capítulo é apresentada uma aplicação da metodologia de avaliação da
qualidade de software utilizado como ferramenta de apoio didático em sala de aula.
Antes, porém, são conceituados os custos ABC e ABM, que são o tema do software
didático avaliado, onde o autor propõe um novo modelo de custos adaptado dos
modelos originais, que objetiva refletir uma aplicação mais próxima às necessidades
e à forma de visualizar custos por empresários, especialistas e pessoas ligadas à
análise de custos e à tomada de decisões.
5.1 Conceitos de custos ABC e ABM
Segundo Cogan (1994):
“Um dos benefícios obtidos com o ABC é o de permitir uma melhoria
nas decisões gerenciais, uma vez que se deixa de ter produtos
subcusteados ou supercusteados, permitindo-se a transparência exigida na
tomada de decisão empresarial, que busca, em última análise, otimizar a
rentabilidade do negócio”.
Em Martins (2003), encontramos:
“A Segunda versão ou geração do ABC foi concebida de forma a
possibilitar a análise de custos sob duas visões: a visão econômica de
custeio, que é uma visão vertical, no sentido de que apropria os custos aos
objetos de custeio através das atividades realizadas em cada departamento;
e a visão de aperfeiçoamento de processos, que é uma visão horizontal, no
sentido de que capta os custos dos processos através das atividades
realizadas nos vários departamentos funcionais”.
Segundo Brunstein (2001), “Os recursos da empresa são consumidos e
utilizados na condução de um conjunto de atividades, as quais são executadas para
permitir a produção dos produtos entregues aos clientes”. (Figura 8)
104
Figura 8 Custeio ABC, visão geral da técnica. Fonte: Brunstein e Kliemann (1997).
Horngren et al. (1997) definem “objeto de custo” como qualquer coisa que se
deseja custear; “custos diretos de um objeto de custo”, como os custos relacionados
com esse objeto e que podem ser identificados de uma forma economicamente
viável (custo efetivo); e “custos indiretos de um objeto de custo”, como os custos
relacionados com esse objeto e que não podem ser identificados de uma forma
economicamente viável, e que devem ser alocados através de um método de rateio.
5.1.1 Modelo de custos ABC proposto pelo autor
O modelo ABC costuma adotar apenas três níveis de análises (recursos ou
departamentos, atividades e objetos de custeio), conforme pode ser observado em
Kaplan e Cooper (2000) ou em Cogan (1997). Segundo Ching (2000):
“ABC é um método de rastrear os custos de um negócio ou
departamento para as atividades realizadas e de verificar como estas
atividades estão relacionadas para a geração de receitas e consumo dos
recursos. O ABC avalia o valor que cada atividade agrega para a
performance do negócio ou departamento”.
Conforme Cokins (1996), os “recursos” são os custos indiretos que podem ser
rastreados ou não.
Adaptando os enfoques de Martins (2003), Ching (2000), Cogan (1997) e
Kaplan e Cooper (2000), os “departamentos” utilizados podem ser os próprios
RECURSOS
ATIVIDADES/PROCESSOS
PRODUTOS/SERVIÇOS
CUSTEIO DE PROCESSOS
CUSTEIO DE PRODUTOS
105
departamentos da empresa, seus centros de custos, centros de atividades ou
processos.
Seguindo Martins (2003), as “atividades” podem ser definidas de forma mais
ampla ou de menor abrangência, sendo que o critério fundamental é a sua
relevância para o estudo e para os objetos de custeio.
Os “produtos ou serviços” constituem os objetos de custeio, que podem ser
também, segundo Ching (2000), clientes, fornecedores, setores do mercado entre
outros. Adotou-se esta nomenclatura por uma questão de simplificação e, também,
pelo fato de que “custear clientes ou mercados” na verdade é uma forma de custear
o “serviço prestado ao cliente” (entregas, vendas, visitas) ou o “serviço prestado ao
mercado” (pedidos, pesquisas, consultas).
Todavia, entendendo que é conveniente separar os recursos dos
departamentos, no modelo desenvolvido foi acrescentado um nível adicional,
conforme apresentado na Figura 9.
A vantagem da utilização deste modelo está em poder adaptá-lo para vários
níveis de estudo e necessidades, uma vez que a maioria das empresas prefere
trabalhar com a visão departamental, como também, no caso de processos, fica fácil
analisá-los em separado. Desta forma, torna-se possível analisar os “recursos” e os
“departamentos” distintamente; sabendo quais são estes recursos, seu valor total e
quanto foi consumido em cada departamento.
Recursos (custos indiretos)
Departamentos (departamentos, centro de custos ou de atividades)
Atividades (atividades)
Produtos ou Serviços (objetos de custeio: produtos, serviços, clientes)
Figura 9 Modelo de custos ABC adaptado pelo autor. Fonte: Autor
106
5.1.2 Sobre o software
Diante da necessidade de explorar melhor os exercícios aplicados nos cursos
de custos ABC, introduzindo uma nova dinâmica de trabalho em sala de aula,
através de simulações e recursos gráficos apropriados, o autor decidiu desenvolver
um software que atendesse a estas necessidades. A preocupação principal ao se
definir este software foi que ele servisse de ferramenta de apoio ao curso, sem que
necessariamente pudesse ser aplicado comercialmente, o que facilitaria em muito o
seu desenvolvimento, ao mesmo tempo em que atingiria os objetivos almejados.
Diante disso, o software foi elaborado e desenvolvido a contento.
O software desenvolvido pelo autor foi amplamente aplicado na Fundação
Carlos Alberto Vanzolini, em São Paulo, em cursos específicos de custos ABC,
intitulado: “ABC – Activity Based Costing”, destinando quatro horas do tempo total do
curso (16 horas) para a aplicação de exercícios com o apoio do software em
questão. Os alunos o utilizaram de forma intensiva, e ao final, avaliaram o software e
o curso.
Este mesmo software foi aplicado também em outros cursos na própria
Fundação Vanzolini e em empresas, sempre que o tema “custos ABC” era focado
em algumas aulas. Nestes casos, o software era apenas apresentado para facilitar a
visualização do modelo e o entendimento do mesmo, não sendo utilizado de forma
intensiva pelos alunos e, portanto, não sendo avaliado no final.
Além disso, houve um convite para duas apresentações do software em
empresas, com a finalidade de preparar as pessoas envolvidas para uma futura
implantação da metodologia ABC. A primeira empresa, em São Paulo, é uma
indústria farmacêutica de porte médio, a qual pediu para não ser identificada, e a
segunda foi objeto de estudo e citação na tese de doutorado, defendida em abril de
2002, do Dr. Alcir Ribeiro Carneiro de Almeida. Este estudo foi realizado na Eucatex,
em Salto, São Paulo, e a citação em sua tese foi a seguinte:
“A característica fundamental deste software é que ele foi
desenvolvido especialmente como ferramenta didática, na obtenção do
custo total (indiretos e diretos) de objetos de custeio de uma empresa ou de
107
processos, acatando o modelo ABC, com facilidade de aplicação prática.”
(Almeida, 2002).
5.1.3 Desenvolvimento do software
Segundo Martins (2003), “O ABC é, na realidade, uma ferramenta de gestão
de custos, muito mais do que de custeio de produto”. Esta é uma visão clara do ABM
e decidiu-se que o software deveria atender a algumas análises, tais como: a
participação dos custos indiretos em todos os níveis de custeio, apontamentos de
ociosidade, apontamento das atividades que agregam valor ao cliente (Ching, 2000),
cálculo de preços de venda (apreçamento segundo Nakagawa, 1993) entre outros.
O software desenvolvido pelo autor atende aos conceitos de custos e à visão
de gestão pelo ABM; além disso, foi adotado o modelo de custos ABC proposto
(com um nível a mais).
Os objetivos principais deste software são: o reforço e aplicação dos
conhecimentos adquiridos durante o curso de custos ABC, servir como ferramenta
didática e de apoio a exercícios, a obtenção do custo indireto por objeto de custeio e
do custo total, considerando também os custos diretos, e realizar este custeio
segundo o modelo ABC, que atenda ao ABM, com ampla visão da especificidade da
técnica e de sua aplicação prática.
O software foi desenvolvido para Windows e em linguagem Delphi. O mesmo
pode ser instalado em ambiente operacional Windows 95 ou superior e requer um
PC com processador compatível ao Pentium da Intel.
O software exige um mínimo de conhecimento em Windows para sua
operação; no entanto, para a sua aplicação em sala de aula, é necessário um
conhecimento anterior em custos ABC, como também se faz necessária a leitura da
“ajuda” (help), que apresenta todo o roteiro de utilização, dicas e um exemplo
completo para ser lançado passo a passo. De outro modo, no próprio curso os
alunos são orientados quanto à operação do mesmo.
108
O software apresenta várias ferramentas de análise que permitem sua
extensão ao atendimento do ABM, permitindo a análise das alocações dos custos
indiretos item a item, sua participação relativa, apontamentos de ociosidade, análise
das atividades que agregam valor ao cliente e outros recursos, tais como o cálculo
de preços de venda, por exemplo.
O software permite que se informe os recursos “não rastreáveis” que
aparecem no modelo, mas não interferem no cálculo.
Com o modelo de custos ABC definido, o software exige a informação dos
itens abaixo para a sua execução:
• Projeto: Cada projeto é único e identificado pela empresa, seu nome e
período de apuração dos dados. (anual, semestral, trimestral, etc.).
• Empresa: Na empresa estão seus dados globais, que devem ser informados
mesmo que apenas para um setor ou processo. Devem ser informados os
nomes dos direcionadores de custos das atividades que serão utilizados, por
exemplo.
• Recursos: Quais os recursos que serão considerados, seus valores totais e
os apontamentos dos direcionadores destes custos para serem passados aos
departamentos.
• Departamentos: Quais os departamentos que devem receber esses recursos
e os apontamentos dos direcionadores destes custos para serem passados
às atividades.
• Atividades: Quais atividades devem receber os recursos dos departamentos
e os apontamentos dos direcionadores destes custos para serem passados
aos produtos ou serviços. Se esta atividade agrega valor ao cliente e
ociosidade (opcionais).
109
• Produtos ou serviços: Quais produtos ou serviços serão custeados, seus
custos diretos e quantidades para o período apurado. Dados para cálculo do
preço de venda (opcional).
Com relação à apresentação dos resultados obtidos pela utilização do
software, são disponibilizadas as seguintes opções:
• “Relatório de custos” dos recursos, departamentos, atividades e produtos ou
serviços; informativos que facilitam a conferência dos dados lançados em
valor e porcentagem.
• “Relatório de vínculos”, que apresenta todos os custos e o quanto e como foi
passado de cada um, fase a fase, até chegarem aos produtos ou serviços
(em valor e porcentagem).
• “Relatório de resultados”, que apresenta em detalhes o custo total e unitário,
direto e indireto, os apontadores para a formação do preço de venda, o preço
de venda sugerido, sua margem bruta e mark-up.
• “Gráfico de custos” dos recursos, departamentos, atividades e produtos ou
serviços; quanto foi atribuído dos custos indiretos a cada um.
• “Gráfico de vínculos”, com apresentação visual com a seqüência dos custos e
suas ligações no espaço entre recursos, departamentos, atividades e
produtos ou serviços (visualização completa do modelo final).
5.1.4 Aplicação do software
O curso em questão, de custos ABC, razão do desenvolvimento do aplicativo
ora apresentado, além da parte teórica e discussão do assunto, é rico em exercícios
que são resolvidos pelos alunos sem o uso do software.
110
Na última parte do curso o software é apresentado por completo, utilizando-se
um dos exercícios resolvidos em classe, trazendo, assim, maiores explicações, e
levantando novas discussões sobre a metodologia ABC.
Posteriormente, é proposto que os alunos utilizem o software para resolverem
por completo um exercício. Eles iniciam um projeto novo, sem dados informados,
onde obrigatoriamente passam por todos os itens apresentados anteriormente.
O resultado é conferido e é visualizado o modelo ABC, e são analisadas a
disposição dos custos e seus efeitos, as situações críticas e o ABM.
O software permite que o modelo de custos ABC seja visualizado
graficamente, o que possibilita um entendimento mais amplo e dá um fechamento
excelente ao curso.
Figura 10 Tela principal do software. Fonte: Autor
111
A Figura 10 apresenta a tela principal do software com um exemplo completo.
Nota-se que é possível visualizar de imediato toda a estrutura de itens para o
modelo. Quando se seleciona um dos itens desta tela (através de um “clique” do
mouse), a mesma tela é reordenada de forma que apenas os itens que tenham
algum vínculo com o item selecionado apareçam. Assim, ao selecionar um
departamento em particular, a tela resultante apresenta apenas os recursos que
enviaram custos a este departamento, as atividades que receberam custos deste
departamento, e conseqüentemente, os produtos ou serviços que receberam custos
destas atividades.
Figura 11 Gráfico de vínculos (modelo ABC completo). Fonte: Autor
A Figura 11 apresenta o modelo de custos completo da empresa de forma
gráfica. Observa-se que acima estão os recursos e seus valores totais; ligados a
eles estão, logo abaixo, os departamentos e os valores dos custos atribuídos a eles.
Abaixo destes, as ligações com suas respectivas atividades e os valores dos custos
direcionados a elas. Finalmente, os produtos e seu custo total (diretos + indiretos)
por unidade. Caso se queira verificar qualquer dos itens individualmente, basta
112
“clicar” sobre o mesmo e será apresentado um informativo sobre a sua porcentagem
no grupo. Por exemplo, ao se escolher uma atividade, será apresentada a
porcentagem do seu valor em relação a todas as outras atividades. Esta informação
é essencial para o ABM, pois a partir desta apresentação, são observadas as
atividades que mais consomem custos e sua porcentagem em relação às demais
atividades. Desta forma, o passo seguinte é investigar os motivos destes custos, se
estão exagerados ou não, se o processo está adequado e se esta atividade pode ser
melhorada ou mesmo eliminada, uma vez que existe a informação, no cadastro das
atividades, sobre se ela agrega valor ao cliente ou não. Ainda sob esse prisma, a
decisão pode ser estratégica, pois ou se parte para avaliar e buscar corrigir
primeiramente as atividades pelo maior consumo de custos, ou então as que
agregam valor ao cliente. A primeira busca resolver o problema apenas com o
enfoque de redução de custos; a segunda tem o enfoque de satisfazer os clientes e
melhorar a sua imagem diante deles. As duas situações podem servir para esta
decisão ser tomada conjuntamente, atacando as atividades que recebem maior
custo e que também agregam valor ao cliente.
Figura 12 Gráfico das atividades (análise dos custos indiretos por atividade). Fonte: Autor
113
A Figura 12 apresenta o gráfico das atividades, onde é possível avaliar quais
são as atividades que mais consomem recursos. Este mesmo gráfico pode ser
acionado para recursos, departamentos e produtos ou serviços. Em termos de
gerenciamento (ABM), este gráfico é extremamente útil e significativo, pois se
visualiza facilmente a proporção em que cada atividade consome os custos
indiretos.
Figura 13 Gráfico de vínculos “parcial” (análise de um departamento). Fonte: Autor
A Figura 13 apresenta o modelo parcial de custos, pois anteriormente foi
selecionado o departamento de compras. Repare que ele está com cor de fundo
“cinza” e que apenas aparecem os itens que enviaram ou receberam custos deste
departamento. Os valores apontados também são exatos, e os produtos agora não
apresentam o custo total unitário, mas o custo indireto recebido. Este mesmo estudo
pode ser feito sobre qualquer recurso, departamento, atividade e produto ou serviço.
Por exemplo, é possível selecionar um produto e verificar os valores dos custos a
114
ele direcionados de cada atividade; por sua vez ficam identificados os custos dos
departamentos direcionados a elas e, por fim, os recursos direcionados a estes
departamentos. Esta visão “parcial” – que pode ser feita ao se selecionar qualquer
recurso, departamento, atividade ou produto – facilita a conferência e a visão parcial
do modelo, sendo um importantíssimo apoio ao gerenciamento da estrutura de
custos informada.
5.2 A aplicação da metodologia de avaliação
A metodologia de avaliação da qualidade de um software didático de custos
ABC é apresentada através da aplicação de um software desenvolvido pelo autor
com a finalidade didática especificamente voltada para cursos de custos ABC. Os
cursos submetidos à avaliação foram ministrados no período de abril a maio de
2001, na Fundação Carlos Alberto Vanzolini em São Paulo, e foram 18 avaliações
de alunos que serviram de base para esta pesquisa.
Os valores de médias e pontuações neste capítulo são apresentados com até
duas casas decimais, uma vez que a escala para a métrica definida pelo autor varia
de 1 a 4, com intervalos de 0,25 pontos (Figura 7). No entanto, os cálculos foram
feitos com os valores reais, considerando todas as casas decimais, pois foram
realizados em um aplicativo do tipo planilha de cálculo. Considerando apenas os
valores como apresentados e refazendo os cálculos, alguns resultados poderão
sofrer variações pelo motivo de serem apresentados com arredondamento na
segunda casa decimal.
5.2.1 Determinação dos requisitos básicos
Na aplicação da metodologia de avaliação, o primeiro passo foi determinar os
requisitos básicos que um software didático deva ter para a sua aplicação
específica.
Os requisitos básicos do software didático de custos ABC foram preenchidos
115
em cada uma das subcaracterísticas da Norma como se segue, conforme o
procedimento indicado no tópico 4.2.1, as características estão presentes apenas
para o melhor entendimento para cada grupo de subcaracterísticas:
• C.1. Funcionalidade: O software atende a seu propósito e às necessidades
especificadas? O software deve atender satisfatoriamente às
subcaracterísticas de funcionalidade.
• S.1.1. Adequação: O software atende e é apropriado para as tarefas
especificadas? O software deve apresentar o modelo de custos ABC, os
recursos, os departamentos, as atividades e os objetos de custeio com
seus respectivos valores devidamente atribuídos através dos
direcionadores de custos. Os objetos de custeio devem apresentar seu
custo total e o software permitir a análise dos custos e valores
direcionados através de gráficos e relatórios.
• S.1.2. Acurácia: O software gera resultados corretamente, efeitos ou
conforme o acordado? Exercícios anteriormente aplicados em sala de aula
devem ser aplicados ao software e este dar com exatidão os resultados
esperados, tanto em valores, gráficos e relatórios.
• S.1.3. Interoperabilidade: O software interage com sistemas
especificados? A princípio, um software didático de custos ABC só
necessita deste recurso em relação ao ambiente (ou ambientes) para o
qual foi desenvolvido, uma vez que o mesmo não precisa ser desenvolvido
de forma a interagir com outros sistemas. A aplicação de exemplos
completos em sala de aula independentemente de outros sistemas é
suficiente.
• S.1.4. Conformidade: O software está de acordo com as normas,
convenções ou regulamentações previstas em leis e descrições similares,
relacionadas à aplicação? O software deve estar em conformidade com o
modelo de custos ABC previamente adotado e com uma nomenclatura
comumente aceita, uma vez que existem várias definições para o modelo
116
e também para a nomenclatura utilizada. No entanto, deve-se atentar ao
tratamento dado aos custos indiretos, direcionadores de custos, aos
custos diretos e aos resultados apresentados.
• S.1.5. Segurança de acesso: O software evita acesso não autorizado,
acidental ou deliberado a programas e dados? A princípio o software deve
trabalhar com valores fictícios, por se tratar de exercícios propostos, e não
necessita controlar o acesso a dados; no entanto, deve-se lembrar que os
alunos podem avariar os dados acidentalmente ou deliberadamente,
prejudicando o andamento da aula ou do exercício em questão. Neste
sentido, é favorável a existência de alguma segurança.
• C.2. Confiabilidade: O software mantém seu nível de desempenho sob
condições estabelecidas durante um período de tempo estabelecido? O
software deve atender satisfatoriamente às subcaracterísticas de
confiabilidade.
• S.2.1. Maturidade: Qual a freqüência de falhas por defeitos que o
software apresenta? Além dos testes técnicos completos voltados a estas
medições, o próprio software poderia registrar algumas falhas durante a
aplicação, aquelas que poderiam ser interpretadas de forma lógica pelo
próprio software, como, por exemplo, gravando cada passo iniciado e cada
passo concluído pelo usuário; ou seja, se ao analisar os registros houver
uma descontinuidade entre o início de um passo e seu final esperado, é
que houve uma interrupção que não permitiu que esse passo fosse
completado. Esta informação pode ajudar a equipe de desenvolvimento a
verificar algumas falhas que porventura não ocorreram em seus testes.
• S.2.2. Tolerância a falhas: O software mantém um nível de desempenho
especificado nos casos de falhas no software ou de violação nas
interfaces especificadas? O software deve prever que na ocorrência de
uma falha os dados não podem ficar incompletos pois isso comprometeria
toda a “cadeia de cálculos” (em cascata) que o modelo de custos ABC
exige; como também, não poderia perder os dados já lançados pelo
117
mesmo motivo. Os dados digitados e os totais dos valores direcionados
devem ter consistência própria, informando de imediato a inconsistência e
dando opções de ação ao usuário. Por se tratar de uma “cadeia de
cálculos”, o software poderia ter uma “verificação global”, que através de
mensagens apontasse falhas e prováveis falhas, como, por exemplo, a
falta de um direcionador de custo ou que o nome do direcionador não
pode ficar em branco. A perda de parte dos dados durante a aplicação dos
exercícios irá prejudicar sua continuidade, causar dúvidas em sua
conclusão e até afetar o bom andamento da aula.
• S.2.3. Recuperabilidade: O software restabelece seu nível de
desempenho em caso de falha e recupera os dados diretamente afetados,
em que tempo e com que esforço? Apesar de não ser essencial, por se
tratar de um software didático, este recurso torna-se importante para o
bom andamento e a continuidade da aula.
• C.3. Usabilidade: É fácil para o usuário utilizar o software? O software deve
atender satisfatoriamente as subcaracterísticas de usabilidade.
• S.3.1. Inteligibilidade: O usuário reconhece com facilidade no software o
conceito lógico e sua aplicabilidade? É fundamental que o software seja
claro e objetivo, apresente amplamente e de forma visual (gráfica) o
modelo de custos ABC e seus conceitos, além das apresentações em
telas e relatórios.
• S.3.2. Apreensibilidade: O usuário aprende com facilidade a aplicação do
software? É fundamental também que o usuário visualize onde e como
informar os dados necessários para a aplicação do exercício em questão,
de forma prática e direta, de modo a não comprometer a assimilação do
que é essencial ao curso, deste modo, podendo dar o foco de sua atenção
ao aprendizado.
• S.3.3. Operacionalidade: O usuário opera e controla cada operação do
118
software com facilidade? Os comandos devem ser similares ou os mais
próximos possíveis do ambiente em que o software está sendo executado,
permitindo a rápida e fácil utilização destes comandos e suas operações,
enfocando assim o aprendizado no assunto ‘custos ABC’.
• C.4. Eficiência: É satisfatório o relacionamento entre o nível de desempenho
do software e a quantidade de recursos usados em condições estabelecidas?
O software deve atender satisfatoriamente às subcaracterísticas de eficiência.
• S.4.1. Comportamento em relação ao tempo: É satisfatório o tempo de
resposta do software, o tempo de processamento e velocidade na
execução de suas funções? A princípio, estima-se que o cálculo e
apresentação do modelo de custos ABC são as operações que mais
consumam tempo, devendo assim apresentar a melhor performance
possível. Caso este procedimento, amplamente utilizado e repetido nos
cursos, for um procedimento demorado, o mesmo poderá atrasar ou
comprometer a qualidade do próprio curso, que poderia ser mais rico em
detalhes e elucidações, havendo mais tempo para tanto.
• S.4.2. Comportamento em relação aos recursos: É satisfatória a
quantidade de recursos usados pelo software e a duração de seu uso na
execução de suas funções? A princípio, os recursos que mais devam ser
utilizados são os recursos de cálculos, gráficos e impressão, nesta ordem
de importância. Assim, se melhor avaliados e aplicados estes recursos no
desenvolvimento, melhor o resultado final na aplicação do software.
• C.5. Manutenibilidade: É fácil fazer modificações específicas no software? O
software deve atender satisfatoriamente às subcaracterísticas de
manutenibilidade.
• S.5.1. Analisabilidade: É fácil de diagnosticar deficiências ou causas de
falhas, ou identificar partes a serem modificadas no software? É
fundamental uma boa documentação, o desenvolvimento deve ser em
119
módulos, de forma padronizada, com biblioteca de funções e, se possível,
orientado a objetos, além de recursos inerentes à própria linguagem e ao
ambiente de desenvolvimento, permitindo, assim, a fácil localização de
onde fazer o acerto ou a melhoria necessária.
• S.5.2. Modificabilidade: É fácil de modificar o software, remover seus
defeitos ou adaptá-lo a mudanças ambientais? Uma vez localizado o local
a se acertar ou melhorar, o software deve estar desenvolvido com uma
estrutura tal, que tudo esteja documentado, construído de forma
padronizada, sem redundâncias de operações e funções; sendo fácil de se
corrigir ou de se adaptar, sem que se comprometa o correto
funcionamento de outras partes do software.
• S.5.3. Estabilidade: É baixo o risco de efeitos inesperados ocasionados
por modificações no software? Fazendo-se uma verificação global a partir
de um exemplo completo e com resultados conhecidos, pode-se avaliar as
conseqüências das modificações. De outro modo, um roteiro básico de
verificações pode ser adotado em complemento à primeira, assegurando,
assim, a exatidão das alterações. O risco neste caso é de ocorrerem
falhas e de não se obter os resultados corretos durante uma apresentação
ou uso em sala de aula.
• S.5.4. Testabilidade: É fácil de se validar o software modificado? O
software poderia se autoverificar em boa parte de suas funções a partir de
um exemplo com resultados conhecidos; para as demais funções, poderia
ser elaborado um roteiro de testes.
• C.6. Portabilidade: O software é facilmente transferido de um ambiente para
outro? O software pode atender às subcaracterísticas de portabilidade, uma
vez que pode ser necessário, em breve, utilizar esse software em outro
ambiente.
• S.6.1. Adaptabilidade: O software é facilmente adaptado a ambientes
120
diferentes especificados, sem a necessidade de aplicação de outras ações
ou meios além daqueles fornecidos para essa finalidade pelo software
considerado? A princípio, deve-se avaliar em qual linguagem desenvolver
o software, ou em qual linguagem o mesmo está desenvolvido. Nem todas
as linguagens permitem, ou estão preparadas integralmente para serem
executadas em ambientes diferentes, ou mesmo que se possa fazer esta
adaptação por meio de outro software. O ideal é confrontar as linguagens
com os possíveis ambientes ou, no caso de serem conhecidos, avaliar a
linguagem e sua adaptabilidade para outros ambientes. Portanto, deve-se
considerar essa possibilidade para breve.
• S.6.2. Capacidade para ser instalado: É fácil de se instalar o software
num ambiente especificado? Neste caso, existe no mercado mais de um
software que prepara e gera cópias para instalação. Estas cópias facilitam
a instalação para o usuário, pois geralmente seguem um mesmo padrão
de operação de um software comum, sendo auto-explicativo, além de
preparar o ambiente corretamente e de permitir algumas opções, como,
por exemplo, a seleção do diretório a ser instalado. De outro modo, é
preciso que se tenha ou se desenvolva esse processo, o que geralmente
exige muito esforço e vários conhecimentos específicos, como, por
exemplo, do ambiente o qual será instalado e sobre o banco de dados
utilizado. Um software deve ser adquirido para a instalação de forma
satisfatória.
• S.6.3. Conformidade: O software está consonante com os padrões ou
convenções relacionados à portabilidade? É provável que em breve seja
preciso utilizar o software em outros ambientes. Há também de se avaliar
a linguagem de programação e se esta permite alguma solução para
outros ambientes, pois algumas linguagens são específicas para um único
ambiente; outras fornecem versões distintas para uma migração específica
e outras permitem a execução em vários ambientes diferenciados. É
importante que o software esteja pronto para funcionar em outros
ambientes.
121
• S.6.4. Capacidade de substituir: O software facilmente substitui outro
software, no ambiente estabelecido por esse outro software? A princípio,
por ser um software didático e por possibilitar a aplicação de exemplos
completos sem o uso de outro software, recursos ou banco de dados, ele
facilmente substitui qualquer outro, por funcionar de forma totalmente
independente. Portanto, ainda que funcionasse em outro ambiente, não
seria necessário substituir qualquer software, pois nem haveria a
necessidade de que o outro software fosse desinstalado, podendo
funcionar um ou outro, conforme se deseje. Portanto, não há a
necessidade de se avaliar esta subcaracterística.
Uma vez preenchidos os requisitos básicos, passou-se para as aulas com a
aplicação do software didático de custos ABC e, ao final, com a avaliação dos
alunos sobre a aplicação do software em sala de aula.
5.2.2 A avaliação da aplicação do software pelos alunos
Os alunos receberam o modelo de avaliação individual da Tabela 8, e foram
orientados a manter em branco os itens que, no entendimento deles, não foram
vistos no software ou que não haveria como se avaliar naquele momento. Além
disso, eles também foram avisados de que não precisariam se identificar.
Ao fim do preenchimento da avaliação feita pelos alunos, estas foram
recolhidas e todos os subitens pontuados foram somados e passados para a Tabela
9 nas respectivas colunas: Insuficiente, Regular, Bom e Excelente. A coluna
“TOTAL” recebeu a soma simples da quantidade de pontuações em cada subitem.
Este resultado é apresentado na Tabela 17.
122
Tabela 17 Total de pontuações das avaliações dos alunos.
Item Subitem Insuficiente
Regular Bom Excelente TOTAL
Apresentação 7 8 15
Operação
Facilidade de uso 8 9 17
Telas 12 6 18
Cadastros 1 8 9 18
Gráficos 5 13 18
Relatórios 8 9 17
Visualização
Ajuda (help) 8 7 15
Visão do assunto 4 8 12
Aprendizado 1 5 7 13
Exemplos 7 7 14
Complemento
ao curso
Aplicação prática 6 7 13
Software didático 9 8 17
Avaliação
geral
Software comercial 1 8 7 16
Fonte: Autor
Com estes valores (Tabela 17), passou-se a calcular as médias ponderadas
de cada subitem e as médias simples de cada item.
5.2.3 Cálculo das médias das avaliações dos alunos
Antes dos cálculos propriamente ditos, o autor adotou o valor de referência 3
(três) para o software avaliado nessa aplicação da metodologia de avaliação,
exatamente como apontado no exemplo da Figura 7. Este valor de referência
corresponde ao nível de pontuação Bom e subnível mais; portanto, representa um
nível de exigência razoavelmente alto (Bom mais) para a pontuação de um software
didático e de todos os itens que o compõem. Isto se deve ao fato de que este
software foi desenvolvido com finalidade didática e já vem sendo aplicado
satisfatoriamente em vários cursos; assim, é natural que se espere que ele
apresente uma pontuação relativamente alta como software didático e também em
todos os seus itens.
123
Para os cálculos, a coluna “Média Final” da Tabela 10 recebeu as médias
ponderadas das pontuações de cada subitem. Por exemplo, no subitem “Cadastros”,
que recebeu uma pontuação como Regular, oito pontuações como Bom e nove
pontuações como Excelente, em um total de dezoito pontuações, a média
ponderada (considerando os pesos 1, 2, 3 e 4 respectivamente) foi calculada assim:
( 0 x 1 + 1 x 2 + 8 x 3 + 9 x 4 ) / 18 = ( 2 + 24 + 36 ) / 18 = 62 / 18 = 3,44
Os resultados destes cálculos estão presentes na Tabela 18.
Tabela 18 Média final das avaliações da aplicação do software didático
Item Subitem Média final
Apresentação 3,53
Operação
Média 3,53
Facilidade de uso 3,53
Telas 3,33
Cadastros 3,44
Gráficos 3,72
Relatórios 3,53
Visualização
Média 3,5
Ajuda (help) 3,47
Visão do assunto 3,67
Aprendizado 3,46
Exemplos 3,5
Complemento
ao curso
Média 3,54
Aplicação prática 3,54
Software didático 3,57
Avaliação
geral
Software comercial 3,38
Aplicação do Software
Média Final 3,52
Fonte: Autor
A média de cada item é calculada pela média simples de seus subitens. Por
exemplo, a média do item “Operação” foi calculada assim: (3,53 + 3,53) / 2 = 3,53.
A média final da aplicação do software é a média simples das médias dos três
itens. Neste caso, ela foi calculada assim: (3,53 + 3,5 + 3,54) / 3 = 3,52.
124
Analisando os resultados apontados na Tabela 18 e comparando com o valor
de referência que é 3 (Bom mais), pode-se observar:
• Que a aplicação do software pela avaliação desenvolvida pelo
professor obteve a média final de 3,52 (Excelente, conforme a Figura
7), sendo superior ao valor de referência, o que indica que o software é
adequado quanto à aplicação nesse ponto da avaliação.
• Que os três itens têm suas médias superiores ao valor de referência, e
de nível de pontuação Excelente; portanto, também são adequados.
• Que todos os subitens têm as suas médias finais superiores ao valor
de referência, o que indica que estes subitens também são adequados.
Suas médias variam desde 3,33 até 3,72, ou seja, foram pontuados
desde Excelente menos até Excelente. Apesar de adequados, estes
subitens podem ser melhorados para uma nova versão do software, se
assim for desejado, melhorando conseqüentemente a média de seus
respectivos itens e a média final da aplicação do software.
• Que não se obteve valores inferiores ao valor de referência em
qualquer das médias, como era esperado para a aplicação deste
software.
É importante lembrar que esta avaliação da aplicação neste ponto é parcial, e
apenas os valores das médias finais obtidas para os subitens serão considerados na
seqüência desta aplicação da metodologia de avaliação. Portanto, dos resultados
obtidos, apenas estes servirão para dar continuidade ao processo de pontuação final
da aplicação do software pelo ponto de vista dos alunos. No entanto, todos os
resultados podem servir para serem avaliados mais profundamente no caso de
buscas de possíveis problemas e melhorias quanto à aplicação avaliada.
Com esses resultados, o próximo passo é relacionar as médias obtidas com
cada subitem às subcaracterísticas da Norma.
125
5.2.4 Relacionando a avaliação dos alunos com a Norma
A Tabela 18 foi utilizada para o transporte das médias finais dos subitens para a
coluna “Média das avaliações” na tabela 11. Este resultado é apresentado na Tabela 19.
Tabela 19 Relação da avaliação dos alunos com as subcaracterísticas da Norma
Item Subitem
Média das
avaliações
Subcaracterísticas da Norma que têm relação
com o subitem avaliado pelos alunos
Apresentação
3,53
S.1.1 Adequação, S.3.3 Operacionalidade
Operação
Facilidade
de uso
3,53
S.3.3 Operacionalidade
Telas
3,33
S.1.1 Adequação, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade
Cadastros
3,44
S.1.1 Adequação, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.3 Operacionalidade
Gráficos
3,72
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade
Relatórios
3,53
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade
Visualização
Ajuda (help)
3,47
S.1.1 Adequação, S.3.2 Apreensibilidade
Visão do
assunto
3,67
S.1.4 Conformidade, S.3.1 Inteligibilidade,
S.3.2 Apreensibilidade
Aprendizado
3,46
S.3.1 Inteligibilidade
Exemplos
3,5
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade,
S.3.3 Operacionalidade
Complemento
Ao curso
Aplicação
prática
3,54
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade,
S.3.3 Operacionalidade
Software
didático
3,57
S.1.1 Adequação, S.1.2 Acurácia, S.1.4 Conformidade,
S.3.1 Inteligibilidade, S.3.2 Apreensibilidade,
S.3.3 Operacionalidade
Avaliação
Geral
Software
comercial
3,38
“Sem efeito”
Fonte: Autor
Uma vez que a Tabela 19 foi preenchida, cada subcaracterística apontada em
cada um dos subitens da tabela foi acrescida do valor da respectiva média da
avaliação. Assim, todas as subcaracterísticas acumularam os valores das médias
apontadas nos respectivos subitens onde se apresentam. Dividindo-se o valor
126
acumulado de cada uma pela quantidade de vezes em que recebeu médias dos
subitens (média simples), foram obtidas suas pontuações. Por exemplo, a
subcaracterística “S.1.1 Adequação” aparece apontada em nove subitens, que
acumulam seus valores de médias para esta subcaracterística. Foram recebidas
nove médias (considerando todas as vezes, pois nenhum subitem deixou de receber
valor de média). Assim, o cálculo deu-se da seguinte forma: (3,53 + 3,33 + 3,44 +
3,72 + 3,53 + 3,47 + 3,5 + 3,54 + 3,47) / 9 = 3,5. Estes valores obtidos devem ser
registrados na Tabela 13, no campo “Pontuação:” da última coluna, referente à
subcaracterística sobre a qual se realizou o cálculo. As subcaracterísticas que foram
preenchidas são exatamente as subcaracterísticas voltadas à aplicação, restando
pontuar as essencialmente técnicas. Na seqüência, a Tabela 20 apresentará seu
preenchimento integral com as pontuações das subcaracterísticas voltadas à
aplicação calculadas aqui, e com as pontuações das subcaracterísticas
essencialmente técnicas a serem pontuadas pela equipe de desenvolvimento.
5.2.5 Avaliação pela equipe de desenvolvimento
Passou-se, então, para a avaliação da equipe de desenvolvimento, por meio
da utilização da Tabela 13 para a pontuação apenas das subcaracterísticas
essencialmente técnicas, que podem ser reconhecidas, observando na última coluna
as subcaracterísticas que pedem a escolha de pontuação, entre: 1, 2, 3, 4 ou NA
(“não se aplica”). As subcaracterísticas que apresentam somente o termo
“Pontuação:” na última coluna, são as da aplicação pontuadas pela avaliação dos alunos.
Portanto, a equipe de desenvolvimento pontuou diretamente cada
subcaracterística essencialmente técnica, com a confrontação entre os requisitos
básicos do software e o que o software didático realmente apresentou em testes
realizados pela própria equipe. Assim, a Tabela 20 está completa quanto às
pontuações das duas avaliações anteriores (avaliação pelos alunos e avaliação da
equipe de desenvolvimento). A seguir, foram calculadas as pontuações por tipo de
avaliação: a avaliação da aplicação pelo ponto de vista dos alunos e a avaliação
técnica pelo ponto de vista da equipe de desenvolvimento. O resultado destas
pontuações é apresentado na Tabela 20.
127
Tabela 20 Avaliação dos requisitos básicos de qualidade do software didático pelos pontos de vista
da equipe de desenvolvimento e dos alunos, com base na Norma ISO 9126.
Características e Subcaracterísticas
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA
= Não se Aplica
C.1 Funcionalidade Pontuação: 3,12
S.1.1
Adequação:
O software atende e é apropriado para as tarefas especificadas?
Pontuação: 3,5
S.1.2
Acurácia:
O software gera resultados corretamente, efeitos ou conforme o acordado?
Pontuação: 3,55
1
2 3 4 NA
S.1.3
Interoperabilidade:
O software interage com sistemas especificados?
X
S.1.4
Conformidade: O software está de acordo com as normas, convenções ou
regulamentações previstas em leis e descrições similares, relacionadas à
aplicação?
Pontuação: 3,53
1
2 3 4 NA
S.1.5
Segurança de acesso
O software evita acesso não autorizado, acidental ou deliberado a programas e
dados?
X
C.2 Confiabilidade Pontuação: 2
1
2 3 4 NA
S.2.1
Maturidade:
Qual a freqüência de falhas por defeitos que o software apresenta?
X
1
2 3 4 NA
S.2.2
Tolerância a falhas: O software mantém um nível de desempenho especificado
nos casos de falhas no software ou de violação nas interfaces especificadas?
X
1
2 3 4 NA
S.2.3
Recuperabilidade: O software restabelece seu nível de desempenho em caso
de falha e recupera os dados diretamente afetados, em que tempo e esforço?
X
C.3 Usabilidade Pontuação: 3,52
S.3.1
Inteligibilidade
O usuário reconhece com facilidade no software o conceito lógico e sua
aplicabilidade?
Pontuação: 3,52
S.3.2
Apreensibilidade
O usuário aprende com facilidade a aplicação do software?
Pontuação: 3,53
S.3.3
Operacionalidade
O usuário opera e controla cada operação do software com facilidade?
Pontuação: 3,5
C.4 Eficiência Pontuação: 4
1
2 3 4 NA
S.4.1
Comportamento em relação ao tempo: É satisfatório o tempo de resposta do
software, o tempo de processamento e velocidade na execução de suas
funções?
X
1
2 3 4 NA
S.4.2
Comportamento em relação aos recursos: É satisfatória a quantidade de
recursos usados pelo software e a duração de seu uso na execução de suas
funções?
X
128
C.5 Manutenibilidade Pontuação: 3
1
2 3 4 NA
S.5.1
Analisabilidade: É fácil de diagnosticar deficiências ou causas de falhas, ou
para identificar partes a serem modificadas no software?
X
1
2 3 4 NA
S.5.2
Modificabilidade: É fácil de modificar o software, remover seus defeitos ou
adaptá-lo a mudanças ambientais?
X
1
2 3 4 NA
S.5.3
Estabilidade
É baixo o risco de efeitos inesperados ocasionados por modificações no
software?
X
1
2 3 4 NA
S.5.4
Testabilidade
É fácil de se validar o software modificado?
X
C.6 Portabilidade Pontuação: 1,67
1
2 3 4 NA
S.6.1
Adaptabilidade: O software é facilmente adaptado a ambientes diferentes
especificados, sem a necessidade de aplicação de outras ações ou meios além
daqueles fornecidos para essa finalidade pelo software considerado?
X
1
2 3 4 NA
S.6.2
Capacidade para ser instalado:
É fácil de se instalar o software num ambiente especificado?
X
1
2 3 4 NA
S.6.3
Conformidade:
O software está consonante aos padrões ou convenções relacionados à
portabilidade?
X
1
2 3 4 NA
S.6.4
Capacidade para substituir: O software facilmente substitui outro software, no
ambiente estabelecido por esse outro software?
X
Pontuação Final do Software Didático – Avaliação da Aplicação
(Média Simples das Subcaracterísticas Voltadas à Aplicação que foram Pontuadas)
Pontuação
da Aplicação
3,52
Pontuação Final do Software Didático – Avaliação Técnica
(Média Ponderada das Subcaracterísticas Voltadas à parte Técnica que foram Pontuadas)
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
14
Qtde
Total
de
Pontos:
1 6 5 2
36
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação
Técnica
2,57
Pontuação Final do Software Didático – Avaliação do Produto de Software
(Média Simples das Pontuações da Aplicação e Técnica)
Pontuação
Produto de
Software
3,05
Fonte: Autor
A pontuação de cada característica foi calculada pela média simples das
pontuações de suas respectivas subcaracterísticas que foram pontuadas, como no
caso da característica “Funcionalidade”: (3,5 + 3,55 + 2 + 3,53 + 3) / 5 = 3,12.
129
A pontuação da aplicação foi de 3,52, calculada pela média simples das
pontuações das subcaracterísticas voltadas à aplicação (todas foram pontuadas),
desta forma: (3,5 + 3,55 + 3,53 + 3,52 + 3,53 + 3,5) / 6 = 3,52.
A pontuação técnica foi de 2,57, calculada pela média ponderada das
pontuações das subcaracterísticas essencialmente técnicas que receberam
pontuação, desta forma: (1 x 1 + 6 x 2 + 5 x 3 + 2 x 4) / 14 = 36 / 14 = 2,57.
A pontuação como produto de software é obtida pela média simples das
pontuações da aplicação e técnica, desta forma: (3,52 + 2,57) / 2 = 3,05. Essa
pontuação é superior ao valor de referência e aponta para o nível de pontuação Bom
mais, o que indica a adequação desse software como produto de software. No
entanto, a pontuação final a ser calculada para o software didático deve considerar
também a avaliação do ponto de vista do professor (visão didática), o que será feito
e apresentado na Tabela 21.
Assim, analisando cada subcaracterística e sua respectiva pontuação, pode-
se destacar que as que receberam pontuações abaixo de 3 (valor de referência),
precisam ser revistas para se adequarem quanto a uma possível reavaliação de uma
nova versão deste software. Caso o software venha a ser aceito para a aplicação ou
se for aprovada a sua continuidade de uso em sala de aula, mesmo com estas
pontuações abaixo do valor de referência, é indicado providenciar o que for
necessário adaptar ou corrigir, para uma próxima versão deste software.
Com os resultados obtidos até aqui, algumas análises já podem ser feitas.
5.2.6 Avaliação técnica e da aplicação com base nos requisitos básicos
É interessante que o professor, junto com a equipe de desenvolvimento, faça
observações sobre a pontuação obtida para cada subcaracterística em relação ao
que se pede nos requisitos básicos do software. Estas podem ser detalhadas, em
especial para a equipe técnica, e podem apresentar uma observação sucinta que
aponte de modo geral o que se apurou, pois o professor não necessariamente tem
130
conhecimentos de informática a nível técnico e o mesmo se dá com outras pessoas
ou grupos que venham a discutir sobre os resultados da avaliação do software. A
idéia é que a equipe de desenvolvimento guarde para ela as observações
detalhadas (faz parte de seu serviço), e as observações sucintas sejam descritas no
campo “Observações sobre o software” da Tabela 14, o que foi feito e será
apresentado a seguir na Tabela 21.
Uma vez calculadas as pontuações de cada subcaracterística e de cada
característica (média simples das pontuações de suas respectivas
subcaracterísticas), confrontou-se estas pontuações (Tabela 20) com os requisitos
básicos do software. Desta forma, foram detalhados os problemas e indicadas as
possíveis melhorias e providências gerais necessárias para o software.
A seguir, é apresentado o comentário desta análise por subcaracterística e, a
observação sucinta que está entre aspas sempre no final de cada comentário. Para
os níveis de pontuações indicados ao lado dos valores das pontuações, é importante
ressaltar que apenas para as subcaracterísticas essencialmente técnicas são
indicadas a própria pontuação, que é exatamente 1, 2, 3 ou 4 (respectivamente
Insuficiente, Regular, Bom ou Excelente). Para as subcaracterísticas voltadas à
aplicação e para todas as características, são indicados os níveis de pontuação
conforme a Figura 7.
• C.1 Funcionalidade: Pontuação 3,12 (Bom mais) - média simples de suas
subcaracterísticas.
• S.1.1 Adequação: Pontuação 3,5 (Excelente) da avaliação dos alunos.
Verificou-se uma pequena melhoria nas avaliações do curso de custos
ABC após a introdução do software como ferramenta didática. Além disso,
os alunos passaram a interagir mais com o curso e elogiar a utilização do
software. O software recebeu pontuação 3,57 no item “software didático” e
3,67 no item “visão do assunto”, ambos de nível de pontuação Excelente,
de onde concluímos que a sua proposta foi atendida. Portanto: “É
adequado ao assunto e finalidade”.
131
• S.1.2 Acurácia: Pontuação 3,55 (Excelente) da avaliação dos alunos. O
software foi amplamente utilizado em diversas aulas e atendeu
satisfatoriamente aos exercícios propostos. Portanto: “Faz corretamente o
que se propõe”.
• S.1.3 Interoperabilidade. Pontuação 2 (Regular) da avaliação da equipe
de desenvolvimento. O software foi desenvolvido para o ambiente
Windows e é executado em computadores compatíveis com o processador
Intel. Este ambiente é amplamente utilizado; e, em especial, nos locais
onde o curso é ministrado. Além disso, o software não necessita de
recursos de outros sistemas. Desta forma, o software não necessita
interagir com outros sistemas no momento, mas poderá precisar em breve
interagir com outros ambientes. Portanto: “Interage com os sistemas
especificados”.
• S.1.4 Conformidade. Pontuação 3,53 (Excelente) da avaliação dos
alunos. Quanto à legislação e às normas, o modelo de custos ABC aplica-
se de forma direta, uma vez que não há restrições ou determinações
legais para seu uso ou aplicação. Isto se dá pelo fato de o modelo de
custos utilizar informações já existentes e que o que será analisado são os
seus aspectos gerenciais (ABM). Os dados utilizados e a sua aplicação
seguem às convenções de custos e à metodologia de custeio ABC.
Portanto: “Está em conformidade com o assunto”.
• S.1.5 Segurança de acesso: Pontuação 3 (Bom) da avaliação da equipe
de desenvolvimento. A instalação do software é segura, pois se dá através
de software de mercado que realiza este processo de forma simples e
direta (auto-explicativo), prepara o ambiente sem interferência do usuário,
permitindo que o mesmo confirme ou redirecione o diretório de instalação.
Esta instalação cuida da adequação de ambiente e acesso ao banco de
dados, eliminando esses passos, caso os usuários venham a instalar o
software, o que não é o caso. Os arquivos de dados estão protegidos com
senha para sua abertura e visualização. O acesso aos dados, pelo
software, não está restrito por senhas de acesso, uma vez que o mesmo é
132
utilizado para finalidade didática e não necessita que estes dados tenham
restrição para visualização. Portanto: “É seguro para a finalidade didática”.
• C.2 Confiabilidade: Pontuação 2 (Regular) – média simples das suas
subcaracterísticas.
• S.2.1 Maturidade: Pontuação 2 (Regular) da avaliação da equipe de
desenvolvimento. Pela larga utilização do software ao longo de vários
cursos, e pelas atualizações constantes, este não tem apresentado falhas
em nenhuma das suas opções, uma vez que todas são utilizadas na
apresentação e na parte prática com os exercícios pelos alunos. No
entanto, uma falha é observada ao se testar o software isoladamente para
um exemplo mais complexo. O gráfico de vínculos ultrapassa o tamanho
da tela, apresentando problema na impressão. Porém, esta falha não
interrompe a execução do software, mas dificulta a visualização. Portanto:
“Falha na impressão do gráfico de vínculos”.
• S.2.2 Tolerância a falhas: Pontuação 2 (Regular) da avaliação da equipe
de desenvolvimento. Para o caso de falhas no software ou de violação nas
interfaces especificadas, o principal problema está em se perder
informações previamente lançadas pelo usuário, neste caso, apenas as
informações confirmadas quando do lançamento pelo usuário não se
perdem, os lançamentos seguintes à confirmação sim. Isto remete à
subcaracterística S.2.3 a seguir (recuperabilidade). No caso de falhas por
informações incompletas ou erradas na digitação pelo usuário, o software
apresenta o modelo de custos e seus cálculos com as informações que
tem no momento. No entanto, ele permite uma verificação, na qual são
apontados itens sem cadastramento, sem vínculos, sem valores ou em
branco. Outra situação é quando o total informado de vários itens não
confere com o total pré-definido; nestes casos, o software apresenta dois
tipos de mensagens: uma informando da diferença e não aceitando os
novos lançamentos, fazendo com que o usuário os corrija ou desista dos
lançamentos cancelando a operação; e a outra, por causa de diferenças
em casas decimais ou centesimais (resultados de cálculos), que informa
133
da diferença e pergunta se deseja manter estes lançamentos com a
diferença ou alterar os dados. É permitido ao usuário cancelar esta
operação também. Concluindo, o software trata os erros de lançamentos,
permite alguns campos sem valores ou dados, mas os apresenta e
permite verificar se há informações deste tipo para serem analisadas.
Portanto: “Tem consistências e verificador de erros”.
• S.2.3 Recuperabilidade: Pontuação 2 (Regular) da avaliação da equipe
de desenvolvimento. O software pode não recuperar integralmente os
dados após uma interrupção ocasionada por travamento ou desligamento;
no entanto, os dados digitados pelo usuário são efetivamente salvos
quando da sua confirmação e aceitação pelo software (após consistência);
assim, se houver interrupção durante os lançamentos de dados, o que
estiver sendo lançado se perde, mas os dados anteriores se mantêm,
permitindo assim a sua integridade. Portanto: “Recupera apenas os dados
confirmados”.
• C.3 Usabilidade: Pontuação 3,52 (Excelente) – média simples das suas
subcaracterísticas.
• S.3.1 Inteligibilidade: Pontuação 3,52 (Excelente) da avaliação dos
alunos. O conceito lógico e a aplicação do software foram reconhecidos
pelos alunos, uma vez que a média da avaliação para o item “visão do
assunto” foi de 3,67 (Excelente). Portanto: “Conceito lógico e aplicação
assimilados”.
• S.3.2 Apreensibilidade: Pontuação 3,53 (Excelente) da avaliação dos
alunos. Em todas as aplicações do software, os alunos resolveram
completamente os exercícios concluindo-os satisfatoriamente, o que
enfatiza o aprendizado de sua aplicação. Portanto: “Fácil assimilação para
aplicar conceitos”.
• S.3.3 Operacionalidade: Pontuação 3,5 (Excelente) da avaliação dos
134
alunos. Em todas as aplicações do software os alunos não apresentaram
dificuldades em operá-lo, de forma que o tempo destinado a seu
aprendizado e operação não precisou ser estendido. Portanto: “Fácil
assimilação para operar e controlar”.
• C.4 Eficiência: Pontuação 4 (Excelente mais) – média simples das suas
subcaracterísticas.
• S.4.1 Comportamento em relação ao tempo: Pontuação 4 (Excelente)
da avaliação da equipe de desenvolvimento. Durante as várias
apresentações completas dos recursos do software e uso prático pelos
alunos em vários tipos de hardware (porém compatíveis), observou-se que
o tempo de resposta dos cálculos, gráficos e relatórios tem sido
satisfatório, uma vez que em nenhuma das aulas houve necessidade de
se estender o curso após sua duração normal ou de se encurtar a
apresentação ou exercícios. Isto é confirmado pelos testes realizados
antes e na aplicação. Portanto: “Responde satisfatoriamente à aplicação”.
• S.4.2 Comportamento em relação aos recursos: Pontuação 4
(Excelente) da avaliação da equipe de desenvolvimento. O desempenho
dos recursos utilizados tem sido satisfatório diante dos testes realizados.
Portanto: “Responde satisfatoriamente à aplicação”.
• C.5 Manutenibilidade: Pontuação 3 (Bom) - média simples das suas
subcaracterísticas.
• S.5.1 Analisabilidade: Pontuação 3 (Bom) da avaliação da equipe de
desenvolvimento. O software foi desenvolvido modularmente com
biblioteca de funções, com documentação associada aos blocos, funções
e linhas de programa, que permitem uma boa análise da programação;
mas, esta documentação pode ser melhorada. Portanto: “É modular,
documentado e com bibliotecas”.
135
• S.5.2 Modificabilidade: Pontuação 3 (Bom) da avaliação da equipe de
desenvolvimento. É fácil de localizar onde está a alteração a ser feita, pela
própria documentação que é vasta e de vários níveis, ou, se for o caso,
pelo fato de que há uma biblioteca de funções; bastaria mudar esta função
para se alterar este procedimento em todo o software. Por exemplo, se
houver mudança no acesso ao banco de dados, mudando as funções que
o acessam, automaticamente todos os módulos que utilizem o banco de
dados corresponderão a esta mudança. Portanto: “É modular,
documentado e com bibliotecas”.
• S.5.3 Estabilidade: Pontuação 3 (Bom) da avaliação da equipe de
desenvolvimento. O risco de surgirem problemas após modificações é
baixo, pois, por ser modular, é fácil verificar o resultado da modificação
para o módulo alterado. Além disso, testes padronizados são realizados e
permitem a conferência da alteração. Da mesma forma, com resultados já
conhecidos, fica fácil verificar se houve alterações nos mesmos. Portanto:
“É estável. Baixo risco nas alterações”.
• S.5.4 Testabilidade: Pontuação 3 (Bom) da avaliação da equipe de
desenvolvimento. Por ser modular, fica fácil testá-lo módulo a módulo, o
que ocorreu efetivamente durante o seu desenvolvimento, pois o software
foi desenvolvido a partir de exercícios prontos e com resultados
conhecidos. Quanto a testes de utilização o software já foi amplamente
utilizado em todos os seus itens nas aulas em que foi aplicado. Portanto:
“Modular. Facilmente testado com exemplos”.
• C.6 Portabilidade: Pontuação 1,67 (Insuficiente mais) - média simples das
suas subcaracterísticas.
• S.6.1 Adaptabilidade: Pontuação 1 (Insuficiente) da avaliação da equipe
de desenvolvimento. O software não foi planejado para ser adaptado a
outros ambientes, a não ser o Windows, apesar de haver a possibilidade
desta adaptação com esforço significativo. Portanto: “Existe solução para
136
a linguagem adotada”.
• S.6.2 Capacidade para ser instalado: Pontuação 2 (Regular) da
avaliação da equipe de desenvolvimento. Utiliza software de mercado que
executa completamente e corretamente esta instalação, mas apenas para
um tipo de ambiente. Portanto: “É instalado conforme especificado”.
• S.6.3 Conformidade: Pontuação 2 (Regular) da avaliação da equipe de
desenvolvimento. Não houve a preocupação com portabilidade no início,
porém, a linguagem de programação adotada permite a migração para
outros ambientes com algum esforço adicional. Portanto: “A linguagem
adotada permite migração”.
• S.6.4 Capacidade para substituir: Sem apreciação da equipe de
desenvolvimento. Não há motivo para a substituição de outro software
conforme consta nos requisitos básicos. Portanto: “Item não necessário no
momento”.
As observações sucintas apresentadas foram transcritas para a Tabela 21.
As pontuações apresentadas por característica na Tabela 21 mesclam a
avaliação técnica com a da aplicação e não compreendem a avaliação didática. As
pontuações das características são válidas, porém, somente para a avaliação de um
software didático como produto de software, e não integralmente, onde devem
compreender também o ponto de vista didático. Estas pontuações podem ser
consideradas em uma análise mais específica nas questões técnicas e da aplicação;
no entanto, para este trabalho, importa obter as pontuações de cada característica
para cada ponto de vista avaliado, inclusive para o ponto de vista didático. Assim,
estas pontuações das características, nesse ponto, não fazem parte da metodologia
de avaliação; ficam apenas como referência à análise do produto de software, se for
o caso.
137
Tabela 21 Pontuações e observações sobre o software por subcaracterística da Norma
Característica Item Subcaracterística Pont. Observações sobre o software
S.1.1
Adequação
3,5 É adequado ao assunto e finalidade
S.1.2
Acurácia
3,55 Faz corretamente o que se propõe
S.1.3
Interoperabilidade
2 Interage com os sistemas especificados
S.1.4
Conformidade
3,53 Está em conformidade com o assunto
C.1
Funcionalidade
Pontuação: 3,12
S.1.5
Segurança de acesso
3 É seguro para a finalidade didática
S.2.1
Maturidade
2 Falha na impressão do gráfico de vínculos
S.2.2
Tolerância a falhas
2 Tem consistências e verificador de erros
C.2
Confiabilidade
Pontuação: 2
S.2.3
Recuperabilidade
2 Recupera apenas os dados confirmados
S.3.1
Inteligibilidade
3,52 Conceito lógico e aplicação assimilados
S.3.2
Apreensibilidade
3,53 Fácil assimilação para aplicar conceitos
C.3
Usabilidade
Pontuação: 3,52
S.3.3
Operacionalidade
3,5 Fácil assimilação para operar e controlar
S.4.1
Comp. em relação ao tempo
4 Responde satisfatoriamente à aplicação
C.4
Eficiência
Pontuação: 4 S.4.2
Comp. em rel. aos recursos
4 Responde satisfatoriamente à aplicação
S.5.1
Analisabilidade
3 É modular, documentado e c/ bibliotecas
S.5.2
Modificabilidade
3 É modular, documentado e c/ bibliotecas
S.5.3
Estabilidade
3 É estável. Baixo risco nas alterações
C.5
Manutenibilidade
Pontuação: 3
S.5.4
Testabilidade
3 Modular. Facilmente testado c/ exemplos
S.6.1
Adaptabilidade
1
Existe solução para a linguagem adotada
S.6.2
Capacidade p/ ser instalado
2 É instalado como especificado
S.6.3
Conformidade
2 A linguagem adotada permite migração
C.6
Portabilidade
Pontuação: 1,67
S.6.4
Capacidade para substituir
- Item não necessário no momento
Produto de
software
3,05
Fonte: Autor
Com esses resultados (Tabela 21), tem-se a avaliação final da qualidade do
software didático pelas questões essencialmente técnicas e pelas questões da
aplicação em sala de aula, ou seja, a avaliação de um produto de software. No
entanto, resta a avaliação didática deste software, como será apresentada a seguir.
138
5.2.7 Avaliação e pontuação pelo ponto de vista didático
Uma vez realizada a aplicação do software em sala de aula e obtida a
avaliação dos alunos e também a da equipe de desenvolvimento, coube ao
professor a análise e o preenchimento da avaliação didática do software através do
questionário didático (Tabela 15). Esta avaliação é apresentada na Tabela 22.
139
Tabela 22 Modelo para avaliação didática do software didático pela visão do professor, com base na
Norma ISO 9126
Subcaracterísticas voltadas à aplicação do software didático
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.1.1. Adequação
1 2 3 4
N
A
1
Auxilia o processo de ensino-aprendizagem X
2
Faz a ligação entre a teoria e a prática de forma adequada X
3
Apresenta uma seqüência de forma racional e eficiente X
4
É adequado quanto aos dados da matéria e ao assunto da aula X
5
Favorece o ensino baseado na observação e experimentação X
6
É atualizado quanto ao estado da arte X
7
Faz a ligação de conhecimentos científicos e a realidade do dia-a-dia do aluno X
8
Permite ao aluno entrar em contato com situações concretas de sua vida fora da
escola
X
9
Diminui as dificuldades dos alunos e abre novas perspectivas culturais X
10
Possibilita atividades que direcionem o aluno à compreensão e assimilação da
matéria
X
11
Permite a aplicação adequada para exercícios do tipo “estudo de caso” X
12
Prepara adequadamente o aluno para o mercado de trabalho X
13
Prepara adequadamente o aluno como cidadão X
14
Faz parte adequadamente das estratégias adotadas pelo professor X
15
É adequado à capacidade e limitações reais dos alunos (estabelece exigências e
expectativas que os alunos possam cumprir)
X
16
Promove o interesse geral estimulando o aprendizado X
17
Desperta e mantém a atenção X
18
Incentiva o aluno a perguntar e apresentar questões que o envolvam X
19
É desafiador, suscitando e mobilizando a atividade do aluno X
20
Serve de ferramenta de apoio a exercícios, a esclarecimentos gerais e à fixação
do assunto
X
21
Inicia concretamente o estudo de uma unidade que envolva determinadas
operações ou processos a serem aprendidos
X
22
Funciona como recurso de transposição do tema do plano verbal e simbólico para
o plano real, da palavra para a realidade da ação
X
23
Apresenta todas as informações necessárias de forma adequada X
24
Possibilita inclusões, alterações e exclusões de dados de forma adequada X
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
23
Qtde
Total
de
Pontos:
1 7 15 83
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação: 3,61
140
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.1.2. Acurácia
1 2 3 4
N
A
1
Está de acordo com os objetivos de ensino adotados X
2
Serve de forma eficaz aos objetivos da aula X
3
Realiza satisfatoriamente os procedimentos de demonstração, organização e
aplicação de testes objetivos
X
4
Permite a análise dos resultados de forma adequada X
5
Permite ao professor uma flexibilidade tal, de modo a explorá-lo de diversas
formas, realística e criativamente, segundo seus objetivos
X
6
Atinge os objetivos almejados de maneira segura, econômica e eficiente X
7
Suplementa a palestra ou explanação verbal do professor, tornando-a mais real e
concreta
X
8
Proporciona a recapitulação e comprovação dos conhecimentos teóricos já
adquiridos
X
9
Os exercícios aplicados apresentam os resultados esperados com exatidão X
10
Apresenta a modelagem de forma correta X
11
A apresentação da impressão de dados e relatórios estão corretos X
12
Possibilita a verificação parcial ou gradativa das informações X
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
12
Qtde
Total
de
Pontos:
1 8 3 38
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação: 3,17
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.1.4. Conformidade
1 2 3 4
N
A
1
Está de acordo com as normas, convenções ou regulamentações previstas em
leis e descrições similares, relacionadas à aplicação
X
2
Fornece o modelo e as normas concretas da ação a executar X
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
2
Qtde
Total
de
Pontos:
1 1 7
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação: 3,5
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.3.1. Inteligibilidade
1 2 3 4
N
A
1
Facilita a percepção e compreensão dos fatos e conceitos em estudo X
2
Facilita a apreensão sugestiva e ativa de um tema ou de um fato em estudo X
3
Ajuda a melhor compreender as relações das partes, o todo de um tema, objeto
ou fenômeno
X
4
Auxilia a formar conceitos exatos, principalmente com referência a temas de difícil
observação direta
X
5
Atende ao desenvolvimento das capacidades cognitivas dos alunos X
141
6
Orienta com segurança os alunos para a compreensão e a assimilação X
7
Permite ao aluno relacionar o que está aprendendo com os conhecimentos e
experiências que já possui
X
8
O conceito lógico e sua aplicabilidade são facilmente verificados X
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
8
Qtde
Total
de
Pontos:
5 3 27
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação: 3,38
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.3.2. Apreensibilidade
1 2 3 4
N
A
1
Propicia a retenção do assunto de forma adequada X
2
Propicia ao aluno o domínio de conhecimentos, habilidades e hábitos X
3
Possibilita atividades que direcionem o aluno à compreensão e assimilação da
matéria
X
4
Possibilita ao professor estimular, orientar e facilitar o aprendizado dos alunos X
5
Facilita o ensino do professor X
6
Facilita o aprendizado do aluno X
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
5
Qtde
Total
de
Pontos:
3 2 17
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação: 3,4
1 = Insuficiente 2 = Regular 3 = Bom 4 = Excelente NA = Não se Aplica
Pontuação
S.3.3. Operacionalidade
1 2 3 4
N
A
1
O usuário opera e controla cada operação do software com facilidade X
2
O esforço do professor para aplicá-lo é adequado X
3
O esforço do aluno em utilizá-lo é adequado X
Qtde de
Itens
Pontuados
1 2 3 4
Somatório
Pontos x Peso
3
Qtde
Total
de
Pontos:
3 12
Somatório
Pontos x Peso
Qtde de Itens
Pontuados
Pontuação: 4
Pontuação Final do Software Didático – Avaliação Didática
(Média Simples de todas as Subcaracterísticas que foram Pontuadas)
Pontuação
Didática
3,51
Fonte: Autor
O professor fez as pontuações e os respectivos cálculos por média
ponderada, para obter as pontuações finais por subcaracterística e também a
142
pontuação didática do software avaliado. Como pode ser observado na Tabela 22, a
pontuação didática do software foi de 3,51 (Excelente), enquanto que as
subcaracterísticas voltadas à aplicação receberam pontuações de 3,17 a 4, ou seja,
de Bom mais a Excelente mais. Portanto, tanto o software quanto suas
subcaracterísticas avaliadas pelo ponto de vista didático são adequados.
Neste ponto, as três avaliações foram concluídas, a da equipe de
desenvolvimento, a dos alunos e a do professor. Passou-se então à pontuação geral
do software, considerando as avaliações pelos três pontos de vista.
5.2.8 Pontuações finais do software e para os três pontos de vista.
Para obter as pontuações finais e o nível de pontuação do software didático
avaliado, foi preciso transportar a pontuação de todas as subcaracterísticas
pontuadas na Tabela 20 (ponto de vista da equipe de desenvolvimento e dos
alunos), como também as pontuações das subcaracterísticas da Tabela 22 (ponto
de vista do professor), para a Tabela 23. Cada pontuação em cada subcaracterística
foi lançada na coluna correspondente ao ponto de vista pelo qual recebeu a
pontuação.
Uma vez lançadas as pontuações para as subcaracterísticas, passou-se a
realizar todos os cálculos na Tabela 23, até que fosse integralmente preenchida.
143
Tabela 23 – Avaliação completa das pontuações obtidas do software didático avaliado.
Pontuação por Ponto de Vista
Característica Item Subcaracterística
Técnica Aplicação
Didática
S.1.1 Adequação
3,5 3,61
S.1.2 Acurácia
3,55 3,17
S.1.3 Interoperabilidade
2
S.1.4 Conformidade
3,53 3,5
C.1
Funcionalidade
S.1.5 Segurança de acesso
3
S.2.1 Maturidade
2
S.2.2 Tolerância a falhas
2
C.2
Confiabilidade
S.2.3 Recuperabilidade
2
S.3.1 Inteligibilidade
3,52 3,38
S.3.2 Apreensibilidade
3,53 3,4
C.3
Usabilidade
S.3.3 Operacionalidade
3,5 4
S.4.1 Comp. em relação ao tempo
4
C.4
Eficiência
S.4.2 Comp. em relação aos recursos
4
S.5.1 Analisabilidade
3
S.5.2 Modificabilidade
3
S.5.3 Estabilidade
3
C.5 Manutenibilidade
S.5.4 Testabilidade
3
S.6.1 Adaptabilidade
1
S.6.2 Capacidade para ser instalado
2
S.6.3 Conformidade
2
C.6
Portabilidade
S.6.4 Capacidade para substituir
Ponto de Vista
Cálculos para as
Características
Item Característica
Técnica Aplicação
Didática
C.1 Funcionalidade
2,5 3,53 3,43
C.2 Confiabilidade
2
C.3 Usabilidade
3,52 3,59
C.4 Eficiência
4
C.5 Manutenibilidade
3
Médias das
Pontuações por
Característica e por
Ponto de Vista
C.6 Portabilidade
1,67
Ponto de Vista
Cálculos para os Pontos de Vista
Técnica Aplicação
Didática
Pontuações Finais por Ponto de Vista
2,63 3,52 3,51
Cálculo Final para o Software Didático
Software Didático
Pontuação Final do Software Didático Avaliado
3,22
Fonte: Autor
144
Com as subcaracterísticas pontuadas na Tabela 23, passou-se a realizar os
“Cálculos para as Características”, onde cada característica deve receber a média
simples de suas respectivas subcaracterísticas, pontuadas por ponto de vista. Por
exemplo, para a característica “Usabilidade”:
• Não há subcaracterísticas pontuadas para o ponto de vista técnico;
portanto, o respectivo campo desta característica para o ponto de vista
técnico ficou em branco;
• São três subcaracterísticas pontuadas para o ponto de vista da
aplicação; portanto, o respectivo campo desta característica e do
ponto de vista da aplicação recebeu o valor: (3,52 + 3,53 + 3,5) / 3 =
3,52;
• São três subcaracterísticas pontuadas para o ponto de vista didático;
portanto, o respectivo campo desta característica e do ponto de vista
didático recebeu o valor: (3,38 + 3,4 + 4) / 3 = 3,59.
Nos “Cálculos para os Pontos de Vista”, cada ponto de vista recebeu a média
simples das suas respectivas características pontuadas. Por exemplo, o ponto de
vista didático recebeu a média simples das duas características pontuadas,
“Funcionalidade” e “Usabilidade”, assim: (3,43 + 3,59) / 2 = 3,51.
O “Cálculo Final para o Software Didático” recebeu a média simples das
pontuações dos três pontos de vista, desta forma: (2,63 + 3,52 + 3,51) / 3 = 3,22.
Uma vez obtidas todas as pontuações finais, incluindo a pontuação do
software didático avaliado (Tabela 23), passou-se ao julgamento, como segue.
5.2.9 Julgamento das avaliações
Para o julgamento, o valor de referência 3 (Bom mais), determinado pelo
autor para esta aplicação da metodologia de avaliação, foi utilizado em cada análise
feita sobre os resultados.
145
Apenas a análise da Tabela 23 foi utilizada neste processo de julgamento,
que é apresentado a seguir:
1. Análise da pontuação do software didático como um todo. Na
Tabela 23, no item “Pontuação Final do Software Didático Avaliado”, a
pontuação obtida pelo software didático foi de 3,22 (Bom mais). Esta
pontuação está acima do valor de referência que é 3 (Bom mais),
portanto, o software didático pode ser aceito ou continuado seu uso.
2. Análise das pontuações de cada avaliação do software didático
por ponto de vista. Na Tabela 23, no item “Pontuações Finais por
Ponto de Vista”, foram apontadas as pontuações para cada ponto de
vista, a saber; 2,63 (Bom menos), para o ponto de vista da equipe de
desenvolvimento (técnica); 3,52 (Excelente) para o ponto de vista dos
alunos (aplicação); e 3,51 (Excelente) para o ponto de vista do
professor (didática). Com essas pontuações por ponto de vista, o
software didático não superou o valor de referência apenas no ponto
de vista da equipe de desenvolvimento; mesmo assim, tanto o ponto de
vista dos alunos como o do professor superaram o valor de referência
com nível de pontuação Excelente. As exigências quanto a cenários
futuros nos requisitos básicos deste software fizeram com que a parte
técnica ficasse aquém do esperado; no entanto, pela aplicação didática
em sala de aula estar em um nível de excelência, tanto pela visão dos
alunos como pela do professor, isto demonstra que hoje o software
corresponde satisfatoriamente na parte técnica também; senão,
fatalmente, as pontuações voltadas a aplicação seriam mais baixas.
Portanto, o software didático pode ser aceito ou continuado seu uso,
com a ressalva de se melhorar as questões técnicas para uma nova
versão.
3. Análise das características do software didático por ponto de
vista. Na Tabela 23, no item “Médias das Pontuações por
Característica e por Ponto de Vista”, estão calculadas as pontuações
finais de cada característica para cada ponto de vista (respectivamente
146
de “C.1” a “C.6”). As características que apresentaram pontuações
abaixo da referência (valor 3) foram: “funcionalidade”, “confiabilidade” e
“portabilidade”, respectivamente com as pontuações 2 (Regular), 2,5
(Bom menos) e 1,67 (Insuficiente mais), todas pelo ponto de vista da
equipe de desenvolvimento. As demais características para cada ponto
de vista estão todas acima do valor de referência e atingem o nível de
pontuação “Excelente”. Portanto, quanto à análise técnica do software
para a busca de problemas e ajustes, a prioridade pode ser a seguinte:
verificar primeiro as subcaracterísticas com as menores pontuações da
característica “portabilidade” (menor pontuação das três); em seguida,
as da característica “confiabilidade” (segunda menor pontuação das
três); e, por fim, as da característica “funcionalidade” (por ser a última
das três). Entre as nove características pontuadas, apenas essas três
não alcançam o valor de referência, e ainda assim, apenas na parte
técnica. Portanto, o software didático pode ser aceito ou continuado
seu uso, com a ressalva de se buscar as questões técnicas nas
subcaracterísticas dessas características, a fim de se tomar as
providências necessárias para uma nova versão do software a ser
avaliado.
4. Análise das subcaracterísticas do software didático por ponto de
vista. Na Tabela 23, nos itens de “S.1.1” a “S.6.4”, que são as suas
respectivas subcaracterísticas, estão lançadas as pontuações finais de
cada uma para cada ponto de vista. As subcaracterísticas que
apresentam pontuações abaixo do valor de referência pertencem
apenas ao ponto de vista da equipe de desenvolvimento, e são elas:
“interoperabilidade”, “maturidade”, “tolerância a falhas”, “recupera-
bilidade”, “capacidade para ser instalado”, “capacidade para substituir”,
todas com pontuação 2 (Regular) e “adaptabilidade” com pontuação 1
(Insuficiente). Todas as subcaracterísticas restantes superam o valor
de referência com pontuações de 3 a 4, ou seja, de Bom a Excelente.
Portanto, o software didático pode ser aceito ou continuado seu uso,
com a ressalva de se buscar as questões técnicas nas
subcaracterísticas com pontuações abaixo do valor de referência,
147
iniciando com a subcaracterística “adaptabilidade”, que obteve a menor
pontuação de todas, a fim de se tomar as providências necessárias
para uma nova versão do software a ser avaliado.
5. Julgamento do software didático. Considerando as pontuações
atingidas pelo software didático avaliado, as pontuações finais das
avaliações de cada ponto de vista, as pontuações finais das
características para cada ponto de vista, a pontuação final de cada
subcaracterística para cada ponto de vista e, além disso, as análises
indicadas nos itens anteriores (1 a 4), o julgamento foi favorável ao
software, considerando-o como adequado quanto a ser um “software
didático”. Portanto, foi aprovado para sua continuidade de uso, por
estar dentro do nível de exigência para aceitação e pelo fato dos itens
que não se enquadraram como adequados não afetarem a aplicação
do software no momento. No entanto, outra versão do software, com os
devidos acertos e ajustes, deverá ser desenvolvida e reavaliada,
buscando o enquadramento de todos os seus itens como adequados.
Uma vez que o software didático foi aceito, o passo seguinte foi a realização
de uma reunião do professor com a equipe de desenvolvimento, onde analisaram e
definiram em detalhes o que deve ser feito e como deve ser feito, visando à próxima
versão do software didático.
148
6 CONCLUSÃO
Neste capítulo é apresentada uma discussão sobre o processo de
desenvolvimento da dissertação, sua contribuição, a aplicabilidade da metodologia
proposta e, finalmente, as sugestões para trabalhos futuros.
6.1. Sobre a dissertação
A partir da necessidade de se desenvolver e aplicar um software de custos
ABC em cursos de nível superior, ficou claro que o mesmo não poderia ser
desenvolvido sem a preocupação sobre sua eficiência e qualidade técnica, sobre
sua eficiência e qualidade da aplicação em sala de aula, e sobre sua eficiência e
qualidade como ferramenta de apoio didático.
Não bastaria que o software fosse funcionalmente eficaz em todos os
quesitos técnicos, mas, também, seria necessário que atendesse plenamente aos
objetivos do professor quanto à assimilação da matéria, à visão plena do conteúdo,
à visão dinâmica de uma aplicação do assunto no mundo real e, fundamentalmente,
à melhoria na qualidade de ensino e na aprendizagem em sua disciplina.
Além disso, o software deveria ser fácil de operar, simples na apresentação
dos resultados, claro quanto ao enriquecimento do assunto, motivador e um
facilitador à aprendizagem dos alunos.
Desse modo, não haveria como desenvolver um software para aplicação em
sala de aula sem atentar para estas considerações, ou seja, as questões didáticas.
No entanto, observa-se em geral a falta de preocupação da finalidade didática
em software aplicado em sala de aula em cursos de nível superior, uma vez que a
maioria foi gerada para fins comerciais e para aplicações empresariais, entre várias
outras finalidades que não a didática.
Surgiu então uma questão: Como avaliar um software aplicado em sala de
149
aula de forma a se obter uma resposta quanto à sua eficiência em aplicações de
finalidade didática?
Neste ponto, iniciou-se a pesquisa para a elaboração e desenvolvimento do
presente trabalho.
Como base para o desenvolvimento da metodologia, foi contemplada a
Norma ISO 9126, voltada à avaliação da qualidade de produto de software, que
discorre sobre três pontos de vista para esta avaliação: visão da equipe de
desenvolvimento (visão técnica), visão dos usuários (visão da aplicação) e a visão
do gerente (visão dos objetivos).
Similarmente, para um software didático, os três pontos de vista propostos
seriam: visão da equipe de desenvolvimento (técnica), visão dos alunos (aplicação)
e a visão do professor (objetivos didáticos).
Assim, observando as necessidades didáticas da aplicação de um software
em aula, os três pontos de vista se enquadram nas três necessidades fundamentais
para um software ser didático: ter qualidade satisfatória como produto, ter qualidade
satisfatória para os alunos em sua aplicação e ter qualidade satisfatória em sua
função didática para o professor.
Desta forma, com base na Norma ISO 9126, foram desenvolvidos os
questionários de forma que atendessem aos três pontos de vista citados, buscando-
se enquadrar cada questão dentro das características e subcaracterísticas
peculiares desta Norma.
Se, após a avaliação pelos três pontos de vista, o software for pontuado ao
menos como “satisfatório” em todos eles, o software é considerado como sendo
didático, ainda que não seja aprovado para ser aplicado em sala de aula, por se
esperar que o mesmo fosse pontuado, por exemplo, no mínimo como “Bom” em
todas as avaliações.
Uma pontuação final do software é obtida, o que pode servir, em momento
150
posterior, como referência para se adotar um valor padrão para a aprovação de um
outro software didático; ou, ainda, para acompanhar a evolução de um software
didático diante das melhorias de novas versões e da continuidade de sua aplicação.
6.2. Contribuição
A primeira contribuição deste trabalho está em apresentar uma visão
abrangente e prática quanto ao que se denomina ser “didática”, possibilitando,
assim, reflexões e correções de rota quanto ao assunto para professores de
qualquer área de ensino. Geralmente, professores que não sejam da área de
Educação entendem didática de uma forma simplista, resumindo-se basicamente ao
professor saber dar uma boa aula, na qual os alunos detenham a atenção e
aprendam. Como foi apresentado no segundo capítulo, observou-se claramente que
a didática é muito mais abrangente e complexa do que isso.
Do mesmo modo, contribui com a área de Educação, uma vez que este
trabalho apresenta uma aplicação específica para o ensino superior, com um
software flexível em seu uso e que permite simulações, diferentemente do que
normalmente acontece com software educativo no ensino fundamental, que
apresenta restrições às simulações, e conseqüentemente à utilização da lógica e da
ampla liberdade de raciocínio e, portanto, não atende às necessidades de
aplicações mais amplas.
Por ser indispensável ou inevitável o contato com computadores nos dias de
hoje, com projeções para a ampliação cada vez maior desse fato, o software
também se torna indispensável ou inevitável da mesma forma, uma vez que
hardware e software operam juntos. Assim, outra contribuição é trazer ao leitor o
conhecimento e um exemplo de aplicação da Norma ISO 9126 destinada a ser
aplicada para avaliar a qualidade de um produto de software, em qualquer área de
conhecimento e, ainda, com os pontos de vista e nível de detalhamento desejados.
Outra contribuição está em apresentar para a área de Engenharia de
Software uma metodologia e um estudo de uma aplicação completa da utilização da
151
Norma ISO 9126 destinada à avaliação da qualidade didática de um software.
A aplicação da metodologia em um software específico para ensino de custos
ABC deixa também sua contribuição, pois traz à tona o assunto “custos ABC”, atual
e aplicável na maioria das empresas, onde o crescente avanço das tecnologias e
das complexidades na produção – resultantes de maiores exigências de
consumidores, mercados e da necessidade de ser mais competitivo – fazem-se
presentes. Dentro desse contexto, essas empresas arcam com um constante
aumento dos custos fixos e de sua maior participação nos custos totais, o que faz do
custeio ABC o mais indicado a ser aplicado, pois tem como base as atividades, o
que torna o custo mais acurado em relação a outros sistemas tradicionalmente
adotados. O leitor, nesse caso, inteira-se dos conceitos básicos de custos e da
metodologia do custeio ABC, que pode ser muito útil em uma aplicação futura, na
sugestão da aplicação desta metodologia em casos futuros, no acompanhamento,
ou simplesmente no entendimento de uma implantação de custeio ABC em uma
empresa.
6.3 Sobre a metodologia de avaliação e sua aplicabilidade
O estudo demonstrou a aplicabilidade da metodologia, que pode
potencialmente se estender a outras áreas do conhecimento. A aplicação pode ser
realizada tanto para um software em contínua utilização em sala de aula quanto para
um que seja proposto para futura aplicação. Pode, por outro lado, servir de
orientação na elaboração e acompanhamento de um software a ser desenvolvido ou
em desenvolvimento.
A metodologia permite também a avaliação completa ou parcial do software
(avaliar apenas as questões didáticas, por exemplo); e permite que essa avaliação
seja básica ou o mais detalhada quanto se queira, para as necessidades gerais ou
específicas de análise. Portanto, a aplicação da metodologia de avaliação permite
adaptações às necessidades de cada avaliador por ele mesmo, tornando-a
adequada a seus objetivos de análise.
152
Com a aplicação da metodologia de avaliação, pode-se concluir que a mesma
pode contribuir da seguinte forma:
• Para orientação na elaboração de um software didático;
• Para orientação do acompanhamento de um software didático em
desenvolvimento;
• Para orientação na escolha de um software a ser avaliado para futura
aquisição e aplicação didática;
• Para a avaliação didática de um software que já está sendo aplicado
em sala de aula;
• Para a avaliação didática periódica da aplicação contínua de um
software em sala de aula;
• Para o apontamento de falhas, insuficiências, inadequações,
aprimoramentos e melhorias de um software avaliado, permitindo,
assim, sua condição de adequar-se como didático em nova avaliação,
ou a tomada de providências para uma nova versão mais adequada;
• Para auxiliar – com a experiência da aplicação da metodologia e
respectivamente aos dados históricos – na determinação de notas
mínimas a serem padronizadas em futuras avaliações para considerar
um software como aprovado para aplicação didática.
6.4 Trabalhos futuros
Diante do estudo desenvolvido, abre-se a perspectiva de novos trabalhos de
pesquisa correlatos e/ou complementares:
• Desenvolver novos estudos práticos correlatos, aplicando a
metodologia em sistemas de software didático de outras áreas do
conhecimento;
• Pesquisar novas possibilidades de avaliação, com foco em projeto e
processo de desenvolvimento, para software didático a ser
desenvolvido;
153
• Pesquisar e adequar questões de outras Normas e modelos que
agreguem valor às avaliações constantes desta metodologia de
avaliação; por exemplo, o modelo CMMI-ACQ (Carnegie Mellon
University, 2007), voltado à aquisição de sistemas;
• Pesquisar a adaptação da metodologia para a avaliação didática de
software aplicado via Internet e em outros meios que não os
convencionais.
154
REFERÊNCIAS
ALMEIDA, A.C.R. Gerenciamento de custos baseado em atividades: uma proposta
para o setor florestal. Tese (Doutorado em Engenharia de Produção) - Escola
Politécnica, Universidade de São Paulo, 2002.
BIANCHETTI, L. Da chave de fenda ao laptop - tecnologia digital e novas
qualificações: desafios à educação. 1.ed. Rio de Janeiro: Vozes, 2001. 254p.
BRUNSTEIN, I. ABC – Activity Based Costing. Fundação Carlos Alberto Vanzolini,
material interno, 2001.
BRUNSTEIN, I.; KLIEMANN Neto, J. F. Novas Técnicas de Controle e Custeio de
Processos. Universidade Federal do Rio Grande do Sul. Porto Alegre, RS. 1997.
CANDAU, V. M. (Org.). A Didática em Questão. 25.ed. Petrópolis: Vozes, 2005.
128p.
CARNEGIE MELLON UNIVERSITY, Software Engineering Institute. Guide to
Products and Services, 2007. Disponível em
<http://www.sei.cmu.edu/pub/documents/07.reports/06721-psguide.pdf>. Acesso em
26 out. 2007.
CHING, H.Y. Gestão baseada em custeio por atividades: activity based
management. 3.ed. São Paulo: Atlas, 2000. 184p.
CLAVADETSCHER, C. User involvement, key to success. IEEE Software, mar./abr.
1998.
COGAN, S. Activity-based costing (ABC): a poderosa estratégia empresarial. 1.ed.
Rio de Janeiro: Pioneira, 1994. 129p.
COGAN, S. Modelos de ABC / ABM: inclui modelos resolvidos e metodologia original
de reconciliação de dados para o ABC/ABM. 1.ed. Rio de Janeiro: Qualitymark,
1997. 176p.
COKINS, G. Activity-based cost management, making it work: a manager’s guide to
implementing and sustaining an effective ABC system. 1.ed. McGraw-Hill, 1996.
192p.
FENTON, N. Improve Quality?. IEEE Software, jan. 1996.
FREITAS, A. A.; DORNELLAS, D. V.; BELHOT, R. V. Requisitos profissionais do
estudante de engenharia de produção: uma visão através dos estilos de
aprendizagem. GEPROS: Gestão da produção, operação e sistemas, abr. 2006.
GLADCHEFF, A. P. Um instrumento de avaliação da qualidade para software
educacional de matemática. Tese (Mestrado em Ciência da Computação) – Instituto
de Matemática e Estatística, Universidade de São Paulo, 2001.
155
GUIA ITI – INSTITUTO NACIONAL DE TECNOLOGIA DA INFORMAÇÃO. Guia de
Avaliação da Qualidade de Produto de Software, 2001. Disponível em:
<www.pr.gov.br/abntsoftware/guiaaval.pdf>. Acesso em 10 jun. 2003.
HILST, V. L. S. A tecnologia necessária: uma nova pedagogia para os cursos de
formação de nível superior. 1.ed. São Paulo: Unimep, 1994. 142p.
HORNGREN, C. T.; FOSTER, G.; DATAR, S. M. Cost accounting: a managerial
emphasis. New Jersey: Prentice hall, 1997. 1012p.
ISO 9126 - ABNT - Associação brasileira de normas técnicas - NBR 13596 -
Tecnologia da informação. Avaliação de produto de software. Características de
qualidade e diretrizes para seu uso. Rio de Janeiro, ABNT, 1996.
KAPLAN, R.S.; COOPER, R. Custo e desempenho: administre seus custos para ser
mais competitivo, 2.ed. São Paulo: Futura, 2000. 376p.
KITCHENHAM, B.; PFLEEGER, S.L. The elusive target. IEEE Software, jan. 1996.
LAWRENCE, B. Designers must do the modeling. IEEE Software, mar./abr. 1998.
LIBÂNEO, J. C. Didática, 1.ed. São Paulo: Cortez, 2004. 263p.
LOUREIRO, F. S. Lições de pedagogia e didática geral, 1.ed. Coimbra: 1950. 206p.
MAIDEN, N.A.; NCUBE, C. Acquiring cots software selection requirements. IEEE
Software, mar./abr. 1998.
MARTINS, E. Contabilidade de custos: incluiu o ABC, 9.ed. São Paulo: Atlas, 2003.
378p.
MARTINS, P. L. O. Didática teórica / didática prática: para além do confronto, 8.ed.
São Paulo: Edições Loyola, 2006. 184p.
MASETTO, M. T. Didática: a aula como centro, 4.ed. São Paulo: FTD, 1997. 112p.
MATSUBARA, T. Beyond the black box: open implementation. IEEE Software, jan.
1996.
MATTOS, L. A. Sumário de didática geral, 3.ed. Rio de Janeiro: Gráfica Editora
Aurora, 1960.
NAKAGAWA, M. Gestão estratégica de custos: conceito, sistemas e implementação,
2.ed. São Paulo: Atlas, 1993. 111p.
NÉRICI, I. G. Didática: uma introdução, 1.ed. São Paulo: Atlas, 1993
NIELSEN, J. Let’s ask the users. IEEE Software, mai./jun. 1997.
156
OLIVEIRA, C. C. Ambientes informatizados de aprendizagem: produção e avaliação
de software educativo, 4.ed. São Paulo: Papirus, 2001. 144p.
PRESSMAN, R. S. Engenharia de software, 5.ed. McGraw-Hill. São Paulo, 2002.
872p.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de software: teoria
e prática, 1.ed. São Paulo: Prentice Hall, 2001. 303p.
REEL, J.S. Critical success factors in software projects. IEEE Software, mai./jun.
1999.
WEIDENHAUPT, K.; POHL, K.; JARKE, M.; HAUMER, P. Scenarios is system
development: current practice. IEEE Software, mar./abr. 1998.
157
GLOSSÁRIO
Software: Programas, procedimentos, regras e qualquer documentação associada,
pertinente à operação de um sistema computacional (Norma ISO 9126).
Produto de software: Uma entidade de software disponível para liberação a um
usuário (Norma ISO 9126).
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
