Tema: Engenharia de Software (processo de desenvolvimento de sistemas)
|
|
- Marina César Diegues
- 8 Há anos
- Visualizações:
Transcrição
1 Título do Trabalho: Ei, Seu Sistema é um Workflow! Autor(a): Marlon Silva Carvalho Tema: Engenharia de Software (processo de desenvolvimento de sistemas) Total de páginas: 29
2
3 Título: Ei, Seu Sistema é um Workflow! Autor: Marlon Silva Carvalho Tema: Engenharia de Software (processo de desenvolvimento de sistemas) Resumo: O objetivo deste trabalho baseia-se na apresentação dos principais benefícios factíveis de serem alcançados por uma empresa, a partir do momento em que há a disseminação e um entendimento sólido sobre a tecnologia de Workflows. Com a posse deste entendimento, as equipes munem-se de práticas e técnicas que garantem um produto mais confiável e construído em prazos mais curtos. Embora apresente-se como uma tecnologia com amplos estudos e diversas soluções de software livre existentes no mercado, ainda há pouco direcionamento para o seu uso no Serpro. A pouca compreensão que existe internamente na empresa sobre o tema apresenta-se como o maior dificultador para identificar, documentar e implementar sistemas deste tipo. Considerando a grande extensão deste assunto, que abrange conceitos como Services Oriented Architecture (SOA), Business Process Management (BPM) e Enterprise Service Bus (ESB), que possuem como foco uma visão mais ampla, tocando mais incisivamente nas questões que envolvem o negócio macro de uma empresa, o contexto no qual o Serpro atua urge não desprezar as dificuldades encontradas por suas equipes de desenvolvimento para construírem aplicações desta natureza para seus clientes. Observou-se que o pouco conhecimento em Workflows direciona para a perda de qualidade e produtividade das equipes, uma vez que grande parte de código dos sistemas que são inerentes a esta tecnologia pode ser descartada apenas adotando um mecanismo de Workflow. Contudo, este benefício estende-se também às áreas de requisitos, análise e projeto, que tendem a se tornar mais simples, uma vez que sistemas de Workflow são propensos a se comportarem de forma similar. Este trabalho ainda apresenta um estudo de caso, dentro do próprio Serpro, exemplificando como este trabalho extra foi evitado adotando um mecanismo de código livre no desenvolvimento de um projeto para a Receita Federal do Brasil. Com este rápido estudo de caso, é possível observar os benefícios alcançados pela equipe, reduzindo a quantidade de código, aumentando a qualidade do produto e diminuindo o prazo para entrega. Concluindo, apresenta-se como o Demoiselle pode agregar funcionalidades de Workflow, permitindo que as equipes de desenvolvimento do Serpro usufruam das vantagens que esta tecnologia proporciona. Palavras-chave: Workflow. SOA. BPM. ESB. Demoiselle. Engenharia. Total de páginas: 29
4 Currículo Funcionário do Serpro desde 2006, atua na área de desenvolvimento de software desde Atuou no Serpro no projeto Sispei, sistema da Receita Federal do Brasil totalmente direcionado para Workflows. Possui a certificação Java 1.4 e está concluíndo a pósgraduação de Sistemas Distribuídos pela Universidade Federal da Bahia. Apoiador e mantenedor de diversos projetos de software livre.
5 Sumário O Incrível Mundo dos Workflows...7 Ei, Seu Sistema é um Workflow!...9 Então, qual o problema?...10 Qual o Caminho?...12 O Mapa para a Mina...12 Sistema AmoWorkflows S/A...13 Ajudando o Analista de Requisitos...15 Generalizando os Casos de Uso...15 Casos de Uso Modulares...17 Regras de Negócio por Entidade/Ação...17 Análise, Projeto e Codificação...18 Componentes...18 Utilização de Engines...19 Exemplos são Melhores que Mil Palavras...20 Demoiselle e Workflows...23 O Amanhã...24 O Fim...24 Bibliografia...26
6
7 O INCRÍVEL MUNDO DOS WORKFLOWS Embora seja considerado um tema de discussão antiga, podem ser encontradas, ainda hoje, diversas correntes divergentes quanto ao que é e quais as atribuições de um Workflow. O objetivo desta seção é esclarecer o que são Fluxos de Trabalho, quais as suas atribuições e como podem ser aplicados, tentando desmistificar este incrível, e fascinante, mundo dos Workflows. Muitos dos conceitos desta área são encontrados em nosso cotidiano. A sequência de tarefas realizadas ao levantar-se da cama até o momento de chegada ao trabalho destaca uma série de atividades executadas todos os dias por muitas pessoas: levantar, escovar os dentes, tomar banho, tomar o café da manhã, dirigir-se ao trabalho, etc. Deste exemplo, observa-se um conjunto de estados que se modificam a partir de ações. Tem-se, então, o estado dormindo, que necessita da ação acordar para que se passe para o estado escovando os dentes. Para chegar ao estado tomando café da manhã será necessário executar algumas atividades, como escovar os dentes e tomar banho. Embora possa ser considerado um exemplo simplório, é importante para clarear as ideias básicas de um Workflow. Em uma visão macro, abordando questões de negócio de uma empresa, tem-se relatórios que estão aguardando validação e que, para chegarem até o chefe do setor, devem ser analisados e, logo após, aprovados. Para aqueles formados na área de engenharia de sistemas, alguns conceitos anteriormente aprendidos em outras áreas podem surgir, como o de Máquinas de Estado. De fato, um fluxo de trabalho contém esta ideia, mas a amplia consideravelmente. Conforme a evolução das tecnologias que circundam os Workflows foram avançando, diversas características foram agregadas, muitas vezes criando termos novos que possivelmente criaram mais dificuldades para entender este tema. Para Eder e Liebhart (1996), fluxos de trabalho são Processos de Negócio que consistem de múltiplas atividades que devem ser executadas em uma sequência válida. Atividades representam qualquer unidade de trabalho, que pode ser, por exemplo, uma simples chamada de telefone. Para o objetivo deste trabalho será considerada a definição construída pela Workflow Management Coalition (WfMC), órgão criado e gerido por um grupo de empresas e outras partes interessadas neste assunto. A WfMC descreve: Workflows preocupam-se com a automação de procedimentos nos quais documentos, informações 7
8 ou tarefas são trocados entre participantes, conforme um conjunto definido de regras, com o objetivo de alcançar, ou contribuir, para uma meta global de negócios (WFMC, 2010). Considerando a definição proposta pela WfMC, pode-se esclarecer um fluxo de trabalho através de um rápido exemplo real, como um fluxo de pedidos de compra. Nele pode-se perceber a participação de entes que devem executar tarefas como, por exemplo, o técnico que deve verificar o estoque dos produtos que compõem o pedido e a aprovação financeira, realizada pelo analista financeiro. A Ilustração 1 exemplifica esta ideia. Nesta ilustração percebe-se seis estados, ou passos, que um pedido pode passar. Em cada passo deste pode existir uma ou mais tarefas associadas aos usuários do sistema. Uma vez executada uma atividade, ou tarefa, o fluxo migra de estado, utilizando para isto as transições, representadas através das setas direcionadas que interligam os passos. Ilustração 1: Exemplo de Fluxo de Trabalho. Outro termo comum nesta área, e que merece um esclarecimento, é o termo Workflow Engine ou, traduzido para nosso idioma, Mecanismo de Fluxo de Trabalho. Uma vez definido um fluxo de trabalho, cabe operacionalizá-lo e um mecanismo de workflow é o responsável por esta ação. Cabe a ele tratar uma entrada, o fluxo de trabalho descrito em uma linguagem, e gerenciar as transições entre os estados e as tarefas que cada participante possui, além da execução destas pelos seus responsáveis. As linguagens de definição de processos são estruturas formalmente organizadas que permitem aos responsáveis pela idealização de um fluxo descreverem os passos e as 8
9 tarefas que cada participante terá. Neste contexto, podemos destacar as linguagens extensible Process Definition Language (XPDL, 2010) e a Business Process Management Notation 2 (BPMN2, 2010). A primeira é mantida pela WfMC, enquanto a segunda é mantida pelo grupo BPM.org. A linguagem BPMN2 diferencia-se da XPDL não apenas na sintaxe, mas também na forma de apresentação, uma vez que ela também pode ser usada de maneira visual, permitindo a construção de fluxos de trabalho adotando elementos gráficos pré-estabelecidos. Ambas linguagens não encerram o assunto, pois diversas outras já foram sugeridas, embora muitas não tenham alcançado o êxito pretendido. Atualmente, a linguagem BPMN2 possui maior evidência, sendo adotada como linguagem padrão dos Mecanismos de Workflow mais utilizados do mercado. Finalizando, é importante diferenciar os conceitos de Workflows e BPM, pois percebe-se, nos analistas de sistemas e negócio, confusão quanto aos limites de cada um. Pretendendo não se estender neste assunto, será adotada a ideia de BPM defendida por (COOK, 2007): Worflows são a base para o BPM. Deste ponto de vista, um BPM é um Workflow com alguns enfeites. Do ponto de vista de um analista de negócios, contudo, estes adornos são tão importantes para as pessoas que desejam que seus processos de negócio sejam rodados de forma eficiente, que cabe criar um termo específico para designar isto. EI, SEU SISTEMA É UM WORKFLOW! Com base nos conceitos de Workflows já discutidos, esta seção apresenta como muitos analistas de sistemas não percebem que várias aplicações a serem desenvolvidas são Workflows e acabam perdendo a oportunidade de adotar práticas que agilizariam o desenvolvimento e ajudariam a ter um produto mais confiável. Espera-se que ao final deste seção qualquer analista de sistemas possa imediatamente afirmar, ao ouvir os requisitos ditados por seu cliente, a frase: Ei, seu sistema é um Workflow!. De fato, muitos sistemas possuem características inerentes de Workflow, porém uma quantidade bem razoável de analistas de sistemas não consegue captar este detalhe de fundamental importância. Quando o fazem, infelizmente, não adotam práticas que permitam um maior ganho de produtividade. 9
10 Então, qual o problema? Desenvolver um sistema não é uma tarefa trivial. Contudo, pode ser ainda mais conturbada quando os responsáveis por sua criação não possuem conhecimentos além daqueles referentes à sua área de atuação. Sistemas de Workflow são um exemplo prático disto. A partir das descrições do negócio de uma empresa, é simples observar que determinada aplicação pode ser modelada facilmente como um fluxo de trabalho, mas não é tão fácil para aqueles que nunca estudaram o assunto. Conscientes ou não, os analistas terminam abdicando de adotar práticas ou reusar soluções existentes que poderiam agilizar e embutir maior qualidade ao produto. Este esforço supérfluo é comum no desenvolvimento de sistemas, principalmente pela falta de cultura nesta tecnologia. Visando a exemplificar, pode-se considerar esta simples descrição inicial de um sistema, dada por um cliente fictício: Gostaria de um sistema para facilitar a publicação de notícias em meu sítio na Internet. Os repórteres enviam as notícias de suas casas e o redator revisa. Depois, eu devo publicá-las, uma a uma, evitando notícias que ferem interesses de patrocinadores. Para um analista de sistemas com bons conhecimentos em Workflows é bastante fácil identificar um fluxo de trabalho no qual notícias passam por, no mínimo, três passos antes de serem acessíveis ao usuário externo, conforme apresenta a Ilustração 2. Contudo, para o analista sem conhecimentos sólidos, este fato passa despercebido, dificultando sobremaneira o reuso e manutenção futura do sistema. Ilustração 2: Exemplo de Workflow para Publicação de Notícias. Cabe destacar, também, que sistemas como o já descrito nos parágrafos anteriores são comuns. Considerando uma empresa com as dimensões do Serpro, no qual centenas de sistemas são mantidos e desenvolvidos anualmente, pode-se compreender o esforço desnecessário aplicado na criação de sistemas de Workflow. Em um rápido levantamento, consultando as equipes de desenvolvimento de uma das regionais, constatou-se a 10
11 existência de, no mínimo, cinco sistemas que poderiam ser criados com práticas específicas. Sistema (Linguagem) Requisitos Projeto Engine A (Java) Sim Sim OSWorkflow B (ASP) Não Não Não Utilizou C (PHP) Não Não Galáxia D (Java) Não Não Não Utilizou E(ASP) Não Não Não Utilizou Tabela 1: Lista de Sistemas Regional Salvador que poderiam usar práticas de Workflow. A Tabela 1 apresenta estes sistemas, usando nomes ficíticos. Este levantamento foi feito em agosto de 2010 e demonstra como apenas um sistema adotou práticas na área de engenharia de requisitos, análise e projeto, além de uma engine. Três foram totalmente desenvolvidos sem qualquer tipo de prática que visasse alavancar a produtividade da equipe. Um deles adotou apenas um engine. Um fato comum é a construção quase completa de uma engine própria, contendo código específico da aplicação entrelaçado com o gerenciamento do fluxo de trabalho. Adotando os termos comuns na área de desenvolvimento de aplicações, pode-se dizer que o código encontra-se com centenas de comandos if e switch totalmente desnecessários, que visam a apenas controlar em qual direção o fluxo deve prosseguir. Obviamente, uma simples engine eliminaria todo este esforço. A Listagem 1 exemplifica um cenário como este. public class SistemaSemEngineDeWorkflow { public void aprovardocumento(documento documento) throws Exception { if (! documento.getsituacao().equals("situacao_aaprovar") ) { throw new Exception("Situação Incorreta!"); } else { // Checar se o usuário pode executar tal tarefa... if ( usuario.getnome().equals("usuario1") ) { documento.setsitucao("situacao_aprovado"); } else { throw new Exception("Usuário Não Pode executar tal ação!"); } } } } Listagem 1: Código Fictício de um Fluxo de Trablaho sem utilizar Engines. 11
12 Este código Java (JAVA, 2010) fictício demonstra a utilização dispensável de instruções de controle de fluxo. Todo ele pode, e deve, ser executado por um mecanismo de fluxo de trabalho, que abstraia todas estas informações, permitindo ao programador focar-se apenas nas regras que são específicas para a aplicação em construção. Embora já haja forte ganho adotando apenas uma engine, benefícios ainda maiores podem ser obtidos usando práticas também em algumas disciplinas da engenharia de software. Comumente sistemas de Workflow são complexos e a engenharia tende a ocupar um tempo considerável no desenvolvimento do sistema. Os ganhos são perceptíveis não apenas na questão do tempo economizado, mas também na robustez do produto. As engines disponíveis no mercado já foram validadas por dezenas de outros projetos. Práticas e padrões na área de engenharia também garantem um produto mais confiável, pois estas podem ser constantemente evoluídas e validadas por diversas equipes. As etapas de elicitação de requisitos, análise e projeto são aquelas que mais ganham com a utilização destas práticas. Qual o Caminho? A garantia de um bom produto ao término do desenvolvimento de um sistema de Workflow depende fortemente dos meios adotados para desenvolvê-lo. Esta seção descreve poucas e simples práticas que, em tese, se aplicadas no desenvolvimento de sistemas deste tipo, tendem a dar maiores ganhos para as equipes. Destaca-se que nenhum estudo aprofundado foi realizado. Todo conhecimento aqui descrito foi adquirido através da criação de um sistema real e de estudos teóricos nesta área. Estas práticas ainda devem ser melhoradas e avaliadas no desenvolvimento de sistemas deste tipo, visando a validá-las e estendê-las. Também é importante destacar que se tratam apenas de práticas e não um roteiro completo e fechado de passos a serem seguidos por qualquer equipe. O Mapa para a Mina Cada tipo de sistema possui características específicas que podem ser usadas para facilitar sua classificação. Em Workflows o cenário não é diferente. Dada uma descrição de um cliente, o analista pode verificar a existência de alguns termos que definem facilmente sua classificação como um sistema de fluxo de trabalho. Provavelmente, o cliente do produto não dirá imediatamente estes termos, mas o analista pode induzi-lo a isto. Entretanto, caso o cliente relate diretamente os termos ação, atividade, tarefa, passo, 12
13 situação e estado, há fortes indícios que o sistema a ser desenvolvido é um Workflow. Também deve-se ter atenção especial a uma possível sequência de ações que o usuário possa relatar, como fulano deve escrever o relatório e enviar para o seu chefe olhar. Há uma possibilidade, neste caso, de que se esteja falando em uma entidade relatório que possui dois estados. Sistemas de Workflow sempre possuem esta característica: pessoas ou sistemas devem executar algo em alguma entidade, normalmente um documento. Para entender como um sistema pode interagir com um fluxo, basta imaginar uma administradora de cartão de crédito fornecendo um retorno para o fluxo, indicando que o cartão do cliente tem crédito. Neste caso, um pedido pode passar do estado Aguardando Pagamento para Pago, sem interferência humana direta. Finalizando, a indicação é estar atento não apenas a termos específicos, mas também a entidades que dependem de pessoas para executar alguma ação, como enviar para o chefe analisar. Sistema AmoWorkflows S/A Para ilustrar estas práticas, consideraremos uma descrição de um sistema fictício. Tratase de uma aplicação que contém apenas dois documentos: um Relatório Diário e um Relatório Especial. O primeiro é um documento que é gerado diariamente por analistas da empresa AmoWorkflows S/A. O segundo é um relatório gerado ao final do mês pelos chefes de setor. O cliente deste sistema descreve-o da seguinte forma para o analista de sistemas: Preciso de um sistema que gerencie dois documentos de minha empresa. Um documento chamado Relatório Diário, que é criado pelos analistas todos os dias e que depois são enviados para revisão da sua chefia imediata. Após revisar, o Relatório Diário deve ser enviado para a Aprovação da chefia do setor. Já o segundo documento é um Relatório Especial, criado pelas chefias imediatas mensalmente e enviado para o Parecer do chefe do setor. Logo após isto, o chefe do setor envia para a aprovação do gerente da empresa. Esta etapa de aprovação é idêntica à aprovação do Relatório Diário. Nenhum relatório pode ser aprovado caso o usuário não tenha informado seu detalhamento. Todo relatório também deve ter preenchida automaticamente a data de aprovação. Finalmente, todos os relatórios são classificados como público ou restrito e ainda há o envio de s para as pessoas responsáveis em executar cada tarefa. Desta descrição, pode-se encontrar facilmente alguns casos de uso, sendo eles: 13
14 Relatório Diário Manter Relatório Diário; Enviar Relatório Diário para Revisão; Revisar Relatório Diário; Rejeitar Relatório Diário; Enviar Relatório Diário para Aprovação; Aprovar Relatório Diário; Reprovar Relatório Diário. Relatório Especial Manter Relatório Especial; Enviar Relatório Especial para Parecer; Dar Parecer no Relatório Especial; Enviar Relatório Especial para Aprovação; Aprovar Relatório Especial; Reprovar Relatório Especial. Modelando este sistema com os conceitos de Workflow, teremos estados, tarefas e transições entre estes estados. A Ilustração 3 apresenta a forma gráfica que representa o fluxo de trabalho para o documento Relatório Diário. Ilustração 3: Representação Gráfica do Fluxo do Relatório Diário. 14
15 A Ilustração 4 apresenta, utilizando a mesma notação gráfica do Relatório Diário, a representação do fluxo de trabalho do Relatório Especial. Ilustração 4: Representação Gráfica do Fluxo do Relatório Especial. Ajudando o Analista de Requisitos Deve-se considerar a área de requisitos inicialmente, pois trata-se da primeira etapa da construção de todo sistema. Aqui são apresentadas práticas que visam a construir casos de uso mais genéricos e o principal ganho é na produtividade. Aqui, nenhuma técnica de elicitação nova foi criada, ao contrário, algumas foram apenas mais evidenciadas, pois trazem ganhos para os sistemas de Workflow. Serão apresentadas apenas três práticas consideradas mais importantes. Generalizando os Casos de Uso Generalização é um conceito bastante comum na engenharia de software, principalmente na fase de construção de código. Atribui-se a ela muitos ganhos, pois partes comuns são agrupadas em uma única entidade, evitando a repetição. Em requisitos, no entanto, vê-se pouco o seu uso. Tende-se a construir diversos casos de uso, um para cada situação descrita pelo cliente, sem analisar friamente se existem casos de uso que podem ser generalizados. Isto é importante principalmente em sistemas de Workflows, pois é comum ocorrer a repetição de atividades em diversas instâncias de fluxos diferentes. Conforme o exemplo apresentado nesta seção, pode-se perceber que os dois documentos transitam entre 15
16 estados diferentes, mas possuem tarefas parecidas, ou até mesmo iguais. Ambos relatórios necessitam de aprovação e geraram dois ECUs chamados, respectivamente, Aprovar Relatório Especial e Aprovar Relatório Diário. Neste contexto, a melhor prática para esta situação consiste em tentar generalizar em um único ECU o comportamento geral da atividade Aprovar. Nome do Caso de Uso Aprovar Relatório Diário e Relatório Especial Objetivo Aprovar os documentos Relatório Diário e Relatório Especial. Atores Analista, Chefe de Setor, Chefia Imediata Pré-condições O documento a ser aprovado deve se encontrar na situação A Aprovar. Fluxo Principal P1. Solicitar Aprovação Na tela de edição do documento, o Ator opta por Aprovar o documento. P2. Solicitar Confirmação O sistema exibe mensagem solicitando confirmação da aprovação. P3. Confirmar Aprovação O Ator confirma a aprovação. P4. Gravar Dados P4.1. Inclusão do Caso de Uso Validar Campos de Formulário P4.2. O sistema grava os dados e altera a situação do documento para Aprovado. P4.3. O sistema numera o documento. P4.4. O sistema grava o histórico conforme LEL. P5. Enviar Fluxos Alternativos A1. Aprovar Relatório Diário Se no passo P4, o documento for do tipo Relatório Diário: A1.1. O sistema envia para a Chefia Imediata. A1.2. O fluxo retorna ao passo P4.2. A2. Aprovar Relatório Especial Se no passo P4, o documento for do tipo Relatório Especial: A2.1. O sistema envia para todos funcionários do setor. A2.2. O fluxo retorna ao passo P4.2. Tabela 2: Definição do ECU de Aprovação. A Tabela 2 demonstra, de forma bastante resumida, como o ECU de aprovação pode ser 16
17 idealizado com esta ideia. Observa-se que as questões específicas para cada documento podem ser referenciadas na seção de fluxos alternativos, evitando a criação de dois ECUs, uma vez que seus fluxos principais são iguais, mudando apenas questões simples de regra de negócio. Embora possa parecer uma prática bastante simples e seus ganhos contestáveis, considerando sistemas com mais de dez documentos e que possuem semelhanças em suas atividades, esta prática tende a diminuir consideravelmente o número de casos de uso. De fato, para sistemas pequenos, talvez não haja ganhos visíveis. Mas, neste caso, cabe também avaliar se a tecnologia de Workflows é realmente necessária para criá-lo. Casos de Uso Modulares Embora a ideia de modularizar alguns tipos de casos de uso possa parecer idêntica à ideia de generalização, existem diferenças e tratam-se de práticas complementares. Existem outros padrões também comuns em sistema de fluxo de trabalho, como o envio de correios eletrônico ou a atribuição de papeis de forma dinâmica. Neste caso, pode-se criar ECUs específicos para estes padrões comportamentais, apenas referenciado-os quando necessário nos casos de uso mais específicos. Por exemplo, o ECU Aprovar Relatório Especial pode referenciar diretamente estes dois ECUs citados. Regras de Negócio por Entidade/Ação O documento de regras de negócio não possui um padrão para ser criado, contendo os tópicos necessários e o formato do texto. Cabe ao analista definir a melhor forma junto ao seu cliente. Em um sistema de Workflow, entretanto, algumas características levam a considerar a possibilidade de se adotar um padrão comum. Todo fluxo de trabalho possui ações a serem executadas, sejam por humanos ou por uma máquina. Também possuem entidades que sofrem estas ações. Por exemplo, o documento Relatório Diário sofre a ação Aprovar. Em um sistema de notícias, uma Notícia sofre a ação de Revisão, uma passagem sofre a ação de Aprovação em um sistema de reserva de passagens. 17
18 1. Relatório Diário 1. Enviar para Aprovação Descrever as regras de negócio desta ação. 2. Aprovar Descrevar as regras de negócio desta ação. Tabela 3: Documento de Regras de Negócio. Assim, é indicado que as regras de negócio do sistema venham a ter dois níveis de divisão. A primeira, por entidade que sofre a ação, como o Relatório Diário. A segunda, por ação. A Tabela 3 ilustra simplificadamente esta ideia. Esta ação reforça a qualidade do artefato gerado. Análise, Projeto e Codificação As etapas de análise e projeto beneficiam-se de práticas bastante difundidas na área. A principal delas diz respeito à componentização. Já a etapa de codificação beneficia-se basicamente na utilização de uma engine, além das práticas comuns e bastante difundidas de programação. Os ganhos de uma área beneficiam diretamente a outra, portanto, esta seção discutirá as técnicas independente de área da engenharia. Aqui, observa-se um forte ganho na robustez do produto, adotando soluções consolidadas de mercado e práticas reconhecidas. Componentes A ideia de criar sistemas componentizados é antiga, embora pouco praticada. Os teóricos na área afirmam a necessidade de se modularizar, visando dividir o problema em partes mais compreensíveis e de fácil manutenção. Na área de Workflows a componentização assume papel de fundamental importância tanto na programação, como na definição da arquitetura. No sistema sugerido nesta seção, pode-se verificar alguns requisitos pedidos pelo cliente, como o envio de correios eletrônicos, documentos que são classificados entre público e restrito, validados, complementados com informações extras e, finalmente, tem seus dados persistidos em um banco de dados. Analistas experientes materializam estes requisitos em alguns componentes, como: Componente de Validação, Componente de Complementação, Componente de Classificação, Componente de Persistência e 18
19 Componente de Envio de Correio Eletrônico. Todos podem agir de forma independente e podem ter seu comportamento definido de diversas formas, como em arquivos no formato extensible Markup Language (XML, 2010) ou em através de código na linguagem no qual o sistema foi concebido. A prática de componentizar comportamentos gerais facilita sobremaneira a realização de casos de uso que adotam diagramas de sequência. Ilustração 5: Diagrama de Sequência Simplificado. A Ilustração 5 apresenta um diagrama de sequência bastante simplificado de uma possível realização de caso de uso, como a aprovação dos Relatórios. Observa-se que todos os documentos poderão ter diagramas de sequência parecidos com este, mudando apenas a ordem de chamada dos componentes. Assim, é possível agrupar diagramas de sequência em comum. Por exemplo, basta apenas a criação de um diagrama de sequencia para todos os documentos que possuem a necessidade de Aprovação, pois a sequência de componentes e a forma como são chamados apresenta-se sempre a mesma. Para a criação dos componentes, é indicado ao analista verificar comportamentos em comum a muitas entidades. Como exemplo, caso dois ou três documentos tenham necessidade de classificação, cabe criar um componente específico para isto. Utilização de Engines Quanto à programação do sistema é fortemente indicado que uma engine de Workflow seja adotada. Isto evitará o problema já destacado, no qual código de negócio apresentase entrelaçado com código para o controle do fluxo de trabalho. Uma engine abstrai todos 19
20 estes aspectos, controlando o fluxo e a atribuição de tarefas para os usuários. Um estudo deve ser realizado visando a detectar aquela que melhor se encaixa ao projeto em criação. Deve-se considerar as características da engine, as facilidades que ela provê, se segue padrões abertos e amplamente difundidos e, preferencialmente, se é código aberto. Há uma gama enorme de mecanismos deste tipo disponibilizados pelos comunidades de código aberto e este fato deve ser aproveitado. No momento de escolha da engine, a equipe pode usar como guia os seguintes aspectos: 1. Licença Livre; 2. Ampla documentação, contendo JavaDoc; 3. Adota como linguagem de definição de processos a BPMN2; 4. Possuir ferramenta gráfica para criação de processos; 5. Comunidade ativa; 6. Facilitar a criação de componentes para acoplamento à engine; 7. Integração com diretórios de usuário, como LDAP. Esta lista não esgota o assunto e, portanto, a depender do projeto, novos aspectos devem ser levantados e agregados. Usar uma engine de mercado reforça o reuso de soluções abertas e já consolidadas no mercado, agregando maior confiabilidade ao produto final, além de um grande ganho de produtividade. EXEMPLOS SÃO MELHORES QUE MIL PALAVRAS Esta seção tem como objetivo apresentar um estudo de caso interno ao Serpro, no qual a equipe de desenvolvimento responsável pelo sistema adotou as práticas citadas na seção anterior para a modelagem e programação de um aplicativo com características de Workflow. Trata-se de um sistema criado para a Receita Federal do Brasil. Devido ao caráter altamente sigiloso do sistema, o cliente não permitiu que documentos reais do sistema fossem utilizados neste trabalho. Portanto, serão realizadas substituições gráficas e documentais, embora os exemplos apresentados ainda estejam refletindo o sistema real. O objetivo deste sistema, de forma bastante resumida, baseia-se no gerenciamento dos 20
21 documentos que permeiam o processo de investigação da Receita Federal do Brasil. O sistema foi idealizado para ser executado em um ambiente Java e acessado através de navegadores web. O cerne deste sistema baseia-se nos trâmites de mais de vinte (20) documentos, cada qual com suas ações específicas. Cada documento possui, em média, cinco ações que podem ser executadas por pessoas. Neste cenário, tem-se aproximadamente cerca de cem (100) ações diferentes em todo o sistema. Considerando a própria complexidade do sistema, mas também a necessidade em concluir a sua confecção dentro do prazo, a equipe realizou um estudo inicial, no qual o objetivo foi identificar um Motor de Workflow que fosse capaz de dar suporte à aplicação. A engine escolhida foi a OSWorkflow (OSWORKFLOW, 2010) da empresa OpenSymphony. Uma vez definido o software, necessitou-se identificar a melhor forma possível para elicitar os requisitos, assim como para a realização de casos de uso, conforme determinado pela versão vigente do Processo de Desenvolvimento de Software do Serpro (PSDS, 2010), chegando às práticas já descritas na seção anterior. Esta etapa demonstrou-se de extrema importância, uma vez que o sistema apresentava cerca de cento e noventa (190) casos de uso, além de um documento de Regras de Negócio que alcançava cerca de duzentas (200) páginas. Neste contexto, havia uma necessidade urgente de adotar um padrão, ou prática, que visasse agilizar a etapa de elicitação de requisitos, sem comprometer a qualidade dos documentos gerados por esta área da engenharia de software. Notou-se que era possível generalizar muitas ações realizadas nos documentos e, portanto, foram criados ECUs genéricos e modulares. A Ilustração 6 apresenta a quantidade total de ECUs necessários caso esta prática não fosse adotada, em contrapartida com a adoção desta prática. 21
GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas
PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas
Leia mais3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio
32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio
Leia maisSistema de Controle de Solicitação de Desenvolvimento
Sistema de Controle de Solicitação de Desenvolvimento Introdução O presente documento descreverá de forma objetiva as principais operações para abertura e consulta de uma solicitação ao Setor de Desenvolvimento
Leia maisDesenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA
Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos
Leia maisManual SAGe Versão 1.2 (a partir da versão 12.08.01)
Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação
Leia maisPROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às
Leia maisSISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl
SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo
Leia maisBPMN (Business Process. George Valença gavs@cin.ufpe.br
BPMN (Business Process Modeling Notation) George Valença gavs@cin.ufpe.br 31/10/2012 Introdução Modelagem de processos No ciclo de vida BPM, a etapa de modelagem de processos consiste em um conjunto de
Leia mais2 Diagrama de Caso de Uso
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa
Leia mais5 Exemplo de aplicação
111 5 Exemplo de aplicação Este capítulo apresenta um exemplo de uso da linguagem proposta como forma de validação. Através da implementação da linguagem utilizando o potencial de extensão da ferramenta
Leia maisHistórico da Revisão. Data Versão Descrição Autor
Sistema de Gerenciamento de Loja - SIGEL Documento de Visão Versão 1.0.0 Histórico da Revisão Data Versão Descrição Autor 13/01/2011 0.1 Versão preliminar do levantamento de requisitos funcionais e não
Leia maisApesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma:
1 Introdução A utilização de frameworks como base para a construção de aplicativos tem sido adotada pelos desenvolvedores com três objetivos básicos. Primeiramente para adotar um padrão de projeto que
Leia maisEngenharia de Software III
Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,
Leia maisHistórico de Revisão Data Versão Descrição Autor
H6Projetos Documento de Requisitos Versão 1.3 Histórico de Revisão Data Versão Descrição Autor 05/09/2013 1.0 Preenchimento do Capítulo 2 Requisitos Funcionais Evilson Montenegro 26/09/2013 1.1 Preenchimento
Leia maisGerenciamento de Problemas
Gerenciamento de Problemas O processo de Gerenciamento de Problemas se concentra em encontrar os erros conhecidos da infra-estrutura de TI. Tudo que é realizado neste processo está voltado a: Encontrar
Leia maisPrograma do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA)
Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Apresentação O programa de Pós-graduação Lato Sensu em Engenharia de Software Orientada a Serviços
Leia maisManual Geral do OASIS
Manual Geral do OASIS SISTEMA DE GESTÃO DE DEMANDA, PROJETO E SERVIÇO DE TECNOLOGIA DA INFORMAÇÃO OASIS Introdução Esse manual tem como objetivo auxiliar aos usuários nos procedimentos de execução do sistema
Leia maisSumário. Apresentação O que é o Centro de Gerenciamento de Serviços (CGS) NTI? Terminologia Status do seu chamado Utilização do Portal Web
Sumário Apresentação O que é o Centro de Gerenciamento de Serviços (CGS) NTI? Terminologia Status do seu chamado Utilização do Portal Web Fazendo Login no Sistema Tela inicial do Portal WEB Criando um
Leia maisEngenharia de Requisitos Estudo de Caso
Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este
Leia maisManual de Utilização
Manual de Utilização Versão 1.0 18/01/2013 Sempre consulte por atualizações deste manual em nossa página. O Cotação Web está em constante desenvolvimento, podendo ter novas funcionalidades adicionadas
Leia maisSUMÁRIO Acesso ao sistema... 2 Atendente... 3
SUMÁRIO Acesso ao sistema... 2 1. Login no sistema... 2 Atendente... 3 1. Abrindo uma nova Solicitação... 3 1. Consultando Solicitações... 5 2. Fazendo uma Consulta Avançada... 6 3. Alterando dados da
Leia maisRegistro e Acompanhamento de Chamados
Registro e Acompanhamento de Chamados Contatos da Central de Serviços de TI do TJPE Por telefone: (81) 2123-9500 Pela intranet: no link Central de Serviços de TI Web (www.tjpe.jus.br/intranet) APRESENTAÇÃO
Leia maisIMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR
IMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR Jeferson J. S. Boesing 1 ; Manassés Ribeiro 2 1.Aluno do Curso
Leia maisPRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)
RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,
Leia maisPesquisa com Professores de Escolas e com Alunos da Graduação em Matemática
Pesquisa com Professores de Escolas e com Alunos da Graduação em Matemática Rene Baltazar Introdução Serão abordados, neste trabalho, significados e características de Professor Pesquisador e as conseqüências,
Leia maisARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.
ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página
Leia maisPLANEJAMENTO DA MANUFATURA
58 FUNDIÇÃO e SERVIÇOS NOV. 2012 PLANEJAMENTO DA MANUFATURA Otimizando o planejamento de fundidos em uma linha de montagem de motores (II) O texto dá continuidade à análise do uso da simulação na otimização
Leia maisTRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES
TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado
Leia maisDocumento de Arquitetura
Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento
Leia maisROTEIRO PARA ELABORAÇÃO DE PROJETOS
APRESENTAÇÃO ROTEIRO PARA ELABORAÇÃO DE PROJETOS Breve histórico da instituição seguido de diagnóstico e indicadores sobre a temática abrangida pelo projeto, especialmente dados que permitam análise da
Leia maisMANUAL DO USUÁRIO SORE Sistema Online de Reservas de Equipamento. Toledo PR. Versão 2.0 - Atualização 26/01/2009 Depto de TI - FASUL Página 1
MANUAL DO USUÁRIO SORE Sistema Online de Reservas de Equipamento Toledo PR Página 1 INDICE 1. O QUE É O SORE...3 2. COMO ACESSAR O SORE... 4 2.1. Obtendo um Usuário e Senha... 4 2.2. Acessando o SORE pelo
Leia mais4 O Workflow e a Máquina de Regras
4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu
Leia maisSatélite. Manual de instalação e configuração. CENPECT Informática www.cenpect.com.br cenpect@cenpect.com.br
Satélite Manual de instalação e configuração CENPECT Informática www.cenpect.com.br cenpect@cenpect.com.br Índice Índice 1.Informações gerais 1.1.Sobre este manual 1.2.Visão geral do sistema 1.3.História
Leia maisPR 2 PROCEDIMENTO. Auditoria Interna. Revisão - 2 Página: 1 de 9
Página: 1 de 9 1. OBJETIVO Estabelecer sistemática de funcionamento e aplicação das Auditorias Internas da Qualidade, fornecendo diretrizes para instruir, planejar, executar e documentar as mesmas. Este
Leia mais1. Tela de Acesso pg. 2. 2. Cadastro pg. 3. 3. Abas de navegação pg. 5. 4. Abas dados cadastrais pg. 5. 5. Aba grupo de usuários pg.
Sumário 1. Tela de Acesso pg. 2 2. Cadastro pg. 3 3. Abas de navegação pg. 5 4. Abas dados cadastrais pg. 5 5. Aba grupo de usuários pg. 6 6. Aba cadastro de funcionários pg. 7 7. Pedidos pg. 12 8. Cartões
Leia maisA construção de um manual sobre a utilização dos modelos também poderá alavancar o uso das representações. Este conteria a explicação detalhada da
6 Conclusões No âmbito do framework teórico da Engenharia Semiótica, este trabalho faz parte de um esforço conjunto para desenvolver ferramentas epistêmicas que apóiem a reflexão do designer durante o
Leia maisFase 1: Engenharia de Produto
Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os
Leia maisUNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação
SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar
Leia maisPlano de Gerenciamento do Projeto
Projeto para Soluções Contábeis 2015 Plano de Gerenciamento do Projeto Baseado na 5ª edição do Guia PMBOK Brendon Genssinger o e Elcimar Silva Higor Muniz Juliermes Henrique 23/11/2015 1 Histórico de alterações
Leia maisDocumento de Análise e Projeto VideoSystem
Documento de Análise e Projeto VideoSystem Versão Data Versão Descrição Autor 20/10/2009 1.0 21/10/2009 1.0 05/11/2009 1.1 Definição inicial do documento de análise e projeto Revisão do documento
Leia maisFootprints Service Core. Manual de uso do sistema
Footprints Service Core Manual de uso do sistema Sumário Acessando o sistema... 3 Visão geral... 4 Criação de chamados... 5 Acompanhamento de chamados... 7 Compartilhamento de chamados... 8 Notificações...
Leia maisACOMPANHAMENTO GERENCIAL SANKHYA
MANUAL DE VISITA DE ACOMPANHAMENTO GERENCIAL SANKHYA Material exclusivo para uso interno. O QUE LEVA UMA EMPRESA OU GERENTE A INVESTIR EM UM ERP? Implantar um ERP exige tempo, dinheiro e envolve diversos
Leia maisManual do usuário - Service Desk SDM - COPASA. Service Desk
Manual do usuário - Service Desk SDM - COPASA Service Desk Sumário Apresentação O que é o Service Desk? Terminologia Status do seu chamado Utilização do Portal Web Fazendo Login no Sistema Tela inicial
Leia maisParte I. Demoiselle Mail
Parte I. Demoiselle Mail Para o envio e recebimento de e-s em aplicativos Java, a solução mais natural é usar a API JavaMail [http:// www.oracle.com/technetwork/java/java/index.html]. Ela provê um framework
Leia maisMicrosoft Access XP Módulo Um
Microsoft Access XP Módulo Um Neste primeiro módulo de aula do curso completo de Access XP vamos nos dedicar ao estudo de alguns termos relacionados com banco de dados e as principais novidades do novo
Leia maisDESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES
DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.
Leia maisConteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Leia maisGuia de Especificação de Caso de Uso Metodologia CELEPAR
Guia de Especificação de Caso de Uso Metodologia CELEPAR Agosto 2009 Sumário de Informações do Documento Documento: guiaespecificacaocasouso.odt Número de páginas: 10 Versão Data Mudanças Autor 1.0 09/10/2007
Leia mais3. Fase de Planejamento dos Ciclos de Construção do Software
3. Fase de Planejamento dos Ciclos de Construção do Software A tarefa de planejar os ciclos de construção do software pode partir de diretrizes básicas. Estas diretrizes visam orientar que os ciclos de
Leia maisGestão inteligente de documentos eletrônicos
Gestão inteligente de documentos eletrônicos MANUAL DE UTILIZAÇÃO VISÃO DE EMPRESAS VISÃO EMPRESAS - USUÁRIOS (OVERVIEW) No ELDOC, o perfil de EMPRESA refere-se aos usuários com papel operacional. São
Leia maisFATEC Cruzeiro José da Silva. Ferramenta CRM como estratégia de negócios
FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Cruzeiro SP 2008 FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Projeto de trabalho de formatura como requisito
Leia maiswww.f2b.com.br 18/04/2006 Micropagamento F2b Web Services Web rev 00
www.f2b.com.br 18/04/2006 Micropagamento F2b Web Services Web rev 00 Controle de Revisões Micropagamento F2b Web Services/Web 18/04/2006 Revisão Data Descrição 00 17/04/2006 Emissão inicial. www.f2b.com.br
Leia maisFeature-Driven Development
FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por
Leia maisGARANTIA DA QUALIDADE DE SOFTWARE
GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características
Leia maisRock In Rio - Lisboa
Curso de Engenharia Informática Industrial Rock In Rio - Lisboa Elaborado por: Ano Lectivo: 2004/05 Tiago Costa N.º 4917 Turma: C Gustavo Graça Patrício N.º 4757 Turma: C Docente: Professora Maria Estalagem
Leia maisProjeto SIGA-EPT. Manual do usuário Módulo Requisição de Almoxarifado SISTEMA INTEGRADO DE GESTÃO ACADÊMICA
Projeto SIGA-EPT Manual do usuário Módulo Requisição de Almoxarifado SISTEMA INTEGRADO DE GESTÃO ACADÊMICA Versão setembro/2010 Requisição de Almoxarifado Introdução Requisição é uma solicitação feita
Leia maisProcessos Técnicos - Aulas 4 e 5
Processos Técnicos - Aulas 4 e 5 Trabalho / PEM Tema: Frameworks Públicos Grupo: equipe do TCC Entrega: versão digital, 1ª semana de Abril (de 31/03 a 04/04), no e-mail do professor (rodrigues.yuri@yahoo.com.br)
Leia maisFACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>
FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido
Leia maisAnálise e Projeto Orientados por Objetos
Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender
Leia maisW Projeto. Gerenciamento. Construindo a WBS e gerando o Cronograma. Autor: Antonio Augusto Camargos, PMP 1/12
W Projeto BS Construindo a WBS e gerando o Cronograma. Gerenciamento Autor: Antonio Augusto Camargos, PMP 1/12 Índice Remissivo Resumo...3 1. Introdução...3 2. Conceituando a WBS (Work Breakdown Structure/Estrutura
Leia maisPag: 1/20. SGI Manual. Controle de Padrões
Pag: 1/20 SGI Manual Controle de Padrões Pag: 2/20 Sumário 1 Introdução...3 2 Cadastros Básicos...5 2.1 Grandezas...5 2.2 Instrumentos (Classificação de Padrões)...6 3 Padrões...9 3.1 Padrão Interno...9
Leia maisGestão de Processos de Negócios
Gestão Operacional da TI Gestão de Processos de Negócios Business Process Management (BPM) Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Professor NOME: RÔMULO CÉSAR DIAS DE ANDRADE
Leia mais1 Sumário... 2. 2 O Easy Chat... 3. 3 Conceitos... 3. 3.1 Perfil... 3. 3.2 Categoria... 3. 4 Instalação... 5. 5 O Aplicativo... 7 5.1 HTML...
1 Sumário 1 Sumário... 2 2 O Easy Chat... 3 3 Conceitos... 3 3.1 Perfil... 3 3.2 Categoria... 3 3.3 Ícone Específico... 4 3.4 Janela Específica... 4 3.5 Ícone Geral... 4 3.6 Janela Geral... 4 4 Instalação...
Leia maisANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação.
ANEXO 11 O MATRIZ Para o desenvolvimento de sites, objeto deste edital, a empresa contratada obrigatoriamente utilizará o framework MATRIZ desenvolvido pela PROCERGS e disponibilizado no início do trabalho.
Leia maisEspecificação do 3º Trabalho
Especificação do 3º Trabalho I. Introdução O objetivo deste trabalho é abordar a prática da programação orientada a objetos usando a linguagem Java envolvendo os conceitos de classe, objeto, associação,
Leia maisCurva ABC. Tecinco Informática Ltda. Av. Brasil, 5256 3º Andar Centro Cascavel PR www.tecinco.com.br
Curva ABC Tecinco Informática Ltda. Av. Brasil, 5256 3º Andar Centro Cascavel PR www.tecinco.com.br Sumário Introdução... 3 Utilização no sistema TCar-Win... 3 Configuração da curva ABC... 4 Configuração
Leia maisISO/IEC 12207: Gerência de Configuração
ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que
Leia maisFACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação
FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE
Leia maisPós-Graduação em Gerenciamento de Projetos práticas do PMI
Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL
Leia maisResolução da lista de exercícios de casos de uso
Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se
Leia maisOrientação a Objetos
1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou
Leia maisINTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN
INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 1 INTRODUÇÃO A Business Process Modeling Notation (BPMN), ou Notação de Modelagem de Processos de Negócio, é um conjunto de
Leia maisDocumento de Requisitos
Documento de Requisitos Projeto: Data 26/05/2005 Responsável Autor (s) Doc ID Localização Versão do Template Márcia Jacyntha Nunes Rodrigues Lucena Silvia Cássia Pereira Márcia Jacyntha Nunes Rodrigues
Leia maisSumário. Uma visão mais clara da UML
Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da
Leia maisTUTORIAL DO ALUNO. Olá, bem vindo à plataforma de cursos a distância da Uniapae!!!
TUTORIAL DO ALUNO Olá, bem vindo à plataforma de cursos a distância da Uniapae!!! O Moodle é a plataforma de ensino a distância utilizada pela Uniapae sendo a unidade de ensino para rápida capacitação
Leia maisMódulo de Usuário 04 Orientações para o Uso 05 Acessando as Salas 06 Dentro do Ambiente das Salas 08 (1) Outros Usuários 09 (2) Seus Dados 09 (3)
O recurso das Salas Virtuais é parte da estratégia adotada pelo Órgão Gestor da Política Nacional de Educação Ambiental para estimular e fortalecer a participação de grupos, coletivos e colegiados no processo
Leia maisApós a confirmação de pagamento de sua inscrição para o congresso, você estará apto a entrar no sistema de submissão de trabalho.
Para submissão de trabalhos é necessário que você esteja inscrito no evento. Você deve realizar seu cadastro acessando a opção Cadastrar, quando disponível. É imprescindível que você guarde suas informações
Leia mais5 Estudo de caso: utilizando o sistema para requisição de material
61 5 Estudo de caso: utilizando o sistema para requisição de material A fim de avaliar as características da arquitetura proposta e a corretude da implementação, realizamos experiências com cenários de
Leia maisGuia de utilização da notação BPMN
1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação
Leia maisPEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0
PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.
Leia maisEm 2012, a Prosoft planejou o lançamento da Versão 5 dos seus produtos.
VERSÃO 5 Outubro/2012 Release Notes Não deixe de atualizar o seu sistema Planejamos a entrega ao longo do exercício de 2012 com mais de 140 melhorias. Mais segurança, agilidade e facilidade de uso, atendendo
Leia maisGovernança de TI. ITIL v.2&3. parte 1
Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços
Leia maisMANUAL DE UTILIZAÇÃO
MANUAL DE UTILIZAÇÃO Módulo de operação Ativo Bem vindo à Vorage CRM! Nas próximas paginas apresentaremos o funcionamento da plataforma e ensinaremos como iniciar uma operação básica através do nosso sistema,
Leia maisO modelo unificado de processo. O Rational Unified Process, RUP.
Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,
Leia maisSistema de HelpDesk da SESAU Guia do Usuário
Secretaria de Estado da Saúde de Alagoas SESAU Coordenadoria Setorial de Gestão a Informática - CSGI Sistema de HelpDesk da SESAU Guia do Usuário Maceió 06/02/2012 Técnico Responsável: Bruno Cavalcante
Leia maisGerenciamento de Projetos no Marketing Desenvolvimento de Novos Produtos
Gerenciamento de Projetos no Marketing Desenvolvimento de Novos Produtos Por Giovanni Giazzon, PMP (http://giazzon.net) Gerenciar um projeto é aplicar boas práticas de planejamento e execução de atividades
Leia maisConceitos de Banco de Dados
Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir
Leia maisGestão do Conhecimento A Chave para o Sucesso Empresarial. José Renato Sátiro Santiago Jr.
A Chave para o Sucesso Empresarial José Renato Sátiro Santiago Jr. Capítulo 1 O Novo Cenário Corporativo O cenário organizacional, sem dúvida alguma, sofreu muitas alterações nos últimos anos. Estas mudanças
Leia maisManual Operacional SIGA
SMS - ATTI Julho -2012 Conteúdo Sumário... 2... 3 Consultar Registros... 4 Realizar Atendimento... 9 Adicionar Procedimento... 11 Não Atendimento... 15 Novo Atendimento... 16 Relatórios Dados Estatísticos...
Leia maisEstratégia de TI. Posicionamento Estratégico da TI: como atingir o alinhamento com o negócio. Conhecimento em Tecnologia da Informação
Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação Estratégia de TI Posicionamento Estratégico da TI: como atingir o alinhamento com o negócio 2011 Bridge Consulting Apresentação
Leia maisMAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO
MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO UTILIZANDO O HIBERNATE Rafael Laurino GUERRA, Dra. Luciana Aparecida Martinez ZAINA Faculdade de Tecnologia de Indaiatuba FATEC-ID 1 RESUMO Este artigo apresenta
Leia maisCapítulo 6. Criando um Diagrama de Caso de Uso Inicial
Capítulo 6 Criando um Diagrama de Caso de Uso Inicial Mapa do Processo Por que Necessitamos de Um Diagrama de Casos de Uso? Eis algumas razões da necessidade de um Diagrama de Casos de Uso: O SRS é preenchido
Leia maisGrécia Um Framework para gerenciamento de eventos científicos acadêmicos utilizando componentes
Grécia Um Framework para gerenciamento de eventos científicos acadêmicos utilizando componentes Resumo Este trabalho apresenta uma infra-estrutura para gerenciamento de eventos científicos acadêmicos na
Leia maisProjeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.
Projeto Demoiselle Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.net Palestrantes: Antônio Carlos Tiboni Luciana Campos Mota 20/07/2009
Leia maisSoftware de Compras. Manual de treinamento para usuários do OutBuyCenter
Software de Compras Manual de treinamento para usuários do OutBuyCenter OutBuyCenter Software para o gerenciamento de compras integradas (eprocurement e supply chain), objetiva a rápida tramitação de compras
Leia mais