Embed Size (px)
Citation preview
PROPOSTA DE METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE BASEADA EM RUP E SCRUM
Eduardo Finzi1
William Chaves de Souza Carvalho2
Resumo
Esse artigo tem como objetivo realizar uma análise do processo tradicional de
desenvolvimento de software, RUP, e do processo ágil SCRUM. Será apresentado também
um framework híbrido de desenvolvimento baseado no RUP e SCRUM. Tendo em vista os
problemas enfrentados pelas fábricas de desenvolvimento de software, o intuito do artigo é
expor uma nova metodologia de desenvolvimento que minimize os problemas enfrentados
pela gestão de projetos de TI. O artigo apresenta, em sua seção de analise de dados,
resultados de comparações de indicadores de projetos, em que o framework foi aplicado e
onde não houve aplicação. Nesses resultados, a aplicação do framework na empresa
pesquisada gerou uma melhora de 54,6% no indicador de atraso de projetos. Após a
utilização do framework, o percentual de atraso que era de 32% caiu para 14,5%.
Palavras chave: RUP, Scrum, Processos, Indicadores.
1 Aluno do curso de Especialização em Gestão em Tecnologia da Informação , Turma VI, 2010
2 Professor orientador: William Chaves de Souza Carvalho, curso de Especialização em Gestão em
Tecnologia da Informação, Especialista
2
1. Introdução
Uma tendência cada vez mais adotada pelas empresas é a utilização de processos híbridos,
que reúnem as boas práticas de paradigmas ágeis e tradicionais, sempre alinhados com os
objetivos da empresa. E como ocorre em todas as engenharias, desde a civil até a
aeronáutica, a construção de software também deve seguir rotinas e etapas estabelecidas.
Essas rotinas correspondem aos processos de desenvolvimento de software. O objetivo
deste artigo é apresentar um framework de processo híbrido, baseado em RUP e Scrum,
adotado por uma empresa produtora de software e quantificar os resultados objetivos de sua
utilização. Para isso, realizou-se um estudo de caso numa empresa de desenvolvimento de
software utilizando dados reais de projetos desenvolvidos ao longo de 2011.
Um processo é um conjunto de ações e atividades inter-relacionadas que são realizadas
para atingir um determinado objetivo (PÁDUA FILHO, 2009), que reflete elementos da
estratégia de negócio da empresa. Para que seja útil e eficaz, o processo deve ser definido
com foco na maximização do desempenho dos parâmetros que atendam as expectativas
organizacionais, como produtividade, qualidade ou flexibilidade de mudança.
A indústria de software busca continuamente novas alternativas e processos de
desenvolvimento que minimizem os problemas encontrados na gestão de projetos. Segundo
Gartner, 70% dos projetos falham no cumprimento de cronograma, custos e metas de
qualidade e 50% são executados acima do orçamento (AZEVEDO, 2008).
Desde meados da década de 1990, os processos de desenvolvimento utilizados pelas
empresas de TI podem ser classificados em duas grandes categorias: processos
tradicionais e processos ágeis:
Processos tradicionais de desenvolvimento de software são baseados na aplicação
sistemática de princípios de Engenharia, incluindo as áreas de Qualidade e
Engenharia de Sistemas. Metodologias baseadas em processos tradicionais têm
foco no planejamento e na elaboração de arquiteturas estabilizadas. Seus principais
objetivos são previsibilidade, estabilidade e alta garantia (BOEHM, 2004). Seu
principal representante é o Rational Unified Process (RUP).
Por outro lado, os processos ágeis de desenvolvimento de software remetem ao
ressurgimento da programação como uma arte e não como um processo industrial
(BOHEM, 2004), (COCKBURN, 2000). Diferentemente dos processos tradicionais, os
métodos ágeis enfatizam a importância do planejamento adaptativo, simplicidade e
3
liberação contínua de software com valor operacional em pequenas iterações com
tempo fixado. São exemplos de métodos ágeis: XP (BECK, 2000), (BECK, 2004),
Scrum (SCHWABER, 1995), (SCHWABER, 2001), FDD (PALMER, 2002) e Lean
(POPPENDIECK, 2003).
Tanto as metodologias baseadas em processos tradicionais quanto as que se fundamentam
em métodos ágeis têm seus pontos fortes e fracos. Enquanto os métodos tradicionais têm
sido recomendados para projetos de larga escala e alto risco, o desenvolvimento ágil tem
se mostrado mais apropriado para projetos de baixo risco e curta duração (RAMSIN, 2008),
(COHEN, 2004), (AMBLER, 2007), (LEFFINGWELL, 2006).
Existem também, na literatura, propostas de abordagens híbridas que incorporam princípios
dos paradigmas ágil e tradicional. Boehm e Turner (BOEHM, 2004) se basearam em
estudos de caso e propuseram um modelo para auxiliar na escolha do paradigma a ser
utilizado em um dado projeto, com base em cinco fatores principais: tamanho do projeto,
número e perfil das pessoas da equipe, criticidade, dinamismo e cultura.
Projetos grandes e críticos podem ser prejudicados pela falta de rigor e previsibilidade do
paradigma ágil, enquanto que projetos pequenos e de baixo risco podem ter um custo e
prazo desnecessariamente elevados pela falta de simplicidade e flexibilidade inerente do
paradigma tradicional, que geralmente impõe procedimentos complexos e documentação
abrangente.
As próximas seções do artigo apresentam os conceitos fundamentais do RUP e do Scrum,
descrevem o processo híbrido proposto e documentam os resultados do estudo de caso e
validação de resultados. Por fim, a seção destinada às considerações finais contém as
conclusões do trabalho.
2. RUP (processo tradicional)
O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um
framework de desenvolvimento de software criado pela Rational Software, que atualmente é
uma divisão da IBM. Ele é resultado de técnicas e métodos de analise e projeto orientado a
objetos. A principal meta do processo é aumentar a qualidade (RATIONAL, 2001) no
desenvolvimento de software das empresas de TI que o utilizam. O RUP foi criado de
acordo com os princípios descritos nos próximos tópicos.
4
2.1. Desenvolvimento iterativo e incremental
O processo criativo de desenvolvimento de software tem por objetivo automatizar alguma
necessidade de negócio. Essa necessidade independe de complexidade. Quanto mais
complexa é a necessidade do negócio, maior será o tempo necessário para o
desenvolvimento de sua automação. Como o prazo para a construção da solução pode
demorar meses ou anos, requisitos de negócio podem ser alterados nesse período.
O gap entre o tempo de desenvolvimento e as alterações dos requisitos de negócio diminui
o percentual de probabilidade de sucesso da automação e, consequentemente, diminui a
aderência da solução às necessidades do usuário. Esses gaps são encontrados em projetos
de longo prazo desenvolvidos utilizando o modelo cascata.
“Dado os atuais sistemas sofisticados de software, não é possível, sequencialmente, primeiro
definir todo o problema, projetar toda a solução, construir o software e, em seguida, testar o
produto no final. Em uma abordagem iterativa, é necessário maior compreensão do problema
através de refinamentos sucessivos, e gradativos, construindo uma solução eficaz em várias
iterações. O Rational Unified Process suporta uma abordagem iterativa para o
desenvolvimento que atende os itens de maior risco em todas as fases do ciclo de vida,
reduzindo significativamente o perfil de um projeto de risco. Essa abordagem iterativa ajuda
a atacar o risco através de demonstrações frequentes dos progressos, entrega de executáveis
que permitem a participação do usuário final e contínuo feedback. Como cada iteração termina
com uma versão executável, a equipe de desenvolvimento se mantém focada em produzir
resultados, e status reports frequentes ajudam a garantir que o projeto permaneça dentro do
cronograma. Uma abordagem iterativa também torna mais fácil para acomodar as mudanças
em requisitos, funcionalidades ou cronograma (PROCESS, 2001).”
2.2. Orientado a casos de uso
De acordo com Ivan Jacobson, caso de uso é um documento narrativo que descreve a
sequência de eventos de um ator que usa um sistema para completar um processo
(RATIONAL, 2001). O RUP é orientado a casos de uso, pois todas suas disciplinas do
processo de desenvolvimento: tais como analise e projeto; implementação; teste utilizam os
casos de uso como base.
2.3. Centrado na arquitetura
A arquitetura de um software pode ser comparada a arquitetura de uma construção civil.
Enquanto em uma residência temos os cômodos da casa com utilidades diferentes, em uma
5
aplicação temos componentes responsáveis por realizar funcionalidades diferentes. Tanto
uma casa, quanto um software necessitam de uma arquitetura estável para que mudanças
possam se realizadas sem afetarem grandes problemas. O RUP foca na produção da
arquitetura básica nas primeiras iterações. A arquitetura do sistema deve ser estabilizada ao
final da fase de elaboração e servira de alicerce para o desenvolvimento restante.
2.4. Fases e Disciplinas
O ciclo de vida do RUP é dividido nas seguintes fases:
Quadro 1 - Fases e Marcos do Ciclo de Vida RUP
FASE MARCO
Iniciação Objetivos do ciclo de vida: Inicio do projeto
Elaboração Arquitetura do ciclo de vida: Estabilização
Construção Capacidade operacional inicial: Desenvolvimento da solução
Transição Lançamento do produto: Entrega da solução
Fonte: (RATIONAL, 2001)
As atividades do processo RUP são agrupadas em nove disciplinas: Modelagem de negócio,
Requisitos, Análise e Projeto, Implementação, Teste, Implantação, Gerenciamento de
Configuração e Mudança, Gestão de Projeto e Ambiente.
As empresas que utilizam este framework geralmente o customizam a fim de aumentar a
qualidade e produtividade no desenvolvimento de software, sem muita rigidez. Para se obter
o melhor resultado na utilização do processo customizado, são necessários estudos
referentes a necessidade da empresa e provas de conceito para aplicação e
acompanhamento dos resultados.
A figura a seguir ilustra a inter-relação das fases e disciplinas de acordo com o preconizado
pelo RUP:
O eixo horizontal representa as Fases, ou seja, o tempo. Ele mostra os aspectos do
ciclo de vida do processo.
O eixo vertical representa as disciplinas.
Figura 1 - Fases e Disciplinas do RUP
6
Fonte: (POLLYSOFT, 2009)
Na próxima seção, será descrito o framework de desenvolvimento ágil Scrum.
3. SCRUM (processo ágil)
Scrum é um framework focado em práticas de gestão para desenvolvimento ágil de
software. O framework Scrum utiliza um conjunto de Scrum teams, profissionais, time-boxes
(eventos com tempo fixado), artefatos e regras. Ele organiza o desenvolvimento de software
em iterações de 2 a 4 semanas chamadas Sprints.
Schwaber e Sutherland definem que Scrum teams são concebidos para otimizar flexibilidade
e produtividade. Para esta finalidade, eles são auto-organizáveis, multifuncionais e
trabalham em iterações. Cada Scrum teams utiliza profissionais de três papéis distintos:
ScrumMaster: responsável por assegurar que o processo seja e seguido;
Product Owner, responsável por maximizar o valor do trabalho realizado; e
Equipe (Team) formada por desenvolvedores que possuem as habilidades
necessárias para transformar os requisitos do Product Owner em funcionalidades.
Uma visão pictórica do fluxo do ciclo de vida da construção de software baseado em Scrum
é mostrada na Figura a seguir.
Figura 2 - Scrum - fluxo de construção
7
Fonte: (DADOSWEB, 2012)
Quatro principais artefatos são empregados pelo Scrum. O Product Backlog é uma lista
priorizada de tudo o que se necessita para o produto. O Sprint Backlog é uma lista de
tarefas para transformar o Product Backlog de uma Sprint em um incremento de produto
potencialmente liberável (release parcial) (SCHWABER, 2011).
O Release Burndown mede o Product Backlog realizado e não realizado no tempo, para um
planejamento de release. Um Sprint Burndown mede o Sprint Backlog realizado e não
realizado no tempo, para uma Sprint (SCHWABER, 2011)..
Regras vinculam time-boxes, papéis e artefatos. Um exemplo de regra é que apenas
membros da Equipe (Team) – as pessoas comprometidas em converter o Product Backlog
em um incremento – podem falar durante uma reunião Daily Scrum.
3.1. Time Scrum
O time Scrum é composto pelo Product Owner, Time de desenvolvimento e o Scrum Master.
O Product Owner é o dono do produto. Ele é responsável por maximizar o retorno do
produto e gerenciar o artefato Product Backlog.
O Time de desenvolvimento é responsável em transformar os requisitos do Product Backlog
em funcionalidades do produto ao final de uma Sprint. O time é responsável por gerenciar
suas próprias atividades. No framework Scrum não existe um Gestor de Projeto responsável
por gerenciar o prazo, custo e riscos do projeto. O Scrum Master é responsável por fazer
com o framework seja entendido e aplicado. Outra responsabilidade importante desse papel
é retirar os impedimentos da equipe de desenvolvimento.
8
3.2. Eventos
O Scrum possui eventos de duração definida para controlar o fluxo de desenvolvimento de
software: Sprint; Daily Scrum; Sprint Review; Sprint Retrospective; Sprint Planning Meeting;
Release Planning Meeting. Sprint é um período de 2 a 4 semanas em que a equipe de
desenvolvimento produz um incremento utilizável do produto. Toda Sprint utiliza o mesmo
framework, de forma iterativa e incremental. Ao final de cada Sprint, caso ainda existam
itens do Product Backlog a serem consumidos, outra Sprint é iniciada.
3.3. Artefatos
O Scrum possui quatro principais artefatos: Product Backlog, Sprint Backlog, Release
Burndown e Sprint Burndown. O Product Backlog é uma lista de itens priorizada contendo os
requisitos necessários para o Produto. O Sprint Backlog é uma lista de tarefas para
transformar alguns itens priorizados do Product Backlog em um incremento do produto no
final da Sprint. O Release Burndow mede a quantidade de itens realizados e não realizados
do Product Backlog em relação ao tempo. Ele é necessário para o planejamento de uma
release. O Sprint Burndown mensura a quantidade de tarefas realizadas e não realizadas do
Sprint Backlog em relação ao tempo. Ele é necessário para o planejamento de uma Sprint.
4. Framework de desenvolvimento de software proposto
Esta seção apresenta o framework híbrido proposto por uma empresa de TI de médio porte
da região do Triangulo Mineiro. Ele consolida boas práticas tanto do RUP quanto do Scrum,
e foi desenvolvido após estudos e adaptações feitas a partir destes dois processos.
A empresa na qual foi o realizado o estudo de caso atua com projetos de TI de médio a
grande porte – cerca de 8.000 hs de projeto –, e como a maioria das empresas de TI, ela
apresenta problemas clássicos de gestão de projeto: falhas de orçamento, prazo e
qualidade. Após exaustiva análise pelo profissionais, estes três parâmetros foram escolhidos
para ser alvo de pesquisas e investimentos, de forma a minimizar os problema.
No início de 2009 a empresa adotou o processo de desenvolvimento ágil Scrum. Até aquele
momento, não existia um processo formal de desenvolvimento de software definido. Os
projetos internos de curto prazo, escopo reduzido e baixa complexidade apresentaram os
resultados esperados após a implantação do Scrum.
9
Mesmo no período em que a empresa utilizava o processo Scrum, as atividades de
arquitetura eram desenvolvidas por um profissional que possuía experiência nas tecnologias
adotadas e regras de negócio. No entanto, neste período, o este papel não era formalizado.
A partir da adoção do framework híbrido, o papel de arquiteto foi formalizado e respectivas
atribuições foram bem definidas.
No entanto, observou-se que os projetos desenvolvidos para clientes externos, com prazo
de grande duração e alta complexidade, mantiveram os mesmos resultados negativos de
antes da implantação do Scrum. Com base neste cenário foi concebido um projeto de P&D
para estudo e elaboração e uma nova metodologia de desenvolvimento de software que se
alinhasse aos objetivos da empresa e reduzisse os problemas encontrados na gestão
desses projetos.
Tomando como referência o processo tradicional (RUP) e o processo ágil (Scrum), o
framework proposto possui as características citadas no quadro a seguir:
Quadro 2 – Principais características do framework híbrido
DESCRIÇÃO PROCESSO
O processo é executado em iterações e a cada iteração são
acrescentadas novas funcionalidades ao produto
SCRUM e RUP
As fases do ciclo de vida são: iniciação, construção e transição RUP
As atividades do processo são agregadas em cinco disciplinas RUP
Baseado em papéis bem definidos SCRUM e RUP
Fonte: (FINANCES, 2009)
4.1. Fases
O ciclo de vida proposto para o projeto é estruturado nas seguintes fases:
Quadro 3 - Fases e Marcos do Ciclo de Vida do framework híbrido
FASE MARCO
Iniciação Objetivos do ciclo de vida: Inicio do projeto
Construção Capacidade operacional inicial: Desenvolvimento da solução
Transição Lançamento do produto: Entrega da solução
Fonte: (FINANCES, 2009)
10
Uma visão do fluxo de desenvolvimento de um software que utiliza o framework proposto é
mostrado na figura a seguir:
Figura 3 - Visão Geral do Processo
Fonte: (FINANCES, 2009)
A fase de Iniciação esta destacada com um retângulo de cor amarela. Ela é descrita como
Fase de Concepção do Produto. Nessa etapa, o Product Owner (PO) em conjunto com os
stakeholders do projeto, elaboram a Visão do Produto e seu Product Backlog. Com base
nesses artefatos, o PO elabora o plano de retorno de investimento do projeto. Ao final dessa
fase, é feita a definição do início ou interrupção do projeto.
A fase de construção está destacada com um retângulo de cor bege. Ela é totalmente
gerenciada em termos de sprints. Em cada Sprint é feito o planejamento e execução das
atividades de desenvolvimento do software. Durante cada Sprint da fase de construção são
realizadas as atividades das disciplinas de análise e projeto, implementação e testes. As
disciplinas estão destacadas por meio de um retângulo verde.
11
A fase de transição está destacada com dois retângulos vermelhos. Essa fase é constituída
pelos macroprocessos Finalizar Sprint e Preparar Implantação. Nessa etapa do processo
são criadas as documentações do produto, tais como manual do usuário e modelo de
deployment. Além disso, os eventos de finalização da Sprint, Sprint review e Sprint
retrospective são realizadas.
4.2. Disciplinas
As atividades do processo são agrupadas em cinco disciplinas: Requisitos, Análise e
Projeto, Implementação, Teste e Implantação. As atividades de análise e projeto são
exibidas na figura 4. Neste processo, a equipe de desenvolvimento realiza as atividades de
criação e atualização dos diagramas de subsistemas, classes, comportamento e dados do
projeto. Essa atividade é realizada para cada item do Sprint Backlog priorizado pelo PO em
conjunto com os stakeholders. O arquiteto de software tem uma responsabilidade grande
nesta atividade, pois é ele quem valida se a análise e o projeto estão em conformidade com
a arquitetura da solução.
Figura 4 – Atividades da disciplina de análise e projeto
Fonte: (FINANCES, 2009)
Finalizada esta etapa, tem vez a implementação, cujo fluxo de atividades pode ser visto no
diagrama a seguir.
12
Figura 5 - Atividades da disciplina de implementação
Fonte: (FINANCES, 2009)
A implementação consiste da criação do código fonte das funcionalidades do projeto. Essa
atividade é realizada para cada item do Sprint Backlog priorizado pelo PO em conjunto com
os stakeholders. Ao final da Sprint, a equipe terá transformado os requisites do Product
Backlog em funcionalidades, que então, poderão ser testadas. O framework proposto
estabelece que as atividades de testes sejam executadas em duas etapas: projeto e
execução. O fluxo macro de trabalho das atividades de teste é mostrado a seguir.
Figura 6 - Atividades da disciplina de Teste
Fonte: (FINANCES, 2009)
A equipe de desenvolvimento é responsável por projetar os casos de testes referentes aos
itens do Product Backlog priorizados pelo PO. Após a elaboração dos casos de teste, a
equipe executa os cenários descritos diferenciando-os em testes de sistema e integração.
13
Após o produto ser aprovado nos testes, ele prossegue para a implantação, cujas atividades
são mostradas na figura abaixo:
Figura 7 - Atividades da disciplina de Implantação
Fonte: (FINANCES, 2009)
Os desenvolvedores auxiliados pelo analista de suporte prepara o modelo de implantação
da solução. Para a implantação das funcionalidades, é elaborado um manual de
deployment. Além disso, também é escrito o manual do usuário e o material de treinamento.
5. Análise de Dados
Para validar o aumento de assertividade do framework proposto, foram utilizados dados de
03 projetos, sendo 02 desses projetos desenvolvidos utilizando o Scrum e 01 projeto
desenvolvido utilizando o framework proposto nesse artigo. Os projetos se enquadram na
área de negócio Mercado Financeiro e foram selecionados com base nos seguintes critérios:
tecnologia, área de negócio, número de requisitos funcionais e esforço previsto para
conclusão do projeto. Os projetos considerados nessa analise possuem tamanho de médio
e grande porte, ou seja, mais de 10.000 horas. A tabela a seguir mostra os dados dos
projetos considerados.
Quadro 4 - Dados dos Projetos Considerados no Estudo de Caso
Projeto Tecnologia RF Framework EP Prazo Releases Recursos
P1 Java 81 Proposto 19192 13,63 7 8
14
P2 C++ 57 Scrum 12369 10,03 5 7
P3 C++ 90 Scrum 18990 13,48 7 8
Fonte: (FINANCES, 2011)
O significado dos dados da tabela acima é descrito a seguir:
Projeto: Corresponde à identificação do projeto, sendo que foram atribuídos
identificadores de P1 a P3. O nome real do projeto e a identidade do cliente foram
mantidos em sigilo.
Tecnologia: Corresponde à tecnologia na qual o projeto foi desenvolvido. Foram
considerados projetos Java e C++. Projetos desenvolvidos em tecnologias menos
expressivas não foram considerados.
RF: Corresponde à quantidade de requisitos funcionais do projeto.
Framework: Indica framework foi utilizado para o desenvolvimento do projeto.
EP: Esforço planejado: Esforço estimado para realizar o projeto.
Prazo: Prazo previsto em meses para conclusão do projeto.
Releases: Número de releases previstos durante a realização do projeto.
Recursos: Número de profissionais alocados para o projeto, incluindo o gerente.
5.1. Apresentação de resultados
Com o intuito de analisar o impacto da utilização do framework no desenvolvimento de
software, foram analisados três indicadores coletados para os projetos:
Previsto x Realizado: comparativo entre o esforço, em horas, utilizado para
desenvolver o projeto e o esforço previsto para conclusão.
Qualidade da entrega: Número de bugs encontrados em cada release incremental.
Percentual de alteração de requisitos: % de alteração de requisitos em cada release,
devido decorrentes de falhas no processo de identificação e detalhamento de
requisitos.
Quadro 5 - Dados do indicador previsto X realizado
Projeto EP ER ER - EP Atraso
P1 19192 21973 2781 1,98
P2 12369 16311 3942 3,21
P3 18990 27330 8340 5,93
Fonte: (FINANCES, 2011)
O significado dos dados da tabela acima é descrito a seguir:
15
ER: Esforço realizado: Quantidade de horas realizadas durante o projeto; e,
Atraso: Número de meses em que o projeto se atrasou.
Fonte: (AUTORIA PRÓPRIA)
Fonte: (AUTORIA PRÓPRIA)
De acordo com os gráficos acima, temos que o atraso do projeto P1, desenvolvido utilizando
o framework proposto, foi menor que o atraso dos projetos P2 e P3. O percentual de atraso
do projeto P1 ficou em 14,5%. O percentual de redução de atraso, comparando ao projeto
P2, foi de 55%. Comparando o percentual de atraso ao projeto P3, a redução foi de 67%.
Quadro 6 - Dados do indicador de numero de bugs x releases
Projeto R1 R2 R3 R4 R5 R6 R7 Total
P1 4 10 2 8 5 3 1 33
P2 9 17 12 32 37 - - 107
P3 21 31 102 92 54 43 21 364
Fonte: (FINANCES, 2011)
As colunas R1 a R7 referem-se aos bugs encontrados em cada release do projeto.
Fonte: (AUTORIA PRÓPRIA)
Fonte: (AUTORIA PRÓPRIA)
Figura 8 - Atraso real do projeto
(em meses)
Figura 9 - Percentual real de
redução
de atraso
Figura 10 – Número de bugs x
release
de atraso
Figura 11 – Total de bugs
de atraso
16
O indicador de qualidade indica significativa redução da quantidade de bugs no projeto P1,
desenvolvido com a adoção do framework, ao compará-lo com os demais projetos. A
quantidade total de bugs do projeto P1 foi 33.
Para assegurar que os ganhos com a qualidade de software não sejam perdidos, a empresa
adotou as seguintes práticas:
Auditoria dos artefatos gerados durante o processo de desenvolvimento;
Status Reports semanais do projeto contendo o relatório de bugs gerados;
Armazenamento de base histórica dos problemas encontrados;
Obrigatoriedade de realização de testes unitários durante o desenvolvimento para
diminuir o número de bugs encontrados nos testes de release.
Quadro 7 - Percentual de alteração de requisitos
Projeto R1 R2 R3 R4 R5 R6 R7 Média
P1 11% 9% 12% 8% 14% 8% 7% 10%
P2 18% 17% 21% 15% 10% - - 16%
P3 28% 21% 33% 17% 19% 21% 16% 22%
Fonte: (FINANCES, 2011)
O significado dos dados da tabela acima é descrito a seguir:
R1 a RN: Percentual de alteração dos requisitos priorizados por release;
Média: Percentual médio de alteração de requisitos do projeto;
Figura 8 - Percentual médio de alteração de requisitos por projeto
Fonte: (AUTORIA PRÓPRIA)
Os dados representados no gráfico anterior mostram que o percentual médio de alteração
de requisitos do projeto P1 é menor ao dos projeto P2 e P3, o que indica que o framework
auxiliou na diminuição da volatilidade dos requisitos. Comparando-se o percentual médio de
alteração de requisitos do projeto P1 ao projeto P2, observamos um ganho de 37,5%. O
ganho é ainda mais expressivo, 54,5%, se a comparação for feita com o projeto P3.
17
Requisitos bem detalhados, influenciam na qualidade do projeto. Analisando os indicadores
de qualidade da entrega e de percentual de alteração de requisitos, observa-se que existe
correlação entre eles. O projeto P1 apresentou melhores resultados em ambos indicadores
do que os projetos P2 e P3. Se analisarmos conjuntamente os dados dos projetos P1, P2 e
P3, apresentados na tabela a seguir, podemos elaborar algumas hipóteses.
Quadro 8 - Tecnologia x Recursos x Total de bugs
Projeto Tecnologia Recursos Total
P1 Java 8 33
P2 C++ 7 107
P3 C++ 8 364
Fonte: (FINANCES, 2011)
A tabela acima apresenta o cruzamento das informações de tecnologia adotada por projeto,
o número de profissionais por projeto e a quantidade total de bugs encontrados. Nesse
cruzamento é levantada a hipótese de que a tecnologia adotada no desenvolvimento do
software pode influenciar na qualidade do projeto.
Segundo informações do departamento de Recursos Humanos da empresa pesquisada, o
tempo necessário para contratação de um profissional especialista na tecnologia C++ é de
60 a 90 dias. Para a contratação de um profissional especialista Java, segundo o RH da
empresa, o prazo máximo para contratação é de 30 dias.Esse tempo elevado para
contratação de profissionais C ++ pode influenciar na qualidade do projeto. Devido ao
turnover de profissionais ser um risco passível ao gerenciamento de projetos, essa hipótese
fica ainda mais reforçada. Nesse contexto, para os projetos que necessitem de substituição
de profissionais C++, o número de bugs gerados pode aumentar. Esse aumento é devido ao
alto tempo de contratação e o tempo estimado para a capacitação nas regras de negócio
específicas do projeto.
Os projetos pesquisados no artigo foram alvos do cenário de substituição de profissionais:
tanto o projeto P1, desenvolvido em tecnologia Java, quanto o projeto P2, desenvolvido em
C++. O projeto P1 contou com 8 profissionais, enquanto o projeto P2 contou com 7
profissionais. Em ambos os projetos, durante seu tempo de desenvolvimento, foram feitas
substituições de 02 profissionais. As mudanças de profissionais especialista em Java no
projeto P1 favoreceram a geração dos 33 bugs do projeto, enquanto as duas mudanças de
profissionais C++ para o projeto P2 ocasionaram a geração dos 107 bugs do projeto.
18
6. Considerações Finais
O framework proposto nesse artigo apresenta uma nova abordagem para o
desenvolvimento de software. De acordo com os resultados apresentados, o projeto em que
foi adotado o framework apresentou uma melhora significativa nos indicadores de atraso e
qualidade de software.
Destaca-se a importância do papel da alta direção da empresa em suportar a inciativa da
concepção do framework de desenvolvimento, em função dos resultados positivos
apresentados nesse artigo.
Com a adoção do framework, a empresa deu ênfase maior no uso de processos de
engenharia de software, devido à utilização dos princípios do RUP na concepção do
framework. Os projetos desenvolvidos utilizando o framework SCRUM não possuíam bases
sólidas de engenharia, o que evidentemente gerou diversos problemas.
Sendo assim, o resultado imediato da utilização do framework descrito neste trabalho foi o
aumento da qualidade dos produtos desenvolvidos. Já com relação ao indicador de atraso,
com a adoção do framework, o índice estabilizou em 14,5%. Mesmo a redução tendo sido
significativa, o resultado ficou abaixo da expectativa da empresa, que era de alcançar de 5%
a 10% de atraso.
Assim, após análise dos resultados obtidos, a empresa decidiu a estudar uma evolução do
framework apresentado, acrescentando maior controle durante as fases de desenvolvimento
do projeto. Para isso, os próximos passos da evolução do framework passam pela adoção
de conceitos do PMBOK.
7. Referências Citadas
AMBLER, S. Agile Software Development at Scale. IFIP European Conference on Software
Engineering Techniques, Poznan, Poland, 2007.
AZEVEDO, Sofia. Artigo: Por que os projetos falham? 2008. Disponível em
http://www.mundopm.com.br/noticia.jsp?id=280
BECK, K. Extreme Programming Explained: Embrace Change, 2a Ed. Addison-Wesley,
2004.
19
BECK, K. Extreme Programming Explained: Embrace Change. Addison Wesley, 2000.
BOEHM, B. and TURNER, R., “Balancing Agility and Discipline: A Guide for the Perplexed”,
Addison Wesley, Boston, 2004.
COCKBURN, A. Manifesto for Agile Software Development – www.agilemanifesto.org, 2000.
COHEN, D., LINDVALL, M., COSTA, P. An introduction to agile methods, in: M.V. Zelkowitz
(Ed.), Advances in Computers, Advances in Software Engineering, vol. 62, Elsevier,
Amsterdam, 2004.
DADOSWEB, 2012. Disponível em http://www.dadosweb.com.br/scrum/.
DYBÅ, T. Improvisation in small software organizations, IEEE Software, 2000.
FINANCES, C. Framework Híbrido de Desenvolvimento de Software, 2009.
FINANCES, C. Pesquisa referente ao resultado da aplicação do Framework Híbrido de
Desenvolvimento de Software, 2011.
KARLSTRÖM, D., RUNESON, P. Integrating agile software development into stage-gate
managed Product development. Empirical Software Engineering, 2006.
LEFFINGWELL, D. Scaling Software Agility. Addison Wesley, 2006.
NERUR, S., MAHAPATRA, R., MANGALARAJ, G. Challenges of migrating to agile
methodologies, Communications of the ACM, 2005.
PÁDUA FILHO, W. P. Engenharia de Software. LTC, 2009.
PALMER, S.R., FELSING, J.M. A Practical Guide to Feature-driven Development, Prentice
Hall, Upper Saddle River, NJ, 2002.
POLLYSOFT, 2009. Disponível em http://www.pollysoft.com.br/?m=fabrica&p=rup.
POPPENDIECK, M., POPPENDIECK, T. Lean Software Development, Addison-Wesley,
Boston, 2003.
PROCESS, Rational Unified Process – Best Pratices for Software Development Teams –
TP026B, 2001.
RAMSIN R. and PAIGE, R. F., Process-Centered Review of Object Oriented Software
Development Methodologies, ACM Computing Surveys, Vol. 40, No. 1, Article 3, February
2008.
20
RATIONAL, Rational Unified Process – Visão Geral, 2001. Disponível em
http://www.wthreex.com/rup/portugues/index.htm
SCHWABER K. e SUTHERLAN J., Guia do Scrum, Scrum.org, 2011;
SCHWABER, K. and BEEDLE, M. Agile Software Development with Scrum. Prentice-Hall,
2001.
SCHWABER, K. SCRUM development process. Conference on Object Oriented Programing
Systems, Languages, and Applications, 1995.
TECHBLOG. Casos de Uso, 2001. Disponível em
http://techblog.desenvolvedores.net/2011/05/12/diagrama-de-caso-de-uso-uml/
