PROPOSTA DE METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE BASEADA EM RUP E SCRUM

Transcrição

1 PROPOSTA DE METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE BASEADA EM RUP E SCRUM Eduardo Finzi 1 William Chaves de Souza Carvalho 2 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, 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 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 2

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

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) 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 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 4

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 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 Elaboração Construção Transição Objetivos do ciclo de vida: Inicio do projeto Arquitetura do ciclo de vida: Estabilização Capacidade operacional inicial: Desenvolvimento da soluçã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 5

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 6

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

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

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 O processo é executado em iterações e a cada iteração são acrescentadas novas funcionalidades ao produto As fases do ciclo de vida são: iniciação, construção e transição As atividades do processo são agregadas em cinco disciplinas Baseado em papéis bem definidos PROCESSO SCRUM e RUP RUP RUP 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 Iniciação Construção Transição MARCO Objetivos do ciclo de vida: Inicio do projeto Capacidade operacional inicial: Desenvolvimento da solução Lançamento do produto: Entrega da solução Fonte: (FINANCES, 2009) 9

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

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

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

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

14 P2 C++ 57 Scrum , P3 C++ 90 Scrum , 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 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 P ,98 P ,21 P ,93 Fonte: (FINANCES, 2011) O significado dos dados da tabela acima é descrito a seguir: 14

15 ER: Esforço realizado: Quantidade de horas realizadas durante o projeto; e, Atraso: Número de meses em que o projeto se atrasou. Figura 8 - Atraso real do projeto (em meses) Figura 9 - Percentual real de redução de atraso 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 R1 R2 R3 R4 R5 R6 R7 Total Projeto P P P Fonte: (FINANCES, 2011) As colunas R1 a R7 referem-se aos bugs encontrados em cada release do projeto. Figura 10 Número de bugs x release de atraso Figura 11 Total de bugs de atraso Fonte: (AUTORIA PRÓPRIA) Fonte: (AUTORIA PRÓPRIA) 15

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

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 P3 C 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. 17

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, AZEVEDO, Sofia. Artigo: Por que os projetos falham? Disponível em BECK, K. Extreme Programming Explained: Embrace Change, 2a Ed. Addison-Wesley,

19 BECK, K. Extreme Programming Explained: Embrace Change. Addison Wesley, BOEHM, B. and TURNER, R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison Wesley, Boston, COCKBURN, A. Manifesto for Agile Software Development 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, DADOSWEB, Disponível em DYBÅ, T. Improvisation in small software organizations, IEEE Software, FINANCES, C. Framework Híbrido de Desenvolvimento de Software, FINANCES, C. Pesquisa referente ao resultado da aplicação do Framework Híbrido de Desenvolvimento de Software, KARLSTRÖM, D., RUNESON, P. Integrating agile software development into stage-gate managed Product development. Empirical Software Engineering, LEFFINGWELL, D. Scaling Software Agility. Addison Wesley, NERUR, S., MAHAPATRA, R., MANGALARAJ, G. Challenges of migrating to agile methodologies, Communications of the ACM, PÁDUA FILHO, W. P. Engenharia de Software. LTC, PALMER, S.R., FELSING, J.M. A Practical Guide to Feature-driven Development, Prentice Hall, Upper Saddle River, NJ, POLLYSOFT, Disponível em POPPENDIECK, M., POPPENDIECK, T. Lean Software Development, Addison-Wesley, Boston, PROCESS, Rational Unified Process Best Pratices for Software Development Teams TP026B, 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