Concrete Logo
Hamburger button

10 apresentações do CBSoft 2014 que você deve conferir!

  • Blog
  • 13 de Outubro de 2014
Share
ARPost-its no CBSoft 2014

#postit com #arpostits no #cbsoft em #maceio #alagoas #augmentedreality #agiledevelopment #cloudcomputing #mobileocomputing

O Congresso Brasileiro de Software (CBSoft) deste ano contou com grandes nomes nas áreas de Engenharia de Software, Arquitetura de Software e Computação de Alto Desempenho. Além disto, uma das ilustres presenças neste evento foi o ARPost-its!

Já já sai do forno um post inteiro dedicado a mostrar para vocês o que este Post-it com borda engraçada é capaz de fazer! Curioso? Pode dar uma espiadinha nos slides!

Enquanto isso, neste post, você pode conferir uma seleção de dez apresentações super interessantes que rolaram neste evento e são muito relevantes para o nosso contexto. Nelas foram abordados temas como esboço de arquitetura de software, competências necessárias em engenheiros de software, testes de mutação, métricas para comparação de desenvolvedores, ciclos curtos de releases e muito mais!

Software Design Sketching

André van der Hoek (University of California, Irvine)

Software Design Sketching

#softwaredesign #sketching on #whiteboards

Assim como Post-its, canetas marcadoras de quadro branco também são um grande peso no orçamento da Concrete Solutions! Mas não somos os únicos. André apresentou estudos profundos sobre a prática de esboçar design de software em quadros brancos. Estes estudos foram baseados em vídeos de sessões de design de software com experts de empresas como Adobe e Intuit.

Por exemplo, você já se perguntou sobre quem contribui mais na frente do quadro branco? É intuitivo pensar que quem está com a caneta na mão domina o design. Mas, na prática, as contribuições de todos os envolvidos na sessão costumam ser equilibradas.

Nessas sessões de design de software, múltiplos diagramas e formas de representação de ideias são desenhados no quadro branco. Ao longo do tempo, o foco transita por estes diversos tipos de representações. Inclusive, múltiplas áreas podem receber o foco ao mesmo tempo.

Essa habilidade de transitar o foco é uma grande vantagem de design no quadro branco em relação às ferramentas de modelagem tradicionais. Ou seja, as ferramentas tradicionais funcionam tal como:

Espera aí! Estamos falando do assunto X. Agora, vamos falar sobre Y…

Os estudos mostram evidências de que o processo de design de software não funciona de maneira consciente e linear por natureza. Inclusive, estudos realizados com estudantes menos experientes mostraram que eles tendem a trabalhar em um assunto por vez, indicando uma distância entre o ensino de engenharia de software e a prática desta área.

Outra grande diferença entre o design de software no quadro branco em relação a programas de modelagem tradicionais é que, na prática, especialistas não se prendem a notações. Inicialmente, conceitos são lançados no quadro e nada mais. As notações não são completas. Eventualmente, caixas e setas são acrescentadas e as notações vão emergindo. Forçar a necessidade de notação desde o início pode atrapalhar a criatividade e reduzir a capacidade de exploração de múltiplas abordagens. E isso é mais uma coisa que estudantes são bastante cobrados em disciplinas de Engenharia de Software (quem nunca perdeu pontos por causa de uma linha errada!?).

Um padrão que deve ser familiar para os que já vivenciaram algumas destas sessões é aquele momento em que todos acham que estão pensando na mesma coisa, mas na verdade estão falando sobre coisas diferentes. Inclusive, é comum que dois experts estejam no quadro chaveando entre os modos síncrono e assíncrono. A princípio, isto pode parecer ruim, já que falha na comunicação pode ser um desperdício. Mas na realidade, foi observado que esses momentos podem ser produtivos para uma maior liberdade de exploração de abordagens. Só é importante, de tempos em tempos, questionar as suposições uns dos outros para promover oportunidades de consenso, ou simplesmente concordar em discordar e continuar o ciclo.

Apesar de todas as vantagens, quadros brancos são ferramentas passivas. Elas não contribuem ativamente para o processo de design. Ao virtualizar parte da experiência do quadro branco, designers de software podem se beneficiar de retornos como, por exemplo, alertas vermelhos e saltitantes em caso de más decisões de design de software!

No final da apresentação, André demonstrou o funcionamento da ferramenta Calico, que enriquece essas sessões de design de software em quadros brancos interativos (ou até mesmo em tablets!). No YouTube é possível encontrar outros demos desta ferramenta.

Software Engineering, Why and What

David Parnas (McMaster University e University of Limerick)

Software Engineering, Why and What

#davidparnas the creator of #informationhiding talking about #softwareengineering

Sim, isso mesmo! Parnas, David Parnas! Parnas criou o princípio de Information Hiding. Parnas negou a viabilidade do projeto “Star Wars”. Parnas é um grande ídolo para muitos desenvolvedores!

Em sua (modesta) opinião, Parnas discursou sobre as habilidades que todo Engenheiro de Software deve dominar:

  • Communicate precisely between developers and stakeholders

  • Communicate precisely among developers

  • Design human-computer interfaces

  • Design and maintain multi-version software

  • Design software for reuse

  • Revise old programs

  • Software quality assurance

  • Develop secure software

  • Create and use models in system development

  • Specify, predict, analyze and evaluate performance

  • Be disciplined in development and maintenance

  • Use metrics in system development

  • Manage complex projects

  • Deal with concurrency

  • Understand and use non-determinacy

  • Apply mathematics to increase quality and efficiency.

Estes tópicos são tratados em detalhes nos slides. Parnas acredita que essas são as habilidades que realmente devem ser aprendidas por estudantes de engenharia de software. É importante separar estas habilidades “universais” e as tecnologias “do momento”. As últimas, amanhã podem esvaecer.

Vale também compartilhar duas sábias dicas de Parnas:

Usem princípios, não apenas recite-os!

“Almost”, em inglês, é mais uma palavra para não!

Parnas terminou a apresentação sugerindo que desenvolvedores, gerentes e professores se questionem se realmente dominam essas habilidades e considerem desenvolver as que estão faltando! Preparou o checklist?

Extracting new metrics from Version Control System for the comparison of software developers

Marcello de Moura (Universidade Federal de Goiás), Hugo do Nascimento (Universidade Federal de Goiás), Thierson Rosa (Universidade Federal de Goiás)

Extracting new metrics from Version Control System for the comparison of software developers

#metrics from #versioncontrol for comparison of #softwaredevelopers

A tomada de decisões baseada em dados já é aplicada em muitas áreas aqui na Concrete Solutions. E uma pergunta que nos fazemos é: Como comparar desenvolvedores em um projeto baseado em métricas? Hugo apresentou uma abordagem que utiliza métricas granulares obtidas do sistema de controle de versão para este propósito.

Um diferencial interessante desta abordagem em relação às ferramentas tradicionais de análise de repositório de códigos é a utilização de dois tipos de métricas: métricas relacionadas ao esforço do desenvolvedor e métricas relacionadas à sobrevivência do código feito por este desenvolvedor (quanto do código desenvolvido permaneceu sem ser modificado ou removido).

As diversas métricas sobre os desenvolvedores são processadas através de Multidimensional Scaling, gerando um gráfico em duas dimensões em que fica fácil comparar e agrupar os desenvolvedores.

A re-validação pelo gerente de projeto mostrou que a abordagem é útil para comparar e agrupar desenvolvedores (o objetivo não é análise individual). A expectativa é que quanto mais métricas descorrelacionadas, melhor será o resultado desta abordagem. Dê uma olhada na apresentação.

On the Extraction of Cookbooks for APIs from the Crowd Knowledge

Lucas Batista Leite de Souza (Universidade Federal de Uberlândia), Eduardo Campos (Universidade Federal de Uberlândia), Marcelo de Almeida Maia (Universidade Federal de Uberlândia)

On the Extraction of Cookbooks for APIs from the Crowd Knowledge

using #crowdknowledge from #stackoverflow to build #cookbooks for #apis

API’s geralmente são feitas por poucos e consumidas por muitos. Eventualmente, esta distância leva a documentações pouco satisfatórias, com poucos exemplos e explicações.

Neste cenário, plataformas como StackOverflow oferecem um complemento a estas documentações. No entanto, o conhecimento está disponível de forma não-estruturada e espalhada.

Quem nunca usou um cookbook para explorar uma nova API? Um clássico é o Jquery Cookbook. Cookbooks oferecem uma alternativa exploratória por meio de receitas. Não é necessário uma pergunta em mente para aprender mais sobre o assunto.

Eduardo apresentou uma abordagem que minera questões “how-to-do-it” sobre uma API no Stack Overflow, monta receitas relevantes e as organiza em capítulos. E assim um cookbook é montado automaticamente!

Para aqueles curiosos sobre as técnicas utilizadas, a seleção de perguntas e respostas foi realizada por uma abordagem baseada em regras e a identificação automática dos capítulos foi através da técnica de Latent Dirichlet Allocation. Confira o artigo completo.

Do Rapid Releases Affect Bug Reopening? A Case Study of Firefox

Rodrigo Souza (Universidade Federal da Bahia), Christina Chavez (Universidade Federal da Bahia), Roberto Bittencourt (Universidade Estadual de Feira de Santana)

Do Rapid Releases Affect Bug Reopening? A Case Study of Firefox

#bug reopening on #mozillafirefox before and after #rapidreleases

Integração contínua, desenvolvimento ágil e ciclos rápidos de releases fazem parte da cultura da Concrete Solutions.

Rodrigo apresentou uma análise baseada em bug reports do projeto Mozilla Firefox em duas fases do projeto: antes e depois da mudança para uma política de releases rápidas.

Os resultados sugerem que o ciclo de releases rápidas aumenta a reabertura de bugs. No entanto, o tempo de resolução de bugs mais difíceis diminuiu consideravelmente: aqueles bugs que demoravam meses para serem consertados são resolvidos em poucas semanas com a nova política de releases rápidas.

Empirical identification of barriers faced by newcomers to Open Source Software projects

Igor Steinmacher (Universidade Tecnológica Federal do Paraná), Ana Paula Chaves Steinmacher (Universidade Tecnológica Federal do Paraná), Tayana Conte (Universidade Federal do Amazonas), Marco Aurelio Gerosa (Universidade de São Paulo)

Empirical identification of barriers faced by newcomers to Open Source Software projects

barriers #newcomers face on #opensource projects

Há na literatura vários estudos procurando definir os fatores que incentivam a retenção de contribuidores, mas e os novatos? Nisso, Igor apresentou um estudo procurando dar o foco na identificação das barreiras enfrentadas por novatos que querem fazer suas primeiras contribuições.

As barreiras foram organizadas nas seguintes categorias:

  • Reception issues

  • Newcomers characteristics

  • Newcomers need orientation

  • Documentation problems

  • Cultural diffferences

  • Technical hurdles

No artigo é possível conferir todas as 58 barreiras identificadas.

Categorizing Faults in Exception Handling: A Study of Open Source Projects

Eiji Adachi Barbosa (Pontifícia Universidade Católica do Rio de Janeiro), Alessandro Garcia (Pontifícia Universidade Católica do Rio de Janeiro), Simone Barbosa (Pontifícia Universidade Católica do Rio de Janeiro)

Categorizing Faults in Exception Handling: A Study of Open Source Projects

#faults in #exceptionhandling at #opensource projects

É triste, mas é verdade: geralmente desenvolvedores negligenciam o tratamento de exceções. Quando estes mecanismos são aplicados, é comum que sejam usados apenas para logging ou para a conhecida má prática de retenção de exceções.

Eiji apresentou um trabalho usando mineração de sistemas de versionamento de código e bases de bugs do Tomcat e do Hadoop para elaborar uma categorização dos diferentes tipos de falhas relacionadas com tratamento de exceções.

Este estudo levantou 10 categorias, ordenadas pelo número de ocorrências:

  • Information swallowed

  • Improper continuation of execution

  • Resource leak

  • Uncaught exception

  • Overly generic catch block

  • Premature termination

  • Throwing wrong type

  • Overly protective try-block

  • Exceptional loop break

  • Excessive throwing condition

A partir desta categorização, estudos poderão investigar como estes tipos de falhas são tipicamente corrigidos, e assim, guias e ferramentas poderão ajudar desenvolvedores a evitar e corrigir estas falhas. Saiba mais no artigo!

Uma Combinação Experimental na Indústria para Avaliar um Método de Classificação de Sistemas de Representação Preferidos de Desenvolvedores de Software

Methanias Colaço Júnior (Universidade Federal de Sergipe), Igor Maciel (Universidade Federal de Sergipe), Mário André Farias (Instituto Federal de Sergipe), Paulo Henrique (Universidade Federal de Sergipe), Manoel Mendonça (Universidade Federal da Bahia)

Uma Combinação Experimental na Indústria para Avaliar um Método de Classificação de Sistemas de Representação Preferidos de Desenvolvedores de Software

preferred #representationalsystems of #software #developers

Diferentes pessoas têm diferentes preferências sensoriais. E é difícil acreditar, mas desenvolvedores também são pessoas! Aqueles mais visuais compreendem melhor através de gráficos e diagramas. Os auditivos preferem ouvir explicações sobre as classes. Já os cinestésicos, preferem meter a mão no código para compreender.

Traçar o perfil dos desenvolvedor pode ser muito útil para melhorar a comunicação nas organizações e times de desenvolvimento.

Methanias apresentou um estudo usando a ferramenta NeuroMiner, que usa mineração de texto para identificar os sistemas de representação favoritos de uma pessoa em um determinado contexto.

Além desta ferramenta, foi desenvolvido um questionário e foram analisados logs das ações dos desenvolvedores com o plug-in de visualização e compreensão de software SourceMiner.

Os experimentos apresentaram forte relação entre os resultados do questionário, a mineração de emails com NeuroMiner e a análise dos logs de ações de SourceMiner.

Growing a Reduced Set of Mutation Operators

Marcio Delamaro (Universidade de São Paulo), Lin Deng (George Mason University – USA), Nan Li (George Mason University – USA), Vinícius Humberto Durelli (Universidade de São Paulo), Jeff Offutt(George Mason University – USA)

Growing a Reduced Set of Mutation Operators

reduced set of #mutationoperators for #mutationtesting

Teste de mutação é uma técnica poderosa para avaliar a qualidade e compreensão de testes de software. Mas os custos relacionados ao tempo de execução e de análise são as principais barreiras para sua adoção. Grande parte destes custos são devidos à redundância gerada por mutantes equivalentes.

Neste trabalho, uma estratégia gulosa de cultivo de operadoes mutantes é usada para que os mutantes equivalentes sejam aniquilados! Desta maneira, não é necessário escolher a priori um conjunto reduzido fixo de operadores de mutação para melhorar a eficiência destes testes.

A apresentação foi bastante dinâmica, contando com a presença de simpáticos bonecos de palito mutantes de duas cabeças!

What does good PhD research looks like?

André van der Hoek (Univerisity of California, Irvine), Sven Apel (University of Passau, Germany), Paulo Borba  (UFPE), Julio Leite  (PUC-­Rio) e Sebastian Uchitel (University of Buenos Aires)

What does good PhD research looks like?

what is good #phdresearch

O evento também promoveu um painel com pesquisadores renomados para levantar a discussão sobre as principais questões enfrentadas por novos estudantes e pesquisadores quanto à qualidade de pesquisas de doutorado.

Para Sebastian, uma boa pesquisa de doutorado deve ser ao mesmo tempo válida, interessante e original. No entanto, ele sugere que o pesquisador deve focar em uma entre as seguintes qualidades: ou a pesquisa deve ser extremamente útil ou ela deve ser criteriosamente esclarecedora. A seu ver, o meio do caminho pode ser um beco sem saída.

Júlio complementou a discussão com a seguinte frase:

Data is dear. Ideas are gold. Code is king

Além de caracterizar o que é necessário para uma fantástica pesquisa de doutorado, foi também abordado o que seria uma pesquisa boa o suficiente. Neste contexto, foi discutido que é melhor comprometer o lado visionário e atrevido, mas não comprometer o método científico, o foco no estudante de doutorado (não na pesquisa) e a honestidade sobre os trade-offs associados com a jornada.

As questões humanas na relação entre o estudante de doutorado e seu professor orientador foi um tópico quente neste painel. Foi levantado que os estudantes não devem tomar a decisão baseando apenas na área de expertise, sem conhecer o orientador. A escolha do orientador pode ser o fator mais importante para o sucesso da pesquisa.

E aí? Gostou?

Esta foi apenas uma amostra do que rolou no CBSoft 2014. Aposto que ficou ansioso pelo próximo! O CBSoft 2015 já tem data e local: o evento acontecerá de 21 a 29 de Setembro em Minas Gerais. Fique atento!

Dúvidas? Só deixar nos comentários. Até a próxima!