COMPARAO ENTRE OS PROCESSOS DOS MTODOS GEIS: XP, SCRUM, FDD E ASD EM RELAO AO DESENVOLVIMENTO ITERATIVO INCREMENTAL COMPARISON

BETWEEN THE PROCESSES OF METHODS GEIS: XP, SCRUM, FDD AND ASD WITH RESPECT TO THE DEVELOPMENT OF AN INCREMENTAL ITERATIVE
Priscila Basto Fagundes SENAIsc-Florianpolis, E-mail: priscila@ctai.senai.br Janice Ins Deters SENAIsc-Florianpolis, E-mail: jan@ctai.senai.br Sandro da Silva dos Santos SOCIESC, E-mail: sandro.silva@sociesc.com.br Resumo. Cada vez mais os mtodos geis tm despertado o interesse da comunidade de Engenharia de Software como uma alternativa para o processo de desenvolvimento de sistemas de uma maneira mais rpida, eficiente e que atenda as reais necessidades dos clientes. Existem no mercado vrios mtodos disponveis que utilizam a abordagem gil e que, por seguirem os princpios geis, apresentam uma srie de atividades semelhantes no seu processo de desenvolvimento. Este artigo apresenta uma comparao entre os processos propostos pelos mtodos geis XP, Scrum, FDD e ASD, de forma a auxiliar a equipe de desenvolvimento na escolha do mtodo que melhor se adapte a suas expectativas. Palavras-chave: Mtodos geis, XP, SCRUM, FDD, ASD Abstract. More and more often the Software Engineering community has paid attention to agile methods as a more efficient alternative for system development that supports customer real needs. There are several methods in the market based on the agile approach and, because these methods use the same agile principles, a lot of activities in their development processes resemble that approach. This paper presents a comparison of the processes proposed by the agile methods XP, Scrum, FDD, and ASD, aiming at helping development teams in the choice of the agile method that best meets their expectations. Key-words: Agile methods XP; Scrum; FDD; ASD 1 INTRODUO

medida que as organizaes tornam-se cada vez mais dependentes da indstria do software, ficam mais evidentes os problemas relacionados ao processo de desenvolvimento de sistemas: alto custo, alta complexidade, dificuldade de manuteno, e uma disparidade entre as necessidades dos usurios e o produto desenvolvido (SOMMERVILLE, 2003).

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.

37

Acreditando que o processo utilizado um dos motivos para a ocorrncia desses problemas, um segmento crescente da Engenharia de Software vem defendendo a adoo de processos mais simplificados conhecidos como mtodos geis, que visam a desburocratizao das atividades associadas ao desenvolvimento (FOWLER, 2001). Os mtodos geis tm despertado um grande interesse entre a comunidade de desenvolvimento de sistemas. E, acredita-se que devido a esta demanda, uma considervel quantidade de mtodos apresentando caractersticas geis tm surgido nos ltimos anos. Para auxiliar os profissionais, ligados ao desenvolvimento de software, interessados na utilizao da abordagem gil, na escolha de um mtodo gil que melhor se adapte s necessidades dos seus projetos, equipes e/ou organizaes, este artigo apresenta uma comparao entre os processos de desenvolvimento de alguns destes: Extreme Programming (XP) (BECK, 2000), Scrum BEEDLE et al, 1998), Feature Driven Development (FDD) (DE LUCA, 2002) e Adaptive Software Development (ASD) (HIGHSMITH, 2002). Esta comparao o resultado de uma anlise das atividades adotadas por cada um dos mtodos. 2 MTODOS GEIS

A indstria do software sempre contou com mtodos cujos processos de desenvolvimento eram baseados em um conjunto de atividades predefinidas, descritas como processos prescritivos (AMBLER 2004), onde muitas vezes, o trabalho comeava com o levantamento completo de um conjunto de requisitos, seguido por um projeto de alto-nvel, de uma implementao, de uma validao e, por fim, de uma manuteno (SOMMERVILLE 2003). A partir da dcada de 90, comearam a surgir novos mtodos sugerindo uma abordagem de desenvolvimento gil onde os processos adotados tentam se adaptar s mudanas, apoiando a equipe de desenvolvimento no seu trabalho (BECK, et. al., 2001). Estes novos mtodos surgiram como uma reao aos mtodos tradicionais1 de desenvolvimento de sistemas, ganhando com o passar dos anos um nmero cada vez maior de adeptos. Com o intuito de definir um manifesto para encorajar melhores meios de desenvolver sistemas, em fevereiro de 2001 um grupo inicial de 17 metodologistas, entre eles, Robert C. Martin, Jim Highsmith, Kent Beck e outros, formou a Aliana para o Desenvolvimento gil de Software, que formulou um manifesto contendo um conjunto de princpios que definem critrios para os processos de desenvolvimento gil de sistemas (AMBLER, 2004). Os doze princpios (BECK, et. al. 2001), aos quais os mtodos geis devem se adequar so: a) b) c) d) e) f) g) h) i) j) k) l) A prioridade satisfazer ao cliente atravs de entregas contnuas e freqentes; Receber bem as mudanas de requisitos, mesmo em uma fase avanada do projeto; Entregas com freqncia, sempre na menor escala de tempo. As equipes de negcio e de desenvolvimento devem trabalhar juntas diariamente; Manter uma equipe motivada fornecendo ambiente, apoio e confiana necessrios; A maneira mais eficiente da informao circular atravs de uma conversa face-aface; Ter o sistema funcionando a melhor medida de progresso; Processos geis promovem o desenvolvimento sustentvel; Ateno contnua a excelncia tcnica e a um bom projeto aumentam a agilidade; Simplicidade essencial; As melhores arquiteturas, requisitos e projetos provm de equipes organizadas; Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz.
38

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.

Com base nos princpios descritos acima, cada um dos mtodos geis - incluindo os utilizados nesta comparao - apresenta um conjunto de atividades a serem adotadas durante o processo de desenvolvimento do sistema. com base nestas atividades que realizada a comparao apresentada neste trabalho. importante mencionar que antes de iniciar a comparao propriamente dita entre os mtodos foi realizado um estudo detalhado de cada um dos quatro mtodos (XP, Scrum, FDD e ASD). 3 COMPARAO ENTRE OS MTODOS GEIS

O texto a seguir mostra os critrios utilizados na comparao e os respectivos resultados. 3.1 CRITRIOS UTILIZADOS

Os critrios adotados para servirem de base para a identificao das atividades propostas pelos Mtodos geis so as atividades sugeridas pelo Desenvolvimento Incremental. Sommerville (2003) afirma que os mtodos geis so fundamentados no Desenvolvimento Incremental. E conforme puderam ser observado, as atividades sugeridas durante o seu processo de desenvolvimento so bastante semelhantes aos Princpios geis. No Desenvolvimento Incremental (Figura 1) os clientes inicialmente identificam, em um esboo, os requisitos do sistema e selecionam quais so os mais e os menos importantes. Em seguida definida uma srie de iteraes de entrega, onde em cada uma fornecido um subconjunto de funcionalidades executveis, dependendo das suas prioridades.

Definir esboo dos requisitos

Atribuir requisitos as iteraes

Projetar arquitetura do sistema

Desenvolver incremento do sistema

Validar incremento

Integrar incremento

Validar sistema Entrega final

Figura 1. Desenvolvimento Incremental Fonte: Adaptado de Sommerville (2003)

Aps a identificao dos incrementos, as funcionalidades a serem entregues na primeira iterao so detalhadas e desenvolvidas. Paralelamente a este desenvolvimento, outras funcionalidades podem ser analisadas para fazerem parte dos outros incrementos. Uma vez que cada incremento concludo e entregue, os clientes podem coloc-lo em operao. O fato dos clientes poderem experimentar o sistema gradualmente facilita o esclarecimento das funcionalidades para os incrementos subseqentes e medida que novos incrementos so concludos, eles so integrados s iteraes existentes, de modo que o sistema melhora a cada novo incremento entregue (SOMMERVILLE, 2003). 3.2 RESULTADOS DA COMPARAO Para possibilitar uma melhor compreenso da comparao realizada, para cada uma das atividades do Desenvolvimento Incremental apresentada uma tabela contendo um resumo da atividade correspondente em cada um dos mtodos analisados, e, logo aps, uma explicao
E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008. 39

de como e quando estas atividades so realizadas durante o processo de desenvolvimento de cada um dos mtodos. 3.2.1 Definio do Esboo dos Requisitos No XP, a definio preliminar dos requisitos feita a partir da escrita das user stories pelos clientes. As user stories so descries textuais sucintas a respeito das funcionalidades do sistema (BECK, 2000). No Scrum, de acordo com Schwaber e Beedle (2002), os requisitos conhecidos at o momento so listados dando origem ao Product Backlog. Estes requisitos so agrupados de acordo com as suas prioridades, apresentando as seguintes informaes: descrio do requisito, tempo estimado para o desenvolvimento e responsvel pelo desenvolvimento. No FDD, os requisitos j conhecidos so listados, definidos e documentados atravs de casos de uso ou users stories. Sugere-se tambm que sejam construdos um diagrama de classes UML e diagrama(s) de seqncia UML com o objetivo de auxiliar na compreenso do projeto (HIGHSMITH 2002). Segundo Highsmith (2002) e Abrahamsson (2002), o ASD no apresenta nenhuma atividade explcita em relao definio preliminar dos requisitos, mas so realizadas sesses JAD2 (Joint Application Development) com a presena dos representantes dos clientes, objetivando identificar os requisitos conhecidos at o momento. A Tabela 1 apresenta as atividades de definio do Esboo dos Requisitos. Tabela 1 - Atividade - Definio do Esboo dos Requisitos Mtodo XP Scrum FDD ASD Especificao da Atividade Clientes escrevem as user stories. Definio do Product Backlog Gerao de artefatos para a documentao dos requisitos Requisitos definidos durante as sesses JAD
Fonte: Dos Autores (2008)

3.2.2 Atribuio dos Requisitos s Iteraes A atribuio dos requisitos s iteraes no XP acontece com a participao do cliente sempre que uma nova iterao iniciada (BECK 2000), onde so definidas as user stories que sero implementadas durante cada iterao. No Scrum os requisitos que sero desenvolvidos em cada Sprint so definidos a partir da lista de requisitos contida no Product Backlog. Durante a Reunio de Planejamento da Sprint acontece a alocao dos requisitos s Sprints, de acordo com a sua prioridade, dando origem ao Sprint Backlog (BEEDLE et al, 1998). No FDD, as caractersticas (requisitos) so agrupadas e priorizadas de acordo com a sua importncia e dependncia dando origem aos conjuntos de caractersticas que sero desenvolvidos durante as vrias iteraes (HIGHSMITH 2002). O ASD define a quantidade de iteraes e quais os requisitos que sero implementados em cada uma delas. (ABRAHAMSSON 2002). As atribuies dos requisitos as iteraes esto representados na Tabela 2.

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.

40

Tabela 2 - Atividade - Atribuio dos Requisitos as Iteraes Mtodo Especificao da Atividade Equipe tcnica e clientes definem as user stories que sero desenvolvidas XP nas iteraes. As iteraes duram de 1 a 4 semanas. Definio do Sprint Backlog. As Sprints (iteraes) duram no mximo 30 Scrum dias. As caractersticas so agrupadas, priorizadas e distribudas aos responsveis FDD pelo seu desenvolvimento. As iteraes duram no mximo 2 semanas. ASD Definio do nmero de iteraes. As iteraes duram de 4 a 8 semanas.
Fonte: Dos Autores (2008)

3.2.3 Projeto da Arquitetura do Sistema O XP prope que paralelamente escrita das user stories, seja realizado o projeto da arquitetura do sistema (BECK 2000). Porm, no apresenta sugestes em relao a como este projeto deve ser feito, nem quais os artefatos devem ser gerados. O Scrum sugere que seja feito um projeto geral do sistema baseado nos itens do Product Backlog (SCHWABER E BEEDLE, 2002). E tambm no sugere nenhuma tcnica associada a esta atividade. De acordo com Highsmith (2002a), De Luca (2002) e Abrahamsson (2002), o FDD sugere que seja construdo um diagrama de classes da UML para representar a arquitetura do sistema. Para complementar o diagrama de classes tambm podero ser gerados diagramas de seqncia da UML. O ASD no sugere nenhuma atividade relacionada ao projeto de arquitetura. 3.2.4 Desenvolver Incremento do Sistema No XP a atividade de desenvolvimento dos requisitos realizada durante as iteraes (BECK 2000), onde, para cada conjunto de user stories selecionadas para fazerem parte da iterao so realizadas as atividades de modelagem e programao. No Scrum, esta atividade acontece durante a Sprint, onde so implementados os requisitos contemplados no Sprint .Backlog Schwaber (1995) ressalta que o desenvolvimento dos itens dentro de uma Sprint no segue nenhum processo pr-definido. Durante cada uma das Sprints acontecem as Reunies Dirias do Scrum que devem durar de 15 a 30 minutos e tm como objetivo que todos os envolvidos se mantenham informados sobre o progresso e as dificuldades encontradas. No FDD a implementao das classes e mtodos correspondentes s caractersticas que sero desenvolvidas durante as iteraes antecedida pelas atividades de anlise da documentao existente, gerao de diagramas de seqncia para o conjunto de caractersticas, refinamento do modelo gerado durante as atividades de definio dos requisitos e do projeto da arquitetura do sistema (HIGHSMITH 2002). O ASD sugere os requisitos sejam desenvolvidos dentro das suas respectivas iteraes e que, se possvel, sejam desenvolvidos simultaneamente (ABRAHAMSSON 2002).

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.

41

Tabela 3 - Atividade - Desenvolver Incremento do Sistema Mtodo Especificao da Atividade XP Scrum FDD ASD Implementao das user stories que fazem parte da iterao corrente por duplas de programadores. Implementao dos requisitos contemplados no Sprint Backlog para a Sprint corrente. Anlise da documentao existente, gerao de Diag. de Seqncia da UML, refinamento do modelo gerado nas atividades anteriores e implementao das caractersticas que sero desenvolvidas durante a iterao corrente. Implementao dos requisitos que fazem parte da iterao corrente.
Fonte: Dos Autores (2008)

3.2.5 Validar Incremento No XP a validao dos requisitos desenvolvidos durante a iterao ocorre atravs da execuo dos testes de aceitao e dos testes de unidade. De acordo com Beck (2000), os programadores escrevem os testes de unidade e os clientes os testes de aceitao e ambos so escritos anteriormente ao processo de codificao e s aps so executados. O Scrum sugere que a atividade de validao dos itens do Sprint Backlog implementados seja realizada no final da Sprint (SCHWABER E BEEDLE 2002). Segundo Abrahamsson (2002), no FDD os testes acontecem ao final de cada iterao, onde o conjunto de caractersticas implementado durante a mesma testado atravs de testes de unidade pelos proprietrios de classe os programadores -. O ASD verifica a qualidade funcional do sistema gerado na iterao atravs da definio de grupos de clientes para revisar e testar a aplicao (HIGHSMITH 2002). Tambm a qualidade tcnica verificada, onde um par de programadores responsvel por revisar e avaliar o cdigo do sistema. A validao do incremento demonstrada na Tabela 4. Tabela 4 - Validar Incremento Mtodo Especificao da Atividade Os programadores executam os testes de unidade e os clientes executam os XP testes de aceitao. Scrum O Scrum no adota nenhum processo de validao pr-definindo. FDD ASD Os testes e inspees so executados pelos prprios programadores aps a implementao. So verificadas a qualidade tcnica e funcional do sistema.
Fonte: Dos Autores (2008)

3.2.6 Integrar Incremento No XP, Beck (2000) sugere que medida que o cdigo vai sendo gerado ele vai sendo integrado, evitando problemas de compatibilidade cedo. No Scrum, a integrao dos resultados das vrias Sprints acontece ao final de cada uma delas (SCHWABER E BEEDLE 2002). O Scrum no sugere como esta atividade deve ser realizada. No FDD, a integrao do conjunto de caractersticas implementado durante a iterao corrente com os outros conjuntos acontece ao final de cada iterao, aps os testes e inspees (HIGHSMITH 2002). O ASD no sugere nenhuma atividade especfica de integrao dos incrementos desenvolvidos em cada. A Tabela 6 apresenta a atividade de Integrar o Incremento.
E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008. 42

Tabela 6 - Atividade - Integrar Incremento Mtodo Especificao da Atividade XP A integrao acontece paralelamente ao desenvolvimento das user stories. Scrum FDD ASD Atividade realizada ao final de cada Sprint. Atividade realizada aps os testes no incremento. Fonte: Dos Autores (2008)

3.2.7 Validar Sistema Como o XP sugere que as integraes devem acontecer paralelamente s implementaes das user stories e, conseqentemente, aos testes, o mesmo no sugere atividades especficas de validao aps a integrao dos incrementos. Entretanto, ele coloca que o resultado da iterao pode ser posto em operao dentro da organizao, onde ser avaliado e poder sofrer alterao de acordo com as consideraes levantadas pelos clientes (BECK 2000). Conforme Schwaber e Beedle (2002), o Scrum valida a integrao dos incrementos no ltimo dia de cada Sprint atravs de uma reunio chamada Reviso da Sprint. Os participantes avaliam o incremento e decidem sobre as atividades seguintes. Aps a entrega do incremento ao cliente, o Scrum sugere que seja realizado algum tipo de acompanhamento em relao utilizao do mesmo, onde so executados mais testes com o objetivo de garantir a qualidade do mesmo. Aps a integrao dos conjuntos de caractersticas, o FDD valida todos os incrementos gerados atravs das inspees e dos testes de integrao (DE LUCA 2002). O ASD no sugere nenhuma atividade especfica de validao do sistema como um todo. A Tabela 7 apresenta a comparao da Atividade Validar Sistema. Tabela 7 - Atividade - Validar Sistema Mtodo Especificao da Atividade XP Scrum FDD ASD O sistema disponibilizado ao cliente para que o mesmo realize validaes. O cliente valida o sistema integrado em uma reunio no ltimo dia da Sprint. Esta atividade ocorre atravs das inspees e dos testes de integrao Fonte: Dos Autores (2008)

3.2.8 Entrega Final De acordo com Beck (2000), no XP a entrega final do sistema ocorre quando o cliente estiver satisfeito com o sistema e no tiver mais nada a acrescentar em relao s funcionalidades. No Scrum, o sistema entregue quando no existirem mais itens no Product Backlog a serem desenvolvidos (SCHWABER E BEEDLE 2002). O FDD sugere que todos os conjuntos de caractersticas devem passar pelas etapas de projeto e construo at que o sistema esteja pronto para ser entregue (HIGHSMITH 2002, ABRAHAMSSON 2002). E, por fim, no ASD esta atividade tambm s realizada aps no existirem mais requisitos a serem implementados (HIGHSMITH 2002). A Tabela 8 apresenta a Atividade de Entrega Final.

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.

43

Tabela 8 Atividade de Entrega Final Mtodo Especificao da Atividade XP Scrum FDD ASD 4 Cliente satisfeito com o sistema Todos os itens no Product Backlog desenvolvidos O sistema entregue aps todos os conjuntos de caractersticas implementados Todos os requisitos desenvolvidos.
Fonte: Dos Autores (2008)

CONCLUSES

Este trabalho apresentou uma comparao entre os processos XP, Scrum, FDD e ASD, levando em considerao o Desenvolvimento Incremental. Esta abordagem diferente das apresentadas em (ABRAHAMSSON ET AL, 2003) e (COHN, 2002). Em (ABRAHAMSSON ET AL, 2003), apresentado uma comparao entre os mtodos geis ASD, AM, Crystal Family, DSDM, XP, FDD, ISD, PP e Scrum em relao aos seguintes critrios: Ciclo de vida de desenvolvimento de software; Administrao de projeto; Princpios abstratos versus direo concreta; Predefinio universal versus situao adequada; e Apoio emprico. E em (COHN, 2002), apresentado um estudo cujo objetivo verificar se os mtodos geis FDD, Scrum, XP, Crystal Family e DSDM atendem os princpios contidos no Manifesto gil. De acordo com a comparao apresentada neste artigo, pode-se concluir que os mtodos geis selecionados para fazerem parte deste estudo apresentam atividades bastante semelhantes em relao aos seus processos de desenvolvimento. Porm, algumas atividades apresentam particularidades, como por exemplo: a programao em dupla, as user stories escritas pelos clientes e a escrita dos testes antes da implementao do XP; as reunies de planejamento, dirias e de reviso adotadas pelo Scrum; as inspees de cdigo de FDD; e as sesses JAD sugeridas pelo ASD. Acredita-se que o presente estudo possibilita aos interessados em utilizar a abordagem gil no desenvolvimento de seus sistemas, obterem uma viso geral das atividades propostas pelos mtodos geis de maneira a auxili-los na escolha de qual mtodo adotar ou mesmo, de reduzir o tempo gasto com estudos sobre mtodos que no se adaptaro as suas necessidades. Entretanto, sugere-se que a equipe que optar pela utilizao de algum dos mtodos apresentados obtenha maiores detalhes sobre as prticas adotadas durante cada uma de suas atividades, bem como dos papis destinados a cada um dos envolvidos no projeto, de maneira a garantir uma maior eficincia em relao aplicao do mtodo. Em (FAGUNDES, 2005) pode-se encontrar uma descrio detalhada de cada um destes mtodos, bem como um framework contendo as atividades sugeridas por cada um dos mtodos de forma a permitir a escolha de quais delas utilizar durante o processo de desenvolvimento de um sistema.

REFERNCIAS
ABRAHAMSSON, P., Salo, O., RONKAINEN, J., & WARSTA, J. Agile Software Development Methods: Review and Analysis. Espoo 2002. VTT Publications 478, 2002.

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.

44

ABRAHAMSSON, P., WARSTA, J., SIPONEN, M.T., & RONKAINEN, J. New Directions on Agile Methods: A Comparative Analysis. In: ICSE 2003, USA AMBLER, S. Modelagem gil: prticas eficazes para a Programao Extrema e o Processo Unificado. Porto Alegre: Bookman, 2004. BECK, K. Extreme Programming Explained. Massachusetts: Addison-Wesley, 2000. BECK, K. et al.Agile Manifesto. 2001. Disponvel em: <http://www.agilemanifesto.org>. Acesso em: 24/01/2008 BEEDLE, M; et al. SCRUM: An extension pattern language for hyperprodutive software development. In: Pattern Languages of Programs'98 Conference, Monticello, 1998. COHN, M. Selecting an Agile Process: Comparing the Leading Alternatives. 2002. Disponvel em: <http://www.mountaingoatsoftware.com/pres/Selecting 021015.pdf.>. Acesso em: 20/01/2008 DE LUCA, J. Feature-Driven Development (FDD) Overview Presentation. 2002. Disponvel em: <http://www.nebulon.com/articles/fdd/download/ fddoverview.pdf >. Acesso em: 10/07/2007 FAGUNDES, P. Framework para Comparao e Anlise de Mtodos geis. Florianpolis: 2005. Dissertao (Mestrado em Cincia da Computao) . Universidade Federal de Santa Catarina, Florianpolis, 2005. FOWLER, M. The New Methodology. 2001. Disponvel em: <http://www.martinfowler.com/articles/newMethodology.html>. Acesso em: 12/12/2007. HIGHSMITH, J. Agile Software Development Ecosystems. Boston: Addison Wesley, 2002. Jeffries, R. XP Magazine Contents: What is Extreme Programming? 2001. Disponvel em: <http://www.xprogramming.com/xpmag/index.htm>. Acesso em: 11/11/2007 RUMBAUGH , J. What Is a Method? Journal of Object Oriented Programming. October, v.26, n. 17 p. 1016, 1995. SOMMERVILLE, I. Engenharia de software. So Paulo: Addison-Wesley, 2003. SCHWABER, K. Scrum Development Process. In: OOPSLA95 Workshop on Business Object Design and Implementation. Springer-Verlag, Atlanta, 1995. SCHWABER, K; BEEDLE, M. Agile Software Development with SCRUM. New Jersey: Prentice Hall, 2002.
1

Segundo Fowler (2001), os mtodos que utilizam processos prescritivos so conhecidos como mtodos tradicionais.
2

WOOD, J.; SILVER, D. Joint Application Development. 2nd ed. New York: Wiley, 1995.

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.

45

Originais recebidos em: 11 fev. 2008. Texto aprovado em: 18 mar. 2008.

SOBRE OS AUTORES
Natural de Pelotas no Rio Grande do Sul. Bacharel em Anlise de Sistemas pela Universidade Catlica de Pelotas UCPEL em 1999 e Mestre em Cincia da Computao pela Universidade Federal de Santa Catarina UFSC em 2005, onde pesquisou sobre os Mtodos geis propondo um Framework para Anlise e Comparao dos Mtodos geis. Atualmente atua como Coordenadora do Curso Superior de Tecnologia em Redes de Computadores e docente no Curso Tcnico de Programao de Computadores na rea de Anlise e Projeto de Software e no Curso de Ps-Graduao em Engenharia de Software com UML na rea de modelagem de negcios e modelagem de requisitos, todos estes oferecidos pela Faculdade de Tecnologia SENAI/SC - Florianpolis. Possui como principal rea de interesse de pesquisa engenharia de requisitos e processo de desenvolvimento de software. E-mail: priscila@ctai.senai.br Possui graduao em Sistemas de Informao - Faculdades Franciscanas (1999) e mestrado em Cincias da Computao pela Universidade Federal de Santa Catarina (2003). Atualmente professora mensalista - Servio Nacional de Aprendizagem Industrial - Departamento Regional de Santa Catarina. Tem experincia na rea de Cincia da Computao, com nfase em Sistemas de Informao. Atua principalmente nos seguintes temas: Engenharia de Software, Linguagem de Programao, Sistemas Tutores Inteligentes, informtica na educao. E-mail: jan@ctai.senai.br Natural de Pelotas no Rio Grande do Sul. Bacharel em Anlise de Sistemas pela Universidade Catlica de Pelotas UCPEL em 1999 e Mestre em Cincia da Computao pela Universidade Federal de Santa Catarina UFSC em 2002, onde pesquisou sobre os Participatory Design na implementao de sistemas de informao para pequenos agricultores. Atualmente atua como docente do Curso de Graduao em Administrao de Empresas da Sociedade Educacional de Santa Catarina - FGV na rea de Tecnologia da Informao, Sistemas de Informao e Anlise e Projeto de Sistemas. Possui como principal rea de interesse de pesquisa em Informtica aplicada educao e o processo de desenvolvimento de software. E-mail: sandro.silva@sociesc.com.br

Priscila Basto Fagundes

Janice Ins Deters

Sandro da Silva dos Santos

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.

46