ROBSON SCATOLON

PROPOSTA DE UM PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE PARA
UMA EMPRESA DE PEQUENO PORTE

LAVRAS
MINAS GERAIS - BRASIL
2014
 ROBSON SCATOLON

PROPOSTA DE UM PROCESSO DE DESENVOLVIMENTO DE

SOFTWARE PARA UMA EMPRESA DE PEQUENO PORTE

Relatrio de estgio supervisionado

no obrigatrio apresentado ao
Colegiado do Curso de Sistemas de
Informao, como parte das
exigncias para a obteno do ttulo
de Bacharel em Sistemas de
Informao.

Orientador
Dr. Heitor Augustus Xavier Costa

LAVRAS
MINAS GERAIS - BRASIL
2014
 AGRADECIMENTOS
A Deus, por todas as bnos em minha vida, por sempre estar ao
meu lado dando fora para superar as dificuldades.
Aos meus pais Carlos Augusto e Damiana, pelo amor, incentivo e
apoio incondicional.
Ao meu orientador Heitor Augustus Xavier, pelo conhecimento.
A Universidade Federal de Lavras, seu corpo docente, em especial
aos professores e funcionrios do departamento de Cincia da Computao,
que oportunizaram o aprendizado e conhecimento constante.
E a todos que direta ou indiretamente fizeram parte da minha
formao, o meu muito obrigado.
 SUMRIO

LISTA DE FIGURAS
LISTA DE TABELAS

1 INTRODUO ................................................................................ 1
1.1 Empresa-Alvo ................................................................................... 2
1.2 Motivao ......................................................................................... 2
1.3 Objetivo ............................................................................................ 3
1.4 Procedimentos Metodolgicos ........................................................ 3
1.5 Estrutura do Trabalho .................................................................... 4

2 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE .... 5

2.1 Consideraes Iniciais ..................................................................... 5
2.2 Modelo de Processo de Desenvolvimento Cascata ........................ 6
2.3 Modelo de Processo de Desenvolvimento Processo Unificado ..... 7
2.4 Consideraes Finais ....................................................................... 9

3 PROPOSTA DE PROCESSO DE DESENVOLVIMENTO ...... 10

3.1 Consideraes Iniciais ................................................................... 10
3.2 Entendimento do Desenvolvimento Software da Empresa-Alvo10
3.3 Atual Processo de Desenvolvimento da Empresa-Alvo .............. 11
3.4 Descrio do Processo de Desenvolvimento Proposto ................ 15
3.4.1 Fase Desenvolvimento de Requisitos ............................................ 17
3.4.2 Fase Desenvolvimento (Criao)................................................... 19
3.4.3 Fase Gerenciamento de Requisitos ............................................... 22
3.4.4 Fase Finalizao do Projeto .......................................................... 23
3.5 Consideraes Finais ..................................................................... 24

4 Aplicao do Processo Proposto ................................................... 26

4.1 Consideraes Iniciais ................................................................... 26
4.2 Descrio do Desenvolvimento do Software ................................ 26
4.2.1 Desenvolvimento de Requisitos ..................................................... 26
4.2.2 Desenvolvimento (Criao) ........................................................... 28
4.2.3 Gerenciamento de Requisitos........................................................ 29
4.2.4 Finalizao do Projeto ................................................................... 29
4.3 Descrio do Software ................................................................... 29
4.4 Modelagem do Software ................................................................ 30
4.4.1 Diagrama de Caso de Uso.............................................................. 30
4.4.2 Diagrama de Classes ...................................................................... 30
4.4.3 Diagrama de Navegao ................................................................ 33
4.5 Modelagem de Dados ..................................................................... 35
4.6 Funcionalidade ............................................................................... 35
4.7 Consideraes Finais ..................................................................... 44

5 CONSIDERAES FINAIS ........................................................ 46

5.1 Concluses ...................................................................................... 46
5.2 Contribuies e Dificuldades Encontradas .................................. 46
5.3 Disciplinas Abordadas ................................................................... 48
5.4 Trabalhos Futuros ......................................................................... 48

REFERNCIAS BIBLIOGRFICAS ...................................................... 49

 LISTA DE FIGURAS

Figura 1 Modelo Cascata .......................................................................... 6

Figura 2 Artefatos Gerados na Etapa Planejamento do Projeto ......... 13

Figura 3 Artefatos Gerados na Etapa Anlise de Requisitos ............... 14

Figura 4 Artefatos Gerados na Etapa Desenvolvimento ...................... 14

Figura 5 Artefatos Gerados no Processo de Testes ............................... 15

Figura 6 Processo de Desenvolvimento Proposto .................................. 17

Figura 7 Fase Desenvolvimento de Requisitos ...................................... 18

Figura 8 Fase Desenvolvimento (Criao) ............................................. 21

Figura 9 Fase Gerenciamento de Requisitos ......................................... 23

Figura 10 Fase Finalizao do Projeto ..................................................... 24

Figura 11 Diagrama de Caso de Uso ........................................................ 31

Figura 12 Diagrama de Pacotes ................................................................ 32

Figura 13 Diagrama de Classes do Pacote Business ............................... 33

Figura 14 Diagrama de Classes do Pacote Persistncia.......................... 34

Figura 15 Diagrama de Classes do Pacote de Entidades ........................ 34

Figura 16 Diagrama de Navegao .......................................................... 35

Figura 17 Modelagem de Dados ............................................................... 35

Figura 18 Tela de Login............................................................................. 36

Figura 19 Tela de Solicitao de Chave do Sistema................................ 37

Figura 20 Tela Inicial (Usurio Contador) .............................................. 38

Figura 21 Tela de Exibio de Documentos (Usurio Contador) .......... 39

Figura 22 Tela de Envio de Documentos (Usurio Contador) ............... 39

Figura 23 Tela de Registro de Novos Clientes ......................................... 40

Figura 24 Tela de Registro de Usurios Contadores .............................. 40

Figura 25 Tela de Adio e Excluso de Categorias de Documentos .... 41

Figura 26 Tela de Configuraes (Usurio Contador) ........................... 42

Figura 27 Tela Inicial (Usurio Cliente) .................................................. 42

Figura 28 Tela de Exibio de Documentos (Usurio Cliente) .............. 43

Figura 29 Tela de Contato com o Contador ............................................ 44

 LISTA DE TABELAS

Tabela 1 Atividades Realizadas .................................................................. 4

Tabela 2 Descrio do Caso de Uso: Enviar Documento ....................... 31

 RESUMO

Este trabalho trata de um estudo de caso de uma empresa de software de

pequeno porte qual proposto um modelo de processo de
desenvolvimento. Feito um levantamento bibliogrfico na rea de
Engenharia de Software em busca de trabalhos relacionados a modelos de
processos de desenvolvimento. Na sequncia, a fim de entender melhor a
real situao da empresa-alvo, foi realizada uma observao participante
junto ao corpo de funcionrios responsveis pelas atividades de
desenvolvimento da empresa. Neste contexto, foram obtidas maiores
informaes sobre as atividades envolvidas no decorrer do processo de
desenvolvimento atual para possibilitar criar a proposta atendendo de melhor
forma a realidade e as necessidades da empresa. Ao fim apresentada uma
proposta de processo de desenvolvimento buscando a melhor ocupao dos
recursos e artefatos disponibilizados pela empresa, sendo aplicada ao
desenvolvimento de um software Gerenciador Eletrnico de Documentos
(GED).

Palavras-chave: Processo de Desenvolvimento de Software,

Desenvolvimento de Software, GED

ABSTRACT

This work deals with a case study of a small software company which is a
proposed model of development process. In order to better understand the
real situation of the target company, was held a participant observation
beside the body of officials responsible for development activities of the
company. In this context, were obtained more information about the
activities involved in the course of the development process to enable current
creating the proposal in view of better way to reality and the needs of the
company. The order is submitted a proposal for development process
seeking the best occupation of resources and artifacts made available by the
company, being applied to the development of Electronic Manager
Documents (EMD) software.

Keywords: Software Development Process, Software Development, EDM

1 INTRODUO

As prticas e as tcnicas para processos de desenvolvimento de

sistemas de software surgem a cada dia. Um problema notado saber quais
tcnicas devem ser aplicadas na prtica pelas empresas desenvolvedoras de
software. Processos de desenvolvimento variam entre essas empresas, pelo
fato da realidade a qual a empresa est inserida e da cultura organizacional
existente influenciarem na adoo de um processo de desenvolvimento.

Nesse sentido, interessante observar quais tcnicas so utilizadas na

empresa desenvolvedora de software de pequeno porte em que foi realizado
este estudo (Empresa-Alvo) para propor uma viso do que seriam processos
de desenvolvimento para produzir produtos finais com qualidade. Para isso,
observao participativa por meio do estgio foi utilizada para elicitar os
mtodos e as atividades presentes na Empresa-Alvo. Dessa forma foram
observados os processos de desenvolvimento de software juntamente com a
equipe responsvel pelas atividades de desenvolvimento da empresa, visando
obteno de conhecimento prtico sobre sua realidade. Para que este
estudo fosse vlido, os resultados observados foram descritos de forma
imparcial e realista, visando descobrir quais atividades e subprocessos
presentes nos processos de desenvolvimento foram omissos ou aplicados de
forma incorreta.

A fim de propor melhorias para a atual situao do processo de

desenvolvimento da Empresa-Alvo desse trabalho, foi elaborada uma
proposta de processo de desenvolvimento de software aplicada realidade
da empresa, por meio do desenvolvimento do software Gerenciador
Eletrnico de Documentos. Os passos e as atividades presentes durante o
desenvolvimento desse software foram descritos.
1.1 Empresa-Alvo

A presente empresa em que este trabalho foi realizado foi fundada em

2002 por dois programadores em parceria com uma empresa de Automao
Comercial. A parceria aconteceu pela necessidade da criao de um software
para auxiliar as atividades de gesto de pequenos comrcios varejistas. Nos
dias atuais, a Empresa-Alvo conta com cerca de 30 colaboradores e
aproximadamente 1.500 clientes ativos espalhados entre os estados de So
Paulo, Rio de Janeiro e, principalmente, Minas Gerais.

Os produtos de software desenvolvidos pela empresa so sistemas

gerenciais para o comrcio atacadista e varejista desenvolvidos para
plataforma desktop (Windows) e mvel (Palm e Android). Recentemente, a
empresa expandiu seu segmento de produtos abordando tecnologias Web a
fim de acompanhar as tendncias do mundo atual. Apesar de a empresa
possuir pouco tempo de existncia, a demanda por seus sistemas de
softwares vem crescendo, possibilitando a expanso de toda sua estrutura
fsica e setorial. O organograma da empresa conta com os setores comercial,
de treinamento, de suporte, de desenvolvimento e de teste. Os principais
setores que este trabalho deu enfoque foram os setores de desenvolvimento e
testes que contam com sete analistas de desenvolvimento e dois analistas de
testes. Esses colaboradores so os atuais responsveis pelo processo de
desenvolvimento de software no atual da Empresa-Alvo.

1.2 Motivao

A principal motivao deste trabalho foi a possibilidade de vivenciar

na prtica, o acesso a teoria abordada nas disciplinas da rea de Engenharia
de Software, com a possibilidade de interagir com uma equipe de
desenvolvimento de software e observar o processo de desenvolvimento na
prtica. Outras motivaes deste trabalho foram:
Falta de um processo de desenvolvimento bem definido em empresas de
pequeno porte (possibilidade de contribuies neste sentido);

2
 Interao com profissionais da rea;
Obter maior viso e compreenso das barreiras criadas pelos
profissionais do setor de desenvolvimento para a aplicao de algumas
tcnicas de Engenharia de Software;
Conhecimento de padres de desenvolvimento aplicados na Empresa;
Aplicao da teoria junto a prtica existente na realidade de uma
Empresa de Software.

1.3 Objetivo

Neste trabalho, o objetivo foi propor um processo de desenvolvimento

de software para uma empresa de pequeno porte. Como objetivos
especficos, tm-se:
Identificar mtodos aplicados no setor de desenvolvimento da
empresa;
Propor melhorias para o processo de desenvolvimento da empresa;
Criar um Software junto equipe de desenvolvimento (GED).

1.4 Procedimentos Metodolgicos

Inicialmente, foi realizada uma procura por livros e artigos com

trabalhos relacionados objetivando o entendimento de processos de
desenvolvimento de software e conhecimento especficos que auxiliassem na
construo deste trabalho. Aps essa etapa, foram realizadas reunies com
diretores da empresa para obter mais conhecimento sobre a atual situao
das atividades de desenvolvimento, do ponto de vista da alta gerncia, e
conscientizar sobre o contexto em que a Empresa-Alvo se encontra. Diversas
reunies foram realizadas com os diretores da Empresa-Alvo, sendo
necessria a participao junto aos desenvolvedores para que pudessem ser
observadas as atividades e as rotinas empregadas no cotidiano da empresa.
Aps a elicitao das informaes do atual processo, foi construda uma
proposta de desenvolvimento de software, propondo melhorias para o ciclo
de desenvolvimento da Empresa-Alvo. Posteriormente foi aplicado o

3
processo propostos atravs do desenvolvimento de um software Gerenciador
Eletrnico de Documentos, junto com os profissionais responsveis.

O cronograma da execuo do trabalho com as atividades realizadas

apresentado na Tabela 1.

Tabela 1 Atividades Realizadas

2 Perodo Letivo de 2013
Atividades
Outubro Novembro Dezembro Janeiro
Reviso bibliogrfica
Reunies com diretores da empresa
Observao participativa nas atividades de
desenvolvimento
Construo da proposta de
desenvolvimento de software
Aplicao do processo proposto

1.5 Estrutura do Trabalho

Este trabalho est organizado da seguinte forma.

Breve descrio dos conceitos de processos desenvolvimento de

software e modelos de ciclo de vida de processos de software apresentada
no Captulo 2.

O atual processo de desenvolvimento, relatando posteriormente uma

proposta de processo para desenvolvimento de sistemas de software,
descrito no Captulo 3.

A descrio do software desenvolvido junto com a equipe de

desenvolvimento da Empresa-Alvo atravs da aplicao da proposta
apresentada no Captulo 4.

Concluses, contribuies, sugestes de trabalhos futuros so tratadas

no Captulo 5.

4
2 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

1.1 Consideraes Iniciais

Um modelo de processo de desenvolvimento de software pode ser

visto como uma representao ou abstrao das atividades envolvidas no
processo. Alm disso, oferece uma forma abrangente de representar o
gerenciamento de processo de software, alm do progresso do projeto
(LOURENO; BENINI, 2011). Processo um conjunto de passos
parcialmente ordenados, constitudos por atividades, mtodos, prticas e
transformaes e utilizados para atingir uma meta (PAULA FILHO, 2002).
Em geral, essa meta est associada a um ou mais resultados concretos finais
chamados produtos da execuo do processo.

Geralmente, os processos a serem aplicados so previamente

estabelecidos no planejamento do projeto, onde as estratgias so traadas
para o projeto. de responsabilidade do Engenheiro de Software traar essas
caractersticas fundamentais. Muitos so os modelos de processos propostos
para as realidades de empresas de desenvolvimento, porm a escolha de qual
modelo a ser aplicado pode ser difcil. A escolha tem que ser adequada
realidade de cada empresa, em que seus aspectos, tais como, tamanho,
quantidade e tamanho dos projetos e funcionrios, so colocados em
destaque. Muitas vezes, necessria a contratao de consultoria
especializada para auxiliar nessa atividade. Nesta seo, so abordados os
modelos de processos de desenvolvimento de software: Cascata e UP.

Breve descrio do modelo de processo de desenvolvimento Cascata

apresentada na Seo 2.2. Breve descrio do modelo de processo de
desenvolvimento Processo Unificado (UP) apresentada na Seo 2.3.
1.2 Modelo de Processo de Desenvolvimento Cascata

Cascata um modelo em que as fases do processo ocorrem de forma

sequencial, pois a prxima fase comea quando a anterior estiver finalizada
(Figura 1). Esse modelo pode ser considerado um dos mais antigos entre os
modelos dos processos, sendo utilizado em algumas empresas em que o
contexto do software a ser desenvolvido seja estvel (h poucas mudanas
nos requisitos) (JUNG, 2009). Algumas dificuldades podem ser encontradas
na sua aplicao, por exemplo, as fases dos processos ocorrem em forma
sequencial e no h previso de entrega de uma verso parcial do software
em desenvolvimento ao cliente/stakeholders. Dessa forma, existe a
possibilidade de, aps serem realizadas as fases previstas no modelo, o
produto no estar de acordo com as necessidades do cliente.

Definio
de
Design e
Requisitos
Arquitetura
Implement
ao Integrao
e Teste
Operao e
Manuteno

Figura 1 Modelo Cascata

Ao analisar o modelo Cascata, possvel perceber que a falta de

interao por parte do cliente com o desenvolvimento pode vir a causar
problemas quando escolhida a aplicao do modelo. importante citar que,
em alguns casos, clientes no conseguem especificar os requisitos do
software, tornando a tarefa de captao e de anlise desses requisitos mais
dificultada, alm de necessitar de calma e de pacincia por parte do cliente,
pois o software poder ser visualizado ao final do processo (SAYO;
BREITMAN, 2005). Nesse modelo, so consideradas atividades

6
fundamentais do processo de desenvolvimento promovendo abordagem
sistemtica e sequencial que possui as fases (SOMMERVILLE, 2009):
Definio dos Requisitos. Nessa fase, so geradas especificaes dos
requisitos do software por meio de consultas com usurios e clientes. A
especificao dos requisitos gerada indica "o que" ser implementado;
Design e Arquitetura. Nessa fase, descrita a arquitetura do sistema,
indicando "como" o software dever ser implementado;
Implementao. Nessa fase, o cdigo fonte gerado, sendo codificadas
as unidades do sistema;
Integrao e Teste. Nessa fase, as unidades desenvolvidas da etapa
anterior so integradas e testadas, verificando e validando os requisitos
elicitados na fase Definio de Requisitos;
Operao e Manuteno. Nessa fase, o sistema instalado no cliente,
existindo a deteco e a correo dos erros no descobertos em outras
fases. Alm disso, podem surgir novos requisitos, possibilitando a
evoluo do sistema.

1.3 Modelo de Processo de Desenvolvimento Processo Unificado

O Processo Unificado (Unified Process - UP) um modelo que visa

garantia da alta qualidade em tempo e custos previsveis para a produo de
software (SCOTT, 2003). Geralmente, ele aplicado em grandes ou mdias
empresas, por ser considerado um "modelo pesado". Porm, sua estrutura
facilmente adaptvel a diversos tipos de organizaes facilitando a sua
implantao. Isso se deve a seus componentes no serem extremamente
necessrios para cada fase do projeto, possibilitando realizar uma anlise
para cada caso e perceber com a necessidade de uso de acordo com o projeto
e a organizao que o implementar. O UP baseado em componentes,
fazendo o uso da UML (Unified Modeling Language) para documentar,
modelar e especificar artefatos. O modelo guiado por casos de uso e
centrado na arquitetura e possui abordagem totalmente iterativa, pois
defende no ser possvel definir os problemas a serem abordados em um

7
nico passo, tornando-o iterativo e incremental. Sua integrao realizada
durante o processo de desenvolvimento, sendo menos complexo, reduzindo
custo e aumentando a eficincia. No UP, as interaes so incentivadas,
fazendo com que os stakeholders estejam ativos com cada entrega, tentando
verificar se o que foi produzido est de acordo com o desejado; caso
contrrio, traz mostra as pendncias por parte do desenvolvimento para
com o projeto. O UP possui um quatro fases (SCOTT, 2003): i) Concepo;
ii) Elaborao; iii) Construo; e iv) Transio.

A fase Concepo possui como principal objetivo definir o escopo do

projeto. Nessa fase, so identificados os requisitos essenciais do software,
com o auxlio dos stakeholders. Esta etapa no possui o objetivo de realizar
uma anlise fechada, mas realizada para ter a primeira ideia do que
necessrio para o software. Na fase Elaborao, a arquitetura e a viso dos
produtos so definidas. Os requisitos do sistema abrangem desde declaraes
de carter geral a critrios preciosos de avaliao, em que cada requisito
especifica o determinado comportamento funcional e proporciona a base
para realizao de testes. Nessa fase, complementada a identificao dos
requisitos ou documentao dos casos de uso, voltados para a arquitetura do
sistema, revisando a modelagem do negcio para os projetos e inicia a
verso do manual do usurio. Alm disso, deve ser feita uma anlise da
estabilidade da viso geral do produto, se o plano do projeto confivel e se
os custos so admissveis. Na fase Construo, o sistema desenvolvido e
testado, gerando uma arquitetura baseline executvel e destinada
transferncia para a comunidade de usurios. Os testes realizados nessa fase
tm o objetivo de verificar se o sistema atende os requisitos e os critrios de
avaliao. A fase Transio no possui o intuito de finalizar o processo, mas
o aprimoramento contnuo do sistema, com a descoberta de bugs que
possibilitam a correo e acrscimo de novas caractersticas ao sistema.

8
 O UP define um guia para controlar atividades para a equipe de
desenvolvimento, realizando o direcionamento de tarefas para cada
desenvolvedor em especfico. Com o UP, podem ser especificados
detalhadamente os artefatos a serem desenvolvidos e os critrios para
monitorar as atividades do processo de desenvolvimento.

1.4 Consideraes Finais

Processos de desenvolvimento variam entre as diversas empresas de

software, sendo diretamente influenciados com a cultura de cada
organizao em que so aplicados. A aplicao correta dos processos no
desenvolvimento pode acarretar inmeras vantagens no s para o sistema
final, mas para a prpria organizao que pode diminuir o gasto
desnecessrio de tempo, melhores relatos e diminuio do custo do software.

Entretanto, para que os benefcios sejam alcanados, importante

conscientizao de todos os membros da equipe de desenvolvimento da
importncia de seguir um processo de desenvolvimento e as possveis
melhorias geradas. Assim, passos definidos no processo de desenvolvimento
no so cortados na primeira dificuldade a ser encontrada no cotidiano no
decorrer do projeto.

Neste captulo, foram apresentados dois modelos de processo de

desenvolvimento de software, ajudando a realizar a escolha das atividades a
serem abrangidas na proposta de processo de desenvolvimento, de forma a
satisfazer as necessidades encontradas no cotidiano das atividades da
Empresa-Alvo.

9
3 PROPOSTA DE PROCESSO DE DESENVOLVIMENTO

1.1 Consideraes Iniciais

Neste captulo, proposto um processo de desenvolvimento de

software elaborado com o objetivo de proporcionar melhorias das atividades
de desenvolvimento presentes na Empresa-Alvo. Para que o leitor possa ter
maior conhecimento sobre a realidade da EmpresaAlvo, realizada a
descrio sobre o atual processo de desenvolvimento, especificando as
atividades envolvidas durante o ciclo de vida do processo.

Definio das etapas para entendimento do funcionamento da

Empresa-Alvo no desenvolvimento de software apresentada na Seo 3.2.
O atual processo de desenvolvimento descrito na seo 3.3. Descrio
detalhada das etapas do processo proposto mostrada na Seo 3.4.

1.2 Entendimento do Desenvolvimento Software da Empresa-Alvo

Para a elaborao do processo de desenvolvimento, foram definidas

algumas etapas para entender como a Empresa-Alvo desenvolve o software,
cujo objetivo obter um processo que se encaixasse no perfil da Empresa-
Alvo da melhor forma. Foram definidas quatro etapas:
Primeira Etapa. Nessa etapa, houve a busca por metodologias de
desenvolvimento de software na literatura. As referencias bibliogrficas
serviram para dar apoio sobre metodologias existentes de diversos tipos
de processos de desenvolvimento, ajudando a conhecer tcnicas
utilizadas que serviram de base para o processo de desenvolvimento
proposto para a Empresa-Alvo;
Segunda Etapa. Nessa etapa, h reconhecimento/entendimento da
organizao e da sua estrutura, ocorrendo conversas onde foi possvel
conhecer um pouco sobre a cultura organizacional, sua estrutura e seus
recursos. Essa etapa foi fundamental, pois foi possvel ter uma viso da
empresa do ponto de vista da alta gerncia, levantando os atuais
 problemas da empresa e quais so as barreiras encontradas na viso dos
diretores da Empresa-Alvo. Alm da viso dos diretores, a viso dos
funcionrios que atuam nas atividades de desenvolvimento cotidianas da
empresa foi considerada;
Terceira Etapa. Nessa etapa, o intuito foi obter uma viso de um
funcionrio que no estivesse relacionado com atividades de
desenvolvimento. Assim, ocorreu participao ativa durante algumas
atividades de desenvolvimento em um projeto de software junto com a
equipe responsvel. Com essa participao, foi possvel obter uma viso
imparcial da realidade Empresa-Alvo e realizar a anlise sobre os
recursos disponibilizados para o processo de desenvolvimento,
procurando aplicar o processo de desenvolvimento a ser proposto;
Quarta Etapa. Nessa etapa, foi elaborado o processo de
desenvolvimento, considerando informaes extradas das etapas
anteriores para obter um processo de desenvolvimento de forma a gerar
benefcios s atividades de construo de software presentes na
Empresa-Alvo. Com as informaes obtidas na segunda e terceira
etapas, foi possvel perceber os recursos, as deficincias, as
oportunidades e diversos outros fatores a serem considerados ao propor
o processo de desenvolvimento. Aps a sntese das informaes com
auxlio do conhecimento de metodologias existentes (primeira etapa),
teve-se embasamento para a elaborao do processo. Nessa presente
etapa foi utilizado o plug-in EPF (Eclipse Process Framework) [The
Eclipse Foundation, 2014] da ferramenta Eclipse que utiliza a linguagem
de modelagem SPEM (Software Process Engineering Metamodel)
(SPEM, 2008).

1.3 Atual Processo de Desenvolvimento da Empresa-Alvo

A empresa por no possuir muito tempo de existncia e estar passando

por um processo de evoluo constante nos ltimos tempos no possui um
framework definido sobre as atividades de desenvolvimento. Sua estrutura

11
no definida, pois os passos existentes no processo de desenvolvimento
muitas vezes no so aplicados pelo fato de haver atraso relativo ao tempo
proposto para o desenvolvimento do software. Contudo, a Empresa-Alvo
encontra-se em crescimento e est procura da melhor forma de realizar seu
processo de desenvolvimento, tentando cada vez mais adequar suas
atividades para aperfeio-lo.

O projeto que engloba o processo de desenvolvimento geralmente

efetuado de forma mensal, sendo liberada uma verso ao ms para o seu
sistema, possibilitando que o cliente da empresa sempre mantenha seu
software atualizado. Um importante fator para que a atualizao ocorra de
forma mensal o tempo de o sistema estar indisponvel para o usurio
durante este processo, procurando manter uma verso atual do software sem
prejudicar as atividades do cotidiano do cliente. As atividades de
desenvolvimento podem ser basicamente resumidas em quatro etapas: i)
Planejamento do Projeto; ii) Anlise de Requisitos; iii) Desenvolvimento
(Programao); e iv) Testes.

Na etapa Planejamento do Projeto (Figura 2), so definidas quais

atualizaes ou mdulos a serem integrados ao sistema. Essa etapa
importante, pois, geralmente, a quantidade de correes e de requisies para
o sistema grande, tornando-se invivel para que possam ser efetuadas em
uma verso mensal. As sugestes de atualizaes podem ser apresentadas de
duas formas diferentes: i) pelos clientes, que podem faz-las por meio de um
canal disponibilizado pela Empresa-Alvo; e ii) pelo setor de testes, que, ao
realizarem suas atividades, fazem sugestes de melhorias ou erros no
sistema. A definio de quais atualizaes ou implementaes so realizadas
no sistema realizada por um dos diretores da empresa que atua diretamente
no setor de desenvolvimento com a ajuda dos profissionais pertencentes ao
departamento. Geralmente, as escolhas do prioridade a bugs relatados como
graves, por a empresa possuir o objetivo de bom funcionamento do sistema.

12
Nas verses disponibilizadas, so geradas novas implementaes para o
sistema.

Figura 2 Artefatos Gerados na Etapa Planejamento do Projeto

Logo aps serem definidas as atualizaes, o diretor presente no

desenvolvimento observa os requisitos necessrios. Nessa atividade no
realizado um contato mais prximo com cliente. Sendo assim, a anlise de
requisitos feita sobre dados obtidos na primeira requisio sem ter contato
mais a fundo para buscar entender melhor sobre as caractersticas e funes
necessrias. Os artefatos gerados na Etapa Anlise de Requisitos podem ser
observados na Figura 3.

Aps a fase Anlise de Requisitos, realizada a diviso de tarefas

entre os integrantes do departamento de desenvolvimento responsveis pela
programao. Nessa atividade, cada programador responsvel pela
correo bugs ou atualizaes no sistema. A atribuio de tarefas realizada
utilizando a ferramenta Mantis, utilizada pela Empresa-Alvo para controle
do andamento do desenvolvimento de novas verses e correes. Cada
programador tem que finalizar suas tarefas em um prazo de
aproximadamente 15 dias para que as atualizaes sejam testadas. Cabe
ressaltar que no existe documentao de forma que a definio dos
requisitos feita verbal e informalmente entre os funcionrios. As
informaes existentes esto presentes na ferramenta Mantis, com dados e

13
uma prvia descrio de afazeres destinados a cada programador. A etapa
Desenvolvimento e seus artefatos gerados so ilustrados na Figura 4.

Figura 3 Artefatos Gerados na Etapa Anlise de Requisitos

Figura 4 Artefatos Gerados na Etapa Desenvolvimento

Atividades de modelagem de software em UML no so implantadas

na empresa, deixando o desenvolvimento sem registros concretos de como
acontecem s aes no sistema. Outras atividades que possuem destaque na
Engenharia de Software no so existentes. A etapa Teste (Figura 5)
iniciada aps o prazo ser concretizado ou conforme a demanda gerada pelos
desenvolvedores medida que terminam correes ou novidades do sistema.
O setor de teste foi implantado recentemente na organizao, possuindo uma
estrutura simples, no tendo as atividades necessrias para realizar os testes

14
de maneira apropriada, por exemplo, testes em cdigo e automatizao de
testes.

Figura 5 - Artefatos Gerados no Processo de Testes

As atuais atividades de teste consistem em observar a funcionalidade

descrita na reunio inicial do planejamento, em que foi realizada a anlise de
requisitos da verso a ser gerada, e verificar se esto apresentveis no
sistema de forma a satisfazer os requisitos. Nessa etapa, so apresentados
bugs e sugestes de melhorias para os desenvolvedores relatados no Mantis;
se necessrio, so feitos alguns reajustes na verso para atender os padres
estabelecidos de usabilidade da Empresa-Alvo. Ao final do processo de
desenvolvimento, talvez a nica documentao presente atualmente na
Empresa-Alvo elaborada pelo setor teste, cuja funo relatar as mudanas
e as correes da verso. Nesse documento, existe descrio das funes
agregadas ao sistema, sendo relatados tambm os casos e seus devidos
responsveis (desenvolvedores).

1.4 Descrio do Processo de Desenvolvimento Proposto

O processo de desenvolvimento de software proposto para a Empresa-

Alvo proporciona maior interao entre steakholders, equipe de
desenvolvimento e membros da equipe de desenvolvimento. Com esse

15
processo, busca-se alcanar melhoria da utilizao dos recursos e
oportunidades existentes, tendo como objetivo proporcionar um processo
para criao de um software eficaz e prtico, fazendo com que o processo de
desenvolvimento possa se adequar com a necessidade do projeto. A fim de
gerar um processo de desenvolvimento adequado ao porte da empresa, foi
criado um processo que visa o enfoque da interao das pessoas e reduo da
quantidade de documentos gerados quando comparado a processos mais
tradicionais. O processo possui quatro fases: i) Desenvolvimento de
Requisitos; ii) Desenvolvimento; iii) Gerenciamento de Requisitos; e iv)
Fechamento do projeto.

O processo possui suas entregas de forma iterativa com o cliente,

visando sua maior participao no processo e entrega de um produto
consistente com a necessidade do cliente. Detalhe esquemtico do processo
de desenvolvimento proposto apresentado na Figura 6. Cada uma dessas
fases detalhada em outras atividades para elaborar os artefatos de software
necessrios.

16
Figura 6 Processo de Desenvolvimento Proposto

3.4.1. Fase Desenvolvimento de Requisitos

Essa fase est dividida em quatro atividades essenciais para gerar os

artefatos de software necessrios (Figura 7): i) Elicitao de Requisitos; ii)
Avaliao de Requisitos; iii) Especificao de Requisitos; e iv) Validao de
Requisitos. Cabe ressaltar que o fluxo entre as atividades no ocorre de
forma a seguir um fluxo nico, pois, caso exija a necessidade, um fluxo
alternativo, pode ser utilizado, visando correo dos artefatos obtidos nas
atividades anteriores. Detalhamento das atividades:
Elicitao de Requisitos. Nessa atividade, h o contato com o cliente
responsvel por definir os requisitos a serem alcanados durante o
desenvolvimento do software. A fim de iniciar as atividades de
elicitao de requisitos, necessrio realizar uma reunio definindo
formas e metodologias a serem aplicadas para que os artefatos

17
 (requisitos) sejam identificados. Essa reunio acontece, pois as tcnicas
para a elicitao dos requisitos no so fixas e pr-determinadas para os
projetos. Cada projeto pode utilizar tcnicas diferentes de extrao,
visando proporcionar maior flexibilidade a esta atividade. Isso acontece
por muitos projetos que a empresa responsvel possurem tempos e
espaos fsicos (distncia) diferentes. Nessa reunio, tambm so
definidas as pessoas responsveis por realizar as aplicaes das tcnicas
de levantamento de requisitos. As informaes geradas devem ser
apresentadas em um documento para dar suporte s atividades a serem
realizadas posteriormente;

Figura 7 Fase Desenvolvimento de Requisitos

Avaliao dos Requisitos. Nessa atividade, realizada uma avaliao

dos requisitos por parte da equipe responsvel pelo desenvolvimento.
Com essa avaliao, so construdos documentos e diagramas (artefatos)

18
 para o melhor entendimento dos membros da equipe. Alm disso, deve
ser analisada a viabilidade de implementao dos requisitos encontrados,
ajudando a definir custos e conflitos para a implementao de cada
requisito. Posteriormente a essa anlise, tem-se noo sobre o risco
envolvido para o atendimento de cada requisito;
Especificao dos Requisitos. Nessa atividade, os requisitos devem ser
detalhados utilizando documentos e diagramas construdos na atividade
anterior. Alm disso, ocorre definio de atores dos requisitos
definindo membros da equipe para a criao de cada um dos requisitos.
Uma importante tarefa para todo o projeto ocorre nessa atividade, a
observao da permisso de escrita nos mdulos base do sistema,
possibilitando aloc-los junto ao cronograma para o desenvolvimento,
evitando a disputa dos desenvolvedores por esses recursos. Outra tarefa
a ser realizada a verificao da possibilidade do reuso de mdulos
desenvolvidos anteriormente em outros projetos, visando causar menos
retrabalho na fase Desenvolvimento;
Validao de Requisitos. Nessa atividade, so elaborados critrios de
aceitao dos requisitos para realizar tarefas de revises dos requisitos
encontrados, com seus artefatos (diagramas e documentos), a fim de
eliminar defeitos e brechas encontradas. Essa atividade fornece suporte
ao setor de teste, pois so definidos casos de testes e padres aceitveis
para a futura validao dos requisitos que ocorre na fase
Desenvolvimento.

3.4.2. Fase Desenvolvimento (Criao)

Na fase Desenvolvimento, ocorre a criao e o teste do sistema. Nesta

fase, so utilizados artefatos gerados na fase anterior, como os documentos
de requisitos, diagramas e padres de aceitao. O detalhe esquemtico da
fase Desenvolvimento apresentado na Figura . A fim iniciar essa fase,
necessrio existir breve descrio das principais ferramentas e recursos
utilizados, tais como, sistemas gerenciadores de banco de dados, IDEs,

19
software para controle de verso e ferramenta para registro de sugestes e
correo de erros. Com a utilizao dos recursos e das ferramentas, as
atividades de desenvolvimento devem iniciar de forma a seguir as atividades
descritas na fase Desenvolvimento de Requisitos, seguindo o calendrio e
prazos estabelecidos. Para ter controle sobre o projeto, devem acontecer
pequenas reunies diariamente entre os envolvidos no projeto para que haja
feedback sobre o andamento do desenvolvimento. Essas reunies so breves,
com durao de 15 minutos, citando dificuldades encontradas e evolues no
projeto.

Com as reunies dirias, possvel obter noo sobre o

desenvolvimento e consequentemente, controle sobre o prazo e riscos
referentes a atrasos no cronograma. Um importante fator a maior interao
entre a equipe de desenvolvimento, forando a existncia de cooperao
entre os profissionais responsveis pelo desenvolvimento. Com o auxlio da
ferramenta de controle de verso Tortoise SVN, possvel garantir a
consistncia entre as verses do sistema, possibilitando o desenvolvimento
modular e acarretando maior flexibilidade na alocao das tarefas. Aps o
desenvolvimento, o profissional passa o artefato criado (mdulo do sistema)
para que o setor de testes possa iniciar seus trabalhos. As atividades de teste
abordam a validao dos requisitos descritos no documento de requisitos,
realizando a validao dos padres previamente estabelecidos. Caso existam
discordncias com os requisitos e seus padres, o analista de teste deve
notificar o analista de desenvolvimento responsvel pelo mdulo.

20
Figura 8 Fase Desenvolvimento (Criao)

Caso o desenvolvimento satisfaa os requisitos e seus padres, a

entrega do software deve ser feita para que o cliente tenha conhecimento
sobre o que esta sendo construdo. Com a entrega sendo realizada em partes,
pode ser obtido um feedback por parte do cliente, verificando se alguma
alterao precisa ser realizada. Caso exista, ela deve passar pela fase
Gerenciamento de Requisitos para ter uma melhor viso sobre a viabilidade
e impacto a ser gerado sobre o desenvolvimento, retornando ao incio da fase
Desenvolvimento. Aps a validao por parte do cliente, o setor de teste
deve gerar um novo artefato (documento de caso de uso), fazendo breve
descrio do sistema. Esse artefato serve de apoio para ao setor de suporte da
empresa e ao cliente, servindo como manual para sua interao com o
sistema.

21
3.4.3. Fase Gerenciamento de Requisitos

Nessa fase, um fluxo padro seguido durante o desenvolvimento do

software. Atravs da fase de Gerenciamento de Requisitos possvel
assegurar que os requisitos levantados no incio do projeto supram as
necessidades do cliente. Caso exista algum novo/alterao de requisito, ele
devidamente registrado no documento de requisitos de forma que seu
impacto e viabilidade sejam verificados junto equipe de desenvolvimento.
A viabilidade das alteraes necessita ser validada pela questo do cliente
saber o que melhor para ele. Por isso, deve ser realizada uma anlise
verificando a necessidade da mudana. Nessa fase, importante verificar o
impacto do requisito, visando a consistncia do software.

Caso existam mudanas a serem realizadas, necessrio que todos os

artefatos gerados na fase Desenvolvimento de Requisitos sejam revisados
para ter conhecimento sobre as alteraes e os impactos causados nos prazos
e no calendrio do projeto. A questo de impacto abrange a disponibilidade
dos recursos com relao aos prazos de permisses de escrita nos mdulos
durante o desenvolvimento. Possivelmente, pode ser necessrio realizar
mudanas nos documentos de registro de atividades, adequando-as da
melhor maneira. Aps a realizao da mudana nos artefatos, relatada a
nova situao para a equipe de desenvolvimento para eles estarem cientes do
novo cronograma e das exigncias do cliente. Detalhe esquemtico da fase
Gerenciamento de Requisitos apresentado na Figura 9.

22
Figura 9 Fase Gerenciamento de Requisitos

Caso o requisito solicitado no seja definido como vivel pela equipe

de desenvolvimento, necessrio reportar ao requisitante com justificativa
da no implementao do requisito.

3.4.4. Fase Finalizao do Projeto

Nessa fase, o desenvolvimento do software est concludo e deve ser

implantado no cliente. Antes de realizar a implantao, deve existir nova
verificao do software para rever os requisitos implementados e os padres
impostos. Essa fase busca a qualidade e a integrao do software, visando
gerar um produto de qualidade para o cliente. Para isso, so necessrios os
artefatos criados nas fases anteriores para verificar a consistncia do
software, validando os requisitos levantados para o projeto. Aps a
verificao, validao e implantao do software, treinamentos so
realizados para fornecer suporte necessrio ao cliente para operar o software.
Alm disso, h uma reunio em que so analisados os pontos fortes e os

23
pontos fracos do processo de desenvolvimento, visando aprender e inferir
melhorias aos prximos desenvolvimentos. Detalhe esquemtico da fase
Finalizao do Projeto apresentado na Figura .

Figura 10 Fase Finalizao do Projeto

1.5 Consideraes Finais

Neste captulo, foi apresentada a descrio do processo de

desenvolvimento proposto com o objetivo de mostrar seu funcionamento e
esclarecer suas atividades. Atravs do processo proposto aproveitada a
questo da equipe de desenvolvimento no ser grande. Com o processo, o
problema de levantamento e de validao dos requisitos pode ser resolvido,
fazendo com que a equipe diminua a quantidade de retrabalhos pela
existncia de rudos na comunicao por parte de seus membros.

24
 Apesar da resistncia proporcionada pela equipe de desenvolvimento
com relao documentao do software, a proposta faz uso de atividades
para criar o mnimo necessrio de artefatos de documentao e modelagem
de software, relatando os requisitos encontrados no ciclo de vida do
processo. Assim, a proposta de uma metodologia menos sobrecarregada de
documentao sobre os passos do processo de desenvolvimento pode
acarretar menos barreiras por parte dos membros, sem deixar de gerar os
artefatos necessrios para que o software seja construdo com qualidade.

25
4 Aplicao do Processo Proposto

1.1 Consideraes Iniciais

A fim de aplicar o proposto processo de desenvolvimento de software,

foi construdo um software Gerenciador Eletrnico de Documentos junto
equipe responsvel na empresa. Este presente captulo ir descrever a
aplicao do processo proposto na prtica, assim como toda a funcionalidade
do software criado.

Os passos tomados para o desenvolvimento do Software so descritos

na seo 4.2. Descrio do Software, suas caractersticas e sua modelagem
so apresentadas na Seo 4.3. A descrio do funcionamento do software
abordada na Seo 4.4.

4.2 Descrio do Desenvolvimento do Software

4.2.1 Desenvolvimento de Requisitos

A fim de realizar a atividade de elicitao dos requisitos, foi realizada

uma reunio com o gerente de desenvolvimento da empresa a fim de definir
as formas de avaliao/extrao de requisitos a serem utilizadas no processo
de desenvolvimento. Aps a reunio foi estabelecido que seriam realizadas
entrevistas com profissionais da rea de contabilidade alm da definio de
um canal de contato com o objetivo de obter maior conhecimento sobre as
necessidades encontradas para as atividades de gesto de documentos. Nesta
etapa tambm foram definidos os membros responsveis por essas
atividades, nos quais foram nomeados dois colaboradores para essa funo.

As atividades de avaliao dos requisitos ento foram realizadas

aplicando-se entrevistas de forma informal sobre os futuros usurios do
sistema. As entrevistas ocorrem em uma reunio marcada com os
profissionais da rea, tendo como responsveis pelo da mesma os
colaboradores destinados s atividades de avaliao dos requisitos. Ao final

26
dessa reunio, foram documentados os requisitos possibilitando que estes
pudessem ser avaliados pelo corpo de colaboradores que participaram do
projeto. Tambm foi definido um canal de comunicao com os usurios, um
chat utilizado entre os profissionais e parceiros da Empresa-Alvo, com
intuito de suprir dvidas e sugestes posteriores. Alguns dos requisitos
encontrados na atividade de avaliao foram:
Permitir troca de documentos entre contadores e clientes;
Notificar a chegada de novos documentos via e-mail;
Permitir excluso de documentos;
Permitir aplicao de filtros de datas e categorias na pesquisa de
documentos;
Permitir a criao e excluso de categorias de documentos;
Autenticar usurios com CPF/CNPJ e senha;
Permitir cadastrar novos clientes no sistema;
Permitir requisitar a chave para utilizao do sistema;
Permitir aos clientes enviarem e-mail para seus contadores.

Da mesma forma, foram identificados requisitos no funcionais:

Ferramenta deve ser web;
O sistema ser desenvolvido em C# (ASP);
Proibir o envio de arquivos executveis, visando segurana;
Os arquivos devem ser mantidos acessveis apenas a seus destinatrios;
O tamanho mximo do arquivo a ser enviado de 40 MB;
Boa navegabilidade;
Fazer uso mnimo de "cliques" possveis para realizar atividade;
Interface simples e dedutiva.

Ao final da avaliao dos requisitos, foram realizadas as atividades de

especificao dos requisitos, onde foi possvel a modelagem do software
atravs de diagramas e descries de casos de uso que sero exibidos nas
sees 4.4 e 4.5 a seguir. Cabe ressaltar que no foi possvel a reutilizao de

27
nenhum artefato de software j existente na empresa, devido ao fato de que o
GED foi o primeiro artefato web gerado, possuindo particularidades bem
diferentes aos j encontrados nos repositrios virtuais de software da
Empresa-Alvo.

Aps a modelagem do software, foi repassado aos colaboradores

envolvidos no projeto os requisitos do software e a modelagem criada.
Padres de interface e arquitetura do software tambm foram discutidos e
determinados nas atividades de validao com o intuito de acrescent-los
junto ao documento de requisitos para que pudessem ser validados
futuramente a proporo que os mdulos fossem construdos.

Dessa forma, o cronograma e recursos que foram utilizados em todo o

processo de desenvolvimento foram elicitados e registrados, fazendo o uso
da ferramenta de Gerncia de Projetos Microsoft Project 2013.

4.2.2 Desenvolvimento (Criao)

As atividades de desenvolvimento comearam logo aps a fase de

desenvolvimento dos requisitos, onde foi possvel elicitar e documentar as
necessidades e seus padres a serem implementados no produto final.
Ferramentas como Microsoft Visual Studio 2012, foram usadas para
codificar as rotinas dos mdulos, assim como criar a estrutura de banco de
dados necessria e modelada na fase anterior. A ferramenta de controle de
verses Tortoise SVN, foi utilizada para que se pudesse garantir a
integridade das verses durante todas as atividades presentes no cronograma
de desenvolvimento.

proporo que os mdulos do GED foram construdos, estes

seguiam para o setor de testes, onde foram verificados juntos aos artefatos
gerados na primeira etapa, os requisitos e padres. Quando encontrados
alguns erros ou no conformidades nos mdulos, estes foram relatados como
casos e destinados aos colaboradores envolvidos atravs da ferramenta

28
Mantis, a fim de registrar todas as atividades bem como acompanh-las
conforme a evoluo do projeto. Ao final dos testes de cada mdulo, foram
registradas as suas funcionalidades e telas no intuito de document-las.

4.2.3 Gerenciamento de Requisitos

Cabe ressaltar que, por causa do tamanho do projeto, no houve a

necessidade da nfase nessa fase, pois no houve demanda de novo requisito
a ser incluso no processo de desenvolvimento.

4.2.4 Finalizao do Projeto

Aps a finalizao do desenvolvimento dos mdulos, estes foram

integrados e novamente revisados pelo setor de teste, a procura de requisitos
no implementados ou partes que fugissem dos padres de interface
definidas na fase de desenvolvimento de requisitos. Foi criado ento um
novo documento relatando as funes do software disponveis no software
reunindo todos os documentos dos mdulos gerados at ento, possibilitando
criar um documento, em formato de apostila, que alm de registrar o novo
software, vai auxiliar nas atividades de treinamento ou suporte da empresa.

4.3 Descrio do Software

O software desenvolvido um Sistema Gerenciador Eletrnico de

Documentos (GED), cujo objetivo realizar a troca de documentos entre
contadores e seus clientes de forma padronizada. Para que o software possa
realizar suas funes de forma prtica, o mesmo foi desenvolvido em
plataforma Web para ser acessado em diversos lugares sem a necessidade de
instal-lo em um dispositivo. Sendo assim, foi definido que o sistema deve
armazenar os documentos enviados por contadores e clientes de forma
organizada por categorias, possibilitando que o software possa ser moldado
para atender de melhor forma cada empresa contbil que o utiliza. Quando
enviado, um documento armazenado no repositrio virtual referente ao
destinatrio que possui as categorias criadas em seu subdiretrio. O software

29
utiliza essa organizao para facilitar a gesto de documentos, o que agrega
agilidade na realizao da procura por algum documento alm de oferecer a
possibilidade de realizar mais um filtro sobre a pesquisa referente data do
documento.

4.4 Modelagem do Software

Para a especificao do software, foram utilizados dois diagramas da

UML: Diagrama de Casos de Uso e Diagrama de Classes. Alm desses
diagramas, foram elaborados a Descrio dos Casos de Uso e o Diagrama de
Navegao. Esses diagramas foram construdos utilizando a ferramenta
Astah* (http://astah.net/).

4.4.1 Diagrama de Caso de Uso

O Diagrama de Caso de Uso tem como intuito mostrar de forma usual

as tarefas empregadas no software desenvolvido. Na Figura , possvel notar
as funes do GED e seus atores. Para melhorar o entendimento dessas
funes, foram construdos documentos de Descrio de Caso de Uso
(Tabela ).

4.4.2 Diagrama de Classes

Por causa da existncia de diversas classes no sistema, houve a

necessidade de dividi-las em pacotes para que pudessem ser organizadas
logicamente da melhor forma (Figura 11). No pacote Business, esto
alocadas classes responsveis pelas regras de "negcio" (Figura 12). No
pacote Persistncia, esto localizadas classes responsveis pelo acesso ao
banco de dados (Figura 13). No pacote Entidades, esto localizadas classes
para suporte aos mtodos presentes no sistema (Figura ). No pacote
Interface, esto localizadas classes responsveis por funes que atualizam
informaes na tela para o usurio.

30
Figura 11 Diagrama de Caso de Uso

Tabela 2 Descrio do Caso de Uso: Enviar Documento

Nome do Caso de Uso Enviar Documentos
Ator Principal Contador
Esse caso de uso descreve as etapas percorridas
Resumo por um contador ao enviar um novo documento
para um cliente.
Pr-condies O contador precisa estar logado no sistema.
Fluxo Principal
Aes do ator Aes do Sistema
1. Na tela inicial clicar na
opo "Enviar Documento"

2. exibida uma tela listando os clientes do

contador.
3. selecionado ou
digitado nome ou parte do
nome do cliente em que se
deseja enviar o Documento.
4. exibido e requerido na tela uma nova
caixa exibindo todos as categorias de
Documentos.
5. O contador escolhe a
categoria a qual o
documento pertence e

31
pressiona a opo "Enviar".
6. exibida uma mensagem avisando do
sucesso do envio e so exibidos os outros
documentos pertencentes a mesma categoria j
enviados.
7. enviado um E-mail para o destinatrio do
documento informando que este possui um
novo documento em seu GED.

1- No possvel enviar arquivos executveis

(.exe).
Restries / Validaes
2- No possvel enviar arquivos com
tamanho superior a 40 Mb.
Fluxo alternativo
Aes do ator Aes do sistema

Fluxo de Exceo Cdigo do produto no existente no sistema

Aes do ator Aes do sistema
1. Comunicar ao usurio que no existe
nenhum arquivo selecionado, caso pressione a
opo enviar sem que selecionar algum
documento.

Figura 11 Diagrama de Pacotes

32
Figura 12 - Diagrama de Classes do Pacote Business

4.4.3 Diagrama de Navegao

A fim de apresentar melhor viso sobre como seriam expostas as

funes no sistema e de que forma elas iriam se localizar, foi construdo um
Diagrama de Navegao (Figura 14). Atravs deste diagrama possvel
observar como ocorre o acesso s funes do sistema atravs das setas que
indicam as possibilidades de navegao entre as telas do software.

33
Figura 13 Diagrama de Classes do Pacote Persistncia

Figura 15 Diagrama de Classes do Pacote de Entidades

34
4.5 Modelagem de Dados

Para armazenar os dados, foi construda a modelagem de dados

utilizando a ferramenta Workbench Community 6.08 (Figura 1517). H trs
tabelas: Clientes, Contador e Categorias.

Figura 14 Diagrama de Navegao

Figura 15 Modelagem de Dados

4.6 Funcionalidade

Nesta seo, so descritas as funes do sistema. Inicialmente,

apresentada uma tela de Login (Figura 16), sendo possvel realizar o acesso
ao sistema pelo usurio do tipo Contador e pelo o usurio do tipo Cliente.
Antes de realizar o login, necessrio possuir uma chave de acesso (senha)

35
obtida na opo Solicite sua Chave no menu, escolhendo o tipo de usurio
(Contador ou Cliente). Quando selecionada a opo, apresentada uma tela
para o usurio obter sua senha (Figura 17). Para solicitar a senha, a empresa
contbil ou contador deve ter realizado o registro do novo usurio no sistema
para que este possa realizar o cadastro de sua senha no sistema.

Figura 16 Tela de Login

36
Figura 17 Tela de Solicitao de Chave do Sistema

Aps realizar o login, apresentada a tela inicial exibindo diversas

funes, porm as telas iniciais dos usurios diferem-se. O usurio Contador
possui mais funes (Figura ). Se desejar procurar os dados disponibilizados
para ele ou por ele, o usurio Contador deve selecionar o boto Exibir
Documentos na tela inicial. Aps a seleo, uma tela apresentada exibindo
as informaes (Figura ). Para efetuar a pesquisa de documentos, o usurio
Contador deve realizar alguns filtros por meio da TreeView ou digitando a
informao desejada (total ou parcialmente) no campo apropriado. Em
seguida, so exibidos novos campos para realizar outros filtros. Ao realizar a
pesquisa, selecionando o boto Exibir Documento, uma relao de nomes
dos documentos e suas caractersticas so exibidas em uma tabela. Nessa
relao, pode ser feito o download do documento selecionando-o ou exclu-
lo do diretrio virtual, selecionando a opo excluir situada a direita da
tabela.

37
Figura 20 Tela Inicial (Usurio Contador)

A funo de enviar documento ocorre de forma parecida com a de

exibir documentos, possuindo um layout padronizado. Para enviar um
documento, deve ser escolhido o cliente a que se deseja enviar o arquivo. Em
seguida, aparecem novas opes situadas na diviso direita (Figura ). Entre
essas opes, h um boto que abre uma caixa para selecionar o documento
desejado. Aps a seleo, deve ser escolhida a categoria do documento e
selecionar o boto Enviar. Aps o processamento da operao, emitida
uma mensagem de feedback ao usurio sobre a reao perante a sua ao e
lista os documentos presentes no diretrio escolhido pelo contador para
enviar o documento.

Voltando a tela inicial, h duas opes de registro para o usurio do

tipo Contador para registrar: i) outros contadores; e ii) clientes. Essa funo
pode ser realizada apenas pelo usurio Contador, como no caso do registro
de novos clientes (Figura ). Para realizar o registro de clientes, o contador
deve preencher os dados do cliente que deseja registrar no sistema e
selecionar a opo registrar. Cabe ressaltar que registro de um usurio
realizado apenas uma vez. Em seguida, emitida uma mensagem com o
feedback sobre a ao.

38
Figura 21 Tela de Exibio de Documentos (Usurio Contador)

Figura 22 Tela de Envio de Documentos (Usurio Contador)

O registro de novos contadores acontece da mesma forma, porm com

uma diferena (Figura ). Quando um usurio Contador realiza o registro de

39
um novo cliente, o cliente relacionado com o contador responsvel pelo
seu registro; no registro de um contador, no h essa relao. Isso acontece
por causa da organizao de diretrios ser de forma que os diretrios dos
clientes localizam-se como subpastas do diretrio do contador ao qual o
cliente est relacionado.

Figura 23 Tela de Registro de Novos Clientes

Figura 24 Tela de Registro de Usurios Contadores

40
 Outra importante responsabilidade atribuda apenas ao usurio
Contador criar e excluir categorias de documentos (Figura ). Qualquer
contador pode criar uma categoria desde que no exista outra com seu
mesmo nome. Para excluir uma categoria, o sistema verifica nos diretrios
dos clientes associados ao contador se existem documentos referentes
categoria que se deseja excluir; caso exista algum documento, no ser
possvel excluir a presente categoria.

Figura 25 Tela de Adio e Excluso de Categorias de Documentos

O GED possui a opo de o usurio modificar dados referentes ao seu

perfil. Para ter acesso a essa opo, o usurio deve passar o mouse sobre o
smbolo de engrenagem, situado ao canto superior direito da tela, e
selecionar a opo Configuraes no menu gerado abaixo ao smbolo. Aps
selecionar a opo, exibida uma tela com os campos do perfil disponveis
para modificao (Figura ).

Na tela de configuraes, deve ser fornecida apenas a nova

informao a ser inserida nos campos do perfil e, em seguida, selecionar o
boto Salvar situado abaixo de cada sesso de configurao. O sistema emite
feedback aps a execuo de cada ao para notificar o usurio. Com citado
anteriormente, h diferenas entre os tipos de usurios. As diferenas

41
basicamente so visveis quando observadas as telas iniciais de cada usurio,
em que se pode notar que o usurio Cliente possuir menos opes quando
comparado ao usurio Contador (Figura ).

Figura 26 Tela de Configuraes (Usurio Contador)

Figura 27 Tela Inicial (Usurio Cliente)

42
 Alm da quantidade de funes, as funes para exibir documentos e
enviar documentos so mais simples e com menos passos a serem seguidos
para o usurio Cliente (Figura ), pois permitida apenas a exibio e envio
de dados referentes a um contador, enquanto o usurio Contador pode enviar
ou exibir documentos referentes a diversos clientes.

Figura 28 Tela de Exibio de Documentos (Usurio Cliente)

O nico "privilgio" que o usurio Cliente possui a mais que o usurio

Contador referente possibilidade de entrar em contato diretamente com o
usurio contador utilizando o GED. Essa tarefa facilita a ao de contato por
parte do cliente que no precisa abrir um site de e-mail com seu contador. Os
dados de outros possveis contatos so apresentados na tela de contatos
(Figura ).

43
Figura 29 Tela de Contato com o Contador

4.7 Consideraes Finais

A aplicao do processo proposto foi descrita neste captulo,

especificando os passos tomados durante o processo de desenvolvimento do
software. Atravs da aplicao da proposta foi possvel observar que com as
atividades de desenvolvimentos dos requisitos, o uso de retrabalho durante o
ciclo de vida do desenvolvimento foi praticamente nulo, quando comparado
a atual situao da Empresa-Alvo. Com relao s atividades de
documentao e modelagem de software, algumas reclamaes e barreiras
foram propostas pelos desenvolvedores envolvidos no processo, porm foi
possvel realiz-las conforme a proposta de processo de desenvolvimento.

Nesse captulo, foi possvel apresentar a funcionalidade e os requisitos

do Sistema Gerenciador Eletrnico de Documentos, cujo objetivo realizar a
padronizao da troca de documentos entre contadores e seus clientes. Isso
ocorre porque o software oferece um canal simples e direto que pode ser
acessvel em diversos lugares diferentes sem a necessidade da instalao do
sistema. O armazenamento das informaes e dos arquivos de total

44
responsabilidade das empresas contbeis que adquirirem o sistema. Sendo
assim, o site hospedado no servidor de cada empresa que adquiri-lo.

45
5 CONSIDERAES FINAIS

5.2 Concluses

No presente trabalho, foi apresentada uma proposta de processo de

desenvolvimento para uma empresa de software de pequeno porte. Essa
proposta foi fundamentada nos resultados de avaliaes realizadas com
participao nas atividades de desenvolvimento da empresa e com reunies
com seus diretores. Alguns importantes fatores para o desenvolvimento do
trabalho foram encontrados durante o processo de levantamento de
informaes, como a grande resistncia a mudana por parte do corpo de
funcionrios.

Alguns profissionais envolvidos no processo acreditam que a maioria

dos passos no processo de desenvolvimento relacionados com a
documentao desnecessria e acarreta maior tempo ao projeto. Por isso, o
processo de desenvolvimento faz uso da vasta comunicao, aproveitando a
baixa quantidade de colaboradores envolvidos no processo de
desenvolvimento. Assim, a documentao pode ser reduzida, evitando
resistncia dos responsveis pelas atividades de desenvolvimento do
software.

O processo de desenvolvimento proposto tem como objetivo estruturar

o desenvolvimento da Empresa-Alvo, mostrando o fluxo de atividades
presentes em cada fase, ressaltando o que necessrio para tentar atender os
padres de qualidade. Com um processo bem definido, a Empresa-Alvo
pode conseguir utilizar de melhor forma seus recursos, acarretando melhoria
em suas atividades internas e na qualidade do produto final.

5.3 Contribuies e Dificuldades Encontradas

Com a realizao desse trabalho, existiram diversas contribuies para

a formao do autor da presente pesquisa, bem com a investigao sobre

46
processos de desenvolvimento e a experincia adquirida no envolvimento
com a equipe de desenvolvimento da Empresa-Alvo. Atravs do
envolvimento junto aos desenvolvedores da empresa, foi possvel adquirir
um maior conhecimento sobre arquitetura de software, aprendendo como
realizado o desenvolvimento feito em camadas fsicas e lgicas do software.
Tcnicas de programao foram observadas durante as atividades de
desenvolvimento proporcionando maior conhecimento sobre os conceitos de
orientao a objetos aplicando-os em prtica, como o uso polimorfismo,
tratamento de excees e padres de programao. Atividades de
modelagem de software e dados proporcionaram maior conhecimento sobre
o uso de ferramentas especificas para este fim, como as ferramentas Astah e
MySQL Workbench.

Porm para a realizao da construo do sistema, foi necessrio

aprender uma nova linguagem alm da programao web. Essas atividades
adicionaram algumas dificuldades durante todo o progresso do estgio,
necessitando por auxlio de outros profissionais da rea com maior
experincia e conhecimento em desenvolvimento de software. Atravs da
troca de informaes com os colaboradores da empresa responsveis pelo
desenvolvimento, foi possvel suprir essas dificuldades possibilitando a
execuo da construo do GED, proporcionando conhecimento sobre a
nova linguagem e programao web para o autor.

Com este trabalho, foi possvel criar e estruturar um processo de

desenvolvimento a ser proposto para a Empresa-Alvo. Com o auxlio desse
processo, a Empresa-Alvo pde ter uma viso de uma pessoa imparcial, que
estudou sua estrutura e seus recursos, podendo futuramente utilizar o
processo ou pelo menos algumas das fases/atividades mencionadas. Com
esse processo, a equipe pode se organizar e ter maior clareza sobre os
requisitos, os padres e os resultados a serem obtidos no desenvolvimento.
Com a melhoria da atual situao da Empresa-Alvo, os seus aspectos

47
internos podem ser melhorados e um produto final com maior qualidade
pode ser obtido.

5.4 Disciplinas Abordadas

Durante as atividades realizadas junto equipe de desenvolvimento,

foram aplicadas as teorias de diversas matrias vistas durante todo o decorrer
do curso de Sistemas de Informao. Matrias de programao como
Algoritmos e Estruturas de dados e Programao Orientadas a Objetos foram
de extrema necessidade para a criao do GED, auxiliando nas atividades de
codificao. Para que pudesse ser criada a estrutura e os cdigos
responsveis por realizar as funes no Banco de Dados do software, a
matria Banco de Dados 1 e 2 foram necessrias para a execuo dessas
atividades. A matria Engenharia de Software presente na grade do curso
proporcionou a base para a criao da proposta, sua a teoria vista nas aulas
foi responsvel por dar apoio para a criao da proposta do processo de
desenvolvimento.

5.5 Trabalhos Futuros

Este trabalho abordou o processo de desenvolvimento de uma empresa

de pequeno porte desenvolvedora de sistemas de software, porm existem
diversas oportunidades para dar continuidade a este trabalho:
Ampliar a proposta de processo para abordar a qualidade de software;
Implantar um conjunto de normas para garantir a qualidade;
Implantar a proposta de processo de desenvolvimento na empresa e
verificar os resultados obtidos;
Melhorar a proposta de desenvolvimento atravs dos resultados obtidos;
Aplicar o processo em outros desenvolvimentos de software para obter
resultados e, eventualmente, adequar o processo proposto.

48
REFERNCIAS BIBLIOGRFICAS
JUNG, C. F. Metodologia Aplicada a Projetos de Pesquisa: Sistemas de
Informao & Cincia da Computao. Editora Taquara. 2009.

LOURENO, F. L. M.; BENINE, M. A. Estudo do Ciclo de Vida do

Software em uma Empresa de Desenvolvimento de Sistemas. Batatais:
Linguagem Acadmica, 2011. 183p.

PAULA FILHO, W. DE P. Engenharia de Software: Fundamentos,

Mtodos e Padres. 2 Ed. Rio de Janeiro: LTC Editora. 2002. 602p.

SAYO, MIRIAM; BREITMAN, KARIN KOOGAN. Gerncia de

Requisitos. Mini Curso do 20 SBBD e 19 SBES, 2005.

SCOTT, KENDALL. O Processo Unificado Explicado. Bookman. 160p.

2003.

SOMMERVILLE, I. Software Engineering. Addison-Wesley, 2009. 840p.

SPEM. Software & Systems Process Engineering Metamodel

Specification. 2008. Verso 2.0. Disponvel em:<
http://www.omg.org/spec/SPEM/2.0/PDF/ > Acesso em: 7 Janeiro 2014.

THE ECLIPSE FOUNDATION. Eclipse Process Framework Project.

2014. Disponvel em:<https://www.eclipse.org/epf/> Acesso em: 7 Janeiro
2014.

49