MODELAGEM DE SOFTWARE

E
METODOLOGIA ÁGIL DE
DESENVOLVIMENTO DE
SOFTWARE
Prof. Luciano José Savio
ONDE ATUA A
ENGENHARIA
DE SOFTWARE
MODELOS DE
PROCESSO DE
SOFTWARE E
ATIVIDADES DE
SOFTWARE
Ao longo do tempo
a forma de se
construir softwares
evoluiu...
 ▶ Softwares da Primeira era –
1950 🡪 1965
▶ Software era customizado
▶ Software era personalizado
▶ Software era processado offline
(em batch)
▶ Sem documentação
específica

EVOLUÇÃO NA CONSTRUÇÃO DE
SOFTWARES
 ▶ Softwares da Segunda era –
1965 🡪 1975
▶ Software Multiusuário
▶ Operação em tempo real
▶ Conexão com banco de
dados
▶ Profissionalização da
construção do software –
software houses

EVOLUÇÃO NA CONSTRUÇÃO DE
SOFTWARES
▶ Softwares da Terceira era – 1975 🡪 1985
▶ Sistemas distribuídos
▶ Inteligência Artificial
▶ Redução do custo de hardware

EVOLUÇÃO NA
CONSTRUÇÃO DE
SOFTWARES
 ▶ Softwares da Quarta era – 1985 🡪 1990
▶ Sistemas Especialistas
▶ Redes Neurais Artificiais
▶ Computação paralela

EVOLUÇÃO NA CONSTRUÇÃO DE
SOFTWARES
 ▶ Softwares da Quinta era – 1990…
▶ Conectividade
▶ Ambientes Virtuais
▶ Cloud computing
▶ IoT
▶ Evolução tecnológica

EVOLUÇÃO NA CONSTRUÇÃO DE
SOFTWARES
▶ São programas de “computador”
... e mais que isso...
…Também faz parte toda a
documentação associada ao seu
desenvolvimento e uso.

▶ Softwares devem ter o

desempenho e a funcionalidade
exigidos pelo usuário.
“ATENDER
NECESSIDADES
DO
USUÁRIO!!!”
 O QUE FAZ UM ENGENHEIRO DE SOFTWARE

https://www.youtube.com/watch?v=wdU9L3DqU2w
▶ Área que se preocupa com todos
os aspectos da produção do
software.
▶ Principais atividades da
engenharia de software
▶ Especificação
▶ Desenvolvimento
▶ Validação
▶ Evolução
 Conjunto de atividades que levam São consideradas atividades
à produção de um software essenciais
Pode ser desenvolvido totalmente Especificação
Pode ser estendido a partir de um software já Projeto
existente Implementação
Pode ser composto por componentes pré- Validação
existentes (bibliotecas de código)
Evolução

PROCESSO DE SOFTWARE
 MODELOS DE PROCESSO DE
SOFTWARE

▶ Trata-se de uma representação simplificada (abstraída) de um

processo de software.
▶ Destacam-se
▶ Cascata
▶ Incremental
▶ Orientado a reuso
MODELO DE
PROCESSO
DE SOFTWARE
TEÓRICO
MODELO DE
PROCESSO
DE SOFTWARE
EM CASCATA
MODELO DE
PROCESSO
DE SOFTWARE
INCREMENTAL
MODELO DE PROCESSO DE SOFTWARE
ORIENTADA A REÚSO
MODELOS DE
PROCESSO DE
SOFTWARE
▶ Perceba que em todos os
modelos vistos sempre
estiveram presentes as
etapas de
▶ Especificação
▶ Desenvolvimento
▶ Validação
▶ Evolução
MODELAGEM DE
SOFTWARE
Engenharia de Requisitos
 • Requisitos de sistemas/software
• Descrições do que o sistema/software deve fazer, os
serviços que ele oferece, as restrições sobre seu

REQUISITOS / funcionamento.

ENGENHARIA • Refletem as necessidades dos clientes que servem uma

finalidade determinada.

DE
REQUISITOS
• Engenharia de requisitos (Requirements engineering):
processo de descobrir, analisar documentos, verificar e
validar esses serviços e restrições.
 NÍVEIS DE REQUISITOS
• Nível de requisito varia:
• Declaração abstrata (alto nível) → requisito do usuário
• Definição detalhada (baixo nível) → requisito de sistema

• Requisito de usuário:
• Linguagem natural (podendo ter
diagramas)
• Quais serviços o sistema deverá
fornecer a seus usuários
• Quais restrições com as quais o
sistema deverá operar
NÍVEIS DE REQUISITOS
• Requisito de sistema:
• Costuma ser chamado de
“especificação de requisitos”
• Deve definir exatamente o que
dever ser implementado
• Pode ser parte do contrato entre
comprador/desenvolvedor
NÍVEIS DE REQUISITOS: exemplo
 TIPOS DE REQUISITOS

Requisitos
Requisitos
não
funcionais
funcionas
 TIPOS DE REQUISITOS
• Requisitos funcionais:

- declaração de serviços que o sistema deve fornecer;

- declarações de como o sistema deve reagir a entradas
específicas;
- declarações de como o sistema deve se comportar em
determinadas situações
- declarações do que o sistema não deve fazer.
 • Exemplos - sistema medico MHC-PMS:
• Um usuário deve ser capaz de pesquisar as
listas de agendamento para todas as
REQUISITOS clínicas.
• O sistema deve gerar a cada dia, para
FUNCIONAIS cada clínica, a lista dos pacientes para as
consultas daquele dia.
• Cada membro da equipe que usa o
sistema deve ser identificado apenas por
seu número de oito dígitos.
 TIPOS DE REQUISITOS
• Requisitos não funcionais

• Restrições aos serviços ou funções

oferecidos pelo sistema
• Incluem restrições de tempo, restrições no
processo de desenvolvimento e restrições
impostas por normas
• Geralmente, aplicam-se ao sistema como
um todo.
Exemplos de requisitos não funcionais no sistema médico
MHC-PMS.
Requisitos de produto
O MHC-PMS deve estar disponível para todas as clínicas durante as horas
normais de trabalho(segunda a sexta, 08h30min às 17h30min). Períodos de
não operação dentro de horários normal de trabalho não podem exceder
cinco segundos em um dia.

Requisito organizacional
Usuários do sistema MHC-PMS devem se autenticar com seus cartões de
identificação da autoridade da saúde.

Requisito externo
O sistema deve implementar as disposições de privacidade dos pacientes, tal
como estabelecido Hstan-03-2006-priv.
 DOCUMENTOS DE REQUISITOS
Depois de finalizada etapa de levantamento de
requisitos temos o documento
Especificação de requisitos do Sistema
MODELAGEM DE
SOFTWARE
Análise de Requisitos
 ANÁLISE DE REQUISITOS
ABORDAGEM TRADICIONAL

MAIS ABRANGENTE MAIS METÓDICA MAIS COMPLETA

ANÁLISE DE
REQUISITOS
Modelo de análise de
requisitos em espiral
 ESPECIFICAÇÃO DE REQUISITOS
DO SISTEMA

Trata-se de um documento
Documento muito Documento “sem
oficial do processo de
importante... utilidade”
especificação do software
• Consta “o quê” os • Em software houses ou • Metodologia ágeis de
desenvolvedores devem fábricas de software, desenvolvimento
implementar empresas especializadas
• Não consta “como” os em construir software
desenvolvedores os
devem implementar
 O ANALISTA DE REQUISITOS
• Profissional responsável por construir a
especificação de requisitos do sistema
• Não necessariamente deve ser um
profundo conhecedor de tecnologia
• Habilidades interpessoais são essenciais
• Habilidades comunicativas
• “Fino trato” com outras pessoas
• Perspicácia investigativa
• Saber “como” obter respostas
• Psicologia comportamental
• Entender o comportamento dos usuários
 •Validar se suas necessidades estão
Clientes contempladas

•Elaborar proposta para o cliente

Gestores
PARA QUÊ E •Planejar o desenvolvimento do sistema

POR QUEM •Entendem o quê deve ser desenvolvido

Desenvolvedores
ESTE (contemplado)

DOCUMENTO
É UTILIZADO?
•Testam o software com base nas
Testadores necessidades (requisitos) do cliente

•Entendimento geral do sistema, do que

Manutenção foi contemplado e o que deve sofrer
manutenção.
 DOCUMENTO DE ESPECIFICAÇÃO
DE REQUISITOS

É realmente
necessário??

Base para as Fornece uma visão

Interessa a muitas
próximas etapas bastante
pessoas no âmbito
do específica das
do projeto de
desenvolvimento necessidades do
software
do software cliente.
 ESTRUTURA FORMAL PARA UM
DOCUMENTO DE REQUISITOS
• Prefácio
• Deve definir os possíveis leitores do documento e descrever seu histórico de versões,
incluindo uma justificativa para a criação de uma nova versão e um resumo das
mudanças feitas em cada versão
• Introdução
• Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções
do sistema e explicar como ele vai funcionar com outros sistemas. Também deve
descrever como o sistema atende aos objetivos globais de negócio ou estratégicos da
organização que encomendou o software.
• Glossário
• Deve definir os termos técnicos usados no documento. Você não deve fazer suposições
sobre a experiência ou o conhecimento do leitor.
 ESTRUTURA PARA UM
DOCUMENTO DE REQUISITOS
• Definição de requisitos de usuário
• Deve descrever os serviços fornecidos ao usuário. Os requisitos não funcionais de sistema
também devem ser descritos nessa seção. Essa descrição pode usar a linguagem
natural, diagramas ou outras notações compreensíveis para os clientes. Normas de
produto e processos que devem ser seguidos devem ser especificados.
• Arquitetura do sistema
• Deve apresentar uma visão geral em alto nível da arquitetura do sistema previsto,
mostrando a distribuição de funções entre os módulos do sistema. Componentes de
arquitetura que são reusados devem ser destacados.
• Especificação de requisitos do sistema
• Deve descrever em detalhes os requisitos funcionais e não funcionais. Se necessário,
também podem ser adicionados mais detalhes aos requisitos não funcionais. Interfaces
com outros sistemas podem ser definidas.
 ESTRUTURA PARA UM
DOCUMENTO DE REQUISITOS
• Modelos do sistema
• Pode incluir modelos gráficos do sistema que mostram os relacionamentos entre os componentes
do sistema, o sistema e seu ambiente. Exemplos de possíveis modelos são modelos de objetos,
Boa parte da formalização
modelos de fluxo de dados ou modelos semânticos de dados.
• Evolução do sistema pode ser uma exigência do
• Deve descrever os pressupostos fundamentais em que o sistema cliente!!!
se baseia, bem como quaisquer
mudanças previstas, em decorrência da evolução de hardware, de mudanças nas necessidades
do usuário etc. Essa seção é útil para projetistas de sistema, pois pode ajudá-los a evitar decisões
capazes de restringir possíveis mudanças futuras no sistema
• Apêndices
• Deve fornecer informações detalhadas e específicas relacionadas à aplicação em
desenvolvimento, além de descrições de hardware e banco de dados, por exemplo. Os requisitos
de hardware definem as configurações mínimas ideais para o sistema. Requisitos de banco de
dados definem a organização lógica dos dados usados pelo sistema e os relacionamentos entre
esses dados.
• Índice
• Vários índices podem ser incluídos no documento. Pode haver, além de um índice alfabético
normal, um índice de diagramas, de funções, entre outros pertinentes
 COMO CONSTRUIR UMA
ESPECIFICAÇÃO DE REQUISITOS
• Linguagem Natural
• Os requisitos são escritos em frases numeradas em linguagem natural. Cada
frase deve expressar um requisito.
• Exemplo:
1. O sistema deve medir o açúcar no sangue e fornecer insulina, se necessário, a
cada dez minutos. (Mudanças de açúcar no sangue são relativamente lentas,
portanto, medições mais frequentes são desnecessárias; medições menos
frequentes podem levar a níveis de açúcar desnecessariamente elevados.)
2. O sistema deve, a cada minuto, executar uma rotina de autoteste com as
condições a serem testadas e as ações associadas definidas na Quadro 4.3 (A
rotina de autoteste pode descobrir problemas de hardware e software e pode
alertar o usuário para a impossibilidade de operar normalmente.)
 COMO CONSTRUIR UMA
ESPECIFICAÇÃO DE REQUISITOS
• Linguagem Natural Estruturada
• Os requisitos são escritos em linguagem natural em um formulário padrão ou
template.

Bomba de insulina/ software de controle/SRS/3.3.2

Função Calcula doses de insulina: nível seguro de açúcar
Descrição Calcula a dose de insulina a ser fornecida quando o nível de açúcar está
na zona de segurança entre três e sete unidades
Entradas Leitura atual de açúcar (r2), duas leituras anteriores (r0 e r1).
Fonte Leitura atual da taxa de açúcar pelo sensor. Outras leituras da memória.
Ação CompDose é zero se o nível de açúcar está estável ou em queda ou se o
nível está aumentando, ...
:: : : : :
 ELICITAÇÃO (DESCOBERTA) E
ANÁLISE DE REQUISITOS
• Nesta etapa entram em cena os profissionais
(analistas de requisitos) que vão obter
informações a respeito do que deve ser
implementado

• Serviços que o sistema vai oferecer

• Domínio (escopo) da aplicação
• Restrições do Sistema
• …
 ELICITAÇÃO DE REQUISITOS
DESAFIOS
• Indecisão do cliente a respeito do que precisam exatamente.
• Dificuldade em expor o que o sistema precisa fazer
• Exigem ações inviáveis para o sistema desempenhar
• Comunicação carregada de termos e terminiologias próprias da área fim.
• Analistas de requisitos sem experiência na área podem ter dificuldade de
entendimento dos requisitos.
• Visões diferentes de um mesmo requisito.
• Usuários podem ter diferentes visões (muitas vezes divergentes) para um mesmo
requisito.
• Ocultamento de informações
• Nem todo usuário estará disposto a colaborar prontamente com esta tarefa.
 ELICITAÇÃO DE REQUISITOS
DESAFIOS
• Fatores políticos
• Exigência de certos requisitos para aumentar sua influência na empresa.
• Fatores econômicos
• Durante esta fase, eventos que levam a alterações na estabilidade financeira
podem influenciar na descoberta dos requisitos.
• Mudanças constantes dos requisitos
• Por ser um processo bastante metódico, as mudanças muito frequentes de
requisitos podem atrapalhar o processo de descoberta.
 ELICITAÇÃO DE REQUISITOS
Descoberta
PROCESSO
de requisitos

Classificação
Especificação e organização
de requisitos de requisitos

Priorização de
requisitos
 ELICITAÇÃO DE REQUISITOS
OBTENDO INFORMAÇÕES

Fontes de informação Técnicas de Obtenção

Documentação Observação
Sistemas similares / compatíveis Entrevistas
Clientes / Usuários Cenários
Prototipação
Imersão
 ELICITAÇÃO DE REQUISITOS
OBTENÇÃO DE INFORMAÇÃO ATRAVÉS DE UM CENÁRIO
• Suposição inicial:
• O paciente é atendido em uma clínica médica por uma recepcionista; ela gera um registro no sistema e coleta suas
informações pessoais (nome, endereço, idade etc.). Uma enfermeira é conectada ao sistema e coleta o histórico
médico do paciente.
• Normal:
• A enfermeira busca o paciente pelo sobrenome. Se houver mais de um paciente com o mesmo sobrenome, o nome e
a data de nascimento são usados para identificar o paciente. A enfermeira escolhe a opção do menu para adicionar
o histórico médico. A enfermeira segue, então, uma série de prompts do sistema para inserir informações sobre
consultas em outros locais, os problemas de saúde mental (entrada de texto livre), condições médicas (enfermeira
seleciona condições do menu), medicação atual (selecionado no menu), alergias (texto livre) e informações da vida
doméstica (formulário).
• O que pode dar errado:
• O prontuário do paciente não existe ou não pôde ser encontrado. A enfermeira deve criar um novo registro e registrar
as informações pessoais. As condições do paciente ou a medicação em uso não estão inscritas no menu. A enfermeira
deve escolher a opção ‘outros’ e inserir texto livre com descrição da condição/medicação. O paciente não pode/não
fornecerá informações sobre seu histórico médico. A enfermeira deve inserir um texto livre registrando a incapacidade/
relutância do paciente em fornecer as informações. O sistema deve imprimir o formulário-padrão de exclusão
afirmando que a falta de informação pode significar que o tratamento será limitado ou postergado. Este deverá ser
assinado e entregue ao paciente.
• Outras atividades:
• Enquanto a informação está sendo inserida, o registro pode ser consultado, mas não editado por outros agentes.
• Estado do sistema na conclusão:
• O usuário está conectado. O prontuário do paciente, incluindo seu histórico médico, é inserido no banco de dados e
um registro é adicionado ao log do sistema, mostrando o tempo de início e fim da sessão e a enfermeira envolvida.
ELICITAÇÃO
DE REQUISITOS
OBTENÇÃO DE
INFORMAÇÃO
ATRAVÉS DE
CASOS DE
USO
 ELICITAÇÃO DE REQUISITOS
OBTENÇÃO DE INFORMAÇÃO ATRAVÉS DE
CASOS DE USO - DESCRIÇÃO
“Agendar a consulta permite que dois ou
mais médicos de consultórios diferentes
possam ler o mesmo registro ao mesmo
tempo. Um médico deve escolher, em um
menu de lista de médicos on-line, as pessoas
envolvidas. O prontuário do paciente é
então exibido em suas telas, mas apenas o
primeiro médico pode editar o registro. Além
disso, uma janela de mensagens de texto é
criada para ajudar a coordenar as ações.
Supõe-se que uma conferência telefônica
para comunicação por voz será
estabelecida separadamente.”
ELICITAÇÃO • Técnica de observação que pode ser usada para
compreender os processos e ajudar a extrair os
DE requisitos para esses processos. O profissional em
análise faz uma imersão no ambiente onde o sistema
REQUISITOS: será usado. Através da observação da rotina diária são
feitas anotações sobre as tarefas reais em que os
participantes estão envolvidos.
• Esta técnica permite identificar requisitos implícitos e
ETNOGRAFIA detalhes de requisitos que em outras técnicas podem
passar desapercebido ou não serem relatados
(IMERSÃO)
 OBSERVE O SEGUINTE EXEMPLO
• Com base no exemplo
1. Identifique os requisitos funcionais
2. Identifique os requisitos não-funcionais
“Um sistema automático de emissão de passagens vende passagens de trem. A partir
de uma lista de possíveis destinos, os usuários escolhem seu destino e apresentam um
cartão de crédito e um número de identificação pessoal. Os destinos possíveis devem
ser organizados de modo a facilitar a escolha. Após a escolha do destino, o sistema
deve responder prontamente se há espaço disponível no trem. A passagem é emitida
e o custo dessa passagem é incluído em sua conta do cartão de crédito. Quando o
usuário pressiona o botão para iniciar, uma tela de menu com os possíveis destinos é
ativada, juntamente com uma mensagem para que o usuário selecione um destino.
Uma vez selecionado um destino, pede-se que os usuários insiram seu cartão de
crédito. A validade do cartão é checada e o usuário então deve fornecer um
número de identificação pessoal. Quando a transação de crédito é validada, a
passagem é emitida. O formato do bilhete de passagem deve seguir ao padrão
definido pelo Sistema Nacional de Tráfego Ferroviário”.
 POSSÍVEIS REQUISITOS
LEVANTADOS
• RF1: Quando o usuário pressiona o botão para iniciar, uma tela de menu com os possíveis destinos é
ativada, juntamente com uma mensagem para que o usuário selecione um destino.
• RF2: Uma vez selecionado um destino, pede-se que os usuários insiram seu cartão de crédito.
• RF3: O sistema deve informar se existem vagas no destino escolhido
• RF3: A validade do cartão é checada e o usuário então deve fornecer um número de identificação pessoal.
• RF4: Quando a transação de crédito é validada, a passagem é emitida e o custo dessa passagem é
incluído em sua conta do cartão de crédito.
• RNF1: As telas devem facilitar a escolha do destino
• RNF2: O tempo de resposta sobre vaga no trem deve ser adequado
• RNF3: O formato do bilhete de passagem deve seguir ao padrão definido pelo Sistema Nacional de Tráfego
Ferroviário”.
• RNF4: A passagem deve ser emitida para usuários maiores de 16 anos.
• RNF5: O cartão de crédito deve estar em nome do próprio usuário.
MODELAGEM DE
SOFTWARE
Validação e gerenciamento de requisitos
QUANTO CUSTA
O
RETRABALHO??
 QUANTO
CUSTA O
RETRABALHO??
 QUANTO
CUSTA O
RETRABALHO??
QUANTO CUSTA
REESCREVER UM
SOFTWARE??
 VALIDAÇÃO DE
REQUISITOS
• Consiste num processo de checagem, a fim de verificar se os
requisitos definidos realmente vêm de encontro às necessidades do
cliente
• Checagem para confirmar se o sistema faz o que o cliente
quer.
• A validação foca na tentativa de encontrar problemas com os
requisitos definidos.
• Portanto se sobrepõe ao processo de análise de requisitos.
• Erros na elicitação e na especificação de requisitos podem gerar
custos elevados em termos de retrabalho
• É fundamental se certificar de que os requisitos estão alinhados
com as necessidades do cliente.
 VALIDAÇÃO
X
VERIFICAÇÃO

Validação
Checa se os requisitos representam o
sistema corretamente.
• Esta funcionalidade do sistema atende
ao que o cliente deseja?
Verificação
Checa se os requisitos estão
representados corretamente.
• Esta funcionalidade do sistema está
definida corretamente?
 Um caso de uso sempre
deve estar associado a
um ator.
(Erro de verificação)

Quem registra o
paciente não é o
médico!!
(Erro de Validação)
 PROBLEMAS COMUNS
• Validade/Corretude
• A função era exatamente aquela?
• Consistência
• Diferentes requisitos em conflito.
• Completude
• Todos os requisitos estão contemplados?
• Realismo
• Os requisitos são passíveis de serem implementados?
• Testabilidade
• Os requisitos podem ser validados no sistema assim que implementado?
 TÉCNICAS DE VERIFICAÇÃO
E DE VALIDAÇÃO (V&V)
• Revisão
• Revisar os requisitos periodicamente em busca de erros.
• Prototipação
• Uma implementação simplificada do modelo é demonstrada para os usuários,
a fim de validar se atende às suas necessidades.
• Projeto casos de testes
• Adiantar projetos de casos (situações) de testes .
 O GERENCIAMENTO DE
REQUISITOS
• Em função das mudanças de requisitos (principalmente em
ambientes muito dinâmicos) o gerenciamento destas
mudanças é vital para a construção adequada do sistema.
• Exemplos de mudanças
• Evolução de hardware
• Integração com outros sistemas
• Legislação
• Prioridade nos negócios
• Conflitos entre cliente e usuários
• Conflitos entre usuários
 MATRIZ DE RASTREABILIDADE
DE REQUISITOS
• Consiste em uma matriz onde são registrados todos os requisitos e os
documentos que estão associados a estes de acordo com as etapas em
que o requisito foi submetido.
• Pode conter em uma matriz
• Descrição do Requisito
• Estado do Requisito: finalizado, aprovado, em construção...
• Documento de projeto
• Documento de código Principais
• Documento de testes informações
• Documento de manual de usuário
GERENCIAMENTO
DE REQUISITOS
Com este
gerenciamento é
possível uma evolução
dos requisitos
 GERENCIAMENTO DA MUDANÇA
DE REQUISITOS
• As mudanças nos requisitos durante o projeto vão acontecer... Temos que
estar preparados para elas!!
Modelagem de
Software
Metodologias ágeis
Evolução na construção de Software e a
Crise do Software
• 1960 / 1970: Crise do
O bicho software
• Problemas com orçamento
• Problemas com prazo
pegou! • Problemas com qualidade
• Problemas com requisitos
• Problemas com manutenção
• ...
• Motivo???
 • Para solucionar os problemas necessitava-se
• Sistematizar a construção de software...
• Acompanhamento adequado
• Atendimento aos requisitos iniciais
• Métodos formais e adequados
Solução para • Garantia de qualidade
• O termo engenharia em outras áreas
a crise do tecnológicas cumpre papel de sistematizar
software • Então por que não utilizar o termo engenharia de
software

• Nasce então o termo engenharia de software

 Planejamento cauteloso Atenção à qualidade

Engenharia de Utilização de ferramentas de

apoio

software Adoção de métodos formais

de análise e desenvolvimento
• Ferramentas CASE (Computer-Aided
Software Engineering)
• Software para ajudar a desenvolver

tradicional software

Processo de desenvolvimento
bastante austero e com muito
controle
• Necessário para solucionar os
problemas enfrentados na crise do
software
 • Por que de um modelo de desenvolvimento
de software austero e controlado
Engenharia • Gastava-se muito na produção do software
• Estourava-se o tempo com frequência
de software • Não se tinha controle de qualidade
tradicional • As necessidades dos usuários (requisitos) nem
sempre eram atendidos adequadamente

Vamos
arrumar esta
bagunça!!!
 • Atendeu muito bem às demandas para os
anos de 1980 a 1990
• Softwares grandes e muitas vezes críticos eram
desenvolvidos
• Sistemas bancários
Engenharia • Sistemas aeroespaciais
• Sistemas de governo (civil e militar)
de Software • Sistemas com vida longa
• Necessitando de manutenção adequada
Tradicional • Empresas bem estruturadas tecnologicamente
utilizavam a engenharia de software tradicional
• Grandes equipes trabalhando no
desenvolvimento de sistemas
• Geograficamente distantes
• Longo tempo de desenvolvimento
 Vosmecê por
obséquio teria
intenção em
Aí Gata...
pegar uma afresca
Vamos dar um
ao jardim??
rolê??

Mudanças acontecem... necessariamente!!

Veja o que já aconteceu com a comunicação ao longo do tempo...
 • Sociedade mais ativa
• Novos mercados
Ano 2000... • Novos produtos
• Maior concorrência
mudanças no • Mais agilidade
horizonte... • Dependência da tecnologia
• Organizações apoiadas pela tecnologia... e pelo
software
 Cenário muito mais dinâmico
• Globalização
• Internet

Desenvolvimento
E a tecnologia??? (e o software??)
de software ágil • Exigência de softwares com ciclo de vida mais curto
• Utilizados por pouco tempo e renovados em seguida
• O mercado também muda muito rápido, e o software deve acompanhar
esta mudança.
• Softwares menores (mais fragmentados e especializados)
• Maior rapidez no desenvolvimento de software (e produtos como um
todo)
• Tempo passa a ter importância crucial
• Inclusive mais importante que a qualidade em muitos casos
Metodologia de Desenvolvimento Ágil
https://www.youtube.com/watch?v=HdE8S2ALvWI
 • O desenvolvimento de software tradicional
consegue se enquadrar neste cenário??
• As mudanças não acontecem de uma hora para
Desenvolvimento outra
• Há um grande mercado para o desenvolvimento
de software ágil de software tradicional
• Softwares corporativos
• De longa duração
• Softwares críticos
 • Requisitos instáveis
• Durante o processo de desenvolvimento os
requisitos mudam
• Definir todos os requisitos antes de começar o
desenvolvimento pode acarretar em um
software desatualizado ao ser entregue ao
usuário
Desenvolvimento • Empresas menores passam a utilizar mais e mais
de software ágil softwares
• O modelo tradicional de desenvolvimento de
software dispende muito tempo planejando e pouco
tempo desenvolvendo.
• E isto não se adequa mais a este novo cenário
mais dinâmico.
• Ao final da década de 90 começam a ser propostos
os modelos ágeis de desenvolvimento
2001... O “Manifesto Ágil”

“Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e

ajudando outros a fazê-lo. Através desse trabalho, valorizamos mais:
ESQUERDA DIREITA
Indivíduos e interações do que processos e ferramentas
Software em funcionamento do que documentação abrangente
Colaboração do cliente do que negociação de contrato
Respostas a mudanças do que seguir um plano
Ou seja, embora itens à direita sejam importantes, valorizamos mais os que estão à
esquerda.”
 • Exemplos de métodos
• Mais conhecidos
• Extreme Programming (XP) (mais técnico)
• Scrum (mais gestão do projeto, menos
técnico))
• Test Driven Development (TDD) (mais
técnico)
• Menos usados
Métodos ágeis • Crystal
• Adaptive Software Development (ASD)
• Feature Driven Development (FDD)
• Dynamic System Development Method
(DSDM)
• Agile Unified Process
 Princípios dos métodos ágeis

PRINCÍPIOS DESCRIÇÃO
Envolvimento do cliente Os clientes devem estar intimamente envolvidos no processo de desenvolvimento. Seu papel é fornecer e
priorizar novos requisitos do sistema e avaliar suas iterações.

Entrega incremental O software é desenvolvido em incrementos com o cliente, especificando os requisitos para serem
incluídos em cada um

Pessoas, não processos As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas. Membros da equipe
devem desenvolver suas próprias maneiras de trabalhar, sem processos prescritivos.

Aceitar as mudanças Deve-se ter em mente que os requisitos do sistema vão mudar. Por isso, projete o sistema de maneira a
acomodar essas mudanças.

Manter a simplicidade Focalize a simplicidade, tanto do software a ser desenvolvido quanto do processo de desenvolvimento.
Sempre que possível, trabalhe ativamente para eliminar a complexidade do sistema.
 • Usuário (cliente) é mais envolvido no
desenvolvimento
• Requer mais tempo e dedicação
• Todas as partes interessadas devem estar
representadas
• Todos os usuários devem participar ativamente
Limitações e
• Membros da equipe não se adequando ao
barreiras novo método de trabalho
• Ter o usuário próximo do desenvolvimento
• Organizações muito baseadas em processos
podem ter dificuldade com esta nova cultura
de desenvolvimento.
 • Dificuldades em priorizar mudanças
• Especialmente quando existem muitas partes
envolvidas

Limitações e • Dificuldades de negociação com o cliente

• O cliente pode exigir muito claro tudo e como
barreiras deve ser realizado (como prever as mudanças??)
• Necessita-se de desenvolvedores mais
experientes
Desenvolvimento
tradicional
(baseado em
planos) e o
Desenvolvimento
Ágil
Desenvolvimento
tradicional
(baseado em
planos) e o
Desenvolvimento
Ágil
Método Ágil
Extreme Programming (XP)

• Ciclo de desenvolvimento de
software com XP
• Foca mais nas atividades
sob o ponto de vista
técnico
• Ex.: Como realizar o
levantamento de
requisitos junto ao
usuário
XP
Ciclo de desenvolvimento de software

• Seleciona-se uma “parte” do

software para ser
desenvolvido naquele
“release” ou incremento ou
ciclo
• Em um release seleciona-
se quais estórias
(requisitos) serão
contempladas
Ciclo
XP
Ciclo de desenvolvimento de software

• Cada estória é detalhada

• Constrói-se tarefas que,
no seu todo, contemplam
toda a estória

Ciclo
XP
Ciclo de desenvolvimento de software

• Planejamento do release
• É traçado um plano para o
desenvolvimento das
tarefas a fim de
contemplar as
necessidades daquele
release

Ciclo
XP
Ciclo de desenvolvimento de software

• Desenvolvimento
• Desenvolve-se de acordo
com o que foi planejado
• Integração
• Integra-se com os demais
releases já desenvolvidos
• Teste
• Realiza-se os testes
necessários para aquele Ciclo
release
XP
Ciclo de desenvolvimento de software

• Liberar Software
• O software é liberado
para avaliação

Ciclo
XP
Ciclo de desenvolvimento de software

• Avaliação do software
• O software é avaliado
pelos usuários

Ciclo
XP
Ciclo de desenvolvimento de software

• Seleciona-se outra“parte” do
software para ser
desenvolvido naquele novo
release, dando continuidade
ao ciclo de desenvolvimento
do software

Ciclo
 Práticas utilizadas no XP
Várias destas práticas estão em conformidade com os princípios gerais do desenvolvimento ágil

PRÁTICA DESCRIÇÃO
Planejamento incremental Os requisitos são gravados em cartões de história e as histórias que serão incluídas em um
release são determinadas pelo tempo disponível e sua relativa prioridade. Os
desenvolvedores dividem essas histórias em ‘Tarefas’. Veja os quadros 3.1 e 3.2

Pequenos releases Em primeiro lugar, desenvolve-se um conjunto mínimo de funcionalidades úteis, que
fornecem o valor do negócio. Releases do sistema são frequentes e gradualmente
adicionam funcionalidade ao primeiro release

Projeto simples Cada projeto é realizado para atender às necessidades atuais, e nada mais

Desenvolvimento test-first Um framework de testes iniciais automatizados é usado para escrever os testes para uma
nova funcionalidade antes que a funcionalidade em si seja implementada
 Práticas utilizadas no XP
Várias destas práticas estão em conformidade com os princípios gerais do desenvolvimento ágil

PRÁTICA DESCRIÇÃO
Refatoração Todos os desenvolvedores devem refatorar o código continuamente assim que encontrarem melhorias de
código. Isso mantém o código simples e manutenível

Programação em pares Os desenvolvedores trabalham em pares, verificando o trabalho dos outros e prestando apoio para um bom
trabalho sempre.

Propriedade coletiva Os pares de desenvolvedores trabalham em todas as áreas do sistema, de modo que não se desenvolvam ilhas
de expertise. Todos os conhecimentos e todos os desenvolvedores assumem responsabilidade por todo o
código. Qualquer um pode mudar qualquer coisa

Integração contínua Assim que o trabalho em uma tarefa é concluído, ele é integrado ao sistema como um todo. Após essa
integração, todos os testes de unidade do sistema devem passar
 Práticas utilizadas no XP
Várias destas práticas estão em conformidade com os princípios gerais do desenvolvimento ágil

PRÁTICA DESCRIÇÃO

Ritmo sustentável Grandes quantidades de horas-extra não são consideradas aceitáveis, pois o
resultado final, muitas vezes, é a redução da qualidade do código e da
produtividade a médio prazo.

Cliente no local Um representante do usuário final do sistema (o cliente) deve estar disponível
todo o tempo à equipe de XP. Em um processo de Extreme Programming, o
cliente é um membro da equipe de desenvolvimento e é responsável por levar a
ela os requisitos de sistema para implementação.
 Exemplo de uma estória
Kate é uma médica que deseja prescrever medicamentos para um paciente de uma clínica. O prontuário do paciente já
está sendo exibido em seu computador, assim, ela clica o campo ‘medicação’ e pode selecionar ‘medicação atual’,
‘nova medicação’, ou ‘formulário’.
Se ela selecionar ‘medicação atual’, o sistema pede que ela verifique a dose. Se ela quiser mudar a dose, ela altera esta
e em seguida, confirma a prescrição.
Se ela escolher ‘nova medicação’, o sistema assume que ela sabe qual medicação receitar.
Ela digita as primeiras letras do nome do medicamento. O sistema exibe uma lista de possíveis fármacos que começam
com essas letras. Ela escolhe a medicação requerida e o sistema responde, pedindo-lhe para verificar se o
medicamento selecionado está correto.
Ela insere a dose e, em seguida, confirma a prescrição.
Se ela escolhe ‘formulário’, o sistema exibe uma caixa de busca para o formulário aprovado.
Ela pode, então, procurar pelo medicamento requerido. Ela seleciona um medicamento e é solicitado que verifique se
a medicação está correta. Ela insere a dose e, em seguida, confirma a prescrição.
O sistema sempre verifica se a dose está dentro da faixa permitida. Caso não esteja, Kate é convidada a alterar a dose.
Após Kate confirmar a prescrição, esta será exibida para verificação. Ela pode escolher ‘OK’ ou ‘Alterar’. Se clicar em
‘OK’, a prescrição fica gravada nos bancos de dados da auditoria.
Planejamento do
desenvolvimento da
estória

• A partir de cada estória são

extraídas as funcionalidades
mais importantes e divididas
em tarefas, que são registradas
em cartões de tarefa.
• Posteriormente outras
funcionalidades secundárias
podem surgir a partir desta
mesma estória.
 • Test-first
• Antes de desenvolver a tarefa o
XP – teste é planejado
• Teste incremental a partir de

Teste de determinados cenários

• Os usuários participam do
desenvolvimento dos testes
software • Utilização de ferramentas
(frameworks) para automatização dos
testes.
 Desenvolver a cultura
de responsabilidade “programação sem ego”
coletiva

Revisão do desenvolvimento mais informal

Programação
em pares Corrige-se o que está
errado no momento,
Apoio à refatoração tornando o código mais
simples e direto na
programação

Programadores menos experientes

conseguem experiência mais facilmente
com esta forma de desenvolvimento.
 • Focado no planejamento do ciclo (sprint)

Desenvolvimento
Ágil
Scrum
 • Vantagens do uso do Scrum segundo Rising e
Janoff (2000)
• O produto é decomposto em um conjunto de
partes gerenciáveis e compreensíveis.
• Requisitos instáveis não atrasam o progresso.
Desenvolvimento • Toda a equipe tem visão de tudo, e,
consequentemente, a comunicação da equipe é
Ágil melhorada.
Scrum • Os clientes acompanham a entrega de
incrementos dentro do prazo e recebem
feedback sobre como o produto funciona.
• Estabelece-se confiança entre clientes e
desenvolvedores e cria-se uma cultura positiva,
na qual todo mundo espera que o projeto tenha
êxito.
Scrum https://cysneiros.com.br/metodologias-ageis-produtividade-empresa/
Quando aplicar uma
metodologia ágil
• Geralmente é indicado para
• Produtos novos
• Produtos de pequeno/médio porte
• O cliente está disposto a participar
ativamente do desenvolvimento
• Não há muita dependência de
elementos externos (leis, regras,
regulamentos) que afetam o
desenvolvimento do software
• Equipes pequenas e integradas
Quando uma metodologia ágil
não é indicada
• Sistemas de grande porte
• Sistemas críticos, onde uma análise completa do problema
é necessária
• Equipes grandes ou distribuídas geograficamente
• Manutenção e/ou extensão de software
• O cliente não pode estar muito envolvido com o
desenvolvimento
• Passa a especificação e recebe o produto
• Depende de regulamentações externas que não mudam
com frequência (requisitos estáveis)
Quando uma metodologia ágil
não é indicada
• Sistemas de grande porte
• Não é possível focar apenas no código do software, o projeto,
planejamento do todo é essencial.
• A arquitetura do software todo deve ser pensada antes
(software complexo)
• Aspectos críticos do sistema devem ser documentados
• Definir esquemas de banco de dados
• Definir conexão com outros sistemas
• Descrever a divisão do trabalho em equipe
• Estes indicativos não são elementos que impossibilitam a
aplicação de métodos ágeis
• Há relatos de sucesso na utilização destes métodos em
sistemas com as características apontadas acima
• Geralmente adaptações e ajustes devem ser aplicados
em cada caso.
 Sommerville, Ian. Engenharia de
Software. 10ª Edição. Pearson.
https://plataforma.bvirtual.com.br
/Acervo/Publicacao/168127
Capítulo 3
Capítulo 4