3. Parte essencial do projeto, direcionando as tomadas de decisões,
planejamento, desenvolvimento e manutenção de todo o ciclo de
vida do projeto.
Responsável pelo levantamento de requisitos, ou seja, toda a
documentação do projeto necessária para o entendimento
aprofundado do software a ser desenvolvido.
Fundamental para o desenvolvimento de um software com qualidade. O
desenvolvimento é complexo, envolvendo diversas áreas. Permite
padronizar os processos, reduzindo custo e prazo.
4. Especificação, desenvolvimento e manutenção
de sistemas de software. Contém melhores
práticas de gerenciamento de projetos, que
visa organização, produtividade e qualidade.
Conjunto de metodologias e boas práticas para arquitetar e
planejar o desenvolvimento de qualquer tipo de software que
atenda uma necessidade específica do cliente.
Padrão para todas as fases de um desenvolvimento de
sistemas, desde o levantamento de requisitos (regras de
negócio) até testes e manutenções.
6. 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
7. Facilita o desenvolvimento de um projeto e define
seus objetivos através de um estudo detalhado.
Define o roteiro de construção do projeto, por meio
de metodologias como ITIL, CMMI, etc.
Como modelo conceitual, possui 3 elementos: Métodos,
procedimentos e ferramentas. Nesses processos são
envolvidos a parte de testes e manutenções,
documentações que são desenvolvidas com custos e
prazos estimados.
8. Independente do tamanho do projeto e/ou empresa,
a Engenharia de Software está presente na área
de TI, organizando e auxiliando no
desenvolvimento de projetos.
Na maioria das empresas o responsável pelo levantamento de requisitos
recebe toda a especificação dos projetos e alinha de acordo com as
necessidades, utilizando, por exemplo, conceitos de UML. Passa as
informações para a equipe de desenvolvimento, mas sempre
acompanhando para que nada saia fora do que foi combinado.
9. A Engenharia de Software ajuda na
padronização e criação de processos,
gerando várias documentações que
auxiliam na tomada de decisões.
Na minha empresa, é aplicada quando as
fases de desenvolvimento de um
software são divididas, definindo seus
processos e padrão de qualidade.
10. Cada empresa utiliza a Engenharia de Software
conforme sua necessidade, onde, de acordo com o
projeto, é estudado o melhor método para utilizar.
Alguns mais complexos e detalhados, outros mais
simples.
Normalmente, a Engenharia de Software é
aplicada nas empresas para que haja melhoria
nos sistemas conforme levantamento dos
requisitos com os usuários/clientes.
11. Em empresas de grande porte, onde o cliente exige a
qualidade do serviço, as consultorias utilizam todas as etapas
da Engenharia de Software, incluindo recursos como CMMI,
COBIT, entre outros. Mas internamente, nas consultorias e nos
departamentos de uma empresa, o uso da Engenharia de
Software é defasado, devido ao curto espaço de tempo para
resolução de problemas e falta de conhecimento da gerência e
direção.
12.
13. 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.
14. ...engenharia...
“construção, criação, execução de algo em que se
utilize engenho e arte” (Fonte: Dicionário Houaiss)
15. ...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.
17. 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”)
18. 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
19. 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
26. 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
27. 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
28. 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
30. 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
31. 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
32. 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
33. 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
34. Não cumprimento dos prazos
Comunicação
Escopo não definido adequadamente
Mudanças de escopo constantes
Estimativas incorretas
Entre outros...
36. 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.?
37. 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.?