O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Goiânia
2013
DIOGO ROCHA FERREIRA DE MENEZES
REINALDO JUNIOR ALMEIDA
SISTEMAS DE INFORMAÇÃO
QUALIDADE DE SOFTWARE
VT- Aval...
Goiânia
2013
QUALIDADE DE SOFTWARE
VT- Avaliação de Produto de Software.
Trabalho apresentado à disciplina Qualidade de
So...
SUMÁRIO
1 INTRODUÇÃO.....................................................................................................3...
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
4   usabilidade - y
4 usabilidade - y
Carregando em…3
×

Confira estes a seguir

1 de 23 Anúncio

QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software

Este trabalho tem por objetivo apoiar o processo de desenvolvimento da VT. A finalidade desta VT é propiciar o acesso a conhecimentos sobre Avaliação de Produto de Software. Esta avaliação está de acordo com as normas: ISO/IEC 9126-1 (NBR ISO/IEC 13596 - Modelo de qualidade de produto de software), ISO/IEC 9126-3 (Métricas Internas) e ISO/IEC 14598.

Este trabalho tem por objetivo apoiar o processo de desenvolvimento da VT. A finalidade desta VT é propiciar o acesso a conhecimentos sobre Avaliação de Produto de Software. Esta avaliação está de acordo com as normas: ISO/IEC 9126-1 (NBR ISO/IEC 13596 - Modelo de qualidade de produto de software), ISO/IEC 9126-3 (Métricas Internas) e ISO/IEC 14598.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

Anúncio

Semelhante a QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software (20)

Mais de Diogo Rocha Ferreira de Menezes (8)

Anúncio

Mais recentes (20)

QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software

  1. 1. Goiânia 2013 DIOGO ROCHA FERREIRA DE MENEZES REINALDO JUNIOR ALMEIDA SISTEMAS DE INFORMAÇÃO QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software.
  2. 2. Goiânia 2013 QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software. Trabalho apresentado à disciplina Qualidade de Software da Universidade Salgado de Oliveira - UNIVERSO Professor: Roberto Couto DIOGO ROCHA FERREIRA DE MENEZES REINALDO JUNIOR ALMEIDA
  3. 3. SUMÁRIO 1 INTRODUÇÃO.....................................................................................................3 2 DESENVOLVIMENTO .........................................................................................4 2.1 Avaliação ............................................................................................................4 2.1.1 Propósito da Avaliação .................................................................................4 2.1.2 Identificação do Tipo de Produto ..................................................................5 2.1.3 Especificação do Modelo de Qualidade – Atributos......................................6 2.1.4 Métricas para os Atributos ............................................................................9 2.1.5 Níveis de Pontuação das Métricas - Escala................................................18 2.1.6 Critérios de Julgamento do Produto de Software........................................18 3 CONCLUSÃO ....................................................................................................20 REFERÊNCIAS.........................................................................................................21 ANEXOS ...................................................................................................................22
  4. 4. 3 1 INTRODUÇÃO Este trabalho tem por objetivo apoiar o processo de desenvolvimento da VT. A finalidade desta VT é propiciar o acesso a conhecimentos sobre Avaliação de Produto de Software. Esta avaliação está de acordo com as normas: ISO/IEC 9126-1 (NBR ISO/IEC 13596 - Modelo de qualidade de produto de software), ISO/IEC 9126-3 (Métricas Internas) e ISO/IEC 14598. Nesta avaliação esta sendo considerada somente a característica Manutenibilidade e suas sub-características. Esta é uma característica interna, logo não reflete uma visão que o usuário possui do produto de software mais sim uma visão do desenvolvedor. Sendo assim, o objetivo deste trabalho é nos fornecer um suporte metodológico e estrutural visando o entendimento do tema Qualidade de Software em uma simulação para empresa Golden Soluções Ltda, mulitinacional na área de construção civil, aonde busca no mercado por um sistema de informação para gestão de suas operações.
  5. 5. 4 2 DESENVOLVIMENTO  Etapas para Realização de uma Avaliação: o Propósito da Avaliação o Identificação do Tipo de Produto o Especificação do Modelo de Qualidade - Atributos o Métricas para os Atributos o Níveis de Pontuação das Métricas o Critérios de Julgamento o Plano de Avaliação o Obtenção das Medidas o Comparação com Critérios o Julgamento do Resultado 2.1 AVALIAÇÃO 2.1.1 Propósito da Avaliação Esta avaliação visa determinar se um produto de software desenvolvido internamente na organização Golden Soluções Ltda, é aceitável do ponto de vista do desenvolver, não do ponto de vista do usuário. A questão fundamental a ser avaliada é se o programa em questão está internamente bem organizado e bem projetado, contribuindo assim, para uma fácil manutenção do mesmo, pois este estará sendo utilizado para gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção.
  6. 6. 5 2.1.2 Identificação do Tipo de Produto  Sistema 1 – Zeus O item a ser avaliado é um programa desenvolvido em linguagem. Net, com banco de dados Postgres. O mesmo não se constitui um pacote de software. O programa tem como objetivo ser utilizado em empresas do mercado de construção civil em gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. Este faz controle de acessos de cada um dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema, obriga que cada um dos usuários troque suas senhas em um intervalo de seis em seis meses, possui guia de usuário que ensina a operar e manipular todas as funções que o sistema oferece, possui interface amigável, com base em um ambiente mais conhecido a maioria dos usuários brasileiros. Programa: Zeus. Departamento Responsável: Dpto Desenvolvimento e Tecnologia Desenvolvido por: Diogo Rocha – Analista de Sistemas. Data: 09/09/2013 Versão: 1.0  Sistema 2 - Polus O item a ser avaliado é um programa que foi desenvolvido em Java com banco de dados Postgres. O mesmo não se constitui um pacote de software. . O programa tem como objetivo ser utilizado em empresas do mercado de construção civil em gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. . Este faz controle de acessos de cada um dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema, o mesmo não possui obrigatoriedade na troca ou expiração da senha de acesso. Possui guia de usuário que ensina a operar e manipular todas as funções que o sistema oferece. Possui uma aplicação auxiliar para introdução ao sistema, que ensina aos usuários em como se fazer uso do sistema de forma eficiente. Programa: Polus Departamento Responsável: Dpto Desenvolvimento e Tecnologia Desenvolvido por : Diogo Rocha – Analista de Sistemas
  7. 7. 6 Data: 09/09/2013 Versão: 1.0 2.1.3 Especificação do Modelo de Qualidade – Atributos Modelo de Qualidade descrito a seguir está em conformidade com as normas: ISO/IEC 9126-1 (NBR ISO/IEC 13596 - Modelo de qualidade de produto de software), ISO/IEC 9126-3 (Métricas Internas).  Sistema 1 – Zeus  Funcionalidade o 1 – Adequação  1.1 – O sistema deve ser via web.  1.2 – O sistema deve ser desenvolvido em linguagem .Net com banco de dados e Postgres.  1.3 – O sistema deve possuir no mínimo 90% das suas funcionalidades implementadas.  1.4 – O sistema tem como objetivo gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. o 2 – Segurança de Acesso  2.1 – O sistema deve fazer controle de acessos de cada um dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema.  2.2 – O sistema deve obrigar que cada um dos usuários troque suas senhas em um intervalo de seis em seis meses.
  8. 8. 7 o 3 – Acurácia  3.1 – O sistema deve ser projetado utilizando uma ferramenta Case com suporte a orientação a objetos, que gera documentos como diagramas de classe, diagramas de objetos e diagramas de sequencia.  Usabilidade o 4 – Operacionalidade  4.1 – O sistema deve possuir guia do usuário que ensina o usuário a operar e manipular todas as funções que o mesmo oferece. o 5- Inteligibilidade  5.1- O sistema deve possuir uma interface mais amigável, com um ambiente mais conhecido a maioria dos usuários brasileiros.  Portabilidade o 6 – Conformidade  6.1 – Todas as instruções de acesso e manuseio ao banco de dados devem ser escritas em SQL, padrão mais utilizado;  Sistema 2 - Polus  Funcionalidade o 1 – Adequação  1.1 – O sistema deve ser via web.  1.2 – O sistema deve ser desenvolvido em linguagem Java com banco de dados e Postgres.  1.3 – O sistema deve possuir no mínimo 85% das suas
  9. 9. 8 funcionalidades implementadas.  1.4 – O sistema tem como objetivo gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. o 2 – Segurança de Acesso  2.1 – O sistema deve fazer controle de acessos de cada um dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema. o 3 – Acurácia  3.1 – O sistema deve ser projetado utilizando os padrões UML, que gera documentos como diagramas de classe, diagramas de objetos e diagramas de sequencia, um dicionário de dados completo da estrutura de dados que o sistema manipula.  Usabilidade o 4 – Operacionalidade  4.1 – O sistema deve possuir guia do usuário que ensina o usuário a operar e manipular todas as funções que o mesmo oferece. o 5- Inteligibilidade  5.1- O sistema deve possuir uma aplicação auxiliar para introdução ao sistema, que ensina aos usuários em como se fazer uso do sistema de forma eficiente.  Portabilidade o 6 – Conformidade  6.1 – Todas as instruções de acesso e manuseio ao banco de dados devem ser escritas em SQL, padrão mais utilizado;
  10. 10. 9 2.1.4 Métricas para os Atributos A seguir é listado cada um dos atributos seguido pela métrica adequada ao mesmo:  Sistema 1 – Zeus Requisito 1.1 – O sistema deve ser via web. Métrica Situação Valor Medido O sistema deve ser via web. 10 O sistema deve ser parcialmente via web. 5 O sistema não deve ser via web. 0 Requisito 1.2- O sistema deve ser desenvolvido em linguagem .Net com banco de dados e Postgres. Métrica Situação Valor Medido O sistema deve ser desenvolvido em linguagem .Net com banco de dados e Postgres. 10 O sistema é parcialmente desenvolvido em linguagem .Net com banco de dados e Postgres.. 6 O sistema deve ser desenvolvido em qualquer linguagem com 3
  11. 11. 10 banco de dados e Postgres. O sistema não deve ser desenvolvido em nenhuma linguagem 0 Requisito 1.3 – O sistema deve possuir no mínimo 90% das suas funcionalidades implementadas. Métrica Situação Valor Medido O sistema deve possuir no mínimo 90% das suas funcionalidades implementadas. 10 O sistema deve possuir no mínimo 50% das suas funcionalidades implementadas.. 5 O sistema não teve funcionalidades implementadas. 0 Requisito 1.4 – O sistema tem como objetivo gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. Métrica Situação Valor Medido O sistema tem como objetivo gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. 10 O sistema tem como objetivo parcialmente realizar gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. 5
  12. 12. 11 O sistema não deixou claro o objetivo. 0 Requisito 2.1 – O sistema deve fazer controle de acessos de cada um dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema. Métrica Situação Valor Medido O sistema deve fazer controle de acessos de cada um dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema. 10 O sistema deve fazer controle de acessos de alguns dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema.. 8 .O sistema deve fazer controle de acessos de cada um dos usuários em seus respectivos acessos, mas não gerar registros de acesso ao sistema. 5 O sistema não faz controle de acessos de cada um dos usuários 0 Requisito 2.2 - O sistema deve obrigar que cada um dos usuários troque suas senhas em um intervalo de seis em seis meses. Métrica Situação Valor Medido O sistema deve obrigar que cada um dos usuários troque suas senhas em um intervalo de seis em seis meses. 10
  13. 13. 12 O sistema informa que cada um dos usuários troque suas senhas em um intervalo de seis em seis meses, mas não obriga. 8 O sistema não deve obrigar que cada um dos usuários troque suas senhas em um intervalo de seis em seis meses. 5 O sistema não faz controle de trocas de senha dos usuários. 0 Requisito 3.1 - O sistema deve ser projetado utilizando uma ferramenta Case com suporte a orientação a objetos, que gera documentos como diagramas de classe, diagramas de objetos e diagramas de sequencia. Métrica Situação Valor Medido O sistema deve ser projetado utilizando uma ferramenta Case com suporte a orientação a objetos, que gera documentos como diagramas de classe, diagramas de objetos e diagramas de sequencia. 10 O sistema deve ser projetado utilizando uma ferramenta Case qualquer, que gera documentos como diagramas de classe, diagramas de objetos e diagramas de sequencia.. 5 O sistema não utiliza uma ferramenta Case. 0 Requisito 4.1 - – O sistema deve possuir guia do usuário que ensina o usuário a operar e manipular todas as funções que o mesmo oferece. Métrica Situação Valor Medido O sistema deve possuir guia do usuário que ensina o usuário a operar e manipular todas as funções que o mesmo oferece 10
  14. 14. 13 O sistema deve possuir guia do usuário que ensina o usuário a operar e manipular metade das funções que o mesmo oferece 5 O sistema não fornece guia do usuário. 0 Requisito 5.1 O sistema deve possuir uma interface mais amigável, com um ambiente mais conhecido a maioria dos usuários brasileiros. Métrica Situação Valor Medido O sistema deve possuir uma interface mais amigável, com um ambiente mais conhecido a maioria dos usuários brasileiros. 10 O sistema deve possuir uma interface complexa, com um ambiente mais conhecido somente pelos desenvolvedores. 0 Requisito 6.1 – Todas as instruções de acesso e manuseio ao banco de dados devem ser escritas em SQL, padrão mais utilizado. Métrica Situação Valor Medido Todas as instruções de acesso e manuseio ao banco de dados devem ser escritas em SQL, padrão mais utilizado. 10 Todas as instruções de acesso e manuseio ao banco de dados devem ser escritas parcialmente em SQL, padrão mais utilizado. 5 Não deve existir banco de dados.. 0
  15. 15. 14  Sistema 2 – Polus Requisito 1.1 – O sistema deve ser via web. Métrica Situação Valor Medido O sistema deve ser via web. 10 O sistema deve ser parcialmente via web. 5 O sistema não deve ser via web. 0 Requisito 1.2- O sistema deve ser desenvolvido em linguagem Java com banco de dados e Postgres. Métrica Situação Valor Medido O sistema deve ser desenvolvido em linguagem Java com banco de dados e Postgres. 10 O sistema é parcialmente desenvolvido em linguagem Java com banco de dados e Postgres... 6 O sistema deve ser desenvolvido em qualquer linguagem com banco de dados e Postgres. 3 O sistema não deve ser desenvolvido em nenhuma linguagem 0 Requisito 1.3 – O sistema deve possuir no mínimo 85% das suas funcionalidades implementadas.
  16. 16. 15 Métrica Situação Valor Medido O sistema implementa >= 90% das suas funcionalidades implementadas. 10 O sistema implementa < 90% das suas funcionalidades implementadas.. 0 Requisito 1.4 – O sistema tem como objetivo gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. Métrica Situação Valor Medido O sistema tem como objetivo gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. 10 O sistema tem como objetivo parcialmente realizar gestão de suas operações, como funções administrativas, financeiras, contábeis, comerciais e de produção. 5 O sistema não deixou claro o objetivo. 0 Requisito 2.1 – O sistema deve fazer controle de acessos de cada um dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema.
  17. 17. 16 Métrica Situação Valor Medido O sistema deve fazer controle de acessos de cada um dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema. 10 O sistema deve fazer controle de acessos de alguns dos usuários em seus respectivos acessos, além dos registros de acesso ao sistema.. 8 .O sistema deve fazer controle de acessos de cada um dos usuários em seus respectivos acessos, mas não gerar registros de acesso ao sistema. 5 O sistema não faz controle de acessos de cada um dos usuários 0 Requisito 3.1 - O sistema deve ser projetado utilizando os padrões UML, que gera documentos como diagramas de classe, diagramas de objetos e diagramas de sequencia, um dicionário de dados completo da estrutura de dados que o sistema manipula. Métrica Situação Valor Medido O sistema deve ser projetado utilizando os padrões UML, que gera documentos como diagramas de classe, diagramas de objetos e diagramas de sequencia, um dicionário de dados completo da estrutura de dados que o sistema manipula. 10 O sistema deve ser projetado utilizando padrões quaisquer, que gera documentos como diagramas de classe, diagramas de objetos e diagramas de sequencia.. 7
  18. 18. 17 O sistema não utiliza nenhum padrão. 0 Requisito 4.1 - O sistema deve possuir guia do usuário que ensina o usuário a operar e manipular todas as funções que o mesmo oferece. Métrica Situação Valor Medido O sistema deve possuir guia do usuário que ensina o usuário a operar e manipular todas as funções que o mesmo oferece 10 O sistema deve possuir guia do usuário que ensina o usuário a operar e manipular metade das funções que o mesmo oferece 5 O sistema não fornece guia do usuário. 0 Requisito 5.1 O sistema deve possuir uma aplicação auxiliar para introdução ao sistema, que ensina aos usuários em como se fazer uso do sistema de forma eficiente. Métrica Situação Valor Medido O sistema possui uma aplicação auxiliar para introdução ao sistema, que ensina aos usuários em como se fazer uso do sistema de forma eficiente. 10 O sistema possui uma aplicação auxiliar para introdução ao sistema, porém, não ensina os usuários como utilizar o sistema de forma eficiente. 5 O sistema não possui guia do usuário. 0
  19. 19. 18 Requisito 6.1 – Todas as instruções de acesso e manuseio ao banco de dados devem ser escritas em SQL, padrão mais utilizado. Métrica Situação Valor Medido Todas as instruções de acesso e manuseio ao banco de dados devem ser escritas em SQL, padrão mais utilizado. 10 Todas as instruções de acesso e manuseio ao banco de dados devem ser escritas parcialmente em SQL, padrão mais utilizado. 5 Não deve existir banco de dados.. 0 2.1.5 Níveis de Pontuação das Métricas - Escala A escala apresentada abaixo é a mesma para todos os atributos, por conseguinte, a mesma pode ser utilizada para aferir a qualidade e a aceitabilidade de cada um dos atributos de forma independente um do outro. Escala de Avaliação de Valor Medido Intervalos de Valores Classificação Julgamento 9 – 10 Ótimo Aceitável 7 – 8,9 Bom 5 – 6,9 Regular Não Aceitável 3 – 4,9 Ruim 0 – 2,9 Péssimo 2.1.6 Critérios de Julgamento do Produto de Software A média ponderada calculada na forma da expressão matemática
  20. 20. 19 listada abaixo, deve determinar o Valor Final da Avaliação (VFA) de qualidade do produto de software. A aceitação ou não do produto de software deve ser determinada avaliando a posição do VFA na escala definida no item 2.1.5 (ou seja, aqui se esta usando a mesma escala definida para cada atributo também para o produto de software). VFA = (P1 * A1) + (P2 * A2) + ... + (Pn * An) / (P1 + P2 + ... + Pn) Considerações: Ax - refere-se ao valor medido para o atributo de número x. Px - refere-se ao peso que deve ser dado ao atributo de número x. Este peso é determinado pelo número de citações do atributo no "Modelo de Qualidade - Atributos" definido no item 2.1.3. Por exemplo, o atributo (requisito) 1.1 foi citado no modelo por quatro vezes nos dois sistemas, logo seu peso é quatro.  Sistema Zeus VFA = (10 * 4) + (10 * 2) + (10 * 1) + (10 * 1) + (10 * 1) + (10 * 1) = 100 = 10 4 + 2 + 1 + 1 + 1 + 1 10  Sistema Polus VFA = (7,5 * 4) + (10 * 1) + (10 * 1) + (10 * 1) + (10 * 1) + (10 * 1) = 80 = 8,88 4 + 1 + 1 + 1 + 1 + 1 9
  21. 21. 20 3 CONCLUSÃO O Valor Final da Avaliação (VFA) de qualidade do produto de software, determinou que o Software Zeus possui nota 10 , e o sistema Polus nota 8,88, por conseguinte, o julgamento, que permita a escolha por parte da empresa Golden Soluções Ltda, determinou que o sistema Zeus esta melhor avaliado segundo os padrões da ISO/IEC 14598.
  22. 22. 21 REFERÊNCIAS QUALIDADE DE SOFTWARE, Material1.pdf, Professor Roberto Couto, setembro de 2013.
  23. 23. 22 ANEXOS

×