ausbildung formação mündl.prüfung prova final oral 2009-2010 2011 REPORT ZUR FACHAUFGABE RELATÓRIO DA TAREFA fach formação Ο Informatikkaufmann Gestão de Informática thema der aufgabe Sistema de Controle de Despesas de Viagens Internacional tema da tarefa name des prüflings Henrique Kolling Limberger nome do candidato e-mail (gültig 2011) e-mail (válido 2011) rique.limberger@gmail.com telefone (válido 2011) (47) 9643-7112 ausbildungsbetrieb sede da aprendizagem T-Systems do Brasil Ltda tutor Marco Aurélio da Silva Pereira e-mail tutormarco.pereira@t-systems.com.br Persönliche Erklärung zur Fachaufgabe und zum Report Ich versichere durch meine Unterschrift, dass ich die Fachaufgabe im Einsatzgebiet und den Report selbstständig erarbeitet habe. Im Report verdeutliche ich, was genau mein persönlicher Anteil erbrachter Leistungen und gegebener Informationen ist. Ich habe sämtliche Texte, Bilder und Grafiken sowie alle Teile derselben, die ich gedruckten und digitalen Medien, Schul- und Betriebsdokumenten jeglicher Art entnommen habe, sei es direkt oder modifiziert, entsprechend als Zitate, Vorlagen und Quellen kenntlich gemacht. Declaração pessoal de autenticidade da autoria Eu asseguro por meio da minha assinatura que a tarefa junto à empresa e este relatório foram por mim desenvolvidos de maneira autónoma. No relatório eu esclareço qual foi exatamente a minha contribuição nos processos e resultados relatados. Todos os textos, imagens, gráficos ou subelementos dos mesmos que eu retirei de mídias impressas ou digitais, documentos escolares ou empresariais, seja diretamente ou mediante modificações, estão identificadas como citações, modelos e fontes. Blumenau, 20 de janeiro de 2011 Dieses Formular als Kopfblatt des Reports benutzen. Dahinter eine Kopie der 2. Seite das Antragsformulars! Dann gleich das Inhaltsverzeichnis + Text + Anhang. 5 komplette, einfach geklammerte Exemplare abgeben! Usar esta folha como CAPA do relatório da tarefa integrada. Em seguida uma copia da 2 a página do formulário de requerimento! Em seguida, diretamente prosseguir com o índice + texto + anexos. Entregar 5 vias completas, simplesmente grampeadas! Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 1/22
Índice 1 Introdução... 4 1.1 Visão geral... 4 1.1.1 Entendimento do problema... 4 1.1.2 Stakeholders... 4 1.2 Contatos... 5 2 Análise do Processo Atual... 6 2.1 Processo atual... 6 2.2 Software e arquivos... 6 3 Proposta de Melhoria... 7 3.1 Conceito... 7 3.2 Recursos extras... 7 3.2.1 Registro de estabelecimentos... 7 3.2.2 Roteiro de viagem... 7 3.3 Arquivos... 7 3.4 Diagrama de cadeia de processos orientados a eventos... 8 3.5 Usuários, hierarquia e direitos de acesso... 9 3.6 Diagrama de classes... 10 3.7 Diagrama de casos de uso... 11 3.8 Diagrama entidade-relacional... 12 4 Planejamento do Projeto... 13 4.1 Plano sequencial das tarefas... 13 4.2 Planejamento dos pacotes de trabalho... 14 4.3 Diagrama de rede de tarefas... 15 4.4 Planejamento de recursos necessários... 16 4.4.1 Tecnologias... 16 4.4.2 Hardware... 17 4.4.3 Recursos Humanos... 18 4.5 Planejamento de custos e análise econômica... 18 4.5.1 Cálculo de custo... 18 4.5.2 Análise econômica... 19 4.6 Análise de riscos e indicadores de desempenho... 20 5 Considerações Finais... 21 6 Referências... 22 Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 2/22
Índice de Tabelas Tabela 1 - Stakeholders... 4 Tabela 2 - Contatos... 5 Tabela 3 Direitos de usuário... 9 Tabela 4 Plano sequencial de tarefas... 13 Tabela 5 Comparativo entre linguagens... 17 Tabela 6 Análise de ponto de função... 18 Tabela 7 Cálculo de custo do projeto... 18 Tabela 8 Cálculo de custo das transições... 19 Tabela 9 Cálculo da economia gerada... 19 Tabela 10 Análise de riscos... 20 Índice de Diagramas Diagrama 1 - Stakeholders... 5 Diagrama 2 - EPK... 8 Diagrama 3 - Hierarquia... 9 Diagrama 4 - Stakeholders... 10 Diagrama 5 Caso de uso... 11 Diagrama 6 Modelagem Entidade-Relacional... 12 Diagrama 7 Pacotes de trabalho... 14 Diagrama 8 Rede de tarefas... 15 Diagrama 9 Arquitetura do sistema... 16 Diagrama 10 Comparativo entre linguagens... 17 Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 3/22
1 Introdução 1.1 Visão geral Nos últimos anos, os serviços de TI deram ao Brasil uma posição de destaque, incluído recentemente como um dos 30 melhores países para fazer Offshore, ou seja, a prestação de serviços de TI para outros países. Dentro dessa estatística encontra-se a T-Systems, especialmente a unidade Blumenauense, onde encontra-se o primeiro centro de competência Offshore do Brasil que presta seus serviços exclusivamente na lingua alemã. Diferencial que tem proporcionado a Blumenau um evolução muito grande nesta área, tendo começado em 2006 com apenas 22 funcionários e atualmente comportando mais de 220. Através da oferta de suporte à Alemanha em lingua materna, o número de projetos importados cresce constantemente, o que origina uma demanda grande de viagens para a realização de transições de serviços. Tais transições são os repasses de conhecimento sobre serviços que eram realizados na Alemanha e serão realizados no Brasil. Em cada viagem realizada o funcionário deverá realizar a própria contabilidade, que serão apresentadas ao setor financeiro após o término da transição. Estes custos são declarados manualmente, através de arquivos em formato.xls. 1.1.1 Entendimento do problema Hoje a contabilidade das viagens para transições de serviços da T-Systems do Brasil é realizada manualmente, tomando um tempo precioso das pessoas envolvidas. Elas necessitam de uma boa parte do tempo da transição somente para declarar seus gastos, o que torna a transição mais demorada, gerando custos extras. Além disso, como não há um gerenciamento de qualidade sobre os gastos realizados, ocorrem constantes transtornos devido a perda de comprovantes ou falta de histórico em uma base única. Este documento tem como objetivo fazer o planejamento de um sistema de controle para a otimização destes processos junto ao controle dos custos de uma transição para que os envolvidos possam focar-se nas tarefas que lhes foram delegadas. 1.1.2 Stakeholders Em princípio foram identificados os Stakeholders, ou seja, as pessoas que são direta ou indiretamente afetadas através da criação do projeto. No gráfico seguinte, encontram-se os principais interessados no projeto e quais seus possíveis pontos positivos ou negativos. Tabela 1 - Stakeholders Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 4/22
Stakeholder P¹ I² Positivas Negativas T-Systems Blumenau CBM 6 8 Setor de Finanças Sistema auxiliará no controle de despesas de todas as viagens realizadas novo sistema. Demora na adaptação ao 4 5 por funcionários da T-Systems Blumenau, reduzindo os gastos substancialmente. 3 3 Funcionários 1 2 Team Leaders ¹ P = Poder ² I = Interesse 3 2 A conta do cliente pode ter um custo reduzido, gerando um lucro maior para a T-systems Brasil. Maior controle dos gastos, reduzindo o tempo necessário. Economia de tempo da viagem para focar-se nas tarefas da mesma; redução da frequência de lacunas das declarações. Possível demora na a- provação de custos. Podem alegar a inconfiabilidade do sistema. Demora na declaração de despesas; possível descaso na participação de todo o novo processo. Melhor acompanhamento do líder Não há pontos negativos. sobre os gastos do funcionário, reduzindo o trabalho gerencial. Em seguida, a representação gráfica da tabela anterior, usando como critérios o poder e o interesse dos agentes. Diagrama 1 - Stakeholders Poder CBM T-Systems Blumenau Setor de Finanças Team Leaders Interesse Funcionários 1.2 Contatos Tabela 2 - Contatos Name Área Telefone E-mail Blumenschein, Markus Systems Integration (47)32311206markus.blumenschein@tsystems.com.br Vital, Eduardo SI Sales (11)21842607eduardo.vital@t-systems.com.br Imme, Edney PoP Offshore (47)32311257edney.imme@t-systems.com.br Pereira, Marco PoP Offshore (47)32314258marco.pereira@t-systems.com.br Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 5/22
2 Análise do Processo Atual 2.1 Processo atual Atualmente a contabilidade das viagens é realizada manualmente. Os funcionários que estão em viagem recebem um pagamento pré-calculado, baseado na quantidade de dias previstos para a transição. Ele deve coletar todos os recibos referentes aos seus gastos para que sejam comprovados ao final da viagem. Estes gastos são divididos em três tipos: transporte, hospedagem e custos extras. Todos os gastos devem ser comprovados, exceto trinta euros ( 30,00) diários, considerados per diem. Quanto aos gastos com transporte, a única declaração que não é necessária é a da viagem de partida e retorno das transições, por serem previamente calculadas. Já para os outros custos de transporte, devem ser declarados o trecho, o valor, a localidade e a data. Já para os custos de hospedagem, deve ser registrado o estabelecimento, a diária e o valor pago e a localidade. Nos custos extras, há necessidade da descrição do custo, da localidade e do valor gasto. Todos os custos que não se enquadram em hospedagem ou transporte recaem sobre custos extras, com exceção do per diem. Este é o valor destinado para gastos com alimentação a cada dia. Caso o funcionário utilize menos que esse valor, o restante não necessita de declaração. Ao final da viagem, o funcionário recebe uma planilha para que seja preenchida. Nela o funcionário declara seus gastos com hospedagem, transporte e extras, anexando ao arquivo os respectivos comprovantes. Do valor pago inicialmente, o chamado pré-pagamento, desconta-se o valor do per diem multiplicado pelo número de dias da transição. Sobre do restante são abatidos os gastos do funcionário. Se houver sobras, o funcionário deve devolvê-las à empresa e, caso o funcionário tenha utilizado dinheiro próprio para suas despesas, a T-Systems o reembolsa com o mesmo valor. 2.2 Software e arquivos A declaração de despesas era realizada pelo aplicativo Microsoft Office Excel ou similares, através de um formulário em formato XLS disponibilizada pelo departamento SI Sales que realiza o controle das despesas de viagem. Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 6/22
3 Proposta de Melhoria 3.1 Conceito O projeto baseia-se em um sistema web onde as despesas deverão ser declaradas diariamente pelo funcionário para que haja um controle mais exato e elimine a frequência de problemas ligados a essas declarações. O processo inicia com o registro de uma nova viagem por parte do Team Leader do projeto. Ele deverá cadastrar todos os dados necessários para que essa transição se inicie. Inicialmente devem ser registrados dados como funcionário, projeto, data de partida e retorno, percurso da viagem aérea, número de dias de transição e valor do pré-pagamento. Tanto os Team Leaders como os funcionários deverão ser registrados no sistema para que possam utilizá-lo. Quando o funcionário já estiver em viagem ele deverá registrar diariamente seus gastos. Também deverá em algum momento escanear os recibos e anexá-los a seus respectivos registros, assim terá maior controle. Os registros de gastos estão divididos em três categorias, hospedagem, transporte e extras. ara cada item de hospedagem é necessário o cadastro do estabelecimento, caso não exista. Assim haverá um registro para futuras viagens, onde a empresa poderá basear para consulta de locais e valores. Ao final da transição será emitido um relatório de viagem. Nele contarão os custos declarados, o pré-pagamento, o cálculo do per-diem, valores de transferências entre funcionários e um possível reembolso por parte do funcionário para a T- Systems ou o inverso. Juntamente com o relatório deverá o funcionário entregar todos os recibos coletados. 3.2 Recursos extras 3.2.1 Registro de estabelecimentos Como as viagens ao exterior são frequentes, o sistema será também uma base de dados de estabelecimentos já frequentados, assim como a média das diárias pagas. Com isso, a empresa poderá prever o seu gasto para futuras viagens. O sistema armazenará o histórico automaticamente. 3.2.2 Roteiro de viagem Outro recurso que o sistema trará é o roteiro de viagem. Este utiliza o aplicativo web Google Maps, que mostra a visualização dos locais por onde o funcionário passou durante a viagem. roteiro é demarcado automaticamente ao cadastrar os custos das viagens entre as cidades visitadas. 3.3 Arquivos Para cada transição realizada o sistema gerará um único documento para acompanhamento gerencial, um resumo de viagem, onde se apresentarão todos os dados da transição e os gastos relacionados a ela. Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 7/22
3.4 Diagrama de cadeia de processos orientados a eventos O diagrama de cadeia de processos orientado a eventos (EPK) mostra o fluxo do processo de inserção de uma nova transição. Após ser identificada, o Team Leader deve registrá-la no sistema, então determinar o funcionário que será responsável. Se este funcionário não estiver cadastrado, ele terá que cadastrar e delegar os direitos de acesso à ele. Cada transição necessita de um pré-pagamento, pago ao funcionário previamente. Uma transição deve ter este cadastro necessariamente, feito pelo Team Leader. Ao final, o sistema verificará se o valor do per diem está definido, só então o Team Leader poderá determinar o tempo planejado de dias da transição. Diagrama 2 - EPK Nova Transição Identificada Team leader Cadastrar Transição Nova Solicitação de Cadastro Aberta Determinar Funcionário Funcionário encontrado XOR Funcionário não encontrado Cadastrar Funcionário Funcionário cadastrado XOR Definir Prépagamento Prépagamento definido Sistema Per diem determinado? Per diem já determinado XOR Per diem não determinado Team leader Determinar Per diem Per diem determinado XOR Definir tempo de transição Transição cadastrada Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 8/22
3.5 Usuários, hierarquia e direitos de acesso O sistema proposto deverá comportar uma hierarquia de usuários com direitos específicos de acordo como funcionário em questão. O sistema terá quatro níveis hierárquicos. Administrador do sistema, Gestores, Team Leaders e Funcionários: Administrador Possui funções básicas do sistema. O princípio é a manutenção das senhas dos dados e senhas de todos os níveis inferiores. Gestores Mesma função que um administrador, porém, possui direitos de manutenção somente sobre os usuários abaixo de seu nível hierárquico e sob sua jurisdição. Team Leaders Nomenclatura do cargo de chefe de equipe. Como usuário possui todos os direitos de acesso e manutenção sobre os usuários abaixo de seu nível hierárquico e sob sua jurisdição. Funcionários Nível hierárquico mais baixo, concedido aos funcionários que realizam as transições. Possui direitos referentes ao registro dos gastos. Abaixo o diagrama da hierarquia de usuários e a tabela de direitos de cada um. Diagrama 3 - Hierarquia Administrador Gestor Gestor Team Leader Team Leader Team Leader Funcionário Funcionário Funcionário Funcionário Funcionário Funcionário Direitos Administrador Gestor Team Leader Cadastrar, modificar e apagar usuários Tabela 3 Direitos de usuário Funcionário ¹ ¹ Modificar dados de usuário Modificar senha de usuário Resetar senha ¹ ¹ Conceder direitos a usuários ¹ ¹ Cadastrar, modificar e apagar estabelecimentos Cadastrar e modificar transições Definir per diem padrão Registrar gastos Imprimir resumo de viagem Visualizar roteiro de viagem ¹ Usuário a partir do nível hierárquico inferior. Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 9/22
3.6 Diagrama de classes O diagrama a seguir representa o escopo das classes do sistema. Apenas as classes de negócios estão nele representadas. Diagrama 4 - Stakeholders Estabelecimento nome: String endereco: String numero: int complemento: int cidade: Cidade email: String site: String ultimadiaria: double linkgmaps: String tipo: String Construtor() remover() adicionar() selecionar() 0..* 1 1 0..* Cidade nome: String uf: String linkgmaps: String Construtor() remover() adicionar() selecionar() Hospedagem:Custo estabelecimento: Estabelecimento dataate: Date valordiaria: Double Construtor() remover() adicionar() selecionar() 1 1 0..* 0..* Extra:Custo descricao: String local: Cidade Construtor() remover() adicionar() selecionar() Transporte:Custo de: Cidade para: Cidade tipo: String Construtor() remover() adicionar() selecionar() Custo valor: Double transicao:transicao data: Date Construtor() remover() adicionar() selecionar() Viagem tipo: String trecho: String data: Date transicao: Transicao Construtor() remover() adicionar() selecionar() 0..* 2 1 1 Funcionario nome: String email: String chaverede: Date tipo: String senha: String Construtor() remover() adicionar() selecionar() Transicao wbs: String projeto: String funcionario: Funcionario destino: String tempo: int prepagamento: double Construtor() remover() adicionar() selecionar() 1 1..* Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 10/22
3.7 Diagrama de casos de uso Diagrama 5 Caso de uso Sistema Cadastrar Usuário Administrador Alterar Dados de Usuário Gestor Pesquisar Usuários Resetar Senha Alterar Senha de Usuário Cadastrar Transições Pesquisar Transições Team Leader Definir Per Diem Funcionário Registrar Gastos Cadastrar Estabelecimentos Pesquisar Estabelecimentos Modificar Estabelecimentos Visualizar Resumo de Viagem Visualizar Transições Imprimir Resumo de Viagem Visualizar Roteiro Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 11/22
3.8 Diagrama entidade-relacional Diagrama 6 Modelagem Entidade-Relacional local nome Realizado na Movese de descricao Extra cidade de partida tipo trecho tipo Viagem data Contém transição transição data valor wbs pré-pagamento tempo Transição destino projeto Possui link gmaps uf cidade Cidade Localizase na Movese para cidade destino Transporte Custo funcionário Realiza tipo ultima diária link gmaps complemento endereco Estabelecimento numero nome email site Realizado no dataate Hospedagem valor diária senha tipo Funcionário chave rede nome email Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 12/22
4 Planejamento do Projeto 4.1 Plano sequencial das tarefas Seq Descrição Tempo Anter. Próximo Tabela 4 Plano sequencial de tarefas FAZ FEZ SAZ SEZ GP FP 1 Descrever o processo atual 3 2 0 3 0 3 0 0 2 Indetificar os Gaps 2 1 3 3 5 3 5 0 0 3 Coletar as sugestões de melhoria 2 2 4 5 7 5 7 0 0 4 Elaborar a proposta de melhoria 4 3 5,6,7,1 0 7 11 7 11 0 0 5 Verificar os recursos físicos 1 4 8 11 12 11 12 0 0 6 Verificar os recursos de software 1 4 8 11 12 11 12 0 0 7 Verificar os recursos humanos 1 4 8 11 12 11 12 0 0 8 Calcular os custos 3 5,6,7 9 12 15 12 15 0 0 9 Calcular retorno sobre o investimento (ROI) 3 8 12 15 18 15 18 0 0 10 Identificar os Stakeholders 1 4 11 11 12 15 16 4 0 11 Elaborar o plano de comunicação 2 10 12 12 14 16 18 4 4 12 Identificar os riscos 2 9,11 13 18 20 18 20 0 0 13 Elaborar plano de ação 2 12 14 20 22 20 22 0 0 14 Criar os índices de desempenho (KPI) 15 Elaborar documentação do projeto FAZ Prazo mínimo para início SAZ Prazo máximo para início GP Tempo total de flexibilidade FEZ Prazo mínimo para término SEZ Prazo máximo para término FP Tempo de flexibilidad 2 13 15 22 24 22 24 0 0 10 14 24 34 24 34 0 0 Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 13/22
4.2 Planejamento dos pacotes de trabalho O organograma abaixo ordena os pacotes de trabalho do processo de planejamento. Diagrama 7 Pacotes de trabalho Planejamento do Sistema Análise do processo atual e dos Gaps Levantamento de Recursos Cálculo de custos Levantamento dos Stakeholders Análise de Riscos Elaboração da Documentação Descrever o processo atual Varificar os recursos físicos necessários Calcular os custos Identificar os Stakeholders Identificar os Riscos Elaborar a documentação do projeto Identificar os Gaps Verificar os recursos de software necessários Cálcular o retorno sobre o investimento Elaborar o plano de comunicação Elaborar plano de ação Coletar as sugestões de melhoria Verificar os recursos humanos necessários Criar o índices de desempenho (KPI) Elaborar a proposta de melhoria Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 14/22
4.3 Diagrama de rede de tarefas Este diagrama representa a tabela anterior. Cada pacote de trabalho é representado por um elemento do diagrama, onde o numero do pacote está acima, abaixo estão, sequencialmente o tempo de duração da atividade, a sobra de tempo total e a sobra de tempo de cada processo. A linha crítica é o trecho do processo que não pode sofrer atrazos. É determinada através da identificação de tempo livre 0 em todos os processos que dela fazem parte. 0 3 1 3 0 0 0 3 3 5 2 2 0 0 3 5 5 7 3 2 0 0 5 7 7 11 4 4 0 0 7 11 11 12 5 1 0 0 11 12 Diagrama 8 Rede de tarefas 11 12 6 1 0 0 11 12 12 15 8 3 0 0 12 15 15 18 9 3 0 0 15 18 11 12 7 1 0 0 11 12 18 20 12 2 0 0 18 20 11 12 10 1 4 0 15 16 12 14 11 2 4 4 16 18 20 22 13 2 0 0 20 22 22 24 14 2 0 0 22 24 24 34 15 10 0 0 24 34 Linha crítica: 1, 2, 3, 4, 5/6/7, 8, 9, 12, 13, 14, 15 Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 15/22
4.4 Planejamento de recursos necessários 4.4.1 Tecnologias Para o desenvolvimento do projeto, optou-se a utilização de ferramentas gratuítas. O sistema será baseado em interface web, sendo escolhida a linguagem mais adequada Java, por conter soluções já prontas necessárias ao projeto como o Framework de segurança Spring, além do JPA que realiza a interface objeto-relacional. Já a interface com o usuário será baseada no framework Zkoss, que integra um conjunto de ferramentas como Java Server Faces e Google Maps e imprime páginas HTML com funções em JavaScript abstraídas de outras mais complexas da linguagem Ajax. Para a solução de armazenamento não foi necessária a realização de um comparativo entre os bancos gratuitos existentes. O banco de dados MySql mostra se a opção mais robusta e com ferramentas de desenvolvimento avançadas, além de integrar-se com facilidade à linguagem Java e seus Frameworks. É o banco de dados gratuito mais usado entre os desenvolvedores, mesmo e- xistido outras bases conhecidas como PostgreeSql, não há um concorrente à sua altura. Em resumo das tecnologias selecionadas, o diagrama abaixo mostra um esboço arquitetura do sistema. Diagrama 9 Arquitetura do sistema Client Browser JavaScript Server Webserver Apache Tomcat JVM Java Apresentação ZKoss Spring Security Persistência JPA Armazenamento MySQL Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 16/22
O uso da linguagem Java e do Framework Zkoss foram selecionados baseando-se em um comparativo com outras possibilidades: Diagrama 10 Comparativo entre linguagens Tecnologia Quesito Segurança Nível de Desenvolvimento Requerido Integração ao Banco de Dados Execução Avaliação Geral 4.4.2 Hardware Java + Zkoss Java + JSP Ruby on Rails PHP Nível de segurança apurados, devido a excelentes frameworks existentes baseados em Java. Nível de segurança apurados, devido a excelentes frameworks existentes baseados em Java. O Framework Zkoss Possui inúmeras abstrai inúmeros tecnologias para elementos Web tornando o desenvol- de abstração não integração. O nível vimento e a manu- é tão elevado, re- tenção do programa mais suaves. Requer nível de conhecimento médio. Comporta a maioria das soluções existentes. Há uma solução pronta de execução que provém do Framework Zkoss. Processamento mais lento por rodas em Máquina Virtual. querendo do programador um conhecimento elevado. Comporta a maioria das soluções existentes. Executado através do contêiner de Servlets Apache Tomcat, projeto de software livre para execução de páginas de linguagem JSP. Processamento mais lento por roda em máquina virtual. O JSF é uma extensão baseada em uma extensão O JSP ainda é XML, sendo o muito utilizada no Zkoss uma evolução desta tecnolo- Web, apesar de desenvolvimento gia. Para desenvolver basta ter coluções sinificati- não receber evonhecimentos em vas. É interessante por ser conhe- JSF, há um grande número de desenvolvedores. Melhor volvedores Java. cida entre desen- opção para desenvolver. Ferramenta com grau de segurança maturo para uma tecnologia nova. Não possui muitas soluções externas. Tem nível de programação simplificado, porém ainda não possui muitas soluções para integrá-la. Ruby aceita os principais bancos. Há poucas soluções prontas para esse quesito no php. Possui nível de programação simplificado e um número baixo de soluções para integração. Suporta conexões com alguns bancos, princialmente os mais conhecidos como MySql, Postgree, Oracle e Firebird. Utiliza o Apache Server para execução das Melhor linguagem para processamento. Extremamente rápido. O Rails utiliza páginas. o Apache Server para execução. Ruby on Rails tem se tornado popular entre desenvolvedores, porém, apesar da crescente evolução, é ainda uma linguagem pouco explorada. O PHP é uma das linguagens mais populares para Web. Por ser de um nível mais simplificado, não é a melhor indicada quando se busca maior integração. O projeto deverá ser implantado em servidores já existentes dentro da T- Systems Blumenau e sistema necessitará de requisitos de hardware mínimo, já que Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 17/22
os servidores possuem uma capacidade ampla e o sistema requer processamento e armazenamento baixos. 4.4.3 Recursos Humanos Para realização do projeto será necessário programadores com conhecimentos na tecnologia Java, especificamente nos frameworks de integração JSF, JPA e S- pring. Além disso, será necessário que o programador tenha conhecimentos em banco de dados MySql, assim como publicação do aplicativo através da ferramenta Apache Tomcat, além de um analista para acompanhamento das atividades de desenvolvimento e coordenação dos testes e implantação do sistema. 4.5 Planejamento de custos e análise econômica 4.5.1 Cálculo de custo O sistema não será hospedado no DataCenter interno na T-Systems Blumenau, o que resultará em custo de hardware não significativo. O sistema envolve apenas os custos com pessoal para realizar o desenvolvimento. A análise de pontos de função é uma prática de mensuração de software. Sua técnica é realizar um cálculo sobre as funcionalidades do sistema para designar o custo total do projeto. Este cálculo é realizado sobre as funcionalidades específicas visíveis aos usuários, como um campo da tabela ou uma transação. O objetivo é substituir o cálculo de horas trabalhadas diretamente, focando-se no que será feito para melhor avaliar os valores. A tabela abaixo mostra os pontos de função identificados através do diagrama entidade-relacional e do diagrama de caso de uso: Tabela 5 Análise de ponto de função Arquivos Internos (ALI) Arquivos Interface Externa Qtde Peso Total Características do Ambiente Simples 6 7 42 Comunicação de Dados 1 Médio 2 10 20 Processamento Distribuído 1 Complexo 0 15 0 Configuração Altamente Utilizada 0 Simples 0 5 0 Entrada de Dados On-Line 5 Médio 0 7 0 Eficiência do Usuário Final 5 (AIE) Complexo 0 10 0 Atualização On-Line 3 Entradas Externas (EE) Saídas Externas (SE) Consulta Simples 0 3 0 Facilidade de Operação 5 Médio 1 4 4 Modificação Facilitada 1 Complexo 56 6 336 Características do Sistema Simples 0 4 0 Performance 1 Médio 0 5 0 Volume de Transações 1 Complexo 30 7 210 Processamento Complexo 1 Simples 0 3 0 Reusabilidade 1 Externas Médio 19 4 76 Facilidade de Instalação 1 (CE) Complexo 25 6 150 Múltiplos Locais 2 Cálculo de pontos por Função Total Geral 28 Tabela 6 Cálculo de custo do projeto Fator de Ajuste APF 0,93 Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 18/22
Pontos por função bruto 838,00 Pontos por função ajustado 779,34 Produtividade do ambiente e equipe 5,00 % Risco (Identificado no F36) 0% Produtividade Ajustada com Risco 5,00 Horas trabalhadas por dia 8,00 Esforço para desenvolvimento do projeto (horas) 3.896,70 Custo do desenvolvimento do projeto 97.417,50 4.5.2 Análise econômica O custo diário de uma transição gira em torno de 140,00 e o tempo de permanência em uma transição é de uma semana a três meses, gerando uma média de um mês e quinze dias em cada transição. Além disso, anualmente são realizadas em torno de cinco transições. Tudo isso resulta no cálculo de custo abaixo: Tabela 7 Cálculo de custo das transições Custo diário de um funcionário em transição 140,00 Euros Tempo médio de permanência do funcionário 45 Dias Média de transições realizadas por ano 5 Custo total das transições de um ano 31.500,00 Euros Custo convertido para moeda nacional (cotação 1:2,25) 70.875,00 Reais A declaração de despesas manual toma aproximadamente dez porcento do tempo de uma transição, sem contar as freqüentes falhas que ocorrem devido a perdas de comprovantes ou falta de organização. A declaração através do software custaria menos de cinco porcento do tempo de transição, tirando em torno de 20 minutos diários do funcionário para declaração, o que resulta em uma economia de tempo, consequentemente redução de custos. Tabela 8 Cálculo da economia gerada Custo total das transições de um ano 70.875,00 Reais Custo das declarações feitas manualmente sobre o custo total 10% 7.087,50 Reais Economia gerada anualmente 5% 3.543,63 Reais O tempo gasto indiretamente em declarações manuais, ou seja, os transtornos gerados pela falta de organização não podem ser mensurados. Portanto, deve-se levar em conta de que o valor da economia gerada não os inclui. Assim, pode-se concluir que o valor retornado é ainda superior ao apresentado. Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 19/22
4.6 Análise de riscos e indicadores de desempenho A tabela abaixo mostra os riscos identificados relativos ao sucesso do projeto, as possíveis causas de cada um, as ações que devem ser tomadas para que este risco possa ser prevenido assim como as ações para contenção do problema que pode ser gerado caso o risco venha a se concretizar. Juntamente, para cada risco será criado um índice de desempenho para que haja um controle da qualidade do processo. Risco Potencial Possível Causa Ações preventivas Atrazos nas declarações Falha no sistema Descaso por parte dos funcioná- inicial do Reciclagem Treinamento Ações de rios sistema Erro de código Resistência por Dificuldade de parte dos usuários novo adaptação ao processo Incompatibilidade da aplicacesso falha Análise do proção com os requisitos da empresa Falha de Segurança Testes prévios no sistema Desenvolvimento Testes de do sistema sem segurança a prévia observação das normas de segurança Ações de (KPI) Índice de contingência desempenho Solcitação de correção do erro Treinamento Orientação pré- individual implemen- tação suários pro- com os u- blemáticos Auditoria Nova análise e corre- prévia sobre o processo ção do problema Solicitação de mudança do código Número de a- trazos Número de falhas Tabela 9 Análise de riscos Contagem Dias de atrazo e quantidade por transição Tickets por mês - - Data final de conclusão da implementação Número de falhas Dias de atrazo Tickets por mês Arquivo: Henrique_Relatorio-final_AHK-2011.doc Data: 18.05.2010 Autor: Henrique Kolling Limberger 20/22