Slides da 4ª aula da disciplina "Engenharia de Software I". Curso: Tecnologia em Análise e Desenvolvimento de Sistemas.

1. Alessandro Almeida | www.alessandroalmeida.com

2. Relembrando aulas passadas...

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.  ...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.

5.  Processos...
 Uma base para a Engenharia de Software

6.  Um conjunto de atividades inter-relacionadas
ou interativas, que transforma insumos
(entradas) em produtos (saídas) [ABNT,
2001].

8. Folha de Pagamento
Fechamento Contábil
Pagamento

9. Todas as empresas trabalham
orientadas a processos!

10.  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?

11. Legal... Mas o que posso considerar ao definir
um processo que atenda minhas demandas
de Engenharia de Software?

12. RUP
SWEBoK
SCRUM
BABoK
Etc...
mps.Br
EUP
OpenUP
Extreme Programming
PMBoK CMMI

14. Qual é o significado do acrônimo?

15.  Capability Maturity Model
Integration®
Fontes: Houaiss e Merriam-Webster

16.  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 capaz
Fontes: Houaiss e Merriam-Webster

17.  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
desenvolvimento
Fontes: Houaiss e Merriam-Webster

18.  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...

19.  Capability Maturity Model
Integration® 1 : simplificação da
realidade
2 : representação
em escala reduzida
de objeto, a ser
reproduzida em
dimensões
normais; maquete
Fontes: Houaiss e Merriam-Webster

22.  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)

23.  Agrupamento de práticas comuns de uma
determinada “disciplina”.
 Onde fica o “O que fazer?”.
 Por exemplo: Project Planning (PP)

24.  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)

25.  Sponsor:
 DoD (U.S. Department of Defense)
 Versão 1.3 publicada em novembro de 2010

26.  Para quem não quer gastar...

27.  Para quem quer investir...

29. CMMI-SVC
CMMI
Model
Foundation
CMMI-DEV CMMI-ACQ
Fonte: -http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html

30.  Representações
 Contínua (Capability Levels)
 Por estágio (Maturity Levels)

31.  Exemplo:

32.  Exemplo:

33. 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

34. 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

35. 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

36.  “Certificação” e exigências de clientes
propiciam o processo só para constar
 Perde-se o propósito do CMMI
 O CMMI é totalmente “orientado a
evidências”
 Embora contemple todo o ciclo de vida, há
pouca preocupação com gestão de pessoas
 Para tentar resolver: People CMM
 Alto custo de implementação

39.  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)

40.  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)

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