Qualidade de Software

Resumo - Gerenciando a Qualidade de Software com Base em Requistos

Obter qualidade nos processos e produtos de engenharia de software não é uma tarefa tão fácil. São vários os fatores que dificultam atingir os objetivos de qualidade. Mas, o principal objetivo é o software atender a necessidade do usuário, E em muitos casos, muitos recursos são gastos, mas ainda assim ocorre uma grande frustração por parte dos clientes com o produto final. Muitos desses problemas são derivados da falta de atenção na divisão das tarefas durante a produção do software.

Para diminuição desse problema, e o melhoramento da qualidade do software, é necessário usar o chamado baseline de requisitos. Baseline é uma definição que toma por base as necessidades dos clientes, serve de referência para o desenvolvimento de software e está em constante evolução.

CLIQUE AQUI PARA SABER APROFUNDADAMENTE SOBRE BASELINE.

INTRODUÇÃO

Quando se fala em qualidade de software é necessário termos claro que o processo de produção também deve ter qualidade e não apenas o produto software.
Durante muito tempo, a qualidade do software era entendida da seguinte forma:

• Qualidade do produto é função principalmente de teste do produto
final.

• O processo de produção era centrado em fases caracterizadas por produtos bem
definidos.

• Tinha-se uma ênfase na qualidade das representações, isto é nas linguagens artificiais.

De fato, esses aspectos são também essenciais para a qualidade do produto. Todo software precisa dos testes finais que é onde se encontram os erros e os requisitos que se faltam. A escolha de qual linguagem de programação adotar é também um fator importante no processo. Se tem a visão de sequencialidade, onde acredita-se ser a chave para produtos bem definidos.

Hoje tem-se uma visão muito mais abrangente. Primeiro, sabe-se que o processo de produção é fundamental para obtenção de produtos de qualidade. Segundo, tem-se uma visão mais equilibrada dos aspectos essenciais e acidentais da engenharia de software. Terceiro, a sociedade passa a entender melhor os custos relacionados com a evolução do software. Hoje o processo de produção de software é composto por diferentes subsistemas, como Gerência, Análises e outras.

QUALIDADE

O software passou cada vez mais a fazer parte de outros produtos, e assim como eles exige-se qualidade e preço. Esse é o papel da Engenharia: procurar sistemas de melhor qualidade dentro de um custo compatível com essa qualidade, otimizando a redução de custos.

Como foi dito, ela envolve métodos, técnicas e ferramentas para este fim (Clique aqui para ver). O principal objetivo é que o software seja confiável, isto é seja eficaz e siga os padrões exigidos pelo contexto onde irá atuar. Freeman faz uma distinção entre qualidade básica e qualidade extra. Em qualidade básica ele lista: funcionalidade, confiabilidade, facilidade de uso, economia e segurança de uso. Em qualidade extra ele lista: flexibilidade, facilidade de reparo, adaptabilidade, facilidade de entendimento, boa documentação e facilidade de adicionar melhorias. Este tipo de classificação nos fornece uma idéia do que estamos falando, mas é importante ressaltar que dar prioridade à essas qualidades depende de cada caso e do custo de cada uma dessas qualidades. A qualidade deve estar presente não só nos produtos produzidos, como também nos processos utilizados para gerar esses produtos. Assegurar a qualidade dos produtos e dos processos é responsabilidade do subsistema GERÊNCIA, e este dever toda uma equipe onde o auxiliará. Com isso, percebe-se que é também muito importante não esquecer que a produção de software é um processo que envolve, como parte fundamental, seres humanos, portanto o ambiente de trabalho precisa ser o máximo “humanizado”, com tarefas definidas a cada pessoa e ele não se sobrecarregará com todo processo de produção.

REQUISITOS

Engeharia de Requisitos, é uma sub-área da Engeharia de Software, que tem por obejtivo melhorar a modelagem de sistemas e a capacidade de analisá-los, possibilitando assim, maior entendimento de suas características antes da implementação. É seu papel realizar a interação entre requisitantes e desenvolvedores, entre “o que” deve ser feito e “como” deve ser feito. Para isso estabelece um processo no qual é necessário, analisar conflitos, validar, priorizar, modificar e reusar requisitos.

O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares, 2005):

1 - Indentifição.
2 - Análise e negociação.
3 - Especificação e documentação.
4 - Validação.

Os requisitos de softwares estão dividiso em dois:

1 - Requisitos Funcionais: está diretamente ligado a funcionalidade do software, isto é, uma operação, cujo qualquer usuário pode manter com o software, calcular um média de um aluno, por exemplo.

2 - Requisitos não Funcionais: reflete os requisitos que expressam restrições que o software deve atender ou qualidades específicas que o software deve ter, por exemplo, num sistema acadêmico um aluno não pode ter acesso à alteração de notas, porém pode visualizar as notas.

EVOLUÇÃO

O processo de construção de software será cada dia mais baseado no conceito de evolução, ou seja estaremos sempre modificando algum software já existente, isso quer dizer que o software nunca estará 100% completo, por mais que ele esteja atendendo as necessidades do usuário, é o que chamanos de impossibilidade da completeza.

Acreditamos que para lidar com evolução é fundamental utilizar o conceito de baseline oriundo da área de configuração de sistemas. Um baseline é uma espécie de referencial que utilizamos num processo de mudança, por exemplo, uma 'imagem' de versão de cada artefato no repositório do projeto.

É claro que a complexidade de controlar essa baseline é não trivial, no entanto é uma maneira integrada de tentarmos garantir que a alocação dos requisitos, tanto funcionais como não funcionais seja registrada e rastreável. Assim, é possível efetivamente gerenciar os requisitos, principalmente num contexto volátil.

Qualidade de Software: Teoria e Prática, Orgs. Rocha, Maldonado, Weber, Prentice-Hall, São Paulo, 2001. Capítulo 17.