BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artesanato de software no InfoQ Brasil

  • Não se repita? DRY e o dilema entre código duplicado e alto acoplamento

    O princípio DRY ("Não se Repita") reduz a duplicação de código e os problemas de manutenção resultantes, mas quando é mal aplicado aumenta o acoplamento e reduz a legibilidade. Conheça a opinião de vários especialistas sobre o princípio, suas aplicações e armadilhas.

  • Uma Introdução à Qualidade de Software

    Em dois artigos recentes, David Chappell, CEO da Chappell & Associates, descreve os diferentes aspectos da qualidade de software (funcionais, estruturais e de processo), os grupos de pessoas diretamente interessadas na qualidade (usuários, desenvolvedores e patrocinadores), e o resultado que os defeitos no software causam, sejam eles externos ou internos, ao longo do tempo.

  • Sistemas embarcados: Testes de software e arquitetura em alta

    Em edição recente da revista Chip Design, foi apontado grande crescimento dos sistemas portáveis e sem fio, e o aumento de relevância do software nos sistemas embarcados. Com isso, questões de qualidade precisam de atenção especial, principalmente em sistemas críticos em segurança; e ferramentas de testes e a arquitetura de software se tornam aspectos críticos.

  • Coverity: Código Open Source tem menos defeitos que código comercial

    Estudo realizado pela Coverity Scan, patrocinado pelo Departamento de Segurança Doméstica dos EUA, conclui que o código Open Source tem menos defeitos que código comercial, e que a análise estática de código é eficaz na redução da quantidade de defeitos em software.

  • Dívida técnica custa 3.6 dólares por linha de código, segundo a CAST Software

    A CAST Software divulgou seu segundo relatório anual sobre a dívida técnica em projetos de software. Os dados, compilados a partir da análise de sistemas de 160 empresas com um agregado de 365 milhões de linhas de código, mostraram que os custos podem ser milionários em grandes sistemas.

  • Educação Universitária para Engenheiros de Software é perda de tempo?

    Mitch Harper, cofundador do BigCommerce.com, afirmou em um recente artigo que a educação universitária talvez não seja o melhor caminho para se tornar um engenheiro de software. Segundo Harper, as universidades muitas vezes não preparam seus estudantes para a o dia-a-dia e os desafios de trabalhar como um engenheiro de software.

  • Aceite o inesperado: padrões chave para a entrega efetiva de software

    Dan North apresentou em um keynote recente novos detalhes sobre seus “padrões de entrega efetiva de software”, nos quais defende, entre outras ideias chave, que se deve aceitar a incerteza para alcançar os melhores resultados.

  • Psicologia Aplicada para Engenheiros de Software

    John R. Fox publicou este mês seu livro “Trabalho Digital em um Mundo Analógico”, cujo subtítulo “Melhorando a Engenharia de Software através da Psicologia Aplicada” indica o verdadeiro objetivo: discutir os aspectos psicológicos no contexto de engenharia de software. O foco são os aspectos e práticas psicológicos relevantes para os engenheiros de software.

  • Quando a agilidade não é suficiente: precisamos revisar o Manifesto?

    Steve Denning aponta, em artigo recente, pontos fracos do Agile que precisam ser revistos para responder a mudanças ocorridas nos últimos dez anos após publicação do Manifesto Ágil. Apenas gerar software em funcionamento deixou de ser suficiente: o foco deve ser no encantamento dos clientes. Denning oferece recomendações de mudanças na filosofia Agile para adequação à nova realidade.

  • Se usuários não mudam as configurações, para que configurações?

    Pesquisas recentes por especialistas em experiência do usuário mostram que a grande maioria dos usuários mantém os valores padrão para todas as configurações dos softwares, mesmo perdendo com isso funcionalidades essenciais. O excesso de escolhas e a confiança nos desenvoldedores contribuem para uma situação que prejudica os dois lados da equação usuário-desenvolvedor.

  • O desenvolvimento de software nunca será engenharia?

    Recentemente John Sonmez publicou um artigo polêmico afirmando que Engenharia de Software não pode ser encarada como as engenharias tradicionais.

  • A Sobrecarga de Manifestos

    Por definição, um manifesto é uma declaração pública de princípios e intenções que descreve as motivações, razões e demandas de um grupo. Um dos manifestos mais populares existentes é o Manifesto Ágil. Contudo, o número de manifestos tem crescido de forma epidêmica desde então.

  • O conflito entre Agile e Arquitetura

    Há uma luta constante entre as técnicas ágeis e a arquitetura corporativa. Enquanto o desenvolvimento ágil foca-se em ajustar o planejamento à medida que se ganha conhecimento do domínio, a arquitetura estabelece uma plataforma tecnológica e trata dos atributos de qualidade. A combinação dessas duas dimensões tem sucesso quando as técnicas ágeis são usadas na direção da arquitetura desejada.

  • Código é responsabilidade e risco: quanto menos, melhor

    A mentalidade Lean enfatiza a redução dos estoques, porque sempre há custos associados à sua manutenção. No desenvolvimento de software, costuma-se tratar os requisitos como estoque. Mas e o código?

  • Representando testes ágeis

    Vários membros da comunidade Agile têm explorado estilos para a representação e registro de testes, usando desde listas simples e tabelas, a estruturas lógicas e mapas mentais.

BT