exame de certificação em análise de pontos de função · medições funcionais e na gestão dos...

FATTO Consultoria e Sistemas - www.fattocs.com

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

A apresentação será gravada e o vídeo publicado posteriormente

Para aqueles que possuem certificação PMP, o evento vale 1 PDU

Acompanhe-nos nas redes sociais

Orientações iniciais

1


FATTO Consultoria e Sistemas

2

Missão: “Ajudar nossos clientes a planejar e controlar melhor seus projetos de software.”

Consultoria e Treinamento em Medição, Estimativas e Requisitos de Software:

– Análise de Pontos de Função (IFPUG, NESMA , COSMIC)

– Estimativas de projetos de software

– Engenharia de Requisitos

– Medição e auditoria em medição de software

– Análises de produtividade em projetos de software

O livro mais vendido de APF no país foi escrito por nós

Formou ~25% de especialistas certificados pelo IFPUG no Brasil

Representante do Scope Project Sizing Software

– Aumenta seu nível de governança nas medições funcionais e na gestão dos ativos de software

2


Cursos da FATTO

Preparação para

o Exame CFPS 96 horas (EAD e

presencial)

APF: Fundamentos,

Benefícios e Implantação

8 horas (EAD e presencial)

Capacitação em APF:

Medição e Estimativa de Software

16 horas (EAD e presencial)

Workshop APF:

Metodologia e Práticas de Medição

16 horas (presencial)

Engenharia de

Requisitos de Software 24 horas

Estimativa de Projetos

de Software com o

COCOMOII

16 horas

Oficina de Contagem

de Pontos de Função Sessões de 8 ~ 40 horas

Medição e Estimativa de

Software com o Método COSMIC

16 horas (presencial)

Gestão de Riscos em

Projetos 16 horas

Oficina de Requisitos

Sessões de 8 ~ 40 horas

3

Introdução ao

Gerenciamento de Projetos

16 horas


Desafios e soluções para trabalhar com Requisitos de Software

Sejam bem vindos

Guilherme Siqueira Simões

4


O que é a Engenharia de Requisitos

Importância da Engenharia de Requisitos

O que é Requisito?

Comunicação, acesso a partes interessadas, usuários que

não sabem o que querem, requisitos implícitos, mudanças,

conflitos, resistência à mudança, usuários que não dominam

o seu negócio, clientes que não leem a especificação de

requisitos

Conclusão

O que será apresentado?

5


Disciplina da Engenharia de Software que consiste no uso sistemático e repetitivo de técnicas para cobrir atividades Obtenção,

Documentação, Manutenção de um conjunto de requisitos para

software que atendam aos objetivos de negócio e sejam de

qualidade*

O que é Engenharia de Requisitos

6 * https://youtu.be/d8XmSaER2F4


47% dos projetos fracassados tem como causa gestão de requisitos deficiente

Sintomas diretos ou indiretos desta deficiência:

– Scope Creep;

– Comunicação deficiente;

– Baixo envolvimento de partes interessadas e

– Suporte inadequado do patrocinador

Causas de fracasso em projetos*

7

*PMI’s Pulse of the Profession: Requirements Management

A Core Competency for Project and Program Success - 2014


Origem dos defeitos

8

~40% do orçamento total dos projetos é

gasto em retrabalho. Em

projetos maiores, ~50%

Encontrar e corrigir erros originados em requisitos consome entre 70 e 85%

do custo total de retrabalho do projeto em função de sua quantidade e efeito

multiplicativo

Software Defects Origins and

Removal Methods Capers Jones -

2014

Em um estudo mais recente, Capers Jones afirma que 20% dos defeitos têm origem

no trabalho de requisitos


Quanto custam os reparos de defeitos

9

Custo unitário para detectar e reparar um erro durante a

codificação

Leffingwell, D; “Calculating the Return on

Investment from More Effective Requirements

Management”; American Programmer 10(4); 13-

16; 1997.

Software Defect Reduction – Top 10 List

Barry Boehm y Victor Basili - 2001


Definição de Requisito

(1) uma condição ou capacidade necessária por um usuário para resolver um problema ou alcançar um objetivo.

(2) uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto

(3) uma representação documentada de uma condição ou capacidade como em (1) ou (2)

10

desejo (projeto)

produto

Documentação das capacidades do projeto ou produto


Quais os problemas nesta tirinha?

11

Imagem extraída de http://www.projectcartoon.com


E se não houvesse telefone sem fio?

12

Entregar exatamente o que o cliente pede é garantia de

satisfazê-lo???


Comunicar-se com objetividade e sem ambiguidade

Os requisitos em geral são expressos em linguagem natural, o que facilita a compreensão, porém permite que se crie múltiplas interpretações

Falha na interpretação das mensagens trocadas entre clientes e analistas de requisitos, bem como propagação incorreta da mensagem entre os membros da equipe do projeto

13

Dificuldade: Comunicação


Desenvolver suas habilidades de comunicação (verbal, não verbal, escuta e escrita) e relacionamento interpessoal

14

Comunicação - Solução


Nem sempre está ao alcance do analista de requisitos selecionar as pessoas com quem irá levantar requisitos

As vezes um intermediário é selecionado para representar o papel do usuário. Isto é mais comum quando o usuário é de fora da empresa (cliente, fornecedor, parceiro, etc)

Isto significa um risco considerável da informação levantada não ser a mais adequada

“Não tenho tempo”

Qual o papel desta pessoa?

Cliente direto?

Cliente indireto?

Externo à empresa?

15

Dificuldade: Acesso aos interessados


“Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto” – Princípio 4 do Manifesto Ágil (www.agilemanifesto.org/principles.html)

Promover cultura de participação

Esclarecer a importância do papel do interessado no processo

Obter ajuda de alguém com mais autoridade (GP?)

Usar métodos de levantamento que necessitem de menos tempo do interessado: observação, questionário, análise de documentos

Identificar outra pessoa que também possa ter a informação e que tenha mais interesse em participar e disponibilidade

16

Acesso aos interessados - Solução

http://www.agilemanifesto.org/principles.html


Esta dificuldade varia desde o usuário que não sabe dizer o que quer até aquele que diz a necessidade incorreta

O que fazer? Trocar os usuários?

17

Dificuldade: Usuário que não sabe o que quer


O grande valor do trabalho do analista de requisitos é compreender corretamente as necessidades, ainda que o usuário não saiba dizer com clareza o que deseja. Para alcançar isso, o trabalho deve ser proativo, e não passivo

Selecionar os métodos adequados para elicitação O que funciona para alguns não funciona para todos. Prototipação e observação são muito efetivas para lidar com aqueles que tem dificuldade em se expressar

18

Usuário que não sabe o que quer - Solução


Ou “óbvios”, mas não ditos

O analista ouve os usuários, documenta e confirmar suas necessidades, especifica uma solução, valida este projeto com os usuários e obtém a aprovação. O produto é desenvolvido e na entrega são apresentadas várias necessidades não supridas pelo produto

Quem falhou? O analista? Os usuários?

19

Dificuldade: Requisitos Implícitos

A B C

Correcto Especificado


Acreditar que o trabalho de requisitos está restrito ao que é explícito não é a realidade

Entretanto não há método que garanta que uma especificação esteja completa. É possível minimizar via:

Aprofundar o conhecimento no negócio

Técnica de observação

Técnica de prototipação

20

Requisitos Implícitos - Solução


"(...) requisitos mudam a um ritmo de 2% ao mês (...)" - Capers Jones en “Software Engineering: The State of the Art in 2008”.

21

Dificuldade: Mudanças


Mudanças geram trabalho adicional. Porém nem todas significam problema. Mudanças deveriam existir para aumentar (ou preservar) o valor do projeto

Um trabalho de requisitos passivo, quase sempre provoca muitas mudanças desnecessárias mais à frente (para corrigir o escopo). Postura proativa é fundamental

Para as mudanças inevitáveis, o que se pode fazer é estar preparado para a mudança. Criar especificações de requisitos facilmente modificáveis é uma maneira

22

Mudanças - Solução


Conflitos aumentam na proporção da quantidade de interessados. Exemplos:

Pedidos de partes interessadas distintas que não se podem atender simultaneamente

Dados inconsistentes sobre o processo de negocio

Falta de sintonia entre as áreas de negocio

Solicitações fora do escopo do projeto

Partes antipáticas umas às outras

23

Dificuldade: Conflitos


Resolução de conflitos é uma responsabilidade mais direta do GP que do analista de requisitos

Porém, desenvolver habilidades de relacionamento interpessoal é fundamental para o analista de requisitos. Antes de tudo, ele não deve ser um foco gerador de conflitos

Além disso, para muitos cenários, ter habilidades de diplomacia, política e psicologia é muito eficaz para evitar e eliminar conflitos

24

Conflitos - Solução


Projetos introduzem novidades. Novidades frequentemente geram temor e/ou preocupação nas pessoas

Manter a zona de conforto é a reação natural da maioria

25

Dificuldade: Resistência à Mudança


Qual a motivação para a resistência?

Interesse de alguém é prejudicado?

– Buscar fontes de informação alternativas: outras pessoas, documentos, observação

Falta de conhecimento sobre os objetivos do projeto?

– Comunicar os benefícios a serem gerados pelo projeto

26

Resistência à Mudança - Solução


Espera aí, como é que é? Como assim? Isso não seria obrigatório?

Às vezes isso ocorre, mas como uma situação transitória, por exemplo: um novo gestor assume a diretoria de uma área de negócio nova para ele

Porém é frequente em alguns casos:

Pessoas em cargos não por competência, mas por política

Trocas frequentes de gestores (governo depois de eleição)

Áreas de negócio que delegam para a TI decisões que são de sua própria responsabilidade

27

Dificuldade: Cliente não domina seu negócio


Melhorar o próprio conhecimento no negócio

Buscar outras fontes de informação (outras pessoas – quase sempre há, documentação existente)

Alinhar os papéis entre a TI e as demais áreas de negócio da organização

28

Cliente não domina seu negócio - Solução


A especificação de requisitos é o contrato da equipe de desenvolvimento para com o cliente

Ela deve comunicar ao cliente tudo que será entregue (logicamente satisfazendo todas suas necessidades) e o cliente deve conseguir compreendê-la e dar sua aprovação para que o trabalho no projeto possa seguir adiante

Contrato que não é aprovado pelas partes não tem validade

29

Dificuldade: Cliente não lê a especificação


Parar o projeto?

Entender o motivo para não se ler a especificação

As pessoas não compreendem sua função e acham que é só burocracia

– Comunicar como funciona o processo de desenvolvimento

– Simplificar a documentação

Apresentação equivocada dos requisitos

– Definir o nível de feedback desejado

O cliente acredita que já sabe tudo

– Se isto é verdade, ótimo. Se não é, apresente estes pontos

30

Cliente não lê a especificação - Solução


Conclusão

31

Os itens apresentados abrangem boa parte das dificuldades mais frequentes no trabalho de requisitos. Porém não esgota a discussão

É possível que você tenha experiência com outros desafios ou soluções para o que comentamos. Participe! Comente agora no chat


Perguntas?

Obrigado pela atenção e participação!

Guilherme Siqueira Simões

[email protected]

linkedin.com/in/guilhermesimoes

Skype: guilherme.s.simoes

Fechamento

32

exame de certificação em análise de pontos de função · medições funcionais e na gestão dos...

Documents