A proposal of software process model based on Goal-Driven Software Development Process (GDP) and Impact Mapping.

1. GOAL-DRIVEN
SOFTWARE PROCESSAndré Rocha Agostinho

2. Tópicos abordados
1. Desafios em projetos de software
2. Processo de software
3. Metas de negócios
4. Proposta de um modelo Tempo de apresentação

3. Desafios em projetos de software
50,000 projects around the world, ranging from tiny enhancements to
massive systems re-engineering implementations
(CHAOS Report 2015 - Standish Group)
Sucessful: on time, on budget with a satisfactory result

4. Desafios em projetos de software
50,000 projects around the world, ranging from tiny enhancements to
massive systems re-engineering implementations
Agile: 39%
Waterfall: 11%
(CHAOS Report 2015 - Standish Group)

5. Desafios em projetos de software
• Fatores de sucesso (CHAOS Report 2015 - Standish Group)
Objetivos da apresentação
• Apoio executivo
• Levantamento de requisitos
• Especificação de Requisitos
• Escopo do projeto
• Processo ágil
• Clareza nos objetivos

6. Processo de software
• “A structured set of activities required to develop a software
system” (SOMMERVILLE)
Um processo de software envolve ao menos 4 tópicos:
• Especificação
• Projeto (Design) e implementação
• Validação
• Evolução

7. Modelo de Processo de software
• “Is an abstract representation of a process. It presents a description
of a process from some particular perspective” (SOMMERVILLE)
Exemplos de modelos de processo de software
• Modelo cascata
• Modelo incremental
• Modelo orientado a reuso

8. Tipos de modelos de Processo de software
• Modelo cascata
(Summerville, Software Engineering, 9th Edition Ch2)

9. Tipos de modelos de Processo de software
• Modelo incremental
(Summerville, Software Engineering, 9th Edition Ch2)

10. Tipos de modelos de Processo de software
• Modelo orientado a reuso
(Summerville, Software Engineering, 9th Edition Ch2)

11. • Qual selecionar?
Escolhendo o tipo de modelo
Modelo cascata
+ Atividades de levantamento e definição de requisitos mais formalizados.
- Não responde com facilidade à mudanças.
Modelo incremental
+ Entrega contínua de partes do software (iterativo e incremental).
- Requisitos podem ser levantados e especificados sem detalhes (falta de formalismo).
Modelo orientado a reuso
+ Componentes com conceito client-server SaaS (escalabilidade).
- Maior esforço e complexidade no desenvolvimento.
Modelo orientado à metas

12. Escolhendo o tipo de modelo
• Modelo conceitual de processo de software com suporte à metas
REQUISITOS
DESENVOLVIMENTO
VALIDAÇÃO
VISÃO DO
PRODUTO
METAS

13. Definição de metas
Objetivo: Propósito de realizar algo. Direção. Intenção.
Meta: Incorpora uma unidade quantitativa como referência
para se atingir um objetivo.
http://www.ibccoaching.com.br/portal/metas-e-objetivos/definicao-metas-objetivos/
Objetivo: Uma pessoa deseja fazer uma viagem.
Meta: Ela pretende fazer essa viagem até o ano de 2015 para a
europa.
GOAL
Meta
Objetivo
Business Goal (Meta)

14. Metas de negócios
Business Goals
• Devem justificar o desenvolvimento de “alguma coisa”.
• Permitir stakeholders reavaliar o plano a medida que novas
informações são geradas.
• Não são definições sobre como construir produtos ou
entregar um escopo de projeto.
• Devem apresentar o problema a ser resolvido e não a solução.
• Permite entendimento entre todos os stakeholders do projeto.
HOW WHAT WHYWHO WHERE WHEN

15. Metas de negócios
Exemplos
• Iniciar no mercado americano em março do próximo ano
• Aumentar a taxa de conversão de usuários em 30% nos
próximos 3 meses.
• Aumentar o volume de cotações em 40% em 6 meses.
• Possuir uma carteira de anunciantes no nordeste equivalente
a 1/3 da carteira do centro-oeste brasileiro até o final do ano.
• Reduzir em 35% os custos com infra-estrutura para serviços de
armazenamento na nuvem nas próximas 2 sprints.
HOW WHAT WHYWHO WHERE WHEN

16. Metas de negócios
Boas práticas - S.M.A.R.T
• Specific: target a specific area for improvement.
• Measurable: quantify or at least suggest an indicator of progress.
• Assignable: specify who will do it.
• Realistic: what results can realistically be achieved, given
available resources.
• Time-related: specify when the result can be achieved.
(Impact Mapping Gojko Adzic)

17. (Impact Mapping Gojko Adzic)
Business Goal
A meta de negócio que pretende-se alcançar
Actor
Participantes que produzirão impactos.
Impact
Ações realizadas por atores que produzem
impactos.
Deliverable
Produtos que suportam impactos.
Metas de negócios

18. (Impact Mapping Gojko Adzic)
Impact Mapping
• Deliverable – WHAT
• Impact – HOW
• Actor – WHO
• Business Goal – WHY
Metas de negócios

19. (Impact Mapping Gojko Adzic)
Impact Mapping
Metas de negócios

20. FEATURES - BACKLOG
(Impact Mapping Gojko Adzic)
USER
STORIES
Impact Mapping
Metas de negócios

21. Goal-Driven Oriented Development Process (GDP)
GDP é focado primariamente em identificar metas antes de especificar
os requisitos e utiliza a convergência de desenvolvimento top-down e
bottom-up.
bottom-uptop-down
GDP permite combinar aspectos top-down e bottom-up.
• Top-down thinking - metas e requisitos do topo para baixo.
• Bottom-up acting - colocar em prática: desenvolvimento, requisitos à metas.

22. Goal-Driven Oriented Development Process (GDP)
Justificativas de uso
1. Falta de alinhamento de requisitos com objetivos de negócios.
2. Muitos autores limitam o conhecimento à apenas requisitos de
softwares
3. Requisitos tendem a incluir desejos desnecessários e custosos
enquanto excluem features tecnicamente simples que devem
fornecer benefício substancial.
4. A formalização de um processo de negócio durante o
desenvolvimento geralmente revela inconsistências e gaps com o
processo o qual é necessário ser compensado com as mudanças
do processo ou até mesmo no papel do sistema de software.

23. Goal-Driven Oriented Development Process (GDP)
Ganhos
1. Identificar e adaptar funcionalidades (use
cases/user story) aos requisitos de acordo
com as metas de negócios.
2. Estabilizar uma ponte entre metas e
arquitetura de IT possibilitando convergir
em uma solução.
3. Validar requisitos considerando metas
alcançadas.

24. Goal-Driven Oriented Development Process (GDP)
Pré-requisitos
Organização vertical
• Desenvolvedores de software necessitam ser especialistas e generalistas.
• Cada desenvolvedor deve ser criativo o suficiente para achar as melhores soluções técnicas
para alcançar os níveis mais altos de metas de negócios, não apenas se responsabilizando
por implementações.

25. Goal-Driven Oriented Development Process (GDP)
Organização vertical X Organização horizontal
“Decrease overall development time by
increasing the number of people working on a
software project “
(The Mythical Man-Month)
“Slim vertical project organization is by far more
productive than a horizontally organized project with
numerous specialists and communication interfaces
between them.”
(Pizka M., Schnabel I.)

26. Goal-Driven Oriented Development Process (GDP)
Papéis e pessoas
1.Desenvolvedores
2.Analistas de negócios
3.Arquitetos de software
4.Gerente de projeto
5.Engenheiro de requisitos
Pessoas
• Especializadas, qualificadas e
motivadas.
• Pessoas são mais importantes que
processos (Agile Manifesto)
• Comprometidas e não apenas
envolvidas.
Papéis

27. Goal-Driven Oriented Development Process (GDP)
Atividades
1.Identificação das metas
2.Priorização das metas
3.Distribuição vertical de tarefas
4.Implementação e teste
5.Entrega

28. Goal-Driven Oriented Development Process (GDP)
1- Identificação das metas
A. Grupos de 5 pessoas: stakeholders, analistas de negócios e
desenvolvedores.
B. Stakeholders e analistas de negócios devem explicar suas
metas aos desenvolvedores sem QUALQUER ASPECTO
TÉCNICO.
C. Desenvolvedores devem:
I. Manter pessoas de negócios focados nos objetivos de
negócio ao invés de tecnologia.
II. Oferecer ideias para as quais pode se usar a tecnologia
para atingir as metas.
III. Informar as pessoas de negócios sobre custos e
dificuldades das implementações, além de auxiliar na
priorização das metas.
Atividades

29. Goal-Driven Oriented Development Process (GDP)
2- Priorização de metas
A. Responsabilidade de todos stakeholders, analistas de
negócios e desenvolvedores.
B. Analistas de negócios deve informar possíveis dependências
em requisitos de negócios que possam interferir para
alcançar a meta
C. Desenvolvedores devem informar possíveis dependências
tecnológicas às pessoas de negócios
Atividades

30. Goal-Driven Oriented Development Process (GDP)
3- Distribuição vertical de tarefas
A. Baseado nas prioridades das metas e nas skills individuais
de cada desenvolvedor, as metas selecionadas são setadas
em grupos de até 4 desenvolvedores ou, dependendo do
projeto, um desenvolvedor pode ter diversas metas
associadas.
Atividades

31. Goal-Driven Oriented Development Process (GDP)
4- Implementação e testes
A. Implementation-driven tests: executados durante a
implementação por desenvolvedores
B. Goal-driven tests: executados ao fim de cada iteração e
comparado com a implementação junto as questões
formuladas durante a identificação da meta.
C. A falta de conformidade, pode indicar um defeito na
implementação durantes os testes, como também pode
indicar fraqueza na definição de metas.
Atividades

32. Goal-Driven Oriented Development Process (GDP)
5- Entrega
Entrega com potencial funcional validada através dos testes de
implementação e dos testes de metas.
Atividades

33. Proposta de um modelo
Visão geral
Requisitos de
usuários
Requisitos do
projeto
Requisitos
de software
Metas de
negócios
Requisitos de
negócio
Metas de
software
Metas de
usuários
Metas do
projeto
Especificações dos requisitos
do projeto
Elicitação de requisitos Especificação de requisitos
Especificações dos requisitos
de negócios
Especificações dos requisitos
de usuários
Especificações dos requisitos
de software
Definição de metas
REQUISITOS
Desenvolvimento
Validação de
entregáveis
Validação de
metas
Planejamento da
arquitetura
Arquitetura de Software
Desenvolvimento
e teste
Transição
Planejamento de infra
estrutura
Infra-estrutura
Deploy
Testes em produção
Validação
de uso
CONSTRUÇÃO
ITERATIVOEINCREMENTALCASCATA
Validação de requisitos

34. Proposta de um modelo
Requisitos – Exemplos de definição de metas
OUTCOMEIMPORTÂNCIA
Impact
Mapping
ISO 9126
40% Eficácia 30% Eficiência 15% Satisfação
15% Contexto de uso
Doc.
Informal
ISO 9241-11
Orçamento avaliado
em R$ 130.000
Aumentar 30% de inscritos
para cursos on-lineMetas de
negócios
Metas de
software
Metas de
usuários
Metas do
projeto
Definição de metas
Guiar e suportar métricas para o
projeto de software a ser executado
Guiar e suportar métricas para o
produto a ser desenvolvido
Guiar e suportar métricas para
stakeholders que utilizarão o produto
Guiar e suportar métricas para o
funcionamento do software
12 meses para
projeto
Reability - Tolerância à falhas (Load balance)
Portability - Rodar em Linux e Windows (Net
.Core)
FERRAMENTAS/TÉCNICAS

35. Proposta de um modelo
Requisitos – Exemplos de definição de requisitos
OUTCOMEIMPORTÂNCIA
Reuniões,
Brainstorm,
Design
Thinking,
Workshop,
Pesquisa de
campo,
Questionários
Conhecimento sobre os usuários
Visão do projeto
Regras de negócios
Levantar os requisitos do projeto a ser
executado
Levantar os requisitos de negócios do
software a ser construído
Levantar os requisitos de stakeholders
que utilizarão o produto
Levantar os requisitos do software a
ser construído
FERRAMENTAS/TÉCNICAS
Conhecimento sobre o produto de software a
ser construído
Requisitos de
usuários
Requisitos do
projeto
Requisitos
de software
Requisitos de
negócio
Elicitação de
requisitos

36. Proposta de um modelo
Requisitos – Exemplos de especificação de requisitos
OUTCOMEIMPORTÂNCIA
Documento
Visão
Perfils de usuários
Documento textual do projeto
Diagramas de colaboração
Criar uma linguagem de fácil
interpretação entre pessoas
técnicas e não técnicas reduzindo
gaps de comunicação e
fornecendo boas condições para a
construção do produto.
Especificações de uso em um sistema de
software
Especificação de
requisitos
Especificações dos requisitos
do projeto
Especificações dos requisitos
de negócios
Especificações dos requisitos
de usuários
Especificações dos requisitos
de software
BPMN
Personas
Use Case
FERRAMENTAS/TÉCNICAS

37. Proposta de um modelo
Validação de requisitos
Validação de metasValidação de requisitos
Validação de entregáveis
Validação
de uso
Validação
do software
Testes
Testes com usuários
Revisão com stakeholders
Testes em requisitos
Goal-driven tests:
Executados ao fim de cada
iteração (se possível) e
comparado com a
implementação junto as
questões formuladas durante
a identificação da meta.

38. Obrigado!
• Gojko Adzic., Impact Mapping: Making a Big
Impact with Software Products and Projects
(2012)
• I., Pizka M., Goal-Driven Software Development
Process (2006).
• Johnson, J. , Crear J. , Vianna L. et all., CHAOS
Report , Standish Group (2015).
• Sommerville I. , Software Engineering 9th
edition (2011)