Arquitetura de Software

Aula 2: Atributos de Qualidade

Prof. Dr. Bruna C. Rodrigues da Cunha
bruna.rodrigues@ifsp.edu.br
Avaliação Diagnóstica
Desenhe o Diagrama de Classes e o Diagrama de Sequência:
● Pokémon são monstrinhos que batalham. Eles possuem um nome, um tipo, um
apelido e 4 golpes
● Um Pokémon pode ter um Treinador que possui nome, idade, cidade de origem
e compete em uma Liga
● Uma Liga possui um nome, um nível, uma localização e campeões, que são os
Treinadores a serem desafiados na Liga
● Uma Liga pode ter vários treinadores competidores. Treinadores podem
competir em várias Ligas. No entanto, campeões podem fazer parte de apenas
uma Liga.
● Para um Treinador se inscrever em uma Liga ele precisa enviar um pedido de
inscrição para o Conselho. Se o Conselho aprovar a inscrição, ela será
encaminhada para a Liga, que então realiza o cadastro do competidor.
Definições
● Requisitos Funcionais: (o que o sistema faz)

● Requisitos Não-Funcionais: (como o sistema faz) Também designados

Atributos de qualidade!
Definições
● Se um requisito funcional é “Quando o usuário pressiona o botão
verde, o diálogo Opções aparece”, um atributo de qualidade de
desempenho, por exemplo, pode descrever “o quão rapidamente o
diálogo irá aparecer”, enquanto um atributo de qualidade de
disponibilidade pode descrever “a frequência com esta função irá
falhar e quão rápido ela será reparada”.
● A arquitetura provê a fundação para alcançar atributos de qualidade. No
entanto essa fundação não é suficiente se o desenvolvimento não for
eficiente.
Atributos de Qualidade
Em software de alta complexidade, a obtenção de qualidades - como
desempenho, disponibilidade, segurança e modificabilidade - depende da
arquitetura do software. Além disso, os atributos de qualidade de sistemas
grandes podem ser altamente limitados pelos requisitos e restrições do
sistema.

Assim, é importante tentar determinar o mais cedo possível se o sistema terá

as qualidades desejadas. Os requisitos de qualidade devem ser descritos
concretamente antes que uma arquitetura seja desenvolvida (Barbacci et al.,
2003).
Requisitos de Qualidade NBR ISO/IEC 9126-1:2003
Requisitos de Qualidade
● Qualidade interna é a totalidade das características do produto de
software do ponto de vista interno. A qualidade interna é medida e
avaliada com relação aos requisitos de qualidade interna. Detalhes da
qualidade do produto de software podem ser melhorados durante a
implementação do código, revisão e teste, mas a natureza fundamental
da qualidade do produto de software representada pela qualidade
interna mantém-se inalterada, a menos que seja reprojetada.
Requisitos de Qualidade
● Qualidade externa é a totalidade das características do produto de
software do ponto de vista externo. É a qualidade quando o software é
executado, o qual é tipicamente medido e avaliado enquanto está sendo
testado num ambiente simulado, com dados simulados e usando
métricas externas. Durante os testes, convém que a maioria dos defeitos
seja descoberta e eliminada. Entretanto, alguns defeitos podem
permanecer após o teste. Como é difícil corrigir a arquitetura do software
ou outro aspecto básico do projeto do software, a base do projeto
usualmente permanece inalterada ao longo do teste.
Requisitos de Qualidade
● Os requisitos de qualidade externa especificam o nível de qualidade
requerido sob o ponto de vista externo. Eles incluem requisitos derivados
das necessidades de qualidade dos usuários, incluindo os requisitos de
qualidade em uso. Os requisitos de qualidade externa são usados como
meta para validação em vários estágios de desenvolvimento.
Requisitos de Qualidade
● Os requisitos de qualidade interna especificam o nível de qualidade
requerido sob o ponto de vista interno do produto. Os requisitos de
qualidade interna são usados para especificar as propriedades dos
produtos intermediários. Estes podem incluir modelos estáticos e
dinâmicos, outros documentos e código-fonte. Requisitos de qualidade
interna podem ser usados como metas para validação em vários estágios
de desenvolvimento. Eles também podem ser usados para definir
estratégias de desenvolvimento e critérios de avaliação e de verificação
durante o desenvolvimento.
Verificação x Validação
● A verificação tem o objetivo de avaliar se o que foi planejado realmente
foi realizado.
● A validação tem o objetivo de avaliar se o que foi entregue atende as
expectativas do cliente.
Modelo de Qualidade NBR ISO/IEC 9126-1:2003
● Categoriza atributos de qualidade
Funcionalidade
Capacidade do produto de software de prover funções que atendam às necessidades explícitas e
implícitas, quando o software estiver sendo utilizado sob condições especificadas.
● Adequação: Capacidade do produto de software de prover um conjunto apropriado de
funções para tarefas e objetivos do usuário especificados.
● Acurácia: Capacidade do produto de software de prover, com o grau de precisão necessário,
resultados ou efeitos corretos ou conforme acordados (corretude e completude).
● Interoperabilidade: Capacidade do produto de software de interagir com um ou mais
sistemas especificados.
● Segurança de acesso: Capacidade do produto de software de proteger informações e dados,
de forma que pessoas ou sistemas não autorizados não possam lê-los nem modificá-los.
● Conformidade relacionada à funcionalidade: Capacidade do produto de software de estar
de acordo com normas, convenções ou regulamentações previstas em leis e prescrições
similares relacionadas à funcionalidade.
Confiabilidade
Capacidade do produto de software de manter um nível de desempenho especificado,
quando usado em condições especificadas.
● Maturidade: Capacidade do produto de software de evitar falhas decorrentes de
defeitos no software.
● Tolerância a falhas: Capacidade do produto de software de manter um nível de
desempenho especificado em casos de defeitos no software ou de violação de sua
interface especificada.
● Recuperabilidade: Capacidade do produto de software de restabelecer seu nível
de desempenho especificado e recuperar os dados diretamente afetados no caso
de uma falha.
● Disponibilidade (2011): refere-se a propriedade do software de estar acessível e
pronto para executar uma tarefa quando solicitada.
Usabilidade
Capacidade do produto de software de ser compreendido, aprendido, operado e atraente
ao usuário, quando usado sob condições especificadas.
● Inteligibilidade: Capacidade do produto de software de possibilitar ao usuário
compreender se o software é apropriado e como ele pode ser usado para tarefas e
condições de uso específicas.
● Apreensibilidade: Capacidade do produto de software de possibilitar ao usuário
aprender sua aplicação.
● Operacionalidade: Capacidade do produto de software de possibilitar ao usuário
operá-lo e controlá-lo.
● Atratividade: Capacidade do produto de software de ser atraente ao usuário.
● Acessibilidade (2011): Adaptação do sistema às necessidades do usuário
● Predição e recuperação de erros (2011): minimização do impacto de erros.
● Adequação e Reconhecimento (2011): conformidade.
Eficiência
Capacidade do produto de software de apresentar desempenho apropriado,
relativo à quantidade de recursos usados, sob condições especificadas.
● Comportamento em relação ao tempo: Capacidade do produto de
software de fornecer tempos de resposta e de processamento, além de
taxas de transferência, apropriados, quando o software executa suas
funções, sob condições estabelecidas.
● Utilização de recursos: Capacidade do produto de software de usar
tipos e quantidades apropriados de recursos, quando o software executa
suas funções sob condições estabelecidas.
Manutenibilidade
Capacidade do produto de software de ser modificado. As modificações podem incluir
correções, melhorias ou adaptações do software devido a mudanças no ambiente e
nos seus requisitos ou especificações funcionais.
● Analisabilidade: Capacidade do produto de software de permitir o diagnóstico de
deficiências ou causas de falhas no software, ou a identificação de partes a serem
modificadas.
● Modificabilidade: Capacidade do produto de software de permitir que uma
modificação especificada seja implementada.
● Estabilidade: Capacidade do produto de software de evitar efeitos inesperados
decorrentes de modificações no software.
● Testabilidade: Capacidade do produto de software de permitir que o software,
quando modificado, seja validado. Se refere à facilidade com que um software
pode ser feito para demonstrar seus erros por meio de testes.
Portabilidade
Capacidade do produto de software de ser transferido de um ambiente para outro.
● Adaptabilidade: Capacidade do produto de software de ser adaptado para
diferentes ambientes especificados, sem necessidade de aplicação de outras ações
ou meios além daqueles fornecidos para essa finalidade.
● Capacidade para ser instalado: Capacidade do produto de software para ser
instalado em um ambiente especificado.
● Coexistência: Capacidade do produto de software de coexistir com outros
produtos de software independentes, em um ambiente comum, compartilhando
recursos comuns.
● Capacidade para substituir: Capacidade do produto de software de ser usado em
substituição a outro produto de software especificado, com o mesmo propósito e
no mesmo ambiente.
Modelo de Qualidade ISO/IEC 25010:2011
Segurança
Segurança é a medida da habilidade de um sistema de proteger dados e resistir a acessos
não autorizados enquanto proveem serviços a usuários e sistemas que são autorizados.
Segurança pode ser caracterizada pelas características:
● Confidencialidade: garante que dados ou serviços são protegidos contra o acesso não
autorizado.
● Integridade: garante que dados ou serviços não estão sujeitos a manipulação não
autorizada.
● Disponibilidade: garante que o sistema estará disponível para uso legítimo.
● Autenticação: garante ambas as partes de uma transação são quem eles dizem ser.
● Não Repudiação: garante que o remetente de uma mensagem não pode negar ter
enviado e que o destinatário não pode negar ter recebido.
● Auditoria: garante o rastreamento de atividades de forma que o sistema possa
reconstruí-las.
Modelo de Qualidade em Uso
● Perspectiva do usuário
Qualidade em Uso
Capacidade do produto de software de permitir que usuários especificados atinjam metas
especificadas com eficácia, produtividade, segurança e satisfação em contextos de uso
especificados.
● Eficácia: Capacidade do produto de software de permitir que usuários atinjam metas
especificadas com acurácia e completitude, em um contexto de uso especificado.
● Produtividade: Capacidade do produto de software de permitir que seus usuários
empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um
contexto de uso especificado.
● Segurança: Capacidade do produto de software de apresentar níveis aceitáveis de riscos
de danos a pessoas, negócios, software, propriedades ou ao ambiente, em um contexto
de uso especificado.
● Satisfação: Capacidade do produto de software de satisfazer usuários, em um contexto
de uso especificado.
Tradeoffs
● É uma decisão situacional que envolve diminuir ou perder uma qualidade,
quantidade ou propriedade de design em troca de ganhos em outras
● Portabilidade x Segurança
● Eficiência x Segurança
● Usabilidade x Segurança
● Usabilidade x Eficiência
● Disponibilidade x Manutenibilidade
Referências
● ABNT – Associação Brasileira de Normas Técnicas. Engenharia de
software - Qualidade de produto Parte 1: Modelo de qualidade:
Norma NBR ISO/IEC 9126-1:2003.
● Barbacci, M. R., Ellison, R., Lattanze, A. J., Stafford, J. A., & Weinstock, C. B.
(2003). Quality attribute workshops (qaws) (No. CMU/SEI-2002-TR-016).
CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST.
● ISO (2011). ISO/IEC 25010:2011: Systems and software engineering --
Systems and software Quality Requirements and Evaluation (SQuaRE) --
System and software quality models. Thecnical report, International
Organization for Standardization (ISO), Geneva, Switzerland.