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.

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

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

disposição. aprendizado. alegria. por ter me auxiliado em muitas decisões. a Deus. sinergia e tudo mais “que enche um belo prato”. Agradeço à minha futura esposa Camila pelo amor. companheirismo. pelo apoio incondicional em todos momentos.v AGRADECIMENTOS Agradeço. sempre me oferecendo ajuda e apoio com muito amor. frustração. incentivo. Flávio de Oliveira Stutz. primeiramente. Agradeço à minha família. 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. pela motivação. A todos os funcionários. carinho e compreensão nos momentos mais turbulentos do curso. Diversão! Ao meu orientador professor Rodolfo Miranda de Barros que me mostrou possibilidades de aprendizado que me motivaram a fazer esse trabalho. Agradeço especialmente ao meu irmão. me mostrando os melhores caminhos a se seguir. nosso criador. Obrigado “fao”! Agradeço a Deus por ser seu irmão! Aos “hermanos” da Equipe Puerto Rico pelos grandes momentos de descontração. por ter me dado ânimo. força e direção para conseguir chegar até aqui com saúde. motivação. 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. paciência e dedicação. . alegria e SATISFAÇÃO. diversão. pela confiança e principalmente pelo amor.

RUP. 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. Monografia (Bacharel em Ciência da Computação) – Departamento de Ciência da Computação. Para verificar a relevância desse procedimento. RESUMO Esse estudo compreende a análise da importância da modelagem de negócios nas fases iniciais de um projeto de software. 2006. também. Universidade Estadual de Londrina. Tiago De Oliveira. modelagem de negócios. EKD. Agregando Valor ao Software Por Meio da Modelagem de Negócios. 2006. engenharia de software. será analisado. UML. Palavras-chave: desenvolvimento de software. Nesse contexto. como esse grupo de atividades interfere em todo o ciclo de vida e qual o impacto disso no valor dado ao software desenvolvido. . Londrina.vi STUTZ.

Key-words: software development. 2006. UML. RUP. State University of Londrina. 2006. EKD. . how this set of activities intervenes in all the life cycle and what’s its impact on the value given to the developed software. ABSTRACT This study understands an analysis about the importance of Business Modeling in the initial phases of a software project. software engineering. Inside this context. it will be analyzed. consolidated theoretical concepts will be studied. Monograph (Graduation in Computer Science) – Department of Computer Science.vii STUTZ. To verify the relevance of this procedure. also. 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. Londrina. Tiago De Oliveira. business modeling. Aggregating Value to the Software Through Business-Modeling.

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

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

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

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 .

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

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

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

será feita uma análise geral do que foi apresentado neste trabalho. será tratado no capítulo 2. mostrando a aplicabilidade dos conceitos e idéias propostos. Finalmente. . mas que tem valor também pelo que ele traz de custo/benefício à Organização. Já no capítulo 4. destacando os principais pontos abordados e as possibilidades futuras dentro do assunto. Chegando ao final. 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. a Modelagem de Negócios também serve como argumento nas negociações de preço. no capítulo 6. bem como qual valor ele agrega à ela e ao software de maneira geral. pois ela deixa claro para o cliente o que ele terá de retorno utilizando o software. uma abordagem prática dos conceitos teóricos estudados até então. diminuição de riscos. será mostrado no capítulo 5. 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. No capítulo 3. Depois desta introdução básica. a disciplina de Modelagem de Negócios do RUP e qual o seu papel dentro dele.15 Além dos vários benefícios no que tange ao desenvolvimento propriamente dito (levantamento de requisitos. 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". será apresentado o EKD e qual a sua relação com a Modelagem de Negócios. de conclusão. etc). definição de escopo.

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. parte de sua credibilidade se deve ao dele ser um produto de uma das gigantes da informática: a IBM. O RUP foi criado pela Rational Software em conjunto com a empresa sueca Objectory AB nos anos 90. a qual deve escolher quais os elementos desse framework irão satisfazer suas necessidades (EELES. 2.1 – O que é o RUP O Rational Unified Process é produto da IBM-Rational que descreve e suporta um processo iterativo de desenvolvimento de software. O processo de criação do RUP foi caracterizado pelo compartilhamento de experiências vividas em diversos projetos de software. . descrevendo as melhores práticas para as diversas atividades presentes no ciclo de vida deste desenvolvimento. desde que devidamente customizado. mas para projetos de todos os tamanhos. 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. HOUSTON & KOZACZYNSKI. 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. antes sua composição permite que ele seja adaptável e moldável pela equipe de desenvolvimento que o está utilizando. Sua proposta não é a de ser um produto estático com apenas uma perspectiva e não sujeito a customização. 2002).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.

é possível que se adote um método ágil utilizando o RUP. arquitetura baseada em componentes. essas práticas são: desenvolvimento iterativo. é preciso que um processo seja estabelecido. e. . assim. 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. iriam eliminar as raízes desses problemas. 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. atividades. De maneira sucinta.. HOUSTON & KOZACZYNSKI. artefatos. 2002). ele não é um produto final assim como os métodos ágeis. uso de modelos visuais. esse framework disponibiliza para você várias alternativas de customização dos processos descritos e vários modelos e artefatos que podem ser utilizados. papéis. mas um framework que contém todos os componentes envolvidos em um desenvolvimento de software. ou seja. entre outros. garantindo o sucesso no desenvolvimento do software. i. Portanto. os criadores do RUP definiram uma série de melhores práticas de software que. 2002). tudo depende da customização. se adotadas. 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. Dessa forma. É um equívoco comparar o RUP a um método de desenvolvimento. 2006). o Extreme Programming (XP) – como se eles fossem adversários que não podem ocupar o mesmo espaço. 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. fazendo. assim como Gibbs (2006) afirma. pois “o produto Rational Unified Process (RUP) é um processo de negócios genérico” (RUP. Com o RUP esse problema é resolvido. Para que uma equipe de desenvolvimento possa adotar essas melhores práticas. gerenciamento de requisitos. verificação contínua da qualidade do software e gerenciamento de mudanças (EELES. tais como: diretrizes.17 foram de sucesso.

elaboração. se necessário. 2. 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. 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. cada atividade realizada de uma forma padronizada.18 Com relação ao processo sistematizado. esse framework disponibiliza uma série de artefatos para que os desenvolvedores possam documentar. . A figura abaixo ilustra esse conceito de esforço gasto em cada uma das disciplinas em função da fase do ciclo de vida. as quais possuem seus objetivos e atividades básicas.2 – A fase de iniciação e sua importância Como foi comentado acima. além de utilizar como notação fundamental a Unified Modeling Language (UML). Com relação aos modelos. o RUP prega um ciclo de vida composto por quatro fases (iniciação. construção e transição) sendo que cada uma delas é desenvolvida através de disciplinas bem especificadas. o ciclo de vida proposto pelo RUP é dividido em 4 fases.

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. Para que essa meta seja alcançada. e. o que ocorre na maioria dos projetos é o atropelamento de fases e disciplinas. alguns objetivos são traçados e devem ser atingidos ao fim dessa fase (RUP. 2002).. ou seja. . 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. 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. i.19 Figura 1: Fases e disciplinas do RUP (2002). o que deve ou não estar no software. São eles: • Definir o escopo do projeto. Infelizmente.

HOUSTON & KOZACZYNSKI. nenhuma a mais para confundi-lo e nenhum a menos para deixá-lo na mão. a construção de algumas funcionalidades comuns ou das mais prioritárias já pode ser agilizada. Se um gerenciamento de riscos for feito da forma correta. i. Planejar arquiteturas para alguns cenários básicos. e o planejamento do cronograma poderá ser cumprido. se além de identificados. especialmente os que são comuns em vários projetos e também estão presentes neste.20 • • Desenhar os casos de uso críticos do sistema. identificar as origens de imprevistos. Isso porque quando o escopo do projeto é bem definido. Definida a arquitetura dos cenários básicos. por exemplo. Quando a equipe desenvolvedora atinge esses objetivos. 2002) já nas primeiras releases2 do ciclo de vida.. 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 . 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. a equipe desenvolvedora mostrar serviço ao cliente.e. pois a equipe sabe exatamente o que tem fazer e para quando. durante o processo de construção. Preparar o ambiente de suporte para o projeto. fazendo inclusive algumas provas de conceito1. o cliente terá exatamente as funcionalidades que precisa. o que ajuda. Quando os casos de uso críticos do sistema são atacados. • • • Estimar o custo geral e o planejamento para a próxima fase (elaboração) e para o projeto todo. os desenvolvedores se previnem de. 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. Fazer um gerenciamento de riscos em potencial. os riscos também possuem respectivas medidas de redução de impacto.

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

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

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

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

independente do tamanho.25 desconforto para ninguém. o gerente de projeto era o indivíduo que identificava as tarefas necessárias. não é diferente. O gerente de projeto é um indivíduo extremamente participativo: realiza parcerias com os membros da equipe. então a sua decisão. até como se fazer. 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. 2. pois o membro possui essa responsabilidade e se ele foi escolhido para aquele papel. A correta definição desses papéis influencia diretamente no custo do software. uma definição correta dos papéis dentro da equipe acarretará na valorização do software. 2006). natureza ou metodologia de desenvolvimento adotada. essa realidade mudou. a definição de papéis é fundamental. a seguir serão apresentados os papéis chaves dentro da Modelagem de Negócios. Dentro da Modelagem de Negócios. Conseqüentemente. tanto no que diz respeito ao sucesso no desenvolvimento deste. inicialmente. mesmo que não seja a da maioria da equipe.3. as delegava aos membros da equipe e ficava pressionando cada um para cumprir os prazos (GIBBS.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. Inicialmente. tem grandes chances de ser a melhor (POLLICE et. al. como na satisfação do cliente com a qualidade do serviço oferecido. 2004) a se tomar. definirão o que o software deverá fazer e. Hoje. estimula e . é porque ele possui o perfil necessário. principalmente pelo fato dos participantes dessas atividades deverem possuir algumas habilidades a mais do que meramente técnicas.1.

a saber: • • • • saber realizar apresentações e se comunicar bem.1. Quando um gerente se preocupa em agregar valor ao cliente. . ele passará para a equipe esse objetivo. surpreende-o positivamente. envolvendo todos os membros num processo organizado que tem como ideal promover a satisfação do cliente e agregar valor ao software. Segundo RUP (2002). 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. esse entusiasmo. 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 é o papel mais importante. Além disso. protegendo a equipe de distrações e organizando cronogramas. para desempenhar o papel Gerente de Projeto. a última merece um destaque especial. 2006). 2002) Dentre essas habilidades. deixa claro para ele qual a importância do software para a empresa.26 valoriza as soluções encontradas e conduz o andamento do projeto (GIBBS. além de valorizar a participação do cliente no desenvolvimento. ele se comunica bem com ele.3.2 – Analista de Processos de Negócio Dentro da disciplina de Modelagem de Negócios. 2. defende os interesses do time e realiza a comunicação com o cliente. o indivíduo deve possuir algumas habilidades imprescindíveis. pois é ele quem realizará as atividades que são responsáveis por atingir os objetivos da Modelagem de Negócios. como o gerente deseja cumprir o acertado com o cliente para atingir o objetivo de agregar valor ao produto oferecido. pois ela está diretamente relacionada ao objetivo desse estudo.

extraindo. 2002) 2 Um diagrama de atividade é um gráfico de fluxo.. 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. Dessa análise. É usado como base para identificar papéis e produtos liberados na organização. i. al.e. o que se pretende com a implantação do sistema.27 O analista de processos de negócio essencialmente coordena a criação de modelos de casos de uso de negócio1 (KRUCHTEN et.” (RUP. dentro da óptica deste trabalho. 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. Mas. 1 “O Modelo de Casos de Uso de Negócios é um modelo das funções pretendidas do negócio. sem contar a possibilidade de se identificar oportunidades que agregarão valor ao negócio do cliente. É responsabilidade do analista de processos de negócio definir quais serão as fronteiras e o escopo da Modelagem de Negócios (RUP. ou seja. as quais irão direcionar o esforço da Modelagem de Negócios. 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. definindo os atores. quais as partes da Organização-alvo. Ou seja. se envolverá ou não mudanças e inovações no negócio analisado. 2000) e realiza a avaliação da Organização. setores envolvidos e como eles se relacionam. serão levadas em consideração e qual o tipo de esforço será realizado na Modelagem de Negócios. 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. assim. no qual é mostrado o fluxo de controle de uma atividade para outra. . mostrando o valor do software para a Organização e a seriedade da equipe em honrar seus compromissos. 2002).

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. 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. apresentada no capítulo 3 – EKD. os trabalhadores e alguns casos e fluxos de negócios que envolvam esses trabalhadores (KRUCHTEN et.28 Existem algumas metodologias que descrevem técnicas e boas práticas para obtenção dessas informações e outras complementares. levando-se em consideração os problemas e as oportunidades existentes nos cenários avaliados. Ele define as entidades presentes na Organização que participam das relações de negócio. . Participar do levantamento de requisitos final. o membro da equipe escolhido deve: • • • Preocupar-se com o que o cliente precisa e espera do sistema. Para desempenhar esse papel.. Dentre elas está a metodologia chamada EKD. 2000). que é uma metodologia que tem como um de suas prioridades investigar de forma clara e direta quais os objetivos e metas da Organização. Preocupar-se com as necessidades dos usuários – que podem ser os próprios clientes ou clientes dos clientes. 2.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.1.3. ordenados de acordo com suas respectivas prioridades.e. al. i. portanto esse indivíduo terá tempo de levantar e de analisar as questões tranqüilamente.

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

entre outros. basta apenas que a situação de cada um seja bem entendida para que o uso do framework seja feito da maneira correta. eles quase não se encontram e. como por exemplo: cliente. Em linhas gerais. a documentação das atividades realizadas é muito importante. Porém. pois é ela que servirá como base para o planejamento da fase seguinte. não se . usuários do sistema.30 gerente de projeto. pois eles são apenas direcionamentos que devem compor a realização da Modelagem de Negócios. ou seja. é certo que o RUP possuirá as atividades e artefatos necessários para atender os diferentes estados que estes elementos possam se encontrar. juntamente com a equipe. portanto. 2003) no projeto. ao final de cada iteração é possível avaliar-se o desempenho da estratégia adotada para realização da Modelagem de Negócios. alguns elementos sempre estarão presentes neles. Por exemplo: suponha um projeto em que o gerente de projeto reside em uma cidade e o analista de negócio em outra. 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. Outro bom motivo para se ter as informações sobre os acontecimentos e experiências obtidos. Apesar dos roadmaps serem particulares a cada projeto. possa realizar a customização do RUP para a fase de elaboração. e os dias de trabalho dos dois quase nunca coincidem. Assim. 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. pois como o RUP é baseado em iterações. problemas existentes. é a possibilidade de melhoria desses processos.

O elemento “Comunicação entre os membros da equipe” apresenta a característica da comunicação não pessoal e inconstante entre alguns membros. . ele terá que seguir uma norma definida pelo gerente para que haja o entendimento entre eles. Por esse motivo. Para dar um caráter mais prático a esse estudo sobre as atividades e artefatos da Modelagem de Negócios. que tem como finalidade descrever como você deve modelar casos de uso.3 – Etapa 1: Aprovação do Projeto Um projeto de desenvolvimento de software. antes de qualquer coisa. entidades e trabalhadores de negócios. 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. o que faz com que eles não tenham termos e concepções iguais ou padronizadas em seus vocabulários e entendimentos. no documento o gerente especificaria como o analista de negócio deveria documentar as análises feitas de modo que o gerente pudesse compreender. 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. Para resolver esse problema. é uma relação comercial e como tal envolve recursos financeiros que muitas vezes são altíssimos.31 comunicam pessoalmente. sejam estes financeiros ou logísticos. Ou seja. é 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. Por outro lado. Portanto. RUP (2002) apresenta um artefato chamado “Guia de 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.3. 2. 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. ela será dividida em duas etapas: Aprovação do Projeto e Planejamento do Desenvolvimento.

2. de modo que os membros da equipe possam concentrar seus esforços nessas atividades. 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. um marco é identificado dentro da disciplina de Modelagem de Negócios: Aprovação do Projeto.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. 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.32 Portanto. O motivo de se considerar essa aprovação como um marco é o de tornar as atividades dessa disciplina sistematizadas e direcionadas. 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. durante a fase de iniciação. o cliente aceitará melhor o valor cobrado e o prazo de entrega do sistema. é 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. Dessa forma. prazos e a viabilidade do projeto (RUP. uma vez que eles poderão ter uma idéia de quais tecnologias e metodologias deverão ser utilizadas durante o projeto. Assim.3. pois se elas não forem bem executadas.3. essas informações também são úteis para os desenvolvedores poderem estimar custos. pois ele entenderá exatamente os benefícios gerados por ele e as questões a serem analisadas durante a sua construção. quais são as pessoas envolvidas nos processos relacionados a estes. 2002). Mas a importância de se coletar essas informações não é apenas a de mostrar ao cliente todos esses benefícios. é fundamental que esses indivíduos levem em consideração não só os interesses do .

aqueles que mais geram polêmica são o valor a ser cobrado pelo projeto e o tempo de duração deste. executivos. pois uma empresa pode oferecer um custo financeiro e cronológico menor que a de outra não por ser melhor executora dos projetos. 2002). 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 –. é a atividade de revisão do projeto que irá “Determinar. essa correta análise do negócio é um dos aspectos que mais tem influência na hora de se estimar os custos. os riscos são avaliados e uma análise econômica.. se vale ou não a pena investir neste projeto” (RUP. ou seja. Por esse motivo que RUP (2002) trata de forma particular um fluxo de trabalho chamado “Conceber Novo Projeto”. o projeto será formalmente configurado. Para que uma boa estimativa possa ser feita. à disponibilidade dos recursos necessários para o desenvolvimento do projeto e o qual será o custo desse projeto. é produzida.. que irão levar em conta todas as informações sobre a viabilidade econômica e tecnológica do projeto. Esta atividade consiste em uma ou mais reuniões com os responsáveis da equipe pela aprovação do projeto. o Caso de Negócio. (RUP. para poderem saber exatamente o que ele deseja. Segundo Gibbs (2006). De todos esses aspectos.]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. mas de toda a equipe. 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. mas por não ter entendido corretamente a dimensão e os objetivos do projeto. 2002) Dentro desse fluxo de trabalho. analistas de negócio. tanto em valores absolutos como em termos de retorno sobre investimento (ROI). a qual tem o seguinte objetivo de acordo com o autor: [. Se a Revisão da Aprovação do Projeto julgá-los satisfatórios. Com base na Visão inicial. do ponto de vista do negócio. gerentes.33 cliente. o que acarreta em . etc.

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

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

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

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

já que esse plano é um artefato composto basicamente pelas informações citadas acima. que é um artefato dentro do RUP. ou seja. ele estabelecerá um conjunto de passos e diretrizes que terá o objetivo de “organizar as atividades”.38 Uma vez reunidas todas essas informações. 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á é possível construir-se um Plano de Desenvolvimento de Software. 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.

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

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. . na qual o EKD será utilizado como uma das ferramentas na Modelagem de Negócios. ela foi escolhida para a construção da metodologia sugerida nesse trabalho.

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

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

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

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

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. gerar novas alternativas para viabilização do alcance dos objetivos.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. que podem impedir a Organização de atingir estes objetivos. O Modelo de Regras de Negócio também será extremamente útil para a fase de especificação de requisitos. Por outro lado os objetivos podem também ser facilmente alcançados através das oportunidades. ou seja. 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. uma regra não deve relacionar um objetivo ou situação que não esteja presente ou subentendido no Modelo de Objetivos.45 Alguns objetivos estão sujeitos a problemas. portanto. Para guiar esta atividade de modelagem de objetivos. assim. 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.2. devem ter suas causas documentadas para que a equipe possa buscar soluções ou preparar planos de contingência. . 2006). e. as quais devem ser anotadas pela equipe para que possam ser exploradas e.

como Pádua (2004) diz. Para exemplificar essa característica.2. Como se pode ver.46 Para melhor entender essa situação. mas o que seria uma “operação de crédito”? Seria empréstimo? Financiamento? Para que o objetivo seja corretamente compreendido. i. tragam realmente melhorias e não problemas ao negócio. Durante a especificação de requisitos é especificado que o sistema deve possuir uma funcionalidade de entrega on-line de monografia. ou seja. incluindo a implantação de um SI. é necessário que os conceitos citados sejam esclarecidos. 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. 3.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. 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”. este modelo funciona como uma espécie de “dicionário” para os outros modelos. as regras de negócio devem ser devidamente especificadas para que as eventuais mudanças realizadas na Organização. Nessa situação. os alunos entrarão no sistema e carregarão nele o arquivo com sua monografia.. É aí que entra o modelo estudado nesse tópico. .e. que no caso do exemplo. pois é nele que serão explicados esses conceitos. o objetivo está declarado. suponha que no Modelo de Objetivos você tenha o seguinte objetivo: “Automatizar operações de crédito”. explicaria o que é uma operação de crédito.

PERSSON & STIRNA 2001) para saber se ele é realmente necessário e • ele. é 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.47 Portanto. para se realizar a modelagem conceitual.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. que é composto por todos os modelos. Analisar a participação e quantidade de relacionamentos do conceito para decidir qual nível de detalhamento é necessário dar a Dessa forma. fazendo com que o modelo global. verificar a importância dele na aplicação (BUBENKO. 3. bem como o fluxo de informações que circula nessas atividades e processos.2. 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. . Antes de incluir um conceito. A título de comparação. bem como seus atributos e relacionamentos. Fazer um levantamento inicial dos conceitos envolvidos na aplicação. 2004). 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. Para isso. possa ser completo e consistente.

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

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

. 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. quais processos necessitam ser detalhados ou não. 3. os processos modelados certamente estarão fazendo uso de informações descritas por componentes do Modelo de Conceitos (terceiro modelo). pois assim. e que conseqüentemente geraram os conceitos definidos no terceiro modelo. i. sendo sempre verificados a presença dos conceitos e atores envolvidos nos seus respectivos modelos.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.e. Lembrando que o indivíduo que estiver realizando a modelagem deve julgar. sempre observando a dinâmica da Organização. os processos e atividades a serem modelados deverão ser escolhidos de acordo com sua relação aos objetivos e regras do negócio. um ator poder ser responsável por uma determinada atividade ou pode buscar um particular objetivo (PÁDUA. 2004).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. Dessa forma. para que os responsáveis pela realização dessa tarefa já possam ter uma orientação do que considerar no momento . Dentro da Organização.2. é interessante se estabelecer uma classificação dos tipos de atores e recursos possíveis.

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

.. é aquele que está diretamente relacionado à construção de um sistema de informação (PÁDUA. regras e objetivos descritos nos outros modelos.6 – Modelo de Requisitos e Componentes Técnicos Como citado no início desse capítulo 3. Compreendido os componentes do modelo. 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.52 intimamente ligada aos processos de negócios no que se refere à dependência causada por uma operação dentro de um processo. Assim. as soluções encontradas para os problemas identificados poderão ter um melhor direcionamento para os responsáveis. unidades organizacionais e recursos dentro da Organização que estão ligadas a todos processos. a partir daqui. 3. fazendo com que os esforços sejam despendidos somente pelas pessoas que realmente estão envolvidas nas questões levantadas.e. i. 2004): o Modelo de Requisitos e Componentes Técnicos. e está diretamente ligada às regras de negócio no que diz respeito à dependência causada pela necessidade de autorização. o último de seus modelos. ele é uma metodologia que têm sim como um dos seus objetivos. o qual não é utilizado em situações nas quais não há o desenvolvimento de um software. 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. o método EKD não está necessariamente envolvido ao desenvolvimento de um sistema de informação.2..e. Porém. Assim. gerar informações que sejam úteis ao desenvolvimento de um sistema desse. i. 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. 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.

ou seja. Um fato que direciona melhor esse trabalho de organizar as informações é o modo como o modelo é composto. processos. esse componente expressa uma série de objetivos de alto nível do sistema de informaçã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. . Os requisitos são divididos em dois tipos: Requisitos Funcionais: São funcionalidades especificadas para a execução de ações completas pelo sistema. podem fazer referencia a componentes do Modelo de Atores e Recursos e do Modelo de conceitos. • • Problemas do Sistema de Informação: São riscos que podem se tornar empecilhos ao alcance dos objetivos do SI. levando-se em consideração todos os componentes do sistema. expressam o comportamento 1 Um risco é tudo que possa impedir o sucesso do projeto e que atualmente é desconhecido ou incerto (RUP.53 De acordo com Pádua (2004). 2002). Requisitos do Sistema de Informação: são condições ou estados expressados pelas propriedades do sistema que devem ser modeladas. Em síntese. PERSSON & STIRNA 2001). 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. regras e atores da Organização. de forma que o sistema a ser desenvolvido esteja coerente com as informações levantadas nesses outros modelos. Os requisitos sempre referenciam componentes do Modelo de Processos de Negócio. o objetivo desse modelo é direcionar a parte técnica do desenvolvimento para os objetivos.

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

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

Possivelmente. 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. Entender a estrutura e a dinâmica da Organização na qual um sistema deve ser implantado (a Organização-alvo). 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. a equipe. Portanto.56 plena sintonia para que as próximas reuniões e atividades realizadas pela equipe de modelagem possam ser devidamente planejadas e executadas. nota-se que essa fase inicial do EKD está diretamente ligada a 2 dos 4 objetivos da modelagem de negócios. • • • • 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. Continuando esse processo de aplicação do EKD. atingir todos os objetivos da Modelagem de Negócios. assim. Claramente. PERSSON & STIRNA 2001) e. apenas uma segunda reunião não seja suficiente para se estabelecer todos os modelos (BUBENKO. será avaliado se os refinamentos dos modelos já . Ao final dessas reuniões. após realização da primeira reunião. usuários e desenvolvedores tenham um entendimento comum da Organização-alvo. a saber: • • Assegurar que os clientes. é bem provável que mais uma ou duas reuniões sejam úteis para que os modelos todos estejam bem definidos e coerentes.

Portanto. 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. 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.57 alcançaram seus estágios finais ou se necessitaram de mais ajustes. inclusive o Modelo de Requisitos e Componentes Técnicos. mostrando como essa metodologia atende e inclusive supera os objetivos propostos. o que levaria ao agendamento de outras reuniões. essa etapa final do EKD só terminará quando todos os modelos estiverem satisfatoriamente completados. Derivar os requisitos de sistema necessários para sustentar a Organização-alvo. Dessa forma. quando essas reuniões não forem mais necessárias. sendo que dentre eles. significará que os objetivos dessas atividades foram alcançados. Assim. . fornecendo informações necessárias aos profissionais que irão trabalhar nas outras fases do desenvolvimento.

é fundamental que o projeto tenha uma boa documentação para que a equipe tenha registros das fases de desenvolvimento do software. O estudo dessa seção está dividido em duas partes: notações e artefatos. Na seção relativa à notação.58 4 – Artefatos e Notações Neste capítulo. 2006). 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. serão apresentados os elementos utilizados na . Mas para que essa eficiência seja alcançada. querem utilizar o sistema que está sendo desenvolvido para poderem se certificar de que o projeto está correndo como previsto. afinal. até porque muitos deles nem participarão de todas elas. Portanto. em especial na Modelagem de Negócios. a documentação direcionada para os desenvolvedores é geralmente melhor utilizada. esta seção trata da parte relacionada à documentação do software que é necessária durante a fase de iniciação. antes. o que os clientes querem ver são os resultados. Apesar da Modelagem de Negócios tratar de aspectos presentes tanto no lado do desenvolvedor quanto no do cliente. 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. Dessa forma. 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. 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. 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. 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.

por exemplo. Isso faz com que. Em particular. a partir do zero. 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. essa linguagem unificada é composta por uma coleção de símbolos que podem ser divididos em 3 blocos: coisas. possam ser modelados visualmente. 2006). Uma notação é uma forma de representação de algo através da utilização de um sistema especial de marcas e caracteres (Wordnet. 1999) que combinados fazem com que todas as etapas e aspectos do desenvolvimento. via de regra. com o objetivo de facilitar a construção e compreensão dos modelos criados durante determinadas atividades. Apesar dos elementos também serem considerados artefatos. o analista de negócio possa .59 construção dos artefatos propostos para a Modelagem de Negócios. 4. Por muito tempo várias empresas adotaram determinada notação nas documentações feitas em todos os seus setores. eles serão estudados na seção de notação. inclusive no de Tecnologia da Informação (TI). 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). nessa área da informática.1 – Notações A escolha de uma notação é fundamental para que a documentação fique padronizada. um determinado contexto. intuitiva e não-ambígua. 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. Ao invés de se criar uma notação toda nova. evitando que haja as catastróficas falhas de comunicação entre os membros da equipe e com o cliente. Lançada a primeira versão estável em 1991 pela Object Management Group (OMG). relacionamentos e diagramas (DEWALT.

E no caso da Modelagem de Negócios. Dessa forma. al.. 2001). o objetivo será apresentar aqueles componentes da UML que estão relacionados à Modelagem de Negócios. não existe somente uma maneira de utilizar a UML para modelar o que se deseja (ERIKSSON et.1. nesta seção. possibilitando que todos os envolvidos no desenvolvimento falem a mesma língua e com isso seja aumentada e melhorada a produtividade. O que se deve ter em mente é que todas as informações coletadas devem estar disponíveis de uma forma clara. de uma forma que todos entendam se precisar fazer muito esforço. ou seja. 4. 2000). é produzir uma série de modelos que servirão como planos para condução dos negócios. por exemplo. pois além de ser o padrão adotado mundialmente. pois ela dá suporte a todas as atividades propostas por ele. i..e. obviamente. Afinal de contas. 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. ela é a utilizada dentro do RUP. entre outras possibilidades (ERIKSSON et. para a negociação de uma proposta. sejam estes usados para priorização dos objetivos. 2000).. a UML não deve ser encarada como um produto final não-configurável. Apesar de existirem diversas notações. simples e não ambígua.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. o objetivo da Modelagem de Negócios.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. É por isso que a utilização da . Assim como acontece com o RUP. al. será apresentada apenas a UML.

pois como ela é a notação padrão. al. 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. mas a documentação inteligente. • Ator de Negócio: São os usuários no ponto de vista do negócio. 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.e. direcionada1 e objetiva produzirá resultados melhores em menos tempo e com menos trabalho. sendo que uma documentação mais enxuta. entre outros (KRUCHTEN et. Note que não está sendo defendida aqui a falta de documentação. é bom que se tenha por onde começar para depois partir para a customização. 2000). clientes.61 UML já é um primeiro passo. pois apesar deles serem escolhidos conforme a necessidade de cada projeto. . serão apresentados a seguir alguns componentes e diagramas da UML que são comumente utilizados na Modelagem de Negócios. é 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. vendedores. 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. aquela máxima que diz: “menos é mais”. 2006). 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. i. parceiros. Diante disso. Figura 5: Exemplo de Ator de Negócio (RUP.. uma vez que terão que “aprender” sobre a documentação.

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

Figura 10: Exemplo de uma Atividade (RUP. . Figura 8: Exemplo de Caso de Uso de Negócio (RUP. 2002) • Estado inicial: Indica o ponto de partida do modelo (ANQUETIL.63 resultado de valor observável1 a um determinado ator de negócios (RUP. 2002) 1 Pode ser percebido e medido (RUP. 2002). marca a entrada de um processo. 2006). 2002). 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 9: Estado Inicial (RUP.

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

deixados de lado. os quais são descritos no RUP. . aqueles que forem julgados importantes devem ser incluídos no projeto e os que não forem. pois cada um tem sua finalidade e.2 – Artefatos Dentro da disciplina da Modelagem de Negócios. mas quando eles atingem certo grau de maturidade.65 Figura 14: Exemplo de Raias (RUP. portanto. 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. 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. de até 7 desenvolvedores. ou seja. não é necessário que todos os artefatos apresentados nesse framework sejam produzidos. e na Figura 18. levando-se em consideração que o projeto está sendo desenvolvido por equipes pequenas. as quais ilustram dois diagramas onde esses elementos são utilizados 4. o que deve ser avaliado é a importância e necessidade deles para o projeto. uma fase ou etapa de software não é encerrada quando os artefatos iniciados naquela fase são terminados. 2002) Exemplos de utilização desses componentes podem ser encontrados na Figura 16. Porém. página 71. vários artefatos podem ser produzidos. página 74.

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

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

na qual você incluiria um panorama geral da Organização. Esse formato é proposto por Pollice et. quais as suas metas. al (2004) que ainda sugere que esse documento seja elaborado em formato de panfleto.2 – Visão do Negócio Esse documento contém informações sobre a estrutura da Organização-alvo. quais os objetivos da Organização de modo geral e quais os relacionados ao sistema. 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.2. é interessante também já se colocar nesse documento algumas estimativas de quais metodologias serão utilizadas. enfatizando qual a participação do cliente nele. 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. quais melhorias nos processos o sistema construído irá acarretar. 4. 2002). entre outros (RUP. entre outros. Uma forma interessante de se produzir esse documento é elaborá-lo como se fosse a proposta para o cliente. 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. 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 serão os custos de tempo e dinheiro necessários. quais setores dela serão afetados pela implantação do projeto. é notável que um glossário é indispensável para a etapa de aprovação do projeto. como o projeto será organizado. sobre o sistema proposto e qual o papel desse sistema dentro da organização.68 Dessa forma.1. para que ele seja mais atrativo ainda ao cliente. Adotando-se o formato de proposta. .

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).

2. conforme são identificadas características no processo de negócio que justifique as alterações no modelo. 2002) 4. 2001). Portanto.2.2 – Diagrama de Atividades Depois de levantados os casos de uso de negócio. elas devem ser feitas. O diagrama de atividades é o principal diagrama da UML utilizado para representar os processos de negócio que ocorrem dentro da Organização-alvo. 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. é interessante que esses caso de uso sejam analisados mais detalhadamente. Figura 17: Exemplo de caso de uso de negócio (RUP.72 outros modelos. Porém como o desenvolvimento é iterativo. um diagrama de atividades descreve um fluxo de trabalho e explora a ordem . como os diagramas de atividades.

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

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

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

são definidos esses trabalhadores como “trabalhadores de negócio” e os recursos como “entidades de negócio”.e. sendo que essas classes estão dividas em 2 categorias: trabalhadores de negócio e entidades de negócio. Em seguida. o que caracteriza este modelo como sendo de transição entre a Modelagem de Negócio e o início do desenvolvimento (RUP. o objetivo é fazer uma reformulação no negócio da Organização. primeiramente são identificados os trabalhadores da organização e os recursos que eles utilizam nos processos de negócio. 2002). esse modelo permite que existam entre os elementos as relações como herança.. são construídos os relacionamentos entre esses trabalhadores. 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. as entidades e as relações entre eles. os trabalhadores. que consiste em capturar as classes de entidades mais importantes do domínio e como elas se relacionam entre si.76 Quando vamos realizar a modelagem dos objetos de negócio. 2002). portanto. 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”. enquanto diagrama de classe. • não criar nenhum modelo haja vista que todos integrantes da equipe já conhecem bem o domínio do negócio. Depois. é 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. • criar um modelo com foco na reengenharia de negócios: neste caso. i. entre as entidades e entre os . os quais foram descritos na seção anterior. Para se construir este modelo. Assim. agregação e associação de modo geral.

A figura abaixo é um exemplo de um diagrama de atividades com fluxo de objetos. é interessante se criar um diagrama de atividades alternativo que contém as transições entre. Além disso. Estas transições entre os objetos são chamadas de “fluxo de objetos” (RUP. . A figura abaixo ilustra esse modelo. 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. os objetos marcados com seus respectivos estados atuais. Em baixo do nome dos objetos é colocado entre colchetes qual o estado atual do objeto. 2002).77 trabalhadores e as entidades. Figura 20: Modelo de objetos de negócio ilustrando um caso de uso de negócio de Check-in Individual (RUP. além das atividades. são utilizadas as raias para representar os trabalhadores de negócio e as entidades para representar os objetos.

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. mas resolver os . 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. pois ao mesmo tempo em que a equipe terá uma parte do trabalho já feita. Esse tipo de abordagem proporciona à equipe um ganho de tempo e qualidade na modelagem tecnológica do sistema.

principalmente. i. depois de terminada a construção do modelo. Ao final da construção do modelo. .e. três verificações devem ser feitas: • • • Todas as atividades descritas nos casos de uso de negócio estão sendo representadas pelos objetos. Assim. 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. 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. o modelo terá grandes chances de estar correto e. em conjuntos. de ter alguma utilidade para os desenvolvedores do sistema na etapa seguinte do processo. é preciso saber o que se quer e se isso foi conseguido.79 problemas existentes na Organização-alvo e propor novas possibilidades que irão dar ao cliente vantagens competitivas no mercado.. é importante que se tenha garantia de um bom trabalho.

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

na maioria das vezes. independente da existência de um sistema de informação. i. como o software irá fazer com que os objetivos sejam mais facilmente alcançados.81 As metodologias.. e mais concretamente dentro da elaboração da proposta de desenvolvimento de software. Porém.1. se mostram mais simples na teoria do que na prática e com o EKD não é diferente. bem como o software irá resolvê-los. elas utilizam recursos da metodologia para resolver problemas que elas não têm na verdade. a proposta deve especificar da melhor forma possível os objetivos da Organização que o software irá contribuir para atingir. 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. . 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.e. é mostrar quais objetivos da Organização a serem atingidos (BUBENKO. i. portanto. e novas oportunidades.. a finalidade do Modelo de Objetivos dentro da Modelagem de Negócios. Afinal. alguns problemas para atingir esses objetivos. essa dificuldade vem do fato das pessoas que aplicam as metodologias não as adaptarem às suas reais necessidades. 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. PERSSON & STIRNA 2001). e. 5.1 – Modelo de Objetivos Como estudado no tópico referente. metas e resultados. o Modelo de Objetivos dentro do EKD descreve objetivos da Organização. Nesta seção será apresentado qual o papel do EKD dentro do desenvolvimento. deve-se ter em mente que uma Organização é movida por objetivos. Portanto.

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. B e C. Na elaboração da proposta. Para o objetivo Y os módulos são B. 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 2: Relação entre objetivos da Organização e os problemas em se alcançá-los . que estarão relacionados ao sistema como um todo e depois refinar (PÁDUA. 2. Portanto. 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. para guiar a construção desse modelo e inseri-lo na proposta de software. é fundamental que esses objetivos estejam claramente especificados. Ou seja. relacionando-os às funcionalidades (módulos) que compõe o sistema. deve-se responder às seguintes perguntas com as respectivas respostas: 1. D e F. cada módulo do sistema terá seus objetivos. 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. 2004) cada um dos objetivos em sub-objetivos. sendo que cada objetivo pode estar relacionado a mais de um módulo ao mesmo tempo.82 Na construção do Modelo de Objetivos.

83 3. 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 . 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. 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. tornando as informações geradas por ele mais seguras e consistentes. foramse identificados por meio de conversa com funcionários quais os objetivos da empresa.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.

é 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. Cronogramas não atualizados e inconsistentes às vezes fazem os alunos irem a aula em dias que não há aula. Tabela 3: Relação entre objetivos da Organização e oportunidades de se alcançá-los 5. Portanto. email ou pessoalmente. portanto é possível que ela seja entregue via Internet. . já são entregues em formato eletrônico. 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. sem a necessidade de intermediação de técnicos e secretários para tal trabalho.1.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.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. ou criar a expectativa de se ter aula com um professor e na verdade ter com outro. ou seja.

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

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

i.4 – Modelo de Processos de Negócios O Modelo de Processos de Negócios é geralmente representado pelos diagramas de atividades.1. esse modelo é fundamental.87 Essa estratégia sugerida aqui é interessante. 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. o que serve como uma espécie de norte para que a equipe avalie se o sistema implementado está realizando o processo todo. 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. pois ele diz quais são as entradas e saídas dos processos. Esse modelo não será utilizado diretamente na elaboração da proposta. Exemplo: Processo de entrega de monografia . 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.e. pois ele não acrescentará muita informação ao cliente. recebendo a entrada desejada e gerando a saída esperada.. Para a equipe de desenvolvimento. 5. os quais descrevem o fluxo de atividades que ocorrem em cada um desses processos que acontecem dentro da empresa.

Dentre suas várias utilidades.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.88 Entrada: Primeira versão da monografia Saída: Protocolo de entrega de monografia 5. .1. 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.

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

Portanto. 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. evitando que algum aluno ou professores vá para a aula quando não houver. Consistência nos cronogramas. automaticamente ele será atualizado para os professores e alunos. 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 .2 – Planejando e Adiantando o Próximo Passo Apesar das diversas utilidades da Modelagem de Negócios. Uma sugestão clara e direta dada por Heumann (2001). Quando um cronograma sofrer alterações. demonstrando que o departamento se preocupa em proporcionar facilidades para os alunos e para os professores. Cumprimento dos prazos de entrega conforme estabelecido. Tabela 4: Relação dos requisitos com os benefícios gerados 5. tais como os utilizados na etapa de análise.90 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. o seu objetivo principal é auxiliar a construção de um sistema de informação.

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

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

3. 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. 2000) . em casos de uso do sistema. 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.93 1.

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

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

99 .

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

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

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

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

.

com.br / 9941-0825 Eduardo Zanoni Marques ezmarques@hotmail.br / 9103-8839 Daniel Teleginski Camargo telecargo@yahoo.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.com / 9124-0104 .

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

garantindo assim a qualidade do ensino oferecido pela instituição. Do lado do professor também é interessante. um feedback imediato para a instituição a respeito do desempenho do professor e da qualidade do serviço oferecido aos seus alunos. remanejamento de pessoal e oferta de novos serviços – possam ser feitos de forma ponderada. para que um sistema tenha sucesso ele precisa ser socialmente aceito pela organização onde irá atuar. assim. De fato. Na realidade existe uma série de fatores sociais inerentes à implantação de tais sistemas. pois com feedback imediato da aula ministrada. organizacionais e políticos – no que se refere à decisão sobre emprego de tecnologias. proporcionando. fornecendo aos responsáveis da instituição relatórios e mecanismos de acompanhamento dessa avaliação. um sistema puramente técnico. ele poderá saber o que precisa melhorar e o que já está bom. 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. . como alguns acreditam ser. Ser socialmente aceito implica que a organização trabalhe com aquele sistema como parte do seu dia-a-dia criando uma cultura digital. uma avaliação será emitida para os alunos realizarem.O Inbrape e a Cultura Digital Um sistema de informação não é. Ao final de cada encontro. 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. no entanto. o conjunto de aspectos técnicos é de fundamental importância.

cursos. consulta de notas. por dados de alunos (controle acadêmico). professores. instituições conveniadas. No caso de uma instituição de ensino. 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. entre outros. . essas informações são compostas. existem oito instituições de ensino oferecendo cursos de pós-graduação lato sensu exclusivamente à distância. de acordo com dados do MEC. Instituição CEFET-PR PUC-PR EDUCON . tais como acesso online a material didático.mec. 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.Outras Funcionalidades No processo de informatização de uma organização. 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.gov. essencialmente.br). é necessária a identificação de quais são os elementos chaves que devem constituir sua base de informações. Uma vez que estas informações estejam devidamente estruturadas e armazenadas.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. Só na região sul do país. faltas e cronogramas das disciplinas. projetos pedagógicos e pela maneira como a instituição os organiza e relaciona em seus processos de negócio.

com.com / 9124-0104 Tiago de Oliveira Stutz tiagostutz@yahoo.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.com.br / 9941-0825 Eduardo Zanoni Marques ezmarques@hotmail.br / 9103-8839 Londrina 2006 .

qual o setor do departamento que concentrava o maior volume de trabalho e que precisava de automatização e sistematização dos processos. foi identificado. 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. a equipe realizou uma análise de negócio no departamento para identificar quais as necessidades e objetivos do departamento. 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. através de conversas com professores. técnicos e secretários. ainda que parcialmente. armazenando-as de forma prática e útil Promover o bem estar dos alunos Puerto Rico Software . tornando as informações geradas por ele mais seguras e consistentes. classificando-os segundo as suas respectivas prioridades. O setor identificado foi a secretaria. Na primeira etapa desse trabalho.11 de dezembro de 2006 1 – Análise de Negócio Para definição dessa proposta. Definido o setor. e atender essas necessidades.

buscando.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). Além de prover o armazenamento destas informações. evitar que estas informações sejam lançadas tardiamente no sistema comprometendo outras funcionalidades que dependem destas informações. emissão de comprovante de aula ministrada e geração automática dos cronogramas das turmas. estes serão descritos com mais detalhes no decorrer da proposta. 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. 2. Estes módulos e funcionalidades extras serão integrados ao sistema atual de forma transparente.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. 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. O segundo relatório apresenta uma lista dos alunos do curso que estão com Puerto Rico Software . provendo um meio para que as informações das pautas sejam armazenadas de forma prática. oferecendo um mecanismo de notificação para os docentes com atraso na entrega da pauta. alimentando informações que serão utilizadas em outras funcionalidades deste e de outros módulos do sistema. O primeiro diz respeito ao acompanhamento da entrega das pautas por parte dos professores.

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

a partir dos dados do sistema e disponibilizados para consulta on-line. emissão de comprovante de aula ministrada e geração automática dos cronogramas das turmas. 2. sendo alguns destes identificados já na fase de análise de negócio e durante a utilização do sistema. 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 . 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.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. também. 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 –.

11 de dezembro de 2006 Puerto Rico Software .

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. Implementação 5. 2. Puerto Rico Software . será composto pelas fases: Iniciação. será o sugerido pelo RUP.definição dos módulos e classificação de suas respectivas prioridades de desenvolvimento. Elaboração. Modelagem dos processos de negócio .. i. Testes 6. Construção e Transição. Durante cada uma das fases. Com relação ao ciclo de vida do desenvolvimento. e. ocorrerá iteração sobre as seguintes diretrizes: 1. Protótipos de interface 4. Implantação Sendo cada uma delas mais ou menos aplicadas dependendo de qual fase do ciclo de vida o desenvolvimento se encontra. Especificação dos requisitos dos módulos de maior prioridade 3.

definir as prioridades. 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. a organização indicará um ou mais funcionários que tenham autonomia para indicar as necessidades. 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. 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. Puerto Rico Software . Além dos computadores. para se instalar as ferramentas utilizadas no desenvolvimento. são necessários três computadores (recomendado: 512MB de RAM) ligados em rede e conectados à Internet com permissão de administrador.

documentações de código e documentos de auxílio aos usuários com explicações do funcionamento do sistema. Puerto Rico Software . 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.11 de dezembro de 2006 6 – Documentação e Manutenção Serão gerados diagramas UML.

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 .

Puerto Rico Software . como sugerido pelo RUP. 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. Designer de Interface de Tiago de Oliveira Stutz. Documentação de Código. 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.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.

Sign up to vote on this title
UsefulNot useful