Engenharia de

Software

Engenharia de Software

Sistematizar o processo de criação e manutenção de

software.

Ciclos de Vida de Sofware

Ciclo de Vida Clássico (Cascata)

Prototipação

Modelo Espiral

Técnicas de 4a Geração

Ciclo de Vida Clássico

Comunicação

Início do projeto

Levantamento das

necessidades Planejamento

Estimativas

Cronograma

Acompanhamento Modelagem

Análise

Projeto

Construção

Codificação

testes Emprego

entrega

Suporte

feedback

Engenharia de

Sistemas Análise de

Requisitos Projeto

Codificação

Testes

Manutenção

Cascata

Problemas com o Ciclo de Vida Clássico

projetos reais raramente seguem o fluxo seqüencial que

o modelo propõe

logo no início é difícil estabelecer explicitamente todos

os requisitos. No começo dos projetos sempre existe uma

incerteza natural

o cliente deve ter paciência. Uma versão executável do

software só fica disponível numa etapa avançada do

desenvolvimento

fim

início

construção

produto

refinamento

protótipo

avaliação

protótipo

construção

protótipo

projeto

rápido

obtenção

dos

requisitos

Prototipação

Problemas com a

Prototipação

cliente não sabe que o software que ele vê não considerou,

durante o desenvolvimento, a qualidade global e a

manutenibilidade a longo prazo. Não aceita bem a ideia que a

versão final do software vai ser construída e "força" a utilização

do protótipo como produto final.

Problemas com a Prototipação

desenvolvedor freqüentemente faz uma

implementação comprometida (utilizando o que

está disponível) com o objetivo de produzir

rapidamente um protótipo. Depois de um tempo ele familiariza

com essas escolhas, e esquece que elas não são apropriadas para o produto

final.

Prototipação (comentários)

Ainda que possam ocorrer problemas, a prototipação

é um ciclo de vida eficiente

A chave é definir-se as regras do jogo logo no

começo

O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como

um mecanismo a fim de definir os requisitos

Ciclo de Vida em Espiral

engloba as melhores características do ciclo de vida Clássico e da

Prototipação, adicionando um novo elemento: a Análise de Risco

segue a abordagem de passos sistemáticos do Ciclo de Vida

Clássico incorporando-os numa estrutura iterativa que reflete mais

realisticamente o mundo real

usa a Prototipação, em qualquer etapa da evolução do produto,

como mecanismo de redução de riscos

decisão de continuar ou não

direção de um

sistema

concluído

avaliação

do cliente engenharia

análise dos

riscos

planejamento

Espiral

início

Atividades do Ciclo de Vida em Espiral

Planejamento: determinação dos objetivos,

alternativas e restrições

Análise de Risco: análise das alternativas e

identificação / resolução dos riscos

Construção: desenvolvimento do produto no

nível seguinte

Avaliação do Cliente: avaliação do produto

e planejamento das novas fases

avaliação

do

cliente engenharia

análise dos

riscos

planejamento

é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala.

usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva.

pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável

exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso

Espiral (comentários)

o modelo é relativamente novo e não tem sido amplamente

usado

Demorará muitos anos até que a eficácia desse

modelo possa ser determinada com certeza

absoluta.

Espiral (comentários)

Técnicas de 4a Geração

Concentra-se na capacidade de se especificar o software a uma

máquina em um nível que esteja próximo à linguagem natural.

Engloba um conjunto de ferramentas de software que

possibilitam que:

o sistema seja especificado em uma linguagem de

alto nível e

o código fonte seja gerado automaticamente a partir

dessas especificações

Obtenção dos

Requisitos Estratégia do

“Projeto” Implementação

usando 4GL Testes

Técnicas de 4a Geração

Ferramentas do ambiente de

desenvolvimento de software de 4GL

O ambiente de desenvolvimento de software que sustenta o ciclo de vida

de 4a geração inclui as ferramentas:

linguagens não procedimentais para consulta de banco de dados

geração de relatórios

manipulação de dados

interação e definição de telas

geração de códigos

capacidade gráfica de alto nível

capacidade de planilhas eletrônicas

1. Revisões

2. Documentação

3. Controle de

Mudanças

CCCooonnnssstttrrruuuçççãããooo

1. Entender

2. Modificar

3. Revalidar

Manutenção “mudanças”

OOOpppeeerrraaaçççãããooo

SSSOOOFFFTTTWWWAAARRREEE

PPPRRROOODDDUUUTTTOOO

AAAtttiiivvviiidddaaadddeeesss dddeee AAApppoooiiiooo

1. Análise de

Sistema

2. Planejamento

do Projeto

3. Análise de

Requisitos

Definição“o que” Desenvolvimento

“como”

1. Projeto de

Software

2. Codificação

3. Teste

Engenharia de Software uma visão genérica

Abordagem Clássica vs. Abordagem Ágil

• Ciclo de vida ágil é semelhante ao clássico

• Define o que o cliente quer e inicia o projeto

• Planeja o projeto, calculando o esforço

• Executa o plano, construindo a solução

• Monitora resultados e entrega ao cliente

20 /

61

Fases

• Planejamento

• Sprints (padrão de processo)

• Reuniões Diárias

• Revisão

• Retrospectivas

• Encerramento

21 /

61

Scrum

23 /

61

Planejamento

• Relativamente curto

• Projeto da arquitetura do sistema

• Estimativas de datas e custos

• Criação do backlog

– Participação de clientes e outros departamentos

• Levantamento dos requisitos e atribuição de prioridades

• Definição de equipes e seus líderes

• Definição de pacotes a serem desenvolvidos

24 /

61

Backlog

Sprint - Reuniões

Diárias

• Cerca de 15 minutos de duração

• Todos respondem às perguntas: – O que você realizou desde a última reunião?

– Quais problemas você enfrentou?

– Em que você trabalhará até a próxima reunião?

• Benefícios: – Maior integração entre os membros da equipe

– Rápida solução de problemas

• Promovem o compartilhamento de conhecimento

– Progresso medido continuamente

• Minimização de riscos

25 /

61

Sprint - Revisão

• Deve obedecer à data de entrega

– Permitida a diminuição de funcionalidades

• Apresentação do produto ao cliente

– Sugestões de mudanças são incorporadas ao backlog

• Benefícios:

– Apresentar resultados concretos ao cliente

– Integrar e testar uma boa parte do software

– Motivação da equipe

26 /

61

Nova funcionalidade

Encerramento

• Finalização do projeto

• Atividades:

• Testes de integração

• Testes de sistema

• Documentação do usuário

• Preparação de material de treinamento

• Preparação de material de marketing

27 /

61

Papéis – Product

Owner

• Responsável por apresentar os interesses de todos os

stakeholders

• Define fundamentos iniciais do projeto, objetivos e planos

de release

• Responsável pela lista de requisitos (Product

Backlog)

• Certifica se as atividades com maior valor para o negócio

são desenvolvidas primeiro

• Priorização freqüente das funcionalidades antes de cada

iteração

28 /

61

Papéis – Scrum Master

• Responsável pelo sucesso do Scrum

• Ensina o Scrum para os envolvidos com o projeto

• Implementa o Scrum na empresa de forma adaptada a sua

cultura, para continuamente gerar benefícios

• Certifica se cada pessoa envolvida está seguindo seus papéis

e as regras do Scrum

• Certifica que pessoas não responsáveis não interfiram no

processo

29 /

61

Papéis – Time

• Responsável por escolher as funcionalidades a serem desenvolvidas

em cada interação e desenvolvê-las

• O time se auto-gerencia, se auto-organiza

• Todos os membros do time são coletivamente responsáveis pelo

sucesso de cada iteração

30 /

61

31 /

61

XP – Extreme Programming

(Programação Extrema)

XP

• Fases:

• Planejamento

• Projeto

• Codificação

• Teste

32 /

61

XP

Planejamento

• Fase de levantamento de requisitos.

• ouvir histórias

33 /

61

XP

Jogo do Planejamento

• Elaboração das Histórias (Exploração)

• 1) Histórias determinam algo que o sistema precisa fazer, são

• descritas pelo cliente.

• 2) O tempo para elaborar uma história é estimado pelo time.

• 3) Caso uma história fique muito grande, ela é dividida em

• tarefas.

34 /

61

XP

35 /

61