Você está na página 1de 9

Mtodo gil aplicado ao Desenvolvimento de Software

Confivel baseado em Componentes


Alan Braz
1
, Orientadora: Ceclia M. F. Rubira
1
,
Co-orientador: Marco Vieira
2
1
Instituto de Computao Universidade Estadual de Campinas (UNICAMP)
Caixa Postal 6176 13083-852 Campinas SP Brasil
2
Departamento 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. Introduo
A 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 gil
Desenvolvimento 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 Scrum
Scrum 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 Scrum
traduzido 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 Arquitetura
A 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 contribuio
Desenvolver 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 trabalho
O 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 Scrum
1
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 resultados
Nos 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. Referncias
Beck, 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: <http://manifestoagil.com.br/>. 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:
<http://www.jeffsutherland.org/oopsla/schwapub.pdf>. 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: <http://hbr.org/product/new-new-product-
development-game/an/86116-PDF-ENG>. Acessado em: 09 abr 2011.

Você também pode gostar