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

TIAGO DE OLIVEIRA STUTZ

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

Londrina 2006

TIAGO DE OLIVEIRA STUTZ

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

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

2006

ii

TIAGO DE OLIVEIRA STUTZ

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

COMISSÃO EXAMINADORA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A figura abaixo ilustra esse conceito de esforço gasto em cada uma das disciplinas em função da fase do ciclo de vida. Essas atividades estão diretamente ligadas às disciplinas que devem ser praticadas em cada uma das fases. sendo que a importância e tempo gasto em cada uma das disciplinas variam de acordo com a fase em que o desenvolvimento se encontra. o RUP prega um ciclo de vida composto por quatro fases (iniciação. construção e transição) sendo que cada uma delas é desenvolvida através de disciplinas bem especificadas. elaboração. Com relação aos modelos. 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. o ciclo de vida proposto pelo RUP é dividido em 4 fases. cada atividade realizada de uma forma padronizada. as quais possuem seus objetivos e atividades básicas. 2.2 – A fase de iniciação e sua importância Como foi comentado acima. . se necessário.18 Com relação ao processo sistematizado. 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Figura 5: Exemplo de Ator de Negócio (RUP. al. é 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. Note que não está sendo defendida aqui a falta de documentação. vendedores.. entre outros (KRUCHTEN et. 2000). parceiros. direcionada1 e objetiva produzirá resultados melhores em menos tempo e com menos trabalho. sendo que uma documentação mais enxuta. 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. 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. é bom que se tenha por onde começar para depois partir para a customização. i. aquela máxima que diz: “menos é mais”. serão apresentados a seguir alguns componentes e diagramas da UML que são comumente utilizados na Modelagem de Negócios. 2006). 2002) 1 2 Que tenha o propósito de ser feita para auxiliar uma atividade futura que com certeza será realizada Indivíduos que não pertencem à Organização-alvo ou que fazem parte de um setor da Organização que não está no escopo da modelagem atual. clientes.e. pois as atividades dessa disciplina podem subentender muitos diagramas com vários componentes e isso pode acabar gerando um monte de documentação que tornará confuso o entendimento daqueles que a usarão. . pois como ela é a notação padrão. • Ator de Negócio: São os usuários no ponto de vista do negócio. pois apesar deles serem escolhidos conforme a necessidade de cada projeto. mas a documentação inteligente.61 UML já é um primeiro passo. uma vez que terão que “aprender” sobre a documentação. Diante disso.

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

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

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

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

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

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

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

69

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

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

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

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

4.2.2 – Artefatos Utilizados no Planejamento do Desenvolvimento

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

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

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

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

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

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

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

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

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

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

importantíssima

ser

relacionamentos

especiais

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

1

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

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

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

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

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

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

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

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

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

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

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

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

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

é 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. Portanto.84 Melhorar trabalho a divisão do Falta de processos bem definido Falta de um meio central de realização de atividades As informações destinadas tanto aos docentes como aos discentes são todas fornecidas pela secretária por telefone.2 – Modelo de Regras de Negócio O modelo de regras de negócio deve ser utilizado quando forem identificadas regras que fujam à lógica ou que sejam extremamente importantes para o funcionamento da Organização. . ou seja.1. já são entregues em formato eletrônico. email ou pessoalmente. ou criar a expectativa de se ter aula com um professor e na verdade ter com outro. Cronogramas não atualizados e inconsistentes às vezes fazem os alunos irem a aula em dias que não há aula. 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. sem a necessidade de intermediação de técnicos e secretários para tal trabalho. Tabela 3: Relação entre objetivos da Organização e oportunidades de se alcançá-los 5. Os alunos precisam se deslocar até a UEL ou enviar pelo correio a versão final da monografia. portanto é possível que ela seja entregue via Internet.

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

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

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

Dentre suas várias utilidades.1.88 Entrada: Primeira versão da monografia Saída: Protocolo de entrega de monografia 5. destaca-se a dele servir como um instrumento de identificação de acúmulos de responsabilidades para alguns atores e da forma de utilização dos recursos. .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.

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

Consistência nos cronogramas. Uma sugestão clara e direta dada por Heumann (2001). Portanto. Facilidade na comunicação da secretária com os docentes. automaticamente ele será atualizado para os professores e alunos. dentro dos modelos de negócio existe a possibilidade – e por que não dizer intenção – de se construir um modelo que possa depois ser mapeado para os modelos de sistema. 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. Cumprimento dos prazos de entrega conforme estabelecido. Tabela 4: Relação dos requisitos com os benefícios gerados 5.2 – Planejando e Adiantando o Próximo Passo Apesar das diversas utilidades da Modelagem de Negócios. Quando um cronograma sofrer alterações. evitando que algum aluno ou professores vá para a aula quando não houver. tais como os utilizados na etapa de análise. 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. é 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 . o seu objetivo principal é auxiliar a construção de um sistema de informação.90 processo.

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

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

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

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

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

99 .

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

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

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

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

.

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

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

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

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

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

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

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

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

O cronograma da turma será gerado. sendo alguns destes identificados já na fase de análise de negócio e durante a utilização do sistema. a partir dos dados do sistema e disponibilizados para consulta on-line. também. 2. emissão de comprovante de aula ministrada e geração automática dos cronogramas das turmas.3 – Funcionalidades Adicionais Conforme dito anteriormente as funcionalidades adicionais que serão implantadas no sistema são: emissão de comprovante de participação em banca.11 de dezembro de 2006 2. 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.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 –. 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 .

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful