29 abril, 2015

Normas Aplicadas a Qualidade de Software

ISO 9126


Define características e sub-características. Norma técnica sempre te dá o roteiro sobre "o que fazer" e não como.

Define um conjunto de 6 visões da qualidade para produtos de software:
  1. Funcionalidade: entender quais as funções;
    • Adequação: medir o tanto que o software é adequado aos processos do cliente (mais usada)
    • Acurácia: precisão, saber se o software entrega dados corretos e precisos
    • Interoperabilidade: capacidade que o sistema tem de integrar com outros sistemas
    • Conformidade: os dados gerados pelo sistema estão de acordo com as regras do negócio. Ex. Calculo do imposto de renda, está fiel ao calculo do IR?
    • Segurança: saber se o sistema evita acessos não autorizados
  2. Confiabilidade: o esforço de medir as indisponibilidades do sistemas, diz respeito a falhas
    • Maturidade: frequência de falhas, quanto maior o numero de falhas, menos maduro
    • Tolerância a falhas: robustez do sistema. Reage bem após falha.
    • Recuperabilidade: capacidade de recuperar dados, transações pós falha.
    • Conformidade: Não estar em conformidade com o contrato redigido pelo cliente.
  3. Usabilidade: esforço de uso do sistema
    • Inteligibilidade: capacidade que o sistema tem de passar para o usuário o seu propósito.
    • Apreensibilidade: esforço de uso do sistema.
    • Atratividade: capacidade de atração que proporciona ao usuário.
    • Operatividade: instalação do software, colocar disponível, fazer backup, etc. 
    • Conformidade: se está em conformidade com padrões de organização, fonte, etc.
  4. Eficiência: desempenho
    • Comportamento em relação ao tempo: quanto tempo leva para o sistema te retornar uma informação. 
    • Comportamento em relação aos recursos: recursos é memória, CPU, etc. 
    • Conformidade: sistema tem entregue dentro de uma eficiência acordada (contrato).
  5. Manutenibilidade: esforço de manutenção
    • Analisibilidade: esforço de analisar aonde existe algum problema a ser resolvido. Quanto menor o esforço de analisar o sistema, melhor.
    • Modificabilidade: esforço de modificação do código.
    • Estabilidade: risco de se mexer no sistema.
    • Testabilidade: esforço de teste após manutenção.
    • Conformidade: mesmo das outras características, está sendo feita dentro do que foi acordado.
  6. Portabilidade: capacidade que o sistema tem de trabalhar em diferentes ambientes operacionais
    • Adaptabilidade: o quanto que o sistema se adapta ao ambiente especificado (Win, Linux)
    • Coexistência: capacidade de coexistir com outros softwares.
    • Capacidade para ser instalado: qual o esforço para instalar num ambiente ou no outro.
    • Capacidade para substituir: capacidade de substituir um outro sistema num outro ambiente. Ex. Office no Windows -> não tem capacidade de substituir outro pacote de escritório no linux
    • Conformidade: portabilidade acordada para o software está sendo atendida?

Sistema quantitativo para medir qualidade

Qualidade de Software = soma(características)
Características = soma(subcaracteristicas)
Subcaracterísitcas = soma(métricas)


Métricas são perguntas objetivas feitas para o avaliador responder sobre o sistema

Peso é um valor relativo da importância que se atribui a cada uma característica. Ex. sistema web deve ter um peso maior para Usabilidade. Automação deve ter um peso maior na confiabilidade.


ISO 14598

Trata o processo de avaliação do software. Bem mais recente que a ISO 9126. É um roteiro de como projetar uma avaliação de um software.

Possui 4 momentos:
  1. Estabelecer requisitos de avaliação: 
    • estabelecer o proposito da avaliação
    • identificar o tipo de produto a ser avaliado
    • especificar um modelo de qualidade (ISO 9126)
  2. Especificar a avaliação
    • selecionar métricas (criar métricas para as características)
    • atribuir valores/pesos para as métricas
    • estabelecer critérios para julgamento
  3. Projetar a avaliação (fazer o plano de avaliação)
    • plano deve conter métricas para ser avaliados por usuários, desenvolvedores, etc. cada um no que entende. Ex. desenvolvedor que avalia a confiabilidade, e o usuário que avalia a usabilidade.
  4. Executar a avaliação
    • obter as medidas
    • comparar com critérios
    • julgar os resultados













Maturidade nos Processos de Software

Capability Maturity Model - CMM

Surgiu na área militar do EUA ao terceirizar a produção de software, havia necessidade de qualificar uma empresa de software.

Definição

É uma soma de "melhores práticas" para diagnóstico e avaliação de maturidade no desenvolvimento de software.

Organizações maduras:
  • papéis e responsabilidades bem definidos
  • existe base históricas
  • é possível julgar a qualidade do produto
  • qualidade é monitorada
  • o processo pode ser atualizado
  • modelo de comunicação bem definido

Organização imaturas:
  • processo improvisado
  • não possui base histórica (a cada novo projeto um recomeço)
  • não há maneira objetiva de julgar a qualidade do produto
  • não há rigor no processo
  • resolução de crises imediatas

O modelo é definido por 5 níveis de maturidade
  1. Inicial - todos estamos nele, quando não existe clareza na forma de desenvolvimento de software. Não há KPAs. Depende do desenvolvedor que abraça o projeto e o leva até o fim. 
  2. Repetível - o desenvolvimento de software já tem alguma repetição de sucesso nas entregas. Empresa já adota algumas práticas sempre. Já se consegue estimar com maior clareza. Seria o primeiro nível de maturidade. É o passo mais difícil, por ter que sair de zero maturidade. Possui as seguintes KPAs:
    1. gerenciamento de requisitos
    2. planejamento de projetos
    3. gerenciamento de subcontratação (terceiros)
    4. garantia da qualidade de software
    5. gerenciamento de configuração
  3. Definido - já implantou e tem uma série de práticas definidas. É obrigatório seguir padrões, não é possível alguém fazer algo diferente. KPAs:
    1. revisões
    2. coordenação de intergrupos
    3. engenharia de produto de software
    4. gerenciamento de software integrado
    5. programa de treinamento
    6. foco no processo da organização
    7. definição do processo da organização
  4. Gerenciado - quando se consegue fazer medições quantitativas no processo. Fazer medições no produto é praticar o "nível gerenciado". KPAs:
    1. gerenciamento quantitativo da qualidade do software
    2. gerenciamento quantitativo do processo
  5. Otimizado - é a melhoria contínua do processo de desenvolvimento. Promover inovação no seu processo. KPAs:
    1. gerenciamento de mudança no processo
    2. gerenciamento de mudança tecnológica
    3. prevenção de defeitos

Há outros processos de maturidade como:
  • Personal Software Process - PSP
  • MPS-BR
  • SPICE - ISO/15504
  • CMMi (evolução do CMM)
  • Outros
















21 abril, 2015

Introdução a qualidade de software

Qualidade é:
  • atender aos requisitos do cliente
  • antecipa os desejos do cliente
  • escrever tudo o que se deve fazer e fazer tudo que foi escrito
Definição de qualidade segundo alguns autores:
  • a) qualidade intrínseca do produto ou serviço: presença ou ausência de critérios específicos;
  • b) custo: é o preço justo que o cliente está disposto a pagar;
  • c) atendimento: quantidade certa, no local e hora certa;

Definição segundo a ISO:

... a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explicitas e implícitas
entidade é o software
necessidade explicita: tudo que o usuário consegue perceber em relação  ao software
necessidade implícita: é tudo que somente os desenvolvedores conseguem perceber



Apesar do software ser um produto de um processo intelectual, assim como um livro ou um quadro, o software não pode ser totalmente criado com as vontades do seu criador, diferente das obras de arte por exemplo. 


Considerações

  • software é um produto complexo, até mais do que o hardware
  • não tem produção em série e o seu custo está no projeto e desenvolvimento
  • não se desgasta
  • a engenharia de software ainda não está madura o suficiente


Conclusão

Não tem como modelar um software de qualidade sem um processo de qualidade também.
Para que o software tenha qualidade, é necessário que o modelo de negócio também seja de qualidade.


Construção de Software (Vídeo 2)


Projeto é construir um produto, dentro de determinadas especificações, que atenda as necessidades dos usuários para que executem processos operacionais e gerenciais de negócios.

Projeto = (objetivos + atividades + prazos + recursos envolvidos + riscos e incertezas)

Características de um projeto de software:
  • esforço finito, no seu termino pretende-se a entrega
  • um esforço que pode ser subdividido (fases, etapas, atividades)
  • objetivo, recursos e progresso podem ser monitorados e avaliados

Todo projeto tem três partes básicas:
  1. Planejamento
    • elaborar escopo
    • elaborar estimativas de prazo, recursos, esforço, custo, tamanho
    • definir o processo de desenvolvimento
  2. Controle (execução)
    • controle da alocação de recursos
    • verificação e validação de produtos intermediário
    • controle de mudança de escopo
    • refinamento e replanejamento 
    • acompanhamento das tarefas e orçamento conforme cronograma
  3. Monitoramento
    • verificar o progresso
    • verificar e avaliar a qualidade
    • verificar e avaliar produtividade
    • verificar e avaliar financeiro

Processo de software

Conjunto de atividades em sequencia, métodos e práticas utilizadas na produção e evolução do software.
  • definir politicas de desenvolvimento (ex. só se desenvolve para web ou para mobile)
  • procedimentos para o desenvolvimento
  • diversas técnicas e padrões para construção de produtos
  • padrões de apresentação de produtos intermediários

Produto de software

É o resultado da execução de um processo que contém uma série de atributos derivados dos requisitos e especificações previstos no projeto.


Sofre alterações caracterizadas como:
  • manutenções corretivas, adaptativas
  • melhorias










05 abril, 2015

Processos de Ciclo de Vida

Dividido em dois grandes momentos:
  • Ciclo de Desenvolvimento
    • Concepção: o que tem que ser feito, objetivos do sistema, viabilidade, analise custo x benefício, tem condições implementar, quantidade de pessoas, ferramentas, limitações do projeto. É o projeto. Invista tempo na concepção!
    • Criação: implementação do sistema. verificar se realmente a equipe consegue implementar, seria interessante terceirizar a criação?
  • Ciclo Operacional
    • Evolução: manutenção do código, mudanças nas regras de negócio, melhorias. Não é natural fazer alguma coisa de concepção ou criação. O menor custo de um defeito é evita-lo. 
    • Decadência: indicadores que o software está em decadência: esforço grande para manutenção do sistema, atraso tecnológico, reclamação do usuário, mudanças organizacionais. Inicia-se um novo projeto.

Processos de Ciclo de Vida - Norma ISO 12207

Orientar a organização sobre quais os processos desde a concepção até o fim. Três grandes classes de processo:

  • Processos Primários (é o básico para criação de software)
    • tenha um processo de aquisição
    • tenha um processo de fornecimento
    • tenha um processo de desenvolvimento
    • tenha um processo de operação
    • tenha um processo de manutenção
  • Processos de Apoio
    • tenha um processo de documentação
    • tenha um processo de gerência de qualidade
    • tenha um processo de validação (protótipos, projetos, testes)
    • tenha um processo de auditoria
    • tenha um processo de usabilidade 
    • tenha um processo de gerência de configuração (diferentes plataformas)
    • tenha um processo de verificação
    • tenha um processo de revisão conjunta
    • tenha um processo de resolução de problemas
    • tenha um processo de contrato
  • Processos Organizacionais (parte da organização no processo de software)
    • tenha um processo de gerência
    • tenha um processo de infra-estrutura
    • tenha um processo de melhoria
    • tenha um processo de recursos humanos (treinamento, consultor, evolução técnica)
  • Processos de Reuso de Software
    • tenha um processo de gestão de ativos
    • tenha um processo de programas de reuso (reuso tudo que já se tem pronto)
    • tenha um processo de engenharia de domínio (não perder a arquitetura do processo)
  • Processos de Adaptação
    • os processos devem ser adaptáveis ao projeto
    • os processos devem ser adaptáveis a organização
    • os processos devem ser adaptáveis a cultura
    • os processos devem ser adaptáveis a modelo de ciclo de vida, método, técnicas, linguagens.