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, (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  [DoN00] Department of Navy, Information Systems Security. Software Acquisition In: ref.navy.mil/turbo2/topics/ci.cfmhttp:// ref.navy.mil/turbo2/topics/ci.cfm  [EEL03] EELES, P.; HOUSTON, K.; KOZACZYNSKI, W. Building J2EE Applications with Rational Unified Process. Addison Wesley  [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 Technical Report. CMU/SEI-96-TR-020. EXC-TR December,  [ISO95] NBRITO/IEC 12207: Tecnologia da Informação - processos de ciclo de vida de software, 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  [JAC99] JACOBSON, I.; BOOCH G.; RUMBAUGH, J. The Unified Software Development Process. Addison-Wesley Longman, Inc  [MEY01] MEYERS, B. C.; OBERNDORF, P. Managing Software Acquisition - SEI Series in Software Engineering. Addison Wesley  [ROC01] ROCHA, A. R. C.; MALDONADO, J. C.;WEBER, K. C. Qualidade de Software - Teoria e Prática. Prentice Hall  [COO02] COOPER, J.; FISHER, M. Software Acquisition Capability Maturity Model (SA-CMM) Version Technical Report. CMU/SEI-2002-TR-010. ESC-TR March,  [RAT02] RATIONAL SOFTWARE CORPORATION. Rational Unified Process Version Copyright