ES Aula02

(1)

Modelos de Processo

C L EY TO N RO D R IGU ES , P HD C A N D I DATE U P E – C A M P U S G A R A N HU N S

(2)

CLEYTON RODRIGUES, M.SC

(3)

Agenda

Metodologia de Processo de Software; Atividades Tradicionais e Complementares; Modelos Prescritivos de Processo;

(4)

Processo de Software

Sengundo Pressman: Processo é “[...] conjunto de atividades, ações e tarefas realizadas na

criação de algum produto de trabalho (work product)” e Processo de Software é “[...] um arcabouço para as tarefas que são necessárias para construir softwares de alta qualidade”

Processo é geralmente adaptado às necessidades da organização.

Base para o controle gerencial de projetos de softwares, gerência, marcos, uso efetivo das tecnologias

(5)

Metodologia de Processo Genérico

Cada Projeto precisa de um conjunto diferente de tarefas;

Entretanto, existem aquelas tarefas bases para todo projeto:

◦ Comunicação;

◦ Planejamento;

◦ Modelagem;

◦ Construção;

(6)

Comunicação

Atividade de Comunicação e colaboração com os stakeholders, isto é, todos os interessados no projeto;

(7)

Metodologia de Processo Genérico

Planejamento

◦ Definir o plano de tarefas, riscos, recursos, qual o produto de trabalho, e um cronograma.

Modelagem

◦ Criação de Modelos claros, e de entendimento comum.

◦ Duas atividades:

◦ Análise: elaboração, validação dos requisitos; ◦ Projeto: Arquitetura, Interface, Componentes;

(8)

Arcabouço de Processo Genérico

Construção:

◦ Codificação + Testes

Implantação:

(9)

Atividades (complementares) de apoio

Acompanhamento e controle de projeto de software;

Gestão de Risco;

Garantia de Qualidade de Software;

Revisões Técnicas Formais;

Medição (PPP: Processo x Projeto x Produto);

Gestão de Configuração de Software;

Gestão de Reusabilidade;

(10)

Modelos Prescritivos de

Processo

(11)

Modelos Prescritivos do Processo

Os Modelos de processo convencionais são um roteiro para impor ordem e dar estrutura para a Engenharia de Software;

O Mundo do software quase sempre busca modificações! E então?

Modelos prescritivos ordem e consistência;

(12)

Tipos de Modelos Tradicionais

Modelo em Cascata;

Modelo Incremental;

Modelo (Evolucionário) de Prototipagem; Modelo (Evolucionário) em Espiral;

(13)

Modelo em Cacasta

Abordagem sistemática e sequencial (linea).

Requisitos razoavelmente compreendidos e estáveis; Mudança Linear da Comunicação para Implantação; Mais antigo e mais problemático:

◦ E se surgirem modificações?

◦ Consegue-se (inicialmente) ter uma documentação de requisitos completa e estável?

(14)

(15)

Modelo em Cascata

Outros problemas:

◦ Estado de Bloqueio; ◦ Testes Tardes!!!

(16)

Modelo Incremental

O escopo global do projeto não é totalmente conhecido;

Há necessidade enviar para o cliente ou para uma análise mais detalhada, o andamento do produto;

Cada iteração libera novas funcionalidades; É iterativo, e esta cessa quando o projeto acaba.

(17)

Modelo Incremental

(18)

Modelo Evolucionário de Prototipagem

Evolucionário: evolui com o tempo;

Utilizado quando se tem requisitos confusos, ou mesmo só o objetivo geral; Problemas com tempo!

Protótipos são sempre levados para o cliente, afim de definir melhor os requisitos;

Em geral, não são operacionais primeiro protótipo deve ser descartado!

Também, são usadas como parte dos outros modelos prescritivos.

(19)

(20)

Atenção: Incremental x Evolucionário

Incremental

(21)

Modelo Espiral

Combina o modelo de Prototipagem com o Modelo em Cascata; Produz Versões Evolucionárias;

Marcos de Ancoragem;

Pode ser aplicado ao longo da vida do software: exemplo, projeto de aperfeiçoamento do

produto;

(22)

(23)

Modelagem Concorrente

Atividades possuem um fluxo de estados;

Todas as atividades existem concorrentemente, porém estão em diferentes estados;

Exemplo:

Atividade Comunicação: “Concluído”

“Aguardando Modificações”;

Atividade Modelagem: “Inativo” “Em desenvolvimento”

Cliente sugere mudanças nos requisitos;

Atividade de Modelagem: “Em desenvolvimento”

(24)

A Saga de Zezinho...

(25)

Vamos analisar...

Vocês poderiam entregar um protótipo do sistema

em 15 dias?

Não, nosso processo não segue essa

(26)

Vamos analisar...

Vocês podem começar a desenvolver o sistema com parte

dos requisitos?

Não, precisamos da especificação

(27)

Vamos analisar...

Quando vocês começam a desenvolver?

Vamos especificar, depois analisar, depois

refinar a especificação, entrar

em contato, e só então, pensar na codificação.

(28)

Vamos analisar...

Eu posso participar das reuniões do projeto efetivamente?

Não, nossa reunião é interna, e precisaríamos agendar um dia para

(29)

Vamos analisar...

Os requisitos mudarão. Vocês podem tratar isso

para a próxima revisão?

Não, você precisará esperar que o sistema

esteja totalmente pronto.

(30)

Vamos analisar...

Vocês suportam mudanças de tecnologias, de plataforma,... ? Não...

(31)

Vamos analisar...

Vocês exploram as especialidades dos seus colaboradores?

Não... Eles sempre atuam de forma

(32)

Vamos analisar...

??? Ok, cancele o projeto!

Senhor, nós estaremos enviando um protocolo, que

o senhor precisará assinar juntamente com os gerentes,

reconhecer firma, em seguida, destacar os motivos

do cancelamento, entrar novamente em contato com

(33)

(34)

(35)

“Desenvolvendo e ajudando outros a desenvolver software, estamos desvendando

formas melhores de desenvolvimento. Por meio desse trabalho, passamos a valorizar:

- Indivíduos e Interações acima de processos e ferramentas;

- Software operacional acima de documentação completa;

- Colaboração dos Clientes acima de negociação contratual;

- Respostas a mudanças acima de seguir um plano;

Ou seja, embora haja valor nos itens à direita, valorizaremos os da esquerda mais

ainda.”

MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT, 2001

HT TP://AGILEMANIFESTO.ORG/ISO/PTBR

(36)

Metodologia Ágil

“Entrega rápida do Valor de Negócio, com Menos Burocracia”

◦

Há Regras

Poucas, porém suficientes!

Comunicação e Interação entre as

Pessoas.

(37)

(38)

(39)

(40)

Metodologia Ágil e Documentação

(41)

(42)

E quais seriam os Métodos Ágeis?

SCRUM XP KANBAN FDD Crystal DSDM RUP OpenUP

(43)

Atividade II – Seminário da Unidade

Equipe de 03 pessoas

Professor ↔ Cliente;

Cada equipe terá 20 min para expor sua Metodologia, sem slides;

Em seguida, o professor fará questionamentos a qualquer membro da equipe, sobre como a Metodologia reagirá a certas situações.

(44)