Utilização do TSP para a Gerência de Equipes Nível 2 do CMMI

Transcrição

1 Utilização do TSP para a Gerência de Equipes Nível 2 do CMMI Samuel Dall Agnol 1, Juliana Silva Herbert 1 1 ESICenter UNISINOS Universidade do Vale do Rio dos Sinos Av. Unisinos, 950 CEP São Leopoldo RS Brasil samuel@tds.com.br, julianah@unisinos.br 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

2 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

3 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

4 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 reportados 1 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] (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

5 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 Plano 1 Requisitos 1 Projeto 1 Implementação 1 Teste 1 Postmortem 1 Ciclo 2 - Lançamento Estratégia 2 Plano 2 Requisitos 2 Projeto 2 Implementação 2 Teste 2 Postmortem 2 Ciclo 3 - Lançamento Estratégia 3 Plano 3 Requisitos 3 Projeto 3 Implementação 3 Teste 3 Postmortem 3 Figura 1 - Estrutura e fluxo do TSP. Produto final Versão final 111

6 Tabela 1 - Formulários do TSP Formulário Abrev Formulário Abrev Requisição de alteração da configuração CCR Formulário da estratégia STRAT Relatório de posição da configuração CSR Sumário dos defeitos injetados SUMDI Informações do membro da equipe INFO Sumário dos defeitos removidos SUMDR Relatório de inspeções INS Sumário do plano SUMP Rastreabilidade dos riscos do projeto ITL Plano de qualidade SUMQ Registro de defeitos LOGD Sumário de tamanho SUMS Registros de tempos LOGT Sumário de tempo de desenvolvimento SUMT Registros de testes LOGTEST Sumário de tarefas SUMTASK Avaliação da equipe e dos pares PEER Modelo de planejamento de tarefas TASK Proposta de melhorias de processo PIP Relatório de posição semanal WEEK Modelo de planejamento cronograma SCHEDULE Tabela 2 - Scripts de processo do TSP Formulário Abrev Formulário Abrev Projeto (Design) DES Desenvolvimento dos requisitos REQ Processo de desenvolvimento do software DEV Gerenciamento de configuração de software SCM Implementação IMP Desenvolvimento da estratégia STRAT Inspeção INS Teste de sistema e integração TEST Lançamento do projeto LAU Teste unitário UT Desenvolvimento do plano PLAN Reuniões semanais WEEK Postmortem PM 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

7 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 SG 1 Alinhar atividades de medição e análise: Atividades e objetivos de medição são Na etapa de lançamento do projeto são definidos os objetivos do projeto, os dados que deverão ser coletados para avaliar o progresso do projeto e a periodicidade que estes dados serão alinhados com as informações necessárias avaliados pela equipe. identificadas e os objetivos. 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 armazenamento Script PLAN, formulários TASK, SUMQ, LOGD, LOGT SP 1.4 Especificar procedimentos de análise Não endereçado SG 2 Prover resultados de medição: O TSP provê diversos formulários que exibem o andamento do Resultados de medições que endereçam asprojeto 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 objetivos são disponibilizados relatório incluindo as principais medições feitas durante o projeto. 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

8 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 SG 1 Estabelecer Estimativas: Estabelecer e manter estimativas dos Equipes TSP documentam e rastreiam estimativas utilizando processos definidos de estimativa parâmetros para o planejamento do projeto SP 1.1 Estimar o escopo do projeto Script e formulário STRAT SP 1.2 Estabelecer estimativas de produtos de trabalho e atributos de tarefa Scripts LAU, STRAT e PLAN, forms. 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 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 comodocumentar um plano com as atividades e responsabilidades base para gerenciar o projeto 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 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 ecompromisso 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. 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 disponibilidade recursos Script PLAN, formulários TASK e 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

9 Tabela 5 - TSP X Monitoramento e Controle de Projetos MONITORAMENTO E CONTROLE DE PROJETOS SG 1 Monitorar o projeto através do plano: Desempenho atual e progresso do projeto são monitorados através do plano de projeto 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. 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 SG 2 Gerenciar ações corretivas: Ações corretivas são gerenciadas para serem aplicadas quando o desempenho ou os resultados do projeto desvia significantemente do planejado As equipes do TSP fazem pequenos ajustes aos planos periodicamente (normalmente semanas) para minimizar os desvios entre os resultados atuais e o planejado. Quando o desvio é significativo, as equipes relançam o projeto para replanejar seu trabalho. SP 2.1 Avaliar cada assunto (Coletar e analisar cada assunto para determinar a ação corretiva apropriada a tomar) Especificação de papéis, Script PLAN, 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 ações corretivas para determinar a efetividade na correção do problema) Especificação de papéis, reuniões periódicas de revisão, Postmortem 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

10 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 SG 1 Estabelecer acordos com fornecedores: Acordos com fornecedores são estabelecidos e mantidos 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 SP 1.1 Determinar tipo de aquisição 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. SG 2 Satisfazer acordos com fornecedores: Acordos com fornecedores são satisfeitos pelo fornecedor e pelos responsáveis pelo projeto Além de estabelecer acordos com fornecedores é crucial para o sucesso do projeto baseado em COTS que os compromissos estabelecidos nos acordos sejam cumpridos por ambos os lados. COTS 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

11 6. Aplicação de conceitos de melhoria de processos A TDS Sistemas de Informação LTDA ( é 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

12 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, [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 [DAL04] DALL AGNOL, Samuel, Métodos de Desenvolvimento de Software para os Processos do Nível 2 do CMMI: Proposta de Framework, Unisinos, Julho [DAV00] DAVIS, Noopur; MCHALE, James, The TSP At Any CMM Level, Software Engineering Institute, [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 [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 [GIL91] GIL, Antônio Carlos, Como elaborar projetos de pesquisa, 3ª ed. São Paulo: Atlas, [HUM97] HUMPHREY, Watts S., Introduction to the Personal Software Process, Addison Wesley Longman, [HUM00] HUMPHREY, Watts S., Introduction to the Team Software Process, Addison Wesley Longman, [JAL99] JALOTE, P. CMM in practice: processes for executing software projects at Infosys, Addison Wesley Longman, [NAV03] NAVAIR News Release ECL , 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 [PRE02] PRESSMAN, Roger S., Engenharia de software, 5ª ed., McGraw-Hill, [SEI02] CMMI for Software Engineering, Version 1.1, Staged Representation Software Engineering Institute, CMU/SEI-2002-TR-029, [SEI04] Process Maturity Profile, Software Engineering Institute, Março [SOM03] SOMMERVILLE, Ian, Engenharia de software, 6ª ed., Addison Wesley,