Aula 13 - Engenharia I - segunda - matutino

Prévia do material em texto

Centro Universitário FMU
Disciplina: 
Engenharia de Software I
Aula 13v
Bacharelado em Ciência da Computação
Tecnologia em Análise e Desenvolvimento de Sistemas
Prof.: Celso Eduardo Guimarães
celso.guimaraes@fmu.br
É um ramo da engenharia com foco em desenvolver 
sistemas de software de Alta Qualidade e Custos 
Adequados
O QUE É???
Engenharia de Software
Camadas da Engenharia de 
Software
Engenharia de Software
retomando...
A Engenharia de Software está relacionada a todos os 
aspectos do software.
O software envolve os programas de 
computador e a documentação
A diferença para Ciência da Computação é que a 
engenharia está relacionada com a parte prática de 
desenvolvimento de software
Definindo Software
(1) instruções (programas de computador) que, quando executadas, 
fornecem características, funções e desempenho desejados; 
(2) estruturas de dados que possibilitam aos programas manipular 
informações adequadamente; e 
(3) informação descritiva, tanto na forma impressa como na virtual, 
descrevendo a operação e o uso dos programas.
Pressman
Software não é apenas o pgm do computador, mas também toda a 
documentação associada e os dados de configuração necessários para fazer 
com que esses programas operem corretamente.
Sommerville
Software é desenvolvido ou passa por um processo de engenharia; ele não é 
fabricado no sentido clássico.
Ferramentas CASE
Ferramentas CASE (do inglês Computer-Aided Software Engineering
“Engenharia de Software Auxiliada por Computador”) 
➔ é uma classificação que abrange todas ferramentas baseadas em 
computadores que auxiliam atividades de engenharia de software, desde 
análise de requisitos e modelagem até programação e testes.
❑FERRAMENTAS CASE podem ser utilizadas para gerar um esboço 
do programa, a partir de um projeto. 
❑ → Em alguns casos o programador precisa somente acrescentar detalhes 
da operação de cada componente do programa.
Estão para o Engenheiro de Software assim como o CAD está para a 
Engenharia Civil
Ferramentas CASE
Ferramentas CASE
➢ Uma ferramenta CASE é um aplicativo que auxilia os 
profissionais envolvidos na tarefa de produzir sistemas. 
➢ O tipo de “ajuda” que a ferramenta fornece, depende
exclusivamente da proposta do fabricante.
➢ Um dos componentes indispensáveis de uma ferramenta CASE
é a modelagem visual, ou seja, a possibilidade de representar,
através de modelos gráficos, o que está sendo definido.
✓ Algumas são baseadas na Notação UML.
Demonstração de um software da IBM da sua suíte Rational para Gerenciamento de Requisitos de Software:
https://www.youtube.com/watch?v=BaQOu-7hC88
https://www.youtube.com/watch?v=BaQOu-7hC88
Na elaboração de um produto ou sistema, é importante seguir uma 
série de passos previsíveis — um roteiro que ajude a criar um resultado 
de alta qualidade e dentro do
prazo estabelecido. O roteiro é denominado...
processo de software
(Pressman)
Processo de Software
Processo é um conjunto de atividades, ações e tarefas 
realizadas na criação de algum produto de trabalho 
(work product). 
Processo de Software
Exemplo de 
representação de 
um processo.
Processo seletivo 
de RH
Quem pode me dar um 
exemplo de processo?
Qualquer exemplo...
Processo de Software
Uma ATIVIDADE esforça-se para atingir um objetivo amplo (por 
exemplo, comunicar-se com os interessados) e é utilizada 
independentemente do campo de aplicação, do tamanho do 
projeto, da complexidade de esforços ou do grau de rigor com 
que a engenharia de software será aplicada. 
Processo é um conjunto de atividades, ações e tarefas realizadas na criação 
de algum produto de trabalho (work product). 
Produto de Software
Produto = Resultado → O produto de 2 X 2 é 4
Conjunto completo, ou qualquer dos itens individuais do 
conjunto, de programas de computador, procedimentos, e 
documentação associada e dados designados para liberação para 
um cliente ou usuário final. [PAULK95]
Quando entregamos a um cliente um pacote bem delimitado e 
identificado, podemos dizer que entregamos um produto [SPINOLA98].
Componentes do processo de 
desenvolvimento de software
Atividades ou tarefas definem "o que" e "como" as coisas serão feitas, por 
meio da incorporação de procedimentos, regras, políticas, agentes, papéis e 
artefatos.
As atividades são realizadas pelos agentes, produzem artefatos e utilizam 
recursos.
Toda atividade deve ter claramente definidos seu objetivo, seu início e seu final. 
Exemplos de atividades:
Gerenciamento de projeto.
Teste de código de programa.
Coleta de requisitos.
Comunicação. Antes de iniciar qualquer trabalho técnico, é de vital 
importância comunicar-se e colaborar com o cliente (e outros interessados). 
A intenção é compreender os objetivos das partes interessadas para com o 
projeto e fazer o levantamento das necessidades que ajudarão a definir as 
funções e características do software.
Planejamento. Qualquer jornada complicada pode ser SIMPLIFICADA caso 
exista um mapa. 
O mapa — denominado plano de projeto de software — define o trabalho de 
engenharia de software, descrevendo as tarefas técnicas a ser conduzidas, os 
riscos prováveis, os recursos que serão necessários, os produtos resultantes a 
ser produzidos e um cronograma de trabalho.
Fases no processo de Desenvolvimento de 
Software
Modelagem. Paisagistas, construtores de pontes, engenheiros aeronáuticos, 
carpinteiros, arquitetos, trabalham com modelos todos os dias. 
Cria-se um “esboço” da coisa, de modo que se possa ter uma ideia do todo —
qual será o seu aspecto em termos de arquitetura, como as partes 
constituintes se encaixarão e várias outras características.
Se necessário, refina-se o esboço com mais detalhes, numa tentativa de 
compreender melhor o problema e como resolvê-lo. 
Um engenheiro de software faz a mesma coisa criando modelos 
para melhor entender as necessidades do software e o projeto que 
irá atender a essas necessidades.
Fases no processo de Desenvolvimento de 
Software
Construção. Essa atividade combina geração de código (manual ou 
automatizada) e testes necessários para revelar erros na codificação.
Emprego. O software (como uma entidade completa ou como um 
incremento parcialmente efetivado) é entregue ao cliente, que 
avalia o produto entregue e fornece feedback, baseado na avaliação
Fases no processo de Desenvolvimento de 
Software
Agentes são os executores de um processo, podendo ser um 
indivíduo, um grupo de indivíduos ou uma ferramenta computadorizada.
São entidades também conhecidas como "Atores", e representam um papel 
definido com relação à atividade.
Um agente pode estar relacionado a diversas atividades.
Exemplos de agentes:
Secretária.
Empresa "X".
Gerente.
Componentes do processo de 
desenvolvimento de software
Artefatos: Recurso produzido ou utilizado por uma atividade, ou 
produto criado ou modificado durante um processo.
Podem ser usados como entrada e/ou saída para uma determinada atividade.
Um artefato pode ser associado a diversas atividades e uma atividade pode 
estar associada a diversos artefatos. 
Exemplos de artefatos:
Código fonte dos programas.
Documentos de definição dos sistemas.
Bases de dados criadas.
Componentes do processo de 
desenvolvimento de software
Recursos são entidades estáticas necessárias para executar uma atividade. 
A não utilização ou indisponibilidade de recursos necessários pode causar falha na 
execução da atividade ou até mesmo, impedir sua execução.
Todos os elementos que devem estar presentes para que os objetivos dos processos 
de desenvolvimento, do software desejado, sejam alcançados. 
São considerados os recursos humanos e técnicos.
Exemplo de recursos:
Equipamentos.
Artefatos.
Ferramentas C.A.S.E.
Componentes do processo de 
desenvolvimento de software
Papéis representam um conjunto de responsabilidades, obrigações, 
permissões e habilidades necessárias para executar uma atividade. 
Pode também ser definido como o conjunto de permissões e obrigações 
associadasa um objetivo funcional.
É importante estabelecer quem exerce determinado papel.
Componentes do processo de 
desenvolvimento de software
Na elaboração de um produto ou sistema, é 
importante seguir uma série de passos previsíveis
— um roteiro que ajude a criar um resultado de alta 
qualidade e dentro do
prazo estabelecido. O roteiro é denominado...
processo de software (Pressman)
Modelos de Desenvolvimento de Software
Um modelo de processo de desenvolvimento de software, ou 
simplesmente modelo de processo, pode ser visto como uma 
representação, ou abstração dos processos de software. 
Além disso, oferece uma forma mais abrangente e fácil de representar o 
gerenciamento de processo de software e consequentemente o 
progresso do projeto.
Um modelo deve possuir as características principais do que se quer 
produzir e um conjunto de instruções para o seu desenvolvimento.
Modelo de Processo de Software
Sommerville
É uma descrição simplificada de um 
processo de software, que é apresentada a 
partir de uma perspectiva específica. Os 
modelos, pela sua natureza, são 
simplificações. 
Os modelos tem como objetivo serem “mapas”, fornecendo 
“diretrizes” de como conduzir um projeto de software.
Modelo Cascata
ou ciclo de vida clássico
ou linear sequencial
ou waterfall
Abordagem sequencial sistemática
1. Levantamento de necessidades por parte do cliente
2. Planejamento
3. Modelagem
4. Construção
5. Implementação
6. Suporte Contínuo
(Pressman)
Modelo Cascata
▪ Abordagem sistemática e sequencial
▪ É o paradigma mais antigo da Engenharia de Software
▪ Esse modelo originou-se de outros processos de engenharia
▪ Em princípio, para cada estágio (ou fase) encerrado, há a assinatura de documentos 
(aprovação) → a fase seguinte não deveria iniciar sem essas aprovações. Porém...
... essas fases se sobrepõe e trocam informações entre si. 
Modelo V
Uma variação na representação do modelo 
cascata é denominada modelo V.
À medida que a equipe de software desce em 
direção ao lado esquerdo do V, os requisitos 
básicos do problema são refinados em 
representações progressivamente cada vez mais 
detalhadas e técnicas do problema e de sua 
solução. 
Uma vez que o código tenha sido gerado, a 
equipe se desloca para cima, no lado direito do V, 
realizando basicamente uma série de testes 
(ações de garantia da qualidade) que validem 
cada um dos modelos criados à medida que a 
equipe se desloca para baixo, no lado esquerdo 
do V.
Na realidade, não existe uma diferença fundamental entre o ciclo de vida 
clássico e o modelo V. O modelo V fornece uma forma para visualizar como a 
verificação e as ações de validação são aplicadas ao trabalho de engenharia 
anterior. 
Frequentemente, o cliente define uma série de objetivos 
gerais para o software, mas não identifica, 
detalhadamente, os requisitos para funções e recursos. 
Em outros casos, o desenvolvedor encontra-se inseguro
quanto à eficiência de um algoritmo, quanto à 
adaptabilidade de um sistema operacional ou quanto à 
forma em que deva ocorrer a interação homem/máquina. 
Em situações como essas, e em muitas outras, o 
paradigma de prototipação pode ser a melhor escolha de 
abordagem.
Prototipação
Prototipação
Modelo Espiral
Idealizado por Berry Boehm – é um modelo 
evolucionário também – com ampla natureza 
iterativa (repetitiva) da propotipação com 
aspectos dos sistemas aplicados no modelo 
cascata.
É um modelo para se desenvolver versões 
cada vez mais completas do software.
Modelo Espiral
❑ É dividido em um 
conjunto de atividades 
metodológicas 
definidas pela equipe 
de engenharia de 
software. 
❑ Cada uma dessas 
atividades representa 
um segmento do 
caminho espiral. 
Modelo Espiral
❑ Assim que esse processo 
evolucionário começa, a equipe de 
software realiza atividades 
indicadas por um circuito em torno 
da espiral no sentido horário, 
começando pelo seu centro. 
❑ Os riscos são considerados à 
medida que cada revolução é 
realizada. 
❑ Pontos de controle — uma 
combinação de produtos de 
trabalho e condições que são 
satisfeitas ao longo do trajeto da 
espiral — são indicados para cada 
passagem evolucionária.
Modelo Espiral
❑ As iterações têm uma duração 
típica de seis meses a dois anos. 
❑ Cada fase inicia com um objetivo 
esperado e termina com uma revisão 
pelo cliente do progresso (que deve 
ser interna), e assim por diante...
❑ É uma abordagem realística para o 
desenvolvimento de software de 
grande porte. 
❑ Como o software evolui na medida 
em que o processo avança, o cliente e 
o desenvolvedor entendem melhor e 
reagem aos riscos em cada nível 
evolucionário.
Modelo Incremental
Ele combina elementos dos fluxos lineares e paralelos
(Pressman)
Características:
❑Combina elementos do modelo em cascata com a filosofia iterativa
da prototipação.
❑Aplica sequências lineares de uma forma racional à medida que o 
tempo passa.
❑Cada sequência linear produz um incremento do software e pode 
gerar uma entrega parcial do produto.
❑Os primeiros incrementos são versões simplificadas do produto 
final.
❑O primeiro incremento é chamado de "núcleo do produto" (core).
Modelo Incremental
Modelo Incremental X Evolucionário
Fiquei confuso: Qual a 
diferença entre os dois 
modelos???
A principal diferença é que o incremental sempre libera algo usável. 
Um pedaço completo da foto. 
O evolucionário não necessariamente, as versões vão se tornando 
mais completas. 
Um esboço inicial da foto que vai tomando forma aos poucos.
Modelo RAD
O Rapid Application Development (RAD) é um modelo de processo de software incremental que 
enfatiza um ciclo de desenvolvimento curto. 
O Modelo RAD é uma adaptação, de alta velocidade, do modelo em cascata, no qual a agilidade é 
conseguida com o uso de uma abordagem de construção baseada em componentes.
❑É um modelo de processo de software baseado no 
modelo incremental, visando a construção de 
software orientado a objetos. 
❑Usa como notação de apoio a UML
→ Unified Modeling Language
Processo Unificado
➢O processo é uma tentativa de aproveitar as 
melhores práticas e as melhores características dos 
processos tradicionais.
➢Dedica grande foco em
✓Dar importância à comunicação com o cliente; 
✓Métodos racionalizados (sequenciados) para descrever a visão do cliente sobre um 
sistema – Casos de Uso;
✓Enfatizar a importância do papel da arquitetura de software (ajuda o arquiteto a 
manter o foco nas metas corretas: compreensibilidade, confiança em mudanças 
futuras e reutilização);
✓Sugerir um fluxo de processo iterativo e incremental, proporcionando a sensação 
evolucionária.
Processo Unificado
Rational Unified Process
• É suportado por ferramentas que automatizam
grande parte das atividades de desenvolvimento.
• É processo configurável. 
• Dificilmente um único processo é adequado para o 
desenvolvimento de todos os tipos de software. 
• Ele pode ser ajustado (customizado) para pequenas equipes 
de desenvolvimento bem como para grandes organizações. 
• Captura as melhores práticas de desenvolvimento da Engenharia de 
Software.
Concepção
• O objetivo dessa fase é estabelecer um 
Business Case para o sistema.
• Identifica-se todas as Entidades Externas (inclui 
pessoas e sistemas) que irão interagir com o sistema a 
ser construído, definindo também suas interações.
• As informações são usadas para avaliar a contribuição do sistema 
com o negócios para entendimento da viabilidade do sistema 
(deve-se seguir em frente com o projeto?)
Fases do Processo Unificado
Concepção
• Protótipo pode ser desenvolvido 
para validação do cliente.
• As iterações devem ser definidas quanto: quantidade / objetivos.
• O planejamento identifica RECURSOS, AVALIA RISCOS, define um 
CRONOGRAMA e estabelece uma base para as fases que serão 
aplicadas à medida que o incremento de software é desenvolvido.
Fases do Processo Unificado
Elaboração
• OBJETIVO:
✓ Um modelo de requisitos para o sistema;
✓ Uma descrição de arquitetura;
✓ Um planode desenvolvimento para o 
software.
• Essa fase envolve atividades de planejamento e modelagem.
• Nela devem ser desenvolvidas os casos práticos iniciais levantados na fase 
anterior (concepção). 
• Nessa fase é essencial chegar a um entendimento do domínio do problema.
Fases do Processo Unificado
Elaboração
• Essa etapa amplia a representação da 
arquitetura para o sistema.
• Deve buscar complementar o levantamento (documentação dos 
casos de uso), voltado para a arquitetura do sistema.
• Revisar a modelagem do negócio para os projetos.
• Deve buscar o entendimento de:
-O plano do projeto é confiável?
- Custos são admissíveis?
Fases do Processo Unificado
Construção
• Relacionada principalmente às 
atividades de programação e testes 
do sistema.
• Ao concluir essa fase:
- Deve-se ter um sistema de software em funcionamento e a 
documentação associada pronta para ser liberada para os 
usuários do sistema.
• As partes do sistema são desenvolvidas paralelamente e 
integradas durante essa fase do PU.
Fases do Processo Unificado
Construção
• A fase de construção do PU é idêntica à 
atividade de construção definida para o 
processo de software genérico.
• A entrada para a fase de construção é Modelo de Arquitetura.
• A fase de construção desenvolve ou adquire componentes de software.
• Esses componentes farão com que cada caso prático se torne operacional para os 
usuários finais.
• Os modelos de requisitos e de projeto (iniciados na fase de elaboração), são 
completados para refletir a versão final do incremento de software.
Fases do Processo Unificado
• Ao final dessa fase:
-Deverá ter um sistema de software 
- Documentado
- Funcionando Corretamente
- Documentação e Software devem ser disponibilizados no 
ambiente operacional.
Transição
• Transferência do sistema do “Ambiente 
de Desenvolvimento” para o “Ambiente 
de Produção”.
• Go Live no ambiente real!
Fases do Processo Unificado
Transição
• Essa fase ainda possui os últimos estágios da Construção.
• Entrega-se o software aos usuários finais para testes beta e 
o feedback dos usuários relata defeitos e mudanças 
necessárias.
• Além disso, a equipe de software elabora material com as 
informações de apoio (por exemplo, manuais para o usuário, guias 
para resolução de problemas, procedimentos
de instalação) que são necessárias para lançamento da versão. 
• Na conclusão da fase de transição, o incremento torna-se uma versão 
do software utilizável.
Fases do Processo Unificado
❖ Nesse modelo, é provável que
▪ Ao mesmo tempo em que as fases de construção, transição e 
produção estejam sendo conduzidas.
-Já se tenha iniciado o incremento de software seguinte. 
▪ Isso significa que as cinco fases do PU não ocorrem em sequência, 
mas sim concorrentemente.
Produção
• Durante essa fase
- Monitora-se o uso contínuo do software
- Disponibiliza-se suporte para o ambiente operacional
- Realiza-se e avalia-se relatórios de defeitos e 
solicitações de mudanças.
As duas Dimensões do RUP
❑O processo unificado pode ser descrito 
por duas dimensões, ao longo de dois 
eixos:
• Eixo horizontal representa o tempo e mostra o aspecto dinâmico do 
processo. Ele é expresso em termos de ciclos, fases, iterações e 
marcos. (Fases)
• Eixo vertical representa o aspecto estático do processo. Ele é 
descrito em termos de atividades, artefatos, papéis e fluxos. 
(Disciplinas)
1. Iniciação ou Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.
As fases indicam a 
ênfase que é dada no 
projeto em um dado 
instante.
Disciplinas do RUP
6 Disciplinas de Engenharia de Software
✓Modelagem de Negócios
✓Requisitos
✓Análise e Projeto
✓Implementação
✓Teste
✓Implantação
3 Disciplinas de Apoio / Suporte
✓ Ambiente
✓Configuração e Gerência de Mudança
✓Gerência de Projeto
Disciplinas do RUP
Modelagem de Negócios
❑ O objetivo é estabelecer uma melhor compreensão e um canal de comunicação 
entre engenharia de negócios e a engenharia de software.
o Significa que os engenheiros de software devem compreender a estrutura e a 
dinâmica da empresa alvo (o cliente)
- Atuais problemas na organização e possíveis melhorias. 
o Os engenheiros de software também devem garantir um entendimento 
comum da organização-alvo entre os clientes, usuários finais e 
desenvolvedores.
Os processos de negócio são modelados usando 
Casos de Uso de Negócios
Disciplinas do RUP
Requisitos
❑ Esta disciplina explica como levantar pedidos das partes 
interessadas e transformá-los em um conjunto de requisitos que os 
produtos funcionam no âmbito do sistema a ser construído e 
fornecem requisitos detalhados para o que deve fazer o sistema.
Os agentes que interagem com o sistema são 
identificados e os Casos de Uso são desenvolvidos 
para modelar os requisitos do sistema
Disciplinas do RUP
Análise e Projeto
❑ O objetivo da análise e projeto é mostrar como o sistema vai 
ser realizado. Provar que o sistema:
✓Executará as tarefas e funções projetadas.
✓Satisfará os requisitos estabelecidos.
✓Será robusto e ameno a mudanças.
Um modelo de projeto é criado e documentado usando 
modelos de arquitetura, modelos de componentes, 
modelos de objeto e modelos de sequência.
Disciplinas do RUP
Implementação
❑ Os objetivos são:
✓Organizar o código em subsistemas, camadas, componentes, pacotes.
✓ Implementar classes e objetos em termos de componentes. 
✓ Testar unitariamente os componentes desenvolvidos. 
✓ Integrar resultados, produzindo um sistema executável.
❖Os componentes são implementados e estruturados em subsistemas 
de implementação.
❖A geração automática de código com base nos modelos de projetos 
ajuda a acelerar esse processo.
❖Despende-se esforço na organização e reutilização de componentes.
Disciplinas do RUP
Teste
❑ O RUP propõe uma abordagem iterativa, o que significa que 
deve-se testar durante todo o projeto.
✓ Isto permite encontrar defeitos tão cedo quanto possível, 
o que reduz radicalmente o custo de reparar o defeito.
O teste é um processo iterativo realizado em 
conjunto com a implementação.
Disciplinas do RUP
Implantação
❑ As diretrizes para a implantação é de produzir com sucesso 
lançamentos de produtos e entregar o software para seus usuários finais. 
Cobre:
✓Produção de releases externos do software
✓Embalagem do software e aplicativos de negócios
✓Distribuição do software
✓Instalação do software e prestação de ajuda
✓Assistência aos usuários.
Uma versão é criada, distribuída aos usuários e 
instalada no local de trabalho.
Disciplinas do RUP
Configuração e Gerência de Mudança
❑ Gerenciamento de configuração: A gestão de configuração é responsável pela 
estruturação sistemática dos produtos. 
✓Artefatos, como documentos e modelos, precisam estar sob controle de versão
e essas alterações devem ser visíveis. 
✓Ele também mantém o controle de dependências entre artefatos para que 
todos os artigos relacionados sejam atualizados quando são feitas alterações
❑ Gerenciamento de solicitações de mudança: Durante o processo de 
desenvolvimento de sistemas com muitos artefatos existem diversas versões. 
❑Gerenciamento de status e medição: As solicitações de mudança são controladas, 
assim como seus atributos e a causa raiz, prioridade, etc. Esses estados e atributos 
são armazenados no banco de dados para produzir relatórios úteis sobre o 
andamento do projeto.
Disciplinas do RUP
Gerência de Projetos
❑ No RUP, a Gerência de Projetos concentra-se principalmente em: 
✓Balancear objetivos conflitantes dos envolvidos, superando problemas e 
entregando, de forma bem sucedida, um produto que satisfaz a necessidade de 
clientes e usuários. 
✓Fornecer um suporte para gerenciar projetos de software e gerenciamento de 
risco. 
✓Fornecer diretrizes práticas para planejar, montar a equipe, executar e monitorar 
os projetos.
❑ Esta disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento de 
projetos.
✓Não abrangequestões como: Gestão de Pessoas: Custos, Contratos, etc
Disciplinas do RUP
Ambiente
❑ O foco são nas atividades necessárias para configurar o processo para um projeto. 
❑ Ele descreve as atividades necessárias para desenvolver as diretrizes de apoio a 
um projeto. 
❑ Tem como finalidade fornecer e garantir o ambiente adequado para a 
organização, através de ferramentas e processos capazes de suportar as atividades 
da equipe de desenvolvimento.’
Essa disciplina está relacionado à disponibilização 
de ferramentas apropriadas de software para a 
equipe de desenvolvimento
Os 5 principais Elementos do RUP
Além das disciplinas, o RUP traz outros 4 elementos 
considerados como principais.
Os 5 elementos principais do RUP:
• Papéis (perfil) 
• Atividades
• Artefatos
• Fluxos de Trabalho
• Disciplinas
Papéis 
▪ Define um conjunto de responsabilidades em termos das 
atividades que esse papel pode realizar. 
▪ Pode ser desempenhado por um indivíduo ou um conjunto de 
indivíduos trabalhando como uma equipe.
▪ Ele define o comportamento e as responsabilidades de um 
indivíduo ou grupo num trabalho em equipe.
▪ Os papéis não são indivíduos e nem cargos ou funções→ um 
indivíduo pode ter vários papéis. 
Os 5 principais Elementos do RUP
Papéis 
▪ Exemplos:
• Analista de sistema: coordena o levantamento dos requisitos e a modelagem 
dos casos de uso, identificando funções do sistema e estabelecendo o escopo 
deste.
• Projetista: define responsabilidades, operações, atributos, relacionamentos de 
uma ou mais classes e determina como devem ser ajustadas para serem 
implementadas no ambiente.
• Projetista de testes: responsável pelo planejamento, projeto, implantação e 
avaliação de testes, incluindo a geração de plano e modelo, implementando 
procedimentos para os testes e avaliando a abrangência e profundidade dos 
testes.
Os 5 principais Elementos do RUP
Os 5 principais Elementos do RUP
Atividades 
• Uma atividade é uma unidade de trabalho que um indivíduo executa quando está 
exercendo um determinado papel.
• É descrita por seus passos e artefatos de entrada e saída. 
• Exemplos:
✓Planejar uma iteração: realizada pelo papel gerente de projeto.
✓Encontrar casos de uso e atores: realizada pelo papel analista de sistemas.
✓Rever o projeto: realizada pelo papel revisor de projeto.
✓Executar um teste de performance: realizado pelo papel testador de performance.
Os 5 principais Elementos do RUP
Artefatos
• É um trecho de informação que é produzido, modificado ou utilizado em 
um dado processo, sendo produzido durante o desenvolvimento deste.
• Podem ser usados como entradas de atividades e podem ser produzidos 
como saída.
• Exemplos 
✓Modelo: como um modelo de caso de uso, um modelo de projeto.
✓Elemento de um modelo: como uma classe, um caso de uso, um 
subsistema.
✓Documento: como um caso de negócio, glossário, visão.
✓Código fonte.
✓Executável.
Os 5 principais Elementos do RUP
Fluxos de Trabalho (Workflows)
• Determina a sequência do desenvolvimento das 
atividades para que possam ser produzidos artefatos de 
valor.
• É uma sequência de atividades que são executadas para 
a produção de um resultado. Pode ser representado por 
diagramas de sequência, diagramas de colaboração e 
diagramas de atividades da linguagem UML.
Os 5 principais Elementos do RUP
Fluxos de Trabalho (Workflows)
• O RUP utiliza três tipos de fluxos de trabalho:
✓Fluxos de trabalho principais, associados com cada 
disciplina.
✓Fluxos de trabalho de detalhe, para detalhar cada 
fluxo de trabalho principal.
✓Planos de iteração, que mostram como a iteração 
deverá ser executada.
Metodologias Ágeis - Introdução
❑Desenvolvendo e ajudando outros a desenvolver software, estamos 
desvendando formas melhores de desenvolvimento. 
Por meio deste 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
• Ano de 2001
• Kent Beck e outros dezesseis renomados desenvolvedores, autores 
e consultores da área de software - batizados de “Agile Alliance”-
“Aliança dos Ágeis” assinaram o “Manifesto para o Desenvolvimento 
Ágil de Software”, que se inicia da seguinte maneira:
O Manifesto Ágil
➢Foram desenvolvidos para sanar fraquezas reais e 
perceptíveis da engenharia de software convencional. 
➢O desenvolvimento ágil oferece benefícios 
importantes, no entanto, não é indicado para todos 
os projetos, produtos, pessoas e situações.
O processo de Software baseado 
em Metodologias Ágeis
➢As condições de mercado mudam rapidamente, as 
necessidades dos usuários finais se alteram e novas 
ameaças competitivas emergem sem aviso. 
➢Em muitas situações, não se conseguirá definir 
completamente requisitos antes que se inicie o projeto. 
➢É preciso ser ágil o suficiente para dar uma resposta ao 
ambiente de fluido negócios.
O processo de Software baseado 
em Metodologias Ágeis
➢Fluidez implica mudanças, e mudanças são caras. 
Particularmente, se forem sem controle e mal 
gerenciadas.
➢ Uma das características mais convincentes da 
abordagem ágil é sua habilidade de reduzir os custos da 
mudança ao longo de todo o processo de software.
O processo de Software baseado 
em Metodologias Ágeis
O processo de Software baseado em 
Metodologias Ágeis
A proposta do modelo ágil é para 
fazer frente aos modelos 
tradicionais, mais prescritivos, que 
possuem certa rigidez.
A engenharia de software ágil combina filosofia
com um conjunto de princípios de 
desenvolvimento. 
O processo de Software baseado em 
Metodologias Ágeis
❑ A filosofia defende:
✓A satisfação do cliente e a entrega de incremental prévio;
✓Equipes de projeto pequenas e altamente motivadas; 
✓Métodos informais;
✓Artefato de engenharia de software mínimos e, acima de tudo, 
simplicidade no desenvolvimento geral.
❑ Os princípios de desenvolvimento:
✓Priorizam a entrega mais que análise e projeto.
✓Também priorizam a comunicação ativa e contínua entre 
desenvolvedores e clientes.
Etapas Envolvidas no 
Método Ágil
As atividades metodológicas básicas permanecem: 
• Comunicação,
• Planejamento, 
• Modelagem, 
• Construção e
• Emprego. 
Entretanto, estas se transformam em um conjunto de tarefas 
mínimas que impulsiona a equipe para o desenvolvimento e para 
a entrega
Agilidade
➢ Consiste em algo mais que uma resposta à mudança
➢Abrangendo a filosofia no manifesto
✓ Ela incentiva a estruturação e as atitudes em equipe→ comunicação mais fácil
― entre membros da equipe, entre o pessoal ligado à tecnologia e o pessoal 
da área comercial, entre os engenheiros de software e seus gerentes.
✓ Enfatiza a entrega rápida do software operacional.
✓Assume o cliente como parte da equipe de desenvolvimento .
✓Trabalha para eliminar a atitude de “nós e eles”
✓ Reconhece que o planejamento em um mundo incerto tem seus limites e que o 
plano (roteiro) de projeto deve ser flexível.
O Processo Ágil
➢ Como criar um processo capaz de administrar a imprevisibilidade?
➢Segundo a filosofia ágil, a resposta está na adaptabilidade do processo.
➢Portanto o processo ágil deve ser adaptável!
➢Deve adaptar incrementalmente:
▪ A equipe ágil precisa de feedback do cliente (de modo que as 
adaptações apropriadas possam ser feitas). 
▪ Um efetivo catalisador para feedback de cliente pode ser um 
protótipo operacional ou parte de um sistema operacional. 
O Processo Ágil
➢ Deve se instituir uma estratégia de desenvolvimento 
incremental. 
➢ Os incrementos de software (protótipos executáveis ou partes 
de um sistema operacional) devem ser entregues em curtos 
períodos de tempo, de modo que as adaptações acompanhem o 
mesmo ritmo das mudanças. 
➢O cliente consegue avaliar o incremento de software 
regularmente, fornecer o feedback necessário para a equipe de 
software e influenciar as adaptações de processo feitas para 
incluir adequadamente o feedback.
Osvalores do Manifesto Ágil:
• INDIVÍDUOS E INTERAÇÃO mais que Ferramentas e Processos
• SOFTWARE FUNCIONANDO mais que Documentação Abrangente
• COLABORAÇÃO COM CLIENTE mais que Negociação de Contratos
• RESPONDER A MUDANÇAS mais que Seguir um Plano
Manifesto Ágil: Princípios
1. Nossa maior prioridade é satisfazer o cliente através 
da entrega rápida e contínua de um software de valor
2. Pessoas de negócio e programadores devem trabalhar 
juntos, diariamente, ao longo de todo o projeto
3. Aceite as mudanças de requisitos, mesmo que numa 
etapa avançada do desenvolvimento
4. Entregue novas versões do software frequentemente
5. O software em funcionamento é a medida primária de 
progresso do projeto
6. Construa projetos com pessoas motivadas. Ofereça a 
elas o ambiente e todo o apoio necessários e acredite 
em sua capacidade de realização do trabalho
Manifesto Ágil: Princípios
7. As melhores arquiteturas, requisitos e projetos 
emergem de equipes auto-organizadas
8. O método mais eficiente e efetivo de distribuir a 
informação para e entre uma equipe de 
desenvolvimento é a comunicação face a face
9. Processos ágeis promovem desenvolvimento 
sustentado
10. A atenção contínua na excelência técnica e num bom 
projeto aprimora a agilidade
11. Simplicidade é essencial
12. Equipes de projeto avaliam seu desempenho em 
intervalos regulares e ajustam seu comportamento de 
acordo com os resultados
O Processo Ágil
❑ Vários modelos de processo foram propostos 
seguindo os princípios das metodologias ágeis, 
como XP e Scrum.
eXtreme Programming 
❑ É considerada a abordagem mais 
amplamente utilizada para o desenvolvimento 
de software ágil.
❑ 5 Valores Básicos da XP
✓Comunicação
✓Simplicidade
✓Feedback
✓Coragem
✓Respeito
1. Comunicação
A XP enfatiza a colaboração estreita, embora informal (verbal), 
ENTRE CLIENTES E DESENVOLVEDORES, o estabelecimento de 
metáforas eficazes para comunicar conceitos importantes, 
FEEDBACK (realimentação) contínuo e evitar documentação 
volumosa como meio de comunicação.
“Os problemas nos projetos invariavelmente recaem 
sobre alguém não falando com alguém sobre algo 
importante”
Kent Beck
eXteme Programming -
Valores Básicos
Metáforas são muito usadas na XP onde os desenvolvedores criam 
elementos dentro do computador para simular outros do mundo real.
A lixeira, a mesa de trabalho, janelas, pastas e outros itens que 
estamos habituados a encontrar no computador, simulam elementos 
do mundo físico e seus respectivos comportamentos.
A XP procura explorar a utilização de metáforas, para que clientes e 
desenvolvedores estabeleçam um vocabulário apropriado para o 
projetode modo a elevar a compreensão mútua.
eXteme Programming - Valores Básicos
2. Simplicidade
A XP restringe os desenvolvedores a projetar apenas 
para as necessidades imediatas, em vez de 
considerarem as necessidades futuras. 
O intuito é criar um projeto simples que possa ser 
facilmente implementado em código. 
Se o projeto tiver que ser melhorado, ele poderá ser 
refatorado mais tarde.
eXteme Programming -
Valores Básicos
3. Feedback
provém de três fontes: 
a) do próprio software implementado,
b) do cliente e 
c) de outros membros da equipe de software. 
Através da elaboração do projeto e da implementação de uma
estratégia de testes eficaz, o software (via resultados de testes) 
propicia um feedback para a equipe ágil. 
A XP faz uso do teste de unidades como sua tática de testes 
primária. 
eXteme Programming -
Valores Básicos
4. Coragem
Kent Beck afirma que a adoção estrita a certas práticas da XP 
exige coragem. 
Coragem, nesse caso, significa disciplina. 
Quando há uma pressão significativa para a elaboração do 
projeto pensando em futuros requisitos...
eXteme Programming -
Valores Básicos
... a maioria das equipes de software sucumbe, argumentando que 
“projetar para amanhã” poupará tempo e esforço no longo prazo
... já uma equipe XP ágil deve ter disciplina (coragem) para 
projetar para hoje, reconhecendo que as necessidades futuras 
podem mudar dramaticamente exigindo, consequentemente, 
substancial retrabalho em relação ao projeto e ao código 
implementado.
eXteme Programming -
Valores Básicos
5. Respeito
É um valor que dá sustentação a todos os demais. 
Membros de uma equipe só irão se preocupar em comunicar-se 
melhor, por exemplo, se importarem uns com os outros.
Respeito é o mais básico de todos os valores!
Se ele não existir em um projeto, não há nada que possa salvá-lo!
Saber ouvir, saber compreender e respeitar o ponto de vista do 
outro é essencial para que um projeto de software seja bem 
sucedido!
eXteme Programming -
Valores Básicos
eXteme Programming
O Processo
✓ Abordagem orientada a objetos como 
paradigma de desenvolvimento preferido.
✓ Envolve um conjunto de regras e práticas 
constantes no contexto de quatro 
atividades metodológicas: 
1. Planejamento,
2. Projeto, 
3. Codificação e 
4. Testes
eXteme Programming
O Processo
XP – Fases: Planejamento
❑ Ouvir
 conduz à criação de um conjunto de 
“histórias” (histórias de usuários)
Histórias de Usuários: descreve o resultado, as características e 
a funcionalidade requisitados para o software a ser construído. 
O Jogo do planejamento: se inicia com a atividade de ouvir...
É uma atividade de levantamento de requisitos que capacita os membros técnicos 
da equipe XP a entender o ambiente de negócios do software e possibilita que se 
consiga ter uma percepção ampla sobre os resultados solicitados, fatores principais 
e funcionalidades.
XP – Fases: Planejamento
Clientes + desenvolvedores trabalham juntos 
✓ Decidem como agrupar histórias para a versão seguinte (próximo incremento) a ser 
desenvolvida pela equipe XP.
✓Chega-se a um compromisso básico 
• quais histórias serão incluídas,
• data de entrega e
• outras questões de projeto
✓ A equipe XP ordena as histórias a serem desenvolvidas em uma das três formas: 
1) Todas serão implementadas imediatamente – em um prazo de poucas semanas,
2) As histórias de maior valor serão deslocadas para cima no cronograma e implementadas 
primeiro ou
3) As histórias de maior risco serão deslocadas para cima no cronograma e implementadas 
primeiro.
XP – Fases: Planejamento
✓Primeira versão (incremento) entregue...
... a equipe calcula a velocidade do projeto de forma simples...
... a velocidade do projeto é o número de histórias de clientes 
implementadas durante a primeira versão.
Dessa forma:
▪ É possível calcular as datas para as próximas entregas e o 
cronograma do projeto;
▪ Determinar se foi assumido um compromisso exagerado.
XP – Fases: Planejamento
Conforme o trabalho de desenvolvimento prossegue...
...o cliente pode acrescentar histórias...
...mudar o valor de uma existente...
...dividir algumas ou eliminá-las... 
...em seguida...
...a equipe XP reconsidera todas as versões remanescentes 
e modifica seus planos.
XP – Fases: Projeto
✓Princípio KIS ➔ Keep It Simple preserve a simplicidade
✓Se um difícil problema de projeto for encontrado como 
parte do projeto de uma história, a XP recomenda a criação 
imediata de um protótipo operacional dessa parte do 
projeto.
 Como em outros modelos de processos de 
desenvolvimento de software, é a fase de design 
(modelagem), transformando os requisitos (histórias) em 
documentos que o programador consegue entender. 
➢ Só que seguindo o princípio KIS.
XP – Fases: Codificação
✓Conceito Chave: Programação em Pares
✓A XP recomenda que duas pessoas trabalhem juntas em uma mesma estação de trabalho 
para criar código para uma história. 
✓ Isso fornece um mecanismo para resolução de problemas em tempo real → duas cabeças 
normalmente funcionam melhor do que uma ☺ e garantia da qualidade em tempo real na 
medida em que o código é revisto à medida que é criado
✓ Ele também mantém os desenvolvedores focados no problema em questão. 
✓ Na prática, cada pessoa assume um papel ligeiramente diferente. 
❖ Por exemplo, uma pessoa poderia pensarnos detalhes de codificação de determinada 
parte do projeto...
... enquanto outra assegura que padrões de codificação (uma parte exigida pela XP) sejam 
seguidos ou que o código para a história passará no teste de unidades desenvolvido para 
validação do código em relação à história.
XP – Fases: Testes
✓ Antes de começar a codificar, são feitos testes unitários.
▪ Exercita-se cada uma das histórias a serem incluídas na versão corrente.
✓ Os testes de unidade criados devem ser implementados usando-se uma 
metodologia que os capacite a ser automatizados (podendo ser executados fácil e 
repetidamente).
Cada vez que um novo incremento é acrescentado, novos caminhos de fluxo de dados 
são estabelecidos - podem ocorrer novas entradas e saídas e nova lógica de controle é 
chamada.
teste de regressão é a reexecução do mesmo subconjunto de testes que já foram 
executados para assegurar que as alterações não tenham propagado efeitos colaterais 
indesejados.
➢As iterações são curtas. As mudanças devem ser incrementais 
e feitas aos poucos.
➢Os planejamentos de release e das iterações são feitos com 
base na história dos usuários e conta com a colaboração de 
toda a equipe de desenvolvimento, inclusive o cliente. 
➢Tais histórias descrevem cenários com situações de utilização 
que os envolvidos gostariam que o sistema viesse a oferecer.
➢A princípio, devem ser escritas pelos próprios usuários. 
➢No XP, elas substituem longos documentos de requisitos dos 
métodos tradicionais. São a base para a criação de estimativas 
de tempo que serão utilizadas nas reuniões de planejamento 
de entregas (releases).
eXteme Programming - RESUMO
➢Cada história deve levar de 2 a 3 semanas para ser 
implementada em uma iteração individual. 
➢Se levar mais do que isso, é necessário que seja dividida em 
duas ou mais.
➢No final de um release, é feita uma determinação rápida do 
escopo do próximo, através da combinação de estimativas e 
prioridades do negócio.
➢Um release consiste de várias iterações e, em cada iteração, 
várias histórias são implementadas.
➢Os programadores estimam cada história e dizem quantas eles 
podem implementar no final do release.
eXteme Programming - RESUMO
➢Os clientes escolhem as principais histórias, que serão 
implementadas - as que agregam > valor p/negócio.
➢No XP, faz-se uso de metáforas, com a intenção de 
oferecer uma visão geral do sistema de uma forma 
simples e que possa ser compartilhada por clientes e 
programadores.
➢Utiliza-se a refatoração com constantes melhorias no 
projeto do software para se adaptar a mudanças.
➢Semana de trabalho dos envolvidos é de 40 horas - o 
cansaço e a insatisfação de trabalhar horas extras pode 
levar a uma queda da qualidade do código.
eXteme Programming - RESUMO
➢Esta metodologia prega a utilização de 
padrões de codificação, ou seja, que 
todos os programadores programem da 
mesma forma, facilitando o 
entendimento do código e as alterações 
realizadas. Fortificando o princípio da 
propriedade coletiva do código.
➢Basicamente, um projeto XP passa 
pelas fases de exploração, planejamento 
inicial, iterações do release, produção, 
manutenção e morte.
eXteme Programming - RESUMO
SCRUM
❖ O nome Scrum refere-se a uma jogada do Rugby, na qual os jogadores 
dos dois times entram em uma formação para disputar a bola. 
Caso um dos jogadores caia, o time inteiro é prejudicado, pois a formação 
perde a sustentação. 
Esse é o conceito principal por trás do Scrum, a interdependência entre 
todos os componentes do time.
❑ Os projetos são dividos em ciclos 
✓Tipicamente Mensais
✓Chamados de Sprints. 
 O Sprint representa um incremento para o novo software 
 Um Sprint é a unidade básica de desenvolvimento em Scrum. 
 Sprint é um esforço dentro de uma faixa de tempo (ou seja, restrito a 
uma duração específica) de comprimento constante → normalmente 1 
mês.
SCRUM
❑ No início de cada incremento (sprint) é realizada uma reunião de planejamento de 
incremento (Sprint Planning Meeting)
❑ Nessa reunião o dono do produto (Product Owner) informa os requisitos do produto.
❑ Esse conjunto de requisitos do produto (software) é conhecido como Product
Backlog.
❑ Após a definição pelo Product Owner (na reunião) que ele quer que sejam feitos, a 
equipe Scrum (Scrum Team) seleciona as tarefas que são possíveis de se realizar durante 
o próximo incremento.
SCRUM
SCRUM
❑ Os requisitos definidos na reunião pelo Product Owner são então movidas do 
Product Backlog para o Backlog do Sprint. 
❑ A execução de cada sprint deve terminar dentro do "quadro de tempo" previsto. 
❑Se não for possível implementar todos os requisitos contidos no backlog daquele 
sprint, eles são colocados de volta no backlog do produto.
❑ Em cada sprint há a realização de reuniões 
diárias, denominadas Scrum Diário (Daily Scrum, 
Daily Meeting ou ainda Stand up Meeting).
❑ Essas reuniões são importantes, pois ajudam a 
equipe a manter o foco. 
❑ É onde cada participante descreve o que foi 
feito no dia anterior, o que deve ainda ser 
realizado e que o impedem de avançar.
SCRUM
❑ No final de cada sprint, a equipe apresenta a funcionalidade concluída, na 
denominada reunião de revisão do incremento (Sprint Review Meeting), também 
conhecida como Reunião de Retrospectiva de Sprint.
SCRUM
❑ Principais Características
✓ As equipe se auto organizam para maximizar os trabalhos e diminuir a supervisão 
→ São normalmente de pequenas à médias.
✓O Scrum trabalha com ciclos curtos de desenvolvimento e entrega de software →
o feedback sobre o resultado é obtido rapidamente, colaborando com a qualidade 
do produto.
✓Todos os responsáveis pelo resultado devem ter a visão de tudo o que está 
acontecendo, além de um mesmo entendimento do que está sendo visto.
✓Os artefatos e o progresso em direção ao objetivo devem ser inspecionados 
frequentemente por todos os usuários do Scrum, de maneira a detectar desvios 
indesejáveis.
✓Não há prática de Engenharia de Software prescrita, mas é comum utilizar a XP.
SCRUM
❑ Papéis e Responsabilidades
✓ Product Owner Representante dos usuários (clientes)
▪ Auxilia a determinar a direção do produto (prioriza requisitos)
▪ Ajuda a ter certeza de quais requisitos serão necessários para o Product Backlog
▪ Na verdade, o PO representa o cliente dentro do time Scrum. 
– Alto grau de envolvimento do cliente representa mais assertividade. 
– Normalmente o cliente não pode estar disponível para o Time de 
Desenvolvimento toda vez que seja necessário tirar uma dúvida ou validar um 
requisito. 
– Por isso esse papel no Scrum cabe ao Product Owner.
SCRUM
❑ As principais tarefas do Product Owner são (em resumo):
✓Manter o Product Backlog;
✓ Aceitar ou rejeitar o trabalho;
✓ Priorizar os requisitos;
✓ Auxiliar o Time durante a execução do trabalho;
✓ Auxiliar o cliente na descoberta de novos requisitos;
✓ Ser o centralizador de demandas;
➢Caso o Product Owner não possua alguma informação necessária, é papel dele realizar 
esse levantamento junto ao cliente.’’
SCRUM
❑ Papéis e Responsabilidades
✓ Scrum Master O Scrum Master ou SM é o Mestre do time Scrum.
▪ Não é um gerente, uma vez que o time Scrum é autogerenciável.
▪ Seu trabalho é garantir que o projeto do produto esteja evoluindo.
▪ Deve garantir que cada membro do time tenha as ferramentas para realizar 
seus trabalhos.
▪ Organiza reuniões, monitora o trabalho e facilita o desenvolvimento do 
release.
SCRUM
❑ Outros envolvidos
✓Time de desenvolvimento
✓ Testadores
✓ Clientes
✓ Executivos
SCRUM
❑ Defect Backlog
✓É uma lista de bugs que vão surgindo durante a execução do 
projeto.
✓São classificadas de acordo com as características do defeito 
encontrado.
✓É comum planejar um sprint especial somente para tratar 
exclusivamente dos bugs.
SCRUM
SCRUM
❑ Retrospectiva da Sprint (Sprint Retrospective)
Todos os membros da equipe refletem sobre a 
sprint passada.
✓A ideia é providenciar melhorias contínuas de 
processos.
✓Duas questões principaissão feitas na 
retrospectiva do sprint: 
➢ O que correu bem durante a corrida? 
O que poderia ser melhorado na próxima sprint?
O Kanban➔Pull Systems (sistemas de produção puxados)
A maioria das indústrias utilizavam o conceito de Push Systems (sistemas de 
produção empurrada). 
Um sistema de produção empurrada se caracteriza por iniciar a produção antes 
de ocorrer uma real demanda, ou seja, o processo recebe uma ordem de 
produção e executa, empurrando o resultado da operação atual para a 
operação seguinte. 
Um sistema de produção puxado se caracteriza por iniciar a produção quando 
um item é vendido, gerando demanda para a fabricação de outro, assim cada 
operação do processo é alimentada pela demanda da etapa anterior.
Esse é um quadro básico, você pode incluir as colunas que 
necessitar para o seu projeto.
https://www.youtube.com/watch?v=5_zQRdWR8FY
https://www.youtube.com/watch?v=5_zQRdWR8FY
Conceitos: 
Buffer = fila.
Priorização = observe que os defeitos estão sempre acima, ou seja, os primeiros a entrarem em progresso 
(WIP) na fila.
Limite WIP: Número máximo de trabalho em andamento em cada etapa do processo.
Conceitos: 
Raias: Swimlanes
Controle de demanda → cada raia é um fluxo é distinto do outro. Perceba que as raias são totalmente diferentes, por 
exemplo, na coluna “Fazer” a raia de cima possui um limite WIP de 3 cartões enquanto a raia abaixo possui um limite 
WIP de 6 cartões. As raias foram divididas por tipo de item (BUGS e TAREFAS), porém, você pode dividir de acordo a sua 
necessidade, podendo optar também por classe de serviço, prioridade ou tamanho.
MAS COMO SABER QUANTO PODEMOS DESENVOLVER 
DENTRO DE UMA SPRINT???
➢ O Scrum não define uma maneira como os requisitos devem ser escritos e, 
consequentemente, uma maneira como os requisitos devem ser estimados.
➢ A maioria dos times Scrum usa histórias de usuário, e as estimam utilizando a técnica 
de Pontos de História.
Já sei, já sei, você não 
lembra ou ainda não 
entendeu o que são...
HISTÓRIAS DE 
USUÁRIO
https://www.youtube.com/watch?v=sEtiCJfXTE8
https://www.youtube.com/watch?v=sEtiCJfXTE8
MAS COMO SABER QUANTO PODEMOS DESENVOLVER 
DENTRO DE UMA SPRINT???
➢ O Scrum não define uma maneira como os requisitos devem ser escritos e, 
consequentemente, uma maneira como os requisitos devem ser estimados.
➢ A maioria dos times Scrum usa histórias de usuário, e as estimam utilizando a técnica 
de Pontos de História.
➢ Um ponto de história nada mais é do que uma unidade de tamanho, que faz sentido 
para o time Scrum e indica se a história é grande ou pequena.
➢ Por exemplo: uma história muito simples de ser implementada, para o time, poderá ter 
o tamanho 1. Consequentemente, uma história com o dobro de complexidade da 
primeira terá o tamanho 2.
https://www.youtube.com/watch?v=dP8VD2DWiVoPlanning POKER ➔
https://www.youtube.com/watch?v=dP8VD2DWiVo
HÁ VARIAÇÕES NO BARALHO. EIS UM EXEMPLO QUE PODE SER UTILIZADO
? (interrogação): Significa que o membro não se 
sente confiante para atribuir um valor a tarefa;
0 (zero): Significa que a tarefa é absolutamente 
desnecessária e deveria ser descartada;
0.5 (meio): Significa que a tarefa necessita de uma 
pequeno esforço para ser concluída;
… (infinito): Significa que a tarefa é extremamente 
importante;
Xícara de café: Significa uma pausa para refletir 
antes de tomar a decisão. Esta pausa é importante e 
deve ser respeitada quando solicitada, é muito 
provável que os membros não abusem dela.
por que Fibonacci?
Se utiliza Fibonacci devido aos “saltos” que se tem entre os números, esse espaços entre 
eles é o que vai medir a incerteza de uma estimativa e também retirar as pessoas de irem 
no número do meio.
Quando o time está estimando itens menores de tamanho como 1, 2 e 3, a assertividade 
da estimativa tende a ser enorme. Pelo fato do item ser pequeno ele se torna mais simples 
de se ter o total entendimento.
Se o item está entre 5 , 8 e 13, perceba que existe um salto grande do 8 para o 13. Esse 
salto é justamente para provocar a discussão entre as pessoas, e evitar que escolham por 
exemplo, o tamanho 10, que nada mais é que o meio termo entre 8 e 13.
Resumindo, a Sequencia de Fibonacci foi escolhida para o planning poker para tirar as 
pessoas do status comum e discutirem em volta dos itens a serem estimados.
Gráfico Burndown
Geralmente, em uma parte do 
quadro de tarefas encontramos o 
gráfico burndown. 
Ele é utilizado para que se possa 
acompanhar o desempenho do 
time ao longo da sprint.
No eixo X do gráfico encontra-se a 
quantidade de pontos restantes na 
sprint. No eixo Y do gráfico temos a 
quantidade de dias da sprint.
Uma condição ou capacidade necessária para um 
usuário RESOLVER um problema ou alcançar um 
objetivo
REQUISITO DE SOFTWARE
Engenharia de Requisitos
(IEEE)
Engenharia de Requisitos
É o amplo conjunto de TAREFAS e técnicas que levam a um 
entendimento dos requisitos
Fornece o mecanismo apropriado para entender aquilo que o 
CLIENTE deseja
(Pressman)
Durante TODO o ciclo de vida do produto
Quando se preocupar com Requisitos de Software?
Engenharia de Requisitos
O Processo de Engenharia de Requisitos
Sommerville
Engenharia de Requisitos
Levantamento e Análise de Requisitos
Este é o processo de obter requisitos do sistema pela 
observação de sistemas existentes, pela conversa com usuários e 
compradores em potencial e/ou pela análise de tarefas. Pode envolver o 
desenvolvimento de um ou mais diferentes modelos e protótipos de 
sistemas.
✓ Isso ajuda o analista a compreender o sistema a ser 
especificado.
Sommerville
Engenharia de Requisitos
Especificação de Requisitos
É a atividade de traduzir as informações coletadas durante a 
atividade de análise em um documento que defina um conjunto 
de requisitos. Podem ser abstratas (Requisitos dos usuários) ou 
especificações detalhadas ( Requisitos do Sistema).
Sommerville
Requisitos
Funcionais Não Funcionais
– Permitir cadastramento de novos clientes
– Cada NF pode ter, no máximo, 15 itens
– O sistema deverá emitir relatório diário dos 
indicadores de vendas
Testabilidade Confiabilidade
Segurança Manutenibilidade
Desempenho Escalabilidade
Elicitação de Requisitos
• Veja essa ficha cadastral 
de clientes;
• Imagine que a empresa 
faz essas fichas para 
manter um arquivo 
manual de cadastro de 
clientes ( essa empresa 
não tem um sistema 
informatizado); 
• Vamos agora pensar que essa empresa tem as seguintes regras de negócio:
o Para que os clientes façam compras parceladas, é necessário preencher a ficha de 
clientes;
o O vendedor deverá confirmar as informações por meio de documento e fazendo 
uma ligação no local de trabalho do cliente;
o Todas as informações da ficha precisam ser preenchidas.
O QUE SÃO REGRAS DE 
NEGÓCIO???
• Agora vamos pensar em 
desenvolver um sistema 
para esse cliente;
• Vamos considerar as 
regras de negócios como 
requisitos de software (o 
software terá que 
atender a essas 
funcionalidades);
• Poderíamos ainda estabelecer alguns requisitos funcionais:
o No campo cidade deve existir uma lista de municípios para seleção;
Ou melhor....
o Ao preencher o CEP, os campos cidade e endereço sejam preenchidos 
automaticamente (para isso devemos segregar o campo endereço em logradouro, 
número e complemento).
O QUE SÃO REGRAS DE 
NEGÓCIO???
Diferença de Requisito Funcional e Regra de Negócio
A diferença entre requisito funcional e regra de negócio, 
conceitualmente falando, é que o REQUISITO FUNCIONAL refere-se 
à O QUE O SISTEMA DEVERÁ FAZER, enquanto a REGRA DE 
NEGÓCIO refere-se a COMO O SISTEMA DEVERÁ FAZER. 
Do ponto de vista do negócio (negócio do cliente para o qual o 
sistema está sendo feito), ambos são necessidades (requisito 
funcional e Regra de Negócio), mas cada uma com um foco 
diferente.
Concluindo, sempre que tiver dúvida se o que você está 
escrevendo é uma Regra de Negócio ou um Requisito de 
Software, seja funcional ou não funcional, faça esteexercício: Tire o software e veja se o que você está 
escrevendo acontecerá sem ele.
Se sim, é uma regra de 
negócio, se não, é um 
requisito de software.
https://www.youtube.com/watch?v=QyJDkR1Ejt4
https://www.youtube.com/watch?v=QyJDkR1Ejt4
Engenharia de Requisitos
Levantamento e Análise de Requisitos
Este é o processo de obter requisitos do sistema pela 
observação de sistemas existentes, pela conversa com usuários e 
compradores em potencial e/ou pela análise de tarefas. Pode envolver o 
desenvolvimento de um ou mais diferentes modelos e protótipos de 
sistemas.
✓ Isso ajuda o analista a compreender o sistema a ser 
especificado.
Sommerville
TÉCNICAS PARA COLETA DE INFORMAÇÕES
→ Entrevistas
→ Focus Groups (discussões em grupo)
→ Questionários
→ Shadowing (aprendizagem por observação)
→ Instrução dos Usuários
→ Prototipação
FONTES DE REQUISITOS:
→ Stakeholders
→ Documentos
→ Sistemas em Operação
FATORES DE SATISFAÇÃO
→ Básicos
→ Esperados
→ Inesperados
Elicitação de Requisitos
Uma ENTREVISTA é uma reunião individual entre um membro da equipe 
do projeto e um usuário ou um stakeholder
FOCUS GROUP é uma discussão objetiva, conduzida ou moderada que 
introduz um tópico a um grupo de respondentes e direciona sua 
discussão sobre o tema, de uma maneira não-estruturada e natural
QUESTIONÁRIOS consistem em conjuntos de perguntas que são 
criados para reunir informações
INSTRUÇÃO DOS USUÁRIOS: Quando você usar a técnica de instrução dos 
usuários, essas pessoas realmente irão treiná-lo nas tarefas que realizam
Um PROTÓTIPO é uma versão inicial, em geral parcial, de um produto
(ou parte do produto) do projeto
Elicitação de Requisitos
SHADOWING é uma técnica em que você observa um usuário realizar as 
tarefas no seu ambiente de trabalho, e pergunta ao usuário qualquer 
questão relativa às tarefas
O QUE É UM WIREFRAME?
É uma representação de baixa fidelidade do design de um projeto e tem como
principal objetivo mostrar o que podemos chamar de “o quê”, “como” e “onde”:
✓ O quê: quais são os grupos de conteúdo que serão utilizados;
✓ Onde: qual é a estrutura da informação;
✓ Como: como será a visualização básica da interface e como o usuário irá 
interagir com ela;
➢ Devem ser criados num espaço de tempo curto.
➢ Não possuem design bem elaborado e são como se fosse o esqueleto do
design, contendo todas as partes importantes do projeto final.
Primeiro estudo: 
Representa a primeira 
rolagem do site da 
SPTrans destacando as 
tarefas críticas do site.
https://aiuxtrab.wordpress.com/wire-frames-e-prototipo/
Exemplo de Wireframe
https://aiuxtrab.wordpress.com/wire-frames-e-prototipo/
Segundo Estudo (wireframe de 
maior fidelidade)
Detalhamento do primeiro 
estudo, melhoria de rótulos e 
alteração das funções do bloco.
https://aiuxtrab.wordpress.com/wire-frames-e-prototipo/
Exemplo de Wireframe
https://aiuxtrab.wordpress.com/wire-frames-e-prototipo/
Protótipo Aplicação do 
visual semelhante ao do 
site atual visando o menor 
estranhamento possível dos 
usuários
https://aiuxtrab.wordpress.com/wire-frames-e-prototipo/
Exemplo de Protótipo
https://aiuxtrab.wordpress.com/wire-frames-e-prototipo/
Gerenciamento de Requisitos
• Entender os requisitos de um problema está 
entre as tarefas mais difíceis enfrentadas por 
um engenheiro de software.
Gerenciamento de Requisitos
• Entre as dificuldades encontradas na fase de levantamento de requisitos 
estão: 
• O usuário principal do sistema não sabe o que quer que o sistema faça ou sabe e 
não consegue transmitir para o analista; 
• Requisitos identificados, mas que não são realistas e não identificam os requisitos 
similares informados por pessoas diferentes. 
• Um stakeholder errado afetará em perda de tempo e dinheiro para ambas as 
partes envolvidas no desenvolvimento do sistema.
• Fato: Os requisitos de software estão sempre mudando.
• O problema não pode ser definido totalmente de uma vez – os requisitos ficam 
incompletos.
• O entendimento das partes interessadas sobre o problema estão em constante 
mudança.
• Esses requisitos devem refletir as novas visões do problema.
Gerenciamento de Requisitos
▪Já em produção (sistema):
Inevitavelmente novos 
requisitos surgirão.
• Gerenciamento de Requisitos é um processo para compreender e controlar as 
mudanças dos requisitos do sistema.
• É necessário manter o acompanhamento dos requisitos, individualmente e manter 
as ligações entre os requisitos dependentes.
• É importante conseguir avaliar o impacto nas mudanças dos requisitos 
formalmente (documentalmente e seguindo processo pré-definido)
• É necessário estabelecer o Processo de Gerenciamento de Requisitos assim que a 
primeira versão do documento de requisitos é iniciada.
• Ele deve ser mantido durante todo o Ciclo de Vida do Projeto e também durante todo 
o Ciclo de Vida do Software.
Gerenciamento de Requisitos
Modelagem de sistemas
A modelagem de sistemas é o processo de desenvolvimento de 
modelos abstratos de um sistema, de maneira que cada modelo apresenta 
uma visão ou perspectiva diferente do sistema.
Atualmente, a modelagem de sistemas se tornou a representação de 
um sistema usando algum tipo de notação gráfica, que hoje em dia quase 
sempre são baseadas em notações em Unified Modeling Language (UML). 
A modelagem de sistemas ajuda o analista a entender a funcionalidade 
do sistema e os modelos são usados comunicação com os clientes. 
❑ O aspecto mais importante de um modelo de sistema é 
que ele deixa de fora os detalhes. O modelo é uma 
abstração do sistema a ser estudado, e não uma 
representação alternativa dele.
❑ A partir de perspectivas diferentes, você pode 
desenvolver diversos modelos para representar o 
sistema. 
Por exemplo:
Modelagem de sistemas
INTRODUÇÃO À UML
Unified Modeling Language – linguagem de modelagem unificada
É uma linguagem-padrão para descrever e documentar projeto 
de software. 
A UML pode ser usada para visualizar, especificar, construir e 
documentar os artefatos de um sistema de software.
INTRODUÇÃO À UML
Unified Modeling Language
Entendendo o vocabulário da UML (elementos visuais do 
diagrama e seus significados)...
... Poderá entender e especificar um sistema e explicar o 
projeto daquele sistema para outros interessados.
❑ Todo diagrama é constituído de elementos, cada um com um 
propósito, regras e notação diferentes para definir uma situação do 
processo de desenho. 
❑ Embora a maioria dos diagramas seja gráfica, apresentando nós 
relacionados entre si por uma linha, demonstrando uma conexão, o 
relacionamento pode ser expresso na forma de recipiente em que um 
símbolo está contido em outro, ou de anexo, em que um símbolo 
aparece próximo a outro.
Modelagem de sistemas
Modelagem de
Casos de Uso
https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=2ahUKEwjT9fTu-ejhAhW1GLkGHS55D4UQjRx6BAgBEAU&url=https://pt.depositphotos.com/86793544/stock-illustration-use-case-diagram-uml-unified.html&psig=AOvVaw1K1amNo3gSobM-tknqFYeX&ust=1556202726490257
Modelagem de Casos de Usos
(MCU)
❑O Modelo de Casos de Uso (MCU) é uma 
representação das funcionalidades
externamente observáveis ao sistemas e dos 
elementos externos que INTERAGEM com ele.
Modelagem de Casos de Usos
(MCU)
❑O Modelo de Casos de Uso (MCU) é um 
modelo de análise que representa um 
refinamento dos requisitos funcionais 
do sistema em desenvolvimento.
Diagramas de Casos de Uso
A interação do usuário junto ao sistema pode ser 
ilustrada por meio do diagrama de casos de uso. 
Ele representa cada uma das funções do sistema e como 
cada ator interage com elas. 
. Somente para 
requisitos funcionais
Ferramenta UML utilizada na 
modelagem de casos de uso.
Diagramas de Casos de Uso
A interação do usuário junto ao sistema pode ser 
ilustrada por meio do diagrama de casos de uso. 
Ferramenta UML utilizada na 
modelagem de casos de uso.
https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=2ahUKEwiFzsa0_ejhAhWtILkGHbiZC3oQjRx6BAgBEAU&url=https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5&psig=AOvVaw1K1amNo3gSobM-tknqFYeX&ust=1556202726490257Diagramas de Casos de Uso
Depois de identificado os atores é preciso então 
ilustrar os casos de uso em si. Cada um deles se 
tornará uma função dentro do sistema.
Diagramas de Casos de Uso
Diagramas de Casos de Uso
Diagramas de Casos de Uso
Colocamos um geral 
conhecido por fronteira 
de sistema. 
– Esse bloco delimita os 
casos de uso e permite 
identificar todos os que 
serão implementados e 
disponibilizados pelo 
sistema. 
E
x
is
te
m
 v
á
ri
o
s
te
m
p
la
te
s
d
if
e
re
n
te
s
 q
u
e
 p
o
d
e
m
 s
e
r 
u
ti
li
z
a
d
o
s
 p
a
ra
 e
s
te
 f
im
.
E
s
s
e
 é
 s
o
m
e
n
te
 u
m
 e
x
e
m
p
lo
• Nome do caso de uso: deve conter o mesmo nome do caso de uso que está no 
diagrama em questão e que será detalhado;
• Descrição: um resumo da utilidade do caso de uso;
• Ator envolvido: é o ator quem executa o caso de uso, o mesmo do diagrama de 
casos de uso. Em determinadas situações, pode haver mais de um ator envolvido;
• Interação entre o ator e o sistema: descreve os passos envolvidos na realização 
do caso de uso, evidenciando as responsabilidades do ator e do sistema, num 
processo interativo;
• Exceções: indicam situações onde, primordialmente, o tratamento de erros deve 
ser efetuado;
• Alternativas: indicam situações opcionais que podem ocorrer durante o cenário 
que está sendo descrito pelo caso de uso;
• Regras de Negócio: são as regras impostas para a utilização do caso de uso, 
definidas pelo domínio da aplicação;
• Requisitos de Interface com o Usuário: descrevem características que devem ser 
implementadas na interface com o usuário.
Diagrama de Classes
Representa um conjunto de objetos com características afins. Uma classe 
define o comportamento dos objetos através de seus métodos, e quais 
estados ele é capaz de manter através de seus atributos. 
Exemplo de classe: Veículos
Representa a abstração de um conjunto de objetos do mundo real que 
possuem tipos de características e de comportamentos comuns.
Classe
Atributos e Comportamentos Comuns
189
Diagrama de Classes
❑Uma CLASSE é representada por, no máximo, 
três compartimentos.
Nome da Classe Nome da Classe
Lista de Atributos
Nome da Classe
Lista de Operações
Nome da Classe
Lista de Atributos
Lista de Operações
Possíveis notações para uma classe na 
UML
https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=2ahUKEwj6jqaVyYziAhUiIbkGHflLA_4QjRx6BAgBEAU&url=https://pt.slideshare.net/daniballester/modelagem-de-sistemas-de-informao-08-diagrama-de-classes&psig=AOvVaw2Wp1EE_zzsmvRgDD7u0B4s&ust=1557426813097715
➢Na OO a funcionalidade é fornecida por meio de 
colaboração entre objetos.
➢Externamente ao sistema, os atores visualizam 
resultados de cálculos, relatórios produzidos, 
confirmações de requisições realizadas etc.
➢internamente, os objetos dos sistemas colaboram uns 
com os outros para produzir os resultados visíveis fora.
Diagrama de Classes
➢À medida que o sistema é desenvolvido, o modelo de classes é 
incrementado com novos detalhes. Há 3 estágios de abstração 
sucessivos pelos quais o modelo de classes passa:
✓Modelo de classes de análise
✓Modelo de classes de especificação
✓Modelo de classes de implementação
Modelo de Classes
✓Modelo de classes de análise
Focamos a atenção em “o que” o sistema deve fazer.
É construído na fase de análise e em geral não leva em 
consideração restrições tecnológicas.
O modelo de casos de uso, juntamente com o modelo de 
classes formam o conjunto principal da fase de análise do 
processo de desenvolvimento de software.
Modelo de Classes
✓Modelo de classes de especificação
É um detalhamento do modelo de classes de análise. É também 
conhecido como modelo de classes de projeto.
Nesse momento descobrimos a necessidade de criar outras classes 
focando a atenção sobre “como” o sistema deverá funcionar.
Modelo de Classes
✓Modelo de classes de implementação
É a implementação da classe em uma linguagem de programação –
normalmente Orientada a Objetos, como Java, C#, C++, etc.
Ele é construído na fase de implementação de um modelo iterativo.
Modelo de Classes
❑Os objetos de uma classes podem se relacionar uns com os 
outros.
❑A existência de relacionamento entre os objetos permitem 
que eles troquem mensagens uns com os outros.
❑Em última análise, relacionamentos entre objetos 
permitem que eles colaborem entre si a fim de produzir 
funcionalidades do sistema.
Diagrama de Classes
❑Podemos representar o relacionamento entre os 
objetos em um Diagrama de Classes.
❑Para isso, existe o elemento na notação conhecido 
como associação.
❑Representa relacionamentos que são formados 
entre objetos durante a execução do sistema. 
Diagrama de Classes
➢ As associações representam ligações 
possíveis entre objetos das classes 
envolvidas na associação.
➢ Durante a execução do programa, haverá 
possibilidade da troca de mensagens entre 
os objetos dessas classes.
Um objeto para a classe Vendedor que esteja 
associado a diversos objetos da classe Pedido.
Classe Associativa
Diagrama de Sequência
Também conhecido 
como Diagrama de 
Mensagens
Ferramenta da UML usada 
para representar a 
interação de um sistema 
orientado a objetos.
Enfatiza a ordem de chamada das operações 
em uma determinada situação do sistema em 
função do tempo.
➢ Projeto pode ter uma grande 
quantidade de métodos em 
classes diferentes
> É difícil determinar a 
sequência global do 
comportamento. 
➢ O diagrama de sequência 
representa essa informação.
Diagrama de Sequência
Exemplo
➢ Ele procura determinar a 
sequencia de eventos que 
ocorrem em um determinado 
caso de uso.
➢ Quais operações devem ser 
disparadas entre os objetos 
envolvidos e em qual ordem
(sequência) para a realização 
completa do caso de uso.
Diagrama de Sequência
Exemplo
➢ Ele procura determinar a 
sequencia de eventos que 
ocorrem em um determinado 
caso de uso.
➢ Quais operações devem ser 
disparadas entre os objetos 
envolvidos e em qual ordem
(sequência) para a realização 
completa do caso de uso.
Diagrama de Sequência
Baseia-se nos 
diagramas de 
classes e casos 
de uso
Esteriótipos
Ator: representa um usuário ou 
outro sistema interagindo com o 
sistema.
Esteriótipos
Interface: Classe que fará a troca de 
mensagens com o ator. 
Caso esse ator seja uma pessoa, 
esse será a classe que 
representará a interface gráfica 
daquela sequência que está 
sendo desenhada.
Esteriótipos
Controle: Essa é a classe que possuirá 
a lógica de negócio do sistema para a 
sequência modelada.
Esteriótipos
Entidade: Essa classe é conhecida 
por armazenar o conteúdo das 
entidades que estão sendo tratadas 
por aquele sistema.
Lifelaine
ou 
Linha de Vida
Um retângulo magro 
indica o período em 
que o objeto está 
participando 
ativamente do 
processo
DIAGRAMA DE MÁQUINA DE ESTADOS
✓Demonstra a troca de estados 
possíveis de uma classe em 
específico do sistema, através 
da representação dos eventos 
responsáveis pela transição 
entre os estados existentes.
✓O estado significa o período de 
tempo em que o objeto atenda 
a uma condição, realize alguma 
atividade ou espere algum 
evento.
DIAGRAMA DE MÁQUINA DE ESTADOS
✓Esse é um diagrama muito útil para objetos do sistema 
que possuam muitos estados, pois dessa maneira se 
torna simples representar quando cada um dos estados 
do objeto será acionado.
✓É possível representar estados internos existentes 
dentro de um estado específico, de tal forma a deixar 
muito claro todas as transições de situação existentes 
para o objeto que se está modelando.
DIAGRAMA DE MÁQUINA DE ESTADOS
DIAGRAMA DE MÁQUINA DE 
ESTADOS
• Nesse exemplo: Representa os 
estados possíveis de uma 
reclamação.
DIAGRAMA DE 
ATIVIDADES
• Mostra a lógica de 
execução, em passo-a-
passo, de uma ação do 
sistema.
DIAGRAMA DE 
ATIVIDADES
❑É pertinente utilizá-lo quando o propósito é:
✓Documentar o aspecto funcional (não estrutural)do 
software, quando é necessário representar o fluxo da 
informação que o software trabalhará, e quando 
existam condições/decisões que precisam 
detalhadas/descritas.
✓Mostrar aspectos específicos de alguma rotina do negócio 
que será automatizada pelo software, como um “zoom” em 
parte de alguma funcionalidade, por exemplo.
Fluxos Simultâneos
❑ Cada uma das áreas 
organizacionais representa 
um papel dentro da execução 
do processo. 
❑ As atividades ocorrem sob a 
responsabilidade de algum 
desses papéis.
Arquitetura de Sistemas
Arquitetura em pequena escala (software)
X
Arquitetura em larga escala (sistemas distribuídos).
Arquitetura em pequena escala (software).
▪ Vamos a alguns exemplos de arquitetura em larga escala.
▪ Pense que estamos representando a arquitetura dos 
sistemas, ou seja, de como os sistemas operam 
(comunicam-se) entre si.
▪ Vamos entender primeiro o conceito cliente/servidor...
Arquitetura cliente/servidor 2 camadas
Todo o aplicativo está instalado e processando nos clientes (users)
Possibilita o compartilhamento dos bancos de dados entre clientes em tempo real.
❑Modelo multicamadas
❑ Também conhecido como modelo cliente e servidor de várias camadas, este método é 
uma evolução da tecnologia de duas camadas e tem como princípio básico o fato de 
que a estação cliente jamais realiza comunicação direta com o servidor de banco de 
dados, mas sim com uma camada intermediária, e esta, com o banco de dados. Isto 
proporciona uma série de vantagens sobre a técnica de duas camadas, as quais serão 
explanadas adiante.
❑ Um sistema multicamadas faz uso de objetos distribuídos aliados à utilização de 
interfaces para executar seus procedimentos, o que torna o sistema independente de 
localização, podendo estar tanto na mesma máquina como em máquinas separadas. 
Desta forma, a aplicação pode ser dividida em várias partes, cada uma bem definida, 
com suas características e responsável por determinadas funções. Em um aplicativo 
nestes moldes, pelo menos três camadas são necessárias: apresentação, regras de 
negócios e banco de dados.
Arquitetura 
multicamadas
Arquitetura em larga escala (sistemas distribuídos).
Arquitetura Espaguete:
Consumidores de serviços 
dependem diretamente de 
provedores de serviços.
Um barramento de serviços proporciona 
desacoplamento entre consumidores e provedores 
de serviços, já que os consumidores não conhecem 
diretamente quem está provendo o serviço. 
Alterações em tais provedores de serviços podem 
impactar diretamente o ESB, mas em geral são 
transparentes para os consumidores de serviços. 
Arquitetura em larga escala
Engenharia de Software Orientada a 
Serviços
• O middleware de serviços da Web 
desempenha o papel de "intermediário" na 
arquitetura geral de software.
• A camada de middleware pode tratar de 
coisas como segurança ou comunicações 
entre plataformas.
• Também pode permitir mensagens entre 
diferentes componentes de software. É 
como uma cola conectiva para uma 
estrutura de software maior.
Arquitetura Orientada a Serviços
Web Service
→Serviço implementado para suportar interação 
interoperável, processo a processo, ou máquina a 
máquina através de rede. 
→“Software projetado para ajudar a gerenciar a 
complexidade e a heterogeneidade inerente dos 
sistemas distribuídos” [Bakken 2001]
❑Cada bloco de construção SOA (Web Service) pode desempenhar um ou ambos os 
papéis:
✓Service Provider - O prestador de serviços (provedor) cria um Web Service e, 
eventualmente publica sua interface e acesso à informação para o registro de serviços. 
Cada fornecedor deve decidir quais os serviços irá expor.
O provedor decide em qual categoria os serviços devem ser listados. Ele registra que os 
serviços estão disponíveis dentro dele.
✓Consumer - O consumidor de serviços ou cliente do serviço web localiza entradas, 
liga-se ao prestador do serviço para invocar um de seus web services. 
Consumers podem acessar vários serviços, se estiverem disponíveis.
Web Service
❑A plataforma básica para Web Services é XML + HTTP.
✓ XML fornece uma linguagem que pode ser usada entre diferentes 
plataformas e linguagens de programação e ainda consegue expressar 
funções e mensagens.
✓ O protocolo HTTP é o protocolo mais utilizado na internet.
✓A plataforma Web Service tem os seguintes elementos:
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)
Web Service
✓SOAP é um protocolo baseado em XML que permite 
que aplicações troquem informação sobre HTTP. É um 
protocolo para acessar um Web Service.
✓UDDI é um serviço de diretório em que empresas 
podem registrar e buscar por Web Services. Ele é 
descrito por WSDL e se comunica via SOAP.
✓WSDL é uma linguagem baseada em XML para 
localizar e descrever Web Services.
Web Service
Registro de 
Serviço
Solicitante do 
Serviço
Provedor de 
Serviços
Serviço
UDDI
Unir (SOAP) WSDL
Como as Web Services são usadas
Os provedores de serviços projetam e implementam serviços e os especificam em WSDL.
As informações sobre esses serviços são publicadas em um registro de acesso geral usando o 
padrão UDDI.
Os solicitantes de serviços (clientes) buscam o registro UDDI para descobrir a especificação 
desse serviço e para localizar o provedor de serviços. 
Eles podem finalmente unir suas aplicações para um serviço específico e se comunicar com 
ele usando o protocolo SOAP.
❑ Definições e Conceitos
❑ Processos de Verificação e Validação
❑ Testes
Caixa Preta
Caixa Branca
➢ O processo de testes consiste em executar o software de 
uma maneira controlada com o objetivo de avaliar se ele se 
comporta conforme o especificado.
➢ É uma das atividades que compõem a GQS (Garantia de 
Qualidade do Software).
Testes de Software
Definições
❑ O teste do software é a investigação do software a fim de 
fornecer informações sobre sua qualidade em relação ao contexto 
em que ele deve operar. Isso inclui o processo de utilizar o produto 
para ENCONTRAR seus DEFEITOS.
❑O teste é um processo realizado pelo testador de software, que 
permeia outros processos da engenharia de software, e que envolve 
ações que vão do levantamento de requisitos até a execução do 
teste propriamente dito.
Testes de Software
O software é testado para 
revelar erros cometidos 
inadvertidamente quando 
projetado e construído.
Fundamentos do Teste de Software
❑ O objetivo do teste é encontrar erros, e um bom teste é aquele que 
tem alta probabilidade de encontrar um erro. 
❑ Um engenheiro de software deve projetar e implementar um 
sistema ou produto baseado em computador tendo em mente a 
“testabilidade”. 
❑ Ao mesmo tempo, os próprios testes devem ter uma série de 
características que permitam atingir o objetivo de encontrar o maior 
número de erros com o mínimo de esforço.
✓Testabilidade: facilidade com que um programa 
de computador pode ser testado.
Testes de Software
Conceitos
Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender uma 
determinada informação, resolver um problema ou utilizar um método ou uma 
ferramenta. Por exemplo, uma instrução ou comando incorreto.
Erro é uma manifestação concreta de um defeito num artefato de software. 
Diferença entre o valor obtido e o valor esperado, ou seja, qualquer 
estado intermediário incorreto ou resultado inesperado na execução de um programa 
constitui um erro.
Falha é o comportamento operacional do software diferente do esperado pelo 
usuário. Uma falha pode ter sido causada por diversos erros e alguns 
erros podem nunca causar uma falha.
Testes de Software
Elementos Essenciais
❑ Caso de Teste: descreve uma condição particular a ser testada e é 
composto por valores de entrada, restrições para a sua execução e um 
resultado ou comportamento esperado.
❑Procedimento de Teste: é uma descrição dos passos necessários 
para executar um caso (ou um grupo de casos) de teste.
❑Critério de Teste: servepara selecionar e avaliar casos de teste
de forma a aumentar as possibilidades de provocar falhas ou, quando 
isso não ocorre, estabelecer um nível elevado de confiança na correção 
do produto .
Testes de Software
❑ Caso de Teste: descreve uma condição particular a ser 
testada e é composto por valores de entrada, restrições para 
a sua execução e um resultado ou comportamento esperado.
https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=2ahUKEwi8opW4kP3hAhUXLLkGHWZaAigQjRx6BAgBEAU&url=https%3A%2F%2Fwww.researchgate.net%2Ffigure%2FFigura-212-Exemplo-de-caso-de-teste_fig8_317035110&psig=AOvVaw2NBNerOayHiqxo-b8EdX5m&ust=1556896188556647
❑Procedimento de Teste: é uma descrição dos passos necessários para executar um 
caso (ou um grupo de casos) de teste.
https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=2ahUKEwiAlNjMkP3hAhWDKrkGHVa5BPkQjRx6BAgBEAU&url=https%3A%2F%2Fslideplayer.com.br%2Fslide%2F4180062%2F&psig=AOvVaw1YSD-Gxa031JmXpyp826uW&ust=1556896232053032
❑Critério de Teste: serve para selecionar e avaliar casos de teste
de forma a aumentar as possibilidades de provocar falhas ou, quando 
isso não ocorre, estabelecer um nível elevado de confiança na correção 
do produto .
Verificação e validação
❑ O teste de software é um elemento de um tópico mais 
amplo, muitas vezes conhecido como verificação e validação
(V&V). 
❑Verificação refere-se ao conjunto de tarefas que garantem que 
o software implementa corretamente uma função específica. 
✓Validação refere-se a um conjunto de tarefas que asseguram 
que o software foi criado e pode ser rastreado segundo os 
requisitos do cliente.
Testes de Software
Testes de Software
Verificação Estamos criando 
o produto 
corretamente?
Estamos criando o 
produto certo?
Validação
Testes Caixa Branca / Caixa Preta
Teste Caixa-Branca
❑O teste caixa-branca, também chamado de teste da 
caixa-de-vidro, teste estrutural, ou ainda teste orientado 
a lógica, é uma filosofia de projeto de casos de teste.
❑É uma técnica de teste que usa a perspectiva interna 
do sistema para modelar os casos de teste. No teste de 
software, a perspectiva interna significa basicamente o 
código fonte. 
Teste Caixa-Branca
❑ Usando métodos de teste caixa-branca, o engenheiro de software 
pode criar casos de teste que:
(1) garantam que todos os caminhos independentes de um módulo 
foram exercitados pelo menos uma vez, 
(2) exercitam todas as decisões lógicas nos seus estados verdadeiro e 
falso, 
(3) executam todos os ciclos em seus limites e dentro de suas 
fronteiras operacionais, e 
(4) exercitam estruturas de dados internas para assegurar a sua 
validade.
Testes Caixa-Branca
Caminhos Independentes
Caminho 1: 1-11
Caminho 2: 1-2-3-4-5-10-1-11
Caminho 3: 1-2-3-6-8-9-10-1-11
Caminho 4: 1-2-3-6-7-9-10-1-11
Note que cada novo 
caminho introduz uma 
nova aresta. 
Testes Caixa-Branca
Caminhos Independentes
Testes de Software
O caminho 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 não é considerado um caminho independente 
porque ele é simplesmente uma combinação dos caminhos já especificados e não atravessa 
nenhuma nova aresta.
Teste Caixa-Preta
❑ Também chamado de teste comportamental, focaliza os requisitos 
funcionais do software. 
❑ As técnicas de teste caixa-preta permitem derivar séries de 
condições de entrada que utilizarão completamente todos os 
requisitos funcionais para um programa. 
❑O teste caixa-preta não é uma alternativa às técnicas caixa-branca.
❑ É uma abordagem complementar, com possibilidade de descobrir 
uma classe de erros diferente daquela obtida com métodos caixa-
branca.
Teste Caixa-Preta
❑O teste caixa-preta tenta encontrar erros nas seguintes categorias:
(1) funções incorretas ou faltando, 
(2) erros de interface, 
(3) erros em estruturas de dados ou acesso a bases de dados 
externas,
(4) erros de comportamento ou de desempenho, e 
(5) erros de inicialização e término.
Testes de Software
✓As especificações de requisitos 
são base para o planejamento 
dos testes de aceitação, 
✓o teste de sistema é planejado 
a partir do projeto de alto nível, 
✓o projeto detalhado é fonte 
para os planos de teste de 
integração e, por fim, 
✓a codificação subsidiará os 
planos de teste unitários.
Testes de Software
Testes de Software
Teste de Unidade:
❑ O objetivo é testar os componentes individualmente. Utilizado
para garantir que um programa, método ou função atenda às
especificações e produza os resultados esperados.
➢ Nesse estágio, são elaborados os CAMINHOS para descobrir
erros nos limites dos módulos.
✓ Emprega-se foco na lógica interna e estrutura de dados do
componente, onde cada componente tem suas interfaces
testadas para garantir que as informações fluam corretamente
para dentro e para fora da unidade.
✓ E por fim, assegura que todas as instruções de um módulo
tenham sido executadas pelo menos uma vez.
Testes de Software
Teste de Integração:
❑Utilizado para verificar se os requisitos explícitos e 
implícitos do sistema estão sendo atendidos. 
❑Deve servir, também, para analisar a estrutura 
hierárquica de execução dos módulos.
❑Permite que os componentes que já passaram pelo 
teste da unidade sejam testados de forma integrada, 
verificando assim se suas interfaces estão 
funcionando como deveriam.
Testes de Software
Teste de Integração:
❑Uma boa prática é a aplicação de uma abordagem 
incremental de testes para a construção da arquitetura do 
sistema. 
❑O programa é construído e testado em pequenos 
incrementos, onde os erros são mais fáceis de serem 
isolados e corrigidos, na contramão de se construir e testar 
unitariamente todos os componentes e só integrá-los no 
final, de uma vez só. 
❑Essa última opção normalmente traz um grande volume de 
erros difíceis de serem administrados e resolvidos.
Testes de Software
Teste de Integração:
❑Durante essa fase, a equipe de testes tem 
acesso ao código-fonte do sistema. 
❑Quando um problema é encontrado, o time 
de integração investiga para determinar a 
causa-raiz e identificar os componentes que 
estão causando os defeitos no sistema para 
resolvê-los.
Testes de Software
Teste de Sistema:
❑Aqui a equipe de testes testa uma versão a ser 
liberada ao usuário. 
❑O foco nessa etapa é validar se o sistema está 
atendendo aos requisitos e se é confiável.
❑Geralmente é um teste tipo “caixa preta”, onde a 
equipe permanece concentrada em confirmar o 
correto funcionamento do sistema.
Testes de Software
Teste de Aceitação:
❑Nessa etapa, há a participação de usuários e, se a 
confirmação (aceitação) do sistema for feita, o mesmo 
pode ser liberado para uso. 
❑Caso contrário, os erros são relatados à equipe de 
desenvolvimento que deverá prosseguir com as devidas 
correções.
❑Utilizado para garantir que o cliente vistoriou o produto 
entregue e está de acordo com os requisitos.
Teste Alfa
É realizado imediatamente após o término do desenvolvimento do sistema. No 
momento em que o sistema se torna plenamente operacional, os usuários passam 
a testá-lo em ambiente apropriado (geralmente ambiente de homologação), que 
está sob a supervisão da equipe de desenvolvimento. Esse tipo de teste busca erros 
que podem ter sido negligenciados nos planos de teste, cenários e casos de teste 
elaborados. É o primeiro contato do cliente/usuário com o produto.
Teste Beta
Trata-se de um tipo de teste de aceitação. É conduzido pelo cliente/usuário, sem a 
presença do desenvolvedor, no ambiente do cliente visando identificar possíveis 
erros resultantes da configuração. O cliente registra os problemas (reais ou 
imaginários) que são encontrados e relata-os ao desenvolvedor a intervalos 
regulares.
Testes Alfa e Beta
❑Em se tratando de homologar um software, a “autoridade” é o cliente. 
❑Para software aplicativo, desenvolvido para ser utilizado internamente na empresa 
ou de produto criado especificamente para um cliente externo, o cliente é 
responsável por atestar que o produto estáapto a ser utilizado no ambiente de 
produção. 
✓A liberação do produto está atrelada à satisfação do cliente em relação aos 
requisitos, desempenho, usabilidade e outros elementos que determinam se o 
software está ou não em conformidade com as suas expectativas. 
✓Essa aprovação deve ser formal, onde normalmente é entregue um documento 
para que o usuário (cliente) assine um termo de aceite, o qual ratifica que o 
sistema foi validado e aprovado. 
Homologação de Produtos de 
Software (Teste de Aceitação
❑Quando um software é desenvolvido para ser distribuído 
em larga escala, ou seja, é um produto que será vendido 
para uma aplicação de forma genérica (Por exemplo, um 
sistema de contabilidade para empresas), a homologação 
deve ficar a cargo de empresas que são especializadas em 
testes de software. Isso garante que exista, principalmente, 
imparcialidade no processo.
Homologação de Produtos de 
Software
Exemplos ruins de design de interface do usuário e erros 
comuns de designers de interface do usuário
Obviamente, uma boa interface 
do usuário pode nos fazer sentir 
em casa com tudo no lugar 
certo; enquanto a má interface do 
usuário fará com que você sinta 
um gosto ruim na boca e tudo que 
você deseja fazer é sair 
rapidamente.
Design não responsivo
Arquiteto de informação ruim
Menos pode ser mais. 
Manter um bom equilíbrio na hierarquia visual pode deixar uma boa impressão nos 
usuários e fornecer mais informações a eles. O exemplo abaixo pode nos dar um 
sentimento de desordem e confusão mais ou menos.
Estilo inconsistente
Isso não significa que o estilo de mashup não 
seja bom, mas se a interface geral tiver um 
conflito visual enorme e feio, é melhor 
reprojetá-lo. 
Um excelente design de interface do usuário 
deve ser consistente com o estilo para fazer 
com que os usuários entendam e respondam 
claramente ao conteúdo fornecido. Isso 
também ajudará a melhorar a eficiência do 
trabalho.
Engenharia de Software
Atividades essenciais no processo de 
Desenvolvimento de Software
❑ Especificação 
❑ Desenvolvimento
❑Validação
❑ Evolução
Evolução de Software
(Pressman)
Todo software, independente do tamanho e complexidade, depois de 
colocado em operação, continuará a evoluir continuamente.
• Erros são corrigidos
• Adaptação a um novo ambiente (hardware, sistema operacional...)
• Cliente solicita novas características ou funções
• Aplicação pode passar por um processo de reengenharia
A manutenção do software inicia-se quase que imediatamente após a implementação.
Por que? Relatos de bugs, novas regulamentações, novos requisitos de negócio
(mudanças no mercado)...
Evolução de Software
(Pressman)
Reengenharia
Um produto de software lhe serviu bem por muitos anos...
Você o utiliza ainda regularmente, mas esse começa a apresentar problemas com 
muita frequência...
Leva-se mais tempo para ser reparado do que você aceitaria e já não representa a 
tecnologia mais atualizada... 
O que fazer? Por um tempo, você tenta consertá-lo, remendá-lo ou até ampliar sua 
funcionalidade. Isso se chama manutenção!
Mas a manutenção se torna cada vez mais difícil à medida que os anos passam... 
Reengenharia
... chega então um momento em que precisa reformá-lo!
Você criará um produto com mais funcionalidades, melhor 
desempenho e confiabilidade e de manutenção mais fácil. Isso é o que 
chamamos de reengenharia de software!
Evolução de Software
(Pressman)
Engenharia Reversa é o processo de descobrir 
os princípios tecnológicos e o funcionamento de 
um dispositivo, objeto ou sistema, através da análise de 
sua estrutura, função e operação.
1. Tradução de código-fonte. Usando uma ferramenta de tradução, o programa é 
convertido a partir de uma linguagem de programação antiga para uma versão 
mais moderna da mesma linguagem ou em outra diferente. 
1. Engenharia reversa. 0 programa é analisado e as informações são extraídas a partir dele. Isso 
ajuda a documentar sua organização e funcionalidade. Esse processo também é completamente 
automatizado.
2. Melhoria de estrutura de programa. A estrutura de controle do programa é analisada e 
modificada para que se torne mais fácil de ler e entender. Isso pode ser parcialmente 
automatizado, mas, normalmente, alguma intervenção manual é exigida. 
3. 4. Modularizaçâo de programa. Partes relacionadas do programa são agrupadas, e onde houver 
redundância, se apropriado, esta é removida. Em alguns casos, esse estágio pode envolver 
refatoração de arquitetura (por exemplo, um sistema que usa vários repositórios de dados 
diferentes pode ser refeito para usar um único repositório). Esse é um processo manual. 
4. Reengenharia de dados. Os dados processados pelo programa são alterados para refletir as 
mudanças de programa. Isso pode significar a redefinição dos esquemas de banco de dados e a 
conversão do banco de dados existente para a nova estrutura. Normalmente devem-se limpar os 
dados, o que envolve encontrar e corrigir erros, remover registros duplicados etc. Ferramentas 
são disponíveis para dar suporte à reengenharia de dados. 
Sommerville mostra na Figura como maiores esforços durante o desenvolvimento do 
sistema para produção de um sistema manutenível reduzem os custos gerais durante a vida 
útil do sistema.
Quando se investe em uma produção de software visando maior facilidade de 
compreensão, análise e testes para quem suportará o sistema na sua vida útil, no longo 
prazo, há uma economia nos custos totais do sistema ao longo de seu ciclo de vida.