FACULDADES SPEI

CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

MPPD

CURITIBA
06/2012

LUIS HENRIQUE MATIAS
LUCAS DA CRUZ YERA BARBOSA
SOL SELENE SOIMU

MPPD

Projeto de Modelagem Física de
Sistemas apresentado ao Curso de
Análise e Desenvolvimento de
Sistemas das Faculdades SPEI.

Orientador: Rodrigo Fragoso

CURITIBA
06/2012

SUMÁRIO
1. INTRODUÇÃO................................................................................................6
2. PLANO DE PROJETO....................................................................................7
2.1 OBJETIVOS DO PLANO DE PROJETO.......................................................7
2.2 VISÃO GERAL DO PROJETO......................................................................7
2.2.1 Objetivo do Projeto.....................................................................................7
2.2.2 Custo Benefício..........................................................................................8
2.2.2.1 Custo de Desenvolvimento do Projeto....................................................8
2.2.2.2 Custo de Implantação do Projeto............................................................9
2.2.2.3 Preço do Projeto.....................................................................................9
2.2.2.4 Custo benefício para o cliente...............................................................10
2.3 ORGANIZAÇÃO DO PROJETO..................................................................11
2.3.1 Estrutura Organizacional do Projeto.........................................................11
2.4 PROCESSO DE GERENCIAMENTO DO PROJETO.................................11
2.4.1 Gerenciamento do Escopo.......................................................................11
2.4.2 Gerenciamento do Tempo........................................................................12
2.4.2.1 Cronograma...........................................................................................13
2.4.2.2 Detalhamento das Fases.......................................................................13
2.4.3 Gerenciamento de Riscos.........................................................................14
3.DESCRIÇÃO DO PROJETO..........................................................................15
3.1 OBJETIVOS DA DESCRIÇÃO DO PROJETO............................................15
3.2 DESCRIÇÃO DA SITUAÇÃO ATUAL.........................................................15
3.2.1 Descrição dos Problemas........................................................................17
3.2.2 Ambiente do Usuário...............................................................................18
3.2.3 Resumo das partes interessadas............................................................18
3.2.4 Resumo dos usuários..............................................................................18
3.3 DESCRIÇÃO DO SISTEMA PROPOSTO..................................................19
3.4 REQUISITOS DO PRODUTO....................................................................22
3.4.1 Requisitos funcionais..............................................................................22
3.4.2 Requisitos Não Funcionais.....................................................................22
4.ARQUITETURA............................................................................................22
4.1 OBJETIVOS DA ARQUITETURA..............................................................22
4.2 VISÃO FÍSICA...........................................................................................22
3

4.2.1 Descrição dos principais componentes..................................................22
4.3 SOFTWARE DE APLICAÇÃO...................................................................22
4.4 VISÃO LÓGICA.........................................................................................23
5.MODELOS DE CASOS DE USO.................................................................23
5.1 OBJETIVOS DO MODELO DE CASOS DE USO......................................23
5.2 CASOS DE USO DO SISTEMA.................................................................23
5.2.1 Diagrama de Casos de Uso....................................................................23
5.2.2 Atores......................................................................................................24
5.2.3 Casos de Uso..........................................................................................24
6.DESCRIÇÃO DOS CASOS DE USO............................................................24
6.1 OBJETIVOS DA DESCRIÇÃO DOS CASOS DE USO..............................24
6.2 CASOS DE USO DO SISTEMA.................................................................24
6.2.1 Caso de Uso Cadastrar SPD...................................................................25
6.2.2 Caso de Uso Cadastrar Card...................................................................26
6.2.3 Caso de Uso Cadastrar Cenário de Teste...............................................28
6.2.4 Caso de Uso Aprovar SPD......................................................................28
6.2.5 Caso de Uso Validar SPD.......................................................................29
6.2.6 Caso de Uso Priorizar SPD.....................................................................30
6.2.7 Caso de Uso Orçar SPD.........................................................................31
6.2.8 Caso de Uso Dúvida SPD.......................................................................32
6.2.9 Caso de Uso Responder Dúvida.............................................................33
7.MODELO RELACIONAL NORMALIZADO...................................................34
8.DICIONÁRIO DE DADOS PARA O MRN......................................................34
10. CONCLUSÃO.............................................................................................36
BIBLIOGRAFIA RECOMENDADA..................................................................37

4

..............................34 5 .............................11 FIGURA 2 – PROCESSO SITUAÇÃO ATUAL.................23 FIGURA 5 – MODELO RELACIONAL NORMALIZADO.........................................................................15 FIGURA 3 – DESCRIÇÃO SISTEMA PROPOSTO...............................20 FIGURA 4 – DIAGRAMA DE CASO DE USO......................LISTA DE ILUSTRAÇÕES FIGURA 1 – ESTRUTURA ORGANIZACIONAL ...................

............................................................................................18 TABELA 11 ..............................................................RESUMO DOS USUÁRIOS.........34 6 .............................13 TABELA 8 – RISCOS DO PROJETO ...............................................................................................................8 TABELA 3 – VALORES / HORA CARGOS ....................................9 TABELA 4 – TOTALIZAÇÃO DE CUSTOS DO PROJETO .................24 TABELA 14 ........................................................................................ 14 TABELA 9 – DESCRIÇÃO DOS PROBLEMAS.................................................9 TABELA 5 – CICLOS DE VIDA DO PROJETO ....................CONFIGURAÇÃO MÍNIMA.............................................................18 TABELA 12 ................8 TABELA 2 – HORAS TOTAIS / VALORES ..............LISTA DE TABELAS TABELA 1 – VALORES / HORA ....................13 TABELA 7 – DETALHAMENTO DAS FASES.......12 TABELA 6 – CRONOGRAMA.... 17 TABELA 10 – RESUMO DAS PARTES INTERESSADAS....................................................ATORES.......................................................23 TABELA 13 ...DICIONÁRIO DE DADOS PARA O MRN..

consiste em criar uma solução de melhoria para os processos da empresa. descrição. A utilização da documentação tem por objetivo aumentar as chances de sucesso no desenvolvimento e minimizar ao máximo os riscos e ameaças à conclusão do projeto inerentes a qualquer processo de desenvolvimento. Este documento também apresentará os requisitos funcionais e não funcionais do projeto. Sendo assim. 7 . bem como todas as informações necessárias para o projeto e implementação do sistema MPPD. controle e gerenciamento. Logo após será mostrado de forma detalhada a descrição do sistema proposto. casos de uso e diagramas da orientação a objetos. respeitando os requisitos não funcionais e os recursos que nos são ofertados para esta atividade. A proposta do Sistema MPPD. os componentes de hardware e software utilizados. Ao final deste documento. será apresentado o Plano de Projeto. do gerenciamento do tempo e riscos. os modelos de caso de uso – detalhamentos dos atores. abordando assuntos acerca do planejamento. a solução física e lógica da arquitetura do sistema. espera-se deixar de forma definida a estratégia de planejamento. os objetivos do sistema.1. com criação de sistemas auxiliares na otimização e controle do processo. a descrição do ambiente do usuário e as partes interessadas bem como suas responsabilidades. arquitetura e modelagem. Também será demonstrada a representação dos modelos físico e lógico que estruturam este projeto. INTRODUÇÃO Este documento visa demonstrar de maneira os requisitos necessários para o desenvolvimento do projeto MPPD que será apresentado como tema para o Trabalho de Conclusão de Curso do curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Faculdade SPEI. do cronograma das atividades e o custo para o desenvolvimento.

alto índice de retrabalho. separar e descrever o projeto de tal forma que durante os processos de gerenciamento. atrasos e falha na definição dos requisitos. a divisão de tarefas. hardwares e funcionários 8 . Para isso. os objetivos e os resultados esperados utilizando as melhores práticas e técnicas.1 Objetivo do Projeto O setor de PDs vem perdendo credibilidade com o cliente interno.2. como qual será o conteúdo do desenvolvimento. gerando certo desconforto no setor. 2. um processo de scruving (pavimentação de mudança de processos) foi iniciado. condições de entender o trabalho necessário para se concluir a atividade.2.2.2 VISÃO GERAL DO PROJETO 2. 2.2. os prazos estipulados. proporcione ao grupo de execução.PLANO DE PROJETO 2. análise e desenvolvimento. visando recuperar a credibilidade focando em melhorar os pontos mais críticos apontados pelo cliente interno.2 Custo Benefício Neste tópico serão apresentados os custos de desenvolvimento.1 Custo de desenvolvimento do projeto Como se trata de uma melhoria de processo que será implementada em uma empresa já existente e que já possui os softwares. a fim de aumentar os níveis de sucesso em projetos. valor total e benefícios decorrentes do projeto. custos de implantação. Estas perdas de credibilidade provêm de planejamento falho.1 OBJETIVOS DO PLANO DE PROJETO O objetivo principal do plano de projeto é organizar. 2.2.

acessado em 12/04/2012 TABELA 2 – HORAS TOTAIS / VALORES Valor Cargo Horas Totais Gerente de Projetos 100h Analista 130h Desenvolvedor Visual Hora R$ 40. O custo será avaliado encima de hora/trabalho dos analistas que trabalharão para o projeto.618.00 R$ 7.84 R$ 1.47 R$ 1.41 R$ 13.569.84 Desenvolvedor Visual Valor Mês R$ 4.especializados.84 TOTAL: Fonte: RHinfo.99 Basic R$ 12.41 Fonte: RHinfo.20 Basic 150h 2.766.00 R$ 1. TABELA 1 – VALORES / HORA Cargo Valor Hora Gerente de Projetos R$ 40.799. não haverá custos com os itens citados.2.2 Custo de implantação do projeto Como se trata de uma melhoria de processo que será implementada em uma empresa já existente e que já possui softwares. hardwares e funcionários especializados.41 Analista R$ 13.926. não haverá custos com os itens citados. TABELA 3 – VALORES / HORA CARGOS Cargo Horas Totais Valor Hora Valor Total 9 .2.20 R$ 12. O custo será avaliado encima de hora/trabalho dos analistas desenvolvedores do projeto. acessado em 12/04/2012 R$ 1.041.467.84 Valor Total R$ 4.

TABELA 4 – TOTALIZAÇÃO DE CUSTOS DO PROJETO Tipo do Custo Hardware Software Pessoas Horas Totais 0h 0h 380h Total Geral: 2.900.2. já que entende-se que a empresa já possui tais equipamentos e softwares e sua manutenção não se deve somente a esta aplicação.900.Analista de TI 8h 15. visam a recuperação de credibilidade interna da empresa. quando otimizados.2.2. Também podemos observar atualmente que esse processo falho acaba gerando muito retrabalho no setor de PDs o que aumenta o gasto com profissionais qualificados.3 Preço do projeto O custo total do projeto é obtido através da tabela 4 tendo como resultado o valor de R$ 7. o índice de retrabalho é grande pelo planejamento falho que há entre a comunicação de diversos setores da empresa GVT. Estes processos que são realizados somente dentro do âmbito da empresa.28.28 R$ 7.900. fazendo com que isso gere atrasos nas entregas das melhorias.08 R$ 124.08 2. Atualmente. acessado em 12/04/2012 R$ 124.51 TOTAL: Fonte: RHinfo. o que causa a perda de credibilidade desses clientes internos.2. As informações relativas às melhorias nos sistemas não são passadas de maneira planejada. Não estão contabilizados os custos mensais de manutenção de servidores nem aplicações. na melhoria do atendimento e ao mesmo tempo geram ganhos no momento que não existe mais o retrabalho.4 Custo benefício para o cliente Valor Total R$ R$ R$ 7. com o setor de PDS.28 O desenvolvimento deste projeto está orientado para satisfazer as necessidades do setor de PDs da empresa GVT e dos setores que dependem de seus serviços. 10 .

 Agilidade no atendimento das necessidades  Coleta e visualização dos dados em tempo real.  Redução do tempo de atendimento. Após o treinamento dos funcionários para utilização do sistema. espera-se um aumento significativo na qualidade do relacionamento dos setores da GVT com o PDs através da agilidade no atendimento.Essa integração entre os serviços procura melhorar o tempo de acesso às informações bem como diminuir o tempo para abertura e fechamento de solicitações.  Agilidade na criação e alteração das aplicações.  Aumento do índice de participação (retorno das respostas).  Rapidez na apuração dos resultados. gerando assim.1 Estrutura Organizacional do Projeto A estrutura organizacional é apresentada em um organograma.  Redução do tempo de obtenção das respostas.3. tanto do usuário do setor quanto da área de PD´s. conforme Figura 1. Aumento de produtividade e satisfação do cliente gera lucros e a proposta desse projeto é auxiliar para que isso aconteça.3 ORGANIZAÇÃO DO PROJETO Neste tópico são definidas as atividades e responsabilidades de cada integrante do projeto. Uma empresa capaz de inovar e investir em nome dos interesses dos clientes é uma empresa que tem visão de longo prazo. satisfação nos serviços prestados.  Redução do prazo de conclusão. 11 . Dessa maneira espera-se um aumento da produtividade em:  Recursos avançados de criação. 2. 2. distribuição e manutenção das informações das aplicações.

FIGURA 1 – ESTRUTURA ORGANIZACIONAL 2.2 Gerenciamento do Tempo 12 .4 PROCESSO DE GERENCIAMENTO DO PROJETO 2.4.4. 2. Apresentar como será realizado o gerenciamento do escopo do projeto.1 Gerenciamento do Escopo No gerenciamento do escopo serão determinadas as condições exatas para que o projeto seja finalizado ou completado. Deve ficar claro como será realizado o aceite dos requisitos levantados e como será o tratamento dado a mudanças de requisitos e inclusão de novos requisitos durante o ciclo de vida do projeto.

as atividades que o compõem o ciclo de vida do projeto são: a) análise e engenharia de sistemas – os requisitos iniciais serão levantados para a execução do projeto.Segundo Presman.1 Cronograma TABELA 6 .2. será definida as estruturas de dados e definidas as estruturas de controle. b) projeto – a documentação do projeto de software. irá iniciar-se a realização de testes da aplicação. e) manutenção – após a entrega da aplicação. utilizando VB como linguagem de programação. d) testes – após a geração do código. c) codificação – o projeto será transformado em um software.CRONOGRAMA Etapa Atividades 13/03/2012 a 10/04/2012 a 24/04/2012 13 .4.CICLOS DE VIDA DO PROJETO Atividade Análise e Engenharia Sistemas Projeto Codificação Testes Manutenção Fonte: Autores Recurso de Gerente Projetos Analista Desenvolvedor Analista Desenvolvedor Duração de 100hrs 100hrs 130hrs 30hrs 20hrs 2. Segue TABELA 5 com breve descrição das fases que farão parte o ciclo de vida do projeto: TABELA 5 . este pode ser melhorado ou ter seus problemas revistos.

10/04/2012 Levantamento de Requisitos Análise de Requisitos Elaboração de Proposta Validação da Proposta Alterações da Proposta Planejamento Proposta Pronta Plano de gerenciamento de tempo Luis Sol Sol Sol Lucas Lucas Lucas Lista de Eventos Especificação de Processos Modelar MRN Dicionário do MRN Validação Junto ao Cliente Alterações necessárias Desenvolvimento da aplicação em VB Desenvolvimento Alterações necessárias Lucas Lucas Lucas Lucas Design para o usuário Testes Funcionais Testes Testes Validação Correções Implantação Treinamento Distribuição da aplicação Documentação Aceite do Projeto a 10/05/2012 Luis Luis Luis Luis Sol Plano de Projeto Análise e Modelagem 24/04/2012 Sol Sol Sol Lucas Luis Luis 14 .

2. Apresentação da documentação ao cliente para validação. Terminar documentação do plano de projeto e corrigir alterações se houver. que contém a descrição das tabelas e seus campos. Especificações dos processos a serem implementados. 15 .DETALHAMENTO DAS FASES Etapa Atividades Levantamento de Requisitos Análise de Requisitos Elaboração de Proposta Validação da Proposta Alterações da Proposta Planejamento Proposta Pronta Plano de gerenciamento de tempo Plano de Projeto Lista de Eventos Especificação de Processos Análise e Modelagem Modelar MRN Dicionário do MRN Desenvolviment o Validação Junto ao Cliente Alterações necessárias Desenvolvimento da aplicação em VB Alterações necessárias Design para o usuário Testes Funcionais Testes Implantação Treinamento Testes Validação Correções Distribuição da aplicação Documentação Aceite do Projeto Detalhamento Análise e coleta de informações sobre o ambiente de trabalho do usuário. Apresentação da Proposta. Validação das informações coletadas. Distribuição da aplicação para os usuários. Elaboração da documentação do Projeto. Modelagem do banco de dados Criar o dicionário do MRN.2 Detalhamento das fases TABELA 7 . Montagem de proposta de uma aplicação para resolução dos principais problemas de controle e organização do cliente. Análise estruturada do projeto. Testes das funcionalidades da aplicação Testes da funcionalidades pelo usuário Correções e ajustes que possam ser necessários após a identificação de errors na fase de testes.2. Realização de alterações se necessário.4. Alterações necessárias na proposta. Programação da aplicação Realização de alterações se necessário. identificação das principais funcionalidades. Aceitação da Proposta Elaboração do Cronograma de trabalho. Programação do design da aplicação para visualização do usuário. Aguardar avaliação e aceite do projeto.

DESCRIÇÃO DO PROJETO 3. Grupo Redistribuir as atividades Sobrecarga de Desistência de atividades.1 OBJETIVOS DA DESCRIÇÃO DO PROJETO 16 . AÇÃO Ajustes no cronograma RESPONSÁVEL Grupo Criação de backups do projeto.3 Gerenciamento de Riscos Na TABELA 8 são descritos os riscos a que está sujeito o projeto. TABELA 8 – RISCOS DO PROJETO RISCO CONSEQUÊNCIA Falha planejamento cronograma Entregas em atraso Impossibilidade de continuar até Falhas nos correção do equipamentos problema. Grupo Considerar contingência de demorar mais que o estimado conforme conhecimento e Atraso do projeto Impacto no tempo nas atividades Grupo desenvolvimento e Desistência do falta de orientação orientador para o projeto Solicitar novo orientador Grupo 3.4.2. se possível ter backup de equipamentos. atraso integrante da equipe no projeto Desenvolvimento tempo de trabalho disponível.

Regulatório. é responsável por pequenas melhorias nos diversos sistemas da empresa GVT. avaliando e pagando pelos serviços prestados pelo setor de PDs. Segue abaixo um diagrama de atividades evidenciando como é atualmente o processo: 17 .2 DESCRIÇÃO DA SITUAÇÃO ATUAL Como citado anteriormente O setor de PDs (Pequenos Desenvolvimentos). 3. entre outros possuem diferentes sistemas em várias tecnologias. e se caracterizam como clientes internos.O Objetivo da Descrição do Projeto é apresentar a situação atual do sistema. Ambiente do Usuário. Sistema Proposto e requisitos funcionais e não funcionais. em diversos setores da empresa. onde. Atualmente os serviços do setor de PDs assemelha-se com uma fábrica de software. Financeiro. como Marketing. Vendas. porém com processos de projetos.

Este documento consiste nas informações necessárias para o desenvolvimento de um pequeno desenvolvimento cujo qual terá um benefício com baixo impacto para a empresa.FIGURA 2 – PROCESSO SITUAÇÃO ATUAL Este processo linear é muito falho. a) A elaboração do documento de SPD (Solicitação de Pequeno Desenvolvimento) é uma atividade do cliente. Este documento permite que o usuário sugira soluções para o problema. visto que não existe interação com o cliente durante o processo de desenvolvimento. Segue uma breve explicação sobre cada passo deste fluxo atual. 18 .

unidade de negócio) recebe o SPD para validação. e inicia uma breve analise técnica para que possa prosseguir em seu orçamento. ou seja. 19 . f) A implantação dos PDs. indisponibilizam o ambiente no tempo de sua aplicação. visto que a mudança de requisitos no SPD é constante.b) O líder da BU (Business Unit. cerca de 70% dos PDs atrasam ou são entregues com muita antecedência. e se o documento está compreensível. gerando retrabalho e atrasos na entrega. inicia uma série de testes funcionais no sistema. sem reuniões esporádicas e afins. Este processo possui diversas falhas. que o usuário acessa para efetuar suas atividades). d) Neste momento. sofrerá retrabalho (56% dos PDs sofrem retrabalho). caso ocorra um mau entendimento de um requisito. o analista/desenvolvedor codifica o PD. acontecem em horários determinados através de uma ferramenta chamada Jira. visto que muitos dos PDs. e muitas vezes a comunicação destas mudanças não ocorre adequadamente. para o agendamento destes. Como não existe um tempo hábil para esta atividade. sem contato com o cliente. para que este não gere impacto no ambiente de produção (ambiente final. este. Dessa maneira. verificando se todos os campos foram preenchidos. Garantia de Qualidade). para que ele repasse ao arquiteto de software. c) Com o documento validado. o arquiteto recebe este. e) O setor de QA (QualityAssurance.

tenha acesso ao sistema através de um usuário padrão (funcionário GVT). Será disponibilizada uma funcionário Retrabalho opção para inserir s ou atraso informações detalhadas.1 Descrição dos Problemas TABELA 9 – DESCRIÇÃO DOS PROBLEMAS Problema Afetado Impacto Atraso Solução ou Falta de tempo hábil para Empresa. 20 . será necessário que o usuário possua um computador. do projeto um orçamento da melhoria a ser implantada muita entrega gerência e Falta de contato com o cliente estimada. saiba trabalhar com a plataforma Windows e Microsoft Office. De uma forma macro. para fazer uso do sistema MPPD em ambiente físico. Como se trata da empresa GVT que já possui software e hardwares próprios. O que atualmente está por padrão instalado nas máquinas da empresa. 3.3.2.2.2 Ambiente do Usuário O ambiente de interação com o sistema encontra-se localmente nos computadores da empresa. somente é necessário certificar-se que a máquina possua no mínimo o pacote Microsoft Office 2003 instalado e funcionando para executar a aplicação. fazer a análise técnica e gerência e antecedência Será disponibilizada uma gerar funcionário na opção para inserir a data s Empresa.

se houver alguma mudança.RESUMO DOS USUÁRIOS Nome Descrição Administrador da Responsabilidade Fazer a manutenção dos campos da Administrador aplicação aplicação.RESUMO DAS PARTES INTERESSADAS Nome Descrição Luis Henrique Gerente de Matias Projetos Lucas da Cruz Yera Barbosa Desenvolvedor Responsabilidades Planejamento e controle do projeto. Fazer o uso da aplicação na empresa Usuário gerando melhorias.3 DESCRIÇÃO DO SISTEMA PROPOSTO 21 . Arquiteto desenvolvedor do projeto.3 Resumo das partes interessadas TABELA 10 .2. 3. Usuário 3.3. Detalhamento de Caso de uso e auxílio na sugestão de soluções para Sol Selene Soimu Analista a pavimentação e criação de novos templates de documentos.4 Resumo dos usuários TABELA 11 . Criação de Diagramas.2. atuando na linha de frente com o cliente e criação das soluções.

será feita uma descrição detalhada de cada item proposto.O MPPD é uma aplicação criada para a melhoria de um processo atualmente feito na empresa GVT. temos opção BU que serve para escolher o setor que está solicitando o pequeno desenvolvimento. destinado para passar as informações do pedido para o PDs. e qual áreas serão impactadas com a mudança. separados por tipo de acesso. existe um novo ator. Ele atuará como analista de negócio junto com o cliente. A modelagem desses processos consiste em vários sistemas e mudança de cultura tanto do cliente quanto do setor de desenvolvimento. na definição dos requisitos das demandas. possuir o Pacote Office instalado. este é o Ponto focal da BU. e gera a informação simplificada e focada para o desenvolvimento das melhorias feitas pelo setor de PDs. Em relação à situação atual. e logo passaremos para a parte de Benefícios e Impactos gerados pela solicitação. A otimização dos processos ocorrerá com o tempo de uso do projeto. Nos tópicos a seguir.  Benefícios e Impactos: Temos campos para inserir informações de como esse PD gerará benefícios para a empresa. o usuário terá de estar devidamente logado em seu computador. em quais setores.  Requisitos: Na parte de requisitos. Para poder utilizar a aplicação. receber e abrir o arquivo em Microsoft Excel da aplicação. 22 . Através de um software simples como Microsoft Excel. temos vários campos para que o usuário melhor descreva a solicitação que está sendo feita. o novo processo será mais abrangente e controlável. foi desenvolvida essa aplicação que recebe várias informações de vários setores da empresa GVT. iniciando com acesso os Dados do SPD. que diz respeito à solicitação que será realizada pelos usuários. passando posteriormente para o nível de Requisitos do SPD. Nesta nova versão de processo. os dados do solicitante e a equipe de acompanhamento que cuidará do processo dessa solicitação.  Dados do SPD : Nos dados do SPD.

23 . Segue o diagrama exibindo como será o novo fluxo do setor. serão criados sistemas necessários para controlar e validar os passos. fazendo com que todos sejam seguidos.Para automatizar o processo.

FIGURA 3 – DESCRIÇÃO SISTEMA PROPOSTO 24 .

5) A aplicação deverá mostrar uma tela de confirmação antes de apagar as informações. somente utilizando o Microsoft Excel para execução da aplicação.2 Requisitos Não Funcionais 1) O tempo de resposta não deverá ultrapassar 30 segundos.3. 25 . pelo fato de todas as máquinas já possuírem este software. 3) Durante a realização das operações. 3. 2) Comunicação através de Excel. ARQUITETURA 4.1 OBJETIVOS DA ARQUITETURA A arquitetura de um sistema de informação visa estabelecer critérios e padrões para os sistemas implantados com a finalidade de garantir seu funcionamento. o sistema deve indicar de forma visual (através do ponteiro do mouse) que está realizando o processo solicitado. 4.4 REQUISITOS DO PRODUTO 3.1 Requisitos Funcionais 1) Nem todos os setores poderão acessar links externos. na versão mínima Excel 2003. 2) Não deve ser instalado nenhum software na máquina dos usuários.4. 4) A aplicação deverá ser aberta no Microsoft Office Excel.4.2 VISÃO FÍSICA O sistema será implantado utilizando a máquina local de cada usuário. 4.

fornecer o produto Excel para todos seus funcionários. tendo a gestão de dados e a manutenção.4 VISÃO LÓGICA Por questões de segurança interna da empresa.CONFIGURAÇÃO MÍNIMA TIPO Sistema Operacional Aplicação MARCA Microsof t Microsof t DESCRIÇÃO Windows XP ou superior Microsoft Office 2003 ou superior O sistema utilizará o Microsoft Excel para gerir as regras de negócio. Todas as regras estarão dentro do arquivo. como padrão instalados o Windows XP e o Microsoft Office. facilitando a escolha da tecnologia. não foi possível a criação de um sistema web ou desktop. A razão para a escolha do Excel é devido a empresa ter conteúdo ilimitado da empresa Microsoft. devido à conexão na rede. onde muitas empresas terceiras não podem ter acesso a esse conteúdo.3 SOFTWARE DE APLICAÇÃO O computador do usuário deverá ter a configuração mínima de software descritas na tabela 10 abaixo: TABELA 12 .2.1 Descrição dos principais componentes Os componentes de hardware serão somente os computadores locais que a empresa GVT já possui. podendo assim. onde não é necessário envolver instalações de novos aplicativos nas máquinas e não será necessária a utilização de servidores para sua execução ou base de dados. 4. 4. Por isso a escolha do uso local da aplicação.4. 26 . Este arquivo terá total controle para manter as informações necessárias.

1 Diagrama de Caso de Uso FIGURA 4 – DIAGRAMA DE CASO DE USO 27 . apresentando os atores do sistema e os casos de uso que cada manipula.5. MODELO DE CASOS DE USO 5.2 CASOS DE USO DO SISTEMA 5.2. 5.1 OBJETIVOS DO MODELO DE CASOS DE USO O modelo de caso de uso é realizado para o melhor entendimento das funções desempenhadas pelo sistema que será desenvolvido.

muitas vezes junto do desenvolvedor. Manter Histórico Responsável por manter cada alteração feita no de Alterações documento Gerar uma planilha de maneira padrão.3 Casos de Uso TABELA 14 . até a sua migração para o ambiente final. Os usuários da ferramenta poderão anexar arquivos e colocar descrições deste. para orçar o PD Analista que irá codificar a atividade. e descrever as técnica alterações na ferramenta. validaManter solução la funcionalmente e tecnicamente. Envia por e-mail para a equipe de acompanhamento do Enviar e-mail PD. maneiras simples Ferramenta de administrar a ferramenta.2. Checklist de Um checklist será exibido em tela. exibindo todas as Gerar SPD informações do SPD. mostrando para os Validação usuários se o SPD está correto ou não. irá alocar os recursos para o desenvolvimento da atividade Analista com conhecimento técnico das aplicações à serem alteradas pela demanda.2. Administrar Deverá ser exposto para um analista.ATORES ATOR Cliente Líder BU Arquiteto Analista DESCRIÇÃO Usuário do sistema. para facilitar o entendimento da Anexar Arquivos solicitação.CASOS DE USO CASO DE USO DESCRIÇÃO Responsável por criar toda a regra de captura de dados Manter SPD dos formulários Manter Cards Responsável por inserir Cartões de Funcionalidade no SPD Manter Cenários Responsável por cadastrar os cenários de testes para de Teste cada Cards Responsável por manter as informações referentes à Manter atividade. informações IT prioridades e datas de entregas. Este terá de fazer uma analise. que sente necessidade de uma nova alteração ou melhoria no sistema atual É o gerente de projeto de cada equipe de desenvolvimento. onde o usuário poderá usufruir da demanda. como prazo.5.2 Atores TABELA 13 . de conhecimento do IT. 28 . sendo ela de melhoria ou manutenção 5. e para o solicitante O Arquiteto da tecnologia irá verificar a alteração.

2.1 UC001 Manter SPD 1) Breve Descrição Neste caso de uso o ator é o cliente. o cliente pode remover pessoas da Equipe de Acompanhamento.1. 10. O cliente irá inserir os dados da equipe de acompanhamento. O cliente deve clicar na guia “Benefícios e Impactos”. 3. 5. 7. O cliente pode adicionar “Benefícios”. 2. Este. onde serão adicionados os cards (Descritos em outro Caso de Uso). O cliente deve clicar em Gerar SPD. 5) Requisitos Especiais Não se aplica. 11. 29 .6. 3) Fluxos Alternativos 1. O cliente pode adicionar “Impactos”. No passo 8.1 OBJETIVOS DA DESCRIÇÃO DOS CASOS DE USO O objetivo deste item é apresentar a descrição dos casos de uso do sistema. O Sistema irá mapear os campos e inserir cada um em sua devida posição no template fina. O cliente irá clicar inserir o Título do SPD. irá inserir os dados do SPD. para que o mesmo possa prosseguir no seu fluxo padrão. 12. 3. o cliente pode remover Impactos. 8. O cliente deverá inserir os dados da BU. O cliente deverá inserir o e-mail. 6. O cliente irá clicar no botão “Gerar SPD”. o cliente pode remover Benefícios. 4. O cliente deverá ir para a Aba Requisitos. No passo 9. 6. 2) Fluxo Básico 1. O cliente deverá inserir os dados da solicitante. 4) Sub-Fluxos Não se aplica.DESCRIÇÃO DOS CASOS DE USO 6. No passo 3. 9.

6) Pré Condições O arquivo deve ser o template em branco. 30 . o sistema deve colocar todos os campos nos locais mapeados. de acordo com o template padrão final. para que não tenha outros dados impedindo o usuário de prosseguir. 7) Pós Condições Ao clicar em Gerar SPD.

3 UC003 Manter Cenários de Teste 1) Breve Descrição 31 . O cliente deve preencher o campo “Título do Requisito”.1.1. o sistema deve carregar as informações do caso de uso selecionado. 4) Sub-fluxos Não se aplica. 6. O Cliente deve preencher o campo “Por que?”.2 UC002 Manter Cards 1) Breve Descrição Neste caso de uso o ator é o cliente. 3. 3) Fluxos Alternativos 1. o cliente pode editar um Requisito já existente. para que o mesmo possa prosseguir no seu fluxo padrão. 4. O Cliente deve preencher o campo “Quem?”. 7. O usuário deve clicar no botão Salvar. O cliente deve incluir ao menos um critério de aceitação (descrito em outro caso de uso).6. 2. O cliente deve clicar em Cadastrar. 6. 6) Pré Condições O arquivo deve ser o template em branco. para que não tenha outros dados impedindo o usuário de prosseguir. O Cliente deve preencher o campo “O que?”. No passo 1. Este irá inserir os dados dos cards. 2) Fluxo Básico 1. 5) Requisitos Especiais Não se aplica. 2. O cliente clica no botão Incluir. 5. 3. Neste caso.

o usuário pode clicar no botão fechar. 32 . para que o mesmo possa prosseguir no seu fluxo padrão. O usuário deverá clicar no botão “Cadastrar”. 6) Pré Condições O usuário deverá estar no formulário de Requisitos. 5) Requisitos Especiais Não se aplica. 4) Sub-Fluxos Não se aplica. 4. 7) Pós Condições Não se aplica. 3. 3) Fluxos Alternativos 1. No passo 1. Este. e o formulário será fechado sem salvar as informações. O usuário deverá clicar no botão “Incluir”. 2) Fluxo Básico 1. e os campos de um cenário de teste antigo pode ser alterado. irá inserir os dados dos Cenários de Teste. O usuário deverá preencher o campo “Descrição”. 2. 2. o usuário pode clicar no botão Editar.Neste caso de uso o ator é o cliente. O usuário deverá preencher o campo “Título do Critério”. No passo 4.

3) Fluxos Alternativos 1. deve ser exibido a seguinte frase: “Favor rever os itens necessários do checklist” 6) Pré Condições O SPD deve estar preenchido corretamente para ser validado. No passo 4. 33 . No passo 1. 3. O checklist deve aparecer. Os itens de marcação obrigatória devem estar com um asterisco vermelho ao lado esquerdo do checkbox. o usuário pode gerar o SPD pelo menu principal. 4. com vários itens e um checkbox ao lado esquerdo de cada item. devem preencher o checklist de validação para se certificar de que o mesmo encontra-se correto. o SPD é gerado. após a edição do SPD. O usuário. toda vez que forem gerar o SPD.1. 2) Fluxo Básico 1. caso os checklists não estejam preenchidos corretamente. clica em Gerar SPD. 2. na tela de “Formulário do SPD”. Ao selecionar todos os itens obrigatórios e clicar em Gerar SPD. 7) Pós Condições Não se aplica.4 UC004 Checklist de Validação 1) Breve Descrição Os usuários. 1. fazendo com que a tela do checklist apareça normalmente.6.

3) Fluxos Alternativos Não se aplica. 34 . 2) Fluxo Básico 1. 6) Pré Condições O SPD deve estar validado para que esta priorização ocorra. 2. 7) Pós Condições Não se aplica. Na tela aberta. ele deve preencher os campos “Prioridade”. Após o preenchimento o líder deve clicar em salvar.1. 5) Requisitos Especiais Não se aplica.6.5 UC005 Manter informações IT 1) Breve Descrição O líder da BU prioriza requisitos junto do arquiteto e do cliente. “Tamanho” e “Data Pré-UAT”. 3. 4) Sub-Fluxos Não se aplica. O usuário clica no botão “Análise de IT”. e também insere informações sobre tamanho e datas de entrega.

6) Pré Condições O SPD deve estar validado para que esta priorização ocorra. 5) Requisitos Especiais Não se aplica. 7) Pós Condições Não se aplica. 35 . 3) Fluxos Alternativos Não se aplica. devem ser salvas de maneiras que possam ser visualizadas. 4) Sub-Fluxos Não se aplica. deve exibir as informações detalhadas acima. Ao clicar em uma das alterações. 3. 2) Fluxo Básico 1.1. exibe um popup com as informações das alterações. O usuário faz qualquer alteração no SPD.5 UC006 Manter Histórico de Alterações 1) Breve Descrição Todas as alterações do documento. 2. Ao clicar no botão “Alterações”.6.

3) Fluxos Alternativos Não se aplica. 7) Pós Condições Não se aplica. 2) Fluxo Básico 1.7 UC007 Gerar SPD 1) Breve Descrição Deve ser gerado o SPD obedecendo ao template estabelecido pelo cliente. 2.1.6. 36 . 4) Sub-Fluxos Não se aplica. O SPD é gerado conforme template. O usuário clica no botão Gerar SPD no menu principal. 6) Pré Condições O SPD deve estar validado para que esta priorização ocorra. 5) Requisitos Especiais Não se aplica.

7. O usuário clica no botão “Anexos”. O usuário clica no botão “. 2) Fluxo Básico 1.8 UC008 Anexar Arquivos 1) Breve Descrição Deve ser permitido o anexo de arquivos ao documento..6. 8. O usuário preenche o campo observações. O usuário seleciona o arquivo que ele deseja. 2. O usuário clica duas vezes sobre um item para abrir o anexo. 6) Pré Condições O SPD deve estar validado para que esta priorização ocorra. O usuário clica no botão “Editar SPD”. 4. O usuário clica no botão Abrir Anexos no menu principal.1. 37 . 4) Sub-Fluxos Não se aplica. 6. 2. O usuário clica no botão “anexar”. 7) Pós Condições Não se aplica. 3) Fluxos Alternativos 1. O usuário preenche o campo “Nome do anexo”. 5.. 3. 5) Requisitos Especiais Não se aplica.”. O sistema exibe uma tela de anexos.

5) Requisitos Especiais Não se aplica. O usuário clica no botão “Enviar E-mail” no menu principal. 6) Pré Condições O SPD deve estar validado para que esta priorização ocorra. 38 . de equipe de acompanhamento e destinatários. Ao clicar no botão “Enviar E-mail”. 3.1.9 UC009 Enviar Email 1) Breve Descrição O sistema deve fornecer a funcionalidade de envio de e-mail. facilitando o trafego da ferramenta. 7) Pós Condições Não se aplica. 4) Sub-Fluxos Não se aplica.6. O sistema exibe uma janela com duas listas. 2. 2) Fluxo Básico 1. é envio um e-mail automaticamente para a lista de destinatários.

1. 39 . O arquiteto clica no botão “Análise de IT” no menu principal.6. O arquiteto clica em salvar. 2) Fluxo Básico 1. O arquiteto preenche o campo de solução técnica. 6) Pré Condições O SPD deve estar validado para que este orçamento ocorra. 2. 4) Sub-Fluxos Não se aplica.7 UC010 Manter solução técnica 1) Breve Descrição O arquiteto deve fazer uma analise técnica no PD e um estudo de viabilidade para este. 7) Pós Condições Não se aplica. 3. 5) Requisitos Especiais Não se aplica.

7.DICIONÁRIO DE DADOS PARA O MRN Tabela CENARIO Campos ID_CENARIO ID_REQUISITO TITULO DESCRICAO Tabela REQUISITO Campos ID_REQUISITO TITULO Tipo integer integer varchar varchar PK Sim FK Descrição Campo que contém a identificação do cenário Campo que contém a identificação do requisito Campo que contém o título do cenário Campo que contém a descrição do cenário Tipo integer varchar PK Sim FK Tamanho Nulidade Descrição Não Nulo Campo que contém a identificação do requisito 15 Campo que contém o título do requisito Campo que contém quem esta solicitando o 15 requisito 35 Campo que contém a descrição do requisito Campo que contém o porque as solicitação do 35 requisito PK Sim FK Tamanho Nulidade Descrição Não Nulo Campo que contém a identificação do log Campo que contém a versão do log 15 Campo que contém o autor do log Campo que contém a data do log QUEM OQUE varchar varchar PORQUE Tabela LOG Campos ID_LOG VERSÃO AUTOR DATA varchar Tipo integer integer varchar date Tamanho Nulidade Não Nulo Sim 5 15 35 40 .DICIONÁRIO DE DADOS PARA O MRN TABELA 14 . MODELO RELACIONAL NORMALIZADO (MRN) FIGURA 5 – MODELO RELACIONAL NORMALIZADO 8.

DESCRICAO varchar 35 MUDANCA varchar Tabela AREA Campos Tipo ID_AREA integer DESCRIÇÃO varchar Tabela EQUIPE_ACOMPANHAMENTO Campos Tipo ID_EQUIPE integer EMAIL varchar Tabela BENEFICIOS Campos Tipo 35 Campo que contém a descrição do log Campo que contém a mudança que foi feita no log PK Sim FK Tamanho Nulidade Descrição Não Nulo Campo que contém a identificação da área 35 Campo que contém a descrição da área PK Sim FK Tamanho Nulidade Descrição Não Nulo Campo que contém a identificação da equipe 15 Campo que contém o e-mail da equipe PK FK Tamanho Nulidade FK Tamanho Nulidade Não Nulo 15 15 ID_BENEFICIO DESCRIÇÃO Tabela SPD Campos TITULO BU SOLICITANTE integer varchar Sim Tipo integer varchar varchar PK Sim EMAIL_SOLICITANTE VERSAO_ATUAL PROPRIETARIO DT_ALTERACAO varchar integer varchar date Descrição Campo que contém a identificação do Não Nulo benefício 35 Campo que contém a descrição do benefício 15 15 Descrição Campo que contém o título do SPD Campo que contém o BU Campo que contém o solicitante do SPD Campo que contém o e-mail do solicitante do SPD Campo que contém a versão atual Campo que contém o proprietário Campo que contém a data de alteração 41 .

assim como as etapas de implementação e desenvolvimento. descrição. de modo a diminuir riscos e minimizar custos de desenvolvimento. 42 . arquitetura e modelagem. Espera-se. deixar definida a estratégia de planejamento. percebeu-se o diferencial do MPPD. Durante a leitura do plano.10. a modelagem e entendimento dos casos de uso. exige planejamento e acompanhamento.CONCLUSÃO Neste documento foram apresentados aspectos fundamentais e recomendações balizadoras para a realização do projeto “MPPD”. Para atender ao fluxo de informações e as necessidades de todos os departamentos considerando os níveis de importância necessária e da adequação de infra-estrutura e a operabilidade. Foram apresentadas as sistemáticas utilizadas para execução do Plano de Projeto. da arquitetura e da análise do sistema. controle e gerenciamento. como o controle na documentação e nos processos hoje em dia é o principal foco para o sucesso empresarial. Este controle. que através do levantamento dos requisitos de software. bem como todas as informações necessárias para o projeto e implementação do sistema MPPD. Assim fica justificado o uso da análise e especificação dos processos no sistema para o seu perfeito desenvolvimento para auxiliar de forma eficaz as atividades de PDs exercidas na empresa GVT. possibilitaram documentar objetivamente o desenvolvimento. com este projeto. para a efetividade dos serviços oferecidos pelos diferentes setores da empresa.

Scruving: Pavimentação de mudança de processos SPD : Solicitação de Pequeno Desenvolvimento TI: Tecnologia da Informação 43 .LISTA DE SIGLAS Card: Cartão Checklist: Checagem da lista BU : Business Unit GVT: Global Village Telecom (GVT) é uma operadora multinacional de telecomunicações. escritor e consultor. Pressman é engenheiro de software. norteamericano.Garantia de Qualidade Presman : Roger S. Pressman & Associates. MPPD: Modelagem de Processos de Pequenos Desenvolvimentos PDs : Pequenos Desenvolvimentos QA : Quality Assurance . presidente da R.S.

S. Análise estruturada moderna/ Edward Yourdon. 1995. MAKRON Books. tradução Dalton Conde de Alencar – Rio de Janeiro: Campus. YOURDON. 44 . R.BIBLIOGRAFIA RECOMENDADA PRESMAN. Pearson Education do Brasil. Engenharia de Software. São Paulo. 1990. 3ª edição. Edward.