SA-CMM – Processo de
Aquisição de Software
Mayerber Neto
Rafael Araújo
Rafael Ortolan
Rodrigo Alves
Thiago Araújo
Introdução

Aquisição – todas as ações realizadas pelo
comprador

Processo de Aquisição


Necessidade de adquirir um sistema
Escolhas são necessárias
Como fazer escolhas adequadas?




Necessidade de conhecimento de requisitos
Necessidade de conhecimento de entradas e
saídas
Necessidade de um processo bem definido de
aquisição
Formalização (1/2)
 Aquisição de um sistema
 O fornecedor desenvolve tudo do zero
 Aquisição de um produto de software
 Sistema já desenvolvido
 Aquisição de um serviço de software
 É necessário algum desenvolvimento (sistemas
parcialmente desenvolvidos, por exemplo)
Formalização (2/2)
 Definir o que se quer pode não ser tão fácil!
Formalização (2/2)
 Definir o que se quer pode não ser tão fácil!
 É imprescindível a participação do
comprador no desenvolvimento, ainda que
apenas com elicitação de requisitos
 Formalizar o processo de aquisição significa,
portanto
 Redução de falhas
 Redução de riscos
SA-CMM
 Software Engineering Institute at Carnegie Mellon University
(SEI/CMU)
 Desenvolveram o CMM (SW-CMM)
 Tentativa de adaptá-lo para aquisição
 Definição de diretrizes, em cinco níveis, que uma
organização deve seguir para dispor de um modelo
adequado de aquisição
 SW-CMM descreve o papel do desenvolvedor
 SA-CMM descreve o papel do comprador
 Interface que facilita e ferramentas que agilizam a aquisição
 Processo genérico que visa melhorias contínuas
Abrangência do SA-CMM
 Definição de requisitos
 Definição de requisitos para o sistema a ser adquirido
 Requisitos técnicos  afetam o sistema em si
 Requisitos funcionais, de performance, de qualidade, ...
 Requisitos não técnicos  afetam o processo de
aquisição
 Cronograma, datas de entrega, pontos de controle, ...
 Atividades de pré-contrato
 Preparação de um pacote de solicitação
 Desenvolvimento de requisitos de aquisição
 Participação em uma pré-seleção
 Termina com a conclusão dos termos do contrato,
para produtos e para serviços
Quem pode usar o SA-CMM?
 Genérico o suficiente para ser usado por qualquer
tipo de organização que adquire qualquer tipo de
produto
 Abrangente o suficiente para atender todas as
necessidades da organização relacionadas à
aquisição de software
 Não se propõe a descrever uma forma única como
realizar os processos
 Descreve as características gerais que o processo de
aquisição deve ter
 Ele vem para ajudar, não para congelar
 Não adianta se implantar um processo que vá fazer a
empresa parar!
O processo (1/2)
 Define cinco níveis de maturidade
 Cada nível define o nível de competência e contém
processos chave
 Cada processo possui
 Objetivos
 resultado agregado devido à implementação de um
processo chave
 Compromisso para realizar
 ações que a organização deve tomar para estabelecer o
processo
 Habilidade para realizar
 pré-condições que devem existir no projeto ou na
organização para implementar o processo
O processo (2/2)
 Cada processo possui (cont.)
 Atividades realizadas
 papéis e procedimentos necessários para
implementar um processo chave
 Medição e Análise
 necessidade de se medir a performance do
processo e a interpretação destas medições
 Verificação de Implementação
 passos que são cumpridos para garantir que as
atividades são realizadas de acordo com o
processo que foi estabelecido
Níveis de Maturidade (1/2)
 Nível 1 – Inicial
 Resultados imprevisíveis, o processo é ad hoc e
“caótico”
 Nível 2 – Repetível
 Práticas básicas de gerenciamento de projetos são
estipuladas para planejar os aspectos de aquisição
 Práticas bem sucedidas são repetidas em outros
projetos
 Nível 3 – Definido
 Processo de aquisição padronizado e bem documentado
 Todos os projetos utilizam o processo estipulado
Níveis de Maturidade (2/2)
 Nível 4 – Quantitativo
 Medidas detalhadas do processo de aquisição de
software, produtos e serviços são coletadas
 Processos entendidos qualitativamente e
quantitativamente
 Nível 5 – Otimizado
 Melhorias contínuas, incorporação de novas idéias e
tecnologias
 Realimentação das experiências do processo
Nível 2 - Repetível
 Processos Chave
 Planejamento de Aquisição de Software;
 Solicitação;
 Desenvolvimento e Gerenciamento dos
Requisitos;
 Gerenciamento do Projeto;
 Administração de Contratos;
 Validação
 Transição para Suporte
Nível 3 - Definido
 Processos Chave
 Definição e Manutenção do Processo;
 Requisitos do Usuário;
 Gerenciamento de Desempenho de
Projeto;
 Gerenciamento de Desempenho de
Contrato;
 Administração de Riscos de Aquisição;
 Gerenciamento de Programas de
Treinamento;
Níveis 4 e 5 – Quantitativo e Otimizado
 Processos Chave – Nível 4
 Gerenciamento Quantitativo dos
Processos;
 Gerenciamento Quantitativo da Aquisição;
 Processos Chave – Nível 5
 Melhoria Contínua do Processo;
 Gerenciamento da Inovação da Aquisição;
Adaptando o SA-CMM Nível 2 e a
Visão de Casos de Uso (1/4)
 Planejamento da Aquisição
 Os critérios de seleção, requisitos técnicos e não
técnicos, prazos e a forma de avaliação dos
produtos e fornecedores
 Definição dos Requisitos Técnicos do Sistema
 Documento de Visão do RUP©
 Visão dos clientes
 Características essenciais
 Níveis aceitáveis de qualidade
Adaptando o SA-CMM Nível 2 e a
Visão de Casos de Uso (2/4)
 Solicitação, Seleção e Avaliação de Produtos e
Fornecedores
 Pacote de solicitação
 Documento de visão, acrescido da referência da equipe
técnica para contato;
 Relatório Sintético de Casos de Uso;
 Minuta do contrato;
 Documento com o processo e critérios de avaliação do
produto.
 Contratação do Fornecedor
 Contrato definitivo
 Customização e implantação do sistema
 Casos de uso de alta prioridade
Adaptando o SA-CMM Nível 2 e a
Visão de Casos de Uso (3/4)
 Planejamento da Implantação
 Priorização de casos de usos
 Planejamento do treinamento;
 Controle das atividades do fornecedor;
 Customização, Implantação e Testes
 Execução do plano de implantação
 Finalização do manual de suporte ao usuário e
treinamento
 Verificar o andamento do projeto, analisar riscos e
prazos e medidas de contingências
Adaptando o SA-CMM Nível 2 e a
Visão de Casos de Uso (4/4)
 Homologação do Produto
 Utilização dos testes para homologação
 Caso o resultado seja negativo, é estabelecido um
novo planejamento e implementação de ajustes
 Planejamento dos Ajustes
 Mini-sistemas com cronogramas e suas fases
 Ciclo se repete até aprovação completa
 Rescisão do contrato
Conclusão (1/2)
 Benefícios da adoção
 Definição de padrões baseados em modelo de
maturidade
 Utilização de procedimentos focados na melhoria
contínua dos processos de contratação
 Definição de níveis de serviço baseados em
parâmetros da maturidade dos processos e da
qualidade dos produtos
 Realização de avaliações periódicas nos processos
dos fornecedores
 Criação de um banco de fornecedores avaliados
 Melhoria contínua dos procedimentos de
contratação e dos processos de software
Conclusão (2/2)
 SA-CMM no Brasil
 72% das empresas que terceirizam seus serviços
não exigem padrões de qualidade
 Dentre as 28% restantes:
 ISO 9000 (55%)
 Normas próprias (37%)
 SA-CMM (6%)
 Outros (2%)
 Nível de maturidade não é garantia de
continuidade de bom serviço
 É fundamental definir padrões de maturidade e
avaliações periódicas
Referências

[BOO97] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. Unified Modeling
Language Semantics and Notation Guide 1.0 San Jose, CA, 1997.
(Relatório Técnico da Rational Software Corporation).

[BOO99] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified
Modeling Language User Guide. Addison-Wesley Longman, Inc. 1999.

[DoN00] Department of Navy, Information Systems Security.
Software Acquisition In: http://www.acqref.navy.mil/turbo2/topics/ci.cfm

[EEL03] EELES, P.; HOUSTON, K.; KOZACZYNSKI, W. Building J2EE
Applications with Rational Unified Process. Addison Wesley. 2003.

[FER96] FERGUSON, J.; COOPER, J.; FALAT, M.; FISHER, M.; GUIDO,
A.; MARCINIAK, J.; MATEJCECK, J.; WEBSTER, R. Software
Acquisition Capability Maturity Model (SA-CMMSM) Version 1.01.
Technical Report. CMU/SEI-96-TR-020. EXC-TR96-020. December,
1996.

[ISO95] NBRITO/IEC 12207: 1995. Tecnologia da Informação processos de ciclo de vida de software, 1997. apud [ROC01]
Referências

[JAC92] JACOBSON, I.; CHRISTERSON, M.; JONSSON,
P.;ÖVERGAARD, G. Object-Oriented Software Engineering. New
York. 1a. edição. Addison-Wesley Publishing Company. 1992.

[JAC99] JACOBSON, I.; BOOCH G.; RUMBAUGH, J. The Unified
Software Development Process. Addison-Wesley Longman, Inc.
1999.

[MEY01] MEYERS, B. C.; OBERNDORF, P. Managing Software
Acquisition - SEI Series in Software Engineering. Addison Wesley.
2001.

[ROC01] ROCHA, A. R. C.; MALDONADO, J. C.;WEBER, K. C.
Qualidade de Software - Teoria e Prática. Prentice Hall. 2001.

[COO02] COOPER, J.; FISHER, M. Software Acquisition Capability
Maturity Model (SA-CMM) Version 1.03. Technical Report.
CMU/SEI-2002-TR-010. ESC-TR-2002-010. March, 2002.

[RAT02] RATIONAL SOFTWARE CORPORATION. Rational Unified
Process Version 2002.05.20 Copyright 1987-2002. 2002.