Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação

Tamanho: px
Começar a partir da página:

Download "Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação"

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Estudo exploratório utilizando BPMN em um processo de Engenharia de Requisitos Diego de Aquino Soares Lino Salvatore Bordin Insfrán Monograa apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação Orientadora Prof. a Dr. a Genaína Nunes Rodrigues Brasília 2011

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação Bacharelado em Ciência da Computação Coordenador: Prof. Dr. Marcos Vinicius Lamar Banca examinadora composta por: Prof. a Dr. a Genaína Nunes Rodrigues (Orientadora) CIC/UnB Prof. a Dr. a Aletéia Patrícia Favacho de Araújo CIC/UnB Prof. Dr. Rodrigo Bonifácio de Almeida CIC/UnB CIP Catalogação Internacional na Publicação de Aquino Soares, Diego. Estudo exploratório utilizando BPMN em um processo de Engenharia de Requisitos / Diego de Aquino Soares, Lino Salvatore Bordin Insfrán. Brasília : UnB, p. : il. ; 29,5 cm. Monograa (Graduação) Universidade de Brasília, Brasília, Processo de Engenharia de Requisitos, 2. BPMN CDU Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP BrasíliaDF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Estudo exploratório utilizando BPMN em um processo de Engenharia de Requisitos Diego de Aquino Soares Lino Salvatore Bordin Insfrán Monograa apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação Prof. a Dr. a Genaína Nunes Rodrigues (Orientadora) CIC/UnB Prof. a Dr. a Aletéia Patrícia Favacho de Araújo CIC/UnB Prof. Dr. Rodrigo Bonifácio de Almeida CIC/UnB Prof. Dr. Marcos Vinicius Lamar Coordenador do Bacharelado em Ciência da Computação Brasília, 13 de julho de 2011

4 Agradecimentos Agradecemos a todos que nos ajudaram no decorrer do trabalho. A Professora Genaína que nos acompanhou durante todo o andamento da monograa, o George Valença que nos deu o tema exato a ser seguido e com isso uma direção quanto ao trabalho, ao professor e coordenador do CIC Marcus Vinicius Lamar que disponibilizou seu tempo e ajuda para que nosso trabalho desse prosseguimento da forma correta, ao Eduardo Rodrigues da Cunha e Giovânia Ferreira que aportaram várias bibliograas sobre BPM. A todos os nossos amigos, professores e companheiros de curso que nos ajudaram no decorrer da graduação com trabalhos, estudos, aulas e inclusive na parte da diversão. Diego e Lino Agradeço primeiramente a Deus por ter me dado forças e disposição nessa fase da minha vida. A minha família que esteve comigo todo esse tempo, os meus pais, a minha irmã Daniella e a minha namorada Viviane que sempre me apoiaram não deixando que eu desanimasse nos momentos ruins e o meu irmão Caio que me ajudou em alguns trabalhos do curso. Agradeço também os meus amigos Bruno Orsi, Charbel Chater, Gustavo Sekão Ramos, ao pessoal da banda e da bagunça, o meu grande amigo Lino que me ajudou muito nesse trabalho e no curso e a todos os que contribuíram para a minha formação acadêmica, prossional e pessoal. Diego Agradecimentos grandes a minha mãe, que apesar da distância, enviou forças que me ajudaram a continuar o projeto inicializado. Aos meus colegas de curso porque eles zeram com que conseguisse achar uma nova família. A Mai, pela paciência e por ser o complemento que me regulou nos momentos certos. O Ski, que sem ele, 90 % desta monograa não estaria feita. E, por último, meus amigos, que direta, ou indiretamente, inuenciaram no sucesso da realização deste trabalho. Lino iv

5 Resumo Este trabalho visa apresentar a utilização do BPMN (Business Process Modelling Notation), nas distintas fases do Processo de Engenharia de Requisitos. Isto será desenvolvido através de um estudo exploratório que trata uma problemática real no Departamento de Ciência da Computação da Universidade de Brasília, especicamente, o processo de alocação de salas de aula durante o início do semestre. Assim, será feito uma junção da metodologia do estudo de caso exploratório junto com a metodologia do Processo de Engenharia de Requisitos, onde se desenvolverá a partir de requisitos levantados diagramas feitos em BPMN que vão retratar dois cenários diferentes, um real (AS-IS) e um ideal (TO-BE). Como resultado nal deste trabalho teremos uma análise das hipóteses iniciais levantadas no primeiro capítulo e uns documentos de especicação que são o resultado da documentação dos diagramas, além de uns protótipos que vão retratar o possível formato de um futuro sistema que possa ser implementado no futuro. Palavras-chave: Processo de Engenharia de Requisitos, BPMN v

6 Abstract This work presents the use of BPMN (Business Process Modelling Notation) in the dierent phases of Requirements Engineering Process. This will be developed through an exploratory study that attend a real problem in the Department of Computer Science at the University of Brasilia (UnB), specically, the allocation process of classrooms during the beginning of the semester. So, will be use a join between the methodology of the exploratory case study and the methodology of the Requirements Engineering Process, which will be developed through the requirements raised from BPMN diagrams and it will portray two dierent scenarios, one real (AS-IS) and an ideal (TO-BE). As a nal result of this work is an analysis of the initial hypotheses raised in the rst chapter and some documents specication that are the result of the documentation of the diagrams, and few prototypes that will portray the possible visual of a system that can be implemented in the future. Keywords: Requirements Engineering Process, BPMN vi

7 Sumário 1 Introdução Descrição do Problema Hipótese(s) Objetivos O trabalho apresentado Referencial Teórico Processo de engenharia de requisitos Denição Estudo de viabilidade Elicitação e análise de requisitos Especicação de requisitos Validação de requisitos Gerenciamento de requisitos BPM Duas visões para o BPM Processos AS-IS e TO-BE Automação de Processos de Negócio BPMN Tipos de Diagramas BPMN Componentes de um diagrama BPMN Estudo de caso: Denição e Metodologia O que é um Estudo de Caso Natureza do estudo de caso Estudo de Caso Exploratório Estudo de Caso: Processo de alocação de salas Escolha do Tema Estudo de viabilidade Visão e escopo do CIC e do processo de alocação de salas Formulação do problema de pesquisa Denição dos Objetivos Formulação das hipóteses Estudo exploratório Coleta e análise de dados Elicitação e Análise de Requisitos vii

8 3.4.2 Especicação Etapas AS-IS e TO-BE Validação Especicação BPMN Processo AS-IS (Real) Descrição do Processo Processo TO-BE (Ideal) Descrição do Processo Discussões sobre o Estudo de Caso Análise Escolha do Tema e Estudo de Viabilidade Elicitação, Análise e Especicação de Requisitos Validação, Protótipos e Documentação BPMN e UML Validação de hipótese e Limitações Conclusão e Trabalhos futuros Conclusão Trabalhos futuros I Reuniões 60 I.1 Tabelas de reuniões I.1.1 Escolha do tema I.1.2 Reuniões com o Coordenador I.1.3 Aprovação de modelos Referências 63 viii

9 Lista de Figuras 2.1 Processo de Engenharia de Requisitos [29] Pools e Lanes [30] Representação gráca dos eventos [30] Tipos de eventos [30] Gateways [30] Atividades [30] Artefatos [30] Conectores [30] Distribuição das disciplinas do CIC por dia e período Diagrama do processo real de alocação de salas (AS-IS) Diagrama do processo ideal de alocação de salas (TO-BE) Fluxo do Processo TO-BE que indica as telas do protótipo Tela menu do protótipo Tela para inclusão de disciplinas Tela para inclusão de preferências Tela para pré-alocação de matérias Tela nal do sistema Token I do diagrama real Token II do diagrama real Token III do diagrama real Token IV do diagrama real Token I do diagrama ideal Token II do diagrama ideal Token III do diagrama ideal Token IV do diagrama ideal Exemplo de BPMN do processo de alocação de salas Exemplo de UML do processo de alocação de salas ix

10 Lista de Tabelas I.1 Cronograma de reuniões para delimitação de um tema viável I.2 Cronograma das reuniões com o coordenador I.3 Cronograma da apresentação do cenário obtido I.4 Cronograma da fase de validação do processo real de alocação de salas I.5 Cronograma da fase de validação do processo ideal de alocação de salas.. 62 x

11 Capítulo 1 Introdução Como bem foi citado no European Software Process Improvement Training Initiative, em 1996, "Os principais problemas que acontecem nas áreas de desenvolvimento e produção de software são a especicação de requisitos e o gerenciamento de requisitos do cliente" [29]. Desde que se inicia o curso de Ciência da Computação aparecem matérias que tratam sobre a otimização de resultados, que no ponto de vista do curso, tratam-se na maioria das vezes do código em si mais do que outros fatores. Com o decorrer do tempo, são vistos outros tipos de problemas que fazem parte do desenvolvimento propriamente dito e que afetam visívelmente a qualidade e o tempo destinado a criação de sistemas. Além disso, com a ajuda de estágios, é possível notar outros aspectos fundamentais dentro da informática presente no mercado. Ao trabalhar próximo aos clientes e aos usuários nais percebe-se a importância de criar um produto ou serviço que atenda as necessidades de todos eles, onde se preza mais pela comunicação entre as duas partes (cliente - produtor) do que o meio em como o trabalho será feito. Isto leva a várias ideias, dentre as quais uma delas viu-se reforçada com os dados que mostram que achar e solucionar um problema de software depois da entrega é quase 100 vezes mais caro do que achá-lo e resolvê-lo durante a fase de requisitos [5]. Um dos impedimentos que está presente para os programadores ou criadores de sistemas é receber uma documentação adequada em relação aos requisitos levantados por parte dos analistas. Estes requisitos, podem ser expostos por meio de diagramas, casos de usos, ou por outras técnicas. Existe um distanciamento entre os usuários e os desenvolvedores, além de uma baixa aderência dos sistemas aos processos de negócio. A maior barreira na obtenção ou denição de requisitos com qualidade é a lacuna de cultura existente entre usuários e engenheiros de requisitos [11]. Duas características dos engenheiros de requisitos que contribuem para essa lacuna são: pouco conhecimento do negócio e um ponto de vista de engenharia de requisitos excessivamente técnica. Perante essa situação surgiram novas tecnologias para tratar essas diculdades encontradas por eles. Até agora não se tem uma decisão unânime que possa apontar a melhor técnica, mas nota-se que determinadas empresas estão apostando em novas tecnologias que surgem no mercado. Dentre elas, tem-se o BPM (sigla em inglês para Business Process Management ). Ao se tratar de uma ferramenta de gerenciamento, ela estuda áreas que interessam à Engenharia de Requisitos, a de Processos de Négocios e o gerenciamento em si destes 1

12 processos. É possível encontrar na bibliograa vários documentos que tratam sobre o Gerenciamento de Processos de Negócios (BPM), pois se trata de uma área com relativa maturidade [31] [37]. No entanto, somente em 2004, foi lançada a primeira documentação do BPMN (sigla em inglês para Business Process Modeling Notation) [35], que consiste em mostrar como se dá, de forma padronizada, a modelagem de um determinado processo de negócio. 1.1 Descrição do Problema Em um mundo competitivo, todas as organizações precisam de eciência e ecácia na realização de seus objetivos, isto é válido tanto para empresas como qualquer outra organização. O processo de desenvolvimento de software não foge a essa premissa e sempre se busca uma melhor relação entre o produto obtido após a análise de negócio e o recurso disponibilizado do desenvolvimento do sistema. Daí a importância do processo de engenharia de requisitos ser realizado de forma correta e validado desde os estágios iniciais do ciclo de desenvolvimento de um software. Dentro da ER é possível ver a BPMN como um auxílio efetivo que leva uma entrada de dados por meio da modelagem de processos. Tanto é que esta nova notação já está amplamente difundida em empresas do mercado mundial, tais como IBM [13] e a ORACLE [20]. Esta investida por parte de empresas, como essas citadas, fazem-nos indagar sobre a utilização desta notação. Isto gerou uma inquietação da nossa parte e pensar na utilização do BPMN em uma organização real no âmbito do processo de engenharia de requisitos. Como contexto para explorar essa questão, escolhemos o próprio Departamento de Ciência da Computação (CIC) da Universidade de Brasília (UnB) e como sistema, escolhemos explorar o sistema de alocação de salas. O CIC possui um processo de alocação de salas de aulas, que não é automatizado completamente. Mas, como qualquer exemplo de outros contextos, este processo possui requisitos que podem ser elicitados para a posterior execução do processo de engenharia de requisitos. Daí, percebemos a oportunidade de aplicar a BPMN em algumas das distintas fases da Engenharia de Requisitos no estado atual do processo de alocação de salas do CIC, que na metodologia BPM esse processo recebe o nome de cenário real (AS-IS), assim como projetar um cenário ideal (TO-BE), nome esse dado também na metodologia BPM, que é feito a partir do cenário real, para ser implementado um sistema, tendo como base o cenário TO-BE, em trabalhos futuros. Com isso, deparamos-nos com a seguinte questão: será que realizando o processo de Engenharia de Requisitos para um cenário real, o BPMN poderá modelar de forma precisa o processo de alocação de salas de aula do CIC (cenários AS-IS e TO-BE) nas distintas fases iniciais do processo de engenharia de requisitos? 1.2 Hipótese(s) Tendo em vista o problema exposto, é necessário que seja levantada alguma hipótese que será, posteriormente, comprovada ou negada por meio do processo de validação dos requisitos que irá decidir sobre a validade ou não da mesma. A hipótese que será levantada é a seguinte: A notação BPMN constitui um instrumento capaz de auxiliar as fases de engenharia de requisitos por meio dos cenários AS-IS e TO- 2

13 BE. Com essa hipótese será vericado se o BPMN realmente é útil em todas as fases do Processo de Engenharia de requisitos, isto é, se a notação auxiliará em todas as fases ou somente em algumas, tais como as fases iniciais. 1.3 Objetivos Este trabalho tem como objetivo validar o processo de engenharia de requisitos utilizando o BPMN. A partir deste objetivo, é possível explorar ainda mais a natureza do trabalho, isto é, pode ser apresentado uma das novas tendências da indústria de TI as quais ainda não estão presentes no CIC. Como proposta de extensão, este trabalho pode também servir de base para que o departamento de Ciência da Computação passe a adotar a especicação, dando continuidade ao trabalho, isto é, incentive trabalhos futuros nessa área a m de que outros setores do CIC utilizem a mesma abordagem adotada no processo de alocação de salas. Para que o trabalho seja explorado de forma eciente a m de produzir bons resultados, tem-se como objetivo mais especíco encontrar uma solução adequada à implementação escolhida por meio de um estudo de caso. Como foi mencionado em seções anteriores desse mesmo capítulo será tratado o Processo de Alocação de Salas. Ao ter o conhecimento desse processo, será modelado o processo que acontece regularmente no decorrer dos semestres, o qual recebe o nome de processo ou cenário real (AS-IS) e a partir dele, após identicar suas características e lacunas, será modelado o processo ideal para a alocação de salas de aula do CIC, o qual recebe o nome de cenário ou processo ideal (TO-BE). O estudo de caso, terá como função demonstrar a utilidade do BPM, mais precisamente utilizando a notação BPMN adotado na modelagem dos processos citados (AS-IS e TO- BE). Neste trabalho utilizamos a versão 2.0 do manual BPMN como referência principal na modelagem dos componentes para a realização dos diagramas[19]. Após essa realização, será feita a análise que trará informações relevantes sobre o uso do BPMN nas diversas fases da Engenharia de Requisitos (ER) e se o seu uso é propriamente factível dentro deste processo de desenvolvimento. Além disso, após realizar a modelagem do cenário AS-IS, este trabalho tem o intuito de encontrar lacunas nesse mesmo processo para a melhoria contínua do mesmo. Essa procura por lacunas se dará por meio de pesquisas e análises do processo, a m de chegar no cenário TO-BE, isto é, depois do processo ideal ter sido modelado, a partir dele extrair os requisitos para o desenvolvimento futuro de um possível sistema de alocação de salas do CIC. Além disso, tanto o cenário real (AS-IS) quanto o cenário ideal (TO-BE), entra no processo de engenharia de requisitos para que esse possa ser validado utilizando a tecnologia BPM. O seguinte trabalho tem como objetivo mostrar um problema real e a partir dele encontrar uma solução por meio de um estudo de caso. Conceitos, disciplinas, características, processos e tecnologias acerca do Processo de Engenharia de Requisitos e sobre o BPM e sua notação, o BPMN, serão apresentados no decorrer desse documento. 1.4 O trabalho apresentado O trabalho está estruturado da seguinte forma: O Capítulo 2 aborda o referencial teórico do que está sendo tratado no trabalho desenvolvido, no Capítulo 3 será apresen- 3

14 tado o estudo de caso, que como já foi mencionado, trata do processo de alocação de salas do departamento de ciência da computação passando por todas as fases da ER, assim como a metodologia utilizada. Além disso, serão apresentados também nesse mesmo capítulo a descrição dos diagramas tanto real quanto ideal do processo de alocação de salas, o protótipo de um possível sistema que poderá vir a ser implementado e a análise do próprio estudo de caso. O Capítulo 4 apresentará a especicação dos diagramas modelados na notação BPMN. E, nalmente, no Capítulo 6 serão apresentadas as conclusões provenientes dos autores e, além disso, será mostrada a proposta de trabalhos futuros. 4

15 Capítulo 2 Referencial Teórico O seguinte capítulo tem como objetivo mostrar o referencial teórico do que estará sendo usado neste trabalho. Será iniciado com a teoria sobre o que vem a ser o processo de engenharia de requisitos na Seção 2.1.1, depois haverá uma abordagem sobre a tecnologia BPM na Seção 2.2, logo em seguida será mostrado a notação BPMN na Seção 2.3 e a denição do que é um estudo de caso na Seção Processo de engenharia de requisitos Denição Segundo Zave [38], os objetivos do processo de engenharia de requisitos podem ser categorizados em três grupos principais: investigação de objetivos, funções e restrições de uma aplicação de software; especicação do software; e, Gerenciamento da evolução e das famílias do software. Para Sommerville [29] todo esse processo é composto por quatro subprocessos que determinam o produto nal de requisitos: Estudo de viabilidade, Elicitação e análise de requisitos, Especicação de requisitos, Validação dos requisitos e o Gerenciamento de requisitos. Na Figura 2.1 é mostrado o desenho do processo. Figura 2.1: Processo de Engenharia de Requisitos [29]. 5

16 2.1.2 Estudo de viabilidade Em todos os sistemas novos o processo de engenharia de requisitos deve começar com um estudo de viabilidade [29]. O primeiro subprocesso de alto nível e também o primeiro passo do processo de engenharia de requisitos é saber se o sistema que o cliente solicitou é viável para a empresa. Um estudo de viabilidade é um estudo breve e focalizado que procura responder a uma série de questões [29]: O sistema contribui para os objetivos gerais da organização? O sistema pode ser implementado com tecnologia atual e dentro das restrições denidas de custo e prazo? O sistema pode ser integrado a outros sistemas já implantados? A entrada para o estudo de viabilidade consiste de um conjunto preliminar de requisitos de negócios, um esboço da descrição do sistema e como o sistema pretende apoiar os processos de negócios. Os resultados do estudo de viabilidade devem estar em um relatório que recomenda se vale a pena ou não prosseguir com os processos de engenharia de requisitos e de desenvolvimento do sistema Elicitação e análise de requisitos Nesta fase os engenheiros reúnem-se com os clientes e os usuários nais do sistema para que assim eles possam saber como será o domínio da aplicação, os serviços que o sistema deve ter, as restrições do hardware, o desempenho do sistema, etc. É esta fase que demanda mais atenção por parte dos engenheiros, pois é a mais longa, isso é, demandase um maior tempo por possuir um maior número de atividades. É nela que é possível envolver o maior número de pessoas de uma organização. Esses agentes envolvidos, podem ser pessoas ou grupos de pessoas que estão envolvidos com o sistema nal, são chamados de stakeholders [29]. Os stakeholders podem ser os usuários nais do sistema, os engenheiros envolvidos no desenvolvimento do software, os representantes da empresa (gerentes, chefes, diretores), enm todas as pessoas envolvidas direta ou indiretamente no desenvolvimento, manutenção e utilização do novo software instalado. No entanto, essa fase do processo é a mais complexa, como mencionado anteriormente, uma vez que é complicado a elicitação e análise dos requisitos por várias razões [29]. As principais razões são: Os stakeholders frequentemente não sabem o que querem do sistema de computador a não ser em termos gerais; As formas que os stakeholders expressam os requisitos são com os seus próprios termos e com o conhecimento implícito do seu trabalho; Diferentes stakeholders têm diferentes requisitos expressos de diferentes formas; Fatores políticos podem inuenciar os requisitos dos sistemas; O ambiente econômico e de negócios sobre o qual a análise e realizada é dinâmico. 6

17 Com isso, algumas atividades surgem para ajudar os engenheiros de requisitos extrair de forma mais precisa e clara os requisitos do sistema. Tais atividades são: obtenção de requisitos (elicitação), classicação e organização dos requisitos (elicitação), priorização e negociação dos requisitos (elicitação) e documentação dos requisitos (especicação/descrição). O foco principal deste trabalho é na parte de obtenção e validação de requisitos. E nessa atividade estão presentes as seguintes técnicas de obtenção: Entrevista Formulação de questões para os stakeholders sobre o sistema a ser desenvolvido. Para que os requisitos sejam levantados por meio dessa técnica, é possível utilizar diferentes tipos de entrevista. De acordo com Lakatos e Marconi [16], os tipos de entrevista são: Padronizada ou estruturada: Consiste no entrevistador seguir um roteiro previamente estabelecido. As perguntas são padronizadas e predeterminadas. Despadronizada ou não estruturada: O entrevistado tem liberdade para desenvolver cada situação em qualquer direção que considere adequada. É uma forma de poder explorar mais amplamente uma questão. Em geral, as perguntas são abertas. Painel: Consiste na repetição de perguntas, de tempo em tempo, às mesmas pessoas, a m de estudar a evolução das opiniões em períodos curtos. Cenários É uma técnica onde há o relato do dia a dia da organização e as atividades que os stakeholders realizam com o sistema antigo e de como eles interagiriam com o novo sistema. Um cenário é uma descrição que contém atores, a informação por trás deles, assunções sobre o seu ambiente, os seus objetivos e sequências de ações e eventos. Pode-se incluir também os obstáculos, contingências e sucessos dos atores [6]. Em alguns sistemas, os cenários podem omitir um dos elementos ou expressá-lo de forma simples, ou implícita. Objetiva-se com o uso de cenários descrever as ações em um ambiente relacionadas a um sistema atual ou a um sistema a ser desenvolvido [34]. Na engenharia de requisitos, dada a diculdade de elicitar, analisar, negociar e validar os requisitos de software, técnicas baseadas em cenários têm sido consideradas de grande utilidade. Isso porque cenários são construídos do ponto de vista de clientes/usuários, por meio de uma linguagem facilmente entendida pelos mesmos. As descrições do sistema realizadas por meio de cenários devem ser entendidas também pelos demais stakeholders. Assim, o trabalho para elicitar, analisar e validar os requisitos de um sistema pode integrar todos os stakeholders, num esforço em conjunto, que leva ao desenvolvimento de um documento de requisitos mais completo, consistente e não ambíguo. A técnica começa com o esboço da interação e, durante a elicitação os detalhes são adicionados para criar uma descrição completa dessa interação. De maneira geral, um cenário deve incluir: Uma descrição do que os usuários esperam do sistema no início do cenário; Uma descrição do uxo normal de eventos no cenário; 7

18 Uma descrição do que pode dar errado e como isso é tratado; Informação sobre outras atividades que podem ocorrer simultaneamente; Uma descrição do estado de sistema no m do cenário. Os cenários podem ser feitos de diferentes formas, tais como: escritos na forma de texto, complementados por diagramas e imagens de computador. Como alternativa, pode ser adotada uma abordagem mais estruturada, como cenários de eventos e casos de uso [29]. Neste trabalho, foi utilizado um cenário na forma de texto detalhando a Hipótese inicial, o funcionamento Normal de um possível sistema, Exceções, Outras atividades e o Estado do sistema após o término. Além disso, o cenário mostrado teve como complemento, a m de mostrar melhor como foram levantados os requisitos, o uso de diagramas utilizando notação BPMN Especicação de requisitos O objetivo da especicação preliminar ou anteprojeto é transmitir uma idéia global e genérica do projeto a ser desenvolvido segundo a visão dos usuários. É elaborado para compreender a real necessidade dos usuários e suas expectativas, dimensionar a sua abrangência e delimitar o seu escopo [10]. A principal característica do Anteprojeto é a sua natureza de estudo de viabilidade, de algo desejado, mas que ainda não foi devidamente analisado, permitindo dessa forma explorar alternativas para vericação de sua ecácia como solução. É fundamental o estabelecimento das Premissas Básicas que nortearão o desenvolvimento do sistema, atendo-se ao que o sistema deve fazer para cumprir a sua nalidade [10]. Compreende aspectos como: Levantamento Inicial: no qual se busca encontrar, embora em termos genéricos, o máximo de informações relacionadas à área do negócio, que sejam relevantes aos objetivos do projeto ou que possam impactar o seu desenvolvimento. Estudo Preliminar: identicação de todas as áreas envolvidas na solução e os grandes módulos de processamento, bem como o seu inter-relacionamento, sendo desejável a elaboração de um desenho macro onde o usuário possa identicar cada componente da solução pretendida. Nessa especicação não deverá haver a preocupação com a solução técnica que será adotada, poderá, no entanto, descrever as opções já vericadas ou desejadas pelos usuários no que se refere à tecnologia pretendida. A solução tecnológica propriamente dita será objeto da fase de Projeto. Como todo relatório deverá zelar pela clareza e objetividade das informações, seus dados devem ser precisos e suas estimativas e projeções deverão ser realistas, sem exageros ou omissões, dando base a conclusões sobre custos e benefícios com a implantação do sistema. A apresentação deverá ser organizada em tópicos coerentes favorecendo a compreensão e a seqüência do raciocínio [10]. Trata-se de uma peça importante e que merece total cuidado na preparação, pois além de possibilitar que seja dado aprovação ao prosseguimento do projeto, a apresentação criará expectativas nos futuros usuários e servirá de base ao detalhamento das fases seguintes do desenvolvimento [10]. 8

19 2.1.5 Validação de requisitos Essa fase do processo consiste em saber se os requisitos levantados correspondem às necessidades dos usuários. Dessa forma, deve ser respondida a seguinte pergunta: Será que foi realmente entendido o que o cliente desejava. Além disso, tem que se certicar também se houve uma boa comunicação entre os engenheiros e os stakeholders envolvidos. Uma importância da validação de requisitos é que os erros encontrados em um documento de requisitos podem levar a custos excessivos de retrabalho quando são descobertos durante o desenvolvimento ou depois que o sistema está em operação [29]. Durante a fase de validação dos requisitos, devem ser vericados (por meio de checklists) os seguintes atributos dos requisitos: Validade: a especicação resulta da análise dos requisitos identicados junto das diversas partes interessadas envolvidas. Como tal, requisitos identicados individualmente (isto é, junto de cada parte interessada) podem diferir da especicação nal que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especicação nal obtida. Consistência: não devem existir conitos entre os requisitos identicados. Compreensibilidade ou Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas. Completude: todas as funcionalidades pretendidas devem fazer parte da especicação do sistema. Realismo: dadas as restrições do projeto (tecnológicas, nanceiras e temporais) o sistema especicado tem de ser implementável. Vericabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especicados, estes devem ser descritos de modo a que seja possível vericar se foram ou não concretizados, isto é, se o sistema nal corresponde à especicação inicial. Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identicada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos. Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especicação deve obedecer às normas usadas ao longo de todo o documento. Para que seja possível a validação dos requisitos é necessário uma série de técnicas que podem ser usadas em conjunto ou individualmente: Revisões de requisitos, Prototipação e Geração de casos de teste. Revisão de requisitos Uma equipe de revisores pode analisar sistematicamente a especicação produzida de forma a garantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe de revisores pode simplesmente ter uma conversa, envolvendo o maior número possível de representantes das partes interessadas, acerca dos requisitos produzidos; em 9

20 revisões formais, a equipe de revisores deve conrmar junto do cliente um conjunto de critérios que todos os requisitos devem cumprir, são eles: vericabilidade, compreensibilidade (por parte dos utilizadores nais), rastreabilidade (a origem dos requisitos deve ser identicável) e adaptabilidade (capacidade de sofrer alterações sem produzir efeitos em todos os outros requisitos). Prototipação Um protótipo é uma versão inicial de um sistema de software usado para demonstrar conceitos, experimentar opções de projeto e, geralmente, conhecer mais sobre o problema e suas possíveis soluções [29]. Nesta abordagem de validação, um modelo executável do sistema é apresentado para usuários nais e clientes. Esta técnica também é ecaz, embora tenha algumas desvantagens: o tempo gasto na sua implementação pode não justicar o seu uso, pode enviesar os utilizadores (levando a desilusões com a versão nal do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a usar o protótipo para continuar o desenvolvimento do sistema. Geração de casos de teste Esta técnica consiste em desenvolver testes especícos para os requisitos para depois avaliá-los. Isso quer dizer que se os testes não forem possíveis de serem aplicados aos requisitos, isso quer dizer que os requisitos devem ser reconsiderados devido a diculdade de implementação dos mesmos. Ou seja, é necessário que seja possível criar testes para os requisitos a m de validá-los Gerenciamento de requisitos Como os requisitos, frequentemente, mudam ao longo do processo de desenvolvimento, seja por mudanças na empresa, seja por questões de facilidades para o usuários nais, esses problemas, ditos 'perversos', têm que ser tratados. Esse tratamento é feito nesta última fase do processo de engenharia de requisitos [29]. O gerenciamento de requisitos é um modelo sistemático para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema. Envolve a identicação de inconsistências entre os requisitos, o plano do projeto e os produtos desenvolvidos [27]. Para que seja realizado, deve-se garantir que os requisitos tenham sido bem identicados, tomando-se o cuidado de obtê-los com os melhores fornecedores de requisitos e que eles tenham sido bem entendidos. As mudanças de requisitos são normais e devem ser documentadas. Uma avaliação do impacto da mudança para o projeto deve determinar se o projeto deve absorver as mudanças e devese manter o rastreamento bi-direcional dos requisitos e identicar as inconsistências entre os requisitos e o que está sendo desenvolvido. Os principais itens para o gerenciamento eciente de requisitos incluem manter uma declaração clara dos requisitos, juntamente com atributos aplicáveis para cada tipo de requisito e rastreabilidade para outros requisitos e outros artefatos do projeto. O processo de gerenciamento de requisitos deve se iniciar assim que uma versão inicial do documento de requisitos esteja disponível mas, o ínicio do planejamento das mudanças de requisitos deve ocorrer durante o processo de elicitação de requisitos [29]. 10

21 2.2 BPM O Gerenciamento de Processos de Negócio (em inglês Business Process Management ou BPM) é um conceito que une gestão de negócios e tecnologia da informação com foco na otimização dos resultados das organizações por meio da melhoria dos processos de negócio [23]. São utilizados métodos, técnicas e ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos humanos, aplicações, documentos e outras fontes de informação Duas visões para o BPM BPM: visão Tecnologia da Informação A utilização do BPM, ao longo dos últimos anos, vem crescendo de forma bastante signicativa, dada a sua utilidade e rapidez com que melhora os processos nas empresas onde já foi implementado. A sua perspectiva de crescimento é bastante considerável, visto que ainda é um conceito pouco conhecido, principalmente no Brasil [23]. O termo processos "operacionais se refere aos processos de rotina (repetitivos) desempenhados pelas organizações no seu dia-a-dia, ao contrário de "processos de decisão estratégica, os quais são desempenhados pela alta direção. O BPM difere da remodelagem de processos de negócio, uma abordagem sobre gestão bem popular na década de 90, cujo enfoque não eram as alterações revolucionárias nos processos de negócio, mas a sua melhoria contínua. Adicionalmente, as ferramentas denominadas sistemas de gestão de processos do negócio (sistemas BPM) monitoram o andamento dos processos de uma forma rápida e barata. Dessa forma, os gestores podem analisar e alterar processos baseados em dados reais e não apenas por intuição. A alta direção da empresa pode enxergar, por exemplo, onde estão os gargalos, quem estão atrasando determinada tarefa, o quanto está atrasando e com que frequência isso ocorre; o percentual de processos concluídos e em andamento, entre outros. Como conseqüência disso, fatores cruciais para o bom desempenho de uma empresa podem ser analisados com extrema facilidade e rapidez o que geralmente não ocorre com outras ferramentas que não o BPM. Além disso, as pessoas participantes do processo também são beneciadas: com o BPM, elas têm o seu trabalho facilitado uma vez que recebem tarefas e devem simplesmente executá-las, sem preocupar-se com para onde devem enviá-la, por exemplo, dado que o processo já foi desenhado e todas as possíveis situações de seguimento deste já estão registradas. Além disso, podem enxergar como foi o caminho realizado até a sua atividade e em que status está. Os softwares responsáveis pela automação dessas atividades são chamados de Business Process Management Suites, ou BPMS. Estão disponíveis no mercado diferentes ferramentas com esta nalidade, sejam licenciadas ou freeware. Algumas delas são: Enterprise Architecture - Microsoft[22] Visio - Microsoft[2] TIBCO - TIBCO Software Inc[21] 11

22 Oracle BPM - Oracle[12] Intalio BPMS - Intalio[15] BizAgi BPM SUITE - BizAgi[1] BPM: visão Gestão de Negócios Nos anos 80, a Gestão pela Qualidade Total estava no topo da lista de prioridades das empresas em todo o mundo. Na década de 90, Michael Hammer e James Champy lançaram o artigo Don't automate, obliterate pela Harvard Business Review. Esse artigo foi o marco da chamada onda de BPR (sigla em ingês para Business Process Reengineering) ou Reengenharia de Processos. Em 2006, Howard Smith e Peter Fingar lançaram o livro "Business Process Management: The Third Wave com os conceitos de Gerenciamento de Processos de Negócios [28]. O BPM se tornou então o assunto mais importante nas empresas. Como especialistas em TI, os autores focaram o BPM como sendo uma automação de processos por meio de ferramentas de software. É importante ressaltar alguns pontos, em relação ao BPM, para os gestores interessados em implantar o Gerenciamento de Processos de Negócios para alavancar os resultados de suas empresas. Primeiramente, o BPM é uma metodologia de otimização de processos avançada, que se desenvolveu e evoluiu a partir das experiências anteriores (Gestão pela Qualidade Total e BPR). Segundo, os BPMS (ferramentas de sistema) não são o BPM (Gerenciamento de Processos de Negócios). As ferramentas de software utilizadas para automação dos processos são desejáveis, porém não devem ser o foco. O foco deve ser a melhoria dos processos de negócios para que as organizações possam alcançar os resultados esperados do negócio: lucratividade, satisfação dos clientes, otimização de custos etc. Outro ponto de atenção é que implantar o BPM (Gerenciamento de Processos de Negócios) em uma empresa não é simples, não é rápido, envolve mudança de comportamento das pessoas e comprometimento da alta administração. Por último, o uso da metodologia de Gerenciamento de Processos de Negócios se torna essencial para o sucesso de um projeto de implantação de BPM. Não necessariamente se deve contratar uma consultoria especializada, desde que os gerentes tenham conhecimento técnico suciente e a empresa coloque o BPM como prioridade [23]. O BPM tem como objetivo prover o alinhamento dos processos de negócios com a estratégia (os processos são a execução da estratégia), os objetivos e a cadeia de valor das organizações. O BPM utiliza as melhores práticas de gestão, tais como: o mapeamento dos processos, a modelagem, a denição do nível de maturidade, a documentação, o plano de comunicação, a automação, o monitoramento por meio de indicadores de desempenho e o ciclo de melhoria contínua. O objetivo é a melhoria contínua dos processos para se atingir os resultados esperados. Essas práticas aplicadas ajudam a maximizar os resultados e o desempenho dos processos, e assim fazer com que as organizações tenham melhores resultados nanceiros, vantagem competitiva, redução de custos, otimização de recursos, aumento da satisfação dos clientes por meio de produtos e serviços com um nível superior de qualidade. O que foi listado anteriormente são todas as atividades necessárias para realizar um produto/serviço em uma empresa, incluindo as ferramentas necessárias, as tarefas das pessoas envolvidas, os tempos e momentos de cada ação, os recursos, etc. 12

23 2.2.2 Processos AS-IS e TO-BE Para trabalhar a melhoria dos processos organizacionais, o primeiro passo é a identi- cação do negócio da organização e qual a visão estratégica que ela tem do mercado em que atua [7]. Após, é necessário identicar quais são os processos que atendem ao negócio da organização, ou seja, os processos-ns, porque são eles que agregam valor ao negócio da empresa, que produzem os bens ou serviços. Tais processos são ditos processos AS-IS, pois mostra o processo como ele ocorre no dia-a-dia da organização. Logo, deve-se identicar o problema ou os problemas existentes nos processos e suas causas, bem como fazer um levantamento detalhado da situação atual dos processo, vericando a documentação existente, volume de trabalho, recursos utilizados, tempos de execução, custos envolvidos, uxo do processo, fatores críticos, de sucesso, os pontoschaves do processo e a tecnologia da informação utilizada [7]. A continuação, deve ser feita a análise do processo atual, de cada parte para conhecer seus objetivos, funções, atividades, uxo de informações, e suas relações com os demais processos existentes [7]. A análise responde a questões que possibilitam vericar o que poderia ser feito para simplicar e racionalizar o processo em estudo, ou seja, seu redesenho. A análise e o redesenho constituem-se na tentativa de melhoria da qualidade de um processo feito por meio das seguintes etapas: Análise crítica do levantamento; Elaboração do uxograma do processo atual; Alocação do volume de trabalho, dos recursos, dos custos, e dos tempos de execução para cada atividade reetida no uxo de processo; Análise do uxo atual do processo; Análise da tecnologia da informação utilizada. Baseado na análise realizada é elaborado um novo desenho do processo por meio da modelagem de um novo uxo, levando em consideração: A eliminação dos gargalos identicados na análise; A eliminação de duplicidade de atividades e funções; A distribuição adequada dos recursos necessários ao uxo do processo; A possível eliminação de uma ou mais atividades e suas consequências; A melhoria do tempo de resposta; Após a denição do novo uxo do processo poderá haver ainda a denição de novas funções da tecnologia da informação é necessária, e por m, a aprovação do novo processo. Esse novo processo modelado, recebe o nome de processo TO-BE, pois é uma forma de dizer aos analistas de negócio como deve ser o processo da organização. Em seguida é preciso estabelecer a normatização das normas e regras dos procedimentos inerentes a cada atividade de um processo. E após saber como se dá os processos da organização e além disso, depois de ter modelado o processo como ele é (AS-IS) e a partir dele, modelar processo ideal (TO-BE), é feita a próxima etapa da metodologia BPM, que consiste na automação de Processos de Negócio. 13

24 2.2.3 Automação de Processos de Negócio Quando se automatiza processos, rapidamente é possível obter um controle mais rígido e adaptado às necessidades da empresa. Esta automação é realizada pelas BPMS. Algumas empresas comercializam os suites por processos, e não pelo pacote completo, o que torna ainda mais acessível. Por meio da automação, um serviço melhor é oferecido ao cliente, dada a rapidez e organização que a empresa passará a apresentar. Além disso, terá seus custos reduzidos. Modelagem A modelagem de processos é feita no próprio BPMS. Alguns destes seguem a notação mais usada atualmente, o BPMN. Esta notação trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário. A modelagem é uma etapa importante da automação pois é nela que os processos são descobertos e desenhados. É nela também que pode ser feita alguma alteração no percurso do processo visando a sua otimização. Simulação Após o desenho e o estabelecimento dos usuários responsáveis pela conclusão de cada tarefa, pode ser feita uma simulação, onde se pode testar se as regras pré-estabelecidas estão de acordo com o objetivo da empresa e se as tarefas estão sendo encaminhadas para as pessoas corretas. Execução A execução do processo ocorre após as etapas anteriores já terem sido realizadas. O BPMS utilizado faz que as tarefas sejam enviadas para os seus devidos responsáveis, controlando o seu tempo de execução por pessoa e pelo processo em geral. Podem ser utilizadas também regras de negócio (Business Rules) pré-estabelecidas. Controle O controle ideal de BPM é aquele que está presente durante todas as etapas do processo: antes, durante e depois. Desde o início da modelagem até a análise pós-conclusão da execução, o controle deve ser realizado. Um tipo de controle que existe em alguns BPMS são relatórios de uxos em andamento, onde é fornecido o status do uxo, com quem está parado, há quanto tempo está parado, etc. Isso é importante para evitar que os erros sejam encontrados somente quando o processo é concluído. Há também relatórios de uxos concluídos, onde se pode ter uma noção geral de como se desenvolveu o processo. Alguns softwares apresentam grácos e relatórios com bastantes detalhes dos processos. Otimização A otimização tem crucial importância quando se trata de BPM. É essencial para que sejam feitas melhorias nos processos de modo a alcançar resultados positivos mais rapidamente, melhorando o serviço aos clientes e, possivelmente, com menores custos. 14

25 Depende, obviamente, das etapas anteriores, principalmente do controle, onde deve haver uma busca pela perfeição. 2.3 BPMN BPMN (sigla em inglês para Business Process Modeling Notation) é um padrão em destaque na atualidade que dentre algumas notações, tais como: IDEF, UML, Grafos também é uma forma de representar processos em execução em um workow [19]. Além de mais atual que notações como IDEF e UML, também possui um rico conjunto de elementos grácos para representação de uma série de situações que acontecem nos uxos de processos. O padrão está em evolução e longe da perfeição, mas de todas as notações da indústria é o que mantém a maior concordância da indústria. Por outro lado, o padrão BPMN é uma notação gráca para desenho de processos, e não está associado a nenhum formato de armazenamento especíco [19]. Ou seja, cada BPMS diferente tem uma forma diferente de armazenar, ou seja, depende do BPMS utilizado. Um objetivo secundário é permitir que as linguagens que irão realizar a orquestração do projeto possam ser vista em uma notação orientada a negócios, facilitando a leitura do arquivo XML que dene a sua execução [19] Tipos de Diagramas BPMN Os diferentes tipos de diagramas são chamados de BPD (Business Process Diagram). A especicação dos nomes se dá conforme o nível de detalhamento do diagrama. Private Business Process: São os diagramas de processos privados. Estes diagramas são usados quando só interesse a representação de um único tipo de processo e não como diferentes processos se interagem. Abstract process: São os diagramas de processos abstratos. Ao contrário do processo privado, aqui somente interessa como diferentes processos se interagem sem se preocupar com o teor do uxo de cada processo. Colaboration Process: São os processos colaborativos. É a junção da representação privada com a representação abstrata, ou seja, além de mostrar o nível de detalhamento relativamente alto de um processo, é mostrado também como esse processo se interage com outros processos que nesse caso também estão bem detalhados Componentes de um diagrama BPMN Será mostrado nesta subseção os diferentes componentes que podem compor um diagrama de um processo modelado em BPMN. Pools e Lanes Os Pools são uma denição de um uxo de processo onde o processamento ocorre em seu interior independentemente do que acontece ao seu redor. Já as Lanes são os partici- 15

26 pantes que concretizam o processo e cam no interior da pool [19], conforme mostrado na Figura 2.2: Figura 2.2: Pools e Lanes [30]. Instância de processos Esse nome se dá quando um uxo do processo está em execução. Está presente dentro de um pool ou uma lane. Eventos Ao se ter inicialmente uma lane (ou somente um pool, cujo processo não seja tão complexo) é necessário que se inicie o processo. Para isso, há a presença dos eventos. São eles que tem a capacidade de iniciar ou nalizar um processo [19]. Podem aparecer durante a execução ou serem gerados. Os eventos não realizam atividades, isto é, não executam tarefas no processo, eles funcionam como um gatilho para que determinada atividade aconteça, ou seja, eles podem forçar uma execução ou simplesmente, desviar a execução para que determinada atividade se inicie. Os eventos podem ser de três tipo: Iniciais: Os eventos de início fazem com que se inicie a execução de um uxo do processo. O início do processo por si só já é um evento. São círculos com a borda formada por uma linha simples. Intermediários: Os eventos intermediários acontecem ou são gerados ao longo do uxo do processo já em execução. Podem ser gerados ou serem receptores de um evento gerado por outra parte do uxo do processo. São círculos com a borda formada por uma linha dupla. Finais: Os eventos nais terminam o uxo do processo em execução. Após esse evento, nenhuma outra atividade pode ser executada. São círculos com a borda formada por uma linha espessa. A representação dos evento é mostrado na Figura 2.3. Os eventos intermediários geralmente subdividem-se em outros tipos, tais como mostrados na Figura 2.4: É importante ressaltar que o mesmo pode ocorrer com os eventos iniciais e nais, mas são raras as exceções. 16

27 Figura 2.3: Representação gráca dos eventos [30]. Figura 2.4: Tipos de eventos [30]. Gateways Os gateways são os mecanismos padronizados do BPMN que têm como função efetuar desvios no uxo do processo [19]. Como eventos tem o formato de círculos, para representar os gateways são utilizados losangos. Podem vir depois de uma atividade ou até mesmo depois de um evento. Em geral, tem-se cinco tipos de gateways: Gateway: Com esse gateway somente um dos caminhos será seguido e o próximo passo do uxo é uma atividade. Exclusivo ou do tipo XOR (dados): Com esse gateway somente um dos caminhos será seguido e o próximo passo do uxo é uma atividade. Diferencia do gateway anterior pela presença de um X no seu interior. Exclusivo ou do tipo XOR (eventos): Com esse gateway somente um dos caminhos será seguido e o próximo passo do uxo é um evento. 17

28 AND: Quando o uxo chega nessa bifurcação os dois caminhos criados são seguidos. OR: Neste gateway pelo menos um caminho será seguido na bifurcação do uxo do processo. COMPLEXO: Cada uma das saídas deste gateway pode efetuar testes distintos. Com isso as decisões podem ser tomadas de forma mais completa. A representação gráca está mostrada na Figura 2.5 abaixo. Figura 2.5: Gateways [30]. Atividades Uma atividade é uma unidade de trabalho em um processo, isto é, uma ação por parte do responsável daquela atividade [19]. Encontram-se também no interior de uma pool e são disparadas por eventos. Os tipos de atividades são mostrados na gura 2.6: Figura 2.6: Atividades [30]. Token Na ocorrência de uma instância do processo, quando há uma bifurcação, ou seja, caminhos diferentes do uxo podem ser seguidos, cada caminho desse dá-se o nome de token. Isso quer dizer que quando aparece algum gateway (xor, and, or) que dividirá a instância de processo, cada caminho diferente será um token. Pode-se fazer uma analogia às threads, mas não se dá o nome de thread, pois o token pode car parado até um evento disparar uma atividade (evento de timer) ou somente quando um evento receber uma 18

29 mensagem para disparar uma outra atividade (evento de mensagem), ou seja diferentes tokens não precisam está agindo paralelamente. O que não ocorre com uma thread [19]. Artefatos Os artefatos são elementos que aparecem no modelo de processo que não alteram o uxo e nem mesmo executam atividades [19]. São acrescentados somente para dá mais detalhes ao modelo, ou seja, deixar os diagramas mais claros ou expor pontos mais importantes. Geralmente vem ligado a uma atividade. Os tipos de artefatos são mostrados na Figura 2.7. Figura 2.7: Artefatos [30]. Conectores Essa notação mostra como o uxo conecta seus elementos, sejam eles atividades, eventos, gateways e artefatos. Existem três tipos diferentes, tais como uxo de seqüência, uxo de mensagem e associação, a Figura 2.4 exemplica estes modelos. Um uxo de seqüência liga elementos e indica a ordem que irão ser executados. Um uxo de mensagem demonstra a troca de mensagens entre duas atividades. E associações ligam outras artefatos ao uxo, como dados ou textos informativos [8]. Exemplos de conectores são mostrados na Figura 2.8. Figura 2.8: Conectores [30]. A partir desses componentes é possível iniciar a modelagem de um processo que será apresentado em um diagrama BPMN. Isso foi feito para que fosse possível melhorar a especicação do documento de requisitos e mostrar também como se dá o real processo de alocação de salas de aula do CIC. No entanto, tudo mais que será feito no trabalho 19

30 terá como base um estudo de caso para que seja possível demonstrarmos o que está sendo tentado provar. Para isso, segue a denição de um estudo de caso para ns de conhecimento dos leitores deste trabalho. 2.4 Estudo de caso: Denição e Metodologia O que é um Estudo de Caso Caso estudo, caso de estudo ou estudo de caso são expressões sinônimas que designam um método da abordagem de investigação em ciências sociais simples ou aplicadas [36]. Consiste na utilização de um ou mais métodos quantitativos de recolha de informação e não segue uma linha rígida de investigação. Caracteriza-se por descrever um evento ou caso de uma forma longitudinal. O caso consiste geralmente no estudo aprofundado de uma unidade individual, tal como: uma pessoa, um grupo de pessoas, uma instituição, um evento cultural, etc. Quanto ao tipo de caso de estudo, estes podem ser exploratórios, descritivos, ou explanatórios. Inicialmente esta metodologia nasceu da necessidade de transmitir na íntegra a complexidade de situações reais com as quais nos confrontamos todos os dias [36]. A aplicação inicial deu-se na área da medicina, na qual é impossível abraçar a totalidade dos fatores que podem inuir sobre determinada situação e que obrigam a vários avanços e recursos na forma como dirigimos a resolução do problema que é colocado. Ensinar por meio de casos de estudo, é formar sem ensinar. Consiste em acompanhar o aluno em diligências rigorosas e disciplinadas. Pretende-se que o aluno descubra pela sua maneira de ver, sentir, entender e interpretar, tudo fazendo que os conhecimentos adquiridos sejam os do próprio aluno que se identica claramente com a construção desse mesmo saber. O caso de estudo, signica uma evolução nas relações entre docente e alunos sendo que deixa de haver uma relação clássica entre quem sabe e quem aprende. A crença de base no presente método é que, as tarefas só se conseguem ser ensinadas pela vivência e experiência Natureza do estudo de caso De acordo com diferentes autores, o estudo de caso tem origem na pesquisa médica e na pesquisa psicológica, com a análise de modo detalhado de um caso individual que explica a dinâmica e a patologia de uma doença dada [33]. Com este procedimento se supõe que pode-se adquirir conhecimento do fenômeno estudado a partir da exploração intensa de um único caso. Além das áreas médica e psicológica, tornou-se uma das principais modalidades de pesquisa qualitativa em ciências humanas e sociais [33]. Já o estudo de caso como modalidade de pesquisa origina-se nos estudos antropológicos de Malinowski e na Escola de Chicago e, posteriormente, teve seu uso ampliado para o estudo de eventos, processos, organizações, grupos, comunidades etc. Sua origem é bastante remota e se relaciona com o método introduzido por C.C.Laugdell no ensino jurídico nos Estados Unidos. Sua difusão, entretanto, está ligada à prática psicoterapêutica caracterizada pela reconstrução da história do indivíduo, bem como ao trabalho dos assistentes sociais junto a indivíduos, grupos e comunidades [33]. Atualmente, é adotado na investigação de fenô- 20

31 menos das mais diversas áreas do conhecimento, podendo ser visto como caso clínico, técnica psicoterápica, metodologia didática ou modalidade de pesquisa. Assim como há diferentes posicionamentos que relatam as origens do estudo de caso, para a apresentação do seu signicado como modalidade de pesquisa, há na literatura mundial contemporânea a contribuição de muitos autores, com posições diversas, entre os quais destacam-se: Goode, Yin, Stake, Lüdk, etc. [36] Para Goode e Hatt, o estudo de caso é um meio de organizar os dados, preservando do objeto estudado o seu caráter unitário. Considera a unidade como um todo, incluindo o seu desenvolvimento (pessoa, família, conjunto de relações ou processos etc.). Vale, no entanto, lembrar que a totalidade de qualquer objeto é uma construção mental, pois concretamente não há limites, se não forem relacionados com o objeto de estudo da pesquisa no contexto em que será investigada. Portanto, por meio do estudo do caso o que se pretende é investigar, como uma unidade, as características importantes para o objeto de estudo da pesquisa Estudo de Caso Exploratório A pesquisa exploratória é um tipo de pesquisa realizada para um problema que não foi claramente denido [3]. Ela ajuda a determinar o melhor projeto de pesquisa, método de coleta de dados e seleção de assuntos. Mesmo com suposições lógicas erradas, o estudo exploratório precisa ser feito. Isto é, uma premissa falsa leva em consideração que podem surgir hipóteses verdadeiras no nal do Estudo. É o grau de direcionamento da pesquisa. É provável que qualquer estudo empírico novo desenvolvido seja considerado como exploratório. Mas, segundo Yin [36], o estudo exploratório deve ser precedido por armações sobre: o que será explorado, o propósito da exploração, e os critérios por meio dos quais se julgará a exploração como bem-sucedida. Depois de ter sido mostrado o referencial teórico neste documento para um entendimento maior do trabalho realizado, os próximos capítulos irão mostrar como a teoria se tornará prática, concretizando o que foi dito. 21

32 Capítulo 3 Estudo de Caso: Processo de alocação de salas Este capítulo tem como objetivo mostrar as fases do processo de engenharia de requisitos, e a metodologia utilizada neste trabalho. Além de como levantar as informações necessárias para desenvolver um projeto BPM e fazer uma comparação entre processos, sendo o processo como ele é (AS-IS) e a melhoria do mesmo para que que como pretendido a m de dá resultados positivos para a organização (processo TO-BE). Segundo Amado L. Cervo e Pedro A. Bervian [4], para desenvolver um projeto de pesquisa é preciso seguir quatro etapas. Os quais são: Escolha do Tema: Seção 3.1; Formulação do Problema de Pesquisa: Seção 3.2; Estudo exploratório: Seção 3.3; Coleta e análise de dados: Seção Escolha do Tema O tema de uma pesquisa é qualquer assunto que necessite melhores denições, maior precisão e clareza do que aquilo que já está contido em materiais concernentes à pesquisa [4]. Deve-se, nalmente, evitar temas que já devem ter sido explorados, principalmente se já foram explorados localmente. Assim, a escolha denitiva do tema foi a do estudo exploratório utilizando uma modelagem com notação BPMN em um processo de Engenharia de Requisitos. Denindo o objeto utilizado na investigação como o processo de alocação de salas de aula do Departamento de Ciência da Computação da Universidade de Brasília Estudo de viabilidade O tema a ser seguido e desenvolvido, para que fosse possível continuar com as outras etapas do projeto de pesquisa, teria que envolver alguma das etapas do BPM (neste caso a modelagem, feita em BPMN) e as fases de engenharia de requisitos. 22

33 A partir de reuniões feitas para estudar a viabilidade do assunto escolhido, foi feita uma outra reunião para a apresentação da proposta de utilizar dados referentes ao processo de matrícula de alunos. Desta maneira, acertou-se utilizar o processo de alocação de salas de aulas por parte da coordenação do curso de Ciência da Computação. Então era necessário elicitar com o coordenador do curso para que este pudesse nos dizer se seria viável ou não o sistema a ser desenvolvido a m de auxiliar no processo de alocação de salas do Departamento de Ciêncida da computação. A tabela I.2, mostra cronologicamente, como se deu os encontros com o coordenador do curso. Como alocar alunos em salas de aula não tem seu processo totalmente automatizado, foi visto que é viável o desenvolvimento do sistema de alocação de salas para as disciplinas do CIC, viabilidade esta mostrada pelo principal agente envolvido no processo de alocação de de salas do CIC o coordenador do curso. Depois de constatado a viabilidade do desenvolvimento de um sistema, passaremos para a p oxima etapa do processo que é a elicitação e a análise de requisitos. Mas antes disso, será mostrado a visão e o escopo do CIC, bem como o processo de alocação de salas em si Visão e escopo do CIC e do processo de alocação de salas O trabalho realizado possui o seguinte escopo com o intuito de auxiliar o Departamento de Ciência da Computação no processo de alocação de salas, para assim mostrar o processo como ele é (AS-IS) e sugerir um processo ideal (TO-BE) de alocação de salas do departamento de Ciência da computação. O Departamento de Ciência da Computação (CIC) foi criado por meio da Resolução do Conselho Universitário no 002/87 de 28/05/1987. Desde sua criação o CIC está vinculado ao Instituto de Ciências Exatas (IE). Tem como objetivo contribuir para o avanço do estado da arte e formação de recursos humanos de excelência em Computação, capazes de pesquisar, aplicar e criar novos conhecimentos e tecnologias para promover o bem estar e o desenvolvimento social. Além disso tem uma grande atuação na graduação da UnB, com 729 alunos matriculados. Os alunos tem opção de ingresso na computação por meio dos cursos: Bacharelado em Ciência da Computação (curso diurno com 319 alunos matriculados), Licenciatura em computação (curso noturno com 267 alunos matriculados) e o curso criado recentemente no segundo semestre de 2009 pelo programa REUNI de Engenharia de Computação que conta com 143 alunos matriculados, além do grande número de vagas oferecidas nas disciplinas de serviço presentes nos vários cursos da UnB, chegando a 4000 vagas semestrais. O CIC, para acomodar esses alunos a m de que estes possam assistir às aulas ministradas pelo departamento, tem as seguintes salas de aula disponíveis: CONF 1, CONF 2, CONF 3 (presentes dentro do departamento); BT 504, BT 524 (encontradas no ICC Norte); B1 110 (ICC SUL), AUDITÓRIO (É utilizado como alternativa, pois não pertence ao CIC) e CIC MIDIA. Além disso o Departamento de Ciência da Computação conta com o Laboratório de Informática (LINF) dividido em: LINF 1, LINF 2, LINF 3, LINF 4, LINF 5 e LINF 6. Esses laboratórios são utilizados para ministrar aulas de diferentes disciplinas do departamento, assim como, disciplinas de serviço. No entanto, o CIC conta exatamente com 10 salas próprias para alocação. Esse processo de alocação encontra-se sob responsabilidade do coordenador do CIC, que é o principal stakeholder 23

34 para o desenvolvimento do sistema. Sua contribuição no processo e muito signicativa, pois ele é o único responsável por esse processo de alocação. Algumas das disciplinas que exigem maiores demandas por serem matérias obrigatórias para os cursos, tanto Bacharelado, quanto Licenciatura e Engenharia da Computação são: Introdução à Ciência da Computação, Programação Sistemática, Noções de Sistemas Operacionais, Computação Básica, Estrutura de Dados, Organização de Arquivos, Linguagens de Programação, Circuitos Digitais, Teoria da computação, Bancos de dados, Organização e Arquitetura de Computadores, Sistemas de Informação, Transmissão de Dados, Software Básico, Engenharia de Software, Tradutores, Sistemas Operacionais, Trabalho de Graduação, Autômatos e Computabilidade, Projeto de Licenciatura 1, Projeto de Licenciatura 2, Trabalho de Graduação 1, Trabalho de Graduação 2, Arquitetura de Processadores Digitais, Lógica Computacional 1, Introdução à Engenharia de Computação, Projeto e Análise de Algoritmos. Na Figura 3.1 segue a Distribuição das disciplinas do CIC por dia e período. Figura 3.1: Distribuição das disciplinas do CIC por dia e período. Após esta etapa, segue a formulação do problema de pesquisa, o qual será visto na próxima seção. 3.2 Formulação do problema de pesquisa Uma vez escolhido o tema, passa-se a formular o que será explorado posteriormente por meio da denição dos objetivos e hipóteses que se encontram dentro do escopo Denição dos Objetivos A identicação dos objetivos caracterizam a natureza do trabalho, o tipo de problema a ser solucionado, o material a ser coletado, etc. Muito frequentemente os objetivos são caracterizados como [4]: Objetivos Gerais: procura-se determinar clara e objetivamente o propósito geral da realização da pesquisa, caracterizando os estados ou condições que se pretende atingir com o trabalho (por exemplo, "estabelecer um modelo para..."ou "demonstrar a validade de... "ou ainda "investigar as razões de..." 24

35 Objetivos Especícos: procura-se detalhar as inteções e propósitos expressos nos objetibos gerais e declarar os produtos ou segmentos da pesquisa que comporão o trabalho a ser desenvolvido. Os verbos e ações aqui utilizados são mais especícos, tais como: desenvolver um instrumento, identicar um aspecto, levantar dados de algo, diagnosticar uma condição, traçar um perl, realizar um experimento, e assim por diante. Tendo como base o exposto acima, tem-se como resultado dos objetivos gerais: Validar o processo de engenharia requisitos utilizando BPMN. Ou seja, a partir de um diagrama de processo modelado ter os parâmetros necessários para desenvolver um determinado sistema. A partir dos objetivos gerais, pode-se especicar os objetivos especícos que são: 1. Apresentar uma das novas tendências da indústria de TI. Como mencionado no Capítulo 2, Subseção 2.2, no que diz respeito ao BPM e foi explicado na Seção 1.3 no Capítulo 1 2. Achar a melhor solução da implementação escolhida por meio de um estudo de caso. Ao ter como base o estudo de caso que será tratado neste capítulo que fala do processo de alocação de salas do CIC. 3. Demonstrar a utilidade do BPM. Para poder estabelecer a relação entre o uso do BPMN e as fases do processo de Engenharia de Requisitos, se estudariam dois casos de modelos diferentes, conforme a metodologia AS-IS e TO-BE. A partir da realização deles, se relacionaria cada uma das fases presentes na Engenharia de Requisitos, apontando facilidades e diculdades na obtenção dos requisitos dado o determinado problema. 4. Encontrar lacunas no processo de alocação de salas. A partir do processo de alocação modelado na forma de diagrama, será analisado as possíveis falhas presentes no processo. O problema é uma questão que envolve uma diculdade teórica ou prática para a qual se almeja uma solução [4]. A formulação do problema pode ser feita por meio de uma ou mais perguntas. O tema escolhido deve ser questionado, com criatividade, naqueles aspectos que se apresentem obscuros. Contudo, depois de exposto o que foi mencionado acima sobre o problemas de pesquisa, foi levantada a seguinte questão: Realizando o processo de engenharia de requisitos para um estudo de caso real, a BPMN possui utilidade nas fases iniciais deste processo? Essa pergunta, como foi discutida, será respondida no decorrer do trabalho, ou seja, serão feitas extrações de informações, a partir delas teremos a demonstrações de alguns resultados que pretendemos obter com a pesquisa Formulação das hipóteses Uma hipótese é uma suposição de que algum fato, fenômeno ou relação entre eles seja verdadeira [4]. Em linguagem cientíca a hipótese equivale à suposição verossímel sobre objetos fatos ou fenomênos, que será posteriormente comprovada ou negada por observações que irão decidir sobre a validade ou não da hipótese. A hipótese levantada 25

36 para esse trabalho é: A notação BPMN constitui um instrumento capaz de auxiliar as fases de engenharia de requisitos utilizando como exemplo uma melhoria de processo por meio dos cenários AS-IS e TO-BE em um contexto real de negócio. Logo, podemos deduzir que nossa hipótese seria uma hipótese indutiva, ou seja, a partir de conhecimentos já obtidos com outras formas, linguagens e padrões de modelar um processo, temos que a partir daí é possível modelar os processos e também seria útil no processo de engenharia de requisitos para assim alcançar nossos objetivos. 3.3 Estudo exploratório Como foi referenciado na Seção 2.4.3, nesta seção serão colocadas as partes integrantes do estudo exploratório. A primeira parte que consiste no que será explorado vem a ser o processo de alocação de salas de aulas do ponto de vista da coordenação do curso de ciência da computação. Já o propósito de exploração pode-se dizer que é melhorar o cenário atual e tentar chegar no cenário ideal, a partir dos requisitos levantados. E para encerrar os critérios por meio dos quais se julgará a exploração como bem-sucedida seria a alocação realizada com sucesso. 3.4 Coleta e análise de dados A coleta será realizada dentro do processo de engenharia de requisitos na fase de elicitação. Que será tratado na Seção Já a análise dos dados estará dentro da especicação que consta na Seção Com isso, toda essa atividade, que consiste na coleta e análise de dados bem como a atividade de percorrimento das fases do processo de engenharia de requisitos, estão todas inseridas no escopo do processo de alocação de salas do Departamento de Ciência da computação que serão mais detalhados nas subseções a seguir Elicitação e Análise de Requisitos Inicialmente, para que os requisitos pudessem ser elicitados, foi utilizado a técnica de elicitação denominada cenário. Como auxílio à técnica mencionada, foi utilizada também a técnica de entrevista. Objetivos da entrevista Para que pudéssemos ter o levantamento detalhado do processo e do cenário foi necessário utilizar uma técnica de levantamento, que no nosso caso foi a entrevista uma técnica de elicitação de requisitos a qual também foi utilizada para levantar parte dos requisitos de um provável sistema para processo de alocação de salas. Conforme Lakatos e Marconi [16] entrevista, do ponto de vista de pesquisa, é um encontro para que uma das pessoas obtenha informações a respeito de determinado assunto, mediante uma conversação de natureza prossional. Os objetivos da entrevista quanto ao conteúdo, podem ser [16]: Averiguação de fatos; 26

37 Determinação das opiniões sobre os fatos; Determinação de sentimentos; Descoberta de planos de ação; Conduta atual ou do passado; Motivos conscientes para opiniões, sentimentos, sistemas ou condutas. Ao tomarmos como base a Subseção 2.1.3, podemos ver que as atividades feitas neste trabalho, no que diz respeito à entrevista, consiste em um tipo de entrevista nãopadronizada e teve como objetivo a averiguação de fatos. Isso porque, em um primeiro momento, foi deixado o coordenador do curso explicar sobre o processo de alocação de salas, onde só havia algumas interrupções caso surgisse alguma dúvida de nossa parte ou o assunto relacionado àquele período da entrevista estivesse esgotado. Logo, as perguntas feitas para o coordenador foram: 1. Como é feita alocação de salas de aula nos cursos da computação? 2. O que é levado em conta no momento de alocar as salas de aula? 3. Quem são os envolvidos e interessados nessa atividade? 4. Que ferramentas são utilizadas? 5. Qual a maior diculdade encontrada nessa atividade? 6. Os horários das disciplinas afetam na alocação de salas? 7. Como o espaço físico interfere na alocação de salas? 8. Como a disponibilidade dos professores interfere na atividade? 9. Que alterações tem que ser feitas quando ocorre uma mudança de horário de alguma disciplina? 10. Os professores são obrigados a seguir as salas alocadas às turmas que ele for ministrar as aulas? 11. O que acontece com a atividade de alocação de surgir alguma matéria nova? 12. O que é feito quando ocorre choque de horário? 13. Existe alguma exceção à regra, no que diz respeito às turmas e matérias, na atividade de alocação? 14. O que acontece quando não há salas disponíveis? Essas perguntas foram associadas e projetadas ao que se desejava ao ter como idéia um possível processo de alocação e que diculdade e ajudas poderiam surgir em tal atividade tanto por parte do coordenador quanto por parte dos outros stakeholders. Como tratou-se de uma entrevista não padronizada, a maioria das perguntas, foram surgindo no decorrer da entrevista, isto é, conforme o coordenador falava, outras perguntas vinham surgindo sobre o assunto. Foi preciso saber quem eram os responsáveis por essa alocação das salas 27

38 dos cursos do Departamento de Ciência da Computação. Depois de procurar os interessados (stakeholders), constatou-se que os responsáveis são: Coordenador do Departamento, Professores do Departamento, Alunos (alocar conforme a quantidade e capacidade das salas) e a Prefeitura da UnB. Ao término da entrevista a próxima fase consiste em realizar a técnica de cenário presente na ER. O Cenário Depois de realizada a entrevista, foi possível montarmos um cenário na forma de texto e complementado pelas diagramas com notação BPMN como mencionado na Seção do processo de alocação de salas do CIC. São analisados cinco componentes na técnica de cénarios: Hipótese inicial, Fluxo normal, Exceções, Outras atividades e Estado do sistema após o término, que serão descritos a seguir. Hipótese inicial: O usuário (coordenador do curso) conecta-se ao sistema de alocação de salas de aula e conseguiu alocar a nova turma que será ministrada. Fluxo normal: O uxo tem como ponto de partida a análise da planilha do histórico de alocações de salas de semestres anteriores. Caso exista alguma nova disciplina ou nova turma de uma disciplina já existente, o usuário informa todos os dados necessários a serem utilizados como parâmetros na alocação da nova turma. Esses são: Código da disciplina, Nome da Disciplina, Quantidade de créditos (teóricos e práticos), Quantidade de alunos na turma e Professor que ministrará a turma (se houver). Se o professor que ministrará a disciplina tiver alguma preferência de horário e de sala, serão acrescentados nos itens informados: Sala teórica e/ou prática e o Horário e dia da disciplina. Uma vez que todos os parâmetros sejam informados se passará à análise na planilha de alocação, vendo se os dias e horários encontram-se disponíveis. Caso estejam, a alocação da turma será realizada com sucesso. Exceções: O usuário pode não informar um dos 4 itens obrigatórios vistos no tópico anterior. Nesse caso, o sistema acusa a falta de um ou mais deles e pede uma solicitação das informações faltantes. O sistema pode não ter disponibilizado horários e salas conforme a petição do professor. Neste caso, será enviado um pedido para o professor informar um novo horário e/ou nova sala da sua preferência. O sistema pode não ter horários disponíveis em salas para aulas teóricas. Neste caso, o LINF será utilizado para suprir esta falta. O sistema pode não ter horários disponíveis em salas para aulas práticas. Neste caso, as salas destinadas para aulas teóricas serão utilizadas para suprir esta falta, sem a utilização do laboratório. O sistema pode não ter horários disponíveis para salas teóricas e nem para salas práticas. Neste caso se enviará um pedido à Prefeitura da Universidade para que este seja analisado. Em caso armativo, será disponibilizada uma sala que atenda às necessidades da turma que será alocada. Outras atividades: Alocação esporádica de salas do LINF por parte de professor. 28

39 Estado do sistema após o término: O usuário continuará conectado após a mensagem de sucesso ou de erro. Se for o caso bem-sucedido, a turma terá sido alocada em alguma(s) sala(s) disponível(eis). Caso contrário, caberá ao usuário tomar outras medidas que fujam do uxo de processo de alocação de salas. Depois de feito o cenário, o próximo passo é a modelagem do cenário atual (AS- IS) do processo de alocação de salas do departamento utilizando a notação BPMN para demonstrar como se dá o uxo do mesmo. Início da modelagem para elicitação dos requisitos Depois de executado a técnica de cenário, foi possível iniciar a modelagem do processo de alocação de salas real utilizando a notação BPMN e a ferramenta BizAgi que será melhor explicada na Seção Com algumas versões já feitas do cenário real foi necessário termos reuniões com o coordenador do departamento para uma validação do processo. É a partir dessa fase que iremos realizar a modelagem do processo ideal (TO-BE) sobre a alocação de salas de aula. O qual espera-se como resultado, também com a ajuda da notação BPMN, o diagrama correspondente, mostrando como seria um cenário ideal no processo de alocação. Com isso, algumas análises do processo de alocação de salas real foram feitas. Tais como: Identicação de algumas lacunas que poderiam está presentes no processo real; Procurar uma forma de proteger a atividade de alocação de salas do LINF por parte dos professores do departamento, critério esse principal para o processo de alocação de salas ideal, que será melhor explicado na Subseção Especicação Como foi visto no capítulo anterior, na Seção 2.1.4, agora será feito um detalhamento dos requisitos que foram levantados, por meio da comparação dos dois processos obtidos: O processo real de alocaçao de salas (AS-IS) e o processo ideal de alocação de salas (TO-BE) Etapas AS-IS e TO-BE Etapa AS-IS O objetivo desta etapa é analisar o modelo atual do processo para obter um diagnóstico da situação atualmente (AS-IS). Nesta etapa é dimensionado o valor relativo dos problemas identicados, as oportunidades de melhoria, a inteligência corporativa e o desempenho operacional. São vericados as relações de integração, da informação, detectando as oportunidades de automatização e, princiapalmente, como melhorar ou alterar o processo para obter melhor desempenho na organização, no nosso caso, o Departamento de Ciência da computação. [17]. A etapa AS-IS consiste na organização para o entendimento e um futuro aperfeiçoamento do processo como ele é (processo real de alocação de salas) e na modelagem e 29

40 projeto do processo. Ao nal, é esperado um melhora do processo como é atualmente, ou seja, chegar à etapa TO-BE. Para isso, é feito um levantamento inicial do processo, ou seja, a identicação dos processos de negócio, das atividades, e rotinas de trabalho por meio de algumas entrevistas e reuniões com o coordenador do departamento. Nesse sentido, uma reunião foi feita com o coordenador do departamento a m de elicitar parte dos requisitos para assim ter a possibilidade de modelar parte ou até mesmo todo o processo de alocação de salas. Com o cenário descrito pelo coordenador do departamento foi possível visualizar o processo atual (AS-IS) para assim, utilizando uma ferramenta de modelagem de processo de negócio fosse possível modelar o processo de alocação de salas. A gura do coordenador é tão marcante no processo que a raia destinada à ele concentra a maioria das atividades e eventos do diagrama do processo. Em um primeiro momento, houve a tentativa de utilizar a ferramenta Intalio, pois trata-se de um BPMS totalmente livre, que executa todos os passos do BPM. No entanto, como não seria utilizado a parte de implementação do BPMS e como a parte de modelagem não era tão intuitiva, como outras ferramentas, foi escolhido outro software. A ferramenta utilizada foi o BizAgi que suporta a notação BPMN o qual a partir dela foi modelado o processo de alocação de salas atual e com a mesma modelar um processo de alocação de salas ideal. A escolha do BizAgi se deu por ser uma ferramenta de mais fácil manipulação e compreensão das funcionalidades. Mesmo não tendo em mãos um manual BPMN, é possível, intuitivamente, modelar alguns processos. No entanto, o BizAgi só é livre em algumas etapas da metodologia BPM, mais precisamente para a modelagem dos processos suciente para esse trabalho. Com o auxílio da planilha fornecida pelo coordenador do Departamento de Ciência da Computação juntamente com a descrição do cenário de alocação de salas, foi possível fazer a modelagem do processo real de alocação de salas do Departamento de Ciência da Computação. Após terminado a primeira versão do Diagrama, foi novamente marcada uma reunião com o principal responsável pela alocação de salas, o coordenador do departamento, para que o mesmo pudesse validar o diagrama do processo. Retiradas algumas ambigüidades no diagrama e falta de compreensão de algumas atividades e tarefas do processo, então é que foi possível a validação nal do diagrama do processo de alocação de salas e termos nalizado a etapa AS-IS, isto é, conseguir modelar o processo de alocação de salas como ele está ocorrendo atualmente. Como mostrado na Figura 3.2 Etapa TO-BE Por meio da identicação dos processos atuais nas etapas anteriores, uma análise detalhada do processo de alocação de salas real foi feita para que possam ser identicadas necessidades e ir atrás de possíveis melhorias para denir o redesenho do processo de alocação, que no trabalho presente, daremos o nome de processo alocação de salas ideal. O desenvolvimento e transformação de processos consistem em identicar necessidades, melhorias e oportunidades para a revisão e denição de processos, modelar os novos processos desenvolvidos no Modelo do Negócio e aprovar este novo modelo [17]. Este processo de alocação de salas ideal (TO-BE) seria um cenário onde as matérias que necessitam em algum momento no decorrer do semestre de uma aula prática nos 30

41 laboratórios de informática do departamento (LINF) somente utilizassem o mesmo para tal atividade, ou seja, aulas teóricas em sala de aula e aulas práticas no LINF somente quando fosse solicitado no decorrer do semestre. É necessário que se estabeleça medidas pertinentes do início ao m do processo que serão indicadoras de desempenho do mesmo que poderão ser ou não aprovadas pelo coordenador do curso. Qualquer que seja a decisão do coordenador, serão feitos os mesmos procedimentos que são: Revisão, Modelagem e Implementação. Tais procedimentos são cíclicos, ou seja, após a implementação sempre terá que haver um aperfeiçoamento do processo, uma vez que a organização, no caso o Departamento de Ciência da Computação, estará sempre em fase de mudança, isto é, apresentará sempre um caráter dinâmico. O novo processo será modelado para uma futura validação por parte do coordenador do departamento. Os recursos de TI são determinantes para as propostas de transformações e inovações. Logo, a etapa TO-BE é composta pelo(a): Aperfeiçoamento (Desenvolvimento, Implantação, Gerenciamento e Interação); Medições, controle (Análise); Aperfeiçoamento contínuo (Otimização). Então, iniciou-se o redesenho do diagrama do processo real até que foi concluído o uxo do novo processo representado pelo diagrama do processo de alocação de salas ideal. Como mostrado na Figura 3.3. Por meio da reunião para a validação com o coordenador, a atividade de alocação de salas do LINF cou somente sob responsabilidade daquele e não foi encontrada nenhuma lacuna no processo de alocação ideal de salas de aula do departamento de ciência da computação e com isso a utilização desse diagrama ideal no trabalho que está sendo feito Validação Para que fosse possível validar o processo, isto é, ver se realmente a partir do diagrama do modelo ideal (TO-BE) desenvolver um sistema que tornaria o processo de alocação de salas do CIC mais automatizado, foram feitas algumas telas desse possível sistema. Essas telas é o denominado Protótipo que foram feitas a partir de uma ferramenta encontrada na web denominada Balsamiq Mockups [18] que tem como principal função a realização de telas que servirão de modelos para uma apresentação mais abstrata de como será um futuro sistema com suas principais funcionalidades. Em seguida, foi validado as telas do possível sistema com o coordenador do curso. Protótipo As telas que seguirão segue o uxo demonstrado na Figura 3.4. Cada tela pertence a uma atividade da instância do processo, ou seja, a partir das atividades, foi possível extrair os requisitos para gerar um protótipo do sistema que será desenvolvido, denominado como SASA (Sistema de Alocação de Salas de Aula), bem como concluir a fase de validação da ER. 31

42 O sistema teria como uma das telas a Figura 3.5, onde está presente o Menu que indicará os possíveis recursos disponibilizados pelo sistema. Cada ítem no Menu do sistema corresponde a um CRUD ((acrônimo de Create, Retrieve, Update e Delete, em língua Inglesa)) para operações básicas no banco de dados relacional. Isto é, um CRUD para Disciplina, um CRUD para Professor e um CRUD para Sala. Ao considerar o banco de dados vazio no início, no ítem Sistema do menu tem a opção Exportar histórico que consiste em carregar as disciplinas, salas de aula, horários e professores responsáveis no banco. Feito isso, tem-se as demais opções no menu os quais são: Importar histórico: função responsável por trazer do banco o histórico de alocações anteriores; Executar nova alocação: função responsável, como o próprio nome diz, em alocar nova disciplina no banco de dados do sistema; Pré-alocação de matéria: função responsável em alocar as matérias dos semestres anteriores no semestre que iniciará, caso não haja nenhuma disciplina nova para ser inserida no banco de dasos; Exportar PDF: função responsável para exportar o PDF de alocação feita no semestre como um forma de comprovante de alocação realizada com sucesso; Sair: função responsável que naliza o sistema. Umas das funções do sistema é incluir novas disciplinas no banco de dados do departamento de ciência da computação. Seguindo o uxo do processo, essa é uma atividade que o coordenador faz paralelamente à atividade de enviar uma mensagem ao professor. Na tela, mostrada na Figura 3.6, é onde o usuário, nesse caso o coordenador inserirá os parâmetros da nova disciplina, que são o Código o Nome e a Turma e a Carga horária da disciplina e se a mesma possui ou não Créditos Práticos. Caso a resposta desse último parâmetro seja sim, somente o coordenador terá a opção de escolher os laboratórios do LINF para que sejam ministradas as aulas práticas no mesmo. Quanto às demais informações em relação a horário e salas que não o LINF serão fornecidas pelo professor. Seguindo o token para a raia do professor, a tela seguinte, mostrada na Figura 3.7 consiste em mostrar ao professor as alternativas que o mesmo possui para que seja possível ministrar sua(s) disciplina(s) no decorrer do semestre. Como foi mencionado anteriormente, o professor não poderá escolher salas do LINF para ministrar suas aulas teóricas, somente aulas práticas depois do coordenador ter alocado a salas do LINF para ele. Ainda na instância que prossegue logo após o processo ter saído da raia do professor, o token retorna novamente para o coordenador e esse pode ter acesso à seguinte tela, mostrado na Figura 3.8. Essa parte do sistema tem a função de pré-alocar de forma automática as matérias que já existem na base de dados do departamento. Para que essa função seja feita, basta o coordenador decidir por meio de um clique se deseja executar aquela atividade naquele momento. Caso o coordenador decida pré-alocar a matéria a função é executada e não necessitando mais alocar outra matéria no banco, o processo é nalizado. Finalizando a demonstração do sistema com o protótipo na forma de telas, temos que ao nal do processo, depois do coordenador ter seguido todas as etapas, a tela nal, 32

43 mostrado na Figura 3.9, pergunta se o coordenador do departamento já encerrou suas atividades, ou se ainda possui matérias novas pendentes de alocação. Caso tenha se encerrado as matérias, o processo é nalizado com sucesso. As telas foram mostradas ao principal agente interessado no processo de alocação de salas do CIC que é o coordenador do departamento e as mesmas foram validadas, ou seja, o protótipo está consistente, compreensível, completo, real, obteve os requisitos concretizados, rastreável e em conformidade com as norma estabelecidas. Logo, a fase de validação foi nalizada depois da aprovação do coordenador do CIC. 33

44 Figura 3.2: Diagrama do processo real de alocação de salas (AS-IS). 34

45 Figura 3.3: Diagrama do processo ideal de alocação de salas (TO-BE). 35

46 Figura 3.4: Fluxo do Processo TO-BE que indica as telas do protótipo. 36

47 Figura 3.5: Tela menu do protótipo. Figura 3.6: Tela para inclusão de disciplinas. 37

48 Figura 3.7: Tela para inclusão de preferências. Figura 3.8: Tela para pré-alocação de matérias. 38

Conceitos de Processos & BPM

Conceitos de Processos & BPM http://rogerioaraujo.wordpress.com Série Rações Semanais Conceitos de Processos & BPM Parte I Rogério Araújo http://rogerioaraujo.wordpress.com Série Rações Semanais Conceitos de Processos & BPM Parte

Leia mais

DISSEMINAÇÃO DE CONHECIMENTO FERRAMENTA BIZAGI

DISSEMINAÇÃO DE CONHECIMENTO FERRAMENTA BIZAGI DISSEMINAÇÃO DE CONHECIMENTO FERRAMENTA BIZAGI Harley Caixeta Seixas Márcia Lúcia Borges de Melo Gomes Roberta A. de Mello Bezerra Silvana Dias Soares FERRAMENTA BIZAGI BPMN Business Process Modeling Notation

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Treinamento BPM e BPMN Apresentação Executiva

Treinamento BPM e BPMN Apresentação Executiva Apresentação Executiva 1 O treinamento de BPM e BPMN tem como premissa capacitar o aluno a captar as atividades relativas a determinado processo da empresa, organizá-las, gerando um fluxograma de atividades/processos,

Leia mais

Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012

Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012 Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012 O que é um processo? Um processo é um grupo de atividades realizadas numa seqüência lógica com o objetivo de produzir um bem ou um

Leia mais

Framework de comunicação para Webservices P2P

Framework de comunicação para Webservices P2P Universidade Federal de Ouro Preto - UFOP Instituto de Ciências Exatas e Biológicas - ICEB Departamento de Computação - DECOM Framework de comunicação para Webservices P2P Aluno: Brayan Vilela Alves Neves

Leia mais

Adm. Vinicius Braga admviniciusbraga@gmail.com. Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br

Adm. Vinicius Braga admviniciusbraga@gmail.com. Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br Adm. Vinicius Braga admviniciusbraga@gmail.com Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br Objetivos Contextualização Conceitos Boas práticas de modelagem Elementos do BPMN Tipos

Leia mais

Framework de comunicação para Webservices 2P2

Framework de comunicação para Webservices 2P2 Universidade Federal de Ouro Preto - UFOP Instituto de Ciências Exatas e Biológicas - ICEB Departamento de Computação - DECOM Framework de comunicação para Webservices 2P2 Aluno: Brayan Vilela Alves Neves

Leia mais

BPMN (Business Process. George Valença gavs@cin.ufpe.br

BPMN (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 mais

BPMN: Identificando vantagens e desvantagens do uso desta ferramenta para modelagem de processos.

BPMN: Identificando vantagens e desvantagens do uso desta ferramenta para modelagem de processos. BPMN: Identificando vantagens e desvantagens do uso desta ferramenta para modelagem de processos. Franciele da Costa Canello 1 RESUMO As organizações estão cada vez mais necessitando de sistemas que aliem

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

INTRODUÇÃ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 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 mais

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015 BPMN Business Process Modeling Notation Leandro C. López Agosto - 2015 Objetivos Conceitos Boas práticas de modelagem Elementos do BPMN Tipos de processos Apresentar os conceitos e elementos da notação

Leia mais

Ciclo BPM: da Estratégia à Medição

Ciclo BPM: da Estratégia à Medição Treinamentos em Gestão por Processos Ciclo BPM: da Estratégia à Medição Da modelagem e análise ao monitoramento da execução de processos automatizados: tudo o que você precisa saber para fazer a Gestão

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Executive Proposal: Um Padrão para a Apresentação de Propostas de Projetos

Executive Proposal: Um Padrão para a Apresentação de Propostas de Projetos Executive Proposal: Um Padrão para a Apresentação de Propostas de Projetos Corneli Gomes Furtado Júnior 1, Thiago Ferraz 1, Rossana Maria de Castro Andrade 1 1 Departamento de Computação Universidade Federal

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Unidade: Pró-Reitoria de Desenvolvimento Institucional - PRDI Nº: MANUAL DE PROCEDIMENTOS. TÍTULO: Modelar Processos 1/17

Unidade: Pró-Reitoria de Desenvolvimento Institucional - PRDI Nº: MANUAL DE PROCEDIMENTOS. TÍTULO: Modelar Processos 1/17 1/17 ESTA FOLHA ÍNDICE INDICA EM QUE REVISÃO ESTÁ CADA FOLHA NA EMISSÃO CITADA R. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 R. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 FL. FL. 01 X 26 02 X 27 03 X 28 04 X 29 05 X 30 06 X

Leia mais

BPMN. Business Process Modeling Notation

BPMN. Business Process Modeling Notation BPMN Business Process Modeling Notation Montar viagem UML (diagrama de atividades) Montar viagem BPMN Tipos de diagrama 1) Private Business Process ou Diagramas de processos privados: usado quando não

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Curso de BPMN - II. Desenho de processo

Curso de BPMN - II. Desenho de processo Curso de BPMN - II Glauco Reis (gsrt@terra.com.br) é Consultor em Java e metodologias OO, e especializado em plataforma IBM. Têm o título de SCJP 1.1 e 1.4, SCJWCD 1.4, e IBM CSE e IBM Websphere Application

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

BEM-VINDO!!! Apresentação Inicial. Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos

BEM-VINDO!!! Apresentação Inicial. Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos Apresentação Inicial BEM-VINDO!!! Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos 1 Mapeamento de Processos Mapeamento de Processos e Negócios com BPM 2 Ementa Introdução Definição

Leia mais

BPM Definições e Contexto Prática Aula 1

BPM Definições e Contexto Prática Aula 1 BPM Definições e Contexto Prática Aula 1 BP Business Process Algumas definições sobre o que é Processos de Negócio (BP) Um processo é um fluxo coordenado e padronizado de atividades executadas por pessoas

Leia mais

PROPOSTA PARA AUTOMAÇÃO DO PROCESSO DE ELABORAÇÃO DE HORÁRIOS DO CENTRO UNIVERSITÁRIO UNIVATES

PROPOSTA PARA AUTOMAÇÃO DO PROCESSO DE ELABORAÇÃO DE HORÁRIOS DO CENTRO UNIVERSITÁRIO UNIVATES XIV COLÓQUIO INTERNACIONAL DE GESTÃO UNIVERSITÁRIA CIGU A Gestão do Conhecimento e os Novos Modelos de Universidade Florianópolis Santa Catarina Brasil 3, 4 e 5 de dezembro de 2014. ISBN: 978-85-68618-00-4

Leia mais

BPMN - Business Process Modeling and Notation

BPMN - Business Process Modeling and Notation BPMN - Business Process Modeling and Notation AGENDA Notação Conceito Visão Geral da Notação BPMN Notação BPMN no Escritório de Processos NOTAÇÃO - CONCEITO Segundo o dicionário: Ação de indicar, de representar

Leia mais

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS Cilene Loisa Assmann (UNISC) cilenea@unisc.br Este estudo de caso tem como objetivo trazer a experiência de implantação

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01 PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01 LEVANTAMENTO, MODELAGEM

Leia mais

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN Business Process Modeling Notation Business Process Modeling Notation Página 1 Objetivo O objetivo deste curso é apresentar os elementos da notação de modelagem de processos de negócio BPMN 1.1 (Business

Leia mais

Dominando o Mapeamento de Processos com BPMN 2.0

Dominando o Mapeamento de Processos com BPMN 2.0 Treinamentos em Gestão por Processos Dominando o Mapeamento de Processos com BPMN 2.0 Representando processos de negócio com a notação mais poderosa do Mercado. BPMN (Business Process Model and Notation)

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1

MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1 MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1 Prof. Dr. Jorge Henrique Cabral Fernandes (jhcf@cic.unb.br) Departamento de Ciência da Computação

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN

Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN Benefícios da modelagem Em uma organização orientada a processos, modelos de processos são o principal meio para medir o desempenho

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

EProcessos: Um Sistema para Edição de Processos de Software

EProcessos: Um Sistema para Edição de Processos de Software Universidade Federal de Ouro Preto - UFOP Instituto de Ciencias Exatas e Biologicas - ICEB Departamento de Computação - DECOM EProcessos: Um Sistema para Edição de Processos de Software Aluno: Sávio Geraldo

Leia mais

POLÍTICA ORGANIZACIONAL

POLÍTICA ORGANIZACIONAL POLÍTICA ORGANIZACIONAL PARA DESENVOLVIMENTO DE SOFTWARE NA DR TECH Data 01/03/2010 Responsável Doc ID Danielle Noronha PoliticaOrg_DR_V003 \\Naja\D\Gerenciamento\Política Localização Organizacional Versão

Leia mais

Material para nivelamento de informações sobre Mapeamento de Processos

Material para nivelamento de informações sobre Mapeamento de Processos Material para nivelamento de informações sobre Mapeamento de Processos 1 Objetivo Nivelar informações e conceitos sobre mapeamento de processos na UFABC. O que é um processo?? É um conjunto de atividades

Leia mais

Gestão de Processos de Negócios

Gestã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 mais

Administração de Sistemas de Informações Gerenciais

Administração de Sistemas de Informações Gerenciais O computador deve ser encarado como uma ferramenta de auxílio à resolução de problemas que podem ser de natureza cientifica, comercial ou qualquer outra. O hardware é a parte física do computador, ou seja,

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Palavras-Chave: Aquisições; Planejamento de Aquisições; Controle de Aquisições; Projeto; Lead time; Processo; Meta.

Palavras-Chave: Aquisições; Planejamento de Aquisições; Controle de Aquisições; Projeto; Lead time; Processo; Meta. 1 A INFLUÊNCIA DO PLANEJAMENTO E CONTROLE DA AQUISIÇÃO NO PRAZO FINAL DO PROJETO Euza Neves Ribeiro Cunha RESUMO Um dos grandes desafios na gerência de projetos é planejar e administrar as restrições de

Leia mais

Extração de Requisitos

Extração de Requisitos Extração de Requisitos Criação: Março 2001 Atualização: Setembro 2005 Referências I.Sommerville. Sw Engineering, 6ª ed, 2001, cap6 P.Jalote. An Integrated Approach to Sw Engineering, 2ª ed., 1997, cap3

Leia mais

Introdução ao BPM e CBOK. Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR

Introdução ao BPM e CBOK. Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR Introdução ao BPM e CBOK Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR BPM CBOK O Guia para o Gerenciamento de Processos de Negócio - Corpo Comum de Conhecimento

Leia mais

Tutorial de BPMN. Visão Geral. Escopo. Elementos

Tutorial de BPMN. Visão Geral. Escopo. Elementos Tutorial de BPMN Visão Geral É um padrão para modelagem de processos de negócio que fornece uma notação gráfica para especificação de processos de negócio em um DPN (Diagrama de Processo de Negócios).

Leia mais

Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo

Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo DOCUMENTAÇÃO TÉCNICA Melhores práticas de gerenciamento de ativos de software JUNHO DE 2013 Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo John Fulton CA IT Business Management

Leia mais

TRABALHO 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 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 mais

Levantamento de Requisitos.

Levantamento de Requisitos. FACULDADES INTEGRADAS MATO-GROSSENSES DE CIÊNCIAS SOCIAIS E HUMANAS RESUMO Levantamento de Requisitos. Leandro Cícero da Silva Mello. Prof. Jeanine Ferrazza Meyer Metodologia e Técnica de Pesquisa- Levantamento

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I BPMN I Ricardo de Sousa Britto rbritto@ufpi.edu.br 1 + Processo de Negócio 2 n Coleção de atividades relacionadas e estruturadas que produzem um serviço ou produto específico.

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01 ASPECTOS DE MUDANÇA CULTURAL

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Fase 1: Engenharia de Produto

Fase 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 mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR. Business Process Modeling Notation BPMN

Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR. Business Process Modeling Notation BPMN Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR Business Process Modeling Notation BPMN BPMN Business Process Modeling Notation A especificação da notação de modelagem

Leia mais

Conhecimento em Tecnologia da Informação. Catálogo de Serviços. Conceitos, Maturidade Atual e Desafios. 2012 Bridge Consulting All rights reserved

Conhecimento em Tecnologia da Informação. Catálogo de Serviços. Conceitos, Maturidade Atual e Desafios. 2012 Bridge Consulting All rights reserved Conhecimento em Tecnologia da Informação Catálogo de Serviços Conceitos, Maturidade Atual e Desafios 2012 Bridge Consulting All rights reserved Apresentação Esta publicação tem por objetivo apresentar

Leia mais

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Mauricio Fiorese 1, Alessandra Zoucas 2 e Marcello Thiry 2 1 JExperts

Leia mais

CURSO DE MAPEAMENTO DE PROCESSOS DE TRABALHO COM BPMN E BIZAGI

CURSO DE MAPEAMENTO DE PROCESSOS DE TRABALHO COM BPMN E BIZAGI INSTITUTO SERZEDELLO CORRÊA CURSO DE MAPEAMENTO DE PROCESSOS DE TRABALHO COM BPMN E BIZAGI Exercícios JANEIRO, 2013 Copyright 2013, Tribunal de Contas de União www.tcu.gov.br Permite-se a reprodução desta

Leia mais

silviaheld@usp.br Italiano, Isabel Cristina. Profa. Dra. - Têxtil e Moda - Escola de Artes, Ciências e RESUMO ABSTRACT

silviaheld@usp.br Italiano, Isabel Cristina. Profa. Dra. - Têxtil e Moda - Escola de Artes, Ciências e RESUMO ABSTRACT MAPEAMENTO DE PROCESSOS DE CONFECÇÃO PARA IDENTIFICAÇÃO DE PONTOS CRÍTICOS DA PRODUÇÃO Espinosa, Caroline Stagi - Bacharel em Têxtil e Moda - Escola de Artes, Ciências e Humanidades - Universidade de São

Leia mais

BPM. (Business Process Management) Gerenciamento de Processos de Negócio. Meta IT Mapeamento de Processos BPM ARIS Módulo 1

BPM. (Business Process Management) Gerenciamento de Processos de Negócio. Meta IT Mapeamento de Processos BPM ARIS Módulo 1 BPM (Business Process Management) Gerenciamento de Processos de Negócio Meta IT Mapeamento de Processos BPM ARIS Módulo 1 Agenda 1 2 3 Conceitos BPM x TI Softwares BPM 4 Certificações Conceitos O que são

Leia mais

UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE ENGENHARIA ENGENHARIA DE PRODUÇÃO MILLENA SILVA PAIVA ESTÁGIO SUPERVISIONADO EM ENGENHARIA DE PRODUÇÃO

UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE ENGENHARIA ENGENHARIA DE PRODUÇÃO MILLENA SILVA PAIVA ESTÁGIO SUPERVISIONADO EM ENGENHARIA DE PRODUÇÃO UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE ENGENHARIA ENGENHARIA DE PRODUÇÃO MILLENA SILVA PAIVA ESTÁGIO SUPERVISIONADO EM ENGENHARIA DE PRODUÇÃO GOIÂNIA 2015 2 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO

Leia mais

UTILIZAÇÃO DA TECNOLOGIA BPMS PARA IMPLEMENTAÇÃO DE PROCESSOS ADERENTES AO MODELO DO MPS.BR

UTILIZAÇÃO DA TECNOLOGIA BPMS PARA IMPLEMENTAÇÃO DE PROCESSOS ADERENTES AO MODELO DO MPS.BR UTILIZAÇÃO DA TECNOLOGIA BPMS PARA IMPLEMENTAÇÃO DE PROCESSOS ADERENTES AO MODELO DO MPS.BR Karin Maria Sohnlein (UNISC) karin.sohnlein@gmail.com Rafael Bortolini (UNISC) rfbortolini@gmail.com Vinicius

Leia mais

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA O Impacto da Engenharia de Requisitos no Processo de Métricas Fátima Cesarino CAIXA Apresentação Diferentes Cenários Desenvolvimento Software Importância do SISP Agradecimento Oportunidade Responsabilidade

Leia mais

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS Rosiane da Silva Biscaia Discente do curso Tecnologia em Análise e Desenvolvimento de Sistemas Faculdades

Leia mais

Modelagem de Processos de Negócio

Modelagem de Processos de Negócio Treinamentos em Gestão por Processos Modelagem de Processos de Negócio Documentando o conhecimento sobre processos de negócio de forma clara e completa Conhecida como a base para iniciativas de processos,

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

PEN - 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 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 mais

BPMN. Business Process Modeling Notation. Outubro/2006. Rafael Bortolini rafael@cryo.com.br Cryo Technologies www.cryo.com.br

BPMN. Business Process Modeling Notation. Outubro/2006. Rafael Bortolini rafael@cryo.com.br Cryo Technologies www.cryo.com.br BPMN Business Process Modeling Notation Outubro/2006 Rafael Bortolini rafael@cryo.com.br Cryo Technologies www.cryo.com.br 1 Agenda Introdução História Especificação Swinlanes Atividades Eventos Gateways

Leia mais

Gestão de Processos. Principais etapas, decisões e desafios da implantação de processos de TI com base no ITIL

Gestão de Processos. Principais etapas, decisões e desafios da implantação de processos de TI com base no ITIL Conhecimento em Tecnologia da Informação Gestão de Processos Principais etapas, decisões e desafios da implantação de processos de TI com base no ITIL 2011 Bridge Consulting Apresentação É comum que as

Leia mais

Verificação e Validação de Requisitos

Verificação e Validação de Requisitos Verificação e Validação de Requisitos Verificação e Validação dos Requisitos Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção Verificar conflitos de requisitos Verificar consistência

Leia mais

Definições. BPM - Business Process Management. BPMN Business Process Modeling Notation. BPMS Business Process Management System

Definições. BPM - Business Process Management. BPMN Business Process Modeling Notation. BPMS Business Process Management System Definições BPM - Business Process Management BPMN Business Process Modeling Notation BPMS Business Process Management System Erros da Gestão de Processos / BPM 1. Fazer a Gestão sem Automação Desenho,

Leia mais

Auditoria de Sistemas. UNIPAC Ipatinga Segurança e Auditoria de Sistemas Prof. Thiago Lopes Lima

Auditoria de Sistemas. UNIPAC Ipatinga Segurança e Auditoria de Sistemas Prof. Thiago Lopes Lima Auditoria de Sistemas UNIPAC Ipatinga Segurança e Auditoria de Sistemas Prof. Thiago Lopes Lima Auditoria É uma atividade que engloba o exame das operações, processos, sistemas e responsabilidades gerenciais

Leia mais

Questão em foco: Colaboração de produto 2.0. Uso de técnicas de computação social para criar redes sociais corporativas

Questão em foco: Colaboração de produto 2.0. Uso de técnicas de computação social para criar redes sociais corporativas Questão em foco: Colaboração de produto 2.0 Uso de técnicas de computação social para criar redes sociais corporativas Tech-Clarity, Inc. 2009 Sumário Sumário... 2 Introdução à questão... 3 O futuro da

Leia mais

UM CATÁLOGO DE BOAS PRÁTICAS, ERROS SINTÁTICOS E SEMÂNTICOS EM MODELOS BPMN

UM CATÁLOGO DE BOAS PRÁTICAS, ERROS SINTÁTICOS E SEMÂNTICOS EM MODELOS BPMN UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO UM CATÁLOGO DE BOAS PRÁTICAS, ERROS SINTÁTICOS E SEMÂNTICOS EM MODELOS BPMN Cynthia Raphaella da Rocha Franco

Leia mais

Teste de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br

Teste de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Teste de Software Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Qualidade Garantia de Qualidade Qualidade do processo Qualidade do produto Testes Estáticos Testes Dinâmicos Teste de software

Leia mais

ESTUDO E AVALIAÇÃO DA ÁREA DE PROCESSO GESTÃO DE REQUISITOS DE ACORDO COM A NORMA CMMI NÍVEL 2 NA EMPRESA SWQUALITY

ESTUDO E AVALIAÇÃO DA ÁREA DE PROCESSO GESTÃO DE REQUISITOS DE ACORDO COM A NORMA CMMI NÍVEL 2 NA EMPRESA SWQUALITY ESTUDO E AVALIAÇÃO DA ÁREA DE PROCESSO GESTÃO DE REQUISITOS DE ACORDO COM A NORMA CMMI NÍVEL 2 NA EMPRESA SWQUALITY FABRÍCIO DE ALMEIDA OLIVEIRA ANA CRISTINA ROUILLER UFLA - Universidade Federal de Lavras

Leia mais

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais

O desafio de uma visão mais ampla

O desafio de uma visão mais ampla com SAP NetWeaver BPM Descrição de Solução A competição acirrada tem levado as organizações a adotar novas disciplinas de gestão e empregar recursos tecnológicos avançados, a fim de atingir melhores índices

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor.

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor. Módulo 6 Módulo 6 Desenvolvimento do projeto com foco no negócio BPM, Análise e desenvolvimento, Benefícios, Detalhamento da metodologia de modelagem do fluxo de trabalho EPMA. Todos os direitos de cópia

Leia mais

DOCUMENTO DE REQUISITOS

DOCUMENTO DE REQUISITOS DOCUMENTO DE REQUISITOS ID documento: Data: / / Versão : Responsável pelo documento: ID Projeto: HISTÓRICO DE REVISÕES Data de criação/ atualização Descrição da(s) Mudança(s) Ocorrida(s) Autor Versão do

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Engenharia de Software Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Thiago P. da Silva thiagosilva.inf@gmail.com Agenda Engenharia de Requisitos Níveis de Descrição dos Requisitos Tipos

Leia mais

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

A gestão de processos de negócio: conceitos e ferramentas BPM

A gestão de processos de negócio: conceitos e ferramentas BPM FACULDADE DE LETRAS DA UNIVERSIDADE DO PORTO A gestão de processos de negócio: conceitos e ferramentas BPM Trabalho realizado por: Ana Luisa Veiga Filipa Ramalho Doutora Maria Manuela Pinto GSI 2007 AGENDA:

Leia mais

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso...

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso... Projeto de Software usando UML Sumário Capítulo I : Casos de Uso...3 1. Modelo de Casos de Uso... 3 2. Diagramas de Casos de Uso... 3 3. Exemplo... 9 4. Conclusão... 13 Capítulo II : Levantamento de Classes...15

Leia mais