Engenharia de Software – Ciclo de vida e requisitos de software

Professor: Saulo Henrique Cabral Silva

Instituto Federal de Minas Gerais Campus Ponte Nova

PORQUE O USO DA ENGENHARIA DE SOFTWARE ???

2

As estatísticas dos projetos de software

• Porcentagem de projetos que terminam dentro do prazo:

10%

• Porcentagem de projetos que são descontinuados antes de

chegarem ao fim: 25%

• Porcentagem de projetos acima do

custo esperado: 60%

• Atraso médio dos projetos: 1 ano

3

Quando voces vão construir uma casa você espera o que…

• Espero que tudo que eu imaginei seja construído e com qualidade. – 3 quartos

– Sala ampla

– Lugar pra churrasqueira

– Área de serviço

– Escritório

– Cozinha ampla

– Uma horta

– Garagem pra dois caros

– ...

4

5

Porque uso da engenharia de Software 2.147.483.647

6

Mostrar Vídeo com o foguete Ariane 5 (1996) decolando com problemas de software...

https://www.youtube.com/watch?v=gp_D8r-2hwk

Uma década de desenvolvimento $7.5 Bi

CICLO DE VIDA

7

Ciclo de vida clássico

8

Ciclo de vida clássico – Volume de Trabalho

9

LEVANTAMENTO DE REQUISITOS

10

Pedido clássico de um cliente…

11

Preciso de um programa simples, para GERENCIAR meu negócio, NADA muito sofisticado não...

Levantamento de requisitos

• Levantamento das “características” ou “necessidades”.

• Requisitos funcionais e não funcionais.

• Funcionais: São características que representam os comportamentos que um programa ou sistema deve apresentar durante certas ações de seus usuários.

• Não funcionais: que quantificam determinados aspectos do

comportamento.

• Em um software os requisitos devem ser entregues.

12

Levantamento de requisitos - Especificação

• Os requisitos ainda se dividem em: – Explícitos: são aqueles que foram descritos em um documento que

deve ser formalizado e homologado junto aos interessados e a equipe do projeto.

– Normativos: são aqueles de decorrem de leis, regulamentos, padrões

e outros tipos de normas a que o tipo de produto possa obedecer.

– Implícitos: são expectativas dos clientes e usuários, que são cobradas

por estes, embora não tenham sido documentadas.

13

PROBLEMAS!!!!

14

Problemas - Levantamento de requisitos

• Requisitos implícitos são indesejáveis, uma vez que não foram documentados e provavelmente não foram pensados durante a fase de desenho do produto.

• Mesmo requisitos

documentados podem

apresentar problemas,

uma vez que os mesmos

são passíveis de serem

documentados de forma

errada ou ambígua.

15

EXERCITANDO - CLASSIFICANDO ALGUNS REQUISITOS

16

Exemplos – classifique os requisitos

• O Sistema deve responder no tempo máximo de 200 ms.

• Ao final de toda operação o usuário deverá receber um número de protocolo.

• O sistema deve ser adaptado para proporcionar acessibilidade a pessoas com deficiência visual.

• O sistema deve requisitar do usuário seu cpf e sua senha para efetuar o login.

• O Sistema deve ser acessado de qualquer lugar que se disponha de internet.

17

Exemplos – classifique os requisitos

• O sistema deve proporcionar o usuário a opção de recuperação de senha.

• Caso o usuário permaneça mais de 2 minutos inativo, o mesmo deve ser deslogado (logout) do sistema.

• Na area principal o usuário deverá visualizar suas informações

pessoais.

• O Sistema precisa de uma máquina com pelo menos 1 TB de disco rígido.

• O sistema deve discriminar todas as informações sobre cada pagamento realizado ao funcionário. (créditos e débitos)

18

PROCESSO PARA A DESCRIÇÃO DE REQUISITOS

19

Processo para descrição de requisitos de software

20

• Os analistas devem desenvolver sua compreensão do domínio da aplicação;

• Coleta: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;

• Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;

• Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;

Comentários sobre as etapas de levantamento de requisitos

21

Comentários sobre as etapas de levantamento de requisitos

• Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;

• Os requisitos devem ser verificados

para descobrir se estão completos

e consistentes e se estão em

concordância com o que os

stakeholders desejam do sistema.

22

TÉCNICAS PARA LEVANTAMENTO DE REQUISITOS

23

Técnicas para levantamento de requisitos

• Orientado a ponto de vista

• Etnografia

• Prototipagem

• Entrevistas

• Questionários

• Brainstorming

• JAD

24

Levantamento de requisitos orientado a ponto de vista

• Grande maioria dos sistemas existentes possuem diferentes perfis de usuários. – Por este motivo existem muitos pontos de vista diferentes que devem

ser considerados. – Nesta técnica de levantamento estamos atrás dos diferentes “pontos de vista” de cada um dos usuários. (um mesmo problema é visto de forma diferente pelos usuários)

• No Levantamento de requisitos orientado a ponto de vista reconhecemos os diferentes pontos de vista e estes são utilizados para organizar e estruturar os requisitos comuns.

25

Levantamento de requisitos orientado a ponto de vista

• Primeira etapa: corresponde a identificação dos possíveis pontos de vista. – Abordagem de reunião (livre posicionamento entre os participantes)

• Segunda etapa: estruturação dos pontos de vista, envolve agrupar pontos de vista relacionados (serviços comuns).

• A etapa de documentação (terceira etapa) tem como principal objetivo refinar a descrição dos pontos de vista e serviços identificados.

• O mapeamento do sistema (quarta etapa) envolve uma primeira identificação dos objetos que interagem com o sistema.

26

Etnografia

• Nesta técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado. – Principal objetivo: descobrir requisitos do sistema que ainda estão

implícitos.

– Analisamos como tudo funciona na prática e não apenas analisando um processo em documento.

• Itens a serem planejados e discutidos nesta técnica: – Identificar as áreas de usuários a serem observadas e obter autorização

da chefia para efetuar as observações necessárias.

– Familiarizar com o ambiente de trabalho, montar planos estatísticos com relação a frequência de determinadas tarefas acontecem.

– Documentar e rever cada observação com os

interessados e com as pessoas observadas.

27

Prototipagem

• Implementação de um pequeno conjunto de funcionalidades. – Técnica muito utilizada para levantar necessidades com relação a

usabilidade.

28

Entrevistas

• Focalizar em um escopo do sistema.

• É preciso ter feito leituras e observações a priori antes da entrevista.

• Importante encontrar quais partes do sistema o usuário se sente mais a vontade de expor suas ideias.

• Após a entrevista é preciso ainda validar todas as anotações com o que foi exposto pelo entrevistado

• Uma entrevista não é uma competição! (evitar uso de termos técnicos)

29

Entrevista perguntas…

• Explique o relacionamento entre o que está em discussão e as demais partes do sistema.

• Descreva o ponto de vista de outros usuários em relação ao item que esta sendo discutido.

• Descreva informalmente o que esta sendo

requisitado,

• O que mais esta relacionado ao assunto

discutido? Quais as suas contribuições...

30

Brainstorm

• Brainstorm = Chuva de ideias

• Ideal para as fazes iniciais do levantamento de requisitos.

• Alguns pontos a serem planejados antes de iniciar uma Brainstorm: – Pessoas bem informadas garantem uma

boa representação;

– Preferencial que o grupo seja composto

por pessoas de diferentes áreas.

31

Brainstorm

• No brainstorm as idéias que a princípio pareçam não convencionais, são encorajadas: – pois elas frequentemente estimulam os participantes;

– Levam a soluções criativas para os problemas;

• O número de idéias deve ser bem grande, quanto mais idéias forem

propostas, maior a chance de

aparecerem boas.

• A fase final do brainstorm é a análise: – As valiosas são mantidas;

– Classifica-se as idéias.

32

JAD

• JAD (Joint Application Design) é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os usuários e os desenvolvedores.

• Os usuários ajudam os usuários a formular problemas e explorar soluções. – Usuários ganham sentimento de envolvimento,

posse e responsabilidade com o sucesso do

produto.

33

Princípios do JAD

• Dinâmica de grupo: líder, analista, usuários e gerentes.

• Uso de técnicas visuais: aumentar o entendimento e comunicação.

• Manutenção do processo organizado e racional: Realizado sempre no sentido top down.

• Utilização de documentação padrão:

preenchida e assinada por todos os

participantes. Garante a qualidade e

promove confiança dos participantes.

34

JAD - participantes

• Líder da sessão: facilitador de encontros, deve possuir bom relacionamento pessoal e qualidade de gerencia e liderança.

• Engenheiro de requisitos: responsável pelos documentos de saída. (Geralmente é um desenvolvedor bem experiente tradução do que é discutido).

• Executor: responsável pelo produto

sendo construído. (no geral, toma

conta da distribuição dos recursos

que podem afetar os requisitos)

35

JAD - participantes

• Representante dos usuários: Pessoas-chave que possuem uma visão melhor de como o todo será utilizado. (Gerentes, ou funcionários que operam diretamente o produto)

• Representantes de produtos de software: Possuem a responsabilidade de ajudar os usuários a entender o que é razoável ou possível que o novo

produto faça.

• Especialistas das mais diversas

áreas. (opcional)

36

PEQUENO EXEMPLO DE ESPECIFICAÇÃO DOS REQUISITOS

37

Exemplo – Sistema de Controle de Vacinação (RF)

• [RF001] Cadastro de usuários: – O sistema deve permitir cadastro de usuários com as respectivas

permissões: criar, alterar, buscar (pacientes, vacinas e campanhas).

• [RF002] Cadastro de pacientes: – O administrador ou ao usuário podem realizar o cadastro de pacientes

contendo os campos nome, endereço, RG, CPF, telefone, endereço, e-mail, data e certidão de nascimento.

• [RF003] Ficha de vacinação: – Todo paciente cadastrado no Sistema possui uma ficha de vacinação

contendo data de aplicação das vacinas, lote da vacina, dose aplicada e tempo de validade.

38

Exemplo – Sistema de Controle de Vacinação (RF)

• [RF004] Vacinação: – O sistema deve montar a ficha de vacinação de um paciente, quando

este comparecer para receber vacina, contendo as vacinas já aplicadas e as vacinas que o mesmo já deveria ter recebido.

• [RF005] Estatística de vacinas: – O sistema deve gerar um relatório de vacinas aplicadas em um

determinado período.

39

Exemplo – Sistema de Controle de Vacinação (RNF)

• [RNF001] Usabilidade: – A navegação deve ser simplificada de modo a tornar o sistema

produtivo e fácil de usar. Deve utilizar a nomenclatura própria da área de saúde.

• [RNF002] Acessibilidade: – O sistema deve permitir acesso de qualquer local que disponha de um

computador com acesso a internet.

40

EXERCITANDO

41

Exercitando: Sistema para uma Vídeo Locadora • Preciso de um sistema de controle completo da locadora, informatizando

funções de locação, devolução e reserva de vídeos.

• No início do negócio todo mês elaborávamos um relatório das locações realizadas, onde era possível saber os títulos mais alugados, faturamento, clientes em atraso, etc. No entanto ultimamente não estamos conseguindo acompanhar o fluxo de locação dos nossos filmes.

• Não sabemos exatamente para onde e de onde vem o nosso dinheiro, dessa forma não estamos conseguindo investir em nada. Sempre que tento colocar a casa em ordem chega um freguês ou um problema surge.

• Preciso de informar ao meu usuário se o vídeo está disponível ou não. Os clientes estão sem tempo e precisam de uma logística que seja compatível com a realidade deles.

42

Exercitando: Sistema para uma Vídeo Locadora • Minha locadora possui diversos funcionários, inclusive de níveis

hierárquicos distintos, os usuários do sistema devem ser devidamente identificados.

• Tenho um problema em que eu preciso agilizar o processo de busca de vídeos na prateleira, os usuários estão levando muito tempo.

• Os meus funcionários atuais têm familiaridade com a plataforma Windows, no entanto o nível de conhecimento de informática pode ser classificado como baixo e/ou médio.

• A maior parte dos meus usuários possui acima de 50 anos.

43

ENGENHARIA DE REQUISITOS

44

Levantamento de requisitos – Engenharia de requisitos

• Engenharia dos requisitos, é uma das disciplinas da engenharia de software.

• Conjunto de técnicas de levantamento da documentação e análise.

• Problema comum em projetos:

Muitas das vezes clientes,

desenvolvedores e os próprios

engenheiros de software não

dão o devido valor...

45

Levantamento de requisitos – Engenharia de requisitos

• Cabe aos engenheiros de software insistir sempre na elaboração de uma boa especificação de requisitos. – Boas especificações de requisitos são indispensáveis.

– Não são custos supérfluos.

– Participação dos clientes é indispensável para que as necessidades sejam atendidas.

– Uma boa especificação custa tempo e dinheiro.

– Mudanças devido a uma má especificação no fim do projeto custam

muito caro.

46

ANÁLISE DOS REQUISITOS

47

Análise de requisitos – especificação dos requisitos

• Nesta etapa ocorre: – A quebra de um sistema em seus componentes.

– Estudo de como os componentes interagem com o objetivo de entender como o sistema funciona.

– A verificação dos requisitos

estarem entendíveis, também

deve ocorrer aqui.

48

Análise de requisitos – especificação dos requisitos

• Assim como no levantamento de requisitos, na análise ainda não levamos em conta o ambiente tecnológico a ser utilizado.

• Tem-se o interesse em construir a estratégia de solução sem se preocupar com a maneira em que será utilizada para construir essa estratégia.

• Aqui acima de tudo, é necessário

saber o que o sistema proposto deve

fazer, para então, definir o como esse

sistema ira fazê-lo.

49

Análise de requisitos – especificação dos requisitos

• Como resultado (físico) da fase da análise de requisitos temos os modelos que representam as estruturas das classes de objetos que vão compor este sistema. – Diagramas de classes

– Diagrama de sequencia

– Diagrama de implantação

– Diagrama arquitetural

– Diagrama de casos de uso

– ...

• Cada um destes modelos deve ser

cuidadosamente validado e verificado.

50

Análise de requisitos – especificação dos requisitos

• Validação, é assegurar que as necessidades do cliente estão sendo atendidas pelo sistema. – Será que o software correto está sendo construído?

• Verificação, verificar se os modelos construídos estão em conformidade com os requisitos definidos. – O Software esta sendo construído de corretamente?

51

GESTÃO DOS REQUISITOS

52

Levantamento de requisitos – Gestão dos requisitos

• Gestão dos requisitos é a disciplina da engenharia de software que mantém o controle sobre o conjunto dos requisitos.

• Não importa se os requisitos foram bem especificados. Eles vão mudar...

• Imagine uma alteração como em qualquer outra engenharia... A alteração é tão danosa quanto... • A boa engenharia procura mitigar as alterações antes que elas aconteçam de fato. (cabe ao analista auxiliar o cliente nesta etapa).

53

Levantamento de requisitos – Gestão dos requisitos

• A questão é: Por vezes alterações são inevitáveis...

• Toda a etapa de especificação dos requisitos é sujeita as limitações humanas.

• E mesmo que num caso super hipotético: em que o levantamento tenha sido perfeito, podem ocorrer mudanças quanto a legislação, mercado...

• Todas as mudanças nos requisitos devem ser documentadas e homologadas tanto por parte do cliente, tanto por parte da equipe de desenvolvedores.

54

PRAZOS E CUSTOS

55

Prazos e Custos

• Estimar prazos e custos faz parte da rotina de qualquer ramo da engenharia. Mas a computação em especial ainda erra muito!!!

• A viabilidade de se prosseguir com um projeto depende diretamente destes dois fatores (prazo e custo).

• Estourar orçamentos e cronogramas é rotina da maioria dos profissionais de software. (Início de pressão nos desenvolvedores)

• Dentro das organizações existe muito o que chamamos de “matar os mensageiros de más notícias”. (O projeto não vai ser entregue no tempo esperado)

56

Prazo

• Um engenheiro de software comumente é cobrado pelo cumprimento dos prazos prometidos. – Fazer com que eles prometam algo que seja intangível.

• “Não me interessa como vai fazer desde que entregue no prazo”.

• A cultura do prazo político é ruim para todos. Para os desenvolvedores, ela significa estresse e má qualidade de vida. Para gerentes perda de credibilidade e prejuízos.

57

Triângulo de Ferro

58

Qualidade

EXERCÍCIOS

59

Exercício 1 (5 pontos)

• Baseado em sua experiência, tente escrever um documento de requisitos para um sistema de controle acadêmico. Esse sistema deve controlar as inscrições de alunos em disciplinas, as alocações de turmas, salas, professores etc. Deve permitir também o controle de notas atribuídas aos alunos em diversas disciplinas. Você pode se basear na forma de funcionamento do ifmg ...

60

Exercício 2 (10 pontos)

• Baseado em sua experiência, tente escrever um documento de requisitos para um sistema de software do seu cotidiano (por exemplo, um sistema para automatizar algum processo na empresa que você trabalha, aproveitando o conhecimento do negócio que você tiver). Durante a elaboração desse documento, tente não considerar detalhes técnicos de implementação.

61