Qual o nível de detalhe adequado para os requisitos?

Transcrição

1 Qual o nível de detalhe adequado para os requisitos? Guilherme Siqueira Simões 22/11/2016 1

2 ORIENTAÇÕES INICIAIS Dê preferência ao uso de uma conexão de banda larga Feche qualquer outro programa que possa interferir na transmissão de áudio ou na conexão de Internet. 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 ter mais visibilidade do desempenho de seus processos de software e a estabelecer modelos de negócios em que eles tenham o controle sobre os mesmos. DIRECIONAMENTO ESTRATÉGICO COM: Estimativas e Medição de Projetos de Software Implantação da Aná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) Estimativa de Projetos de Software: Fundamentos e Técnicas 16 horas 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 Introdução ao Gerenciamento de Projetos 16 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 Gestão de Riscos em Projetos 16 horas Mais de alunos capacitados O livro mais vendido de APF no país foi escrito por nós Formou >25% dos CFPS no Brasil 4

5 Objetivos desta apresentação O que é especificação de requisitos Por que observar o nível adequado de detalhe? Critérios que impactam o nível de detalhe Conclusão 5

6 O que é especificação de requisitos? É a documentação das capacidades desejadas pelo usuário para um software ou já existentes no mesmo É um contrato entre clientes e equipe de desenvolvimento Deve esclarecer aos clientes o que será entregue como produto do trabalho da equipe de desenvolvimento Assim como permitir que a equipe de desenvolvimento consiga compreender exatamente o que os clientes desejam 6

7 Requisitos para quem? Contrato entre as partes! cliente necessidades do cliente Especificação de requisitos Gerência de Projetos Análise e Projeto Produz insumos para... plano de projeto e acompanhamento - escopo, orçamento e prazo projeto da solução acordos sobre a entrega Implementação Implantação projeto do banco de dados material de treinamento e de suporte ao usuário equipe Medição e Análise estimativas e medições Testes casos de teste 7

8 Exemplo Especificação de Requisitos 8

9 Quão detalhado deve ser o contrato? É um equívoco pensar que quanto mais detalhada a especificação de requisitos, melhor ela é. Detalhar demais pode ser um elemento paralisante do projeto, o software tem que ser entregue Documentação não substitui a comunicação entre as partes! Quanto maior a relação de confiança entre as partes, mais enxuto pode ser esse contrato. E vice-versa Um contrato verbal só funciona quando as partes possuem um alto nível de confiança e quando o objeto do contrato é simples Que critérios específicos afetam o nível de detalhe? 9

10 Objetivo da especificação Uma especificação de requisitos pode ser elaborada visando alcançar três objetivos distintos Delimitar o escopo de forma preliminar (visão ampla) Definir o funcionamento das transações (visão profunda do todo ou parte do software) Estruturar os requisitos para design e implementação 10

11 Interno Externo Desenvolvimento Interno x Externo A interação cara a cara é mais fácil e frequente A equipe de desenvolvimento e clientes, em geral, são colegas de trabalho A equipe de projeto é composta de funcionários de fornecedores Menos possibilidade de interação cara a cara, portanto mais necessidade de detalhes 11

12 Equipe Agrupada x Dispersa Agrupada Todos no mesmo espaço físico Comunicação mais fácil Dispersa Trabalho remoto Falta de convivência, barreira de comunicação 12

13 Nível de Incerteza nas Estimativas A incerteza nas estimativas está diretamente relacionada ao nível de maturidade e dos requisitos Quanto mais cedo se necessita de uma estimativa, menos maduros estarão os requisitos Para gerar uma estimativa de ordem de grandeza, não é necessário uma especificação de requisitos tão detalhada 13

14 Nível de Participação dos clientes Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto. Princípio 4 do manifesto ágil O cliente que é altamente participativo constrói una relação mais forte com a equipe A comunicação cara a cara é mais frequente 14

15 Conhecimento do negócio Para bom entendedor, meia palavra basta Interno A mesma equipe executa vários projetos para a mesma área de negocio Comunicação com o cliente no mesmo nível Externo Há fornecedores que atuam exclusivamente com projetos de áreas de negocio especificas Facilita a comunicação com o cliente Também há fornecedores sem tanta especialização. Neste caso os responsáveis devem estudar previamente o negócio, e ainda assim será necessário mais detalhe na especificação 15

16 Trabalho com características similares Precedentes são importantes fontes de informação Reengenharia de sistema existente Por exemplo, em nova tecnologia Detalhes podem não ser tão necessários Manutenções similares em sistemas distintos Decisões adotadas na primeira manutenção podem ser úteis nas seguintes 16

17 Desenvolvimento concorrente de procedimentos de negocio Quando o processo de negocio ainda não está maduro o projeto estará sujeito a uma grande demanda de solicitações de mudança Nestes casos produzir uma especificação mais detalhada será um desafio Manter esta documentação detalhada e consistente implicará muito esforço 17

18 Uso de pacote na solução Uma especificação para adquirir, configurar ou personalizar um pacote, em geral demanda menos detalhes que o desenvolvimento de um software inteiramente novo Configuração Adequação nativa do pacote Personalização Alterações que envolvem código fonte Manutenção Adaptação de legados para o pacote 18

19 Rotatividade de pessoal Desafio para a Gestão do Conhecimento Regra Geral: Menos rotatividade, menos detalhe Mais rotatividade, mais detalhe 19

20 Conclusão Nem sempre mais detalhe significa uma especificação melhor Menos detalhe na especificação Visão ampla do escopo Desenvolvimento interno Equipe agrupada Exigência por estimativas menos precisas Alto envolvimento dos clientes Alto conhecimento da equipe no negócio Precedentes existentes Uso de pacotes na solução Baixa expectativa de rotatividade de pessoal Mais detalhe na especificação Visão profunda (do todo ou parte) do escopo Desenvolvimento externo Equipe dispersa Exigência por estimativas mais precisas Baixo envolvimento dos clientes Pouco conhecimento da equipe no negócio Sem precedentes Solução não adotará pacote Alta expectativa de rotatividade de pessoal 20

21 Para saber mais Curso: Engenharia de Requisitos: Software Orientado ao Negócio On-line: Webinars: Dificuldades ao lidar com requisitos (youtu.be/mckx4m95z88) Qualidade em Requisito (youtu.be/d8xmsaer2f4) Protótipos: um brinquedo valioso (youtu.be/4boo7loutmm) Rastreabilidade de Requisitos (youtu.be/g0q9tuzfzgi) Grupo de discussão: Engenharia de Requisitos 21

22 AVALIAÇÃO DO EVENTO 22

23 WEBINARS: PRÓXIMOS EVENTOS Aceitando o software: Como garantir a qualidade dos projetos de software Data: 13/12/16 às 20h Inscrição: PRÓXIMAS TURMAS ENGENHARIA DE REQUISITOS 06/12 a 08/12 São Paulo 06/12 a 08/12 Curitiba Curso ON-LINE - Início imediato 23

24 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)