ARA0097 – ENGENHARIA DE SOFTWARE

Prof. Ms. Pedro Gabriel Calíope Dantas Pinheiro

1. Fundamentos de Software e Gerenciamento de Projetos.

Situação-problema: Imagine que você tem um terreno e deseja construir uma casa. Qual o primeiro

passo? Você iniciará pelas paredes, pela fundação ou pelo projeto? E quando você tem um problema e deseja
construir um software para solucioná-lo, por onde você deve começar?

Engenharia de Software:
Há 20 anos, menos de 1% do público poderia descrever de forma inteligível o que significa "software
de computador". Hoje, a maioria dos profissionais bem como a maior parte do público, acham que
entendem o que é software. Será que entendem?

• É uma derivação da Engenharia de Sistemas e de Hardware.

• Compreende um conjunto de etapas (Paradigmas da Engenharia de Software) que envolve
métodos, ferramentas e os procedimentos.
• É um elemento de sistema lógico, e não físico.
• Possui características que difere do hardware.
• Pode ser aplicado a qualquer situação, em que um conjunto de passos procedimentais (um
algoritmo) tiver sido previamente especificado.
Exemplo:
✓ Não se desgasta.
✓ É feito sob medida em vez de ser montada a partir de componentes existentes.

Aplicações do Software:
• Software de Sistema: Finalidade de atender às necessidades de outros programas;
• Software de Aplicação: Finalidade de solucionar necessidades específicas de negócio;
• Software Científico/Engenharia: Finalidade em diversas áreas de pesquisa e simulações;
• Software Embutido: Residem em um produto ou sistema com finalidade de controlar as
atividades de equipamentos como por exemplo um ar-condicionado digital.
 • Software Generalistas/Prateleira: Finalidade de suprir as necessidades de diversos clientes,
por exemplo, na criação de planilhas eletrônicas, editores de textos, entre outros para linhas
de produtos;
• Aplicações para a web (WebApps): Executados em um servidor conectado à rede e que pode
ser acessado e utilizado por diferentes usuários, desde que possuam acesso;
• Software de Inteligência Artificial: Utilizados na resolução de problemas complexos, com
aplicações em redes neurais artificiais, robótica, jogos, entre outras.

Problemas do Software:
A “Crise do Software” é o conjunto de problemas associados ao software que atingem seu
desenvolvimento, alguns desse problemas podem ser descritos como:
1. Estimativas de Prazos e Custos que são frequentemente imprecisos;
2. Produtividade dos profissionais;
3. A qualidade do software;

Importância do Software:
1. Avanços da Microeletrônica
2. Integração de informações
3. Praticidade e agilidade
4. Mensuração de resultados descomplicada

O Processo de Software:
É o conjunto de atividades executadas com o objetivo de criar um produto (software). Pressman
(2011) define cinco atividades para o processo de software são elas:

✓ Comunicação: Visa a compreensão dos objetivos dos interessados, definindo os requisitos

para o desenvolvimento do produto;
o Levantamento de Requisitos: Levantar conhecimento sobre o negócio do cliente,
identificando suas necessidades;
o Análise: Detalhamento dos requisitos e definição lógica dos procedimentos;
✓ Planejamento: Tem como objetivo a criação de um mapa (também conhecido como plano de
projeto de software) que contém a descrição das tarefas, possíveis riscos, cronograma de
execução, os recursos demandados e o resultado esperado;
o Gerência de Projeto: Planejamento das funções a serem executadas;
 ✓ Modelagem: Criação de modelos (esboços) para representar o produto que deseja
desenvolver, fazendo assim com que as necessidades do projeto possam ser definidas antes
do início do desenvolvimento, reduzindo assim os custos de mudanças.
o Projeto: Definição física dos procedimentos, recursos tecnológicos necessários;

✓ Construção: Desenvolvimento e Testes do Software;

o Implementação: Construção do sistema (códigos);
o Teste: Validação do sistema, verificando se os requisitos levantados foram
devidamente desenvolvidos, se atendem às expectativas do cliente e se o sistema
funciona sem erros;

✓ Emprego: Entrega do produto ao cliente, de maneira Integral ou Parcial.

o Implantação: Disponibilizar o produto ao cliente (usuário), inclusive treinamentos e
carga de dados;
o Manutenção: Efetuar os ajustes necessários em caso de erros no programa, no
levantamento de requisitos ou no desenvolvimento de novas funcionalidades,
conforme necessidade do cliente;
o Qualidade: efetuar medidas para a verificação e busca pela excelência do sistema.

Os modelos de processos, também conhecidos como ciclos de vida de software mais utilizados são:
✓ O modelo cascata: Também conhecido como ciclo de vida clássico, possui suas atividades
sendo executadas de forma linear.
✓ O modelo evolucionário;
o Prototipagem: Utilizada como ferramenta para a descoberta de requisitos de forma
interativa, pondera-se a necessidade de reavaliação dos requisitos, fazendo assim com
que todas as etapas sejam revistas e ao final, um novo protótipo seja entregue ao
cliente.

o Espiral - BOEHM (1988): Seu ciclo não necessariamente termina quando o software é
entregue, ele pode ser adaptado para perdurar por toda a vida do software. A análise
de riscos é feita na etapa de planejamento e a cada volta em torno do eixo do espiral
pode ser utilizada para o desenvolvimento de um protótipo.
✓ O modelo incremental (Ciclo Interativo): Visa combinar as vantagens do modelo cascata com
as vantagens do modelo espiral. Os serviços a serem fornecidos pelo software a ser produzido
são devidamente identificados e desenvolvidos independentemente. Sendo assim, logo na
primeira entrega, o sistema já pode ser utilizado.
2. Gerenciamento de Projetos

Situação-problema: Você deseja aprender um novo idioma e de vez em quando assiste algumas aulas na
internet, ou faz algumas leituras esporádicas, isso pode ser considerado um projeto pessoal? Suponha agora
que você tenha planejado estudar duas horas por dia, três vezes na semana durante 18 meses, e após esse
período irá fazer uma viagem de 30 dias para exercitar a conversação. Isso pode ser considerado um projeto
pessoal?

Project Management Body of Knowledge (PMBOK):

O Guia PMBOK® é uma publicação do Project Management Institute (PMI) que traz um conjunto de
conhecimentos e boas práticas reconhecidas em gerenciamento de projetos.

Projeto:
✓ É um empreendimento único, com início e fim definidos, visando atingir metas e objetivos
pré-definidos e estabelecidos dentro de parâmetros de prazo, custo e qualidade (PMI 2008).
✓ Exige atividades de gerenciamento e conjuntos de habilidades.
✓ Realizados por pessoas, restringidos por recursos limitados, planejados, executados e
controlados.

Operações:
✓ São esforços contínuos que geram saídas repetitivas, com recursos designados para realizar
basicamente o mesmo conjunto de tarefas
✓ Exigem gerenciamento de processos de negócios.
✓ O gerenciamento de operações é responsável pela supervisão, orientação e controle das
operações de negócios.
✓ Realizados por pessoas, restringidos por recursos limitados, planejados, executados e
controlados.
Programa:
✓ É um grupo de projetos relacionados e gerenciados de modo coordenado para a obtenção de
benefícios e controle.
✓ Envolve empreendimento repetitivo ou cíclico e geralmente, maior tempo de duração.

Áreas de conhecimento do PMBOK®:

1. Gerenciamento de Integração: Significa unificação, consolidação e articulação das partes de

qualquer projeto. Requer escolhas sobre alocação de recursos, concessões entre objetivos e
alternativas conflitantes. É papel do gerente de projetos fazer com que os componentes do
projeto trabalhem juntos. habilidades gerenciamento, negociação, comunicação,
organização, familiaridade técnica com o produto etc.

2. Gerenciamento do Escopo: Através de processos o objetivo é definir e controlar o que faz

parte do projeto. O escopo/âmbito é o foco do projeto e difere-se do escopo do produto na
medida em que define o trabalho necessário para concluir o produto, e o escopo do produto
define os recursos (atributos e comportamentos).

3. Gerenciamento do Cronograma: Também chamado de gerenciamento de tempo em edições

anteriores, visa manter uma sequência de eventos precisa e atualizada, incluindo processos
necessários para estimar as tarefas, seus recursos e durações, de modo a gerenciar o projeto
para o término pontual.

4. Gerenciamento de Custos: Inclui processos envolvidos em estimativas, orçamentos e controle

dos custos, de modo que o projeto possa ser terminado dentro do orçamento aprovado. Os
processos incluem: Planejar o gerenciamento dos custos, estimar os custos, determinar o
orçamento, controlar os custos.
 5. Gerenciamento da Qualidade: Inclui processos e atividades da organização executora que
determinam as políticas de qualidade, objetivos, requisitos e responsabilidades de modo que
o projeto satisfaça às necessidades para as quais foi empreendido.

6. Gerenciamento de Recursos: Também chamada de recursos humanos em algumas edições,

inclui processos que organizam e gerenciam a equipe do projeto. Faz parte desta área do
conhecimento descrever as necessidades de pessoal e suas respectivas capacidades e
habilidades.

7. Gerenciamento de Comunicações: Inclui os processos necessários para assegurar que as

informações do projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e
organizadas de maneira oportuna e apropriada.

8. Gerenciamento de Riscos: Inclui processos de planejamento, identificação, análise,

estabelecendo um plano de resposta para tratar problemas que possam surgir, bem como o
monitoramento e controle de riscos de um projeto.

9. Gerenciamento de Aquisições: Inclui processos necessários para comprar ou adquirir

produtos, serviços ou resultados externos ao projeto e abrange o gerenciamento de
contratos. A organização pode ser tanto compradora como vendedora dos produtos, serviços
ou resultados de um projeto. Na ótica do PMI®, abordamos o gerenciamento das aquisições
do ponto de vista do comprador.

10. Gestão de Partes Interessadas (Stakeholders): Inclui processos de identificação,

planejamento, engajamento e gerenciamento das partes interessadas. Para isso, São
utilizadas estratégias para identificar e gerenciar as expectativas dos stakeholders para
aumentar o suporte e comprometimento ao projeto.
*Stakeholders: Pessoa ou Grupo envolvidos com o sistema, direta ou indiretamente.

Gerência de Projetos:

É a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do

projeto para atender aos seus requisitos. Os grupos de processos de gerenciamento de
projetos são:

Monitoramento e
Iniciação Planejamento Execução Encerramento
Controle
Os itens que integram um gerenciamento de projetos são:

✓ Escopo, cronograma, orçamento, qualidade, recursos e riscos.

✓ Levantamento das necessidades e expectativas dos clientes e das partes
interessadas.
✓ Estabelecimento de objetivos claros e alcançáveis.
✓ Adaptação das especificações, dos planos e da abordagem às diferentes
preocupações e expectativas das diversas partes interessadas.
✓ Balanceamento das demandas conflitantes de escopo, cronograma,
orçamento, qualidade, recursos e riscos.

Problemas - Causas x Soluções:

Problemas
Atrasos no cronograma
Custos acima do previsto.
Falta de recursos de pessoal.
Mudanças de requisitos e especificações.
Qualidade abaixo da esperada.
Produtos que não funcionam
Complexidade acima da capacidade.
Produtos mal projetados.
Projetos que são cancelados.
Causas
Cronogramas apertados ou mal estruturados.
Estimativas de orçamento fracas ou abaixo do Análise do escopo, cronograma e recursos para a correta
real.
Desenvolvimento inadequado da equipe dos
projetos.
Falta de um comando claro para o projeto.
Sistema de controle mal planejado.
Objetivos mal planejados ou não compreendidos
Falta de capacitação da equipe do projeto.
Expectativas dos clientes sem monitoramento.
Falha no levantamento dos requisitos ou
recursos financeiros insuficientes
Soluções
Tempo estimado considerando os recursos disponíveis.
estimativa de custos.
Controle do pool de recursos alocados nos projetos em
andamento e previstos.
Implementação de processo de controle de mudanças.
Validação do produto pela equipe do projeto e aceite do
cliente.
Reuniões semanais com o cliente para validação prévia dos
produtos.
Capacitar a equipe do projeto ou contratar especialistas
Ênfase no planejamento do projeto em conjunto com o
cliente.
Ajustar o escopo do projeto para atender as necessidades
do cliente.
3. Engenharia de Requisitos e Análise de Sistema
Situação-problema: Quando um cliente deseja um software, como nós sabemos quanto tempo

demorará para ser desenvolvido? Como nós descrevemos para os programadores todas as características que
devem ser implementadas? De que forma são listadas todas as funcionalidades que o software deve possuir?

Requisitos:
Existem dois tipos principais de requisitos:
✓ Funcionais: São declarações de como o sistema deve reagir a entradas específicas e como se
comportar em determinadas situações. É uma interação entre o sistema e o seu ambiente.
Também podem explicitar o que o sistema não deve fazer.
✓ Não-Funcionais:
➢ Organizacionais: Políticas e procedimentos nas organizações do cliente e do desenvolvedor.
➢ Externos: Fatores externos ao sistema e ao seu processo de desenvolvimento;
o Interoperabilidade com outros sistemas;
o Requisitos éticos ou legais;
➢ De produto: Comportamento do produto
o Eficiência: Desempenho, Espaço, Rapidez, Memória;
o Confiabilidade;
o Portabilidade.

Os requisitos ainda podem ser divididos em outras categorias:

✓ Inversos: Definem o que nunca deve ocorrer durante a execução do software;
✓ Estáveis: Não são alterados ou modificados com frequência, sua alteração é algo excepcional;
✓ Voláteis: Vivem em constante modificação, podem ser divididos em quatro categorias:
Compatíveis, Mutáveis, Emergentes e Consequentes.

Os requisitos ainda podem ser divididos em outra categoria, se vistos pelo aspecto da
implementação:
✓ Cliente ou Alto Nível: Expostos pelo cliente em linguagem natural, ou ainda em forma de
desenhos ou casos de uso, qualquer técnica que facilite o entendimento. Se caracterizam por
dizer apenas o que o usuário/cliente quer que o sistema faça, não há a preocupação de como
aquela funcionalidade será implementada;
✓ Sistema ou Baixo Nível: Relatam não só o que deve ser implementado, mas como deve ser
implementado, fazem restrições a aspectos de implementação e arquitetura, possuem detalhes
que geralmente são obscuros para o cliente, mas não para os desenvolvedores.

Engenharia de Requisitos:
O processo de Engenharia de Requisitos possui quatro subprocessos com finalidade de criação e
manutenção do documento de requisitos, com foco na qualidade do processo:

✓ Estudo de viabilidade: Consiste num conjunto preliminar de requisitos de negócio, um esboço

da descrição do sistema e como este pretende apoiar os processos de negócio. Através de uma
série de questões, como:
➢ O sistema contribui para os objetivos gerais da organização?
➢ O sistema pode ser implementado com tecnologia atual e dentro das restrições de
prazo e custo? O sistema pode ser integrado a outros sistemas existentes?
➢ Como a empresa se comportaria se esse sistema não fosse implementado?
➢ Quais são os problemas com os processos atuais e como o novo sistema ajudaria a
reduzir esses problemas?
Estas questões são respondidas através de conversas com: gerentes de departamento em que o
sistema será usado, engenheiros de software familiarizados com o tipo de sistema proposto,
especialistas em TI e usuários finais. Os resultados devem ser apresentados no relatório de
viabilidade, onde recomenda se vale a pena ou não prosseguir com o processo.

✓ Elicitação e Análise dos requisitos: Nessa atividade, os engenheiros de software trabalham com
os clientes e usuários finais do sistema para compreender sobre o domínio da aplicação, os
serviços do sistema, desempenho, restrições etc. Essa fase pode envolver vários stakeholders e
possui 4 atividades de processo:
➢ Obtenção de requisitos
➢ Classificação e organização de requisitos
➢ Priorização e negociação de requisitos
➢ Documentação de requisitos

✓ Obtenção de Requisitos: Obter informações sobre sistema através de fontes de informação

como: Documentação, Stakeholders de sistema e Especificações de sistemas similares.
Os requisitos podem ser obtidos através de:
➢ Pontos de vista: Organiza o processo de Elicitação de requisitos e os próprios requisitos
em pontos de vista. Um ponto forte dessa abordagem é que ela reconhece várias
perspectivas de um requisito, ou seja, várias visões diferentes de um requisito.
Existem 3 tipos de ponto de vista:
o Pontos de vista de interação
o Pontos de vista indiretos
o Pontos de vista de domínio

➢ Entrevista (Formais ou Informais): São formuladas perguntas Abertas ou Fechadas para

os stakeholders.
o Abertas: Indicadas quando deseja-se conhecer o escopo do entendimento do
entrevistado, não são seguidas por alternativas encorajando resposta livre,
podendo consumir muito tempo e resultar em pouca informação útil.
o Fechadas: Indicadas para avaliar características específicas do problema.
Fornecem escolha de alternativas ou níveis de resposta, impondo limites do tipo
Nível e Quantidade de informação fornecida pelo entrevistado.

Se utilizarmos apenas a entrevista como meio de obter requisitos, pode haver perda de
informações. Essa técnica deve ser utilizada em conjunto com outras técnicas de
Elicitação.

➢ Cenários: Geralmente as pessoas consideram mais fácil relatar exemplos da vida real do
que abstrair descrições. O cenário começa com um esboço da interação e, durante o
processo de Elicitação, os detalhes são adicionados para uma descrição completa dessa
interação.
➢ Casos de uso: Utiliza a linguagem de modelagem UML. É uma técnica baseada em
cenários para elicitação de requisitos. Os casos de uso identificam interações individuais
com o sistema.
✓ Validação: Finalidade de mostrar que os requisitos realmente definem o sistema que o usuário
deseja. Também está relacionada com a descoberta de problemas com os requisitos. Erros em
um documento de requisitos podem levar a custos excessivos. Devem ser realizadas verificações
nos requisitos do sistema:
➢ Verificação de validade
➢ Verificação de consistência
➢ Verificação de clareza
➢ Verificação de realismo
➢ Facilidade de verificação

Uma série de técnicas de validação pode ser utilizada:

➢ Revisão de requisitos
➢ Prototipação
➢ Geração de casos de teste

✓ Gerenciamento de Mudanças: Deve ser aplicado a todas as mudanças propostas. A principal

vantagem da utilização de um processo formal para tal tarefa é que todas as alterações de
requisitos propostas são tratadas consistentemente, e as mudanças no documento de requisitos
são realizadas de forma controlada. Existem 3 estágios principais no processo:
➢ Análise do problema e especificação da mudança
➢ Análise da mudança e estimativa do custo
➢ Implementação da mudança
4. Diagramas de Casos de Uso
Procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo
do sistema por qualquer pessoa, através da apresentação da visão externa geral das funções e
serviços que o sistema deverá oferecer aos usuários, sem se preocupar com o COMO;

Componentes Principais:

Atores: Tenta identificar os tipos de usuários que irão interagir com o sistema, quais os papéis que
estes usuários irão assumir e quais funções serão requisitas por cada usuário específico;
• Pessoas (Normalmente)
• Hardware / software (Eventualmente)

Casos de Uso: Referem-se aos serviços, tarefas ou funções que podem ser utilizados pelos usuários
do sistema. Utilizados para expressar/documentar os comportamentos pretendidos para as funções
do sistema;

Documentação:
Associações:
➢ Atores e Casos De Uso
➢ Casos De Uso e Casos De Uso

Relacionamentos:
➢ Inclusão: Usada quando existe um serviço, situação ou rotina comum a mais de um Caso de
Uso, “Chamada de Sub-rotina”, representada por uma linha tracejada com texto
“<<Include>>”.

➢ Extensão: Descrever cenários opcionais de um Caso de Uso que somente ocorrerão em uma
situação específica – se uma determinada condição for satisfeita. Representada por:
“<<Extend>>”
 ➢ Generalização/Especialização: Associação entre Casos de Uso com características
semelhantes, onde a estrutura de um Caso de Uso generalizado é herdada pelos Casos de Usos
especializados.

5. Rational Unified Process (RUP)

Situação-problema: Nos modelos apresentados anteriormente, tínhamos uma fase bem definida
para fazer cada coisa. Mas e se existisse um modelo que se preocupasse com modelagem de negócios,
análise de requisitos, implementação e outras disciplinas durante todo o processo de
desenvolvimento?
É o modelo de processo criado pela Rational, hoje de propriedade da IBM. Para conduzir o
desenvolvimento de sistemas orientado a objetos, define práticas e princípios para cumprimento do
desenvolvimento de sistemas. Para ordenar o desenvolvimento é proposto o ciclo de vida iterativo e
incremental, onde cada parte do sistema é desenvolvida em uma iteração e implantada ao final do
ciclo de vida. O ciclo gera benefícios como: entrega antecipada de resultados, antecipação de riscos
e facilidade para mudança de requisitos.

✓ Iterativo e incremental;
✓ Guiado por casos de uso (use cases);
✓ Baseado na arquitetura do sistema;
✓ Descrito a partir de 3 perspectivas:
➢ Dinâmica: Mostra as fases do modelo ao longo do tempo.
➢ Estática: Mostra as atividades realizadas no processo.
➢ Prática: Sugere boas práticas a serem usadas durante o processo.
Perspectiva Estática:

1. Prioriza as atividades que ocorrem durante o processo de desenvolvimento (Workflows).

2. Existem seis workflows centrais, três workflows de apoio;
3. A descrição do workflow é orientada em torno de modelos associados à UML.

Perspectiva Prática:

1. Desenvolver Softwares iterativamente: Planejar os incrementos do sistema com base nas

prioridades do cliente e desenvolver os recursos de alta prioridade no início do processo de
desenvolvimento.
2. Gerenciar os requisitos: Documentar explicitamente os requisitos do cliente e acompanhar
suas mudanças. Analisar o impacto das mudanças no sistema antes de aceitá-las.
3. Usar arquiteturas baseadas em componentes: Estruturar a arquitetura do sistema em
componentes.
4. Modelar o software visualmente: Usar modelos gráficos da UML para apresentar visões
estáticas e dinâmicas do software.
5. Verificar a qualidade do software: Assegurar que o software atenda aos padrões de qualidade
organizacional.
6. Controlar as mudanças do software: Gerenciar as mudanças do software, usando um sistema
de gerenciamento de mudanças e procedimentos e ferramentas de gerenciamento de
configuração.
Ciclo de Vida RUP: O ciclo de vida de um sistema consiste em quatro fases:

✓ Concepção: Abrange as tarefas de comunicação com o cliente e planejamento. É feito um

plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo
as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo.

✓ Elaboração: Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é

analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que
o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações
como "O plano do projeto é confiável?", "Os custos são admissíveis?" são esclarecidas nesta
etapa.

✓ Construção: Desenvolve ou Adquire os componentes de Software. O principal objetivo desta

fase é a construção do sistema de software, com foco no desenvolvimento de componentes
e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.

✓ Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase
é disponibilizar o sistema, tornando-o disponível e 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 que possua o nível adequado de qualidade.

Exemplo de Fluxo de Planejamento e Gerenciamento:

6. Desenvolvimento Ágil - Extreme Programming (XP)

Situação-problema: Até agora estudamos diversos modelos de processo para

desenvolvimento de software. Todos eles com etapas e procedimentos bem rígidos.
Mas será que na prática, as organizações buscam por um método tradicional ou um
mais flexível? Imagine se pudéssemos aplicar todas as boas práticas aprendidas,
gerando o mínimo de burocracia!

MÉTODOS ÁGEIS

A insatisfação com o overhead que envolve os métodos de projeto de software dos

anos de 1980 e 1990 levou a criação de métodos ágeis.

➢ Têm foco no código ao invés de no projeto.

➢ São baseados em uma abordagem iterativa de desenvolvimento de software.
➢ São planejados para entregar rapidamente o software em funcionamento e
evoluí-lo rapidamente para alcançar os requisitos em constante mudança.

O objetivo é reduzir o overhead nos processos de software (ex. limitando a

documentação) e permitir uma resposta rápida aos requisitos em constante mudança
sem retrabalho excessivo.

MANIFESTO ÁGIL:

Estamos descobrindo melhores formas de desenvolver softwares e ajudar outros a

fazê-lo também. Através desse trabalho, valorizamos mais:

➢ Indivíduos e interações, ao invés de processos e ferramentas. Softwares que já

funcionam ao invés de documentação abrangente.
➢ Colaboração do cliente ao invés de negociação contratual.
➢ Resposta a mudanças ao invés de seguir um plano.
O que significa que existe valor nos itens a direita, mas que valorizamos mais os itens
a esquerda.

OS PRINCÍPIOS DOS MÉTODOS ÁGEIS

✓ Indivíduos e interações são mais importantes que processos e ferramentas.

✓ Software funcionando é mais importante do que documentação completa e

detalhada.

✓ Colaboração com o cliente é mais importante do que negociação de contratos.

✓ Adaptação a mudanças é mais importante do que seguir o plano inicial.

Aplicabilidade dos Métodos Ágeis

✓ Desenvolvimento de produto, quando a empresa de software está desenvolvendo

um produto pequeno ou médio para venda.
✓ O Desenvolvimento de sistema personalizado dentro de uma organização, quando
existe um compromisso claro do cliente em se envolver no processo de
desenvolvimento e quando não existem muitas regras e regulamentos externos que
afetam o software.
✓ Devido ao foco em equipes pequenas e fortemente integradas, existem problemas
na escalabilidade de métodos ágeis em sistemas grandes.

PROBLEMAS COM MÉTODOS ÁGEIS

✓ Pode ser difícil manter o interesse dos clientes que estão envolvidos no processo.
✓ Membros da equipe podem não ser adequados ao envolvimento intenso que
caracteriza os métodos ágeis.
✓ Priorizar mudanças pode ser difícil onde existem múltiplos stakeholders.
✓ Manter a simplicidade requer trabalho extra.
✓ Os contratos podem ser um problema assim como em outras abordagens que usam
o desenvolvimento iterativo.

MÉTODOS ÁGEIS E MANUTENÇÃO DE SOFTWARE

A maioria das organizações gasta mais na manutenção de softwares existentes do que

no desenvolvimento de softwares novos. Devido a isso, para que os métodos ágeis
obtenham sucesso, os softwares devem receber tanta manutenção quanto o
desenvolvimento original. Duas questões muito importantes:
 ➢ É possível dar suporte aos sistemas que são desenvolvidos usando uma
abordagem ágil, tendo em vista a ênfase no processo de minimização da
documentação formal?
➢ Os métodos ágeis podem ser usados efetivamente, para evoluir um sistema em
resposta a mudanças nos requisitos do cliente?

Podem ocorrer problemas no caso do tempo original de desenvolvimento não puder

ser mantido.

DESENVOLVIMENTO ÁGIL E DIRIGIDO A PLANOS

1. Para a engenharia de software, uma abordagem dirigida a planos, é baseada

em estágios de desenvolvimento separados, com os produtos a serem
produzidos em cada um desses estágios planejados antecipadamente.
2. O desenvolvimento incremental é possível no modelo cascata - dirigido a
planos.
3. Iterações ocorrem dentro das atividades.

DESENVOLVIMENTO ÁGIL

1. Especificação, projeto, implementação e teste são intercalados e os produtos do

processo de desenvolvimento são decididos através de um processo de
negociação, durante o processo de desenvolvimento do software.
ESPECIFICAÇÕES DIRIGIDA A PLANOS E ÁGIL

Extreme Programming (XP):

Talvez seja o método ágil mais conhecido e amplamente usado.

Usa uma abordagem 'extrema' ao desenvolvimento iterativo.

➢ Novas versões podem ser construídas várias vezes por dia;

➢ Incrementos são entregues aos clientes a cada 2 semanas;

➢ Todos os testes devem ser realizados em todas as versões e cada versão só é aceita se os testes
forem concluídos com sucesso.

Princípios dos Métodos Ágeis E Do Xp

✓ O desenvolvimento incremental é mantido através de releases de sistema pequenos e frequentes.

✓ O envolvimento do cliente significa compromisso do cliente com a equipe em tempo integral.

✓ 'Pessoas e não processos’ por meio de programação em pares, propriedade coletiva do código e um
processo que evita longas horas de trabalho.

✓ Mudanças suportadas através de releases regulares de sistema.

✓ Manter a simplicidade através de constante refatoração de código.

O Ciclo de um Release em Extreme Programming

Práticas Do Extreme Programming (A)

Cenários de Requisitos:

➢ Em XP, um cliente ou usuário é parte do time de XP e é responsável na tomada de

decisões sobre requisitos.
➢ Requisitos do usuário são expressos como cenários.
➢ Esses são escritos em cartões e a equipe de desenvolvimento os divide em tarefas
de implementação. Essas tarefas são a base das estimativas de cronograma e
custo.
➢ O cliente escolhe as estórias que serão incluídas no próximo release baseando-se
nas suas prioridades e nas estimativas de cronograma.

XP E Mudanças

➢ O senso comum da engenharia de software diz que se deve projetar pensando em

mudanças.
➢ Vale a pena gastar tempo e esforço antecipando as mudanças já que,
posteriormente, esse esforço reduz custos no ciclo de vida.
➢ No entanto, o XP afirma que isso não vale a pena já que as mudanças não podem
ser antecipadas de forma confiável.
➢ Ao invés disso, propõe melhorias constantes do código (refatoração) para tornar
as mudanças mais fáceis quando essas precisam ser implementadas.

Refatoração

➢ A equipe de programação busca possíveis melhorias de software e as faz

mesmo quando essas não são uma necessidade imediata.
➢ O O que melhora a inteligibilidade do software e reduz a necessidade de
documentação.
➢ O Torna-se mais fácil fazer mudanças porque o código é bem construído e
limpo.
➢ O No entanto, algumas mudanças requerem refatoração da arquitetura, o que
é muito mais caro.
✓ Os métodos ágeis são métodos de desenvolvimento incremental centrados no
desenvolvimento rápido, frequentes releases de software, redução de overheads
de processo e produção de código de alta qualidade. Eles envolvem o cliente
diretamente no processo de desenvolvimento.
✓ A decisão de quando usar uma abordagem ao desenvolvimento ágil ou dirigida a
planos deve depender do tipo de software que está sendo desenvolvido, das
capacidades da equipe de desenvolvimento e da cultura da companhia
desenvolvedora do sistema.
✓ O Extreme Programming é um método ágil bem conhecido que integra uma série
de boas práticas de programação como por exemplo releases de software
frequentes, melhorias contínuas de software e participação do cliente na equipe de
desenvolvimento.

Testes em XP

✓ Em XP, os testes são fundamentais, XP desenvolveu uma abordagem em que o

programa é testado depois de que cada alteração é feita.
✓ O Características de testes em XP:

1. Desenvolvimento TEST-FIRST.

2. Desenvolvimento de testes incrementais a partir de cenários.

3. Envolvimento do usuário no desenvolvimento de testes e validação.

4. Cada vez que um novo release é construído, são usados frameworks de testes
automatizados para executarem todos os testes de componentes.
Desenvolvimento TEST-FIRST

✓ Escrever testes antes do código esclarece os requisitos que devem ser

implementados.
✓ Os testes são escritos na forma de programas ao invés de dados para que
possam ser executados automaticamente.
✓ Os testes incluem checagem de que foram executados corretamente.
✓ O Geralmente conta com um framework de testes como o Junit.
✓ O Todos os testes anteriores e novos são executados automaticamente quando
uma nova funcionalidade é adicionada, para checar se a nova funcionalidade não
introduziu erros.

Envolvimento do Cliente
✓ A função do cliente no processo de testes é ajudar a desenvolver testes de aceitação
para as estórias que serão implementadas no próximo release do sistema.
✓ O cliente, parte da equipe, escreve testes conforme o desenvolvimento prossegue.
Todo código novo é validado para garantia de que seja o que o cliente precisa.
✓ No entanto, a pessoa que assume a função de cliente tem tempo limitado disponível
e não pode trabalhar em tempo integral com a equipe de desenvolvimento.
✓ Eles podem pensar que prover os requisitos seja contribuição suficiente e se
tornarem relutantes em se envolverem no processo de testes.

A Automação de Testes
✓ A automação de testes significa que os testes são escritos como componentes executáveis antes
que a tarefa seja implementada.
➢ Esses componentes de teste devem ser autômatos, devem simular a submissão de entrada
para ser testada e devem avaliar se o resultado atende à especificação de saída. Um
framework de testes automatizados (ex. Junit) é um sistema que facilita a escrita de testes
executáveis e a submissão de um conjunto de testes para execução.
O Como os testes são automatizados, sempre existe um conjunto de testes que podem ser
rapidamente e facilmente executados.
 ➢ Quando qualquer funcionalidade é adicionada ao sistema os testes podem ser executados e
problemas que o novo código possa ter introduzido podem ser percebidos imediatamente.

Dificuldades dos Testes Em XP

✓ Os programadores preferem programar a testar e as vezes eles usam atalhos quando escrevem
esses testes. Por exemplo, eles podem escrever testes incompletos que não avaliam todas as
possíveis exceções que podem ocorrer.
✓ Alguns testes podem ser muito difíceis de serem escritos de forma incremental. Por exemplo, em
uma interface de usuário complexa, geralmente é difícil escrever testes de unidade para o código
que implementa a 'lógica de display' e o fluxo de trabalho entre telas.
✓ É difícil julgar se um conjunto de testes está completo.
✓ Embora você tenha vários testes de sistema, o conjunto dos testes pode não prover uma
cobertura completa.

PROGRAMAÇÃO EM PARES
✓ Em XP, programadores trabalham em pares na mesma estação de trabalho para desenvolver
softwares.
✓ Isso ajuda a desenvolver propriedade coletiva do código e espalha o conhecimento na equipe.
✓ Serve como um processo de revisão informal pois cada linha do código é observada por mais de
uma pessoa.
✓ Encoraja a refatoração pois toda a equipe pode se beneficiar dessa atividade.
✓ Avaliações sugerem que a produtividade do desenvolvimento com programação em pares é
similar à de duas pessoas trabalhando independentemente.
✓ Os pares são criados dinamicamente para que todos os membros da equipe trabalhem com cada
um dos outros membros durante o processo de desenvolvimento.
✓ O compartilhamento de conhecimento que acontece durante a programação em pares é muito
importante por reduzir os riscos gerais de um projeto quando um membro da equipe vai embora.
✓ A programação em pares não é necessariamente ineficiente e existem evidências de que o
trabalho em pares é mais eficiente do que 2 programadores trabalhando separadamente.

VANTAGENS DA PROGRAMAÇÃO EM PARES

1. Apoia a ideia da propriedade coletiva e responsabilidade pelo sistema.
2. Os indivíduos não são responsabilizados por problemas no código. Ao invés disso, a equipe
tem responsabilidade coletiva na solução desses problemas.
 3. Funciona como um processo de revisão informal porque cada linha de código é observada
por pelo menos duas pessoas.
4. Ajuda a apoiar a refatoração, que é um processo de melhoria do software.
5. Em processos nos quais a programação em pares e a propriedade coletiva são usados,
outros se beneficiam imediatamente da refatoração, o que provavelmente fará com que
apoiem o processo.

GERENCIAMENTO ÁGIL DE PROJETOS

✓ A principal responsabilidade de gerentes de projeto de software é gerenciar o projeto para que
o software seja entregue em tempo e dentro do orçamento planejado para o projeto.
✓ A abordagem padrão para o gerenciamento de projeto é dirigida a planos.
✓ Os gerentes estruturam um plano para o projeto mostrando o que deve ser entregue, quando
deve ser entregue e quem irá trabalhar no desenvolvimento dos entregáveis.
✓ O gerenciamento ágil de projetos requer uma abordagem diferente, adaptada ao
desenvolvimento incremental e aos pontos fortes particulares dos métodos ágeis.

SCRUM
✓ É um processo para construir software incrementalmente em ambientes complexos, onde os
requisitos não são claros ou mudam com muita frequência.
✓ É um método ágil genérico, mas seu foco é na gerência de desenvolvimento iterativo ao invés de
práticas ágeis específicas.
✓ É um time trabalhando como uma unidade altamente integrada com cada membro
desempenhando um papel bem definido e focando num único objetivo.
✓ O objetivo do Scrum é fornecer um processo conveniente para projetos e desenvolvimento
orientado a objetos.
✓ A metodologia é baseada em princípios semelhantes aos de XP: equipes pequenas, requisitos
pouco estáveis ou desconhecidos, e iterações curtas para promover visibilidade para o
desenvolvimento.

FASES NO SCRUM
1. A fase inicial é uma fase de planejamento em que se estabelece os objetivos gerais do projeto
e se projeta a arquitetura do software.
2. Essa é seguida por uma série de ciclos de Sprint, em que cada ciclo desenvolve um incremento
do sistema.
 3. A fase de encerramento do projeto finaliza o projeto, completa a documentação necessária
como frames de ajuda do sistema e manuais de usuário e avalia as lições aprendidas no
projeto.

O PROCESSO SCRUM

O CICLO DE SPRINT
✓ Assim que isso é definido, a equipe se organiza para desenvolver o software.
✓ O Durante esse estágio a equipe é isolada do cliente e da organização, com todas as
comunicações canalizadas por meio do chamado “Scrum Master”.
✓ O A função do Scrum Master é proteger a equipe de desenvolvimento de distrações
externas.
✓ O Ao final do Sprint o trabalho feito é revisto e apresentado aos stakeholders. Assim o
próximo ciclo de Sprint começa.

TRABALHO EM EQUIPE NO SCRUM

✓ O Scrum Master é um facilitador que organiza reuniões diárias, mantêm o backlog do
trabalho a ser feito, grava decisões, mede o processo usando o backlog e comunica-se com
os clientes e a gerência fora da equipe.
✓ A equipe inteira comparece às reuniões diárias curtas nas quais todos os membros da
equipe compartilham informações, descrevem seu progresso desde a última reunião,
descrevem os problemas que surgiram e o que está planejado para o dia seguinte.
✓ Com isso, todos na equipe sabem o que está acontecendo e, caso ocorra um problema,
podem replanejar o trabalho a curto prazo para lidar com a situação.
BENEFÍCIOS DO SCRUM
✓ O produto é dividido em um conjunto de partes gerenciáveis e inteligíveis.
✓ Os Requisitos instáveis não impedem o progresso.
✓ O Toda a equipe tem visão de tudo e consequentemente a comunicação da equipe é
melhorada.
✓ O Os clientes recebem a entrega dos incrementos no tempo certo, além do feedback de
como o produto funciona.
✓ O Se estabelece a confiança entre os clientes e os desenvolvedores e se cria uma cultura
positiva na qual todos acham que o projeto dará certo.

7. Referências
✓ ANDRADE, Mayb. Qualidade de Software. 1ª Ed. Rio de Janeiro: SESES, 2015. Disponível em:
✓ https://repositoriov2.azurewebsites.net/api/objetos/efetuaDownload/405d3e91-3eef-4471-9ead-702cee3d2861
✓ PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software. Porto Alegre: AGMH, 2016. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788580555349/
✓ SOMMERVILLE, Ian. Engenharia de Software. 10ª Ed. São Paulo: Pearson Prentice Hall, 2011. Disponível em:
https://plataforma.bvirtual.com.br/Leitor/Loader/168127/pdf
✓ Amui, Saulo. Processos de Desenvolvimento de Software. 1ª Ed.. Rio de Janeiro: SESES, 2015.Disponível em:
https://repositoriov2.azurewebsites.net/api/objetos/efetuaDownload/faf38cab-2fb5-48d6-ac0b-a2685e2f5f48
✓ Braga, Pedro H. C. (Organizador). Testes de Software. 1ª Ed.. São Paulo: Pearson, 2016. Disponível em:
https://plataforma.bvirtual.com.br/Leitor/Publicacao/150962/pdf/
✓ Galloti, Giocondo M. A. (Organizador). Qualidade de Software. 1ª Ed.. São Paulo: Pearson Education do Brasil, 2016.
Disponível em: https://plataforma.bvirtual.com.br/Acervo/Publicacao/124148
✓ PADUA FILHO, Wilson de Paula. Engenharia de Software. 3ª Ed.. Rio de Janeiro: LTC, 2009. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/978-85-216-1992-5/
✓ SCHACH, Stephen R. Engenharia de Software. 7ª Ed. Porto Alegre: ArtMed, 2010. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788563308443/