O documento apresenta os fundamentos da engenharia de software e sua importância em projetos práticos, com foco em técnicas de especificação e suporte. Detalha os métodos de avaliação do desempenho acadêmico, além de abordar a dinâmica das aulas e a colaboração entre alunos e professor. Também discute a gestão de projetos de software, desde a concepção até a manutenção, enfatizando a necessidade de boas práticas e a interação com os stakeholders.

1. Alessandro Almeida | www.alessandroalmeida.com

4.  Apresentar os princípios da Engenharia de
Software, além da sua aplicação e
importância no dia-a-dia dos projetos
 Compartilhar técnicas para especificação de
software
 Oferecer suporte ao projeto integrado

5.  Quatro aulas semanais...
 Terças: 19:00 – 20:40
 Sábados: 11:10 – 12:50

6.  Dinâmica das aulas
 Sem monólogo, por favor!
▪ Tragam seus questionamentos, ideias e experiências!
▪ A colaboração ajuda na construção do conhecimento.
 Material em constante mudança
▪ Publicação no espaço de arquivos do UNIFIEO e no
Slideshare

7.  Art. 63. O aproveitamento escolar será aferido por uma nota da avaliação continuada (AC) e uma
nota da prova final escrita. (PF).
 Parágrafo único - A avaliação continuada será obrigatoriamente composta de no mínimo dois (2)
instrumentos diferentes de avaliação, sendo um deles individual.
 Art. 64. As notas da avaliação continuada e da prova final serão expressas em números inteiros,
de zero a dez.
 Art. 65. A média final (MF) é a média aritmética entre as notas da avaliação continuada (AC) e da
prova final escrita (PF), segundo a fórmula:
MF = AC + PF
2
 Art. 66. O Calendário Escolar estabelecerá um período destinado ao lançamento das notas da
avaliação continuada (AC) e do período da realização da prova final escrita.

8.  Art. 67. Não haverá segunda chamada nem prova substitutiva.
 Art. 68. O aluno que obtiver média final inferior a seis, mas igual ou superior a dois, poderá
realizar o exame de 2ª Época, enviado pela Secretaria Geral, estabelecido no calendário, desde
que satisfeita a freqüência mínima exigida.
 Art. 69. O aluno que obtiver média final inferior a dois é considerado reprovado, sem direito à
segunda época.
 Art. 70. O exame de segunda época constará de uma (1) prova escrita, avaliada por nota expressa
em número inteiro, de zero a dez.
 Art. 71. A média final de segunda época (MF 2ª época) será a média aritmética de uma (1) prova
definida no artigo anterior (Ex 2ª época) mais a média final, dividido por dois, segundo a fórmula:
MF 2ª. época = (Ex 2ª época) + MF
2
 Fonte: Regimento Geral do Centro Universitário FIEO

10.  Simplificando...
Média Final: Para ser aprovado, a MF
precisa ser maior ou igual a 6!
MF = AC + PF
2

11.  Simplificando...
Mas como a Média Final é
composta?
MF = AC + PF
2

12.  Simplificando...
Avaliação Continuada
MF = AC + PF
2

13. De 0 a 10 pontos, sendo:
 Simplificando... - 0 a 5: Atividades parciais (provas e
outras atividades em sala de aula)
- 0 a 5: Projeto
MF = AC + PF
2

14.  Alguma novidade?

15.  Simplificando...
Prova Final (de 0 a 10 pontos)
(aplicada de acordo com o calendário da
instituição)
MF = AC + PF
2

16.  Simplificando...
Prova Final (de 0 a 10 pontos)
(aplicada de acordo com o calendário da
instituição)
MF = AC + PF
2

18.  Em todas as aulas...
 O feedback de vocês é fundamental
 Ajustes na dinâmica (conteúdo, velocidade, etc.)
 Ouvidoria do UNIFIEO
 Em dezembro...
 Avaliação sobre a disciplina

19.  Em todas as aulas...
 O feedback de vocês é fundamental
 Ajustes na dinâmica (conteúdo, velocidade, etc.)
 Ouvidoria do UNIFIEO
 Em dezembro...
 Avaliação sobre a disciplina

20.  Pessoalmente ou através do endereço
alessandro.almeida@uol.com.br
 Materiais:
 www.alessandroalmeida.com
 www.slideshare.net/alessandroalmeida

21. Analisando a atividade da aula passada...

22. Toda a parte de planejamento, desde a ideia inicial até a entrega do
projeto de software, buscando toda a necessidade do cliente na parte
do planejamento, estética, funcionalidade, praticidade e
documentação.
Estrutura desenhada antes da programação em si, serve para prever
situações e eliminar possíveis erros.
Roteiro para a construção de um produto / software a partir
de uma solução de um usuário ou área de negócio. A
Engenharia de Software propõe normas e uma metodologia
para atingir a solução desejada.

23. É a área de desenvolvimento, gestão de projeto, criação,
elaboração de ideias e, principalmente, colocar em prática as ideias
desenvolvendo software.
É todo o desenvolvimento que engloba todas as áreas da empresa,
com o trabalho em equipe, chegando ao objetivo desejado.
Projetar e executar o software do modo
que o usuário necessita.
Processo de confecção do aplicativo, desde o processo do
levantamento das necessidades, passando pela
programação, testes e, por fim, a implantação.

24. Já ouviram falar em “boas práticas” ou “melhores práticas”?

25.  Cuidado!!!!
 Quem definiu que as práticas são boas ou
melhores?
 A empresa fez uma avaliação?
 Houve um diagnóstico?
 Os principais stakeholders foram ouvidos?
 Sinal de alerta:
 Consultoria ou um grupo restrito definindo e
decidindo as “melhores” práticas para a área de TI

26. No geral, as empresas subdividem em etapas
que tem como início a necessidade de uma nova
ideia ou produto, processo de análise de criação
e, por fim, o desenvolvimento das ideias.
Em nossas empresas, os sistemas já são
executados, mas precisam de constante
atualização por erros detectados pelos
usuários, por isso, há a gestão desse
software.

27. Com a fragmentação do setor de TI, para que
o software tenha um bom funcionamento,
incluindo testes, análise e suporte.
Na prática, o cliente faz a solicitação do software para a
área responsável e os gerentes analisam a viabilidade do
projeto. Se for viável, direcionam programadores,
analistas, testadores, líderes de projeto, enfim, toda a
equipe. Depois de tudo codificado e testado, implanta-se o
software e faz-se futuras manutenções.

29.  Disciplina de engenharia cujo foco está em
todos os aspectos da produção de software,
desde os estágios iniciais da especificação do
sistema até sua manutenção, quando o
sistema já está sendo usado.

30.  ...engenharia...
 “construção, criação, execução de algo em que se
utilize engenho e arte” (Fonte: Dicionário Houaiss)

31.  ...todos os aspectos da produção de
software...
 Não apenas processos “técnicos”, mas também as
atividades de gerenciamento de projeto, por
exemplo.

32. Motivação

33.  Os números apresentados nos próximos slides são
baseados nas edições 2011 e 2012 do
Benchmarking em Gerenciamento de Projetos
 Realizado por capítulos nacionais e internacionais
(Argentina, França e Uruguai) do PMI
 Disponível para download gratuito no endereço
www.pmsurvey.org
 Setor considerado: Tecnologia da Informação
 Não é possível filtrar por tipo de projeto (por exemplo:
“Projeto de desenvolvimento ou manutenção de
software”)

34. 80%
71%
70%
64%
60%
50%
40% 2011
2012
29%
30% 27%
20%
9%
10%
0% 0% 0%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

35. 80%
71%
70%
64%
60%
50%
40% 2011
2012
29%
30% 27%
20%
9%
10%
0% 0% 0%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

36. Gerente de Projeto

37. Como assim?!?!
Nós

38. Consigo terminar
meus projetos,
mas sempre
estoura algo...
Nós

39. ... principalmente
custo e prazo.
Nós

40. Além disso, tenho
uns 3 projetos que
nunca terminam...
Nós

41. ... pois meu cliente
não quer
homologar.
Nós

42. 80%
71%
70%
64%
60%
50%
40% 2011
2012
29%
30% 27%
20%
9%
10%
0% 0% 0%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

43. Como podemos definir
80%
maioria das vezes e 71%
70%
poucas vezes? 64%
60%
50%
40% 2011
2012
29%
30% 27%
20%
9%
10%
0% 0% 0%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

44. Quem respondeu a
80%
pesquisa? O gerente do 71%
70%
projeto ou o cliente? 64%
60%
50%
40% 2011
2012
29%
30% 27%
20%
9%
10%
0% 0% 0%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

45. Gerente de Projeto
(na vida real)

46. 50%
47%
45% 45%
45% 43%
40%
35%
30%
25% 2011
2012
20%
15%
10% 9%
5%
5% 3% 3%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

47. 60%
55% 55%
50%
40%
34%
33%
30% 2011
2012
20%
10%
7% 7%
5%
4%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

48. 70%
64%
61%
60%
50%
40%
2011
2012
30%
23% 23%
20%
12% 13%
10%
3%
1%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

49. 80%
74%
69%
70%
60%
50%
40% 2011
2012
30%
20%
15% 16%
13%
11%
10%
2%
0%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

50.  Não cumprimento dos prazos
 Comunicação
 Escopo não definido adequadamente
 Mudanças de escopo constantes
 Estimativas incorretas
 Entre outros...

51. Gerente de Projeto
(na vida real)

52.  Agora, a principal motivação para pensarmos
em Engenharia de Software:
E na minha empresa, como funcionam os
projetos de desenvolvimento ou manutenção
de software?
 Enfrentamos problemas com prazo, custo,
qualidade, escopo, satisfação do cliente, etc.?

53.  Agora, a principal motivação para pensarmos
em Engenharia de Software:
E na minha empresa, como funcionam os
projetos de desenvolvimento ou manutenção
de software?
 Enfrentamos problemas com prazo, custo,
qualidade, escopo, satisfação do cliente, etc.?

55. alessandro.almeida@uol.com.br
www.slideshare.net/alessandroalmeida