Engenharia de Software II - Aula 5

507 views
434 views

Published on

Slides da 5ª aula da disciplina "Engenharia de Software II".

Curso: Sistemas de Informação.

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
507
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
31
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Engenharia de Software II - Aula 5

  1. 1. Alessandro Almeida | www.alessandroalmeida.com
  2. 2. Relembrando aulas passadas...
  3. 3.  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.
  4. 4.  Processos...  Uma base para a Engenharia de Software
  5. 5. Legal... Mas o que posso considerar ao definir um processo que atenda minhas demandas de Engenharia de Software?
  6. 6. RUP SWEBoK SCRUM BABoK Etc... mps.BrEUP OpenUP Extreme Programming PMBoK CMMI
  7. 7. Qual é o significado do acrônimo?
  8. 8.  Capability Maturity Model Integration®Fontes: Houaiss e Merriam-Webster
  9. 9.  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
  10. 10.  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
  11. 11.  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...
  12. 12.  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
  13. 13.  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)
  14. 14.  Agrupamento de práticas comuns de uma determinada “disciplina”. Onde fica o “O que fazer?”.  Por exemplo: Project Planning (PP)
  15. 15.  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)
  16. 16.  Para quem não quer gastar...
  17. 17.  Para quem quer investir...
  18. 18. Optimizing  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID)Quantitatively Managed  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Decision Analysis and Resolution (DAR) Integrated Project Management (IPM) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Defined  Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Managed  Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)Initial  Processos ad hoc
  19. 19. Optimizing  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID)Quantitatively Managed  Organizational Process Performance (OPP) Quantitative Work Management (QWM) Capacity and Availability Management (CAM) Decision Analysis and Resolution (DAR) Incident Resolution and Prevention (IRP) Integrated Work Management (IWM) Organizational Process Definition (OPD) Defined  Organizational Process Focus (OPF) Organizational Training (OT) Risk Management (RSKM) Service Continuity (SCON) Service System Development (SSD) Service System Transition (SST) Strategic Service Management (STSM) Configuration Management (CM) Measurement and Analysis (MA) Work Monitoring and Control (WMC) Managed  Work Planning (WP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Service Delivery (SD) Supplier Agreement Management (SAM)Initial  Processos ad hoc
  20. 20. Optimizing  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID)Quantitatively Managed  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Acquisition Technical Management (ATM) Acquisition Validation (AVAL) Acquisition Verification (AVER) Decision Analysis and Resolution (DAR) Integrated Project Management (IPM) Defined  Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Risk Management (RSKM) Acquisition Requirements Development (ARD) Agreement Management (AM) Configuration Management (CM) Managed  Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Solicitation and Supplier Agreement Development (SSAD) Initial  Processos ad hoc
  21. 21.  Melhoria de processo do software brasileiro  www.softex.br/mpsbr Criado no final de 2003 Foco em micro, pequenas e médias empresas  Custo de implementação e avaliação menor  Aproximadamente, 380 empresas já foram avaliadas no modelo (mais de 70% são PME)
  22. 22.  Base Técnica para a definição do mps.Br  ISO/IEC 12207: Ciclo de Vida de processos de software  ISO/IEC 15504: Avaliações de processos de software  CMMI-DEV, 1.2 Níveis:  G (Parcialmente Gerenciado) até A (Em otimização)
  23. 23.  Reconhecido internacionalmente Consolidado (quase 20 anos) Dois tipos de abordagens para implementação  Contínua  Estágio Empresas no mundo inteiro utilizam Modelo abrangente  DEV, SVC e ACQ
  24. 24.  Modelo brasileiro  A questão do idioma influencia muito 7 níveis de maturidade  Os resultados podem ser visualizados no “curto prazo” Custo baixo  Comparado com o CMMI Foca a realidade brasileira  Micros, pequenas e médias empresas
  25. 25.  “Depende...” Tudo depende da MOTIVAÇÃO.  Qual é o nosso objetivo?  Quem é o nosso cliente?  Qual é a cultura da empresa?  Etc...
  26. 26.  Mito! Processos não são (e nunca serão) a solução dos seus problemas! Um processo sozinho (mesmo aderente ao CMMI ou afins) nunca será a solução; mas, sozinho, ele pode representar todo o problema
  27. 27.  Mito! Se o trabalho com os processos for feito da forma correta, o herói “estilo Jack Bauer” deixar de existir...
  28. 28.  Herói potencializado Consegue planejar seus projetos Tem os recursos definidos, de acordo com o projeto Tem tempo para estudar e utilizar novas tecnologias Tem tempo para os amigos Consegue se divertir e até namorar...
  29. 29.  Herói potencializado Consegue planejar seus projetos Tem os recursos definidos, de acordo com o projeto Tem tempo para estudar e utilizar novas tecnologias Tem tempo para os amigos Consegue se divertir e até namorar...
  30. 30.  Depende... Os benefícios quando a empresa reflete sobre seus processos já foram apresentados Mas há muitas empresas que buscam somente passar em alguma auditoria ou obter uma certificação, fazendo com que seus processos sejam somente para “inglês ver”
  31. 31.  Depende... Se os envolvidos na execução do processo participarem da definição, a tendência é que o jogo combinado atenda todas as partes, evitando atividades desnecessárias
  32. 32.  Depende... O processo criou uma burocracia? Há punições para quem não segue?
  33. 33.  O diagnóstico deve ser muito bem feito  Foto da situação atual  Cada doença com o seu remédio... Saiba onde você deseja chegar  Quais são as metas?  “Por que estamos iniciando esta empreitada?”
  34. 34.  A iniciativa deve estar alinhada com a estratégia da empresa Alguém “forte” na organização deve ser o padrinho do projeto Normalmente envolve mudança cultural  Traga o pessoal de RH para o projeto
  35. 35.  Conte com os “integradores” TODOS devem participar (desde analistas até diretores)  Alguém deve gerenciar a iniciativa Seja “subversivo”  Sempre questionem!  “Por que fazer assim se podemos fazer diferente?”
  36. 36.  Seja um “herege”  Cuidado com os “religiosos”!  “Misture” práticas, metodologias, ferramentas e etc. Comunique!
  37. 37.  Cuidado com aqueles que só estão preocupados com o “diploma” na parede Cuidado com as "melhores práticas"  "Melhor" para quem? Não queremos uma ditadura!  Mas ninguém deseja viver em uma anarquia... Não se esqueçam: Os processos sempre estarão lá, mesmo que a empresa não os controle
  38. 38. alessandro.almeida@uol.com.brwww.slideshare.net/alessandroalmeida

×