Departamento de Computação Trabalho de Conclusão de Curso

TIAGO DE OLIVEIRA STUTZ

Agregando Valor ao Software Por Meio da Modelagem de Negócios

Londrina 2006

TIAGO DE OLIVEIRA STUTZ

Agregando Valor ao Software Por Meio da Modelagem de Negócios

Trabalho de conclusão de curso obrigatório desenvolvido durante o 4º ano do Curso de Graduação em Ciência da Computação como requisito parcial à obtenção do título de Bacharel. Orientador: Prof. Ms. Rodolfo Miranda de Barros

2006

ii

TIAGO DE OLIVEIRA STUTZ

Agregando Valor ao Software Por Meio da Modelagem de Negócios

COMISSÃO EXAMINADORA

_______________________________ Prof. Ms. Rodolfo Miranda de Barros Universidade Estadual de Londrina

_______________________________ Prof. Ms. Daniel dos Santos Kaster Universidade Estadual de Londrina

_______________________________ Prof. Dra. Maria Angélica Maria Angélica de O. C. Brunetto Universidade Estadual de Londrina Londrina,___de___________ de 2006.

não merece ser pago pelo que faz” By Abraham Lincoln .iii “O homem que trabalha somente pelo que recebe.

iv DEDICATÓRIA A Deus. meu conselheiro. meu conforto. . à minha família. meu alicerce e à minha futura esposa Camila.

incentivo. força e direção para conseguir chegar até aqui com saúde. sinergia e tudo mais “que enche um belo prato”. pelo apoio incondicional em todos momentos. Agradeço especialmente ao meu irmão. por ter me dado ânimo. frustração. Agradeço à minha futura esposa Camila pelo amor. aprendizado. Diversão! Ao meu orientador professor Rodolfo Miranda de Barros que me mostrou possibilidades de aprendizado que me motivaram a fazer esse trabalho. pela motivação. primeiramente.v AGRADECIMENTOS Agradeço. Obrigado “fao”! Agradeço a Deus por ser seu irmão! Aos “hermanos” da Equipe Puerto Rico pelos grandes momentos de descontração. alegria e SATISFAÇÃO. sempre me oferecendo ajuda e apoio com muito amor. companheirismo. a Deus. Flávio de Oliveira Stutz. diversão. pela confiança e principalmente pelo amor. técnicos e secretárias do departamento de computação pelo empenho e dedicação para fazer do curso de Ciência da Computação da UEL um dos melhores do país. Ao professor Daniel dos Santos Kaster que mais do que um professor se tornou um amigo admirável que me deu diversos conselhos e me ajudou sempre que precisei em todas as circunstâncias não só acadêmicas. me mostrando os melhores caminhos a se seguir. paciência e dedicação. por ter me auxiliado em muitas decisões. motivação. alegria. Agradeço à minha família. A todos os funcionários. nosso criador. disposição. carinho e compreensão nos momentos mais turbulentos do curso. .

engenharia de software. Universidade Estadual de Londrina. RESUMO Esse estudo compreende a análise da importância da modelagem de negócios nas fases iniciais de um projeto de software. Tiago De Oliveira. também. Palavras-chave: desenvolvimento de software. EKD. Londrina. serão estudados conceitos teóricos já consolidados como a disciplina de Modelagem de Negócios a qual está dentro do Rational Unified Process (RUP) e a metodologia Enterprise Knowledge Development (EKD) que é usada para extração do conhecimento. modelagem de negócios. . será analisado. 2006. como esse grupo de atividades interfere em todo o ciclo de vida e qual o impacto disso no valor dado ao software desenvolvido. Monografia (Bacharel em Ciência da Computação) – Departamento de Ciência da Computação. RUP. 2006.vi STUTZ. UML. Nesse contexto. Agregando Valor ao Software Por Meio da Modelagem de Negócios. Para verificar a relevância desse procedimento.

EKD. Inside this context. business modeling. ABSTRACT This study understands an analysis about the importance of Business Modeling in the initial phases of a software project. State University of Londrina. such as the Business Modeling discipline which is inside of Rational Unified Process (RUP) and the methodology Enterprise Knowledge Development (EKD) which is used for extraction of the knowledge. how this set of activities intervenes in all the life cycle and what’s its impact on the value given to the developed software. RUP. Tiago De Oliveira. Londrina. Key-words: software development.vii STUTZ. Monograph (Graduation in Computer Science) – Department of Computer Science. 2006. To verify the relevance of this procedure. Aggregating Value to the Software Through Business-Modeling. UML. software engineering. also. . it will be analyzed. consolidated theoretical concepts will be studied. 2006.

................................................. 2000) ................................................. 69 Figura 17: Exemplo de caso de uso de negócio (RUP................. 64 Figura 12: Decisão (RUP........................... 2000) ........................ ... 65 Figura 15: Parte de um Glossário........................................... al.......... 75 Figura 20: Modelo de objetos de negócio ilustrando um caso de uso de negócio de Check-in Individual (RUP................................................................................. PERSSON & STIRNA 2001) . 2002)............................................................... Considerado para esboço (BUBENKO... 64 Figura 13: Barra de sincronização (RUP................. 63 Figura 9: Estado Inicial (RUP...... PERSSON & STIRNA 2001)........... 78 Figura 22: Modelo de Caso de Uso de Negócio – Transação Financeira (KRUCHTEN et................. No diagrama acima estão apontados os componentes básicos de um diagrama de atividades................ 62 Figura 7: Exemplo de Entidade de Negócio (RUP...... Pode ser considerado bom para versão final (BUBENKO............. 2002) .......................... 61 Figura 6: Exemplo de Trabalhador de Negócio (RUP..... 2002) ......... 2002)......................... 49 Figura 5: Exemplo de Ator de Negócio (RUP.......... 2002) ........................................................................................... 63 Figura 11: Estado Final (RUP............... 2002) ......................... 2002)............. 40 Figura 3: O processo da verificação de endereço de cliente em alto nível........ 19 Figura 2 – Tabela comparativa entre algumas técnicas de modelagem organizacional ................................ 67 Figura 16: exemplo de um documento de Visão em forma de panfleto ... 2002).................. 72 Figura 18: Exemplo de diagrama de atividades........ 63 Figura 10: Exemplo de uma Atividade (RUP.. 74 Figura 19: Diagrama de atividades utilizando raias (swim lanes)...... 49 Figura 4: O processo da verificação de endereço de cliente detalhado............................................ 77 Figura 21: Um diagrama de atividades com fluxos de objetos mostrando como um pedido muda de estado durante o processamento de um pedido............ 2002) ...... 2002)...... .. 62 Figura 8: Exemplo de Caso de Uso de Negócio (RUP.................... 2002) . 92 Figura 23: Modelo de Objetos de Negócio – Transação Financeira (KRUCHTEN et...................... 2002) ........... 92 ....... (RUP.................. al....... 2002) ............................. 64 Figura 14: Exemplo de Raias (RUP...viii LISTA DE FIGURAS Figura 1: Fases e disciplinas do RUP (2002)...........................................

........................ 2000) ..................... al........................ 94 Figura 26: Modelo de Objetos de Negócio – Transação Financeira (KRUCHTEN et......... 93 Figura 25: Modelo de Caso de Uso de Negócio – Transação Financeira (KRUCHTEN et. al.....................................................ix Figura 24: Mapeamento do modelo de negócio para o de sistema (KRUCHTEN et...................................... 2000) ............ al..... 94 Figura 27: Mapeamento dos objetos de negócio para as classes de entidades (KRUCHTEN et.................... 2000) ........ 2000) ........................... al............................................................... 95 .................

....................................... 84 Tabela 4: Relação dos requisitos com os benefícios gerados............................................................................... 83 Tabela 2: Relação entre objetivos da Organização e os problemas em se alcançá-los .x LISTA DE TABELAS Tabela 1: Relação entre objetivos da organização e módulos do sistema ............................................ 84 Tabela 3: Relação entre objetivos da Organização e oportunidades de se alcançálos..... 90 ......................................................

xi LISTAS DE ABREVIATURAS E SIGLAS EKD RUP ROI TI UML XP Enterprise Knowledge Development Rational Unified Process Return On Investiment Tecnologia da Informação Unified Modeling Language eXtreme Programming .

..... 72 4........................................................................2 – Planejando e Adiantando o Próximo Passo......................1 – Principais Papéis da Equipe .................... 66 4..................................................................3..3............................. 22 2...............................................................................2 – Aprovação Pelo Cliente .....................................................................................................................................................................3 – Modelo de Conceitos........ 32 2...............................................................................................................................2.............................2...................................109 ..........................1 – O EKD e a Aprovação do Projeto ....................................3......................................................... 59 4...........................................................................3 – Modelo de Conceitos.........................................................2.......................1 – O que é o RUP...................................1 – Glossário ...3 – Etapa 1: Aprovação do Projeto............................................... 75 5 – ABORDAGEM PRÁTICA...........................1 – Aprovação Pela Equipe.............. 34 2........................................................................................................................4 – Modelo de Processos de Negócios .............................................................58 4...... 84 5............................1 – Artefatos Utilizados na Aprovação do Projeto .................................................................................................1...................................... 88 5........................................................1........................................................... 45 3........................................3 – O EKD e a Modelagem de Negócios............................ 81 5.................................................................... 31 2.......5 – Modelo de Atores e Recursos.............................................. 42 3........ 60 4.............................................1......................1.........................2 – A metodologia EKD............................................................3..... 70 4..................................................... 50 3...................................................................................................2........... 41 3................................3...6 – Modelo de Requisitos e Componentes Técnicos ...............1.......3... 25 2...2 – Modelo de Regras de Negócio ................... 47 3............................6 – Modelo de Requisitos e Componentes Técnicos ..........................39 3.......................................... 16 2..........1 – Gerente de Projeto.................3 – A disciplina de Modelagem de Negócios ..........................................4 – Etapa 2: Planejamento do Desenvolvimento ....................... 90 6 – CONCLUSÃO ................................... 24 2....................... 29 2................................................2 – Analista de Processos de Negócio .....................2......................2 – Visão do Negócio................2..........................1..... 65 4................................................ 35 3 – EKD.........1...........2............ 86 5.................................................. 26 2..................................................................................................................................................................................................................................................................................2...............................13 2 – O RUP E A MODELAGEM DE NEGÓCIOS ...................... 52 3..............16 2..................2 – Artefatos Utilizados no Planejamento do Desenvolvimento .................1 – Notações..............................................100 APÊNDICE A – PROPOSTA EM FORMA DE PANFLETO.......... 54 4 – ARTEFATOS E NOTAÇÕES........................................................2....2 – Modelo de Regras de Negócio .......2......3...............................1 – Modelo de Casos de Uso de Negócio ...............105 APÊNDICE B – PROPOSTA TRADICIONAL...............2.. 44 3................................. 66 4...................................................97 REFERÊNCIAS BIBLIOGRÁFICAS .................................4 – Modelo de Processos de Negócio..........................................................................1.............................1.............................................................................................2 – A fase de iniciação e sua importância ................................80 5........................................................1.......xii SUMÁRIO 1 – INTRODUÇÃO ....... 69 4......................................3......................................2................................................3......2....................................................................1............................................................................................1................................................ 87 5...................3 – Modelo de Objetos de Negócio.2 – Artefatos ..................1 – Visão geral..........................................................................3...........................................................1 – Modelo de Objetivos ...... 46 3....................................................... 89 5...............3................................................................................ 68 4................2................................................................................................... 18 2.5 – Modelo de Atores e Recursos....1 – UML e a Modelagem de Negócios.............................2 – Diagrama de Atividades.........................2....................................................2 – Organização e Documentação das Atividades..............................................................................................................................................1 – Modelo de Objetivos ..................................................................................2...................................... 28 2........................................... 80 5........3 – Designer de Negócio........

a metodologia EKD e algumas experiências e observações feitas com clientes em potencial no mercado. O presente tem como objetivo mostrar como a Modelagem de Negócios é importante no ciclo de vida do desenvolvimento de software e como essa atividade pode agregar valor ao software. mudanças. desenvolvimento . tendo essa metodologia como fundamentação as práticas do RUP. a partir disso. além das perdas financeiras e o ineficiente aproveitamento do que ambas as áreas poderiam oferecer uma para a outra. desentendimentos ou qualquer outro desses tipos de problema que são constantes na maioria dos desenvolvimentos e que geram prejuízos. esse trabalho tem o objetivo de propor uma metodologia para realização da atividade de Modelagem de Negócios. 2004). que se tornaram uma constante em nosso tempo. sendo o principal causador dessa falha a má comunicação entre esses membros e a conseqüente incompreensão. a saber: escopo mal definido (CRUZ. O problema é que devido à velocidade dessas transformações. 2004). evitando ao máximo retrabalho. O maior objetivo dessa metodologia é fazer com que a comunicação com o cliente seja eficiente e que. é gerada uma insatisfação para os membros das duas áreas (MARQUIONI. 2006). por ambas as partes. Nesse estudo serão abordados alguns dos diversos causadores dessa insatisfação e das perdas financeiras. o que fez com que essas duas áreas se aproximassem bastante nesses últimos tempos (CRUZ.13 1 – Introdução Os avanços tecnológicos computacionais. Como conseqüência disso. dos valores e das relações que norteiam o mundo que não o seu. falhas ocorridas pela falta de gerenciamento de riscos. Também contribuir para que o processo de desenvolvimento de software ganhe qualidade. também afetaram as tecnologias empresariais. a integração entre os membros dessas duas áreas ainda não chegou à sua plenitude. dando a este o devido valor. Depois de feita essa análise. ele tenha maior compreensão da importância e do papel do software.

sendo estas devidamente explicadas. mudanças constantes (MARQUIONI. que não é feito atualmente.. eles não vêem. mas um agente inovador dentro de sua empresa. . Diante disso. pelo cliente no momento da construção do software e pelo fornecedor no momento da entrega do software. 2006) e não esclarecimento das funções do software por ambas as partes. ou não vêem o retorno financeiro que irão ter adotando esse sistema no que se refere aos processos de negócios. Assim. pois para o empresário. i.14 desorganizado. trazendo benefícios para os membros da área de computação e empresarial. juntamente com algumas técnicas que podem ser utilizadas nessa atividade. Além disso. sendo esse método sugerido testado e aprovado com alguns clientes. e os desenvolvedores possam ver que um planejamento e modelagem adequados de software não são “perda de tempo” mas uma atividade que os auxiliará a ter controle do desenvolvimento e que irá agregar valor ao seu trabalho e ao seu produto. o que o sistema vai trazer de benefício. As principais contribuições desse trabalho são: a proposta de utilização de algumas técnicas e métodos descritos no RUP juntamente com o método EKD e a divisão da Modelagem de Negócios em duas etapas. fazer de diferente. a priori. Com um pouco de contato com o mercado. é tudo muito simples e óbvio. o trabalho apresentará uma forma de se realizar a modelagem de negócio utilizando essas técnicas citadas acima. bem como seu papel na Organização.e. fazendo com que o empresário possa ver no software não somente uma modernização dos processos de negócio já existentes. ou seja. pois não enxergam a dimensão do negócio que ele realiza. e como ela pode solucionar os problemas citados. será apresentada a Modelagem de Negócios. pode-se observar que os empresários acham que o software é caro.

. o que ele faz e qual o benefício disso para a Organização além das outras possibilidades que ele abre e que podem agregar valor ao negócio realizado. de conclusão. será mostrado no capítulo 5. a disciplina de Modelagem de Negócios do RUP e qual o seu papel dentro dele. mostrando a aplicabilidade dos conceitos e idéias propostos. serão apresentados com mais detalhes alguns artefatos e notações que são utilizados nas atividades da disciplina estudada e qual a importância deles para o desenvolvimento do software. mas que tem valor também pelo que ele traz de custo/benefício à Organização. a Modelagem de Negócios também serve como argumento nas negociações de preço. destacando os principais pontos abordados e as possibilidades futuras dentro do assunto. uma abordagem prática dos conceitos teóricos estudados até então. Dessa maneira o desenvolvedor de software consegue tirar a idéia de que o software tem seu valor somente por ele ser algo que exige um "conhecimento mágico". Chegando ao final. será tratado no capítulo 2. Já no capítulo 4. no capítulo 6. bem como qual valor ele agrega à ela e ao software de maneira geral. Depois desta introdução básica. No capítulo 3. definição de escopo.15 Além dos vários benefícios no que tange ao desenvolvimento propriamente dito (levantamento de requisitos. diminuição de riscos. será feita uma análise geral do que foi apresentado neste trabalho. etc). será apresentado o EKD e qual a sua relação com a Modelagem de Negócios. Finalmente. pois ela deixa claro para o cliente o que ele terá de retorno utilizando o software.

Sua proposta não é a de ser um produto estático com apenas uma perspectiva e não sujeito a customização. HOUSTON & KOZACZYNSKI. descrevendo as melhores práticas para as diversas atividades presentes no ciclo de vida deste desenvolvimento. 2002). Por todos esses motivos e por ele trazer a disciplina de Modelagem de Negócios de uma forma bem estruturada e explicativa é que ele foi escolhido como ponto de partida desse trabalho. . mas para projetos de todos os tamanhos. a qual deve escolher quais os elementos desse framework irão satisfazer suas necessidades (EELES. O processo de criação do RUP foi caracterizado pelo compartilhamento de experiências vividas em diversos projetos de software. 2.16 2 – O RUP e a Modelagem de Negócios O IBM Rational Unified Process (RUP) é o framework1 de processo de desenvolvimento mais utilizado entre as grandes corporações hoje em dia. desde que devidamente customizado. Essa ampla adoção se deve à consistência e versatilidade desse produto uma vez que ele possui práticas e orientações não só para grandes projetos. Além disso. dos quais foram identificados quais práticas e processos foram causadores de falha e quais 1 Estrutura de suporte a alguma atividade. O RUP foi criado pela Rational Software em conjunto com a empresa sueca Objectory AB nos anos 90. parte de sua credibilidade se deve ao dele ser um produto de uma das gigantes da informática: a IBM.1 – O que é o RUP O Rational Unified Process é produto da IBM-Rational que descreve e suporta um processo iterativo de desenvolvimento de software. antes sua composição permite que ele seja adaptável e moldável pela equipe de desenvolvimento que o está utilizando.

fazendo. os criadores do RUP definiram uma série de melhores práticas de software que. Para que uma equipe de desenvolvimento possa adotar essas melhores práticas. é possível que se adote um método ágil utilizando o RUP. 2002). Com o RUP esse problema é resolvido. gerenciamento de requisitos. i. e. 2006). De maneira sucinta. que modelos sejam disponibilizados e que possam existir diferentes alternativas de se adotar essas práticas em função dos diferentes tipos de projeto existentes. pois “o produto Rational Unified Process (RUP) é um processo de negócios genérico” (RUP. .17 foram de sucesso. Dessa forma. HOUSTON & KOZACZYNSKI. entre outros. tais como: diretrizes. arquitetura baseada em componentes. 2002). uso de modelos visuais.. ou seja. iriam eliminar as raízes desses problemas. artefatos. essas práticas são: desenvolvimento iterativo. com que os desenvolvedores desse processo de engenharia de software pudessem reconhecer quais as raízes dos problemas e propor soluções que os eliminariam ainda em sua gênese (WIKIPEDIA. assim como Gibbs (2006) afirma. é preciso que um processo seja estabelecido. Portanto. esse framework disponibiliza para você várias alternativas de customização dos processos descritos e vários modelos e artefatos que podem ser utilizados. É um equívoco comparar o RUP a um método de desenvolvimento. pois ele é como se fosse um grande mercado com várias prateleiras cheias de produtos para que você possa escolher aquele que irá satisfazer suas necessidades. assim. se adotadas. atividades. Muitos profissionais da área de desenvolvimento ou engenharia de software costumam fazer uma distinção entre RUP e métodos de desenvolvimento ágeis – por exemplo. ele não é um produto final assim como os métodos ágeis. mas um framework que contém todos os componentes envolvidos em um desenvolvimento de software. garantindo o sucesso no desenvolvimento do software. verificação contínua da qualidade do software e gerenciamento de mudanças (EELES. papéis. tudo depende da customização. o Extreme Programming (XP) – como se eles fossem adversários que não podem ocupar o mesmo espaço.

se necessário. Um erro muito comum é o pensamento de que a seqüência de tarefas de um desenvolvimento está relacionada às disciplinas enquanto a ordem de execução dessas tarefas está ligada às fases do ciclo de vida. Essas atividades estão diretamente ligadas às disciplinas que devem ser praticadas em cada uma das fases. esse framework disponibiliza uma série de artefatos para que os desenvolvedores possam documentar. o RUP prega um ciclo de vida composto por quatro fases (iniciação. as quais possuem seus objetivos e atividades básicas. Com relação aos modelos.18 Com relação ao processo sistematizado. cada atividade realizada de uma forma padronizada. o ciclo de vida proposto pelo RUP é dividido em 4 fases. construção e transição) sendo que cada uma delas é desenvolvida através de disciplinas bem especificadas. . além de utilizar como notação fundamental a Unified Modeling Language (UML). 2. sendo que a importância e tempo gasto em cada uma das disciplinas variam de acordo com a fase em que o desenvolvimento se encontra. elaboração. A figura abaixo ilustra esse conceito de esforço gasto em cada uma das disciplinas em função da fase do ciclo de vida.2 – A fase de iniciação e sua importância Como foi comentado acima.

A fase de iniciação tem como meta estabelecer um planejamento do ciclo de vida do software e conscientizar todos os envolvidos no processo a respeito desses objetivos e atividades. o que deve ou não estar no software.19 Figura 1: Fases e disciplinas do RUP (2002). Infelizmente. . e. ou seja. passando-se direto para o levantamento de requisitos. a fase de iniciação muitas vezes é misturada com a de elaboração e a Modelagem de Negócios não é realizada. São eles: • Definir o escopo do projeto. alguns objetivos são traçados e devem ser atingidos ao fim dessa fase (RUP. o que ocorre na maioria dos projetos é o atropelamento de fases e disciplinas. 2002). Para que essa meta seja alcançada.. Pode-se observar pelo gráfico que a fase de iniciação é a mais curta de todas e é composta basicamente pelas disciplinas de Modelagem de Negócios e Requisitos. i.

durante o processo de construção. Isso porque quando o escopo do projeto é bem definido. fazendo inclusive algumas provas de conceito1. os riscos também possuem respectivas medidas de redução de impacto. Se um gerenciamento de riscos for feito da forma correta. descobrir a inviabilidade de implementação de alguma funcionalidade que é crucial para o cliente e faz com que a utilidade do sistema seja percebida (EELES. i. se além de identificados. ela pode ter a certeza de possuir informações suficientes para que o mínimo de erro seja cometido durante o projeto e para que conseqüentemente seu produto e serviço sejam de excelente qualidade. por exemplo. especialmente os que são comuns em vários projetos e também estão presentes neste. o que ajuda.. 2002) já nas primeiras releases2 do ciclo de vida.e. a equipe desenvolvedora mostrar serviço ao cliente.20 • • Desenhar os casos de uso críticos do sistema. HOUSTON & KOZACZYNSKI. o cliente terá exatamente as funcionalidades que precisa. Planejar arquiteturas para alguns cenários básicos. Definida a arquitetura dos cenários básicos. • • • Estimar o custo geral e o planejamento para a próxima fase (elaboração) e para o projeto todo. os desenvolvedores se previnem de. Quando os casos de uso críticos do sistema são atacados. Fazer um gerenciamento de riscos em potencial. nenhuma a mais para confundi-lo e nenhum a menos para deixá-lo na mão. identificar as origens de imprevistos. Preparar o ambiente de suporte para o projeto. 1 Construção de um código exemplo para verificar a viabilidade da implementação de alguma funcionalidade 2 versão de uma parte do software ou dele todo lançada publicamente . pois a equipe sabe exatamente o que tem fazer e para quando. Quando a equipe desenvolvedora atinge esses objetivos. e o planejamento do cronograma poderá ser cumprido. a construção de algumas funcionalidades comuns ou das mais prioritárias já pode ser agilizada.

devido ao pouco ou nenhum tempo investido na fase de iniciação. 2000). as medidas preventivas já estarão planejadas. podendo. E por fim. O ideal seria que ao final da fase de iniciação. Outro benefício notável de se realizar uma adequada fase de iniciação é a criação de perspectivas fundamentadas sobre outras fases do desenvolvimento. que é a essência da fase de iniciação. Isso acontece não só pelo fator financeiro. até estipular o custo financeiro do desenvolvimento.21 as possibilidades de fracasso no sistema ou de prejuízo serão muito reduzidas. a equipe poderá dar uma estimativa de quanto isso irá custar e já preparar o ambiente para o desenvolvimento desse software (POLLICE et. uma vez levantadas as informações sobre o cliente e sobre o que ele deseja. a equipe considerasse os estudos realizados e as características do projeto para tomar a decisão sobre continuar ou cancelar o projeto. pode-se compreender a importância da fase de iniciação para tornar as aplicações cada vez mais intuitivas. irão servir como parâmetro para determinação de custos e prazos das fases subseqüentes. uma vez que não foi feito um gerenciamento de riscos. pois dificilmente alguma grande surpresa ocorrerá. modernas e úteis aos clientes. Uma curiosa observação a ser feita é que quando uma equipe é contratada para desenvolver o software ela nunca cogita a possibilidade do seu cliente não necessitar do software. 2006) e do levantamento inicial de requisitos que. junto dos outros dois componentes. Disso. a equipe e a gerência do projeto ficam sem saber como resolver essas questões. e mesmo que ocorra. e pior. agregando valor ao negócio e deixando de ser simples mecanizações de antigas atividades manuais (KRUCHTEN et. muitos problemas surgem no decorrer do projeto. 2004). Infelizmente. uma correta definição de escopo e um adequado gerenciamento de requisitos. al. . al. do gerenciamento de riscos (GIBBS. através da definição de uma arquitetura candidata. em alguns casos. que mostraria a necessidade ou não do cliente em obter um software. mas pela falta de uma adequada análise de negócio.

Todo desenvolvimento de software visa um produto que tenha boa qualidade. A exemplo das outras disciplinas. Isso porque para uma eficiente elicitação de requisitos é necessário que se entenda em qual o contexto o software está sendo construído. porém as suas atividades são as primeiras a serem realizadas dentro de um projeto. ela está presente em todas as fases. 2002). o modelo de negócio gerado é um importante subsídio para a disciplina de Requisitos (EELES.3 – A disciplina de Modelagem de Negócios A Modelagem de Negócios é a disciplina de maior participação dentro da fase de iniciação do RUP. para que tenha um preço justo. é preciso que ele case o quesito utilidade com outros como por exemplo: confiabilidade e agilidade. 2002). preço justo e que seja útil para os usuários que o requisitaram. e para que o software tenha boa qualidade.22 2. Apesar da disciplina de “Requisitos” também possuir uma acentuada presença na primeira fase do ciclo de vida. 2002): . é necessário que seja feita uma estimava acertada dos custos do projeto. ou seja. pode-se concluir que a disciplina descrita neste tópico possui algumas metas claras. e quem vai te dizer o que fazer será a Modelagem de Negócios (NG. o que faz com que a Modelagem de Negócios tenha suas atividades realizadas antes das relacionadas ao levantamento de requisitos na ordem do desenvolvimento. as quais são descritos nesse framework. São elas (RUP. Começando do fim para o começo: para um software ser útil ele precisa dar suporte direto ao negócio para o qual ele foi construído. HOUSTON & KOZACZYNSKI. a sua expressividade se concentra no período compreendido no fim da primeira e no começo da segunda fase. Ciente da característica marcante do RUP de sugerir formas sistemáticas de se realizar as atividades.

• Com a identificação precisa dos problemas da Organização.. de todas as questões levantadas a respeito dos processos de negócio da Organização. senão o mais. i. pois todos eles saberão o porquê da implantação do sistema. Quando uma equipe de desenvolvimento consegue atingir essas metas. A definição de escopo é um dos. • Escopo e limites do sistema bem definidos. pois mostra a sua eficiência em realizar o que o cliente quer: resolver problema. 2002). Assegurar que os clientes.e. • Os clientes e desenvolvedores já estarão se comunicando melhor. correspondentes às metas descritas acima. usuários e desenvolvedores tenham um entendimento comum da Organização-alvo. Isso dá alta soluções credibilidade à equipe.23 • • • • Entender a estrutura e a dinâmica da Organização na qual um sistema deve ser implantado (a Organização-alvo1). Entender os problemas atuais da Organização-alvo e identificar as possibilidades de melhoria. como as listadas abaixo. o que ele deverá fazer e o que ele trará de benefício. satisfatórias podem ser encontradas. Isso facilitará muito a 1 Empresa ou Instituição cliente para qual o serviço está sendo prestado . o que está incluído e o que está excluído da área de atuação do sistema (NG. o ciclo de desenvolvimento será iniciado com algumas características positivas. componente que mais influencia na definição de prazos e custos de projeto. Derivar os requisitos de sistema necessários para sustentar a Organização-alvo. as chances do desenvolvimento se dar de forma harmoniosa são muito grandes. pois com as informações geradas como conseqüência das tarefas realizadas nessa busca.

2006). mas à qualidade da especificação. o que servirá como ponto de partida para a atividade de especificação de requisitos (GIBBS. produza abaixo de sua capacidade e esteja sujeita a riscos de difícil contensão. Além disso. Podem ser identificadas. é necessário que sejam definidos papéis e responsabilidades para cada um dos membros. mesmo que pequena – menos de 10 pessoas (POLLICE et. assim. na medida em que há uma possibilidade de que sejam identificados durante as atividades. o que atrasa muitos processos e causa enorme dependência dos funcionários daquele setor. 2002). nos quais algum membro tem que tomar a frente e dizer o que será feito. 2004) –.3. tarefas redundantes que causam baixa produtividade e problemas de consistência de informações. Isso já direcionará a primeira iteração do ciclo de vida. oportunidades de melhoria dos processos e relações de negócios atuais (NG. a Modelagem de Negócios pode agregar valor ao processo modelado. isso é realizado de forma mais saudável e natural. não só em relação a tempo de duração. Essa importância é visível principalmente nos momentos de indecisões da equipe. por exemplo. Com os papéis bem definidos. 2. pois os requisitos que devem ser prioritariamente atacados terão sido identificados cedo. fazendo. conseqüentemente. • Os requisitos chaves do sistema terão sido levantados. al. fazendo com que a Organização. mas principalmente para que haja na equipe responsabilidades definidas para cada atividade realizada. sem gerar .1 – Principais Papéis da Equipe Dentro de qualquer equipe. pode-se verificar a existência de um gargalo de trabalho e informações em um determinado setor da Organização. A importância da definição de papéis não é somente para melhorar divisão do trabalho. com que os membros tenham que cumprir direitinho as suas tarefas e que respondam por elas.24 atividade de levantamento de requisitos. e conseqüentemente ao software.

al. essa realidade mudou. Para melhor entendimento da importância dos papéis e suas definições. pois os indivíduos escolhidos para assumir os papéis e responsabilidades dessa disciplina irão ter contato direto com o cliente. independente do tamanho. tem grandes chances de ser a melhor (POLLICE et. 2004) a se tomar. natureza ou metodologia de desenvolvimento adotada. Inicialmente. Conseqüentemente. as delegava aos membros da equipe e ficava pressionando cada um para cumprir os prazos (GIBBS. mesmo que não seja a da maioria da equipe. pois o membro possui essa responsabilidade e se ele foi escolhido para aquele papel.3. O gerente de projeto é um indivíduo extremamente participativo: realiza parcerias com os membros da equipe. o gerente de projeto era o indivíduo que identificava as tarefas necessárias. inicialmente. 2.25 desconforto para ninguém. principalmente pelo fato dos participantes dessas atividades deverem possuir algumas habilidades a mais do que meramente técnicas. definirão o que o software deverá fazer e. então a sua decisão. A correta definição desses papéis influencia diretamente no custo do software. não é diferente.1. é porque ele possui o perfil necessário. Hoje. tanto no que diz respeito ao sucesso no desenvolvimento deste. até como se fazer.1 – Gerente de Projeto Talvez seja um dos únicos papéis que estarão presentes em todos os projetos e em todas as suas fases. como na satisfação do cliente com a qualidade do serviço oferecido. a definição de papéis é fundamental. estimula e . 2006). uma definição correta dos papéis dentro da equipe acarretará na valorização do software. Dentro da Modelagem de Negócios. a seguir serão apresentados os papéis chaves dentro da Modelagem de Negócios.

pois é ele quem realizará as atividades que são responsáveis por atingir os objetivos da Modelagem de Negócios. 2006).1. como o gerente deseja cumprir o acertado com o cliente para atingir o objetivo de agregar valor ao produto oferecido. . ele passará para a equipe esse objetivo. a saber: • • • • saber realizar apresentações e se comunicar bem. Segundo RUP (2002). o indivíduo deve possuir algumas habilidades imprescindíveis. Isso faz com que o cliente tenha satisfação em contratar o serviço oferecido e se sinta confortável ao negociar o preço e as condições do contrato. Além disso. pois ela está diretamente relacionada ao objetivo desse estudo. 2. esse é o papel mais importante. envolvendo todos os membros num processo organizado que tem como ideal promover a satisfação do cliente e agregar valor ao software. defende os interesses do time e realiza a comunicação com o cliente.3. exercer liderança e desenvolver o espírito de equipe possuir um bom relacionamento interpessoal e opinar sensatamente na seleção de pessoal “ter como objetivo agregar valor ao cliente na forma de software que atenda (ou ultrapasse) às expectativas do cliente” (RUP. esse entusiasmo. a última merece um destaque especial.26 valoriza as soluções encontradas e conduz o andamento do projeto (GIBBS. para desempenhar o papel Gerente de Projeto. protegendo a equipe de distrações e organizando cronogramas. Quando um gerente se preocupa em agregar valor ao cliente. deixa claro para ele qual a importância do software para a empresa. além de valorizar a participação do cliente no desenvolvimento.2 – Analista de Processos de Negócio Dentro da disciplina de Modelagem de Negócios. 2002) Dentre essas habilidades. ele se comunica bem com ele. surpreende-o positivamente.

e. É responsabilidade do analista de processos de negócio definir quais serão as fronteiras e o escopo da Modelagem de Negócios (RUP. . no qual é mostrado o fluxo de controle de uma atividade para outra. Mas. quais as partes da Organização-alvo. mostrando o valor do software para a Organização e a seriedade da equipe em honrar seus compromissos. Dessa análise. al. serão levadas em consideração e qual o tipo de esforço será realizado na Modelagem de Negócios. 1 “O Modelo de Casos de Uso de Negócios é um modelo das funções pretendidas do negócio. a tarefa de maior importância que o analista de processo de negócios realiza é a de identificar quais são as metas e objetivos da Organização-alvo. 2002) 2 Um diagrama de atividade é um gráfico de fluxo. definindo os atores. assim. Ou seja. ou seja. É usado como base para identificar papéis e produtos liberados na organização. sem contar a possibilidade de se identificar oportunidades que agregarão valor ao negócio do cliente. as quais irão direcionar o esforço da Modelagem de Negócios. o que se pretende com a implantação do sistema.. se envolverá ou não mudanças e inovações no negócio analisado. extraindo. o gerente de projeto – em nome da equipe – terá em mãos um guia para saber direcionar o esforço de desenvolvimento ao mesmo tempo em que terá uma lista de benefícios gerados pela implantação do sistema extraída do próprio cliente que servirão para justificar os custos financeiros e cronológicos.27 O analista de processos de negócio essencialmente coordena a criação de modelos de casos de uso de negócio1 (KRUCHTEN et. juntamente com seus indivíduos. A importância dessa tarefa reside no fato dela ditar aos desenvolvedores qual o objetivo do trabalho realizado e o que deixará o cliente satisfeito. 2002).” (RUP. setores envolvidos e como eles se relacionam. i. são produzidas documentações contendo as regras de negócio e alguns diagramas de atividades2 ilustrando os processos de negócios que ocorrem na Organização. dentro da óptica deste trabalho. 2000) e realiza a avaliação da Organização.

3.3 – Designer de Negócio O designer de negócio trabalha para gerar a maioria das informações que o analista de processos de negócio utiliza em suas atividades.e.. os trabalhadores e alguns casos e fluxos de negócios que envolvam esses trabalhadores (KRUCHTEN et. 2000). Preocupar-se com as necessidades dos usuários – que podem ser os próprios clientes ou clientes dos clientes. levando-se em consideração os problemas e as oportunidades existentes nos cenários avaliados. ordenados de acordo com suas respectivas prioridades. Dentre elas está a metodologia chamada EKD. i. Ele define as entidades presentes na Organização que participam das relações de negócio. al. apresentada no capítulo 3 – EKD. 2. pois o volume de informações gerado não será muito grande. para verificar a coerência do seu levantamento de informações com o da equipe de Requisitos Em projetos pequenos. portanto esse indivíduo terá tempo de levantar e de analisar as questões tranqüilamente. .1. o membro da equipe escolhido deve: • • • Preocupar-se com o que o cliente precisa e espera do sistema.28 Existem algumas metodologias que descrevem técnicas e boas práticas para obtenção dessas informações e outras complementares. Para desempenhar esse papel. assim como a quais regras e processos de negócio estes objetivos estão amarrados e quais indivíduos têm participação direta no alcance deles. esse papel pode ser atribuído a mesma pessoa que desempenha o papel de analista de processos de negócio. que é uma metodologia que tem como um de suas prioridades investigar de forma clara e direta quais os objetivos e metas da Organização. Participar do levantamento de requisitos final.

enxuta e eficaz possível. o gerente fará uma customização do RUP para a realidade daquele projeto (POLLICE et. Definidas as atividades a serem realizadas e seus respectivos prazos. Portanto. Planejamento de organização futuro..3. dizendo o que será feito.e. Conseguinte. destaca-se o documento de Visão de Negócio. al. iniciam-se as atividades definidas acima. após um primeiro briefing1 com o cliente. de preferência. organizando-as cronologicamente e prioritariamente de forma que somente as tarefas realmente necessárias para o projeto em questão sejam realizadas.29 2. uma vez que cada projeto possui uma característica. Ao final dessa estruturação do ambiente. e o Caso de Negócio.2 – Organização e Documentação das Atividades Durante o desenvolvimento da Modelagem de Negócios. 2004). o RUP possui uma série de atividades e artefatos disponíveis para que os desenvolvedores utilizem. documentado em um sistema gerenciador de projeto (GIBBS. sendo que essa escolha irá variar de acordo com o tipo e tamanho do projeto em questão. 2006). então. que fornece a justificativa para o projeto e estabelece suas restrições econômicas. sendo que o resultado dessas atividades será utilizado para que o 1 2 Conjunto de dados e informações. Dentre estes artefatos. que descreve qual a visão que a equipe tem da Organização-alvo e do produto a ser desenvolvido. um roadmap2 da realização da Modelagem de Negócios. o gerente de projeto da equipe deverá definir. podendo este ser. é fundamental definir quais as atividades dessa disciplina serão realizadas. quais as atividades serão realizadas. i. no qual todos membros da equipe terão acesso e poderão se planejar para realização das tarefas. Como foi explicado acima. . o gerente de projeto deve avaliar quais os artefatos deverão ser produzidos em cada atividade para que os membros responsáveis pela execução das tarefas relacionadas a essas atividades possam realizá-la da forma mais objetiva. como e quando. a equipe terá.

como por exemplo: cliente. juntamente com a equipe. entre outros. ou seja. Outro bom motivo para se ter as informações sobre os acontecimentos e experiências obtidos. 2003) no projeto. Em linhas gerais. Porém. alguns elementos sempre estarão presentes neles. e os dias de trabalho dos dois quase nunca coincidem. possa realizar a customização do RUP para a fase de elaboração. pois eles são apenas direcionamentos que devem compor a realização da Modelagem de Negócios. Assim. problemas existentes. pois como o RUP é baseado em iterações. é certo que o RUP possuirá as atividades e artefatos necessários para atender os diferentes estados que estes elementos possam se encontrar. Por exemplo: suponha um projeto em que o gerente de projeto reside em uma cidade e o analista de negócio em outra. eles quase não se encontram e. não se . uma vez que a grande maioria dos sistemas possui entidades e conceitos comuns que devem ser avaliados na fase inicial para que haja um entendimento comum entre todas as partes envolvidas (KROLL & KRUCHTEN. ao final de cada iteração é possível avaliar-se o desempenho da estratégia adotada para realização da Modelagem de Negócios. usuários do sistema. basta apenas que a situação de cada um seja bem entendida para que o uso do framework seja feito da maneira correta. é a possibilidade de melhoria desses processos. pois é ela que servirá como base para o planejamento da fase seguinte. Apesar dos roadmaps serem particulares a cada projeto.30 gerente de projeto. todo planejamento de desenvolvimento da disciplina de Modelagem de Negócios deve contemplar: • • • • Como será feita a comunicação com o cliente Quais informações sobre a Organização-alvo são importantes O que o sistema deverá fazer e quais regras que tangem essas funcionalidades Como será feita a comunicação entre os membros da equipe Os elementos acima não serão detalhados em relação às tarefas que devem ser realizadas ou os artefatos que devem ser produzidos. portanto. a documentação das atividades realizadas é muito importante.

no documento o gerente especificaria como o analista de negócio deveria documentar as análises feitas de modo que o gerente pudesse compreender. Para resolver esse problema. A abordagem feita nas seções que tratarão dessas duas etapas mostrará o quão útil são as atividades e os artefatos que o RUP oferece para os desenvolvedores de maneira geral. ele terá que seguir uma norma definida pelo gerente para que haja o entendimento entre eles. Por esse motivo. antes de qualquer coisa.3 – Etapa 1: Aprovação do Projeto Um projeto de desenvolvimento de software. o que faz com que eles não tenham termos e concepções iguais ou padronizadas em seus vocabulários e entendimentos. é uma relação comercial e como tal envolve recursos financeiros que muitas vezes são altíssimos. RUP (2002) apresenta um artefato chamado “Guia de Modelagem de Negócios”. que tem como finalidade descrever como você deve modelar casos de uso. Por outro lado.31 comunicam pessoalmente. os desenvolvedores também devem ter consciência da importância do seu trabalho e não desvalorizá-lo somente para não perder o cliente. Ou seja. Quando o analista de negócio for passar para o gerente de projeto alguns documentos gerados nas suas atividades dentro da Modelagem de Negócios. uma empresa não irá pagar pelo desenvolvimento de um projeto que não esteja bem fundamentado e que mostre adequadamente quais os retornos o sistema implantado irá trazer. sejam estes financeiros ou logísticos. ela será dividida em duas etapas: Aprovação do Projeto e Planejamento do Desenvolvimento. O elemento “Comunicação entre os membros da equipe” apresenta a característica da comunicação não pessoal e inconstante entre alguns membros. Portanto. é necessário que um padrão mais formal de comunicação seja estabelecido entre os membros da equipe que não se comunicam pessoalmente – em particular o analista de negócio e o gerente de projeto.3. entidades e trabalhadores de negócios. . 2. Para dar um caráter mais prático a esse estudo sobre as atividades e artefatos da Modelagem de Negócios.

pois ele entenderá exatamente os benefícios gerados por ele e as questões a serem analisadas durante a sua construção.1 – Aprovação Pela Equipe O início de um projeto se dá à partir do momento em que o cliente solicita uma proposta para um determinado serviço e os membros da equipe responsáveis por elaborar essa proposta iniciam os trabalhos. essas informações também são úteis para os desenvolvedores poderem estimar custos. Nesse aspecto. fazendo com que os desenvolvedores possam cobrar um preço justo sem receios e assumam o compromisso de entregar o sistema em um prazo coerente. é fundamental que esses indivíduos levem em consideração não só os interesses do . de modo que os membros da equipe possam concentrar seus esforços nessas atividades. uma vez que eles poderão ter uma idéia de quais tecnologias e metodologias deverão ser utilizadas durante o projeto. o cliente aceitará melhor o valor cobrado e o prazo de entrega do sistema. prazos e a viabilidade do projeto (RUP. quais são as pessoas envolvidas nos processos relacionados a estes. O motivo de se considerar essa aprovação como um marco é o de tornar as atividades dessa disciplina sistematizadas e direcionadas. Assim.3. 2. o que a empresa deseja que o sistema faça e quais as soluções e inovações que a equipe propõe para que os problemas sejam resolvidos. um marco é identificado dentro da disciplina de Modelagem de Negócios: Aprovação do Projeto. 2002). durante a fase de iniciação.32 Portanto. Mas a importância de se coletar essas informações não é apenas a de mostrar ao cliente todos esses benefícios. Dessa forma. pois se elas não forem bem executadas.3. é importantíssimo que seja elaborada para o cliente uma proposta de desenvolvimento mostrando a ele que a equipe compreende quais são os objetivos e problemas da empresa. os objetivos alcançados e oportunidades de agregar valor ao negócio aproveitadas. possivelmente o projeto não será aprovado e conseqüentemente qualquer esforço concentrado nas atividades que não as referentes à essa etapa terá sido em vão.

essa correta análise do negócio é um dos aspectos que mais tem influência na hora de se estimar os custos. para poderem saber exatamente o que ele deseja. do ponto de vista do negócio. mas de toda a equipe. é a atividade de revisão do projeto que irá “Determinar. Segundo Gibbs (2006). o que acarreta em . pois uma empresa pode oferecer um custo financeiro e cronológico menor que a de outra não por ser melhor executora dos projetos. De todos esses aspectos. executivos. o Caso de Negócio. Nessa reunião serão discutidos aspectos relacionados aos benefícios que o produto proporcionará ao cliente e à empresa – tanto à equipe implementadora quanto aos demais –.33 cliente. se vale ou não a pena investir neste projeto” (RUP. os riscos são avaliados e uma análise econômica.]A finalidade deste detalhamento do fluxo de trabalho é apresentar um projeto desde a origem de uma idéia até o ponto em que é possível tomar decisões fundamentadas para continuar ou abandonar o projeto. Por esse motivo que RUP (2002) trata de forma particular um fluxo de trabalho chamado “Conceber Novo Projeto”. (RUP. que irão levar em conta todas as informações sobre a viabilidade econômica e tecnológica do projeto. tanto em valores absolutos como em termos de retorno sobre investimento (ROI). à disponibilidade dos recursos necessários para o desenvolvimento do projeto e o qual será o custo desse projeto. aqueles que mais geram polêmica são o valor a ser cobrado pelo projeto e o tempo de duração deste. etc. 2002) Dentro desse fluxo de trabalho. analistas de negócio. o projeto será formalmente configurado. Se a Revisão da Aprovação do Projeto julgá-los satisfatórios. gerentes. a qual tem o seguinte objetivo de acordo com o autor: [. Com base na Visão inicial. Esta atividade consiste em uma ou mais reuniões com os responsáveis da equipe pela aprovação do projeto. ou seja.. os riscos levantados e a visão a respeito da Organização-alvo e suas expectativas em relação ao projeto. o gerente de projeto deve conhecer bem a equipe para saber das capacidades e limites dos membros e os analistas devem ter feito uma adequada modelagem do negócio do cliente.. 2002). mas por não ter entendido corretamente a dimensão e os objetivos do projeto. Para que uma boa estimativa possa ser feita. é produzida.

afinal. é envolver todos desenvolvedores que atuarão no projeto para poderem expressar suas opiniões e experiências.2 – Aprovação Pelo Cliente Assim que a empresa de software concluir a proposta.3. justificando que ela deveria saber quanto cobrar pelo seu serviço. A exemplo da aprovação do projeto feito pela equipe. juntamente com os analistas de negócio. os critérios que mais contam para o cliente são preço e tempo. Nas reuniões de apresentação e negociação da proposta. Isso pode gerar problemas inclusive de credibilidade. o conselho que Gibbs (2006) dá para que essas estimativas de tempo e preço sejam feitas da melhor forma possível. que é o que normalmente acontece. o gerente de projeto juntamente com os analistas devem . muitos clientes podem querer subestimar a “arte” de se produzir um software. eles estão na melhor posição para dizer se as estimativas de custo e tempo estão dentro do possível e serão os maiores afetados caso essas estimativas falhem. Com relação ao prazo. o gerente de projeto. existem muitas formas de se estimar os valores a serem cobrados em um projeto. por acharem que produzir um software resume-se em programação. exigindo prazos absurdos. Uma possível solução para esses problemas está na melhoria da comunicação entre a empresa de software e o cliente. porém poucas são as empresas de software que conseguem fazer uma estimativa exata.34 problema a toda a equipe que se verá pressionada para entregar o produto no prazo e ainda não receberá uma quantia justa por isso.3. ainda que adotando estes métodos. pois o cliente pode desconfiar da competência da empresa. Dessa forma. a apresentarão ao cliente que fechará o acordo ou negociará uma nova proposta. 2. Segundo Gibbs (2006).

demonstrando domínio do contexto em que este projeto se dará. coletadas. exemplos de projetos bem sucedidos e principalmente qual a expectativa da empresa em relação a esse projeto. Portanto.4 – Etapa 2: Planejamento do Desenvolvimento Seguindo a linha proposta neste estudo. . é importante também que seja aberta uma sessão de perguntas (GIBBS. 2006) para que o cliente possa tirar todas as suas dúvidas e como essas perguntas serão principalmente sobre o projeto e sua relação ao negócio do cliente – retorno sobre investimento (ROI) –. depois de produzido um bom documento. 2004) e demonstrado o valor da equipe desenvolvedora. organizadas e apresentadas várias informações. tais como as capacidades da equipe desenvolvedora (GIBBS.35 passar informações adicionais às contidas na proposta. com várias informações úteis para o cliente poder tomar sua decisão. pois elas estarão presentes tanto na proposta como no contato direto entre o cliente e os gerentes e analistas do projeto. esclarecidas todas essas dúvidas principalmente com relação ao retorno sobre investimento (POLLICE et. Assim. chega-se ao marco final da Modelagem de Negócios: Planejamento do Desenvolvimento. 2.3. al. Nessa reunião. é chegada a hora de se iniciar o desenvolvimento propriamente dito. Depois de realizadas todas as atividades. é fundamental que o gerente e os analistas tenham domínio do assunto e saibam exatamente como o sistema agregará valor ao negócio da Organização-alvo. da complexidade e dos benefícios do projeto que ele solicitou. compreendendo e aceitando os custos de tempo e dinheiro apresentados. o cliente terá uma melhor compreensão dos custos de um projeto de software. pois dessa forma o cliente terá uma noção melhor do tamanho. é de fundamental importância as informações coletadas na Modelagem de Negócios. elaborada e aprovada a proposta de desenvolvimento. 2006).

2006). A definição de estratégias para realização das tarefas envolvidas na construção do sistema é a atividade mais dinâmica desse planejamento. instituindo-se um processo (KROLL & KRUCHTEN. sejam feitas antes. onde quer chegar e quanto está disposto a gastar com isso. para poder classificá-los de modo que nenhuma funcionalidade que precisa de outra seja implementada antes da primeira. diminuindo assim o valor percebido do serviço. Pollice et. e configuração do ambiente de trabalho. de modo que as tarefas sejam organizadas de acordo com as suas precedências e importâncias relativas ao valor percebido1 que é uma informação que só pode ser obtida por meio de uma adequada modelagem. Para iniciar o planejamento. sem sofrer grandes alterações. isso implica em satisfação do cliente (BELTRÃO. . pois ela será realizada por inteiro a cada iteração – chamada de plano de iteração –. no ponto de vista do cliente. o primeiro passo a ser dado é planejar esse trabalho. levantamento de riscos. definição de estratégias para realização dos trabalhos propostos.36 Para isso. al (2004) sugere que sejam realizadas as seguintes atividades: • • • • priorização dos requisitos de alto nível já levantados. A priorização dos requisitos consiste em analisar as dependências entre os requisitos. pois é ela que dirá o que o cliente quer. essa atividade na fase de iniciação irá ter como produto final um plano de estratégias trabalho para as atividades do projeto de um 1 É quanto o cliente está disposto a pagar por um produto antes de saber o preço real. Portanto. enquanto as outras são realizadas nesse início de projeto e depois serão somente refinadas. ou que as funcionalidades menos importantes. 2002). Se a quantia que ele está disposto a pagar é superior ao valor real do produto.

Além disso. tais como: • • Não se deve utilizar ferramentas que sejam ricas em processos que sejam pobres. salas. pois muitos projetos não são concluídos com sucesso pela falta de identificação e definição de medida de contingência para cada um dos riscos. a ferramenta informatizará o sistema que continuará sendo pobre. medidas de contingência para poder saber o que fazer caso o risco se concretize. Segundo Gibbs (2006). ou seja. uma vez que essa iteração está próxima da atual (iniciação). entre outros recursos. É importante distinguir ferramenta de automação de processo do processo em si. é preciso tomar cuidado com os aspectos relacionados a esses processos quando se for escolher as ferramentas. sem muitos detalhamentos. ou seja. contendo informações adicionais como descrição do risco. Neste plano. em sua distribuição normal. será feita uma verificação de quais equipamentos. Segundo Gibbs (2006). inicia-se a construção de uma lista de riscos que. pode ter um valor que comprometa ou elimine o sucesso de um projeto”.uma variável que. Esta lista é um artefato do RUP que contém os riscos ordenados do mais “importante” para o menos. depois de levantados os riscos. nessa atividade são escolhidas todas as ferramentas que serão utilizadas durante o desenvolvimento.37 modo mais amplo e estimativo. Finalmente. . sejam estas para a parte de programação como para automatização dos processos adotados.. Realizadas essas duas atividades. pois o problema está no processo e não na ferramenta. tudo que possa fazer o projeto dar errado. impacto que ele pode causar.. segundo RUP (2002) é “. pois se o processo for pobre (ineficiente). um indicador de que ele pode acontecer. o ambiente de trabalho será configurado. mesas. as tarefas relativas à primeira iteração da fase de elaboração terão as estimativas e definições mais precisas. serão utilizados durante o desenvolvimento. essa atenção especial aos riscos é de suma importância.

A definição que RUP (2002) dá para esse Plano de Desenvolvimento é a de ser um documento que define o processo que será seguido no projeto. ele estabelecerá um conjunto de passos e diretrizes que terá o objetivo de “organizar as atividades”. . de uma maneira que já atenda a necessidade de se organizar as atividades envolvidas no ciclo de vida do desenvolvimento do software. como citado acima. já que esse plano é um artefato composto basicamente pelas informações citadas acima. ou seja.38 Uma vez reunidas todas essas informações. que é um artefato dentro do RUP. já é possível construir-se um Plano de Desenvolvimento de Software.

.39 3 – EKD O Enterprise Knowledge Development (EKD) é uma metodologia que sugere uma forma sistemática de se analisar. Sendo resultado desse processo. quais seus requisitos. 2004). um esclarecimento e descrição de como funciona o negócio. mas as informações por ele obtidas são de grande valia para o ciclo de desenvolvimento do software. Uma característica interessante do EKD em relação a outras metodologias é o fato dele possuir uma ligação estreita com o desenvolvimento de sistemas de informação. entender e documentar os processos dentro de uma Organização e seus componentes (PÁDUA. note que ele possui a característica de poder ser utilizado para especificação de requisitos. A tabela abaixo ilustra as características dele e de outras características. Dessa forma. quais as necessidades de mudanças e como fazê-las. o EKD não está ligado diretamente ao desenvolvimento de um sistema de informação (SI).

40 Figura 2 – Tabela comparativa entre algumas técnicas de modelagem organizacional Como essa técnica possui um número maior de características ligadas ao desenvolvimento de software. ela foi escolhida para a construção da metodologia sugerida nesse trabalho. . na qual o EKD será utilizado como uma das ferramentas na Modelagem de Negócios.

identificando qual será o seu papel e o seu valor dentro da Organização que o está adquirindo (RUP. na qual a ordem era: “automatizar os processos” (PÁDUA. trazendo como únicas vantagens a agilidade e a organização das informações. Porém. É preciso fazer com que o software seja mais que isso. a imparcialidade sócio-cultural. nessa ânsia de se criar sistemas de informação que colocassem as empresas dentro da nova realidade. além de facilitar a obtenção dos requisitos . iniciou-se no país uma corrida tecnológica. a relação humana.41 3. extraindo. essa tarefa de extração e análise do conhecimento dentro das organizações não é uma tarefa fácil. planejamento. principalmente por parte dos analistas. visando vantagem competitiva. 2006). 2002). 2005). Assim. e a diversidade dos tipos de negócios existentes. mas que irão melhorar a qualidade dos processos e aumentarão a produtividade. pois ela envolve. É aí que entra a metodologia EKD. precisa-se de uma metodologia que guie os passos na obtenção desse conhecimento. o máximo de informações que serão úteis para que a equipe desenvolvedora proponha idéias inovadoras e soluções que não somente automatizarão os processos. Com a necessidade de se acompanhar as novas tendências mundiais. entre diversos fatores.1 – Visão geral A partir da década de 90 as empresas brasileiras começaram a sentir os efeitos do mundo globalizado (CASTRO. os desenvolvedores precisam estudar e entender a realidade do negócio para o qual seu produto está sendo feito. raciocínio e aprendizado dos negócios dentro da Organização (STIRNA. tornando-o simplesmente um substituto do “papel e da caneta”. para atingir esses objetivos. modelagem e mudança dos negócios através de técnicas e métodos que dão suporte ao pensamento. é necessário que se entenda o contexto em que o software está inserido. Como se sabe. Sua função é auxiliar na análise. muitos empresários e desenvolvedores de software não se preocuparam em utilizar o software como agente de mudança nos processos de negócio. 2004). assim. Mas para tanto. Para isso.

2 – A metodologia EKD O EKD. quais seus objetivos. principalmente no que se refere a colaboração dos usuários (PÁDUA. possui uma descrição formal de técnicas e métodos a serem utilizados e qual a ordem dessas atividades na pesquisa da Organização a fim de se obter algumas conclusões. Nesta seção. o que este sistema irá fazer e quais os critérios serão utilizados para avaliar quanto valor o sistema agregará aos processos atuais (CASTRO. para então se estudar qual a relação e utilidade desse método dentro da Modelagem de Negócios.42 organizacionais. será mostrado o que é este método EKD. será possível. Diante disso. quais as possibilidades que ele traz e como ele afeta a Modelagem de Negócios e as fases iniciais do desenvolvimento do software. 2004). o EKD não é uma abordagem diretamente ligada ao desenvolvimento de um sistema de informação. avaliando em quais situações é interessante utilizá-lo ou não. No contexto da Modelagem de Negócios. então. ela produz mais idéias inovadoras tanto no que se refere ao software como a processos de negócio. É importante lembrar que o quando a equipe desenvolvedora entende bem como a Organização funciona e quais as suas necessidades. mas ligada à análise de negócio. suas técnicas e diretrizes. como toda metodologia. Serão apresentados nessa seção os . o EKD será o responsável por preencher o vazio existente entre a parte relacionada a negócios e a relacionada a tecnologia. qual área de atuação do sistema de informação sendo desenvolvido. afinal. melhorando a qualidade do produto final – software – e do processo de desenvolvimento. 3. o EKD será útil para identificar como a Organização funciona atualmente. 2005). Com base nessas informações. chegar a uma conclusão de qual é a contribuição do método EKD no alcance do objetivo final que é agregar valor ao software.

como estão relacionados esses Organização. al. • Modelo de Requisitos e Componentes Técnicos: Este modelo é útil quando o objetivo do EKD é levantar requisitos para a construção de . bem como seus conceitos • relacionamentos. delimitando os caminhos que poderão ser trilhados para se alcançar os objetivos. Modelo de Processos de Negócio: Descreve as atividades presentes no negócio que são necessárias para que os objetivos sejam alcançados (BARBALHO. processos. atividades e responsabilidades dentro dessa. O EKD é resultado de pesquisas iniciadas em 1980 com o projeto Plantada.. é muito mais do que isso. 2002). • Modelo de Conceitos: Neste modelo estão descritos alguns utilizados nos outros modelos. propostos pelo EKD. que apesar de ter origens na engenharia de requisitos (BARBALHO et. 2004). quais caminhos seguir para alcançar os objetivos propostos. no final daquela década (PÁDUA. quais seus papéis. pois o EKD se baseia não somente no modelo de engenharia de requisitos.. mas nos seguintes modelos: • Modelo de Objetivos: Representa os objetivos da Organização. ainda passou pelo refinamento de outros projetos até se tornar então o EKD.43 métodos. 2006). i. fazendo com que questões como quais são os objetivos e suas respectivas prioridades sejam respondidas (STIRNA. • Modelo de Regras de Negócio: Representa quais as regras regem os negócios da empresa. 2006). concentrando-se na descrição das idéias que irão traduzir suas intenções. ROZENFELD & AMARAL..e. como percorrer esse caminho da forma adequada (TEIXEIRA. 2002) respeitando-se as regras do negócios.e. e as técnicas. Depois disso. • Modelo de Atores e Recursos: Relaciona os atores presentes na mostrando também. o qual foi refinado pelo SISU (Swedish Institute for Systems Development – Instituto Sueco para o Desenvolvimento de Software). i.

já que a prioridade estabelece uma relação de ordem de ação para se atingir os objetivos. Para isso. causa. problemas enfrentados. pontos fracos e possíveis alternativas que eles tenham em mente para se alcançar esse objetivos (BUBENKO. De uma maneira prática e clara.44 um sistema de informação (BUBENKO. o que dá uma melhor organização para a equipe que está realizando a modelagem. pontos fortes. O objetivo deste modelo é fazer com que os requisitos levantados para a construção do sistema sejam coerentes com os objetivos. ele deve traduzir qual o sentimento dos dirigentes e funcionários com relação a perspectivas futuras em relação ao negócio. ela não será apresentada. portanto o registro dos resultados dessa atividade não necessariamente deverão seguir o padrão adotado pelo método EKD. atores e conceitos presentes na Organização. Os objetivos de uma Organização podem ser classificados quanto a suas prioridades (STIRNA. PERSSON & STIRNA 2001). Cada um desses modelos é dividido em componentes e possui uma notação para representá-los. um objetivo é algo que um membro da Organização. Nas sub-seções seguintes serão apresentados esses modelos sobre a visão da Modelagem de Negócios. . 2006).1 – Modelo de Objetivos O Modelo de Objetivos descreve o que a Organização quer em relação ao seu negócio. desejam alcançar no futuro (BUBENKO. apresentando os componentes e suas características que se enquadram na Modelagem de Negócios. regras. PERSSON & STIRNA 2001). limitação e oportunidade. 3. problema. pois o objetivo desse estudo é extrair do EKD as práticas e idéias que serão úteis na Modelagem de Negócios. Os componentes desse modelo são: objetivos. PERSSON & STIRNA 2001) em alguma das suas áreas ou como um todo. respeitando suas limitações que podem ser impostas por políticas internas ou externas. ou vários. Apesar do EKD possuir uma notação oficial.2.

45 Alguns objetivos estão sujeitos a problemas. Por outro lado os objetivos podem também ser facilmente alcançados através das oportunidades. ou seja. que podem impedir a Organização de atingir estes objetivos. devem ter suas causas documentadas para que a equipe possa buscar soluções ou preparar planos de contingência. uma regra não deve relacionar um objetivo ou situação que não esteja presente ou subentendido no Modelo de Objetivos. O Modelo de Regras de Negócio também será extremamente útil para a fase de especificação de requisitos.2. pois esses requisitos deverão seguir e respeitar essas regras para que o software desenvolvido esteja em acordo com as relações de negócio da Organização. as quais devem ser anotadas pela equipe para que possam ser exploradas e. e.2 – Modelo de Regras de Negócio O Modelo de Regras de Negócio possui algumas operações comuns realizadas dentro da Organização bem como os limites que rodeiam essas operações. . 2006). assim. Para guiar esta atividade de modelagem de objetivos. algumas perguntas são propostas: • • • • • Quais os atuais planos e objetivos da Organização? Quais as prioridades desses objetivos? Existem problemas que possam afetar os objetivos? Existem oportunidades para melhor alcançar os objetivos? Qual a importância do sistema no alcance dos objetivos? 3. gerar novas alternativas para viabilização do alcance dos objetivos. portanto. Essas regras de negócio devem ser modeladas em conformidade com o Modelo de Objetivos para que elas estejam consistentes com o modelo organizacional (STIRNA.

explicaria o que é uma operação de crédito.2. pois é nele que serão explicados esses conceitos. o objetivo está declarado. é necessário que os conceitos citados sejam esclarecidos.e. i. este modelo funciona como uma espécie de “dicionário” para os outros modelos. É aí que entra o modelo estudado nesse tópico. Nessa situação.3 – Modelo de Conceitos O Modelo de Conceitos reúne todas as entidades e relacionamentos presentes nos outros modelos que precisam ser descritas para que se tenha um melhor entendimento do que está sendo declarado nos modelos. suponha que no Modelo de Objetivos você tenha o seguinte objetivo: “Automatizar operações de crédito”. o requisito “entrega de monografia” deverá ser implementado de uma maneira que ele cumpra a regra que proíbe a entrega de monografia de alunos que tenham mais de 3 mensalidades atrasadas. os alunos entrarão no sistema e carregarão nele o arquivo com sua monografia. ou seja. as regras de negócio devem ser devidamente especificadas para que as eventuais mudanças realizadas na Organização. mas o que seria uma “operação de crédito”? Seria empréstimo? Financiamento? Para que o objetivo seja corretamente compreendido. Durante a especificação de requisitos é especificado que o sistema deve possuir uma funcionalidade de entrega on-line de monografia. incluindo a implantação de um SI. como Pádua (2004) diz. tragam realmente melhorias e não problemas ao negócio. . 3. que no caso do exemplo.. Para exemplificar essa característica.46 Para melhor entender essa situação. analise o seguinte exemplo exemplo: Imagine que no Modelo de Regras de Negócio você possua a seguinte regra: “Um aluno que tenha atrasado mais de 3 mensalidades não pode entregar sua monografia”. Como se pode ver.

obtendo um modelo que procure se aproximar o máximo possível do mundo real. o responsável por essa modelagem deve seguir algumas diretrizes: • • • • Fechar o escopo estabelecendo um cenário do que será modelado.47 Portanto. . PERSSON & STIRNA 2001) para saber se ele é realmente necessário e • ele. que é composto por todos os modelos. verificar a importância dele na aplicação (BUBENKO. 2004).4 – Modelo de Processos de Negócio O Modelo de Processos de Negócio procura definir os processos e atividades que compõe o cerne da Organização e geram valor para ela.2. pode-se dizer que esse modelo é muito parecido com os tão conhecidos modelos de fluxos de dados (PÁDUA. Incluir no modelo somente os relacionamentos que sejam significativos para o cenário em questão. possa ser completo e consistente. bem como seus atributos e relacionamentos. Fazer um levantamento inicial dos conceitos envolvidos na aplicação. Antes de incluir um conceito. A título de comparação. fazendo com que o modelo global. é importante que essas diretrizes sejam seguidas para que o responsável pela modelagem de conceitos possa produzir um modelo que seja útil e complementar para todos os outros modelos presentes. deve-se fazer um levantamento das entidades presentes no domínio. Para isso. bem como o fluxo de informações que circula nessas atividades e processos. 3. para se realizar a modelagem conceitual. Analisar a participação e quantidade de relacionamentos do conceito para decidir qual nível de detalhamento é necessário dar a Dessa forma.

Um exemplo dessa situação é dado por Bubenko. pois esse modelo é relativamente simples em sua ilustração. um documento. a saber: • Processo: Conjunto de atividades que consome uma entrada e produz uma saída. podendo essa entrada e essa saída ser uma informação ou um material1. na saída do processo . na alimentação do processo No fim. aumentando a profundidade da descrição conforme mais informações a respeito do que se está modelando são obtidas. porém conseguir fazer uma representação adequada dos processos e atividades que ocorrem no mundo real. já se tem condições de construir. mesmo que de alto nível. Persson & Stirna (2001). Isto é. os processos externos geralmente se encontram na fonte2 ou no sorvedouro3 de um processo interno.48 Para construção desse modelo. um esboço do modelo. mas que possuem participação direta em alguma atividade do domínio desta. Uma forma interessante de se partir do esboço e chegar ao modelo final é trabalhar com a decomposição de processos. A verdade é que tanto para o esboço como para a versão final os componentes são os mesmos. mas de certo modo complexo em sua definição. Ex. são definidos alguns componentes básicos. • Processo externo: Conjunto de atividades que estão fora do escopo da Organização. é uma atividade não tão trivial. Ela consiste no detalhamento iterativo de um processo inicialmente esboçado. pelo menos. Segundo Bubenko. a quantidade de componentes usados para representação do modelo é pequena. Persson & Stirna (2001) em uma situação de verificação de endereço de cliente: 1 2 3 Um artefato. sem tirar e nem por. Definidos esses componentes básicos.: um boleto bancário No início.

Info 3 Endereço inválido Figura 4: O processo da verificação de endereço de cliente detalhado. PERSSON & STIRNA 2001) .1 Verificação de Rua Processo 32. Info 3 Endereço inválido Figura 3: O processo da verificação de endereço de cliente em alto nível.49 Conj.3 Endereço Conj. Info 2 Processo 32 Conj. Info 1 Endereço Endereço válido Verificação de endereço do cliente Conj. Considerado para esboço (BUBENKO. Info Cidade Verificação de Cidade Processo 32. Info CEP Verificação de CEP Processo 32.4 Conj. Info País Verificação de País Conj. Info 1 Conj.2 Conj. Pode ser considerado bom para versão final (BUBENKO. Info Rua Processo 32. Info 2 Processo 32 Endereço válido Verificação de endereço do cliente Conj. PERSSON & STIRNA 2001) Conj.

i. Dessa forma.. um ator poder ser responsável por uma determinada atividade ou pode buscar um particular objetivo (PÁDUA. 3.e. sendo sempre verificados a presença dos conceitos e atores envolvidos nos seus respectivos modelos. Dentro da Organização. 2004). quais processos necessitam ser detalhados ou não. para que os responsáveis pela realização dessa tarefa já possam ter uma orientação do que considerar no momento . os processos modelados certamente estarão fazendo uso de informações descritas por componentes do Modelo de Conceitos (terceiro modelo).5 – Modelo de Atores e Recursos O Modelo de Atores e Recursos serve para descrever como esses atores interagem no sistema sob o ponto de vista de suas interdependências e participações nos objetivos e processos de negócio.50 Essa ilustração mostra uma concepção inicial do processo e em seguida um detalhamento que já dá mais informações a respeito do processo sendo modelado. Lembrando que o indivíduo que estiver realizando a modelagem deve julgar. os processos e atividades a serem modelados deverão ser escolhidos de acordo com sua relação aos objetivos e regras do negócio. e que conseqüentemente geraram os conceitos definidos no terceiro modelo.2. Para que seja mantida a consistência com os outros modelos é importante que sejam escolhidos os processos e atividades que estejam relacionados aos objetivos identificados no primeiro modelo. é interessante se estabelecer uma classificação dos tipos de atores e recursos possíveis. sempre observando a dinâmica da Organização. pois assim.

Por exemplo. além da relação entre os próprios atores. Dessa forma. tal como um departamento. Dentro do modelo existem relações entre os indivíduos que caracterizam a dinâmica dos envolvidos no negócio sendo modelado. isto é. Persson & Stirna (2001): • Responsabilidade: É. Essa responsabilidade pode ser tanto no sentido do ator fazer parte da definição mais ampla desses modelos. uma relação entre os atores e os processos de negócios. além de definir os recursos humanos1 e não-humanos. • Dependência: Relação entre dois atores. Porém. as regras de negócio e os objetivos. etc. Os indivíduos presentes neste modelo geralmente possuem relação com alguma dessas unidades organizacionais. pessoas . essencialmente. esses relacionamentos puramente internos não acrescentariam nada ao modelo de negócio geral da Organização. Dessa forma. Essa dependência está 1 Indivíduos. • Papéis: Definem um perfil de uma entidade. uma divisão. definir alguns de seus componentes ou executar tarefas relacionadas a eles. um setor. um indivíduo pode ter o papel de Gerente de Projeto e o departamento de finanças pode ter o papel de Administrador. Podem ser delegados tanto a indivíduos como a unidades organizacionais. no qual um precisa do outro para obtenção de algo como um recurso ou continuidade de realização de um processo de negócio.51 da modelagem. é fundamental que os atores e recursos identificados neste modelo sejam relacionados aos componentes dos outros modelos para que sejam estabelecidas as relações de responsabilidade e dependência entre eles. o modelo também define outros dois tipos de recursos: • Unidade Organizacional: Representa uma estrutura organizacional. o conjunto de todos os modelos. De acordo com a definição de Bubenko. principalmente o de objetivos e o de processos de negócio.

6 – Modelo de Requisitos e Componentes Técnicos Como citado no início desse capítulo 3. Compreendido os componentes do modelo. i.. i.52 intimamente ligada aos processos de negócios no que se refere à dependência causada por uma operação dentro de um processo. gerar informações que sejam úteis ao desenvolvimento de um sistema desse. é aquele que está diretamente relacionado à construção de um sistema de informação (PÁDUA. um ator só terá participação efetiva no fluxo de uma determinada atividade depois da participação de um outro. pois ele define quais são as pessoas. o qual não é utilizado em situações nas quais não há o desenvolvimento de um software. fazendo com que os esforços sejam despendidos somente pelas pessoas que realmente estão envolvidas nas questões levantadas. e está diretamente ligada às regras de negócio no que diz respeito à dependência causada pela necessidade de autorização. Porém.. . ele é uma metodologia que têm sim como um dos seus objetivos. o último de seus modelos. pode-se notar a sua importância para a análise de negócio na medida em que ele complementa o sentido dos outros modelos. unidades organizacionais e recursos dentro da Organização que estão ligadas a todos processos. 3. um ator só poderá realizar uma operação ou ter participação efetiva em um processo ou cenário depois de passar pela autorização de um outro ator. Assim.2. o método EKD não está necessariamente envolvido ao desenvolvimento de um sistema de informação. 2004): o Modelo de Requisitos e Componentes Técnicos. regras e objetivos descritos nos outros modelos. as soluções encontradas para os problemas identificados poderão ter um melhor direcionamento para os responsáveis. a partir daqui. Assim.e. pois ele é um método de modelagem organizacional e não de levantamento de requisitos ou quaisquer outras atividades relacionadas ao ciclo de vida do desenvolvimento de um software.e.

• • Problemas do Sistema de Informação: São riscos que podem se tornar empecilhos ao alcance dos objetivos do SI. expressam o comportamento 1 Um risco é tudo que possa impedir o sucesso do projeto e que atualmente é desconhecido ou incerto (RUP. pois ele é dividido nas seguintes três partes: • Objetivos do Sistema de Informação: Motivado principalmente pelos objetivos descritos no Modelo de Objetivos e pelas atividades descritas no Modelo de Processos de Negócio (BUBENKO.53 De acordo com Pádua (2004). o objetivo desse modelo é direcionar a parte técnica do desenvolvimento para os objetivos. levando-se em consideração todos os componentes do sistema. ou seja. processos. Os requisitos sempre referenciam componentes do Modelo de Processos de Negócio. 2002). PERSSON & STIRNA 2001). . Os requisitos são divididos em dois tipos: Requisitos Funcionais: São funcionalidades especificadas para a execução de ações completas pelo sistema. Um fato que direciona melhor esse trabalho de organizar as informações é o modo como o modelo é composto. podem fazer referencia a componentes do Modelo de Atores e Recursos e do Modelo de conceitos. Requisitos do Sistema de Informação: são condições ou estados expressados pelas propriedades do sistema que devem ser modeladas. Em síntese. de forma que o sistema a ser desenvolvido esteja coerente com as informações levantadas nesses outros modelos. regras e atores da Organização. o modelo deve organizar as informações obtidas de forma que elas sejam úteis e precisas ao levantamento de requisitos e ao gerenciamento de riscos1 bem como a relação destes com os componentes técnicos que irão compor o produto final do desenvolvimento. esse componente expressa uma série de objetivos de alto nível do sistema de informação.

Requisitos não-funcionais: Descrevem. ao final de todas essas atividades. Portanto. uma vez que ele trata de aspectos externos ao sistema que possuem influência direta e expressiva no projeto. já que as ações do mundo real que serão realizadas pelo sistema estão descritas aí. devem estar relacionados a algum dos processos descritos no respectivo modelo. o . muitas vezes. atributos do sistema ou de seu ambiente que não subentendem funcionalidades propriamente ditas. tais como: segurança. desempenho e usabilidade. avaliando-se os padrões e restrições existentes nestes componentes técnicos que deverão ser respeitados. é feito um levantamento do atual potencial tecnológico da Organização que darão suporte ao sistema em desenvolvimento bem como quais mudanças serão sugeridas. 3. de auxiliar a Modelagem de Negócios na definição dos componentes da Organização para a qual o software será desenvolvido. fornecendo à equipe uma perspectiva geral do que o sistema deverá fazer e quais as condições técnicas para isso. 2002). como restrições políticas e econômicas.54 de entrada e saída do sistema (RUP. além de possuir clara referência ao Modelo de Conceitos. dentro do escopo do estudo proposto. Estes requisitos. Depois de levantadas todas essas informações. pois é nele que são esclarecidos os todos conceitos envolvidos na modelagem e isto inclui os utilizados no presente modelo. portanto. Estes requisitos possuem interferência direta nos objetivos. requisitos e riscos do sistema.3 – O EKD e a Modelagem de Negócios Todo o processo descrito acima tem o claro objetivo. Dessa forma. será formalizado um modelo que dará uma visão inicial dos requisitos e do cenário no qual esses requisitos deverão ser atendidos.

na qual serão expostos os principais elementos do EKD escolhidos para serem utilizados na Modelagem de Negócios. que pode ser no formato de um seminário. A fase inicial do EKD tem como primeiro e mais importante marco a primeira reunião de modelagem. Portanto. Durante estas entrevistas devem ser construídos alguns esboços do Modelo de Objetivos. já que nessa reunião: • • • • serão estabelecidas as relações de empatia entre os membros da equipe e os da Organização. é de fundamental importância que a Organização-alvo e a equipe de modelagem iniciem o processo em . as quais são os bens mais importantes para essa disciplina. Assim. serão abordados alguns dos atuais problemas da Organização. para que se possa conduzir essa reunião da forma mais coerente e produtiva possível.55 presente trabalho propõe que o EKD seja utilizado na Modelagem de Negócios como a metodologia de extração e gerenciamento de conhecimento sobre a Organização-alvo. e será passado para os membros da Organização qual será o papel e a participação deles durante essa fase de modelagem organizacional. Persson & Stirna (2001). pois dificilmente haverá uma segunda chance. do Modelo de Conceitos e do Modelo de Atores e Recursos que servirão para o planejamento e realização dessa primeira reunião que terá como foco a modelagem das regras e processos de negócios. é fundamental que sejam escolhidos as pessoas certas para essa reunião. será passado para a equipe de modelagem uma visão geral sobre a Organização. a qual não pode falhar. fazendo uma junção dessas informações com as obtidas nas entrevistas e refinadas nessa reunião. na preparação dessa reunião. Segundo Bubenko. é importante que sejam levantadas algumas das questões acima com cada um dos participantes. gerando informações objetivas e bem delimitadas. A proposta sugerida nesse trabalho será melhor explicada abaixo.

a equipe. apenas uma segunda reunião não seja suficiente para se estabelecer todos os modelos (BUBENKO. será avaliado se os refinamentos dos modelos já . nota-se que essa fase inicial do EKD está diretamente ligada a 2 dos 4 objetivos da modelagem de negócios.56 plena sintonia para que as próximas reuniões e atividades realizadas pela equipe de modelagem possam ser devidamente planejadas e executadas. atingir todos os objetivos da Modelagem de Negócios. partirá para a segunda na qual serão realizadas as seguintes tarefas: • revisar os trabalhos realizados na primeira reunião para dar continuidade ao desenvolvimento das atividades a partir de onde elas foram interrompidas. usuários e desenvolvedores tenham um entendimento comum da Organização-alvo. Possivelmente. assim. dando já um direcionamento com relação ao futuro da Organização designar tarefas a membros da Organização que estejam participando do trabalho para que ele possa contribuir da melhor maneira possível e ser útil para a equipe. após realização da primeira reunião. Continuando esse processo de aplicação do EKD. Claramente. Entender a estrutura e a dinâmica da Organização na qual um sistema deve ser implantado (a Organização-alvo). PERSSON & STIRNA 2001) e. Ao final dessas reuniões. a saber: • • Assegurar que os clientes. Portanto. é bem provável que mais uma ou duas reuniões sejam úteis para que os modelos todos estejam bem definidos e coerentes. • • • • expandir e/ou corrigir os modelos já existentes utilizando as novas informações obtidas criar novos modelos na medida do necessário planejar e sugerir trabalhos futuros.

quando essas reuniões não forem mais necessárias.57 alcançaram seus estágios finais ou se necessitaram de mais ajustes. . Derivar os requisitos de sistema necessários para sustentar a Organização-alvo. Assim. fornecendo informações necessárias aos profissionais que irão trabalhar nas outras fases do desenvolvimento. pode-se evidenciar de forma bem direta a relação entre os objetivos descritos para a Modelagem de Negócios e os alcançados pelo EKD. essa etapa final do EKD só terminará quando todos os modelos estiverem satisfatoriamente completados. estão os especificados pelo RUP (2002) dentro da disciplina de Modelagem de Negócios: • • Entender os problemas atuais da Organização-alvo e identificar as possibilidades de melhoria. significará que os objetivos dessas atividades foram alcançados. sendo que dentre eles. mostrando como essa metodologia atende e inclusive supera os objetivos propostos. o que levaria ao agendamento de outras reuniões. inclusive o Modelo de Requisitos e Componentes Técnicos. Dessa forma. Portanto.

esta seção trata da parte relacionada à documentação do software que é necessária durante a fase de iniciação. pois os clientes não compreendem muitas vezes (ou não querem compreender) os documentos que contém as análises e modelagens realizadas (GIBBS. até porque muitos deles nem participarão de todas elas. querem utilizar o sistema que está sendo desenvolvido para poderem se certificar de que o projeto está correndo como previsto. é fundamental que o projeto tenha uma boa documentação para que a equipe tenha registros das fases de desenvolvimento do software. Na seção relativa à notação. Mas para que essa eficiência seja alcançada. 2006). serão apresentados os elementos utilizados na . serão estudados quais os artefatos e notações são úteis para que todo o trabalho da Modelagem de Negócios possa ser registrado e aproveitado. em especial na Modelagem de Negócios. O objetivo não é mostrar todos os artefatos e notações existentes que podem ser usados nas atividades dessa disciplina e nem que todos os mostrados aqui sejam sempre usados. Apesar da Modelagem de Negócios tratar de aspectos presentes tanto no lado do desenvolvedor quanto no do cliente. Dessa forma. antes. Portanto.58 4 – Artefatos e Notações Neste capítulo. para que a comunicação entre os desenvolvedores seja boa e para que tanto os desenvolvedores quanto os clientes possam saber em que estado o projeto se encontra. a finalidade das próximas seções é apresentar alguns artefatos chaves que podem ser usados para registrar as informações levantadas de uma forma eficiente. o que os clientes querem ver são os resultados. afinal. O estudo dessa seção está dividido em duas partes: notações e artefatos. a documentação direcionada para os desenvolvedores é geralmente melhor utilizada. não se pode achar que todos os membros da equipe lembrarão com detalhes das informações levantadas durante a realização das atividades descritas acima.

Isso faz com que. tornando a documentação mais prática. houve uma movimentação por parte da comunidade com o intuito de se padronizar uma notação que deveria ser utilizada em todos os projetos de TI pelo mundo. a partir do zero. via de regra. Uma notação é uma forma de representação de algo através da utilização de um sistema especial de marcas e caracteres (Wordnet. Em particular. 4. inclusive no de Tecnologia da Informação (TI). 2006). por exemplo. Lançada a primeira versão estável em 1991 pela Object Management Group (OMG). um determinado contexto. com o objetivo de facilitar a construção e compreensão dos modelos criados durante determinadas atividades. eles serão estudados na seção de notação. possam ser modelados visualmente. intuitiva e não-ambígua. pois o foco do estudo referente aos artefatos será a construção de modelos que englobem mais de um desses elementos e que ilustrem uma determinada situação. a Unified Modeling Language (UML). essa linguagem unificada é composta por uma coleção de símbolos que podem ser divididos em 3 blocos: coisas.1 – Notações A escolha de uma notação é fundamental para que a documentação fique padronizada. os responsáveis por essa padronização decidiram reunir algumas das notações existentes que estavam sendo comumente utilizadas e criar uma linguagem de modelagem unificada. 1999) que combinados fazem com que todas as etapas e aspectos do desenvolvimento. relacionamentos e diagramas (DEWALT. o analista de negócio possa . evitando que haja as catastróficas falhas de comunicação entre os membros da equipe e com o cliente. nessa área da informática. Por muito tempo várias empresas adotaram determinada notação nas documentações feitas em todos os seus setores.59 construção dos artefatos propostos para a Modelagem de Negócios. Apesar dos elementos também serem considerados artefatos. Ao invés de se criar uma notação toda nova.

2000). Apesar de existirem diversas notações. O que se deve ter em mente é que todas as informações coletadas devem estar disponíveis de uma forma clara. isso não é diferente: não existe uma forma correta de se usar a UML nem tão pouco a idéia de que existem componentes dessa linguagem que são indispensáveis para se construir os modelos resultantes das atividades desta disciplina.e. 2000). al. É por isso que a utilização da . ela é a utilizada dentro do RUP. o objetivo será apresentar aqueles componentes da UML que estão relacionados à Modelagem de Negócios. ou seja... é produzir uma série de modelos que servirão como planos para condução dos negócios. de uma forma que todos entendam se precisar fazer muito esforço. o objetivo da Modelagem de Negócios. i. 4. a UML não deve ser encarada como um produto final não-configurável..1 – UML e a Modelagem de Negócios As atividades realizadas durante a Modelagem de Negócios não têm sentido de serem realizadas se elas não produzirem resultados que podem ser utilizados pelas fases subseqüentes do desenvolvimento do software. sejam estes usados para priorização dos objetivos. pois ela dá suporte a todas as atividades propostas por ele. por exemplo. nesta seção. para a negociação de uma proposta. Assim como acontece com o RUP. simples e não ambígua. não existe somente uma maneira de utilizar a UML para modelar o que se deseja (ERIKSSON et. E no caso da Modelagem de Negócios. obviamente.1. Dessa forma. Afinal de contas. pois além de ser o padrão adotado mundialmente. possibilitando que todos os envolvidos no desenvolvimento falem a mesma língua e com isso seja aumentada e melhorada a produtividade. 2001). al. entre outras possibilidades (ERIKSSON et. será apresentada apenas a UML.60 usar a mesma notação e ferramenta para documentar os processos de negócios que o arquiteto de software usa para documentar a construção do sistema (HEUMANN.

serão apresentados a seguir alguns componentes e diagramas da UML que são comumente utilizados na Modelagem de Negócios. pois apesar deles serem escolhidos conforme a necessidade de cada projeto. aquela máxima que diz: “menos é mais”. São indivíduos que estão do lado de fora das fronteiras2 do sistema e que geralmente iniciam os processos de negócio (GIBBS. sendo que uma documentação mais enxuta. mas a documentação inteligente.61 UML já é um primeiro passo. . al. parceiros. uma vez que terão que “aprender” sobre a documentação. Figura 5: Exemplo de Ator de Negócio (RUP. pois como ela é a notação padrão. clientes. 2000). é bom que se tenha por onde começar para depois partir para a customização. entre outros (KRUCHTEN et. é provável que todos os envolvidos no processo já a conheçam e não necessitem de explicações de ordem técnica a respeito do modelo. i. 2006). Note que não está sendo defendida aqui a falta de documentação.e. pois as atividades dessa disciplina podem subentender muitos diagramas com vários componentes e isso pode acabar gerando um monte de documentação que tornará confuso o entendimento daqueles que a usarão. • Ator de Negócio: São os usuários no ponto de vista do negócio. Diante disso. vendedores.. direcionada1 e objetiva produzirá resultados melhores em menos tempo e com menos trabalho. Também deve ser levada em conta na hora de se decidir quais modelos produzir e quais componentes da UML escolher para a documentação da Modelagem de Negócios. 2002) 1 2 Que tenha o propósito de ser feita para auxiliar uma atividade futura que com certeza será realizada Indivíduos que não pertencem à Organização-alvo ou que fazem parte de um setor da Organização que não está no escopo da modelagem atual.

al. são os trabalhadores da Organização-alvo que estão dentro do escopo do modelo. Ou seja. 2000). Relacionam-se entre si e manipulam as entidades de negócio. Podem ser encaradas como materiais manipulados e produzidos na realização dos casos de uso de negócio. Figura 7: Exemplo de Entidade de Negócio (RUP. 2000). 2002) • Entidade de Negócio: São os objetos. 2001).62 • Trabalhadores de Negócio: São indivíduos que desempenham um papel dentro da Organização (KRUCHTEN et. Figura 6: Exemplo de Trabalhador de Negócio (RUP. as quais serão descritas no próximo item. Um caso de uso de negócios descreve o desempenho de uma seqüência de ações que produz um . al. as “coisas” que os de negócio utilizam. 2002) • Caso de Uso de Negócio: São os resultados das saídas dos processos de negócios (HEUMANN. gerenciam ou produzem trabalhadores (KRUCHTEN et.

2002) • Estado inicial: Indica o ponto de partida do modelo (ANQUETIL. 2002) • Atividade ou Estado de uma atividade: Representam a realização de um conjunto de ações (atividade) ou uma etapa do fluxo de trabalho. Figura 10: Exemplo de uma Atividade (RUP. 2002). 2002) 1 Pode ser percebido e medido (RUP. . 2006). marca a entrada de um processo. Figura 9: Estado Inicial (RUP.63 resultado de valor observável1 a um determinado ator de negócios (RUP. Figura 8: Exemplo de Caso de Uso de Negócio (RUP. 2002).

Figura 13: Barra de sincronização (RUP. marca a saída de um processo. .64 • Estado Final: Indica o término do diagrama (ANQUETIL. Figura 11: Estado Final (RUP. São linhas verticais que criam áreas para as atividades serem inseridas. Também são usados para sincronizar essas atividades. de um indivíduo ou de um papel. 2002) • Decisão: Ponto em que o fluxo tomará um sentido ou outro dentro do diagrama baseado em uma condição que é explicitada na saída dessa decisão. 2006). 2002) • Sincronização: Utilizado para indicar fluxos de atividades que irão ocorrer em paralelo. também deve ser usado para sincronização deste (HEUMANN. 2001) Figura 12: Decisão (RUP. Assim como é utilizado para realizar a separação do fluxo. 2002) • Raias (swim lanes): São usados para fazer a separação de responsabilidades dentro do fluxo. sendo que cada uma dessas áreas é de responsabilidade de um setor da organização.

o que deve ser avaliado é a importância e necessidade deles para o projeto. pois cada um tem sua finalidade e. mas quando eles atingem certo grau de maturidade. página 71. ou seja. não é necessário que todos os artefatos apresentados nesse framework sejam produzidos.65 Figura 14: Exemplo de Raias (RUP. deixados de lado. aqueles que forem julgados importantes devem ser incluídos no projeto e os que não forem. de até 7 desenvolvedores. Uma observação feita por Kroll & Krunchten (2002) que é importante destacar é que as etapas do desenvolvimento do software não devem estar amarradas aos artefatos. portanto. página 74.2 – Artefatos Dentro da disciplina da Modelagem de Negócios. os quais são descritos no RUP. Nesta seção serão apresentados alguns artefatos que são úteis para as duas etapas básicas em que foi dividida a Modelagem de Negócios: Aprovação do Projeto e Planejamento do Desenvolvimento. . as quais ilustram dois diagramas onde esses elementos são utilizados 4. 2002) Exemplos de utilização desses componentes podem ser encontrados na Figura 16. uma fase ou etapa de software não é encerrada quando os artefatos iniciados naquela fase são terminados. vários artefatos podem ser produzidos. Porém. e na Figura 18. levando-se em consideração que o projeto está sendo desenvolvido por equipes pequenas.

à medida que as terminologias. prevenindo a equipe de uma das causas mais comuns de mal-entendido e falha de comunicação: a falta de padrão nas terminologias utilizadas (KROLL & KRUCHTEN. sejam estes termos oriundos da análise de negócio ou do desenvolvimento do projeto.1 – Glossário Contém definições importantes utilizadas no projeto (RUP.2. • Serve como instrumento de padronização da comunicação.1 – Artefatos Utilizados na Aprovação do Projeto Durante a aprovação do projeto. o importante é definir bem do que se trata o projeto proposto e qual o tamanho estimado deste.2. os benefícios e uma ilustração simples de cada um. contendo uma breve descrição. abreviaturas e acrônimos utilizados no projeto estão todas nesse glossário (GIBBS. 4. o que implica em passar para a equipe uma visão clara de quem é a Organização-alvo. o que ela quer nesse projeto e quais as possibilidades e empecilhos existentes atualmente nos seus negócios que pode ter alguma influência no projeto. 2002). 2006). Muitas vezes este artefato é deixado de lado por parecer não ter muita importância ou ser muito trivial (GIBBS.66 Alguns artefatos servem para as duas etapas. 4. porém ele possui 3 serventias fundamentais: • Auxiliar novos integrantes do projeto a se situarem mais rapidamente no contexto do projeto. 2006).1. 2002). A seguir serão apresentados os artefatos que são úteis para a equipe na etapa de aprovação do projeto. porém eles serão especificados na subseção relativa à etapa que mais os utiliza. .

por lógica.67 • Evitar que os termos chaves utilizados no projeto sejam passados de um membro para o outro individualmente. pois esse meio é muito frágil e não confiável. o que causaria uma catástrofe. 2002) para que ele possa compreender perfeitamente a proposta. a equipe pode supor. é passível de esquecimento e uma mudança pode não ser informada a todos os membros. Como os termos do glossário foram capturados durante a análise de negócio junto ao cliente. gerando graves inconsistências de informações vitais. que ISS significa “Instituto da Saúde Social”. o glossário é importante para que haja entendimento sobre o que o cliente deseja. Por exemplo: uma parte de um projeto de um hospital consiste no envio de informações para a ISS. por “osmose”. a equipe responsável pela elaboração da proposta saberá exatamente quais termos usar para que o cliente entenda perfeitamente o que está sendo colocado. . Do lado da equipe. na medida em que ele não tem garantia de atingir toda a equipe. pois o responsável por escrevê-la deverá fazê-lo utilizando a linguagem do cliente (RUP. qual o tamanho do projeto e quais as partes envolvidas. Figura 15: Parte de um Glossário A importância desse glossário na etapa de aprovação do projeto é percebida principalmente no momento de se elaborar uma proposta para o cliente aprovar. Se ISS no projeto significar International Space Station e isso não estiver em um glossário. sem nenhum registro.

como o projeto será organizado. resultantes de uma análise de negócio inicial e contém já uma visão geral do que o projeto deverá produzir ao seu final (KROLL & KRUCHTEN. é notável que um glossário é indispensável para a etapa de aprovação do projeto.2 – Visão do Negócio Esse documento contém informações sobre a estrutura da Organização-alvo. Uma forma interessante de se produzir esse documento é elaborá-lo como se fosse a proposta para o cliente. para que todos os envolvidos possam falar a mesma língua e assim evitar falhas de comunicação que são os maiores causadores de problema durante essa fase do projeto. quais melhorias nos processos o sistema construído irá acarretar. al (2004) que ainda sugere que esse documento seja elaborado em formato de panfleto.2. 2002). .68 Dessa forma. Também será colocado nesse documento uma lista de funcionalidades que indica quais os serviços o sistema irá prover para os usuários para que as necessidades identificadas sejam atendidas. quais os objetivos da Organização de modo geral e quais os relacionados ao sistema. Adotando-se o formato de proposta. entre outros (RUP. sobre o sistema proposto e qual o papel desse sistema dentro da organização. na qual você incluiria um panorama geral da Organização. para que ele seja mais atrativo ainda ao cliente.1. quais setores dela serão afetados pela implantação do projeto. entre outros. 2002). Isso significa que a equipe irá ter em mãos um documento que esclareça questões relativas aos tipos de serviços e produtos oferecidos pela Organização. enfatizando qual a participação do cliente nele. 4. quais as suas metas. Esse formato é proposto por Pollice et. é interessante também já se colocar nesse documento algumas estimativas de quais metodologias serão utilizadas. quais serão os custos de tempo e dinheiro necessários.

69

Figura 16: exemplo de um documento de Visão em forma de panfleto

No capítulo relativo à abordagem prática serão mostrados como se extrair os principais componentes desse documento de Visão tratando-o como uma proposta, porém com o objetivo de se formalizar uma proposta mais tradicional do que a sugerida por Pollice et. al (2004), pois esta forma – panfleto – vai utilizar as mesmas informações que o modelo tradicional, porém a sua construção exige outras técnicas que estão fora do escopo deste estudo.

Assim, a importância desse artefato para a aprovação do projeto é notável, pois adotando-se a sugestão dada acima, este documento será a própria proposta entregue ao cliente e à equipe.

Um exemplo de proposta em forma de panfleto pode ser verificado no Apêndice A e de uma proposta no formato tradicional no Apêndice B.

4.2.2 – Artefatos Utilizados no Planejamento do Desenvolvimento

Durante a etapa de Planejamento do Desenvolvimento, é importante que seja bem definido quais as partes do negócio da Organização-alvo o projeto

70 afetará e qual a sua importância em cada uma delas para que se possa bolar uma estratégia inicial de como se desenvolver o projeto e que, com base nessas informações, já possa ser feito o planejamento da fase de Elaboração (KRUCHTEN et. al, 2000). Essa estratégia de desenvolvimento do projeto será mais bem estruturada e especificada na fase de elaboração, mas terá como ponto de partida esse “esboço” formulado na fase de iniciação, o que leva a concluir que essa etapa de Planejamento do Desenvolvimento constitui uma espécie de transição da fase de iniciação para a elaboração. Portanto, é fundamental que os elementos utilizados na definição da estratégia inicial estejam bem documentados para que a fase de elaboração tenha recursos suficientes e completos para realizar suas atividades.

4.2.2.1 – Modelo de Casos de Uso de Negócio
Este modelo descreve os processos de negócio da Organização e suas interações com as partes externas como clientes e parceiros (RUP, 2002). Um caso de uso de negócio é uma representação em alto nível de um processo de negócio que estará presente no sistema projetado, portanto, antes de se partir para os casos de uso do sistema, é preciso primeiro que os casos de uso de negócio estejam montados e bem compreendidos por todos (GIBBS, 2006).

Na construção do modelo de casos de uso de negócio, deve-se ter em mente que ele deve informar a quem o consulta como os clientes e parceiros utilizam o negócio da Organização-alvo, isto é, quais são os negócios envolvidos e quais os casos de uso deles. Uma forma alternativa é se pensar que um caso de uso de negócio documenta (intitula) o fluxo de um determinado negócio (HEUMANN, 2001).

Os casos de uso de negócio são formados basicamente por atores de negócio, casos de negócios – mostrados na seção referente a notações – e relacionamento entre eles todos. Para que o modelo possa ser bem compreendido, é

71 importante que ele seja bem estruturado, principalmente os relacionamentos presentes neste. É por isso que esses relacionamentos foram divididos em 3 tipos: • Extensão: Quando parte de um caso de uso de negócio for

opcional, i.e., quando ele não estiver sempre presente no processo de negócio que compõe esse caso de uso, ele pode ser colocado para fora como sendo um outro caso de uso de negócio que estende o caso de uso de negócio base1. • Inclusão: A inclusão é usada quando alguma(s) parte(s) de um caso

de negócio só tiver importância pelo resultado produzido por ele, ou seja, não importa o seu método para o caso de uso de negócio base, ele não compõe diretamente o corpo desse caso de uso. Para justificar a separação dessa parte é preciso que ela esteja presente em mais de um caso de uso de negócio ou que a separação dela facilite o entendimento do modelo. O que acontecerá é que essa parte consistirá em um outro caso de uso e será incluído dentro do caso de uso de negócio base e poderá ser incluído por outros casos de uso de negócio do modelo. • Generalização: Se forem identificadas semelhanças entre os casos

de uso de negócios, eles podem ser divididos e ter as partes iguais agrupadas em um caso de uso de negócio pai e as diferenças serem colocadas em casos de uso de negócios que herdam desse pai (RUP, 2002).

Lembrando que esses relacionamentos devem ser usados somente se eles facilitarem a compreensão do modelo, portanto é preciso tomar muito cuidado ao utilizá-los para não a complicar feita é o modelo que esses (RUP, 2002). Outra observação não

importantíssima

ser

relacionamentos

especiais

necessariamente surgem na criação do modelo, mas durante o desenvolvimento de

1

Caso de uso original que foi modificado devido a inclusão ou exclusão de sua composição (RUP, 2002).

é interessante que esses caso de uso sejam analisados mais detalhadamente.2 – Diagrama de Atividades Depois de levantados os casos de uso de negócio. Figura 17: Exemplo de caso de uso de negócio (RUP. conforme são identificadas características no processo de negócio que justifique as alterações no modelo. 2002) 4. Porém como o desenvolvimento é iterativo. Para se entender melhor o que cada um desses casos de uso realiza e qual a participação dos atores nele é interessante que seja montado um diagrama de atividades (HEUMANN.2.72 outros modelos. Portanto.2. 2001). um diagrama de atividades descreve um fluxo de trabalho e explora a ordem . elas devem ser feitas. como os diagramas de atividades. O diagrama de atividades é o principal diagrama da UML utilizado para representar os processos de negócio que ocorrem dentro da Organização-alvo.

Assim. e o estado final. sendo que uma atividade pode consistir de uma tarefa manual ou automatizada (RUP. . pois esses processos definirão muitos dos relacionamentos entre as classes desse domínio. pois o sistema desenvolvido deverá atender esse processo. incluindo transições entre elas e estruturas de controle como os elementos de decisão e sincronização. a equipe terá também um documento que servirá como consulta na hora de se realizar a modelagem de domínio.73 das tarefas ou das atividades que realizam os objetivos e metas do negócio explicitado nos casos de negócio. recebendo as entradas descritas e gerando as respectivas saídas. pode-se notar que o diagrama de atividades é importantíssimo para a equipe de desenvolvimento. atividades. A Figura 17 ilustra esses componentes e a relação entre eles. Ao criar esses diagramas de atividades. O diagrama de atividades é composto basicamente por um estado inicial. na medida em que ele descreverá como são os processos que acontecem dentro da empresa. principalmente em questões de entradas e saídas. 2002).

A Figura 18 ilustra esse diagrama. mostrando qual trabalhador ou entidade da Organização .explicados no próximo tópico – realizam determinada atividade (HEUMANN. 2002) Apesar de esse diagrama atender às necessidades básicas de representação das atividades que acontecem dentro da Organização.74 Figura 18: Exemplo de diagrama de atividades. No diagrama acima estão apontados os componentes básicos de um diagrama de atividades. (RUP. ainda existe uma variação desse diagrama que contém elementos chamados de “raias” (swim lanes). 2001). .

e como eles se relacionam entre si (KROLL & KRUCHTEN. Ele captura as responsabilidades e conceitos importantes dentro do negócio da Organização. Esse modelo apresenta características transitórias em relação ao tipo de pensamento. mas utilizado no ponto de vista tecnológico. O modelo exposto nesta seção possui uma função importantíssima: transição do ambiente de negócios para o ambiente de tecnologia. em se tratando das entidades presentes nessas relações. na qual as idéias estão relacionadas a softwares. 2001). e do papel do software dentro dela. . 2002).2. pois este modelo diz como será feito (HEUMANN.3 – Modelo de Objetos de Negócio Este modelo é complementar ao modelo de casos de uso de negócio.2. Ele é o produto final da etapa de compreensão do negócio realizado pela Organização-alvo. uma vez que ele ainda é construído na visão do negócio.75 Figura 19: Diagrama de atividades utilizando raias (swim lanes) 4. que diz o que será feito.

são construídos os relacionamentos entre esses trabalhadores. as entidades e as relações entre eles. Em seguida. que consiste em capturar as classes de entidades mais importantes do domínio e como elas se relacionam entre si. • criar um modelo com foco na reengenharia de negócios: neste caso. Depois.76 Quando vamos realizar a modelagem dos objetos de negócio. agregação e associação de modo geral. portanto. os quais foram descritos na seção anterior. entre as entidades e entre os . 2002). o objetivo é fazer uma reformulação no negócio da Organização. o que caracteriza este modelo como sendo de transição entre a Modelagem de Negócio e o início do desenvolvimento (RUP.e.. esse modelo permite que existam entre os elementos as relações como herança. i. primeiramente são identificados os trabalhadores da organização e os recursos que eles utilizam nos processos de negócio. • não criar nenhum modelo haja vista que todos integrantes da equipe já conhecem bem o domínio do negócio. nos deparamos com 3 possibilidades de criação do modelo: • criar um modelo com foco na extração dos elementos do domínio: neste caso o que é feito é a construção de um modelo chamado “modelo de domínio”. é necessário que sejam feitos 2 modelos de objeto: uma descrevendo a situação atual da Organização e um descrevendo como ela ficará depois da reestruturação (RUP. sendo que essas classes estão dividas em 2 categorias: trabalhadores de negócio e entidades de negócio. Um modelo de objetos de negócio nada mais é do que um diagrama das classes de objetos envolvidos no negócio e os seus relacionamentos. Para se construir este modelo. Assim. são definidos esses trabalhadores como “trabalhadores de negócio” e os recursos como “entidades de negócio”. os trabalhadores. enquanto diagrama de classe. 2002).

é interessante se criar um diagrama de atividades alternativo que contém as transições entre. além das atividades.77 trabalhadores e as entidades. os objetos marcados com seus respectivos estados atuais. são utilizadas as raias para representar os trabalhadores de negócio e as entidades para representar os objetos. A figura abaixo ilustra esse modelo. Figura 20: Modelo de objetos de negócio ilustrando um caso de uso de negócio de Check-in Individual (RUP. 2002). A figura abaixo é um exemplo de um diagrama de atividades com fluxo de objetos. Além disso. de modo que sejam ilustrados no modelo como se dão os diversos casos de uso de negócio da Organização. 2002) Para dar um detalhamento maior de um determinado o fluxo de atividades envolvido no modelo e como os objetos se comportam nele. . Em baixo do nome dos objetos é colocado entre colchetes qual o estado atual do objeto. Estas transições entre os objetos são chamadas de “fluxo de objetos” (RUP.

pois ele foi construído com foco no negócio do cliente e não foco no sistema de informação. afinal o objetivo real não simplesmente implementar um software. Esse tipo de abordagem proporciona à equipe um ganho de tempo e qualidade na modelagem tecnológica do sistema. pois ao mesmo tempo em que a equipe terá uma parte do trabalho já feita. o diagrama de classes inicial já estará extremamente coerente com o que o cliente deseja que o sistema faça.78 Figura 21: Um diagrama de atividades com fluxos de objetos mostrando como um pedido muda de estado durante o processamento de um pedido. mas resolver os .

o modelo terá grandes chances de estar correto e. uma vez que o modelo de objetos de negócios é um artefato que é usado como transição entre a coleta de informações do negócio da Organização-alvo e o início do desenvolvimento do sistema. depois de terminada a construção do modelo. de ter alguma utilidade para os desenvolvedores do sistema na etapa seguinte do processo. Ao final da construção do modelo. principalmente. em conjuntos. é preciso saber o que se quer e se isso foi conseguido..e. é importante que se tenha garantia de um bom trabalho. do modelo? A visão que o modelo de objetos criado proporciona sobre a Organização é adequada? Já é possível se extrair do modelo algumas classes para entrarem no plano de implementação? Caso essas três verificações tenham sido feitas.79 problemas existentes na Organização-alvo e propor novas possibilidades que irão dar ao cliente vantagens competitivas no mercado. três verificações devem ser feitas: • • • Todas as atividades descritas nos casos de uso de negócio estão sendo representadas pelos objetos. i. Assim. .

o documento da proposta se torna um verdadeiro “folder de propaganda”. onde ela quer chegar e quais as possibilidades de isso acontecer. o EKD é útil principalmente na hora de se formalizar a proposta que deverá ser aprovada pelo cliente. A metodologia EKD possui diretrizes que basicamente mostrarão ao cliente como sua Organização se encontra atualmente. bem esclarecidas e colocadas. e para isso possa acontecer. pois ao se utilizar as técnicas descritas por esta metodologia. porém com todas as informações. serão colocados em prática todos os conceitos estudados até o momento. boas e ruins (problemas do cliente). Neste capítulo. 5. é preciso que se dê uma abordagem prática para que essa mescla dos conhecimentos faça algum sentido e tenha alguma utilidade. de forma que se torna visível como a aplicação dessas técnicas e metodologias relativas à Modelagem de Negócios agrega valor ao software.1 – O EKD e a Aprovação do Projeto Conforme estudado no capítulo “A disciplina de Modelagem de Negócios”. Parte da junção desses elementos pode ser visto de forma mais concreta ainda no Apêndice B – Proposta Tradicional. Portanto. A situação descrita nas próximas seções é referente ao desenvolvimento da Modelagem de Negócios realizada durante a fase inicial do segundo projeto de construção de alguns módulos para a Intranet do Departamento de Computação da UEL.80 5 – Abordagem Prática Depois de estudadas diversas técnicas e metodologias. o primeiro marco das atividades relacionadas à essa disciplina se dá na aprovação do projeto. é preciso que tanto o cliente quanto a equipe desenvolvedora aprovem os termos colocados. .

i. .1 – Modelo de Objetivos Como estudado no tópico referente. essa dificuldade vem do fato das pessoas que aplicam as metodologias não as adaptarem às suas reais necessidades. Portanto. Afinal. metas e resultados. elas utilizam recursos da metodologia para resolver problemas que elas não têm na verdade. quais conceitos e práticas desta metodologia são úteis nesse contexto e qual o valor que essa metodologia irá agregar ao software de maneira geral. 5. e mais concretamente dentro da elaboração da proposta de desenvolvimento de software. a finalidade do Modelo de Objetivos dentro da Modelagem de Negócios. e novas oportunidades. PERSSON & STIRNA 2001).81 As metodologias.. Nesta seção será apresentado qual o papel do EKD dentro do desenvolvimento.1. se mostram mais simples na teoria do que na prática e com o EKD não é diferente. além da possibilidade de se identificar possíveis oportunidades de inovações para os processos atuais que irão agregar mais valor ainda ao negócio realizado pela empresa. Porém. deve-se ter em mente que uma Organização é movida por objetivos. o Modelo de Objetivos dentro do EKD descreve objetivos da Organização. portanto. A utilização desse sub-modelo do EKD na elaboração da proposta proporciona ao documento da proposta uma maior objetividade e uma melhor especificação de qual o papel do software dentro da empresa e o que ela vai ganhar adotando este sistema. como o software irá fazer com que os objetivos sejam mais facilmente alcançados. é mostrar quais objetivos da Organização a serem atingidos (BUBENKO. independente da existência de um sistema de informação. i. e..e. na maioria das vezes. alguns problemas para atingir esses objetivos. bem como o software irá resolvê-los. a proposta deve especificar da melhor forma possível os objetivos da Organização que o software irá contribuir para atingir.

que estarão relacionados ao sistema como um todo e depois refinar (PÁDUA. 2. relacionando-os às funcionalidades (módulos) que compõe o sistema. Na elaboração da proposta. cada módulo do sistema terá seus objetivos. Quais objetivos não estão sendo atualmente alcançados e quais os problemas estão criando este empecilho? R: O objetivo A não está sendo alcançado por causa do problema P. é fundamental que esses objetivos estejam claramente especificados. D e F. Para o objetivo Y os módulos são B. sendo que cada objetivo pode estar relacionado a mais de um módulo ao mesmo tempo. Portanto. deve-se responder às seguintes perguntas com as respectivas respostas: 1.82 Na construção do Modelo de Objetivos. A forma mais clara de se responder esta pergunta é montar uma tabela semelhante à Tabela 2: Relação entre objetivos da Organização e os problemas em se alcançá-los . B e C. para guiar a construção desse modelo e inseri-lo na proposta de software. Ou seja. 2004) cada um dos objetivos em sub-objetivos. Quais os objetivos da Organização relacionados a este sistema? R: Para o objetivo X os módulos são A. A forma mais clara de se responder esta pergunta é montar uma tabela semelhante à Tabela 1: Relação entre objetivos da organização e módulos do sistema. uma estratégia interessante é criar objetivos de alto nível. pois são eles que irão dizer aos membros da Organização o porquê do investimento.

armazenando-as de forma prática e útil Promover o bem estar dos alunos Disponibilização on-line cronogramas das aulas Controle de monografias Sistema de controle entrega de pauta dos de Tabela 1: Relação entre objetivos da organização e módulos do sistema Objetivo Problema . tornando as informações geradas por ele mais seguras e consistentes. Quais os objetivos o software irá tornar mais fáceis de se alcançar? R: O objetivo B será mais facilmente alcançado pelo motivo M. foramse identificados por meio de conversa com funcionários quais os objetivos da empresa. chegando-se ao seguinte: Objetivo Melhorar a divisão do trabalho Sistema Controle de monografias Disponibilização on-line cronogramas das aulas atividades dos Automatizar rotineiras e agilizar Controle de monografias Sistema de controle de entrega de pauta Emissão automática de comprovantes que são úteis aos docentes Controle de monografias Sistema de controle entrega de pauta de Dar mais credibilidade ainda ao departamento. Durante a análise de negócio de uma determinada Organização.83 3.A forma mais clara de se responder esta pergunta é montar uma tabela semelhante à Tabela 3: Relação entre objetivos da Organização e oportunidades de se alcançá-los Abaixo segue um exemplo ilustrando o procedimento descrito nas perguntas acima.

já são entregues em formato eletrônico. sem a necessidade de intermediação de técnicos e secretários para tal trabalho. Tabela 3: Relação entre objetivos da Organização e oportunidades de se alcançá-los 5. ou seja. Cronogramas não atualizados e inconsistentes às vezes fazem os alunos irem a aula em dias que não há aula. . ou criar a expectativa de se ter aula com um professor e na verdade ter com outro.2 – Modelo de Regras de Negócio O modelo de regras de negócio deve ser utilizado quando forem identificadas regras que fujam à lógica ou que sejam extremamente importantes para o funcionamento da Organização.84 Melhorar trabalho a divisão do Falta de processos bem definido Falta de um meio central de realização de atividades As informações destinadas tanto aos docentes como aos discentes são todas fornecidas pela secretária por telefone. Portanto. email ou pessoalmente. portanto é possível que ela seja entregue via Internet. Promover o bem estar dos alunos Tabela 2: Relação entre objetivos da Organização e os problemas em se alcançá-los Objetivo Automatizar e agilizar atividades rotineiras Oportunidade A entrega das monografias são feitas em CD. Os alunos precisam se deslocar até a UEL ou enviar pelo correio a versão final da monografia.1. é importante que o responsável pela análise das regras levantadas identifique junto a um membro da Organização quais as regras não são tão óbvias e simples e quais não podem ser quebradas em hipótese alguma para que seja colocada na proposta a ciência que a equipe tem em manter a segurança do sistema.

abrindo espaço para desorganização e até fraudes no seu negócio. Isso da credibilidade ao cliente. Regra 3: O protocolo deve ser assinado pelo aluno e por quem o emitiu (secretária) O exemplo acima ilustra bem uma situação em que os membros da equipe estão cientes de algumas regras. nome da secretária que realizou a operação e um indicativo de qual o tipo do protocolo (Entrega de monografia). Regra 2: O protocolo não pode ser emitido depois das 18:00. restrições e políticas que deverão ser implementadas no sistema desenvolvido. assim. Exemplo: Geração Automática de Protocolo Quando um aluno for entregar uma versão da monografia na secretaria do departamento. que se sentirá segurança por não correr o risco de ter suas regras e políticas quebradas. data de emissão. . o sistema deve emitir um protocolo com o nome do aluno. as regras de negócio que respeitas pelo sistema. a segurança do sistema. assegurando.85 Seria inserida na descrição das funcionalidades dentro da proposta. Regra 1: O protocolo não será emitido pelo sistema caso o aluno não tenha assistido a pelo menos 70% das aulas.

utilizando-se a idéia do RUP (2002) de processo iterativo. ele é de fundamental importância para a equipe e.3 – Modelo de Conceitos Na elaboração da proposta. devem ser coletadas todas as informações desse local de postagem de dúvidas e o modelo de conceitos deve ser construído. Um tipo específico de coleção de documentos ou um software colaborativo usado para criar esses documentos (WIKIPEDIA. pois para compreender os objetivos extraídos do cliente. Depois dessa fase de aprendizado coletivo. Porém. Persson & Stirna (2001) é seguir uma série de perguntas que ele fornece. uma vez que quem definiu as partes dele foram os próprios clientes. esclarecendo quais são os conceitos e termos que estavam mal-entendidos. A proposta para o cliente não precisa conter nenhuma informação desse modelo.1. todos da equipe terão acesso e poderão responder à dúvida dos colegas. Ele é particularmente importante para a equipe de desenvolvimento. é necessária uma forma sistemática de construí-lo. 1 . pode-se tornar o processo mais prático procedendo-se assim: para cada uma das modelagens (objetivos. Nesse local de postagem das dúvidas. 2006). A sugestão dada por Bubenko. atores e recursos e requisitos e componentes técnicos) entregue o documento que contém o modelo construído para cada membro da equipe e disponibilize um local – página de Internet em formato wiki1 por exemplo – para que todos eles possam postar os conceitos e termos que não compreenderam durante a análise dos documentos.86 5. processos de negócio. Porém. este modelo serve para definir alguns termos e entidades existentes no modelo de objetivos e estabelecer de forma clara o escopo da aplicação. portanto. regras de negócio. a equipe terá que consultar esse modelo para poder compreender exatamente o que o cliente quis dizer e para se ter uma dimensão do tamanho do projeto.

recebendo a entrada desejada e gerando a saída esperada. os quais descrevem o fluxo de atividades que ocorrem em cada um desses processos que acontecem dentro da empresa. pois ela torna a documentação dos conceitos e termos bem prática na medida em que ela será formada a partir de dúvidas reais da equipe e não de possíveis dúvidas. Exemplo: Processo de entrega de monografia . Esse modelo não será utilizado diretamente na elaboração da proposta. pois ele não acrescentará muita informação ao cliente. Porém ele será de fundamental importância para a equipe poder identificar oportunidades e problemas dentro do negócio e apresentá-los na proposta. pois ele diz quais são as entradas e saídas dos processos.1. o que serve como uma espécie de norte para que a equipe avalie se o sistema implementado está realizando o processo todo.87 Essa estratégia sugerida aqui é interessante. além do que os conceitos serão esclarecidos segundo a visão e linguagem de todos os membros da equipe e não de um em particular.4 – Modelo de Processos de Negócios O Modelo de Processos de Negócios é geralmente representado pelos diagramas de atividades..e. i. esse modelo é fundamental. 5. Para a equipe de desenvolvimento.

88 Entrada: Primeira versão da monografia Saída: Protocolo de entrega de monografia 5. destaca-se a dele servir como um instrumento de identificação de acúmulos de responsabilidades para alguns atores e da forma de utilização dos recursos.1.5 – Modelo de Atores e Recursos O Modelo de Atores e Recursos descreve alguns trabalhadores e clientes da empresa bem como os recursos que eles utilizam para realizar as suas atividades. Dentre suas várias utilidades. .

em uma abordagem prática. Com a geração garantida do protocolo.1. Sistematização do processo. pois com uma melhor divisão do trabalho os funcionários que antes ficavam cheios de tarefas para realizarem agora poderão produzir algo mais qualificado e melhorar seu serviço. Portanto. colocar alguns requisitos de alto nível identificados na Modelagem de Negócios e qual o ganho que ele irá gerar. evitando confusões e/ou dúvidas por parte dos envolvidos no processo. Exemplo: Requisito Geração automática de protocolo Benefício Agilidade no processo fazendo com que a secretária possa produzir mais. diminuição de burocracia e dependências que o sistema pode proporcionar e que devem ser sugeridas na proposta. vemos que este modelo serve para identificação de pontos de melhorias do negócio.6 – Modelo de Requisitos e Componentes Técnicos Dentro da elaboração da proposta. A geração do protocolo é padronizada. reduzem-se as possibilidades de fraudes. Segurança. aproveitamento de recursos. dando mais confiança ao Relatório de entrega de pauta com notificação aos docentes . Consistência da informação sobre quem entregou e quem não entregou a pauta. principalmente relativas à divisão do trabalho. o Modelo de Atores e Recursos serve para se identificar melhorias de divisão de trabalho.89 Sob essa perspectiva. Com essas informações em mãos a equipe pode sugerir na proposta melhorias que o sistema pode proporcionar a essa divisão do trabalho e como a empresa ganhará com isso. 5.

evitando que algum aluno ou professores vá para a aula quando não houver. Uma sugestão clara e direta dada por Heumann (2001). automaticamente ele será atualizado para os professores e alunos.90 processo.2 – Planejando e Adiantando o Próximo Passo Apesar das diversas utilidades da Modelagem de Negócios. tais como os utilizados na etapa de análise. ajudando os professores a se lembrarem de entregar a pauta e possibilitando que a secretária faça isso mais rápida e facilmente. Disponibilização on-line cronogramas das aulas dos Os professores e os alunos poderão saber quando irão ter aula sem a necessidade de ligar na secretaria. dentro dos modelos de negócio existe a possibilidade – e por que não dizer intenção – de se construir um modelo que possa depois ser mapeado para os modelos de sistema. é a de que sejam feitos seguintes mapeamentos: • • De um processo de negócio para um caso de uso De um caso de uso de negócio para um subsistema . Cumprimento dos prazos de entrega conforme estabelecido. Tabela 4: Relação dos requisitos com os benefícios gerados 5. Facilidade na comunicação da secretária com os docentes. Portanto. demonstrando que o departamento se preocupa em proporcionar facilidades para os alunos e para os professores. Consistência nos cronogramas. Quando um cronograma sofrer alterações. o seu objetivo principal é auxiliar a construção de um sistema de informação.

• os objetos (entidades) e seus relacionamentos identificados no modelo de objetos de negócio correspondam a classes de entidade com os respectivos relacionamentos dentro do sistema Seguindo essa proposta dada pelo RUP. um caso de uso de negócio que tem participação dos trabalhadores de negócio deve.91 • De uma entidade de negócio para uma classe de entidade do sistema Segundo este autor. Uma forma mais detalhada é colocada no RUP (2002). . A seguir é apresentada esta ilustração. Krunchten (2000) fornece um exemplo que ilustra bem essa situação envolvendo os mapeamentos citados acima. a priori. esse mapeamento irá facilitar o início da fase de análise e design do sistema a ser construído. ser mapeado para um caso de uso do sistema. ele pode ser divido. mas se o caso de uso de negócios for complexo ou muito grande. onde é sugerido que: • • um trabalhador de negócios no modelo de negócios corresponda a um ator dentro do sistema de informações.

92 1. que mostra como esse caso de uso é feito e quais as entidades e trabalhadores da empresa envolvidos no processo. Figura 23: Modelo de Objetos de Negócio – Transação Financeira (KRUCHTEN et. 2000) 1. al.1. 2000) . Figura 22: Modelo de Caso de Uso de Negócio – Transação Financeira (KRUCHTEN et. Na figura abaixo está ilustrado o modelo de objetos de negócio do caso de uso de negócio de transação financeira.2. Trabalhador de Negócio de Uso do Sistema Ator do Sistema e Caso de Uso de Negócio Caso 1. Na figura abaixo está ilustrado o caso de uso de negócio em que um cliente realiza uma transação financeira. al.

2000) . Na figura abaixo está representado o mapeamento dos trabalhadores de negócio em atores do sistema e dos casos de uso de negócio que estes atores participam. al. Figura 24: Mapeamento do modelo de negócio para o de sistema (KRUCHTEN et. no caso o caso de uso de negócio de transação financeira. em casos de uso do sistema.93 1.3.

Figura 26: Modelo de Objetos de Negócio – Transação Financeira (KRUCHTEN et. A exemplo do primeiro mapeamento. al.94 2.2. que mostra como esse caso de uso é feito e quais as entidades e trabalhadores da empresa envolvidos no processo. na figura abaixo está ilustrado o modelo de objetos de negócio do caso de uso de negócio de transação financeira. na figura abaixo está ilustrado o caso de uso de negócio em que um cliente realiza uma transação financeira. Figura 25: Modelo de Caso de Uso de Negócio – Transação Financeira (KRUCHTEN et. Assim como no primeiro mapeamento. 2000) 2. al.1. 2000) . Entidade de Negócio Classe de Entidade 2.

95 2.3. Na figura abaixo está representado o mapeamento das entidades de negócio em entidades de classes. No caso as entidades “Perfil do Cliente”, “Conta” e “Empréstimo” foram mapeadas para classes de entidade de mesmo nome no modelo de análise.

Figura 27: Mapeamento dos objetos de negócio para as classes de entidades (KRUCHTEN et. al, 2000)

Dessa forma, é possível notar que esses mapeamentos irão promover algum adiantamento nas atividades de levantamento de requisitos e de design no sistema, pois a partir dos modelos de negócio chega-se à primeira versão do modelo de casos de uso e do diagrama de classes. Isso acarreta não só no adiantamento de trabalho, mas no amadurecimento da compreensão das necessidades e oportunidades identificadas na Organização-alvo, além da criação de artefatos utilizados para planejamento desse próximo passo que consistirá em mais atividades de construção e implementação propriamente ditas.

96 Esse diagrama de casos de uso já pode ser utilizado para o início do levantamento de requisitos do sistema, pois nele já estarão descritas algumas funcionalidades. O diagrama de classes, por sua vez, também já pode ser usado para o design do sistema, i.e., para construção do modelo de domínio, sendo que nessa construção, essas classes irão ser recheadas com atributos e novos relacionamentos poderão surgir, entretanto a origem dessa modelagem se deu por meio do mapeamento do modelo de negócio para o modelo de sistema.

97

6 – Conclusão
No presente trabalho, foram apresentados os principais pontos dentro da disciplina de Modelagem de Negócios do RUP e algumas técnicas e metodologias que podem ser utilizados para realização das suas principais atividades e para obtenção das informações que por ela devem ser geradas.

Como pode ser visto durante o estudo, a Modelagem de Negócios é fundamental para qualquer projeto de software, pois ela atende duas necessidades fundamentais desse projeto: comunicação e planejamento. Ela é a maior responsável pela sintonia entre o que o cliente deseja e o que serviço prestado irá fornecer, pela compreensão da equipe a respeito da missão do projeto e pelo planejamento geral de todas as etapas do desenvolvimento.

Para que a comunicação com o cliente seja realmente efetiva, é importante que sejam utilizadas técnicas de extração e organização do conhecimento e informação. Nesse ponto, o estudo mostrou que a técnica EKD se mostra uma forte arma para que a equipe, ou os responsáveis dentro dela, possam mostrar ao cliente a importância do software produzido para o seu negócio, destacando a quais objetivos ele está relacionado e quais benefícios diretos ele vai gerar para a Organização.

Com relação ao trabalho da equipe de desenvolvimento, a forma mais segura e eficiente de comunicação é o registro (documentação) das informações necessárias para que a equipe saiba exatamente a missão do projeto, sem perder o foco. Além da questão ligada à comunicação, o registro das informações também importante para o planejamento, uma vez que essas informações serão essenciais para que se possa escolher o melhor caminho a se seguir durante o desenvolvimento.

Pode-se ver, então, que muito tem a ser trabalhado dentro dessa área uma vez que ela vem sendo estudada mais seriamente nos últimos anos com a

Assim. a junção da metodologia EKD com algumas técnicas do RUP para o desenvolvimento da primeira etapa dessa metodologia. um estudo futuro a se realizar. . o que mostra um outro ramo de estudo nessa área que é a de construção de modelos reaproveitáveis. sendo apresentado. é o desenvolvimento de uma metodologia para realização da segunda etapa dessa metodologia. Apesar da junção do EKD com o RUP também ser útil para a segunda etapa da metodologia sugerida. a modelagem de objetos de negócio tem sua importância não somente na questão do entendimento do negócio. Uma área particularmente interessante é a área de modelagem de objetos de negócio como atividade preparatória para a modelagem de domínio. o presente trabalho visou construir uma metodologia para se realizar a Modelagem de Negócios. como parte da contribuição. mas na parte de implementação do projeto. ela não a contempla totalmente e. dividindo-a em duas etapas: aprovação do projeto e planejamento do desenvolvimento. Como contribuição. que atualmente vem sendo encarada como o modelo principal de uma aplicação. portanto.98 aproximação da informática nos negócios.

99 .

Acesso em: 14 out 2006.pg. Salvador.br/portal/opiniao/exibir. Stockholm: Royal Institute of Technology. S. diagrama de estado. Acesso em: 10 nov 2006. Department of computer and systems sciences. In: 26 º Encontro Nacional da Associação Nacional dos Programas de Pós-Graduação em Administração. Janis jr.pdf>. PERSSON. html>. ENANPAD.. D. H.br/ppgep/revista/revista2005/pdf4/RGIv01n04a02.php?id_trabalho=85>.se/users/js/ekd_user_guide. Acesso em: 10 out 2006. CASTRO.br/ucbtic/mgcti/paginapessoalprof/Nicolas/Disciplinas/UML/node7. . Disponível em: <ftp://ftp. BELTRÃO. 2002. ROZENFELD. M. C. n. Edson Walmir.su. v. Quanto Custa Meu Design?.designbrasil. Disponível em: <www.jhtml?idArtigo=593>. Disponível em: Acesso <http://www. Salvador: ENANPAD. BUBENKO.72 – 75. Acesso em: 2 jul 2006. 4. Janis. 436-443.. EKD user guide. Anne. BARBALHO. Um modelo de mudança organizacional contínua através da gestão do conhecimento integrando tecnologia da informação e pessoas. AMARAL.org.br/congresso/inscritos/teste2. 2002. 1. Análise da abrangência de metodologias de modelagem de empresas.pdf>. Disponível em: <http://www. Revista Gestão Industrial. Sergio Alexandre de. Diagrama de atividade.ifm. em 08 nov 2006.ucb. p. Nicolas. 2005.dsv.100 Referências Bibliográficas ANQUETIL. 2001. CAZARINI. 2006. C. Disponível em: <www.org..cefetpr. STIRNA. p. André.

Business Modeling with UML: Business Patterns at Work. GIBBS. ed. KOZACZYNSKI. The Rational Unified Process: An Introduction. KRUCHTEN.pdf>. Peter. 2004. Jim. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. KRUCHTEN.geti. Craig. Introduction to Business Modeling Using the Unified Modeling Language (UML). Boston: Addison-Wesley. Hans-Erik. ERIKSSON. PENKER. 312 p.jsp>. Upper Saddle River: IBM Press.br/downloads/HpReq. 2000. 459 p. 2001. 464 p. Acesso em: 10 jun 2006. Wojtek.therationaledge. Heurísticas para Identificação de Requisitos de Sistemas de Informações a partir de Modelos de Processos. . Project Management with the IBM® Rational Unified Process®: Lessons from the Trenches. Kelli. 288 p. Philippe. Dennis. R. 2003. 320 p. EELES.ufrj. Building J2EE Applications with the Rational Unified Process. Johns Hopkins University. Pren. Boston: Addison-Wesley.dcc. Disponível em: http://www. Disponível em:<www. Tese (Mestrado em Informática) – Núcleo de Computação Eletrônica. Universidade Federal do Rio de Janeiro. Pedro Oscar de Souza.101 CRUZ. 2000. Philippe. HEUMANN. KROLL. 2002. Magnus. Boston: Addison-Wesley.com/content/mar_01/m_uml_jh. 92 p. Rio de Janeiro. 2006. HOUSTON. Acesso em: 10 ago 2006 DEWALT. 1999. Business Process Modeling with UML. The Rational Edge. John Wiley & Sons. 2.

Janis. The Rational Unified Process. Carlos Eduardo. Jas. 2004.choose. 252 p. Disponível em: <http://www.se/~js/ekp/ekd_method. Acesso em: 10 ago 2006 POLLICE.br/infochoose/artigos/39art03.dsv. Chris. Software Development for Small Teams A RUP-Centric Approach. Silvia Inês Dallavalle. versão 2002.pdf>.html>. São Carlos. 2004. MADHUR. Boston: Addison-Wesley.com/content/apr_02/t_businessProcessModeling_pn. 2004. Tese (Doutorado em Engenharia Mecânica) – Escola de Engenharia de São Carlos. Acesso em: 10 out. The Rational Edge. 1-20.. 304 p. STIRNA. IBM Rational.102 MARQUIONI. Acesso em: 05 jun. Disponível em: <http://www. RUP. Disponível em: <http://www. Edson Walmir. AUGUSTINE.htm>. NG. Liz. Universidade Federal de São Carlos. Ricardo Yassushi. Business Process Modeling and Simulation with UML.su. p. Modelagem organizacional: captura dos requisitos organizacionais no desenvolvimento de sistemas de informação. INAMASU.br/pdf/gp/v11n2/a06v11n2. Gary. PÁDUA. 11. 2006 . Pan-Wei. LOWE. 2002. São Carlos. CAZARINI. A Modelagem de Processos de Negócio como subsídio fundamental para a identificação dos Requisitos. EKD - Enterprise Knowledge Development.scielo. Acesso em: 10 jun 2006 PÁDUA.therationaledge. Revista Gestão e Produção. v. Disponível em: <www.jsp >.com. Método de avaliação do Modelo de Processos de Negócio do EKD. Silvia Inês Dallavalle. 2006.

org/wiki/Wiki>.edu/perl/webwn?s=notation>. Acesso em: 28 out 2006. Disponível em: <http://en. Acesso em 11 nov 2006.1: notation.103 TEIXEIRA.princeton.com/ler.wikipedia. . WIKIPEDIA.wikipedia. Disponível em: <http://wordnet. Wiki. Rational Unified Process. O que significa metodologia. Gilberto. WordNet Search - 2. Disponível em: < http://spu. Acesso em: 07 nov 2006. Disponível em: <http://pt. Acesso em: 10 out 2006. WIKIPEDIA.org/wiki/Rational_Unified_Process>.php?modulo=21&texto=1338>. WordNet.autoupdate.

.

br / 9941-0825 Eduardo Zanoni Marques ezmarques@hotmail.com / 9124-0104 .com.Apêndice A – Proposta em forma de Panfleto Sistema de Avaliação Docente Inbrape (Apresentação de Projeto) Tiago de Oliveira Stutz tiagostutz@yahoo.br / 9103-8839 Daniel Teleginski Camargo telecargo@yahoo.com.

Necessidades e Oportunidades A qualificação profissional sempre foi um dos fatores determinantes para que um indivíduo ocupe seu lugar no mercado. O Papel da Informática Papel da Informática dentro da organização (cadastros. deverão passar por um processo de informatização e criação de um cultura digital interna. pelo menos uma vez. por exemplo. para que as atuais instituições de ensino possam se adaptar a essa nova realidade do mercado. Um bom começo é agilizar os processos das organizações.ibge.) e no ensino à distância Com o desenvolvimento da tecnologia e a popularização da informática. . 2005 (http://www. domicílio de outras pessoas ou qualquer outro local) nos 90 dias que antecederam à entrevista. por meio de computador. estabelecendo. 33. Portanto. podemos verificar que o ensino à distância é um negócio extremamente viável e com ótimas perspectivas. principalmente os que afetam diretamente os alunos e certificarse de estar oferecendo um ensino de qualidade. centro de acesso gratuito ou pago.” Fonte: IBGE. local de trabalho. o mercado de ensino à distância vêm crescendo cada vez mais e se tornando a alternativa mais procurada entre os profissionais das diversas áreas. em algum local (domicílio. principalmente os que precisam se deslocar de suas cidades por lá não haver instituições de ensino. elas precisam se projetar para oferecer esse novo tipo de serviço. A solução que melhor concilia essa necessidade dos clientes e os interesses das instituições é o ensino à distância. benefícios. surge uma evidente necessidade: os profissionais precisam muito se qualificar e melhorar seus currículos.. ao parcela da população passou a ter acesso ao computador e à Internet.9% acessaram à Internet. mas não têm tempo disponível para isso. O que fazer? Assim.gov. assim.. Os seguintes dados do IBGE mostram essa realidade: “21% da população de 10 anos ou mais de idade acessaram à Internet em 2005 Em 2005. escola. conquistando e mantendo seus espaços. Diante dessa situação. 21% da população de 10 anos ou mais de idade acessaram à Internet.br) Com base nessas informações. uma imagem de referência no mercado. Com um baixo custo operacional de implantação – não exige. saindo na frente. as instituições de ensino que desejarem ingressar nessa nova era da educação. que acabam ficando sem tempo disponível para buscarem essa tão requisitada qualificação. com a finalidade de construir a infra-estrutura necessária para realização desses novos processos de negócio. etc. o mercado vem exigindo cada vez mais tempo e dedicação dos profissionais. Porém. Na população de 15 a 17 anos de idade. o maior resultado entre as faixas etárias. deslocamento dos docentes – e o benefício aos alunos da facilidade de acesso a um ensino de qualidade.

O Inbrape e a Cultura Digital Um sistema de informação não é. o conjunto de aspectos técnicos é de fundamental importância. como alguns acreditam ser. garantindo assim a qualidade do ensino oferecido pela instituição. remanejamento de pessoal e oferta de novos serviços – possam ser feitos de forma ponderada. no entanto. ele poderá saber o que precisa melhorar e o que já está bom. organizacionais e políticos – no que se refere à decisão sobre emprego de tecnologias. para que um sistema tenha sucesso ele precisa ser socialmente aceito pela organização onde irá atuar. uma avaliação será emitida para os alunos realizarem. Ser socialmente aceito implica que a organização trabalhe com aquele sistema como parte do seu dia-a-dia criando uma cultura digital. Na realidade existe uma série de fatores sociais inerentes à implantação de tais sistemas. um sistema puramente técnico. proporcionando. fornecendo aos responsáveis da instituição relatórios e mecanismos de acompanhamento dessa avaliação. Estudos comprovam que a implantação de sistemas de informação mais complexos são mais facilmente aceitos e menos traumáticos quando implantados de forma gradual permitindo que aspectos técnicos. pois com feedback imediato da aula ministrada. um feedback imediato para a instituição a respeito do desempenho do professor e da qualidade do serviço oferecido aos seus alunos. Do lado do professor também é interessante. Ao final de cada encontro. assim. . A criação de um sistema de avaliação docente permitirá que essa cultura digital comece a ser disseminada pela instituição abrindo caminho para funcionalidades mais complexas e de maior impacto com um sistema para gerência do ensino a distancia O Sistema de Avaliação Docente O Sistema de Avaliação Docente é um sistema de informação on-line que possibilitará aos alunos da instituição avaliar seus professores de qualquer lugar e em tempo real. De fato.

No caso de uma instituição de ensino. essas informações são compostas. torna-se possível a disponibilização de serviços que automatizarão tarefas dos funcionários (como a emissão dos relatórios das avaliações docentes) e promoverão benefícios aos alunos. Uma vez que estas informações estejam devidamente estruturadas e armazenadas. consulta de notas.br). Instituição CEFET-PR PUC-PR EDUCON . professores. existem oito instituições de ensino oferecendo cursos de pós-graduação lato sensu exclusivamente à distância.Outras Funcionalidades No processo de informatização de uma organização. de acordo com dados do MEC. tais como acesso online a material didático. instituições conveniadas.PR Cursos oferecidos Em suas áreas de atuação Em suas áreas de atuação Gestão Estratégica em Direito Contemporâneo Especialização Educação em Desenvolvimento Humano e Tecnológico Especialização em Gestão Estratégica em Serviços e Sistemas de SaúdeSegmento Publico e Privado Especialização Controladoria Governança em e MBA Executivo em Gestão Empresarial UNESC-SC UNISINOS-RS CESUMAR-PR UNIANDRADE-PR Em suas áreas de atuação Em suas áreas de atuação Em suas áreas de atuação Em suas áreas de atuação fonte: MEC (http://portal. Panorama do Mercado Em virtude das vantagens oferecidas pelo ensino a distância um número cada vez maior de organizações públicas e privadas vêm aderindo a este programa. cursos. projetos pedagógicos e pela maneira como a instituição os organiza e relaciona em seus processos de negócio. Só na região sul do país. Para o Inbrape seria interessante ter um número de matrícula associado a cada aluno para que seja possível um controle exato da quantidade de alunos que a instituição possui e para que o aluno esteja vinculado à ela e não à instituição parceira. faltas e cronogramas das disciplinas. por dados de alunos (controle acadêmico). essencialmente.gov. .mec. entre outros. é necessária a identificação de quais são os elementos chaves que devem constituir sua base de informações.

br / 9941-0825 Eduardo Zanoni Marques ezmarques@hotmail.br / 9103-8839 Londrina 2006 .com.com / 9124-0104 Tiago de Oliveira Stutz tiagostutz@yahoo.com.Apêndice B – Proposta Tradicional Puerto Rico Software Intranet – Módulo 2 Departamento de Computação – UEL (Proposta de Desenvolvimento) Daniel Teleginski Camargo telecargo@yahoo.

e atender essas necessidades. através de conversas com professores. armazenando-as de forma prática e útil Promover o bem estar dos alunos Puerto Rico Software .11 de dezembro de 2006 1 – Análise de Negócio Para definição dessa proposta. tornando as informações geradas por ele mais seguras e consistentes. qual o setor do departamento que concentrava o maior volume de trabalho e que precisava de automatização e sistematização dos processos. O setor identificado foi a secretaria. foram levantados juntamente com os funcionários da secretaria quais os objetivos e necessidades imediatas da área e qual a melhor solução para se atingir esses objetivos. técnicos e secretários. A tabela abaixo enumera os objetivos e quais os sub-sistemas (módulos) a serem desenvolvidos para tornar esses objetivos mais fáceis de se alcançar: Objetivo Melhorar a divisão do trabalho Sistema Controle de monografias Disponibilização on-line dos cronogramas das aulas Controle de monografias Sistema de controle de entrega de pauta Emissão automática de comprovantes que são úteis aos docentes Controle de monografias Sistema de controle de entrega de pauta Disponibilização on-line dos cronogramas das aulas Controle de monografias Sistema de controle de entrega de pauta Automatizar e agilizar atividades rotineiras Dar mais credibilidade ainda ao departamento. Na primeira etapa desse trabalho. a equipe realizou uma análise de negócio no departamento para identificar quais as necessidades e objetivos do departamento. foi identificado. classificando-os segundo as suas respectivas prioridades. ainda que parcialmente. Definido o setor.

provendo um meio para que as informações das pautas sejam armazenadas de forma prática. buscando. alimentando informações que serão utilizadas em outras funcionalidades deste e de outros módulos do sistema.11 de dezembro de 2006 2 – Serviço proposto O serviço proposto é a implementação de dois módulos e três funcionalidades extras do sistema. O segundo relatório apresenta uma lista dos alunos do curso que estão com Puerto Rico Software . evitar que estas informações sejam lançadas tardiamente no sistema comprometendo outras funcionalidades que dependem destas informações. estes serão descritos com mais detalhes no decorrer da proposta. oferecendo um mecanismo de notificação para os docentes com atraso na entrega da pauta.1 – Módulo de Controle de Entrega de Pauta Este módulo consiste na disponibilização de um sistema de controle da entrega de pauta das disciplinas dos cursos de pós-graduação do DC (Departamento de Computação) da UEL (Universidade Estadual de Londrina). Estes módulos e funcionalidades extras serão integrados ao sistema atual de forma transparente. 2. O primeiro diz respeito ao acompanhamento da entrega das pautas por parte dos professores. As funcionalidades extras são: emissão de comprovante de participação em banca. desta forma. Os módulos em questão são: módulo de controle de entrega de pauta e módulo de controle de monografias. este módulo disponibilizará dois relatórios para tomada de decisão por parte dos secretários. Seu objetivo é aprimorar a forma como este serviço vem sendo realizado pela secretaria do Departamento de Computação. emissão de comprovante de aula ministrada e geração automática dos cronogramas das turmas. Além de prover o armazenamento destas informações.

11 de dezembro de 2006

pendências academicas. Com estas informações em mãos, a secretaria poderá notificar, através do próprio sistema, os alunos de tal irregularidade. Com isso espera-se que o aluno em estado irregular venha realizar, mais rapidamente, as medidas cabíveis para regularizar sua situação perante o curso.

2.2 – Módulo de Controle de Monografias
Este módulo compreende todas as funcionalidades necessárias para o controle das monografias dos alunos dos cursos de pós-graduação do Departamento de Computação da UEL.

Este controle terá inicio com o cadastro da monografia e com o acompanhamento dos eventos ligados a ela. A seqüência de eventos pode variar de duas formas (1) Sem a necessidade de reformulação: entrega da primeira versão (em espiral), definição da banca por parte do coordenador do curso, homologação no sistema UEL, devolução da monografia para correção e entrega da versão final (em CD). (2) Com necessidade de reformulação: entrega da primeira versão (em espiral), definição da banca por parte do coordenador do curso, homologação no sistema UEL, devolução da monografia para reformulação, entrega da versão reformulada (em espiral), devolução da monografia para correção e entrega da versão final (em CD).

Dentro desta seqüência de atividades existem relações de dependência que precisam ser mantidas. Para ajudar nesse controle o sistema oferecerá uma serie de relatórios, mecanismos de notificações e será responsável pelas emissões de protocolos e ofícios necessários que permitirão o acompanhamento da situação de cada aluno nas diversas etapas do processo possibilitando a detecção precoce de eventuais pendências e agilização dos processos de regularização, contribuindo para o fluxo normal entre uma determinada etapa e sua subseqüente.

No final do processo de entrega de monografia, o aluno entrega uma versão final de sua monografia em CD e algum funcionário do departamento fica responsável por submetê-la no sistema “nou-rau” (biblioteca digital do DC). Com o sistema, essa

Puerto Rico Software

11 de dezembro de 2006

entrega da versão final será feita de forma on-line e integrada com o sistema “nou-rau”, portanto a monografia poderá ser submetida pelo aluno de onde ele estiver e ela já ficará disponível no acervo da biblioteca digital do departamento de computação da UEL.

Funcionalidade Relatório de entrega de pauta com notificação aos docentes

Benefício Consistência da informação sobre quem entregou e quem não entregou a pauta, dando mais confiança ao processo. Facilidade na comunicação da secretária com os docentes, ajudando os professores a se lembrarem de entregar a pauta e possibilitando que a secretária faça isso mais rápida e facilmente. Cumprimento dos prazos de entrega conforme estabelecido. Agilidade no processo fazendo com que a secretária possa produzir mais. Segurança. Com a geração garantida do protocolo, reduzem-se as possibilidades de fraudes. Sistematização do processo. A geração do protocolo é padronizada, evitando confusões e/ou dúvidas por parte dos envolvidos no processo. Conforto para os alunos que não precisarão sair de suas casas para ir para a UEL só para entregar o CD com a versão final. Melhor divisão do trabalho uma vez que nenhum funcionário ficará responsável por receber os CDs e controlar quem entregou, bem como submeter a monografia no sistema “nou-rau”. Melhor utilização do sistema “nou-rau” deixando-o sempre atualizada, uma vez que não dependerá mais de nenhum

Geração automática de protocolo e ofícios

Submissão de monografia on-line e integração com o sistema “nourau”

Puerto Rico Software

11 de dezembro de 2006

funcionário para submeter as monografias que estavam em CD. Relatório de alunos com pendências acadêmicas e mecanismo de notificação aos referidos Agilidade no controle e comunicação da secretária, ganhando-se tempo que será utilizado para a realização de outras atividades. Evitar que monografias sejam enviadas para homologação havendo ainda pendências por parte do aluno causando desconforto para a secretaria. Bem-estar do aluno que poderá regularizar sua situação o mais rápido possível, dando credibilidade ao departamento que demonstra, assim, preocupação com o aluno. Melhora na divisão do trabalho, pois a secretária terá parte do seu trabalho dividido com o coordenador do curso. Facilidade e versatilidade na definição da banca. O coordenador do curso poderá fazer de qualquer lugar a definição da banca, descentralizando as tarefas da secretaria. Os professores e os alunos poderão saber quando irão ter aula sem a necessidade de ligar na secretaria, demonstrando que o departamento se preocupa em proporcionar facilidades para os alunos e para os professores. Consistência nos cronogramas. Quando um cronograma sofrer alterações, automaticamente ele será atualizado para os professores e alunos, evitando que algum aluno ou professores vá para a aula quando esta não houver. Agilidade na emissão do comprovante, uma vez que ele será feito automaticamente, disponibilizando-o para que os professores possam acrescentá-lo em seus currículos.

Definição on-line da banca avaliadora pelo coordenador do curso

Disponibilização on-line cronogramas das aulas

dos

Emissão automática de comprovante de ministração de aula e de participação em banca

Puerto Rico Software

sendo alguns destes identificados já na fase de análise de negócio e durante a utilização do sistema. a partir dos dados do sistema e disponibilizados para consulta on-line. também. emissão de comprovante de aula ministrada e geração automática dos cronogramas das turmas. O cronograma da turma será gerado.11 de dezembro de 2006 2.4 – Benefícios Gerados Com a utilização das funcionalidades citadas acima (tanto as dos módulos como as adicionais) muitos benefícios serão gerados para o departamento – em particular para a secretaria –. O comprovante de participação em banca e o comprovante de aula ministrada serão emitidos (impresso) com base nos dados do sistema respeitando o modelo estabelecido pelo cliente. 2. Os benefícios que as funcionalidades irão gerar foram identificados junto aos funcionários da secretaria e estão relacionados na tabela abaixo: Puerto Rico Software .3 – Funcionalidades Adicionais Conforme dito anteriormente as funcionalidades adicionais que serão implantadas no sistema são: emissão de comprovante de participação em banca.

11 de dezembro de 2006 Puerto Rico Software .

Elaboração. i. ocorrerá iteração sobre as seguintes diretrizes: 1. será o sugerido pelo RUP. será composto pelas fases: Iniciação. Protótipos de interface 4. Especificação dos requisitos dos módulos de maior prioridade 3. Implantação Sendo cada uma delas mais ou menos aplicadas dependendo de qual fase do ciclo de vida o desenvolvimento se encontra. 2. Testes 6. Construção e Transição.definição dos módulos e classificação de suas respectivas prioridades de desenvolvimento. Durante cada uma das fases. e. Implementação 5. Puerto Rico Software . Com relação ao ciclo de vida do desenvolvimento..11 de dezembro de 2006 3 – Metodologia de Desenvolvimento A metodologia de desenvolvimento será orientada à constante interação com os membros da organização tanto na coleta de informações como na prestação de contas com relação ao andamento do projeto. Modelagem dos processos de negócio .

Sua contribuição maior será na definição dos módulos do sistema: a partir de reuniões com membros da organização e contato com a estrutura de negócio atual será feita a modelagem desta. e tomar decisões sobre os sistemas a serem desenvolvidos. Para que essa sinergia entre a organização e a equipe desenvolvedora possa ser mantida.11 de dezembro de 2006 4 – Participação da Organização A organização terá participação fundamental no desenvolvimento do sistema. definir as prioridades. a organização indicará um ou mais funcionários que tenham autonomia para indicar as necessidades. bem como o levantamento dos requisitos do sistema. principalmente nas etapas inicias. Puerto Rico Software . os quais serão definidos com o consentimento dos representantes da organização.

11 de dezembro de 2006 5 – Recursos físicos Para a realização do projeto. a disponibilização de uma sala para acomodação da equipe e dos computadores contribuiria muito para um desenvolvimento mais harmonioso e rápido. sendo estas basicamente free software. Além dos computadores. para se instalar as ferramentas utilizadas no desenvolvimento. Puerto Rico Software . são necessários três computadores (recomendado: 512MB de RAM) ligados em rede e conectados à Internet com permissão de administrador.

11 de dezembro de 2006 6 – Documentação e Manutenção Serão gerados diagramas UML. documentações de código e documentos de auxílio aos usuários com explicações do funcionamento do sistema. A documentação será simples e objetiva de modo que seja suficiente para a compreensão do sistema e possibilite a outros desenvolvedores mantê-lo. Puerto Rico Software .

11 de dezembro de 2006 7 – Cronograma de desenvolvimento Atividade Modelagem de negócio dos módulos 1 semana Tempo Levantamento de requisitos (criação e validação 3 semanas de telas) Apresentação de protótipos Implementação Testes Implantação (treinamento) 2 semanas 4 semanas 2 semanas 2 dias Puerto Rico Software .

Daniel Documento de Usuário Teleginski Camargo preferências do usuário Desenvolvedores Arquiteto de Software Designer Dados de Banco de Eduardo Zanoni Marques Eduardo Zanoni Marques Modelo de Dados Implementador Integrador* Daniel Teleginski Camargo. Documentação de Código.11 de dezembro de 2006 8 – Informações da equipe Papéis Analistas Responsável - Artefatos - Analista do Processo de Tiago de Oliveira Stutz Negócios Analista de Sistemas Daniel Teleginski Camargo Diagrama de Atividades Diagramas de casos de uso Protótipo das telas de UI. Tiago Material de Suporte para o de Oliveira Stutz Usuário Daniel Teleginski Camargo Plano de Teste Gerentes Gerente de Projeto Tiago de Oliveira Stutz - *O Integrador também desempenhará o papel de testador. Eduardo Zanoni Marques. como sugerido pelo RUP. Puerto Rico Software . Designer de Interface de Tiago de Oliveira Stutz.

Sign up to vote on this title
UsefulNot useful