O documento descreve um contrato pedagógico para a disciplina de Engenharia de Software, definindo horários, regras sobre equipamentos eletrônicos, avaliações, webclasses, sugestões, metodologia de avaliação e ementa da disciplina.

1. Engenharia de Software
Professor Ítalo Quirino Brilhante

2. Contrato Pedagógico
•Horário
Início: 19:15h
Intervalo: 20:30h às 20:45h
Final: 22:00h
•Controle de Faltas
Máximo Permitido: 25% - (16 faltas)
•Chamada:
1 chamada por dia

3. Contrato Pedagógico
•Celular
Colocar no modo Silencioso
Pedir licença aos colegas
Atender fora da sala de aula (não próximo a porta)
•Limites
Maturidade
Respeito

4. Equipamentos Eletrônicos

5. Contrato Pedagógico
•Equipamentos Eletrônicos
É permitido o uso de notebooks e netbooks
durante as aulas;
Não será permitido brincar com equipamentos
eletrônicos durante a aula.

6. Contrato Pedagógico
•Avaliações
Não serão permitidos o uso de computadores,
calculadoras, telefones celulares, smartphones e
outros dispositivos eletrônicos.

7. Contrato Pedagógico
•Webclasses
 Todos os documentos da disciplina estarão
disponíveis no portal;
 Textos e informações adicionais;
 Listas de Exercícios;
 Datas importantes;
 Comunicados.

8. Contrato Pedagógico
•Sugestões e Opiniões
Todas as sugestões e críticas poderão ser enviadas
por e-mail.
italouniandrade@gmail.com

9. Contrato Pedagógico
•Avaliações
Metodologia de avaliação progressiva.
Avaliações sem consulta
Avaliações Individuais
Prova de Reconstrução no final da Etapa com todo
o conteúdo.

10. Contrato Pedagógico
•Trabalhos:
Listas de Exercícios;
Pesquisas (ABNT).

11. Contrato Pedagógico
•Datas e Prazos
Todas as datas de prova e de entrega de trabalhos
serão negociados. Uma vez definidas somente serão
alteradas por motivo de força maior.

12. Metodologia de Avaliação
•Para aprovação
Lançamento das notas de 0 a 10
Nota 1º = Prova 1º (Valor7,00) + trabalhos e Atividades (Valor 3,00)
Nota 2º = Prova 2º (Valor 7,00) + trabalhos e Atividades (Valor 3,00)
Média Final = (Nota 1º + Nota 2º) /2
Média Final >= 7,00 -- aprovado sem exame
Média Final < 7,00 e >= 4,00 -- exame final
Média Final < 4,00 -- reprovado
Exame Final >= (10 – Média Final) -- aprovado
Exame Final < (10 – Média Final) -- reprovado
Frequência >= 75% das aulas dadas -- aprovado (condição analisada em
conjunto com a média final)
Frequência < 75% das aulas dadas -- reprovado (independente da média
final obtida)

13. Ementa da Disciplina
Conceitos básicos de Engenharia de Software
Sistemas Sociotécnicos
Processo de Software
Requisitos de Software
Processos de Engenharia de Requisitos
Modelos de Sistema
Especificação
Projetos de Arquitetura
Arquiteturas de Aplicações
Desenvolvimento Rápido de Software
Reuso de Software
Engenharia de Software Baseada em Componentes
Evolução de Software
Gerenciamento de Configuração
Engenharia de Software Orientada a Serviços
Desenvolvimento de Software Orientado a Aspectos

14. Referência Bibliográfica
IAN, Sommerville. Engenharia de Software. Tradução: Ivan Bosnic e Kalinka
G. de O. Gonçalves. São Paulo: Pearson Addison Wesley, 2011. ISBN 978-85-
7936-108-1.
PRESSMAN, Roger S. Engenharia de software. Tradução: José Carlos
Barbosa dos Santos. São Paulo: Makron Books, 1995. 1056 p. ISBN 85-346-
0237-9.
REZENDE, Denis Alcides. Engenharia de software: para excelência em
sistemas empresariais. Curitiba: Apta, 1997. 141 p.

15. Engenharia de Software
É um ramo da engenharia cujo foco é o
desenvolvimento dentro de custos adequados de
sistemas de software de alta qualidade.
SOMMERVILLE.

16. Termo utilizado nos anos 1970, quando a
engenharia de software era praticamente
inexistente.
Expressava as dificuldades do desenvolvimento
de software frente ao rápido crescimento da
demanda por software, da complexidade dos
problemas a serem resolvidos e da inexistência
de técnicas estabelecidas para o
desenvolvimento de sistemas que funcionassem.
adequadamente ou pudessem ser validados.
Crise de Software

17. Problemas:
• Software inadequado;
• Cronogramas e custos imprecisos;
• Inexistência de dados históricos sobre o processo
de desenvolvimento.
Crise de Software

18. Problemas:
• Comunicação deficiente - insatisfação de usuários;
• Carência de conceitos quantitativos sobre
confiabilidade, qualidade e reusabilidade;
• Software existente e de difícil manutenção.
Crise de Software

19. Solução:
• Combinar métodos para as fases de
desenvolvimento;
• Ferramentas para automatizar esses métodos;
• Técnicas para assegurar qualidade.
Crise de Software

20. • Programas de computador e os dados de
documentação e configuração associados.
• Entidade abstrata.
Software

21. Conceitos mais amplos:
• Comportamento exibido por essa sequência de
instruções quando executada em um computador;
• Estrutura de dados para manipular informação;
Software

22. • Genéricos;
• Sob encomenda.
Tipos de Software

23. • Saber o que o software deve fazer;
• Ferramentas;
• Linguagem;
• Tempo e custos elevados de desenvolvimento;
• Prever falhas (antes de entregar);
• Tratar manutenção e versões.
Dificuldades para desenvolver
software

25. • Métodos e Técnicas: detalhes de como fazer
• Metodologias: como aplicar
• Ferramentas: automatizam os métodos, dão apoio à utilização.
CASE => (Computer-Aided Engineering):
Ferramentas integradas para desenvolver software.
Engenharia de Software - ES

27. • Formalidade;
• Abstração;
• Decomposição;
• Generalização;
• Flexibilização.
Princípios da ES

28. • Formalidade: Ter programas mais confiáveis com baixo
custo e bom desempenho e o software deve ser
desenvolvido de acordo com passos definitivos com
precisão e seguidos de maneira efetiva.
• Abstração: É o processo de identificação de um
determinado fenômeno da realidade considerando
apenas os aspectos mais relevantes.
Princípios da ES

29. • Decomposição: É o processo de dividir o problema para
que cada subproblema seja resolvido de uma maneira
específica. Usado para controlar a complexidade do
software.
• Generalização: Reutilizar as soluções dos problemas
• Flexibilização: Alterar o software sem que ele tenha um
problema de execução.
Princípios da ES

30. • 60% dos custos são de desenvolvimento;
• 40% dos custos são de teste.
• Para software sob encomenda, os custos de evolução
frequentemente excedem os custos de desenvolvimento.
Custos da ES

31. Abordagens estruturadas para desenvolvimento de SW que
incluem modelos de sistemas, notações, regras,
recomendações de projetos e guias de processo.
Métodos da ES

32. • Sistemas de software que têm a intenção de fornecer apoio
automatizado para atividades de processo de software.
• É uma classificação que abrange todas as ferramentas baseadas em
computadores que auxiliam atividades de engenharia de software.
• Exemplo:
• CaseStudio 2
• Dr. Case
• ErWin
• Visio
• Together, etc.
Ferramentas CASE (Computer Aided Software
Engineering )

33. • São elaborados vários diagramas que em conjunto constituem
praticamente uma “planta” do sistema a ser desenvolvido.
 Com o advento da Orientação a Objetos, surgiu também uma
nova maneira de documentar sistemas, que é a UML ( Unified
Modeling Language ),
O que é CASE (Computer Aided
Software Engineering )?

34. • Funcionalidade;
• Desempenho;
• Fácil de manter;
• Confiável;
• Usabilidade.
Atributos de um bom software

35. Estar à altura do aumento de diversidade, demandas para
redução do tempo de entrega e desenvolvimento de
software digno de confiança.
Desafios da ES

36. É um conjunto de atividades cujo objetivo é o
desenvolvimento ou evolução do software.
Atividades:
- Especificação;
- Desenho e Implementação;
- Validação;
- Evolução.
Processo de Software

37. Atividades de Processo de Software
•Especificação:
Decidir para que funcionará
o software e suas restrições
de operação.
•Desenho e Implementação
Produção do Software a
partir das definições.
•Validação: (V & V)
Testar se está de acordo
com o que o cliente necessita
para ser validado.
•Evolução:
O software tem que ser
atualizado para sempre
garantir as necessidades do
cliente.
27/07/13

38. É uma representação de um processo de software,
apresentada sobre uma perspectiva específica. Ou seja, é
uma estratégia para o desenvolvimento do software.
 Define a ordem de execução das atividades durante
as fases de engenharia de software.
Modelo de Processo de Software

39. Modelo de Processo de
Software
O modelo de ciclo de vida é a primeira escolha a
ser feita no processo de software. A partir desta
escolha definir-se-á desde a maneira mais
adequada de obter as necessidades do cliente,
até quando e como o cliente receberá sua primeira
versão operacional do sistema.
27/07/13

40. Existe um modelo ideal?
O perfil, a complexidade do negócio do
cliente, o tempo disponível, o custo, a
equipe, o ambiente operacional são fatores
que influenciarão diretamente na escolha do
ciclo de vida de software a ser adotado.
27/07/13

41. 1. Cascata ou ciclo de vida clássico ou tradicional;
2. Modelo evolutivo;
3. Transformação formal;
4. Integração de Componentes reusáveis;
5. Espiral.
Modelos de Processo de Software

42. O que diferencia um modelo de
processo do outro?
• É a ordem em que as fases vão ocorrer;
• O tempo e a ênfase dados a cada fase;
• As atividades presentes;
• Os produtos entregues.
27/07/13

43. • Modelo mais antigo e o mais amplamente conhecido da
engenharia de software;
• Modelado em função do ciclo da engenharia
convencional;
• Requer uma abordagem sistemática, sequencial ao
desenvolvimento de software;
• O resultado de uma fase é entrada para outra fase.
Modelo Cascata

44. • Utilizado principalmente quando os requisitos de um
determinado problema são bem compreendidos.
• Utilização:
• Fazer adaptações ou aperfeiçoamentos em um
sistema já existente.
• Necessidade de uma nova funcionalidade e os
requisitos estão bem definidos e são estáveis.
Modelo Cascata

45. Modelo Cascata

46. Definição de Requisitos
 O processo de coleta dos requisitos é intensificado e
concentrado especificamente no software.
 Deve-se compreender o domínio da informação, a
função, desempenho e interfaces exigidos.
Fases - Modelo Cascata

47. Projeto do Sistema
 Tradução dos requisitos do software para um conjunto
de representações que podem ser avaliadas quanto à
qualidade, antes que a codificação se inicie.
Fases - Modelo Cascata

48. Implementação
 Tradução das representações do projeto para uma
linguagem “artificial” resultando em instruções
executáveis pelo computador.
Fases - Modelo Cascata

49. Teste
 É a investigação do software a fim de fornecer
informações sobre sua qualidade em relação ao
contexto em que ele deve operar. Isso inclui o
processo de utilizar o produto para encontrar seus
defeitos.
Fases - Modelo Cascata

50. Manutenção
 Provavelmente o software deverá sofrer mudanças
depois que for entregue ao cliente.
 Causas das mudanças:
- Falhas;
-Adaptação do software para acomodar mudanças em seu
ambiente externo;
-Exigência do cliente para acréscimos funcionais e de
desempenho.
Fases - Modelo Cascata

51. Utilização
• Existe um conjunto de requisitos do usuário estáveis e
de alta qualidade;
• O sistema completo deve estar disponível de um única
vez;
• Recomendado para sistemas onde a segurança e a
confiabilidade tem grande importância.
27/07/13

52. • Projetos reais raramente seguem o fluxo sequencial que o
modelo propõe;
• Logo no início é difícil estabelecer explicitamente todos os
requisitos. No começo dos projetos sempre existe uma
incerteza natural;
• Fases são dependentes uma da outra;
• Não é permitida mudança dos requisitos no meio do
processo de desenvolvimento.
Desvantagens

53. Referências
• Pressman, R. Software Engineering: A Practitioner's
Approach. McGraw-Hill, 6th edition, 2006.
• Sommerville, I. Software Engineering:) International
Computer Science Series) 8th edition, 2006.

54. 1) O que é software?
2) Cite 4 Características de Software.
3) O que é a Engenharia de Software?
4) Qual o objetivo da Engenharia de Software?
4) O que é um processo de software?
5) O que é um modelo de Processo de Software?
6) Dê exemplos de modelos de Processo de Software e descreva o
Modelo cascata.
Sugestão:
Vincular a Engenharia de Software a um assunto visto em alguma
disciplina cursada na instituição.
Questionário - Introdução