Engenharia de Software (Pressman e Sommerville)  Software aberto: são aqueles em que muitas pessoas

podem contribuir para o seu desenvolvimento.

Software: são programas de computador e documentação
associada (tudo o que acompanha o programa). Produtos de
software podem ser desenvolvidos para um cliente específico ou
para o mercado em geral. Consiste em instruções que quando
executadas fornecem características, funções e desempenho
desejados.
Um bom software deve prover a funcionalidade e o desempenho
requeridos pelo usuário; além disso, deve ser confiável e fácil de
manter e usar. (Manutenibilidade, Confiança e Proteção,
Eficiência e Aceitabilidade)
Atenção!! Software é desenvolvido, e não fabricado ou
manufaturado.
Atenção!! Software não se desgasta, porém se deteriora e sofre
constantes modificações.
Atenção!! A maior parte dos softwares é desenvolvida de forma
personalizada, sob encomenda.
Engenharia de Software: é a disciplina de engenharia que se
preocupa com todos os aspectos de produção de software.
Abordagem em camadas
Riscos de projeto: riscos que afetam o cronograma ou os
recursos de projeto.
Riscos de produto: riscos que afetam a qualidade ou o
desempenho do software que está sendo desenvolvido.
Riscos de negócio: os riscos que afetam a organização que
desenvolve ou adquire o software.
Modelo de processo de software: é uma representação
simplificada de um processo de software. Cada modelo
representa uma perspectiva particular de um processo e,
portanto, fornece informações parciais sobre ele.
Tipos de Modelo (Tradicionais ou Prescritivos)
Neste modelo, a ordem e a consistência do projeto são questões
dominantes. Cada modelo de projeto também prescreve um fluxo
de trabalho, ou seja, a forma pela qual os elementos do processo
estão inter-relacionados.
Modelo Cascata (dirigido a planos)(SOMMERVILLE E PRESSMAN):
também chamado de ciclo de vida clássico e linear, sugere uma
abordagemsequencial e sistemática para o desenvolvimento de
software, começando com o levantamento das necessidades e
avançando pelas fases de planejamento, modelagem,
construção, emprego e suporte contínuo do software concluido.

 Foco na qualidade: sustenta a engenharia de software.

 Processo: define uma metodologia que deve ser
estabelecida para a entrega efetiva de tecnologia de ES.
Constitui a base para o controle do gerenciamento de
projetos de software e estabelece o contexto no qual são
aplicados métodos técnicos.
 Métodos: fornecem as informações técnicas para
desenvolver software. Envolvem uma ampla gama de Análise – Definição da arquitetura – Projeto – Implementação –
tarefas que incluem – comunicação, análise de requisitos, Testes com validação – Manutenção.
modelagem de projeto, construção de programas e teste e
suporte. O estágio seguinte não deve ser iniciado até que a fase anterior
 Ferramentas: fornecem suporte automatizado ou semi seja concluída. Na prática, esses estágios se soprepõem e
automatizado para o processo e para os métodos. alimentam uns aos outros de informações. Em principio, o modelo
cascata deve ser usado apenas quando os requisitos são bem
Campos de aplicação de software compreendidos e pouco provavelmente venham a ser
 Software de sistema: programas para atender a outros radicalmente alterados durante o desenvolvimento do sistema.
programas – compiladores, SO, drivers.
 Software de aplicação: programas sob medida que Modelo Incremental (dirigido a planos, ágil ou
solucionam uma necessidade específica do negócio. ambos)(SOMMERVILLE E PRESSMAN): essa abordagem intercala as
 Software científico (de engenharia): algoritmo para atividades de especificação, desenvolvimento e validação. O
processamento númerico pesado. sistema é desenvolvido como uma série de versões
 Software embutido: residente em um produto ou sistema e (incrementos), de maneira que cada versão adicione alguma
utilizado para implementar e controlar características e funcionalidade à anterior.
função para o usuário final e para o próprio sistema.
 Software para linha de produtos: projetado para prover
capacidade específica de utilização por muitos clientes
diferentes.
 Aplicações web: abarca uma gama de aplicações.
 Software de inteligência artificial: faz uso de algoritmos não
numéricos para solucionar problemas complexos que não
são passíveis de computação ou de análise direta.
 Computação mundial aberta.
 Netsourcing: softwares simples que podem ser utilizados
via internet.
Baseia-se na ideia de desenvolver uma implementação inicial,
expô-la aos comentários dos usuários e continuar por meio da
criação de várias versões até que um sistema adequado seja
desenvolvido.
Modelo Evolucionário(PRESSMAN): são iterativos. Permitem
desenvolver versões cada vez mais completas do software. São
divididos em:
 Prototipação: mecanismo para identificar requisitos de
software. Utilizado para entender requisitos e apropriado
quando o cliente não tem detalhes dos requisitos. O
paradigma da prototipação auxilia os interessados a
compreender melhor o que está para ser construído. Cria-
se um protótipo em que os envolvidos conseguem ter uma
prévia de como o sistema ficará – tipos: prototipação
evolucionária e prototipação descartável.
 Espiral: acopla a natureza iterativa da prototipação com os
aspectos sistemáticos e controlados do modelo cascata.
Abordagem cíclica guiadas por riscos, aumenta
incrementalmente o grau de definição e implementação de
um sistema.
Modelo Concorrente(PRESSMAN): permite à equipe de software
representar elementos concorrentes e iterativos de qualquer um
dos modelos de processo descritos. Define uma série de eventos
que irão disparar transições de estado para estado para cada
uma das atividades, ações ou tarefas de ES. Equipe envolvida
em várias atividades simultâneas.
Tipos de Modelo (Especializados)
Utilizados quando se opta por uma abordagem de ES
especializada ou definida de forma restrita.
Engenharia de software orientada à reuso(SOMMERVILLE): é
baseada na existência de um número significativo de
componentes reusáveis. O processo de desenvolvimento do
sistema concentra-se na integração desses componentes em um
sistema já existente em vez de desenvolver um sistema a partir
do zero.(Também chamada de Integração e Configuração)
 Análise de componentes: dada a especificação de
requisitos, é feita uma busca por componentes para
implementar essa especificação.
 Modificação (alteração) de requisitos: durante esse
estágio, os requisitos são analisados usando-se
informações sobre os componentes que foram descobertos.
Em seguida, estes serão modificados para refletir os
componentes disponíveis.
 Projeto do sistema com reúso: durante esse estágio, o
framework do sistema é projetado ou algo existente é
reusado.
 Desenvolvimento e integração: softwares que não podem
ser adquiridos externamente são desenvolvidos e os
componentes e sistemas COTS (prateleira) são integrados
para criar o novo sistema.
Desenvolvimento baseado em componentes(PRESSMAN): são
componentes de software comerciais de prateleira ou COTS,
desenvolvido por vendedores que oferecem produtos e
disponibilizam a funcionalidade almejada juntamente com as
interfaces definidas. Esse modelo incorpora muitas características
do modelo espiral e é evolucionário em sua natureza,
demandando uma abordagem iterativa para a criação de
software. O modelo de desenvolvimento baseado em
componentes desenvolve aplicações a partir de componentes de
software pré-empacotados. Utiliza fortemente a UML.
Métodos formais(PRESSMAN): baseados em técnicas matemáticas.
Promessa de um software “livre de defeitos”, é aplicado a
sistemas críticos e utiliza a notação Z.
Desenvolvimento orientado a aspectos(PRESSMAN): é um
paradigma de ES relativamente novo que oferece uma
abordagem metodológica e de processos para definir, especificar,
projetar e construir aspectos. Tem como característica não
influenciar apenas uma parte de um componente, mas sim o
sistema como um todo. É uma alternativa para resolver
problemas que não são solucionados pelos demais métodos de
desenvolvimento.
Processo de Software: conjunto de atividades relacionadas que
levam à produção de um produto de software. Os softwares
podem ser desenvolvidos do zero ou estendidos a partir de um
software já existente.
Atividades fundamentais da Engenharia de Software
 Especificação do software: clientes e engenheiros definem
o software a ser produzido e as restrições de sua operação.
(DEFINIÇÕES, RESTRIÇÕES E FUNCIONALIDADES)
 Projeto e implementação (Desenvolvimento) do software: o
software é projetado e programado. (PRODUZIR O SOFTWARE
DE ACORDO COM AS ESPECIFICAÇÕES)
 Validação do software: o software é verificado para garantir
que é o que o cliente quer (escopo). (GARANTIR QUE ATENDE
ÀS NECESSIDADES DOS CLIENTES)
 Evolução do software: o software é modificado para refletir
a mudança de requisitos do cliente e do mercado. (EVOLUIR
PARA REFLETIR MUDANÇAS SOLICITADAS)
Espeficificação de software: possuem quatro atividades
principais do processo de engenharia de requisitos.
 Estudo de viabilidade: é feita uma estimativa acerca da
possibilidade de se satisfazerem as necessidades do
usuário identificado usando-se tecnologias atuais de
software e hardware.
 Elicitação e análise de requisitos: esse é o processo de
derivação dos requisitos do sistema por meio da
observação dos sistemas existentes, além de discussões
com os potenciais usuários e compradores, entre outros.
 Especificação de requisitos: é a atividade de traduzir as
informações obtidas durante a atividade de análise em um
documento que defina um conjunto de requisitos. Tipos:
requisitos do usuário e requsitos de sistema.
 Validação de requisitos: essa atividade verifica os requisitos
quando a realismo, consistência e completude.
Projeto e implementação (Desenvolvimento) do software
 Projeto de arquitetura: pode-se identificar a estrutura geral
do sistema, os componentes principais (subsistemas ou
módulos), seus relacionamentos e como eles são
distribuídos.
 Projeto de interface: define-se as interfaces entre os
componentes do sistema.
 Projeto de componente: toma-se cada componente do
sistema e projeta seu funcionamento.
 Projeto de banco de dados: projeta-se as estruturas de
dados do sistema.
Validação de software: teste de programa, em que o sistema é
executado com dados de testes simulados, é a principal técnica.
Também pode envolver processos de verificação, como
inspeções e revisões, em cada estágio do processo de software,
desde a definição dos requisitos de usuários até o
desenvolvimento do programa.
 Teste de componente: os componentes do sistema são
testados pelas pessoas que o desenvolveram. Cada
componente é testado de forma independente, separado
dos outros.
 Teste de sistema: componentes do sistema são integrados
para criar um sistema completo. Esse processo se
preocupa em encontrar os erros resultantes das interações
inesperadas entre componentes e problemas de interface
do componente. Tambem visa mostrar que o sistema
satisfaz seus requisitos funcionais e não funcionais, bem
como testar as propriedades emergentes do sistema.
 Teste de aceitação (teste alfa): é o estágio final do processo
de testes. O sistema é testado com dados fornecidos pelos
clientes e não com dados advindos de testes simulados.
Podem revelar erros e omissões na definição dos requisitos
do sistema e problemas de requisitos.
Baseline é uma configuração de software especialmente criada
para uma situação específica e aprovada em determinado
momento do ciclo de vida de software para servir de base a
desenvolvimentos posteriores.
O Rational Unified Process – RUP é um exemplo de modelo de
processo moderno, derivado de trabalhos sobre a UML e o
Unified Software Development Process associado. É um bom
exemplo de processo híbrido (incremental, iterativo e
prototipação). Ele reúne elementos de todos os modelos de
processo genéricos. É o principal framework de processos
utilizado atualmente.
 É iterativo e incremental.
 Guiado por casos de uso.
 Centrado na arquitetura.
 Orientado a objetos.
 Planejado por riscos.
Principios chaves do RUP:
 Adaptar processos: “RUP é muito pesado” – Dimensionar
corretamente o processo para a empresa. Não é obrigatório
usar todos os papéis e os artefatos. Varia de projeto a
projeto.
 Balancear prioridades dos interessados: “Meu requisito é
mais importante” – alinha aplicativos às necessidades do
negócio e dos usuários. Otimiza o valor do negócio. Define-
se nas fases iniciais o que é prioritário e balanceia cada
uma das necessidades.
 Colaborar através de equipes: incrementar a produtividade
do time, ter senso de responsabilidade comum. Não deve
existir equipe de “testes” ou equipe de “desenvolvedores”.
 Demonstrar valor iterativamente: reduzir riscos prematuros,
adquirir concordância entre os interessados, execução de
vários ciclos e obter feedback.
 Elevar nível de abstração: forma de se lidar com
complexidades. Utiliza componentes ou linguagens de alto
nível e UML para representação das abstrações.
 Focalizar continuamento na qualidade: assegura que toda a
equipe esteja comprometida com a qualidade do produto.
Testa de forma contínua e conduz revisões.
É descrito em três perspectivas:
 Perspectiva dinâmica: mostra as fases do modelo ao longo
do tempo.
 Perspectiva estática: mostra as atividades/disciplinas
realizadas no processo.
 Perspectiva prática: sugere boas práticas a serem usadas
durante o processo.
Descreve seis boas práticas:
 Desenvolver software iterativamente;
 Gerenciar os requisitos;
 Usar arquiteturas baseadas em componentes;
 Modelar o software visualmente;
 Verificar a qualidade do software; e
 Controlar as mudanças do software.
O RUP é um processo de engenharia de software. Ele oferece
uma abordagem baseada em disciplinas para atribuir tarefas e
responsabilidades dentro de uma organização de
desenvolvimento. Sua meta é garantir a produção de software de
alta qualidade que atenda às necessidades dos usuários dentro
de um cronograma e de um orçamento previsíveis.Caracterizam-
se por ser dirigido por casos de uso, centrado na arquitetura,
iterativo e incremental, além de ter foco em riscos.
O Processo Unificado e diversos métodos atuais de
desenvolvimento iterativo encorajam um planejamento das
iterações iniciais de um projeto de forma a priorizar requisitos que
envolvam a identificação e controle de maiores riscos e/ou que
envolvam características que o cliente mais se preocupa.
Produto de trabalho: abstração geral que representa algum
resultado de um processo.
 Artefato: produtos de trabalho tangíveis e bem definidos.
 Entrega: produto de trabalho que provê uma descrição e
definição para o empacotamento de outro produto de
trabalho.
 Resultado: descreve produtos de trabalho intangíveis como
um resultado ou um estado.
Papéis: define o comportamento e as responsabilidades no
processo. É a definição abstrata de um conjunto de atividades
executadas. Pode ser desempenhado por uma pessoa ou grupo
de pessoas.
Atividades/Tarefas: unidade de trabalho desempenhada por um
papel. Define o trabalho que será executado. Composta por
passos, entradas e saídas e com uma finalidade específica.
“Papéis executam atividades que geram produtos de trabalho”.
É um modelo constituído de fases que identifica quatro fases
distintas no processo de software, estreitamente relacionadas ao
negócio e não a assuntos técnicos. Cada uma concluída por um
marco principal. Uma passagem pelas quatros fases é
considerado um ciclo de desenvolvimento. Indicam a ênfase
que é dada ao projeto em um momento específico.
 Concepção/Iniciação: abranger as tarefas de
comunicação com o cliente e o planejamento. É feito
um plano de projeto avaliando os possíveis riscos, as
estimativas de custo e prazos, estabelecendo as
prioridades, o levantamento dos requisitos do sistema e
a análise preliminar. Nesta fase, deve haver
concordância dos stakeholders quanto ao escopo do
projeto.
 Elaboração: analisar de forma mais detalhada o
domínio do problema, revisando os riscos que o projeto
pode sofrer. A arquitetura do projeto inicia-se com sua
forma básica elaborada. Indagações como "O plano do
projeto é confiável?", "Os custos são admissíveis?" são
esclarecidas nesta fase.
 Construção: desenvolver ou adquirir componentes de
software. O principal objetivo desta fase é codificação
do software, com foco nos componentes e outros
recursos do sistema.
 Transição: disponibilizar o sistema de forma que seja
compreendido pelo usuário final. As atividades desta
fase incluem o treinamento dos usuários finais e a
realização de testes da versão beta do sistema visando
garantir a sua qualidade.
 Concepção/Iniciação(Marco: objetivos do ciclo de vida):
seu objetivo é estabelecer o escopo, estimar custo, tempo e
riscos, identificar casos de uso críticos e principais e propor
ao menos uma opção de arquitetura. Objetiva atingir o
consenso sobre os objetivos do ciclo de vida do projeto.
Principais artefatos:
 Visão: características mais importantes do sistema.
 Caso de negócio: informações sobre o ponto de vista
do negócio.
 Lista de riscos.
 Plano de desenvolvimento de software: todas as
informações necessárias ao gerenciamento do
projeto.
 Plano de iteração: planejar a passagem pelas
disciplinas.
 Casos de desenvolvimento: documentar decisões de
adaptações do projeto.
 Modelo de casos de uso: descrever os requisitos
funcionais do sistema.
 Glossário: termos importantes utilizados no projeto.
 Elaboração (Marco: arquitetura do ciclo de vida): suas
metas são desenvolver uma compreensão do problema
dominante, estabelecer um framework da arquitetura para o
sistema, desenvolver o plano de projeto e identificar os
maiores riscos do projeto. (modelo de requisitos do sistema)

Principais artefatos:
 Protótipos: utilizados como forma de reduzir o risco.
 Lista de riscos (atualizada e revisada).
 Documento de arquitetura: visão geral de arquitetura
abrangente do sistema.
 Modelo de projeto: descreve a realização dos casos
de uso.
 Modelo de dados: descreve a representação lógica e
física dos dados do sistema.
 Conjunto de testes: testes implementados e
executados para validar a estabilidade.
 Modelo de caso de uso (80% concluído).
 Modelo de domínio.
 Construção (Marco: Capacidade operacional inicial):
envolve projeto, programaçao e testes do sistema.
Esclarecer requisitos restantes; concluir o desenvolvimento
do sistema com base na arquitetura definida; ênfase no
gerenciamento de recursos para otimizar custos,
programação e qualidade; atingir versões alfa e beta e alto
grau de paralelismo. (sistema de software já funcionando)
Principais artefatos:
 “O sistema”: sistema executável, pronto para começar
o teste beta.
 Plano de implementação: alinhar as equipes de
implantação para disponibilizar o software.
 Conjunto de testes: testes implementados e
executados para validar a estabilidade dos releases.
 Material de suporte do usuário: manuais e outros
materiais de treinamento. Rascunho preliminar com
base em casos de uso.
 Transição (Marco: Release do produto): implica
transferência do sistema da comunidade de
desenvolvimento para a comunidade de usuários e em seu
funcionamento em um ambiente real.
Principais artefatos:
 Notas de release: texto com informações sobre a
versão.
 Artefatos de instalação: o que é necessário ter para
disponibilizar o sistema no ambiente alvo.
 Material de treinamento: guias de usuário e manuais
do sistema.
Disciplina (Workflow): mostra todas as atividades que devem ser
realizadas para produzir um determinado conjunto de artefatos.
Divididas em engenharia – modelagem de negócios, requisitos,
análise e design, implementação, teste e implantação – e suporte
– gerenciamento de projeto, gerenciamento de mudanças e
ambiente.
 Modelagem de negócios: os processos de negócios são
modelados com a utilização de casos de uso de negócio.
 Requisitos: os casos de uso são desenvolvidos para
modelar os requisitos do software. Definir uma interface de
usuário para o sistema, possuindo, como uma de suas
tarefas, desenvolver a visão geral para o sistema.
 Análise e projeto: cria-se um modelo de projeto com base
em modelos de arquitetura, de componente, de objeto e de
sequência.
 Implementação: os componentes do software são
implementados.
 Teste: o teste é um processo iterativo e é efetuado em
conjunto com a implementação do sistema. (validação)
 Implantação: cria-se uma versão do produto e instala-se no
local de trabalho dos usuários. Desenvolver materiais de
treinamento.
 Gerenciamento de configuração e mudanças: esse
workflow serve como apoio à gerência do projeto em
relação às mudanças no sistema.
 Gerenciamento de projetos: esse workflow de apoio
gerencia o processo de desenvolvimento de software.
 Ambiente: esse workflow relaciona-se à disponibilização de
ferramentas de software adequadas para a equipe de
desenvolvimento.
Desenvolvimento ágil: não é indicado para todos os projetos,
produtos, pessoas e situações. O ponto chave é que o processo
se molda às necessidades das pessoas e equipes, e não o
inverso. Valoriza mais:
 Individuos e interações do que processos e ferramentas;
 Software em funcionamento do que documentação
abrangente;
 Colaboração do cliente do que negociação de contrato;
 Respostas a mudanças do que seguir um plano.
Embora os métodos ageis sejam todos baseados na noção de
desenvolvimento e entrega incremental, eles propõem diferentes
processos para alcançar tal objetivo. No entanto, compartilham
um conjunto de principios, com base no manifesto ágil:
 Envolvimento do cliente;
 Entrega incremental;
 Pessoas, não processos;
 Aceitar as mudanças;
 Manter a simplicidade.
Abordagens ágeis de desenvolvimento de software consideram
o projeto e a implementação como atividades centrais no
processo de software. Eles incorporam outras atividades, como
elicitação de requisitos e testes no projeto e na implementação.
Abordagem dirigida a planos identifica estágios distintos do
processo de software com saídas associadas a cada estágio. As
saídas de um estágio são usadas como base para o
planejamento da atividade do processo a seguir.
Em uma abordagens dirigida a planos, ocorrem iterações no
âmbito das atividades com documentos formais, usados para
estabelecer a comunicação entre os estágios do processo. Em
uma abordagem ágil, iterações ocorrem em todas as atividades,
portanto, os requisitos e o projeto são desenvolvidos em conjunto,
e não separadamente.
XP – Extreme Programming: trata-se de uma metodologia ágil
para equipes pequenas e médias desenvolvendo software com
requisitos vagos e em constante mudança. Nela, os requisitos
são expressos como cenários (chamados de histórias de
usuário), que são implementados diretamente como uma série de
tarefas. Os programadores trabalham em pares e desenvolvem
testes para cada tarefa antes de escreverem o código.
Práticas do XP
 Planejamento incremental: os requisitos são gravados em
cartões de história e as histórias que serão incluídas em um
release são determinadas pelo tempo disponível e sua
relativa prioridade. Os desenvolvedores dividem essas
histórias em “tarefas”.
 Pequenos releases: em primeiro lugar, desenvolve-se um
conjunto minimo de funcionalidades útil, que fornece o valor
do negócio. Releases do sistema são frequentes e
gradualmente adicionam funcionalidade ao primeiro
release.
 Projeto simples: cada projeto é realizado para atender às
necessidades atuais, e nada mais.
 Desenvolvimento test-first: um framework de testes
iniciais automatizados é usado para escrever os testes para
uma nova funcionalidade antes que a funcionalidade em si
seja implementada.
 Refatoração: todos os desenvolvedores devem refatorar o
código continuamente assim que encontrarem melhorias de
código. Isso mantém o código simples e manutenível.
 Programação em pares: os desenvolvedores trabalham
em pares, verificando o trabalho dos outros e prestando
apoio para um bom trabalho sempre.
 Propriedade coletiva: os pares de desenvolvedores
trabalham em todas as áreas do sistema, de modo que não
se desenvolvam ilhas de expertise. Todos os
conhecimentos e todos os desenvolvedores assumem
responsabilidade por todo o código. Qualquer um pode
mudar qualquer coisa.
 Integração contínua: assim que o trabalho em uma tarefa
é concluído, ele é integrado ao sistema como um todo.
Após essa integração, todos os testes de unidade do
sistema devem passar.
 Ritmo sustentável: grandes quantidades de horas extras
não são aceitáveis, pois o resultado final, muitas vezes, é a
redução da qualidade do código e da produtividade a médio
prazo.
 Cliente no local: um representante do usuário final do
sistema deve estar disponível todo o tempo à equipe de XP.
Spike: incremento em que nenhum tipo de programação é
realizado.
Histórias do usuário: conjunto de fases escritas pelo cliente e
desenvolvedores em linguagem comum para capturar os
requisitos.
Valores do XP
 Comunicação;
 Simplicidade;
 Feedback;
 Coragem (disciplina);
 Respeito.
Scrum: é um método ágil geral, mas seu foco está no
gerenciamento do desenvolvimento iterativo, ao invés das
abordagens técnicas específicas da ES ágil.
No Scrum, existem três fases:
 A primeira é uma fase de planejamento geral, em que se
estabelecem os objetivos gerais do projeto e da arquitetura
do software.
 A segunda, ocorre uma série de ciclos sprint, sendo que
cada ciclo desenvolve um incremento do sistema.
 A terceira, encerra o projeto, completa a documentação
exigida e avalia as lições aprendidas com o projeto.
Sprint: é uma unidade de planejamento na qual o trabalho a ser
feito é avaliado, os recursos para o desenvolvimento são
selecionados e o software é implementado. As principais
caracteristicas desse processo são:
 Sprints são de comprimento fixo, normalmente duas a
quatro semanas. Eles correspondem ao desenvolvimento
de um release do sistema em XP.
 O ponto de partida para o planejamento é o backlog do
produto, que é a lista do trabalho a ser feito no projeto.
 A fase de seleção envolve todos da equipe do projeto que
trabalham com o cliente para selecionar os recursos e a
funcionalidade a ser desenvolvida durante a sprint.
 Uma vez que todos estejam de acordo, a equipe se
organiza para desenvolver o software. Reuniões diárias
rápidas (máximo de 15 minutos), envolvendo todos da
equipe, são realizadas para analisar os progressos e, se
necessário, repriorizar o trabalho. Nessa etapa, a equipe
está isolada do cliente e da organização, com todas as
comunicação canalizadas por meio do chamado Scrum
Master.
 No fim, o trabalho é revisto e apresentado aos stakeholders.
O próximo ciclo da sprint começa em seguida.
Scrum Master: é um facilitador, que organiza reuniões diárias,
controla o backlog de trabalho, registra decisões, mede o
progresso comparado ao backlog e se comunica com os clientes
e a gerência externa à equipe. Seu papel é proteger a equipe de
desenvolvimento de distrações externas.
Product Owner: define as funcionalidades do produto, mantêm
os itens do backlog atualizados e priorizados, aceita ou rejeita o
que foi produzido e sempre está disponível para esclarecer
dúvidas.
Requisitos: são as descrições do que o sistema deve fazer, os
serviços que oferece e as restrições a seu funcionamento. O
processo de descobrir, analisar, documentar e verificar esses
serviços e restrições é chamado de engenharia de requisitos.
 Requisitos de usuário: são declarações, em uma linguagem
natural com diagramas, de quais serviços o sistema deverá
fornecer a seus usuários e as restrições com as quais este
deve operar. (declaração abstrata de alto nível)
 Requisitos de sistema: são descrições mais detalhadas das
funções, serviços e restrições operacionais do sistema de
software. (descrição detalhada e formal de uma função do
sistema)

Stakeholder: pessoa ou papel que é de alguma forma afetada
pelo projeto.
Requisitos funcionais: são declarações de serviços que o
sistema deve fornecer, de como o sistema deve reagir a entradas
específicas e de como o sistema deve se comportar em
determinadas situações. Podem explicitar o que o sistema não
deve fazer. Exemplo: um usuário deve ser capaz de pesquisar
listas de agendamentos para todas as clínicas.
Requisitos não funcionais: são restrições aos serviços ou
funções oferecidos pelo sistema. Em geral, aplicam-se ao sistema
como um todo. Não estão diretamente relacionados aos serviços
específicos oferecidos para os usuários, mas podem estar
relacionados às propriedades emergentes do sistema, como
confiabilidade, tempo de resposta e ocupação de área. Deixar de
atender a um requisito não funcional pode significar a inutilizaçaõ
de todo o sistema. São divididos em:
 Requisitos de produto: especificam ou restringem o
comportamento do software – requisitos de desempenho
quanto à rapidez e utilização de memória requerida,
requisitos de confiabilidade que estabelecem a taxa
aceitável de falhas, requisitos de proteção e requisitos de
usabilidade.
 Requisitos organizacionais: são os requisitos gerais de
sistemas derivados das políticas e procedimentos da
organização do cliente e do desenvolvedor – requisitos de
processo operacional que definem como o sistema será
usado, requisitos de processo de desenvolvimento que
especificam a linguagem de programação, o ambiente ou
normas e requisitos ambientais.
 Requisitos externos: derivam de fatores externos ao
sistema e seu processo de desenvolvimento – requisitos
reguladores, requisitos legais e requisitos éticos.
Requisito de domínio: podem ser tanto funcionais e não
funcionais, e refletem as características com relação ao domínio
ao qual está inserido.
Metas estabelecem boas intenções, mas podem causar
problemas para os desenvolvedores do sistema, uma vez que
deixam margem para interpretação e, consequentemente, para
disputas, quando da entrega do sistema.
Engenharia de requisitos (PRESSMAN): abrange sete tarefas
distintas, algumas podendo ocorrer em paralelo e sendo todas
adaptáveis à necessidade do projeto.
1) Concepção: objetiva entender o problema, quais os
envolvidos, a natureza da solução e inicia o processo de
comunicação entre eles. (estudo de viabilidade)
2) Levantamento: descobrir objetivos do sistema e do produto
– como o produto atende às necessidades da empresa e
como será utilizado no dia a dia. (problemas de escopo, de
entendimento e de volatilidade)
3) Elaboração: refinamento das informações obtidas e
inclusão de modelagem de cenários e das classes.
4) Negociação: negociar as necessidades conflitantes, definir
prioridades e custo em conjunto com os recursos
necessários.
5) Especificação: apresentação formal do dados obtidos até o
momento. É o “documento” que irá guiar o desenvolvimento
futuro.
6) Validação: avaliação dos artefatos quanto a qualidade.
Examina-se a especificação para garantir que todos os
requisitos tenham sido declarados de acordo com os
padrões estabelecidos.
7) Gestão de requisitos: visa identificar, controlar e ratrear
requisitos e modificações nos requisitos ao longo do
projeto.
Os processos de engenharia de requisitos podem incluir quatro
atividades de alto nível. Elas visam avaliar se o sistema é útil para
a empresa (estudo de viabilidade), descobrindo requisitos
(elicitação e análise), convertendo-os em alguma formapadrão
(especificação), e verificar se os requisitos realmente definem o
sistema que o cliente quer (validação). É um processo iterativo
em que as atividades são intercaladas.
Engenharia de requisitos (SOMMERVILLE)
2) Elicitação e análise de requisitos: nessa atividade, os
engenheiros de software trabalham com clientes e usuários
finais do sistema para obter informações sobre o domínio
da aplicação, os serviços que o sistema deve oferecer, o
desempenho do sistema, restrições de hardware e assim
por diante.
 Descoberta de requisitos: essa é a atividade de
interação com os stakeholders do sistema para
descobrir seus requisitos. Os requisitos de domínio dos
stakeholder se da documentação também são
descobertos durante essa atividade.
 Classificação e organização de requisitos: essa
atividade toma a coleção de requisitos não
estruturados, agrupa requisitos relacionados e os
organiza em grupos coerentes.
 Priorização e negociação de requisitos: essa
atividade está relacionada com a priorização de
requisitos e em encontrar e resolver os conflitos por
meio da negociação de requisitos. Normalmente, os
stakeholders precisam se encontrar para resolver as
diferenças e chegar a um acordo sobre os requisitos.
 Especificação de requisitos: os requisitos são
documentados e inseridos no próximo ciclo da espiral.
Documentos formais ou informais de requisitos podem
ser produzidos.
A elicitação e análise de requisitos é um processo iterativo, com
feedback contínuo de cada atividade para as outras atividades. O
ciclo do processo começa com a descoberta de requisitos e
termina com sua documentação. O entendimento do analista de
requisitos melhora a cada rodada do ciclo. Quando se completa o
documento de requisitos, o ciclo termina.
Técnicas de Elicitação
 Descoberta de requisitos: é o processo de reunir
informações sobre o sistema requerido e os sistemas
existentes e separar dessas informações os requisitos
de usuário e de sistema.
 Entrevistas: formais ou informais com stakeholders do
sistema. Podem ser fechadas ou abertas.
 Cenários: descrições de exemplos de sessões de
interação – exemplos da vida real.
 Casos de uso: técnica de descoberta de requisitos.
Identifica os atores envolvidos em uma interação e dá
nome ao tipo de interação. São documentados por um
diagrama de casos de uso de alto nível. O conjunto de
casos de uso representa todas as possíveis iterações
que serão descritas nos requisitos do sistema.
 Etnografia: técnica de observação que pode ser usada
para compreender os processos operacionais e ajudar
a extrair os requisitos de apoio para esses processos.
(trabalho do dia a dia) O analista faz uma imersão no
ambiente de trabalho em que o sistema será usado. É
particularmente eficaz para descobrir dois tipos de
requisitos – requisitos derivados da maneira como as
pessoas realmente trabalham e requisitos derivados da
cooperação e conhecimento das atividades de outras
pessoas.
3) Especificação de requisitos: é o processo de escrever os
requisitos de usuário e de sistema em um documento de
requisitos. Idealmente, os requisitos de usuário e de
sistema devem ser claros, inequívocos, de fácil
compreensão, completos e consistentes. Pode ser um
documento formal, um modelo gráfico, um modelo
matemático ou uma coleção de cenários de uso.
 Documento de Requisitos de Software (SRS –
Software Requirements Specification): declaração
formal do que os desenvolvedores deverão
implementar. Deve incluir tantos os requisitos de
usuário para um sistema, quanto uma
especificação detalhada dos requisitos do
sistema.
4) Validação de requisitos: processo pelo qual se verifica se os
requisitos definem o sistema que o cliente realmente quer.
Ela se sobrepõem à analise, uma vez que está preocupada
em encontrar problemas com os requisitos. Evita que erros
em um documento de requisitos possam gerar alto custo de
retrabalho.
Durante esse processo, diferentes tipos de verificação
devem ser efetuados com os requisitos no documento de
requisitos. Incluem (tipos de problemas comuns):
 Verificações de validade/corretude: a função era
exatamente aquela?
 Verificações de consistencia: diferentes requisitos
não podem entrar em conflito.
 Verificações de completude: todos os requisitos
necessários devem ter sido incluídos.
 Verificações de realismo: os requisitos incluídos
devem poder realmente ser implementados.
 Verificabilidade/Testabilidade: os requisitos
devem poder ser validados sobre o sistema
implementado.
Técnicas de validação (V&V)
 Revisões de requisitos: os requisitos são
analisados sistematicamente por uma equipe de
revisores que verifica erros e inconsistências.
 Prototipação: um modelo executável do sistema
é demonstrado para os usuários finais e clientes.
 Geração de casos de teste: requisitos devem
ser testáveis. Se é dificil projetar casos de testes,
então os requisitos serão dificeis de serem
implementados.
Gestão de requisitos: é o processo de compreensão e controle
das mudanças nos requisitos do sistema.
 O planejamento é o primeiro estágio essencial no processo
de gerenciamento de requisitos, e determina o nível de
detalhamento requerido no GR.
 O gerenciamento de mudanças deve ser aplicado a todas
as mudanças propostas aos requisitos de um sistema.
Avalia os benefícios da implementação de novos requisitos
justificam os custos de implementação.
Qualidade de software é um conceito multifacetado que pode ser
descrito seguindo 5 pontos de vista diferentes:
 Visão trancendental: a qualidade é algo que se
reconhece imediatamente, mas não consegue definir
explicitamente.
 Visão do usuário: vê a qualidade em termos das metas
específicas de um usuário final.
 Visão do fabricante: define qualidade em termos da
especificação original do produto.
 Visão do produto: a qualidade pode ser ligada a
caracteristicas inerentes de um produto.
 Visão baseada em valor: mede a qualidade tomando
como base o quanto um cliente estaria disposto a pagar
por um produto.
Qualidade de projeto no desenvolvimento de software engloba
um grau de atendimento às funções e características
especificadas no modelo de requisitos.
Qualidade de conformidade focaliza o grau em que a
implementação segue o projeto e o sistema resultante atende
suas necessidades e as metas de desempenho.
Qualidade de software pode ser definida como uma gestão de
qualidade efetiva aplicada de modo a criar um produto útil que
forneça valor mensurável para aqueles que o produzem e para
aqueles que o utilizam.
Dimensões de qualidade de Garvin
 Qualidade de desempenho.
 Qualidade dos recursos.
 Confiabilidade.
 Conformidade.
 Durabilidade.
 Facilidade de manutenção.
 Estética.
 Percepção.
Fatores de qualidade de McCall, são divididos em:
Operação do Produto
 CORREÇÃO: o quanto um programa satisfaz a sua
especificação e atende aos objetivos da missão do cliente.
 CONFIABILIDADE: o quanto se pode esperar que um
programa realize a função pretendida com a precisão
exigida.
 EFICIÊNCIA: a quantidade de recursos computacionais e
código exigidos por um programa para desempenhar sua
função.
 INTEGRIDADE: o quanto o acesso ao software ou dados por
pessoas não autorizadas pode ser controlado.
 USABILIDADE: esforço necessário para aprender, operar,
preparar a entrada de dados e interpretar a saída de um
programa.
Revisão do Produto
 FACILIDADE DE MANUTENÇÃO: esforço necessário para
localizar e corrigir um erro em um programa.
 FLEXIBILIDADE: esforço necessário para modificar um
programação em operação.
 TESTABILIDADE: esforço necessário para testar um
programar de modo a garantir que ele desempenhe a
função pretendida.
Transição do Produto
 PORTABILIDADE: esforço necessário para transferir o
programa de um ambiente de hardware/software para outro.
 REUSABILIDADE: o quanto um programa (ou partes de um
programa) pode ser reutilizado em outras aplicações –
relacionado com o empacotamento e o escopo das funções
que o programa executa.
 INTEROPERABILIDADE: esforço necessário para integrar um
sistema a outro.
Fatores de qualidade ISO 9126:foi desenvolvido como uma
tentativa de identificar os atributos fundamentais de qualidade de
softwrae.
 Funcionalidade: o grau com que o software satisfaz ás
necessidades declaradas.
 Confiabilidade: a quantidade de tempo que o software
fica dispon[ivel para uso.
 Usabilidade: o grau de facilidade de utilização do
software.
 Eficiência: o grau de otimização do uso, pelo software,
dos recursos do sistema.
 Facilidade de manutenção: a facilidade com a qual uma
correção pode ser realizada no software.
 Portabilidade: a facilidade com a qual um softwrae pode
ser transposto de um ambiente a outro.
Para obter software de alta qualidade, devem ocorrer quatro
atividades:
 Processo e prática comprovados de engenharia de
software;
 Gerenciamento consistente de projetos;
 Controle global de qualidade; e
 A presença de uma infraestrutura para garantir a
qualidade.
Custos da qualidade: inclui todos os custos necessários para a
busca da qualidade ou para a execução de atividades
relacionadas à qualidade, assim como os custos causados pela
falta de qualidade. São divididos em:
 Custo de prevenção: incluem o custo de atividades de
gerenciamento, necessárias para planejar e coordenar
todas as atividades de controle e garantia da qualidade,
o custo de atividades técnicas adicionais para
desenvolver modelos completos de requisitos e de
projeto, custos de planejamento de testes e o custo de
todo o treinamento associado a essas atividades.
 Custo da avaliação: incluem atividades para a
compreensão aprofundada da condição do produto “a
primeira vez de” cada processo. Estão inseridos os
custos de avaliação técnica, custo para coleta de dados
e métricas, custoss de testes e depurações.
 Custo de falhas: são aqueles que desapareceriam
caso nenhum erro tivesse surgido antes ou depois da
entrega de um produto a clientes. Podem ser
subdivididos em falhas internas (ocorrem quando se
detecta um erro em um produto antes da entrega) e
falhas externas (associado aos defeitos encontrados
após o produto ter sido entregue ao cliente).
Um Sistema de Gestão da Qualidade compreende atividades
pelas quais uma organização identifica seus objetivos e
determina os processos e recursos necessários para alcançar os
resultados desejados. Seus princípios são: foco no cliente,
liderança, engajamento das pessoas, abordagem de processo,
melhoria contínua, tomada de decisão baseada em evidência e
gestão dos relacionamentos com as partes interessadas.
Existem quatro subcategorias de Gerência de Qualidade de
Software:
 Planejamento da Qualidade de Software.
 Garantia da Qualidade de Software.
 Controle da Qualidade de Software.
 Melhoria da Qualidade de Software.
O Controle de Qualidade é a aplicação desses processos de
qualidade visando eliminar os produtos que não atingiram o nível
de qualidade exigido.
A Garantia da Qualidade(QA, do inglês quality assurance) é a
definição de processos e padrões que devem conduzir a produtos
de alta qualidade e a introdução de processos de qualidade na
fabricação. Além disso, a garantia da qualidade consiste em um
conjunto de funções de auditoria e de relatórios que possibilita
uma avaliação da efetividade e da completude das ações de
controle de qualidade. O objetivo da garantia da qualidade é
fornecer ao pessoal técnico e administrativo os dados
necessários para serem informados sobre a qualidade do
produto, ganhando, portanto, entendimento e confiança de que as
ações para atingir a qualidade desejada do produto estão
funcionando.
Uma parte importante da garantia de qualidade é a definição ou
seleção de padrões que devem ser aplicados no processo de
desenvolvimento de software ou produtos de software. Como
parte desse processo de QA, devem ser escolhidas ferramentas e
métodos para suportar o uso desses padrões. Uma vez que os
padrões foram selecionados para uso, processos específicos de
projeto devem ser definidos para monitorar o uso dos padrões e
verificar se eles foram seguidos.
 Padrões de produto: aplicam-se ao produto de software
que está sendo desenvolvido. Eles incluem padrões de
documentos — como a estrutura dos documentos de
requisitos; padrões de documentação — como um
cabeçalho de comentário padrão para uma definição de
classe de objeto; e padrões de codificação — os quais
definem como uma linguagem de programação deve
ser usada.
 Padrões de processo: definem os processos que devem
ser seguidos durante o desenvolvimento de software.
As revisões de software são como um filtro para a gestão da
qualidade. Isso significa que as revisões são aplicadas em várias
etapas durante o processo de engenharia de software e servem
para revelar erros e defeitos que podem ser eliminados.
Um bug de software é um erro, falta, falha ou defeito em um
programa de computador ou sistema que faz com que produza
um resultado incorreto ou inesperado, ou se comportar de
maneiras inesperadas. Dito isso, vejamos as diferenças entre
essas terminologias:
 Falha: é o comportamento operacional do software diferente
do esperado pelo usuário. É um comportamento inesperado
do software. Basicamente, é a incapacidade do sistema em
executar a função esperada.
 Falta: Uma etapa ou definição de dados incorreta em um
software que se torna o motivo do comportamento
imprevisto do aplicativo. Pode ser uma condição acidental
que não está documentada e você somente a descobre
quanto é executada.
 Defeito: É uma inconsistência no software, algo que foi
implementado de maneira incorreta, causando uma
anomalia no produto. Ele ocorre em uma linha de código,
como uma instrução errada ou um comando incorreto. O
defeito é a causa de um erro, porém se uma linha de código
que contém o defeito nunca executar, o defeito não vai
provocar um erro.
 Erro: Erro humano produzindo resultado incorreto. O erro
evidencia o defeito, ou seja, quando há diferença entre o
valor obtido e o valor esperado constitui um erro.
Métricas de revisão
 Esforço de preparação (EP): o esforço (homem/hora)
exigido para revisar um produto resultante antes da
reunião de revisão.
 Esforço de avaliação (EA): o esforço (homem/hora0 que
é despendido durante a revisão em si.
 Reformulação esforço (RE): o esforço (homem/hora)
dedicado à correção dos erros revelados durante a
revisão.
 Tamanho do artefato de software: uma medida do
tamanho do artefato de software que foi revisto.
 Erros secundários encontrados: número de erros
encontrados que podem ser classificados como tal.
 Erros graves encontrados: número de erros
encontrados que podem ser classificados como tal.
 Densidade de erros: representa os erros encontrados
por unidade do artefato de software revisto.
Revisões informais: podem ser um simples teste de mesa ou
uma reunição informal, e já pode ser considerada uma revisão.
Revisões técnicas formais: é a atividade de controle da
qualidade de software realizada por engenheiros. Os objetivos
são descobrir erros na função, lógica, implementação; verificar se
o software atende aos requisitos; garantir que o software foi
representado de acordo com os padrões; obter software que seja
desenvolvido de maneira uniforme e tornar os processos mais
gerenciáveis.
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.
A verificação e a validação incluem uma ampla gama de
atividades de Garantia de Qualidade de Software (SQA), como
revisões técnicas, auditorias de qualidade e configuração,
monitoramento de desempenho, simulação, estudo de
viabilidade, revisão de documentação, revisão de base de dados,
análise de algoritmo, teste de desenvolvimento, teste de
usabilidade, teste de qualificação, teste de aceitação e teste de
instalação.
O teste proporciona o último elemento a partir da qual a
qualidade pode ser estimada e os erros podem ser descobertos.
O papel de um Grupo Independente de Teste (ITG) é remover
os problemas associados ao próprio desenvolvedor executar os
testes. Eles trabalham juntos durante todo o projeto de software
para garantir que testes completos sejam realizados.
Estratégias de Testes de Software
 Teste de Unidade (Código): concentra-se em cada
unidade, como um componente, classe ou objeto do
webapp.
 Teste de Integração (Projeto): o foco está no projeto e
construção da arquitetura de software.
 Teste de Validação (Requisitos): os requisitos
estabelecidos como parte dos requisitos de
modelagem são validados em relação ao software
criado.
 Teste de Sistema (Engenharia de Sistemas): o software
e outros elementos são testados como um todo.
Um teste nunca termina, o encargo simplesmente passa do
engenheiro para o usuário final. Todas as vezes que o usuário
executa o programa no compurador, o programa está sendo
testado.
A abordagem da Engenharia de Software de Sala Limpa
sugere técnicas de uso estatístico que executa uma série de
testes derivados de uma amostragem estatística de todas as
execuções possíveis do programa por todos os usuários em uma
população escolhida.
Uma estratégia de teste de software terá sucesso quando os
testadores de software:
1) Especificarem os requisitos do produto de uma maneira
quantificável, muito antes de começar o teste.
2) Definirem explicitamente os objetivos do teste em
termos mensuráveis.
3) Entenderem os usuários do software e desenvolverem
um perfil para cada categoria de usuário.
 4) Desenvolverem um plano de teste que enfatize o teste
do ciclo rápido.
5) Criarem software robusto que seja projetado para
testar-se a si próprio.
6) Usarem revisões técnicas eficazes como filtro antes
do teste.
7) Executarem revisões técnicas para avaliar a estratégia
de teste e os próprios casos de teste.
8) Desenvolverem abordagem de melhora contínua para
o processo de teste.
Teste de unidade (software convencional): focaliza o esforço de
verificação na menor unidade de projeto do software (o
componente ou módulo). Focaliza a lógica interna de
processamento e as estruturas de dados dentro dos limites de um
componente. Esse teste é simplificado quando um componente
com alta coesão é projetado.
Teste de integração: é uma técnica sistemática para construir a
arquitetura de software ao mesmo tempo que conduz testes para
descobrir erros associados com as interfaces. O objetivo é
construir uma estrutura de programa determinada pelo projeto a
partir de componentes testados em unidades.
 Teste de integração descendente (top/down):
abordagem incremental para a construção da
arquitetura de software. Os módulos são integrados
deslocando-se para baixo através da hierarquia de
controle, começando com o módulo principal. Verifica
os principais pontos de controle ou decisão antecipada
no processo de teste.
 Teste de integração ascendente (bottom/up): começa
com a construção e o teste módulos atômicos. Os
componentes são combinados em agregados (clusters)
e cada um dos clusters é testado usando um
pseudocontrolador.
 Teste de regressão: cada vez que um novo módulo é
acrescentado como parte do teste de integração, o
software muda. Esse teste é 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.
É impraticável e ineficiente reexecutar todos os testes.
Com isso, o conjunto de testes de regressão contém
três classes diferentes de caso de teste:
1) Amostra representativa dos testes que usam
todas as funções de software.
2) Testes adicionais que focalizam as funções
de software que podem ser afetadas pela
alteração.
3) Testes que focalizam os componentes do
software que foram alterados.
 Teste de fumaça: usada frequentemente quando
produtos de software são desenvolvidos. Deve usar o
sistema inteiro de ponta a ponta. Uma série de testes é
criada para expor erros que impedem a construção de
executar corretamente sua função. A finalidade deverá
ser descobrir erros bloqueantes que apresentam a mais
alta probabilidade de atrasar o cronograma do software.
Pode ser ascendente ou descendente.
Teste de validação: começa quando termina o de integração, ou
seja, quando os componentes individuais já foram exercitados, o
software montado como um pacote e os erros de interface já
foram descobertos ou corrigidos. O teste focaliza as ações
visíveis do usuário e saídas do sistema reconhecíveis pelo
usuário.
A validação é conseguida por meio de uma série de testes que
demonstram conformidade com os requisitos. Um plano de teste
descreve as classes de testes a serem conduzidas e um
procedimento de test define casos de teste específicos
destinados a garantir que todos os requisitos funcionais sejam
satisfeitos, todas as características comportamentais sejam
obtidas, requisitos de desempenho, documentação, e outros
requisitos como compatibilidade, recuperação e manutenibilidade.
Um elemento importante do processo de validação é a revisão de
configuração que garante que todos os elementos da
configuração do software tenham sido adequadamente
desenvolvidos, estejam catalogados e tenham os detalhes
necessários para amparar as atividades de suporte.
 Teste alfa: os usuários do software trabalham com a
equipe de desenvolvimento para testar o software no
local do desenvolvedor.
 Teste beta: um release do software é disponibilizado
aos usuários para que possam experimentar e levantar
os problemas que eles descobriram com os
desenvolvedores do sistema.
 Teste de aceitação: os clientes testam um sistema para
decidir se está ou não pronto para ser aceito pelos
desenvolvedores de sistemas e implantado no ambiente
do cliente.
Teste de sistema: é uma série de diferentes testes, cuja
finalidade primária é exercitar totalmente o sistema. Todos
funcionam no sentido de verificar se os elementos do sistema
foram integrados adequadamente e executam as funções a eles
alocadas.
 Teste de recuperação: força o software a falhar de
várias formas e verifica se a recuperação é executada
corretamente.
 Teste de segurança: tenta verificar se os mecanismos
de proteção incorporados ao sistema vão de fato
protegê-lo contra caesso indevido.
 Teste de esforço (estresse): servem para colocar os
programas em situações anormais. Usa o sistema de
maneira que demande recursos em quantidade,
frequência ou volumes anormais.
 Teste de desempenho: é feito em todas as etapas no
processo de teste.Os testes de desempenho precisam
ser projetados para assegurar que o sistema possa
processar a carga a que se destina. Isso normalmente
envolve a execução de uma série de testes em que
você aumenta a carga até que o desempenho do
sistema se torne inaceitável.
 Teste de disponibilização (configuração): exercita o
software em cada ambiente na qual ele deve operar.
Examina todos os procedimentos de instalação que
serão usados pelos clientes e toda documentação que
será usada para fornecer o software para os usuários
finais.
Mock objects são objetos com a mesma interface que os objetos
externos usados para simular sua funcionalidade. Mock objects
podem também ser usados para simular operações anormais ou
eventos raros.
A depuração ocorre como consequência de um teste bem
sucedido, isto é, quando um caso de teste descobre um erro, a
depuração é o processo que resulta na remoção do erro – não é
teste.
 Força bruta: é o mais comum e o menos eficiente.
Utiliza-se este método quando todos os outros falham.
  Rastreamento (backtracking): pode ser usado com
sucesso em pequenos programas. O código fonte é
investigado retroativamente (começando do ponto onde
o sintoma foi descoberto) até que a causa seja
encontrada.
 Eliminação da causa: é manifestada por indução ou
dedução e introduz o conceito de particionamento
binário.
Fundamentos de teste de software – Testabilidade: é a facilidade
com que um programa pode ser testado. As seguintes
caracteristicas levam a um software testável.
 Operabilidade: quanto melhor funcionar, mais
eficientemente pode ser testado.
 Observabilidade: o que você vê é o que você testa.
 Controlabilidade: quanto melhor pudermos controlar o
software, mais o teste pode ser automatizado e
otimizado.
 Decomponibilidade: controlando o escopo do teste,
podemos isolar problemas mais rapidamente e executar
um reteste mais racionalmente.
 Simplicidade: quanto menos tiver que testar, mais
rapidamente podemos testá-lo.
 Estabilidade: quanto menos alterações, menos
interrupções no teste.
 Compreensibilidade: quanto mais informações tivermos,
mais inteligente será o teste.
Teste de Caixa Preta (teste comportamental): utiliza uma visão
externa, em que conhecendo a função especificada para qual um
produto foi projetado para realizar, podem ser feitos testes que
demonstram que cada uma das funções é totalmente operacional,
embora ao mesmo tempo procurem erros em cada função. Faz
referência a testes realizados na interface do software,
examinando alguns aspectos fundamentais de um sistema, com
pouca preocupação em relação a estrutura lógica interna do
software.
Teste de Caixa Branca (teste de caixa de vidro): utiliza uma
visão interna, em que conhecendo o funcionamento interno de um
produto, podem ser realizados testes para garantir que tudo se
encaixa, ou seja, que as operações internas foram realizadas de
acordo com as especificações e que todos os componentes
internos foram adequadamente exercitados. Fundamenta-se em
um exame rigoroso do detalhe procedimental. Os caminhos
lógicos do software e as colaborações entre os componentes são
testados exercitando conjuntos específicos de condições e/ou
ciclos. Poderia-se utilizar os testes exaustivos neste cenário para
validar cada caminho lógico, porém é impraticável processar
todos os caminhos possíveis de um sistema grande.
Medida: proporciona uma indicação quantitativa de extensão,
quantidade, capacidade ou tamanho de algum atributo de um
produto ou processo. Quando é coletado um único ponto de
dado.
Medição: é o ato de determinar uma medida. Atribui números ou
simbolos a atributos de entidades no mundo real. Coleção de um
ou mais pontos de dados.
Métrica: é uma medida quantitativa do grau com a qual um
sistema, componente ou processo possui determinado atributo.
Relaciona as medidas individuais de alguma maneira.
Um engenheiro coleta medidas e desenvolve métricas para obter
indicadores. Um indicador é uma métrica ou combinação de
métricas que proporcionam informações sobre o processo de
software. Proporciona informações que permitem ao gerente de
projeto ou aos engenheiros ajustar o processo, o projeto ou o
produto para incluir melhorias.
Um processo de medição pode ser caracterizado por 5 atividades
(principios):
1) Formulação: a criação de medidas e métricas de
software apropriadas para a representação do software
considerado.
2) Coleção: o mecanismo usado para acumular dados
necessários para criar as métricas formuladas.
3) Análise: a computação das métricas e a aplicação de
ferramentas matematicas.
4) Interpretação: a avaliação das métricas que resultam
em informações sobre a qualidade da representação.
5) Feedback: recomendações derivadas da interpretação
de métricas de produto transmitidas para a equipe de
software.
O paradigma Meta / Questão / Métrica (Goal / Question / Metric
– GQM) foi desenvolvido como uma técnica para identificar
métricas significativas para qualquer parte do processo de
software. O GQM enfatiza a necessidade de:
(1) estabelecer um objetivode medição explícita que é específico
para a atividade do processo ou característica de produto que
deve ser avaliada,
(2) definir um conjunto de questões que devem ser respondidas
para atingir o objetivo e
(3) identificar métricas bem formuladas que ajudam a responder a
essas questões.
Um conjunto de atributos que deverão ser abrangidos por
métricas, de software efetivas. A métrica derivada e as medições
que levam até ela deverão ser:
 Simples e computáveis: deverá ser relativamente fácil
aprender a derivar a métrica, e sua computação não deve
demandar esforço ou tempo fora do normal.
 Empiricamente e intuitivamente persuasiva: a métrica
deverá satisfazer as ideias do engenheiro sobre o atributo
do produto considerado.
 Consistente e objetiva: a métrica deverá sempre produzir
resultados que não sejam ambíguos.
 Consistente no seu uso das unidades e dimensões: a
computação matemática da métrica deverá usar medidas
que não resultem em combinações bizarras de unidades.
 Independente da linguagem de programação: as
métricas deverão ser baseadas no modelo de requisitos,
modelo de projeto ou na própria estrutura do programa.
Elas não deverão ser dependentes dos caprichos da
sintaxe ou semânticas das linguagens de programação.
 Um mecanismo efetivo para feedback de alta qualidade:
a métrica deverá fornecer informações que podem levar
Uma métrica de software é uma característica de um sistema de
software, documentação de sistema oou processo de
desenvolvimento que pode ser objetivamente medido. Podem ser:
 Métricas de controle (ou de processo): suportam os
processos de gerenciamento. São associados ao
processo de software.
 Métricas de previsão (ou de produto): ajudam a prever
as características do software. Estão associadas ao
software em si.
Métricas de produto: são métricas de previsão usadas para
medir atributos internos de um sistema de software. Permitem ao
gerente de projeto avaliar o estado de um projeto em andamento.
Dividem-se em duas classes:
 1) Métricas dinâmicas: são coletadas por meio de
medições efetuadas de um programa em execução.
Ajudam a avaliar a eficiência e a confiabilidade de um
programa.
2) Métricas estáticas: são coletadas por meio de medições
feitas de representações do sistema, como projeto, o
programa ou a documentação. Ajudam a avaliar a
complexidade, a compreensibilidade e a manutebilidade
de um sistema ou componentes de um sistema de
software.
Métricas de processo: são coletadas através de todos os
projetos e sobre longos períodos de tempo. Sua finalidade é
proporcionar uma série de indicadores de processo que levam à
melhoria do processo de software no longo prazo.
1) Métricas privadas: pode incluir taxa de defeito por
individuo, por componente e erros encontrados durante
o desenvolvimento.
Atenção! Algumas métricas de processo são privadas
para a equipe de projeto de software, mas são públicas
para todos os membros da equipe.Exemplos incluem
defeitos relatados para funções principais do software
(que foram desenvolvidas por vários profissionais),
erros encontrados durante revisões técnicas, e linhas
de código ou pontos de função por componente ou
função. A equipe examina esses dados para descobrir
indicadores que podem melhorar o desempenho da
equipe.
2) Métricas públicas: geralmente assimilam informações
que originalmente eram privadas aos individuos e
equipes. Taxas de defeito em nível de projeto, esforço,
prazos agendados, e dados relacionados são coletados
e avaliados tentando descobrir indicadores que podem
melhorar o desempenho do processo organizacional.
Qualidade de software – CMMI 1.3
CMMI: é um modelo de referência que contém práticas
necessárias à maturidade em disciplinas específicas. Tem como
principal objetivo fornecer diretrizes baseadas em melhores
práticas para a melhoria dos processos e habilidades
organizacionais, cobrindo o ciclo de vida de produtos e serviços
completos, nas fases de concepção, desenvolvimento, aquisição,
entrega e manutenção. Suas abordagens envolvem a avaliação
da maturidade da organização ou a capacitação das suas áreas
de processo, o estabelecimento de prioridades e a
implementação de ações de melhoria. Oferece duas abordagens
(formas de representação) distintas para a sua implementação:
abordagem por estágios e abordagem contínua.
 Benefícios: custo, prazo, produtividade, qualidade,
satisfação dos clientes e retorno sobre o investimento.
O processo inclui 3 disciplinas ou corpos de conhecimento (body
of knowledges), sendo elas:
 Engenharia de sistemas (SE): cobre a parte de
desenvolvimento de software.
 Engenharia de software (SW): cobre o desenvolvimento de
sistemas completos, ou seja, a parte de software e
hardware.
 Desenvolvimento integrado de produtos e processos
(IPPD): preza pela colaboração entre a equipe de
desenvolvimento e de produção para satisfazer as
expectativas dos clientes.
 Fornecimento de fornecedores (SS): cobre a parte de
contratações críticas para o desenvolvimento de um
determinado software.
Constelação: é uma coleção de componentes gerada a partir do
framework CMMI, que engloba um modelo fundamental, seus
materiais de treinamento e documentação relacionada a
avaliações, abrangendo uma área de interesse específica.
A expansão das constelações para conteúdos específicos
adicionais é feita através de adições.
 CMMI para Desenvolvimento (CMMI-DEV): provê diretrizes
para monitorar, mensurar e gerenciar processos de
desenvolvimento.
 CMMI para Serviços (CMMI-SVC): provê diretrizes para
entrega de serviços dentro das organizações e para clientes
externos.
 CMMI para Aquisições (CMMI-ACQ): provê diretrizes para
suporte às decisões relacionadas à aquisição de produtos e
serviços.
Principais componentes da estrutura do CMMI
1) Áreas de processo: conjunto de práticas inter-
relacionadas que, quando executadas coletivamente,
satisfazem um conjunto de metas consideradas
importantes para realizar melhorias significativas em
uma determinada área.
2) Metas específicas: metas relacionadas a uma
determinada área de processo que descrevem o que
deve ser realizado para assegurar que esta esteja
efetivamente implementada.
3) Práticas específicas: descrições das atividades
consideradas importantes para o atendimento de suas
respectivas metas específicas. Podem ser detalhadas
em subpráticas e possuem como saídas os produtos de
trabalho típicos.
4) Metas genéricas: metas comuns, compartilhadas por
múltiplas áreas de processo, que, quando atingidas
dentro de uma área de processo específica, podem
indicar se estão sendo planejadas e implementadas de
forma efetiva, replicável e controlada.
5) Práticas genéricas: descrições das atividades
consideradas importantes para o atingimento das suas
respectivas metas genéricas e que garantem a
institucionalização efetiva, repetível e controloda das
áreas de processo. Podem ser divididas em subpráticas
e conter derivações específicas (elaborações)
relacionadas a cada área de processo em que são
aplicadas.
6) Componentes informativos de suporte: informações
adicionais necessárias para a descrição de um
componente:
 Notas: incluem detalhamento, fundamentação
teórica ou restrições/premissas relacionadas
ao componente.
 Exemplos: texto ou lista de itens para melhor
clarificar um conceito ou atividade descrita.
 Referências: indicação de que há informações
adicionais ou mais detalhadas para um
componente na descrição de outras áreas de
processo relacionadas.
Classificação dos componentes do modelo CMMI
 Requeridos: absolutamente necessários para a
implementação de uma área de processo. Ex: metas
específicas e metas genéricas.
 Esperados: compõem uma implementação típica de uma
área de processo, porém aceitando alternativas que
produzam resultados satisfatórios. Ex: práticas específicas
e práticas genéricas.
 Informativos: auxiliam no entendimento detalhado das
metas e práticas, e das formas como podem ser
implementadas. Ex: subpráticas, notas, referências,
exemplos de produtos de trabalho.
Áreas de processo
O CMMI sugere que suas 22 áreas de processo sejam agrupadas
em 4 categorias de afinidade:
1) Gestão de processo: agrupa áreas de processos que
manipulam processos no âmbito da organização,
permeando todos os projetos. Engloba as seguintes áreas
de processo:
 Foco no processo organizacional (OPF): planejar,
implementar e entregar melhorias no processo
organizacional, com base no claro entendimento dos
seus pontos fortes e fracos.
 Definição do processo organizacional (OPD):
estabelecer e manter uma biblioteca (re)utilizável de
componentes do processo organizacional, incluindo
políticas, descrições de processos, modelos de ciclos
de vida, critérios e diretrizes para adaptação do
processo, repositório de métricas e demais itens de
documentação relacionados.
 Treinamento organizacional (OT): desenvolver as
habilidades e o conhecimento das pessoas, de forma
que elas possam desempenhar seus pápeis no
processo organizacional de forma efetiva.
 Desempenho do processo organizacional (OPP):
estabelecer e manter uma visão quantitativa do
desempenho dos processos padrões e prover
modelos e baselines de desempenho, visando
melhorar a gestão dos projetos através de métricas de
processo e produto.
 Gestão do desempenho organizacional (OPM):
gerenciar proativamente o desempenho da
organização para atingir os seus objetivos de negócio.
2) Gestão de projeto: envolve áreas de processo que tratam
aspectos de planejamento, monitoriação e controle
relacionados exclusivamente a projetos. Engloba as
seguintes áreas de processo:
 Planejamento do projeto (PP): estabelecer e manter
planos que definam as atividades dos projetos,
envolvendo a elaboração de estimativas, o
estabelecimento do nível adequado de interação com
os grupos envolvidos e a obtenção de compromissos.
 Controle e monitoração do projeto (PMC): permitir
uma visibilidade adequada do progresso do projeto,
de forma que possam ser tomadas ações corretivas
apropriadas quando o seu desempenho apresentar
desvios significativos em relação ao planejado.
 Gestão do acordo com o fornecedor (SAM): gerenciar
a aquisição de produtos de fornecedores externos
para os quais existe um acordo formal.
 Gestão integrada do projeto (IPM): planejar e
gerenciar o projeto e o envolvimento dos principais
grupos interessados, de acordo com um processo
definido e integrado, derivado do processo padrão da
organização.
 Gestão de requisitos (REQM): gerenciar os requisitos
técnicos e não técnicos absorvidos ou gerados por um
projeto, identificando as inconsistências em relação
aos planos e produtos do projeto e tratando de forma
adequada as mudanças necessárias e seus impactos.
 Gestão de riscos (RSKM): identificar problemas
potenciais antes de sua ocorrência, para que possam
ser planejadas e executadas ações de tratamento de
riscos, visando a mitigação de impactos negativos nos
objetivos, ao longo do ciclo de vida do projeto ou
produto.
 Gestão quantitativa do projeto (QPM): gerenciar
quantitativamente (através de métricas) o processo
definido do projeto, visando o atingimento dos
objetivos preestabelecidos de desempenho de
qualidade e processo.
3) Engenharia: agrupa áreas de processo relacionadas ao
ciclo de vida de desenvolvimento e manutenção de
produtos, assim como à garantia do seu funcionamento e
da sua aderência às especificações. Engloba as seguintes
áreas de processo:
 Desenvolvimento de requisitos (RD): gerar, analisar,
definir e validar requisitos do cliente, assim como seus
desdobramentos para os requsitos do produto e dos
seus componentes, em conformidades com as
necessidades dos grupos interessados.
 Solução técnica (TS): projetar, desenvolver e
implementar alternativas de soluções para o
atendimento de requisitos preestabelecidos, podendo
envolver a criação e/ou aquisição de produtos,
componentes de produtos ou serviços relacionados.
 Integração do produto (PI): montar o produto a partir
dos seus componentes e entregá-lo ao cliente,
garantindo o seu funcionamento de forma integrada
em relação a todas as interfaces internas e externas.
 Verificação (VER): garantir que um determinado
produto satisfaça os respectivos requisitos para os
quais foi desenvolvido.
 Validação (VAL): demonstrar que um determinado
produto ou componente de produto atinge os
resultados esperados depois de colocado em
operação no ambiente final.
4) Suporte: qualifica processos cujas atividades são
distribuídas ao lngo de um projeto de desenvolvimento ou
manutenção de projeto, e cujos objetivos são atingidos
indiretamente através de sua execução.
 Gestão da configuração (CM): estabelecer e manter a
integridade dos produtos de trabalho através da
identificação, do controle, da verificação e do
monitoramento constante da situação da sua
configuração.
 Garantia da qualidade do processo e do produto
(PPQA): prover aos integrantes das equipes uma
visibilidade mais clara do andamento dos processos e
dos produtos gerados, através de avaliações objetivas
em relação às especificações, da identificação de não
conformidades e do acompanhamento de ações
corretivas.
 Medição e análise (MA): desenvolver e manter uma
capacitação de medição para suportar as
necessidades de informações gerenciais, em termos
de conceitos, técnicas e mecanismos de execução.
 Análise de decisões e resolução (DAR): analisar
possíveis decisões utilizando um processo de
avaliação formal, que considera alternativas
identificadas em relação a critérios preestabelecidos.
  Análise e resolução de causas (CAR): identificar
causas de defeitos e outros problemas e tomar ações
corretivas para prevenir a sua ocorrência futura.
Abordagem de implementação por estágios: pode ser
considerada uma evolutiva direta do CMM, uma vez que também
é baseada em 5 níveis de maturidade.
Nível de maturidade: pode ser considerado um degrau
evolucionário para a melhoria do processo organizacional como
um todo e consiste em práticas específicas e genéricas que
integram um conjunto predefinido de áreas de processo. O
cumprimento das metas específicas e genéricas correspondentes
a essas áreas de processo é um pré-requisito para o atingimento
do nível de maturidade correspondente.
 Nível 2 (Gerenciado): o foco é direcionado para práticas de
gestão de projetos, indicando que, em uma organização
ainda imatura, é mais prioritário aprender e planejar,
controlar e gerenciar (envolve gerenciar, durante o seu
andamento, os requisitos estabelecidos junto aos grupos
interessados, a qualidade e a integridade dos produtos
gerados, a aderência aos processos existentes e os
acordos formalizados com os fornecedores envolvidos) os
produtos do que investir em técnicas e metodologias de
desenvolvimento de produtos. (Áreas de processo: REQM,
PP, PMC, SAM, MA, PPQA e CM)
1. Maior grau de previsibilidade para os projetos;
2. Melhor controle dos acordos com fornecedores de
produtos e serviços;
3. Maior segurança na criação de uma base de
medições operacionais.
 Nível 3 (Definido): o foco está no processo de engenharia
de produtos, que espelha as fases de um ciclo de vida
padrão: concepção (desenvolvimento de requisitos),
análise e desenho (solução técnica), testes e
implantação (integração do produto, verificação e
validação). Fomenta a criação de um ambiente
organizacional orientado à integração entre equipes de
trabalho e ao compartilhamento de conhecimentos e
habilidades. (Áreas de processo: RD, TS, PI, VER, VAL,
OPF, OPD, OT, IPM, RSKM e DAR)
1. Maior robustez na execução dos processos e nos
produtos, através do uso da integração do produto,
verificação, vallidação e de técnicas de gestão de
riscos;
2. Maior envolvimento da organização no
estabelecimento de um ambiente orientado à
integração das equipes;
3. Melhoria na comunicação interna e externa;
4. Maior acurácia nas tomadas de decisão.
 Nivel 4 (Gerenciado Quatitativamente): a gestão
quantitativa baseada em medições e indicadores cobre, de
forma integrada, todo o conjunto de processos
organizacionais, assim como os projetos e respectivos
produtos, como instrumento de suporte para o
atendimetento dos objetivos de desempenho de processo e
de qualidade. (Áreas de processo: OPP e QPM)
1. Maior precisão no gerenciamento dos projetos,
através da utilização de indicadores de
desempenho baseados em medições extraídas
desde o nível 2.
 Nível 5 (Otimizado): o conceito de inovação organizacional
integra os processos de gestão de mudanças tanto em
processos como na tecnologia. (Áreas de processo: OPM e
CAR)
1. Tratamento adequado de todas as formas de
inovações e mudanças possíveis, tanto nos
processos quanto na tecnologia, e de seus reflexos
no processo organizacional;
2. Maior acurácia no tratamento dos problemas,
através da resolução das causas comuns de
variação.
**É mais recomendada para organizações que já estão
familiarizadas com a incorporação de melhorias nos seus
processos organizacionais através de grandes saltos de
qualidade.
Abordagem contínua de implementação: através dessa, o
CMMI permite que cada uma de suas áreas de processo seja
implementada de forma independente e evolutiva, agrupando
suas práticas genéricas e específicas em 4 níveis de capacidade:
 Nivel 0 (Incompleto): o processo não é executado ou é
parcialmente executado, ou seja, uma (ou mais) das metas
específicas de sua área de processo não é satisfeita.
 Nível 1 (Executado): o processo satisfaz todas as metas
específicas de sua área de processo e realiza o trabalho
necessário para gerar os seus produtos.
 Nível 2 (Gerenciado): o processo é planejado e executado
de acordo com políticas organizacionais, utiliza pessoal
habilitado e recursos adequados para gerar saídas de
forma controlada e envolve os grupos interessados
adequados, além de ser monitorado, controlado, revisado,
avaliado quanto à conformidade com sua descrição e ao
desempenho previsto nos seus planos.
 Nível 3 (Definido): o processo é gerenciado e adaptado a
partir de um conjunto de processos padronizados da
organizaçã que, por sua vez, também evoluem
continuamente.
Cada nível de capacidade tem apenas uma meta genérica que
descreve o grau de institucionalização que a organização deve
atingir no processo através das práticas genéricas relacionadas.
Modelagem de Processo de Negócio – BPM
A Gestão de Processos de Negócio (Business Process
Management – BPM) é uma abordagem disciplinar ou um ciclo
contínuo para planejar, modelar, simular, executar, monirtorar e
melhorar processos de negócio (automatizados ou não) para
alcançar os resultados pretendidos consistentes (pretendidos) e
alinhados com os objetivos estratégicos de uma
organização.Possui foco no cliente.
 Projeto/Planejamento: a etapa do planejamento é a que
define qual o objetivo do BPM, quais processos serão
melhorados, qual a metodologia, as ferramentas e as áreas
envolvidas.
 Modelagem: depois da análise anterior, já se tem ideia das
falhas que precisam ser corrigidas. Por isso, essa etapa
cuida do mapeamento de todo o fluxo de processo e do
desenho de todo o desenvolvimento processual a partir da
cadeia de valor estabelecida.
 Simulação: com a ajuda de uma ferramenta de simulação,
o processo aprimorado é testado para constatar se está
rodando como o previsto.
 Execução: essa etapa é a que move a empresa. A
implantação conta com a ajuda de toda a equipe em aceitar
as novas mudanças organizacionais não sofrendo muito
impacto com elas. Por isso, a gestão de processos deve
estar atenta nessa fase, que é crucial para o andamento do
ciclo BPM.
 Monitoramento: os indicadores de desempenho mostram
se o ciclo BPM está sendo realmente eficiente para a
empresa. Caso haja algum desvio, a empresa deve
procurar resolvê-lo imediatamente, para dar andamento ao
resto do processo.Possui as métricas: gestão de tempo,
qualidade, custo e capacidade.
 Melhoria: o último passo é buscar, sempre que possível,
melhorias no fluxo processual da organização. A avaliação
da situação atual pode ser feita rotineiramente e
aprimoramentos devem ser propostos por qualquer
colaborador que faça parte desse processo.
Vantagens do BPM
 Otimização de recursos;
 Redução de desperdícios (custos);
 Redução nos tempos de duração dos processos;
 Aumento da governabilidade;
 Redução do risco;
 Alinhamento entre negócios e tecnologia;
 Inovar em serviços e produtos; e
 Transformar a experiência do cliente/cidadão.
Atenção!! Reduzir custos e desperdícios, aumentar a
produtividade, aumentar a satisfação do cidadão, buscar
inovações, controlar os recursos e alinhar/integrar as áreas de
negócio são motivadores para implementar o BPM.
Processo: conjunto de atividades relacionadas com o objetivo de
atingir resultados de forma padronizada. É um conjunto definido
de atividades ou comportamentos executadps por humanos ou
máquinas para alcançar uma ou mais metas. São disparados por
eventos específicos e apresentam um ou mais resultados que
podem conduzir ao término do processo ou a transferência de
controle para outro processos.
Negócio: refere-se a pessoas que interagem para executar um
conjunto de atividades de entrega de valor para os clientes e
gerar retorno às partes interessadas.
Um processo de negócio é definido como um trabalhado ponta-
a-ponta, interfuncional e até mesmo interoganizacional, que
entrega valor aos clientes ou apoia/gerencia os outros processos
que agregam valor.
BPM: disciplina gerencial que integra estratégias e objetivos de
uma organização com expectativas e necessidades de clientes,
por meio do foco em processos ponta a ponta. BPM engloba
estratégias, objetivos, cultura, estruturas organizacionais, papéis,
políticas, métodos e tecnologias para analisar, desenhar,
implementar, gerenciar desempenho, transformar, e estabelecer
governança de processos.
Tipos de processos
 Processos de negócio (primários ou essenciais): esses
processos entregam valor ao cliente e estão relacionados à
atividade fim da organização. Estão associados à criação
de um produto/serviço, marketing e transferência ao cliente.
Design de serviços e produtos, marketing, comercialização,
“fabricação de produtos”, “entrega de serviços” e suporte ao
cliente.
 Processos de suporte: provêm suporte a processos
primários, geralmente pelo gerenciamento de recursos e ou
infraestrutura requerida pelos processos primários. Folha de
pagamento, pagamento de contas, suporte de TI, compras
e manutenção predial.
 Processos de gestão: são relacionados ao planejamento,
medição, monitoramento e controle das atividades de
negócio. São necessários para que os processos de
negócio e de suporte tenham
eficácia/eficiência.Gerenciamento de projetos,
gerenciamento da estratégia, gerenciamento de custos,
gerenciamento de desempenho e gerenciamento de
atividades.
Eficácia: ocorre quando as atividades planejadas são realizadas e
os resultados esperados alcançados. Não se preocupa
diretamente com os recursos envolvidos para obter os resultados
do processo.
Eficiência: ocorre quando as atividades planejadas são realizadas
e os resultados esperados alcançados, utilizando o menor
recurso possível. Fornece uma medida da relação
custo/benefício para a realização dos processos.
Efetividade: conceito mais amplo que busca avaliar os
resultados das ações implantadas, verificando os reais
benefícios que as ações trarão. Procura avaliar se o que foi
realizado deveria mesmo ser feito e quais seus impactos.
Modelagem de Processos - BPMN
Combina um conjutno de habilidades e técnicas que permite
compreender, comunicar e gerenciar os componentes de
processos de negócio. Conjunto de atividade envolvidas na
representação de processos e pode ter uma perspectiva de
ponta-a-ponta ou segmentada. Possui as técnicas de
mapeamento: entrevistas, questionários, reuniões, workshops,
observação de campo, análise da documentação existente e
coleta de evidências.
Modelo: é uma representação simplificada de uma coisa, um
conceito ou uma atividade. Podem ser matemáticos, gráficos,
físicos, narrativos ou alguma combinação desses elementos.
BPMN – Business Process Model and Notation: é uma notação
gráfica que permite descrever as etapas e o fluxo ponta a ponta
de um processo de negócio.
BPMS – Business Process Management Suite: é uma ferramenta
complexa que, em linhas gerais, é responsável pela realização de
grande parte do ciclo de vida do gerenciamento de processos de
negócio.
Atividade: representam a decomposição de um processo em
suas principais atividades. Normalmente representamos a lógica
e as regras de negócio neste nível de detalhe, evitando os
detalhes operacionais. É um trabalho realizado na organização
composto de:
 Entrada: objeto real ou abstrato ou informação que
sofrerá transformação pela atividade.
  Regras de negócio: objeto ou informação que define ou
restringe algum aspecto de um negócio e representa
conhecimento do negócio. Ela governa como o negócio
deve ser realizado.
 Saídas: objeto ou informação produzida como resultado
da execução da atividade.
 Executor: recursos (equipamentos/pessoas)
necessários para execução da atividade.
Tipos de atividades
 Valor agregado: atividades que geram valor para o
processo e contribuem de forma positiva para seu trabalho.
 Handoff: atividades que transferem o controle do processo
para outro departamento ou organização.
 Controle: atividades que asseguram que os processos
alcancem as metas planejadas, estejam dentro da
tolerância desejada e de acordo com os padrões e
requisitos estabelecidos.
Tarefas: é uma decomposição ou detalhamento de uma
atividade. É a menor unidade de trabalho com significado
executada por uma pessoa ou máquina.
Atenção!! Um processo é formado por – entrada, atividade ou
tarefa, saída, regras e recursos.
Visão sistêmica: procura enxergar os processos percorrendo as
funções do organograma, em vez de analisar apenas a hierarquia
da organização. O cliente enxerga o produto gerado pelo
processo, que é o que atende efetivamente sua necessidade.
Macrofluxo: cria uma simples fotografia de um processo usando
dois níveis de detalhe. O primeiro nível captura os maiores
passos no processo e o segundo nível lista os subpassos que
estão dentro de cada passo maior.
(Padrões de modelagem e notações BPMN)
Conceitos
 Piscina (pool): onde os processos estão contidos.
 Raia (lane): definem as equipes de pessoas que
realizam as atividades e tarefas.
 Eventos: representa algo que ocorre ou pode ocorrer
durante o curso de um processo. Podem ser eventos de
início, eventos intermediários e/ou eventos de fim
(conforme ordem na imagem).
 Atividade/tarefas: representam o trabalho realizado
dentro de uma organização.
 Gateway (desvios): são elementos utilizados para
controlar pontos de divergência e convergência de um
fluxo.
 Fluxos de sequencia: representam o controle do fluxo
das atividades – da esquerda para a direita ou de cima
para baixo.
 Fluxo de mensagem: representam a interação entre
várias entidades ou processos distintos.
Tipos de atividades/tarefas
 Usuário: realizada por uma pessoa ou usuário com ajuda
de um sistema ou software.
 Manual: realizada por uma pessoal ou usuário sem ajuda
de um sistema ou software.
 Serviço: utiliza ou executa um serviço externo (web service
ou outra aplicação).
 Script: executa uma expressão ou script.
 Regra de negócio: executada por um sistema sem a
intervenção humana.
 Envio de mensagem: envia uma mensagem a um
participante externo.
 Recebimento de mensagem: aguarda o recebimento de
uma mensagem a ser enviada por um participante externo.
Subprocesso: é composta por um conjunto de atividades em
uma sequência lógica (processo) para garantir que essas
atividades possam ser analisadas em um nível mais detalhado.
Pode ser observada de forma expandida ou
minimizada/contraído.
UML 2.x (visão geral, modelos e diagramas)
Modelagem de Sistemas é o processo de desenvolvimento de
modelos abstratos de um sistema em que cada modelo apresenta
uma visão ou perspectiva diferente do sistema. Geralmente
representa o sistema com algum tipo de notação gráfica, que,
atualmente, quase sempre é baseada na UML (Unified Modeling
Language).
Os modelos são usados durante o processo de engenharia de
requisitos para ajudar a extrair os requisitos do sistema; durante o
processo de projeto, são usados para descrever o sistema para
os engenheiros que o implementam; e, após isso, são usados
para documentar estrutura e a operação do sistema.
Um modelo é uma abstração (simplificação da realidade) do
sistema a ser estudado e não uma representação alternativa dele.
Modelos de contexto: mostram que o ambiente inclui vários
outros sistemas automatizados. No entanto, eles não mostram os
tipos de relacionamentos entre os sistemas no ambiente e o
sistema que está sendo especificado. São usados com outros
modelos, como modelos de processo de negócio – descrevem os
processos humanos e automatizados em que os sistemas de
software específicos são usados.
Modelos de interação: ajudam a identificar os requisitos do
usuário. Destacam os problemas de comunicação que podem
surgir, ajudam a compreender se a estrutura proposta para o
sistema é suscetível de produzir o desempenho e a confiança
requerida do sistema.
Modelos estruturais: exibem a organização de um sistema em
termos de seus componentes e seus relacionamentos. Podem ser
modelos estáticos, que mostram a estrutura do projeto do
sistema, ou modelos dinâmicos, que mostram a organização do
sistema quando ele está em execução.
Modelos comportamentais: são modelos do comportamento
dinâmico do sistema quando está em execução. Eles mostram o
que acontece ou deve acontecer quando o sistema responde a
um estímulo de seu ambiente. Pode-se pensar nesse estímulo
como sendo – dados (alguns dados que chegam precisam ser
processados pelo sistema) e eventos (alguns eventos que
acontecem disparam o processamento do sistema).
O que é UML? É uma linguagem gráfica de modelagem para
visualizar, especificar, construir, documentar e comunicar
artefatos de sistemas complexos. A UML não é um processo,
nem uma metodologia, nem análise e projeto orientado a objeto
ou regras de projeto.
Atua em algumas aplicações, tais como:
 Sistemas de informações corporativas;
 Serviços bancários e financeiros;
 Telecomunicações;
 Transportes;
 Defesa/espaço aéreo;
 Vendas de varejo;
 Eletrônica médica;
 Científicos; e
 Serviços distribuídos baseados na web.
Para formar um modelo conceitual da linguagem é necessário
aprender sobre três elementos principais:
Blocos de construção: são divididos em itens (são abstrações),
relacionamentos (reúnem os itens) e diagramas (agrupam
coleções de itens).
Itens da UML: estruturais, comportamentais, de agrupamento e
anotacionais.
 Estruturais: são os SUBSTANTIVOS dos modelos. É a
parte estática, representando elementos conceituais ou
físicos. São classificados em sete tipos – classes,
interfaces, colaborações, casos de uso, classes ativas,
componentes e nós.
 Comportamentais: representam as partes dinâmicas
dos modelos. São os VERBOS, representando
comportamentos no tempo e no espaço. São
classificados em dois tipos – interação (mensagem) e
máquina de estado.
 De agrupamento: são as partes organizacionais dos
modelos de UML. São os blocos em que os modelos
podem ser decompostos – pacotes (mecanismo de
propósito geral para a organização de elementos em
grupos).
 Anotacionais: partes explicativas dos modelos UML.
São comentários, incluídos para descrever, esclarecer e
fazer alguma observação importante sobre qualquer
elemento do modelo – notas.
Relacionamentos: dependência, associação, agregação,
generalização e realização.
 Dependência: relacionamento semântico entre dois
itens, nos quais a alteração de um (o item
independente) pode afetar a semântica do outro (o item
dependente).
 Associação: é um relacionamento estrutural que
descreve um conjunto de ligações, as quais são
conexões entre os objetos.
 Agregação: é um tipo especial de associação
representando um relacionamento estrutural entre o
todo e sua parte (filha p/ mãe).
 Generalização: é um relacionamento de
especialização/generalização, nos quais os objetos dos
elementos especializados (os filhos) são substituíveis
por objetos do elemento generalizado (os pais).
 Realização: é um relacionamento semântico entre
classificadores, em que um classificador especifica um
contrato que outro classificador garante executar.
Diagramas: são apresentações gráficas de um conjunto de
elementos, geralmente representados como gráficos de vértices e
arcos. São classificados em nove tipos – classes, objetos,
pacotes, casos de uso, sequencias, colaborações, estados,
atividades, componentes e implantação.
 Diagrama de classes (modelo estrutural): é a espinha
dorsal da maioria dos métodos orientados a objeto,
inclusive a UML. Descrevem a estrutura estática do
sistema (entidades e relacionamentos). Mostram as
classes de objeto no sistema e as associações entre
elas.
 Diagrama de pacotes: organizam elementos do
sistema em grupos relacionados a fim de minimizar a
dependência entre eles.
 Diagrama de objetos: descrevem a estrutura estática
de um sistema em um determinado momento. Podem
ser usados para testar a precisão dos diagramas de
classes.

 Diagrama de caso de uso (modelo de interação):
modelam a funcionalidade do sistema através de atores
e casos de uso (são serviços ou funções fornecidas
pelo sistema aos seus usuários). Mostram as interações
entre um sistema e seu ambiente.
A modelagem de caso de uso é amplamente usada
para apoiar a elicitação de requisitos. Um caso de uso
pode ser tomado como um cenário simples que
descreve o que o usuário espera de um sistema. Cada
caso de uso representa uma tarefa discreta que envolve
a interação externa com um sistema.
 Diagrama de sequencia (modelo de interação):
descrevem as interações entre as classes através das
trocas de mensagens ao longo do tempo. Mostram as
interações entre os atores e o sistema, e entre os
componentes do sistema. Mostra a sequencia de
interações que ocorrem durante um caso de uso em
particular ou em uma instância de caso de uso.
 Diagrama de colaborações: representam as
interações entre objetos em termos de mensagens em
sequencia. Descrevem tanto a estrutura estática como
o comportamento dinâmico do sistema.
 Diagrama de estados: descrevem o comportamento
dinâmico do sistema em resposta a estímulos externos.
São especialmente úteis para modelar objetos reativos
cujos estados são disparados por eventos específicos.
Mostram como o sistema reage aos eventos internos e
externos.
 Diagrama de atividades (modelo de contexto): ilustram
a natureza dinâmica de um sistema modelando o fluxo
de controle de uma atividade para outra. Mostram as
atividades envolvidas em um processo ou no
processamento de dados.
Uma atividade representa uma operação em uma
classe do sistema que resulta na mudança do estado
do sistema.
Tipicamente são usados para modelar fluxo de trabalho
ou processos de negócios e funcionamento interno.
 Diagrama de componente: descrevem a organização
dos componentes físicos de software.
 Diagrama de implantação: descrevem os recursos
físicos em um sistema, incluindo nós, componentes e
conexões.
Padrões de Projeto
O projeto e implementação de software é um estágio do
processo no qual um sistema de software executável é
desenvolvido.
Projeto de software: é uma atividade criativa em que você
identifica os componentes de software e seus relacionamentos
com base nos requisitos do cliente.
Atenção!! Um projeto precisa ser modular, ou seja, o software
deve ser dividido logicamente em elementos ou subsistemas, de
modo que seja fácil de testar e manter. Deve conter
representações distintas de arquitetura, componentes, dados e
interfaces.
Implementação: é o processo de concretização do projeto como
um programa.
Para desenvolver um projeto de um sistema desde o conceito até
o projeto detalhado orientado a objeto, existem várias atitudes
que você precisa tomar:
 Compreender e definir o contexto e as interações
externas com o sistema;
 Projetar a arquitetura do sistema;
 Identificar os principais objetos do sistema;
 Desenvolver modelos de projeto; e
 Especificar interfaces.
Modelo de contexto do sistema: é um modelo estrutural, que
demonstra os outros sistemas no ambiente do sistema a ser
desenvolvido.
Modelo de interação: é um modelo dinâmico, que mostra como
o sistema interage com seu ambiente quando ativo.

O padrão de projeto é uma descrição do problema e da
essência de sua solução, de modo que a solução possa ser
reusada em diferentes contextos. O padrão não é uma
especificação detalhada. Em vez disso, você pode pensar nele
como uma descrição de conhecimento e experiência, uma
solução já aprovada para um problema comum.
Padrões e linguagens de padrões são formas de descrever as
melhores práticas, bons projetos e capturar a experiência de uma
forma que torne possivel a outros reusar essa experiência.
Os quatro elementos essenciais de padrões de projeto foram
definidos pela “Gangue dos Quatro”:
 Um nome que seja uma referência significativa para o
padrão;
 Uma descrição da área do problema que explique
quando o modelo pode ser aplicado;
 A descrição da solução das partes da solução de
projeto, seus relacionamentos e suas
responsabilidades;
 Uma declaração das consequências/forças – os
resultados e compromissos – da aplicação do padrão.
Principios de padrão de projeto
 Principio aberto fechado: entidades de software como
classes, módulos e funções devem ser abertas para
expansão, mas fechadas para modificações.
 Principio inversão de dependência: módulos de alto
nível não devem depender de módulos de baixo nível.
Ambos devem depender de abstrações.
 Principio segregação de interfaces: os clientes não
devem depender de interfaces que eles não usam.
 Programe para uma inteface e não para uma
implementação: desta forma, você encapsula os
códigos que podem variar para que futuras alterações
não sejam complicadas e também forneça um único
ponto de alteração. Esse principio é a base de todos os
padrões.
 Dê preferência para o “tem um” à “é um”: dar
prioridade a composição.
 Encapsule o que varia: programe para interface à
implementação. Dessa forma seu código estará
preparado para o futuro de forma mais flexível e
extensível.
Padrões de criação
 Abstract Factory (KIT): fornece uma interface para a
criação de uma família de objetos relacionados ou
dependentes, sem especificar suas classes concretas.
 Builder: permite a separação da construção de um
objeto complexo da sua representação, de forma que o
mesmo processo de construção possa criar diferentes
representações. Diferencia-se do Abstract Factory pela
criação de objetos passo a passo, ao invés de criar
todos os objetos de uma só vez.
 Factory Method: define uma interface para a criação de
um objeto, mas deixa as subclasses decidirem qual
classe a ser instanciada. Permite postergar (deferir) a
instanciação em subclasses. Deixa as subclasses
escolherem quais objetos criarem (através de herança).
É o único voltado para o escopo de classe.
 Prototype: especifica objetos a serem criados usando
uma instância-protótipo e cria (clona) uma cópia a partir
desse protótipo.
 Singleton: garante que uma classe tenha somente uma
instância e fornece um ponto globar de acesso a
mesma.
Padrões estruturais
 Adapter (wrapper): converte interface de uma classe em
outra interface, esperada pelo cliente. Permite que
interfaces incompatíveis trabalhem em conjunto. É o
único padrão estrutural que trabalha com ambos os
escopos (classe e objeto).
 Bridge (handle/body): desacopla a abstração de sua
implementação, de modo que as duas possam variar
independentemente.
 Composite: compõe objetos em uma estrutura de
árvora para representar uma hierarquia parte/todo.
 Decorator (wripper): dinamicamente, adiciona nova
responsabilidade a objetos.
 Facede: fornece uma interface unificada para um
conjunto de interfaces de um subsistema.
 Flyweight: a intenção é usar o compartilhamento para
suportar uma grande quantidade de objetos de
granularidade fina. Use-o quando a quantidade de
objetos for muito grande.
 Proxy: fornece um substituto ou um marcador da
localização de um objeto para controlar o acesso a esse
objeto. Sua função é controlar a criação de objetos no
momento que realmente é necessário.
Padrões de comportamento
 Chain of Responsibility: evita o acoplamento do
remetente de uma solicitação ao seu receptor, ao dar a
mais de um objeto a oportunidade de tratar a
solicitação. A ideia é desacoplar o remetente e o
receptor, dando a oportunidade a múltiplos objetos para
tratar a solicitação.
 Command (action ou transaction): encapsula uma
solicitação como um objeto, desta forma permitindo que
clientes parametrizem diferentes solicitações, enfileirem
ou façam o registro (log) de solicitações e suportem
operações que podem ser desfeitas.
 Interpreter: dada uma linguagem, define uma
representação para sua gramática.
 Iterator (cursor): fornece uma maneira de acessar
sequencialmente os elementos de um objeto.
 Mediator: define um objeto que encapsula como um
conjunto de objetos interage. Objetos se comunicam
com o mediador de forma centralizada.
 Memento (token): sem violar o encapsulamento,
captura e externaliza o estado interno de um objeto de
modo que ele possa ser restaurado posteriormente.
 Observer (dependents, publish-subscribe): define uma
dependência um-para-muitos entre objetos, de modo
que, quando um objeto muda de estado, todos os seus
dependentes sejam atualizados.
 State: permite a alteração do comportamento de um
objeto quando ser estado interno é modificado.
 Strategy (policy): define uma família de algoritmos,
encapsula cada um deles para torná-los
intercambiáveis. Permite que o algoritmo varie
independente dos clientes que a utilizam.
 Template Method: define um esqueleto de um algoritmo
em uma operação, postergando a operação de alguns
passos para subclasses. Permite que subclasses
redefinam alguns passos sem mudar sua estrutura.
 Visitor: representa uma operação a ser executada sobre
os elementos da estrutura de um objeto. Permite definir
 uma nova operação sem mudar as classes dos
elementos sobre os quais opera.
Arquitetura em camadas
É um modelo de programação que permite a distribuição da
aplicação funcionalmente por três sistemas independentes:
 Componentes clientes em execução em estações de
trabalho;
 Processos em execução em servidores remotos;
 Coleção discreta de banco de dados, gerenciadores de
recursos e aplicações de mainframe.
Essa arquitetura tornou-se a padrão para sistemas corporativos
com base na web e, assim como a ideia da arquitetura em duas
camadas, são lógicas, ou seja, as camadas podem estar em
execução no mesmo servidor físico. A separação em camadas
lógicas torna os sistemas mais flexíveis, permitindo que as partes
possam ser alteradas de forma independente.
A primeira camada é a Camada de Apresentação, também
chamada de interface. Ela interage diretamente com o usuário e
possui componentes responsáveis pela apresentação e interação
do usuário.
A segunda camada é a Camada de Negócio, também chamada
de lógica empresarial, lógica da aplicação, regras de negócio e
funcionalidade. É onde a maioria do trabalho de processamento
ocorre. Varios componentes clientes podem acessar os
processos da segunda camada simultaneamente, portanto, essa
camada deve gerenciar suas próprias transações.
A terceira camada é a Camada de Dados, também chamada de
acesso a dados ou persistência. É composta pelo repositório das
informações e pelas classes que as manipulam. Essa camada
recebe as requisições da camada de negócios e seus métodos
executam essas requisições em um banco de dados. Uma
alteração no banco de dados altera apenas as classes da
camada de dados, mas o restante da arquitetura não seria
afetado por essa alteração.
Cada camada é normalmente mantida em um servidor específico
para tornar-se o mais escalonável e independente possível em
relação a outras camadas, estando entre as suas principais
características o eficiente armazenamento e a reutilização de
recursos.
Um web service é uma representação padrão para algum
recurso computacional ou de informações que pode ser usado
por outros programas, os quais podem ser recursos de
informações ou recursos de armazenamento.
Arquitetura Orientada a Serviços (SOA): são uma forma de
desenvolvimento de sistemas distribuídos em que os
componentes de sistema são serviços autônomos, executando
em computadores geograficamente distribuídos. Protocolos-
padrão baseados em XML, SOAP e WSDL foram projetados para
oferecer suporte à comunicação de serviço e à troca de
informações. Consequentemente, os serviços são plataforma e
implementação independentes de linguagem.
É uma arquitetura que define como funções de negócios distintas,
implementadas por sistemas autônomos, devem operar
conjuntamente para executar um processo de negócio. Cada
função de negócio(componente) é implementada como um
serviço.
Os protocolos de web service cobrem todos os aspectos das
SOA, desde os mecanismos básicos para troca de informações
de serviço (SOAP), até os padrões de linguagem de programação
(WSDL). Esses padrões são todos baseados em XML
(Linguagem de Marcação Extensível), uma notação legível por
máquina e humanos que permite a definição de dados
estruturados, em que o texto é marcado com um identificador
significativo.
Caracteristicas da arquitetura SOA
 As partes (serviços) são bastante independentes entre
si;
 Não há limitações em relação à plataforma ou à
linguagem utilizada para implementar um serviço,
apenas em relação a como eles se comunicam; e
 Um serviço encapsula uma lógica de negócio. Assim,
temos um alto índice de reaproveitamento.
Benefícios da arquitetura SOA
 Tempo e custo de desenvolvimento serão reduzidos ao
reutilizarmos um serviço em umaparte diferente do
sistema;
 A aplicação final é mais facilmente extensível; e
 Uma aplicação diferente poderá se beneficiar dos
serviços implementados anteriomente.
Principais padrões da SOA
 SOAP: (Protocolo de Acesso a Objetos Simples) é um
padrão de trocas de mensagens que oferece suporte à
comunicação entre os serviços. Ele define os
componentes essenciais e opcionais das mensagens
passadas entre serviços.
 WSDL: (Linguagem de Definição de Serviços Web) – é
um padrão para a definição de interface de serviço.
Define como as operações de serviço (nomes de
operação, parâmetros e seus tipos) e associações de
serviço devem ser definidas.
 WS-BPEL: é um padrão para uma linguagem de
workflow, que é usada para definir programas de
processo que envolvem vários serviços diferentes.
 UDDI: (Descrição, Descoberta e Integração Universais)
– é um padrão que define os componentes de uma
especificação de serviço, que pode ser usada para
descobrir a existência do serviço.