ENGENHARIA DE SOFTWARE 

 
Métodos Ágeis 
 
Em  desenvolvimento  de  software,  o  termo  Ágil  significa,  basicamente, a busca  em 
simplificar  as  coisas, tanto  em nível  de  projeto  quanto  de equipe. A parte  de projeto 
pode ser traduzida em reduzir ao máximo o nível de complexidade de planejamento 
ao  mesmo  tempo  em  que  todos  os  esforços  são  concentrados  em  priorizar  aquilo 
que traz valor pro cliente.  
 
Princípios do Manifesto Ágil: 
• ​Indivíduos e a interação entre eles​  mais que processos e ferramentas;  
• ​Software em funcionamento​  mais que documentação abrangente;  
• ​Colaboração com o cliente​  mais que negociação contratual;  
• ​Responder a mudanças​  mais que seguir um plano. 
•  Nossa  maior  prioridade  é  satisfazer  o  cliente  através  da  entrega  contínua  e 
adiantada de software com valor agregado.  
•  Mudanças  nos  requisitos  são  bem­vindas,  mesmo  tardiamente  no 
desenvolvimento.   Processos  ágeis  tiram  vantagem  das  mudanças  visando 
vantagem competitiva para o cliente.  
•  Entregar  frequentemente  software   funcionando,  de  poucas  semanas  a  poucos 
meses, com preferência à menor escala de tempo.  
• Pessoas  de negócio e desenvolvedores devem trabalhar diariamente  em conjunto 
por todo o projeto.  
•  Construa  projetos  em  torno  de  indivíduos  motivados.  Dê  a  eles  o  ambiente  e  o 
suporte necessário e confie neles para fazer o trabalho.  
•  O  método  mais  eficiente  e  eficaz  de  transmitir  informações  para  e  entre  uma 
equipe de desenvolvimento é através de conversa face a face.  
• Software funcionando é a medida primária de progresso. 
•  Os  processos  ágeis  promovem  desenvolvimento  sustentável.  Os  patrocinadores, 
desenvolvedores  e  usuários  devem  ser  capazes  de  manter  um  ritmo  constante 
indefinidamente.  
• Contínua atenção à excelência técnica e bom design aumenta a agilidade.  
•  Simplicidade  ­  a  arte  de  maximizar  a  quantidade  de  trabalho   não  realizado  ­  é 
essencial.  
•  As  melhores  arquiteturas,  requisitos  e  designs  emergem  de  equipes 
autoorganizáveis. 
  • Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então 
refina e ajusta seu comportamento de acordo. 
 
 
 SCRUM 
 

 
Scrum  é  um  dos  métodos  ágeis mais populares na atualidade e tem foco maior nos 
aspectos  gerenciais  do  desenvolvimento  de  software.  Nele,  cada  iteração   é 
chamada de sprint.  Geralmente cada  sprint tem um  período de mês que pode variar 
de  poucos  dias  a  algumas  semanas.  As  pessoas  envolvidas  no  processo  de 
desenvolvimento  são dividas no Scrum em três papéis principais: o Scrum Master, o 
product Owner (dono do produto) e a equipe. 
No  Scrum,  os  projetos  são  dividos  em  ciclos  (tipicamente  mensais)  chamados  de 
Sprints​.  O  ​
Sprint  representa  um  Time   Box  dentro  do  qual  um  conjunto  de 
atividades  deve  ser  executado.​ Metodologias  ágeis  de  desenvolvimento  de 
software  são  iterativas,  ou  seja,  o  trabalho  é  dividido  em  iterações,  que  são 
chamadas de Sprints no caso do Scrum. 

As  funcionalidades  a  serem  implementadas  em  um  projeto  são  mantidas  em  uma 
lista  que  é  conhecida  como  ​
Product Backlog​ .  No início  de cada Sprint, faz­se  um 
Sprint  Planning Meeting​ , ou seja, uma reunião de planejamento na qual o ​ Product 
Owner prioriza os itens do ​ Product Backlog e a equipe seleciona as atividades que  
ela  será  capaz  de  implementar  durante  o  Sprint  que  se inicia.  As  tarefas  alocadas 
em um Sprint são transferidas do ​ Product Backlog​  para o ​Sprint Backlog​ . 

A  cada  dia  de   uma  Sprint,  a  equipe  faz  uma  breve  reunião  (normalmente  de 
manhã), chamada  ​ Daily Scrum​ .  O  objetivo é  disseminar conhecimento sobre o que 
foi feito  no  dia  anterior,  identificar  impedimentos  e  priorizar o trabalho do dia que se 
inicia. 
Ao  final  de  um  Sprint,  a  equipe  apresenta  as  funcionalidades  implementadas  em 
uma  ​ Sprint  Review  Meeting​ .  Finalmente,  faz­se  uma  ​
Sprint  Retrospective  e  a  
equipe parte para o planejamento do próximo Sprint. Assim reinicia­se o ciclo.  

XP 

Codificar  é  uma  atividade  essencial  para  o  desenvolvimento  de software, afinal de 

contas,  sem  código  não  existe  software  algum.  Nessa  etapa,  é  extremante 
importante  que  o  cliente  continue  acessível  para  que  possa  oferecer  feedback  e 
responder às diversas dúvidas que surgem durante o desenvolvimento.  

Com XP, os  testes  de  unidade são escritos antes do código de produção (test­first); 

todo  o  código  fonte  que  será  executado  em  produção  é  ​ desenvolvido em pares​ ;  a 
integração  do   código  fonte  é  realizada  frequentemente  através  da  prática  de 
integração  contínua​ ;  e  o  ​
código  fonte  é  coletivo​
,  ou  seja,  pertence  a  todos  os 
membros  da  equipe,  e  deve  ser  escrito  de  acordo  com  os  padrões  definidos  pelo 
próprio time.  

Testar  é  uma  atividade  de  extrema  importância  para  garantir  a  qualidade  do 
software  e  não  é  algo  opcional  com  XP,  ao  contrário,  todo  código  deve  possuir 
testes de  unidade, e todos os testes  devem ser executados com sucesso  antes que 
uma  entrega  seja  feita.  Quando  um  defeito  é  encontrado,  cria­se  um  teste  de 
unidade para assegurar que esse mesmo defeito jamais volte a acontecer. No XP os 
testes  são  escritos  antes  do  código  de  produção  através  de  TDD  (Test  Driven 
Development, ou Desenvolvimento Guiado por Testes). 

Práticas da XP 
Praticas  é  o  que  ocorre  no  dia  a  dia  de  uma  equipe  de programação  que utiliza a 
metodologia XP. 
A  seguir  serão  explicadas  as  12  praticas  que  envolvem  a  Programação  Extrema 
segundo Kent [BECK, 2004]: 
  
O jogo do planejamento: 
É  o  jogo  jogado  por  todos  os  envolvidos no  projeto, é o escopo  do  que deverá ser 
feito  com  o  projeto, as etapas do desenvolvimento, isso significa que as pessoas na 
área  de  negócio  têm  que  decidir  sobre  o  escopo,  prioridade,  composição  das 
versões e datas de entrega. 
  
Entregas frequentes: 
Esse procedimento  é  para  manter  o  cliente  informado de  que  o sistema  está sendo 
feito  e  de  forma  rápida,  não  significa  que  será  entregue  mais  rápido,  em  vez  de 
entregar  tudo  em  um  ano,  pode­se  fazer  esse   procedimento  todo  mês,  assim  em 
cada mês é entregue  um  modulo do  sistema,  ajudando também a equipe, para que 
saibam se o que estão fazendo está de acordo com que o cliente quer. 
  
Metáfora: 
Aqui  podemos criar  uma  história para o sistema,  fazendo  com  que  todos  entendam 
o  que  o  mesmo  fará   quando  for  entregue,  e  também qual  foi  a  história  do  sistema 
antes  de  começarem   a  implementá­lo,  assim  todos  vão  falar  a  mesma  língua  e 
programar de forma coerente e conjunta. 
  
Projeto simples: 
Aqui  a  equipe  faz  com  que  o  sistema  seja  feito  de  forma  mais  simples  possível, 
deixando  o  que  é  complexo  de  fora,  pois  se  torna  desnecessário,  pois  o  que  é 
simples é que realmente é para ser feito. 
  
Testes: 
É um tópico muito importante, pois depois de digitar os códigos os programadores e 
clientes  fazem  os  testes  para  que  possam  ter certeza  de  o  que está sendo  pedido 
foi o que  acabaram de  fazer,  então  isso  será repetido em todos os módulos ate que 
tenha  que  ser  feito  no  projeto  todo,   pois  cada  módulo  testado   e  aprovado 
proporciona maior segurança para os envolvidos. 
  
Refatoração: 
Trata­se simplesmente  do  programador procurar um jeito melhor de digitar o código, 
depois  que  ele  termina  um  modulo  ele  fica   pensando  como  é  possível   fazer  o 
mesmo  código de  uma melhor  forma, pois assim ele pode simplificar uma função ou 
mesmo dar um jeito de o sistema responder de forma mais rápida. 
  
Programação em pares: 
É a nova  forma  de  programar,  fazendo com que um integrante da dupla fique com o 
mouse  e o teclado programando, enquanto o outro está pensando se tudo aquilo vai 
dar  certo mesmo. Se  há necessidade de todas aquelas linhas de código. Se há uma 
melhor  forma  para  simplificar  o  código.  Assim,  a  dupla  programa  de  uma  melhor 
forma. 
  
 
 
Propriedade coletiva: 
Significa  que  todos  da  equipe  estão  aptos  a  alterar qualquer parte do código, pois o 
mesmo  é  feito  de  uma   forma  simples  para  que  todos   entendam.  Assim,  a 
propriedade  coletiva  ocorre  é  necessário  que  siga  um  padrão  de  codificação, 
fazendo  também  que  a  equipe  toda   fique  sabendo  o   que  está  sendo  feito  pela  a 
comunicação do grupo. 
  
Integração contínua: 
O  que  a  equipe  deve  fazer  é  sempre  está  melhorando  o  código,  fazendo  vários 
testes por dia  e procurando a cada nova tentativa fazer de uma melhor forma, assim 
o  sistema  se  mantém  vivo  para  novas  modificações  e  atualizações  que  possam 
ocorrer. 
  
Semana de 40 horas: 
Essa  é  a  ideia  de  que  se  a  equipe   estiver  trabalhando  mais  do  que  40  horas 
semanais  por mais  de  duas semanas significa que algo está errado no projeto. Pois 
as  horas  extras  não  devem  se  tornar  rotina.  As  mesmas   são  para  cumprir  algo 
rápido e não se tornar obrigações. 
  
Cliente presente: 
Esse  cliente  se  tornará  membro  da  equipe  enquanto  o  seu  projeto  estiver  sendo 
codificado,  pois servirá para responder as questões levantadas no desenvolvimento. 
Assim,  os  desenvolvedores  terão  uma  melhor  visão  do   projeto  fazendo  com  que 
seja  feito de  uma  forma  mais  simples  e  correta, pois qualquer  dúvida  o  cliente  está 
junto para saná­los. 
  
Padrões de codificação: 
Toda  a  codificação  será  feita  da  mesma  forma  por  toda  a  equipe,  fazendo  assim 
com  que  todos  entendam  o  que  está  sendo  feito,  e  quem  estiver  apto  a  fazer 
mudanças está liberado para fazer, pois conhece a forma como o código foi feito. 
 

ENGENHARIA DE REQUISITOS 

Requisitos Funcionais: 

Define  uma  função  de  um  software ou parte  dele. Ele é o conjunto de entradas, seu 

comportamento  e  sua  saída,  ou  seja,  envolve  cálculos,  lógicas  de  trabalho, 
manipulação  e  processamento  de  dados,  entre  outros.  Dentro  dos  requisitos 
funcionais  também  encontram­se  a  arquitetura  do  aplicativo,  diferentemente  da 
arquitetura técnica, que pertence aos requisitos não funcionais. 

Requisitos não funcionais: 

Requisitos  não  funcionais  são  relacionados  ao  uso  da  aplicação  em  termos  de 
desempenho,  usabilidade,  confiabilidade,  disponibilidade,  segurança  e  tecnologias 
envolvidas.  Muitas  vezes,  os  requisitos  não  funcionais  acabam  gerando  restrições 
aos funcionais. 
•  Requisitos  de  produtos  :  Requisitos  que  especificam  o  comportamento  do   produto.Ex. 
portabilidade; tempo na execução; confiabilidade,mobilidade, etc. 

•  Requisitos  da  organização:  Requisitos  decorrentes  de  políticas  e  procedimentos 

corporativos. Ex. padrões, infra­estrutura,etc. 

•  Requisitos  externos:  Requisitos  decorrentes  de fatores externos ao sistema e ao processo 

de  desenvolvimento.  Ex.   requisitos  de  interoperabilidade,  legislação,localização  geográfica 
etc. 

•  Requisitos  de  facilidade  de  uso.  Ex.:  usuários  deverão  operar  o  sistema  após  um 
determinado tempo de treinamento. 

•  Requisitos  de  eficiência.  Ex.:  o  sistema  deverá  processar  ​

n  requisições  por  um 
determinado tempo. 

•  Requisitos  de  confiabilidade.  Ex.:  o  sistema  deverá  ter  alta  disponibilidade,  p.exemplo, 
99% do tempo. 

• Requisitos de portabilidade. Ex.: o sistema deverá rodar em qualquer plataforma. 

•  Requisitos  de  entrega.Ex.:  um  relatório  de   acompanhamento  deverá  ser  fornecido  toda 
segunda­feira. 

• Requisitos de implementação.: Ex.: o sistema deverá ser desenvolvido na linguagem Java. 

• Requisitos de padrões.: Ex. uso de programação orientada a objeto sob a plataforma A. 

• Requisitos de interoperabilidade.:Ex. o sistema deverá se comunicar com o SQL Server. 

•  Requisitos  éticos.  Ex.:  o  sistema  não  apresentará aos usuários  quaisquer dados de cunho 

privativo. 
•  Requisitos  legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, 
etc. 

• Requisitos de Integração. Ex.: o sistema integra com outra aplicação. 

DIAGRAMA DE CLASSE 

Classe​
: Elemento abstrato que representa um conjunto de objetos por uml. A classe contém 
a  especificação  do  objeto;  suas  características: atributos (características) e métodos (ações 
/ comportamentos). 

Os diagrama de classes ilustram atributos e operações de uma classe e as restrições

como que os objetos podem ser conectados ; descrevem também os tipos de objetos
no sistema e os relacionamentos entre estes objetos que podem ser : associações e
abstrações.

É  uma  modelagem  muito  útil  para  o  desenvolvimento  de  sistemas,  pois  define  todas  as 
classes  que  o  sistema  necessita  possuir  e  é  a  base  para  a  construção   dos  diagramas  de 
comunicação​
, ​
sequência​
 e ​
estados​
. 

PROJETO DE ARQUITETURA 
A  ​
arquitetura  de  software  de  um  sistema  consiste  na  definição  dos  componentes  de  
software,  suas  propriedades  externas,  e  seus  relacionamentos  com  outros  ​
softwares​
.  O  
termo  também  se  refere  à  ​
documentação  da  arquitetura  de  software   do  sistema.  A 
documentação  da  arquitetura   do  software  facilita:  a  comunicação  entre  os  ​
stakeholders​
, 
registra  as  decisões  iniciais acerca do ​
projeto de alto­nível, e permite o reúso do projeto dos 
componentes e padrões entre projetos. 

EX: MVC e Cliente Servidor.