Engenharia de Software I

Aula 5
Processo de Desenvolvimento de Software

l.bertholdo@ifsp.edu.br
Conteúdo
• Processo Unificado
• Processos Ágeis
• eXtreme Programming – XP
• Scrum

l.bertholdo@ifsp.edu.br
Processo Unificado
• O Processo Unificado ou RUP
procura aproveitar os melhores
recursos e características dos
modelos tradicionais de processo,
usando alguns dos princípios do
desenvolvimento ágil de software.
O Processo Unificado costuma ser chamado
de Processo Unificado da Rational (Rational
Unified Process – RUP) em homenagem à
Rational Software Corporation
(posteriormente adquirida pela IBM), uma
das primeiras colaboradoras para o
desenvolvimento e refinamento do Processo
Unificado e desenvolvedora de ferramentas
completas para dar suporte a este processo.

• O RUP sugere um fluxo de processo iterativo, incremental e centrado

na arquitetura do software, visando a facilidade de manutenção e a
reutilização de componentes, características essenciais no
desenvolvimento de software moderno.
• Além disso, utiliza casos de uso de forma sistemática, para descrever
de forma mais lógica a visão do cliente sobre o sistema.

l.bertholdo@ifsp.edu.br
 Processo Unificado
• Casos de Uso
• Um caso de uso é um modelo que descreve uma função ou recurso
de um sistema do ponto de vista do usuário. Ele serve de base para
criar um modelo de análise mais refinado posteriormente.
Diagrama de casos de uso para um sistema de almoxarifado
O caso de uso Solicitar Material inclui o
Ator
caso de uso Checar Estoque, porque
sempre que houver uma solicitação de
material haverá a consulta ao estoque
para saber se o material está disponível.

O caso de uso Comprar Material estende o

caso de uso Solicitar Material, porque quando
houver solicitação de material, se o material
Casos de uso não existir no estoque (após checagem), poderá
ser solicitada a compra do item. Porém, se o
material existir, a compra não será solicitada.

l.bertholdo@ifsp.edu.br
Processo Unificado
• Casos de Uso
• Um caso de uso também pode ser uma narrativa textual. Por exemplo,
uma breve descrição do caso de uso Solicitar Material, poderia ser:

1. O ator solicita ao sistema o cadastramento de uma solicitação de material;

2. O sistema apresenta ao ator o formulário para preenchimento da solicitação;
3. O ator preenche os dados necessários e confirma a operação de solicitação;
4. O sistema valida as informações preenchidas pelo ator;
5. O sistema verifica que o material solicitado existe no estoque;
6. O sistema efetua o cadastramento da solicitação de material;
7. Caso de uso encerrado.

l.bertholdo@ifsp.edu.br
Processo Unificado
• Histórico
• Nos anos 1990, os cientistas da computação James Rumbaugh, Grady
Booch e Ivar Jacobson começaram a trabalhar em um “método
unificado” que combinaria as melhores características de cada um de
seus métodos individuais de análise e projeto orientados a objetos.
• Também adotaram características propostas por outros especialistas
em modelagem orientada a objetos, o que resultou na linguagem de
modelagem unificada UML (Unified Modeling Language).
• A UML possui um conjunto de diagramas voltados para a modelagem e
o desenvolvimento de sistemas orientados a objetos, entre eles:
diagramas de casos de uso, de classes, de sequência, de atividades etc.
• Por volta de 1997, a UML tornou-se um padrão da indústria para o
desenvolvimento de software orientado a objetos.
l.bertholdo@ifsp.edu.br
Processo Unificado
• O Paradigma da Orientação a Objetos Bicicleta Mountain Bike
modelo XYZ
• Objetos do mundo real compartilham duas características:
• Estado: Características ou dados de um objeto. Por exemplo,
bicicletas têm velocidade e marchas.
• Comportamento: Procedimentos ou ações que podem ser
realizadas com o objeto. Por exemplo, bicicletas permitem ações
como pedalar, mudar marcha e frear.
• Objetos também pertencem a uma classe, ou seja, estão
associados a um determinado tipo de objeto. Por exemplo, o
objeto Mountain Bike modelo XYZ pertence à classe “bicicleta”.

Classes são elementos abstratos, enquanto objetos

são concretos, ou seja, existem no mundo real.
l.bertholdo@ifsp.edu.br

Processo Unificado
• O Paradigma da Orientação a Objetos
Softwares orientados a objetos
usam classes, objetos, métodos,
atributos e outros recursos para
representar e processar dados
de objetos do mundo real.

• Um objeto, no contexto dos sistemas orientados a objetos, é

conceitualmente similar a objetos do mundo real, pois também têm
estado e comportamento, e estão associados a uma classe.

• Um objeto armazena seu estado por meio de atributos, semelhantes às

variáveis do paradigma procedural. E define seu comportamento por
meio de métodos, similares às funções do paradigma procedural.

Ao atribuir um estado a um objeto e

fornecer métodos para mudar este estado,
o objeto mantém o controle de como o
mundo exterior pode usá-lo. Exemplo: Se a
bicicleta tem apenas 6 marchas, um
método para mudar a marcha pode rejeitar
marchas que sejam superiores à 6ª.
l.bertholdo@ifsp.edu.br
Processo Unificado
• O Paradigma da Orientação
a Objetos
Programação (Código escrito a partir da modelagem)
Esse paradigma possui um recurso
chamado encapsulamento, que permite
controlar a visibilidade dos atributos e
métodos de uma classe, por meio de
palavras-chave como public e private.

Modelagem
(Diagrama de
Classes)

l.bertholdo@ifsp.edu.br
 Processo Unificado
• Fase de Concepção
Inclui as atividades de comunicação e planejamento. Durante a
comunicação, os stakeholders (envolvidos) identificam as
necessidades de negócio, propõe-se um esboço de arquitetura
para o sistema e desenvolve-se um planejamento que contemple a
natureza iterativa e incremental do projeto. Requisitos de negócio
básicos e casos de uso preliminares são descritos, explicitando
quais recursos e funções cada categoria de usuário deseja.

O planejamento identifica recursos, avalia os

principais riscos, define um cronograma e estabelece
uma base para as fases que serão aplicadas à medida
que o incremento de software for desenvolvido.

Envolvido ou stakeholder é qualquer

pessoa que tenha interesse no êxito de um
projeto: executivos, usuários, engenheiros
de software, pessoal de suporte etc.
l.bertholdo@ifsp.edu.br
 Processo Unificado
• Fase de Elaboração
Inclui as atividades de planejamento e de modelagem. A modelagem
refina e expande os casos de uso preliminares, desenvolvidos na fase
de concepção, e amplia a representação arquitetural. Em alguns
casos, esta fase gera um sistema executável “de degustação”, o qual
demonstra a viabilidade da arquitetura, mas não oferece todos os
recursos e funções necessárias para o uso do sistema.

No auge desta fase, o planejamento é revisado e, se

necessário modificado, para assegurar que escopo,
riscos e datas de entrega permaneçam adequados.

l.bertholdo@ifsp.edu.br
Processo Unificado
• Fase de Construção
Nessa fase são desenvolvidos os componentes de
software, que tornarão os casos de uso funcionais
para os usuários. Os modelos iniciados na fase de
elaboração são concluídos, de modo a refletir a
versão final do incremento de software. Em
seguida, implementa-se o código-fonte, com todos
os recursos e funções exigidos para o incremento.

À medida que os componentes são implementados,

testes de unidades são desenvolvidos e executados
para cada um deles. Além disso, realiza-se a junção dos
componentes e os respectivos testes de integração. Os
casos de uso são usados nos testes de aceitação, sendo
executados antes do início da próxima fase.
l.bertholdo@ifsp.edu.br
 Processo Unificado
• Fases de Transição e
Produção

Na fase de produção, monitora-se o uso

contínuo do software e disponibiliza-se
suporte para seu ambiente operacional. Além
disso, relatórios de defeitos e solicitações de
mudanças são elaborados e avaliados.

A fase de transição abrange os últimos estágios da fase
de construção e a primeira parte da fase de entrega.
Entrega-se o software aos usuários para testes beta, que
relatam os defeitos e as mudanças necessárias. Além
disso, a equipe de software elabora manuais de usuário,
guias rápidos, procedimentos de instalação, necessários
para o lançamento da versão. Na conclusão desta, o
incremento torna-se uma versão utilizável do software.
É comum as fases de construção, transição
e produção serem conduzidas em paralelo
com o início do próximo incremento.
Nem todas as tarefas do RUP são
conduzidas em todos os projetos. Cada
equipe adapta o processo (ações, tarefas e
artefatos) conforme suas necessidades.
l.bertholdo@ifsp.edu.br
Processos Ágeis
• Em 2001, o norte-americano Kent Beck e outros 16 renomados
desenvolvedores, autores e consultores da área de software
formaram um grupo batizado de Agile Alliance (Aliança dos Ágeis).
• Eles assinaram o Manifesto for Agile Software Development
(Manifesto para o Desenvolvimento Ágil de Software) contendo a
declaração abaixo.
• A ideia era admitir o valor dos itens à direita, porém valorizar mais
ainda aqueles à esquerda.
Ao desenvolver e ajudar outros a desenvolver software, descobrimos formas
melhores de desenvolvimento. Por meio deste trabalho, passamos a valorizar:
• Indivíduos e interações acima de processos e ferramentas.
• Software operacional acima de documentação completa.
• Colaboração dos clientes acima de negociação contratual.
• Respostas a mudanças acima de seguir um plano.
l.bertholdo@ifsp.edu.br
Processos Ágeis
• Na economia moderna, as condições de mercado mudam com rapidez
e as necessidades dos clientes se alteram sem aviso prévio.

• É preciso ser ágil para se adequar às mudanças, pois elas são caras,
particularmente se ocorrerem sem controle e forem mal gerenciadas.

• Uma das principais características da metodologia ágil é sua

capacidade de reduzir os custos da mudança no processo de software.

• A metodologia ágil busca sanar fraquezas reais e perceptíveis da

engenharia de software convencional.

O desenvolvimento ágil oferece benefícios importantes, porém não é a

antítese da engenharia de software, nem pode ser aplicado como uma
filosofia geral para todas as situações ou todos os projetos de software.

l.bertholdo@ifsp.edu.br
Processos Ágeis
Nos processos de software convencionais, os custos de mudanças aumentam de forma não
linear. É fácil acomodar uma mudança no início de um projeto. Os custos são mínimos e o
tempo demandado pouco afetará o resultado do projeto. Mas, se uma mudança grande é
solicitada próximo do final do projeto, ela pode exigir alterações no projeto de arquitetura,
desenvolvimento de novos componentes, modificações em outros, novos testes etc.

Um processo ágil reduz o custo das

mudanças porque o software é entregue
de forma incremental e as alterações são
melhor controladas dentro dos
incrementos, permitindo que a equipe de
software assimile as alterações, sem
muito impacto nos custos.

l.bertholdo@ifsp.edu.br

Processos Ágeis
• Um processo ágil de software deve
ser adaptável. Para isso, a equipe
ágil deve fazer entregas incrementais
e receber feedback constante do
cliente, o que pode ser feito por
meio de protótipos operacionais.
• Os incrementos de software devem
ser entregues em curtos períodos de
tempo, para que as adaptações
acompanhem o ritmo das mudanças.
• Essa abordagem demanda do cliente
avaliar os incrementos regularmente,
fornecer seu feedback e antecipar as
adaptações necessárias no processo.
Os 12 princípios para alcançar a agilidade, estabelecidos pela
Agile Alliance:
1. A maior prioridade é satisfazer o cliente com entrega adiantada
e contínua de software funcionando.
2. Aceite bem os pedidos de alterações, mesmo com o
desenvolvimento adiantado. Os processos ágeis se aproveitam
das mudanças para a vantagem competitiva do cliente.
3. Entregue software em funcionamento frequentemente, de
algumas semanas a alguns meses, dando preferência a
intervalos mais curtos.
4. O pessoal do comercial e os desenvolvedores devem trabalhar
em conjunto diariamente ao longo de todo o projeto.
5. Construa projetos em torno de pessoas motivadas. Dê a elas o
ambiente e o apoio necessários e acredite que elas farão o
trabalho corretamente.
6. O método mais eficiente e efetivo de transmitir informações
para e dentro de uma equipe de desenvolvimento é uma
conversa aberta, presencial.
7. Software em funcionamento é a principal medida de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável.
Proponentes, desenvolvedores e usuários devem estar aptos a
manter um ritmo adequado e constante.
9. Atenção contínua para com a excelência técnica e para com
bons projetos aumenta a agilidade.
10.Simplicidade: a arte de maximizar a quantidade de trabalho
que não precisou ser feito é essencial.
11.As melhores arquiteturas, requisitos e projetos surgem de
equipes auto-organizadas.
12.Em intervalos regulares, a equipe se avalia para ver como pode
se tornar mais eficiente, então, sintoniza e ajusta seu
comportamento de acordo.
l.bertholdo@ifsp.edu.br
eXtreme Programming – XP
• eXtreme Programming (Programação Extrema) é a abordagem mais
amplamente utilizada para desenvolvimento ágil de software.

XP emprega uma metodologia

orientada a objetos e envolve um
conjunto de regras e práticas
constantes no contexto de quatro
atividades-chave: planejamento,
projeto, codificação e testes.

l.bertholdo@ifsp.edu.br
 eXtreme Programming – XP
Planejamento: É iniciado com uma atividade de levantamento de requisitos. Esta atividade gera um
conjunto de “histórias de usuários” (similar aos casos de uso), que descrevem as funcionalidades
solicitadas. O cliente atribui prioridades às histórias. A equipe XP avalia, então, cada história e atribui
um custo (em semanas de desenvolvimento) a elas. Se a equipe estimar mais de três semanas de
desenvolvimento para a história, é solicitado ao cliente que ele a divida em histórias menores.

Após entregar o primeiro incremento, a

equipe XP calcula a velocidade do projeto,
para estimar o cronograma das próximas
versões. Conforme o desenvolvimento
prossegue, o cliente pode incluir, alterar ou
excluir histórias. Nesse caso, a equipe XP
modifica seus planos de forma adequada.

l.bertholdo@ifsp.edu.br
eXtreme Programming – XP
Projeto: Para projetar o software em um contexto orientado a objetos, são usados cartões CRC
(Classe-Responsabilidade-Colaboração), que identificam e organizam as classes relevantes
para o incremento de software. Se for encontrado um problema de projeto difícil, pode-se
implementar um protótipo operacional dessa parte do projeto, denominado solução pontual.
Este protótipo é então avaliado, reduzindo assim os riscos para a implementação verdadeira.

Codificação: Antes da codificação, a equipe

prepara os testes unitários de cada história. A
codificação geralmente é feita em pares,
visando a solução de problemas e a garantia
de qualidade em tempo real. À medida que a
dupla de programadores conclui o trabalho, o
código gerado é integrado ao de outros.

l.bertholdo@ifsp.edu.br
eXtreme Programming – XP

XP estimula a refatoração, uma

técnica que permite aperfeiçoar
continuamente o código que foi escrito
durante a construção do sistema.

Testes: Os testes unitários são automatizados, para

que possam ser executados fácil e repetidamente. Os
testes de integração podem ocorrer diariamente, o
que permite encontrar erros precocemente. Os testes
de aceitação são especificados pelo cliente e mantêm o
foco nas características e funcionalidades do sistema.

l.bertholdo@ifsp.edu.br
 O nome Scrum está relacionado a uma atividade que ocorre
Scrum durante o jogo de rugby, onde o grupo de jogadores se juntam ao
redor da bola e trabalham juntos para mover a bola pelo campo.

• Metodologia ágil de software concebida por Jeff Sutherland e sua

equipe no início dos anos 1990. No Scrum, existem três fases:
• Planejamento geral: Estabelecimento dos objetivos gerais do projeto e
da arquitetura do software.
• Sprints: Série de ciclos, sendo que em cada ciclo é desenvolvido um
incremento do sistema.
• Encerramento do projeto: Finalização da documentação exigida, como
manuais do usuário, e avaliação das lições aprendidas com o projeto.
• Uma sprint é uma unidade de planejamento na qual o trabalho a ser
feito é avaliado, os recursos de desenvolvimento são selecionados e o
software é implementado. Ao final de uma sprint, a funcionalidade
completa é entregue ao cliente.
l.bertholdo@ifsp.edu.br
Scrum
• Principais características:

• Uma sprint tem comprimento fixo, normalmente duas a quatro

semanas.

• O ponto de partida para o planejamento é o product backlog, uma

lista de funcionalidades priorizadas pelo representante do cliente,
denominado Product Owner (PO) ou “dono do produto”.

• A seleção dos recursos e da funcionalidade a ser desenvolvida

durante a sprint envolve todas as pessoas da equipe do projeto
que trabalham com o cliente. Esta seleção gera o sprint backlog.

l.bertholdo@ifsp.edu.br
Scrum
• Principais características:
• Após a seleção, a equipe começa a desenvolver o software.
Reuniões diárias rápidas, envolvendo todos os membros da
equipe, são realizadas para analisar os progressos e, se necessário,
repriorizar o trabalho.

• No fim da sprint, o trabalho é revisto e apresentado ao cliente

(stakeholders). Na sequência, começa a próxima sprint.

• Durante o desenvolvimento, a equipe fica isolada do cliente e da

organização, e as comunicações são centralizadas no Scrum
Master. Seu papel é ser um facilitador para a equipe de
desenvolvimento, de modo a protegê-la de distrações externas.

l.bertholdo@ifsp.edu.br
Scrum
Ciclo de uma sprint

3
1 4

l.bertholdo@ifsp.edu.br
Referências
• PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma
abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.

• SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson

Prentice Hall, 2011.

l.bertholdo@ifsp.edu.br