Qualidade de Software - Departamento de...

Qualidade deSoftware

Sebastiao Pais

Engenharia deRequisitos

Visao Geral

Principaisatividades daengenharia derequisitos

Linguagens deEspecificacao

Gestao deRequisitos

Regras de ourodos requisitos desoftware

Conclusao

Qualidade de Software2o Ciclo de Engenharia Informatica, 1o Ano, 1o Semestre

Apontamentos Teoricas - Engenharia de Requisitos

Sebastiao Pais1

1Departamento de InformaticaUniversidade da Beira Interior

[email protected]://www.di.ubi.pt/~sebastiao

2016/2017

http://www.di.ubi.pt/~sebastiao


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Sumario

1 Engenharia de RequisitosVisao GeralPrincipais atividades da engenharia de requisitosLinguagens de EspecificacaoGestao de RequisitosRegras de ouro dos requisitos de softwareConclusao


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Visao Geral I

A engenharia de requisitos tem como finalidade descobrir osobjetivos para os quais o sistema de software se destina,envolvendo as atividades de descoberta, documentacao emanutencao dos requisitos para um determinado sistema. Eatraves dos levantamentos das necessidades de todas as partesenvolvidas e da consequente elaboracao da documentacao dosrequisitos que se faz a identificacao dos pontos a abordar, dasfuncionalidades a implementar e ate dos testes a realizar nodesenvolvimento da aplicacao.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Visao Geral II

Os requisitos sao definidos na fase inicial do desenvolvimentodo sistema como especificacoes a ser implementadas,descrevendo o comportamento, as propriedades e os atributosdo sistema, refletindo as necessidades dos stakeholders.Entendam-se como stakeholders todas as partes interessadas nodesenvolvimento da aplicacao.

Define-se como requisito de software:

• condicao ou capacidade necessitada por um utilizador pararesolver um problema ou atingir um objetivo;

• condicao ou capacidade que deve ser satisfeita no sistemaou componente do sistema com o objetivo de satisfazerum contracto, padrao ou especificacao;

• representacao documentada de uma condicao oucapacidade.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Sumario



Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Identificacao dos requisitos I

• Nesta fase e efetuado o levantamento dos requisitos paraum sistema futuro

• O principal objetivo e identificar o domınio da aplicacao,identificar os servicos que o sistema deve proporcionar, odesempenho e restricoes de uso do sistema.

• Estes requisitos sao obtidos atraves de:• entrevistas;• questionarios;• pesquisas e modelos de processos;• documentacao;• contractos com fornecedores;• atas de reunioes;• tecnicas de desenvolvimento.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Identificacao dos requisitos II

Na fase de identificacao dos requisitos podem ser encontradasvarias dificuldades, o que pode ocasionar erros na obtencao dosrequisitos devido a:

• ideias imprecisas do utilizadores sobre o que pretende dosistema;

• dificuldades dos utilizadores em descrever o domınio doproblema;

• pontos de vista do sistema diferentes, entre analistas eutilizadores;

• aversao do utilizador em utilizar o sistema, nao aceitandofazer parte da identificacao de requisitos.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Identificacao dos requisitos III

A identificacao de requisitos e uma atividade onde inicialmentese definem os objetivos organizacionais, seguindo-se a aquisicaode informacao de background e de enquadramento do sistemaa desenvolver, de forma a organizar e sistematizar a informacaorecolhida em estagios anteriores. Numa etapa muitoimportante deste processo, os stakeholders devem serconsultados metodicamente para a descoberta dos requisitos.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Analise e negociacao de requisitosI


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Analise e negociacao de requisitosII

• Oengenheiro de software especıfica as funcoes, odesempenho e as restricoes do sistema;

• O principal objetivo da fase de analise de requisitos eavaliar e conferir o documento de requisitos do software,obtendo uma especificacao de requisitos completa econsistente;

• Esta etapa pode incluir um esforco de negociacao para adefinicao formal dos requisitos do sistema, ja quetipicamente, diferentes grupos de stakeholders temexpectativas diferentes e frequentemente incompatıveisentre si do que devem ser as estrategias dedesenvolvimento e as funcionalidades do sistema adesenvolver.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Modelacao de requisitos I

Esta fase tem como principal objetivo o desenvolvimento demodelos que descrevem o que o sistema devera fazer,permitindo um maior entendimento da aplicacao e fornecendouma transicao para a fase do projeto.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Validacao de requisitos I

Durante a fase de validacao de requisitos, os analistas devemvalidar se os requisitos das especificacoes vao ao encontro dasnecessidades expressas pelos stakeholders. Neste contexto saoidentificados alguns problemas, como por exemplo:

• falta de conformidade com os padroes de qualidade;

• requisitos ambıguos ou mal formulados; erros conceptuaisno desenho de sistema;

• conflitos entre requisitos nao identificados na fase deanalise.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Documento de requisitos dosoftware I

O documento de requisitos do software contem os requisitosfuncionais e de qualidade do sistema. Este documento e ummeio de comunicacao entre o analista e o cliente, com oobjetivo de estabelecer um acordo sobre o software pretendido.Devido a sua importancia, e fundamental que esteja organizadode forma a melhorar a compreensao dos requisitos, evitandoque surjam erros na fase da implementacao da aplicacao.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Documento de requisitos dosoftware II

No documento de requisitos, deverao ser evitados os seguintesriscos no documento:

• nao incluir requisito crucial - este erro implicapreviamente que os requisitos deverao estar classificadospor prioridades. Caso haja um erro de classificacao(classificando como requisito secundario um requisitoprimario) ou caso nao se inclua, por total lapso, umrequisito vital, podera verificar-se um aumento do trabalhoa desenvolver para corrigir o erro. Caso esta omissao sejadetetada apenas na fase de testes, pode ser necessariofazer mudancas na estrutura do sistema e noscomponentes previstos, o que frequentemente podesignificar recomecar todo o processo;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Documento de requisitos dosoftware III

• falta de inspecoes nos requisitos - ao fazerregularmente inspecoes, podem detetar-se defeitosprecocemente, diminuindo o trabalho repetido e os custosa eles associados;

• representacao inadequada de clientes – se um conjuntode clientes / utilizadores forem representadosinadequadamente, e provavel que as suas necessidades emrelacao ao software que esta a ser desenvolvido nao estejapresentes no documento;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Documento de requisitos dosoftware IV

• busca da perfeicao nos requisitos antes de comecar aconstrucao do software - as alteracoes dos requisitos saoinevitaveis, e, portanto e necessario o controlo dasmudancas, devendo o responsavel do projeto estar atentoas solicitacoes de alteracao e procurando o preenchimentode lacunas antes da implementacao estar concluıda. Maisainda, e porque as estruturas de sucesso sao as quemostram adaptabilidade, os requisitos devem ser definidoscom a inerente assuncao da necessidade da sua posterioradaptacao a realidade dos stakeholders;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Documento de requisitos dosoftware V

• modelar apenas aspetos funcionais - a enfase naidentificacao de requisitos costuma ser maior em relacao arequisitos funcionais e nao tanto nos atributos naofuncionais, que estao relacionados com a qualidade dosoftware;

• estabelecer requisitos nao implementaveis ou naoevolutivas devem considerar-se as restricoes de hardwaree software para o projeto em questao, pois o custo final doproduto deve estar de acordo com o mercado ao qual sedestina e precisa ser competitivo;

• definir requisitos incorretamente - os requisitos devemser validados pelos stakeholders antes da fase de desenhoiniciar, com o objetivo de nao registar requisitos incorretos.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Sumario



Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Linguagens de Especificacao I

Devido a complexidade elevada que o software possui, existe anecessidade de definir com rigor todos os seus componentes,com a finalidade de produzir aplicacoes sem falhas. Aslinguagens de especificacao usadas na area de analise derequisitos sao o instrumento que permitem criar aplicacoes commaior fiabilidade.

Vantagens

• melhor compreensao dos requisitos do sistema;

• provar que as especificacoes do software foram cumpridas;

• identificar e definir casos de testes mais relevantes;

• identificar e corrigir erros no inicio do projeto, diminuindoos custos do projeto.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Linguagens de Especificacao II

Desvantagens

• dificuldade em demonstrar que com as especificacoes, ocusto total do projeto sera mais baixo;

• dificuldade em desenvolver as especificacoes formais,devido a falta de experiencia do analista;

• o cliente pode nao estar familiarizado com a linguagem deespecificacao;

• dificuldade em especificar componentes interativos.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Sumario



Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos I

Os requisitos sao entidades que podem ter prazos de validademuito curtos, devido a diversos fatores como por exemplomudancas externas ao ambiente (alteracao de legislacao,alteracoes de mercado ou alteracao de posicionamentoestrategico da empresa), erros ocorridos no processo derequisitos, variacao no estado do mercado, entre outras.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos II

Atividades na Gestao de Requisitos

• controlo de mudanca - uma das maneiras utilizadas paraorganizar as mudancas e utilizando uma biblioteca deversoes, o que permite ajudar no controlo de versoes;

• gestao de configuracao - tem como objetivo definircriterios que permitam realizar modificacoes deconfiguracao, mantendo a consistencia e integridade dosoftware com as especificacoes, minimizando os problemasrelacionados com o processo de desenvolvimento, atravesdo controlo sobre as modificacoes;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos III

• rastreabilidade - tem como objetivo a capacidade deacompanhar a vida de um requisito em ambas as direcoesdo processo de software e durante todo o seu ciclo,podendo ser de dois tipos: pre-rastreabilidade (rasto quefundamenta a criacao do requisito) e pos-rastreabilidade(rasto que se forma a partir do requisito criado, pelamesma alteracao).

Requisitos que sao mal interpretados pelo utilizadorfrequentemente causam falhas graves no projeto de software.Muitas organizacoes de desenvolvimento estao a melhorar nosmetodos que usam na recolha, analise, documentacao e gestaodos requisitos.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos IV

Tradicionalmente existem as seguintes limitacoes nadocumentacao de requisitos de software:

• dificuldade em gerir a documentacao (por exemplo,documentacao em excesso ou demasiado extensa, ouinversamente, documentacao escassa ou com falhas noconteudo, e ainda, documentacao escrita em linguagemque nao e facilmente compreensıvel, entre outros);

• dificuldade em comunicar mudancas aos membros afetosao projeto;

• dificuldade em armazenar informacoes complementaressobre cada requisito estando esta dificuldade sobretudorelacionada com a importancia da escolha da plataformade suporte a informacao do processo de desenvolvimento;

• dificuldade em definir ligacoes entre requisitos funcionais ecasos de uso, codigo, testes e tarefas de projeto.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos V

Por estas razoes e importante o uso de ferramentas de gestaode requisitos que armazenem os requisitos e disponibilizem umasolucao robusta. Estas ferramentas fornecem funcoes paramanipular e visualizar o conteudo de base de dados, importacaoe exportacao de requisitos, definir ligacoes entre requisitos eligacoes entre requisitos e outras ferramentas dedesenvolvimento de software.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos VI

Tarefas de gestao de requisitos que essas ferramentas podemajudar a executar

• gestao de versoes e mudancas - o projeto deve definiruma linha base de requisitos, um conjunto especıfico derequisitos que a versao devera conter e a historia dasmudancas feitas de cada requisito o que ira explicar asdecisoes anteriores e permitir reverter para uma versaoanterior;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos VII

• armazenamento dos atributos dos requisitos - devearmazenar-se uma variedade de informacao ou atributossobre cada requisito, para que qualquer pessoa quetrabalhe no projecto possa ser capaz de ver os atributos,seleccionar-los e modificar-los individualmente. Cada umadas ferramentas de gestao de requisitos devera gerar variosatributos definidos, como data de criacao, numero deversao e atributos de adicionais como autor, pessoaresponsavel, numero de lancamentos, prioridade, custo erisco;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos VIII

• ligacao dos requisitos a outros elementos do sistema– o rastreamento individual dos requisitos para outroscomponentes do sistema, permite que a equipa naonegligencie inadvertidamente os requisitos durante aimplementacao. Podem definir-se ligacoes entre diferentestipos de requisitos e os varios subsistemas, e por fim, aoanalisar o impacto de uma mudanca de um requisitoespecıfico, as ligacoes de rastreabilidade devem revelar osoutros elementos do sistema que podem afetar a mudanca;

• estado do rasto - o acompanhamento do rasto de cadarequisito durante o desenvolvimento ajuda a controlar oestado geral do projeto;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Gestao de Requisitos IX

• ver subconjuntos de requisitos - classificar, filtrar ouconsultar a base de dados para ver subconjuntos derequisitos e os valores dos atributos especıficos;

• controlo de acesso - definicao de permissoes parautilizadores e grupos de utilizadores, podendo assim apartilha de informacoes de requisitos com todos osmembros da equipa, mesmo que estejam geograficamenteseparados;

• comunicacao entre as partes interessadas – a maiorparte das ferramentas de gestao de requisitos permitemque a equipa discuta algumas ideias sobre os requisitos,utilizando mails e ferramentas on-line.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Sumario



Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Regras de ouro dos requisitos desoftware I

• medir os benefıcios da exigencia de teste com basenos testes de desenvolvimento - constituir um conjuntode metricas com o objetivo de medir os benefıcios retiradosdas necessidades de teste com base em comparacao com oteste completo, iniciado a seguir a fase de desenvolvimentoe onde esta analise vai certamente refletir grandesresultados em termos de tempo, esforcos e dinheiro;

• novo teste para confirmar - nova analise dos casos deteste com os requisitos do negocio e tao importante comoa nova verificacao de casos de teste construıda;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Regras de ouro dos requisitos desoftware II

• comecar os testes assim que uma unidade estejapronta - no final de cada modulo, deve ser feito o teste deunidade e teste de integracao;

• construir um repositorio de casos de teste - construirum repositorio de casos de teste permite economia detempo, para cenarios de requisitos semelhantes;

• alteracao dos casos de teste com a mudanca derequisitos - para efeitos de requisitos, deve-se alterar oscasos de teste apos a compreensao das mudancas exigidas(documentado e assinado);


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Regras de ouro dos requisitos desoftware III

• confirmar a cobertura completa dos requisitos emcasos de teste - assegurar que as coberturas dosrequisitos sao completas e adequadas com a necessidadedo negocio em relacao ao produto construıdo, podendoresultar em desastre, caso a cobertura nao seja completa;

• o conhecimento do negocio e tao importante quantoo conhecimento de testes – a regra dos 50:50 eaplicavel para ambos os casos, ou seja, 50% dosconhecimentos deve ser tecnicos e os outros 50% deconhecimentos de negocio;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Regras de ouro dos requisitos desoftware IV

• comecar a construir os casos de teste conjuntamentecom o desenvolvimento – ao mesmo tempo que o gestordo projeto efetua a gestao das tarefas da equipa dedesenvolvimento, a equipa de testes deve construir oscasos de teste com base nos requisitos de software;

• requisito reservado nao significa nao haver mudancas- nao se deve fechar as portas para mudancas nosrequisitos de negocio apos a fase inicial de estudo, pois asregras do negocio e as empresas mudam;


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Regras de ouro dos requisitos desoftware V

• documentacao com requisitos claros e completos - osrequisitos de teste sao baseados em requisitosestabelecidos pelo cliente ou patrocinador do software epor isso e importante a documentacao dos requisitos aonıvel dos utilizadores e ao nıvel da gestao, pois qualquerfalta ou requisito menos claro pode causar problemas naexecucao e implementacao do projecto.


Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Sumario



Sebastiao Pais


Visao Geral



Gestao deRequisitos


Conclusao

Conclusao I

A importancia do processo da engenharia de requisitos, com oobjetivo da melhoria da qualidade do processo dedesenvolvimento. Nenhuma das propostas se ajusta naperfeicao no projeto e por isso nao ha obrigacao de seguirrigorosamente os modelos apresentados.

Qualidade de Software - Departamento de...

Documents

Transcript of Qualidade de Software - Departamento de...