Post on 19-Apr-2015
SA-CMM – Processo de Aquisição de Software
Mayerber NetoRafael AraújoRafael OrtolanRodrigo AlvesThiago 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çãoPlanejamento 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.acq-ref.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.