Engenharia de Software I - Aula 3

684 visualizações

Publicada em

Slides da 3ª aula da disciplina "Engenharia de Software I".

Curso: Tecnologia em Análise e Desenvolvimento de Sistemas.

Publicada em: Negócios
  • Seja o primeiro a comentar

Engenharia de Software I - Aula 3

  1. 1. Alessandro Almeida | www.alessandroalmeida.com
  2. 2.  Entre os dias 3 e 5 de outubro Provavelmente, no dia 5/10 teremos uma palestra sobre...  Business Intelligence e o futuro da informação  (aguardem mais informações) Alguém deseja compartilhar algo?  Palestra ou estudo de caso
  3. 3. O que vimos nas aulas passadas?
  4. 4. O que é Engenharia de Software?
  5. 5.  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.
  6. 6.  ...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.
  7. 7. Conclusão
  8. 8. Mas... O que é processo?
  9. 9.  Um conjunto de atividades inter-relacionadas ou interativas, que transforma insumos (entradas) em produtos (saídas) [ABNT, 2001].
  10. 10. Entrada Processamento Saída ?
  11. 11.  Vamos ver um exemplo? Bolo de Limão
  12. 12. InsumosAtividades inter- relacionadas
  13. 13. E o produto?!?!?!?!
  14. 14. E nas empresas?
  15. 15. Folha de Pagamento Fechamento Contábil Pagamento
  16. 16. Todas as empresas trabalham orientadas a processos!
  17. 17. Uma reflexão sobre os pontos que fazem a diferença no resultado dasempresas
  18. 18. Tecnologia Resultado da EmpresaPessoas Processos
  19. 19.  Sobre as pessoas...  Nosso pessoal está motivado! ▪ (Será?)  Investimos em capacitação. ▪ (Será?)  A remuneração está adequada. ▪ (Será?)  Etc. ▪ (Será?)
  20. 20.  Sobre a tecnologia...  Investimos pesado! ▪ (Será?)  Utilizamos o que há de melhor. ▪ (Será?)  Etc. ▪ (Será?)
  21. 21.  Sobre os processos...  ?????????????????
  22. 22.  CONHECER e institucionalizar o fluxo de trabalho Identificar oportunidades de melhoria Definir papéis e responsabilidades Transformar o conhecimento tácito em conhecimento explícito Estabelecer controles “Unir” pessoas e tecnologia Colocar a casa em ordem
  23. 23.  As coisas simplesmente acontecem; O “sucesso” nos projetos acontece “por acaso”;  “Por acaso, temos alguns heróis...”  “Por acaso, o cliente era mais desorganizado...”
  24. 24.  É normal estouro de prazo e custos (entre outros problemas) Ambiente sem controle (caos) Grande dependência dos heróis (mas não é qualquer herói)
  25. 25.  Está sempre sob pressão Nunca tira férias Anda sempre estressado Nunca tem tempo para os amigos Nunca se diverte Sempre tem que trabalhar 24 horas direto Até consegue terminar o projeto, mas...
  26. 26.  Os processos sempre estarão lá, mesmo se a empresa preferir ignorá-los  Ou: Eles estão sempre lá, mesmo que a empresa não os conheça Quem controla quem?
  27. 27. Legal... Mas o que posso considerar ao definir um processo que atenda minhas demandas de Engenharia de Software?
  28. 28. RUP SWEBoK SCRUM BABoK Etc... mps.BrEUP OpenUP Extreme Programming PMBoK CMMI
  29. 29.  CMMI e mps.Br  Modelos de referência  Sugerem “o quê” deve ser feito, e não “como fazer”  Podem ser utilizados como guias para orientar o trabalho de definição / melhoria do processo  Fornecem um método para avaliação
  30. 30. Qual é o significado do acrônimo?
  31. 31.  Capability Maturity Model Integration®Fontes: Houaiss e Merriam-Webster
  32. 32.  Capability Maturity Model Integration® 1 : the quality or state of being capable 2 : poder de produção, de execução; rendimento máximo 3 : qualidade ou condição de capazFontes: Houaiss e Merriam-Webster
  33. 33.  Capability Maturity Model Integration® 1 : the quality or state of being mature 2 : estado, condição (de estrutura, forma, função ou organismo) num estágio adulto; condição de plenitude em arte, saber ou habilidade adquirida 3 : estado ou condição de pleno desenvolvimentoFontes: Houaiss e Merriam-Webster
  34. 34.  Primeiro você torna-se capaz de realizar algo, depois você adquire a maturidade Sou capaz!  Aprendi, treinei e sei executar... Possuo maturidade!  Sou capaz e tenho experiência...
  35. 35.  Capability Maturity Model Integration® 1 : simplificação da realidade 2 : representação em escala reduzida de objeto, a ser reproduzida em dimensões normais; maqueteFontes: Houaiss e Merriam-Webster
  36. 36.  Compilação de “boas práticas” no processo de diversas empresas de software Mostra O QUÊ fazer, e não COMO fazer Práticas distribuídas em “áreas de processo”  Área de Processo = PA (Process Area)
  37. 37.  Agrupamento de práticas comuns de uma determinada “disciplina”. Onde fica o “O que fazer?”.  Por exemplo: Project Planning (PP)
  38. 38.  Modelos de maturidade mantidos pelo SEI (Software Engineering Institute)  http://www.sei.cmu.edu/cmmi Abrangem todo ciclo de vida para o desenvolvimento (CMMI-DEV) e operação de software (CMMI-SVC) Também aborda projetos de aquisição (CMMI-ACQ)
  39. 39.  Sponsor:  DoD (U.S. Department of Defense) Versão 1.3 publicada em novembro de 2010
  40. 40.  Para quem não quer gastar...
  41. 41.  Para quem quer investir...
  42. 42. alessandro.almeida@uol.com.brwww.slideshare.net/alessandroalmeida

×