Mtodo gil aplicado ao Desenvolvimento de Software Confivel baseado em ComponentesAlan Braz1, Orientadora: Ceclia M. F. Rubira1,

Co-orientador: Marco Vieira2

1Instituto de Computao Universidade Estadual de Campinas (UNICAMP)Caixa Postal 6176 13083-852 Campinas SP Brasil

2Departamento de Engenharia Informtica Universidade de Coimbra (UC)Polo II Pinhal de Marrocos 3030-290 Coimbra Portugal

alanbraz@gmail.com, cmrubira@ic.unicamp.br, mvieira@dei.uc.pt

Abstrcat. Agile Software Development (ASD) are in evidence in the Software Engineering for the last 10 years but the impression that it only applies to small and simple projects remains. However several previous works have proven that reliable software can be developed using combinations of ASD with Component Based and Architecture-centric processes. This paper presents some improvements in the Scrum process to support the development of robust information systems.

Resumo. O Desenvolvimento gil de Software (DAS) est em evidncia na Engenharia de Software h pelo menos 10 anos, mas ainda tem-se a impresso de que ele apenas se aplica em projetos simples e pequenos. Entretanto, vrios trabalhos prvios j demonstratam que possvel desenvolver sistemas confiveis combinando DAS com processos Baseados em Componentes e Centrados na Arquitetura. Este artigo apresenta algumas melhorias no processo gil Scrum para suportar o desenvolvimento de sistemas de informao robustos.

1. IntroduoA popularizao do Mtodo gil (ou Desenvolvimento gil de Software) atravs de metodologias como XP e Scrum fez com que fossem aplicadas no desenvolvimento de sistemas computacionais robustos. Este fato evidencia a necessidade de processos de desenvolvimento e gerenciamento de software que sejam robustos e que possuam uma quantidade adequada de modelagem e documentao, em especial no que concerne o projeto arquitetural, a fim de garantir maior qualidade no seu resultado final. A robustez pode ser alcanada adicionando elementos de tratamento de excees s fases iniciais do processo de desenvolvimento e na reutilizao de componentes. O objetivo principal deste trabalho propor uma soluo para guiar o desenvolvimento de sistemas confiveis baseados em componentes que utilize os princpios geis, em particular a metodologia Scrum.

2. Fundamentao terica

2.1. Mtodo gilDesenvolvimento gil de Software ou Mtodo gil um conjunto de metodologias guiadas por quatro valores e doze princpios definidos no [Manifesto gil 2001].

Os valores ressaltam:

1. Indivduos e a interao entre eles mais que processos e ferramentas,

2. Software em funcionamento mais que documentao abrangente,

3. Colaborao com o cliente mais que negociao de contratos, e

4. Responder a mudanas mais que seguir um plano.

Os 12 princpios expandem os valores de forma mais detalhada dando mais nfase aos itens esquerda dos valores do que os da direita.

Devido simplicidade de seus valores e enfoque na organizao das equipes e nos aspectos gerenciais, tem-se a impresso de que documentar os requisitos, definir um projeto arquitetural, fazer anlise e design no so obrigatrios ou no precisam de nenhum tipo de rigor. Porm um dos princpios dita que necessrio ter ateno contnua excelncia tcnica e a um bom design salientando a importncia de se ter um design satisfatrio, o que s possvel com certo rigor e formalismo no projeto arquitetural que por sua vez baseado nos requisitos levantados.

Desde as dcadas de 80 e 90 metodologias rotuladas como leves j eram aplicadas, destacando entre elas, o Scrum desde 1986 [Takeuchi e Nonaka 1986] e a Programao Extrema ou XP, que foi desenvolvida por Kent Beck em 1996 quando foi lider de projeto do sistema de folha de pagamento da Chrysler, onde comeou a refinar o processo de desenvolvimento e publicou os resultados no livro Extreme Programming Explained: embrace change [Beck 1999].

2.2. Metodologia ScrumScrum um processo gil de gerenciamento de software, tambm conhecido como processo leve, que promove um desenvolvimento iterativo de incremental. Foi introduzido por Ken Schwaber [Schwaber 1995] e atingiu maior popularidade aps a formao da Agile Alliance em 2001.

Foi criado observando-se que equipes pequenas e multidisciplinares produziam melhores resultados e associaram estas equipes altamente eficazes formao Scrum do Rgbi utilizada para reincio do jogo. Oferece uma abordagem emprica permitindo que os membros da equipe trabalhem independentemente e coordenadamente em um ambiente criativo. Nele reconhecido o aspecto social e colaborativo da engenharia de software.

Suas fases podem ser de dois tipos: Definidas ou Empricas. As definidas seguem um modelo mais tradicional, o qual tem um fluxo linear de atividades prdeterminadas com estradas e sadas bem definidas. J as empricas possibilitam maior liberdade por parte da equipe no que diz respeito processo, criando um

ambiente propcio para competies e experimentaes.

Figura 1: Fases da Metodologia Scrumtraduzido e adaptado de [Schwaber 1995]

Na figura 1 temos as trs fases do Scrum: Pr-jogo (Concepo ou Iniciao), Jogo (Desenvolvimento) e Ps-jogo (Fechamento ou Entrega). As fases de Concepo e Fechamento so definidas, ou seja, tm entradas e sadas predefinidas e o conhecimento explicito seguindo um fluxo linear, mesmo que a etapa de Planejamento possa ser composta por algumas iteraes.

A fase de Jogo emprica, ou seja, as etapas de Desenvolvimento, composta por Anlise, Projeto e Codificao, Integrao ou Empacotamento (Wrap), Reviso e Testes (Review) e Ajustes ocorrem concorrentemente e repetidamente em ciclos com durao predefinidas (entre uma e quatro semanas) chamados de Sprints ou Iteraes.

2.3. Desenvolvimento Baseado em Componentes A ideia de utilizar o conceito de Desenvolvimento Baseado em Componentes (DBC) na produo de software data de 1976 [McIlroy 1976]. No DBC, uma aplicao construda a partir da composio de componentes de software que j foram previamente especificados, construdos e testados, proporcionando ganho de produtividade e qualidade.

Esse aumento da produtividade decorrente da reutilizao de componentes existentes na construo de novos sistemas. J o aumento da qualidade uma consequncia do fato dos componentes j terem sido empregados e testados em outros contextos. Porm, vale ressaltar que apesar desses testes prvios serem benficos no pode-se dispensar a execuo dos testes no novo contexto.

Segundo [Szyperski 1998], um componente de software uma unidade de composio com interfaces especificadas atravs de contratos (interfaces providas) e dependncias de contexto explcitas (interfaces requeridas). Alm disso, os componentes seguem trs princpios fundamentais, que so comuns tecnologia de objetos: (i) unificao de dados e funes; (ii) encapsulamento; e (iii) identidade.

2.4. Processo UML Components

O processo UML Components [Cheesman e Daniels 2001] um processo simples e de fcil utilizao prtica. Adota uma arquitetura predefinida em quatro camadas sendo que duas so destacadas durante o desenvolvimento: camada de sistema e camada de negcio. A camada de sistema agrupa os componentes que implementam as funcionalidades especificadas. Porm, para que essas funcionalidades possam ser implementadas, esses componentes podem necessitar de algumas funcionalidades comuns ao domnio, formando a camada de negcio.

Figura 2: Fases do processo UML Components [Brito 2005]

A figura 2 mostra as seis fases do processo, que iterativo e enfatiza a fase de especificao dos componentes que detalhada em trs sub fases: (i) identificao dos componentes; (ii) interao entre os componentes; e (iii) especificao final.

2.5. Desenvolvimento Centrado na ArquiteturaA arquitetura de software, atravs de um alto nvel de abstrao, define o sistema em termos de seus componentes arquiteturais, que representam unidades abstratas do sistema; a interao entre essas entidades, os conectores; e os atributos e funcionalidades de cada um [Sommerville 1995]. Por conhecerem o fluxo interativo entre os componentes do sistema os conectores possibilitam a criao de protocolos de comunicao e a coordenao da execuo dos servios que envolvam mais de um componente.

As propriedades arquiteturais so derivadas dos requisitos do sistema e influenciam, direcionam e restringem todas as fases do seu ciclo de vida tornando-se um artefato essencial nos processos de desenvolvimento, sendo til em todas as suas fases. Sua importncia fica ainda mais clara no contexto do desenvolvimento baseados em componentes, uma vez que na composio de sistemas, os componentes precisam interagir entre si para oferecer as funcionalidades desejadas. 2.6. Metodologia para Definio do Comportamento Excepcional (MDCE+)[Ferreira 2001] apresentou uma metodologia para a construo de sistemas tolerantes a falhas usando tcnicas de tratamento de excees para manter a confiabilidade e disponibilidade dos servios requisitados. Esta metodologia nomeada MDCE, acrnimo de Metodologia para Definio do Comportamento Excepcional e estende a UML com novos esteretipos. Neste trabalho MDCE foi aplicado ao Processo Catalysis

[D'Souza e Will 1998] de desenvolvimento de software.[Brito 2005] estendeu o MDCE para o MDCE+ que tem o objetivo de

sistematizar a modelagem e a implementao do comportamento excepcional no desenvolvimento de sistemas baseados em componentes. Esse refinamento se concentrou nas fases de projeto arquitetural e implementao. A nfase na arquitetura possibilitou uma melhor anlise dos fluxos de excees que ocorrem entre os componentes arquiteturais. Essa anlise permite a construo de tratadores mais eficientes, alm de antecipar a correo de possveis falhas de especificao. O MDCE+ foi adaptado ao processo UML Components e a uma metodologia de testes. Alm disto, deixou como sugesto para trabalhos futuros a possibilidade de introduzir algumas caractersticas de processos geis ao MDCE+ tomando cuidado para no comprometer seu principal objetivo, ou seja, a confiabilidade do produto final. Esta sugesto o objetivo principal deste trabalho.

3. Trabalhos relacionados[Radinger e Goeschka 2003] propuseram uma abordagem para integrar o Desenvolvimento gil de Software ao Desenvolvimento Baseado em Componentes em um Desenvolvimento gil de Componentes em projetos de pequena e larga escalas combinando as questes tcnicas e gerenciais de ambas as abordagens.

[Nord e Tomayko 2006] exploraram as relaes e sinergias entre a Anlise e Projeto centrado na Arquitetura e a metodologia gil XP, destacando que o segundo enfatiza o desenvolvimento rpido e flexvel enquanto o primeiro prioriza o projeto e a infraestrutura.

[Nord, Tomayko e Wojcik 2004] escreveram um relatrio tcnico descrevendo a integrao entre os mtodos centrados na arquitetura do Instituto de Engenharia de Software (SEI) da Universidade de Carnegie Mellon e o XP. Fizeram isto apresentando um resumo do XP examinando o potencial de uso dos mtodos centrados na arquitetura do SEI, entre eles o Architecture Tradeoff Analysis Method (ATAM).

[Behrouz 2007] mostra que apesar de terem enfoques distintos existe compatibilidade entre o desenvolvimento de software confivel (Software Reliability Engineering - SRE) e gil principalmente no que cerca os aspectos de medir e avaliar a confiabilidade do software desenvolvido. A discusso gira em torno da suposta incompatibilidade de que o SRE executa os testes no software criado com o objetivo de validar os parmetros de confiabilidade previamente definidos e modelados, enquanto o mtodo gil se apoia em uma abordagem dirigida a testes (Test Driven Development - TDD) a qual os casos de testes so escritos antes do cdigo e executados constantemente durante o processo de desenvolvimento.

4. Caracterizao da contribuioDesenvolver a combinao do mtodo que auxilia a construo de sistemas de software com requisitos de confiabilidade ligados tolerncia a falhas, chamado de MDCE+, ao processo gil de desenvolvimento de sistemas de software, nesse caso o Scrum. Isso ser feito atravs da utilizao das tarefas de identificao de excees e a especificao

de seus tratadores nas fases do Scrum. O mtodo resultante ser chamado de Scrum+CE (Scrum com Comportamento Excepcional) e possibilitar o desenvolvimento de software confivel utilizando um mtodo gil.

Ser feito um estudo de caso qualitativo, a fim de validar a aplicabilidade prtica da soluo construda. No estudo de caso, tomaremos como base as mtricas de processo um projeto que utilizou a metodologia Scrum sem preocupao explcita com o comportamento excepcional. Ser feita uma anlise dos benefcios esperados e alcanados com a adoo da soluo proposta usando-se questionrios aplicados aos desenvolvedores do projeto salientando os impactos da utilizao do Scrum+CE em detrimento ao Scrum.

5. Estado atual do trabalhoO Scrum+CE foi definido com as alteraes que sero necessrias nas fases de Pr-jogo e Jogo no que diz respeito a levantar Histrias Excepcionais e refinar a Arquitetura com elementos excepcionais explcitos. Alm disso, tcnicas geis que melhoram a confiabilidade como TDD (Test-Driven Development) e Integrao Contnua so fortemente recomendadas.

Figura 3: Interferncia do Mtodo MDCE+ nas fases do Scrum

A Figura 3 mostra as fases do Scrum com as atividades do MDCE+ que devem ser desenvolvidas nas respectivas fases. Nota-se que as maiores modificaes ser na fase de Pr-Jogo, na qual o comportamento excepcional ser documentado na forma de Histrias Excepcionais e de Testes de Aceitao nas Histrias de Usurio que validem especificamente os fluxos excepcionais. Alm disso, a Arquitetura em alto-nvel passar

a expor os componentes excepcionais conforme o modelo de componente tolerante a falhas ideal, ou simplesmente componente ideal, categorizado em dois tipos: normal, que produz respostas corretas, e excepcional (ou anormal), que executado quando um erro detectado.

Dentro da fase Jogo, teremos como entradas as Histrias de Usurios e Histrias Excepcionais igualmente priorizadas no Backlog do Produto. Elas devero entrar no Backlog do Sprint de acordo com suas prioridades e dependncias.

Figura 4: Detalhamento da Fase Jogo do Scrum1

A Figura 4 mostra em detalhes o framework do Scrum que ocorre dentro da fase Jogo, diferenciando os papis, artefatos e cerimnias ou reunies. A combinao com o MDCE+ afetar os artefatos Backlog do Produto, com a adio das Histrias Excepcionais, e o Backlog do Sprint, com as tarefas especficas de implementao das Excees. Uma vez dentro dos Backlogs, as histrias e tarefas excepcionais sero tratadas e implementadas normalmente, como um requisito funcional comum.

Dois projetos de sistema de informao que utilizam a arquitetura predefinida de quatro camadas do UML Components, que j foi adaptado pelo MDCE+ por [Brito 2005], j foram selecionados e esto em fase de coleta do documento de arquitetura e das Histrias de Usurios (User Stories) [Cohn 2004] para anlise e posterior avaliao dos resultados com as modificaes e adies sugeridas pelo Scrum+CE.

6. Avaliao dos resultadosNos projetos selecionados para o estudo de caso qualitativo ocorrer a reviso dos requisitos (Histrias de Usurios) e documento de arquitetura, adaptando-os as prticas e tcnicas do Scrum+CE.

1 Imagem trazudiza e adaptada do original em ingls do site http://www.agileforall.com/intro-to-agile/

O documento de arquitetura e os diagramas tero o acrscimo dos Componentes Excepcionais. A Histrias de Usurio, como j foram implementadas, j foram estimadas em Pontos de Histria (Story Points) [Cohn 2005] e contm os seus Testes de Aceitao que sero a base para a extrao do comportamento excepcional e criao das Histrias Excepcionais.

Ser feita uma anlise dos benefcios esperados e alcanados usando-se questionrios aplicados aos desenvolvedores dos projetos e utilizando as mtricas propostas por [Gomes 2000] e os Pontos de Histria.

Aps a adaptao e validao espera-se um aumento no nmero de Histrias de Usurios, e por consequencia de Pontos de Histria, acarretando no aumento no tempo de desenvolvimento e custo. Em contrapartida espera-se a diminuio dos defeitos na fase de Ps-Jogo, uma vez que estaremos antecipando e explicitando o comportamento excepcional, resultando em um produto final com maior qualidade.

7. RefernciasBeck, K. (1999). Extreme programming explained: embrace change, Addison-Wesley

Longman Publishing Co., Inc., Boston, MA.Behrouz H. F. (2007). Software Reliability Engineering for Agile Software

Development, 20th IEEE Canadian Conference on Electrical and Computer Engineering CCECE 2007, pp. 694-697.

Brito, P. H. S. (2005). Um Mtodo para Modelagem de Excees em Desenvolvimento Baseado em Componentes. Dissertao (Mestrado em Cincia da Computao) - Universidade Estadual de Campinas, Instituto de Computao. Orientador: Ceclia Mary Fischer Rubira.

Cheesman, J. e Daniels, J. (2001) "UML Components: A Simple Process for Specifying Component-Based Software" Addison-Wesley.

Cohn, M. (2004) User Stories Applied: For Agile Software Development, Addison-Wesley.

Cohn, M. (2005) Agile Estimating and Planning, Prentice Hall.D'Souza, D. e Will, A.C. (1998). Objects, Components and Frameworks with UML.

The Catalysis Approach Addison-Wesley.Ferreira, G. R. M. (2001). Tratamento de Excees no Desenvolvimento de Software

Confivel Baseado em Componentes. Dissertao (Mestrado em Cincia da Computao) - Universidade Estadual de Campinas, Fundao de Amparo Pesquisa do Estado de So Paulo. Orientador: Ceclia Mary Fischer Rubira.

Gomes, A., et al. (2000), Medio e Melhoria de Processos de Software. Anais do Workshop de Qualidade de Software, Simpsio Brasileiro de Engenharia de Software, Joao Pessoa.

Manifesto gil (2001). Manifesto para o desenvolvimento gil de software. Disponvel em: . Acessado em: 17 jan 2011.

McIlroy, M. D. (1976). Mass-produced software components. In J. N. Buxton Peter Naur, Brian Randell, editor, Software Engineering: Concepts and Techniques, pages 8894. Petrocelli/Charter.

Nord, R. L. e Tomayko, J. E. (2006). "Software Architecture-Centric Methods and Agile Development", IEEE Software, vol. 23, no. 2, pp. 47-53, Mar./Apr.

Nord, R. L., Tomayko, J. E. e Wojcik, R. (2004). Integrating Software-Architecture-Centric Methods into Extreme Programming (XP), tech. report CMU/SEI-2004-TN-036, Software Eng. Inst., Carnegie Mellon Univ.

Radinger, W. e Goeschka, K. M. (2003). Agile software development for component based software engineering, Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, October 26-30, 2003, Anaheim, CA, USA

Schwaber, K. (1995). "SCRUM Development Process", OOPSLA'95 Workshop on Business Object Design and Implementation. Austin, USA. Disponvel em: . Acessado em: 22 mar 2010.

Sommerville, I. (1995). Software Engineering. Addison-Wesley, 5th edition.Szyperski, C. (1998). Component Software: Beyond Object-Oriented Programming.

Addison-Wesley.Takeuchi, H. e Nonaka, I. (1986). The New New Product Development Game.

Harvard Business Review. Disponvel em: . Acessado em: 09 abr 2011.

1. Introduo2. Fundamentao terica2.1. Mtodo gil2.2. Metodologia Scrum2.3. Desenvolvimento Baseado em Componentes 2.4. Processo UML Components2.5. Desenvolvimento Centrado na Arquitetura2.6. Metodologia para Definio do Comportamento Excepcional (MDCE+)

3. Trabalhos relacionados4. Caracterizao da contribuio5. Estado atual do trabalho6. Avaliao dos resultados7. Referncias