Revisão – 1 AV - Engenharia de

software
Engenharia de Software
Prof. Isabella Santos
Engenharia de Software
• É uma disciplina da engenharia dedicada a todos os
aspectos da produção de software.
•  Engenheiros de software devem adotar uma
    abordagem sistemática e organizada para o seu
trabalho e usar técnicas e ferramentas
    apropriadas, de acordo com o problema a ser
    resolvido, e com as restrições e recursos
    disponíveis.
• Responsabilidade profissional e ética.
Fonte: Ian Sommerville
 Uma Visão Genérica da E.S.
Análise do Planejamento Análise de
De nição Sistema do Projeto Requisitos
de Software

O Que?
Projeto do Codi cação Testes
Processo de Desenvolvi Software
Software mento

O Como?

Correção Adaptação Melhora

Manutenção mentos

A Obrigação ...
Engenharia de Software
 Engenharia de Software
• Métodos e Técnicas:   detalhes de como fazer
• Metodologias: como aplicar
• Ferramentas:   automatizam os métodos, dão
apoio a utilização.                         CASE  =>
(Computer­Aided Software Engineering):
Ferramentas integradas para desenvolver
software.
abrange um conjunto de três elementos fundamentais:
Métodos, Ferramentas e Procedimentos

Principais metas: melhorar a qualidade de produtos
de software, aumentar a produtividade do pessoal
técnico e aumentar a satisfação do cliente.
Engenharia de Software
conjunto de etapas que envolve
métodos
ferramentas
procedimentos

Essas etapas são conhecidas como componentes de CICLO
DE  VIDA  DE  SOFTWARE
ou Processo de Software
Engenharia de Software
Conceitos Básicos
Ciclo de Vida do Software

    O ciclo de vida de um software descreve as fases pelas quais o
software passa desde a sua concepção até ficar sem uso algum.
Ciclo de Vida do Desenvolvimento de
Sistemas
Abordagens - Ciclo de Vida do
Desenvolvimento de Sistemas
• Abordagens para o desenvolvimento de sistema:
▫ Clássica;
▫ Espiral;
▫ Prototipação.
Abordagens - Ciclo de Vida do
Desenvolvimento de Sistemas
Ciclo de Vida Clássico – Problemas
O uso da implementação bottom­up é uma das
maiores fraquezas deste ciclo de vida, pois:
▫   Nada está terminado até que se complete todas
as fases. Se houver um atraso e o prazo final
coincidir com a fase de testes, não se terá nada
para apresentar ao usuário.
▫   Os erros mais comuns são encontrados no início
do período de testes, enquanto os mais sérios são
encontrados apenas no final.
Abordagens - Ciclo de Vida do
Desenvolvimento de Sistemas
Ciclo de Vida Clássico – Problemas
cont...
▫   A localização do módulo que contém o erro pode
ser extremamente difícil se este for detectado
durante o teste de sistema.

• Uma segunda fraqueza é a organização das fases
de forma sequencial, ou seja, a fase de Análise
somente teria início após a conclusão da fase de
Levantamento de Dados e assim por diante.
Abordagens - Ciclo de Vida do
Desenvolvimento de Sistemas
• Ciclo de Vida da Prototipação – distinção entre o SI
Real e o Protótipo.
▫ Sistemas reais têm a intenção de uso operacional e
devem seguir determinados padrões no que diz
respeito a sua qualidade, segurança, desempenho,
capacidade, robustez e facilidade de manutenção.
▫ Em contraste, protótipos visam clareza na
visualização de determinados aspectos de um sistema
sobre os quais há incerteza. Protótipos são usados
para verificar a precisão das hipóteses feitas sobre
esses aspectos.
▫ Assim, diferente dos sistemas reais, os protótipos são
tipicamente incompletos e não têm a intenção de
funcionar sem falhas (toleráveis).
Abordagens - Ciclo de Vida do
Desenvolvimento de Sistemas
• Ciclo de Vida Prototipação– Problemas
▫ O cliente vê o protótipo e tem pressa para colocá­
lo em funcionamento, não levando em
consideração a qualidade global do sistema;
▫   Muitas vezes o desenvolvedor quer colocar o
protótipo em funcionamento rapidamente, com
isso, um sistema operacional ou linguagem de
programação imprópria pode ser usada,
simplesmente porque está à disposição e é
conhecida.
Abordagens - Ciclo de Vida do
Desenvolvimento de Sistemas
• Ciclo de Vida Espiral – Atividades:
▫ Planejamento: é a determinação dos objetivos,
alternativas e restrições do projeto.
▫   Análise dos Riscos: é a análise das alternativas e
a resolução dos riscos.
▫   Engenharia: desenvolvimento do produto.
▫   Avaliação feita pelo Cliente: é a avaliação dos
resultados obtidos nas atividades da engenharia.
Abordagens - Ciclo de Vida do
Desenvolvimento de Sistemas
• Ciclo de Vida Espiral – Problemas

▫ O modelo Espiral trabalha bem com sistemas
desenvolvidos dentro da própria empresa, mas os sistemas
terceirizados não possuem a mesma flexibilidade para
obter alterações possíveis;

▫ Em geral, os passos do processo do modelo Espiral
necessitam que todos os participantes do desenvolvimento
do sistema estejam operando conscientemente no contexto.
Alguns exemplos disso são os detalhes que devem aparecer
mais minuciosamente, os objetivos, as técnicas para
estimar e sincronizar o esquema do projeto.
Ciclo de Vida do Desenvolvimento de
Sistemas
• Os sistemas de computadores são complexos e
geralmente ligam vários sistemas tradicionais
potencialmente fornecidos por diferentes
fornecedores de software.

• Para gerenciar esse nível de complexidade, uma
série de modelos ou metodologias de SDLC
foram criadas, como o "modelo em cascata",
"espiral", "desenvolvimento ágil de software“ e
"incremental“.
Metodologias - Ciclo de Vida do
Desenvolvimento de Sistemas
• O Ciclo de Vida de Desenvolvimento de Sistemas
pode ser descrito ao longo do espectro desde o ágil
ao iterativo e sequencial. 

Metodologias:
▫ Metodologias Ágeis;
▫ Metodologias interativas;
▫ Método de desenvolvimento de sistemas dinâmicos;
▫ Modelos sequênciais;
▫ Prototipagem.
Metodologias - Ciclo de Vida do
Desenvolvimento de Sistemas
• Metodologias Ágeis
▫ Focam em processos leves que permitem
mudanças rápidas ao longo do ciclo de
desenvolvimento.

• Exemplo: SCRUM e XP
Metodologias - Ciclo de Vida do
Desenvolvimento de Sistemas

• Metodologias iterativas e o método de
desenvolvimento de sistemas dinâmicos
▫ Focam no escopo de projeto limitado e na
ampliação ou melhoria de produtos através de
várias iterações.

• Exemplo: Rational Unified Process – RUP e
Espiral
Metodologias - Ciclo de Vida do
Desenvolvimento de Sistemas
• Modelos sequênciais
▫ Focam em planejamento completo e correto para
conduzir grandes projetos e nos riscos para
resultados bem sucedidos e previsíveis.

• Exemplo: modelo cascata
Metodologias - Ciclo de Vida do
Desenvolvimento de Sistemas
• Prototipagem
▫ Descreve uma abordagem que tenta satisfazer as
necessidades do usuário focalizando a interface
do usuário. Os estágios do projeto e de
desenvolvimento, no que concerne à interface de
usuários, repetem­se até que o usuário esteja
satisfeito.
Ciclo de Vida de Projetos de
Desenvolvimento de Sistemas
A Seleção de um Caminho
• A melhor abordagem para um determinado projeto
depende, em grande parte, da natureza do projeto e
da natureza da organização.

▫  A abordagem em cascata funciona melhor com
projetos de grande porte, complexos, que têm
numerosos interessados, afetam a empresa toda e não
podem ser facilmente divididos em subprojetos. Ela
também funciona bem com organizações que têm
uma cultura formal e uma estrutura hierárquica.
Ciclo de Vida de Projetos de
Desenvolvimento de Sistemas
A Seleção de um Caminho – cont..
▫  A abordagem em espiral e a programação ágil funcionam
bem nas organizações dinâmicas, que podem tolerar a
ambiguidade e necessitam obter resultados rapidamente.
▫ O caminho em espiral pode apresentar melhores
resultados quando adotado para projetos que se dividem
facilmente em subprojetos e para projetos mais simples,
em especial o desenvolvimento de sistemas de usuário
único ou que afetam um pequeno departamento.
▫ A programação ágil é bem­sucedida em ambiente onde as
necessidades do usuário são difíceis de especificar ou
mudam rapidamente.
Ciclo de Vida de Projetos de
Desenvolvimento de Sistemas
A Seleção de um Caminho – cont..
▫  A prototipagem funciona melhor para projetos de
pequeno e médio portes. Ela funciona bem onde a
cultura suporta equipes funcionalmente mistas. A
prototipagem pode ser combinada com a
abordagem em espiral e ser usada para um ou
mais dos subprojetos em um desenvolvimento em
espiral.
 Processo
- Atualmente já está consolidada a idéia que construir
software é um processo iterativo, que tem como resultado a
incorporação do conhecimento coletado

- O que é um processo de software do ponto de vista

técnico???
“Processo de software é definido como uma
metodologia para as atividades, ações e
tarefas necessárias para desenvolver software
de alta qualidade”
(Roger S. Pressman, ES, pág. 52)
 Modelo de Processo
Genérico
Modelo de processo genérico
- Baseado em atividades metodológicas genéricas
e em atividades de apoio, que são aplicadas ao
longo do processo.

- Revendo as atividades...
 Modelo de Processo
Genérico
Cinco atividades de uma metodologia de
processo genérica:
1) Comunicação: é importante se comunicar com os
interessados (clientes, usuários, etc.) para
levantamento das necessidades do software.
2) Planejamento: é preciso “criar um mapa da
jornada”. O planejamento ajudar a antever os
passos da jornada e possibilita a preparação prévia.
Neste mapa devem constar: tarefas técnicas, riscos
prováveis, recursos que serão necessários, produtos
resultantes, cronograma de trabalho, etc.
 Modelo de Processo
Genérico
Cinco atividades de uma metodologia de
processo genérica:

3) Modelagem: é prática de criar modelos que

norteia esta atividade. Modelo é um “esboço” de
algo, que pode dar uma boa idéia do todo.

4) Construção: contempla geração de código

(manual ou automatizada) e testes necessários.
 Modelo de Processo
Genérico
Cinco atividades de uma metodologia de
processo genérica:

5) Emprego: é a entrega do software ao cliente,

que avalia e fornece um feedback sobre o
produto.
 Modelo de Processo
Genérico
1) Comunicação
2) Planejamento
3) Modelagem
4) Construção
5) Emprego

Importante: essas 5 atividades metodológicas
genéricas poderão ser utilizadas em sistemas
pequenos, sistemas grandes, sistemas web, etc. Mas
os detalhes do processo de software serão bem
diferentes em cada caso.
 Modelo de Processo
Genérico
... Voltando ao modelo de processo
genérico
- Um aspecto deste processo precisa ser definido: o
fluxo do processo

- O fluxo define a sequência de execução das

atividades
 Modelos de Processo
Prescritivo

- Os Modelos de Processo Prescritivo são apresentados como

alternativas onde a “ordem” e a “consistência do projeto”
são dominantes.
 Modelos de Processo
Prescritivo

- Veremos três modelos prescritivos

1) Modelo Cascata
2) Modelos de Processo Incremental
3) Modelos de Processo Evolucionário (Prototipação e Espiral)
 Modelo Cascata
- Representação do modelo cascata:

Comunicação
­ Inicio do
projeto
­ Planejament
Levantamento o
de necessidades ­ Estimativas
­  Cronograma Modelagem
­  Acomp. ­ Análise
­  Projeto Construção
­ Codificação
Entrega
­  Testes
­ Entrega
­  Suporte
­  Feedback
 Modelo Incremental
Modelo Incremental:

- Provê fornecimento de um conjunto funcional (primeiro

incremento) aos usuários de maneira mais rápida

- Em momento posteriores esta entrega será refinada e

expandida

- Isto é uma forma incremental de entregar software

 Modelo Incremental
Comunicaçã
o
Planejament
o
Modelagem (análise,
Funcionalidades e recursos do

projeto)
Construção (codificação,
teste)
Emprego (entrega,
feedback)
Incremento n°
“n”
Incremento
n° 3
Incremento
n° 2
Incremento Entrega do
n° 1 “n”°
software

Entrega do incremento
3°
Entrega do incremento
2°
Entrega do incremento
1°
incremento
Cronograma do
Projeto
 Modelo Evolucionário
Modelos de Processo Evolucionário:

- Aplicáveis em... Situações que, por conta das pressões de

prazo, não permitem aprofundamento nos requisitos antes
construir algo

- Aplicáveis quando... um conjunto mais detalhado de

requisitos não pode ser definido sem que antes um conjunto
mais básico de requisitos seja colocado em prática
(situação comum em ambientes muito novos, onde tudo é
novo)
 Modelo Evolucionário
­  Modelos evolucionários são iterativos

- Permitem desenvolver versões cada vez mais completas

de software

- Veremos dois modelo:

­ Prototipação
­ Modelo Espiral
 Modelo Evolucionário
Prototipação (fluxo)
Projeto
 rápido
Comunicaçã
o Modelagem
projeto
rápido

Entrega e Construção
feedback de um
protótipo
 Modelo Evolucionário
Planejame
nto
­ Estimativa de
Modelo Espiral custos
­  Cronograma
­  Análise de riscos

- Representação do
Modelag
Modelo Espiral: ­ em
Análise
­
Projeto
Comunica
ção

Construç
­ ão
Empre Codificação
­ go
 Entrega ­  Testes
­
Feedback
Modelos de Processo Especializado

- Baseado em Componentes
- Orientado a Aspectos
PSP

O PSP é um processo para auto­melhorar

a capacidade de planeamento e
acompanhamento do Engenheiro do
Software. Este foi projetado com o intuito
de o ajudar a controlar, administrar e
melhorar o modo de trabalho.
Visa, basicamente um melhoramento, ao
nível pessoal, dos processos de
desenvolvimento de software.
PSP
O PSP é baseado nos seguintes princípios de qualidade e planeamento:

• Todos os Engenheiros de Software são diferentes, de modo que cada
um deverá fazer o seu planeamento, tendo como base os seus
conhecimentos e preferências.
• Para melhorar a sua qualidade e performance, o Engenheiro de
Software deve usar processos  bem definidos e bem avaliados.
• O Engenheiro de Software deve sentir­se pessoalmente
responsabilizados pela qualidade dos seus produtos, para que
produza trabalhos com elevada qualidade.
• É mais fácil previnir os erros/defeitos do que procurá­los/corrigi­los.
• A maneira correcta é sempre a mais fácil e barata de executar uma
tarefa.
PSP
• Para que um Engenheiro de Software faça um
trabalho da maneira correta, este deve planejar o
trabalho antes de se comprometer ou de começar.
• Para isso, devem utilizar um processo bem definido.
▫ Para que possam ter um conhecimento exato das suas
capacidades e performance, devem medir o tempo
que perdem em cada passo do seu trabalho, os
defeitos que introduziram ou retiraram e, não menos
importante, o tamanho dos produtos que produzem.
 PSP
- Para fazer funcionar um PSP que não
funciona, 5 atividades estruturais são
definidas:
1) Planejamento
2) Projeto de alto nível
3) Revisão de projeto de alto nível
4) Desenvolvimento
5) Autópsia
 PSP - Planejamento
- Isolamento de requisitos

- Estimativas de porte e recursos

- Defeitos estimados para o trabalho

Tudo é registrado em formulários ou

planilhas
 PSP - Planejamento

- Finalmente, as tarefas de desenvolvimento

são identificadas e um cronograma é feito
PSP - Projeto de alto nível
- Componentes do sistemas são
modelados (projeto de
componentes)
- Protótipos podem ser construídos
- Problemas são registrados e
endereçados
 PSP - Revisão de projeto
de alto nível

- Formas de verificação são

aplicadas ao projeto para revelar
erros (métodos formais e outros –
verificações sobre modelos)
- Métricas são mantidas para
resultados de trabalho e tarefas
importantes
 PSP - Desenvolvimento
- O projeto de componentes é revisado
e refinado
- Código é gerado, revisado,
compilado e testado
­  Métricas são mantidas para
resultados de trabalho e tarefas
importantes
 PSP - Autópsia

- Usando medidas e métricas coletadas é

preciso determinar a eficácia do processo
- Medidas e métricas devem guiar
mudanças para melhor eficiência do
processo
 PSP - Conclusão

- PSP enfatiza necessidade de

identificar erros precocemente (ex.:
revisão de projeto de alto nível)
- Esta avaliação deve ocorrer em
todos os artefatos gerados
- PSP é uma abordagem
disciplinada fortemente
baseada em métricas
TSP

- Aproveitando as lições aprendidas

com o PSP, mas visando equipes, o
TSP é proposto
- O objetivo geral é criar uma
equipe auto-dirigida (auto-
organização para criar software de
qualidade)
 TSP
- O objetivos específicos do TSP são:
­ As equipes precisam estabelecer metas e acompanhar seu
próprio trabalho. Podem conter de 3 a 20 engenheiros
­ Mostrar aos gerentes como treinar e motivar suas equipes
e como ajudá-las a manter um bom desempenho
­ Acelerar o aperfeiçoamento dos processos de software,
tornando o comportamento CMMI nível 5 algo esperado
TSP

• Fornecer orientação para

melhorias em organizações que já
têm um grau de maturidade
elevado
• Facilitar o ensino de habilidades
de trabalho em equipe
TSP
Princípios da Construção de
Equipes Usadas no TSP:
• Todos os membros da equipe devem estabelecer
metas comuns e definir os papéis;
• A equipe deve desenvolver uma estratégia
previamente acordada;
• Deve­se definir um processo comum para o
trabalho dos membros da equipe;
TSP
• Todos os membros da equipe devem participar
na produção do plano, e todos devem conhecer
o seu papel no plano;
• O plano definido deverá ser negociada com a
administração;
• A administração deve revêr e aceitar o plano
negociado;
• Todo o trabalho desenvolvido pelos membros
da equipe deverá estar de acordo com o plano;
TSP
• A comunicação entre os membros da equipe
deve ser frequente;
• A equipe deve formar um grupo coeso, onde os
membros devem cooperar, e comprometer­se a
alcançar o objetivo proposto;
• Os engenheiros conhecem o seu status, recebem
feedback relativamenteo ao seu trabalho e têm
capacidade de liderança que sustenta a sua
motivação.
 TSP
- Segundo a TSP, o que faz uma equipe auto-dirigida:
­ Entende suas metas e objetivos
­ Define papéis e responsabilidades para os membros
­ Monitora quantitativamente projetos
­ Identifica o processo de equipe adequado para
determinado projeto (e estratégia de implantação)
­ Define padrões
­ Avalia riscos continuamente
­ Reage aos riscos
­ Acompanha, gerência e informa a
organização sobre o andamento de projetos
TSP

- Segundo a TSP, existem 4

atividades metodológicas:
1) Lançamento do projeto
2) Projeto de alto nível
3) Implementação, integração e
testes
4) Autópsia
TSP
Elementos principais:

• Formando Equipes: Preparar a equipe para
receber o processo TSP.

• Trabalho de Equipe: Após a equipe está
preparada, a mesma começa a usar o
processo TSP.
Engenharia de Software
• O que é Engenharia de Requisitos?
Conceitos
• O que é Stakeholder?
▫ É uma pessoa ou uma organização que tem algum
impacto direto ou indireto sobre os requisitos do
sistema.
ER
• Importância da ER
ER
ER
ER
ER - Processo
ER - Processo
• Estudos de viabilidade
ER
• Etapa: Elicitação
▫ O engenheiro de requisitos precisa extrair, sugar
todas as informações possíveis dos Stakeholders e
identificar os requisitos através de pesquisas.

▫ Para etapa de identificação, levantamento e
detalhamento de requisitos, podem ser utilizadas
diversas técnicas como:
⚫ Entrevistas;
⚫ Workshop;
⚫ JAD (Join Application Design);
⚫ Brainstorming;
⚫ Entre outros...
ER
• Etapa: Elicitação
▫ A escolha da técnica depende:
⚫ Tipo e complexidade da aplicação;
⚫ Perfil da equipe de desenvolvimento;
⚫ Perfil do cliente;
⚫ Criticidade da aplicação e da tecnologia.
ER – Pirâmide de Requisitos
ER
• Etapa: Elicitação – Tipos de Requisitos
▫ Requisitos funcionais ­ RF

▫ Requisitos não­funcionais ­ RNF
ER
• Etapa: Elicitação – Base de Requisitos não­
funcionais
ER
• Etapa: Elicitação – Tipos de Requisitos
▫ Requisitos funcionais ­ RF
⚫ Exemplo: o sistema deve prover um formulário de
entrada para a entrada dos resultados dos testes
clínicos de um paciente.

▫ Requisitos não­funcionais – RNF
⚫ Exemplo: O sistema deve emitir um recibo para o
cliente, com o tempo máximo de 8 segundos após a
transação (performance).
ER
• Etapa ­ Documentação
▫ É importante registrar as informações coletadas e
identificadas na etapa de levantamento de
requisitos de forma adequada.

•  Para documentar requisitos podem ser
utilizadas:
▫ Linguagem natural e modelos formais, utilizando
UML, como por exemplo, diagrama de estado,
sequência, casos de uso e especificações de casos
de uso.
ER
• Etapa: Documentação – Documentos de
Requisitos.
▫ Componentes típicos dos documentos de
requisitos:
⚫ Informação de título e autor do documento (com a
logo da empresa);
⚫ Propósito e escopo do documento;
⚫ Identificação dos Stakeholders e aprovadores do
documento;
⚫ Overview do sistema.
ER
• Etapa: Documentação – Documentos de
Requisitos.
ER
• Etapa: Documentação – Documentos de
Requisitos.
Exemplo
ER
• Etapa ­ Validação de negociação
▫ Deve ser garantida a qualidade dos requisitos,
validando se estão corretos. Por isso é importante
negociar com o cliente o que realmente é
necessário para o produto.

▫ Para negociar e validar os requisitos é importante
ter a avaliação de um especialista, de modo que
possa ser verificado se o que foi levantado condiz
com o que foi solicitado.
ER
• Etapa ­ Gerenciamento
▫ Compreende todas as medidas que são
necessárias às exigências de estrutura para que as
outras 3 etapas da ER possa ocorrer.

▫ Gerenciar consiste em manter os dados
consistentes e com qualidade garantindo que eles
possam ser implementados. É uma etapa
ortogonal as outras 3 visto que trabalha
garantindo a execução destas.
DÚVIDAS?
Exercícios – Quiz!!!

Descreva os estágios do ciclo de vida do
desenvolvimento do sistema.
Exercícios – Quiz!!!

Descreva as principais abordagens do
desenvolvimento de sistema.
Exercícios – Quiz!!!

Quais são os 3 modelos prescritivos e
escrevas sobre cada um deles?
Exercícios – Quiz!!!

Quais são a 4 atividades da engenharia de
requisitos? Escreva sobre cada uma
dessas atividades.
Exercícios – Quiz!!!

Qual a diferença entre PSP e TSP?
DESEMPATE
Exercícios – Quiz!!!

Quais atividades pertence a PSP?
Escreva sobre cada uma delas..