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 .

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

me mostrando os melhores caminhos a se seguir. 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 à minha família. 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. pela motivação. . aprendizado. por ter me auxiliado em muitas decisões. primeiramente. a Deus. disposição. força e direção para conseguir chegar até aqui com saúde. companheirismo. frustração. alegria. Flávio de Oliveira Stutz. A todos os funcionários. incentivo. pela confiança e principalmente pelo amor. diversão. sinergia e tudo mais “que enche um belo prato”. pelo apoio incondicional em todos momentos. Obrigado “fao”! Agradeço a Deus por ser seu irmão! Aos “hermanos” da Equipe Puerto Rico pelos grandes momentos de descontração. sempre me oferecendo ajuda e apoio com muito amor. técnicos e secretárias do departamento de computação pelo empenho e dedicação para fazer do curso de Ciência da Computação da UEL um dos melhores do país. Agradeço especialmente ao meu irmão.v AGRADECIMENTOS Agradeço. Agradeço à minha futura esposa Camila pelo amor. por ter me dado ânimo. nosso criador.

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

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

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

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

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

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 .

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

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

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

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

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

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

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

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. ou seja. e. 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.. 2002). alguns objetivos são traçados e devem ser atingidos ao fim dessa fase (RUP. o que deve ou não estar no software. São eles: • Definir o escopo do projeto. Infelizmente. Para que essa meta seja alcançada. i. . a fase de iniciação muitas vezes é misturada com a de elaboração e a Modelagem de Negócios não é realizada. o que ocorre na maioria dos projetos é o atropelamento de fases e disciplinas.19 Figura 1: Fases e disciplinas do RUP (2002). passando-se direto para o levantamento de requisitos.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. ela foi escolhida para a construção da metodologia sugerida nesse trabalho.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.

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

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

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

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

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

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

bem como o fluxo de informações que circula nessas atividades e processos. 2004). obtendo um modelo que procure se aproximar o máximo possível do mundo real. Para isso. . 3. Incluir no modelo somente os relacionamentos que sejam significativos para o cenário em questão. Fazer um levantamento inicial dos conceitos envolvidos na aplicação. para se realizar a modelagem conceitual. que é composto por todos os modelos.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. bem como seus atributos e relacionamentos.47 Portanto. fazendo com que o modelo global. possa ser completo e consistente. pode-se dizer que esse modelo é muito parecido com os tão conhecidos modelos de fluxos de dados (PÁDUA. PERSSON & STIRNA 2001) para saber se ele é realmente necessário e • ele.2. A título de comparação. Analisar a participação e quantidade de relacionamentos do conceito para decidir qual nível de detalhamento é necessário dar a Dessa forma. verificar a importância dele na aplicação (BUBENKO. é 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. 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. deve-se fazer um levantamento das entidades presentes no domínio.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Esse tipo de abordagem proporciona à equipe um ganho de tempo e qualidade na modelagem tecnológica do sistema. mas resolver os . afinal o objetivo real não simplesmente implementar um software. pois ao mesmo tempo em que a equipe terá uma parte do trabalho já feita. pois ele foi construído com foco no negócio do cliente e não foco no sistema de informação. 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.

é 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. três verificações devem ser feitas: • • • Todas as atividades descritas nos casos de uso de negócio estão sendo representadas pelos objetos. de ter alguma utilidade para os desenvolvedores do sistema na etapa seguinte do processo. 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. é importante que se tenha garantia de um bom trabalho. i. Assim. em conjuntos. o modelo terá grandes chances de estar correto e..e. depois de terminada a construção do modelo. . principalmente. Ao final da construção do modelo.

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

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

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

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. 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 . Durante a análise de negócio de uma determinada Organização. 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. foramse identificados por meio de conversa com funcionários quais os objetivos da empresa. 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. tornando as informações geradas por ele mais seguras e consistentes.83 3.

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

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

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

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

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.5 – Modelo de Atores e Recursos O Modelo de Atores e Recursos descreve alguns trabalhadores e clientes da empresa bem como os recursos que eles utilizam para realizar as suas atividades. Dentre suas várias utilidades. .

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

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

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

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

93 1. no caso o caso de uso de negócio de transação financeira. 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.3. em casos de uso do sistema. 2000) . al. Figura 24: Mapeamento do modelo de negócio para o de sistema (KRUCHTEN et.

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

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

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

99 .

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

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

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

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

.

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

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

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

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

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

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

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. O cronograma da turma será gerado. 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. sendo alguns destes identificados já na fase de análise de negócio e durante a utilização do sistema. também.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 –. emissão de comprovante de aula ministrada e geração automática dos cronogramas das turmas. 2.11 de dezembro de 2006 2. Os benefícios que as funcionalidades irão gerar foram identificados junto aos funcionários da secretaria e estão relacionados na tabela abaixo: Puerto Rico Software .

11 de dezembro de 2006 Puerto Rico Software .

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

e tomar decisões sobre os sistemas a serem desenvolvidos. os quais serão definidos com o consentimento dos representantes da organização. Para que essa sinergia entre a organização e a equipe desenvolvedora possa ser mantida. bem como o levantamento dos requisitos do sistema.11 de dezembro de 2006 4 – Participação da Organização A organização terá participação fundamental no desenvolvimento do sistema. definir as prioridades. 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. principalmente nas etapas inicias. Puerto Rico Software . a organização indicará um ou mais funcionários que tenham autonomia para indicar as necessidades.

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

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. documentações de código e documentos de auxílio aos usuários com explicações do funcionamento do sistema. Puerto Rico Software .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 .

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. 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. 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. Puerto Rico Software . Designer de Interface de Tiago de Oliveira Stutz. Eduardo Zanoni Marques.