Qualidade de software: uma análise nas metodologias ágeis Scrum e OpenUP

Transcrição

1 Qualidade de software: uma análise nas metodologias ágeis Scrum e OpenUP Giovane Montine Moreira Gurgel, Camilo de Lelis, Clarissa L. A. C. Lins giovane.gurgel@ifrn.edu.br 1, camilolelis@gmail.com 2, clarissalorena@gmail.com 3 1 Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte. Rua Raimundo Firmino de Oliveira, 400, Costa e Silva. Mossoró, RN, Brasil 2,3 Universidade Federal do Rio Grande do Norte, Superintendência de Informática, Natal, RN, Brasil Abstract. This paper analyzes the factors of software quality from the agile methods Scrum and OpenUP. The traditional development methodologies promotes the outdated definition of quality. To better respond to changes and seek to add value to products, agile methods are adept at showing the most current concept of quality - noun. The analysis of the scrum from the quality factors proposed by Mnkandla (2006) showed that the scrum does not establish how the quality should be made, but the constant monitoring and transparency between the team and the customer provide good quality standards. By analyzing OpenUP, was identified that collaboration, the focus in setting and managing change, the concern to identify and mitigate risks and the customer's feedback are consistent with that proposed by Mnkandla (2006). Although some factors are not as clear for some agile methodologies, we find that they usually have good results and are being enhanced with other ISO standards of quality. Keywords: Agile methodologies, software quality l. INTRODUÇÃO Visualizando o cenário atual das metodologias, pode-se destacar que as organizações trabalham em forma ágil. Isso devido os projetos estarem cada vez mais dinâmicos, com requisitos passíveis de alterações e datas de entrega do software curta. O foco das metodologias ágeis baseia-se em pessoas e não em processos e planejamento. Atualmente, as equipes de desenvolvimento de software têm focado na qualidade do produto exigido pelo cliente. Nesse sentido, cada vez mais as organizações buscam um aprimoramento nos seus processos para atender ao desejado dentro do prazo e custo estimado para o projeto. O objetivo deste artigo é fazer uma análise dos fatores de qualidade propostos por Mnkandla [1] no contexto das metodologias ágeis Scrum e openup.

2 2 Giovane Montine Moreira Gurgel, Camilo de Lelis, Clarissa L. A. C. Lins O embasamento teórico necessário para a realização deste trabalho é apresentado na seção 2, onde são descritas as principais características da metodologia ágil, bem como explicando os processos Scrum e OpenUP. O resultado do estudo baseado em fatores de qualidade definido por Mnkandla [1] aplicado as essas metodologias é demonstrado na seção 3. E finalmente na seção 4 são apresentadas as considerações finais. 2. METODOLOGIAS ÁGEIS Com tanta similaridade entre as metodologias, no início de 2001, dezessete pessoas experientes se reuniram para tentar achar um denominador comum. Surgiu então a aliança do desenvolvimento de software ágil. O resultado da reunião gerou a criação do Manifesto Ágil (BECK et al[2]). O movimento da metodologia ágil investigou as metodologias de desenvolvimento de software e tentou buscar uma essência para descobrir maneiras melhores de desenvolver software. Neste sentido, o manifesto estabeleceu um framework comum para processos ágeis valorizando o enfoque nas pessoas e não em processos ou algoritmos, mas reconhecendo os limites para atender sempre as mudanças e a continua colaboração dos stakeholders com mais ênfase que a negociação do contrato (BECK et al[2]). Segundo Huo et al.[3], os princípios ágeis caracterizam agilidade no processo de desenvolvimento de software e implicam a utilização de procedimentos que produzem e mantêm a melhor qualidade de código possível quando bem aplicado. A metodologia ágil propôs algumas principais técnicas como: planejamento simples, iterações curtas, feedback freqüente do cliente, geração de valor, mudanças constantes de requisitos, equipes pequenas e médias auto-organizáveis. A seguir são apresentadas as principais características e as práticas das metodologias ágeis Scrum e OpenUP. 2.1 SCRUM O processo de desenvolvimento de software baseado em Scrum possui características descritas no manifesto ágil (BECK et al.[2]), tais como interações entre indivíduos, colaborações com o cliente, valorizando o funcionamento do software e se esse atende às necessidades do cliente. Schwaber [4] não considera Scrum como um processo onde todos os passos são bem definidos. O Scrum proporciona um conjunto de práticas que permitem acompanhar e não prever tudo que está acontecendo. Tem foco na gerência de projetos. O Scrum é baseado em três princípios: a transparência garante a visibilidade de informações necessárias a quem está gerenciando os resultados, o ato de inspecionar o processo com a freqüência necessária para identificar variações inaceitáveis e a adaptação é importante para detectar problemas no processo, o ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores (SCHWABER; SUTHERLAND[5]).

3 Qualidade de software: uma análise nas metodologias ágeis Scrum e OpenUP 3 Ao fim de cada iteração, o produto ganha novas funcionalidades (Figura 1). As adaptações são feitas ao longo da inspeção diária, cada componente do time de desenvolvimento podem inspecionar o outro e ajudar a fazer a adaptação necessária. O framework Scrum consiste em times que possuem vários papéis, as iterações são eventos com duração fixa time-boxes, artefatos também são gerados de acordo com algumas regras. Figura 1. Estrutura básica do Scrum (Fonte: SCHWABER[4]) O Scrum utiliza quatro artefatos principais (SCHWABER; SUTHERLAND[5]): Backlog do produto: lista de requisitos que são necessários no produto. É dinâmico, ou seja, está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. Enquanto existir o produto, o backlog do produto também existirá; Backlog da Sprint: lista de tarefas que representa um incremento potencialmente entregável do produto; Burndown de release: gráfico indicando os avanços realizados na release. Mede o backlog do produto restante ao longo do tempo de um plano de release; Burndown de sprint: gráfico indicando os avanços realizados no Sprint. Mede os itens do backlog da Sprint restantes ao longo do tempo de uma Sprint. Scrum é associado a projetos com poucas pessoas, uma vez que são poucos papéis na equipe e as fases são rápidas e dinâmicas. No entanto, devido as características empíricas do Scrum, já há experiências e adaptações podem ser testadas para grandes equipes (LARMAN; VODDE[6]). As equipes Scrum possuem três papéis: Mestre do Scrum (ScrumMaster): garante que o processo seja compreendido e seguido. Auxilia os clientes na definição de quem seria o Product Owner. Na verdade, o ScrumMaster ensina o Product Owner como trabalhar; Product Owner: é uma pessoa e não um comitê. Mantém os requisitos do produto (Backlog), garantindo o valor do trabalho realizado pela equipe. Assim, todos sabem o que tem maior prioridade do que se deve trabalhar; Time: executa o trabalho propriamente dito. O ideal é um time com sete pessoas, mais ou menos duas pessoas. Quanto menos membros na equipe, maior interação.

4 4 Giovane Montine Moreira Gurgel, Camilo de Lelis, Clarissa L. A. C. Lins Cada time é auto-organizável. A composição de cada time pode ser mudada, mas a produtividade pode ser reduzida. Cada fase no Scrum influencia a seguinte. Semelhante ao ciclo de Demming, cada iteração é avaliada antes de começar uma nova. Um incremento representa uma nova funcionalidade. Esse incremento deve estar pronto, ou seja, deve ser adicionado aos outros incrementos anteriores e ser exaustivamente testado, garantindo que todos funcionem juntos. Sutherland e Schwaber [7] consideram o Scrum diferente de outros métodos tradicionais ao observar o caráter empírico de sua abordagem. Não há nada estritamente definido, os controles existem para gerenciar a incerteza e o risco envolvido. Existem seis momentos onde ocorrem as iterações no Scrum (SCHWABER; SUTHERLAND[5]): Reunião de planejamento da release: tem como propósito estabelecer um plano de metas. Os pontos mais importantes do backlog, os principais riscos e as funcionalidades que estarão contidas no release; Reunião de planejamento da Sprint: momento onde a iteração é planejada. É fixada em oito horas de duração para uma Sprint de um mês. A duração pode variar de acordo com a Sprint. Cada reunião é dividida em duas partes de quatro horas o quê será feito na Sprint e na segunda decide-se como o time desenvolverá a funcionalidade em um incremento do produto; Sprint: é uma iteração. Durante a Sprint, o ScrumMaster deve garantir que não seja feita nenhuma mudança que possa afetar a meta da Sprint. Cada projeto possui um horizonte. Se for longo demais, a definição poderá ter mudado. Normalmente é usado um horizonte de um mês. Assim o risco pode ser controlado a cada mês. Revisão da Sprint: realizada ao final de cada Sprint. Possui duração de quatro horas. O time e as partes interessadas compartilham sobre o que produziram até o momento, quais os problemas enfrentados e o que será feito em seguida; Retrospectiva da Sprint: realizada após a revisão da Sprint e antes da próxima reunião de planejamento da Sprint. Com duração fixa de três horas, tem como propósito analisar o que aconteceu na última Sprint em se tratando das melhores práticas, das relações entre as pessoas, dos processos e das ferramentas; Reunião diária: diariamente cada time se reúne durante 15 minutos. Sempre no mesmo local e horário durante as Sprints. Cada membro explica o que realizou desde a última reunião diária, o que vai fazer antes da próxima reunião diária e quais obstáculos estão em seu caminho. 2.2 openup Projetos diferentes têm necessidades diferentes de processo. Os principais fatores que ditam o processo ser mais formal ou mais ágil são tamanho, complexidade, novidade tecnológica. Assim, Blotner [8] demonstra a evolução da disciplina Sabrix, usando características dos modelos formal e ágil, para melhor atender sua organização. O processo unificado Aberto (OpenUP) é uma versão ágil do IBM Rational Unified Process (RUP) (JACOBSON[9]), refletindo boas práticas com um processo

5 Qualidade de software: uma análise nas metodologias ágeis Scrum e OpenUP 5 Mínimo (apenas o fundamental), Completo (aborda as necessidades do projeto) e Extensível (adaptável). Preserva as características do RUP: desenvolvimento interativo e incremental, casos de uso, cenários, gerenciamento de riscos, abordagem de arquitetura centrada na unidade de desenvolvimento (BALDINO[10]). OpenUP é conforme ao manifesto ágil nos quatro princípios (quadro 1). Quadro 1. Mapeamento entre OpenUp e Manifesto Ágil Princípios OpenUP Colaborar para alinhar interesses e compartilhar conhecimento Balancear prioridades concorrentes com o retorno de valor para o Stakeholder Focar no início de arquitetura para minimizar riscos e organizar o desenvolvimento Envolver continuamente para obter feedback e melhorias Declaração do manifesto ágil Indivíduos e interações sobre Processos e ferramentas Colaboração dos clientes sobre Negociação em contratos Software funcionando sobre Extensa Documentação Respostas à mudanças sobre Seguir um plano Essa metodologia adiciona valor e práticas principalmente das metodologias XP e Scrum. Através dos papéis bem definidos, pessoas gerenciam e desenvolvem soluções colaborativas executando tarefas organizadas por disciplinas (Arquitetura, Configuração e gerencia de mudança, Desenvolvedor, Gerencia de Projeto, Requisitos e Teste), utilizando e produzindo artefatos (OpenUP[11]). A seguir, as atividades e artefatos gerados por cada um dos papéis: Stakeholder: representa um grupo de interessados, cujas necessidades devem ser satisfeitas pelo projeto; Gerente de Projeto: responsável por manter o foco da equipe na realização do projeto. Para cada projeto deve ser gerado um plano de iteração e projeto. A disciplina agrega valor para a criação de um ambiente de trabalho de alto desempenho. Uma outra característica interessante nessa metodologia é que ela é orientada a riscos e é responsabilidade do Gerente de Projeto o registro no artefato Lista de Riscos; Analista: responsável por capturar requisitos do sistema e definir prioridade de execução, gera artefatos como design, build, teste developer e implementa soluções. Durante todo o ciclo de vida a gerencia de mudanças de requisito é realizada; Arquiteto: responsável pela robustez da arquitetura do sistema, orienta a equipe no projeto e implementação e gera artefato chamado Architecture Notebook. A disciplina objetiva alcançar uma arquitetura robusta para o sistema, para isto se relaciona com outras disciplinas, como requisito e gerenciamento de projeto; Desenvolvedor: utiliza uma abordagem onde o desenvolvedor realiza testes. A disciplina transforma requisitos em design do sistema para gerar código de forma incremental. A cada iteração as tarefas evoluem para um ambiente estável;

6 6 Giovane Montine Moreira Gurgel, Camilo de Lelis, Clarissa L. A. C. Lins Testador: Responsável por criar, implementar e realizar os casos de teste, gera os artefatos caso de teste, log de teste e script de teste. A disciplina valida se o sistema construído atende aos requisitos e garante que mudanças no sistema não introduzam novos erros. A disciplina configuração e gerência de mudança contemplada em todo o ciclo são realizadas por todos da equipe de desenvolvimento. Devido sua importância e abrangência está associado a tarefas e produtos de trabalho de todas as outras disciplinas. OpenUP é estruturado em 3 camadas(figura 3). Figura 2. Camadas do openup (Fonte: openup[11]) O Ciclo de Vida do Projeto é definido no plano de projeto. Essa camada possui foco no Stakeholder, abrange a descrição das fases do projeto: iniciação, elaboração, construção e transição, e uma estimativa do desenvolvimento afetando diretamente o planejamento das iterações, além de prover diretrizes para o desenvolvimento detalhado de seu planejamento. O Ciclo de vida da Iteração é definido no plano de iteração, são planejadas em um intervalo de tempo medido em semanas, possui foco no time, ao final de cada iteração é feita uma avaliação que servirá de lições aprendidas e é habilitado um demo ou build. O Micro Incremento se refere a atividades que são definidas no artefato Item de trabalho, essas atividades representam um curto espaço de trabalho que produz um ritmo constante e mensurável do progresso do projeto, normalmente é medido em horas ou poucos dias e tem foco individual. A metodologia centra-se na redução significativa do risco no início do projeto, demandando reuniões regulares e aplicação rigorosa da estratégia de mitigação. Uma

7 Qualidade de software: uma análise nas metodologias ágeis Scrum e OpenUP 7 abordagem iterativa e incremental (evolucionista), realizada em uma maneira altamente colaborativa com "apenas o suficiente" produz software de alta qualidade satisfazendo as necessidades dos seus stakeholders (FOWLER[12]). 3. QUALIDADE EM METODOLOGIAS ÁGEIS A Qualidade tem experimentado mudanças em sua literatura. A primeira onda se destaca pelas questões cartesianas, com foco na inspeção, controle estatístico, a racionalidade no planejamento da produção foi então amplamente difundida. A segunda onda teve foco no processo. A qualidade adjetiva buscava adequar o processo a padrões e a partir disso surgiu a qualidade total. A terceira onda qualidade substantiva consiste em despertar a confiança e superar as necessidades e expectativas do cliente, a excelência é a busca pela qualidade. No processo de desenvolvimento de software, o avanço no conceito de qualidade segue um padrão semelhante ao que vem sendo aplicado nas linhas de produção das indústrias convencionais (MNKANDLA[1]). A linha de produção do software é bem representada na metodologia de desenvolvimento em cascata waterfall. O software é obtido após vários estágios (HUO et al.[3]). Nesse sentido, a segunda onda da qualidade pode ser empregada ao desenvolvimento de software; o foco no processo ainda é priorizado em praticamente todas as metodologias. Vários mitos da qualidade de software apontados por Voas [13] apontam nesse sentido, por exemplo, a maturidade do processo de desenvolvimento. Vale ressaltar que o software não é um produto convencional, gerado em uma linha de produção, é um processo criativo. Diferente das convencionais, as metodologias ágeis respondem melhor às mudanças que ocorrem no desenvolvimento de software. Com uma maior flexibilidade, pequenos ciclos, o desenvolvimento ágil vem se mostrando uma alternativa que pode reduzir o alto custo da mudança nas metodologias convencionais (AGUANNO[14]). Highsmith[15] considera que a qualidade intrínseca em software é muitas vezes associada ao atendimento de prazos, escopo e custo. Entende a importância da adaptabilidade uma vez que o software deve atender às necessidades dos usuários. Os valores propostos no manifesto ágil podem sugerir a presença da terceira onda da qualidade, uma vez que há uma maior preocupação em atender não só os requisitos dos usuários, o valor que o software representa é muito relevante. É preciso ressaltar que a qualidade em métodos ágeis ainda passa por dificuldades de definição, mas é reconhecido que existe e traz bons resultados (MNKANDLA[1]). Nesse contexto, Mnkandla[1] relacionaram práticas da metodologia ágil em fatores de qualidade estabelecidos na literatura. Dessa forma, metodologias ágeis podem ser analisadas a partir desses fatores identificados. Como as práticas variam a cada metodologia, alguns fatores não são definitivos em sua concepção, ou seja, fatores de qualidade podem ser atingidos por caminhos distintos. A seguir a lista dos fatores de qualidade para as metodologias ágeis:

8 8 Giovane Montine Moreira Gurgel, Camilo de Lelis, Clarissa L. A. C. Lins Compatibilidade: a prática de orientação a objetos favorece a construção do software a partir de partes menores. A metodologia ágil promove esse fator a partir de um projeto independente de plataforma; Corretude: uma das características da prática ágil é a aplicação de padrões no desenvolvimento (HUO et al.[3]). Significa fazer certo logo no começo. Nesse sentido, as iterações curtas e rápidas permitem ao cliente aprovar ou não as alterações; Efetividade de Custo: a metodologia ágil permite um maior controle do escopo do projeto uma vez que suas fases são curtas e com isso há uma maior atenção no atendimento dos requisitos e se o custo está se tornando maior do que o desejado; Eficiência: a aplicação de boas práticas de programação e algoritmos que sejam mais eficientes. Nesse sentido, a programação em pares e a comunicação freqüente sugerem uma codificação que irá otimizar os recursos de hardware, comunicação, etc.; Extensibilidade: um software deve ser de fácil adaptação a novas funcionalidades. As metodologias ágeis utilizam pouca documentação formal, justamente por considerar os requisitos dinâmicos; Facilidade de uso: como o cliente está presente em muitas fases do processo de desenvolvimento, o software produzido será amigável ao usuário final. Facilitando o processo de aprendizagem de uso do software; Integridade: integridade deve ser garantida tanto na operação do sistema quanto no seu desenvolvimento; Manutenibilidade: o projeto orientado a objetos favorece a correção de erros e o atendimento a novas funcionalidades do software; Oportunidade: disponibilidade do software de acordo com a necessidade do usuário. Os ciclos curtos de desenvolvimento reduzem o intervalo entre a construção até a entrega do software ao usuário; Portabilidade: o projeto orientado a objetos favorece a mudança de hardware e plataformas para o mesmo software; Reusabilidade: o projeto de software orientado a objetos favorece o uso de componentes que podem ser utilizados por diferentes aplicações; Robustez: o projeto de software orientado a objetos, bem como a adoção de padrões auxiliam as aplicações a reagirem a situações não previstas; Verificação e validação: os testes são utilizados em muitas fases nas metodologias ágeis. Diversas técnicas de testes e integração constante facilitam a verificação e validação do software. 3.1 Qualidade em Scrum O Scrum possui iterações rápidas, uso de padrões de qualidade, rápida adaptação a mudanças, entre outras características. No entanto, Scrum possui ênfase no controle do projeto, não diz como fazer, apenas acompanha os resultados. Essa constante verificação/validação no Scrum é o que representa a dimensão da qualidade (HIGHSMITH[15])

9 Qualidade de software: uma análise nas metodologias ágeis Scrum e OpenUP 9 Embora o Scrum não seja explícito como proceder para garantir a qualidade, o compartilhamento de informações ao longo de todo o processo favorece a adoção de boas práticas e da constante verificação se os incrementos estão atendendo às necessidades do cliente como constatado por Hansen e Baggesen [16]. A definição de pronto também resulta em uma etapa de qualidade, pois os incrementos devem ser testados e deve funcionar com todas as outras funcionalidades já implementadas. A seguir, os fatores de qualidade em métodos ágeis (MNKANDLA[1]) aplicados ao Scrum: Compatibilidade: cada incremento deve ser testado com tudo que já foi concluído. Nesse sentido, iterações rápidas e o desenvolvimento em pequenos times favorecem a criação de componentes compatíveis; Corretude: uso de boas práticas desde o começo. O cliente sempre está presente, verificando se o andamento está de acordo com os requisitos declarados no backlog. Exemplo: verificações realizadas nas reuniões de revisão entre os sprints; Efetividade de Custo: gráficos burndown auxiliam o acompanhamento dos gastos ao longo do tempo do projeto; Eficiência: o compartilhamento contínuo de informações entre os membros da equipe favorecem o uso de artefatos que irão otimizar os recursos de hardware e software; Extensibilidade: na reunião de release, os objetivos são traçados e caso tenha surgido algum novo item no backlog, as prioridades são alteradas e o escopo do sprint redefinido; Facilidade de uso: apesar da interação constante com o cliente, a metodologia Scrum não se mostra muito adequada para lidar com requisitos de usabilidade. Dessa forma, Singh [17] apresenta a metodologia Scrum adaptada para tratar a usabilidade; Integridade: a cada reunião de planejamento cada integrante do time compartilha as lições aprendidas de sucesso ou não. Seguindo a característica empírica do Scrum, o grupo adota novas práticas ao longo do processo; Manutenibilidade: à medida que há uma interação maior da equipe em cada Sprint, os erros são detectados rapidamente, assim como é possível projetar software com maior atenção a integração modularidade; Oportunidade: ao final de cada sprint é realizada a entrega de uma funcionalidade do produto. À medida que ocorrem os sprints, a lista do backlog é reduzida e pode ser modificada a prioridade da lista de acordo com as necessidades do cliente; Portabilidade: o Scrum adota padrões em todas as fases de desenvolvimento do produto, isso permite a criação de arquiteturas independentes de hardware; Reusabilidade: a integração de componentes é facilitada a partir da larga comunicação no time. As práticas desenvolvidas durante um sprint podem ser utilizadas nas próximas iterações a partir das reuniões diárias, revisão e de retrospectiva; Robustez: enquanto o produto existir, o backlog também existirá. O dono do produto acompanha a execução de todas as iterações e sempre oferece feedback sobre o atendimento dos requisitos. Situações não previstas são tratadas rapidamente;

10 10 Giovane Montine Moreira Gurgel, Camilo de Lelis, Clarissa L. A. C. Lins Verificação e validação: reuniões diárias permitem conferir o andamento do trabalho realizado por cada integrante do time. Como cada iteração significa um entregável ao cliente, o produto é verificado, validado e testado constantemente. 3.2 Qualidade em openup OpenUP tem reuniões diárias, iterações são planejadas, projetadas, implementadas e testadas em pequenos incrementos. Estas características em conjunto com mitigação de risco e a forte ênfase na colaboração, nas pessoas que fazem acontecer e entendem a real necessidade das solicitações de mudança dos clientes para gerar valor é que proporcionam garantia de qualidade (HUO et al.[3]). Os principais fatores de qualidade (MNKANDLA[1]) aplicados as atividades adotadas em certa medida no ciclo de desenvolvimento desta metodologia: Compatibilidade: a prática arquitetura evolucionária analisa as principais preocupações técnicas que afetam a arquitetura visando à independência de plataforma. Através da prática integração contínua, os problemas de integração são identificados mais cedo; Corretude: por ser um processo iterativo e incremental, consegue garantir correção e mudança ao longo do projeto devido à participação do cliente e entrega curta de build ou demo. Essas entregas são ajustadas e aprovadas para satisfazer os desejos e aspirações do cliente, atendendo a terceira onda da qualidade; Efetividade de Custo: consegue garantir a relação custo-eficácia, pois existe um controle de atividades que é feito por iteração através do artefato Lista de Itens de trabalho; Eficiência: Colaboração e compartilhamento de conhecimento é uma prática adotada pelo OpenUp através de suas iterações, como por exemplo, refinar os objetivos do plano de iteração para otimizar os recursos; Extensibilidade: Os incrementos realizados com feedback extremamente curto conduz as decisões de adaptação em cada iteração; Facilidade de uso: casos de uso são desenvolvidos colaborativamente com feedback do cliente ao longo do projeto, proporcionando ajustes para adequar a usabilidade; Integridade: O gerente de projeto trabalha em conjunto com toda a equipe a fim de identificar a alta prioridade de resolver os itens de trabalho da lista de itens. O plano de iteração anterior incluir uma avaliação dos resultados e também pode ser usado como entrada para o planejamento da iteração atual. No âmbito deste processo, o gerenciamento de configurações mantém as versões de artefatos e configurações consistentes; Manutenibilidade: Gerenciamento de mudança fornece dados para medir o progresso e proporciona um meio eficaz para se adaptar as mudanças e problemas. As versões de todo trabalho são mantidas atualizadas e as alterações são geridas por tarefas de solicitação de mudança que são posteriormente priorizadas em uma lista de itens de trabalho; Oportunidade: atende este fator por realizar desenvolvimento iterativo e incremental, permitindo entrega rápida e realizando curtos ciclos;

11 Qualidade de software: uma análise nas metodologias ágeis Scrum e OpenUP 11 Portabilidade: o uso de padrões de desenvolvimento praticado no mercado separa o software em camadas permitindo a independência e autonomia de hardware e software nesta metodologia; Reusabilidade: com o apoio de documentação adequada é possível fazer o reuso de código e adaptar de forma simples a diferentes processos e aplicações, reduzindo o tempo de desenvolvimento e garantindo este fator de qualidade; Robustez: Ao longo das iterações a disciplina arquitetura se relaciona com outras disciplinas, como requisitos ao obter arquitetura significativa, testes ao verificar a estabilidade e corretude, entre outras, para alcançar uma arquitetura robusta para o sistema; Verificação e validação: Testadores são responsáveis por realizar testes de funcionalidade, usabilidade, confiança, performance e suportabilidade várias vezes por iteração, cada vez que a solução é incrementada com o desenvolvimento de algo novo, mudança ou correção de erro, no sentido de retirar os riscos mais cedo no ciclo do sistema e garantir a qualidade de software. 4. CONCLUSÃO As contribuições deste trabalho foram obtidas no sentido de responder algumas questões relacionadas por Mnkandla[1]: Como a qualidade se mostra em diferentes metodologias ágeis? Que técnicas são aplicadas para atingir maiores níveis de qualidade? Ficou constatado que a qualidade é uma atividade presente nas diferentes metodologias ágeis de desenvolvimento de software e os princípios relatados no manifesto ágil norteiam também a busca pela qualidade. A garantia da qualidade em Scrum é um desafio para os gestores em virtude da ênfase da metodologia ser no controle do projeto. Apesar disso, há iniciativas no sentido de adequar o Scrum em como realizar as tarefas a fim de melhorar o processo. Exemplo disso é a adaptação do Scrum para questões envolvendo a usabilidade e times com mais integrantes, inclusive em escala global (CRISTAL; WILDT; PRIKLADNICKI[18]; PAASIVAARA; DURASIEWICZ; LASSENIUS[19]). A transparência promovida pelo processo auxilia a adoção de padrões de qualidade, mesmo que não seja esse o objetivo. Rápidas iterações, comunicação de melhores práticas, correção de inconsistências à medida que as experiências ocorrem, entre outros. OpenUP alinhou o que existia de melhor da metodologia RUP às práticas ágeis em um framework de processo open source, resultando em um processo completo. Como os riscos acontecem normalmente em projetos de softwares, OpenUP é muito positivo por reservar um espaço para levantamento e mitigação sem tornar o processo burocrático, inflexível como na maior parte dos modelos tradicionais, proporcionando uma maior garantia de qualidade frente a outras metodologias que não contemplam o risco em seu processo. Além de tratar do risco envolvido, OpenUP evidencia uma forte colaboração entre os stakeholders. Quando a documentação é bem feita, cenários são implementados e testados durante a iteração oferecendo valor acrescido ao cliente. A configuração e

12 12 Giovane Montine Moreira Gurgel, Camilo de Lelis, Clarissa L. A. C. Lins gerência de mudança mantêm o produto de trabalho consistente, proporciona um meio eficaz para se adaptar às mudanças e problemas, fornecendo dados para medir o progresso contínuo das iterações. Como já constatado por Mnkandla [1], alguns fatores de qualidade podem ser obtidos de diferentes práticas, de acordo com cada metodologia. Ao analisar o Scrum e openup, foram percebidas dificuldades na identificação de práticas relacionadas a alguns fatores de qualidade. Apesar disso, pesquisas (JAKOBSEN; JOHNSON[20]) demonstram a interação entre metodologias ágeis e frameworks de qualidade como o Capability Maturity Model Integration (CMMI), a ISO 9001(SCHIEL[21]) e a ISO/IEC (LAMI[22]). 4. REFERENCIAS 1. MNKANDLA, Ernest; DWOLATZKY, Barry. Defining Agile Software Quality Assurance. Proceedings of the International Conference on Software Engineering Advances, p , BECK, Kent; BEEDLE, Mike; BENNEKUM, Arie van; COCKBURN, Alistair; CUNNINGHAM, Ward; FOWLER, Martin; GRENNING, James; HIGHSMITH, Jim; HUNT, Andrew; JEFFRIES, Ron; KERN, Jon; MARICK, Brian; MARTIN, Robert C.; MELLOR, Steve; SCHWABER, Ken; SUTHERLAND, Jeff; THOMAS, Dave. Agile Manifesto Disponível em: < Acesso em: 08/04/ HUO, Ming; VERNER, June; ZHU, Liming; BABAR, Muhammad Ali. Software Quality and Agile Methods. Proceedings of the 28th Annual International Computer Software and Applications Conference, v. 1, p , SCHWABER, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, SCHWABER, Ken; SUTHERLAND, Jeff. Scrum Guide Disponível em < > Acesso em: 17/04/ LARMAN, Craig; VODDE, Bas. Practices for scaling lean & agile development : large, multisite, and offshore product development with large-scale Scrum. Boston: Addison- Wesley, p. 7. SUTHERLAND, Jeff; SCHWABER, Ken. The Scrum papers: Nuts, Bolts, and Origins of an Agile Process Disponível em < > Acesso em: 18/04/ BLOTNER, Joseph A. Agile Techniques to Avoid Firefighting at a Start-Up, JACOBSON, Ivar; BOOCH, Gracy; RUMBAUGH, James. The Unified Software Development Process, Addison-Wesley, BALDINO, Ricardo Introduction to OpenUP (Open Unified Process). Disponível em: < Acesso em:14/04/2010.

13 Qualidade de software: uma análise nas metodologias ágeis Scrum e OpenUP OpenUP. Disponível em: < > Acesso em:14/04/ FOWLER, Martin. The New Methodology Disponível em: < > Acesso em: 08/04/ VOAS, J. Software quality's eight greatest myths. IEEE Software, v. 16, n. 5, , AGUANNO, Kevin. Managing agile projects. Lakefield: Multi-Media Publications Inc., p. 15. HIGHSMITH, James A. Agile project management: creating innovative products. Boston: Addison-Wesley Professional, HANSEN, Mads Troels; BAGGESEN, Hans. From CMMI and isolation to Scrum, Agile, Lean and collaboration. Agile Conference. p , SINGH, Mona. U-SCRUM: An Agile Methodology for Promoting Usability. Agile, AGILE '08 Conference., n. 4-8, p , CRISTAL, Mauricio; WILDT, Daniel; PRIKLADNICKI, Rafael. Usage of SCRUM Practices within a Global Company. IEEE International Conference on Global Software Engineering, p , PAASIVAARA, Maria; DURASIEWICZ, Sandra; LASSENIUS, Casper. Distributed Agile Development: Using Scrum in a Large Project. IEEE International Conference on Global Software Engineering, p , JAKOBSEN, Carsten Ruseng; JOHNSON, Kent Aaron. Mature Agile with a twist of CMMI. Agile conference, p , SCHIEL, James. Enterprise-Scale agile software development. Boca Raton: CRC Press, LAMI, Giuseppe; FALCINI, Fabio. Is ISO/IEC Applicable to Agile Methods? In: ABRAHAMSSON, Pekka; MARCHESI, Michele; MAURER, Frank (Eds.). Agile Processes in Software Engineering and Extreme Programming. Germany: Springer, 2009.