21 102 2 PB

E-Tech: Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1. sem., 2008.
37
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).

38
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 tradicionais
1
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) A prioridade satisfazer ao cliente atravs de entregas contnuas e freqentes;
b) Receber bem as mudanas de requisitos, mesmo em uma fase avanada do projeto;
c) Entregas com freqncia, sempre na menor escala de tempo.
d) As equipes de negcio e de desenvolvimento devem trabalhar juntas diariamente;
e) Manter uma equipe motivada fornecendo ambiente, apoio e confiana necessrios;
f) A maneira mais eficiente da informao circular atravs de uma conversa face-a-
face;
g) Ter o sistema funcionando a melhor medida de progresso;
h) Processos geis promovem o desenvolvimento sustentvel;
i) Ateno contnua a excelncia tcnica e a um bom projeto aumentam a agilidade;
j) Simplicidade essencial;
k) As melhores arquiteturas, requisitos e projetos provm de equipes organizadas;
l) Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz.

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

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
Definir esboo
dos requisitos
Atribuir requisitos
as iteraes
Projetar arquitetura
do sistema
Desenvolver
incremento do sistema
Validar
incremento
Integrar
incremento
Validar
sistema
Entrega final

40
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 JAD
2
(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 Especificao da Atividade
XP Clientes escrevem as user stories.
Scrum Definio do Product Backlog
FDD Gerao de artefatos para a documentao dos requisitos
ASD 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.

41
Tabela 2 - Atividade - Atribuio dos Requisitos as Iteraes
XP
Equipe tcnica e clientes definem as user stories que sero desenvolvidas
nas iteraes. As iteraes duram de 1 a 4 semanas.
Scrum
Definio do Sprint Backlog. As Sprints (iteraes) duram no mximo 30
dias.
FDD
As caractersticas so agrupadas, priorizadas e distribudas aos responsveis
pelo seu desenvolvimento. As iteraes duram no mximo 2 semanas.
ASD Definio do nmero de iteraes. As iteraes duram de 4 a 8 semanas.
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).

42
Tabela 3 - Atividade - Desenvolver Incremento do Sistema
XP
Implementao das user stories que fazem parte da iterao corrente por
duplas de programadores.
Scrum
Implementao dos requisitos contemplados no Sprint Backlog para a Sprint
corrente.
FDD
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.
ASD Implementao dos requisitos que fazem parte da iterao corrente.
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
XP
Os programadores executam os testes de unidade e os clientes executam os
testes de aceitao.
Scrum O Scrum no adota nenhum processo de validao pr-definindo.
FDD
Os testes e inspees so executados pelos prprios programadores aps a
implementao.
ASD So verificadas a qualidade tcnica e funcional do sistema.
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.

43
Tabela 6 - Atividade - Integrar Incremento
XP A integrao acontece paralelamente ao desenvolvimento das user stories.
Scrum Atividade realizada ao final de cada Sprint.
FDD Atividade realizada aps os testes no incremento.
ASD -
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
XP O sistema disponibilizado ao cliente para que o mesmo realize validaes.
Scrum O cliente valida o sistema integrado em uma reunio no ltimo dia da Sprint.
FDD Esta atividade ocorre atravs das inspees e dos testes de integrao
ASD -
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.

44
Tabela 8 Atividade de Entrega Final
XP Cliente satisfeito com o sistema
Scrum Todos os itens no Product Backlog desenvolvidos
FDD
O sistema entregue aps todos os conjuntos de caractersticas
implementados
ASD Todos os requisitos desenvolvidos.
4 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.


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


46

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

SOBRE OS AUTORES

Priscila Basto
Fagundes

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

Janice Ins Deters

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

Sandro da Silva dos
Santos

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

21 102 2 PB

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

21 102 2 PB

Enviado por

Direitos autorais:

Formatos disponíveis

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

Você também pode gostar