ENGENHARIA DOS REQUISITOS - profcelso.orgfree.comprofcelso.orgfree.com/Arquivos_Aulas/06-Qualidade_Soft/AULAS/03... · ADS / REDES / ENGENHARIA Prof. Celso Candido QUALIDADE DE SOFTWARE

ADS / REDES / ENGENHARIA Prof. Celso Candido

QUALIDADE DE SOFTWARE

1

ENGENHARIA DOS REQUISITOS

Apostila Estácio: Engenharia de Software de Roger

S. Pressman. 6º Edição/2006


QUALIDADE DE SOFTWARE

2


QUALIDADE DE SOFTWARE ENGENHARIA DOS REQUISITOS

3

A engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.

Este processo deve ser precedido de estudos que viabilizem a partir das restrições do projeto, determinando se este é ou não viável e se deve prosseguir para a identificação dos requisitos.



4

O processo de engenharia de requisitos é composto por cinco atividades de alto nível (THA, 1997), para que possamos entender o que o cliente deseja:

1. Identificação. 2. Análise e negociação. 3. Especificação e documentação. 4. Validação. 5. Gerindo os requisitos.



5

O processo de engenharia de requisitos é realizado por meio da execução de sete funções distintas: 1. Concepção. 2. Levantamento. 3. Elaboração. 4. Negociação. 5. Especificação. 6. Validação. 7. Gestão. Algumas dessas funções ocorrem em paralelo, sendo no geral, todas adaptadas às necessidades do projeto, tentando definir o desejo do cliente, estabelecendo uma fundação sólida e equilibrada para o projeto.



6



7

Apostila – Como podemos iniciar um projeto de software?

Não existem resposta para essas perguntas. Não se trata de seguir determinadas regras, mas interligar com a experiência da engenharia em identificar as necessidades do cliente.

CONCEPÇÃO

Apostila – Existe um evento único que se torna catalisador de um novo sistema ou produto baseado em computador que conforme a necessidade evolui com o passar do tempo?

Muitos dos assuntos relacionados ao seu conteúdo e a forma de como deverá ser desenvolvido precisam estar claramente determinados, exemplificados e rascunhados, contendo a aprovação de todos interessados no projeto.



8

Para o início do projeto, as vezes um conversa casual seria tudo que a engenharia de software necessitaria para começar um esboço.

No geral todo início de projeto está ligado a alguma necessidade de mercado ou negócio.

CONCEPÇÃO

Na realidade o que acontece na “Concepção” é que os engenheiros de software estabelecem um série de questões livres de contextos com a intenção de estabelecer um entendimento básico do problema.

Essa necessidade leva os gerentes do negócio/produto e a área de marketing a definir a idéia principal e tentar identificar as necessidades e abrangência de mercado através de análises de viabilidade, elaborando uma descrição do funcionamento do escopo do projeto.



9

REQUISITOS

ATIVIDADES DE ALTO NÍVEL FUNÇÕES

ü Identificaçãoü Análise e Negociaçãoü Especificação e Documentaçãoü Validaçãoü Gerindo

ü Concepçãoü Levantamentoü Elaboraçãoü Negociaçãoü Especificaçãoü Validaçãoü Gestão

Concepção

ü Esboçoü Mercado de

Negócioü Idéia Principalü Necessidadesü Abrangência

Levantamento Elaboração Negociação Especificação Validação Gestão

CONCEPÇÃO



10

O levantamento dos requisitos é muito simples:

ü Pergunte ao cliente, aos usuários e aos outros quais são os objetivos do sistema ou do produto?

LEVANTAMENTO

Infelizmente não é simples, é muito difícil.

ü O que precisa ser conseguido?

ü Como o sistema ou o produto se encaixa nas necessidades do negócio?

ü Como o sistema ou o produto será usado no dia a dia?

Muito simples, quatro perguntas resolvem todos os problemas.



11

Christel e Kang (1992) identificam vários problemas que nos ajudam a compreender por que o levantamento é tão difícil:

LEVANTAMENTO

ü Problemas de escopo – Se o limite do sistema for mal definido ou o cliente/usuário especificar detalhes técnicos não necessários, estes poderão confundir em vez de esclarecer os objetivos gerais do sistema.

ü Problemas de entendimento:

Clientes/usuários em muitas das vezes não estão totalmente corretos sobre as necessidades do sistema.

No geral possuem pouca compreensão das capacidades e limitações que seu ambiente computacional oferece para o desenvolvimento.



12

LEVANTAMENTO

Possuem dificuldades de passar aos engenheiros as informações que acreditam ser “óbvias”.

ü Problemas de votabilidade – Este é simples, são os requisitos que mudam ao longo do tempo.

Especificam requisitos que conflitem com as necessidades de outros clientes/usuários.

Especificam requisitos ambíguos (podem seguir mais de um sentido) ou impossíveis de testar.

Organização é tudo na coleta de dados para os Requisitos.



13

REQUISITOS




Concepção



Levantamento

ü Escopoü Entendimentoü Votabiliade

Elaboração Negociação Especificação Validação Gestão

LEVANTAMENTO



14

ELABORAÇÃO

São o refinamento das informações obtidas do cliente na concepção e no levantamento.

A elaboração de uma modelagem de análise (UML) descrevendo como o usuário final e outros atores irão interagir com o sistema.

Cada cenário é analisado para extrair as classes das análises visíveis ao usuário final.

Os atributos de classes são definidos e os serviços requeridos pelas classes identificados.

Os relacionamentos e colaborações entre classes são identificados. Vários diagramas UML suplementares costumam ser elaborados. Teremos como resultado final de um modelo de análise que define: as informações, funcionalidades e sistemas comportamentais.



15

REQUISITOS




Concepção



Levantamento



ü Refinamentoü Elaboração UMLü Classesü Atributosü Relacionamentosü Colaborações

ELABORAÇÃO



16

NEGOCIAÇÃO

Fase em que clientes e usuários costumam pedir mais do que pode ser conseguido, não considerando os recursos limitados do negócio. São ouvidas propostas de clientes/usuários com requisitos conflitantes, argumentando ser “essenciais para suas necessidades especiais”. Quando isso acontece, é muito importante reconciliar esses conflitos usando processos de negociação. A partir desses conflitos precisamos solicitar aos clientes/usuários que ordenem os requisitos e discutam os conflitos de prioridade. Os riscos associados aos requisitos precisam ser identificados e analisados. Elaborar “estimativas”, mesmo que grosseiras, do desenvolvimento para avaliar os impactos de cada requisito no custo e no prazo de entrega do projeto.



17

NEGOCIAÇÃO REQUISITOS




Concepção



Levantamento




ü Processos Conflitantes

ü Riscosü Estimativas de

Prazos e Custos



18

ESPECIFICAÇÃO

No geral uma especificação pode ser:

ü Um documento escrito; ü Um modelo gráfico; ü Um modelo matemático; ü Uma coleção de cenários de uso; ü Um protótipo; ü Enfim, qualquer combinação desses elementos.

Alguns engenheiros preferem usar um “gabarito padrão” para elaborar suas especificações, isso torna a apresentação dos requisitos mais consistente.

No entanto, algumas vezes isso não possível, e se faz necessário elaborar especificações mais flexíveis.



19

ESPECIFICAÇÃO

Quando desenvolvemos grandes sistemas, um documento escrito, combinando descrições em linguagem natural e modelos gráficos que podem ser uma melhor abordagem para o problema.

Precisamos mentalizar que a especialização é o produto final produzido pelo engenheiro de requisitos, servido para:

Já para produtos ou sistemas menores residentes em um ambiente técnico com um bom desenvolvimento, somente os cenários de uso sejam o suficiente.

ü Descrever a função; ü Descrever o desempenho de um sistema baseado em computador; ü Descrever as restrições que orientarão o seu desenvolvimento.



20

REQUISITOS




Concepção



Levantamento




ü Processos Conflitantes

ü Riscosü Estimativas de

Prazos e Custos

ü Funçõesü Desempenhoü Restrições

ESPECIFICAÇÃO



21

VALIDAÇÃO

É nesta fase que os produtos são avaliados quantos a qualidade.

ü As inconsistências; ü Omissões; ü Erros tenham sido declarados e corrigidos; ü Produtos de trabalho de acordo com as normas estabelecidas para:

Garante que todos os requisitos do software tenham sido declarados de modo não tomar mais de um sentido, quanto:

o Processo; o Projeto; o Produto.

O principal mecanismo de validação de requisitos é a revisão técnica formal, que será vista mais adiante.



22

VALIDAÇÃO

Apostila, pag. 120 – Checklist de Validação dos Requisitos:

ü Os requisitos foram claramente estabelecidos para não serem mal interpretados?

ü A fonte do requisito foi identificada e examinada pela fonte original ou com ela?

ü O requisito está limitado em termos quantitativos?

ü Que outros requisitos se relacionam a este requisito?

ü O requisito viola alguma restrição do domínio?

ü O requisito pode ser testado? Se sim, podemos especificar os testes?



23

VALIDAÇÃO

ü Podemos relacionar o requisito a qualquer modelo de sistema que tenha sido criado?

ü O requisito está relacionado aos objetos globais do sistema/produto?

ü A especificação do sistema está estruturada de modo que seja:

ü Foi criado um índice para a especificação?

ü Os requisitos associados ao desempenho, ao comportamento e às características operacionais do sistema foram claramente declarados? Que requisitos parecem estar implícitos?

o Leve e de fácil entendimento? o Fácil referenciação? o Fácil tradução em produtos de trabalho mais técnicos?



24

VALIDAÇÃO REQUISITOS




Concepção

ü Esboço.ü Mercado de

Negócio.ü Idéia

Principal.ü Necessidades.ü Abrangência.

Levantamento

ü Escopo.ü Entendimento.ü Votabiliade.


ü Refinamento.ü Elaboração

UML.ü Classes.ü Atributos.ü Relacioname-

ntos.ü Colaborações.

ü Processos Conflitantes.

ü Riscos.ü Estimativas

de Prazos e Custos.

ü Funções.ü Desempenho.ü Restrições.

ü Inconsistências.ü Omissões.ü Erros.ü Normas: Processo; Projeto; Produto.



25

GESTÃO

A gestão dos requisitos é um conjunto de atividades que ajudam a equipe de projeto a:

A gestão dos requisitos começa com a forma de identificação que é atribuída a cada requisito, sendo desenvolvidas tabelas de rastreamento, onde estas estão relacionados aos requisitos identificados a um ou mais aspectos do sistema ou ao seu ambiente.

ü Identificar; ü Controlar; ü Rastrear os requisitos e suas modificações em qualquer

época.



26

GESTÃO

Tabela de Rastreamento Genérico

Requisitos Aspectos específicos do sistema ou de seu

ambiente A01 A02 A03 A04 A05 A06 A07 A08 Aii

R01 √ √ R02 √ √ R03 √ √ √ R04 √ √ R05 √ √ √ √ R06 R07 Rii √ √

Exemplo da apostila Estácio do autor “Roger S. Pressman” 6ª Edição/2006, pag. 122.



27

GESTÃO

A tabela apresentada é genérica, mas temos outras tabelas:

ü De rastreamento de características; ü De rastreamento de fontes; ü De rastreamento de dependências; ü De rastreamento de subsistemas; ü De rastreamento de interface.

Para mais informações sobre essas tabelas, consulte a página 121 da apostila Estácio do autor “Roger S. Pressman” 6ª Edição/2006.



28

GESTÃO REQUISITOS




Concepção

ü Esboço.ü Mercado de

Negócio.ü Idéia

Principal.ü Necessidades.ü Abrangência.

Levantamento

ü Escopo.ü Entendimento.ü Votabiliade.


ü Refinamento.ü Elaboração

UML.ü Classes.ü Atributos.ü Relacioname-

ntos.ü Colaborações.

ü Processos Conflitantes.

ü Riscos.ü Estimativas

de Prazos e Custos.

ü Funções.ü Desempenho.ü Restrições.

ü Inconsistên-cias.

ü Omissões.ü Erros.ü Normas: Processo; Projeto; Produto.

ü Identificação.ü Controle.ü Rastreamento.



29

LEITURA DA APOSTILA

Consulte o material didático: Faça uma leitura do material

didático referente a apostila “Engenharia de Software. 6º

Edição/2006 de Roger S. Pressman, págs. 116 à 122.

Uma especial atenção para a pag. 121, item “Ferramentas de

Software”, leitura obrigatória.



30

AULAS DE APOIO

Estarão disponibilizadas nos descritos a baixo para downloads os arquivos nos formatos: PowerPoints ou Word das aulas. Alguns estarão disponíveis para impressão, outros, somente para leitura, mas não para edição. Em alguns casos em que se fizer necessário a impressão, o professor estará liberando para um melhor desenvolvimento dos trabalhos a ser solicitados.

www.aulasprof.6te.net ou www.profcelso.orgfree.com/

Contato: [email protected]



31

FIM

Documents

ENGENHARIA DOS REQUISITOS - profcelso.orgfree.comprofcelso.orgfree.com/Arquivos_Aulas/06-Qualidade_Soft/AULAS/03... · ADS / REDES / ENGENHARIA Prof. Celso Candido QUALIDADE DE SOFTWARE