12
1 INTRODUÇÃO
A agricultura representa o norte da economia brasileira. Este setor responde por mais
de um terço do Produto Interno Bruto (PIB) nacional, o que lhe garante uma posição de
vanguarda no desenvolvimento do país. Espera-se que o Brasil se torne a grande potência
exportadora do novo milênio, como tem sido os Estados Unidos nos últimos cem anos e
buscar essa meta será, sem sombra de dúvidas, o grande desafio de todos aqueles que estão
envolvidos com esse segmento da economia – agricultores, universitários, pesquisadores e,
especialmente, a classe política e a própria sociedade brasileira (SILVA, 2010).
Neste cenário, a gestão da informação assume de forma crescente um papel
fundamental no seio das organizações empresariais, permitindo o seu emprego melhorar a
eficiência da utilização dos recursos e atingir níveis de desempenho mais elevados. A
aplicação de sistemas de informações, cobrindo as diversas áreas da produção agrícola
(preparo do solo, plantio, operações de campo como aplicação de defensivos e fertilizantes,
estoque de insumos e materiais), faz com que a gestão se torne mais flexível e proativa, sendo
promotora da obtenção de vantagens competitivas permitindo, quando bem utilizada, obter
ganhos de eficiência inquestionáveis. Por outro lado, as Tecnologias de Informação e
Comunicação (TIC), enquanto instrumentos de suporte ao processo de gestão da informação
favorecem a adoção e utilização de tecnologias de precisão, como os Sistemas de
Posicionamento Global (GPS), os Sistemas de Informação Geográfica (SIG) e as redes de
sensores sem fios. Favorece também, à adoção da agricultura de precisão, que permite reduzir
os custos, aumentar a produção, ajustar os “inputs” às necessidades do solo e das culturas,
aumentar os rendimentos e reduzir os impactos ambientais, no que se convencionou
denominar de agricultura de precisão (AJAP, 2007).
De fato, na atividade agrícola em particular, a importância que o recurso informação
tem vindo a ganhar deve-se, essencialmente, à complexidade de uma atividade onde a
incerteza associada à variabilidade climática, à variabilidade das características espaciais e à
diversidade das plantas e animais utilizados, é proporcionalmente maior do que outros ramos
de atividade. Esta complexidade é ainda acrescida por uma forte regulamentação subjacente
ao enquadramento político e legal induzido pelo forte apelo ambiental a que é submetido este
setor (idem).
A Fazenda Seis Irmãos, localizada no município de Riachão-MA, como o próprio
nome já informa, é formada por seis irmãos e suas famílias que vieram, a 28 anos, do estado
13
do Rio Grande do Sul em busca de novas oportunidades. A principal motivação foi o preço
baixo e quantidade de terras a disposição na região sul do maranhão. Atualmente, a fazenda
possui 6.500 hectares e uma produção de aproximadamente 22 mil toneladas de grãos de soja
e milho.
Nas últimas décadas devido ao crescimento do agronegócio na região, e da própria
Fazenda Seis Irmãos, o modelo tradicional de administração, através das anotações em papel,
não suportou o grande volume de informações que deveriam ser geridas, passando a utilizar a
tecnologia de informação para apoiar as decisões. Inicialmente foram adotadas planilhas
eletrônicas para o controle de todos os processos produtivos e administrativos.
Em um segundo momento, no ano de 2006, as planilhas eletrônicas já não
conseguiam suprir a complexidade que o negócio exigia, surgindo à necessidade da utilização
de softwares específicos para tal. Buscaram-se no mercado diversos softwares para a gestão,
que resultassem em um bom custo-benefício, dos quais dois foram testados, mas sem os
resultados esperados.
Diante destas considerações, teve-se como objetivo desenvolver um protótipo de um
Sistema de Informações Web que possibilite a gestão e controle dos processos agrícolas na
Fazenda Seis Irmãos, localizada em Riachão-MA.
Esta monografia está organizada da seguinte forma: O capítulo 2 trata das
características e complexidades da produção agrícola e aborda o planejamento, organização e
controle dos processos de produção bem como a situação do mercado de software no
agronegócio. O capítulo 3 apresenta uma visão sobre o processo de desenvolvimento de
software, o modelo de desenvolvimento ágil e o método Feature Driven Development (FDD)
utilizados neste trabalho para o desenvolvimento do software para a gestão da produção
agrícola. No capítulo 4 estão descritas as principais tecnologias utilizadas para a
implementação como o Framework .NET, a linguagem de programação CSharp (C#) e o
framework ASP.NET AJAX Control Toolkit. O capítulo 5 apresenta os materiais e métodos
utilizados. O capítulo 6 demostra como o software foi implementado 1 e as suas principais
características, assim como algumas considerações acerca da necessidade de seu
desenvolvimento. E por fim, no capítulo 7 são apresentadas as conclusões da monografia.
1
O termo implementar e implantar possui significados distintos nas áreas de sistemas de informação e
agricultura. Na agricultura "implantar" marca o início (a execução) de uma ação, enquanto "implementar"
expressa a continuidade (o prosseguimento). Diz-se que um projeto foi implementado quando já está em
funcionamento por mais de um ciclo do processo em que está inserido(uma, safra, por exemplo). Em sistemas de
informação a implementação vem primeiro (codificação do software) e em seguida a sua implantação (fase de
produção, ou utilização do software pelo cliente).
14
2 GESTÃO DA PRODUÇÃO AGRÍCOLA
Desde que o ambiente rural passou a ser investigado com maior interesse, o
tradicional setor primário (agricultura – pecuária – extrativismo) tem se transformado em
agronegócio (diversificado – moderno – complexo). As propriedades rurais agora são
entendidas como organizações agroindustriais. A conotação profissional dada ao termo
agronegócio é responsável por uma mudança de paradigma sem precedentes no meio rural e
admite a existência de uma série de novas modalidades de empreendimentos. Esta maior
complexidade tem exigido a configuração de uma visão sistêmica sobre gestão no
agronegócio, que dizem respeito principalmente às suas características de produção
(CALLADO, 2009).
2.1 Características da Produção na Agricultura
Ao contrário do setor urbano (indústria e comércio), a agricultura sofre a
interferência de uma série de fatores que são próprios do setor rural. Assim, a tarefa de
produzir alimentos não é uma atividade de fácil execução em qualquer parte do mundo. O
setor está sob influência direta de condições que apresentam riscos e incertezas inerentes à
atividade agrícola devido às condições do ambiente onde a atividade está inserida. A análise e
o conhecimento desse cenário são de suma importância para que o empresário rural possa
definir com segurança as estratégias para sua empresa, visando ao uso racional de todos os
fatores de produção disponíveis (SILVA, 2010).
Mário Otávio Batalha (2007a), coordenador do Grupo de Estudos e Pesquisas
Agroindustriais (GEPAI), cita as variações climáticas, à sazonalidade da produção, à
perecibilidade2 dos produtos, ao ciclo biológico dos animais e vegetais e ao desempenho
natural alcançado no empreendimento como principais dificuldades encontradas na produção.
Além destas particularidades, observa-se que a comercialização dos produtos é bastante
específica em razão de os preços dos produtos agrícolas, em geral, oscilarem muito em função
de pequenas variações na oferta. Todos estes fatores são muitos importantes e praticamente
não fazem parte da gestão de outros tipos de empreendimentos.
2
De acordo com o dicionário Houaiss da Língua Portuguesa significa a qualidade ou característica do que é
perecível.
15
As variáveis que influenciam sobre a atuação da empresa rural devem ser seriamente
analisadas no momento da realização do planejamento agrícola e sua execução. Roni Antônio
Garcia da Silva (2010) classifica essas variáveis em incontroláveis e controláveis:

Variáveis Incontroláveis
a) Do ambiente externo ou macro ambiente
i) Legislação;
ii) Movimentos demográficos;
iii) Movimentos sociais;
iv) Desenvolvimento tecnológico;
v) Clima (temperatura, umidade relativa, chuvas, secas, geadas etc.);
vi) Religião (proibições, dogmas, preconceitos etc.);
vii) Questões sobre ecologia (levantadas, por exemplo, por Organizações Não
Governamentais – ONGs) e regionalismos.
b) Do ambiente operacional
i) Fornecedores (de capital, mão-de-obra, insumos etc.);
ii) Concorrentes (diretos e indiretos);
iii) Clientes;
iv) Sindicatos;
v) Intermediários (transportadoras, seguradoras, bancos etc.);
vi) Grupos regulamentadores (associações etc.)

Variáveis Controláveis
a) Objetivos empresariais;
b) Estrutura da empresa;
c) Tecnologia adotada;
d) Tarefas a executar;
e) Pessoal.
Observa-se que as principais dificuldades na produção citadas por Mário Otávio
Batalha são classificadas como variáveis incontroláveis e que no planejamento e controle das
operações agrícolas todas as ações tomadas visam atingir somente as variáveis controláveis.
Portanto, busca-se através de um sistema de informações, quando aplicado, facilitar e otimizar
este planejamento e controle.
16
2.2 Planejamento, Organização e Controle das Operações Agrícolas
Segundo Mário Otávio Batalha (2007a), Planejamento e Controle da Produção (PCP)
é um sistema de informações que se estrutura para obter dados, processá-los e avaliá-los. O
planejamento trata de problemas não estruturados de longo prazo, e que dão margem às
grandes decisões da empresa, ou seja, as decisões de caráter estratégico, como por exemplo,
redução de custos, incorporação de novas tecnologias, aquisição de terras. Já o controle trata
dos problemas semiestruturados e estruturados. Os problemas semiestruturados são
considerados de médio prazo, e dão margem às decisões de caráter tático, como a quantidade
de mão-de-obra necessária para a produção, quantidade mínima em estoque de insumos e
produtos e quantidade de máquinas necessárias. Já os problemas estruturados dão origem às
decisões de caráter operacional, para aplicação no curto prazo, como a programação do uso de
recursos produtivos, detalhando onde, como e quando cada recurso será ou foi utilizado.
O planejamento empresarial rural deve ser elaborado levando em conta sempre o
conceito de unidade de produção, ou seja, uma área de terra onde se realiza a produção seja
ela, uma estância, sítio, chácara, granja, fazenda, ou até mesmo uma simples gleba, e sempre
deve buscar aliar os recursos internos e externos de modo a atingir um ponto de equilíbrio
entre os dois. O planejamento atua nos três níveis administrativos: Estratégico, gerencial e
operacional. No nível estratégico, busca determinar os objetivos da empresa, como por
exemplo, aumentar a produtividade de soja de 2.500 kg.ha-1 para 3.000 kg.ha-1. Busca também
fazer uma análise interna da empresa e do ambiente, assim como a geração, avaliação e
seleção das alternativas estratégicas. O planejamento gerencial tem como responsabilidade
fazer o “meio de campo” entre os níveis estratégico e operacional, como gerar a relação custo
benefício sobre as decisões estratégicas e impactos no ambiente operacional. No nível
operacional o planejamento é totalmente voltado para a empresa em si e se refere a como
conduzir cada exploração, como por exemplo, as datas previstas para aplicações de
fertilizantes corretivos, quem irá aplica-los, com que máquinas e implementos e a dose do
produto (SILVA, 2010).
Antes de se efetivar o planejamento, devem-se considerar suas diferentes etapas:
implantação; produção e colheita; reposição de recurso e/ou recomposição do solo. Cada uma
das etapas tem que ser subdividida em tarefas e para cada tarefa é necessário descrever os
recursos de produção necessários, podendo, este processo, ser feito através de um
planejamento semanal de atividades (BATALHA, 2007a).
17
Uma vez formulados os planos e os objetivos, a administração deve desenvolver um
modo organizado de reunir os recursos físicos e humanos que são essenciais à realização das
metas da empresa, assim como controlar os seus resultados. No caso da empresa rural, as
organizações mais comumente usadas são por produto (ou atividade) e por base territorial. A
por produto consiste em estruturar a empresa por setores (fruticultura, culturas anuais,
bovinos, suínos, etc.), enquanto que a organização por base territorial, em fazenda A, fazenda
B, fazenda C etc., normalmente encontrada em grandes propriedades (SILVA, 2010).
Da mesma forma, o controle pode ser aplicado a todos os níveis de organização
escolhida, seja ela, por produto ou por base territorial, pois cabe a ela devolver as informações
ao planejamento a fim de que o ciclo administrativo tenha continuidade, de acordo com o que
foi planejado. A atividade de controle apresenta quatro fases distintas: estabelecimento de
padrões; mensuração do desempenho; comparação do desempenho obtido com o esperado; e
ação corretiva, se necessário. Igualmente às demais funções administrativas, o controle pode
ser feito em nível estratégico, onde se procura avaliar o desempenho global da empresa
(relatórios contábeis, controle de lucros e perdas); gerencial – avalia-se cada unidade,
departamento ou divisão; e operacional – cuida-se do nível mais baixo da empresa, dando a
cada tarefa uma visão de curto prazo (ibidem).
Observa-se que é no controle das operações agrícolas que muitas das tecnologias
utilizadas na agricultura atuam, como o recolhimento das informações de produtividade nas
máquinas equipadas com o Sistema de Posicionamento Global (GPS), para a elaboração de
mapas de produtividade, na análise e correção de solo como o Sistema Inteligente de Apoio à
Produção (SAGRI) desenvolvido pela Empresa Brasileira de Pesquisa Agropecuária
(EMBRAPA), além de outras tecnologias que atuam em áreas bem específicas como a análise
de imagens por satélite para determinar irregularidades de fertilidade de solo e focos de
pragas que não podem ser vistas a campo.
2.3 Softwares Aplicados ao Agronegócio
A resistência do produtor à adoção de inovações tecnológicas é comum a grande
parte dos empreendimentos rurais, mesmo quando estas alterações são técnica ou
economicamente necessárias. Esta situação está gradativamente sendo alterada, em razão do
crescente nível de exigência dos mercados consumidores formados pela agroindústria e pelos
canais de distribuição. A adoção de tecnologia se apresenta como uma necessidade para a
permanência na atividade (BATALHA, 2007b).
18
Segundo a Embrapa Informática Agropecuária (2009), através de uma pesquisa
realizada com 124 empresas ofertantes de software para a agropecuária, verifica-se que cerca
de 88% das empresas estão instaladas nas regiões sul e sudeste, em especial na última, com
mais de 63%, conforme Tabela 1.
Tabela 1 – Distribuição das Empresas Ofertantes de software para a
Agropecuária Segundo Região e Unidade da Federação de
Localização da Sede
Região
Total
%
Estado
%
São Paulo
34,7%
Minas Gerais
25,0%
Sudeste
79
63,7%
Rio de Janeiro
2,4%
Espírito Santo
1,6%
Paraná
12,1%
Sul
30
24,2%
Rio Grande do Sul
7,3%
Santa Catarina
4,8%
Mato Grosso
3,2%
Mato Grosso do Sul
1,7%
Centro-Oeste
9
7,3%
Goiás
1,6%
Distrito Federal
0,8%
Pernambuco
3,2%
Sergipe
0,8%
Nordeste
6
4,8%
Ceará
0,8%
TOTAL
TOTAL
124
100%
100%
Fonte: Embrapa Informática Agropecuária (2009)
Observa-se na Tabela 2, que apesar de haver empresas desenvolvedoras de software
para o agronegócio em 65 municípios, um quarto delas estão instaladas em apenas quatro
municípios e quase metade (49%) em 10 municípios, notadamente no eixo sul-sudeste (com
exceção de Recife entre as 10 primeiras), com destaque para o estado de São Paulo, com
cinco municípios.
O estudo da Embrapa Informática Agropecuária (2009) mapeou um total de 180
empresas no Brasil ofertantes de softwares para o agronegócio, o que representa menos de
2,5% das 7.936 empresas declaradas pela Associação Brasileira das Empresas de Software
(ABES) como integrante da indústria de software. Considerando o número de empresas de
software mapeadas e a quantidade de estabelecimentos agropecuários identificada no Censo
Agropecuário (IBGE, 2006), existem por volta de 25 mil estabelecimentos agropecuários para
cada empresa ofertante de software para o agronegócio no Brasil.
19
Tabela 2 – Distribuição das Empresas Ofertantes de Software para a
Agropecuária Segundo Município de Localização da Sede.
% de Empresas em
Município
Total de
Relação ao Total do
%
Empresas
País
Acumulada
Viçosa
11
8,9%
8,9%
Belo Horizonte
9
7,3%
16,1%
São Paulo
7
5,6%
21,8%
Campinas
7
5,6%
27,4%
Curitiba
6
4,8%
32,3%
Piracicaba
5
4,0%
36,3%
Porto Alegre
5
4,0%
40,3%
Recife
4
3,2%
43,5%
São Carlos
4
3,2%
46,8%
Ribeirão Preto
3
2,4%
49,2%
Goiânia
2
1,6%
50,8%
Rio de Janeiro
2
1,6%
52,4%
Assis
2
1,6%
54,0%
Cuiabá
2
1,6%
55,6%
Juiz de Fora
2
1,6%
57,3%
Londrina
2
1,6%
58,9%
Florianópolis
2
1,6%
60,5%
Uberlândia
2
1,6%
62,1%
Outros Municípios
47
37,9%
100,0%
Fonte: Embrapa Informática Agropecuária (2009)
Hoje no mercado, existem diversos tipos de tecnologias aplicadas ao agronegócio,
bem como sistemas de planejamento e controle de operações agrícolas, sistemas de controle
de frotas, sistemas geográficos de informações, sistemas online de apontamentos de produção,
sistemas de manutenção automotiva e industrial, sistemas de custos agrícolas, sistemas de
pagamentos de contratos e muitas outras tecnologias de gestão como sistemas Enterprise
Resouce Planning (ERP) e os Sistemas Integrados de Gestão Corporativa (SIGC) (PAULINO,
2009).
Os 405 softwares declarados pelas empresas no estudo da Embrapa Informática
Agropecuária (2009) foram divididos em 4 categorias (Tabela 3), que se subdividem em áreas
de aplicação. Como os produtos podem ser aplicados a mais de uma área de aplicação, tal
recontagem faz com que a Tabela 3 some mais de 405 softwares. As áreas de aplicação dos
produtos listadas na Tabela 3 foram ordenadas segundo aquelas que mais têm softwares
declarados pelas empresas, deixando claro que no setor administrativo e gerencial encontramse mais soluções em tecnologia da informação com 363 softwares.
20
Tabela 3 – Distribuição dos Softwares Segundo Categorias e Áreas de Aplicação.
Total de
Total de
Categoria
Área de Aplicação
Softwares
Softwares
Administração rural
151
Gerenciamento de insumos
139
Comercialização
113
Base de dados
111
Administração /
363
Gerenciamento
Contabilidade
97
Gerenciamento/manutenção de
94
maquinário e equipamentos
Gerenciamento de pessoas
64
Rastreabilidade
82
Adubação e calagem
63
GIS/GPS (geoprocessamento)
60
Agricultura de precisão
47
Pós-colheita, processamento e
39
armazenamento
Receituário agronômico
39
Manejo florestal/reflorestamento
38
Mecanização
38
Pecuária de precisão
37
Solos (análise química e física)
37
Agrimensura/topologia
35
Controle de Processos
Previsão de safra
34
325
e/ou Atividade Rurais
Irrigação
31
Manejo ambiental
31
Manejo integrado de pragas
26
Genético
25
Automação agropecuária
24
Inventário florestal
22
Agrometeorologia
20
Instrumentação agropecuária
18
Receituário veterinário
13
Zoneamento agrícola
12
Bioinformática
4
Fitossanidade
4
Fonte: Embrapa Informática Agropecuária (2009)
21
Tabela 3 (Continuação) – Distribuição dos Softwares Segundo Categorias e Áreas de
Aplicação.
Total de
Total de
Categoria
Área de Aplicação
Softwares
Softwares
Soja
84
Milho
77
Açúcar e álcool
76
Café
71
Frutas
64
Trigo
62
Algodão
62
Feijão
62
Cultivo Vegetal
288
Eucalipto
59
Arroz
58
Sistemas agroflorestais
57
Girassol
50
Hortaliças
48
Mamona
45
Dendê
35
Floricultura
23
Bovinos de corte
66
Bovinos de leite
55
Suínos
40
Ovinos (ovelhas)
30
Caprinos (cabras)
28
Aves
23
Manejo Animal
280
Bubalinos (búfalos)
23
Equídeos (cavalo, burro, jumento,
23
mula)
Peixes
14
Frutos do mar (camarão, ostra, etc.)
8
Abelhas
4
Fonte: Embrapa Informática Agropecuária (2009)
Destes 405 softwares que compõem os principais utilizados no agronegócio
brasileiro se observa ainda que cerca de 35% utilizam a linguagem de programação Delphi e
outros 21,1% utilizam Java. É principalmente através destas duas linguagens rodando em
interface gráfica (89%) em ambiente Windows (Tabela 4) que são disponibilizadas a maioria
das soluções para o agronegócio. Em comparação, os softwares que utilizam interface web,
utilizando principalmente ASP e PHP, ocupam 28% dos softwares (EMBRAPA
INFORMÁTICA AGROPECUÁRIA, 2009).
22
Tabela 4 - Distribuição dos Softwares Segundo Plataforma
Plataforma
% dentre os softwares próprios
Windows XP
69,1%
Windows 2000
62,6%
Windows ME
50,4%
Windows 98
48,4%
Outros
22,6%
Linux
13,9%
Unix
7,7%
MS-DOS
3,9%
Free BSD
3,6%
OS/2
1,5%
Fonte: Embrapa Informática Agropecuária (2009)
Há no mercado atualmente uma tendência de migrar diversas aplicações que antes só
eram possíveis em nível de desktop para a nuvem, ou melhor, para servidores espalhados pelo
mundo e acessíveis via rede mundial de computadores. De acordo com a Associação
Brasileira das Empresas de Software (ABES) (2010), a computação em nuvem é umas das
grandes tendências dos próximos anos, sendo que a oferta destes serviços deve crescer 45%
em 2010 e triplicar nos próximos cinco anos. Esta tendência também deverá atingir o
agronegócio, em que os softwares com esta tecnologia, como o proposto por este trabalho,
tenderão a ser mais competitivos.
Neste cenário, o desenvolvimento de softwares de qualidade passa a ter enorme
importância, à medida que a quantidade não supera a qualidade. Para se alcançar a qualidade e
suprir as necessidades dos clientes, normalmente são utilizados técnicas e métodos de
desenvolvimento que englobam um único conceito chamado de engenharia de software.
23
3 ENGENHARIA DE SOFTWARE
A Engenharia de Software se preocupa com o software enquanto produto. Como todo
produto industrial, o software tem um ciclo de vida: ele é concebido a partir da percepção de
uma necessidade; desenvolvido, transformando-se em um conjunto de itens entregue a um
cliente; entra em operação, sendo usado dentro de um algum processo de negócio, e sujeito a
atividades de manutenção, quando necessário; é retirado de operação, ao final de sua vida útil
(PAULA FILHO, 2009).
Todo projeto é iniciado por alguma necessidade do negócio – a necessidade de
corrigir um defeito em uma aplicação existente; a necessidade de adaptar um sistema legado
para mudar um ambiente do negócio; a necessidade de estender as funções e características de
uma aplicação existente; ou a necessidade de criar um novo produto, serviço ou sistema.
Efetivamente, a elaboração de software de computador é um processo iterativo de
aprendizado, e o resultado, é uma incorporação de conhecimentos coletados, destilados e
organizados, à medida que o processo é conduzido (PRESSMAN, 2006).
O autor Paula Filho (2009, p. 23) comenta sobre a função do processo na engenharia
de software:
Em engenharia de software, processos podem ser definidos para atividades como
desenvolvimento, manutenção, aquisição e contratação de software. Podem-se
também definir subprocessos para cada um desses; por exemplo, um processo de
desenvolvimento abrange subprocessos de determinação dos requisitos, análise,
desenho, implementação e testes. Em um processo de desenvolvimento de software,
o ponto de partida para a arquitetura de um processo é a escolha de um modelo de
ciclo de vida ou método de engenharia de software.
Um método de engenharia de software é uma abordagem estruturada para o
desenvolvimento de software, cujo objetivo é facilitar a produção de software de alta
qualidade, apresentando uma boa relação custo-benefício (SOMMERVILLE, 2003).
Segundo Figueiredo (2005), a expansão vertiginosa do uso de Sistemas Web na
última década e seu uso como ferramenta de negócio colocou grande pressão sobre o
desenvolvimento de software, exigindo entrega de resultado tangível cada vez mais rápido,
num ambiente altamente instável e dinâmico. Em resposta a essas necessidades, surgiu uma
nova classe de metodologias de desenvolvimento de software, conhecidas como Metodologias
Ágeis.
24
3.1 Desenvolvimento Ágil
A metodologia de desenvolvimento ágil foi utilizada pela primeira vez em 1997, mas
só foi lançada em 1999. Mais tarde em 2001, Kent Beck e 16 outros notáveis
desenvolvedores, produtores e consultores de software assinaram o “Manifesto para o
Desenvolvimento Ágil de Software”, e através deste manifesto eles declararam que estavam
descobrindo melhores modos de desenvolvimento de software. Por meio deste trabalho eles
ficaram conhecidos como “Aliança Ágil”, sendo que com esta nova metodologia eles
passaram a valorizar (MANIFESTO, 2001, on-line):

Indivíduos e interações em vez de processos e ferramentas.

Softwares funcionando em vez de documentação abrangente.

Colaboração do cliente em vez de negociação de contratos.

Resposta a modificações em vez de seguir um plano.
Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda
(idem).
Segundo Nascimento (2008), “para um processo ser considerado ágil, ele deve
realizar um conjunto de tarefas e seguir disciplinadamente um conjunto de regras, definidas
pela metodologia. O não cumprimento dessas premissas, muitas vezes, faz com que um
processo deixe de ser ágil para tornar-se “caótico”. Portanto, o termo “ser ágil” não significa
negligenciar as atividades de engenharia de software, e sim praticá-las de forma diferente da
tradicional”.
A Aliança Ágil define 12 princípios para aqueles que querem alcançar agilidade
(MANIFESTO, 2001, on-line):
1. Nossa maior prioridade é satisfazer ao cliente desde o início por meio de entrega contínua
de software valioso.
2. Modificações de requisitos são bem vindas, mesmo que tardias no desenvolvimento. Os
processos ágeis aproveitam as modificações como vantagens para a competitividade do
cliente.
3. Entrega de softwares funcionando frequentemente, a cada duas semanas até dois meses,
de preferência no menor espaço de tempo.
4. O pessoal de negócio e os desenvolvedores devem trabalhar juntos diariamente durante
todo o projeto.
25
5. Construção de projetos em torno de indivíduos motivados. Forneça-lhes o ambiente e
apoio que precisam e confie que eles farão o trabalho.
6. O método mais eficiente e efetivo de levar informação para e dentro de uma equipe de
desenvolvimento é a conversa face a face.
7. Software funcionando é a principal medida de progresso.
8. Processos
ágeis
promovem
desenvolvimento
sustentável.
Os
patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante,
indefinidamente.
9. Atenção contínua a excelência técnica e ao bom projeto facilitam a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não efetuado – é essencial.
11. As melhores arquiteturas, requisitos e projetos surgem de equipes auto organizadas.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva, então
sintoniza e ajusta adequadamente seu comportamento.
Várias foram os modelos ágeis de processo que surgiram, como Extreme
Programming (XP), Desenvolvimento Adaptativo de Software (Adaptative Software
Development - ASD), Método de Desenvolvimento Dinâmico de Sistemas (Dynamic Systems
Development Method - DSDM), Scrum, Crystal, Desenvolvimento Guiado por Características
(Feature Driven Development - FDD), Modelagem Ágil (Agile Modeling - AM), entre outros.
Há muitas semelhanças (em filosofia e prática) entre essas abordagens. É importante notar
que todos os modelos ágeis satisfazem (em menor ou maior grau) ao Manifesto para o
Desenvolvimento Ágil de Software e aos 12 princípios da Aliança Ágil (PRESSMAN, 2006).
O XP é o processo ágil mais amplamente usado. Organizado como quatro atividades
de arcabouço – planejamento, projeto, codificação e testes –, o XP sugere um número de
técnicas inovadoras e potentes que permitem a equipes ágeis criar frequentemente versões de
software que possuem características e funcionalidades descritas e priorizadas pelo cliente.
Trabalha em função de estórias, que são descritas e priorizadas pelo cliente. No momento de
sua implementação, a equipe pode fazer estimativas de custo de cada estória e planejar as
releases3 e as iterações. Ao final de cada iteração é obtido um feedback do cliente e, com isso,
pode-se planejar a próxima iteração. Ao final de cada ciclo é entregue uma versão funcional
do software e o planejamento para o próximo release é realizado. A metodologia dá grande
importância para testes e integração. Antes de qualquer implementação, um teste
automatizado deve ser codificado, para que imediatamente após a codificação de alguma
3
Um realease é um conjunto de iterações responsável pela produção de uma versão do software
26
funcionalidade, ela possa ser validada. Além disso, XP sugere que a integração do sistema
seja feita várias vezes ao dia, evitando complicações na hora de integrar as novas estórias
desenvolvidas (NASCIMENTO, 2008).
O Desenvolvimento Adaptativo de Software (ASD) ressalta a colaboração humana e
a auto-organização da equipe. Organizado como três atividades de arcabouço – especulação,
colaboração e aprendizado – o ASD é um processo iterativo que incorpora planejamento do
ciclo adaptativo, métodos relativamente rigorosos para o levantamento de requisitos e um
ciclo de desenvolvimento iterativo que incorpora grupos enfocados nos clientes e revisões
técnicas formais como mecanismos de feedback em tempo real. O Método de
Desenvolvimento Dinâmico de Sistemas (DSDM) define três diferentes ciclos iterativos –
iteração do modelo funcional, iteração de projeto e construção e implementação – precedidos
por duas atividades de ciclo de vida adicionais – estudo de viabilidade e estudo de negócio. O
DSDM recomenda o uso de cronogramação a cada intervalo de tempo e sugere que, em cada
incremento de software, é necessário apenas o trabalho suficiente a fim de facilitar o avanço
para o incremento seguinte (PRESSMAN, 2006).
A metodologia Scrum sugere a existência de equipes multidisciplinares e autoorganizáveis. Para isso, os indivíduos que compõem as equipes não possuem funções fixas.
Todos os membros devem ter uma visão global do projeto e a equipe deve ser capaz de autoorganizar-se para atingir os objetivos pretendidos. O Scrum utiliza um processo que incorpora
as seguintes atividades de arcabouço: requisitos, análise, projeto, evolução e entrega. Em cada
atividade de arcabouço, as tarefas ocorrem dentro de um processo chamado sprint. O trabalho
conduzido dentro de um Sprint (a quantidade de sprints necessária para cada atividade de
arcabouço varia dependendo da complexidade e do tamanho do produto) é adaptado ao
problema em mãos e é definido e, frequentemente, modificado em tempo real pela equipe
Scrum (idem).
Segundo Nascimento (2008), Crystal é uma família de processos aplicáveis a
diferentes tipos de projetos. A ideia de ter múltiplos processos origina-se do fato de existir
projetos que exigem diferentes níveis de controle. A metodologia Crystal funciona
adequando-se a criticalidade e tamanho de um projeto, caso esses aspectos variem. Se um
projeto aumenta de tamanho ou de nível crítico, mais processos Crystal podem ser
adicionados a ele, e vice-versa. Em resumo, a família de processos Crystal pode ser
classificada como uma metodologia ágil que possui um ciclo de desenvolvimento
incremental, altamente adaptável, podendo adequar-se a diversos tipos e tamanhos de
projetos, e altamente escalável, podendo trabalhar com equipes grandes ou pequenas.
27
A Modelagem Ágil (AM) sugere que a modelagem é essencial para todos os
sistemas, mas que a complexidade, tipo e tamanho do modelo devem estar sintonizados com o
software a ser construído. Por meio da prototipação de um conjunto de princípios de
modelagem centrais e suplementares, a AM fornece um guia útil para os profissionais durante
as tarefas de análise e do projeto (PRESSMAN, 2006). O Desenvolvimento Guiado por
Características (FDD) é algo mais formal do que os outros métodos ágeis, mas ainda mantém
a agilidade por concentrar a equipe no conceito de projetar e implementar por
funcionalidades. No contexto do FDD, uma característica “é uma função valorizada pelo
cliente que pode ser implementada em duas semanas ou menos” (PRESSMAN, 2006 apud
DELUCA et al, 1999). Nesta monografia se optou por utilizar e adaptar o método FDD a uma
pequena4 equipe de desenvolvimento de modo que as suas etapas sejam acompanhadas de
perto facilitando a dispersão de informações a cerca do andamento do projeto e verificação de
mudanças e/ou adaptações às funcionalidades. Isto torna as atividades altamente
colaborativas, sendo esta uma característica do FDD. O modelo proposto se encaixa
perfeitamente ao modelo de negócio dos processos agrícolas sendo divididos em
funcionalidades bem definidas e às frequentes adaptações a cada safra, de modo a necessitar
de um ciclo contínuo de desenvolvimento através das iterações, que neste caso poderão ser
reativadas mesmo depois da funcionalidade ter sido entregue.
3.2 Desenvolvimento Guiado por Características
A metodologia de Desenvolvimento Guiado por Características - Feature Driven
Development (FDD) foi criada por Jeff De Luca e Peter Code como um modelo prático de
processo para engenharia de software orientada a objetos. Mais tarde, Stephen Palmer e John
Felsing publicaram uma versão aprimorada e detalhada da metodologia. FDD é uma
metodologia ágil voltada a entregas frequentes de versões do software. Para isso, utiliza-se de
um processo de desenvolvimento incremental e enfatiza mecanismos de controle e divulgação
de informações sobre o projeto (NASCIMENTO, 2008 apud Feature-driven Development
Web Site, 2006).
Todas as atividades técnicas e gerenciais em FDD baseiam-se em funcionalidades,
ou seja, em requisitos do sistema com valor percebido pelo cliente. O planejamento do
4
A equipe de desenvolvimento será formada por apenas três pessoas: Uma pessoa responsável por todos os
processos de desenvolvimento e duas para gerar e avaliar as regras de negócio.
28
projeto, a ocupação técnica de atividades, o controle de andamento e divulgação de resultado
do projeto se dá através de funcionalidades (FIGUEIREDO, 2005).
Segundo Pressman (2006), a ênfase na definição de características fornece os
seguintes benefícios:

Como as características são pequenos blocos de funcionalidade passíveis de entrega, os
usuários podem descrevê-las mais facilmente, entender como elas se relacionam umas
com as outras prontamente e revisá-las melhor quanto a ambiguidades, erros ou omissões.

As características podem ser organizadas em um agrupamento hierárquico relacionado ao
negócio.

Como uma característica é um incremento de software passível de entrega do FDD, a
equipe desenvolve características operacionais a cada duas semanas.

Como as características são pequenas, suas representações de projeto e de código são
mais fáceis de inspecionar efetivamente.

Planejamento de projeto, cronogramação e monitoração são guiados pela hierarquia de
características em vez de por um conjunto de tarefas de engenharia de software
arbitrariamente adotado.
Os processo proposto por FDD consiste de cinco etapas que cobrem as fases de
modelagem e implementação do software. As três primeiras são feitas no início do projeto
instituindo um planejamento de nível médio, as duas últimas são repetidas iterativamente para
construir o planejado (BASSI FILHO, 2008). As etapas do processo FDD, conforme Figura 1,
são:

Desenvolver um Modelo Global: Nessa fase, os especialistas do domínio direcionam a
atenção para o escopo, o contexto e os requisitos do sistema a ser desenvolvido. Alguns
documentos podem ser produzidos, além da visão global do projeto, para auxiliar a
elicitação dos requisitos. Em seguida, este modelo é subdividido para que pequenos
grupos formados por especialistas de negócio e desenvolvedores abordem cada uma das
partes para chegar à modelagem de objetos. Por fim, os objetos são reunidos, revisados e
integrados para chegar à versão inicial do modelo de objetos do sistema.

Construir uma Lista de Características: Baseado nas explicações dos especialistas de
negócio, nos artefatos da especificação e no modelo de objetos criado na fase anterior, é
identificada uma lista de funcionalidades com valor de negócio que compreende todo o
escopo do projeto. No fim, clientes e usuários revisam e validam a listagem.
29

Planejar por Característica: Visa criar um planejamento de alto nível para todo o
projeto. Os gerentes e programadores chefes definem a ordem em que as funcionalidades
serão implementadas baseadas no valor de negócios, dependências e volumes de trabalho.
As funcionalidades podem ser agrupadas para formar versões potencialmente entregáveis
e as classes do modelo atribuídas aos programadores, que passam a ser chamados de
donos dessas classes.

Projetar por Característica: Os programadores chefes selecionam conjuntos de
funcionalidades para formar pacotes de trabalho com duração de dois dias a duas
semanas. Para cada pacote de funcionalidades, os programadores donos das classes
envolvidas são convocados para integrar a equipe. Dessa forma, diversas pequenas
equipes trabalham em paralelo sob o comando de um programador chefe. Se precisar o
modelo de objetos é refinado para comportar as funcionalidades de cada pacote.

Construir por Característica: Para cada funcionalidade do pacote, a equipe implementa,
testa e inspeciona o código. Quando o programador chefe autoriza, as funcionalidades são
integradas ao repositório principal e novos pacotes e equipe são formados pelo
programador chefe para a próxima iteração.
Figura 1: Ciclo de vida de Feature Driven Development
Fonte: NASCIMENTO, 2008 apud ABRAHAMSSON et al., 2002.
A
metodologia
de
desenvolvimento
ágil
enfatiza
uma
abordagem
de
desenvolvimento simples que incorpora ciclos rápidos de desenvolvimento. Esta metodologia
esta sendo utilizada principalmente para a engenharia de sistemas baseados na web. Este tipo
de engenharia de software voltada para sistemas web está sendo chamada de WebE (Web
Engineering). Processos e métodos como o FDD, e tecnologias web (ferramentas) fornecem
uma abordagem em camadas para WebE que é conceitualmente idêntica às camadas de
software tradicionais (PRESSMAN, 2006). De certa forma, a Engenharia da Web pode ser
considerada como uma subárea independente da Engenharia de Software, responsável pelo
30
estudo de abordagens sistemáticas e quantificáveis aplicadas ao desenvolvimento, operação e
manutenção de aplicações Web (ZANIRO, 2008 apud KAPPEL et al., 2006).
Depois de escolhidas às metodologias de desenvolvimento, parte-se para a escolha
das ferramentas, de maneira mais específica, a linguagem de programação e o ambiente de
desenvolvimento. Estas escolhas dependem muito da equipe de trabalho e do ambiente em
que o futuro sistema irá operar.
31
4 FERRAMENTAS DE DESENVOLVIMENTO
Existem no mercado várias tecnologias para aplicações web como exemplo de
tecnologia proprietárias há o ambiente de desenvolvimento Visual Studio, da empresa
Microsoft, que já possui integrada o framework .NET e a linguagem C#. Do outro lado, Flex,
Java, PHP e Flash são exemplos de tecnologias não proprietárias que se destacam neste
ramo.
Neste projeto foram utilizadas as tecnologias compatíveis com o ambiente em que o
sistema irá futuramente operar. Este ambiente caracteriza-se por ter 100% de seus sistemas
operacionais Windows, inclusive os servidores, sendo um deles um servidor web através do
Internet Information Services 7.5 (IIS 7.5) rodando pequenas aplicações como uma agenda de
tarefas e de telefones. Buscando esta integração e devido à equipe de desenvolvimento já estar
familiarizada com tecnologias para esta plataforma, optou-se por utilizar as seguintes
ferramentas, sendo elas gratuitas e disponibilizadas pela Microsoft e comunidades paralelas
para o desenvolvimento de aplicações web ricas e iterativas:

Visual Web Development Express Edition 2008;

.NET Framework 3.5;

Linguagem de programação C#;

ASP.NET AJAX Control Toolkit.
4.1 O Framework .Net
Em Junho de 2000 a Microsoft anunciou a sua tecnologia .NET. A ideia básica por
detrás desta iniciativa é uma mudança, radical, no modelo de desenvolvimento,
comercialização e utilização de Software. A tecnologia .NET é a visão da Microsoft para um
mundo em que o software passa a ser comercializado na forma de serviços, os quais são
acessados através da Internet, utilizando-se protocolos padrão como Extensible Markup
Language (XML) e Simple Object Access Protocol (SOAP). Essa nova perspectiva não é
nenhuma novidade ou invenção da Microsoft. Empresas como IBM, Sun e ORACLE possuem
suas próprias ferramentas e iniciativas nesta direção, algumas inclusive em estágios bastante
avançados de desenvolvimento (BATTISTI, 2001).
O .NET Framework tem dois componentes principais: o Common Language Runtime
(CLR) (linguagem comum em tempo de execução) e o .NET Framework class library, que
32
inclui o ADO.NET, ASP.NET e o Windows Forms. O CLR é o mecanismo responsável pela
execução das aplicações .NET Framework. O CLR suporta C#, assim como outras linguagens
de programação da Microsoft. O código gerado pelo compilador para o suporte CLR é
chamado de código gerenciado. O Common Language Runtime é o cérebro do .NET
Framework. Ele é considerado como o agente que gerencia o código em tempo de execução,
provendo serviços como, por exemplo, o gerenciamento de memória. O CLR proporciona:
gerenciamento automático de memória; verificação de segurança de tipos; gerenciamento de
exceções; segurança aprimorada; acesso a metadados (LOTAR, 2007).
As linguagens da Microsoft suportadas pelo CLR são: Visual Basic, C#, Visual C++,
Jscript, Visual J#, além de linguagens desenvolvidas por outras empresas como, por exemplo,
Perl, C, Java e COBOL. Uma característica interessante do CLR é a interação entre as
linguagens. Por exemplo, pode-se desenvolver um componente no Visual Basic e utilizá-lo
com C#. Esta é uma característica muito interessante quando se trabalham com equipes que
dominam várias linguagens de programação. Cada programador pode trabalhar usando a sua
linguagem preferida e, no final, o projeto é integrado como se tivesse sido criado em uma
única linguagem (LOTAR, 2007).
As aplicações criadas em uma das linguagens habilitadas para o .NET (como
VB.NET, C# ou ASP.NET), ao serem compiladas, geram um código intermediário conhecido
como Microsoft Intermediate Language (MSIL), o qual é abreviado simplesmente como
Intermediate Language (IL). Este código é que é executado pelo CRL conforme Figura 2.
Código
•ASP.NET
•C#
•VB.NET
Compila
MSIL
CLR
Aplicação
Figura 2: Ambiente de execução do CLR
Fonte: BATTISTI, 2001
O segundo elemento fundamental do Framework .NET. é o .NET Framework class
library (biblioteca de classes do Framework .NET), como o próprio nome sugere, é uma
coleção de classes ou tipos completamente integrada com o ambiente de execução – CLR. O
Framework .NET é fortemente baseado nos conceitos de orientação a objetos, principalmente
nos conceitos de Classes, Herança e Polimorfismo. Ao fornecer um conjunto de classes e
tipos, estamos facilitando a vida do programador, uma vez que grande parte da funcionalidade
33
necessária é fornecida diretamente pelo Framework .NET e, o principal, é utilizada de uma
maneira padronizada, pois a maneira de utilizar uma classe da biblioteca de classes do .NET é
a mesma, independente da linguagem. A Figura 3 representa uma visão geral dos principais
elementos que formam o Framework .NET.
Figura 3: Visão geral dos principais elementos que formam o Framework .NET
Fonte: BATTISTI, 2001
4.2 Linguagem C#
C# (C Sharp) é uma linguagem de programação simples, mas poderosa, e ao mesmo,
tempo ideal para desenvolver aplicações web com ASP.NET. É uma evolução do C e C++.
Além de utilizar muitas características do C++, como, por exemplo, declarações, expressões e
operadores, o C# possui um mecanismo chamado Garbage collector (Coletor de Lixo) que
gerencia de forma automática a memória utilizada pelas aplicações e facilita o
desenvolvimento de aplicações web e de aplicações para desktop (LOTAR, 2007).
O C# é uma linguagem orientada a objetos com a qual podemos criar classes que
podem ser utilizadas por outras linguagens como, por exemplo, o Visual Basic. Uma
característica importante é que ainda é possível utilizar os componentes COM, facilitando
assim uma rápida migração para um ambiente de desenvolvimento de alto nível sem precisar
reescrever todas as aplicações que você possui (LOTAR, 2007).
Por ser uma linguagem orientada a objeto, existe a capacidade de uma classe herdar
certas características ou métodos de outras classes, sejam elas escritas em C# ou em VB.
Todos os programas desenvolvidos devem ser compilados, gerando um arquivo com a
34
extensão DLL ou EXE. Isso torna a execução dos programas mais rápida se comparados com
as linguagens de script (VBScript, JavaScript) que atualmente utilizamos na internet (LOTAR,
2007).
4.3 ASP.NET AJAX Control Toolkit
A revolução na internet que acompanhamos nesses últimos 2 anos, com sites cada
vez mais interativos e funcionais, se deve muito a expansão da utilização do conceito de
Asynchronous Javascript And XML (AJAX) . A popularização da metodologia que utiliza
técnicas javascript para realizar operações interativas como um sistema desktop tornou
possível sistemas completos de empresas irem totalmente para grande rede (PEREIRA, 2010).
O ASP.NET AJAX Control Toolkit é um projeto open-source construído em cima da
estrutura do ASP.NET AJAX da Microsoft. É um esforço conjunto entre a Microsoft e a
comunidade ASP.NET AJAX que fornece uma poderosa infraestrutura de controles
reutilizáveis, personalizáveis e extensíveis do ASP.NET AJAX, bem como uma rica variedade
de extensões para controles que podem ser utilizados para criar um experiência Web mais
interativa (COMUNIDADE ASP.NET AJAX, 2010).
35
5 MATERIAL E MÉTODOS
O trabalho foi desenvolvido na Fazenda Seis Irmãos, localizada no município de
Riachão – MA. Para a pesquisa foi utilizado como meio técnico de investigação, o método
observacional, através do nível de pesquisa exploratório, utilizando o delineamento da
pesquisa documental. De acordo com Gil (1999) o delineamento da pesquisa documental,
difere da pesquisa bibliográfica devido à pesquisa documental valer-se de materiais que ainda
não receberam tratamento analítico, podendo ser reelaborados de acordo com o objetivo da
pesquisa.
Para o desenvolvimento do sistema foi utilizado Desenvolvimento Ágil5 como
modelo de processo de Engenharia de Software que enfatiza uma abordagem de
desenvolvimento simples e incorpora ciclos rápidos de desenvolvimento. De acordo com esse
modelo, escolheu-se, o Desenvolvimento Guiado por Características (Feature Driven
Development - FDD) como método, sendo que o mesmo busca entregar novas
funcionalidades ao cliente em no máximo a cada duas semanas.
Foram realizadas as seguintes atividades:

Formulação e Coleta de requisitos – Foram coletadas todas as informações através de
entrevista não estruturadas, ou melhor, entrevistas informais com os responsáveis pela
gerência e operacionalização da Fazenda Seis Irmãos para cada característica desejada de
modo a montar um modelo global do sistema. A entrevista informal é aquela menos
estruturada possível e só se distingue da simples conversação porque tem como objetivo
básico a coleta de dados. O que se pretende com este tipo de entrevista é a obtenção de uma
visão geral do problema pesquisado (GIL, 1999);

Projeto – Para cada característica formulada foram elaborados os casos de uso. Foi
também elaborado o diagrama de entidade-relacionamento, utilizado para implementação do
banco que persiste os dados, e as classes do sistema;

Implementação do sistema – Foram utilizadas as seguintes tecnologias:
o A linguagem C#, plataforma ASP.NET e a ferramenta Visual Web
Development Express Edition para o desenvolvimento da aplicação web;
o O banco de dados utilizado para a persistência dos dados é o MySQL 5 x64;
5
Manifesto para o Desenvolvimento Ágil de Software. Disponível em: < http://www.manifestoagil.com.br/ >.
Acesso em: 06/06/2010.
36
o MySQL Connector 6.2.3 para a ligação entre o banco MySQL e o servidor web
e o ambiente de programação Visual Studio;
o O servidor web é o Internet Information Server 7.5 (IIS 7.5) rodando em um
servidor com sistema operacional Windows Server 2008 SP2.

Coleta de dados e avaliações do software – Foram realizadas avaliações com os
funcionários da Fazenda Seis Irmãos ao ser entregue cada característica formulada, através de
questionário dirigido, que avaliam as funcionalidades e a interface do sistema. Após estas
avaliações foram feitas as modificações necessárias às características buscando a qualidade
final do software, sendo que após serem feitas as modificações foram realizadas novamente as
avaliações, até que a característica fosse aprovada pelo usuário final.
37
6 DESENVOLVIMENTO
Baseado na metodologia de desenvolvimento ágil buscou-se adaptar o modelo FDD
para um modelo onde se tem uma equipe muito pequena de desenvolvimento, sendo formada
por uma pessoa responsável por todas as fases de desenvolvimento e duas responsáveis pelas
regras de negócio, que são os gerentes da Fazenda Seis irmãos. O processo de
desenvolvimento se iniciou em maio de 2010, sendo primeiramente desenvolvido um modelo
global do sistema que representa a primeira etapa do modelo FDD.
6.1 Modelo Global do Sistema
.
Para o desenvolvimento do modelo global foram realizadas entrevistas informais ou
não estruturadas com os gerentes e responsáveis por administrar a Fazenda Seis Irmãos e se
registrou a necessidade das seguintes funcionalidades:

Cadastro de Pessoas Físicas e Jurídicas;

Cadastro de Funcionários;

Cadastro de Fazendas e Matrículas;

Cadastro de Safras;

Cadastro de Talhões;

Cadastro de Espécies;

Cadastro de Variedades;

Cadastro de Máquinas e Implementos;

Cadastro de Marcas/Fabricantes;

Cadastro de Unidades de Medida;

Cadastro de Armazéns;

Cadastro de Frota de Veículos;

Cadastro de Bairros, Cidades e Estados;

Cadastro de Peças e Materiais;

Controle de Entrada e Saída de Peças e Materiais;

Controle de Entrada e Saída de Equipamentos de Proteção Individual (EPI’s) e
Ferramentas de Funcionários;

Cadastro de Insumos e Produtos;

Controle de Entrada e Saída de Insumos e produtos em Estoque;
38

Cadastro de Contratos;

Controle de quantidade de Produtos entregues em cada contrato;

Histórico de Cotações do Dólar e da soja conforme bolsa de Chicago;

Controle da Pluviometria;

Controle das Operações de Campo;

Controle das Avaliações de Campo (Pragas, doenças, população de plantas);

Manutenção de Máquinas e Equipamentos;

Campos de Produção (Quais culturas em qual talhão);

Planejamento das Operações de Campo;

Anexar os Documentos de campo (Mapas de aplicação, produtividade, croquis);

Gerar Projeto Técnico;

Controle de Usuários;

Permissões dos usuários por Perfis;

Fazer o rastreamento interno de todos os processos dos Campos de Produção.
Neste momento buscou-se compreender exatamente todas as funcionalidades que o
protótipo deveria executar aliando o conhecimento do negócio dos gerentes e administradores
com as possibilidades de desenvolvimento avaliadas pelo responsável pelo protótipo. Neste
momento foram criados os documentos de requisitos já os separando em oito grupos ou
módulos: Cadastros; Almoxarifado; Estoque; Comercialização; Produção; Planejamento;
Sistema; Rastrear. Todos os documentos de requisitos foram elaborados utilizando o modelo
do Apêndice A, que representa o documento de requisitos gerais do sistema.
6.1.1 Cadastros
O documento de requisitos do módulo de cadastro foi o primeiro documento a ser
criado, pois as informações de cadastro normalmente são utilizadas por todo o sistema e desta
forma se tornou pré-requisito para as outras funcionalidades. Ao todo, foram gerados 72
requisitos que podem ser observados no apêndice C. Na sua primeira versão foram descritos
os requisitos do cadastro de:

Pessoas Físicas e Jurídicas: Cadastro de todas as pessoas do sistema, sendo estes
utilizados como fornecedores, clientes e funcionários, sendo necessária a validação de CPF ou
39
CNPJ. Ficou definido que a validação desta informação seria realizada somente através de um
algoritmo de validação numérica6.

Funcionários: Vinculado ao cadastro de pessoas, ou seja, necessariamente para se
cadastrar um funcionário o mesmo deve estar cadastrado como uma pessoa física e também
possui as funções de admissão e demissão.

Fazendas: Cadastro das fazendas indicando a cidade e estado.

Matrículas: As matrículas são registros legais das delimitações das áreas das fazendas
e proprietários. Este cadastro é vinculado às fazendas.

Safras: Correspondente ao cadastro dos ciclos de produção das espécies.

Talhões: Cadastro das áreas que são delimitadas dentro de uma fazenda sendo
destinadas à produção.

Espécies: Cadastro de espécies de plantas, pragas, doenças, ou seja, todos os tipos de
espécies animais e vegetais ligados à produção.

Variedades: Cadastro de variações de uma mesma espécie com características
melhoradas, como maior produtividade, adaptação ao clima do norte/nordeste, etc..

Unidades de Medida: Cadastro de unidades de medida para serem usadas pelo
sistema para ter controle de medidas.

Tabela de Equivalência entre Unidades: Cadastro de equivalência entre unidades de
medida para ser usado pelo sistema para converter valores e facilitar a visualização.

Armazéns: Cadastro de locais onde a produção estará armazenada e quantidade
suportada pelo local.

Bairros, Cidades e Estados: Cadastro de todas as cidades, estados e bairros;

Veículos: Cadastro de veículos com seu peso de balança padrão permitido pela
legislação, se houver.

Motoristas: Cadastro de motoristas vinculando os mesmos aos veículos e às pessoas
físicas.

Máquinas e Implementos: Cadastro de todas as máquinas e implementos ligados à
produção, tanto de propriedade própria como de terceiros, no caso de aluguel.

Marcas/Fabricantes: Cadastro de marcas e fabricantes para serem utilizados pelo
sistema para os cadastros de máquinas e implementos, veículos, peças e materiais.
6
Algoritmos disponibilizados no website da empresa RA Digital Solutions:
Algoritmo do CPF: http://www.rads.com.br/javascript_main.php?m=1&id=6
Algoritmo do CNPJ: http://www.rads.com.br/javascript_main.php?m=1&id=7;
40
6.1.2 Sistema
O segundo documento de requisitos a ser elaborado, em paralelo ao documento de
requisitos de cadastro, diz respeito ao módulo de administração do sistema conforme apêndice
A. Neste documento, que possui nove requisitos funcionais e quatro não funcionais, estão
descritos como o sistema irá fazer a administração de usuários e suas permissões. Será
utilizado inicialmente um nível de segurança básica, com somente o uso de um login e senha
para cada usuário e sendo atribuído este login e senha a um funcionário cadastrado. As
permissões serão concedidas através do perfil do usuário, sendo que a definição de quais serão
as permissões só serão estabelecidas na segunda versão do protótipo. Portanto, nesta versão
todos os usuários são considerados administradores e tem acesso irrestrito a todas as
funcionalidades.
6.1.3 Almoxarifado
Posteriormente foi elaborado o módulo de almoxarifado, conforme apêndice B, com
22 requisitos que descrevem as funções de cadastro de peças e materiais e a entrada e saída
das mesmas no almoxarifado. Como requisito, para facilitar a manipulação destas peças e
materiais elas devem ser classificadas em grupos e subgrupos, por exemplo: um filtro
responsável por filtrar o ar que irá ser misturado ao combustível no processo de combustão
necessária para gerar o movimento de um trator, pode ser classificado no grupo de “Filtros” e
subgrupo de “Filtros de ar”, paralelamente existem filtros de combustível, de óleo hidráulico e
outros que também podem ser classificados em subgrupos. O mesmo acontece com
ferramentas de trabalho, que podem ser classificadas e agrupadas da maneira que o cliente
achar necessário.
O documento de requisitos do módulo de almoxarifado também contempla a função
de controle de equipamentos de proteção individual (EPI´s) e ferramentas entregues e
devolvidas aos funcionários, assim como o estado de conservação das mesmas. Como
requisito, esta função está integrada com a entrada e saída de peças e materiais do
almoxarifado, de maneira que se tenha o total controle da entrada e saída das mesmas, assim
como as datas e quantidades por funcionário.
41
6.1.4 Estoque
O quarto documento de requisitos, que descreve o módulo de estoque, foi elaborado
em duas partes: a primeira descreve o estoque de insumos utilizados na produção e a segunda
diz respeito ao estoque da produção, cada uma com 11 requisitos cada, conforme apêndice E.
O estoque de insumos contém os requisitos referentes ao cadastro dos insumos e sua entrada e
saída em estoque. Da mesma forma que as peças e materiais, os insumos também podem ser
classificados em grupos e subgrupos, como por exemplo, os agrotóxicos utilizados para o
controle de ervas daninhas seletivas às gramíneas podem ser classificados no grupo
“Herbicidas” e no subgrupo “Graminicidas”. A segunda parte do módulo de estoque descreve
as entradas e saídas da produção, sendo que todas as entradas de produção em estoque têm
como origem um ou mais campos de produção, e como destino um armazém próprio. E toda
saída de produção em estoque deve pertencer a um ou mais contratos de venda de produção.
Outra funcionalidade descrita pelo módulo de estoque da produção é o cadastro de tabelas de
desconto por empresa compradora e espécie, utilizada para calcular os descontos como
umidade, impureza, avariados, partidos e quebrados e esverdeados de cada carga da produção.
As possibilidades de dividir uma carga vinda da lavoura em mais de um campo de
produção e em mais de um contrato de venda tem por objetivo sanar as duas deficiências
encontradas em um dos softwares testados pela Fazenda Seis Irmãos, o Prorural. Este por sua
vez não possibilitava esta divisão tendo como resultado um engessamento das entradas e
saídas da produção e aumento do erro no cálculo da produtividade por talhão no momento em
que ocorria a situação de um caminhão carregar em dois talhões diferentes para formar uma
carga. Outra deficiência sanada diz respeito ao calculo dos descontos neste software, pois o
mesmo só possui o cadastro das tabelas por espécie, desconsiderando a empresa. Este fato traz
enormes problemas, pois cada empresa utiliza uma tabela de descontos diferente fazendo com
que estas tabelas por espécies não sirvam para calcular os descontos.
6.1.5 Planejamento
O documento de requisitos do módulo de planejamento, quinto documento de
requisitos elaborado, conforme apêndice G possui quatro subitens: campos de produção,
documentos de campo, operações de campo e projeto técnico. No subitem campos de
produção, com sete requisitos, está descrito a funcionalidade de cadastro dos campos de
produção, que tem como conceito, uma área definida e delimitada dentro de um talhão
42
pertencente a uma fazenda, na qual será cultivada uma única espécie com uma única
finalidade. Como requisito, este campo de produção foi designado através de um código que
referencia todas estas informações. Por exemplo: Em uma fazenda chamada Fazenda Seis
Irmãos, de sigla F6, com um talhão numerado em 01, na safra 2010/2011, que cultivou a
espécie soja com a finalidade de venda de grãos, pode ter como designação do campo de
produção o código “SOJA:S1011:T01:F6”, em paralelo na mesma fazenda podemos ter na
mesma safra, no mesmo talhão a delimitação de duas ou mais áreas para ser realizado um
teste com variedades diferentes teríamos vários códigos: “TESTE1:S1011:T01:F6”,
“TESTE2:S1011:T01:F6”, “TESTE3:S1011:T01:F6” e ainda o restante da área do talhão
com “SOJA:S1011:T01:F6”. Esta nomenclatura facilita o controle de todas as operações
agrícolas realizadas, pois utiliza um único código de referência centralizando as informações.
O conceito de campos de produção é utilizado pelo sistema principalmente para rastrear todas
as informações de um campo no módulo de rastreabilidade e pode ser totalmente retratado e
comparado à produção de sementes, onde há a necessidade de se isolar todos os campos de
produção para ter controle específico e rígido dos seus processos e não ocorrer mistura
varietal, que pode inviabilizar totalmente o campo de produção.
No subitem de operações de campo no módulo de planejamento, estão descritos os
requisitos referentes ao cadastramento das operações agrícolas para um campo de produção,
na qual são cadastradas todas as operações, com suas datas e insumos previstos para serem
utilizados. Por exemplo, neste módulo o usuário poderá inserir as operações de plantio,
aplicação de fertilizantes, herbicidas, inseticidas, gradagem do solo e etc., para um campo de
produção, assim como os produtos, doses e datas previstas que deverão ser utilizados no
tratamento de sementes ou no controle de insetos e pragas. Tem por objetivo simular e
facilitar o levantamento da quantidade de insumos a serem orçados e comprados e possui
nove requisitos que o descrevem.
Para facilitar a visualização de todas as operações de campo planejadas foi
adicionada a funcionalidade de gerar um projeto técnico de um campo de produção, que
corresponde ao subitem do projeto técnico. Neste subitem está descrito em quatro requisitos a
funcionalidade de filtrar todas as informações a cerca das operações de campo planejadas e
dos insumos e doses recomendadas para um campo de produção para que os operadores e
técnicos responsáveis pela produção possam visualizar de forma simples e resumida as
atividades que devem ser realizadas em campo.
Outro subitem do módulo de planejamento é o de documentação de campo, com
nove requisitos descritos. Neste subitem do documento de requisitos do módulo de
43
planejamento é apresentada a funcionalidade de salvar no sistema, ou melhor, fazer um
upload dos arquivos que correspondem ao mapa de aplicação7 e mapa de produtividade8 de
um campo de produção para serem acessadas por todos os usuários com permissão para isso.
Estes tipos de arquivos normalmente são utilizados por fazendas que se beneficiam da
agricultura de precisão. No subitem de documentos de campo também há a possibilidade de
salvar arquivos referentes a manuais de máquinas e implementos e/ou outros arquivos que o
usuário do sistema achar relevante.
6.1.6 Produção
O sexto documento de requisitos elaborado, que são os requisitos do módulo de
produção, possui quatro subitens que descrevem as operações de campo realizadas, as
avaliações de campo, as manutenções em máquinas e implementos e a pluviometria,
conforme Apêndice F. Do mesmo modo que as operações de campo planejadas, as operações
de campo realizadas descrevem a maneira como o usuário cadastra e edita as operações de
campo realizadas e seus insumos.
O subitem avaliações de campo descreve em 12 requisitos a funcionalidade de
controlar as avaliações de pragas, doenças, população de plantas e ervas daninhas, tendo
como função o seu cadastro por amostras, ou seja, o funcionário irá no campo e levantará os
resultados de várias amostras por campo de produção e o sistema irá calcular a média das
amostras por parâmetro avaliado.
Outro subitem encontrado no documento de requisitos do módulo de produção diz
respeito à manutenção de máquinas e implementos, onde é descrito em nove requisitos, o
cadastro de manutenções em máquina e/ou implementos assim como os materiais utilizados
em cada manutenção e os responsáveis pela execução da manutenção.
Este módulo é
integrado com o módulo de almoxarifado de modo a permitir o controle de todas as entradas e
saídas do mesmo.
O último subitem encontrado e descrito pelo módulo de produção é a funcionalidade
de controle da pluviometria. Esta funcionalidade está descrita em seis requisitos e tem por
7
Um mapa de aplicação é um arquivo eletrônico utilizado por um sistema de agricultura de precisão para
realizar a aplicação de fertilizantes a um campo de produção utilizando taxas variadas do produto.
8
Um mapa de produtividade é um arquivo eletrônico gerado por sistemas embarcados em colheitadeiras que
representam a mapa em gradiente da produtividade alcançada em um campo de produção.
44
finalidade cadastrar pluviômetros, talhões a serem monitorados, as ocorrências das chuvas por
pluviômetro e a geração de gráficos temporais das chuvas.
6.1.7 Comercialização
O documento de requisitos de comercialização, conforme apêndice D descreve os
requisitos de cadastro de contratos de venda da produção, no qual são definidas as
quantidades vendidas de cada produto para cada empresa. Outra funcionalidade diz respeito a
manter um histórico de cotações do dólar que será utilizado pela tabela de equivalência pelo
sistema para simular, por exemplo, o valor do preço do saco de soja atualizado para reais.
Servirá também para consultar os valores do dólar no dia do fechamento de um contrato,
sendo esta informação de grande importância no momento da comercialização dos produtos.
Nos requisitos deste módulo também está descrito a necessidade de visualizar as cotações da
soja na bolsa de Chicago assim como suas previsões para os períodos subsequentes, não
sendo necessário a sua persistência no banco de dados.
6.1.8 Rastrear
E por fim, o último documento de requisitos referente à rastreabilidade, que descreve
em dois requisitos funcionais a característica de rastrear os campos de produção
correlacionando todas as informações planejadas e realizadas do campo, como operações de
campo, doses e produtos utilizados, a fim de obter um comparativo simples da situação de
cada campo de produção no final do ciclo de produção. Este documento pode ser visualizado
no apêndice H.
6.2 Lista de Características
Com o modelo global do sistema realizado, se iniciou a segunda etapa da
metodologia, que é a criação de uma lista de características. Esta lista foi ordenada
hierarquicamente com base primeiramente nas dependências entre as funcionalidades e em
segundo plano o valor de negócio da característica e ficou definida da seguinte forma:
1. Módulo de Cadastro
1.1. Estados
1.2. Cidades
45
1.3. Bairros;
1.4. Pessoas Físicas e Jurídicas;
1.5. Funcionários;
2. Módulo do Sistema
2.1. Cadastro de Perfis;
2.2. Cadastro de Usuários;
3. Módulo de Cadastro
3.1. Safras;
3.2. Fazendas;
3.3. Matrículas;
3.4. Talhões;
3.5. Unidades de Medida;
3.6. Tabela de Equivalência;
3.7. Simulação de Conversão entre Unidades de Medida;
3.8. Grupos de Espécies;
3.9. Famílias de Espécies;
3.10. Espécies
3.11. Detentores/Mantenedores de Variedades;
3.12. Hábitos de Crescimento de Variedades;
3.13. Cores de Hilo de Variedades;
3.14. Cores de Inflorescência de Variedades;
3.15. Variedades;
3.16. Marcas e Fabricantes;
3.17. Grupo de Máquinas e Implementos;
3.18. Máquinas e Implementos;
3.19. Tipos de Veículos;
3.20. Veículos na Frota;
3.21. Motoristas de Veículos da Frota;
3.22. Armazéns;
4. Módulo de Almoxarifado
4.1. Cadastro de Grupo de Peças/Materiais;
4.2. Cadastro de Subrupo de Peças/Materiais;
4.3. Cadastro de Peças/Materiais;
4.4. Controle de Peças/Materiais em Almoxarifado;
46
4.5. Controle de EPI’s e Ferramentas de Funcionários;
5. Módulo de Estoque
5.1. Cadastro de Grupos de Insumos;
5.2. Cadastro de Subgrupos de Insumos;
5.3. Cadastro de Insumos;
5.4. Controle de Insumos em Estoque;
6. Módulo de Planejamento
6.1. Cadastro de Campos de Produção;
6.2. Cadastro de Tipos de Operação de Campo;
6.3. Cadastro de Operações de Campo Planejadas;
6.4. Geração do Projeto Técnico;
7. Módulo de Produção
7.1. Cadastro de Operações de Campo Realizadas;
7.2. Cadastro de Avaliações de Campo;
7.3. Cadastro de Amostras de Avaliações de Campo;
7.4. Cadastro Tipos de Manutenção em Máquinas e Implementos;
7.5. Cadastro de Manutenção em Máquinas e Equipamentos;
7.6. Cadastro de Pluviômetros;
7.7. Cadastro de Talhões Monitorados;
7.8. Controle de Ocorrências de Chuvas;
7.9. Geração de Gráficos Temporais de Chuvas;
8. Módulo de Comercialização
8.1. Cadastro de Contratos de Venda da Produção;
8.2. Busca e Atualização de Valores do Dólar e Soja de Chicago;
8.3. Geração de Gráficos do Dólar
9. Módulo de Estoque
9.1. Controle das Tabelas de Descontos;
9.2. Controle de Estoque de Produção;
10. Módulo de Rastreabilidade
10.1. Geração de Rastreabilidade de Campos de Produção;
11. Módulo de Planejamento
11.1. Upload de Mapas de Aplicação;
11.2. Upload de Mapas de Produtividade;
11.3. Upload de Manuais de Máquinas e Implementos;
47
11.4. Upload de Outros Arquivos;
Outra atividade desta etapa do método FDD diz respeito à divisão destas
funcionalidades a pequenos grupos. Em cada grupo deverá existir um dono da classe, ou
melhor, da funcionalidade. O dono de classe é um membro de uma equipe sob o comando de
um programador chefe e está responsável pela arquitetura, implementação, teste e
documentação de uma determinada classe. Em cada iteração fará parte das equipes cujas
funcionalidades envolvam a sua classe. Mas, este tipo de abordagem diz respeito a uma
equipe de desenvolvimento com vários integrantes, o que não é o caso deste projeto.
A lista de características elaborada, antes de prosseguir para a próxima etapa, foi
revista e confirmada pelo cliente, ou seja, pelos gerentes de negócio da Fazenda Seis Irmãos.
6.3 Planejamento por Característica
Para refinar as funcionalidades do software foram desenvolvidos os casos de uso e
diagrama de entidade-relacionamento. Usando a lista detalhada e ordenada por prioridade,
criada no processo anterior foi desenvolvida para cada característica um ou mais casos de uso
representando a maneira como o sistema irá interagir com o usuário e processar as
informações. Por exemplo, um dos processos críticos, é o cadastro de campos de produção.
Há duas possibilidades para isso, uma é a criação de um campo de produção que preencha
toda a área de um talhão e a outra é a criação de dois ou mais campos de áreas diferentes na
mesma área do talhão. Este processo gerou três casos de uso que podem ser observados
abaixo:
UC001 – Cadastrar Campo de Produção
Descrição: Este caso de uso descreve o processo de cadastro de um campo de produção.
Fluxo Principal
1 – O caso de uso se inicia quando um usuário precisar cadastrar um campo de produção no
sistema;
2 – O sistema oferece a opção de cadastrar em área total ou em área parcial;
3 – O usuário aciona opção de desejada;
3.1 – Se o usuário acionou a opção de cadastrar em área total (Executa UC002);
3.2 – Se o usuário acionou a opção de cadastrar em área parcial (Executa UC003);
Fim do Caso de Uso
UC002 – Cadastrar Campo de Produção em Área Total
Descrição: Este caso de uso descreve o processo de cadastro de um campo de produção em
área total.
Fluxo Principal
48
1 – O caso de uso se inicia quando um usuário precisar cadastrar um campo de produção em
área total no sistema;
2 – O usuário irá selecionar o talhão desejado;
3 – O sistema buscará as informações de área total;
4 – O sistema irá pedir ao usuário a safra, a espécie, a variedade, a fazenda, o sistema de
plantio, a finalidade do campo, o nome do campo de produção, a população de plantas
(plantas/m) desejada e as observações;
5 – O usuário insere ou seleciona todos os valores acima citados;
6 – O sistema mostra na tela, a opção de adicionar o campo de produção à base de dados do
sistema Rastrear;
7 – O usuário aciona a opção de salvar as informações no sistema (executa FE002);
8 – O sistema monta o código do campo de produção da seguinte forma: Nome do campo +
”:” + safra (usando a terminologia S1011) + “:” + talhão + “:” + fazenda;
9 – O sistema persiste as informações no banco;
10 – O sistema exibe uma mensagem confirmando que o procedimento ocorreu com sucesso.
Fim
Fluxo de Exceção
FE002 – Informações não preenchidas
1 – O sistema exibe uma mensagem de erro ao usuário informando que um dos campos não
foi devidamente preenchido;
2 – Retorna ao passo 2 do fluxo principal;
Fim do caso de uso
UC003 – Cadastrar Campo de Produção em Área Parcial
Descrição: Este caso de uso descreve o processo de cadastro de um campo de produção em
área parcial.
Fluxo Principal
1 – O caso de uso se inicia quando um usuário precisar cadastrar um campo de produção em
área parcial no sistema;
2 – O usuário irá selecionar a safra e o talhão desejado;
3 – O sistema buscará as informações de área total e outros campos já cadastrados no talhão;
4 – O sistema irá pedir ao usuário a espécie, a variedade, a fazenda, o sistema de plantio, a
finalidade do campo, o nome do campo de produção, a área parcial, a população de plantas
(plantas/m) desejada e as observações;
5 – O usuário insere ou seleciona todos os valores acima citados;
6 – O sistema mostra na tela, a opção de adicionar o campo de produção à lista de campos do
talhão;
7 – O usuário aciona a opção de salvar as informações no sistema (executa FE002, FE003);
8 – O sistema monta o código do campo de produção da seguinte forma: Nome do campo +
”:” + safra (usando a terminologia S1011) + “:” + talhão + “:” + fazenda;
9 – O sistema persiste as informações no banco;
10 – O sistema exibe uma mensagem confirmando que o procedimento ocorreu com sucesso.
Fim
Fluxo de Exceção
FE003 – Área Ultrapassa área total do Talhão
1 – O sistema exibe uma mensagem de erro ao usuário informando a soma das áreas
informada e cadastrada na lista de campos do talhão ultrapassa a área total do talhão;
49
2 – Retorna ao passo 2 do fluxo principal;
Fim do caso de uso
Observa-se que no item 8 dos casos de uso UC002 e UC003 é feita a montagem do
código que representa o campo de produção. Este código é usado para se rastrear cada campo
de produção e vincular todas as operações agrícolas, sejam elas planejadas ou realizadas em
campo. Traz também a vantagem de facilitar a visualização das informações agregadas como
safra, talhão e fazenda e, ao mesmo tempo, manter um histórico de todos os processos.
Outro caso de uso interessante é o caso que descreve a inserção de do planejamento
de uma operação de campo a um campo de produção. O mesmo foi descrito em três casos de
uso:
UC031 – Inserir uma Operação de Campo Planejada
Descrição: Esse caso descreve o processo em que o usuário irá inserir o planejamento de uma
nova operação de campo.
Fluxo principal
1 – O caso de uso se inicia quando o usuário acionar a opção de inserir uma nova operação de
campo no menu de planejamento onde irão constar as operações com o status “Planejado”;
2 – O usuário irá selecionar a safra, a espécie ou a fazenda;
3 – O sistema irá buscar os campos de produção existentes na safra, ou na espécie, ou na
fazenda e exibi-los ao usuário;
2 – O usuário irá selecionar os campos de produção desejados, o tipo de operação (plantio,
dessecação pré-colheita, etc.), a forma de operação (terrestre, aérea, etc.), a data prevista para
ser executada e as observações;
3 – Com estas informações o sistema calcula o tempo total previsto para aquela operação
(UC032) e exibe ao usuário;
4 – O sistema oferece a opção de inserir insumos à operação de campo (UC033);
5 – O sistema oferece a opção de salvar estas informações;
6 – O usuário aciona a opção de salvar;
7 – O sistema salva as informações.
Fim do Caso de Uso
UC032 – Calcular Duração de Tempo de uma Operação de Campo Planejada
Descrição: Esse caso descreve o processo em que o sistema calcula o tempo em que uma
operação de campo durará.
Fluxo principal
1 – O caso de uso se inicia quando o usuário selecionar o tipo de operação de campo no
momento do cadastro de uma operação de campo;
2 – O sistema pega a informação de tamanho da área dos respectivos campos de produção e
multiplica pelo rendimento médio do tipo de operação (FE008);
3 – O resultado é exibido ao usuário;
Fim
FE008 – Rendimento de Operação de Campo Inexistente
1 – O sistema exibe uma mensagem ao usuário que não há nenhum rendimento de campo da
respectiva operação selecionada
50
2 – O sistema exibe a opção de alterar Operação de Campo.
Fim do Fluxo de Exceção
Fim do Caso de Uso
UC033 – Inserir Insumos à Operação de Campo
Descrição: Esse caso de uso descreve o processo em que o usuário irá inserir insumos a uma
operação de campo.
Fluxo principal
1 – O caso de uso se inicia quando o usuário acionar a opção de inserir insumos a operação de
campo;
2 – O usuário irá selecionar o insumo desejado, a dose e a unidade de medida;
3 – O sistema calcula o total do insumo multiplicando a área total dos campos de produção
pela dose informada e exibe ao usuário
3 – O sistema oferece a opção de salvar estas informações;
4 – O usuário aciona a opção de salvar;
5 – O sistema salva as informações.
Fim do Caso de Uso
Através dos casos de uso UC031, UC032 e UC033 se pode observar que a operação
de inserir uma operação de campo planejada ocorre em duas etapas: escolha dos campos de
produção e do tipo de operação e inserção de insumos na operação. Desta forma faz-se um
link entre todos os insumos necessários para o cultivo do campo de produção podendo assim
fazer uma simulação da quantidade necessária de insumos para se adquirir, podendo ser
visualizada tanto para o campo de produção como para o talhão, fazenda, espécie ou safra
inteira. Portanto, torna-se uma ferramenta de apoio à tomada de decisão.
Os casos de uso UC001, UC002, UC003, UC031, UC032 e UC033 representam um
exemplo padrão de como foram elaborados todos os casos de uso do protótipo, sendo que
outros casos de uso podem ser vistos no apêndice I.
Paralelamente aos casos de uso, foi projetado o diagrama de entidade-relacionamento
que diz respeito à persistência dos dados, ou seja, como os dados vão estar organizados em
tabelas e suas relações no banco de dados. Para isto foi utilizada a ferramenta MySQL
WorkBench na sua versão 5.2.15, que facilita a criação e exportação do diagrama diretamente
para o bando de dados MySQL na forma de script.
Através da Figura 4 se pode observar, por exemplo, os diagramas responsáveis por
descrever o modo como os dados referentes à pluviometria vão estar persistidos e
relacionados. Nele há cinco tabelas: talhao, talhoes_pluviometro, pluviometro, chuva e
chuva_talhoes. A tabela talhao e pluviometro são responsáveis por armazenar os talhões e
pluviômetros. A tabela talhoes_pluviometro persiste os talhões que serão monitorados pelo
pluviômetro. Neste caso, um pluviômetro pode monitorar vários talhões, sendo que cada
51
talhão pode ter vários pluviômetros que o monitoram. Do mesmo modo, a tabela
chuva_talhoes persiste a ocorrência das chuvas em cada talhão, sendo que uma chuva
registrada em um pluviômetro pode atingir um ou mais talhões monitorados e assim
generalizar a quantidade de chuvas de um talhão a todos os campos de produção cadastrados
neste talhão.
Figura 4: Diagrama de ER – Pluviometria
Outro exemplo de diagrama de entidade-relacionamento está na Figura 5. Ele
representa a entidade do campo de produção, e como se pode verificar, esta entidade é um
elemento central, pois interliga praticamente todas as entidades responsáveis por armazenar
informações referentes à produção como safras, talhões, espécies, variedades, contratos de
venda da produção, avaliações de campo, operações de campo e seus insumos.
52
Figura 5: Diagrama de ER – Campo de Produção e seus relacionamentos. A – Espécies; B – Variedades; C –
Safras; D – Talhões; E – Contratos de Venda da Produção; F – Operações de Campo; G – Avaliações de Campo;
Para persistir todas as informações necessárias foram elaboradas, até o momento para
este protótipo, 79 tabelas com seus relacionamentos. Todas as tabelas que compõem o
diagrama geral de entidades-relacionamentos seguiram o mesmo padrão observado nas
Figuras 4 e 5.
Nesta etapa do projeto também foram definidas as datas previstas para a entrega das
funcionalidades seguindo a ordem estabelecida pelas prioridades no processo anterior.
Buscou-se implementar as 61 funcionalidades em um tempo de 96 dias nos meses de junho,
julho, agosto, setembro e outubro de 2010, tendo uma média de 1,57 dias por funcionalidade
se levar em consideração somente os dias úteis. De acordo com a Tabela 5, que representa o
tempo previsto para implementar cada um dos módulos, verifica-se a previsão inicial de 1 dia
para cada funcionalidade do módulo de cadastro e 2 dias para as funcionalidades dos outros
módulos. Já a Tabela 6 apresenta o cronograma previsto para a entrega de cada
funcionalidade.
53
Tabela 5: Tempo previsto para implementação de cada Módulo
Módulo
Funcionalidades
Cadastro
27
Sistema
2
Almoxarifado
5
Estoque
6
Planejamento
8
Produção
9
Comercialização
3
Rastrear
1
TOTAL
61
Dias
Total de Dias
1
2
2
2
2
2
2
2
Tabela 6: Cronograma de Implementação das Funcionalidades
FUNCIONALIDADE
MÓDULO
Estados
Cidades
Bairros;
Pessoas Físicas e Jurídicas;
Funcionários;
Safras;
Fazendas;
Matrículas;
Talhões;
Unidades de Medida;
Tabela de Equivalência;
Simulação de Conversão entre Unidades de Medida;
Grupos de Espécies;
Módulo de
Famílias de Espécies;
Cadastro
Espécies
Detentores/Mantenedores de Variedades;
Hábitos de Crescimento de Variedades;
Cores de Hilo de Variedades;
Cores de Inflorescência de Variedades;
Variedades;
Marcas e Fabricantes;
Grupo de Máquinas e Implementos;
Máquinas e Implementos;
Tipos de Veículos;
Veículos na Frota;
Motoristas de Veículos da Frota;
Armazéns;
27
4
10
12
16
18
6
2
95
PREVISÃO
21/06/2010
22/06/2010
23/06/2010
24/06/2010
25/06/2010
02/07/2010
05/07/2010
06/07/2010
07/07/2010
08/07/2010
09/07/2010
12/07/2010
13/07/2010
14/07/2010
15/07/2010
16/07/2010
19/07/2010
20/07/2010
21/07/2010
22/07/2010
23/07/2010
26/07/2010
27/07/2010
28/07/2010
29/07/2010
30/07/2010
02/08/2010
54
Tabela 6 (Continuação): Cronograma de Implementação das Funcionalidades
FUNCIONALIDADE
MÓDULO
Cadastro de Perfis;
Módulo do Sistema
Cadastro de Usuários;
Cadastro de Grupo de Peças/Materiais;
Cadastro de Subrupo de Peças/Materiais;
Módulo de
Cadastro de Peças/Materiais;
Almoxarifado
Controle de Peças/Materiais em Almoxarifado;
Controle de EPI’s e Ferramentas de Funcionários;
Cadastro de Grupos de Insumos;
Cadastro de Subgrupos de Insumos;
Cadastro de Insumos;
Módulo de Estoque
Controle de Insumos em Estoque;
Controle das Tabelas de Descontos;
Controle de Estoque de Produção;
Cadastro de Campos de Produção;
Cadastro de Tipos de Operação de Campo;
Cadastro de Operações de Campo Planejadas;
Geração do Projeto Técnico;
Módulo de
Planejamento
Upload de Mapas de Aplicação;
Upload de Mapas de Produtividade;
Upload de Manuais de Máquinas e Implementos;
Upload de Outros Arquivos;
Cadastro de Operações de Campo Realizadas;
Cadastro de Avaliações de Campo;
Cadastro de Amostras de Avaliações de Campo;
Cadastro Tipos de Manutenção em Máquinas e
Implementos;
Módulo de
Cadastro de Manutenção em Máquinas e
Produção
Equipamentos;
Cadastro de Pluviômetros;
Cadastro de Talhões Monitorados;
Controle de Ocorrências de Chuvas;
Geração de Gráficos Temporais de Chuvas;
Cadastro de Contratos de Venda da Produção;
Busca e Atualização de Valores do Dólar e Soja de
Módulo de
Comercialização Chicago;
Geração de Gráficos do Dólar
Módulo de
Geração de Rastreabilidade de Campos de Produção;
Rastreabilidade
PREVISÃO
29/06/2010
01/07/2010
04/08/2010
06/08/2010
10/08/2010
12/08/2010
16/08/2010
18/08/2010
20/08/2010
24/08/2010
26/08/2010
05/10/2010
07/10/2010
30/08/2010
01/09/2010
03/09/2010
07/09/2010
21/10/2010
25/10/2010
27/10/2010
29/10/2010
09/09/2010
13/09/2010
15/09/2010
17/09/2010
21/09/2010
23/09/2010
27/09/2010
29/09/2010
01/10/2010
11/10/2010
13/10/2010
15/10/2010
19/10/2010
55
Este processo busca deixar um plano de implementação do projeto claro e previsto
para a próxima etapa do modelo FDD, que é a etapa iterativa entre projetar e implementar por
característica.
6.4 Implementação
Para a implementação se utilizou o ambiente de programação Visual Web
Development Express Edition, que é um ambiente gratuito oferecido pela Microsoft,
juntamente com o .Net Framework na sua versão 3.5 e o Framework ASP.NET Ajax Control
Toolkit. A interface do sistema foi toda construída através dos componentes do Framework
ASP.NET Ajax Control Toolkit, e do recurso Master Page fornecida pelo .NET. Essa
integração tornou o acesso às funcionalidades bem mais dinâmicas. A Figura 6 representa o
layout das telas do sistema e como estão divididas em 3 áreas, por exemplo, a tela de cadastro
da frota de veículos: A – Lateral esquerda – Menus (Figura 7); B – Topo – Identificação da
página (Figura 8); e C – Centro – Conteúdo (Figura 9).
B
A
Figura 6: Layout do Sistema
C
56
Figura 7: Cadastro da Frota de Veículos – Menus.
Figura 8: Cadastro da Frota de Veículos – Identificação da Página.
Figura 9: Cadastro da Frota de Veículos – Conteúdo.
57
Através do .NET Framework também foi possível a geração de gráficos dinâmicos
afim de facilitar a visualização de informações, como por exemplo, a geração de gráficos
sobre a pluviometria. Os gráficos gerados são filtrados por pluviômetro, por talhão ou por tipo
de gráfico, no qual possui mais de 30 opções, conforme Figura 10 e 11.
Figura 10: Gráfico de Pluviometria tipo Coluna
Figura 11: Gráfico de Pluviometria tipo Área
58
Já as funcionalidades foram implementadas utilizando principalmente o .NET
Framework, que em “grosso modo” vincula cada página no formato .aspx a uma classe, sendo
que esta classe herda os componentes da página .aspx. Desta forma, a cada formulário criado,
uma nova classe também é criada. Utilizando-se desta ferramenta se buscou implementar um
sistema utilizando duas camadas, uma de apresentação e negócios e outra de suporte,
conforme Figura 12.
Página
Aspx
Classe
Vinculada
Classes
Auxiliares
Regras de
Negócio
1º CAMADA
2º CAMADA
Base da
Dados
Figura 12: Estrutura das Camadas do Sistema
A primeira camada compreende a manipulação dos eventos gerados pelo browser,
como cliques do botão e seleção de um item em uma lista, que são implementados juntamente
com a lógica de negócio nessas classes vinculadas às páginas. Para cada funcionalidade foram
desenvolvidas as classes necessárias e em cada classe foram implementadas os seus métodos e
atributos para depois ser implementada a página com seus componentes e eventos
relacionados. Um exemplo desse tipo de vínculo pode ser visto na Figura 13, que representa a
classe vinculada à página de Login do sistema. Nela, temos os atributos (Fields) e os Métodos
(Methods). Observa-se que todos os componentes da página se tornam atributos como botões,
painéis etc., e existem métodos relacionados a alguns destes componentes, como o clique em
um botão (button2_click). Neste conceito toda página é um objeto e assim se pode incluir os
métodos das regras de negócio na classe vinculada à página, como a atualização do último
acesso do usuário (AtualizaUltimoAcesso), a verificação dos perfis e das permissões
(VerificaPerfil) e o redirecionamento para a página principal (Redireciona).
59
Figura 13: Classe vinculada à Página de Login do Sistema.
A segunda camada corresponde a classes auxiliares específicas que simplesmente dão
suporte à camada de negócios, como por exemplo, uma classe responsável por fazer a
60
conexão com o banco de dados, outra para converter formatos de data e hora antes de persistilas no banco de dados, etc. conforme Figura 14.
Figura 14: Classes Auxiliares.
Houve a necessidade de se implementar um método para agendar tarefas em um
horário específico, sendo este utilizado para buscar o valor da cotação do dólar e gravá-lo na
base de dados de forma automática pelo sistema. Esta funcionalidade só foi possível através
da tecnologia web services, pois este serviço deveria ser executado somente no servidor e não
nos clientes. Através do próprio ambiente de programação, criou-se um web service e um
Windows service. O web service foi implementado de forma a somente executar um método
61
público no sistema web para executar os agendamentos ativos, como a atualização da cotação
do dólar. O Windows service foi criado com o objetivo de verificar os horários préestabelecidos e nos momentos certos chamar a função no web service para executar os
agendamentos. Desta forma, às 19 horas de todos os dias úteis é feita a atualização da cotação
do dólar sem a intervenção do usuário neste processo.
Durante o processo iterativo de projetar as classes e implementar, inclui-se um
terceiro processo, que foi a avaliação de cada funcionalidade após a implementação.
6.5 Avaliações
Cada funcionalidade foi avaliada utilizando um questionário dirigido no momento da
entrega da funcionalidade ao cliente, sendo através deste questionário levantada a necessidade
de se alterar ou não a funcionalidade. O questionário, conforme apêndice L avalia a aparência
da página que hospeda a funcionalidade, a facilidade de uso, a inserção, alteração e exclusão,
os filtros e principalmente se a funcionalidade cumpre os requisitos levantados no projeto.
Observou-se que praticamente em todas as funcionalidades implementadas foram
encontradas pelo menos um problema, seja ele na aparência, facilidade de uso ou função
propriamente dita, sendo nestes casos verificada as sugestões e observações transcritas pelos
clientes. Muitas delas geraram alterações diretas em características do sistema, de forma a
garantir uma efetiva resolução do problema a ser implementado pela funcionalidade.
6.6 Discussão
A Fazenda Seis Irmãos buscou vários softwares no mercado para suprir as suas
necessidades, dentre os observados, dois softwares foram adquiridos e testados. O primeiro
deles, Super Safra, adquirido em 2007, oferecia suporte a administração financeira e dos
processos da produção. Este software foi utilizado por duas safras (2007/2008 e 2008/2009), e
foi abandonado, pois continha muitos erros de execução, sendo que durante o tempo de uso
pela fazenda os desenvolvedores não conseguiram resolver estes erros. Além disso, existiam
funcionalidades que a Fazenda Seis Irmãos precisava como o histórico de produção por
talhões e o sistema não fornecia. A cada ciclo de produção havia a necessidade de cadastrar
todos os talhões novamente, ou seja, não havia nenhum vínculo entre os ciclos de produção, o
que levou a outro problema no momento de fazer as alterações pedidas pela Fazenda, os
relatórios. Não havia a possibilidade de fazer comparativos entre safras ou talhões ao longo
62
dos anos. Além de outros problemas na área financeira, este software tinha dificuldades no
controle de acesso, pois o mesmo se dava através dos usuários cadastrados no sistema
operacional do servidor, que na época era um Windows Server 2003 Standard. E todos os
funcionários que quisessem acessá-lo deveriam utilizar o serviço de área de trabalho remota
do Windows, fazendo com que somente dois usuários pudessem acessar o sistema por vez, ao
menos que fossem compradas mais licenças para todos os usuários do Windows.
O segundo software a ser adquirido em 2009 se chama Prorural e ainda está em uso
no momento. Este software, bem mais completo que o anterior, possui dois módulos distintos,
pecuária e agricultura. Os dois módulos são totalmente integrados e seu acesso é baseado em
arquitetura cliente-servidor, tendo como desvantagem a inexistência de um sistema que
gerenciasse as atualizações em cada cliente que o sistema estivesse instalado. A principal
dificuldade encontrada também diz respeito à vinculação dos talhões entre safras diferentes,
pois neste também é necessário o cadastramento de novos talhões todo ciclo de produção.
Outras dificuldades encontradas dizem respeito a relatórios errados que entravam em
divergência com os lançamentos, além de outros problemas como erros de tempo de execução
e com adaptações que não puderam ser realizadas pela equipe de desenvolvimento.
Observa-se que as principais dificuldades encontradas na utilização dos antigos
sistemas da Fazenda Seis Irmãos, que seria manter um histórico de todas as operações
agrícolas ao longo dos anos, a possibilidade de dividir cargas na entrada em estoque por
campo de produção e na saída por contrato de venda, e a necessidade de se fazer atualizações
manuais em cada terminal que queira utilizar o sistema, foram sanadas pelo conceito de
campo de produção utilizado e pelo sistema ser baseado em tecnologias web. Além disso, a
utilização de um sistema web traz outras vantagens, principalmente:
 Aproveitamento da infraestrutura de hardware e rede atual, sem a necessidade de um
upgrade;
 Fácil distribuição (somente a necessidade de um navegador);
 Fácil controle e distribuição de atualizações, visto que somente é necessário atualizar o
projeto no servidor que todos os clientes já estarão atualizados;
 A Fazenda Seis Irmãos já possui o servidor web IIS 7.5 rodando pequenas aplicações
intranet como agenda de telefones e de tarefas na propriedade, ou seja, facilidade de
implantação e uma futura publicação de um sistema web, já que em um primeiro momento
a aplicação rodará somente na intranet.
63
 A infraestrutura de rede está em perfeitas condições, tendo como principal meio físico uma
rede wireless de 2.4Ghz no padrão B/G com tráfego real chegando a 6 Mbps.
64
7 CONCLUSÃO
Verificou-se que através da interação contínua durante todas as fases do projeto com
a equipe de negócios da Fazenda Seis Irmãos, se fez o levantamento das características do
sistema e a criação de um modelo global, ou melhor, uma visão do que o sistema se tornaria
depois de implementado. Este modelo global serviu como guia para se criar a lista de
funcionalidades do sistema, que por sua vez foi utilizado para o planejamento e criação dos
casos de uso e demais artefatos se cumprindo a etapa linear da metodologia FDD, tendo como
resultado final o projeto do sistema.
Observou-se que o protótipo desenvolvido através do projeto possui as principais
funcionalidades necessárias e exigidas pelo cliente para que se possa gerir a produção agrícola
da Fazenda Seis Irmãos. O sistema contempla todas as etapas de produção, desde o
planejamento da safra, das operações de campo necessárias e insumos até a comercialização
da produção e entrega dos produtos finais.
A qualidade final do protótipo pode ser alcançada através da coleta dos resultados e
averiguação do cumprimento das funcionalidades. Verificou-se que aproximadamente 10%
das funcionalidades do protótipo não puderam ser implementadas a tempo, como o upload de
mapas de aplicação e produtividade, manuais de máquinas e equipamentos, e outros arquivos.
Dos 90% das funcionalidades desenvolvidas, cerca de 40% delas ainda faltam ser ajustadas
com relação a novas alterações observadas e erros de lógica de programação.
Visto que o principal objetivo de desenvolver um protótipo de um sistema de
informação para fazer a gestão dos processos da produção agrícola, e que o setor do
agronegócio está cada vez mais competitivo, se observa que há a necessidade de uma solução
mais ampla e complexa, que contemple também todos os processos administrativos e
contábeis referentes à produção agrícola, além de uma diversidade de relatórios que não
foram contemplados nesta primeira versão do protótipo. Por ser um sistema web existe a
facilidade de possivelmente poder publicá-lo na internet, tendo como base a simples
multiplicação de esquemas do banco de dados, deixando esta perspectiva para trabalhos
futuros.
65
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DAS EMPRESAS DE SOFTWARE (ABES). Mercado
Brasileiro de Softwares: Panorama e Tendências 2010. São Paulo, 2008. Disponível em <
http://www.abes.org.br/UserFiles/Image/PDFs/Mercado_BR2010.pdf>.
Acesso
em:
23/11/2010
AJAP – ASSOCIAÇÃO DOS JOVENS AGRICULTORES DE PORTUGAL. Gestão da
Empresa Agrícola no Século XXI: Manual III – Tecnologias de Informação e Comunicação
na Gestão da Empresa Agrícola. Lisboa – Portugal: Gazela, Artes Gráficas, Lda, 2007. ISBN
978-989-95613-2-8. Disponível em: < http://www.ajap.pt/media/MANUAL%20III.pdf >.
Acesso em: 06/06/2010.
BASSI FILHO, Dairton Luiz. Experiências com Desenvolvimento Ágil. Dissertação de
Mestrado apresentada ao Instituto de Matemática e Estatística da Universidade de São Paulo.
São Carlos – SP, 2008. Disponível em: < http://www.teses.usp.br/teses/disponiveis
/45/45134/tde-06072008-203515/ >. Acesso em: 06/06/2010.
BATALHA, Mário Otávio (Coord.). Gestão Agroindustrial. 3. ed. Vol.1. São Paulo: Atlas,
2007a. ISBN 978-85-224-4570-7.
BATALHA, Mário Otávio (Coord.). Gestão Agroindustrial. 4. ed. Vol.2. São Paulo: Atlas,
2007b. ISBN 978-85-224-4569-1.
BATTISTI, Júlio. ASP.NET: Uma Revolução na Construção de Sites e Aplicações Web.
Axcel Books, 2001. 785 p.
BEZERRA, Eduardo. Princípio de Análises e Projeto de Sistemas com UML. Rio de
Janeiro: Ed. Elsevier., 2007. 369 p. ISBN 85-352-1696-0.
CALLADO, Antônio André Cunha. Agronegócio. 2. Ed. São Paulo: Atlas, 2009. 184 p.
ISBN 978-85-224-5054-1
COMUNIDADE ASP.NET AJAX. ASP.NET Ajax Control Toolkit. Disponível em: <
http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ >. Acesso em: 17/11/2010.
DELUCA, J.; COAD, P.; LEFEBVRE, E.. Java Modeling in Color with UML. Prentice-Hall,
1999.
EMBRAPA INFORMÁTICA AGROPECUÁRIA. Estudo do Mercado Brasileiro de
Softwares para o Agronegócio - Relatório da Oferta de Softwares para o Agronegócio:
Empresas Privadas. Embrapa Informática Agropecuária. Campinas: 2009. Disponível em: <
http://www.swagro.cnptia.embrapa.br/projeto/swagro/oferta/oferta/empresas-privadas/analiseda-oferta/analise > Acesso em: 23/11/2010.
FIGUEIREDO, André Luís Gouvêa de. ECO – Um Ecossistema para o Desenvolvimento
Ágil de Sistemas Web. Dissertação de Mestrado apresentada ao Instituto de Ciências
Matemáticas e de Computação – ICMC, USP. São Carlos - SP, 2005. Disponível em: <
66
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-28092006-142845/ >. Acesso em:
06/06/2010.
GIL, A. C. Métodos e técnicas de pesquisa social. 5. ed. São Paulo: Atlas, 1999. ISBN 85224-2270-2.
LIMA, Edwin. C# e .Net para desenvolvedores. Rio de Janeiro: Campus, 2002. ISBN 85352-0954-9.
LOTAR, Alfredo. Como Programar com ASP.NET e C#. Novatec, 2007. 608p. ISBN: 97885-7522-121-1.
MANIFESTO. Manifesto para o Desenvolvimento Ágil de Software. Disponível em: <
http://www.manifestoagil.com.br/ >. Acesso em: 06/06/2010.
NASCIMENTO, Gustavo Vaz. Um Modelo de Referência para o Desenvolvimento Ágil de
Software. Dissertação de mestrado apresentado ao Instituto de Ciências Matemáticas e de
Computação – ICMC, USP. São Carlos - SP, 2008. Disponível em: <
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-07052008-170413/ >. Acesso em:
06/06/2010.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e
padrões. 3. Ed.. Rio de Janeiro: LTC, 2009.
PAULINO, Daniel Augusto; et al.. Inovações Tecnológicas da Gestão da Informação no
Agronegócio. São Paulo, 2009. Disponível em: < http://www.unisalesiano.edu.br/
encontro2009/trabalho/aceitos/CC13096956871.pdf >. Acesso em: 23/11/2010.
PEREIRA, Altieri. Porque usar e porque não usar o Ajax Control Toolkit. Disponível em:
<
http://www.devmedia.com.br/post-18534-Porque-usar-e-porque-nao-usar-o-AjaxControl
Toolkit.html >. Acesso em: 17/11/2010.
PRESSMAN, Roger S.. Engenharia de Software. 6. ed.. Tradução: Rosângela Delloso
Penteado. São Paulo: McGraw-Hill, 2006. 720 p. ISBN 85-86804-57-6.
SILVA, Roni Antonio Garcia da. Administração rural: teoria e prática. Curitiba: Juruá,
2010. 194p.
SOMMERVILLE, Ian. Engenharia de Software. 6. ed.. Tradução: André Maurício de
Andrade. São Paulo: Pearson Addison Wesley, 2003. 592 p. ISBN 85-88639-07-6.
ZANIRO, Dênis Leonardo. WEB-SEMP: Método de Elicitação, Modelagem e Planejamento
para Aplicações Web. Dissertação de mestrado apresentado ao Instituto de Ciências
Matemáticas e de Computação – ICMC, USP. São Carlos - SP, 2008. Disponível em: <
http://200.136.241.56/htdocs/tedeSimplificado/tde_arquivos/3/TDE-2010-01-08T094040Z2794/Publico/2734.pdf >. Acesso em: 06/06/2010.