Questões do capítulo 24 do Livro IAN SOMMERVILLE -

Engenharia de software.

24.1. Explique por que um processo de software de alta qualidade pode levar a
produtos de software de alta qualidade. Discuta os possíveis problemas com
esse sistema de gerenciamento de qualidade.

Porque com um processo de alta qualidade teremos padrões e procedimentos bem

estruturados e definidos assim como um gerenciamento de qualidade, o que leva a um
produto de software com uma alta qualidade. Pode haver alguns problemas
relacionados ao fato de que um processo de alta qualidade requer uma especificação
completa, o que é muito difícil de ter, pois a especificação nunca está completa e
geralmente vai evoluindo durante o processo de desenvolvimento, neste ponto a alta
qualidade do processo pode atrapalhar o desenvolvimento do produto.

24.2.Explique como os padrões podem ser usados para capturar a sabedoria

organizacional a respeito de métodos eficazes de desenvolvimento de software.
Sugira quatro tipos de conhecimentos que possam ser capturados em normas
organizacionais.

O plano de qualidades deve estabelecer as qualidades desejadas para o software e

descrever como elas devem ser avaliadas. Introdução ao produto, Planos de produto,
Descrição do processo, Metas de qualidade.

24.3. Discuta a avaliação de qualidade de software de acordo com os atributos

de qualidade mostradas naTabela 24.1 Você deve considerar cada atributo e
explicar como ele pode ser avaliado.

Atributos de software em geral são importantes, pois “demonstram” a qualidade do

produto de software final. Porem cada atributo pode ser especializado em níveis
diferentes, o que vai depender do domínio da aplicação. Segue alguns atributos e uma
forma de como avaliá-lo:

Segurança – Atributo de grande importância e muitas vezes de alto risco dependendo

da aplicação. Segurança pode ser avaliada de inúmeras formas dependendo do nível
de risco da sua aplicação. Em geral uma forma de avaliar segurança é um controle de
acesso bem definido, certificados de segurança entre outras.

Proteção – Atributo que pode depender de outro atributo, como da segurança, por
exemplo, a sua avaliação deve ser feita em conjunto.

Confiabilidade – Um atributo genérico, que envolve a qualidade de vários atributos

para determinar a sua própria qualidade.

Robustez – Vai depender da plataforma e da tecnologia usada, e para avaliá-lo

dependeria estritamente da necessidade do usuário.

Facilidade de compreensão – Depende também de outros atributos como “usabilidade”

assim como do usuário a utilizar.
Testabilidade – Vários fatores afetam esse atributo entre eles está a complexidade do
código, lógica de desenvolvimento, lógica da solução e principalmente de outro
atributo a modularidade.

Facilidade de adaptação – Depender da usabilidade do usuário com o software entre

outros aspectos.

Modularidade – Irá depender da lógica utilizada no desenvolvimento, e para avaliá-lo

será necessário um estudo sobre a lógica aplicada.

Complexidade – Assim como outros atributos a complexidade irá depender da lógica

aplicada, isso em relação ao funcionamento do software. Quanto a “complexidade de
uso” irá depender da usabilidade do software com o usuário.

Portabilidade – Depende estritamente do domínio da aplicação.

Facilidade de uso – Outro atributo muito importante que irá depender muito da
usabilidade do software. Usuário principal ator para a avaliação deste atributo.

Facilidade de reuso – Capacidade do software de receber mudanças, evoluir os

requisitos com a necessidade do usuário.

Eficiência – Depender de vários atributos, mais conceitualmente depende

principalmente do domínio da aplicação.

Facilidade de aprendizado – Outro atributo que depende tanto da usabilidade do

software quanto do usuário que irá operar o software.

24.4. Projete um formulário eletrônico que possa ser utilizado para registrar
comentários de revisão e que poderia ser usado para enviar por e-mail os
comentários para os revisores.

24.5. Descreva brevemente os padrões que podem ser utilizados para:

1- Uso de construções de controle em C, C# e JAVA.

2- Relatórios que possam ser submetidos a um projeto de formatura em uma
universidade.
3- Processos de fazer e aprovar mudanças(ver cap. 26).
4- Processo de comprar e instalar um novo computador.

1 – Para padronizar a construção de estruturas em alguma linguagem de programação

(C, C#, JAVA), pode se utilizar padrões referentes à escrita do código, declaração de
variáveis, modularizações, comentários, utilização de arquivos XML para controle
através de ferramentas case, entre outros.

2 – Para relatórios pode se utilizar padrões de documentos, tais como, definição da

estrutura do documento, linguagem a ser utilizada, forma de fazer a documentação,
dados obrigatórios no documento (no caso o período letivo da universidade), entre
outros.

3 – Para fazer e aprovar mudanças pode ser feito em duas formas de padronização
uma em relação ao próprio processo, maneira de ser feita a mudança, manual/regra a
ser seguido na mudança, ou até mesmo artefatos que possam ser gerados para
auxiliar na mudança como documentos, modelos com seus devidos padrões de
escrita, estrutura, entre outros.

4 – Para adquirir um computador, pode ser feita uma padronização em relação aos
documentos gerados pela compra (notas fiscais, comprovantes, fabricante...) e algo
relacionado a instalação ( suporte técnico )que fez a instalação do computador
(empresa responsável pelo suporte técnico, garantia do serviço...) entre outros.

24.6. Suponha que você trabalhe para uma organização que desenvolve
produtos de banco de dados para indivíduos e empresas de pequeno porte. Esta
organização está interessada na quantificação de seu desenvolvimento de
software. Escreva um relatório sugerindo métricas adequadas e sugira como
estas podem ser coletadas.

Coleta de dados – Poderia ser feita através de uma interface com o sistema em que o
computador irá operar ou até mesmo com o usuário.

Possíveis métricas – Poderíamos ter inúmeras métricas dependendo do nível de

qualidade que se deseje avaliar, e da tecnologia a ser utilizada. Algumas propostas
seriam:
Métricas de controle – Controlar o tempo do projeto, medir prazos e tempo de
desenvolvimento, recursos requeridos, dentre outras.

Métricas dinâmicas – Tempo de resposta da comunicação com o banco de dados,

número de erros gerados pela interface responsável por coletar os dados. Ambas iriam
medir confiabilidade e eficiência do produto.

Métricas estáticas – Poderíamos utilizar fan-in/fan-out, complexidade ciclomática,

dentre outras métricas relacionadas ao produto final, porém que sejam métricas úteis
para avaliar o produto.

24.7. Explique por que inspeções de programa são uma técnica eficaz para
descobrir erros em um programa. Que tipos de erros são improváveis de serem
descobertos por meio de inspeções?

Revisões e inspeções são atividades de controle de qualidade que verificam a

qualidade dos entregáveis de projeto. Isso envolve examinar o software, sua
documentação e os registros do processo para descobrir erros e omissões e verificar
se os padrões de qualidade foram seguidos. Revisões e inspeções são usadas junto
com teste de programa, como parte do proesso geral de validação e verificação de
projeto.

24.8. Explique por que as métricas de projeto são por si só, um método
inadequado de previsão de qualidade de projeto.

As métricas aplicadas no projeto não são adequadas para garantir a qualidade do

projeto pelo fato de que a qualidade do projeto é determinada pela qualidade do
produto. Um projeto com nível alto de qualidade não necessariamente ira gerar
produtos de qualidade. Produtos de qualidade não dependem somente de um projeto
de qualidade mais de uma especificação bem definida, e considerando todos os
fatores externos que possam influenciar o projeto. A “soma” de todos esses “fatores” é
que garante a qualidade do projeto (produto).

24.9.Explique por que é difícil validar os relacionamentos entre os atributos

internos de produto, como complexidade ciclomátca e atributos externos, como
a manutenabilidade.

Por ser impossível medir os atributos de qualidade de software diretamente. Os

atributos são influenciados por muitos fatores e não existe uma maneira simples para
medi-los. Você deve medir algum atributo interno do software e presumir que há um
relacionamento entre o que você pode medir e o que quer conhecer. Também deve
haver um relacionamento claro e validado entre os atributos de software internos e
externos.

24.10. Um colega, que é um excelente programador, produz softwares com

poucos defeitos, mas, constantemente ignora os padrões de qualidade de
organização. Como seus gerentes deveriam reagir a esse comportamento?

Devem chamar a sua atenção, pois uma organização não é composta apenas por
aquele desenvolvedor, e sim pela equipe como um todo. Se um não seguir com os
padrões definidos, além de influenciar na qualidade do produto, irá também perder o
foco de se utilizar padrões para garantir uma qualidade. Sem falar que o software
produzido por ele pode até ter um número pequeno de defeitos, porém foi feito por ele,
somente ele irá entender como um todo. Se outro desenvolvedor, futuramente,
precisar efetuar uma manutenção ou algo do tipo terá dificuldade pela falta do uso dos
padrões definidos pela organização.