Me expressei mal em relação à métrica do post anterior.
Quando disse:
"eu faço uma comparação simples entre o número de métodos que o programador esperava que houvesse na API e o número de métodos que realmente estão lá."
Eu quis dizer: Eu contabilizo quantos dos métodos presentes no pseudocódigo estão na API. A medida é a API tem X% do que o cara espera. Ou seja, eu pego os métodos que ele gostaria que tivesse na API e vejo quantos deles estão presentes nela.
terça-feira, 11 de agosto de 2009
Quantificando facilidade de uso
Estou fazendo a avaliação de usabilidade de uma API. O método que estou seguindo é o "think aloud protocol for APIs" - um método baseado na avaliação de usabilidade de interfaces gráficas e que foi modificado para APIs.
Em linhas gerais, este método consiste em observar programadores durante o desenvolvimento de algumas tarefas que usam a API. A parte do Think Aloud é feita pelo programador. Ele verbaliza quais as dificuldades que encontra pelo caminho para escrever o código de determinada tarefa. Este método, portanto, suporta a avaliação qualitativa de APIs, pois a observação do comportamento do programador é uma de suas bases.
No entanto, como eu sempre gosto de extrair números das coisas que estou avaliando, acabei bolando uma métrica baseada na seguinte frase:
"It is the comparison between what developers expect and what the API provides that is interesting when evaluating the usability of an API" (Steven Clarck)
O que eu fiz foi pedir para que os programadores, sem conhecer a API, fizessem o pseudocodigo de determinada tarefa. A partir daí eu faço uma comparação simples entre o número de métodos que o programador esperava que houvesse na API e o número de métodos que realmente estão lá.
É uma métrica simples, mas acredito que podem tornar as coisas menos subjetivas.
Dessa maneira, acabo me aproveitando de todo o apoio do protocolo para avaliação subjetiva e ainda crio uma métrica que pode servir como resultado quantitativo.
O que acham?
Em linhas gerais, este método consiste em observar programadores durante o desenvolvimento de algumas tarefas que usam a API. A parte do Think Aloud é feita pelo programador. Ele verbaliza quais as dificuldades que encontra pelo caminho para escrever o código de determinada tarefa. Este método, portanto, suporta a avaliação qualitativa de APIs, pois a observação do comportamento do programador é uma de suas bases.
No entanto, como eu sempre gosto de extrair números das coisas que estou avaliando, acabei bolando uma métrica baseada na seguinte frase:
"It is the comparison between what developers expect and what the API provides that is interesting when evaluating the usability of an API" (Steven Clarck)
O que eu fiz foi pedir para que os programadores, sem conhecer a API, fizessem o pseudocodigo de determinada tarefa. A partir daí eu faço uma comparação simples entre o número de métodos que o programador esperava que houvesse na API e o número de métodos que realmente estão lá.
É uma métrica simples, mas acredito que podem tornar as coisas menos subjetivas.
Dessa maneira, acabo me aproveitando de todo o apoio do protocolo para avaliação subjetiva e ainda crio uma métrica que pode servir como resultado quantitativo.
O que acham?
Assinar:
Postagens (Atom)