VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
Utilização do TSP para a Gerência de Equipes Nível 2 do CMMI Samuel Dall Agnol1, Juliana Silva Herbert1 1
ESICenter UNISINOS – Universidade do Vale do Rio dos Sinos Av. Unisinos, 950 – CEP 93.022-000 – São Leopoldo – RS – Brasil
[email protected],
[email protected]
Abstract.The use of models and methodologies scientifically developed is gaining maturity and visibility due to the increasing concern of software developers with the common problems of their area. Although TSP does not describe methods that address all process areas of CMMI, this combination represents an ideal strategy to make process improvement projects faster in software development companies. This paper presents the adherence of TSP methods to the CMMI and the description of a process for the development of systems based on COTS to address the CMMI process area not covered by TSP. Resumo. A utilização de modelos e metodologias desenvolvidos cientificamente como o CMMI e o TSP têm ganhado, recentemente, maturidade e visibilidade, em função do aumento da preocupação das empresas de desenvolvimento de software com os problemas típicos da área. Embora o TSP não descreva métodos para cobrir todas as áreas de processo do CMMI, esta combinação configura uma ótima estratégia para acelerar projetos de melhoria de processos em organizações de desenvolvimento de software. Este trabalho apresenta, portanto, a aderência entre os métodos do TSP ao CMMI e a descrição de um processo para desenvolvimento de sistemas baseados em COTS para atender a área de processo do CMMI não coberta pelo TSP.
1. Introdução Nos últimos anos, as organizações de desenvolvimento de software têm aumentado sua percepção em relação aos problemas que tipicamente ocorrem neste contexto. Software com defeitos, prazos e orçamentos não cumpridos e insatisfação de clientes, são eventos muito mais freqüentes do que se deseja [SOM03]. Desde a década de 1970, existe um consenso na comunidade de Engenharia de Software de que estes problemas estão, em grande parte, relacionados ao fato de que o desenvolvimento de software é muitas vezes realizado de forma "artesanal", isto é, através de métodos improvisados pelos desenvolvedores, onde o sucesso depende muito mais de seu talento individual (nem sempre abundante) do que de uma sólida formação acompanhada de métodos formais que dirijam suas atividades [SOM03]. Um exemplo de modelo que de alguma forma considera estes métodos formais é o CMMI (Capability Maturity Model Integration) que é um framework focado no processo de desenvolvimento de software. Ele foi desenvolvido através de observações das melhores 107
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
práticas nas organizações de software e reflete uma coletânea de experiências e expectativas de muitas delas [JAL99]. Embora este modelo seja completo e abrangente, segundo o SEI/CMU (Software Engineering Institute/ Carnegie Mellon University) [DAV03], a preocupação dele está em descrever o quê uma organização em certo nível de maturidade deve praticar. O CMMI não orienta como a empresa deve implementar suas áreas de processo para atingir os níveis de excelência propostos pelo modelo. Esta lacuna pode ser preenchida com as diversas metodologias para desenvolvimento de software. Neste artigo, considera-se o TSP (Team Software Process) [HUM00]. A alta aderência de métodos do TSP com as práticas propostas pelo CMMI acelera processos de melhoria de software baseados neste modelo e permite que altos níveis de excelência sejam obtidos em tempos menores que a utilização de outras metodologias [DAV03, NAV03]. Por isso este artigo apresenta uma proposta de métodos de desenvolvimento de software que atendam todas as áreas de processo do nível 2 do CMMI. A proposta está fortemente embasada no uso de TSP, porém para área de Gerência de Acordos com Fornecedores é utilizado um processo baseado em COTS (Commercial off-the-shelf), visto que o TSP não endereça nenhum método neste aspecto. 1.1 Objetivos do trabalho Sommerville [SOM03] aponta como principal causa dos problemas de qualidade de software o fato de que as organizações precisam competir para sobreviver. O chamado “preço definido para ganhar” espreme cronogramas e orçamentos para ganhar o contrato de desenvolvimento. Em conseqüência deste sistema, a qualidade do produto é afetada diretamente. Com base nisso o trabalho descrito neste artigo teve como objetivo principal identificar, à luz do referencial teórico, métodos para desenvolvimento de software alinhados ao nível 2 do modelo CMMI. Acredita-se que o auxílio de métodos comprovados para o desenvolvimento de software possa diminuir o impacto sobre a qualidade dos produtos de software provocado pela competição acirrada do mercado atual. Em contra-partida o alinhamento dos métodos ao CMMI garante adequação dos métodos a um modelo de qualidade estabelecido e aceito mundialmente [JAL99]. Além disso, são objetivos parciais do trabalho: •
identificar as áreas de processo do CMMI através de revisão bibliográfica;
•
identificar os métodos para desenvolvimento de software do TSP;
•
estabelecer relações entre os métodos identificados e as melhores práticas propostas pelo CMMI.
1.2 Metodologia Para alcançar os objetivos propostos, uma série de atividades foi realizada, cada uma gerando um resultado importante para a composição deste trabalho: •
Determinação dos objetivos: as fases seguintes estão baseadas no objetivo principal deste trabalho que é identificar métodos de desenvolvimento de software à luz do referencial teórico. 108
VI Simpósio Internacional de Melhoria de Processos de Software
•
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
Elaboração do plano de trabalho: o plano elaborado, muitas vezes, é provisório e passa por reformulações sucessivas [GIL91]. O plano adotado para este trabalho compreende: o identificar as fontes bibliográficas para o embasamento sobre o CMMI. Foram utilizados, nesta etapa, os artigos e relatórios técnicos publicados pelo SEI/CMU, instituto mantenedor do modelo CMMI; o leitura destes artigos com especial atenção às áreas de processo descritas no modelo; o descrever os métodos propostos pelo TSP e descrever os relacionamentos entre estes métodos e as áreas de processo do CMMI.
•
Identificação das fontes: nesta etapa foram identificadas as fontes capazes de fornecer as respostas adequadas para atingir o objetivo proposto. As fontes identificadas estão listadas na Seção Referências.
•
Leitura do material: segundo Gil [GIL91] a leitura que se faz na pesquisa bibliográfica deve servir os seguintes objetivos: o identificar as informações e os dados constantes do material impresso; o estabelecer relações entre as informações e os dados obtidos com o problema proposto; o analisar a consistência das informações e dados apresentados pelos autores.
•
Redação do trabalho: nesta etapa será confeccionado o relatório apresentando: o problema que deu origem à investigação, a delimitação dos objetivos, o contexto do trabalho e as conclusões obtidas.
1.3 Estrutura do Artigo Esta seção apresentará resumidamente cada seção deste artigo. A presente seção apresentou brevemente a motivação, os objetivos e a metodologia de desenvolvimento deste artigo. Na segunda e terceira seção, serão apresentados os conceitos do CMMI e TSP respectivamente, mais relevantes para este trabalho. Já na Seção 4, será apresentada a aderência entre os métodos do TSP e as práticas propostas pelo CMMI. Em seguida, na Seção 5, será apresentado brevemente um processo para desenvolvimento de software baseado em COTS. Esta abordagem é necessária para cobrir a lacuna deixada pelo TSP na área de processo de gerência de acordos com fornecedores do CMMI. Na Seção 6 será apresentado um caso prático de aplicação dos métodos propostos pelo TSP numa empresa de desenvolvimento de software. A Seção 7 traz as conclusões deste artigo. Nele estão as dificuldades encontradas e os resultados obtidos, bem como as possíveis extensões futuras deste trabalho.
2. CMMI O CMMI é um framework que possui os elementos necessários para tornar um processo de desenvolvimento de software mais eficiente e controlado [BAR02] e foi construído para integrar os diferentes modelos criados a partir do sucesso alcançado pelo CMM para software. O termo disciplina foi adotado para representar os diferentes corpos de 109
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
conhecimento integrados no CMMI. Para atingir os objetivos propostos (métodos para o desenvolvimento de software), este trabalho adotará as disciplinas de Engenharia de Software e Engenharia de Sistemas como guias porque segundo o SEI/CMU [SEI04], estas disciplinas são escolhidas pela grande maioria das organizações que implementam processos de melhoria em desenvolvimento de software. Além disso, o CMMI introduziu duas representações para apresentar seu conteúdo. Este trabalho adotou a representação por estágios pois além de prover uma seqüência comprovada de melhorias, iniciando com práticas básicas e evoluindo através de um caminho pré-definido de níveis sucessivos, permite comparações no âmbito da uma organização, ou entre organizações; e é a representação mais utilizada por organizações de software segundo os resultados de avaliação do CMMI reportados1 ao SEI/CMU [SEI04]. Na representação por estágios os níveis de maturidade são uma forma de priorizar as ações de melhoria de tal forma que se aumente a maturidade do processo de software. Com exceção do nível 1 (considerado imaturidade organizacional), todos os níveis restantes (gerenciado, definido, quantitativamente gerenciado e em otimização) são compostos de PAs (Process Areas) que tratam aspectos de cada componente do processo. A PA é um conjunto de práticas relacionadas em uma determinada área que, quando executadas coletivamente, satisfazem um conjunto de objetivos considerados importantes para executar significantes melhorias naquela área. O nível 2 do CMMI (objeto deste trabalho) é composto das PAs: Gerência de Requisitos, Planejamento de Projetos, Acompanhamento e Controle de Projetos, Gerenciamento de Acordos com Fornecedores, Medição e Análise, Garantia de Qualidade de Produto e Processo e Gerenciamento de Configuração. Portanto, este estudo estará focado em demonstrar a aderência entre as práticas relacionadas em cada PA do CMMI com os métodos propostos por Humphrey [HUM00] na metodologia TSP.
3. Metodologia TSP O objetivo do TSP é criar um ambiente de trabalho em equipe que suporte o trabalho individual disciplinado e mantenha-o direcionado à equipe [DAV03]. O TSP faz uso do PSP (Personal Software Process [HUM97]) para guiar o trabalho individual dos desenvolvedores de software, mostrando-lhes como medir seu trabalho e utilizar estes dados para melhorar seu desempenho. Basicamente os métodos do PSP são utilizados pelos desenvolvedores no seu trabalho rotineiro. Além disso, a metodologia TSP conduz o desenvolvimento de software através de vários ciclos rápidos até atingir o produto final. Cada ciclo guia a equipe através de sete passos: lançamento, estratégia, planejamento, requisitos, projeto, implementação, teste e postmortem. Em cada ciclo os desenvolvedores repetem os mesmos passos (Figura 1) e aumentam o produto construído no ciclo anterior [HUM00].
1
223 (duzentas e vinte e três) avaliações foram reportadas ao SEI/CMU entre abril de 2002 e março de 2004 utilizando-se o método SCAMPI classe A versão 1.1 para avaliar organizações que implementaram o modelo CMMI versão 1.1 [SEI04] 110
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
3. Componentes do TSP O TSP fornece um framework simples e bem definido do processo que será usado para construção do software. Além disso a metodologia fornece orientação específica na formação de equipes, dispensando especial atenção na definição dos papéis e responsabilidades de cada membro, bem como na definição dos objetivos de cada um [HUM00]. Para compor este framework o TSP utiliza-se de scripts de processo (Tabela 2) e formulários (Tabela 1). Os scripts de processo descrevem detalhadamente as atividades que devem ser executadas em cada etapa do processo de desenvolvimento. Já os formulários são utilizados para coletar e apresentar os dados usados no controle do processo. Para completar os componentes do TSP são utilizados também definições de padrões e sugestões de métricas para controlar o processo. Os componentes do TSP serão confrontados contras as práticas específicas do CMMI no nível 2 para determinar o nível de aderência das duas abordagens. Necessidade de produto
Ciclo 1 - Lançamento
Estratégia 1 Ciclo 2 - Lançamento Plano 1 Requisitos 1 Estratégia 2 Projeto 1
Ciclo 3 - Lançamento
Plano 2 Implementação 1 Requisitos 2
Estratégia 3
Projeto 2
Plano 3
Implementação 2
Requisitos 3
Teste 2
Projeto 3
Postmortem 2
Implementação 3
Teste 1 Postmortem 1
Teste 3 Postmortem 3
Produto final Versão final Figura 1 - Estrutura e fluxo do TSP.
111
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
Tabela 1 - Formulários do TSP
Formulário Requisição de alteração da configuração Relatório de posição da configuração Informações do membro da equipe Relatório de inspeções Rastreabilidade dos riscos do projeto Registro de defeitos Registros de tempos Registros de testes Avaliação da equipe e dos pares Proposta de melhorias de processo Modelo de planejamento cronograma
Abrev CCR CSR INFO INS ITL LOGD LOGT LOGTEST PEER PIP SCHEDULE
Formulário Formulário da estratégia Sumário dos defeitos injetados Sumário dos defeitos removidos Sumário do plano Plano de qualidade Sumário de tamanho Sumário de tempo de desenvolvimento Sumário de tarefas Modelo de planejamento de tarefas Relatório de posição semanal
Abrev STRAT SUMDI SUMDR SUMP SUMQ SUMS SUMT SUMTASK TASK WEEK
Tabela 2 - Scripts de processo do TSP Formulário Projeto (Design) Processo de desenvolvimento do software Implementação Inspeção Lançamento do projeto Desenvolvimento do plano Postmortem
Abrev DES DEV IMP INS LAU PLAN PM
Formulário Desenvolvimento dos requisitos Gerenciamento de configuração de software Desenvolvimento da estratégia Teste de sistema e integração Teste unitário Reuniões semanais
Abrev REQ SCM STRAT TEST UT WEEK
4. O TSP e o nível 2 do CMMI O objetivo desta seção é de justificar a escolha do TSP como processo de desenvolvimento de software que acelera os esforços de evolução para o CMMI demonstrando a alta aderência entre as duas abordagens. Por se tratar de um assunto demasiadamente extenso não é objetivo esgotá-lo (certamente existe conteúdo suficiente para um estudo exclusivo desta questão). Portanto, casos como as práticas genéricas que no CMMI são apresentadas ao final de cada PA para demonstrar como cada prática deve ser aplicada exclusivamente naquela PA, serão apresentadas apenas uma vez no modo mais amplo abordando apenas a aderência ao TSP de cada grupo de práticas genéricas. Cabe registrar também que, devido ao escopo deste trabalho, será coberta apenas a aderência entre o TSP e as PAs do nível dois do CMMI. Grande parte do embasamento deste capítulo foi obtida em estudos do SEI [DAV03a] que relatam o mapeamento dos componentes do TSP com o SW-CMM. Isto foi possível devido ao fato do CMMI ser a evolução natural do SW-CMM e a similaridade entre as duas versões ser extremamente alta [SEI02]. Estudos do SEI [DAV00] apontam para forte aderência entre o SW-CMM e o TSP porém algumas lacunas são salientes. Cita-se como exemplo a total ausência de cobertura do TSP para área de gerenciamento de acordos com fornecedores, justificada pelo SEI [DAV03a] na ausência de necessidade pelas empresas que adotam o TSP. Para assegurar um framework completo de métodos para atender o nível 2 do CMMI será descrita na Seção 5 a base de um processo para montagem de sistemas baseados em COTS.
112
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
4.1 TSP e o grupo de práticas genéricas Durante a etapa de lançamento do projeto do TSP assegura-se que os fundos e recursos, ferramentas e habilidades necessárias serão providos, desta forma as práticas para habilidades a executar são atendidas. Para o grupo de práticas de direção da implementação o TSP direciona procedimentos específicos e detalhados para gerência de configuração e, construção e revisão do plano geral para o projeto. Já na verificação da implementação o TSP envolve a gerência no lançamento do projeto e no entendimento e confirmação dos planos para a equipe. Além de definir vários marcos, reuniões de revisão e relatórios para atender as práticas deste grupo. Enquanto isso no grupo de compromissos para executar o TSP não direciona a criação de políticas organizacionais, entretanto o comportamento de suas equipes usualmente é consistente com as políticas já existentes na organização. 4.2 Medições e Análises “O objetivo das Medições e Análise é desenvolver e sustentar a capacidade de medição que é usada para suportar as informações de gerenciamento necessárias.” [SEI02] A Tabela 3 exibe de forma resumida as práticas específicas da PA de Medições e Análise do CMMI e seu relacionamento com os elementos do TSP [DAV03a, HUM00]. Tabela 3 - TSP X Medições e Análises
MEDIÇÕES E ANÁLISE OBJETIVO CMMI COMENTÁRIOS SG 1 – Alinhar atividades de medição e Na etapa de lançamento do projeto são definidos os objetivos do projeto, os dados que deverão ser coletados para avaliar o análise: progresso do projeto e a periodicidade que estes dados serão Atividades e objetivos de medição são alinhados com as informações necessárias avaliados pela equipe. identificadas e os objetivos. PRÁTICA CMMI ELEMENTO TSP Práticas Específicas SP 1.1 Definir e estabelecer objetivos de medição Script LAU, PLAN, DES e formulários TASK, WEEK, LOGT, LOGD SP 1.2 Especificar métricas Padrões de qualidade SP 1.3 Especificar coleção de dados e procedimentos de Script PLAN, formulários TASK, SUMQ, armazenamento LOGD, LOGT SP 1.4 Especificar procedimentos de análise Não endereçado OBJETIVO CMMI COMENTÁRIOS O TSP provê diversos formulários que exibem o andamento do SG 2 – Prover resultados de medição: Resultados de medições que endereçam as projeto composto pelo resultado das medições feitas até o informações necessárias identificadas e os momento. Ao final da etapa de Postmortem é produzido um relatório incluindo as principais medições feitas durante o projeto. objetivos são disponibilizados PRÁTICA CMMI ELEMENTO TSP Práticas Específicas SP 2.1 Coletar dados de medição Script PLAN, forms. LOGD e LOGT SP 2.2 Analisar dados de medição Script Postmortem, revisão do projeto SP 2.3 Armazenar dados e resultados Formulários LOGD e LOGT, SUMP SP 2.4 Comunicar os resultados Script Postmortem
4.3 Planejamento de Projetos “O objetivo do planejamento de projetos é estabelecer e manter planos que definam as atividades do projeto.” [SEI02] 113
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
A Tabela 4 exibe de forma resumida as práticas específicas da PA de Planejamento de Projetos do CMMI e seu relacionamento com os elementos do TSP [DAV03a, HUM00]. Tabela 4 - TSP X Planejamento de Projetos
PLANEJAMENTO DE PROJETOS OBJETIVO CMMI COMENTÁRIOS SG 1 – Estabelecer Estimativas: Equipes TSP documentam e rastreiam estimativas utilizando Estabelecer e manter estimativas dos processos definidos de estimativa parâmetros para o planejamento do projeto PRÁTICA CMMI ELEMENTO TSP Práticas Específicas SP 1.1 Estimar o escopo do projeto Script e formulário STRAT SP 1.2 Estabelecer estimativas de produtos de trabalho e Scripts LAU, STRAT e PLAN, forms. atributos de tarefa SUMS, TASK e SCHEDULE SP 1.3 Definir o ciclo de vida do projeto Script e formulário STRAT SP 1.4 Determinar estimativas de custo e esforço Scripts LAU, STRAT e PLAN, forms. SUMS, TASK e SCHEDULE OBJETIVO CMMI COMENTÁRIOS SG 2 – Desenvolver um plano de projeto: Um Equipes TSP utilizam a etapa de lançamento para criar e plano de projeto é estabelecido e mantido como documentar um plano com as atividades e responsabilidades base para gerenciar o projeto PRÁTICA CMMI ELEMENTO TSP Práticas Específicas SP 2.1 Definir o cronograma e o orçamento Script PLAN, forms. TASK, SCHEDULE e WEEK SP 2.2 Identificar os riscos do projeto Script STRAT e formulário ITL SP 2.3 Planejar dados para o gerenciamento Script LAU SP 2.4 Planejar os recursos para o projeto Script PLAN, forms. TASK, SCHEDULE para cada membro SP 2.5 Planejar as necessidades de conhecimentos Script LAU, formulário INFO e habilidades SP 2.6 Planejar o envolvimento dos stakeholders Não endereçada SP 2.7 Estabelecer o plano de projetos Script PLAN, formulário SUMP OBJETIVO CMMI COMENTÁRIOS SG 3 – Obter o compromisso para o plano: O membro no papel de gerente do projeto, obtém o Compromissos para o plano são estabelecidos e compromisso de todos para o projeto, porém a organização mantidos deve determinar qual será a participação e como serão feitos compromissos com pessoas externas a organização. PRÁTICA CMMI ELEMENTO TSP Práticas Específicas SP 3.1 Rever planos que afetam o projeto Script LAU, STRAT e PLAN, formulário SUMP e STRAT SP 3.2 Reconciliar diferenças entre estimativas e Script PLAN, formulários TASK e disponibilidade recursos SCHEDULE SP 3.3 Obter os compromissos para o plano Não endereçada
4.4 Monitoramento e Controle de Projetos “O objetivo do monitoramento e controle de projetos é prover o conhecimento necessário do progresso da execução do projeto que propicie a tomada de ações corretivas apropriadas quando detectados desvios significantes do planejado.” [SEI02] A Tabela 5 exibe de forma resumida as práticas específicas da PA de Monitoramento e Controle de Projetos do CMMI e seu relacionamento com os elementos do TSP [DAV03a, HUM00]. 114
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
Tabela 5 - TSP X Monitoramento e Controle de Projetos
MONITORAMENTO E CONTROLE DE PROJETOS OBJETIVO CMMI SG 1 – Monitorar o projeto através do plano: Desempenho atual e progresso do projeto são monitorados através do plano de projeto
COMENTÁRIOS As equipes TSP monitoram os resultados atuais e desempenho através dos planos periodicamente (normalmente em semanas). Membros da equipe monitoram seus planos individuais diariamente. ELEMENTO TSP
PRÁTICA CMMI Práticas Específicas SP 1.1 Monitorar os parâmetros do plano de projeto
Script PLAN, formulários SUMP, TASK e SCHEDULE SP 1.2 Monitorar os compromissos com o plano Script PLAN, formulários SUMP, TASK e SCHEDULE SP 1.3 Monitorar os riscos do projeto Formulário ITL SP 1.4 Monitorar os dados de gerenciamento Script PLAN, formulários SUMP, TASK e SCHEDULE SP 1.5 Monitorar o envolvimento dos stakeholders Não endereçada SP 1.6 Conduzir revisões de progresso do projeto Especificação de papéis, Script PLAN, forms. SUMP, TASK e SCHEDULE SP 1.7 Conduzir revisões nos Milestones (marcos do projeto) Especificação de papéis, Script PLAN, formulários SUMP, SUMQ, SUMS, TASK e SCHEDULE OBJETIVO CMMI COMENTÁRIOS As equipes do TSP fazem pequenos ajustes aos planos SG 2 – Gerenciar ações corretivas: Ações corretivas são gerenciadas para serem periodicamente (normalmente semanas) para minimizar os desvios entre os resultados atuais e o planejado. Quando o aplicadas quando o desempenho ou os resultados do projeto desvia significantemente desvio é significativo, as equipes relançam o projeto para replanejar seu trabalho. do planejado PRÁTICA CMMI ELEMENTO TSP Práticas Específicas SP 2.1 Avaliar cada assunto (Coletar e analisar cada assunto Especificação de papéis, Script PLAN, para determinar a ação corretiva apropriada a tomar) forms. SUMP, TASK e SCHEDULE SP 2.2 Tomar ações corretivas Script PLAN SP 1.3 Gerenciar as ações corretivas (analisar resultados das Especificação de papéis, reuniões ações corretivas para determinar a efetividade na periódicas de revisão, Postmortem correção do problema)
5. COTS Segundo a definição de Pressman [PRE02], COTS “são componentes comprados de terceiros, prontos para uso no projeto atual e plenamente válidos”. A montagem de sistemas baseados em COTS atende uma alternativa específica do desenvolvimento de software e permite que este trabalho aborde métodos para todas as áreas do CMMI. Este trabalho adotou para estudos o APCS (Assembly Process for COTS-Based Systems), descrito pelo SEI/CMU [CAR03]. No mais alto nível o APCS é um processo em espiral contendo uma série de iterações, cada qual com forma e atividades similares. Além das atividades iterativas para desenvolvimento do software o APCS apóia-se sobre outros dois grupos de atividades de extrema importância para o sucesso do processo:
115
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
•
organizacionais (pervasive): são atividades que tendem em longo prazo e estão no escopo da organização;
•
executivas (executive): são atividades dirigidas a eventos e estão direcionadas à tomada de decisões.
As atividades iterativas começam com planejamento, seguidas de um período de exploração, montagem de um protótipo executável e finalmente a avaliação do sistema como parte da preparação para a próxima iteração. Está implícito que a duração de cada iteração geralmente é breve devido à “rápida prototipagem” e que as iterações ocorrem até que o sistema esteja construído e aceitável para deployment [CAR03]. 5.1 COTS X CMMI “O objetivo da Gerência de Acordos com Fornecedores é gerenciar a aquisição de produtos de fornecedores para que exista um acordo formal.” [SEI02] A Tabela 6 apresenta graficamente a aderência de um processo COTS ao CMMI. Tabela 6 - COTS X CMMI
GERÊNCIA DE ACORDOS COM FORNECEDORES OBJETIVO CMMI SG 1 – Estabelecer acordos com fornecedores: Acordos com fornecedores são estabelecidos e mantidos PRÁTICA CMMI Práticas Específicas SP 1.1 Determinar tipo de aquisição
COMENTÁRIOS O auxilio do fornecedor será um diferencial positivo na construção do sistema e isto pode ser garantido através de bons acordos com fornecedores. COTS
Uma vez definida a estratégia de utilizar COTS o tipo de aquisição já está definido. SP 1.2 Selecionar fornecedores Uma vez decidido que a funcionalidade será atendida por um COTS, deve-se selecionar dentre os fornecedores que implementam a funcionalidade desejada. SP 1.3 Estabelecer acordos com fornecedore Um acordo formal é necessário quando um COTS é adquirido. OBJETIVO CMMI COMENTÁRIOS SG 2 – Satisfazer acordos com fornecedores: Além de estabelecer acordos com fornecedores é crucial Acordos com fornecedores são satisfeitos pelo para o sucesso do projeto baseado em COTS que os fornecedor e pelos responsáveis pelo projeto compromissos estabelecidos nos acordos sejam cumpridos por ambos os lados. PRÁTICA CMMI COTS Práticas Específicas SP 2.1 Rever produtos COTS A construção do protótipo permite que os produtos COTS sejam revisados para identificar se atendem o que está descrito nos acordos de aquisição firmados. SP 2.2 Executar os acordos com Não endereçada fornecedores SP 2.3 Aceitar os produtos adquiridos Até a etapa de avaliação os produtos já passaram pela revisão, testes e auditorias pertinentes ao processo de desenvolvimento de software provendo para esta fase argumentos suficientes para aprovar ou reprovar o produto. SP 2.4 Transição de produtos Cada ciclo do processo inicia com uma fase de planejamento para garantir que a integração de cada COTS ao projeto será eficiente e tranqüila.
116
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
6. Aplicação de conceitos de melhoria de processos A TDS Sistemas de Informação LTDA (www.tds.com.br) é uma pequena empresa de desenvolvimento de software. Fundada em 1993 e instalada em Bento Gonçalves, RS. A partir do ano 2000 a TDS concentrou seus esforços na construção de um único produto (software de gestão empresarial) para oferecer aos seus clientes. Desde então, os projetos desenvolvidos pela empresa estão focados em adicionar novas funcionalidades e criar novas versões deste produto. Os clientes da TDS são, em sua maioria, pequenas e médias empresas e a equipe da TDS, atualmente, é composta por 8 membros. A quase totalidade dos projetos da TDS era concluída com sucesso, porém não eram raros os casos em que houvesse atrasos no cronograma, ou que demandassem mais recursos que os previstos para que o cronograma fosse cumprido; gerando, assim, prejuízos que sempre foram absorvidos pela empresa. A oportunidade para aplicação dos conceitos de melhoria de processo surgiu durante o desenvolvimento de um trabalho de final de curso graduação [DAL04] e seguiu os conceitos e métodos apresentados neste artigo. Dentre os métodos aplicados, destacam-se: •
aumento do detalhamento dos requisitos do projeto antes do início da implementação para diminuir ambigüidades;
•
coleta dos tempos gastos nas atividades desenvolvidas e utilização destes dados como embasamento para estimar prazos nos novos projetos;
•
utilização de métricas confiáveis para o entendimento das causas que provocavam as principais falhas nos projetos;
•
uso de milestones para avaliar produtos de trabalho e detectar erros e desvios do plano de projeto antes que este chegue ao final.
A TDS está aplicando melhorias gradativamente, no entanto já é possível notar uma reação positiva em relação às mudanças já implantadas.
7. Considerações Finais A primeira constatação é que, mesmo não cobrindo todas as áreas de processo do CMMI, a aderência do TSP ao modelo do SEI/CMU é suficientemente alta para ser utilizado para acelerar processos de melhoria de processo baseadas no CMMI. Disciplina, treinamento e comprometimento (da alta gerência e dos membros da equipe). Estes três fatores são fundamentais para o processo de melhoria e principalmente para que a metodologia TSP seja usada corretamente e com sucesso pela organização que à escolheu. Tanto o CMMI como o TSP guiam somente o processo da organização. Este aspecto permite a utilização, sem restrições, de conceitos que estão em destaque como UML ou PMBOK. Por outro lado, a falta de uma ferramenta que auxiliem os membros da equipe na coleta e compilação dos dados torna-o de difícil aplicação como está proposto. Embora Humphrey proponha uma ferramenta em [HUM00], a falta de recursos computacionais nesta ferramenta dificulta sua utilização por equipes com membros geograficamente distribuídos, por exemplo, desenvolvedores localizados em cidades diferentes. 117
VI Simpósio Internacional de Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004 www.simpros.com.br
Por fim, é inegável a importância das abordagens como o TSP para que o desenvolvimento de software abandone a imagem “artesanal” e seja considerada uma atividade com embasamento científico capaz de produzir produtos de qualidade comprovada de modo eficaz como o fazem outras ciências tais como a engenharia, nas suas mais variadas áreas, a medicina, o direito e outras ciências.
Referências [BAR02] BARTIÉ, Alexandre. Garantia da qualidade de software: adquirindo maturidade organizacional. Rio de Janeiro, Elsevier, 2002. [CAR03] CARNEY, David J.; OBERNDORF, Patricia A.; PLACE, Patrick R.H. A Basis for an Assembly Process for COTS-Based Systems (COTS), Software Engineering Institute, CMU/SEI-2003-TR-010, Maio 2003. [DAL04] DALL’AGNOL, Samuel, Métodos de Desenvolvimento de Software para os Processos do Nível 2 do CMMI: Proposta de Framework, Unisinos, Julho 2004. [DAV00] DAVIS, Noopur; MCHALE, James, The TSP At Any CMM Level, Software Engineering Institute, 2000. [DAV03] DAVIS, Noopur; MULLANEY, Julia, The Team Software Process (TSP) in Practice: A Summary of Recent Results, Software Engineering Institute, CMU/SEI-2003-TR-014, Março 2003. [DAV03a] DAVIS, Noopur; MCHALE Jim, Relating the Team Software Process (TSP) to the Capability Maturity Model for Software (SW-CMM), Software Engineering Institute, CMU/SEI-2002-TR008, Março 2003. [GIL91]
GIL, Antônio Carlos, Como elaborar projetos de pesquisa, 3ª ed. São Paulo: Atlas, 1991.
[HUM97] HUMPHREY, Watts S., Introduction to the Personal Software Process, Addison Wesley Longman, 1997. [HUM00] HUMPHREY, Watts S., Introduction to the Team Software Process, Addison Wesley Longman, 2000. [JAL99]
JALOTE, P. CMM in practice: processes for executing software projects at Infosys, Addison Wesley Longman, 1999.
[NAV03] NAVAIR News Release ECL200301101, “AV-8B JSSA Team Soars to Level 4,” Naval Air Systems Command, Naval Air Warfare Center, Weapons Division, China Lake, CA, 10 de Janeiro de 2003. [PRE02]
PRESSMAN, Roger S., Engenharia de software, 5ª ed., McGraw-Hill, 2002.
[SEI02]
CMMI for Software Engineering, Version 1.1, Staged Representation Software Engineering Institute, CMU/SEI-2002-TR-029, 2002.
[SEI04]
Process Maturity Profile, Software Engineering Institute, Março 2004.
[SOM03] SOMMERVILLE, Ian, Engenharia de software, 6ª ed., Addison Wesley, 2003. 118
