Engenharia de Software

Foco na Qualidade de Software

Imagem

O ciclo de vida de um produto de software apresenta atributos que são influenciados uns pelos outros. O processo influencia no produto, que por sua vez influenciará na qualidade em uso. Fazendo o caminho inverso, há uma dependência entre estas características. A qualidade em uso depende da qualidade do produto, que depende a qualidade do processo de desenvolvimento. Assim, percebe-se a importância de um foco constante na qualidade do processo de software, pois ele garantirá uma padronização das atividades, das práticas e dos artefatos.

Imagem

É comum parar e ficar pensando se é realmente necessária a prática da padronização através de um processo. Por que a padronização dessas práticas é tão importante? A resposta parece simples. Objetiva. A padronização força a reflexão sobre as práticas, que estão sendo desempenhadas pela equipe do projeto, e somadas a isso, a definição expressa problemas no processo e facilita a identificação dos pontos de melhoria.

Qualidade no CMMI

O foco na qualidade é tão importante que o CMMI-dev definiu uma Área de Processo (PA) no nível 2 (Gerenciado) do Modelo de Maturidade, denominada Garantia da Qualidade de Processo e Produto. O propósito principal dela é “Munir a equipe e a gerência com uma visão clara sobre os processos e seus produtos de trabalho associados”. Além disso, define dois grupos e práticas específicas, são elas:

  1. Avaliar Objetivamente processos e produtos de trabalho
  2. Fornecer um entendimento objetivo

Qualidade no MPS-BR

Assim como o CMMI, o MPS-BR define níveis de maturidade de uma organização. Logo, o nível F (Gerenciado) define algumas práticas que devem ser seguidas para garantir a qualidade dos produtos desenvolvidos. Entre elas está o processo de Garantia da Qualidade (GQA) que tem como principal propósito “garantir que os produtos de trabalho e a execução dos processos estão em conformidade com os planos e recursos predefinidos”. Assim, para atingir este propósito, o MPS-BR define alguns resultados esperados para este processo, são eles:

  1. A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues e em marcos predefinidos ao longo do ciclo de vida do projeto;
  2. A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente;
  3. Os problemas e as não-conformidades são identificados, registrados e comunicados;
  4. Ações corretivas para as não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. Quando necessário, o escalamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução.

Qualidade na ISO/IEC 9126

Esta norma trata especificamente sobre os atributos de qualidade de software e possui uma abordagem que facilita o entendimento das características que afetam diretamente a qualidade. Ela se divide em 4 partes, como subconjuntos da mesma.

  • 9126-1: Modelo de Qualidade
  • 9126-2: Métricas Externas
  • 9126-3: Métricas Internas
  • 9126-4: Métricas de Qualidade em Uso

Um detalhamento maior sobre a norma ISO/IEC pode ser encontrado nas referências deste artigo.

Conclusão

Por fim, quando há foco na qualidade, há um pensamento contínuo em melhorar o processo de produção/desenvolvimento dos produtos. O grande benefício de ter foco na qualidade do processo, é que o resultado estará expresso na qualidade dos produtos desenvolvidos a partir dele.

Referências

  1. ISO/IEC 9126
  2. Análise dos Impactos na Qualidade De Software em Instituições Financeiras Segundo a Norma ISO/IEC 9126 na Adoção das Práticas de Testes do Modelo CMMI
  3. Página principal do MPS-BR
  4. Melhoria de Processos do Software Brasileiro
  5. CMMI
  6. CMMI for Development, Version 1.2

Code Smells

É interessante como nunca me ensinaram isso na faculdade. Quando uma pessoa aprende a desenvolver sistemas, também deveria aprender como não desenvolver. Principalmente isto. Assim, você pode focar na solução que deseja desenvolver e saberá se está fazendo algo muito errado. Saberá também quais as melhores práticas de desenvolvimento e, melhor ainda, poderá deixar seu código mais claro, conciso e flexível.
Sabe aquele código que você olha e sente um mau cheiro? Alguns pensam, outros preferem falar em voz baixa: – “Nossa, é um perigo mexer aqui”. Ou pior do que isso, você lê aquele comentário no início da classe: “Só Jesus entende o código abaixo, melhor você cair fora”. Pronto, você agora sente a prensença de um code smell.
Um code smell é uma parte do código fonte do seu programa que poderá causar algum problema. Na literatura existem vários padrões já identificados e difundidos. A partir destes padrões você pode avaliar seu código e verificar se ele está muito mau-cheiroso.
A Industrial Logic disponibilizou uma lista dos padrões de code smells mais conhecidos e das possíveis técnicas de refatoração que você pode utilizar para eliminar estes problemas. Acredito ser uma lista muito boa para consultar naquele momento em que queremos alterar o código fonte e tentar melhorá-lo.

Code smells mais comuns

Alguns autores preferem dividir a lista de code smells comuns em duas partes, os que estão em uma classe e os que envolvem mais de uma classe. Mas como o objetivo do post é ser introdutório, apresentarei uma lista única. São eles:

  • Comentários
  • Código duplicado
  • Método longo
  • Classe muito grande
  • Muitos parâmetros
  • Recurso invejoso
  • Intimidade inaproriada
  • Herança recusada
  • Classe preguiçosa
  • Complexidade inventada
  • Identificadores excessivamente longos
  • Identificadores excessivamente curtos
  • Uso excessivo de literais

Agora tenha muito cuidado quando decidir alterar uma parte do seu sistema que esteja “funcionando”. Tenha testes que garantam o comportamento do seu sistema, pois a chance de você inserir outros erros, ao tentar eliminar os maus cheiros, é grande! Muita calma nessa hora. Refatorações devem ser controladas, objetivas e pequenas para que tenham os resultados desejados.

E melhor do que ficar lendo sobre code smells aqui, é procurar mais informações e ler um pouco mais sobre o assunto. Comece por esta lista de links:

  1. Code smells by Wikipedia
  2. Code smells by Jeff Atwood in Coding Horror
  3. Code smells to refactoring, quick reference by Industrical Logic
  4. Badsmells to refactoring by java.net
  5. Code smells e refactoring by Carlos Duarte

BPM – Business Process Management

Business Process Management

O Gerenciamento de Processo de Negócio (tradução de Business Process Management) é uma metodologia de otimização de processos que une gestão de negócio com tecnologia da informação, com foco em maximizar os resultados das organizações através da melhoria dos processos de negócio[1].

Para Swenson[2] é muito importante observar as diferenças entre um BPM e Engenharia de Software, pois são conceitos que estão sendo confundidos. Ele mostra diferenças cruciais entre um engenheiro de processo e um engenheiro de software, mostrando a importância de ter uma pessoa focada nos objetivos e na melhoria dos processos da empresa, em vez de uma pessoa focada em informatizar, automatizar ou codificar os processos.

  1. BPM => http://pt.wikipedia.org/wiki/Business_Process_Managemen
  2. BPM não é engenharia de software => http://www.bpm.com/bpm-is-not-software-engineering.html
Veja mais artigos sobre BPM.