10 Simples Regras para Desenvolvimento de Softwares Usáveis na Biologia Computacional

Com a alta tecnologia disponível e sua ascensão exponencial, equipamentos de análises laboratoriais estão produzindo uma grande massa de dados no qual está tornando difícil para os softwares acompanhar o ritmo das pesquisas em torno da biologia, pesquisas então mostram que os cientistas não estão felizes com os softwares atuais, acrescentando que o mercado carece de habilidades que contemplem a resolução de problemas complexos, pois há também um pequeno número de Biólogos Arquitetos de Sistemas, no qual são necessários para preencher esta lacuna.

Para aliviar isso, vários desafios relacionados já foram abordados como reprodutibilidade, eficácia e desenvolvimento de software livre, surgindo então mais um tema de grande importância que é a Usabilidade de Interface.

Usabilidade é comumente definida como “uma medida de qualidade de interface que se refere à eficácia, eficiência e satisfação com que os usuários podem realizar tarefas com uma ferramenta.” Considerando a natureza subjetiva deste tópico, um amplo consenso pode ser difícil de Alcançar. No entanto, boa usabilidade é imprescindível para alcançar ampla aceitação de uma ferramenta de software na comunidade.

Em muitos casos, o software acadêmico começa como um protótipo e assim que o desenvolvedor perceber que a complexidade dos problemas resolvidos pelo software pode torná-lo amplamente aplicável, o software crescerá para atender às novas demandas. Infelizmente, os esforços no desenvolvimento de software científico são limitados por um financiamento limitado, tempo e rápida rotatividade de membros do grupo. Como resultado, o software científico é muitas vezes mal documentado, não-intuitivo, pouca ou nenhuma usabilidade. Não surpreendentemente, uma fração substancial dessas ferramentas são provavelmente abandonware; Isto é, estes não são mais desenvolvidos ou apoiados ativamente apesar do seu potencial valor para a comunidade científica.

Para nosso conhecimento, o desenvolvimento de software como parte da pesquisa científica é geralmente realizado por indivíduos ou pequenas equipes com não mais do que dois ou três membros. Assim, a responsabilidade de projetar, implementar, testar e documentar o código baseia-se em poucos braços. Além disso, há pressão para produzir resultados publicáveis ​​ou, pelo menos, para contribuir com trabalhos de análise para projetos em andamento. Conseqüentemente, o software acadêmico é normalmente lançado como um protótipo. Para tanto, 10 regras simples forma selecionadas afim de que tenham um impacto considerável na melhoria da usabilidade do software científico.

Regra 1: Identificar as peças em falta

A menos que você seja um pioneiro, e poucos de nós são, o problema que você está trabalhando é provavelmente abordado por ferramentas existentes. Como um profissional, você está ciente deste software, mas pode considerá-lo pesado, não-funcional, ou de outra forma inaceitável para suas demandas. Certifique-se de que seu julgamento é compartilhado por uma fração substancial dos usuários em potencial antes de começar a desenvolver uma nova ferramenta. Software utilizável deve oferecer os recursos necessários e se comportando como esperado pela comunidade. Além disso, uma nova ferramenta precisa fornecer novidade substancial sobre as soluções existentes. Para isso, liste os requisitos no software e crie uma tabela de comparação para definir a nova ferramenta contra soluções existentes. Isso permite o mapeamento dos pontos de venda de sua ferramenta de forma sistemática.

Regra 2: Coleta de comentários de usuários em potencial

Software pode ser considerado como fornecedor da interface entre a ciência de laboratorial e análise de dados. A falta de comunicação entre os dois lados levará a mal-entendidos que precisam ser corrigidos, mudando substancialmente a base de código em uma fase tardia do projeto. Evite essa armadilha expondo os potenciais usuários a um protótipo. Discussões sobre formatos de dados ou sobre o design da interface do usuário irá revelar desafios imprevistos e ajudar a determinar se uma ferramenta é suficientemente intuitiva. Para planejar seu progresso, mantenha um registro das melhorias sugeridas e problemas existentes.

Regra 3: Prepare-se para o crescimento dos dados

Primeiro deve-se estimar o crescimento de dados esperados em seu campo de atuação e, em seguida, projetar o seu software em conformidade. Para isso, considere a paralelização e certifique-se de que sua ferramenta pode ser integrada com sistemas de gerenciamento de fluxo de trabalho (por exemplo, GALAXY e Taverna ), frameworks pipeline (por exemplo, Ruffus e SnakeMake ) ou Uma estrutura de cluster (por exemplo, Hadoop, http://hadoop.apache.org/). Além disso, certifique-se de que a interface do usuário pode escalar para volumes de dados crescentes. Por exemplo, considere que as visualizações ainda devem ser compreensíveis para conjuntos de dados maiores, exibindo apenas partes dos dados ou através da agregação de resultados.

Regra 4: Usar formatos de dados padrão para entrada e saída

Como especialista em seu domínio de pesquisa, você conhece os padrões de dados estabelecidos e bibliotecas de programação relacionadas para leitura e gravação de formatos de dados comumente usados. Certifique-se de que a saída da sua ferramenta segue as especificações dos padrões conhecidos, mas seja o mais leniente possível quando os usuários fornecem entrada não padrão, ou seja, se antecipar às probabilidades de inputs e convertê-las. As ferramentas que seguem esta regra têm maior probabilidade de se tornarem bem-sucedidas. Se você estiver trabalhando em um campo emergente sem modelo predominante para troca de dados, forneça dados em um arquivo de texto estruturado (por exemplo, tabelas separadas por tabulação, XML / XSD ou JSON) e aponte para auto-documentação de saída, incluindo linhas de cabeçalho e Descrições de tipos de dados. Neste caso, documente como os usuários podem obter dados de entrada adequados para sua ferramenta.

Regra 5: Exponha apenas os parâmetros obrigatórios

Expor todos os parâmetros (possíveis) para um usuário pode ser confuso e acarreta o risco de ajustes de parâmetros sem sentido. Quando possível, os usuários dependerão de parâmetros padrão. O mesmo se aplica aos estudos comparativos que comparam a sua ferramenta com os concorrentes de ponta. Isso tem três implicações importantes: (i) expor apenas um pequeno conjunto de parâmetros por padrão cujos efeitos sobre os resultados podem ser facilmente compreendidos por qualquer usuário, (ii) oferecer parâmetros avançados somente em uma seção especializada e descrevê-los completamente na documentação e (Iii) escolher de forma conservadora (e, se possível, justificar) os valores padrão para os parâmetros, de modo que a ferramenta possa operar em uma ampla gama de cenários e dentro de um tempo de execução razoável.

Regra 6: Esperar que os usuários cometam erros

Você nunca deve assumir que sua ferramenta é auto-explicativa, que os requisitos relativos aos dados de entrada são óbvios, ou que o usuário irá imediatamente compreender todos os detalhes do problema em questão. Idealmente, sua ferramenta suporta o usuário em usá-lo apropriadamente, por exemplo, verificando se os dados permanecem dentro de intervalos requeridos ou se os identificadores são exclusivos e fornece mensagens de erro descritivas no caso de valores inesperados. Se as penalidades de desempenho devido a tais verificações são uma preocupação real (que deve ser testada), faça as verificações opcionais e ativadas por padrão. Finalmente, permita que os usuários interrompam as operações em curso, caso percebam que cometeram um erro.

Regra 7: Fornecer informações de registro

Dois tipos de logs melhoram a usabilidade e também ajudam o usuário a tornar sua pesquisa mais reprodutível. Os registros de configuração mantêm o controle das informações básicas, como o carimbo de data / hora da análise, a versão de sua ferramenta e de bibliotecas de terceiros, bem como as configurações de parâmetros e os dados de entrada. O arquivamento dessas informações é particularmente importante em projetos de pesquisa de longa duração, a fim de rastrear irregularidades nos resultados em qualquer momento posterior. Os logs técnicos, por outro lado, contêm mensagens de progresso que ajudam os usuários a identificar erros no fluxo de execução e permitir uma comunicação clara desses problemas para o desenvolvedor. Tanto quanto possível, evite expor informações de usuários potencialmente sensíveis nos logs.

Regra 8: Faça com que os usuários comecem rapidamente

As rotinas de configuração complexas introduzem dependência ou dúvidas de configuração ; Isto é, o utilizador tem de gastar um tempo substancial a instalar o software e a aprender sobre os parâmetros de execução de uma ferramenta, dispendendo tempo no que não é o foco. Essas questões podem ser resolvidas através de um executável autônomo ou fornecendo um pacote de software específico do sistema. Alternativamente, os problemas de dependência de um programa em bibliotecas de terceiros podem ser evitados encapsulando sua ferramenta em uma imagem de máquina virtual ou, por exemplo, um container Docker (https://docker.com) ou Serviços da Amazon AWS. Finalmente, é imperativo fornecer dados de demonstração que permitam aos usuários interagir imediatamente com o software. Uma execução de teste bem-sucedida prova ao usuário que seu software funciona como esperado e será essencial se você quiser que sua ferramenta seja publicada.

Regra 9: Oferecer material de aprendizagem

Os pesquisadores raramente têm tempo suficiente para ler completamente os manuais complexos do usuário. Eles vão, portanto, apreciar um número de exemplos de código claramente escrito, ilustrações ou moldes de tela de vídeo para começar. Mais importante ainda, os casos de uso documentados permitem aos usuários avaliar rapidamente se sua ferramenta é adequada para o problema em questão e permitir uma aprendizagem rápida ao fazer. Tenha em mente que esses materiais precisam ser atualizados juntamente com sua ferramenta.

Regra 10: Considere o futuro da sua ferramenta

Para a disponibilidade de seu software a longo prazo, use repositórios adequados, como GitHub (https://github.com) ou Bitbucket (https://bitbucket.com) durante todo o processo de desenvolvimento. Explique de forma explícita em que licença de software você libera seu código para terceiros (consulte https://opensource.org/licenses). Sem essa licença, usar seu software pode ser proibitivo para muitas organizações ou empresas. Mais importante ainda, manter seu código em um repositório público também permitirá que você se envolva com os usuários através de acompanhamento de problemas (por exemplo, bugs, sugestões). Após liberar sua ferramenta, espere pedidos de suporte e leve-os a sério. Veja-os como uma oportunidade para melhorar continuamente a usabilidade de sua ferramenta.

Conclusões

Nas dez regras simples acima, destacou-se que o software não deve ser apenas cientificamente sólido, mas também ser percebido como utilizável e eficaz para aplicação generalizada. Para estes fins, os desenvolvedores também devem ser os primeiros a aplicar sua ferramenta, para revelar problemas de usabilidade o mais cedo possível. No entanto, é necessário esforço de ambos os usuários e desenvolvedores para melhorar ainda mais uma ferramenta. Mesmo envolvendo apenas alguns usuários (Regra 2) é provável que tenha um grande impacto sobre a usabilidade, uma vez que, como Jakob Nielsen colocou, “Zero usuários dão zero insights.”

Outras leituras:

Usability is an important topic in software design, and we would like to provide a few starting points for further reading:

Show your support

Clapping shows how much you appreciated Rodney Neville’s story.