SUMARIO 1 Introduo ............................................................................................................................... 4 2 Referencial Teorico ................................................................................................................ 6 1.1 1.2 Processos de Software ................................................................................................. 7 Modelos de Processos de Software ..............................................................................

8 Modelo Cascata ................................................................................................. 8 Modelo de Prototipagem ................................................................................. 10 Modelo Espiral ................................................................................................ 11 Modelo Incremental ........................................................................................ 12 Processo Unificado da Rational RUP .......................................................... 13

1.2.1.1 1.2.1.2 1.2.1.3 1.2.1.4 1.2.1.5 1.3 1.4

Metodologia e Ferramentas........................................................................................ 14 Tcnicas na Coletas de Requisitos ............................................................................. 15

3 Sistema Para Controle E Manuteno De Frotas (Frotten) .................................................. 16 3.1 Instrumento Para Levantamento de Informaes ...................................................... 16

4 Requisitos Do Software ........................................................................................................ 18 4.1 4.2 Requisitos Funcionais ................................................................................................ 18 Requisitos No-Funcionais ........................................................................................ 19

5 Modelo Ambiental ................................................................................................................ 20 5.1 5.2 5.3 5.4 5.4 5.4 Objetivos do FROTTEN ............................................................................................ 20 Diagrama de Contexto ............................................................................................... 21 Lista de Eventos ......................................................................................................... 21 Documento Viso ...................................................................................................... 22 Diagrama de Caso de Uso .......................................................................................... 28 Diagrama de Classe ................................................................................................... 29

3 6 Cronograma .......................................................................................................................... 30 7 Referncias ........................................................................................................................... 31 8 Anexo ................................................................................................................................... 32

1 INTRODUO

O projeto que se segue tem por objetivo geral a construo de um software de automao comercial para gesto, controle e manuteno de frota. Para que este objetivo seja alcanado necessrio que se compreenda o funcionamento da Engenharia de Software (ES), por isso no decorrer desta pesquisa sero mostrados dados sobre a ES. A ideia desenvolver o software em uma plataforma online (conceito de Cloud Computing, ou Computao em nuvem). O sistema dever possuir funcionalidades como controle de combustvel, controle de documentos, gesto da manuteno, custo da frota e controle dos componentes. Visando uma melhor forma de desenvolvimento do sistema, um estudo mais aprofundado em ES ser necessrio para se obter conhecimento e entender os processos e etapas no desenvolvimento de um projeto como este. Sendo assim, foram coletados dados referente a conceitos de ES, Processos de Softwares, Modelos de Desenvolvimentos, Mtodos e Ferramentas de Desenvolvimento e detalhes sobre Tcnicas na Coleta de Requisitos, que sero aqui apresentados. O desenvolvimento completo do projeto ser feito em vrias etapas. Neste documento sero apresentados os objetivos gerais, os diagramas de contexto, caso de uso, e classe, a lista de eventos e o documento viso. Alm claro, de uma pesquisa terica sobre ES. Como principal base de apoio para a realizao do projeto terico e dos diagramas, temos a matria de Engenharia de Software II, que auxiliar na obteno dos conceitos e informaes necessrios no referencial terico e no modelo ambiental. A matria de Linguagens Comerciais auxilia na compreenso da importncia da linguagem escolhida para o desenvolvimento do software. Inteligncia Artificial, traz inmeros conceitos sofisticados, que nos ajudam a obter uma viso mais perfeccionista, trazendo assim benefcios no desenvolvimento de sistemas. Estrutura de Dados II ter benefcio na parte de desenvolvimento do sistema. E por fim, Banco de Dados I, que nos mostra a importncia da modelagem de banco de dados e entendimento das regras de negcio. Todas essas matrias, sero de vital importncia na construo desta e das prximas etapas deste projeto. O surgimento da ES, as necessidades que levaram a criao da mesma, os processos de software, os modelos de desenvolvimento, as metodologias e tcnicas para o

5 desenvolvimento, visando as melhorias propostas pela ES, alm das tcnicas de coleta de requisitos, so os objetivos gerais deste projetos e sero apresentados no decorrer dele. Autores conceituados e seus ensinamentos sero citados. Vale ressaltar que ES um assunto muito extenso e explicar todos os detalhes tomaria um espao tambm muito extenso, por isso o objetivo do texto dar uma viso geral do assunto.

2 REFERENCIAL TEORICO

Engenharia de Software (ES) uma rea da computao que busca dar estrutura, de forma cientfica e racional, a especificao, desenvolvimento e manuteno de sistemas de software aplicando tecnologias e mtodos da Cincia da Computao, da Gerencia de Projetos, das Engenharias e outros campos de conhecimento, visando a organizao, produtividade e qualidade. O termo ES foi utilizado oficialmente em 68 na NATO Conference on Software Engineering (Conferncia sobre Engenharia de Software da OTAN), sua criao se deu na tentativa de controlar a conhecida crise do software e dar um tratamento sistmico ao desenvolvimento de softwares complexos. Para Bauer (1969), o objetivo da ES a criao e utilizao de princpios da engenharia para obter software de maneira econmica, que seja confivel e que trabalhe eficientemente em mquinas reais. Sommerville (2007), complementa dizendo que a ES est relacionada com todos os aspectos da produo de software, dos estgios iniciais at a sua manuteno. Assim, pode se dizer que a ES tem um importante papel dentro dos ciclos de vida do projeto e do produto de software: dar melhor qualidade e produtividade ao software, baseando nos estudos de engenharia. A ES tambm tem por objetivo aplicar mtodos, tcnicas e ferramentas para o gerenciamento do processo de produo. Ela envolve o planejamento de custos e prazos, montagem da equipe, garantia de qualidade do produto e do processo, produo da documentao formal do software e dos manuais de usurios finais.
Apesar de gerentes e profissionais reconhecerem a necessidade de uma abordagem mais disciplinada para o software, eles continuam a debater a forma pela qual essa disciplina deve ser aplicada. Muitos indivduos e empresas ainda desenvolvem software ao acaso, mesmo quando constroem sistemas para servir s tecnologias mais avanadas da atualidade. Muitos profissionais e estudantes desconhecem os mtodos modernos. Em decorrncia disso, a qualidade do software que produzimos sofrvel e coisas ruins acontecem. Alm disso, continua o debate e a controvrsia sobre a verdadeira natureza da abordagem de engenharia de software. O estado atual da engenharia de software um estudo de contrastes. As atitudes mudaram, houve progresso, mas muito resta a ser feito antes que a disciplina alcance maturidade total. (PRESSMAN, 2006).

7 Pressman (2006), destaca que a ES uma tecnologia em camadas, figura 1, onde a qualidade a base e em seguida vem o processo, os mtodos e o apoio automatizado de ferramentas:

Figura 1 Modelo de Tecnologia em Camadas. Fonte: http://abre.ai/camadas

Logo, entender a ES se d de forma mais interessante quando se estuda suas camadas de Processos, Metodologia e Ferramentas.

1.1 Processos de Software

Processo de Desenvolvimento de Software, ou simplesmente Processos de Software, so conjuntos estruturados de atividades para desenvolver um software. Sommerville (2007), diz que o processo um conjunto de atividades e resultados associados que produzem um produto de software.. Jalote (2005) complementa dizendo que se estas atividades operarem corretamente e de acordo com os padres requeridos, o resultado desejado obtido. O resultado desejado por sua vez um software de qualidade e de baixo custo.
A partir destas definies podemos considerar que de forma geral um processo de software padro pode ser visto como um conjunto de atividades, mtodos, ferramentas e prticas que so utilizadas para construir um produto de software. Na definio de um processo de software devem ser consideradas as seguintes informaes: atividades a serem realizadas, recursos necessrios, artefatos requeridos e produzidos, procedimentos adotados e o modelo de ciclo de vida utilizado. (FALBO, 1998).

Pressman (2007) explica que uma linguagem de modelagem no suficiente para obter os resultados. Para ele necessrio mais que um processo de desenvolvimento. Basicamente ele mostra que linguagem de modelagem mais processo de desenvolvimento igual a mtodos de desenvolvimento. Sendo assim, o processo de desenvolvimento serve para definir quem faz o que, quando e como. Existem fases de planejamento que auxiliam nisso,

8 como a criao de relatrios iniciais de investigao, o levantamento de requisitos, dentre outas. 1.2 Modelos de Processos de Software

Uma vez que os objetivos principais da ES so a produo de software de qualidade e de baixo custo, foram definidos modelos de desenvolvimentos para auxiliar na busca desses objetivos. Modelos so representaes dos processos de desenvolvimento, nele definido como as etapas relativas ao desenvolvimento do software sero conduzidas e inter-relacionadas para que o objetivo seja alcanado. Existem diversos modelos de desenvolvimento, alguns mais antigos, outros mais inovadores. Para escolher o modelo ideal necessrio entender a natureza do projeto e da aplicao, os mtodos e ferramentas utilizados, alm de outros pontos importantes. Aqui sero abordados apenas os modelos mais conhecidos, so eles: Cascata (Waterfall) Prototipagem (Evolutivo) Espiral (Spiral) Incremental Processo Unificado da Rational (Rational Unified Process RUP)

1.2.1.1 Modelo Cascata

o modelo mais antigo e mais utilizado na ES, foi idealizado por Royce em 1970 e tambm conhecido como Top-down (de cima para baixo, em traduo livre). Nele as etapas de desenvolvimento seguem rigorosamente uma sequncia. As atividades a executar so agrupadas em tarefas, de forma que uma tarefa s se inicia quando a anterior a ela tenha sido concluda. At meados dos anos 80, era o nico modelo que possua uma aceitao geral. indicado para sistemas onde a segurana e a confiabilidade so de grande importncia.

Figura 2 Modelo Cascata. Fonte: http://abre.ai/cascata

As fases deste modelo so, como mostrados na figura 2, a anlise de requisitos, onde so definidos os objetivos do software atravs do levantamento feito com o cliente. Essa etapa deve ser feita com o mximo de detalhes visando a posteridade do desenvolvimento, uma vez que nesse modelo no permitido voltar a uma etapa anterior. O segundo ponto o projeto, nele os requisitos so divididos em sistemas de hardware e de software. O terceiro, a implementao, a codificao do software em uma linguagem executvel. No quarto ponto ocorrem os testes, que analisam os aspectos lgicos internos do software, e os aspectos funcionais externos, para saber se o resultado dos processamentos de entrada, so as sadas esperadas. O software ento entregue ao cliente, e o ltimo ponto sobre as eventuais mudanas que ocorreram depois de o software ter sido entregue ao cliente. Dentre os pontos fortes do modelo cascata, pode-se citar o fato de ter uma abordagem muito disciplinada. Porm o modelo tem muitos pontos fracos como a dificuldade em acomodar mudanas, a partio inflexvel do projeto em estgios diferentes, dentre outros.

10 1.2.1.2 Modelo de Prototipagem

Modelo de prototipagem, ou modelo evolutivo, tem o objetivo de simular a aparncia e as funcionalidades de um projeto de software. Pode se fazer uma aluso a uma verso inicial de um software que possibilita o desenvolvedor conhecer os problemas e as solues para os mesmos. Pressman (2006) define o modelo de prototipao como um processo que capacita o desenvolvedor a criar um modelo de software que ser implementado..

Figura 3 Modelo de Prototipagem. Fonte: http://abre.ai/prototipagem

A partir da definio de Pressman e da anlise da figura 3, possvel entender que o modelo de prototipagem aproxima o cliente do desenvolvedor, uma vez que o cliente analisar cada prottipo acabado, se estiver tudo certo, o desenvolvedor d segmento ao projeto, caso contrrio, novas correes testes so feitos. Segundo Pfleeger (2004) o desenvolvimento do sistema pode comear como um conjunto simples de requisitos fornecidos pelos cliente e usurios. Ento, as alternativas so exploradas. Examinam-se as telas, tabelas, relatrios e outras sadas do sistema, diretamente

11 utilizadas pelos clientes e usurios. Assim que os usurios e clientes decidem o que realmente querem, os requisitos so revisados. Uma vez que haja consenso de como deveriam ser os requisitos, o desenvolvedor se volta para as atividades de requisitos, a fim de reconsiderar e alterar a especificao. Finalmente, o sistema codificado, e as alternativas, discutidas, de novo com uma possvel iterao entre requisitos e projeto. Pfleeger diz tambm que as vantagens desse tipo de modelo se aplicam em sistemas de grandes portes, onde a obteno dos requisitos so complexas, pequenas verses do que sero o projeto final podero ser usadas pelo cliente, reduo de custos na posteridade, dentre outras vantagens. O autor tambm cita que a utilizao deste modelo tambm possui desvantagens, como por exemplo o fato de que a prototipao pode ser utilizada apenas quando o usurio participa ativamente do projeto, ou o fato de o cliente achar que o desempenho do prottipo ser o mesmo que o da verso final, fazendo com que o cliente se desanime do software.

1.2.1.3 Modelo Espiral

Este modelo foi proposto por Bohm em 1988 integrando os diversos modelos que existiam na poca. Foram eliminadas as dificuldades e explorados os pontos fortes, utilizando-se das melhores caractersticas dos modelos de cascata e prototipagem, e adicionado um novo recuso: anlise de riscos.

Figura 4 Modelo Espiral. Fonte: http://abre.ai/espiral

12 Entretanto o modelo em espiral no simplesmente a integrao das caractersticas dos outros modelos, Bohm diz que ele tambm tem uma abordagem diferente. Nele o processo de desenvolvimento ocorre em ciclos, e cada ciclo possui fases de avaliao e planejamento. O autor cita que o modelo organiza o desenvolvimento como um processo iterativo de 4 fases, onde o conjunto dessas fases executado at que o sistema final esteja pronto. Um ciclo se inicia com a determinao de objetivos, alternativas e restries (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratgia para alcanar os objetivos. Na segunda tarefa, anlise e avaliao de alternativas, identificao e soluo de riscos, executa-se uma anlise de risco. Prototipao um bom modelo para tratar riscos. Se o risco for considerado inaceitvel, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto avaliado e se prepara para iniciar um novo ciclo. Uma vantagem deste modelo seria por exemplo o fato de que a cada iterao se obtenha verses do sistemas cada vez mais completas. Uma desvantagem deste modelo a possibilidade de convencer grandes clientes que a abordagem evolutiva controlvel.

1.2.1.4 Modelo Incremental

Este modelo considerado uma extenso do modelo espiral, s que abordado de forma mais rigorosa e formal. Considerando o fato de que o desenvolvimento de um software uma tarefa que pode perdurar por meses ou at um ano ou mais, o mais vivel seria dividir o trabalho em partes menores, ou iteraes, e cada iterao seria um incremento. exatamente para isso que existe o modelo incremental, as iteraes so os passos para dar andamento ao trabalho e o incremento o crescimento do produto final, no caso o software. O princpio desse modelo que a cada iterao possa se ter uma viso do andamento do projeto. interessante notar que a cada iterao so realizadas tarefas, como ser mostrado na figura 5. As tarefas so analise, onde se fara o refinamento dos requisitos, projeto, onde se fara o refinamento do projeto arquitetural, codificao, onde ser implemento o software, testes, onde se analisar os erros e a implantao e entrega do incremento atual. Esse modelo tem como vantagens a possibilidade de avaliar mais cedo os riscos e pontos crticos do projeto, a reduo de riscos envolvendo custos com um nico incremento, dentre outras vantagens.

13

Figura 5 Modelo Incremental. Fonte: http://abre.ai/incremental

1.2.1.5 Processo Unificado da Rational RUP

Criado para dar apoio ao desenvolvimento orientado a objeto, o Processo Unificado da Rational Software Corporation, ou RUP (Rational Unified Process), fornece uma forma sistemtica para se obter vantagens no uso da UML (Unified Modeling Language).
O principal objetivo do RUP atender as necessidades dos usurios garantindo uma produo de software de alta qualidade que cumpra um cronograma e um oramento previsveis. Assim, o RUP mostra como o sistema ser construdo na fase de implementao, gerando o modelo do projeto e, opcionalmente, o modelo de anlise que utilizado para garantir a robustez. O RUP define perfeitamente quem responsvel pelo que, como as coisas devero ser feitas e quando devem ser realizadas, descrevendo todas as metas de desenvolvimento especificamente para que sejam alcanadas.. (MARTINEZ, 2010)

Com este modelo, o desenvolvimento de software organizado em 4 fases, como ser mostrado na figura 6. Nessas fases so tratadas questes sobre planejamento, levantamento de requisitos, anlise, implementao, teste e implantao do software. Essas fases so muito importantes para o objetivo final e so distribudas entre vrios profissionais como o Analista de Sistemas, o Projetista de Testes, dentre outros.

14

Figura 6 RUP. Fonte: http://abre.ai/rup

A fase de iniciao se d na comunicao com o cliente, o esclarecimento dos riscos do projeto, o levantamento inicial de requisitos, dentre outras tarefas. A fase de elaborao a parte da modelagem do modelo genrico do processo, nesta fase se revisa os riscos que o projeto poder ter, dentre outras tarefas. A fase de construo e a fase de desenvolvimento do software, nessa fase que ocorre a codificao. E por fim a fase de transio engloba a entrega do software ao cliente e a fase de testes.

1.3 Metodologia e Ferramentas

Em ES, temos duas principais metodologias. A Metodologia Estruturada, que abrange vrios mtodos como Anlise Estruturada, Projeto Estruturado, Programao Estruturada, dentre outros. E a Metodologia Orientada Objetos, que abrange mtodos como Orientao a Objetos, RUP, Desenvolvimento gil de software, Scrum, Programao extrema (XP), dentre outros. A ES aborda vrias tecnologias e prticas, que so estudas em Cincia da Computao. Dentre elas, destacam-se as linguagens de programao, banco de dados e paradigmas de programao. Quanto as ferramentas vale lembrar o uso das ferramentas CASE (Computer-Aided Software Engineering), as IDEs so poderosas nesse sentindo, pois formam o ambiente de desenvolvimento completo.

15 1.4 Tcnicas na Coletas de Requisitos Requisitos so a condio ou capacidade que precisa ser atingida por um sistema para satisfazer um contrato, norma, especificao ou algum outro documento. (IEEE standard). Logo o primeiro passo no desenvolvimento de um software o levantamento de

requisitos. Esse ponto de suma importncia para o sucesso ou insucesso do projeto no futuro, e tambm, segundo Sommerville (2007) um dos fatores que se feitos de forma errada aumentam muito o custo do projeto, ento deve ser realizado da melhor forma possvel e para isso existem tipos de coletas que podem facilitar nesse processo, como a Entrevista, Questionrio, Observao Pessoal, Seminrio, dentre outros.
A entrevista uma tcnica simples e direta, com questes livres de contexto e pode ser aplicada com questionrios. A entrevista deve ser bem preparada, o entrevistador deve ser paciente e respeitar o conhecimento do entrevistado, alm de saber entrevistar as pessoas certas. Uma das vantagens dessa tcnica a obteno de informaes mais precisas e detalhadas, uma desvantagem e o consumo de mais tempo e recursos para a realizao. (SOMMERVILLE, 2007)

O autor ainda diz que o questionrio normalmente preparado em formulrio para levantamento das informaes desejadas e pode ser distribudo e recolhido posteriormente. Vale lembrar que o questionrio no substitui a entrevista. Uma das vantagens do questionrio a maior agilidade no processo, uma das desvantagens que a informao pode ser manipulada. Na observao pessoal, o autor completa que o observador deve vivenciar a situao abordada no interferindo no trabalho observado, com essa tcnica possvel identificar problemas, restries impostas pelo ambiente, recebimento da informao, dentre outras coisas. Uma das vantagens da observao pessoal a no interrupo das atividades da empresa, e uma desvantagem a falta de evidncias formais. O seminrio uma reunio planejada com o intuito de obter informaes gerais da empresa, tambm conhecido como dinmica de grupo e deve ser planejado pelo condutor do seminrio para passar confiana. Uma das vantagens a identificao de problemas de interrelacionamentos e uma desvantagem possibilidade de interferncia na rotina da empresa, por mover as pessoas para o seminrio. Existem outras tcnicas de coleta de requisitos, porm so menos utilizadas que as que aqui foram citadas. Em suma, a tcnica usada de estrema importncia para a coleta das informaes, ela deve ser analisada de acordo com cada projeto, pois uma tcnica pode se adequar melhor que outra dependo de vrios fatores.

16

3 SISTEMA PARA CONTROLE E MANUTENO DE FROTAS (FROTTEN)

3.1 Instrumento Para Levantamento de Informaes Para que os requisitos fossem colhidos, a presente pesquisa se baseou na entrevista como instrumento de coleta de dados. A empresa Transportes LTDA, concedeu informaes acerca do sistema utilizado e do trabalho realizado na transportadora. O funcionrio, Sr. Rafael Marques, gerente na citada empresa, foi quem concedeu esta entrevista. Segundo o entrevistado, a empresa j trabalha com um sistema. Eles utilizam um ERP (Enterprise Resource Planning), na plataforma desktop. O Sr Rafael disse que apesar de o sistema utilizado oferecer todo o suporte que a empresa atualmente necessita, ele possui um custo alto e no de fcil aprendizado, sendo necessrio um treinamento profundo para que se conhea bem as funcionalidades. Na entrevista, o Sr Rafael tambm citou quais funcionalidades ele acha essencial em um sistema de informao. De acordo com ele, necessrio hoje na empresa, que se possa visualizar as informaes com mais mobilidade, o que sistemas desktops praticamente no possuem. Para ele, se algumas informaes como a rota do motorista, relatrios diversos e cadastros, pudessem ser visualizados atravs de smartphones e tablets, facilitaria muito os servios realizados na organizao. Ele completou dizendo que o ideal que o sistema tambm seja de fcil iterao, dispensando treinamentos avanados. Quando questionado sobre o que acharia de um sistema web, que pudesse ser acessado de qualquer lugar, pela internet, ou somente dentro da empresa, pela intranet, o Sr Rafael disse que exatamente o que, para ele, necessrio na empresa no atual momento. Por entender um pouco sobre o assunto, ele comentou tambm que o atual sistema requer uma mquina mais potente, o que gerou um custo na aquisio do sistema, visto que todos os computadores da empresa tiveram que ser trocados. Depois de compreender o funcionamento de uma aplicao web, o entrevistado disse o quanto seria produtivo para a empresa esse tipo de sistema, uma vez que os funcionrios pudessem, mesmo de casa, acessar o sistema e trabalhar normalmente, e sem muitas complicaes, visto que aplicaes web requerem apenas, na maioria dos casos, acesso internet e um browser, desconsiderando por exemplo, o sistema operacional que o usurio utiliza.

17 No fim da entrevista, o Sr Rafael falou sobre a importncia dos Sistemas de Informaes nas organizaes. De acordo com ele, a tecnologia permitiu o crescimento da empresa, e que sem ela no seria possvel ter crescido tanto. Ele terminou dizendo que pretende, em um futuro prximo trabalhar com sistema web, pois sabe o quanto a internet promissora.

18

4 REQUISITOS DO SOFTWARE

4.1 Requisitos Funcionais O sistema dever possuir os seguintes cadastros o o o o Colaboradores; Veculos; Funcionrios/Usurios; Motorista

Ser possvel a adio, alterao ou excluso, de qualquer cadastro, pelo administrador do sistema; O sistema possibilitar a consulta sobre estes cadastros. Dados ativos e inativos, tambm podero ser consultados, alterados ou excludos. Pelo sistema, ser possvel tambm manipular as reservas; O sistema dever possuir controle de: o o o Servios prestados pela transportadora; Agendamentos; Centro de custos.

Dever tambm controlar histricos, emitindo relatrios de: o o o o o o Abastecimento; Manuteno; Multas; Renovao de habilitao; Troca de pneus e leos; Motorista com boa conduta;

O sistema dever possuir a exportao de arquivos fiscais como: o Conhecimento de transporte eletrnico CT-e; o Documento auxiliar do conhecimento de transporte DACTE.

Dever possuir restries a rotinas, com senhas para os usurios; O sistema devera aceitar sadas nos diversos meios de pagamentos: vista, no cheque ou carto de credito;

19 4.2 Requisitos No-Funcionais Desenvolvido em Java com interface em HTML 5 e Banco de Dados MySQL; Servidor com processador de 1GHz ou superior e memria RAM de 512MB ou superior; Suporte a browser Mozilla Firefox 3.5 ou superior, Internet Explorer 9 ou superior, Google Chrome, Sfari e Opera; Controle ao acesso as rotinas, com senha para os usurios cadastrados. Cadastro no sistema para poder acessar;

20

5 - MODELO AMBIENTAL

5.1 Objetivos do FROTTEN Visando auxiliar no processo de controle e gerenciamento de frotas, o FROTTEN, um sistema de gesto empresarial para transportadoras, tem como objetivo facilitar os servios oferecidos por esse tipo de organizao, bem como diminuiu o retrabalho que as planilhas eletrnicas causam. Com relatrios e informaes sobre os veculos e motoristas, a tomada de deciso se tornar mais gil e segura, por isso, o FROTTEN deve possuir uma gama variada de relatrios e informaes a serem visualizadas pelos gestores de ode tiverem, uma vez que a ideia a construo de uma aplicao web. Pelo sistema ser possvel fazer agendamentos, reservas, bem como monitorar os servios prestados pela transportadora. Sendo assim, o FROTTEN, deve fazer o que os Sistemas de Informaes tem como principal objetivo: trazer informaes em tempo hbil e confiveis. Para um futuro prximo, a ideia levar o FROTTEN tambm para os aparelhos mobiles. Smartphones e tablets podero acessar algumas rotinas, bem como acompanhar relatrios, informaes e dados, que facilitam o trabalho usando a mobilidade.

21 5.2 Diagrama de Contexto

Figura 7 Diagrama de Contexto: Sistema FROTTEN. Fonte: prpria

5.3 Lista de Eventos FROTTEN recebe dados do usurio; Usurio cadastrado; FROTTEN recebe os dados do motorista; Motorista cadastrado; FROTTEN recebe dados do veculo; Veculo cadastrado; O FROTTEN recebe uma ordem de servio; Veculo reservado;

22 O motorista faz check-in no sistema com as informaes necessrias; Veculo utilizado; Conhecimento de transporte emitido; CT-e emitido; Relatrios sobre o veculo gerado; Relatrios sobre o motorista gerado.

5.4 Documento Viso 5.4.1 Introduo Este documento tem como propsito apresentar as funcionalidades, as principais caractersticas e os requisitos de alto-nvel do Sistema Frotten, um sistema para gesto, controle e manuteno de frotas. Detalhes e objetivos do sistema sero apresentados no decorrer deste texto, de forma que qualquer pessoa possa compreender.

5.4.2 Escopo A ideia desenvolver o software em uma plataforma online, que possa ser acessado de qualquer lugar pela internet, ou somente na empresa, por meio da intranet. O software dever conter as seguintes funcionalidades: Cadastro de: o Usurios; o Fornecedores; o Clientes; o Veculos; o Motoristas. Controle de: o Veculos; o Peas; o Servios prestados; o Agendamentos; o Centro de custo. Emisso de relatrios de: o Abastecimento;

23 o Multas; o Renovao de habilitao; o Manuteno dos veculos. Exportao de arquivos fiscais como: o Conhecimento de transporte eletrnico CT-e; o Documento auxiliar do conhecimento de transporte.

5.4.3 Definies Acrnimos e Abreviaturas Intranet CT-e Software LTDA MySQL Frotten Java HTML5 uma rede de computadores privada de uso exclusivo de um determinado local que s pode ser acessada por seus usurios internos. Modelo nacional de documento fiscal eletrnico que venha substituir a sistemtica atual de emisso de documentos fiscais em papel. uma sequncia de instrues escritas para serem interpretadas por um computador com o objetivo de executar tarefas especficas a sigla para limitada, e refere-se a um tipo de sociedade empresarial, organizada por quotas, onde cada um possui uma responsabilidade limitada. Sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL. Sistema de Gesto de Frota Linguagem de programao orientada a objeto desenvolvida na dcada de 90 pela Sun Microsystems. Linguagem para estruturao e apresentao de contedo para a World Wide Web e uma tecnologia chave da Internet originalmente proposto por Opera Software. Sistema Operacional mais popular do mundo criado pela Microsoft.

Windows

5.4.4.Referncias A ideia de desenvolver um software, que alm de controlar a frota, auxiliasse na gesto da mesma, surgiu do professor Bruno Souto Borges, que atualmente leciona a matria Estrutura de Dados no Instituto Luterano de Ensino Superior de Itumbiara, ILES/Ulbra. O professor e orientador do projeto mostrou a ideia e explicou seu ponto de vista acerca do controle de frotas. A partir de ento, pesquisas e estudos sobre o tema possibilitaram a realizao de um trabalho terico e, agora, o desenvolvimento do documento viso. Para desenvolver o referencial terico do projeto, autores como Pressman, Sommerville e Martinez foram fundamentais. Suas obras foram de crucial importncia para a fundamentao terica deste projeto.

24 5.4.5 Posicionamento 5.4.5.1 Oportunidade de negcio O ramo das transportadoras um segmento de crucial importncia em diversas reas que movimentam a economia, no s no Brasil, como no mundo. Segundo a ANTT (Agencia Nacional de Transportes Terrestres), existem cerca de 130 mil empresas de transportes registradas no pais. Pensando nisso, a ideia de desenvolver um sistema que auxilie no controle, gesto e manuteno de frotas, vai alm do desafio, se tornando uma oportunidade de negcio. O Frotten possuir as funcionalidades necessrias para quem uma empresa de transportes opere com mais tranquilidade e segurana que os sistemas de informao oferecem.

5.4.5.2 Descrio do Problema: O Problema Afeta SISTEMA SEM RELATRIOS A tomada de deciso; O controle da manuteno Avaliao do custo/benefcio do veculo. Falta de informao para tomar decises; Aumento nos gastos com manuteno; Veculos gerando mais gastos que receita. Utilizar as informaes da base de dados do sistema de informao na gerao de relatrios que auxiliem o dia-a-dia da transportadora.

Os Impactos So

Uma Soluo

5.4.6 Descries de Stakeholder e Usurios 5.4.6.1. Stakeholders O mercado alvo deste sistema so pequenas e mdias empresas de transporte, ou empresas que possuem sua prpria frota de veculos, e que se atentam as novidades tecnolgicas usufruindo dos inmeros benefcios que os sistemas de informao trazem para as organizaes. Os desenvolvedores e integrantes do projeto tambm so stakeholders, visto que so idealizadores e faro com que este projete se desenvolva.

25 5.4.6.2. Usurios Envolvido Empresas de Transportes Descrio Stakeholder Responsabilidade Estabelecer os requisitos; Verificar a aceitao do escopo do projeto. Fornecer apoio e informaes que auxiliem na construo do projeto e do software. Definir o escopo do projeto; Distribuir e coordenar as atividades; Controlar o cronograma do projeto; Escrever o documento viso.

Bruno Souto/Fabio Palhares

Professores e Orientadores Integrantes do Projeto

Bruno/Marco/Pablo/Raphael

5.4.7 Observao Sistema ser desenvolvido com linguagens contemporneas para adequao a um mercado em constante atualizao e novos requisitos. Tudo o que o usurio necessita para utilizar o sistema acesso internet e um navegador. Fazendo com que o usurio no se prenda a um determinado sistema operacional simplesmente porque seu software no multi-plataforma.

5.4.8 Mdulos CADASTRO Neste mdulo ser abordado o cadastramento de Usurios; Fornecedores; Clientes; Veculos e Motoristas. A fim de manter-se atualizado acerca dos dados pessoais de interesse para a empresa system Frotten poder obter uma melhor gesto. Tais dados como nome; telefone; endereo; placa; chassi; check-in; check-out. CONTROLE Este mdulo visa a gesto dos veculos; peas; servios prestados; agendamentos e centro de custo a fim de manter uma sistemtica no controle e uso dos servios essenciais para a empresa system Frotten. RELATRIOS Neste mdulo o sistema ir gerar relatrios gerenciais para apoio na tomada de deciso da Gesto. FISCAL Parte do sistema onde ir gerir impostos municipais, estaduais e federais, bem como a parametrizao de suas respectivas alquotas.

26 5.4.9 Precedncia e Prioridades Para a construo dos mdulos temos as seguintes prioridades de desenvolvimento: Prioridade 1 Cadastros (Usurios, Clientes, Veculos, etc) Prioridade 2 Controle da Frota (Pneus, Abastecimento, Troca de Peas, etc) Prioridade 3 Relatrios de Apoio (Manuteno, Renovao de CNH, etc) Prioridade 4 Fiscal (Emisso de CT-e e DACTE)

A prioridade dos mdulos ser da mesma ordem de procedncia para o desenvolvimento por concluirmos que a fase de prototipagem ser mais bem desenvolvida.

5.4.10 Requisitos No Funcionais Requisito do produto a interface de usurio para o sistema deve ser implementada em Java e HTML5. Requisito organizacional o processo de desenvolvimento do sistema e documentos a serem entregues devem estar em conformidade com a UML. Requisito privacidade o sistema no deve revelar nenhuma informao pessoal sobre os usurios do sistema a outros usurios. Requisito de espao o banco de dados no dever ultrapassar a quantidade de registros especificados pelo Sistema Gerenciador de Banco de Dados. Requisito de espao o banco de dados no dever ultrapassar o tamanho de 25GB de armazenamento em HD. Requisito do processo o desenvolvimento do sistema dever utilizar uma ferramenta CASE de modelagem de negcios.

5.4.11 Requisitos de Sistema e Ambientes 5.4.11.1 Sistema Operacional Multi-plataforma.

5.4.11.2 Linguagens de Desenvolvimento A linguagem de desenvolvimento ser Java e HTML5.

27 5.4.11.3 Banco de Dados O SGBD utilizado ser o MySQL, por ser de cdigo aberto, sem custos, suporte a 64bits e multi-plataforma.

5.4.12 Requisitos de Documentao Diagrama de atividades; Diagrama de classes; Diagrama de caso de uso; Relatrios de teste; Manual de instalao; Manual de utilizao;

5.4.13 Viso Geral UML do Sistema - Modelo Conceitual

Figura 8 UML: Sistema FROTTEN. Fonte: prpria

28 5.5 Diagrama de Caso de Uso

Figura 9 Diagrama de Caso de Uso: Sistema FROTTEN. Fonte: prpria

29 5.6 DIAGRAMA DE CLASSE

30

6 CRONOGRAMA

Atividades

Meses Semanas 1

Abril 2 3

Maio 1 2 3

Diagrama de Caso de Uso Pesquisa sobre Diagrama de Classe Desenvolvimento do Diagrama Concluso do Projeto

31

7 REFERENCIAS

FALBO, Ricardo A. Integrao de Conhecimento em um Ambiente de Desenvolvimento de Software. 1998. Tese Doutorado Universidade Federal do Rio de Janeiro, COPPE/UFRJ, Rio de Janeiro, 1998. MARTINEZ, Marina. RUP. Disponvel em: http://www.infoescola.com/engenharia-desoftware/rup/ Acessado em 07 de setembro de 2012 as 22:18. NEGRAO, Eduardo. Engenharia de Software. Disponvel em: http://www.portalarquiteto.com.br/afinal-o-que-e-engenharia-de-software/ Acessado em: 07 de setembro de 2012 as 16:11. PDUA FILHO, Wilson. Engenharia de Software: Fundamentos, Mtodos e Padres. 2003. PRESSMAN, Roger. Engenharia de software. Porto Alegre. Makron Books, 1995. SASS, Glaucia Gabiel. O Processo de Desenvolvimento Baseado em Componentes: O impulso das novas tecnologias. Disponvel em: http://www.administradores.com.br/colunas_membro.jsp?idColuna=233&idColunista=555 Acessado em 07 de setembro de 2012 as 17:11. SOMMERVILLE, Ian. Engenharia de software. 8ed. So Paulo. Pearson Education, 2007. _______, Andrez C. Anlise de Requisitos. Disponvel em: http://wwwusr.inf.ufsm.br/~andrezc/bd/analise_requisitos.pdf Acesso em 07 de setembro de 2012 as 21:36.

32

8 - ANEXO EMPRESA: TRANSPORTES LTDA ENTREVISTADO: RAFAEL MARQUES CARGO: GERENTE QUESTIONRIO DA ENTREVISTA: 1. O atual sistema de controle de frotas da empresa : (X) Desktop ( ) Web ( ) No possui 2. O sistema possui quais cadastros? ( ) Clientes ( ) Funcionrios ( ) Fornecedores ( ) Veculos ( ) Produtos (X) Todas alternativas 3. Quais dados so requeridos no cadastro de motoristas? ( ) Nome ( ) RG ( ) Endereo ( ) CPF ( ) Telefone (X) Todas alternativas 4. Como identificado o veculo no sistema? ( ) Marca ( ) Cdigo ( ) Nome (X) Todas alternativas ( ) Categoria 5. O software dever ter restries de usurios nas diferentes reas funcionais da empresa? (X) Sim ( ) No, mas pretende 6. Como feito o controle de combustvel? ( ) Registrado em planilhas (X) O controle feito pelo prprio usurio no atual sistema ( ) Outra maneira 7. So emitidos relatrios de abastecimento? ( ) Sim ( ) No (X) No, mas pretende 8. utilizado ordens de servio?

33 (X) Sim ( ) No ( ) No, mas pretende

9. A empresa se utiliza de algum mrito para o funcionrio de boa conduta no volante? ( ) Sim ( ) No (X) No, mas pretende 10. Existe plano de manuteno? (X) Sim ( ) No ( ) No, mas pretende 11. O atual sistema controla a quilometragem dos veculos? (X) Sim ( ) No ( ) No, mas pretende 12. O sistema emite documentos fiscais? Quais? ( ) NF-e ( ) CT-e (X) Todas alternativas 13. Possui rastreamento via satlite? (X) Sim ( ) No ( ) No, mas pretende 14. Quanto ao abastecimento? ( ) Acontecer na empresa (X) Em Auto Posto 15. A manuteno ser feita na empresa ou terceirizado? ( ) Na empresa ( ) Terceirizado (X) Todas alternativas