FATTO CONSULTORIA E SISTEMAS

Transcrição

1 Requisitos Não Funcionais Guilherme Siqueira Simões 13/06/2017 FATTO CONSULTORIA E SISTEMAS 1

2 ORIENTAÇÕES INICIAIS Dê preferência ao uso de uma conexão de banda larga O evento não fará uso do vídeo (webcam), somente slides e áudio Se necessário, ajuste o idioma da sala na barra de ferramentas superior O evento terá ~45 min. de apresentação e ~15 min. finais para perguntas Você pode mandar suas perguntas pelo chat ao longo da apresentação Para quem possui a certificação PMP, o evento vale 1 PDU A apresentação será gravada e o vídeo publicado posteriormente no site e redes sociais: 2

3 MISSÃO Apoiar nossos clientes a estabelecer modelos de negócios em que eles tenham o controle e trazer visibilidade do desempenho para a gestão de seus processos de software. DIRECIONAMENTO ESTRATÉGICO COM: Estimativas e Medição de Projetos de Software Implantação daanálise de Pontos de Função (IFPUG, NESMA, COSMIC) Auditoria de Medições de Projetos de Software Medidos com APF Benchmarking e Análises de produtividade Avaliação para Melhoria dos Processos de Software Engenharia de Requisitos Planejamento e avaliação do desempenho (Escopo, Esforço, custo, prazo, qualidade) Construção e Monitoramento de Contratos de Software baseados em Resultados Integração do Desenvolvimento Ágil com a Governança Corporativa de TI usando Métricas Funcionais 3

4 FORMAÇÃO PROFISSIONAL APF: Fundamentos, Benefícios e Implantação 8 horas (EAD e presencial) Preparação para o Exame CFPS 96 horas (EAD e presencial) Preparação para o Exame COSMIC 16 horas (EAD e presencial) Capacitação em APF: Medição e Estimativa de Software 16 horas (EAD e presencial) Medição e Estimativa de Software com o Método COSMIC 16 horas (Presencial) Engenharia de Requisitos de Software 24 horas Workshop APF: Metodologia e Práticas de Medição 16 horas (Presencial) Oficina de Contagem de Pontos de Função Sessões de 8 ~ 40 horas Oficina de Requisitos Sessões de 8 ~ 40 horas Estimativa de Software: Fundamentos e Técnicas 24 horas (EAD e presencial) Introdução ao Gerenciamento de Projetos 16 horas Gestão de Riscos em Projetos 16 horas 4

5 Agenda As duas dimensões do software Requisitos funcionais Requisitos não funcionais ISO/IEC FURPS+ Checklists 5

6 Duas dimensões do software Os requisitos do software subdividem-se em: o quê Funcionais Não Funcionais como Descrevem o quê o software faz: processos ou tarefas da solução (e da transição) que suportam uma prática ou procedimento de uma parte interessada Expressam atributos ou restrições inerentes aos requisitos funcionais e como eles serão atendidos 6

7 Requisitos Funcionais Descrevem o quê a solução (ou transição) deve fazer em termos das tarefas ou serviços do usuário Não aborda a implementação Doc. Visão Lista requisitos Historia usuário Caso de Uso Modelos 7

8 Níveis de Objetivo dos RFs (Granularidade) Efetuar gestão dos cursos Emitir certificado de participação Somente alunos com frequência 75% podem emitir seu certificado 8

9 Requisitos Não Funcionais O que Abordam COMO as funcionalidades serão oferecidas ao usuário Incluem aspectos relacionados a Qualidade: usabilidade, confiabilidade, eficiência, portabilidade, facilidade de manutenção Implementação: plataforma de software, hardware, linguagem de programação. Ambiente: interoperabilidade, segurança, privacidade, sigilo Organização: locais para operação, hardware alvo, aderência a padrões. Exemplo de padrões no governo federal: Padrões Web em Governo Eletrônico e-pwg Modelo de Acessibilidade de Governo Eletrônico e-mag Arquitetura de Interoperabilidade de Governo Eletrônico e-ping 9

10 Requisitos Não Funcionais Em geral costuma-se ter boa visibilidade destes requisitos já em fases iniciais do projeto Costumam ser constante entre os projetos, ou mudam pouco de um projeto para outro na mesma organização, o que também facilita sua identificação Em geral são menos numerosos que os Requisitos Funcionais Para organizações que possuem uma metodologia madura de desenvolvimento de software, a identificação de boa parte dos RNFs fica facilitada pois muitos aspectos técnicos e de qualidade dos projetos são padronizados pela metodologia 10

11 Requisitos Não Funcionais A classificação dos tipos de requisitos não funcionais é útil para apoiar o seu trabalho de identificação Não há consenso na literatura quanto à essa classificação Cada organização pode definir categorias para o seu contexto Alguns modelos podem ser usados para essa definição local: ISO/IEC (SQUaRE) FURPS e FURPS+ Não se preocupe se classificar incorretamente o requisito; o importante é que ele seja identificado! 11

12 ISO/IEC SQuaRE (Systems and software Quality Requirements and Evaluation) Qualidade do Sistema/Software Adequação Funcional Eficiência Compati bilidade Usabilidade Confiabi lidade Segurança Manuteni bilidade Portabi lidade Completude Funcional Correção Funcional Conformidade Funcional Tempo de resposta Utilização de Recursos Capacidade Coexistência Interopera bilidade Reconheci mento Adequado Facilidade de Aprendizado Operabilidade Proteção a Erros de Usuário Maturidade Disponibilidade Tolerância a erros Recuperabili dade Confidencia lidade Integridade Irrefutabilidade Responsab ilidade Autentic idade Modularidade Reusabilidade Análise Mudanças Teste Adaptação Instalação Troca Estética da Interface Acessibilidade 12

13 FURPS e FURPS+ Parte do IBM Rational Unified Process (RUP) Functionality Usability Reliability Performance Supportability (Funcionalidade) (Usabilidade) (Confiabilidade) (Desempenho) (Suportabilidade) Já abordado anteriormente + Restrições de projeto Restrições de implementação Restrições de interface Restrições físicas 13

14 Avalia a facilidade de uso. Possui diversas subcategorias, entre elas: Fatores humanos Estética Consistência na interface do usuário Ajuda on-line e contextual Assistentes Documentação Materiais de treinamento Exemplos: FURPS - Usabilidade A leitura do código de barras deve ser automática para diminuir a digitação de dados, agilizando a transação e evitando erros Documentação quanto ao uso e funcionamento deve ser fornecido por meio de ajuda on-line aos agentes arrecadadores 14

15 Integridade, conformidade e interoperabilidade do software, tratam questões como: Frequência e gravidade de falha Possibilidade de recuperação Previsibilidade Exatidão Tempo médio entre falhas Exemplos: FURPS - Confiabilidade O Word recupera documento não salvo após desligamento inesperado do computador Se o processo de importação de contas arrecadadas for interrompido por uma falha, o sistema deve permitir recuperar os dados já importados e continuar a partir do ponto em que ocorreu a falha 15

16 Usa como medida diversos aspectos da aplicação, entre eles Velocidade Eficiência Taxa de transferência Tempo de resposta Uso de recursos Exemplos: FURPS - Desempenho O sistema deve suportar até 100 usuários simultâneos sem se degradar O tempo de resposta de qualquer tela do sistema não deve exceder 2 segundos 16

17 FURPS - Suportabilidade Facilidade de efetuar mudanças no sistema após sua entrega. Agrupam várias características como: Testabilidade Adaptabilidade Manutenibilidade Compatibilidade Configurabilidade Instalabilidade Escalabilidade Localizabilidade Exemplos: A instalação do software deve ser realizada de forma semiautomática, ou seja, com o mínimo de intervenção humana A solução deve oferecer suporte aos idiomas: inglês, português e espanhol O sistema deve rodar em browser Internet Explorer, Firefox e Chrome 17

18 O que é Checklist? O uso de Checklist, ou também chamado de lista de verificação, é uma das técnicas mais eficazes para levantar requisitos não funcionais Consiste em um conjunto de perguntas/afirmações que tratam sobre o critério de qualidade de um determinado artefato de software Proporciona uma forma estruturada para a identificação de erros em projetos, evidenciando que uma ou mais questões da lista não foram atendidas O conjunto de questões abordadas na lista refletem lições aprendidas de projetos passados e boas práticas de mercado 18

19 Surgimento dos Checklists A técnica Checklist surgiu durante a fase final de avaliações de aeronaves sob a especificação do Exército dos EUA, em 1934 Um acidente em um voo de teste foi o gatilho para a adoção de checklist Quatro listas de verificação (Checklists) foram desenvolvidas: decolagem, voo, antes do pouso e após o desembarque Com seu uso, um planejamento cuidadoso e rigoroso treinamento, a aeronave conseguiu voar 290 mil km sem um único acidente 19

20 Exemplo Checklist para Confiabilidade Pergunta 1. O software terá usuários externos à empresa? 2. O software deverá funcionar apenas em dias úteis e horário comercial? Observação 3. O funcionamento do software deverá ser 24x7? 4. É necessário prover alguma contingência em caso de falha de alguma interface externa? 5. É aceitável interromper a operação para atualização de versão do software? 6. Há algum processo que pode degradar o desempenho do software e prejudicar a operação normal? 20

21 Exemplo Checklist para Desempenho Pergunta 1. Qual é o tempo médio (em segundos) de resposta para transações interativas? (Duração entre o comando de início e a resposta final) 2. Qual é a quantidade de transações processadas por minuto (throughput)? 3. Quanto tempo de CPU se utiliza para concluir uma transação em relação ao tempo total? 4. Quanto tempo de E/S se utiliza para concluir uma transação com respeito ao tempo total? 5. Quantas solicitações de transações online podem ser processadas por segundo? 6. Quantos usuários podem acessar o sistema de maneira simultânea por minuto? Observação 21

22 Benefícios do Checklist Projetos que utilizam checklists economizam tempo da equipe Checklists são facilmente delegáveis Permitem o compartilhamento de conhecimento e experiência entre os membros da equipe Padronizam a execução da atividade de levantamento São simples de se aplicar 22

23 Conclusão O requisito não funcional descreve o COMO as funcionalidades são entregues ao usuário Boa visibilidade em etapas iniciais do projeto Mudam pouco entre projetos da mesma empresa A categorização ajuda na sua identificação Podem ser facilmente levantados via checklists 23

24 Para saber mais Curso: Engenharia de Requisitos: Software Orientado ao Negócio Vitória: 26 a 28/06 Brasília: 04 a 06/07 Fortaleza: 07 a 11/08 São Paulo: 22 a 24/08 Rio de Janeiro: 19 a 21/09 Belo Horizonte: 02 a 06/10 24

25 AVALIAÇÃO DO EVENTO 25

26 PRÓXIMOS EVENTOS WEBINARS: Tutorial prático da análise dos pontos de função IFPUG de um app Google Data: 04/07/17 às 20h Inscrição: Visão prática do BDD (Behaviour Driven Design) para agilizar o processo de desenvolvimento Data: 16/08/17 às 20h Inscrição: 26

27 PERGUNTAS? Obrigado pela sua atenção! Guilherme Siqueira Simões Skype: guilherme.s.simoes Brasília: (61) São Paulo: (11) Vitória: (27) Rio de Janeiro: (21)