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