Fasci-Tech - Fatec São Caetano do Sul

Fasci-Tech
Engenharia de Software em Sistemas Informatizados para Biblioteca
Sueli Aparecida Loddi1
Samaris Ramiro Pereira 2
Bruno de L. Vigidio3
Thiago de A. Roque4
Resumo:
Este artigo aborda o desenvolvimento do sistema de informação
denominado FATEC-SBIB. Este projeto foi desenvolvido por três alunos
da FATEC-SB como trabalho de conclusão de curso. O objetivo do grupo
foi melhorar os processos de gerência de acervo da biblioteca,
automatizando atividades executadas de forma manual. Cada aluno focou
uma perspectiva do desenvolvimento do sistema: o banco de dados
relacional, a tecnologia de arquitetura em multicamadas e a utilização do
método ágil SCRUM.
Palavras-Chave: Banco de dados; Biblioteca; Engenharia de Software;
Scrum; Arquitetura em Multicamadas.
Abstract:
This paper presents the FATEC-SBIB information system, a final
paper developed by three students, to be used as a support to FATEC-SB
library management process. The main objective of the project is to
improve the library collection management and the automation of manually
controlled activities. Each student focused on a different perspective:
relational databases; multi-tiers architecture technology; and project
management through the Agile process SCRUM.
Keywords: Database; Library; Software engineering; Scrum; Multi-tiers
architecture.
1. Introdução
A FATEC-SB (FATEC_SB,2009) é uma Instituição de Ensino Superior, que
iniciou sua atividades no ano de 2005, e divide o Campus com a ETEC Lauro Gomes,
no Município de São Bernardo do Campo. Seu acervo de livros é administrado pela
1
Professora Mestre da Faculdade de Tecnologia de São Bernardo do Campo (FATEC-SB) e do Centro
Universitário Fundação Santo André (FAENG).
2
Professora Mestre da Faculdade de Tecnologia de São Bernardo do Campo (FATEC-SB).
3
Graduado em Tecnologia em Informática para Gestão de Negócios pela Faculdade de Tecnologia de São
Bernardo do Campo (FATEC-SB).
4
Graduado em Tecnologia em Informática para Gestão de Negócios pela Faculdade de Tecnologia de São
Bernardo do Campo (FATEC-SB).
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
biblioteca da ETEC Lauro Gomes, sendo que o sistema de gerenciamento, consulta e
empréstimo dos livros é manual. No intuito de melhorar o funcionamento dessa
biblioteca, foi desenvolvido um sistema de informação em código livre denominado
FATEC-SBIB, como esforço conjunto de três trabalhos de conclusão de curso. Os
autores deste artigo são dois dos desenvolvedores do sistema e seus respectivos
orientadores. São apresentadas as ferramentas empregadas para o desenvolvimento do
sistema e os principais conceitos envolvidos no projeto, entre eles a tecnologia de
arquitetura em multicamadas e a gestão do projetos através do método ágil SCRUM.
A metodologia utilizada foi pesquisa bibliográfica (LAKATOS et al., 1985),
constituída de livros, artigos e materiais disponibilizados na Internet em páginas
idôneas. Foi utilizada também, a experiência vivenciada no desenvolvimento do
sistema.
2. Banco de Dados (BD)
Banco de Dados são softwares de armazenamento de dados baseado em
computador, cujo objetivo é registrar e manter informações consideradas significativas
para a organização. Sua correta utilização possibilita um ambiente eficiente e adequado
de recuperação e armazenamento de grandes quantidades de informações. Seu conceito
originou-se na década de 1970, quando as organizações tinham um alto custo na
contratação de pessoas para armazenar e organizar os dados de forma manual. A
automatização de rotinas com seu auxílio reduziram os custos e erros humanos. Tais
vantagens permanecem até os dias atuais (SILBERSCHATZ et al., 1999).
Um Banco de Dados é criado e mantido por um conjunto de aplicações
desenvolvidas especialmente para esta tarefa. Esses softwares são chamados Sistemas
Gerenciadores de Banco de Dados (SGBD). Um SGBD deve isolar o usuário dos
detalhes internos do banco de dados, promovendo a abstração e independência dos
dados em relação às aplicações, ou seja, tornar a estratégia de acesso e a forma de
armazenamento de dados independente da aplicação (ELMASRI et al., 2005).
Atualmente predomina o Modelo Relacional de Banco de Dados, introduzido no
ano de 1970 pelo Dr. Edgar Frank Codd, conhecido como o pai do modelo relacional.
Sua simplicidade de uso e desempenho o tornou um padrão para aplicações comerciais.
O Modelo Relacional possui uma linguagem de programação própria: Structured Query
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
Language (SQL). Ela se divide em duas partes: (1) Data Definition Language (DDL),
Linguagem de Definição de Dados, destinada à manutenção dos objetos do Banco de
Dados; (2) Data Manipulation Language (DML), Linguagem de Manipulação de
Dados, responsável pela manutenção dos dados armazenados no Banco de Dados.
A
linguagem SQL é utilizada para acessar e fazer a manutenção no Banco de Dados de
duas formas: (1) sendo executada dentro de outras linguagens de programação, ou, (2)
por meio de Store Procedures, que são procedimentos armazenados e pré compilados
que executam conjuntos de comandos (ELMASRI et al., 2005).
Um importante recurso dos SGBDs relacionais é o de Transação. Segundo
Silberschatz et al. (1999), transação “é uma unidade de execução de programa que
acessa e, possivelmente, atualiza vários itens de dados”. A transação é geralmente o
resultado da execução de uma DML de auto nível, ou de algum código em linguagem
de programação. Um SGBD deve garantir a execução apropriada das transações com
relação às falhas – ou a transação é executada por completo ou nada é executado.
Quando não há falhas, as transações completam-se com sucesso, chamadas
então de commited (efetivada) e suas atualizações permanecem no Banco de Dados.
Entretanto, uma transação nem sempre se completa com sucesso. Se ela for abortada,
não terá efeito sobre o Banco de Dados. Portanto quaisquer atualizações que a transação
abortada tiver efetuado devem ser desfeita, esse processo é conhecido como rolled back
(SILBERSCHATZ et al., 1999).
3. C Sharp (C#)
A linguagem de programação C# foi desenvolvida pela Microsoft, dentro do
projeto da arquitetura Dot Net (.Net), especificamente para essa plataforma. Foi criado
tendo como base linguagens de programação já conceituadas no mercado,
principalmente C++, Delphi e Java. As principais vantagens de cada uma dessas
linguagens foram mantidas, erros foram corrigidos e melhorias acrescentadas, tornando
o C# uma linguagem com muitos recursos (SANTOS, 2009).
4. Orientação a Objetos (OO)
Um objeto é uma entidade do mundo real, concreta (uma bicicleta) ou conceitual
(uma estratégia de jogo, uma política de escalonamento em um sistema operacional).
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
Cada objeto tem sua identidade, dois objetos são distintos mesmo que apresentem
exatamente as mesmas características. A estrutura de um objeto são seus atributos e
comportamento. Os atributos representam as características dos objetos e o
comportamento o conjunto de operações aplicáveis ao objeto (TONSING, 2008).
Objetos com os mesmos atributos e comportamentos podem ser agrupados em
uma única classe. Cada classe pode ter um conjunto, que pode ser infinito, de objetos.
Para cada objeto é criado uma instância dentro da classe, assim cada instância dentro de
uma classe tem seus próprios valores para cada atributo. O paradigma OO favorece no
desenvolvimento de software, visto que se propõe a resolver problemas básicos:
diminuir o tempo de desenvolvimento, torná-lo confiável, com baixo custo e
possibilidade de reaproveitamento de códigos. Ferramentas para alcançar este
compartilhamento, tais como abstração, encapsulamento e polimorfismo, estão
presentes na metodologia. (BEZERRA, 2006; BOOCH et al 2006 ).
A abstração focaliza os aspectos essenciais de uma entidade na aplicação a ser
desenvolvida, ou seja, concentrar-se no que ela faz, sem se preocupar com o
desenvolvimento da aplicação. Dessa forma, decisões relativas à implementação serão
tomadas apenas quando houver o entendimento dos requerimentos (BEZERRA, 2006).
O encapsulamento separa os aspectos externos de um objeto (acessíveis a outros
objetos) dos detalhes internos da implementação do objeto, os quais permanecem
escondidos no interior dos objetos, permitindo que a implementação possa ser
modificada sem afetar as aplicações que usam este objeto (BEZERRA, 2006).
Para que um objeto realize alguma tarefa, ele precisa receber um estímulo.
Independentemente da origem do estímulo, quando ele ocorre, o objeto em questão está
recebendo uma mensagem. Uma mensagem é uma solicitação enviada de objeto a outro,
solicitando alguma operação. A mesma mensagem enviada a objetos diferentes podem
gerar comportamentos diferentes no receptor (polimorfismo) (BOOCH et al 2006 ).
A Unified Modeling Language (UML) é uma linguagem gráfica padrão para a
elaboração da estrutura de projetos complexos de software. A UML pode ser empregada
para visualizar, especificar, construir e documentar os artefatos de sistemas de software.
A UML é o resultado da unificação da linguagem de modelagem de objetos de métodos
líderes do mercado (BEZERRA,2006; BOOCH et al 2006 ).
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
Tonsing (2008) afirma que a utilização da UML em um projeto promove os
seguintes aspectos: (1) Disponibilizar mecanismos de especificação em níveis
conceituais; (2) Tornar o processo de desenvolvimento independente da linguagem de
programação; (3) Incentivar o uso do paradigma OO, e (4) suportar conceitos de
programação de alto nível.
5. Desenvolvimento em Multicamadas
Segundo Neward (2003) as camadas são uma separação lógica na estrutura do
código fonte de uma um sistema, onde cada parte dele é independente ficando mais fácil
dividir às responsabilidades do sistema. Segundo o autor a utilização de camadas ajuda
a estruturar aplicativos, que podem ser decompostos em grupos de sub-tarefas, onde
cada grupo representa um nível de abstração. Os primeiros sistemas produzidos
possuíam apenas uma camada, ou seja, feitos em um único código que acessava os
dados, tratava as regras de negócios e fazia a interface com o usuário. Dada a tecnologia
da época, esses sistemas “rodavam” e eram armazenados em um único servidor. Caso
sua lógica não fosse muito bem estruturada, manutenções eram complicadas e
demoradas.
Na década de 1990 os computadores pessoais passaram a contar com capacidade
de processamento suficiente para “rodar” os programas, sem a necessidade de um
servidor. Aliada à evolução das redes de computadores, os métodos de desenvolvimento
de sistemas evoluíram para uma arquitetura descentralizada, e os computadores pessoais
passaram a ter um importante papel nos sistemas e aplicações, pois parte do
processamento era feito na máquina do usuário, e um servidor era responsável por
acessar o Banco de Dados.
Baseado nesse modelo, surgiu a arquitetura em duas
camadas, uma camada é armazenada na máquina do usuário e outra no servidor
(GRANATYR, 2009).
Com o advento da Internet, a arquitetura em duas camadas ficou inviável, pois a
carga de complexos algoritmos de negócios na máquina cliente era muito demorada.
Esse problema levou à criação de novas técnicas de desenvolvimento em multicamadas,
visando melhorar o desempenho e/ou diminuir a necessidade de carregar todos esses
algoritmos nas máquinas clientes. Uma delas foi o modelo em três camadas, que são:
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
apresentação, negócios e dados. A camada de apresentação está localizada fisicamente
na máquina cliente. Essa camada é responsável por fazer a interface entre o cliente e as
outras camadas que estão localizadas em outras máquinas. Essa camada normalmente é
leve, contendo pouco código fonte, composta apenas por telas do sistema e pelas
validações dos campos. Ela armazena as informações fornecidas e operações solicitadas
pelo usuário e transmite essas informações para as demais camadas. Essa camada
também retorna os dados fornecidos pelo sistema e apresenta esses dados para o usuário
(GRANATYR, 2009).
A camada de negócios é responsável por fazer o requerimento ao Banco de
Dados e todo o tratamento dos dados, ou seja, somente ela acessa o Banco de Dados.
Ela pode ser dividida em outras duas camadas: camada de acesso a dados e lógica de
negócios. Na camada de lógica de negócios, ficam localizados todos os métodos para o
tratamento das informações; nessa parte da camada ela faz a interface entre a camada de
apresentação e acesso a dados. Normalmente essa camada fica em um servidor
dedicado, com elevados recursos de hardware, pois nele ficam os métodos para o
tratamento desses dados. Várias estações clientes podem se conectar a um mesmo
servidor de camada de negócios (GRANATYR, 2009).
Na camada de acesso a dados, ficam todos os métodos para fazer acesso físico
ao Banco de Dados, como métodos para abrir/fechar a conexão, entre outros. Essa
camada fica localizada junto à camada lógica de negócios. O objetivo da camada de
dados é isolar o resto da aplicação da manipulação de Dados. Sua função é retornar os
dados de forma que a camada de negócios os trate e/ou atualize, de acordo com as
regras de negócios, separando logicamente, e se possível fisicamente, essas camadas
(MICROSOFT, 2008).
Segundo Battisti (2003) o modelo em quatro camadas surgiu como evolução ao
modelo de três. A idéia básica é que a camada de apresentação é retirada da máquina do
cliente e colocada em um servidor. Isso retira a necessidade de instalação de programa
na máquina cliente; o usuário acessa o programa por meio de um Navegador de Internet
e por meio dele faz todas as operações necessárias.
6. Métodos Ágeis e o Scrum
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
Um método de desenvolvimento de software é um conjunto de atividades que
auxiliam sua produção. O resultado dessas atividades é um produto que reflete a forma
como todo o processo foi conduzido. Os problemas com os projetos e a insatisfação
com as abordagens pesadas levaram os desenvolvedores de software na década de 1990
a propor modificações. (SOMMERVILLE, 2007). Desde então, surgem novos métodos,
chamados de ágeis, que focam de forma diferenciada o desenvolvimento, entre eles:
Scrum, eXtreme Programming, Crystal, Adaptive Software Development, DSDM,
Feature Driven Development e instâncias ágeis do Processo Unificado (LARMAN,
2003).
Sommerville (2007) ressalta que, ao utilizar uma metodologia ágil, um
representante dos stakeholders deve estar disponível quase o tempo todo. Isto se torna
um problema principalmente se houver muitos stakeholders com prioridades distintas.
A motivação para a agilidade e métodos iterativos está nos seguintes tópicos: (1)
Clientes ou usuários não têm certeza do que querem; (2) Eles têm dificuldade de dizer o
que querem e o que sabem; (3) Detalhes do que eles precisam serão revelados durante o
desenvolvimento; (4) Os detalhes são complexos para os usuários; (5) Como eles vêem
o desenvolvimento do produto, eles mudam seus pensamentos; (6) Forças externas
(como um competidor, produto ou serviço) podem levar a modificações.
Scrum é um processo ágil ou ainda um framework para gerenciamento de
projetos ágeis. É um processo de gerência de projetos, certamente não uma
metodologia, pois isto seria pesado demais. Tem suas raízes em um artigo publicado em
1986, que introduziu o termo Scrum ao referir-se às reuniões de equipes. Baseia-se em
equipes de no máximo sete pessoas. Requisitos pouco estáveis e/ou desconhecidos e
iterações curtas. O desenvolvimento da aplicação se divide em fases, com no máximo
30 dias, também chamados de Sprints (MARTINS, 2007; GERMANO, 2009).
Existem três papéis previstos na metodologia: (1) Scrum Master ocupa uma
posição similar à ocupada pelo gerente de projeto e deve agir como um facilitador para
o time; (2) Product Owner representa os interesses da Organização patrocinadora do
projeto, e (3) Equipe de Scrum é o grupo de pessoas responsáveis por desenvolver
funcionalidades do produto, devendo ser auto-gerenciadas, auto-organizadas e
multifuncionais (SCHWABER, 2004; MARTINS, 2007). O quadro 1 ilustra as
responsabilidades de cada papel descritas na metodologia.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
O Scrum propõe uma forma de trabalho flexível que se adapta a ambientes muito
dinâmicos (KOSCIANSKI et al., 2007). Visa a tratar mudanças frequentes de requisitos
de software e outras situações, tais como: trocas de equipe, adaptações de cronogramas,
trocas de ferramentas de desenvolvimento ou das linguagens de programação.
Para
Kniberg (2007) o melhor e o pior do Scrum é que em cada projeto é necessário adaptar
o processo à situação específica. O quadro 2 mostra um resumo das fases do Scrum.
De acordo com Schwaber (2004) o Scrum introduz alguns novos artefatos. Estes
são usados durante todo o processo que são o Product Backlog e o Sprint Backlog.
Quadro 1 – Responsabilidades no Scrum
Atividade
Responsável
Responsabilidades
Gerenciar a
Visão
Product
Owner
Estabelece, nutre e comunica a visão do produto.
Consegue o investimento inicial e cria Product
Backlog inicial.
Gerenciar o ROI
Product
Owner
Monitora o projeto por meio das metas de Return on
Investimet (ROI) e da visão de investimento. Atualiza
e prioriza o Product Backlog assegurando que a
funcionalidade mais valiosa seja desenvolvida
primeiro. Prioriza e refina o Product Backlog e mede
sucesso vs. despesas.
Gerenciar a
Time
Sprint de
desenvolvimento
Durante uma Sprint o time seleciona e desenvolve as
funcionalidades de maior prioridade no Product
Backlog. Coletivamente, o time expande os itens do
Product Backlog em pequenas tarefas, criando assim o
Sprint Backlog, e depois se auto gerencia.
Gerenciar o
processo
Scrum Master
Direcionar o time para o sucesso; Alinha o projeto e a
cultura organizacional a fim de atender ao ROI;
Organiza reuniões de planejamento e revisão. Protege
o time de influências externas. Otimiza reuniões
diárias e a remove de impedimentos.
Gerenciar a
entrega
Product
Owner
Decide quando criar uma entrega oficial. Por uma
série de razões pode não ser desejável entregar o
produto na conclusão de cada incremento.
Fontes: Adaptado de Schwaber(2004) e Martins (2007)
O Product Backlog é uma lista de requisitos, estórias, funcionalidades que o
cliente deseja, descritas utilizando a terminologia do cliente. Essa lista pode ser ajustada
durante todo o projeto pelo Product Owner, responsável pelo conteúdo, priorização e
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
disponibilidade da mesma. Os itens no Product Backlog podem sofrer alterações de
prioridade, requisitos podem ser adicionados ou removidos (KNIBERG, 2007).
De acordo com Martins (2007) em um processo ágil você nunca deverá planejar
nada além da iteração seguinte, pois como os requisitos e prioridades podem mudar, o
planejamento de ações futuras pode se tornar uma perda de tempo.
Martins (2007) define o Sprint Backlog como uma lista com os itens do Product
Backlog que a equipe acredita que poderá produzir no próximo Sprint. Ela deve se
atualizada diariamente com as evoluções do projeto. Seu formato deve se similar ao
Product Backlog, contando com duas colunas de informações a mais: uma para cada dia
do Sprint e outra para que cada membro da equipe vai apontar quantas horas ainda
precisam ser trabalhadas naquele item para que seja concluído.
Quadro 2 – Resumos das fases do Scrum
Fases
Propósito
Estabelecer a visão.
Definir expectativas.
Assegurar o capital.
Arquitetura.
Identificar requisitos e
Design alto nível. priorizá-los para a
primeira iteração.
Desenvolvimento. Implementar um
sistema pronto para
entrega em uma
iteração de 30 dias
(Sprints).
Fechamento.
Implantação.
PósGame
Game
Pré-Game
Planejamento.
Atividades
Escrever a visão. Orçamento.
Product Backlog. Estimar os
itens. Protótipos e design inicial.
Planejamento. Protótipos e
design inicial.
Reunião de planejamento do
Sprint em cada iteração,
definindo o Sprint Backlog e
estimativas. Reuniões diárias e
de retrospectiva.
Documentação. Teste de
aceitação. Treinamento.
Marketing e vendas.
Fonte: Larman(2003)
7. Desenvolvimento do Sistema FATEC-SBIB e seus desafios
Para o gerenciamento do projeto foi utilizado a método ágil Scrum, tema de
projeto de Trabalho de Conclusão de Curso do aluno Bruno (VIGIDIO, 2009). A
arquitetura do sistema foi implementada em multicamadas, tema do aluno Thiago
(ROQUE, 2009). O aluno Allan focou seu projeto nas transações em Banco de Dados
(FERNANDES, 2009). Este tópico resume os três trabalhos.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
Dentre as opções de SGBD, optou-se pelo Microsoft SQL Server 2000, um
SGBD relacional conhecido pela sua excelência e estabilidade.
A linguagem para desenvolvimento do sistema foi a C#, pois suporta orientação
a objeto e possibilita a aplicação dos conceitos de multicamadas através do pacote para
desenvolvimento da Microsoft, o Microsoft Visual Studio (MICROSOFT, 2008).
A Arquitetura adotada foi a de desenvolvimento em camada, implementada
pelas camadas: de Banco de Dados, de Negócios e de Apresentação.
Visando à integridade dos dados, foram utilizadas as transações: Empréstimo;
Inserção de obras; Devolução com multa; Devolução sem multa. O sistema conta
também com um dicionário de dados com as definições dos metadados.
A camada de banco de dados foi a primeira a ser desenvolvida e foi dividida
em três partes: tabelas, Store Procedure e Acesso. Para cada parte da camada foi
utilizada uma técnica. As tabelas foram criadas com as técnicas de normalização e de
programação em SQL. Para cada funcionalidade do sistema onde é necessária a
interação com o Banco de Dados, foi criada uma Store Procedure. O Acesso de Banco
de Dados foi feito por uma camada dentro da aplicação, composta por duas classes, que
recebem os parâmetros da aplicação e os enviam para o Banco de Dados e vice-versa.
A camada de negócios encapsulou as regras de negócios da aplicação, onde,
para cada uma das funcionalidades foi criada uma classe, que por sua vez continham os
métodos para as uma regra de negócio. A camada controla quando é necessário um
roteamento e acessa o respectivo método. Essa camada recebe as informações da
camada de apresentação, que foi dividida em diversas telas, cada uma representando
uma funcionalidade de interação.
O quadro 3 mostra o papel e as tarefas dos envolvidos com o projeto, de acordo
com o método ágil Scrum. Com os papéis e ferramentas definidas, a aplicação do Scrum
se iniciou com a criação da visão do sistema. Para gerar o Product Backlog, foram feitas
algumas entrevistas junto ao especialista de domínio e com o Product Owner, para
entendimento das necessidades e para verificar o que era esperado do sistema. Muitas
dessas entrevistas tiveram a participação da equipe toda, o que facilitou o entendimento
para todos. Ao final dessas entrevistas, o Scrum Master e o Product Owner definiram a
visão inicial do sistema. A final dessas entrevistas o Scrum Master e o Product Owner
definiram a visão inicial do sistema, com as seguintes fases de desenvolvimento:
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
controle de obras; controle de usuários; empréstimo de obras; devolução de obras;
relatórios de estatísticas e o manual do usuário.
O Product Backlog adotado no projeto foi uma planilha eletrônica com duas
colunas: uma com o título do item e outra com uma breve descrição do que se esperava
daquele item. O Product Backlog era atualizado pelo Scrum Master antes da reunião de
planejamento do Sprint, utilizando-se uma planilha eletrônica. Durante as reuniões de
planejamento do Sprint, o Product Owner tinha como função detalhar, adicionar e/ou
remover itens da lista.
Quadro 3 – Papéis e tarefas dos envolvidos no projeto
Pessoa
Alan Ueda
Thiago
Roque
Edmilson S.
Carvalho
Papel
Equipe Scrum
Bruno
Vigidio
Scrum Master
José L.
Bianchi
Esp. de domínio
(biblioteca)
Product Owner
Tarefas
Definir datas para as metas estipuladas; Apresentar
os resultados para o Product Owner; Detectar
impedimentos; Participar das reuniões diárias.
Definir a visão do produto; Apresentar os requisitos
necessários para o produto; Definir a ordem das
tarefas; Aceitar ou reprovar o que foi desenvolvido.
Assegurar a aplicação correta das práticas do
Scrum; Eliminar problemas que possam afetar a
realização de tarefas; Atuar como facilitador nas
reuniões diárias; Auxiliar a comunicação.
Apresentar as regras de negócio.
Fonte: Vigidio, (2009)
Na reunião de planejamento, a função da equipe Scrum era estimar os itens em
horas, levando em conta: análise, desenvolvimento e testes. O Scrum Master agia como
mediador, sua função era encontrar o equilíbrio entre levar o máximo de valor ao cliente
sem sobrecarregar a equipe de desenvolvimento. Após concluir a reunião de
planejamento de Sprint e antes de ter a primeira reunião diária, o Scrum Master tem
fazer o Sprint Backlog para que a equipe possa escolher as tarefas. O uso de post-its nas
tarefas, mesmo não fazendo parte dos artefatos do Scrum, é altamente recomendado
pela comunidade ágil, porém neste projeto não foi adotado, por se tratar de uma equipe
pequena e com facilidade de comunicação. O quadro 4 ilustra a primeira Product
Backlog gerada, com a visão geral do sistema.
As reuniões de início do dia levavam entre 15 e 20 minutos. Durante o Sprint, a
equipe precisava assumir uma tarefa, analisar, desenvolver e testar, uma funcionalidade.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
Na análise, o responsável pela tarefa verificava se possuía todas as informações
necessárias para sua realização, se fosse preciso tirar dúvidas de negócio, elas eram
tiradas com o especialista de domínio ou com o Product Owner. Como artefato de
apoio, os diagramas de UML foram utilizados.
Na maioria das tarefas, a programação era feita em pares, onde dois integrantes
da equipe dividiam o mesmo computador. Quando o Sprint estava próximo de chegar ao
fim, era agendada uma reunião com o Product Owner e a equipe passava a se preparar
para apresentar as novas funcionalidades. Na última semana do Sprint, já com as tarefas
concluídas, o sistema passava por uma bateria de testes e correção de pequenos erros.
Quadro 4 – Primeira Product Backlog para o FATEC-SBIB
Item
Inserir Obra
Atualizar Obra
Excluir Obra
Consultar Obra
Emprestar
Verificar usuário
(empréstimo)
Inserir Usuário
Atualizar Usuário
Excluir Usuário
Consultar Usuário
Devolução
Verificar atraso
Alunos em atraso
Alunos em débito
Rel. circulação
Consulta on-line
Como demonstrar
Inserir os dados da obra, verificar se os dados obrigatórios foram
preenchidos, confirmar solicitar confirmação.
Consultar a obra, alterar os dados, verificar se os dados
obrigatórios foram preenchidos, solicitar confirmação.
Consultar a obra, solicitar confirmação.
Oferecer opções de consulta como: Autor, Código, Categoria,
Título e Tipo.
Informar o usuário (RM), entrar com o(s) código(s) da(s) obra(s),
gerar data de devolução das obras, solicitar confirmação.
Ao digitar o RM verificar se o mesmo já não possui livros
emprestados, e se não é necessário atualizar os dados do usuário.
Inserir os dados do usuário, verificar se os dados obrigatórios
foram preenchidos, solicitar confirmação.
Consultar o usuário, alterar os dados, verificar se os dados
obrigatórios foram preenchidos, solicitar confirmação
Consultar/Selecionar o usuário, solicitar confirmação
Oferecer opções de consulta tais como: Nome, CPF,RM,etc.
Consultar o usuário ou o código de uma de suas obras, escolher
os livros que serão devolvidos, solicitar confirmação.
Quando efetuada a seleção da obra em atraso o sistema deve
gerar a multa ou os dias de suspensão.
Mostrar os usuários em atraso, dar a possibilidade de buscar por
um intervalo de data, por mês ou atual.
Mostrar os usuários em débito, dar a possibilidade de buscar por
um intervalo de data, por mês ou atual.
Exibir os livros de maior circulação organizados por categoria.
Permitir consultar as obras pela Internet
Fonte: Vigidio (2009)
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
Durante a reunião de apresentação com o Product Owner, o Scrum Master fazia
uma pequena retrospectiva dos itens escolhidos no planejamento do Sprint e depois a
equipe apresentava o sistema. Após avaliar a apresentação o Product Owner e o Scrum
Master atualizavam e a priorizava Product Backlog, neste momento se iniciava o
planejamento do próximo Sprint.
O Projeto contou com cinco Sprints, com aproximadamente 30 dias cada, que se
aconteceram entre Fevereiro a Agosto do ano de 2009. Sendo a 3º Sprint levou mais
tempo que o recomendado para terminar, cerca de 60 dias, também houve uma pausa
durante o mês de Julho. Ressalta-se que ao final da 4º Sprint o sistema já atendia a todas
as funcionalidades requeridas no 1º Product Backlog, sendo o último Sprint programado
apenas para uma depuração do produto final.
A versão final do sistema contou com as seguintes funcionalidades: Cadastro de
obras; Cadastro de usuários; Cadastro de leitores; Empréstimo de livros; Devolução de
obras; Renovação de obras; Registro de multas; Consulta de obras por: Código, Título,
Autor, Categoria, Assunto, ISBN; Consulta de usuários por: Nome, Registro, CPF;
Consulta de obras emprestadas; Consulta de multa. Os relatórios da versão final foram:
controle e auditoria, entre eles: Obras; Usuários; Livros mais emprestados; Estatísticas
de atrasos; Estatísticas de multa.
Ao final do projeto a equipe concluiu que: (1) a equipe deve obrigatoriamente
possuir profundo conhecimento da arquitetura selecionada; (2) em se tratando de
aplicações desenvolvidas por metodologias ágeis, por mais flexíveis que estas sejam,
seus princípios devem ser conhecidos e respeitados por toda a equipe, e (3) o sucesso do
projeto depende fortemente do comprometimento da equipe com os objetivos.
8. Considerações Finais
Os sistemas informatizados tornaram-se se uma parte essencial na maioria das
empresas, como ativo de valor. A necessidade de ligação entre as áreas para obter as
informações com mais rapidez e facilidade, demanda sistemas informatizados. Isto
também é aplicado ao ambiente de uma biblioteca, quanto mais rápida for a consulta de
uma obra ou a realização de um empréstimo, melhor não só para o usuário final, como
também para a equipe da biblioteca. Essa necessidade de sistemas gerou a evolução dos
métodos de desenvolvimento para que eles atendessem em tempo hábil ao usuário e
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
também permitissem facilidade de manutenção. O Paradigma OO aliado ao modelo de
desenvolvimento em Multicamadas agrega qualidade ao processo de desenvolvimento,
possibilitando manutenções e atualizações mais rápidas e sem a necessidade de se
atualizarem as máquinas dos clientes.
No desenvolvimento deste Sistema o modelo em Multicamadas mostrou-se
eficiente e eficaz graças à utilização do método ágil Scrum. O sistema gerado
demonstrou ser funcional e de fácil operação nos testes com os stakeholders.
Um sistema necessita de constante manutenção e melhorias para o
acompanhamento de novas necessidades e tecnologias. Como trabalhos futuros, os
autores prevêem: Implantação do sistema; Treinamento de usuários; Suporte e
manutenção; Criação de módulo on-line de consulta e renovação; Levantamento e
falhas e melhorias e desenvolvimento da segunda versão.
O sistema desenvolvido para a FATEC-SB, foi disponibilizado gratuitamente
como software livre. O site da FATEC-SB está sendo reformulado e assim que
concluído permitirá o download completo do sistema, incluindo Instalador, Backup do
banco de dados em estado inicial, Código fonte e Instruções de Uso. Antes disso, o
sistema pode ser solicitado por e-mail aos autores.
9. Referências
BATTISTI, J. Criando Aplicações em 3,4 N Camadas, 2003. Disponível em:
http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp. Acessado em 15 nov. 2009
BEZERRA; E., Princípios de Análise e Projeto de Sistemas com UML. 2. ed. Rio de
Janeiro: Campus, 2006.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I., UML: Guia do Usuário. 2. ed. Rio de
Janeiro: Campus, 2006.
ELMASRI, R.; NAVATHEM, S. B. Sistema de Banco de Dados. 4ª Edição. São
Paulo:Perarson Addison Wesley, 2005.
FATEC-SB. Faculdade de Tecnologia de São Bernardo do Campo. Disponível em:
<http://www.fatecsbc.edu.br/institucional.htm>. Acesso em nov. 2009.
FERNANDES, A. U. Banco de Dados para Biblioteca: FATEC-SB, um Estudo de
Caso. Monografia de conclusão de curso para obtenção do título de Tecnólogo em
Informática para gestão de negócios. FATEC-SB. 2009.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
GERMANO,
V.
H.
Scrum
for
team
system.
Disponível
em:
<http://scrumforteamsystem.com/ProcessGuidance/v2>. Acesso em out. 2009.
GRANATYR,
J.
Introdução
ao
modelo
multicamadas.
Disponível
em:
<http://www.devmedia.com.br/articles>. Acesso em dez. 2009.
KNIBERG, H. Scrum e XP direto das trincheiras – Como nós fazemos Scrum. São
Paulo: InfoQ, 2007.
KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de software: Aprenda as
metodologias e técnicas mais modernas para o desenvolvimento de software. 2ª Ed. São
Paulo: Novatec, 2007.
LAKATOS, E. M.; MARCONI, M. A. Fundamentos de Metodologia Científica. São
Paulo: Ed. Atlas, 1985.
LARMAN, C. Agile and Iterative Development: A Manager's Guide. São Paulo:
Addison-Wesley Professional, 2003.
MARTINS, J. C. C. Técnicas de Gerenciamento de Projetos de Software. São
Paulo:Brasport, 2007.
MICROSOFT. How to buy Microsoft Visual Studio 2008. Disponível em:
<http://www.microsoft.com/visualstudio/en-us/howtobuy>. Acesso em dez. 2009.
NEWARD,
T.
Arquitetura
Pragmática.
2003.
Disponível
em:
http://msdn.microsoft.com/pt-br/library/aa905336.aspx. Acessado em out. 2009
RICARTE, L. M. Definições de orientação a objetos. 2001. Disponível em:
http://www.dca.fee.unicamp.br/cursos/POOCPP/node4.html. Acessado em 20 out. 2009
ROQUE, T. de A. Arquitetura Multicamadas Aplicada a um Sistema de Biblioteca.
Monografia de conclusão de curso para obtenção do título de Tecnólogo em Informática
para gestão de negócios. FATEC-SB. 2009.
SANTOS, L. C. dos. Microsoft Visual C# 2008 Express Edition: Aprenda na Prática.
1ª. Ed. São Paulo:Editora Érica, 2009.
SILBERSCHATZ, A; KORTH, H. F; SUDARSHAN, S. Sistemas de Banco de Dados.
São Paulo: Ed. Makron Books, 1999.
SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison
Wesley, 2007.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.
Fasci-Tech
TONSING, S. L. Engenharia de Software: Análise e Projeto de Sistemas. 2ª. Ed. Rio
de Janeiro: Ciência Moderna, 2008.
VIGIDIO, B. DE L. Aplicação do SCRUM no desenvolvimento e sistemas. Monografia
de conclusão de curso para obtenção do título de Tecnólogo em Informática para gestão
de negócios. FATEC-SB. 2009.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v.1, n. 2, Jan./Jun. 2010, p.
97 a 112.