ENGENHARIA DE SOFTWARE - SLIDE 1

O que é engenharia de software?

Estuda a aplicação de abordagens sistemáticas, disciplinares e quantificadas para
DESENVOLVER, TESTAR, OPERAR E MANTER software.

Áreas de conhecimento
São 15, onde 3 delas são voltadas para suporte “Core”

Requisitos de Software
Requisitos: O que um sistema tem que fazer
Engenharia de requisitos: Atividades onde os sistemas são documentados,
validados especificados

Funcionais: O que o sistema deve fazer

Ex: Quando uma nota for lançada no SUAP os alunos devem receber um email.

Não-funcionais: Como um sistema deve operar e a qualidade que ele deve oferecer
Ex: O e-mail acima deve chegar em até um minuto

Projeto de Software
Descreve como um sistema é organizado em componentes e as interfaces que
esses componentes devem usar para se comunicarem.

Interfaces providas: aqueles serviços que uma unidade de código torna público,
para uso pelo resto do sistema.
Interfaces requeridas: aquelas interfaces das quais uma unidade de código
depende para funcionar.

Construção do software
Codificação do sistema
○ Algoritmos e estruturas de dados
○ Reúso, bibliotecas e frameworks
○ Tratamento de exceções
○ Padrões de nome, layout e documentação de código
○ Ferramentas
Teste de Software
Verifica se o sistema faz o que é especificado, antes era utilizado apenas no final do projeto,
porém agora é utilizado durante todas as fases.

Tipos de Teste
● Testes de Unidade → quando se testa uma pequena unidade do código;
● Testes de Integração → quando se testa uma unidade de maior;
● Testes de Performance → carga de processamento, para verificar o
desempenho;
● Testes de Usabilidade → quando o objetivo é verificar a usabilidade da
interface do sistema.

Testes de Verificação e Validação

● Verificação
○ Exemplo: teste de um método, para verificar se ele retorna o
resultado especificado
● Validação:
○ Exemplo: mostrando para o cliente os resultados e funcionalidades
do sistema

Teste de terminologia
● Visto quando essa parte do código é executada.
TDD
● Incentiva a escrita de testes
● Força DEV a pensar primeiro na interface do código que vão
implementar

Manutenção de software
Não se trata apenas de correção de bug e pode chegar a 90% dos custos do projeto.
É dividido em 4 partes:
○ Corretiva: correção de bugs reportados
○ Preventiva: correção de bugs latentes
○ Adaptativa: migrar um sistema
○ Perfectiva: melhorias no código fonte ou na documentação

Gerenciamento de configuração
Garantir que as mudanças realizadas em um sistema sejam devidamente identificadas,
rastreadas e passíveis de recuperação. (como, git)
Gerência de Projetos
Desenvolvimento de software demanda o uso de práticas e atividades de gerenciamento de
projetos
○ Negociação de contratos (com clientes): prazos, valores, cronogramas
○ Gerência de recursos humanos (contratação, treinamento etc)
○ Gerenciamento de riscos (exemplo: turnover)
○ Acompanhamento da concorrência, marketing etc
○ Análise de viabilidade

Stakeholders
Designa todas as "partes interessadas"
● São aqueles que afetam ou que são afetados pelo projeto
● desenvolvedores, clientes, usuários, gerentes, empresas subcontratadas etc.

Processos de desenvolvimento de software

Quais atividades devem ser feitas
Cascata
● Inspirado em processos usados em engenharias tradicionais
● Proposto na década de 70 e muito comum até a década de 90
● Parte do sucesso pode ser explicada pela sua "padronização"
Ágil
● Lançado após um "encontro" de 17 engenheiros de software em Utah
● Uma crítica a "paradigmas" sequenciais e pesados de desenvolvimento
● Mais ágil, incremental, iterativo etc

Modelagem de software
Representação mais alto nível, do que o código fonte
● Criar um modelo de um software antes de sua implementação
○ para explicar o "design"
○ para documentar o projeto
○ para facilitar compreensão, manutenção e evolução futuras etc
○ para gerar código automaticamente

● UML = Linguagem (gráfica) para modelagem de software baseada em diagramas

Prática Profissional
● Diversos pontos
○ Ética
○ Certificações
○ Regulamentação da Profissão
○ Cursos de graduação
○ Currículo de Referência
Aspectos Econômicos
● Retorno de investimento
● Monetização de startups
● Licença para o meu software

Tipos ABC de sistemas

Segundo essa classificação, existem três tipos de sistemas de software:
○ Sistemas C (Casuais)
● Não existe pressão para terem níveis altos de qualidade
● Podem ter bugs;
● Desenvolvidos por 1-2 engenheiros
● Sistemas pequenos
● Tipo mais comum de sistema
○ Sistemas B (Business)
● Sistemas críticos para uma organização; geram lucro etc
● São os sistemas que vão se beneficiar do que veremos neste curso
● Risco: não usarem técnicas de ES
○ Sistemas A (Acute)
● Sistemas que não podem dar errado pelos custos
● Exemplos: sistemas de transporte, médicos etc
● Requerem certificações
ENGENHARIA DE SOFTWARE - SLIDE 2
Ciclo do processo
● concebido
● desenvolvido
● entra em operação
● sofrer manutenção
● retiradoh

Essência da Prática
● COMPREENDA O PROBLEMA
• Quem tem interesse na solução?
● PLANEJE A SOLUÇÃO
• Problemas similares foram resolvidos anteriormente?
● EXECUTE O PLANO
• A solução se adequa ao plano?
● EXAMINE O RESULTADO
• É possível testar cada parte da solução?

Fases Genéricas do Desenvolvimento

DEFINIÇÃO:
• ANÁLISE DO SISTEMA
• Atribuir o papel de cada elemento
• Atribuir o papel do software
• PLANEJAMENTO DO PROJETO
• Análise de riscos
• Alocação de recursos
• Estimativa de custos
• Tarefas e programação do trabalho
• ANÁLISE DE REQUISITOS
• Detalhar as funcionalidades do sistema

DESENVOLVIMENTO:
• PROJETO DE SOFTWARE
• levar os requisitos para uma representação das partes que compõe o
software e das estruturas de dados
• CODIFICAÇÃO
• Programação numa linguagem
• REALIZAÇÃO DE TESTES
• Identificar os erros e causas
MANUTENÇÃO:
• Mudanças realizadas no software após a sua implementação.
CORRETIVA • corrigir defeitos
ADAPTATIVA • acomodar mudanças no ambiente externo
PREVENTIVA • Aprimoramento além dos requisitos já levantados
PERFECTIVA • Software seja mais facilmente corrigido, adaptado ou melhorado.

O processo de software
Um conjunto estruturado de atividades, ações e tarefas necessários para o
desenvolvimento de um sistema de software, focado em algumas atividades.

Modelos prescritivos de processo de software

O modelo cascata
• Fases separadas e distintas de especificação e desenvolvimento
Engenharia de software baseada em componentes
• Componentes existentes.
Desenvolvimento iterativo
• Várias etapas
Existem muitas variantes destes modelos
• Ex: reutilização de um processo semelhante ao cascata é usada e refinada durante
os vários estágios para um projeto implementável.

VANTAGENS
• Modelo de fácil entendimento;
• Útil para adequações em um Sistema existente.
DESVANTAGENS
• Projetos reais raramente seguem fluxo sequencial;
• É difícil para o cliente estabelecer todas as necessidades;

Engenharia de software baseada em componentes

● Reuso sistemático onde sistemas são integrados a partir de componentes existentes
● Requisitos de sistema SEMPRE evoluem no curso de um projeto
● Duas abordagens
• Entrega incremental: Cada incremento fornece parte da funcionalidade
• Desenvolvimento espiral: O processo é representado como uma espiral ao invés de
uma seqüência de atividades com realimentação
Especificação de software
Definir quais serviços são necessários e identificar as restrições de operação e de
desenvolvimento do sistema
Processo de engenharia de requisitos
• Estudo de viabilidade
• Realizado antes do projeto ser iniciado
• Elicitação e análise de requisitos
• Especificação de requisitos
• Validação de requisitos

Projeto e implementação de software

Conversão da especificação em um sistema de software
Projeto de software
• Estrutura e que atenda à especificação
Implementação
• Transformar em programa executável

Métodos estruturados
Abordagens sistemáticas
Documentado como um conjunto de modelos gráficos

Programação e depuração
DEVs realizam alguns testes para descobrir defeitos no programa e removem esses
defeitos no processo de depuração

Validação de software
Verificação e validação: Servem para mostrar que um sistema está conivente ao que foi
pedido pelo cliente.

Tipos de teste
Teste de componente ou unidade
• Os componentes individuais são testados independentemente
• Funções ou classes de objetos
Teste de sistema
• Teste de sistema como um todo.
Teste de aceitação
• Teste com dados do cliente.
Evolução de software
O software é flexível e pode mudar
Processos antigos separavam explicitamente desenvolvimento de evolução
• Processos e métodos iterativos
Evolução pode se dever a diversas razões
• Correções
• Mudanças de requisitos
• Melhoria de funcionalidades pré-existentes
ENGENHARIA DE SOFTWARE - SLIDE 3
Requisitos de Software
Engenharia de requisitos
Estabelece os sistemas que o cliente deseja e as restrições às quais o sistema
funcionará.

Requisito:
● descrição de um serviço
● restrição de um sistema

Tipos de requisitos
● Requisitos de usuário
○ Escritos para os clientes
● Requisitos de sistema
○ Um documento com descrições detalhadas das funções, serviços e
restrições operacionais do sistema.

Requisitos funcionais
● Serviços que o sistema deve fornecer
● Como o sistema deve reagir a entradas específicas

Requisitos não-funcionais ou de qualidade

● Restrições sobre serviços ou funções oferecidos pelo sistema tais como restrições
de tempo de resposta.

LIBSYS
Biblioteca que fornece uma interface única para uma série de banco de dados de artigos
em bibliotecas diferentes
● Permite pesquisar, baixar e imprimir esses artigos.

Imprecisão de requisitos
Problemas surgem quando os requisitos não são precisamente definidos
● Telas apropriadas
○ Intenção do usuário – tela de propósito especial para cada tipo diferente de
documento
○ Interpretação do desenvolvedor – tela de texto que mostra o conteúdo do
documento
Requisitos completos e consistentes
Completude
● Descrições de todos os recursos requeridos
Consistência
● Não deve haver conflitos ou contradições nas descrições

Metas e requisitos
● Requisitos imprecisos podem ser difíceis de verificar
● Uma intenção geral do usuário, tal como facilidade de uso
● Uma declaração usando alguma medida que pode ser objetivamente testada

Interação de requisitos
Conflitos entre os diferentes requisitos não-funcionais são comuns em sistemas complexos

Requisitos de usuário
Requisitos funcionais devem ser definidos usando uma linguagem simples, tabelas e
diagramas para que o usuário possa compreender.

Diretrizes para escrever requisitos

Usar a linguagem de uma forma consistente
● deve para requisitos obrigatórios
● deveria para requisitos desejáveis
Realçar o texto para identificar as partes principais do requisito

Requisitos de sistema
Podem ser definidos ou ilustrados usando notações gráficas

Requisitos e Projeto
Requisitos devem definir o que o sistema deve fazer e o projeto deve descrever como ele
faz isto
● Requisitos => problema
● Projeto => solução
● São inseparáveis

O documento de requisitos
Declaração oficial do que é requisitado pelos desenvolvedores do sistema
Usuários de um documento do sistema
● Clientes: verifica se atende aos requisitos e especificam as mudanças
● Gerentes: usa o documento para planejar
● Engenheiros: usa os requisitos para entender o que será feito
● Engenheiros de teste: fazem testes de validação
● Engenheiros de manutenção: compreendem o sistema e relacionam suas partes
ENGENHARIA DE SOFTWARE - SLIDE 4
Gerenciamento de Projetos Gerenciamento de Riscos

Gerenciamento de projetos são uma das habilidades mais valorizadas pelas organizações

Projeto: Um esforço temporário com a finalidade de criar um produto/serviço/resultado

único.
Dimensões de um projeto: Custo, Tempo, Escopo, Qualidade, Risco e Satisfação do Cliente

Grupos de Processos para Gerenciamento

● Iniciação
● Planejamento
● Execução
● Monitoramento
● Finalização

Gerenciamento de projetos de software

Atividades envolvidas em assegurar que o software será entregue no prazo e com os
requisitos corretos.

Distinções de gerenciamento de software

● O produto é intangível
● O produto é flexível
● O processo de desenvolvimento de software não é padronizado
● Muitos projetos de software são projetos ‘únicos’

Gerenciamento de riscos
Está relacionado à identificação de riscos e à elaboração de planos para minimizar esses
efeitos em um projeto
● Identificação de riscos
● Análise de riscos
● Planejamento de riscos
● Elabora planos para evitar ou minimizar os efeitos do riscos
● Monitora os riscos ao longo do projeto