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

Transcrição

1 ROBSON SCATOLON PROPOSTA DE UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE PARA UMA EMPRESA DE PEQUENO PORTE LAVRAS MINAS GERAIS - BRASIL 2014

2 ROBSON SCATOLON PROPOSTA DE UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE PARA UMA EMPRESA DE PEQUENO PORTE Relatório de estágio supervisionado não obrigatório apresentado ao Colegiado do Curso de Sistemas de Informação, como parte das exigências para a obtenção do título de Bacharel em Sistemas de Informação. Orientador Dr. Heitor Augustus Xavier Costa LAVRAS MINAS GERAIS - BRASIL 2014

3

4 AGRADECIMENTOS A Deus, por todas as bênçãos em minha vida, por sempre estar ao meu lado dando força 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 funcionários do departamento de Ciência da Computação, que oportunizaram o aprendizado e conhecimento constante. E a todos que direta ou indiretamente fizeram parte da minha formação, o meu muito obrigado.

5 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS 1 INTRODUÇÃO Empresa-Alvo Motivação Objetivo Procedimentos Metodológicos Estrutura do Trabalho PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE Considerações Iniciais Modelo de Processo de Desenvolvimento Cascata Modelo de Processo de Desenvolvimento Processo Unificado Considerações Finais PROPOSTA DE PROCESSO DE DESENVOLVIMENTO Considerações Iniciais Entendimento do Desenvolvimento Software da Empresa-Alvo Atual Processo de Desenvolvimento da Empresa-Alvo Descrição do Processo de Desenvolvimento Proposto Fase Desenvolvimento de Requisitos Fase Desenvolvimento (Criação) Fase Gerenciamento de Requisitos Fase Finalização do Projeto Considerações Finais Aplicação do Processo Proposto Considerações Iniciais Descrição do Desenvolvimento do Software Desenvolvimento de Requisitos Desenvolvimento (Criação) Gerenciamento de Requisitos Finalização do Projeto Descrição do Software Modelagem do Software Diagrama de Caso de Uso Diagrama de Classes Diagrama de Navegação Modelagem de Dados... 35

6 4.6 Funcionalidade Considerações Finais CONSIDERAÇÕES FINAIS Conclusões Contribuições e Dificuldades Encontradas Disciplinas Abordadas Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS... 49

7 LISTA DE FIGURAS Figura 1 Modelo Cascata... 6 Figura 2 Artefatos Gerados na Etapa Planejamento do Projeto Figura 3 Artefatos Gerados na Etapa Análise de Requisitos Figura 4 Artefatos Gerados na Etapa Desenvolvimento Figura 5 Artefatos Gerados no Processo de Testes Figura 6 Processo de Desenvolvimento Proposto Figura 7 Fase Desenvolvimento de Requisitos Figura 8 Fase Desenvolvimento (Criação) Figura 9 Fase Gerenciamento de Requisitos Figura 10 Fase Finalização do Projeto Figura 11 Diagrama de Caso de Uso Figura 12 Diagrama de Pacotes Figura 13 Diagrama de Classes do Pacote Business Figura 14 Diagrama de Classes do Pacote Persistência Figura 15 Diagrama de Classes do Pacote de Entidades Figura 16 Diagrama de Navegação Figura 17 Modelagem de Dados Figura 18 Tela de Login Figura 19 Tela de Solicitação de Chave do Sistema Figura 20 Tela Inicial (Usuário Contador) Figura 21 Tela de Exibição de Documentos (Usuário Contador) Figura 22 Tela de Envio de Documentos (Usuário Contador)... 39

8 Figura 23 Tela de Registro de Novos Clientes Figura 24 Tela de Registro de Usuários Contadores Figura 25 Tela de Adição e Exclusão de Categorias de Documentos Figura 26 Tela de Configurações (Usuário Contador) Figura 27 Tela Inicial (Usuário Cliente) Figura 28 Tela de Exibição de Documentos (Usuário Cliente) Figura 29 Tela de Contato com o Contador... 44

9 LISTA DE TABELAS Tabela 1 Atividades Realizadas... 4 Tabela 2 Descrição do Caso de Uso: Enviar Documento... 31

10 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 bibliográfico na área de Engenharia de Software em busca de trabalhos relacionados a modelos de processos de desenvolvimento. Na sequência, a fim de entender melhor a real situação da empresa-alvo, foi realizada uma observação participante junto ao corpo de funcionários responsáveis pelas atividades de desenvolvimento da empresa. Neste contexto, foram obtidas maiores informações 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 ocupação dos recursos e artefatos disponibilizados pela empresa, sendo aplicada ao desenvolvimento de um software Gerenciador Eletrônico 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

11 1 INTRODUÇÃO As práticas e as técnicas para processos de desenvolvimento de sistemas de software surgem a cada dia. Um problema notado é saber quais técnicas devem ser aplicadas na prática 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 adoção de um processo de desenvolvimento. Nesse sentido, é interessante observar quais técnicas são utilizadas na empresa desenvolvedora de software de pequeno porte em que foi realizado este estudo (Empresa-Alvo) para propor uma visão do que seriam processos de desenvolvimento para produzir produtos finais com qualidade. Para isso, observação participativa por meio do estágio foi utilizada para elicitar os métodos e as atividades presentes na Empresa-Alvo. Dessa forma foram observados os processos de desenvolvimento de software juntamente com a equipe responsável pelas atividades de desenvolvimento da empresa, visando à obtenção de conhecimento prático sobre sua realidade. Para que este estudo fosse válido, 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 situação 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 Eletrônico de Documentos. Os passos e as atividades presentes durante o desenvolvimento desse software foram descritos.

12 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 Automação Comercial. A parceria aconteceu pela necessidade da criação de um software para auxiliar as atividades de gestão de pequenos comércios varejistas. Nos dias atuais, a Empresa-Alvo conta com cerca de 30 colaboradores e aproximadamente clientes ativos espalhados entre os estados de São Paulo, Rio de Janeiro e, principalmente, Minas Gerais. Os produtos de software desenvolvidos pela empresa são sistemas gerenciais para o comércio atacadista e varejista desenvolvidos para plataforma desktop (Windows) e móvel (Palm e Android). Recentemente, a empresa expandiu seu segmento de produtos abordando tecnologias Web a fim de acompanhar as tendências do mundo atual. Apesar de a empresa possuir pouco tempo de existência, a demanda por seus sistemas de softwares vem crescendo, possibilitando a expansão de toda sua estrutura física 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 são os atuais responsáveis pelo processo de desenvolvimento de software no atual da Empresa-Alvo. 1.2 Motivação A principal motivação deste trabalho foi a possibilidade de vivenciar na prática, 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 prática. Outras motivações deste trabalho foram: Falta de um processo de desenvolvimento bem definido em empresas de pequeno porte (possibilidade de contribuições neste sentido); 2

13 Interação com profissionais da área; Obter maior visão e compreensão das barreiras criadas pelos profissionais do setor de desenvolvimento para a aplicação de algumas técnicas de Engenharia de Software; Conhecimento de padrões de desenvolvimento aplicados na Empresa; Aplicação da teoria junto a prática 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 específicos, têm-se: Identificar métodos 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 Metodológicos Inicialmente, foi realizada uma procura por livros e artigos com trabalhos relacionados objetivando o entendimento de processos de desenvolvimento de software e conhecimento específicos que auxiliassem na construção deste trabalho. Após essa etapa, foram realizadas reuniões com diretores da empresa para obter mais conhecimento sobre a atual situação das atividades de desenvolvimento, do ponto de vista da alta gerência, e conscientizar sobre o contexto em que a Empresa-Alvo se encontra. Diversas reuniões foram realizadas com os diretores da Empresa-Alvo, sendo necessária a participação junto aos desenvolvedores para que pudessem ser observadas as atividades e as rotinas empregadas no cotidiano da empresa. Após a elicitação das informações do atual processo, foi construída uma proposta de desenvolvimento de software, propondo melhorias para o ciclo de desenvolvimento da Empresa-Alvo. Posteriormente foi aplicado o 3

14 processo propostos através do desenvolvimento de um software Gerenciador Eletrônico de Documentos, junto com os profissionais responsáveis. O cronograma da execução do trabalho com as atividades realizadas é apresentado na Tabela 1. Tabela 1 Atividades Realizadas Atividades Revisão bibliográfica Reuniões com diretores da empresa Observação participativa nas atividades de desenvolvimento Construção da proposta de desenvolvimento de software Aplicação do processo proposto 2º Período Letivo de 2013 Outubro Novembro Dezembro Janeiro 1.5 Estrutura do Trabalho Este trabalho está organizado da seguinte forma. Breve descrição dos conceitos de processos desenvolvimento de software e modelos de ciclo de vida de processos de software é apresentada no Capítulo 2. O atual processo de desenvolvimento, relatando posteriormente uma proposta de processo para desenvolvimento de sistemas de software, é descrito no Capítulo 3. A descrição do software desenvolvido junto com a equipe de desenvolvimento da Empresa-Alvo através da aplicação da proposta é apresentada no Capítulo 4. Conclusões, contribuições, sugestões de trabalhos futuros são tratadas no Capítulo 5. 4

15 2 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 1.1 Considerações Iniciais Um modelo de processo de desenvolvimento de software pode ser visto como uma representação ou abstração das atividades envolvidas no processo. Além disso, oferece uma forma abrangente de representar o gerenciamento de processo de software, além do progresso do projeto (LOURENÇO; BENINI, 2011). Processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações 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 execução do processo. Geralmente, os processos a serem aplicados são previamente estabelecidos no planejamento do projeto, onde as estratégias são traçadas para o projeto. É de responsabilidade do Engenheiro de Software traçar essas características fundamentais. Muitos são os modelos de processos propostos para as realidades de empresas de desenvolvimento, porém a escolha de qual modelo a ser aplicado pode ser difícil. A escolha tem que ser adequada à realidade de cada empresa, em que seus aspectos, tais como, tamanho, quantidade e tamanho dos projetos e funcionários, são colocados em destaque. Muitas vezes, é necessária a contratação de consultoria especializada para auxiliar nessa atividade. Nesta seção, são abordados os modelos de processos de desenvolvimento de software: Cascata e UP. Breve descrição do modelo de processo de desenvolvimento Cascata é apresentada na Seção 2.2. Breve descrição do modelo de processo de desenvolvimento Processo Unificado (UP) é apresentada na Seção 2.3.

16 1.2 Modelo de Processo de Desenvolvimento Cascata Cascata é um modelo em que as fases do processo ocorrem de forma sequencial, pois a próxima fase começa 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 estável (há poucas mudanças nos requisitos) (JUNG, 2009). Algumas dificuldades podem ser encontradas na sua aplicação, por exemplo, as fases dos processos ocorrem em forma sequencial e não há previsão de entrega de uma versão parcial do software em desenvolvimento ao cliente/stakeholders. Dessa forma, existe a possibilidade de, após serem realizadas as fases previstas no modelo, o produto não estar de acordo com as necessidades do cliente. Definição de Requisitos Design e Arquitetura Implement ação Integração e Teste Operação e Manutenção Figura 1 Modelo Cascata Ao analisar o modelo Cascata, é possível perceber que a falta de interação por parte do cliente com o desenvolvimento pode vir a causar problemas quando escolhida a aplicação do modelo. É importante citar que, em alguns casos, clientes não conseguem especificar os requisitos do software, tornando a tarefa de captação e de análise desses requisitos mais dificultada, além de necessitar de calma e de paciência por parte do cliente, pois o software poderá ser visualizado ao final do processo (SAYÃO; BREITMAN, 2005). Nesse modelo, são consideradas atividades 6

17 fundamentais do processo de desenvolvimento promovendo abordagem sistemática e sequencial que possui as fases (SOMMERVILLE, 2009): Definição dos Requisitos. Nessa fase, são geradas especificações dos requisitos do software por meio de consultas com usuários e clientes. A especificação 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; Implementação. Nessa fase, o código fonte é gerado, sendo codificadas as unidades do sistema; Integração e Teste. Nessa fase, as unidades desenvolvidas da etapa anterior são integradas e testadas, verificando e validando os requisitos elicitados na fase Definição de Requisitos; Operação e Manutenção. Nessa fase, o sistema é instalado no cliente, existindo a detecção e a correção dos erros não descobertos em outras fases. Além disso, podem surgir novos requisitos, possibilitando a evolução 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 previsíveis para a produção de software (SCOTT, 2003). Geralmente, ele é aplicado em grandes ou médias empresas, por ser considerado um "modelo pesado". Porém, sua estrutura é facilmente adaptável a diversos tipos de organizações facilitando a sua implantação. Isso se deve a seus componentes não serem extremamente necessários para cada fase do projeto, possibilitando realizar uma análise para cada caso e perceber com a necessidade de uso de acordo com o projeto e a organização 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 não ser possível definir os problemas a serem abordados em um 7

18 único passo, tornando-o iterativo e incremental. Sua integração é realizada durante o processo de desenvolvimento, sendo menos complexo, reduzindo custo e aumentando a eficiência. No UP, as interações são 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 contrário, traz à mostra as pendências por parte do desenvolvimento para com o projeto. O UP possui um quatro fases (SCOTT, 2003): i) Concepção; ii) Elaboração; iii) Construção; e iv) Transição. A fase Concepção possui como principal objetivo definir o escopo do projeto. Nessa fase, são identificados os requisitos essenciais do software, com o auxílio dos stakeholders. Esta etapa não possui o objetivo de realizar uma análise fechada, mas é realizada para ter a primeira ideia do que é necessário para o software. Na fase Elaboração, a arquitetura e a visão dos produtos são definidas. Os requisitos do sistema abrangem desde declarações de caráter geral a critérios preciosos de avaliação, em que cada requisito especifica o determinado comportamento funcional e proporciona a base para realização de testes. Nessa fase, é complementada a identificação dos requisitos ou documentação dos casos de uso, voltados para a arquitetura do sistema, revisando a modelagem do negócio para os projetos e inicia a versão do manual do usuário. Além disso, deve ser feita uma análise da estabilidade da visão geral do produto, se o plano do projeto é confiável e se os custos são admissíveis. Na fase Construção, o sistema é desenvolvido e testado, gerando uma arquitetura baseline executável e destinada à transferência para a comunidade de usuários. Os testes realizados nessa fase têm o objetivo de verificar se o sistema atende os requisitos e os critérios de avaliação. A fase Transição não possui o intuito de finalizar o processo, mas o aprimoramento contínuo do sistema, com a descoberta de bugs que possibilitam a correção e acréscimo de novas características ao sistema. 8

19 O UP define um guia para controlar atividades para a equipe de desenvolvimento, realizando o direcionamento de tarefas para cada desenvolvedor em específico. Com o UP, podem ser especificados detalhadamente os artefatos a serem desenvolvidos e os critérios para monitorar as atividades do processo de desenvolvimento. 1.4 Considerações Finais Processos de desenvolvimento variam entre as diversas empresas de software, sendo diretamente influenciados com a cultura de cada organização em que são aplicados. A aplicação correta dos processos no desenvolvimento pode acarretar inúmeras vantagens não só para o sistema final, mas para a própria organização que pode diminuir o gasto desnecessário de tempo, melhores relatos e diminuição do custo do software. Entretanto, para que os benefícios sejam alcançados, é importante à conscientização de todos os membros da equipe de desenvolvimento da importância de seguir um processo de desenvolvimento e as possíveis melhorias geradas. Assim, passos definidos no processo de desenvolvimento não são cortados na primeira dificuldade a ser encontrada no cotidiano no decorrer do projeto. Neste capítulo, 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

20 3 PROPOSTA DE PROCESSO DE DESENVOLVIMENTO 1.1 Considerações Iniciais Neste capítulo, é 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 Empresa Alvo, é realizada a descrição sobre o atual processo de desenvolvimento, especificando as atividades envolvidas durante o ciclo de vida do processo. Definição das etapas para entendimento do funcionamento da Empresa-Alvo no desenvolvimento de software é apresentada na Seção 3.2. O atual processo de desenvolvimento é descrito na seção 3.3. Descrição detalhada das etapas do processo proposto é mostrada na Seção Entendimento do Desenvolvimento Software da Empresa-Alvo Para a elaboração 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 bibliográficas serviram para dar apoio sobre metodologias existentes de diversos tipos de processos de desenvolvimento, ajudando a conhecer técnicas utilizadas que serviram de base para o processo de desenvolvimento proposto para a Empresa-Alvo; Segunda Etapa. Nessa etapa, há reconhecimento/entendimento da organização e da sua estrutura, ocorrendo conversas onde foi possível conhecer um pouco sobre a cultura organizacional, sua estrutura e seus recursos. Essa etapa foi fundamental, pois foi possível ter uma visão da empresa do ponto de vista da alta gerência, levantando os atuais

21 problemas da empresa e quais são as barreiras encontradas na visão dos diretores da Empresa-Alvo. Além da visão dos diretores, a visão dos funcionários que atuam nas atividades de desenvolvimento cotidianas da empresa foi considerada; Terceira Etapa. Nessa etapa, o intuito foi obter uma visão de um funcionário que não estivesse relacionado com atividades de desenvolvimento. Assim, ocorreu participação ativa durante algumas atividades de desenvolvimento em um projeto de software junto com a equipe responsável. Com essa participação, foi possível obter uma visão imparcial da realidade Empresa-Alvo e realizar a análise 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 informações extraídas das etapas anteriores para obter um processo de desenvolvimento de forma a gerar benefícios às atividades de construção de software presentes na Empresa-Alvo. Com as informações obtidas na segunda e terceira etapas, foi possível perceber os recursos, as deficiências, as oportunidades e diversos outros fatores a serem considerados ao propor o processo de desenvolvimento. Após a síntese das informações com auxílio do conhecimento de metodologias existentes (primeira etapa), teve-se embasamento para a elaboração 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 não possuir muito tempo de existência e estar passando por um processo de evolução constante nos últimos tempos não possui um framework definido sobre as atividades de desenvolvimento. Sua estrutura 11

22 não é definida, pois os passos existentes no processo de desenvolvimento muitas vezes não são 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 aperfeiçoá-lo. O projeto que engloba o processo de desenvolvimento geralmente é efetuado de forma mensal, sendo liberada uma versão ao mês para o seu sistema, possibilitando que o cliente da empresa sempre mantenha seu software atualizado. Um importante fator para que a atualização ocorra de forma mensal é o tempo de o sistema estar indisponível para o usuário durante este processo, procurando manter uma versão 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) Análise de Requisitos; iii) Desenvolvimento (Programação); e iv) Testes. Na etapa Planejamento do Projeto (Figura 2), são definidas quais atualizações ou módulos a serem integrados ao sistema. Essa etapa é importante, pois, geralmente, a quantidade de correções e de requisições para o sistema é grande, tornando-se inviável para que possam ser efetuadas em uma versão mensal. As sugestões de atualizações 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 sugestões de melhorias ou erros no sistema. A definição de quais atualizações ou implementações são 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 dão prioridade a bugs relatados como graves, por a empresa possuir o objetivo de bom funcionamento do sistema. 12

23 Nas versões disponibilizadas, são geradas novas implementações para o sistema. Figura 2 Artefatos Gerados na Etapa Planejamento do Projeto Logo após serem definidas as atualizações, o diretor presente no desenvolvimento observa os requisitos necessários. Nessa atividade não é realizado um contato mais próximo com cliente. Sendo assim, a análise de requisitos é feita sobre dados obtidos na primeira requisição sem ter contato mais a fundo para buscar entender melhor sobre as características e funções necessárias. Os artefatos gerados na Etapa Análise de Requisitos podem ser observados na Figura 3. Após a fase Análise de Requisitos, é realizada a divisão de tarefas entre os integrantes do departamento de desenvolvimento responsáveis pela programação. Nessa atividade, cada programador é responsável pela correção bugs ou atualizações no sistema. A atribuição de tarefas é realizada utilizando a ferramenta Mantis, utilizada pela Empresa-Alvo para controle do andamento do desenvolvimento de novas versões e correções. Cada programador tem que finalizar suas tarefas em um prazo de aproximadamente 15 dias para que as atualizações sejam testadas. Cabe ressaltar que não existe documentação de forma que a definição dos requisitos é feita verbal e informalmente entre os funcionários. As informações existentes estão presentes na ferramenta Mantis, com dados e 13

24 uma prévia descrição de afazeres destinados a cada programador. A etapa Desenvolvimento e seus artefatos gerados são ilustrados na Figura 4. Figura 3 Artefatos Gerados na Etapa Análise de Requisitos Figura 4 Artefatos Gerados na Etapa Desenvolvimento Atividades de modelagem de software em UML não são implantadas na empresa, deixando o desenvolvimento sem registros concretos de como acontecem às ações no sistema. Outras atividades que possuem destaque na Engenharia de Software não são existentes. A etapa Teste (Figura 5) é iniciada após o prazo ser concretizado ou conforme a demanda gerada pelos desenvolvedores à medida que terminam correções ou novidades do sistema. O setor de teste foi implantado recentemente na organização, possuindo uma estrutura simples, não tendo as atividades necessárias para realizar os testes 14

25 de maneira apropriada, por exemplo, testes em código e automatização de testes. Figura 5 - Artefatos Gerados no Processo de Testes As atuais atividades de teste consistem em observar a funcionalidade descrita na reunião inicial do planejamento, em que foi realizada a análise de requisitos da versão a ser gerada, e verificar se estão apresentáveis no sistema de forma a satisfazer os requisitos. Nessa etapa, são apresentados bugs e sugestões de melhorias para os desenvolvedores relatados no Mantis; se necessário, são feitos alguns reajustes na versão para atender os padrões estabelecidos de usabilidade da Empresa-Alvo. Ao final do processo de desenvolvimento, talvez a única documentação presente atualmente na Empresa-Alvo é elaborada pelo setor teste, cuja função é relatar as mudanças e as correções da versão. Nesse documento, existe descrição das funções agregadas ao sistema, sendo relatados também os casos e seus devidos responsáveis (desenvolvedores). 1.4 Descrição do Processo de Desenvolvimento Proposto O processo de desenvolvimento de software proposto para a Empresa- Alvo proporciona maior interação entre steakholders, equipe de desenvolvimento e membros da equipe de desenvolvimento. Com esse 15

26 processo, busca-se alcançar melhoria da utilização dos recursos e oportunidades existentes, tendo como objetivo proporcionar um processo para criação de um software eficaz e prático, 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 interação das pessoas e redução 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 participação no processo e à entrega de um produto consistente com a necessidade do cliente. Detalhe esquemático do processo de desenvolvimento proposto é apresentado na Figura 6. Cada uma dessas fases é detalhada em outras atividades para elaborar os artefatos de software necessários. 16

27 Figura 6 Processo de Desenvolvimento Proposto Fase Desenvolvimento de Requisitos Essa fase está dividida em quatro atividades essenciais para gerar os artefatos de software necessários (Figura 7): i) Elicitação de Requisitos; ii) Avaliação de Requisitos; iii) Especificação de Requisitos; e iv) Validação de Requisitos. Cabe ressaltar que o fluxo entre as atividades não ocorre de forma a seguir um fluxo único, pois, caso exija a necessidade, um fluxo alternativo, pode ser utilizado, visando correção dos artefatos obtidos nas atividades anteriores. Detalhamento das atividades: Elicitação de Requisitos. Nessa atividade, há o contato com o cliente responsável por definir os requisitos a serem alcançados durante o desenvolvimento do software. A fim de iniciar as atividades de elicitação de requisitos, é necessário realizar uma reunião definindo formas e metodologias a serem aplicadas para que os artefatos 17

28 (requisitos) sejam identificados. Essa reunião acontece, pois as técnicas para a elicitação dos requisitos não são fixas e pré-determinadas para os projetos. Cada projeto pode utilizar técnicas diferentes de extração, visando proporcionar maior flexibilidade a esta atividade. Isso acontece por muitos projetos que a empresa é responsável possuírem tempos e espaços físicos (distância) diferentes. Nessa reunião, também são definidas as pessoas responsáveis por realizar as aplicações das técnicas de levantamento de requisitos. As informações geradas devem ser apresentadas em um documento para dar suporte às atividades a serem realizadas posteriormente; Figura 7 Fase Desenvolvimento de Requisitos Avaliação dos Requisitos. Nessa atividade, é realizada uma avaliação dos requisitos por parte da equipe responsável pelo desenvolvimento. Com essa avaliação, são construídos documentos e diagramas (artefatos) 18

29 para o melhor entendimento dos membros da equipe. Além disso, deve ser analisada a viabilidade de implementação dos requisitos encontrados, ajudando a definir custos e conflitos para a implementação de cada requisito. Posteriormente a essa análise, tem-se noção sobre o risco envolvido para o atendimento de cada requisito; Especificação dos Requisitos. Nessa atividade, os requisitos devem ser detalhados utilizando documentos e diagramas construídos na atividade anterior. Além disso, ocorre à definição de atores dos requisitos definindo membros da equipe para a criação de cada um dos requisitos. Uma importante tarefa para todo o projeto ocorre nessa atividade, a observação da permissão de escrita nos módulos 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 verificação da possibilidade do reuso de módulos desenvolvidos anteriormente em outros projetos, visando causar menos retrabalho na fase Desenvolvimento; Validação de Requisitos. Nessa atividade, são elaborados critérios de aceitação dos requisitos para realizar tarefas de revisões 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 são definidos casos de testes e padrões aceitáveis para a futura validação dos requisitos que ocorre na fase Desenvolvimento Fase Desenvolvimento (Criação) Na fase Desenvolvimento, ocorre a criação e o teste do sistema. Nesta fase, são utilizados artefatos gerados na fase anterior, como os documentos de requisitos, diagramas e padrões de aceitação. O detalhe esquemático da fase Desenvolvimento é apresentado na Figura. A fim iniciar essa fase, é necessário existir breve descrição das principais ferramentas e recursos utilizados, tais como, sistemas gerenciadores de banco de dados, IDEs, 19

30 software para controle de versão e ferramenta para registro de sugestões e correção de erros. Com a utilização 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 calendário e prazos estabelecidos. Para ter controle sobre o projeto, devem acontecer pequenas reuniões diariamente entre os envolvidos no projeto para que haja feedback sobre o andamento do desenvolvimento. Essas reuniões são breves, com duração de 15 minutos, citando dificuldades encontradas e evoluções no projeto. Com as reuniões diárias, é possível obter noção sobre o desenvolvimento e consequentemente, controle sobre o prazo e riscos referentes a atrasos no cronograma. Um importante fator é a maior interação entre a equipe de desenvolvimento, forçando a existência de cooperação entre os profissionais responsáveis pelo desenvolvimento. Com o auxílio da ferramenta de controle de versão Tortoise SVN, é possível garantir a consistência entre as versões do sistema, possibilitando o desenvolvimento modular e acarretando maior flexibilidade na alocação das tarefas. Após o desenvolvimento, o profissional passa o artefato criado (módulo do sistema) para que o setor de testes possa iniciar seus trabalhos. As atividades de teste abordam a validação dos requisitos descritos no documento de requisitos, realizando a validação dos padrões previamente estabelecidos. Caso existam discordâncias com os requisitos e seus padrões, o analista de teste deve notificar o analista de desenvolvimento responsável pelo módulo. 20

31 Figura 8 Fase Desenvolvimento (Criação) Caso o desenvolvimento satisfaça os requisitos e seus padrões, a entrega do software deve ser feita para que o cliente tenha conhecimento sobre o que esta sendo construído. Com a entrega sendo realizada em partes, pode ser obtido um feedback por parte do cliente, verificando se alguma alteração precisa ser realizada. Caso exista, ela deve passar pela fase Gerenciamento de Requisitos para ter uma melhor visão sobre a viabilidade e impacto a ser gerado sobre o desenvolvimento, retornando ao início da fase Desenvolvimento. Após a validação por parte do cliente, o setor de teste deve gerar um novo artefato (documento de caso de uso), fazendo breve descrição do sistema. Esse artefato serve de apoio para ao setor de suporte da empresa e ao cliente, servindo como manual para sua interação com o sistema. 21

32 Fase Gerenciamento de Requisitos Nessa fase, um fluxo padrão é seguido durante o desenvolvimento do software. Através da fase de Gerenciamento de Requisitos é possível assegurar que os requisitos levantados no início do projeto supram as necessidades do cliente. Caso exista algum novo/alteração 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 alterações necessita ser validada pela questão do cliente saber o que é melhor para ele. Por isso, deve ser realizada uma análise verificando a necessidade da mudança. Nessa fase, é importante verificar o impacto do requisito, visando a consistência do software. Caso existam mudanças a serem realizadas, é necessário que todos os artefatos gerados na fase Desenvolvimento de Requisitos sejam revisados para ter conhecimento sobre as alterações e os impactos causados nos prazos e no calendário do projeto. A questão de impacto abrange a disponibilidade dos recursos com relação aos prazos de permissões de escrita nos módulos durante o desenvolvimento. Possivelmente, pode ser necessário realizar mudanças nos documentos de registro de atividades, adequando-as da melhor maneira. Após a realização da mudança nos artefatos, é relatada a nova situação para a equipe de desenvolvimento para eles estarem cientes do novo cronograma e das exigências do cliente. Detalhe esquemático da fase Gerenciamento de Requisitos é apresentado na Figura 9. 22

33 Figura 9 Fase Gerenciamento de Requisitos Caso o requisito solicitado não seja definido como viável pela equipe de desenvolvimento, é necessário reportar ao requisitante com justificativa da não implementação do requisito Fase Finalização do Projeto Nessa fase, o desenvolvimento do software está concluído e deve ser implantado no cliente. Antes de realizar a implantação, deve existir nova verificação do software para rever os requisitos implementados e os padrões impostos. Essa fase busca a qualidade e a integração do software, visando gerar um produto de qualidade para o cliente. Para isso, são necessários os artefatos criados nas fases anteriores para verificar a consistência do software, validando os requisitos levantados para o projeto. Após a verificação, validação e implantação do software, treinamentos são realizados para fornecer suporte necessário ao cliente para operar o software. Além disso, há uma reunião em que são analisados os pontos fortes e os 23

34 pontos fracos do processo de desenvolvimento, visando aprender e inferir melhorias aos próximos desenvolvimentos. Detalhe esquemático da fase Finalização do Projeto é apresentado na Figura. Figura 10 Fase Finalização do Projeto 1.5 Considerações Finais Neste capítulo, foi apresentada a descrição do processo de desenvolvimento proposto com o objetivo de mostrar seu funcionamento e esclarecer suas atividades. Através do processo proposto é aproveitada a questão da equipe de desenvolvimento não ser grande. Com o processo, o problema de levantamento e de validação dos requisitos pode ser resolvido, fazendo com que a equipe diminua a quantidade de retrabalhos pela existência de ruídos na comunicação por parte de seus membros. 24

35 Apesar da resistência proporcionada pela equipe de desenvolvimento com relação documentação do software, a proposta faz uso de atividades para criar o mínimo necessário de artefatos de documentação e modelagem de software, relatando os requisitos encontrados no ciclo de vida do processo. Assim, a proposta de uma metodologia menos sobrecarregada de documentação sobre os passos do processo de desenvolvimento pode acarretar menos barreiras por parte dos membros, sem deixar de gerar os artefatos necessários para que o software seja construído com qualidade. 25

36 4 Aplicação do Processo Proposto 1.1 Considerações Iniciais A fim de aplicar o proposto processo de desenvolvimento de software, foi construído um software Gerenciador Eletrônico de Documentos junto à equipe responsável na empresa. Este presente capítulo irá descrever a aplicação do processo proposto na prática, assim como toda a funcionalidade do software criado. Os passos tomados para o desenvolvimento do Software são descritos na seção 4.2. Descrição do Software, suas características e sua modelagem são apresentadas na Seção 4.3. A descrição do funcionamento do software é abordada na Seção Descrição do Desenvolvimento do Software Desenvolvimento de Requisitos A fim de realizar a atividade de elicitação dos requisitos, foi realizada uma reunião com o gerente de desenvolvimento da empresa a fim de definir as formas de avaliação/extração de requisitos a serem utilizadas no processo de desenvolvimento. Após a reunião foi estabelecido que seriam realizadas entrevistas com profissionais da área de contabilidade além da definição de um canal de contato com o objetivo de obter maior conhecimento sobre as necessidades encontradas para as atividades de gestão de documentos. Nesta etapa também foram definidos os membros responsáveis por essas atividades, nos quais foram nomeados dois colaboradores para essa função. As atividades de avaliação dos requisitos então foram realizadas aplicando-se entrevistas de forma informal sobre os futuros usuários do sistema. As entrevistas ocorrem em uma reunião marcada com os profissionais da área, tendo como responsáveis pelo da mesma os colaboradores destinados às atividades de avaliação dos requisitos. Ao final 26

37 dessa reunião, foram documentados os requisitos possibilitando que estes pudessem ser avaliados pelo corpo de colaboradores que participaram do projeto. Também foi definido um canal de comunicação com os usuários, um chat utilizado entre os profissionais e parceiros da Empresa-Alvo, com intuito de suprir dúvidas e sugestões posteriores. Alguns dos requisitos encontrados na atividade de avaliação foram: Permitir troca de documentos entre contadores e clientes; Notificar a chegada de novos documentos via ; Permitir exclusão de documentos; Permitir aplicação de filtros de datas e categorias na pesquisa de documentos; Permitir a criação e exclusão de categorias de documentos; Autenticar usuários com CPF/CNPJ e senha; Permitir cadastrar novos clientes no sistema; Permitir requisitar a chave para utilização do sistema; Permitir aos clientes enviarem para seus contadores. Da mesma forma, foram identificados requisitos não funcionais: Ferramenta deve ser web; O sistema será desenvolvido em C# (ASP); Proibir o envio de arquivos executáveis, visando segurança; Os arquivos devem ser mantidos acessíveis apenas a seus destinatários; O tamanho máximo do arquivo a ser enviado é de 40 MB; Boa navegabilidade; Fazer uso mínimo de "cliques" possíveis para realizar atividade; Interface simples e dedutiva. Ao final da avaliação dos requisitos, foram realizadas as atividades de especificação dos requisitos, onde foi possível a modelagem do software através de diagramas e descrições de casos de uso que serão exibidos nas seções 4.4 e 4.5 a seguir. Cabe ressaltar que não foi possível a reutilização de 27

38 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 repositórios virtuais de software da Empresa-Alvo. Após a modelagem do software, foi repassado aos colaboradores envolvidos no projeto os requisitos do software e a modelagem criada. Padrões de interface e arquitetura do software também foram discutidos e determinados nas atividades de validação com o intuito de acrescentá-los junto ao documento de requisitos para que pudessem ser validados futuramente a proporção que os módulos fossem construídos. 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 Gerência de Projetos Microsoft Project Desenvolvimento (Criação) As atividades de desenvolvimento começaram logo após a fase de desenvolvimento dos requisitos, onde foi possível elicitar e documentar as necessidades e seus padrões a serem implementados no produto final. Ferramentas como Microsoft Visual Studio 2012, foram usadas para codificar as rotinas dos módulos, assim como criar a estrutura de banco de dados necessária e modelada na fase anterior. A ferramenta de controle de versões Tortoise SVN, foi utilizada para que se pudesse garantir a integridade das versões durante todas as atividades presentes no cronograma de desenvolvimento. À proporção que os módulos do GED foram construídos, estes seguiam para o setor de testes, onde foram verificados juntos aos artefatos gerados na primeira etapa, os requisitos e padrões. Quando encontrados alguns erros ou não conformidades nos módulos, estes foram relatados como casos e destinados aos colaboradores envolvidos através da ferramenta 28

39 Mantis, a fim de registrar todas as atividades bem como acompanhá-las conforme a evolução do projeto. Ao final dos testes de cada módulo, foram registradas as suas funcionalidades e telas no intuito de documentá-las Gerenciamento de Requisitos Cabe ressaltar que, por causa do tamanho do projeto, não houve a necessidade da ênfase nessa fase, pois não houve demanda de novo requisito a ser incluso no processo de desenvolvimento Finalização do Projeto Após a finalização do desenvolvimento dos módulos, estes foram integrados e novamente revisados pelo setor de teste, a procura de requisitos não implementados ou partes que fugissem dos padrões de interface definidas na fase de desenvolvimento de requisitos. Foi criado então um novo documento relatando as funções do software disponíveis no software reunindo todos os documentos dos módulos gerados até então, possibilitando criar um documento, em formato de apostila, que além de registrar o novo software, vai auxiliar nas atividades de treinamento ou suporte da empresa. 4.3 Descrição do Software O software desenvolvido é um Sistema Gerenciador Eletrônico 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 funções de forma prática, 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 contábil que o utiliza. Quando enviado, um documento é armazenado no repositório virtual referente ao destinatário que possui as categorias criadas em seu subdiretório. O software 29

40 utiliza essa organização para facilitar a gestão de documentos, o que agrega agilidade na realização da procura por algum documento além de oferecer a possibilidade de realizar mais um filtro sobre a pesquisa referente à data do documento. 4.4 Modelagem do Software Para a especificação do software, foram utilizados dois diagramas da UML: Diagrama de Casos de Uso e Diagrama de Classes. Além desses diagramas, foram elaborados a Descrição dos Casos de Uso e o Diagrama de Navegação. Esses diagramas foram construídos utilizando a ferramenta Astah* ( 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, é possível notar as funções do GED e seus atores. Para melhorar o entendimento dessas funções, foram construídos documentos de Descrição de Caso de Uso (Tabela ) Diagrama de Classes Por causa da existência 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, estão alocadas classes responsáveis pelas regras de "negócio" (Figura 12). No pacote Persistência, estão localizadas classes responsáveis pelo acesso ao banco de dados (Figura 13). No pacote Entidades, estão localizadas classes para suporte aos métodos presentes no sistema (Figura ). No pacote Interface, estão localizadas classes responsáveis por funções que atualizam informações na tela para o usuário. 30

41 Figura 11 Diagrama de Caso de Uso Tabela 2 Descrição do Caso de Uso: Enviar Documento Nome do Caso de Uso Ator Principal Resumo Pré-condições Ações do ator 1. Na tela inicial clicar na opção "Enviar Documento" Enviar Documentos Contador Esse caso de uso descreve as etapas percorridas por um contador ao enviar um novo documento para um cliente. O contador precisa estar logado no sistema. Fluxo Principal Ações do Sistema 3. É selecionado ou digitado nome ou parte do nome do cliente em que se deseja enviar o Documento. 5. O contador escolhe a categoria a qual o documento pertence e 2. É exibida uma tela listando os clientes do contador. 4. É exibido e requerido na tela uma nova caixa exibindo todos as categorias de Documentos. 31

42 pressiona a opção "Enviar". Restrições / Validações Ações do ator 6. É exibida uma mensagem avisando do sucesso do envio e são exibidos os outros documentos pertencentes a mesma categoria já enviados. 7. É enviado um para o destinatário do documento informando que este possui um novo documento em seu GED. 1- Não é possível enviar arquivos executáveis (.exe). 2- Não é possível enviar arquivos com tamanho superior a 40 Mb. Fluxo alternativo Ações do sistema Fluxo de Exceção Código do produto não existente no sistema Ações do ator Ações do sistema 1. Comunicar ao usuário que não existe nenhum arquivo selecionado, caso pressione a opção enviar sem que selecionar algum documento. Figura 11 Diagrama de Pacotes 32

43 Figura 12 - Diagrama de Classes do Pacote Business Diagrama de Navegação A fim de apresentar melhor visão sobre como seriam expostas as funções no sistema e de que forma elas iriam se localizar, foi construído um Diagrama de Navegação (Figura 14). Através deste diagrama é possível observar como ocorre o acesso às funções do sistema através das setas que indicam as possibilidades de navegação entre as telas do software. 33

44 Figura 13 Diagrama de Classes do Pacote Persistência Figura 15 Diagrama de Classes do Pacote de Entidades 34

45 4.5 Modelagem de Dados Para armazenar os dados, foi construída a modelagem de dados utilizando a ferramenta Workbench Community 6.08 (Figura 1517). Há três tabelas: Clientes, Contador e Categorias. Figura 14 Diagrama de Navegação Figura 15 Modelagem de Dados 4.6 Funcionalidade Nesta seção, são descritas as funções do sistema. Inicialmente, é apresentada uma tela de Login (Figura 16), sendo possível realizar o acesso ao sistema pelo usuário do tipo Contador e pelo o usuário do tipo Cliente. Antes de realizar o login, é necessário possuir uma chave de acesso (senha) 35

46 obtida na opção Solicite sua Chave no menu, escolhendo o tipo de usuário (Contador ou Cliente). Quando selecionada a opção, é apresentada uma tela para o usuário obter sua senha (Figura 17). Para solicitar a senha, a empresa contábil ou contador deve ter realizado o registro do novo usuário no sistema para que este possa realizar o cadastro de sua senha no sistema. Figura 16 Tela de Login 36

47 Figura 17 Tela de Solicitação de Chave do Sistema Após realizar o login, é apresentada a tela inicial exibindo diversas funções, porém as telas iniciais dos usuários diferem-se. O usuário Contador possui mais funções (Figura ). Se desejar procurar os dados disponibilizados para ele ou por ele, o usuário Contador deve selecionar o botão Exibir Documentos na tela inicial. Após a seleção, uma tela é apresentada exibindo as informações (Figura ). Para efetuar a pesquisa de documentos, o usuário Contador deve realizar alguns filtros por meio da TreeView ou digitando a informação desejada (total ou parcialmente) no campo apropriado. Em seguida, são exibidos novos campos para realizar outros filtros. Ao realizar a pesquisa, selecionando o botão Exibir Documento, uma relação de nomes dos documentos e suas características são exibidas em uma tabela. Nessa relação, pode ser feito o download do documento selecionando-o ou excluílo do diretório virtual, selecionando a opção excluir situada a direita da tabela. 37

48 Figura 20 Tela Inicial (Usuário Contador) A função 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 opções situadas na divisão à direita (Figura ). Entre essas opções, há um botão que abre uma caixa para selecionar o documento desejado. Após a seleção, deve ser escolhida a categoria do documento e selecionar o botão Enviar. Após o processamento da operação, é emitida uma mensagem de feedback ao usuário sobre a reação perante a sua ação e lista os documentos presentes no diretório escolhido pelo contador para enviar o documento. Voltando a tela inicial, há duas opções de registro para o usuário do tipo Contador para registrar: i) outros contadores; e ii) clientes. Essa função pode ser realizada apenas pelo usuário 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 opção registrar. Cabe ressaltar que registro de um usuário é realizado apenas uma vez. Em seguida, é emitida uma mensagem com o feedback sobre a ação. 38

49 Figura 21 Tela de Exibição de Documentos (Usuário Contador) Figura 22 Tela de Envio de Documentos (Usuário Contador) O registro de novos contadores acontece da mesma forma, porém com uma diferença (Figura ). Quando um usuário Contador realiza o registro de 39

50 um novo cliente, o cliente é relacionado com o contador responsável pelo seu registro; no registro de um contador, não há essa relação. Isso acontece por causa da organização de diretórios ser de forma que os diretórios dos clientes localizam-se como subpastas do diretório do contador ao qual o cliente está relacionado. Figura 23 Tela de Registro de Novos Clientes Figura 24 Tela de Registro de Usuários Contadores 40

51 Outra importante responsabilidade atribuída apenas ao usuário Contador é criar e excluir categorias de documentos (Figura ). Qualquer contador pode criar uma categoria desde que não exista outra com seu mesmo nome. Para excluir uma categoria, o sistema verifica nos diretórios dos clientes associados ao contador se existem documentos referentes à categoria que se deseja excluir; caso exista algum documento, não será possível excluir a presente categoria. Figura 25 Tela de Adição e Exclusão de Categorias de Documentos O GED possui a opção de o usuário modificar dados referentes ao seu perfil. Para ter acesso a essa opção, o usuário deve passar o mouse sobre o símbolo de engrenagem, situado ao canto superior direito da tela, e selecionar a opção Configurações no menu gerado abaixo ao símbolo. Após selecionar a opção, é exibida uma tela com os campos do perfil disponíveis para modificação (Figura ). Na tela de configurações, deve ser fornecida apenas a nova informação a ser inserida nos campos do perfil e, em seguida, selecionar o botão Salvar situado abaixo de cada sessão de configuração. O sistema emite feedback após a execução de cada ação para notificar o usuário. Com citado anteriormente, há diferenças entre os tipos de usuários. As diferenças 41

52 basicamente são visíveis quando observadas as telas iniciais de cada usuário, em que se pode notar que o usuário Cliente possuir menos opções quando comparado ao usuário Contador (Figura ). Figura 26 Tela de Configurações (Usuário Contador) Figura 27 Tela Inicial (Usuário Cliente) 42

53 Além da quantidade de funções, as funções para exibir documentos e enviar documentos são mais simples e com menos passos a serem seguidos para o usuário Cliente (Figura ), pois é permitida apenas a exibição e envio de dados referentes a um contador, enquanto o usuário Contador pode enviar ou exibir documentos referentes a diversos clientes. Figura 28 Tela de Exibição de Documentos (Usuário Cliente) O único "privilégio" que o usuário Cliente possui a mais que o usuário Contador é referente à possibilidade de entrar em contato diretamente com o usuário contador utilizando o GED. Essa tarefa facilita a ação de contato por parte do cliente que não precisa abrir um site de com seu contador. Os dados de outros possíveis contatos são apresentados na tela de contatos (Figura ). 43