SISTEMA PARA CONTROLE DO FLUXO DE...

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO

SISTEMA PARA CONTROLE DO FLUXO DE PROPOSTAS

DE CUSTOMIZAÇÃO

VALCIR WILLI SCHMIDT

BLUMENAU

2012

2012/1-20



DE CUSTOMIZAÇÃO

Trabalho de Conclusão de Curso submetido à

Universidade Regional de Blumenau para a

obtenção dos créditos na disciplina Trabalho

de Conclusão de Curso II do curso de Sistemas

de Informação— Bacharelado.

Prof. Wilson Pedro Carli, Mestre - Orientador

BLUMENAU

2012

2012/1-20


DE CUSTOMIZAÇÃO

Por


Trabalho aprovado para obtenção dos créditos

na disciplina de Trabalho de Conclusão de

Curso II, pela banca examinadora formada

por:

______________________________________________________

Presidente: Prof. Wilson Pedro Carli, Mestre – Orientador, FURB

______________________________________________________

Membro: Prof. Everaldo Artur Grahl, Mestre – FURB

______________________________________________________

Membro: Prof. Oscar Dalfovo, Doutor – FURB

Blumenau, 04 de julho de 2012.

Dedico este trabalho a minha namorada

Camila, por ter me auxiliado e compreendido

nos meus momentos de dificuldade.

AGRADECIMENTOS

A Deus, pelo seu imenso amor e graça.

À minha família, que mesmo longe, sempre esteve presente.

Aos meus amigos, pelos empurrões e cobranças.

Ao meu orientador, Wilson Pedro Carli, por ter acreditado na conclusão deste trabalho.

Aos professores do Departamento de Sistemas e Computação da Universidade

Regional de Blumenau por suas contribuições durante os semestres letivos.

Os bons livros fazem “sacar” para fora o que a

pessoa tem de melhor dentro dela.

Lina Sotis Francesco Moratti

RESUMO

Este trabalho apresenta um sistema para controle do fluxo de solicitações de propostas de

customizações nos softwares da empresa Senior Sistemas S/A, onde há um setor responsável

pela manutenção de software do tipo adaptativa, nos softwares por ela desenvolvidos. Neste

processo existia uma deficiência para controlar principalmente o envio ao cliente e o

faturamento das propostas de customização de software, as quais eram controladas com o

apoio de uma ferramenta de help desk e através de planilhas eletrônicas Excel. Para o

desenvolvimento foi utilizada a ferramenta de desenvolvimento Borland Delphi 7, integrado

com a biblioteca de componentes DevExpress e AlphaControls, sendo a base de dados em

SQL Server. Como resultado destaca-se o aumento da agilidade no controle das propostas que

estão pendentes de análise e faturamento.

Palavras-chave: Customização de software. Manutenção de software. Propostas.

ABSTRACT

This work presents a system for controlling the flow of requests for proposals for

customizations to the software company's Senior Sistemas S/A, where there is a sector

responsible for maintaining adaptive software type, the software developed by it. In this

process there was a failure to control mainly the customer delivery and billing of the proposed

software customization, which were controlled with the help of a tool to help desk and

through Excel spreadsheets. For development we used the Borland Delphi development tool

7, integrated with the library AlphaControls and DevExpress components, and the database in

SQL Server. As a result, we highlight the increased flexibility in controlling the proposals that

are pending analysis and billing.

Keywords: Software customization. Software maintenance. Proposal.

LISTA DE FIGURAS

Figura 1 – Distribuição de esforços de manutenção de software ............................................. 16

Figura 2 – Planilha de controle de faturamento ........................................................................ 21

Figura 3 – Formulário de checklist de acompanhamento de projeto ........................................ 22

Figura 4 – Planilha de testes utilizada para validar o desenvolvimento ................................... 22

Figura 5 – Solicitação de Customização .................................................................................. 23

Figura 6 – Tela de detalhes da proposta ................................................................................... 24

Figura 7 – Tela de gerenciamento de propostas ....................................................................... 24

Figura 8 – Tela de atividades – visualização de registros ........................................................ 25

Figura 9 – Diagrama de casos de uso ....................................................................................... 29

Figura 10 – Modelo Entidade Relacionamento ........................................................................ 30

Figura 11 – Diagrama de Processos ......................................................................................... 31

Figura 12 – Diagrama de estados da proposta .......................................................................... 33

Figura 13 – Ferramenta Microsoft SQL Server Management Studio ...................................... 34

Figura 14 – Tela utilizando o componente Cxgrid ................................................................... 34

Figura 15 – Tela de acesso ao sistema utilizando o componente SknMngr ............................. 35

Figura 16 – Tela principal do sistema ...................................................................................... 35

Figura 17 – Tela de cadastro de recursos ................................................................................. 36

Figura 18 – Tela de cadastro de habilidades dos recursos ........................................................ 36

Figura 19 – Tela de cadastro de ofertas de customização ........................................................ 37

Figura 20 – Tela de cadastro de propostas ............................................................................... 37

Figura 21 – Tela de detalhamento da análise ........................................................................... 38

Figura 22 – Relatório do detalhamento da análise ................................................................... 39

Figura 23 – Tela para inserir anexos na análise ....................................................................... 40

Figura 24 – Mensagem de confirmação para definir o plano de testes .................................... 40

Figura 25 – Tela de definição do plano de testes ..................................................................... 40

Figura 26 – Tela de detalhes do corpo da proposta .................................................................. 41

Figura 27 – Tela com modelo de proposta gerado ................................................................... 42

Figura 28 – Tela de envio de e-mail da proposta ..................................................................... 42

Figura 29 – Código fonte responsável pelo envio de e-mail da proposta................................. 43

Figura 30 – Tela de registro da aprovação da proposta ............................................................ 43

Figura 31 – Tela de preenchimento do plano de Testes ........................................................... 44

Figura 32 – Tela de confirmação de entrega ............................................................................ 44

Figura 33 – Tela de confirmação de homologação................................................................... 45

Figura 34 – Relatório checkList de acompanhamento .............................................................. 45

Figura 35 – Tela de manutenção do faturamento ..................................................................... 46

Figura 36 – Relatório de faturamento previsto ......................................................................... 46

Figura 37 – Relatório de propostas faturadas mês .................................................................... 47

Figura 38 – Relatório de propostas aprovadas mês .................................................................. 47

Figura 39 – Relatório com propostas não faturadas ................................................................. 48

Figura 40 – Gráfico com previsão de faturamento mês............................................................ 48

Figura 41 – Tela de cadastro de produtos ................................................................................. 49

Figura 42 – Exemplo de e-mail enviado pelo Windows Service .............................................. 49

Figura 43 – Windows Service ativo para envio de e-mail de alerta .......................................... 50

LISTA DE QUADROS

Quadro 1 – Requisitos funcionais ............................................................................................. 28

Quadro 2 – Requisitos não funcionais ...................................................................................... 29

Quadro 3 – Descrição do caso de uso Manter Proposta de Customização ............................... 57

Quadro 4 – Descrição do caso de uso Manter Ofertas Atendidas e grau de Habilidade .......... 58

Quadro 5 – Descrição do caso de uso Manter Análises Técnicas ............................................ 59

Quadro 6 – Descrição do caso de uso Manter Plano de Testes ................................................ 60

Quadro 7 – Descrição do caso de uso Registrar Entrega .......................................................... 60

Quadro 8 – Descrição do caso de uso Manter recursos ............................................................ 60

Quadro 9 – Descrição do caso de uso visualizar propostas faturadas ...................................... 60

Quadro 10 – Descrição do caso de uso visualizar propostas aprovadas ................................... 60

Quadro 11 – Descrição do caso de uso manter ofertas de customização ................................. 61

Quadro 12 – Descrição do caso de uso manter produtos .......................................................... 61

Quadro 13 – Descrição do caso de uso manter configurações gerais ....................................... 61

Quadro 14 – Descrição do caso de uso registrar aprovação ..................................................... 61

Quadro 15 – Descrição do caso de uso efetuar login ............................................................... 61

Quadro 16 – Descrição do caso de uso registrar homologação ................................................ 61

Quadro 17 – Descrição do caso de uso registrar resultados testes ........................................... 61

Quadro 18 – Descrição do caso de uso visualizar análises técnicas ......................................... 62

Quadro 19 – Descrição do caso de uso visualizar previsão de faturamento............................. 62

Quadro 20 – Descrição do caso de uso visualizar propostas aguardando faturamento ............ 62

Quadro 21 – Descrição do caso de uso manter faturamento .................................................... 62

Quadro 22 – Descrição do caso de uso Manter detalhes da proposta....................................... 62

Quadro 23 – Descrição do caso de uso Visualizar checklist .................................................... 62

Quadro 24 - Dicionário de dados da tabela Analise ................................................................. 63

Quadro 25 - Dicionário de dados da tabela Anexos ................................................................. 63

Quadro 26 - Dicionário de dados da tabela AvisoPendencias .................................................. 64

Quadro 27 - Dicionário de dados da tabela ConfigGerais ........................................................ 64

Quadro 28 - Dicionário de dados da tabela Faturamento ......................................................... 64

Quadro 29 - Dicionário de dados da tabela HabilitadesRecursos ............................................ 65

Quadro 30 - Dicionário de dados da tabela Ofertas.................................................................. 65

Quadro 31 - Dicionário de dados da tabela PlanoTestes .......................................................... 65

Quadro 32 - Dicionário de dados da tabela Produtos ............................................................... 66

Quadro 33 - Dicionário de dados da tabela Propostas .............................................................. 66

Quadro 34 - Dicionário de dados da tabela Recursos ............................................................... 66

Quadro 35 - Dicionário de dados da tabela RecursosProposta ................................................. 67

Quadro 36 - Dicionário de dados da tabela VersaoPropostas .................................................. 67

LISTA DE SIGLAS

CRM – Customer Relationship Management

ERP – Enterprise Resource Planning

JSF – Java Server Faces

JPA – Java Persistence API

MER – Modelo Entidade Relacionamento

RF – Requisitos Funcionais

RNF – Requisitos Não Funcionais

TCC – Trabalho de Conclusão de Curso

SUMÁRIO

1 INTRODUÇÃO .................................................................................................................. 12

1.1 OBJETIVOS DO TRABALHO ......................................................................................... 12

1.2 ESTRUTURA DO TRABALHO ....................................................................................... 13

2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 14

2.1 MANUTENÇÃO DE SOFTWARE .................................................................................. 14

2.1.1 Manutenibilidade de Software ........................................................................................ 15

2.1.2 Tipos de Manutenção de Software .................................................................................. 15

2.1.3 Custos de Manutenção ..................................................................................................... 17

2.2 CUSTOMIZAÇÃO DE SOFTWARE .............................................................................. 17

2.3 SISTEMA ATUAL ........................................................................................................... 19

2.4 TRABALHOS CORRELATOS ........................................................................................ 23

3 DESENVOLVIMENTO .................................................................................................... 26

3.1 LEVANTAMENTO DE INFORMAÇÕES ....................................................................... 26

3.2 ESPECIFICAÇÃO ............................................................................................................. 27

3.2.1 Requisitos Funcionais ...................................................................................................... 27

3.2.2 Requisitos não Funcionais ............................................................................................... 28

3.2.3 Casos de uso .................................................................................................................... 29

3.2.4 Modelo Entidade Relacionamento................................................................................... 30

3.2.5 Diagrama de Processos .................................................................................................... 31

3.3 IMPLEMENTAÇÃO ......................................................................................................... 33

3.3.1 Técnicas e ferramentas utilizadas .................................................................................... 33

3.3.2 Operacionalidade da implementação ............................................................................... 35

3.4 RESULTADOS E DISCUSSÃO ....................................................................................... 50

4 CONCLUSÕES .................................................................................................................. 52

4.1 EXTENSÕES ..................................................................................................................... 53

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 54

APÊNDICE A – Descrição dos Casos de Uso ...................................................................... 56

APÊNDICE B – Detalhamento do Dicionário de Dados ..................................................... 63

12

1 INTRODUÇÃO

As atividades de manutenção de software têm em comum, os serviços prestados de

adaptação do sistema às medidas e preferências do usuário, onde existem implantações e

customizações que demandam períodos maiores ou menores de tempo. Algumas

customizações mais complexas requerem a elaboração de cronogramas de desenvolvimento e

se tornam um problema quando não se consegue realizá-las de forma organizada e previsível,

documentando solicitações e decisões de adaptação, de forma que as responsabilidades não se

percam e se consiga avaliar detalhadamente cada atividade que deverá ser executada

(COELHO, 2007).

Desta forma, a empresa Senior Sistemas, situada na cidade de Blumenau, vem

buscando a melhoria de seus processos, procurando obter o aumento de sua competividade no

mercado. A mesma verificou inconsistências no fluxo de propostas enviadas aos clientes e

decidiu agilizar o entendimento do que deve ser feito em cada proposta aprovada. Para

atendimento a esta necessidade, este trabalho apresenta um sistema para o controle do fluxo

das solicitações de propostas de customizações de software, recebidas pelo setor de serviços

customizados da empresa. Atualmente a empresa já possui este processo, sendo uma parte do

processo feita de maneira manual e a outra parte apoiada a um sistema de apoio a usuários

para suporte e resolução de problemas técnicos (Help-Desk), que está disponível na rede

interna da empresa. Com o uso do sistema desenvolvido a empresa poderá obter mais

agilidade no retorno aos clientes e um melhor entendimento do que será customizado pelo

programador.

11..11 OOBBJJEETTIIVVOOSS DDOO TTRRAABBAALLHHOO

O objetivo geral deste trabalho é apresentar um sistema para controle do fluxo de

propostas de customização com registro de análises técnicas de customização.

Os objetivos específicos do trabalho são:

a) registrar as propostas elaboradas e suas diferentes versões;

b) disponibilizar relatório com os valores das propostas pendentes de faturamento;

c) disponibilizar o registro dos detalhes técnicos do trabalho a ser executado;

13

d) disponibilizar relatório com o número de propostas faturadas mensalmente;

e) disponibilizar relatório com o número de propostas aprovadas mensalmente;

11..22 EESSTTRRUUTTUURRAA DDOO TTRRAABBAALLHHOO

A estrutura deste trabalho esta dividida em quatro capítulos.

No primeiro capítulo tem-se a introdução ao tema principal deste trabalho com a

apresentação dos objetivos a serem alcançados.

No segundo capítulo apresenta-se a fundamentação teórica pesquisada sobre

manutenção de software, customização de software, sistema atual e trabalhos correlatos.

No terceiro capítulo descreve-se os detalhes sobre o desenvolvimento, especificação e

modelagem e apresenta-se um estudo de caso dentro da operacionalidade do sistema

encerrando-se com os resultados e discussões.

No quarto capítulo tem-se as conclusões deste trabalho bem como apresentam-se

sugestões para melhorias futuras.

14

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo aborda os assuntos que serão apresentados nas seções a seguir, tais como,

manutenção de software, customização de software, o sistema atual e os trabalhos correlatos.

22..11 MMAANNUUTTEENNÇÇÃÃOO DDEE SSOOFFTTWWAARREE

De acordo com o Institute of Electrical and Electronic Engineers (1998) a manutenção

de software é uma atividade da qual ocorrem modificações em um ou mais artefatos

resultantes do desenvolvimento de um software, buscando mantê-lo disponível, corrigir suas

falhas, melhorar seu desempenho e adequá-lo aos requisitos novos ou modificados conforme a

necessidade do usuário.

Segundo Pressman, (2006) a maioria dos problemas com a manutenção do software é

causado por deficiência em como o software foi planejado e desenvolvido. Os problemas mais

clássicos são:

a) a maioria dos softwares quando planejados não levam em consideração o fator de

manutenibilidade em seus projetos;

b) há falta de métodos ou ferramentas eficazes para auxiliarem em como determinada

manutenção afetará os sistemas;

c) dificuldade de rastrear o processo através do qual o software foi criado. A maioria

dos softwares não foi projetada para suportar alterações;

d) é difícil ou impossível traçar a evolução do software através das varias versões. As

alterações não são adequadamente documentadas. A documentação não existe, é

incompreensível ou esta desatualizada.

e) em geral novos requisitos são adicionados ao invés de requisitos já existentes

serem reavaliados;

f) falta de pessoal com experiência em manutenção.

15

2.1.1 Manutenibilidade de Software

De acordo com a definição do Institute of Electrical and Electronic Engineers (1998),

manutenibilidade é a facilidade com que o sistema de software ou componente pode ser

modificado para corrigir falhas, melhorar a performance ou outros atributos, ou adaptado para

mudança de ambiente.

A manutenibilidade de software pode ser definida qualitativamente como a facilidade

com que o software pode ser entendido, corrigido, adaptado ou aumentado. A

manutenibilidade é a meta primordial que orienta os passos de um processo de engenharia de

software segundo Pressman (2006).

Na definição de ambos os autores é possível perceber que manutenibilidade é a

facilidade de realizar alterações em um software. Então conclui-se que para o software ter

uma boa manutenibilidade é necessário que o processo de manutenção tenha início na fase de

projeto e desenvolvimento do software. Neste momento já é necessário o planejamento de

possíveis alterações, desenvolvendo códigos que possam facilitar essas alterações, onde

consequentemente haverá uma grande redução de custos.

2.1.2 Tipos de Manutenção de Software

Existem quatro tipos de manutenção de software que são a corretiva, a adaptativa, a

perfectiva e a preventiva. Aproximadamente 50% das manutenções são relacionadas à

implementação de novos requisitos que seria do tipo perfectiva, 25% a mudanças do sistema

para adaptá-lo a um novo ambiente, 21% para corrigir defeitos do sistema e apenas 4% para

prevenção de erros e falhas que seria do tipo preventiva, conforme demonstrado na Figura 1

(PFLEEGER, 2004).

Cada tipo de manutenção tem uma finalidade, são elas:

a) manutenção corretiva: este tipo de manutenção caracteriza-se pela correção de erros

relatados ao desenvolvedor durante a utilização do software, para que faça o

diagnostico e os corrija (PRESSMAN, 2006);

b) manutenção preventiva: é a modificação de um produto de software realizada após

a entrega para detectar e corrigir falhas antes que se tornem falhas eficazes

(INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 1998);

16

c) manutenção perfectiva: é a modificação de um produto ou software realizada após a

entrega para melhorar o desempenho ou sustentabilidade (INTERNATIONAL

ORGANIZATION FOR STANDARDIZATION, 1998);

d) manutenção adaptativa: este tipo de manutenção se refere à necessidade de adaptar

o software para se acomodar a mudanças do ambiente que está inserido, estas

podem ser de hardware, sistema operacional, ou ainda regras de negócio, leis ou

políticas governamentais. Este tipo de manutenção na maioria dos casos não é

controlada pelos responsáveis pela manutenção do software e ocorre principalmente

devido a rápida mudança em diversos aspectos da computação. Novas gerações de

hardware são anunciadas em um curto intervalo de tempo. Novos sistemas

operacionais ou relançamentos de antigos aparecem regularmente, equipamentos

periféricos e outros elementos de sistema são atualizados com grande frequência

(PRESSMAN, 2006).

Este trabalho foca no tipo de manutenção adaptativa, onde são feitas customizações no

software para adaptá-lo as regras de negócio do cliente ou a sua necessidade de uso.

Fonte: Pfleeger (2004).

Figura 1 – Distribuição de esforços de manutenção de software

17

2.1.3 Custos de Manutenção

O custo de manutenção de software tem aumentando nos últimos anos. Durante a

década de 70 a manutenção era responsável por cerca de 30 a 40% do custo do software para

a empresa desenvolvedora. Na década de 80 este valor pulou para aproximadamente 60% do

custo do software. A partir da na década de 90 este valor passou para cerca de 70% do custo

do software (PRESSMAN, 2006).

Quando se pensa em custo de manutenção de software geralmente vem em mente

valores, mas nem sempre este é o único custo da empresa segundo Pressman (2006). Existem

também custos intangíveis, como insatisfação dos clientes por não terem suas solicitações

atendidas, ou não terem sido atendidas no prazo que esperavam, e também a redução de

qualidade global do software, como resultado de mudanças que introduziram erros de alta

complexidade no software mantido, ou ainda falta de motivação da equipe, devido ao grande

número de problemas encontrados, e com isso precisam ser “empurrados” para trabalhar em

uma tarefa de manutenção.

A manutenção pode ser um desafio para as organizações que precisam considera-la em

seu dia a dia. Não é de se esperar que uma empresa de grande porte troque todos os seus

sistemas somente pelo fato de que a tecnologia neles empregada está ultrapassada. Estes

sistemas atenderam perfeitamente suas necessidades durante um grande tempo e representam

ativos da organização, com isso ela estará disposta a investir para manter seus sistemas

funcionando (PADUELLI, 2007).

22..22 CCUUSSTTOOMMIIZZAAÇÇÃÃOO DDEE SSOOFFTTWWAARREE

Grande parte dos softwares de Enterprise Resource Planning (ERP) ou Customer

Relationship Management (CRM) atuais têm de lidar com a questão da personalização, por

vezes mais conhecida como “customização” (COELHO,2007). Customizar um software não

só significa introduzir modificações que o tornem aderentes às necessidades particulares de

uma empresa ou linha de negócio, mas também um grande esforço de implementação da

equipe que irá executá-la.

Quando realizada pela empresa fabricante do software, a customização pode ser por

18

vezes uma fonte de renda, por outras, de prejuízo. Ela costuma ser uma fonte de renda quando

a customização pode ser vendida e reincorporada em novas versões do software, ou quando

for possível agregar uma rede de serviços capaz de implementá-las sem modificar o produto.

Por outro lado, a customização pode ser um ônus pesado quando ela implica em uma versão

diferente do produto para cada cliente, causando problemas de suporte e manutenção, ou

quando a exigência de customização pelo cliente não pode ser obedecida pelo fornecedor

devido a limitações de recursos, aumentando o risco da perda do cliente para a concorrência.

Programação customizada, ou customização de software, envolve a compilação de código

com o objetivo de criar ou adaptar programas de software destinados especificamente ao

cliente, podendo envolver o desenvolvimento de uma aplicação inteiramente nova ou a

adaptação de um produto já existente (COELHO, 2007).

2.2.1 Modelos de Customização

Embora a customização de um pacote de software não seja uma tarefa para leigos, é

com certeza uma tarefa mais simples que os processos que envolvem o desenvolvimento de

uma solução completa para toda a organização. A estratégia adotada na customização é

denominada modelo de customização (FUSCO, 2003).

Os modelos mais conhecidos são:

a) parametrização: é o armazenamento em tabelas internas do sistema das definições

adotadas pelo usuário baseado nas funcionalidades requeridas para suas regras de

negocio;

b) interpretador de regras de negocio: permite ao usuário definir como serão calculados

os fatores resultantes, baseados nos dados armazenados no sistema de informação;

c) desenvolvimento de componentes: existe a possibilidade de que o software contratado

não atenda a todos os requisitos da empresa que o adquiriu, neste caso pode optar pelo

desenvolvimento de componentes de software e anexa-los ao sistema atual;

d) adequação de tabelas: permite ao usuário acrescentar campos em tabelas do sistema

que não estavam previstos no pacote original;

e) determinação de lay-outs: é a adequação do formato de entrada ou saída de dados do

sistema de acordo com a necessidade do cliente.

19

22..33 SSIISSTTEEMMAA AATTUUAALL

A empresa Senior Sistemas foi fundada em 1988, e neste período iniciou suas

atividades desenvolvendo um sistema de gestão de recursos humanos e folha de pagamento.

Nos anos seguintes começou a desenvolver para novas áreas, comercializando assim, os

seguintes sistemas no mercado:

a) Vetorh: para gestão de recursos humanos;

b) Sapiens: para gestão empresarial;

c) Segurança: para gestão de acesso e segurança;

d) Regente: para administração de agências de viagens.

A empresa possui um setor especializado em customizar artefatos relacionados aos

sistemas que desenvolve, dentre estes artefatos estão os relatórios, regras, telas para a web,

entre outros (SENIOR SISTEMAS, 2010).

Para cada solicitação de customização é remetida uma proposta de customização ao

cliente, com valores e cronograma. Cada proposta tem uma data de validade, período o qual

os valores e cronograma de desenvolvimento estão garantidos ao cliente. Passando este prazo,

pode haver alterações de valores e cronograma, devido ao fato de que os programadores já

estão alocados no desenvolvimento de outras solicitações.

O tratamento das solicitações de customizações realizadas a este setor especializado é

executado conforme a ordem apresentada:

a) a solicitação é realizada pelo cliente através de chamado no sistema de Help-Desk,

com um descritivo do que deve ser customizado;

b) o analista de demanda1 aplica filtros de pesquisa no sistema de Help-Desk para

encontrar os chamados com solicitações;

c) o analista de demanda procede com a análise, em conjunto com um analista de

desenvolvimento2 para estimar o tempo de desenvolvimento e viabilidade de

desenvolvimento da solicitação, bem como verificar disponibilidade de agenda dos

programadores;

1 Analista de demanda – Pessoa com o conhecimento de especialista nas rotinas do sistema onde será aplicada a

customização (SENIOR SISTEMAS, 2010).

2 Analista de desenvolvimento – Pessoa técnica com conhecimento de especialista na linguagem e técnica de

desenvolvimento que será utilizada (SENIOR SISTEMAS, 2010).

20

d) após a análise, o analista de demanda monta uma proposta de customização com

valores e cronograma de desenvolvimento para ser enviada ao cliente;

e) em seguida o analista de demanda registra em uma planilha eletrônica Excel

apresentada na Figura 2, na aba “Prev-Vetorh”, os valores previstos para

faturamento, os valores que futuramente serão faturados caso a proposta seja

aprovada pelo cliente dentro do prazo de validade descrito na mesma;

f) caso o cliente não aprove esta proposta a mesma é lançada na planilha Excel na aba

“Cancelados”;

g) se a proposta é aprovada dentro do prazo, a mesma é encaminhada pelo analista de

demanda ao analista de desenvolvimento e aos programadores selecionados para o

desenvolvimento. Neste momento com base no tamanho do projeto e na sua

experiência, o analista de desenvolvimento irá decidir por montar ou não uma

planilha de testes que devem ser executados ao finalizar o projeto. Caso a decisão

for criá-la, a planilha será encaminhada ao programador responsável pelo

desenvolvimento, juntamente com o checklist 3

de acompanhamento do projeto. Se

durante o desenvolvimento o programador precisar de auxílio, este será prestado

pelo analista de desenvolvimento. Feito isto, o valor antes lançado na aba previsto

da planilha pelo analista de demanda, é agora lançado na aba “Firme” da planilha;

h) após o término do desenvolvimento, o programador registra todas as etapas de

desenvolvimento no checklist de acompanhamento do projeto e segue a planilha de

testes montada pelo analista de desenvolvimento, caso o mesmo tenha decidido

pelo uso da planilha. Feito isto o programador, envia os artefatos desenvolvidos ao

cliente e caso não sejam necessários ajustes o programador entrega o checklist e

planilha de testes ao analista de demanda, para que o mesmo providencie o

faturamento;

i) após isso, o analista de demanda aplica filtros no sistema de Help-Desk para

identificar quais são as propostas onde os trabalhos já foram concluídos, e a quanto

tempo já foram entregues, para que sejam faturados caso o cliente não tenha

solicitado mais nenhum ajuste.

3 Checklist – Lista de verificação do atendimento de ações e critérios pré-estabelecidos (INFORMAL,2012).

21

A Figura 2 demonstra a planilha onde são feitos os registros dos valores de

faturamento. Para cada equipe de desenvolvimento é utilizada uma planilha, renovada a cada

ano, onde nesta planilha existem as seguintes abas:

a) prev-equipe: onde são registrados os valores das propostas enviadas aos clientes

mais não aprovadas;

b) firmes-equipe: onde são registrados os valores das propostas aprovadas, e

encaminhadas para desenvolvimento;

c) faturados: são registrados os valores das propostas já desenvolvidas entregues e

faturadas;

d) cancelados: são registrados os valores das propostas não aprovadas pelos clientes e

com isso não desenvolvidas;

e) acompanhamento: uma totalização mês a mês dos valores das 4 abas mencionadas.

Fonte: Senior Sistemas (2010).

Figura 2 – Planilha de controle de faturamento

A Figura 3 demonstra o formulário de acompanhamento de projeto utilizado pelo

programador, o qual ao término do desenvolvimento é entregue ao analista de demanda.

22


Figura 3 – Formulário de checklist de acompanhamento de projeto

A Figura 4 demonstra a planilha com os testes elaborados pelo analista de

desenvolvimento para ser utilizada em determinados projetos para validar o desenvolvimento.


Figura 4 – Planilha de testes utilizada para validar o desenvolvimento

A Figura 5 demonstra uma solicitação de customização no sistema de Help-Desk.

23


Figura 5 – Solicitação de Customização

22..44 TTRRAABBAALLHHOOSS CCOORRRREELLAATTOOSS

O objetivo do Trabalho de Conclusão de Curso (TCC) de Petters (2007) foi

desenvolver um sistema de acompanhamento e gerenciamento de propostas e requisitos,

possibilitando a interação entre o analista que especificou os requisitos e o cliente que irá

avaliar se os requisitos especificados atendem a sua solicitação. Utilizando as tecnologias das

linguagens de programação Ajax, Flash e PHP, Petters (2007) relata como é possível obter

bons resultados no desenvolvimento de uma aplicação para internet, onde poderá permitir que

os clientes façam o acompanhamento das suas solicitações e façam a aprovação das suas

propostas. Assim como objetivo deste trabalho, este sistema visa acompanhar e gerenciar as

propostas dos projetos. Um modelo de uma tela do sistema pode ser visualizado na Figura 6.

24

Fonte: Petters (2007).

Figura 6 – Tela de detalhes da proposta

Já o objetivo do software desenvolvido pela empresa Proposital é o gerenciamento de

propostas comercias, com o uso da tecnologia HTML5. A empresa oferece um software

intuitivo e com fácil interatividade ao usuário, e assim como o objetivo deste trabalho, visa

gerenciar o fluxo das propostas comerciais com maior facilidade e agilidade conforme tela

apresentada na Figura 7 (PROPOSITAL, 2011).

Fonte: Proposital (2011).

Figura 7 – Tela de gerenciamento de propostas

Na seqüência de trabalhos tem-se o TCC de Hardock (2008), cujo objetivo foi

desenvolver um sistema para gerenciar tarefas de projetos, bem como as pessoas que devem

realizá-las. Com o uso das tecnologias Java Server Faces (JSF) e Java Persistence API (JPA),

Hardock (2008) pretendeu deixar o sistema mais flexível em relação ao banco de dados e

25

servidores que serão utilizados. Assim um dos objetivos específicos deste trabalho foi o

sistema controlar o custo dos projetos e gerenciar as tarefas alocadas para cada recurso. A

Figura 8 apresenta a tela de atividades do TCC de Hardock (2008).

Fonte: Hardock (2008).

Figura 8 – Tela de atividades – visualização de registros

26

3 DESENVOLVIMENTO

Neste capítulo são apresentadas as características do aplicativo desenvolvido, bem

como a especificação de requisitos funcionais e não funcionais, diagrama de casos de uso e o

Modelo de Entidade Relacional (MER). São descritas também as técnicas e ferramentas

utilizadas no processo de implementação, a operacionalidade do sistema e os resultados

obtidos.

33..11 LLEEVVAANNTTAAMMEENNTTOO DDEE IINNFFOORRMMAAÇÇÕÕEESS

A empresa Senior Sistemas dispõe de um setor especializado em customizar os

artefatos relacionados às funcionalidades dos sistemas mantidos pela mesma. Para cada

solicitação de customização efetuada é enviada uma proposta com estimativa de valores e

horas gastas para o desenvolvimento. Estes valores são lançados como um faturamento

previsto para o mês, de acordo com o vencimento estipulado para proposta. O problema é que

não há um controle efetivo para as propostas pendentes de envio e propostas já enviadas.

Existe apenas a possibilidade de pesquisa no sistema de Help-Desk e o registro em planilhas

eletrônicas Excel, o que ocupa grande parte do tempo do analista, que precisa filtrar as

propostas a serem analisadas, bem como verificar quando a proposta foi enviada, e se a

mesma já foi entregue e/ou faturada ou se ainda está em desenvolvimento.

Outro problema encontrado é que para toda a proposta enviada é necessária uma

análise e em alguns é necessário realizar uma prototipação4 por parte do analista em relação a

solução de como será desenvolvido o projeto. Porém as anotações (rascunhos) desta análise

algumas vezes são extraviadas, e quando o projeto chega ao desenvolvedor o mesmo tem que

analisar, ou perguntar ao analista tudo novamente, para saber quais os recursos/funções vai

utilizar para o desenvolvimento, e em alguns casos o analista não possui mais as anotações

para o desenvolvimento.

4 Prototipação – é o ato de desenvolver um sistema/modelo sem as funcionalidades inteligentes (acesso a banco,

regras de negócio), apenas com as funcionalidades gráficas, e algumas funcionalidades básicas para o

funcionamento do próprio protótipo (INFORMAL, 2012).

27

33..22 EESSPPEECCIIFFIICCAAÇÇÃÃOO

Nesta seção serão apresentados os principais Requisitos Funcionais (RF), Requisitos

Não Funcionais (RNF), sua rastreabilidade com casos de uso e o Modelo de Entidade de

Relacionamento (MER) do sistema desenvolvido. A descrição dos casos de uso será

apresentada no Apêndice A, e o dicionário de dados no Apêndice B.

3.2.1 Requisitos Funcionais

No Quadro 1 são apresentados os requisitos funcionais do sistema e sua rastreabilidade

com os casos de usos.

Requisitos Funcionais Caso de Uso

RF01: O sistema deverá permitir ao analista de demanda a manter o

cadastro de propostas de customização.

UC01

RF02: O sistema deverá permitir ao analista de demanda e ao analista de

desenvolvimento manter cadastro dos Recursos.

UC02

RF03: O sistema deverá permitir ao analista de demanda visualizar as

propostas faturadas.

UC03

RF04: O sistema deverá permitir ao analista de demanda o visualizar o

número de propostas aprovadas por mês.

UC04

RF05: O sistema deverá permitir ao analista de demanda manter o cadastro

de ofertas de customização.

UC05


dos produtos.

UC06


de configurações gerais do sistema.

UC07

RF08: O sistema deverá permitir ao analista de demanda registrar a

aprovação da proposta.

UC08

RF09: O sistema deverá permitir ao analista de desenvolvimento e analista

de demanda manter o cadastro de ofertas atendidas com a definição de

nível de habilidade para cada recurso, em cada uma das ofertas atendidas.

UC09

28


de demanda manter o registro de análises técnicas de customização.

UC10


de demanda manter um plano de testes, para cada proposta atendida.

UC11

RF12: O sistema deverá permitir ao programador, analista de demanda e

analista de desenvolvimento efetuar o login no sistema.

UC12

RF13: O sistema deverá permitir ao programador registrar a entrega dos

artefatos desenvolvidos.

UC13

RF14: O sistema deverá permitir ao programador registrar a homologação

do desenvolvimento dos artefatos.

UC14

RF15: O sistema deverá permitir ao programador registrar resultado dos

testes do plano de testes.

UC15

RF16: O sistema deverá permitir ao programador visualizar as análises

técnicas de customização.

UC16

RF17: O sistema não deverá permitir inserir uma nova versão da proposta

se a última versão já possuir a situação “Concluída” ou “Não aprovada”.

UC01

RF18: O sistema não deverá permitir a alteração da análise técnica se a

mesma já estiver concluída.

UC10

Quadro 1 – Requisitos funcionais

3.2.2 Requisitos não Funcionais

No Quadro 2 são apresentados os requisitos não funcionais do sistema.

Requisitos Não Funcionais

RNF01: O sistema deverá ser implementado utilizando a linguagem Object Pascal, com a

ferramenta de desenvolvimento Borland Delphi 7.

RNF02: O sistema deverá utilizar o banco de dados SQL SERVER 2008.

RNF03: O sistema deverá ser compatível com a plataforma Windows.

RNF04: O sistema não deverá ter a necessidade de instalação para sua execução no

ambiente cliente.

RNF05: O sistema deverá estar integrado com o banco de dados do sistema de Help-Desk

para extrair informações.

RNF06: Deve-se controlar o acesso ao sistema através do uso de senha.

29

RNF07: O sistema deverá fazer uso de um Windows Service para checagem e envio dos

alertas de pendências através de e-mail. Quadro 2 – Requisitos não funcionais

3.2.3 Casos de uso

Na Figura 9 é apresentado o diagrama de casos de uso do sistema, desenvolvido com o

auxílio da ferramenta Enterprise Architect. Existem 3 atores, o analista de demanda, o analista

de desenvolvimento e o programador, onde o analista de demanda herda as permissões do

analista de desenvolvimento e do programador. No Apêndice A é possível visualizar o

detalhamento do diagrama.

Figura 9 – Diagrama de casos de uso

uc Use Case Model

UC01 - Manter

propostas de

customização

Programador

UC02 - Manter

recursos

UC03 - Visualizar

propostas faturadas

UC04 - Visualizar

propostas aprov adas

UC05 - Manter ofertas

de customização

UC09 - Manter ofertas

atendidas e nív el de

habilidade

UC10 - Manter

análises técnicas

UC16 - Visualizar

análises técnicas

UC12 - Efetuar

login

UC13 - Registrar

entrega

Analista

desenv olv imento

Analista demanda

UC15 - Registrar

resultados testes

UC11 - Manter

plano de testes

UC14 - Registrar

homologação

UC06 - Manter

produtos

UC07 - Manter

configurações

gerais

UC08 - Registrar

aprov ação

UC17 - Visualizar

prev isão faturamentoUC18 - Visualizar

propostas aguardando

faturamento UC19 - Manter

faturamento

UC20 - Manter

detalhes da

proposta

«extend»

«extend»

«extend»

30

3.2.4 Modelo Entidade Relacionamento

Na Figura 10 apresenta-se o Modelo Entidade Relacionamento (MER) do sistema,

desenvolvido com auxílio da ferramenta DbDesigner. No Apêndice B é possível visualizar o

detalhamento destas entidades através do Dicionário de Dados.

Figura 10 – Modelo Entidade Relacionamento

31

3.2.5 Diagrama de Processos

A Figura 11 demonstra o fluxo desenvolvido com o auxilio da ferramenta modeladora

de processos BizAgi, o qual demonstra o atendimento das solicitações de customizações com

a implantação do sistema desenvolvido, as operações executadas automaticamente pelo

sistema, estão descritas como “Sistema” no início da frase.

Figura 11 – Diagrama de Processos

O fluxo tem início quando o chamado entra no sistema de Help Desk. Neste momento

o sistema desenvolvido busca esta solicitação e insere o registro de proposta na base,

32

enviando uma solicitação de análise aos analistas. Em seguida o analista de desenvolvimento

registra a análise técnica em conjunto com o analista de demanda e alocam os recursos

necessários, montando um cronograma com horas e datas para execução das atividades, se

julgar necessário o analista de desenvolvimento também prepara um plano de testes para os

artefatos que devem ser desenvolvidos. Após concluir a análise, o sistema lança o faturamento

como previsto com base nas horas e datas informadas no cronograma, utilizando-se do valor

hora previamente cadastrado.

Na sequência, o analista de demanda envia a proposta ao cliente definindo um prazo

para vencimento da mesma. Depois disso existem três possíveis status para proposta, a

aprovada, a não aprovada e a vencida. Caso a proposta esteja vencida, o sistema avisa o

cliente se este possui interesse em prosseguir com a customização ou não, caso tenha

interesse, o analista de demanda envia nova versão da proposta e define um novo vencimento

para mesma. Se a proposta for rejeitada, o sistema lança o faturamento como cancelado e

conclui a proposta como não aprovada. Se a proposta é aprovada, o sistema avisa o analista de

desenvolvimento e os programadores envolvidos de que o desenvolvimento deve ser iniciado

nas datas previstas, e após eles terem concluído o desenvolvimento, preencherão o plano de

testes e o registro de entrega. Quando o cliente homologar o desenvolvimento, o programador

registra no sistema a confirmação de homologação, e o sistema avisa ao analista de demanda

de que a proposta já pode ser faturada.

Na Figura 12 é possível visualizar o diagrama de estados da proposta durante do fluxo

do processo de customização utilizado na empresa Senior Sistemas.

33

Figura 12 – Diagrama de estados da proposta

33..33 IIMMPPLLEEMMEENNTTAAÇÇÃÃOO

A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da

implementação.

3.3.1 Técnicas e ferramentas utilizadas

Para implementação do sistema foi utilizada a ferramenta Borland Delphi 7 Enterprise

da empresa Borland, que auxilia no desenvolvimento da interface, com seu conjunto de

ferramentas integradas, e linguagem Object Pascal. Como banco de dados para o sistema

stm Diagrama de Estados Proposta

Inicio

Em análise Pendente

Aguardando

Aprov açãoAguardando

entrega ao cliente

Cancelada

Final

Aguardando

homologação

Aguardando

faturamento

ConcluídaRegistrar faturamento

Registrar homologação

Registrar entregaAvaliar [Reprovado]

Avaliar [Aprovado]

Enviar ao cliente

Efetuar análiseRegistrar

34

optou-se por utilizar o SQL Server 2008, pois é o mesmo banco de dados em que já esta

hospedada a aplicação de Help-Desk, facilitando assim a integração com o sistema

desenvolvido. Para gerenciá-lo foi utilizada a ferramenta SQL Server Management Studio,

fornecida com o banco de dados, conforme demonstrado na Figura 13.

Figura 13 – Ferramenta Microsoft SQL Server Management Studio

Como pacotes adicionais de componentes para desenvolvimento com Delphi foram

utilizados os pacotes DevExpress e AlphaControls em suas versões Demo, fornecidos pelas

mesmas empresas, onde do pacote da Dev Express foi utilizado o componente Cxgrid que

pode ser visualizado na Figura 14, e do pacote da Alpha Controls foi utilizado o componente

SknMngr, para aplicação de cores e efeitos nas telas, o qual tem sua funcionalidade

demonstrada na Figura 15.

Figura 14 – Tela utilizando o componente Cxgrid

35

Figura 15 – Tela de acesso ao sistema utilizando o componente SknMngr

3.3.2 Operacionalidade da implementação

A operacionalidade do sistema é inicialmente apresentada pela tela de acesso, onde o

usuário do sistema deve preencher os campos usuário e senha conforme já apresentado na

Figura 16.

Após realizar o acesso ao sistema todos os usuários são direcionados a tela principal do

sistema, onde o acesso será mais restrito quando o usuário for um analista de desenvolvimento

ou um programador. Na Figura 16 é apresentada à tela principal, acessada por um usuário

analista de demanda que possui acesso completo ao sistema, no rodapé pode ser visualizado o

nome do usuário e perfil de acesso.

Figura 16 – Tela principal do sistema

Ao passar o mouse sobre os campos ou botões da tela é apresentado um balão de ajuda,

como é possível visualizar na Figura 16. Esta funcionalidade está disponível em todas as telas

36

do sistema para facilitar o entendimento do usuário durante o uso.

Nesta tela estão às pendências do usuário, com duplo clique sobre uma delas será

carregada à tela relacionada à resolução da pendência. Caso o usuário ativo for um analista de

demanda, poderá visualizar todas as pendências, se for um analista de desenvolvimento ou

programador, poderá visualizar apenas as pendências relacionadas ao seu usuário. O analista

de demanda poderá ter os seguintes tipos de pendências: análise, envio de proposta,

faturamento. O analista de desenvolvimento poderá ter as seguintes pendências, a análise, e o

acompanhamento. Já o programador poderá ter as pendências, de desenvolvimento, executar

plano de testes, e a homologação.

Ainda na tela principal, da esquerda para direita, o botão “Recursos” permite o acesso

à tela de cadastro de recursos e suas habilidades de desenvolvimento em cada oferta de

customização, como pode ser visualizado nas Figuras 17 e 18.

Figura 17 – Tela de cadastro de recursos

Figura 18 – Tela de cadastro de habilidades dos recursos

37

Na Figura 19 está demonstrado o cadastro de ofertas de customização, que estão

relacionadas com as habilidades de desenvolvimento do programador, o qual é acessado

através do menu “Diversos\Cadastros\Ofertas de customização”.

Figura 19 – Tela de cadastro de ofertas de customização

Na sequência ainda na tela principal, existe o botão proposta que permite o acesso à

tela de cadastro de propostas atendendo ao objetivo específico “a”, onde é possível gerar e

enviar as propostas conforme pode ser visualizado na Figura 20.

Figura 20 – Tela de cadastro de propostas

38

Esta tela será alimentada de forma automática através de um Windows Service5 que

fará a inserção das novas propostas registradas no sistema de help desk. Ao inseri-las, deixará

o status da primeira versão como pendente de análise, comunicando o analista de que existe

uma pendência para verificar.

Caso o analista tenha a necessidade de registrar uma proposta que ainda não foi

inserida pelo Windows Service, poderá utilizar o segundo botão localizado ao lado do campo

“Proposta”, fazendo a busca diretamente na base do sistema de help desk.

Após a proposta ser carregada do sistema de help desk, é possível visualizar as

informações do cliente e detalhamento da solicitação feita pelo mesmo.

Com estas informações, o analista carrega a tela de análise através do botão localizado

no grupo de botões “Detalhar Análise” conforme demonstrado na Figura 20. Este botão

quando pressionado, apresentará a tela da Figura 21 onde é possível detalhar a análise,

atendendo ao objetivo específico “c” deste trabalho, além de identificar os recursos que farão

o desenvolvimento dos artefatos customizados.

Figura 21 – Tela de detalhamento da análise

Ao clicar no botão ao lado do campo “Recurso”, é demonstrada a tela de “Habilidades

5 Windows Service – executável do Windows sem interface ao usuário, iniciado automaticamente (MSDN, 2010)

39

Recursos”, onde são demonstrados os recursos aptos a desenvolver a oferta identificada e os

seus respectivos níveis de habilidade na oferta selecionada, como é possível visualizar na

Figura 20. Com isso o analista poderá decidir qual recurso irá selecionar para desenvolver, e

se precisar de um desenvolvimento mais ágil e com melhor qualidade, utilizará o recurso com

mais habilidade por exemplo.

Se posteriormente o programador que acessar a tela de análise para consulta e

necessitar visualizar ou imprimir a descrição da análise, poderá clicar no botão com símbolo

de impressora, localizado no canto superior direito da tela, para visualizar o relatório

demonstrado na Figura 22.

Figura 22 – Relatório do detalhamento da análise

Durante a análise o analista também poderá incluir anexos para facilitar o

entendimento do que devem ser desenvolvido pelo programador, como por exemplo, as

figuras, fluxos, e os protótipos. Os anexos podem ser inseridos através da tela apresentada na

Figura 23, a qual pode ser acessada através do segundo botão da esquerda para direita, que

está no topo da tela demonstrada na Figura 21. Estes anexos serão gravados na base de dados

e ficarão disponíveis para visualização do programador posteriormente.

40

Figura 23 – Tela para inserir anexos na análise

Ao concluir a análise onde houve a inclusão de horas para qualidade, será solicitado se

existe a necessidade de gerar um plano de testes, conforme mensagem apresentada na Figura

24.

Figura 24 – Mensagem de confirmação para definir o plano de testes

Caso decida por definir um plano de testes, será apresentada a tela da Figura 25 onde

deverá indicar as condições de testes e resultados esperados para cada condição.

Figura 25 – Tela de definição do plano de testes

Depois de definir o plano de testes, a proposta ficará com o status de “pendente de

envio” para o cliente e neste momento o primeiro botão do grupo “Escrever Proposta” da tela

41

de propostas demonstrada na Figura 20, ficará habilitado. Ao clicar neste botão será

apresentada a tela da Figura 26, onde deverão ser preenchidos os detalhes da proposta, como

soluções propostas e benefícios que a solução entregue ao cliente.

Figura 26 – Tela de detalhes do corpo da proposta

Nesta tela estão as informações que serão demonstradas na proposta de customização

que será enviada ao cliente onde será descrita a solução proposta pelo analista para atender a

solicitação e os benefícios que a customização poderá trazer ao cliente. Após preencher estas

informações e gravá-las, deve-se clicar no botão “Gerar Proposta” para que seja gerado um

arquivo texto no formato “doc” (utilizado como modelo padrão de propostas de customização

da empresa Senior Sistemas), conforme pode ser visualizada na Figura 27. Esta proposta já

possui as informações necessárias para o envio ao cliente, o analista apenas verificará se está

de acordo. Ao sair da tela do documento, o sistema solicitará se deseja salvar a proposta para

posterior envio ou não, conforme também pode ser visto na Figura 27.

42

Figura 27 – Tela com modelo de proposta gerado

Ainda na tela de proposta demonstrada na Figura 20 no grupo de botões “Escrever

Proposta”, ao clicar no segundo botão será apresentada a tela para envio da proposta por e-

mail ao cliente, conforme pode ser visualizado na Figura 28.

Figura 28 – Tela de envio de e-mail da proposta

Na Figura 29 é possível visualizar o código fonte responsável por enviar o e-mail da

proposta através da tela apresentada na Figura 28.

43

Figura 29 – Código fonte responsável pelo envio de e-mail da proposta

Após enviar a proposta, apresentada na tela da Figura 29, o seu status será alterado

para “Aguardando aprovação do cliente”, e ficará disponível para na tela da Figura 30, para o

analista registrar a aprovação ou rejeição.

Figura 30 – Tela de registro da aprovação da proposta

Caso a proposta seja rejeitada, o sistema irá alterar o status da mesma para

“cancelada”. Mas se for aprovada, o sistema vai alterar o status para “pendente de entrega” e

44

irá comunicar os envolvidos, disponibilizando a proposta para desenvolvimento. Depois de

concluído o desenvolvimento, o programador responsável preenche o plano de testes

descrevendo os resultados obtidos e indica se cada um dos itens de testes propostos pelo

analista ao definir o plano estão testados e quais os resultados obtidos durante o teste

executado, como pode ser visto na Figura 31.

Figura 31 – Tela de preenchimento do plano de Testes

Após preencher o plano de testes e finalizar o desenvolvimento, o programador marca

como entregue ao cliente o artefato desenvolvido, conforme demonstrado na Figura 32, que

pode ser acessada através do menu “Desenvolvimento\Entregar Artefatos”.

Figura 32 – Tela de confirmação de entrega

Ao confirmar a entrega, a proposta ficará com o status de “aguardando homologação

do cliente”. Quando o cliente confirmar esta homologação, o programador responsável poderá

fazer o registro desta através da tela demonstrada na Figura 33, que é acessada pelo menu

“Desenvolvimento\Confirmar homologação”.

45

Figura 33 – Tela de confirmação de homologação

Após homologado se for necessária a impressão do checklist de acompanhamento esta

impressão poderá ser feita através do relatório demonstrado na Figura 34, o qual pode ser

acessado através do menu “Desenvolvimento\Gerar CheckList”.

Figura 34 – Relatório checkList de acompanhamento

Após confirmar a homologação a proposta ficará disponível para faturamento. Neste

momento, o analista poderá acessar a tela de manutenção do faturamento através do menu

“Faturamento\Manutenção”, como pode ser visto na Figura 35, onde poderá marcar a

proposta como faturada indicando a data do faturamento. Ao indicar o faturamento da

proposta, seu status é alterado para “concluído”, finalizando assim o processo de

customização.

46

Figura 35 – Tela de manutenção do faturamento

Se o analista necessitar de uma consulta do total de propostas que ainda não foram

faturadas para ter uma previsão de faturamento para o mês, poderá utilizar o relatório de

faturamento previsto, que está disponível no menu “Relatórios\previsão de faturamento”. O

mesmo pode ser acessado através da tela principal demonstrada na Figura 20, e o resultado da

impressão deste relatório pode ser visualizado na Figura 36.

Figura 36 – Relatório de faturamento previsto

Atendendo ao objetivo específico “d”, é possível listar um relatório com quantidade e

valor das propostas faturadas mensalmente conforme demonstrado na Figura 37. Este

47

relatório está disponível no menu “Relatórios\Faturamento Mês”.

Figura 37 – Relatório de propostas faturadas mês

Atendendo ao objetivo específico “e”, através do relatório demonstrado na Figura 38 é

possível visualizar o número de propostas aprovadas no mensalmente, o qual é acessado

através do menu “Relatórios\Propostas Aprovadas Mês”.

Figura 38 – Relatório de propostas aprovadas mês

Atendendo ao objetivo específico “b” é possível visualizar cada uma das propostas que

estão aguardando faturamento, através do relatório demonstrado na Figura 39 o qual é

acessado através do menu “Relatórios\Propostas não Faturadas”.

48

Figura 39 – Relatório com propostas não faturadas

É possível visualizar o mesmo resultado com o valor previsto para faturamento mês

através do gráfico de faturamento, conforme demonstrado na Figura 40. O gráfico pode ser

acessado através do menu “Faturamento\Previsão de Faturamento”.

Figura 40 – Gráfico com previsão de faturamento mês

Cada uma das propostas cadastradas na base do sistema está associada a um produto, e

este produto possui um analista de demanda e um analista de desenvolvimento responsável

pelos trabalhos desenvolvidos para os mesmos. Na Figura 41 pode ser visualizada a tela onde

estas informações são cadastradas, sendo que a informação de código e nome do produto é

carregada diretamente do sistema de help desk, através do segundo botão ao lado do campo

49

“Produto”, conforme Figura 41.

Figura 41 – Tela de cadastro de produtos

Para cada tipo de pendência encontrada no controle do fluxo de propostas, o Windows

Service desenvolvido enviará um e-mail de alerta, com os detalhes da(s) mesma(s) para que

sejam tomadas providências. Um exemplo de e-mail de pendências de análise pode ser

visualizado na Figura 42, e na Figura 43 pode ser visualizado o Windows Service instalado e

ativo para envio dos e-mails.

Figura 42 – Exemplo de e-mail enviado pelo Windows Service

50

Figura 43 – Windows Service ativo para envio de e-mail de alerta

33..44 RREESSUULLTTAADDOOSS EE DDIISSCCUUSSSSÃÃOO

Quando se fala em custo de manutenção de software para as empresas que os

desenvolvem, geralmente se faz referência a valores, mas nem sempre este é o único custo da

empresa. Existem também custos intangíveis como a insatisfação dos clientes pelo não

atendimento de suas solicitações ou ainda por não serem atendidas no prazo e com a

qualidade que esperavam (Pressman, 2006). Desta forma a empresa Senior Sistemas procurou

melhorar o gerenciamento do processo de envio das propostas de customização de software,

aumentando assim, a assertividade dos programadores em relação ao que deve ser

desenvolvido, pois com o uso do registro de análise técnicas e a comunicação das pendências

das propostas em seus diversos estágios, através do envio de e-mail, será possível agilizar o

trabalho da equipe de customizações e como consequência diminuir o tempo de resposta aos

clientes.

Quanto aos trabalhos correlatos, o sistema desenvolvido possui uma maior semelhança

com o sistema da empresa Proposital, o qual disponibiliza a informação de valores e períodos

de aprovação da proposta, mantendo o registro da situação de cada proposta, informando ao

responsável quais propostas devem ser avaliadas, e quais já foram faturadas ou enviadas aos

clientes, da mesma forma que o sistema desenvolvido. O sistema da proposital ainda dispõe

de registros de aprovação eletrônica através do e-mail recebido pelo cliente, recurso o qual

não é disponibilizado pelo aplicativo desenvolvido neste TCC.

Em relação aos outros trabalhos de conclusão de curso, verifica-se que o foco do

desenvolvimento não é exatamente o mesmo. O trabalho de Petters (2007) disponibiliza um

51

sistema para cadastro de solicitações de manutenção ou desenvolvimento de softwares, onde o

cliente registra a entrada de uma solicitação, e o analista faz a avaliação e retorna com valores

para serem aprovados. O cliente então deve acompanhar através do sistema por ele

desenvolvido, como está à situação de sua solicitação, diferente do sistema desenvolvido

neste trabalho, onde o cliente recebe a comunicação por e-mail, informando a aprovação da

proposta, e não possui nenhuma interação com o sistema. Hardock (2008) desenvolveu um

aplicativo que apenas mantém o registro de atividades de projeto que devem ser executadas

pelos participantes de determinado projeto, mas não faz nenhum tipo de comunicação aos

envolvidos no projeto, o que no sistema desenvolvido é feito, informando aos envolvidos em

cada uma das atividades.

Por fim o sistema desenvolvido agrega melhorias no processo do fluxo de propostas

de customização de software da empresa Senior Sistemas, trazendo mais agilidade e

assertividade no retorno aos clientes e no desenvolvimento dos artefatos customizados,

atendendo a todos os objetivos propostos.

52

4 CONCLUSÕES

O crescente número de sistemas legados e a dificuldade para mantê-los adequados ás

necessidades das organizações é a principal razão desses softwares frequentemente passarem

por mudanças, mesmo após terem sido entregues aos seus clientes. É com base neste tipo de

mudança que se define a manutenção adaptativa, que o setor de customizações da empresa

Senior Sistemas trabalha, onde este tipo de manutenção é solicitada e paga pelo cliente.

O fluxo de solicitações de customização a cada dia é maior no setor de customizações

da empresa, dificultando assim um controle manual principalmente dos valores das

customizações já faturados, como ocorria anteriormente, pois na correria de todos os dias,

acaba-se esquecendo de propostas que já haviam sido entregues e que não foram mais

retornadas pelos clientes, as quais deveriam ter sido faturadas, com o controle do fluxo de

propostas feito pelo sistema, isso possivelmente não ocorrerá mais, pois diariamente o sistema

enviará um e-mail por meio do Windows Service desenvolvido, avisando os responsáveis em

cada uma das etapas até o encerramento da proposta de customização, evitando assim que

fiquem propostas sem análise ou faturamento, eliminando a ineficiência do setor de

customizações no controle deste fluxo.

Através do registro de analises técnicas da customização é possível obter melhores

resultados nos trabalhos executados pelos programadores da equipe de customizações. Com

as imagens e descrições apresentadas pelos analistas de uma forma mais técnica e não apenas

uma descrição do resultado final a ser entregue ao cliente, os programadores poderão executar

mais rapidamente o trabalho e com uma melhor qualidade, atendendo as expectativas dos

clientes, que solicitam estes trabalhos.

Conclui-se que o sistema desenvolvido apresenta uma melhoria no controle das

solicitações de customização da empresa Senior Sistemas, atendendo a todos os objetivos

propostos.

Os objetivos pessoais também foram atingidos, pois até o momento não havia

desenvolvido uma aplicação com maior porte, apenas pequenos aplicativos, e como este TCC

é aplicativo ao uso da empresa, foi necessária uma maior atenção no desenvolvimento, e

documentação do código, para que posteriormente pudesse ser mantido por outras pessoas,

construindo assim em um ganho de experiência, como programador. Entendeu-se que a

academia foi essencial para chegar á um nível melhor de detalhamento neste trabalho.

53

44..11 EEXXTTEENNSSÕÕEESS

Para dar continuidade a este trabalho podem ser desenvolvidos os seguintes itens:

a) integração com o sistema Soft Expert de controle de apontamento de horas e

agendas dos programadores, que é utilizado na rede interna da empresa. Com as

informações deste sistema poderiam ser disponibilizados detalhes das agendas de

cada um dos recursos antes de alocá-los na proposta através do sistema

desenvolvido;

b) hoje o setor de customizações da empresa ainda não possui uma metodologia

definida para gerenciar os projetos de desenvolvimento dos artefatos

customizados. Esta metodologia ainda esta em estudo pela gerência da empresa,

quanto estiver definido, serão necessárias melhorias no sistema desenvolvido para

utilizar um gerenciamento de escopo de projeto, e estabelecimento de estimativas

por pontos de função;

c) disponibilizar a possibilidade de aprovação automática das propostas por e-mail,

com o uso de um Web Service6 para receber o registro da aprovação.

6 Web Service – é uma aplicação que proporciona dados e serviços a outras aplicações (MSDN, 2010).

54

REFERÊNCIAS BIBLIOGRÁFICAS

COELHO, O. P. Técnicas para customização de software. São Paulo, 2007. Disponível em:

<http://www.microsoft.com/brasil/msdn/tecnologias/arquitetura/Customizacao_Software.msp

x>. Acesso em: 10 abr. 2012.

FUSCO, J.P.A. Tópicos emergentes em engenharia da produção. 2. ed. São Paulo: Arte &

Ciência, 2003.

HARDOCK, L.L.P. Protótipo de um sistema de gerenciamento de projetos e atividades

utilizando JEE. 2008. 69 f. Trabalho de Conclusão de Curso (Bacharel em Ciências da

Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,

Blumenau.

INFORMAL. Dicionário informal, Belo Horizonte, 2012. Disponível em:

<http://www.dicionarioinformal.com.br/>. Acesso em: 13 mar. 2012.

INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS. IEEE standard

collection. Software Enginnering. IEEE, New York, 1998.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14764. Genève,

1998.

MSDN. Introduction to Windows service applications. Redmont, 2010. Disponível em:

<http://msdn.microsoft.com/en-us/library/d56de412%28v=vs.80%29.aspx>. Acesso em: 06

jun. 2012.

PADUELLI, M.M. Manutenção de software: problemas típicos e diretrizes para um

disciplina específica. 2007. 155 f. Dissertação (Mestre em Ciências da Computação e

Matemática Computacional) – Instituto de Ciências Matemáticas e de Computação,

Universidade de São Paulo, São Carlos.

PETTERS, R.F.M. Sistema de gerenciamento e acompanhamento de propostas e

requisitos. 2007. 75 f. Trabalho de Conclusão de Curso (Bacharel em Sistemas de

Informação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,

Blumenau.

PFLEEGER, S.L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall,

2004.

PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw hill, 2006.

PROPOSITAL. Proposital gerenciamento de propostas, Belo Horizonte, 2011. Disponível

em: < https://www.proposital.com.br>. Acesso em: 16 maio 2012.

55

SENIOR SISTEMAS. Intranet da senior, Blumenau, 2010. Disponível em:

<http://webserver/intranet>. Acesso em: 16 maio 2012.

56

APÊNDICE A – Descrição dos Casos de Uso

Este Apêndice apresenta a descrição dos casos de uso conforme previstos no diagrama

apresentado na subseção 3.2.3. No Quadro 3 apresenta-se o caso de uso “Manter proposta de

customização”.

UC01 – Manter proposta de Customização

Descrição: Permite ao analista de demanda, incluir alterar ou excluir informações das propostas

de customização.

Ator: Analista de Demanda.

Pré-condição: O programador e o analista devem estar cadastrados no sistema.

A solicitação que ira gerar a proposta deve estar cadastrado no sistema de Help-

Desk.

Pós-Condição: Uma proposta foi incluída, alterada ou excluída do sistema.

A estimativa de faturamento foi atualizada.

Cenário-Consulta Proposta {Principal}

1. O analista de demanda acessa a tela de proposta.

2. O sistema apresenta a tela de proposta.

3. O analista de demanda opta por localizar a proposta.

4. O sistema carrega as propostas na tela de pesquisa.

5. O analista seleciona uma das propostas apresentadas na pesquisa.

6. O sistema apresenta os dados da proposta, relacionados a consulta.

7. O analista de demanda opta por uma operação ou encerra.

Cenário – Inclusão

No passo 3, o analista de demanda opta por incluir uma nova proposta.

3.1. O analista de demanda informa o número da proposta com base na numeração gerada pelo

sistema de Help-Desk.

3.2. O sistema valida as informações e carrega os dados principais a partir do sistema de help

desk.

3.3. O analista de demanda seleciona gravar.

3.4. O sistema grava as informações deixando o status como pendente de análise

Cenário – Inclusão versão

No passo 3, o analista de demanda opta por incluir uma nova versão da proposta.

3.1. O analista de demanda clica sobre o botão nova versão de proposta.

3.2. O sistema verifica se a ultima versão já não esta concluída ou cancelada.

3.3. O sistema apresenta mensagem “Não é possível incluir nova versão se a ultima estiver com

status concluída ou cancelada.” caso a proposta esteja em um dos status.

3.4. O sistema carrega as informações a partir do sistema de help desk e efetua a gravação da

proposta na base.

Cenário - Alterar Proposta

No passo 7, o analista de demanda opta por alterar a proposta.

7.1. O sistema apresenta os dados para alteração

7.2. O analista de demanda edita os dados e seleciona gravar

57

7.3. O sistema solicita confirmação da operação

7.4. O analista de demanda confirma

7.5. O sistema altera os dados da proposta

Cenário – Excluir Versão da Proposta

No passo 7, o analista de demanda opta por excluir uma versão da proposta.

7.1. O analista de demanda seleciona excluir.

7.2. O sistema checa se o status da versão da proposta esta como “concluído”, ou “cancelada”.

7.3. Caso a proposta possua um dos status o sistema informa ao analista de demanda que não

será possível exclui-la.

7.4. Caso a proposta ainda não esteja com um destes status o sistema solicita a confirmação de

exclusão ao analista de demanda.

7.5. O analista de demanda confirma a exclusão.

7.6. O sistema exclui a versão da proposta.

Cenário – Proposta não Encontrada {Exceção}

No passo 6, caso a proposta informada não exista, o sistema apresenta mensagem “Proposta

inválida.”

Quadro 3 – Descrição do caso de uso Manter Proposta de Customização

No Quadro 4 apresenta-se o caso de uso “Manter Ofertas Atendidas e Grau de

Habilidade”.

UC09 – Manter Ofertas Atendidas e Grau de Habilidade

Descrição: Permite ao analista de demanda ou analista de desenvolvimento definir as ofertas

atendidas e o grau de habilidade para cada programador.

Ator: Analista de Demanda ou Analista de desenvolvimento.

Pré-condição: O recurso deve estar cadastrado no sistema.

A oferta deve estar cadastrada no sistema.

Pós-Condição: O grau de habilidade foi definido para a oferta atendida.

O recurso teve a definição do grau de habilidade para todas as ofertas atendidas.

Cenário-Consulta Ofertas atendidas. {Principal}

1. O analista de demanda/ desenvolvimento acessa a tela de ofertas atendidas.

2. O sistema apresenta a tela de ofertas atendidas.

3. O analista de demanda/desenvolvimento opta por localizar um programador.

4. O sistema carrega os programadores cadastrados na tela de pesquisa.

5. O analista de demanda/desenvolvimento seleciona a opção de pesquisa e informa os dados

para pesquisa.

6. O sistema apresenta os dados das ofertas atendidas pelo programador selecionado.

7. O analista de demanda/desenvolvimento opta por uma operação ou encerra.

Cenário – Incluir ofertas atendidas

No passo 7, o analista de demanda opta por incluir uma nova oferta atendida.

7.1. O analista de demanda carrega uma oferta e define o grau de habilidade para oferta.

7.2. O analista de demanda seleciona a opção gravar.

7.3. O sistema grava as informações para o recurso selecionado.

58

Cenário - Alterar ofertas atendidas

No passo 7, o analista de demanda opta por alterar a oferta atendida.

7.1. O analista de demanda define um novo grau de habilidade para oferta.

7.2. O analista de demanda seleciona a opção gravar.

7.3. O sistema grava as informações para o recurso selecionado.

Cenário – Excluir ofertas atendidas

No passo 7, o analista de demanda/desenvolvimento opta por excluir a oferta atendida.

7.1. O analista seleciona excluir.

7.2. O sistema checa se a oferta esta sendo utilizada em alguma proposta atendida pelo recurso

em questão.

7.3. Caso a oferta já tenha sido utilizada o sistema informa que não será possível exclui-la.

7.4. Caso a oferta ainda não esteja sendo utilizada, o sistema solicita a confirmação de exclusão.

7.5. O analista confirma a exclusão.

7.6. O sistema exclui a oferta e grau de habilidade ligado ao recurso. Quadro 4 – Descrição do caso de uso Manter Ofertas Atendidas e grau de Habilidade

No Quadro 5 apresenta-se o caso de uso “Manter Análises Técnicas”.

UC010 – Manter Análises técnicas

Descrição: Permite ao analista de demanda ou analista de desenvolvimento Incluir Alterar ou

Excluir o registro de análise técnica.

Ator: Analista de Demanda ou Analista de desenvolvimento.

Pré-condição: A proposta deve estar cadastrada e com status pendente de Análise.

Pós-Condição: O detalhamento da análise foi efetuado e a proposta esta disponível para envio

ao cliente.

Cenário – consulta análise. {Principal}

1. O analista de demanda/ desenvolvimento acessa a tela de análise.

2. O sistema apresenta a tela para preenchimento das informações.

3. O analista de demanda/desenvolvimento seleciona uma proposta.

4. O sistema carrega as informações da proposta.

5. O analista de demanda/desenvolvimento opta por uma operação ou encerra.

Cenário – Incluir análise técnica

No passo 5, o analista opta por incluir uma nova análise.

5.1. O analista preenche as informações técnicas da análise.

5.2. O analista inclui os anexos necessários através do botão incluir anexo disponível na tela de

análise.

5.3. O analista seleciona uma oferta e aciona o botão para selecionar os recursos.

5.4. O sistema apresenta um quadro com os recursos disponíveis para a oferta selecionada,

ordenados pelo nível de habilidade.

5.5. O analista seleciona um recurso, e volta ao passo 5.3 se julgar necessário nova seleção.

5.6. O analista seleciona a opção concluir análise.

5.7. O sistema grava as informações para a análise selecionada, e apresenta mensagem “Deseja

definir um plano de testes para esta proposta”.

5.8. Caso o analista decida por definir um plano de testes o sistema abre a tela de definição do

plano de testes.

59

Cenário - Alterar análise técnica

No passo 5, o analista opta por alterar a análise.

5.1. O sistema verifica se análise já esta concluída.

5.2. Se a análise já estiver concluída o sistema desabilita todos os campos da tela ficando

disponível apenas para consulta.

5.3. Caso a análise ainda não tenha sido concluída, o sistema disponibiliza os campos para

alteração.

5.4. O analista altera o texto da análise e inclui/exclui os anexos da análise.

5.5. O analista seleciona a opção gravar.

5.6. O sistema grava as informações para a análise selecionada.

Cenário – Excluir análise técnica

No passo 5, o analista opta por excluir a análise técnica.

5.1. O analista seleciona a opção excluir.

5.2. O sistema checa se a análise ainda não esta concluída.

5.3. Caso a análise já tenha sido concluída o sistema informa ao analista que não será possível

exclui-la.

5.4. Caso a análise ainda não esteja concluída, o sistema solicita a confirmação de exclusão ao

analista.


5.6. O sistema exclui a análise e informa ao analista. Quadro 5 – Descrição do caso de uso Manter Análises Técnicas

No Quadro 6 apresenta-se o caso de uso “Manter Plano de Testes”.

UC11 – Manter plano de testes

Descrição: Permite ao analista de desenvolvimento Incluir Alterar ou Excluir um registro de

plano de testes.

Ator: Analista de desenvolvimento.

Pré-condição: A proposta deve estar cadastrada e o registro de análise técnica concluído.

Pós-Condição: O plano de testes foi definido e está disponível para o preenchimento do

programador.

Cenário - definição do plano de testes. {Principal}

1. O analista de desenvolvimento acessa a tela de plano de testes.

2. O sistema apresenta a tela para preenchimento das informações.

3. O analista de desenvolvimento seleciona uma proposta para definir o plano de testes.

4. O sistema carrega as informações da proposta.

5. O analista de desenvolvimento opta por uma operação ou encerra.

Cenário – Incluir plano de testes

No passo 5, o analista de desenvolvimento opta por incluir um novo plano de testes.

5.1. O analista de desenvolvimento preenche os campos de processo, condição, resultado

esperado e responsável pelo teste.

5.2. O analista de desenvolvimento seleciona a opção gravar.

5.3. O sistema grava as informações para a proposta selecionada e informa o analista.

Cenário - Alterar plano de testes

No passo 5, o analista opta por alterar o plano de testes.

5.1. O analista inclui/exclui um item do plano de testes.

60

5.2. O analista seleciona a opção gravar.

5.3. O sistema grava as informações para a proposta selecionada e informa o analista.

Cenário – Excluir plano de testes

No passo 5, o analista opta por excluir o plano de testes.

5.1. O analista seleciona excluir.


5.3. O sistema exclui a análise e informa ao analista.

Quadro 6 – Descrição do caso de uso Manter Plano de Testes

No Quadro 7 apresenta-se o caso de uso “Registrar Entrega”.

UC13 – Registrar entrega

Descrição: Permite ao programador indicar se o artefato desenvolvido já foi entregue ao cliente.

Ator: Programador.

Pré-condição: A proposta deve estar cadastrada e pendente de entrega ao cliente.

Pós-Condição: Todos os artefatos foram entregues e a proposta esta aguardando homologação do

cliente.

Cenário – preencher confirmação de entrega.

1. O programador acessa a tela de confirmação de entrega.

2. O sistema apresenta a tela e disponibiliza os filtros para pesquisa das propostas pendentes de

entrega.

3. O programador aplica o filtro para buscar as propostas que deseja entregar.

4. O sistema demonstra as propostas de acordo com o filtro selecionado.

5. O programador marca como entregue as propostas e clica em confirmar.

6. O sistema altera a proposta para aguardando homologação e atualiza a tela. Quadro 7 – Descrição do caso de uso Registrar Entrega

No Quadro 8 apresenta-se o caso de uso “Manter recurso”.

UC02 – Manter recursos

Descrição: Permite ao analista de demanda Incluir, Alterar, Excluir um recurso.

Quadro 8 – Descrição do caso de uso Manter recursos

No Quadro 9 apresenta-se o caso de uso “Visualizar propostas faturadas”.

UC03 – Visualizar propostas faturadas

Descrição: Permite ao analista de demanda visualizar o número de propostas faturadas.

Quadro 9 – Descrição do caso de uso visualizar propostas faturadas

No Quadro 10 apresenta-se o caso de uso “Visualizar propostas aprovadas”.

UC04 – Visualizar propostas aprovadas

Descrição: Permite ao analista de demanda visualizar o número de propostas aprovadas.

Quadro 10 – Descrição do caso de uso visualizar propostas aprovadas

61

No Quadro 11 apresenta-se o caso de uso “Manter ofertas de customização”.

UC05 – Manter ofertas de customização

Descrição: Permite ao analista de demanda alterar, incluir, excluir as ofertas de customização.

Quadro 11 – Descrição do caso de uso manter ofertas de customização

No Quadro 12 apresenta-se o caso de uso “Manter produtos”.

UC06 – Manter produtos

Descrição: Permite ao analista de demanda alterar, incluir, excluir o cadastro produtos.

Quadro 12 – Descrição do caso de uso manter produtos

No Quadro 13 apresenta-se o caso de uso “Manter configurações gerais”.

UC07 – Manter configurações gerais

Descrição: Permite ao analista de demanda alterar, incluir, excluir o cadastro de configurações

gerais do sistema.

Quadro 13 – Descrição do caso de uso manter configurações gerais

No Quadro 14 apresenta-se o caso de uso “Registrar aprovação”

UC08 – Registrar aprovação

Descrição: Permite ao analista de demanda efetuar o registro da aprovação da proposta de

customização. Quadro 14 – Descrição do caso de uso registrar aprovação

No Quadro 15 apresenta-se o caso de uso “Efetuar login”.

UC12 – Efetuar login

Descrição: Permite ao analista de demanda, analista de desenvolvimento e programador efetuar o

login no sistema.

Quadro 15 – Descrição do caso de uso efetuar login

No Quadro 16 apresenta-se o caso de uso “Registrar homologação”

UC14 – Registrar homologação

Descrição: Permite ao programador efetuar o registro da homologação do desenvolvimento.

Quadro 16 – Descrição do caso de uso registrar homologação

No Quadro 17 apresenta-se o caso de uso “Registrar resultados testes”.

UC15 – Registrar resultados testes

Descrição: Permite ao programador efetuar o registro dos resultados do plano de testes proposto

pelo analista.

Quadro 17 – Descrição do caso de uso registrar resultados testes

62

No Quadro 18 aprenda-se o caso de “Visualizar análises técnicas”.

UC16 – Visualizar análises técnicas

Descrição: Permite ao programador visualizar o registro de análises técnicas de customização.

Quadro 18 – Descrição do caso de uso visualizar análises técnicas

No Qquadro 19 apresenta-se o caso de uso “Visualizar previsão de faturamento”.

UC17 – Visualizar previsão de faturamento

Descrição: Permite ao analista de demanda visualizar relatório de previsão de faturamento.

Quadro 19 – Descrição do caso de uso visualizar previsão de faturamento

No Quadro 20 apresenta-se o caso de uso “Visualizar propostas aguardando

faturamento”.

UC18 – Visualizar propostas aguardando faturamento

Descrição: Permite ao analista de demanda visualizar relatório com propostas aguardando

faturamento.

Quadro 20 – Descrição do caso de uso visualizar propostas aguardando faturamento

No Quadro 21 apresenta-se o caso de uso “Manter faturamento”.

UC19 – Manter faturamento

Descrição: Permite ao analista de demanda alterar, incluir e excluir o registro de faturamento das

propostas de customização. Quadro 21 – Descrição do caso de uso manter faturamento

No Quadro 22 apresenta-se o caso de uso “Manter detalhes da proposta”.

Quadro 22 – Descrição do caso de uso Manter detalhes da proposta

No Quadro 23 apresenta-se o caso de uso “Visualizar checklist”.

UC21 – Visualizar checklist

Descrição: Permite ao programador visualizar o relatório de checklist de acompanhamento.

Quadro 23 – Descrição do caso de uso Visualizar checklist

UC20 – Manter detalhes da proposta

Descrição: Permite ao analista de demanda, alterar, incluir, excluir detalhes das propostas de

customização.

63

APÊNDICE B – Detalhamento do Dicionário de Dados

Este Apêndice apresenta a descrição do dicionário de dados conforme apresentado na

subseção 3.2.4. A identificação das chaves primária e estrangeira está representada da

seguinte forma:

a) chave primária: (PK);

b) chave estrangeira: (FK).

Os tipos de dados utilizados pelo banco de dados são:

a) int: para valores numéricos do tipo inteiro;

b) text: para valores do tipo texto longo;

c) varBinary: para valores do tipo binário;

d) nvarchar: para valores do tipo texto;

e) date: para valores do tipo data;

f) float: para valores numéricos do tipo reais.

O Quadro 24 apresenta o dicionário de dados da tabela “Analise”.

Quadro 24 - Dicionário de dados da tabela Analise

O Quadro 25 apresenta o dicionário de dados da tabela “Anexos”.

Quadro 25 - Dicionário de dados da tabela Anexos

.

O Quadro 26 apresenta o dicionário de dados da tabela “AvisoPendencias”.

Tabela: Analise

Tabela responsável por armazenar as analises efetuadas.

Campo Tipo Tamanho Obrigatório Descrição

NumPro(PK) Int 10 Sim Número Proposta

VerPro(PK) Int 10 Sim Versão proposta

idAnexo(FK) Int 10 Não Id dos anexos da análise

DetTec Text Não Detalhes técnicos da análise

Tabela: Anexos

Tabela responsável por armazenar os anexos utilizados.


IdAnexo(PK) int 10 Sim Id do anexo

SeqAnexo(PK) Int 10 Sim Sequência do anexo

BinAnexo VarBinary Não Binário do anexo

NomAnexo nvarchar 100 Não Nome do anexo

64

Quadro 26 - Dicionário de dados da tabela AvisoPendencias

O Quadro 27 apresenta o dicionário de dados da tabela “ConfigGerais”.

Quadro 27 - Dicionário de dados da tabela ConfigGerais

O Quadro 28 apresenta o dicionário de dados da tabela “Faturamento”.

Quadro 28 - Dicionário de dados da tabela Faturamento

O Quadro 29 apresenta o dicionário de dados da tabela “HabilitadesRecursos”.

Tabela: AvisoPendencias

Tabela responsável por armazenar registros de avisos de pendencias das propostas.


NumPro(PK) int 10 Sim Numero da proposta

VerPro (PK) Int 10 Sim Versão da proposta

DatEnv date Não Data de envio do e-mail

TipPen nvarchar 3 Não Tipo de pendencia

EndEma nvarchar 80 Não Endereção de e-mail enviado.

Tabela: ConfigGerais

Tabela responsável por armazenar registros das configurações gerais do sistema.


DirModProp nvarchar 500 Não Diretório modelo de proposta

VlrHorDes float Não Versão da proposta

VlrHorAna float Não Data de envio do e-mail

VlrHorQua float Não Tipo de pendência

EmailRespSis nvarchar 40 Não Endereção de e-mail do

responsável pelo Sistema.

Tabela: Faturamento

Tabela responsável por armazenar registros de faturamento das propostas.


NumPro(PK) Int 10 Sim Numero da proposta

DatFat Int 10 Não Data de faturamento

NumRat Int 10 Não Numero do RAT

HorDes Int 10 Não Horas desenvolvimento

HorAna Int 10 Não Horas análise

HorQua Int 10 Não Horas qualidade

VlrFat Int 15 Não Valor faturamento

AceGer nvarchar 1 Não Acerto gerencial

PrvFat date Não Previsão de faturamento

TipFat nvarchar 1 Não Tipo de faturamento

65

Quadro 29 - Dicionário de dados da tabela HabilitadesRecursos

O Quadro 30 apresenta o dicionário de dados da tabela “Ofertas”.

Quadro 30 - Dicionário de dados da tabela Ofertas

O Quadro 31 apresenta o dicionário de dados da tabela “PlanoTestes”.

Quadro 31 - Dicionário de dados da tabela PlanoTestes

O Quadro 32 apresenta o dicionário de dados da tabela “Produtos”.

Tabela: HabilitadesRecursos

Tabela responsável por armazenar registros Habilidades de desenvolvido de cada recurso.


CodRec(PK) Int 10 Sim Código do recurso

TipOfe (PK) Int 10 Sim Tipo de oferta

NivHab Int 10 Não Nível de habilidade

Tabela: Ofertas

Tabela responsável por armazenar registros de Ofertas oferecidas pela setor.


TipoOfe(PK) Int 10 Sim Código do Tipo de oferta

NomOfe Int 10 Não Nome da oferta

CodPrt(FK) Int 10 Não Produto o qual a oferta

pertence.

Tabela: PlanoTestes

Tabela responsável por armazenar registros do plano de testes a ser executado.



SeqPla (PK) Int 10 Sim Sequência do teste

CodRec(FK) Int 10 Sim Código do recurso responsável

ProcTeste Nvarchar 100 Não Processo do teste

CondTeste Nvarchar 100 Não Condição de teste

ResEsp Text Não Resultado esperado

ResObt Text Não Resultado obtido

TestOk Nvarchar 1 Não Teste Ok ou não Ok

66

Quadro 32 - Dicionário de dados da tabela Produtos

O Quadro 33 apresenta o dicionário de dados da tabela “Propostas”.

Quadro 33 - Dicionário de dados da tabela Propostas

O Quadro 34 apresenta o dicionário de dados da tabela “Recursos”.

Quadro 34 - Dicionário de dados da tabela Recursos

O Quadro 35 apresenta o dicionário de dados da tabela “RecursosProposta”.

Tabela: Produtos

Tabela responsável por armazenar registros dos produtos e seus responsáveis.


CodPrt(PK) Int 10 Sim Código do produto

NomPrt Nvarchar 80 Não Nome do produto

AnaDem Int 10 Não Analista demanda responsável

AnaDes Int 10 Não Analista desenvolvimento

Tabela: Propostas

Tabela responsável por armazenar registros das propostas de customizações.



TitPro Nvarchar 80 Não Titulo da proposta

DesPro text Não Detalhes da proposta

CodEmp Int 10 Não Código da empresa solicitante

RazEmp Nvarchar 60 Não Razão social empresa solicitante

CgcEmp Nvarchar 18 Não Cgc empresa solicitante

TelEmp Nvarchar 40 Não Telefone empresa solicitante

SolNom Nvarchar 40 Não Nome solicitante

SolEma Nvarchar 80 Não E-mail solicitante

CodRep Int 10 Não Código cliente representado

RazRep Nvarchar 60 Não Razão social cliente representado

TelRep Nvarchar 40 Não Telefone cliente representado

SolRep Nvarchar 40 Não Solicitante cliente representado

RepEma Nvarchar 80 Não E-mail cliente representado

CodPrt Int 10 Não Código do produto da proposta

DatAbe Date Não Data de abertura da proposta

DatApRej Date Não Data aprovação/rejeição da proposta

Tabela: Recursos

Tabela responsável por armazenar registros dos recursos/usuários.


CodRec(PK) Int 10 Sim Código do recurso

NomRec Nvarchar 60 Não Nome do recurso

UsuRec Nvarchar 40 Não Usuário do recurso

SenUsu Nvarchar 40 Não Senha do usuário do recurso

EmaRec Nvarchar 40 Não E-mail do recurso

PerRec Int Não Perfil do recurso

StaRec Int Não Status do recurso(Ativo,Inativo)

67

Quadro 35 - Dicionário de dados da tabela RecursosProposta

O Quadro 36 apresenta o dicionário de dados da tabela “VersaoPropostas”.

Quadro 36 - Dicionário de dados da tabela VersaoPropostas

Tabela: RecursosProposta

Tabela responsável por armazenar registros dos recursos alocadas no desenvolvimento.



VerPro(PK) Int 10 Sim Versão da proposta

RecPro(PK) Int 10 Sim Recurso da proposta

TipOfe (PK) Int 10 Sim Tipo de oferta

TipHor(PK) Nvarchar 1 Sim Tipo de hora

HorAlo Int 10 Não Horas alocadas

OfeEnt Nvarchar 1 Não Oferta entregue (S/N)

IniPrv Date Não Início previsto

TerPrv Date Não Término previsto

Tabela: VersaoPropostas

Tabela responsável por armazenar registros das diferentes versões da proposta.


NumPro(PK) Int 10 Sim Número da proposta

VerPro (PK) Int 10 Sim Versão da proposta

DatVen Date Não Data do vencimento da versão

StaPro Int 10 Não Status da versão da proposta

EmaProp Nvarchar 40 Não Endereço de E-mail para o qual

foi enviada a versão

ObsVer Nvarchar 100 Não Observações da versão

TextEma Nvarchar 1500 Não Texto do e-mail enviado

DatEnv Date Não Data de envio

DatSta Date Não Data do último status

SISTEMA PARA CONTROLE DO FLUXO DE...

Documents

Transcript of SISTEMA PARA CONTROLE DO FLUXO DE...