Questões do cap. 24 do Livro SOMMERVILLE - Engenharia de software.

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. A primeira vista não vejo nenhum problema com esse gerenciamento de qualidade, já que ele leva a produtos de alta qualidade. Porém 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 esta completa e geralmente vai evoluindo durante o processo de desenvolvimento, neste ponto a alta qualidade do processo pode atrapalhar o desenvolvimento do produto. Cabendo ao gerente sênior intervir para assegurar que o processo de qualidade apóie, e não prejudique o desenvolvimento do produto.

 As revisões de um projeto de software podem ser feitas de varias formas diferentes, dependendo de como “trabalha” a organização. Dentre elas destacam-se três tipos de revisões: revisões de projeto e/ou código, revisões de progresso, revisões de qualidade. Revisões de projeto e/ou código – São basicamente revisões no próprio processo de desenvolvimento, e no código do software com o objetivo de detectar erros para posteriormente arrumá-los, diminuindo assim a taxa de erros do produto de software. Isso tudo é feito pela “disciplina” de teste de software que utiliza a qualidade como um apoio. Revisões de progresso – É algo mais interno da organização (gerência) para ter um controle de como anda o projeto, em relações a prazo, custos, planos. Revisões de qualidade – São revisões que agem basicamente em sobre o plano de qualidade, avaliando processos, documentação com referência no plano de qualidade do projeto, para saber se a qualidade esperada esta sendo devidamente aplicada. 

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 minha opinião 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 – A meu ver é 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 ia depender 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 esta 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 – Ira 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 ira depender da lógica aplicada, isso em relação ao funcionamento do software. Quanto a ”complexidade de uso” ira depender da usabilidade do software com o usuário. 
• Portabilidade – Depender estritamente do domínio da aplicação. Facilidade de uso – Outro atributo muito importante que ira 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, o que é eficiência pra mim? (usuário). Facilidade de aprendizado – Outro atributo que depende tento da usabilidade do software quanto do usuário que ira operar o software. 

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 ate 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. Ambos os padrões podem gerar documentos. Assim como podem já seguir algum padrão ”já feito”, porem que se adéqüe a situação/ problema.

• Coleta de dados – Poderia ser feita através de uma interface com o sistema em que o microcomputador ira operar ou ate 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. Porem algumas que posso propor são: 
• 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, numero 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, porem que sejam métricas úteis para avaliar o produto.

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).

• Produtividade do desenvolvimento – Medida relacionada ao projeto, que faz uma medição dos prazos, custos e recursos gastos no desenvolvimento de software.
• Crescimento funcional do software durante o desenvolvimento – Faz a medição do software em relação a sua funcionalidade (requisitos).
• Reutilização do código – Medição que depende de outras medições como a complexidade ciclomática, árvore de herança, e operações sobrepostas. 
• Complexidade relativa do software – Medida feita através do estudo do código, em relação a sua complexidade, e facilidade de manutenção. 

Não. Pelo contrário os padrões devem ser “escritos” desenvolvidos para que possam acompanhar e evoluir juntamente com a tecnologia. Com o objetivo de buscar cada vez mais os novos recursos trazidos pela mesma, melhorando assim ate mesmo a sua própria aplicação.

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 alem de influenciar na qualidade do produto, ira também perder o foco de se utilizar padrões para garantir uma qualidade. Sem falar que o software produzido por ele pode ate ter um numero pequeno de defeitos, porem foi feito por ele, somente ele ira entender como um todo, se outro desenvolvedor futuramente precisar efetuar uma manutenção ou algo do tipo ira ter dificuldade pela falta do uso dos padrões definidos pela organização.