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