Fundamentos e Gestão da Qualidade de Software (GQS)

I. Qualidade de Software

O principal objetivo é garantir um produto final satisfatório ao cliente.

A qualidade do produto está diretamente ligada à qualidade do processo.

A qualidade possui dois grupos de fatores: Medidos diretamente (defeito por pontos de função) ou indiretamente (manutenibilidade ou usabilidade).

Os Principais Tópicos da Qualidade:

• Fundamentos de Qualidade: cultura, ética, valores, características e melhorias da qualidade de software;
• Gerência do Processo: garantia, verificação, validação, revisões e auditorias de qualidade de software;
• Considerações Práticas: requisitos, caracterização, técnicas de gerência e medidas de qualidade de software.

Garantia da Qualidade de Software (GQS)

A GQS tem o objetivo de fornecer aos níveis gerenciais a visão de todo o processo do projeto. Assim, os gerentes podem atuar de forma pontual em determinados momentos.

CMMI (Modelo de Maturidade em Capacitação - Integração)

É uma estrutura que fornece às empresas um controle e a mensuração de toda a cadeia de processos de desenvolvimento de software.

SWEBOK (Guia para o Conhecimento da Engenharia de Software)

É um documento que apresenta uma classificação. Visa promover uma visão consistente de engenharia de software, e desenvolver certificações e licenciamento de material.

ISO 9126: Norma de Qualidade do Produto de Software

A ISO 9126 é uma norma para a qualidade do produto de software, focada nos seguintes componentes:

• Processo de desenvolvimento do produto;
• Os atributos do produto gerado, seja interno ou externo;
• Qualidade em uso final para o usuário.

A norma propõe atributos de qualidade interna e externa. São eles:

Funcionalidade

Capacidade de prover as necessidades do usuário final.

• Adequação: conjunto de funcionalidades adequadas;
• Acurácia: precisão para fornecer resultados;
• Interoperabilidade: interação do software com outros sistemas;
• Segurança: capacidade de proteger as informações;
• Conformidade: padronização de políticas e normas do projeto.

Confiabilidade

Capacidade de manter o nível de desempenho exigido.

• Maturidade: evitar falhas e defeitos do software;
• Tolerância a Falhas: manter seu funcionamento mesmo com erros;
• Recuperabilidade: capacidade de se recuperar de erros.

Usabilidade

Capacidade de ser compreendido, aprendido e operado pelo usuário.

• Inteligibilidade: facilidade de compreender suas funcionalidades;
• Apreensibilidade: facilidade de ser aprendido pelo usuário;
• Operacionalidade: facilidade de ser operado pelo usuário;
• Atratividade: facilidade de atrair usuários.

Eficiência

Capacidade de executar os recursos de acordo com seu desempenho.

• Comportamento: tempo de resposta e processamento;
• Utilização de Recursos: mede os recursos consumidos e utilizados.

Manutenibilidade

Capacidade de ser modificado e atualizado.

• Analisabilidade: identifica problemas, deficiências ou falhas;
• Modificabilidade: facilidade do software ser modificado;
• Estabilidade: capacidade de evitar danos decorrentes de modificações;
• Testabilidade: capacidade de ser testado após as modificações.

Portabilidade

Capacidade de ser transferido para outro ambiente.

• Adaptabilidade: adaptação a diferentes plataformas;
• Instalação: facilidade de ser instalado em outro ambiente;
• Coexistência: convivência com os demais softwares;
• Substituição: capacidade de substituir outro sistema similar.

II. Reengenharia e Engenharia Reversa

Engenharia Reversa

Engenharia Reversa é um processo de análise de um sistema, identificando seus componentes e os relacionamentos entre as demais partes do sistema.

É executada por especialistas em software, sendo muito importante para a garantia de funcionamento de um determinado sistema.

As razões para a engenharia reversa são:

• Interface compartilhada por outro sistema;
• Sanar deficiências na documentação de um software;
• Resolver problemas de obsolescência;
• Modernizar o software;
• Analisar a segurança;
• Resolver erros ou falhas;
• Aprendizagem.

Reengenharia de Processo de Negócio

A Reengenharia de Processo de Negócio envolve pessoas, equipamentos, recursos materiais e procedimentos. Visa estudar os recursos necessários para a criação de um novo projeto de um produto.

O processo é dividido em 6 etapas:

1. Definição de Negócio: as metas são identificadas por 4 motivadores: redução de custo, tempo, melhoria de qualidade e desenvolvimento pessoal;
2. Identificação do Processo: identificação dos processos críticos e classificação por nível de importância ou mudança;
3. Avaliação do Processo: identificação das tarefas do processo, seus custos e tempos consumidos por cada tarefa, e isolamento dos problemas de qualidade e desempenho;
4. Especificação e Projeto do Processo: preparação dos casos de uso para cada processo que deve ser reprojetado;
5. Protótipo: sua finalidade é testar o processo para que possa ser refinado;
6. Refinamento e Instanciação: com base nas informações do protótipo, o processo é refinado e instanciado em um sistema de negócio.

Atividades da Reengenharia:

• Análise do inventário de todos os aplicativos. Deve ser revisto regularmente, pois os aplicativos mudam em função do tempo;
• Reestruturação dos documentos, devendo ser atualizada sempre que possível;
• Reestruturação dos códigos (o sistema faz a mesma função com mais qualidade que o original) e dados (melhorias físicas, padronização, racionalização) do sistema.

III. Alocação e Gestão de Pessoal e Recursos

Alocação de Recursos no Desenvolvimento de Software

A alocação de recursos no processo de criação de um software compreende meios humanos, softwares reusáveis e ambientes.

• Recursos Humanos: selecionar as aptidões necessárias para o desenvolvimento de um software. Especifica-se a posição ocupada, especialização, quantidade e divisão das equipes.
• Recursos de Software Reusáveis: reutilização de componentes catalogados, padronização e validação. Subdividem-se em:
  • Componentes de Prateleira: software de terceiros ou desenvolvidos anteriormente. Estão prontos para serem adaptados;
  • Componente de Experiência Plena: projetos, dados ou códigos de teste utilizados em projetos anteriores e que são similares ao software atual;
  • Componentes de Experiência Parcial: projetos, dados ou códigos de teste anteriores que podem ser usados no projeto atual, porém é preciso modificá-los;
  • Componentes Novos: softwares novos a serem construídos para o projeto atual.
• Recursos de Ambiente: englobam os softwares e hardwares necessários para a execução do sistema a ser desenvolvido.

Gestão de Projetos de Software

O ato de gerir significa planejar, organizar, monitorar e controlar.

As práticas de gestão incluem: formação de equipe, comunicação, ambiente de trabalho, gerenciamento de desempenho, treinamento, compensação, análise de competência e desenvolvimento de carreira.

Os 4 P's do Gerenciamento de Software

Todo gerenciamento de software é focado nos 4 P's:

• Pessoas: Divididas em Gerentes Seniores (definem os itens de negócio); Gerentes de Projeto (planejam, motivam, organizam e controlam a equipe de desenvolvimento); Programadores (possuem a habilidade técnica necessária para o desenvolvimento do produto); Clientes (especificam os requisitos do software); Usuários (interagem com o software).
• Produto: Deve seguir 3 regras:
  1. O contexto no qual será desenvolvido: se é capaz de se ajustar a um software maior e quais são as restrições impostas pelo sistema;
  2. O objetivo da informação: quais os dados e as informações que serão tratadas pelo sistema;
  3. A função e a performance: qual será o desempenho para o tratamento de dados de entrada e qual será a saída.
• Processo: Uma combinação junto ao produto, pois será necessário decompor todo o sistema para que seja possível entender sua função final. Assim, deve-se seguir a seguinte lista de tarefas:
  1. Desenvolver uma lista de itens para esclarecimentos;
  2. Reunir-se com os interessados para esclarecer os itens pendentes;
  3. Desenvolver conjuntamente uma base documentada do escopo;
  4. Revisar a base, considerando todos os envolvidos;
  5. Alterar a base conforme o necessário.
• Projeto: Deve-se saber e entender o que pode sair de errado. São índices de perigo (riscos):
  • Toda a equipe não entende as necessidades dos clientes;
  • O escopo do projeto está mal ou parcialmente definido;
  • As alterações são mal administradas;
  • A tecnologia muda drasticamente;
  • As necessidades de negócio mudam;
  • Os prazos estão além da realidade;
  • Os usuários são resistentes a mudanças;
  • O patrocínio é perdido;
  • A equipe não possui ou tem falta de profissionais qualificados;
  • Os gerentes e os desenvolvedores não aprendem com erros anteriores.

Estratégias para Sanar Problemas:

A fim de sanar esses problemas, deve-se:

• Buscar a resolução do problema;
• Manter o ímpeto, seja gerencial ou desenvolvedor;
• Rastrear constantemente o andamento do projeto, em todas as suas fases;
• Tomar decisões com astúcia;
• Fazer uma análise pós-projeto, a fim de entender falhas e buscar a melhoria contínua.