Slides da disciplina Engenharia de Software

1. Introdução à Engenharia de
Software
Leinylson Fontinele Pereira
Engenharia de Software

3. Roteiro
• Introdução

4. Introdução
Conceitos de Software
“Software é abstrato, intangível , não é limitado por
materiais, ou controlado por leis físicas ou por processos
de manufatura”
(Sommerville, 2003)
“Software de computador é o produto que profissionais de
software constroem e, depois, mantêm ao longo do
tempo”
(PRESSMAN, 2011)
• Software não é apenas o programa executável...

5. Primeiros Passos
• Processo
– Conjunto de passos e instruções para executar
determinadas atividades
• Desenvolvimento
– Criação ou manutenção de um produto ou serviço
• Software
– Conjunto de código-fonte e documentação

6. Introdução
• Tipos de Software
– Software básico
– Software de tempo real
– Software comercial (gerencial, operacional)
– Software científico ou de engenharia
– Software embutido ou embarcado
– Software para inteligência artificial
– Jogos...

7. 7
Categorias de Software
• Software Básico: uma coleção de programas escritos para servir a outros
programas. Ex: compiladores, editores, sistemas operacionais, drivers etc.
• Software de Tempo Real: programas que monitoram, analisam e
controlam eventos do mundo real. Um sistema de tempo real precisa
responder dentro de restrições de tempo especificadas, requerendo um bom
tempo de resposta (diferente de sistemas interativos ou on-line). Ex: software
de controle de metrô, de usina nuclear, de satélites etc.
• Software para o Negócio: a maior área de desenvolvimento de software.
Sistemas de Informação: controle escolar, controle de estoque, sistema de
biblioteca, comércio eletrônico, pontos de venda etc.
• Software Aplicativo: softwares de escritório, para computadores pessoais.
Ex: editores de texto, planilhas eletrônicas, software de acesso a e-mails etc.

8. 8
Categorias de Software
• Software de Inteligência Artificial: fazem uso de algoritmos não numéricos
para a resolução de problemas complexos, que não podem ser tratados de forma
convencional. Softwares baseados em heurísticas e em conhecimento. Ex: Redes
Neurais (reconhecimento de voz, de imagem), Sistemas Nebulosos (jogos inteligentes,
gerenciamento de informações imprecisas) etc.
• Software Embarcado (ou embutido): normalmente residem em memória
não volátil (ROM) e são usados para controle de produtos e sistemas para o mercado
consumidor industrial. Ex: programas em forno de microondas, celulares,
computadores de bordo em automóveis etc.
• Software para Engenharia e Científicos: software para apoio a cálculos
matemáticos, físicos e para apoio a atividades de engenharia. Ex: simulação de
sistemas, ferramentas CASE (computer-aided software engineering), ferramentas CAD
(computer-aided design) etc.

9. Introdução
Com a evolução do software começaram a surgir vários problemas relacionados
ao seu processo de desenvolvimento, dando início a “Crise do Software”

10. 10
1ª Era
❑ Programação de computadores era
vista como uma arte "secundária"
para a qual havia poucos métodos
sistemáticos;
❑ Evolução e aperfeiçoamento do
hardware eram colocados em
primeiro plano;
❑ Softwares eram projetados sob
medida nas organizações.

11. 11
2ª Era
❑ Multi-programação e Sistemas Multi-
usuários;
❑ Sistemas Interativos Através de Terminais
de Acesso;
❑ Armazenagem On-line Leva à 1ª Geração
de Sistemas de Gerenciamento de Bancos
de Dados;
❑ Altos Custos e Esforço em Manutenção:
Primeira "Crise do Software”.

12. A Crise do software

13. A Crise do software
“Any fool can write code that a computer can
understand. Good programers write code that
humans can understand”
Martin Fowler

14. Causas da Crise do software
❑ Cumprimento dos prazos;
❑ Custos elevados;
❑ Dificuldades na manutenção dos
sistemas;
❑ Baixa qualidade;
❑ Clientes insatisfeitos;
❑ Construção informal de software.

15. 15
3ª Era
❑ Advento e generalizado uso de
microcomputadores, computadores
pessoais e poderosas estações de
trabalho (workstations);
❑ Sistemas distribuídos x Sistemas
centralizados;
❑ Redes locais: sistemas departamentais e
em pequenas e médias empresas;
❑ Crescem as “software houses”.

16. 16
4ª Era
❑ Problemas genéricos:
❑ Nossa capacidade de construir
programas não acompanha o ritmo da
demanda de novos programas;
❑ Nossa capacidade de manter
programas existentes é ameaçada por
projetos ruins e recursos inadequados.
❑ Mudança de paradigma em função da
tecnologia de orientação a objetos.

17. 17
5ª Era (do ano 2000 em diante)
❑ Desenvolvimento geograficamente
distribuído;
❑ Componentes de software;
❑ Fortalecimento dos especialistas do
domínio;
❑ Desenvolvimento para a Web.

18. 18
Acontecimentos Marcantes:
• 1969 - 1971: boas práticas de programação - surge a
linguagem Pascal.
• 1972 - 1973: programação estruturada, ciclo de vida.
• 1974 - 1975: procedimentos para teste sistemático e
prova formal de programas;
• 1976-1977: focos: requisitos, especificação e projeto;
paradigma de desenvolvimento estruturado.
• 1978 - 1980: era CASE.
• 1990 – 2004: orientação a objetos, desenvolvimento
para Web, desenvolvimento baseado em componentes.

19. 19
Componentes do Software:
• Componentes executáveis em máquina, como:
instruções de programas, estruturas de dados
(bancos de dados), interfaces.
• Componentes não executáveis, como:
documentação de projeto e análise, manual de
usuário e de produção.
– A reutilização é uma característica importante de um
componente de software de alta qualidade!!!

20. Engenharia de Software
“Aplicação sistemática, disciplinada e com abordagem
quantitativa para desenvolvimento, operação e manutenção
de software”
(IEEE)
“Ramo da engenharia cujo foco é o desenvolvimento dentro de
custos adequados de sistemas de software de qualidade”
(SOMMERVILLE, 2003)
“Conjunto de processos, métodos, técnicas e ferramentas que
ajudam a produzir software com maior qualidade e com
menor custo”
(PRESSMAN, 2011)

21. 21
Papéis no Desenvolvimento de Software
• Analista de Sistemas: responsável pela elicitação de
requisitos e especificação do “que” o software fará.
• Projetista: responsável pela especificação de “como” o
software irá implementar os requisitos definidos na
análise.
• Programador: responsável pela construção dos módulos e
programas, especificados no projeto, em uma linguagem
de programação.
• Gerente de Projeto: responsável por definir o processo e
os planos de desenvolvimento. Estabelece cronograma,
estima prazo, custo e recursos. Acompanha o
desenvolvimento.

22. 22
Papéis no Desenvolvimento de Software
• Arquiteto: responsável pela elaboração da estrutura
modular do software. Está surgindo no mercado.
Arquitetos em tecnologias específicas, como J2EE.
• Desenvolvedor: atua em todas as etapas do
desenvolvimento. Normalmente, o mercado exige
especialidade em tecnologias e linguagens específicas.
• Usuário: pessoas, organizações ou departamentos que
utilizam o sistema. Podem ser usuários diretos, que de
fato operam o software, ou indiretos, que enviam dados
ou recebem resultados do software.
• Cliente: companhia, organização ou pessoa que contrata e
paga o sistema de software a ser desenvolvido.

23. Conceitos no Desenvolv. de Software
• O que é?
– Papel
– Disciplina
– Artefato

24. Papéis
• Administrador de Rede
• Analista de Qualidade
• Analista de Requisitos
• Analista de Negócios
• Analista de Testes
• Arquiteto de Software
• Consultor
• Desenvolvedor
• Gerente de Configuração
• Gerente de Projetos
• Testador
• ...
Cada papel tem sua importância,
disciplina, artefatos associados e
atividades pré-definidas

25. Disciplina
• Análise e projeto de software
• Desenvolvimento de software
• Gerência de Configuração
• Gerência de Requisitos
• Gerência de Projetos
• Implantação
• Modelagem de Negócios
• Teste de Software
Categorização de processos que
são, teoricamente, independente
dos demais

26. Artefato
• Ator
• Burndown chart
• Caso de Teste
• Caso de Uso
• Código fonte
• E-mail
• Glossário
• Plano de iteração
• Requisito
• Exemplo:
• Coleção de Requisitos
• Caso de Uso
• Regra de Negócio
Documento ou elemento
pertencente a este, que deve ser
criado ou alterado

27. Artefato

28. 28
Outros conceitos...
• Método: procedimento formal para a produção de um
resultado. Um método define as tarefas que serão realizadas e
de que forma as mesmas deverão ser executadas. Define que
tecnologias e linguagens deverão ser adotadas e os produtos
que serão produzidos.
– Ex: metodologia de Análise Essencial, OMT (Object Modeling
Technique), RUP (Rational Unified Process) etc.
• Ferramenta: instrumento ou sistema automatizado (software)
para suportar a realização de uma tarefa.
– Ex: DFD (diagrama de fluxo de dados), Rational Rose (ferramenta
CASE)
• Paradigma: uma maneira, estilo ou filosofia para a construção
de software, envolvendo um conjunto de princípios. Ex:
paradigma estruturado e paradigma de orientação a objetos
(OO).
• Domínio: família de aplicações com requisitos similares.
– Ex: escolar, agropecuário, legislativo etc.

29. Processo de Software
• Engenharia de software propõe o uso de:
– Processos,
– Modelagem,
– Gestão da qualidade

30. Processo de Software
• Conjunto estruturado de atividades, práticas,
artefatos e ferramentas necessários para o
desenvolvimento de um sistema de software
– Especificação;
– Desenvolvimento;
– Validação;
– Evolução.
• Exemplos: Processo Unificado (RUP), Programação
Extrema, UML Components

31. Processo de Software

32. Processo de Software
• Estudo de viabilidade
– Econômica – relação custo/benefício;
– Técnica – tecnologia e capacitação;
– Jurídica – aspectos legais
• Levantamento de Análise de Requisitos
– Entrevista
– Observação
– Reuniões

33. Processo de Software
• Especificação de requisitos
– Documento contendo os requisitos do usuário e do
sistema
• Funcionais e não funcionais
• Validação de requisitos
– Avaliação dos requisitos (consistência e integridade)

34. Processo de Software
• Alguns elementos de um processo:
– Modelos de sistema:
• Modelos gráficos e notações empregadas;
• Restrições aplicadas aos modelos de sistema;
– Recomendações de boas práticas de projeto;
– Atividades de execução ordenada;
– Às vezes também prescrevem ferramentas.
• Um processo adere a um ou mais modelos de processo

35. Modelo de processo de software
• Representação simplificada de um processo de
software, apresentado sob uma perspectiva específica
• Inclui algumas atividades e sua organização
• Propósitos:
– Melhor entendimento do sistema que está sendo construído
– Especificar a estrutura e comportamento
– Guia a construção do sistema
– Documenta as decisões tomadas

36. Modelo de processo de software
• Objetivo
– Auxiliar ao gerente: controlar o processo de
desenvolvimento de sistemas de software.
– Auxiliar ao desenvolvedor: obter a base para
produzir, de maneira eficiente, software que
satisfaça os requisitos pré-estabelecidos.

37. Modelo de processo de software
• Modelos gerais de processo
– Modelo Cascata
– Prototipação
– Modelo Incremental
– Modelo Espiral
– Modelo RAD
– Modelo RUP
– Modelo Ágil
– .... Vários outros
• Representações de modelos de processo:
– Modelo de workflow – seqüência de atividades;
– Modelo de fluxo de dados – fluxo de informações;
– Modelo de papel/ação – quem faz o quê.

38. Modelo X Processo
• Modelo de software:
– Documento teórico, conjunto de possíveis ações
• Processo de software:
– Determina as ações práticas a serem realizadas
pela equipe como: prazos definidos e métricas
para de avaliação

39. Gestão da Qualidade
• Diferentes visões de qualidade:
– Visão transcedental: algo que se reconhece, mas não
consegue definir;
– Visão do usuário: atendimento das metas específicas
de um usuário final;
– Visão do fabricante: atendimento das especificação
original do produto;

40. Gestão da Qualidade
– Visão do produto: relacionada às características do
produto (funções e recursos)
– Visão baseada em valor: mede o quanto um cliente
estaria disposto a pagar
• Gestão de qualidade:
– Estabelecer um conjunto de tarefas de desenvolvimento,
– Controle de qualidade,
– Métricas.

41. Gestão da Qualidade

42. Gestão da Qualidade

43. Gestão da Qualidade

44. Suporte
Velocidade
Qualidade no atendimento
Aparência
Prazo de entrega
Correção
Facilidade de uso
Escalabilidade
Disponibilidade
Preço de manutenção
Preço de aquisição
Confiabilidade
Parte Visível
Parte InvisívelPráticas de codificação
Complexidade
Redundância
Eficiência
Facilidade de integração
Normalização da base de dados
Reusabilidade
Testabilidade
Flexibilidade
Manutenibilidade
Linguagem de codificação
Documentação do código

45. Ciclo de Vida do Software
• Uma estratégia de desenvolvimento que englobe
processos, métodos e ferramentas, e as fases de
desenvolvimento...
– Modelo em Cascata - ciclo clássico
– Paradigma Evolucionário
• Prototipação
• Incremental
• Espiral
• Métodos Ágeis
– Modelos Formais
– Técnicas de 4ª Geração
– Orientado a Reuso

46. Desafios da Engenharia de Software
• Heterogeneidade
– Sistemas de software devem ser capaz de lidar com diferentes
plataformas de hardware e ambientes de execução;
• Entrega
– O sistema deve ser entregue ao cliente no menor tempo
possível, com o menor custo possível;
• Confiança
– O usuário deve poder justificadamente depositar sua
confiança no sistema
• Escala
– O sistema deve funcionar adequadamente mesmo quando um
grande número de usuários o está usando

47. Modelo Cascata
• Método sistemático e sequencial
• O resultado de uma fase se constitui na entrada
da outra
• Cada fase é estruturada como um conjunto de
atividades que podem ser executadas por
pessoas diferentes

48. Modelo Cascata

49. Modelo Cascata

50. Modelo Cascata
• Análise de Requisitos
– Envolve a coleta de requisitos (nível de usuário) de
forma intensa
– Compreensão do domínio, função, desempenho e
interface necessários
– Os requisitos são documentados e revistos com o
cliente

51. Modelo Cascata
• Projeto
– Requisitos do software -> Representações
– Avaliação de qualidade
– Anterior a codificação
• Concentram em 4 atributos
– Estrutura de dados
– Arquitetura
– Detalhes de procedimentos
– Caracterização de interface

52. Modelo Cascata
• Codificação
– Implementação
– Tradução do projeto em código computacional
– Instruções executáveis pelo computador
– Linguagens de programação ( alto ou baixo nível )
– Quanto mais coeso o projeto e os requisitos mais
rápida é a codificação

53. Modelo Cascata
• Testes
– Concentra os aspectos lógicos internos
– Garante o teste de funcionalidade (código)
– Nos aspectos funcionais externos
– Descobrir erros (teste de funcionalidade)
– Entrada x produz saída y
– Garantir a confiabilidade

54. Modelo Cascata
• Manutenção
– Alterações depois de entrega efetuada
– Mudanças ocorrem por:
• Erros
• Adaptação para acomodação de mudanças em
processo organizacional
• Exigência do cliente para acréscimo funcional
• Em decorrência do desempenho

55. Modelo Cascata
• Problemas:
– Projetos raramente seguem o fluxo do modelo
– Dificuldade de estabelecer os requisitos no início
do projeto
– O cliente deve ter paciência
• Uma versão do produto só ficará disponível numa etapa
avançada de desenvolvimento

56. Modelo Cascata
• Mesmo com as fragilidades, ele é
significativamente melhor que uma
abordagem aleatória de desenvolvimento.
• Embora a entrega de uma versão “beta” seja
tardia o resultado é satisfatório porem
demorado.

57. Atividade 1
• Escreva um roteiro dos processos envolvidos
na reserva de um livro em um sistema de
controle para biblioteca da instituição.