Departamento de Computao Trabalho de Concluso de Curso

TIAGO DE OLIVEIRA STUTZ

Agregando Valor ao Software Por Meio da Modelagem de Negcios

Londrina 2006

TIAGO DE OLIVEIRA STUTZ

Agregando Valor ao Software Por Meio da Modelagem de Negcios

Trabalho de concluso de curso obrigatrio desenvolvido durante o 4 ano do Curso de Graduao em Cincia da Computao como requisito parcial obteno do ttulo de Bacharel. Orientador: Prof. Ms. Rodolfo Miranda de Barros

2006

ii

TIAGO DE OLIVEIRA STUTZ

Agregando Valor ao Software Por Meio da Modelagem de Negcios

COMISSO EXAMINADORA

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

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

_______________________________ Prof. Dra. Maria Anglica Maria Anglica de O. C. Brunetto Universidade Estadual de Londrina Londrina,___de___________ de 2006.

iii

O homem que trabalha somente pelo que recebe, no merece ser pago pelo que faz By Abraham Lincoln

iv

DEDICATRIA A Deus, meu conselheiro, minha famlia, meu alicerce e minha futura esposa Camila, meu conforto.

v AGRADECIMENTOS Agradeo, primeiramente, a Deus, nosso criador, por ter me dado nimo, fora e direo para conseguir chegar at aqui com sade, disposio, alegria e SATISFAO.

Agradeo minha famlia, pelo apoio incondicional em todos momentos, pela motivao, pela confiana e principalmente pelo amor. Agradeo minha futura esposa Camila pelo amor, carinho e compreenso nos momentos mais turbulentos do curso.

Agradeo especialmente ao meu irmo, Flvio de Oliveira Stutz, por ter me auxiliado em muitas decises, me mostrando os melhores caminhos a se seguir, sempre me oferecendo ajuda e apoio com muito amor, pacincia e dedicao. Obrigado fao! Agradeo a Deus por ser seu irmo!

Aos hermanos da Equipe Puerto Rico pelos grandes momentos de descontrao, incentivo, companheirismo, aprendizado, frustrao, diverso, alegria, motivao, sinergia e tudo mais que enche um belo prato. Diverso!

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 admirvel que me deu diversos conselhos e me ajudou sempre que precisei em todas as circunstncias no s acadmicas.

A todos os funcionrios, tcnicos e secretrias do departamento de computao pelo empenho e dedicao para fazer do curso de Cincia da Computao da UEL um dos melhores do pas.

vi STUTZ, Tiago De Oliveira. Agregando Valor ao Software Por Meio da Modelagem de Negcios. 2006. Monografia (Bacharel em Cincia da Computao) Departamento de Cincia da Computao, Universidade Estadual de Londrina, Londrina, 2006. RESUMO

Esse estudo compreende a anlise da importncia da modelagem de negcios nas fases iniciais de um projeto de software. Nesse contexto, ser analisado, tambm, como esse grupo de atividades interfere em todo o ciclo de vida e qual o impacto disso no valor dado ao software desenvolvido. Para verificar a relevncia desse procedimento, sero estudados conceitos tericos j

consolidados como a disciplina de Modelagem de Negcios a qual est dentro do Rational Unified Process (RUP) e a metodologia Enterprise Knowledge Development (EKD) que usada para extrao do conhecimento.

Palavras-chave: desenvolvimento de software; engenharia de software; EKD; modelagem de negcios; RUP; UML.

vii STUTZ, Tiago De Oliveira. Aggregating Value to the Software Through Business-Modeling. 2006. Monograph (Graduation in Computer Science) Department of Computer Science, State University of Londrina, Londrina, 2006. ABSTRACT

This study understands an analysis about the importance of Business Modeling in the initial phases of a software project. Inside this context, it will be analyzed, also, how this set of activities intervenes in all the life cycle and whats its impact on the value given to the developed software. To verify the relevance of this procedure, consolidated theoretical concepts will be studied, 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.

Key-words: software development, software engineering, EKD, business modeling; RUP, UML.

viii LISTA DE FIGURAS Figura 1: Fases e disciplinas do RUP (2002). ............................................ 19 Figura 2 Tabela comparativa entre algumas tcnicas de modelagem organizacional ............................................................................................. 40 Figura 3: O processo da verificao de endereo de cliente em alto nvel. Considerado para esboo (BUBENKO, PERSSON & STIRNA 2001).................. 49 Figura 4: O processo da verificao de endereo de cliente detalhado. Pode ser considerado bom para verso final (BUBENKO, PERSSON & STIRNA 2001) ...... 49 Figura 5: Exemplo de Ator de Negcio (RUP, 2002) ..................................... 61 Figura 6: Exemplo de Trabalhador de Negcio (RUP, 2002) ............................ 62 Figura 7: Exemplo de Entidade de Negcio (RUP, 2002) ................................ 62 Figura 8: Exemplo de Caso de Uso de Negcio (RUP, 2002) ............................ 63 Figura 9: Estado Inicial (RUP, 2002)........................................................ 63 Figura 10: Exemplo de uma Atividade (RUP, 2002) ...................................... 63 Figura 11: Estado Final (RUP, 2002)........................................................ 64 Figura 12: Deciso (RUP, 2002) ............................................................. 64 Figura 13: Barra de sincronizao (RUP, 2002) ........................................... 64 Figura 14: Exemplo de Raias (RUP, 2002) ................................................. 65 Figura 15: Parte de um Glossrio........................................................... 67 Figura 16: exemplo de um documento de Viso em forma de panfleto .............. 69 Figura 17: Exemplo de caso de uso de negcio (RUP, 2002)............................ 72 Figura 18: Exemplo de diagrama de atividades. No diagrama acima esto apontados os componentes bsicos de um diagrama de atividades. (RUP, 2002)........... 74 Figura 19: Diagrama de atividades utilizando raias (swim lanes)...................... 75 Figura 20: Modelo de objetos de negcio ilustrando um caso de uso de negcio de Check-in Individual (RUP, 2002)....................................................... 77 Figura 21: Um diagrama de atividades com fluxos de objetos mostrando como um pedido muda de estado durante o processamento de um pedido. ............... 78 Figura 22: Modelo de Caso de Uso de Negcio Transao Financeira (KRUCHTEN et. al, 2000) .............................................................................. 92 Figura 23: Modelo de Objetos de Negcio Transao Financeira (KRUCHTEN et. al, 2000) ...................................................................................... 92

ix Figura 24: Mapeamento do modelo de negcio para o de sistema (KRUCHTEN et. al, 2000) ...................................................................................... 93 Figura 25: Modelo de Caso de Uso de Negcio Transao Financeira (KRUCHTEN et. al, 2000) .............................................................................. 94 Figura 26: Modelo de Objetos de Negcio Transao Financeira (KRUCHTEN et. al, 2000) ...................................................................................... 94 Figura 27: Mapeamento dos objetos de negcio para as classes de entidades (KRUCHTEN et. al, 2000) ............................................................... 95

x LISTA DE TABELAS Tabela 1: Relao entre objetivos da organizao e mdulos do sistema ........... 83 Tabela 2: Relao entre objetivos da Organizao e os problemas em se alcan-los ............................................................................................. 84 Tabela 3: Relao entre objetivos da Organizao e oportunidades de se alcanlos.......................................................................................... 84 Tabela 4: Relao dos requisitos com os benefcios gerados........................... 90

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

xii SUMRIO

1 INTRODUO ....................................................................................................13 2 O RUP E A MODELAGEM DE NEGCIOS .......................................................16

2.1 O que o RUP.................................................................................................................................... 16 2.2 A fase de iniciao e sua importncia .............................................................................................. 18 2.3 A disciplina de Modelagem de Negcios .......................................................................................... 22 2.3.1 Principais Papis da Equipe ........................................................................................................... 24 2.3.1.1 Gerente de Projeto.................................................................................................................... 25 2.3.1.2 Analista de Processos de Negcio ........................................................................................... 26 2.3.1.3 Designer de Negcio................................................................................................................ 28 2.3.2 Organizao e Documentao das Atividades................................................................................ 29 2.3.3 Etapa 1: Aprovao do Projeto....................................................................................................... 31 2.3.3.1 Aprovao Pela Equipe............................................................................................................ 32 2.3.3.2 Aprovao Pelo Cliente ........................................................................................................... 34 2.3.4 Etapa 2: Planejamento do Desenvolvimento .................................................................................. 35

3 EKD.....................................................................................................................39
3.1 Viso geral.......................................................................................................................................... 41 3.2 A metodologia EKD........................................................................................................................... 42 3.2.1 Modelo de Objetivos ...................................................................................................................... 44 3.2.2 Modelo de Regras de Negcio ....................................................................................................... 45 3.2.3 Modelo de Conceitos...................................................................................................................... 46 3.2.4 Modelo de Processos de Negcio................................................................................................... 47 3.2.5 Modelo de Atores e Recursos......................................................................................................... 50 3.2.6 Modelo de Requisitos e Componentes Tcnicos ............................................................................ 52 3.3 O EKD e a Modelagem de Negcios................................................................................................. 54

4 ARTEFATOS E NOTAES..............................................................................58
4.1 Notaes.............................................................................................................................................. 59 4.1.1 UML e a Modelagem de Negcios................................................................................................. 60 4.2 Artefatos ............................................................................................................................................. 65 4.2.1 Artefatos Utilizados na Aprovao do Projeto ............................................................................... 66 4.2.1.1 Glossrio .................................................................................................................................. 66 4.2.1.2 Viso do Negcio..................................................................................................................... 68 4.2.2 Artefatos Utilizados no Planejamento do Desenvolvimento .......................................................... 69 4.2.2.1 Modelo de Casos de Uso de Negcio ...................................................................................... 70 4.2.2.2 Diagrama de Atividades........................................................................................................... 72 4.2.2.3 Modelo de Objetos de Negcio................................................................................................ 75

5 ABORDAGEM PRTICA....................................................................................80
5.1 O EKD e a Aprovao do Projeto .................................................................................................... 80 5.1.1 Modelo de Objetivos ...................................................................................................................... 81 5.1.2 Modelo de Regras de Negcio ....................................................................................................... 84 5.1.3 Modelo de Conceitos...................................................................................................................... 86 5.1.4 Modelo de Processos de Negcios ................................................................................................. 87 5.1.5 Modelo de Atores e Recursos......................................................................................................... 88 5.1.6 Modelo de Requisitos e Componentes Tcnicos ............................................................................ 89 5.2 Planejando e Adiantando o Prximo Passo..................................................................................... 90

6 CONCLUSO .....................................................................................................97 REFERNCIAS BIBLIOGRFICAS .......................................................................100 APNDICE A PROPOSTA EM FORMA DE PANFLETO....................................105 APNDICE B PROPOSTA TRADICIONAL.........................................................109

13

1 Introduo
Os avanos tecnolgicos computacionais, que se tornaram uma constante em nosso tempo, tambm afetaram as tecnologias empresariais, o que fez com que essas duas reas se aproximassem bastante nesses ltimos tempos (CRUZ, 2004). O problema que devido velocidade dessas transformaes, a integrao entre os membros dessas duas reas ainda no chegou sua plenitude, sendo o principal causador dessa falha a m comunicao entre esses membros e a conseqente incompreenso, por ambas as partes, dos valores e das relaes que norteiam o mundo que no o seu. Como conseqncia disso, gerada uma insatisfao para os membros das duas reas (MARQUIONI, 2006), alm das perdas financeiras e o ineficiente aproveitamento do que ambas as reas poderiam oferecer uma para a outra. O presente tem como objetivo mostrar como a Modelagem de Negcios importante no ciclo de vida do desenvolvimento de software e como essa atividade pode agregar valor ao software. Depois de feita essa anlise, esse trabalho tem o objetivo de propor uma metodologia para realizao da atividade de Modelagem de Negcios, tendo essa metodologia como fundamentao as prticas do RUP, a metodologia EKD e algumas experincias e observaes feitas com clientes em potencial no mercado. O maior objetivo dessa metodologia fazer com que a comunicao com o cliente seja eficiente e que, a partir disso, ele tenha maior compreenso da importncia e do papel do software, dando a este o devido valor. Tambm contribuir para que o processo de desenvolvimento de software ganhe qualidade, evitando ao mximo retrabalho, mudanas, desentendimentos ou qualquer outro desses tipos de problema que so constantes na maioria dos desenvolvimentos e que geram prejuzos.

Nesse estudo sero abordados alguns dos diversos causadores dessa insatisfao e das perdas financeiras, a saber: escopo mal definido (CRUZ, 2004), falhas ocorridas pela falta de gerenciamento de riscos, desenvolvimento

14 desorganizado, mudanas constantes (MARQUIONI, 2006) e no esclarecimento das funes do software por ambas as partes, i.e., pelo cliente no momento da construo do software e pelo fornecedor no momento da entrega do software.

Diante disso, ser apresentada a Modelagem de Negcios, juntamente com algumas tcnicas que podem ser utilizadas nessa atividade, e como ela pode solucionar os problemas citados, trazendo benefcios para os membros da rea de computao e empresarial, fazendo com que o empresrio possa ver no software no somente uma modernizao dos processos de negcio j existentes, mas um agente inovador dentro de sua empresa, e os desenvolvedores possam ver que um planejamento e modelagem adequados de software no so 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.

As principais contribuies desse trabalho so: a proposta de utilizao de algumas tcnicas e mtodos descritos no RUP juntamente com o mtodo EKD e a diviso da Modelagem de Negcios em duas etapas, sendo estas devidamente explicadas. Assim, o trabalho apresentar uma forma de se realizar a modelagem de negcio utilizando essas tcnicas citadas acima, sendo esse mtodo sugerido testado e aprovado com alguns clientes.

Com um pouco de contato com o mercado, pode-se observar que os empresrios acham que o software caro, pois no enxergam a dimenso do negcio que ele realiza, bem como seu papel na Organizao, pois para o empresrio, tudo muito simples e bvio. Alm disso, eles no vem, a priori, o que o sistema vai trazer de benefcio, ou seja, fazer de diferente, que no feito atualmente, ou no vem o retorno financeiro que iro ter adotando esse sistema no que se refere aos processos de negcios.

15 Alm dos vrios benefcios no que tange ao desenvolvimento propriamente dito (levantamento de requisitos, diminuio de riscos, definio de escopo, etc), a Modelagem de Negcios tambm serve como argumento nas negociaes de preo, pois ela deixa claro para o cliente o que ele ter de retorno utilizando o software, o que ele faz e qual o benefcio disso para a Organizao alm das outras possibilidades que ele abre e que podem agregar valor ao negcio realizado. Dessa maneira o desenvolvedor de software consegue tirar a idia de que o software tem seu valor somente por ele ser algo que exige um "conhecimento mgico", mas que tem valor tambm pelo que ele traz de custo/benefcio Organizao.

Depois desta introduo bsica, ser tratado no captulo 2, a disciplina de Modelagem de Negcios do RUP e qual o seu papel dentro dele. No captulo 3, ser apresentado o EKD e qual a sua relao com a Modelagem de Negcios, bem como qual valor ele agrega ela e ao software de maneira geral. J no captulo 4, sero apresentados com mais detalhes alguns artefatos e notaes que so utilizados nas atividades da disciplina estudada e qual a importncia deles para o desenvolvimento do software. Chegando ao final, ser mostrado no captulo 5, uma abordagem prtica dos conceitos tericos estudados at ento, mostrando a aplicabilidade dos conceitos e idias propostos. Finalmente, no captulo 6, de concluso, ser feita uma anlise geral do que foi apresentado neste trabalho, destacando os principais pontos abordados e as possibilidades futuras dentro do assunto.

16

2 O RUP e a Modelagem de Negcios

O IBM Rational Unified Process (RUP) o framework1 de processo de desenvolvimento mais utilizado entre as grandes corporaes hoje em dia. Essa ampla adoo se deve consistncia e versatilidade desse produto uma vez que ele possui prticas e orientaes no s para grandes projetos, mas para projetos de todos os tamanhos, desde que devidamente customizado. Alm disso, parte de sua credibilidade se deve ao dele ser um produto de uma das gigantes da informtica: a IBM. Por todos esses motivos e por ele trazer a disciplina de Modelagem de Negcios de uma forma bem estruturada e explicativa que ele foi escolhido como ponto de partida desse trabalho.

2.1 O que o RUP

O Rational Unified Process produto da IBM-Rational que descreve e suporta um processo iterativo de desenvolvimento de software, descrevendo as melhores prticas para as diversas atividades presentes no ciclo de vida deste desenvolvimento. Sua proposta no a de ser um produto esttico com apenas uma perspectiva e no sujeito a customizao, antes sua composio permite que ele seja adaptvel e moldvel pela equipe de desenvolvimento que o est utilizando, a qual deve escolher quais os elementos desse framework iro satisfazer suas necessidades (EELES, HOUSTON & KOZACZYNSKI, 2002).

O RUP foi criado pela Rational Software em conjunto com a empresa sueca Objectory AB nos anos 90. O processo de criao do RUP foi caracterizado pelo compartilhamento de experincias vividas em diversos projetos de software, dos quais foram identificados quais prticas e processos foram causadores de falha e quais

Estrutura de suporte a alguma atividade.

17 foram de sucesso, fazendo, assim, com que os desenvolvedores desse processo de engenharia de software pudessem reconhecer quais as razes dos problemas e propor solues que os eliminariam ainda em sua gnese (WIKIPEDIA, 2006).

Dessa forma, os criadores do RUP definiram uma srie de melhores prticas de software que, se adotadas, iriam eliminar as razes desses problemas, garantindo o sucesso no desenvolvimento do software. De maneira sucinta, essas prticas so: desenvolvimento iterativo, gerenciamento de requisitos, arquitetura baseada em componentes, uso de modelos visuais, verificao contnua da qualidade do software e gerenciamento de mudanas (EELES, HOUSTON & KOZACZYNSKI, 2002).

Para que uma equipe de desenvolvimento possa adotar essas melhores prticas, preciso que um processo seja estabelecido, que modelos sejam disponibilizados e que possam existir diferentes alternativas de se adotar essas prticas em funo dos diferentes tipos de projeto existentes. Com o RUP esse problema resolvido, pois ele como se fosse um grande mercado com vrias prateleiras cheias de produtos para que voc possa escolher aquele que ir satisfazer suas necessidades, i. e., esse framework disponibiliza para voc vrias alternativas de customizao dos processos descritos e vrios modelos e artefatos que podem ser utilizados. Muitos profissionais da rea de desenvolvimento ou engenharia de software costumam fazer uma distino entre RUP e mtodos de desenvolvimento geis por exemplo, o Extreme Programming (XP) como se eles fossem adversrios que no podem ocupar o mesmo espao. um equvoco comparar o RUP a um mtodo de desenvolvimento, pois o produto Rational Unified Process (RUP) um processo de negcios genrico (RUP, 2002), ou seja, ele no um produto final assim como os mtodos geis, mas um framework que contm todos os componentes envolvidos em um desenvolvimento de software, tais como: diretrizes, artefatos, papis, atividades, entre outros. Portanto, assim como Gibbs (2006) afirma, possvel que se adote um mtodo gil utilizando o RUP; tudo depende da customizao.

18 Com relao ao processo sistematizado, o RUP prega um ciclo de vida composto por quatro fases (iniciao, elaborao, construo e transio) sendo que cada uma delas desenvolvida atravs de disciplinas bem especificadas. Um erro muito comum o pensamento de que a seqncia de tarefas de um desenvolvimento est relacionada s disciplinas enquanto a ordem de execuo dessas tarefas est ligada s fases do ciclo de vida. Com relao aos modelos, esse framework disponibiliza uma srie de artefatos para que os desenvolvedores possam documentar, se necessrio, cada atividade realizada de uma forma padronizada, alm de utilizar como notao fundamental a Unified Modeling Language (UML).

2.2 A fase de iniciao e sua importncia

Como foi comentado acima, o ciclo de vida proposto pelo RUP dividido em 4 fases, as quais possuem seus objetivos e atividades bsicas. Essas atividades esto diretamente ligadas s disciplinas que devem ser praticadas em cada uma das fases, sendo que a importncia e tempo gasto em cada uma das disciplinas variam de acordo com a fase em que o desenvolvimento se encontra. A figura abaixo ilustra esse conceito de esforo gasto em cada uma das disciplinas em funo da fase do ciclo de vida.

19

Figura 1: Fases e disciplinas do RUP (2002).

Pode-se observar pelo grfico que a fase de iniciao a mais curta de todas e composta basicamente pelas disciplinas de Modelagem de Negcios e Requisitos. Infelizmente, o que ocorre na maioria dos projetos o atropelamento de fases e disciplinas, i. e., a fase de iniciao muitas vezes misturada com a de elaborao e a Modelagem de Negcios no realizada, passando-se direto para o levantamento de requisitos.

A fase de iniciao 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. Para que essa meta seja alcanada, alguns objetivos so traados e devem ser atingidos ao fim dessa fase (RUP, 2002). So eles: Definir o escopo do projeto, ou seja, o que deve ou no estar no

software.

20 Desenhar os casos de uso crticos do sistema, fazendo inclusive

algumas provas de conceito1. Planejar arquiteturas para alguns cenrios bsicos, especialmente

os que so comuns em vrios projetos e tambm esto presentes neste. Estimar o custo geral e o planejamento para a prxima fase

(elaborao) e para o projeto todo. Fazer um gerenciamento de riscos em potencial; identificar as

origens de imprevistos. Preparar o ambiente de suporte para o projeto.

Quando a equipe desenvolvedora atinge esses objetivos, ela pode ter a certeza de possuir informaes suficientes para que o mnimo de erro seja cometido durante o projeto e para que conseqentemente seu produto e servio sejam de excelente qualidade. Isso porque quando o escopo do projeto bem definido, o cliente ter exatamente as funcionalidades que precisa, nenhuma a mais para confundi-lo e nenhum a menos para deix-lo na mo, e o planejamento do cronograma poder ser cumprido, pois a equipe sabe exatamente o que tem fazer e para quando. Quando os casos de uso crticos do sistema so atacados, os desenvolvedores se previnem de, durante o processo de construo, descobrir a inviabilidade de implementao de alguma funcionalidade que crucial para o cliente e faz com que a utilidade do sistema seja percebida (EELES, HOUSTON & KOZACZYNSKI, 2002) j nas primeiras releases2 do ciclo de vida. Definida a arquitetura dos cenrios bsicos, a construo de algumas funcionalidades comuns ou das mais prioritrias j pode ser agilizada, o que ajuda, por exemplo, a equipe desenvolvedora mostrar servio ao cliente. Se um gerenciamento de riscos for feito da forma correta, i.e., se alm de identificados, os riscos tambm possuem respectivas medidas de reduo de impacto,

Construo de um cdigo exemplo para verificar a viabilidade da implementao de alguma funcionalidade 2 verso de uma parte do software ou dele todo lanada publicamente

21 as possibilidades de fracasso no sistema ou de prejuzo sero muito reduzidas, pois dificilmente alguma grande surpresa ocorrer, e mesmo que ocorra, as medidas preventivas j estaro planejadas. E por fim, uma vez levantadas as informaes sobre o cliente e sobre o que ele deseja, a equipe poder dar uma estimativa de quanto isso ir custar e j preparar o ambiente para o desenvolvimento desse software (POLLICE et. al, 2004).

Uma curiosa observao a ser feita que quando uma equipe contratada para desenvolver o software ela nunca cogita a possibilidade do seu cliente no necessitar do software. Isso acontece no s pelo fator financeiro, mas pela falta de uma adequada anlise de negcio, que a essncia da fase de iniciao, que mostraria a necessidade ou no do cliente em obter um software. O ideal seria que ao final da fase de iniciao, a equipe considerasse os estudos realizados e as caractersticas do projeto para tomar a deciso sobre continuar ou cancelar o projeto, podendo, em alguns casos, at estipular o custo financeiro do desenvolvimento.

Infelizmente, devido ao pouco ou nenhum tempo investido na fase de iniciao, muitos problemas surgem no decorrer do projeto, e pior, a equipe e a gerncia do projeto ficam sem saber como resolver essas questes, uma vez que no foi feito um gerenciamento de riscos, uma correta definio de escopo e um adequado gerenciamento de requisitos.

Disso, pode-se compreender a importncia da fase de iniciao para tornar as aplicaes cada vez mais intuitivas, modernas e teis aos clientes, agregando valor ao negcio e deixando de ser simples mecanizaes de antigas atividades manuais (KRUCHTEN et. al, 2000). Outro benefcio notvel de se realizar uma adequada fase de iniciao a criao de perspectivas fundamentadas sobre outras fases do desenvolvimento, atravs da definio de uma arquitetura candidata, do gerenciamento de riscos (GIBBS, 2006) e do levantamento inicial de requisitos que, junto dos outros dois componentes, iro servir como parmetro para determinao de custos e prazos das fases subseqentes.

22

2.3 A disciplina de Modelagem de Negcios

A Modelagem de Negcios a disciplina de maior participao dentro da fase de iniciao do RUP. A exemplo das outras disciplinas, ela est presente em todas as fases, porm as suas atividades so as primeiras a serem realizadas dentro de um projeto.

Apesar da disciplina de Requisitos tambm possuir uma acentuada presena na primeira fase do ciclo de vida, a sua expressividade se concentra no perodo compreendido no fim da primeira e no comeo da segunda fase. Isso porque para uma eficiente elicitao de requisitos necessrio que se entenda em qual o contexto o software est sendo construdo, ou seja, o modelo de negcio gerado um importante subsdio para a disciplina de Requisitos (EELES, HOUSTON & KOZACZYNSKI, 2002), o que faz com que a Modelagem de Negcios tenha suas atividades realizadas antes das relacionadas ao levantamento de requisitos na ordem do desenvolvimento.

Todo desenvolvimento de software visa um produto que tenha boa qualidade, preo justo e que seja til para os usurios que o requisitaram. Comeando do fim para o comeo: para um software ser til ele precisa dar suporte direto ao negcio para o qual ele foi construdo, e quem vai te dizer o que fazer ser a Modelagem de Negcios (NG, 2002); para que tenha um preo justo, necessrio que seja feita uma estimava acertada dos custos do projeto; e para que o software tenha boa qualidade, preciso que ele case o quesito utilidade com outros como por exemplo: confiabilidade e agilidade.

Ciente da caracterstica marcante do RUP de sugerir formas sistemticas de se realizar as atividades, pode-se concluir que a disciplina descrita neste tpico possui algumas metas claras, as quais so descritos nesse framework. So elas (RUP, 2002):

23 Entender a estrutura e a dinmica da Organizao na qual um

sistema deve ser implantado (a Organizao-alvo1). Entender os problemas atuais da Organizao-alvo e identificar as

possibilidades de melhoria. Assegurar que os clientes, usurios e desenvolvedores tenham um

entendimento comum da Organizao-alvo. Derivar os requisitos de sistema necessrios para sustentar a

Organizao-alvo.

Quando uma equipe de desenvolvimento consegue atingir essas metas, as chances do desenvolvimento se dar de forma harmoniosa so muito grandes, pois com as informaes geradas como conseqncia das tarefas realizadas nessa busca, o ciclo de desenvolvimento ser iniciado com algumas caractersticas positivas, como as listadas abaixo, correspondentes s metas descritas acima. Escopo e limites do sistema bem definidos, i.e., de todas as

questes levantadas a respeito dos processos de negcio da Organizao, o que est includo e o que est excludo da rea de atuao do sistema (NG, 2002). A definio de escopo um dos, seno o mais, componente que mais influencia na definio de prazos e custos de projeto. Com a identificao precisa dos problemas da Organizao, satisfatrias podem ser encontradas. Isso d alta

solues

credibilidade equipe, pois mostra a sua eficincia em realizar o que o cliente quer: resolver problema. Os clientes e desenvolvedores j estaro se comunicando melhor,

pois todos eles sabero o porqu da implantao do sistema, o que ele dever fazer e o que ele trar de benefcio. Isso facilitar muito a

Empresa ou Instituio cliente para qual o servio est sendo prestado

24 atividade de levantamento de requisitos; no s em relao a tempo de durao, mas qualidade da especificao. Os requisitos chaves do sistema tero sido levantados, o que

servir como ponto de partida para a atividade de especificao de requisitos (GIBBS, 2006). Isso j direcionar a primeira iterao do ciclo de vida, pois os requisitos que devem ser prioritariamente atacados tero sido identificados cedo.

Alm disso, a Modelagem de Negcios pode agregar valor ao processo modelado, e conseqentemente ao software, na medida em que h uma possibilidade de que sejam identificados durante as atividades, oportunidades de melhoria dos processos e relaes de negcios atuais (NG, 2002). Podem ser identificadas, por exemplo, tarefas redundantes que causam baixa produtividade e problemas de consistncia de informaes; pode-se verificar a existncia de um gargalo de trabalho e informaes em um determinado setor da Organizao, o que atrasa muitos processos e causa enorme dependncia dos funcionrios daquele setor, fazendo com que a Organizao, conseqentemente, produza abaixo de sua capacidade e esteja sujeita a riscos de difcil contenso.

2.3.1 Principais Papis da Equipe

Dentro de qualquer equipe, mesmo que pequena menos de 10 pessoas (POLLICE et. al, 2004) , necessrio que sejam definidos papis e responsabilidades para cada um dos membros. A importncia da definio de papis no somente para melhorar diviso do trabalho, mas principalmente para que haja na equipe responsabilidades definidas para cada atividade realizada, fazendo, assim, com que os membros tenham que cumprir direitinho as suas tarefas e que respondam por elas. Essa importncia visvel principalmente nos momentos de indecises da equipe, nos quais algum membro tem que tomar a frente e dizer o que ser feito. Com os papis bem definidos, isso realizado de forma mais saudvel e natural, sem gerar

25 desconforto para ningum, pois o membro possui essa responsabilidade e se ele foi escolhido para aquele papel, porque ele possui o perfil necessrio, ento a sua deciso, mesmo que no seja a da maioria da equipe, tem grandes chances de ser a melhor (POLLICE et. al, 2004) a se tomar.

Dentro da Modelagem de Negcios, no diferente; a definio de papis fundamental, principalmente pelo fato dos participantes dessas atividades deverem possuir algumas habilidades a mais do que meramente tcnicas. A correta definio desses papis influencia diretamente no custo do software, pois os indivduos escolhidos para assumir os papis e responsabilidades dessa disciplina iro ter contato direto com o cliente, definiro o que o software dever fazer e, inicialmente, at como se fazer. Conseqentemente, uma definio correta dos papis dentro da equipe acarretar na valorizao do software, tanto no que diz respeito ao sucesso no desenvolvimento deste, como na satisfao do cliente com a qualidade do servio oferecido.

Para melhor entendimento da importncia dos papis e suas definies, a seguir sero apresentados os papis chaves dentro da Modelagem de Negcios.

2.3.1.1 Gerente de Projeto

Talvez seja um dos nicos papis que estaro presentes em todos os projetos e em todas as suas fases, independente do tamanho, natureza ou metodologia de desenvolvimento adotada. Inicialmente, o gerente de projeto era o indivduo que identificava as tarefas necessrias, as delegava aos membros da equipe e ficava pressionando cada um para cumprir os prazos (GIBBS, 2006).

Hoje, essa realidade mudou. O gerente de projeto um indivduo extremamente participativo: realiza parcerias com os membros da equipe, estimula e

26 valoriza as solues encontradas e conduz o andamento do projeto (GIBBS, 2006), protegendo a equipe de distraes e organizando cronogramas, defende os interesses do time e realiza a comunicao com o cliente. Segundo RUP (2002), para desempenhar o papel Gerente de Projeto, o indivduo deve possuir algumas habilidades imprescindveis, a saber: saber realizar apresentaes e se comunicar bem; exercer liderana e desenvolver o esprito de equipe possuir um bom relacionamento interpessoal e opinar

sensatamente na seleo de pessoal ter como objetivo agregar valor ao cliente na forma de

software que atenda (ou ultrapasse) s expectativas do cliente (RUP, 2002)

Dentre essas habilidades, a ltima merece um destaque especial, pois ela est diretamente relacionada ao objetivo desse estudo. Quando um gerente se preocupa em agregar valor ao cliente, ele se comunica bem com ele, surpreende-o positivamente, deixa claro para ele qual a importncia do software para a empresa, alm de valorizar a participao do cliente no desenvolvimento. Isso faz com que o cliente tenha satisfao em contratar o servio oferecido e se sinta confortvel ao negociar o preo e as condies do contrato. Alm disso, como o gerente deseja cumprir o acertado com o cliente para atingir o objetivo de agregar valor ao produto oferecido, ele passar para a equipe esse objetivo, esse entusiasmo, envolvendo todos os membros num processo organizado que tem como ideal promover a satisfao do cliente e agregar valor ao software.

2.3.1.2 Analista de Processos de Negcio

Dentro da disciplina de Modelagem de Negcios, esse o papel mais importante, pois ele quem realizar as atividades que so responsveis por atingir os objetivos da Modelagem de Negcios.

27 O analista de processos de negcio essencialmente coordena a criao de modelos de casos de uso de negcio1 (KRUCHTEN et. al, 2000) e realiza a avaliao da Organizao, definindo os atores, setores envolvidos e como eles se relacionam, extraindo, assim, o que se pretende com a implantao do sistema. Dessa anlise, so produzidas documentaes contendo as regras de negcio e alguns diagramas de atividades2 ilustrando os processos de negcios que ocorrem na Organizao.

responsabilidade do analista de processos de negcio definir quais sero as fronteiras e o escopo da Modelagem de Negcios (RUP, 2002), ou seja, quais as partes da Organizao-alvo, juntamente com seus indivduos, sero levadas em considerao e qual o tipo de esforo ser realizado na Modelagem de Negcios, i.e., se envolver ou no mudanas e inovaes no negcio analisado.

Mas, dentro da ptica deste trabalho, a tarefa de maior importncia que o analista de processo de negcios realiza a de identificar quais so as metas e objetivos da Organizao-alvo, as quais iro direcionar o esforo da Modelagem de Negcios. A importncia dessa tarefa reside no fato dela ditar aos desenvolvedores qual o objetivo do trabalho realizado e o que deixar o cliente satisfeito. Ou seja, o gerente de projeto em nome da equipe ter em mos um guia para saber direcionar o esforo de desenvolvimento ao mesmo tempo em que ter uma lista de benefcios gerados pela implantao do sistema extrada do prprio cliente que serviro para justificar os custos financeiros e cronolgicos, mostrando o valor do software para a Organizao e a seriedade da equipe em honrar seus compromissos, sem contar a possibilidade de se identificar oportunidades que agregaro valor ao negcio do cliente.

O Modelo de Casos de Uso de Negcios um modelo das funes pretendidas do negcio. usado como base para identificar papis e produtos liberados na organizao. (RUP, 2002) 2 Um diagrama de atividade um grfico de fluxo, no qual mostrado o fluxo de controle de uma atividade para outra.

28 Existem algumas metodologias que descrevem tcnicas e boas prticas para obteno dessas informaes e outras complementares. Dentre elas est a metodologia chamada EKD, apresentada no captulo 3 EKD, que uma metodologia que tem como um de suas prioridades investigar de forma clara e direta quais os objetivos e metas da Organizao, ordenados de acordo com suas respectivas prioridades, assim como a quais regras e processos de negcio estes objetivos esto amarrados e quais indivduos tm participao direta no alcance deles, levando-se em considerao os problemas e as oportunidades existentes nos cenrios avaliados.

2.3.1.3 Designer de Negcio

O designer de negcio trabalha para gerar a maioria das informaes que o analista de processos de negcio utiliza em suas atividades. Ele define as entidades presentes na Organizao que participam das relaes de negcio, i.e., os trabalhadores e alguns casos e fluxos de negcios que envolvam esses trabalhadores (KRUCHTEN et. al, 2000).

Para desempenhar esse papel, o membro da equipe escolhido deve: Preocupar-se com o que o cliente precisa e espera do sistema; Preocupar-se com as necessidades dos usurios que podem ser os

prprios clientes ou clientes dos clientes. Participar do levantamento de requisitos final, para verificar a

coerncia do seu levantamento de informaes com o da equipe de Requisitos

Em projetos pequenos, esse papel pode ser atribudo a mesma pessoa que desempenha o papel de analista de processos de negcio, pois o volume de informaes gerado no ser muito grande, portanto esse indivduo ter tempo de levantar e de analisar as questes tranqilamente.

29

2.3.2 Organizao e Documentao das Atividades

Durante o desenvolvimento da Modelagem de Negcios, fundamental definir quais as atividades dessa disciplina sero realizadas, uma vez que cada projeto possui uma caracterstica. Como foi explicado acima, o RUP possui uma srie de atividades e artefatos disponveis para que os desenvolvedores utilizem, sendo que essa escolha ir variar de acordo com o tipo e tamanho do projeto em questo. Portanto, o gerente de projeto da equipe dever definir, aps um primeiro briefing1 com o cliente, quais as atividades sero realizadas, organizando-as cronologicamente e prioritariamente de forma que somente as tarefas realmente necessrias para o projeto em questo sejam realizadas, i.e., o gerente far uma customizao do RUP para a realidade daquele projeto (POLLICE et. al, 2004).

Definidas as atividades a serem realizadas e seus respectivos prazos, o gerente de projeto deve avaliar quais os artefatos devero ser produzidos em cada atividade para que os membros responsveis pela execuo das tarefas relacionadas a essas atividades possam realiz-la da forma mais objetiva, enxuta e eficaz possvel. Conseguinte, a equipe ter, ento, um roadmap2 da realizao da Modelagem de Negcios, podendo este ser, de preferncia, documentado em um sistema gerenciador de projeto (GIBBS, 2006), no qual todos membros da equipe tero acesso e podero se planejar para realizao das tarefas. Dentre estes artefatos, destaca-se o documento de Viso de Negcio, que descreve qual a viso que a equipe tem da Organizao-alvo e do produto a ser desenvolvido, e o Caso de Negcio, que fornece a justificativa para o projeto e estabelece suas restries econmicas.

Ao final dessa estruturao do ambiente, iniciam-se as atividades definidas acima, sendo que o resultado dessas atividades ser utilizado para que o

1 2

Conjunto de dados e informaes. Planejamento de organizao futuro, dizendo o que ser feito, como e quando.

30 gerente de projeto, juntamente com a equipe, possa realizar a customizao do RUP para a fase de elaborao. Assim, a documentao das atividades realizadas muito importante, pois ela que servir como base para o planejamento da fase seguinte. Outro bom motivo para se ter as informaes sobre os acontecimentos e experincias obtidos, a possibilidade de melhoria desses processos, pois como o RUP baseado em iteraes, ao final de cada iterao possvel avaliar-se o desempenho da estratgia adotada para realizao da Modelagem de Negcios.

Apesar dos roadmaps serem particulares a cada projeto, alguns elementos sempre estaro presentes neles, 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, 2003) no projeto, como por exemplo: cliente; problemas existentes; usurios do sistema; entre outros. Em linhas gerais, todo planejamento de desenvolvimento da disciplina de Modelagem de Negcios deve contemplar: Como ser feita a comunicao com o cliente Quais informaes sobre a Organizao-alvo so importantes O que o sistema dever fazer e quais regras que tangem essas

funcionalidades Como ser feita a comunicao entre os membros da equipe

Os elementos acima no sero detalhados em relao s tarefas que devem ser realizadas ou os artefatos que devem ser produzidos, pois eles so apenas direcionamentos que devem compor a realizao da Modelagem de Negcios. Porm, certo que o RUP possuir as atividades e artefatos necessrios para atender os diferentes estados que estes elementos possam se encontrar; basta apenas que a situao de cada um seja bem entendida para que o uso do framework seja feito da maneira correta. Por exemplo: suponha um projeto em que o gerente de projeto reside em uma cidade e o analista de negcio em outra, e os dias de trabalho dos dois quase nunca coincidem, ou seja, eles quase no se encontram e, portanto, no se

31 comunicam pessoalmente. O elemento Comunicao entre os membros da equipe apresenta a caracterstica da comunicao no pessoal e inconstante entre alguns membros, o que faz com que eles no tenham termos e concepes iguais ou padronizadas em seus vocabulrios e entendimentos. Por esse motivo, necessrio que um padro mais formal de comunicao seja estabelecido entre os membros da equipe que no se comunicam pessoalmente em particular o analista de negcio e o gerente de projeto. Quando o analista de negcio for passar para o gerente de projeto alguns documentos gerados nas suas atividades dentro da Modelagem de Negcios, ele ter que seguir uma norma definida pelo gerente para que haja o entendimento entre eles. Para resolver esse problema, RUP (2002) apresenta um artefato chamado Guia de Modelagem de Negcios, que tem como finalidade descrever como voc deve modelar casos de uso, entidades e trabalhadores de negcios. Ou seja, no documento o gerente especificaria como o analista de negcio deveria documentar as anlises feitas de modo que o gerente pudesse compreender.

Para dar um carter mais prtico a esse estudo sobre as atividades e artefatos da Modelagem de Negcios, ela ser dividida em duas etapas: Aprovao do Projeto e Planejamento do Desenvolvimento. A abordagem feita nas sees que trataro dessas duas etapas mostrar o quo til so as atividades e os artefatos que o RUP oferece para os desenvolvedores de maneira geral.

2.3.3 Etapa 1: Aprovao do Projeto

Um projeto de desenvolvimento de software, antes de qualquer coisa, uma relao comercial e como tal envolve recursos financeiros que muitas vezes so altssimos. Portanto, uma empresa no ir pagar pelo desenvolvimento de um projeto que no esteja bem fundamentado e que mostre adequadamente quais os retornos o sistema implantado ir trazer, sejam estes financeiros ou logsticos. Por outro lado, os desenvolvedores tambm devem ter conscincia da importncia do seu trabalho e no desvaloriz-lo somente para no perder o cliente.

32 Portanto, durante a fase de iniciao, importantssimo que seja elaborada para o cliente uma proposta de desenvolvimento mostrando a ele que a equipe compreende quais so os objetivos e problemas da empresa, quais so as pessoas envolvidas nos processos relacionados a estes, o que a empresa deseja que o sistema faa e quais as solues e inovaes que a equipe prope para que os problemas sejam resolvidos, os objetivos alcanados e oportunidades de agregar valor ao negcio aproveitadas. Mas a importncia de se coletar essas informaes no apenas a de mostrar ao cliente todos esses benefcios; essas informaes tambm so teis para os desenvolvedores poderem estimar custos, prazos e a viabilidade do projeto (RUP, 2002), uma vez que eles podero ter uma idia de quais tecnologias e metodologias devero ser utilizadas durante o projeto. Assim, o cliente aceitar melhor o valor cobrado e o prazo de entrega do sistema, pois ele entender exatamente os benefcios gerados por ele e as questes a serem analisadas durante a sua construo, fazendo com que os desenvolvedores possam cobrar um preo justo sem receios e assumam o compromisso de entregar o sistema em um prazo coerente.

Nesse aspecto, um marco identificado dentro da disciplina de Modelagem de Negcios: Aprovao do Projeto. O motivo de se considerar essa aprovao como um marco o de tornar as atividades dessa disciplina sistematizadas e direcionadas, de modo que os membros da equipe possam concentrar seus esforos nessas atividades, pois se elas no forem bem executadas, possivelmente o projeto no ser aprovado e conseqentemente qualquer esforo concentrado nas atividades que no as referentes essa etapa ter sido em vo.

2.3.3.1 Aprovao Pela Equipe

O incio de um projeto se d partir do momento em que o cliente solicita uma proposta para um determinado servio e os membros da equipe responsveis por elaborar essa proposta iniciam os trabalhos. Dessa forma, fundamental que esses indivduos levem em considerao no s os interesses do

33 cliente, mas de toda a equipe. Por esse motivo que RUP (2002) trata de forma particular um fluxo de trabalho chamado Conceber Novo Projeto, a qual tem o seguinte objetivo de acordo com o autor:
[...]A finalidade deste detalhamento do fluxo de trabalho apresentar um projeto desde a origem de uma idia at o ponto em que possvel tomar decises fundamentadas para continuar ou abandonar o projeto. Com base na Viso inicial, os riscos so avaliados e uma anlise econmica, o Caso de Negcio, produzida. Se a Reviso da Aprovao do Projeto julg-los satisfatrios, o projeto ser formalmente configurado. (RUP, 2002)

Dentro desse fluxo de trabalho, a atividade de reviso do projeto que ir Determinar, do ponto de vista do negcio, se vale ou no a pena investir neste projeto (RUP, 2002). Esta atividade consiste em uma ou mais reunies com os responsveis da equipe pela aprovao do projeto, ou seja, gerentes, executivos, analistas de negcio, etc, que iro levar em conta todas as informaes sobre a viabilidade econmica e tecnolgica do projeto, os riscos levantados e a viso a respeito da Organizao-alvo e suas expectativas em relao ao projeto.

Nessa reunio sero discutidos aspectos relacionados aos benefcios que o produto proporcionar ao cliente e empresa tanto equipe implementadora quanto aos demais , disponibilidade dos recursos necessrios para o

desenvolvimento do projeto e o qual ser o custo desse projeto, tanto em valores absolutos como em termos de retorno sobre investimento (ROI). De todos esses aspectos, aqueles que mais geram polmica so o valor a ser cobrado pelo projeto e o tempo de durao deste. Para que uma boa estimativa possa ser feita, 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 negcio do cliente, para poderem saber exatamente o que ele deseja. Segundo Gibbs (2006), essa correta anlise do negcio um dos aspectos que mais tem influncia na hora de se estimar os custos, pois uma empresa pode oferecer um custo financeiro e cronolgico menor que a de outra no por ser melhor executora dos projetos, mas por no ter entendido corretamente a dimenso e os objetivos do projeto, o que acarreta em

34 problema a toda a equipe que se ver pressionada para entregar o produto no prazo e ainda no receber uma quantia justa por isso.

Dessa forma, o conselho que Gibbs (2006) d para que essas estimativas de tempo e preo sejam feitas da melhor forma possvel, envolver todos desenvolvedores que atuaro no projeto para poderem expressar suas opinies e experincias, afinal, eles esto na melhor posio para dizer se as estimativas de custo e tempo esto dentro do possvel e sero os maiores afetados caso essas estimativas falhem.

2.3.3.2 Aprovao Pelo Cliente

Assim que a empresa de software concluir a proposta, o gerente de projeto, juntamente com os analistas de negcio, a apresentaro ao cliente que fechar o acordo ou negociar uma nova proposta, que o que normalmente acontece.

A exemplo da aprovao do projeto feito pela equipe, os critrios que mais contam para o cliente so preo e tempo. Segundo Gibbs (2006), existem muitas formas de se estimar os valores a serem cobrados em um projeto, porm poucas so as empresas de software que conseguem fazer uma estimativa exata, ainda que adotando estes mtodos. Isso pode gerar problemas inclusive de credibilidade, pois o cliente pode desconfiar da competncia da empresa, justificando que ela deveria saber quanto cobrar pelo seu servio. Com relao ao prazo, muitos clientes podem querer subestimar a arte de se produzir um software, exigindo prazos absurdos, por acharem que produzir um software resume-se em programao.

Uma possvel soluo para esses problemas est na melhoria da comunicao entre a empresa de software e o cliente. Nas reunies de apresentao e negociao da proposta, o gerente de projeto juntamente com os analistas devem

35 passar informaes adicionais s contidas na proposta, tais como as capacidades da equipe desenvolvedora (GIBBS, 2006), exemplos de projetos bem sucedidos e principalmente qual a expectativa da empresa em relao a esse projeto, demonstrando domnio do contexto em que este projeto se dar. Nessa reunio, importante tambm que seja aberta uma sesso de perguntas (GIBBS, 2006) para que o cliente possa tirar todas as suas dvidas e como essas perguntas sero principalmente sobre o projeto e sua relao ao negcio do cliente retorno sobre investimento (ROI) , fundamental que o gerente e os analistas tenham domnio do assunto e saibam exatamente como o sistema agregar valor ao negcio da Organizao-alvo.

Assim, depois de produzido um bom documento, com vrias informaes teis para o cliente poder tomar sua deciso, esclarecidas todas essas dvidas principalmente com relao ao retorno sobre investimento (POLLICE et. al, 2004) e demonstrado o valor da equipe desenvolvedora, o cliente ter uma melhor compreenso dos custos de um projeto de software. Portanto, de fundamental importncia as informaes coletadas na Modelagem de Negcios, pois elas estaro 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 noo melhor do tamanho, da complexidade e dos benefcios do projeto que ele solicitou, compreendendo e aceitando os custos de tempo e dinheiro apresentados.

2.3.4 Etapa 2: Planejamento do Desenvolvimento

Seguindo a linha proposta neste estudo, chega-se ao marco final da Modelagem de Negcios: Planejamento do Desenvolvimento. Depois de realizadas todas as atividades, coletadas, organizadas e apresentadas vrias informaes, elaborada e aprovada a proposta de desenvolvimento, chegada a hora de se iniciar o desenvolvimento propriamente dito.

36 Para isso, o primeiro passo a ser dado planejar esse trabalho, instituindo-se um processo (KROLL & KRUCHTEN, 2002), de modo que as tarefas sejam organizadas de acordo com as suas precedncias e importncias relativas ao valor percebido1 que uma informao que s pode ser obtida por meio de uma adequada modelagem, pois ela que dir o que o cliente quer, onde quer chegar e quanto est disposto a gastar com isso.

Para iniciar o planejamento, Pollice et. al (2004) sugere que sejam realizadas as seguintes atividades: priorizao dos requisitos de alto nvel j levantados; definio de estratgias para realizao dos trabalhos propostos; levantamento de riscos; e configurao do ambiente de trabalho.

A priorizao dos requisitos consiste em analisar as dependncias entre os requisitos, para poder classific-los de modo que nenhuma funcionalidade que precisa de outra seja implementada antes da primeira, ou que as funcionalidades menos importantes, no ponto de vista do cliente, sejam feitas antes, diminuindo assim o valor percebido do servio.

A definio de estratgias para realizao das tarefas envolvidas na construo do sistema a atividade mais dinmica desse planejamento, pois ela ser realizada por inteiro a cada iterao chamada de plano de iterao , enquanto as outras so realizadas nesse incio de projeto e depois sero somente refinadas, sem sofrer grandes alteraes. Portanto, essa atividade na fase de iniciao ir ter como produto final um plano de estratgias trabalho para as atividades do projeto de um

quanto o cliente est disposto a pagar por um produto antes de saber o preo real. Se a quantia que ele est disposto a pagar superior ao valor real do produto, isso implica em satisfao do cliente (BELTRO, 2006).

37 modo mais amplo e estimativo, sem muitos detalhamentos. Neste plano, as tarefas relativas primeira iterao da fase de elaborao tero as estimativas e definies mais precisas, uma vez que essa iterao est prxima da atual (iniciao).

Realizadas essas duas atividades, inicia-se a construo de uma lista de riscos que, segundo RUP (2002) ...uma varivel que, em sua distribuio normal, pode ter um valor que comprometa ou elimine o sucesso de um projeto, ou seja, tudo que possa fazer o projeto dar errado. Esta lista um artefato do RUP que contm os riscos ordenados do mais importante para o menos, contendo informaes adicionais como descrio do risco, impacto que ele pode causar, um indicador de que ele pode acontecer, medidas de contingncia para poder saber o que fazer caso o risco se concretize. Segundo Gibbs (2006), essa ateno especial aos riscos de suma importncia, pois muitos projetos no so concludos com sucesso pela falta de identificao e definio de medida de contingncia para cada um dos riscos.

Finalmente, depois de levantados os riscos, o ambiente de trabalho ser configurado, ou seja, ser feita uma verificao de quais equipamentos, salas, mesas, entre outros recursos, sero utilizados durante o desenvolvimento. Alm disso, nessa atividade so escolhidas todas as ferramentas que sero utilizadas durante o desenvolvimento, sejam estas para a parte de programao como para automatizao dos processos adotados. Segundo Gibbs (2006), preciso tomar cuidado com os aspectos relacionados a esses processos quando se for escolher as ferramentas, tais como: No se deve utilizar ferramentas que sejam ricas em processos que

sejam pobres, pois o problema est no processo e no na ferramenta; importante distinguir ferramenta de automao de processo do

processo em si, pois se o processo for pobre (ineficiente), a ferramenta informatizar o sistema que continuar sendo pobre;

38 Uma vez reunidas todas essas informaes, j possvel construir-se um Plano de Desenvolvimento de Software, que um artefato dentro do RUP, 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 informaes citadas acima. A definio que RUP (2002) d para esse Plano de Desenvolvimento a de ser um documento que define o processo que ser seguido no projeto, ou seja, ele estabelecer um conjunto de passos e diretrizes que ter o objetivo de organizar as atividades, como citado acima.

39

3 EKD
O Enterprise Knowledge Development (EKD) uma metodologia que sugere uma forma sistemtica de se analisar, entender e documentar os processos dentro de uma Organizao e seus componentes (PDUA, 2004). Sendo resultado desse processo, um esclarecimento e descrio de como funciona o negcio, quais seus requisitos, quais as necessidades de mudanas e como faz-las. Dessa forma, o EKD no est ligado diretamente ao desenvolvimento de um sistema de informao (SI), mas as informaes por ele obtidas so de grande valia para o ciclo de desenvolvimento do software.

Uma caracterstica interessante do EKD em relao a outras metodologias o fato dele possuir uma ligao estreita com o desenvolvimento de sistemas de informao. A tabela abaixo ilustra as caractersticas dele e de outras caractersticas; note que ele possui a caracterstica de poder ser utilizado para especificao de requisitos.

40

Figura 2 Tabela comparativa entre algumas tcnicas de modelagem organizacional

Como essa tcnica possui um nmero maior de caractersticas ligadas ao desenvolvimento de software, ela foi escolhida para a construo da metodologia sugerida nesse trabalho, na qual o EKD ser utilizado como uma das ferramentas na Modelagem de Negcios.

41

3.1 Viso geral

A partir da dcada de 90 as empresas brasileiras comearam a sentir os efeitos do mundo globalizado (CASTRO, 2005). Com a necessidade de se acompanhar as novas tendncias mundiais, visando vantagem competitiva, iniciou-se no pas uma corrida tecnolgica, na qual a ordem era: automatizar os processos (PDUA, 2004). Porm, nessa nsia de se criar sistemas de informao que colocassem as empresas dentro da nova realidade, muitos empresrios e desenvolvedores de software no se preocuparam em utilizar o software como agente de mudana nos processos de negcio, tornando-o simplesmente um substituto do papel e da caneta, trazendo como nicas vantagens a agilidade e a organizao das informaes.

preciso fazer com que o software seja mais que isso. Mas para tanto, necessrio que se entenda o contexto em que o software est inserido, identificando qual ser o seu papel e o seu valor dentro da Organizao que o est adquirindo (RUP, 2002). Para isso, os desenvolvedores precisam estudar e entender a realidade do negcio para o qual seu produto est sendo feito, extraindo, assim, o mximo de informaes que sero teis para que a equipe desenvolvedora proponha idias inovadoras e solues que no somente automatizaro os processos, mas que iro melhorar a qualidade dos processos e aumentaro a produtividade.

Como se sabe, essa tarefa de extrao e anlise do conhecimento dentro das organizaes no uma tarefa fcil, pois ela envolve, entre diversos fatores, a relao humana, a imparcialidade scio-cultural, principalmente por parte dos analistas, e a diversidade dos tipos de negcios existentes. Assim, para atingir esses objetivos, precisa-se de uma metodologia que guie os passos na obteno desse conhecimento. a que entra a metodologia EKD. Sua funo auxiliar na anlise, planejamento, modelagem e mudana dos negcios atravs de tcnicas e mtodos que do suporte ao pensamento, raciocnio e aprendizado dos negcios dentro da Organizao (STIRNA, 2006), alm de facilitar a obteno dos requisitos

42 organizacionais, principalmente no que se refere a colaborao dos usurios (PDUA, 2004). Diante disso, o EKD ser o responsvel por preencher o vazio existente entre a parte relacionada a negcios e a relacionada a tecnologia, afinal, o EKD no uma abordagem diretamente ligada ao desenvolvimento de um sistema de informao, mas ligada anlise de negcio.

No contexto da Modelagem de Negcios, o EKD ser til para identificar como a Organizao funciona atualmente, qual rea de atuao do sistema de informao sendo desenvolvido, o que este sistema ir fazer e quais os critrios sero utilizados para avaliar quanto valor o sistema agregar aos processos atuais (CASTRO, 2005). importante lembrar que o quando a equipe desenvolvedora entende bem como a Organizao funciona e quais as suas necessidades, ela produz mais idias inovadoras tanto no que se refere ao software como a processos de negcio, melhorando a qualidade do produto final software e do processo de desenvolvimento.

Nesta seo, ser mostrado o que este mtodo EKD, quais seus objetivos, suas tcnicas e diretrizes, para ento se estudar qual a relao e utilidade desse mtodo dentro da Modelagem de Negcios, avaliando em quais situaes interessante utiliz-lo ou no, quais as possibilidades que ele traz e como ele afeta a Modelagem de Negcios e as fases iniciais do desenvolvimento do software. Com base nessas informaes, ser possvel, ento, chegar a uma concluso de qual a contribuio do mtodo EKD no alcance do objetivo final que agregar valor ao software.

3.2 A metodologia EKD

O EKD, como toda metodologia, possui uma descrio formal de tcnicas e mtodos a serem utilizados e qual a ordem dessas atividades na pesquisa da Organizao a fim de se obter algumas concluses. Sero apresentados nessa seo os

43 mtodos, i.e., quais caminhos seguir para alcanar os objetivos propostos, e as tcnicas, i.e., como percorrer esse caminho da forma adequada (TEIXEIRA, 2006), propostos pelo EKD.

O EKD resultado de pesquisas iniciadas em 1980 com o projeto Plantada, o qual foi refinado pelo SISU (Swedish Institute for Systems Development Instituto Sueco para o Desenvolvimento de Software), no final daquela dcada (PDUA, 2004). Depois disso, ainda passou pelo refinamento de outros projetos at se tornar ento o EKD, que apesar de ter origens na engenharia de requisitos (BARBALHO et. al., 2002), muito mais do que isso, pois o EKD se baseia no somente no modelo de engenharia de requisitos, mas nos seguintes modelos: Modelo de Objetivos: Representa os objetivos da Organizao,

concentrando-se na descrio das idias que iro traduzir suas intenes, fazendo com que questes como quais so os objetivos e suas respectivas prioridades sejam respondidas (STIRNA, 2006). Modelo de Regras de Negcio: Representa quais as regras regem os

negcios da empresa, delimitando os caminhos que podero ser trilhados para se alcanar os objetivos. Modelo de Conceitos: Neste modelo esto descritos alguns utilizados nos outros modelos, bem como seus

conceitos

relacionamentos. Modelo de Processos de Negcio: Descreve as atividades presentes

no negcio que so necessrias para que os objetivos sejam alcanados (BARBALHO, ROZENFELD & AMARAL, 2002) respeitando-se as regras do negcios, processos. Modelo de Atores e Recursos: Relaciona os atores presentes na mostrando tambm, como esto relacionados esses

Organizao, quais seus papis, atividades e responsabilidades dentro dessa. Modelo de Requisitos e Componentes Tcnicos: Este modelo til

quando o objetivo do EKD levantar requisitos para a construo de

44 um sistema de informao (BUBENKO, PERSSON & STIRNA 2001). O objetivo deste modelo fazer com que os requisitos levantados para a construo do sistema sejam coerentes com os objetivos, regras, atores e conceitos presentes na Organizao;

Cada um desses modelos dividido em componentes e possui uma notao para represent-los. Nas sub-sees seguintes sero apresentados esses modelos sobre a viso da Modelagem de Negcios, apresentando os componentes e suas caractersticas que se enquadram na Modelagem de Negcios. Apesar do EKD possuir uma notao oficial, ela no ser apresentada, pois o objetivo desse estudo extrair do EKD as prticas e idias que sero teis na Modelagem de Negcios, portanto o registro dos resultados dessa atividade no necessariamente devero seguir o padro adotado pelo mtodo EKD.

3.2.1 Modelo de Objetivos

O Modelo de Objetivos descreve o que a Organizao quer em relao ao seu negcio. Para isso, ele deve traduzir qual o sentimento dos dirigentes e funcionrios com relao a perspectivas futuras em relao ao negcio, problemas enfrentados, pontos fortes, pontos fracos e possveis alternativas que eles tenham em mente para se alcanar esse objetivos (BUBENKO, PERSSON & STIRNA 2001).

Os componentes desse modelo so: objetivos, problema, causa, limitao e oportunidade. De uma maneira prtica e clara, um objetivo algo que um membro da Organizao, ou vrios, desejam alcanar no futuro (BUBENKO, PERSSON & STIRNA 2001) em alguma das suas reas ou como um todo, respeitando suas limitaes que podem ser impostas por polticas internas ou externas. Os objetivos de uma Organizao podem ser classificados quanto a suas prioridades (STIRNA, 2006), o que d uma melhor organizao para a equipe que est realizando a modelagem, j que a prioridade estabelece uma relao de ordem de ao para se atingir os objetivos.

45 Alguns objetivos esto sujeitos a problemas, que podem impedir a Organizao de atingir estes objetivos, e, portanto, devem ter suas causas documentadas para que a equipe possa buscar solues ou preparar planos de contingncia. Por outro lado os objetivos podem tambm ser facilmente alcanados atravs das oportunidades, as quais devem ser anotadas pela equipe para que possam ser exploradas e, assim, gerar novas alternativas para viabilizao do alcance dos objetivos.

Para guiar esta atividade de modelagem de objetivos, algumas perguntas so propostas: Quais os atuais planos e objetivos da Organizao? Quais as prioridades desses objetivos? Existem problemas que possam afetar os objetivos? Existem oportunidades para melhor alcanar os objetivos? Qual a importncia do sistema no alcance dos objetivos?

3.2.2 Modelo de Regras de Negcio

O Modelo de Regras de Negcio possui algumas operaes comuns realizadas dentro da Organizao bem como os limites que rodeiam essas operaes. Essas regras de negcio devem ser modeladas em conformidade com o Modelo de Objetivos para que elas estejam consistentes com o modelo organizacional (STIRNA, 2006), ou seja, uma regra no deve relacionar um objetivo ou situao que no esteja presente ou subentendido no Modelo de Objetivos.

O Modelo de Regras de Negcio tambm ser extremamente til para a fase de especificao de requisitos, pois esses requisitos devero seguir e respeitar essas regras para que o software desenvolvido esteja em acordo com as relaes de negcio da Organizao.

46 Para melhor entender essa situao, analise o seguinte exemplo exemplo: Imagine que no Modelo de Regras de Negcio voc possua a seguinte regra: Um aluno que tenha atrasado mais de 3 mensalidades no pode entregar sua monografia. Durante a especificao de requisitos especificado que o sistema deve possuir uma funcionalidade de entrega on-line de monografia, i.e., os alunos entraro no sistema e carregaro nele o arquivo com sua monografia. Nessa situao, o requisito entrega de monografia dever ser implementado de uma maneira que ele cumpra a regra que probe a entrega de monografia de alunos que tenham mais de 3 mensalidades atrasadas.

Como se pode ver, as regras de negcio devem ser devidamente especificadas para que as eventuais mudanas realizadas na Organizao, incluindo a implantao de um SI, tragam realmente melhorias e no problemas ao negcio.

3.2.3 Modelo de Conceitos

O Modelo de Conceitos rene 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, ou seja, como Pdua (2004) diz, este modelo funciona como uma espcie de dicionrio para os outros modelos.

Para exemplificar essa caracterstica, suponha que no Modelo de Objetivos voc tenha o seguinte objetivo: Automatizar operaes de crdito; o objetivo est declarado, mas o que seria uma operao de crdito? Seria emprstimo? Financiamento? Para que o objetivo seja corretamente compreendido, necessrio que os conceitos citados sejam esclarecidos. a que entra o modelo estudado nesse tpico, pois nele que sero explicados esses conceitos, que no caso do exemplo, explicaria o que uma operao de crdito.

47 Portanto, para se realizar a modelagem conceitual, deve-se fazer um levantamento das entidades presentes no domnio, bem como seus atributos e relacionamentos, obtendo um modelo que procure se aproximar o mximo possvel do mundo real. Para isso, o responsvel por essa modelagem deve seguir algumas diretrizes: Fechar o escopo estabelecendo um cenrio do que ser modelado; Fazer um levantamento inicial dos conceitos envolvidos na

aplicao; Incluir no modelo somente os relacionamentos que sejam

significativos para o cenrio em questo; Antes de incluir um conceito, verificar a importncia dele na

aplicao (BUBENKO, PERSSON & STIRNA 2001) para saber se ele realmente necessrio e ele. Analisar a participao e quantidade de relacionamentos do

conceito para decidir qual nvel de detalhamento necessrio dar a

Dessa forma, importante que essas diretrizes sejam seguidas para que o responsvel pela modelagem de conceitos possa produzir um modelo que seja til e complementar para todos os outros modelos presentes, fazendo com que o modelo global, que composto por todos os modelos, possa ser completo e consistente.

3.2.4 Modelo de Processos de Negcio

O Modelo de Processos de Negcio procura definir os processos e atividades que compe o cerne da Organizao e geram valor para ela, bem como o fluxo de informaes que circula nessas atividades e processos. A ttulo de comparao, pode-se dizer que esse modelo muito parecido com os to conhecidos modelos de fluxos de dados (PDUA, 2004).

48 Para construo desse modelo, so definidos alguns componentes bsicos, a saber: Processo: Conjunto de atividades que consome uma entrada e

produz uma sada, podendo essa entrada e essa sada ser uma informao ou um material1. Processo externo: Conjunto de atividades que esto fora do escopo

da Organizao, mas que possuem participao direta em alguma atividade do domnio desta. Segundo Bubenko, Persson & Stirna (2001), os processos externos geralmente se encontram na fonte2 ou no sorvedouro3 de um processo interno.

Definidos esses componentes bsicos, j se tem condies de construir, pelo menos, um esboo do modelo, mesmo que de alto nvel. A verdade que tanto para o esboo como para a verso final os componentes so os mesmos, pois esse modelo relativamente simples em sua ilustrao, mas de certo modo complexo em sua definio. Isto , a quantidade de componentes usados para representao do modelo pequena, porm conseguir fazer uma representao adequada dos processos e atividades que ocorrem no mundo real, sem tirar e nem por, uma atividade no to trivial.

Uma forma interessante de se partir do esboo e chegar ao modelo final trabalhar com a decomposio de processos. Ela consiste no detalhamento iterativo de um processo inicialmente esboado, aumentando a profundidade da descrio conforme mais informaes a respeito do que se est modelando so obtidas. Um exemplo dessa situao dado por Bubenko, Persson & Stirna (2001) em uma situao de verificao de endereo de cliente:

1 2 3

Um artefato, um documento. Ex.: um boleto bancrio No incio, na alimentao do processo No fim, na sada do processo

49

Conj. Info 2 Processo 32 Conj. Info 1 Endereo

Endereo vlido Verificao de endereo do cliente

Conj. Info 3

Endereo invlido Figura 3: O processo da verificao de endereo de cliente em alto nvel. Considerado para esboo (BUBENKO, PERSSON & STIRNA 2001)

Conj. Info 2 Processo 32 Endereo vlido

Verificao de endereo do cliente

Conj. Info Rua

Processo 32.1

Verificao de Rua
Processo 32.2

Conj. Info 1

Conj. Info CEP

Verificao de CEP
Processo 32.3

Endereo
Conj. Info Cidade

Verificao de Cidade
Processo 32.4

Conj. Info Pas

Verificao de Pas

Conj. Info 3 Endereo invlido

Figura 4: O processo da verificao de endereo de cliente detalhado. Pode ser considerado bom para verso final (BUBENKO, PERSSON & STIRNA 2001)

50 Essa ilustrao mostra uma concepo inicial do processo e em seguida um detalhamento que j d mais informaes a respeito do processo sendo modelado. Lembrando que o indivduo que estiver realizando a modelagem deve julgar, sempre observando a dinmica da Organizao, quais processos necessitam ser detalhados ou no.

Para que seja mantida a consistncia com os outros modelos importante que sejam escolhidos os processos e atividades que estejam relacionados aos objetivos identificados no primeiro modelo, e que conseqentemente geraram os conceitos definidos no terceiro modelo, pois assim, os processos modelados certamente estaro fazendo uso de informaes descritas por componentes do Modelo de Conceitos (terceiro modelo).

Dessa forma, os processos e atividades a serem modelados devero ser escolhidos de acordo com sua relao aos objetivos e regras do negcio, sendo sempre verificados a presena dos conceitos e atores envolvidos nos seus respectivos modelos.

3.2.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 interdependncias e participaes nos objetivos e processos de negcio, i.e., um ator poder ser responsvel por uma determinada atividade ou pode buscar um particular objetivo (PDUA, 2004).

Dentro

da

Organizao,

interessante

se

estabelecer

uma

classificao dos tipos de atores e recursos possveis, para que os responsveis pela realizao dessa tarefa j possam ter uma orientao do que considerar no momento

51 da modelagem. Dessa forma, alm de definir os recursos humanos1 e no-humanos, o modelo tambm define outros dois tipos de recursos: Unidade Organizacional: Representa uma estrutura

organizacional, tal como um departamento, uma diviso, um setor, etc. Os indivduos presentes neste modelo geralmente possuem relao com alguma dessas unidades organizacionais. Papis: Definem um perfil de uma entidade. Podem ser delegados

tanto a indivduos como a unidades organizacionais. Por exemplo, um indivduo pode ter o papel de Gerente de Projeto e o departamento de finanas pode ter o papel de Administrador.

Dentro do modelo existem relaes entre os indivduos que caracterizam a dinmica dos envolvidos no negcio sendo modelado. Porm, esses relacionamentos puramente internos no acrescentariam nada ao modelo de negcio geral da Organizao, isto , o conjunto de todos os modelos, principalmente o de objetivos e o de processos de negcio. Dessa forma, fundamental que os atores e recursos identificados neste modelo sejam relacionados aos componentes dos outros modelos para que sejam estabelecidas as relaes de responsabilidade e dependncia entre eles. De acordo com a definio de Bubenko, Persson & Stirna (2001): Responsabilidade: , essencialmente, uma relao entre os atores

e os processos de negcios, as regras de negcio e os objetivos, alm da relao entre os prprios atores. Essa responsabilidade pode ser tanto no sentido do ator fazer parte da definio mais ampla desses modelos, definir alguns de seus componentes ou executar tarefas relacionadas a eles. Dependncia: Relao entre dois atores, no qual um precisa do

outro para obteno de algo como um recurso ou continuidade de realizao de um processo de negcio. Essa dependncia est

Indivduos, pessoas

52 intimamente ligada aos processos de negcios no que se refere dependncia causada por uma operao dentro de um processo, i.e., um ator s ter participao efetiva no fluxo de uma determinada atividade depois da participao de um outro; e est diretamente ligada s regras de negcio no que diz respeito dependncia causada pela necessidade de autorizao, i.e., um ator s poder realizar uma operao ou ter participao efetiva em um processo ou cenrio depois de passar pela autorizao de um outro ator.

Compreendido os componentes do modelo, pode-se notar a sua importncia para a anlise de negcio na medida em que ele complementa o sentido dos outros modelos, pois ele define quais so as pessoas, unidades organizacionais e recursos dentro da Organizao que esto ligadas a todos processos, regras e objetivos descritos nos outros modelos. Assim, a partir daqui, as solues encontradas para os problemas identificados podero ter um melhor direcionamento para os responsveis, fazendo com que os esforos sejam despendidos somente pelas pessoas que realmente esto envolvidas nas questes levantadas.

3.2.6 Modelo de Requisitos e Componentes Tcnicos

Como citado no incio desse captulo 3, o mtodo EKD no est necessariamente envolvido ao desenvolvimento de um sistema de informao, pois ele um mtodo de modelagem organizacional e no de levantamento de requisitos ou quaisquer outras atividades relacionadas ao ciclo de vida do desenvolvimento de um software. Porm, ele uma metodologia que tm sim como um dos seus objetivos, gerar informaes que sejam teis ao desenvolvimento de um sistema desse. Assim, o ltimo de seus modelos, o qual no utilizado em situaes nas quais no h o desenvolvimento de um software, aquele que est diretamente relacionado construo de um sistema de informao (PDUA, 2004): o Modelo de Requisitos e Componentes Tcnicos.

53 De acordo com Pdua (2004), o objetivo desse modelo direcionar a parte tcnica do desenvolvimento para os objetivos, processos, regras e atores da Organizao, de forma que o sistema a ser desenvolvido esteja coerente com as informaes levantadas nesses outros modelos. Em sntese, o modelo deve organizar as informaes obtidas de forma que elas sejam teis e precisas ao levantamento de requisitos e ao gerenciamento de riscos1 bem como a relao destes com os componentes tcnicos que iro compor o produto final do desenvolvimento.

Um fato que direciona melhor esse trabalho de organizar as informaes o modo como o modelo composto, pois ele dividido nas seguintes trs partes: Objetivos do Sistema de Informao: Motivado principalmente

pelos objetivos descritos no Modelo de Objetivos e pelas atividades descritas no Modelo de Processos de Negcio (BUBENKO, PERSSON & STIRNA 2001), esse componente expressa uma srie de objetivos de alto nvel do sistema de informao, levando-se em considerao todos os componentes do sistema. Problemas do Sistema de Informao: So riscos que podem se

tornar empecilhos ao alcance dos objetivos do SI. Requisitos do Sistema de Informao: so condies ou estados

expressados pelas propriedades do sistema que devem ser modeladas. Os requisitos sempre referenciam componentes do Modelo de Processos de Negcio, podem fazer referencia a componentes do Modelo de Atores e Recursos e do Modelo de conceitos. Os requisitos so divididos em dois tipos: Requisitos Funcionais: So funcionalidades especificadas para a execuo de aes completas pelo sistema, ou seja, expressam o comportamento

Um risco tudo que possa impedir o sucesso do projeto e que atualmente desconhecido ou incerto (RUP, 2002).

54 de entrada e sada do sistema (RUP, 2002). Estes requisitos, portanto, devem estar relacionados a algum dos processos descritos no respectivo modelo, j que as aes do mundo real que sero realizadas pelo sistema esto descritas a, alm de possuir clara referncia ao Modelo de Conceitos, pois nele que so esclarecidos os todos conceitos envolvidos na modelagem e isto inclui os utilizados no presente modelo. Requisitos no-funcionais: Descrevem, muitas vezes, atributos do sistema ou de seu ambiente que no subentendem funcionalidades propriamente ditas, tais como: segurana, desempenho e usabilidade. Estes requisitos possuem interferncia direta nos objetivos, requisitos e riscos do sistema, uma vez que ele trata de aspectos externos ao sistema que possuem influncia direta e expressiva no projeto, como restries polticas e econmicas.

Depois

de

levantadas

todas

essas

informaes,

feito

um

levantamento do atual potencial tecnolgico da Organizao que daro suporte ao sistema em desenvolvimento bem como quais mudanas sero sugeridas, avaliando-se os padres e restries existentes nestes componentes tcnicos que devero ser respeitados.

Dessa forma, ao final de todas essas atividades, ser formalizado um modelo que dar uma viso inicial dos requisitos e do cenrio no qual esses requisitos devero ser atendidos, fornecendo equipe uma perspectiva geral do que o sistema dever fazer e quais as condies tcnicas para isso.

3.3 O EKD e a Modelagem de Negcios

Todo o processo descrito acima tem o claro objetivo, dentro do escopo do estudo proposto, de auxiliar a Modelagem de Negcios na definio dos componentes da Organizao para a qual o software ser desenvolvido. Portanto, o

55 presente trabalho prope que o EKD seja utilizado na Modelagem de Negcios como a metodologia de extrao e gerenciamento de conhecimento sobre a Organizao-alvo, gerando informaes objetivas e bem delimitadas, as quais so os bens mais importantes para essa disciplina. A proposta sugerida nesse trabalho ser melhor explicada abaixo, na qual sero expostos os principais elementos do EKD escolhidos para serem utilizados na Modelagem de Negcios.

A fase inicial do EKD tem como primeiro e mais importante marco a primeira reunio de modelagem, que pode ser no formato de um seminrio. Segundo Bubenko, Persson & Stirna (2001), fundamental que sejam escolhidos as pessoas certas para essa reunio, a qual no pode falhar, pois dificilmente haver uma segunda chance, j que nessa reunio: sero estabelecidas as relaes de empatia entre os membros da

equipe e os da Organizao; ser passado para a equipe de modelagem uma viso geral sobre a

Organizao; sero abordados alguns dos atuais problemas da Organizao; e ser passado para os membros da Organizao qual ser o papel e

a participao deles durante essa fase de modelagem organizacional;

Portanto, na preparao dessa reunio, importante que sejam levantadas algumas das questes acima com cada um dos participantes, para que se possa conduzir essa reunio da forma mais coerente e produtiva possvel. Durante estas entrevistas devem ser construdos alguns esboos do Modelo de Objetivos, do Modelo de Conceitos e do Modelo de Atores e Recursos que serviro para o planejamento e realizao dessa primeira reunio que ter como foco a modelagem das regras e processos de negcios, fazendo uma juno dessas informaes com as obtidas nas entrevistas e refinadas nessa reunio. Assim, de fundamental importncia que a Organizao-alvo e a equipe de modelagem iniciem o processo em

56 plena sintonia para que as prximas reunies e atividades realizadas pela equipe de modelagem possam ser devidamente planejadas e executadas.

Claramente, nota-se que essa fase inicial do EKD est diretamente ligada a 2 dos 4 objetivos da modelagem de negcios, a saber: Assegurar que os clientes, usurios e desenvolvedores tenham um

entendimento comum da Organizao-alvo. Entender a estrutura e a dinmica da Organizao na qual um

sistema deve ser implantado (a Organizao-alvo).

Continuando esse processo de aplicao do EKD, a equipe, aps realizao da primeira reunio, partir para a segunda na qual sero realizadas as seguintes tarefas: revisar os trabalhos realizados na primeira reunio para dar

continuidade ao desenvolvimento das atividades a partir de onde elas foram interrompidas; expandir e/ou corrigir os modelos j existentes utilizando as novas

informaes obtidas criar novos modelos na medida do necessrio planejar e sugerir trabalhos futuros, dando j um direcionamento

com relao ao futuro da Organizao designar tarefas a membros da Organizao que estejam

participando do trabalho para que ele possa contribuir da melhor maneira possvel e ser til para a equipe.

Possivelmente, apenas uma segunda reunio no seja suficiente para se estabelecer todos os modelos (BUBENKO, PERSSON & STIRNA 2001) e, assim, atingir todos os objetivos da Modelagem de Negcios. Portanto, bem provvel que mais uma ou duas reunies sejam teis para que os modelos todos estejam bem definidos e coerentes. Ao final dessas reunies, ser avaliado se os refinamentos dos modelos j

57 alcanaram seus estgios finais ou se necessitaram de mais ajustes, o que levaria ao agendamento de outras reunies. Portanto, essa etapa final do EKD s terminar quando todos os modelos estiverem satisfatoriamente completados, inclusive o Modelo de Requisitos e Componentes Tcnicos, fornecendo informaes necessrias aos profissionais que iro trabalhar nas outras fases do desenvolvimento. Assim, quando essas reunies no forem mais necessrias, significar que os objetivos dessas atividades foram alcanados, sendo que dentre eles, esto os especificados pelo RUP (2002) dentro da disciplina de Modelagem de Negcios: Entender os problemas atuais da Organizao-alvo e identificar as

possibilidades de melhoria. Derivar os requisitos de sistema necessrios para sustentar a

Organizao-alvo.

Dessa forma, pode-se evidenciar de forma bem direta a relao entre os objetivos descritos para a Modelagem de Negcios e os alcanados pelo EKD, mostrando como essa metodologia atende e inclusive supera os objetivos propostos.

58

4 Artefatos e Notaes
Neste captulo, sero estudados quais os artefatos e notaes so teis para que todo o trabalho da Modelagem de Negcios possa ser registrado e aproveitado, afinal, no se pode achar que todos os membros da equipe lembraro com detalhes das informaes levantadas durante a realizao das atividades descritas acima, at porque muitos deles nem participaro de todas elas.

Portanto, esta seo trata da parte relacionada documentao do software que necessria durante a fase de iniciao, em especial na Modelagem de Negcios. O objetivo no mostrar todos os artefatos e notaes existentes que podem ser usados nas atividades dessa disciplina e nem que todos os mostrados aqui sejam sempre usados, antes, a finalidade das prximas sees apresentar alguns artefatos chaves que podem ser usados para registrar as informaes levantadas de uma forma eficiente.

Apesar da Modelagem de Negcios tratar de aspectos presentes tanto no lado do desenvolvedor quanto no do cliente, a documentao direcionada para os desenvolvedores geralmente melhor utilizada, pois os clientes no compreendem muitas vezes (ou no querem compreender) os documentos que contm as anlises e modelagens realizadas (GIBBS, 2006). Dessa forma, o que os clientes querem ver so os resultados, querem utilizar o sistema que est sendo desenvolvido para poderem se certificar de que o projeto est correndo como previsto. Mas para que essa eficincia seja alcanada, fundamental que o projeto tenha uma boa documentao para que a equipe tenha registros das fases de desenvolvimento do software, para que a comunicao entre os desenvolvedores seja boa e para que tanto os desenvolvedores quanto os clientes possam saber em que estado o projeto se encontra.

O estudo dessa seo est dividido em duas partes: notaes e artefatos. Na seo relativa notao, sero apresentados os elementos utilizados na

59 construo dos artefatos propostos para a Modelagem de Negcios. Apesar dos elementos tambm serem considerados artefatos, eles sero estudados na seo de notao, pois o foco do estudo referente aos artefatos ser a construo de modelos que englobem mais de um desses elementos e que ilustrem uma determinada situao, um determinado contexto.

4.1 Notaes
A escolha de uma notao fundamental para que a documentao fique padronizada, evitando que haja as catastrficas falhas de comunicao entre os membros da equipe e com o cliente. Uma notao uma forma de representao de algo atravs da utilizao de um sistema especial de marcas e caracteres (Wordnet, 2006), com o objetivo de facilitar a construo e compreenso dos modelos criados durante determinadas atividades.

Por muito tempo vrias empresas adotaram determinada notao nas documentaes feitas em todos os seus setores, inclusive no de Tecnologia da Informao (TI). Em particular, nessa rea da informtica, houve uma movimentao por parte da comunidade com o intuito de se padronizar uma notao que deveria ser utilizada em todos os projetos de TI pelo mundo. Ao invs de se criar uma notao toda nova, a partir do zero, os responsveis por essa padronizao decidiram reunir algumas das notaes existentes que estavam sendo comumente utilizadas e criar uma linguagem de modelagem unificada, a Unified Modeling Language (UML).

Lanada a primeira verso estvel em 1991 pela Object Management Group (OMG), essa linguagem unificada composta por uma coleo de smbolos que podem ser divididos em 3 blocos: coisas, relacionamentos e diagramas (DEWALT, 1999) que combinados fazem com que todas as etapas e aspectos do desenvolvimento, via de regra, possam ser modelados visualmente, tornando a documentao mais prtica, intuitiva e no-ambgua. Isso faz com que, por exemplo, o analista de negcio possa

60 usar a mesma notao e ferramenta para documentar os processos de negcios que o arquiteto de software usa para documentar a construo do sistema (HEUMANN, 2001), possibilitando que todos os envolvidos no desenvolvimento falem a mesma lngua e com isso seja aumentada e melhorada a produtividade.

Apesar de existirem diversas notaes, nesta seo, ser apresentada apenas a UML, pois alm de ser o padro adotado mundialmente, ela a utilizada dentro do RUP, pois ela d suporte a todas as atividades propostas por ele. Dessa forma, o objetivo ser apresentar aqueles componentes da UML que esto relacionados Modelagem de Negcios.

4.1.1 UML e a Modelagem de Negcios

As atividades realizadas durante a Modelagem de Negcios no tm sentido de serem realizadas se elas no produzirem resultados que podem ser utilizados pelas fases subseqentes do desenvolvimento do software. Afinal de contas, o objetivo da Modelagem de Negcios, obviamente, produzir uma srie de modelos que serviro como planos para conduo dos negcios, sejam estes usados para priorizao dos objetivos, para a negociao de uma proposta, entre outras possibilidades (ERIKSSON et. al., 2000).

Assim como acontece com o RUP, por exemplo, a UML no deve ser encarada como um produto final no-configurvel, i.e., no existe somente uma maneira de utilizar a UML para modelar o que se deseja (ERIKSSON et. al., 2000). E no caso da Modelagem de Negcios, isso no diferente: no existe uma forma correta de se usar a UML nem to pouco a idia de que existem componentes dessa linguagem que so indispensveis para se construir os modelos resultantes das atividades desta disciplina. O que se deve ter em mente que todas as informaes coletadas devem estar disponveis de uma forma clara, simples e no ambgua, ou seja, de uma forma que todos entendam se precisar fazer muito esforo. por isso que a utilizao da

61 UML j um primeiro passo, pois como ela a notao padro, provvel que todos os envolvidos no processo j a conheam e no necessitem de explicaes de ordem tcnica a respeito do modelo. Tambm deve ser levada em conta na hora de se decidir quais modelos produzir e quais componentes da UML escolher para a documentao da Modelagem de Negcios, aquela mxima que diz: menos mais, pois as atividades dessa disciplina podem subentender muitos diagramas com vrios componentes e isso pode acabar gerando um monte de documentao que tornar confuso o entendimento daqueles que a usaro, uma vez que tero que aprender sobre a documentao, sendo que uma documentao mais enxuta, direcionada1 e objetiva produzir resultados melhores em menos tempo e com menos trabalho. Note que no est sendo defendida aqui a falta de documentao, mas a documentao inteligente.

Diante disso, sero apresentados a seguir alguns componentes e diagramas da UML que so comumente utilizados na Modelagem de Negcios, pois apesar deles serem escolhidos conforme a necessidade de cada projeto, bom que se tenha por onde comear para depois partir para a customizao. Ator de Negcio: So os usurios no ponto de vista do negcio,

i.e., clientes, parceiros, vendedores, entre outros (KRUCHTEN et. al, 2000). So indivduos que esto do lado de fora das fronteiras2 do sistema e que geralmente iniciam os processos de negcio (GIBBS, 2006).

Figura 5: Exemplo de Ator de Negcio (RUP, 2002)

1 2

Que tenha o propsito de ser feita para auxiliar uma atividade futura que com certeza ser realizada Indivduos que no pertencem Organizao-alvo ou que fazem parte de um setor da Organizao que no est no escopo da modelagem atual.

62

Trabalhadores de Negcio: So indivduos que desempenham um

papel dentro da Organizao (KRUCHTEN et. al, 2000). Relacionam-se entre si e manipulam as entidades de negcio, as quais sero descritas no prximo item. Ou seja, so os trabalhadores da Organizao-alvo que esto dentro do escopo do modelo.

Figura 6: Exemplo de Trabalhador de Negcio (RUP, 2002)

Entidade de Negcio: So os objetos, as coisas que os de negcio utilizam, gerenciam ou produzem

trabalhadores

(KRUCHTEN et. al, 2000). Podem ser encaradas como materiais manipulados e produzidos na realizao dos casos de uso de negcio.

Figura 7: Exemplo de Entidade de Negcio (RUP, 2002)

Caso de Uso de Negcio: So os resultados das sadas dos

processos de negcios (HEUMANN, 2001). Um caso de uso de negcios descreve o desempenho de uma seqncia de aes que produz um

63 resultado de valor observvel1 a um determinado ator de negcios (RUP, 2002).

Figura 8: Exemplo de Caso de Uso de Negcio (RUP, 2002)

Estado inicial: Indica o ponto de partida do modelo (ANQUETIL,

2006), marca a entrada de um processo.

Figura 9: Estado Inicial (RUP, 2002)

Atividade ou Estado de uma atividade: Representam a realizao de um conjunto de aes (atividade) ou uma etapa do fluxo de trabalho.

Figura 10: Exemplo de uma Atividade (RUP, 2002)

Pode ser percebido e medido (RUP, 2002).

64 Estado Final: Indica o trmino do diagrama (ANQUETIL, 2006),

marca a sada de um processo.

Figura 11: Estado Final (RUP, 2002)

Deciso: Ponto em que o fluxo tomar um sentido ou outro dentro

do diagrama baseado em uma condio que explicitada na sada dessa deciso. Assim como utilizado para realizar a separao do fluxo, tambm deve ser usado para sincronizao deste (HEUMANN, 2001)

Figura 12: Deciso (RUP, 2002)

Sincronizao: Utilizado para indicar fluxos de atividades que iro

ocorrer em paralelo. Tambm so usados para sincronizar essas atividades.

Figura 13: Barra de sincronizao (RUP, 2002)

Raias (swim lanes): So usados para fazer a separao de

responsabilidades dentro do fluxo. So linhas verticais que criam reas para as atividades serem inseridas, sendo que cada uma dessas reas de responsabilidade de um setor da organizao, de um indivduo ou de um papel.

65

Figura 14: Exemplo de Raias (RUP, 2002)

Exemplos de utilizao desses componentes podem ser encontrados na Figura 16, pgina 71, e na Figura 18, pgina 74, as quais ilustram dois diagramas onde esses elementos so utilizados

4.2 Artefatos
Dentro da disciplina da Modelagem de Negcios, vrios artefatos podem ser produzidos, os quais so descritos no RUP. Porm, no necessrio que todos os artefatos apresentados nesse framework sejam produzidos, pois cada um tem sua finalidade e, portanto, o que deve ser avaliado a importncia e necessidade deles para o projeto; aqueles que forem julgados importantes devem ser includos no projeto e os que no forem, deixados de lado.

Uma observao feita por Kroll & Krunchten (2002) que importante destacar que as etapas do desenvolvimento do software no devem estar amarradas aos artefatos, ou seja, uma fase ou etapa de software no encerrada quando os artefatos iniciados naquela fase so terminados, mas quando eles atingem certo grau de maturidade.

Nesta seo sero apresentados alguns artefatos que so teis para as duas etapas bsicas em que foi dividida a Modelagem de Negcios: Aprovao do Projeto e Planejamento do Desenvolvimento, levando-se em considerao que o projeto est sendo desenvolvido por equipes pequenas, de at 7 desenvolvedores.

66 Alguns artefatos servem para as duas etapas, porm eles sero especificados na subseo relativa etapa que mais os utiliza.

4.2.1 Artefatos Utilizados na Aprovao do Projeto

Durante a aprovao do projeto, o importante definir bem do que se trata o projeto proposto e qual o tamanho estimado deste, o que implica em passar para a equipe uma viso clara de quem a Organizao-alvo, o que ela quer nesse projeto e quais as possibilidades e empecilhos existentes atualmente nos seus negcios que pode ter alguma influncia no projeto.

A seguir sero apresentados os artefatos que so teis para a equipe na etapa de aprovao do projeto, contendo uma breve descrio, os benefcios e uma ilustrao simples de cada um.

4.2.1.1 Glossrio
Contm definies importantes utilizadas no projeto (RUP, 2002), sejam estes termos oriundos da anlise de negcio ou do desenvolvimento do projeto. Muitas vezes este artefato deixado de lado por parecer no ter muita importncia ou ser muito trivial (GIBBS, 2006), porm ele possui 3 serventias fundamentais: Auxiliar novos integrantes do projeto a se situarem mais

rapidamente no contexto do projeto, medida que as terminologias, abreviaturas e acrnimos utilizados no projeto esto todas nesse glossrio (GIBBS, 2006); Serve como instrumento de padronizao da comunicao,

prevenindo a equipe de uma das causas mais comuns de mal-entendido e falha de comunicao: a falta de padro nas terminologias utilizadas (KROLL & KRUCHTEN, 2002).

67 Evitar que os termos chaves utilizados no projeto sejam passados

de um membro para o outro individualmente, por osmose, sem nenhum registro, pois esse meio muito frgil e no confivel, na medida em que ele no tem garantia de atingir toda a equipe, passvel de esquecimento e uma mudana pode no ser informada a todos os membros, gerando graves inconsistncias de informaes vitais.

Figura 15: Parte de um Glossrio

A importncia desse glossrio na etapa de aprovao do projeto percebida principalmente no momento de se elaborar uma proposta para o cliente aprovar, pois o responsvel por escrev-la dever faz-lo utilizando a linguagem do cliente (RUP, 2002) para que ele possa compreender perfeitamente a proposta. Como os termos do glossrio foram capturados durante a anlise de negcio junto ao cliente, a equipe responsvel pela elaborao da proposta saber exatamente quais termos usar para que o cliente entenda perfeitamente o que est sendo colocado. Do lado da equipe, o glossrio importante para que haja entendimento sobre o que o cliente deseja, qual o tamanho do projeto e quais as partes envolvidas. Por exemplo: uma parte de um projeto de um hospital consiste no envio de informaes para a ISS. Se ISS no projeto significar International Space Station e isso no estiver em um glossrio, a equipe pode supor, por lgica, que ISS significa Instituto da Sade Social, o que causaria uma catstrofe.

68 Dessa forma, notvel que um glossrio indispensvel para a etapa de aprovao do projeto, para que todos os envolvidos possam falar a mesma lngua e assim evitar falhas de comunicao que so os maiores causadores de problema durante essa fase do projeto.

4.2.1.2 Viso do Negcio

Esse documento contm informaes sobre a estrutura da

Organizao-alvo, resultantes de uma anlise de negcio inicial e contm j uma viso geral do que o projeto dever produzir ao seu final (KROLL & KRUCHTEN, 2002). Isso significa que a equipe ir ter em mos um documento que esclarea questes relativas aos tipos de servios e produtos oferecidos pela Organizao, quais as suas metas, quais setores dela sero afetados pela implantao do projeto, quais melhorias nos processos o sistema construdo ir acarretar, quais os objetivos da Organizao de modo geral e quais os relacionados ao sistema, entre outros. Tambm ser colocado nesse documento uma lista de funcionalidades que indica quais os servios o sistema ir prover para os usurios para que as necessidades identificadas sejam atendidas.

Uma forma interessante de se produzir esse documento elabor-lo como se fosse a proposta para o cliente, na qual voc incluiria um panorama geral da Organizao, sobre o sistema proposto e qual o papel desse sistema dentro da organizao. Adotando-se o formato de proposta, interessante tambm j se colocar nesse documento algumas estimativas de quais metodologias sero utilizadas, como o projeto ser organizado, enfatizando qual a participao do cliente nele, quais sero os custos de tempo e dinheiro necessrios, entre outros (RUP, 2002).

Esse formato proposto por Pollice et. al (2004) que ainda sugere que esse documento seja elaborado em formato de panfleto, para que ele seja mais atrativo ainda ao cliente.

69

Figura 16: exemplo de um documento de Viso em forma de panfleto

No captulo relativo abordagem prtica sero mostrados como se extrair os principais componentes desse documento de Viso tratando-o como uma proposta, porm 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 informaes que o modelo tradicional, porm a sua construo exige outras tcnicas que esto fora do escopo deste estudo.

Assim, a importncia desse artefato para a aprovao do projeto notvel, pois adotando-se a sugesto dada acima, este documento ser a prpria proposta entregue ao cliente e equipe.

Um exemplo de proposta em forma de panfleto pode ser verificado no Apndice A e de uma proposta no formato tradicional no Apndice 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 negcio da Organizao-alvo o projeto

70 afetar e qual a sua importncia em cada uma delas para que se possa bolar uma estratgia inicial de como se desenvolver o projeto e que, com base nessas informaes, j possa ser feito o planejamento da fase de Elaborao (KRUCHTEN et. al, 2000). Essa estratgia de desenvolvimento do projeto ser mais bem estruturada e especificada na fase de elaborao, mas ter como ponto de partida esse esboo formulado na fase de iniciao, o que leva a concluir que essa etapa de Planejamento do Desenvolvimento constitui uma espcie de transio da fase de iniciao para a elaborao. Portanto, fundamental que os elementos utilizados na definio da estratgia inicial estejam bem documentados para que a fase de elaborao tenha recursos suficientes e completos para realizar suas atividades.

4.2.2.1 Modelo de Casos de Uso de Negcio

Este modelo descreve os processos de negcio da Organizao e suas interaes com as partes externas como clientes e parceiros (RUP, 2002). Um caso de uso de negcio uma representao em alto nvel de um processo de negcio 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 negcio estejam montados e bem compreendidos por todos (GIBBS, 2006).

Na construo do modelo de casos de uso de negcio, deve-se ter em mente que ele deve informar a quem o consulta como os clientes e parceiros utilizam o negcio da Organizao-alvo, isto , quais so os negcios envolvidos e quais os casos de uso deles. Uma forma alternativa se pensar que um caso de uso de negcio documenta (intitula) o fluxo de um determinado negcio (HEUMANN, 2001).

Os casos de uso de negcio so formados basicamente por atores de negcio, casos de negcios mostrados na seo referente a notaes 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: Extenso: Quando parte de um caso de uso de negcio for

opcional, i.e., quando ele no estiver sempre presente no processo de negcio que compe esse caso de uso, ele pode ser colocado para fora como sendo um outro caso de uso de negcio que estende o caso de uso de negcio base1. Incluso: A incluso usada quando alguma(s) parte(s) de um caso

de negcio s tiver importncia pelo resultado produzido por ele, ou seja, no importa o seu mtodo para o caso de uso de negcio base, ele no compe diretamente o corpo desse caso de uso. Para justificar a separao dessa parte preciso que ela esteja presente em mais de um caso de uso de negcio ou que a separao dela facilite o entendimento do modelo. O que acontecer que essa parte consistir em um outro caso de uso e ser includo dentro do caso de uso de negcio base e poder ser includo por outros casos de uso de negcio do modelo. Generalizao: Se forem identificadas semelhanas entre os casos

de uso de negcios, eles podem ser divididos e ter as partes iguais agrupadas em um caso de uso de negcio pai e as diferenas serem colocadas em casos de uso de negcios que herdam desse pai (RUP, 2002).

Lembrando que esses relacionamentos devem ser usados somente se eles facilitarem a compreenso do modelo, portanto preciso tomar muito cuidado ao utiliz-los para no a complicar feita o modelo que esses (RUP, 2002). Outra observao no

importantssima

ser

relacionamentos

especiais

necessariamente surgem na criao do modelo, mas durante o desenvolvimento de

Caso de uso original que foi modificado devido a incluso ou excluso de sua composio (RUP, 2002).

72 outros modelos, como os diagramas de atividades. Porm como o desenvolvimento iterativo, conforme so identificadas caractersticas no processo de negcio que justifique as alteraes no modelo, elas devem ser feitas.

Figura 17: Exemplo de caso de uso de negcio (RUP, 2002)

4.2.2.2 Diagrama de Atividades

Depois de levantados os casos de uso de negcio, interessante que esses caso de uso sejam analisados mais detalhadamente. Para se entender melhor o que cada um desses casos de uso realiza e qual a participao dos atores nele interessante que seja montado um diagrama de atividades (HEUMANN, 2001).

O diagrama de atividades o principal diagrama da UML utilizado para representar os processos de negcio que ocorrem dentro da Organizao-alvo. Portanto, um diagrama de atividades descreve um fluxo de trabalho e explora a ordem

73 das tarefas ou das atividades que realizam os objetivos e metas do negcio explicitado nos casos de negcio, sendo que uma atividade pode consistir de uma tarefa manual ou automatizada (RUP, 2002).

Assim, pode-se notar que o diagrama de atividades importantssimo para a equipe de desenvolvimento, na medida em que ele descrever como so os processos que acontecem dentro da empresa, principalmente em questes de entradas e sadas, pois o sistema desenvolvido dever atender esse processo, recebendo as entradas descritas e gerando as respectivas sadas. Ao criar esses diagramas de atividades, a equipe ter tambm um documento que servir como consulta na hora de se realizar a modelagem de domnio, pois esses processos definiro muitos dos relacionamentos entre as classes desse domnio.

O diagrama de atividades composto basicamente por um estado inicial, atividades, incluindo transies entre elas e estruturas de controle como os elementos de deciso e sincronizao, e o estado final. A Figura 17 ilustra esses componentes e a relao entre eles.

74

Figura 18: Exemplo de diagrama de atividades. No diagrama acima esto apontados os componentes bsicos de um diagrama de atividades. (RUP, 2002)

Apesar de esse diagrama atender s necessidades bsicas de representao das atividades que acontecem dentro da Organizao, ainda existe uma variao desse diagrama que contm elementos chamados de raias (swim lanes), mostrando qual trabalhador ou entidade da Organizao - explicados no prximo tpico realizam determinada atividade (HEUMANN, 2001). A Figura 18 ilustra esse diagrama.

75

Figura 19: Diagrama de atividades utilizando raias (swim lanes)

4.2.2.3 Modelo de Objetos de Negcio

Este modelo complementar ao modelo de casos de uso de negcio, que diz o que ser feito, pois este modelo diz como ser feito (HEUMANN, 2001). Ele captura as responsabilidades e conceitos importantes dentro do negcio da Organizao, e como eles se relacionam entre si (KROLL & KRUCHTEN, 2002).

O modelo exposto nesta seo possui uma funo importantssima: transio do ambiente de negcios para o ambiente de tecnologia. Ele o produto final da etapa de compreenso do negcio realizado pela Organizao-alvo, em se tratando das entidades presentes nessas relaes, e do papel do software dentro dela. Esse modelo apresenta caractersticas transitrias em relao ao tipo de pensamento, uma vez que ele ainda construdo na viso do negcio, mas utilizado no ponto de vista tecnolgico, na qual as idias esto relacionadas a softwares.

76 Quando vamos realizar a modelagem dos objetos de negcio, nos deparamos com 3 possibilidades de criao do modelo: criar um modelo com foco na extrao dos elementos do domnio:

neste caso o que feito a construo de um modelo chamado modelo de domnio, que consiste em capturar as classes de entidades mais importantes do domnio e como elas se relacionam entre si. criar um modelo com foco na reengenharia de negcios: neste

caso, o objetivo fazer uma reformulao no negcio da Organizao, portanto, necessrio que sejam feitos 2 modelos de objeto: uma descrevendo a situao atual da Organizao e um descrevendo como ela ficar depois da reestruturao (RUP, 2002). no criar nenhum modelo haja vista que todos integrantes da

equipe j conhecem bem o domnio do negcio, i.e., os trabalhadores, as entidades e as relaes entre eles.

Um modelo de objetos de negcio nada mais do que um diagrama das classes de objetos envolvidos no negcio e os seus relacionamentos, sendo que essas classes esto dividas em 2 categorias: trabalhadores de negcio e entidades de negcio, os quais foram descritos na seo anterior. Assim, enquanto diagrama de classe, esse modelo permite que existam entre os elementos as relaes como herana, agregao e associao de modo geral, o que caracteriza este modelo como sendo de transio entre a Modelagem de Negcio e o incio do desenvolvimento (RUP, 2002).

Para se construir este modelo, primeiramente so identificados os trabalhadores da organizao e os recursos que eles utilizam nos processos de negcio. Depois, so definidos esses trabalhadores como trabalhadores de negcio e os recursos como entidades de negcio. Em seguida, so construdos os

relacionamentos entre esses trabalhadores, entre as entidades e entre os

77 trabalhadores e as entidades, de modo que sejam ilustrados no modelo como se do os diversos casos de uso de negcio da Organizao. A figura abaixo ilustra esse modelo.

Figura 20: Modelo de objetos de negcio ilustrando um caso de uso de negcio de Check-in Individual (RUP, 2002)

Para dar um detalhamento maior de um determinado o fluxo de atividades envolvido no modelo e como os objetos se comportam nele, interessante se criar um diagrama de atividades alternativo que contm as transies entre, alm das atividades, os objetos marcados com seus respectivos estados atuais. Estas transies entre os objetos so chamadas de fluxo de objetos (RUP, 2002). Alm disso, so utilizadas as raias para representar os trabalhadores de negcio e as entidades para representar os objetos. Em baixo do nome dos objetos colocado entre colchetes qual o estado atual do objeto. A figura abaixo um exemplo de um diagrama de atividades com fluxo de objetos.

78

Figura 21: Um diagrama de atividades com fluxos de objetos mostrando como um pedido muda de estado durante o processamento de um pedido.

Esse tipo de abordagem proporciona equipe um ganho de tempo e qualidade na modelagem tecnolgica do sistema, pois ao mesmo tempo em que a equipe ter uma parte do trabalho j feita, o diagrama de classes inicial j estar extremamente coerente com o que o cliente deseja que o sistema faa, pois ele foi construdo com foco no negcio do cliente e no foco no sistema de informao; afinal o objetivo real no simplesmente implementar um software, mas resolver os

79 problemas existentes na Organizao-alvo e propor novas possibilidades que iro dar ao cliente vantagens competitivas no mercado.

Ao final da construo do modelo, importante que se tenha garantia de um bom trabalho, i.e., preciso saber o que se quer e se isso foi conseguido. Assim, depois de terminada a construo do modelo, trs verificaes devem ser feitas: Todas as atividades descritas nos casos de uso de negcio esto

sendo representadas pelos objetos, em conjuntos, do modelo? A viso que o modelo de objetos criado proporciona sobre a

Organizao adequada? J possvel se extrair do modelo algumas classes para entrarem

no plano de implementao?

Caso essas trs verificaes tenham sido feitas, o modelo ter grandes chances de estar correto e, principalmente, de ter alguma utilidade para os desenvolvedores do sistema na etapa seguinte do processo, uma vez que o modelo de objetos de negcios um artefato que usado como transio entre a coleta de informaes do negcio da Organizao-alvo e o incio do desenvolvimento do sistema.

80

5 Abordagem Prtica
Depois de estudadas diversas tcnicas e metodologias, preciso que se d uma abordagem prtica para que essa mescla dos conhecimentos faa algum sentido e tenha alguma utilidade. Neste captulo, sero colocados em prtica todos os conceitos estudados at o momento, de forma que se torna visvel como a aplicao dessas tcnicas e metodologias relativas Modelagem de Negcios agrega valor ao software.

situao

descrita

nas

prximas

sees

referente

ao

desenvolvimento da Modelagem de Negcios realizada durante a fase inicial do segundo projeto de construo de alguns mdulos para a Intranet do Departamento de Computao da UEL. Parte da juno desses elementos pode ser visto de forma mais concreta ainda no Apndice B Proposta Tradicional.

5.1 O EKD e a Aprovao do Projeto

Conforme estudado no captulo A disciplina de Modelagem de Negcios, o primeiro marco das atividades relacionadas essa disciplina se d na aprovao do projeto, e para isso possa acontecer, preciso que tanto o cliente quanto a equipe desenvolvedora aprovem os termos colocados. A metodologia EKD possui diretrizes que basicamente mostraro ao cliente como sua Organizao se encontra atualmente, onde ela quer chegar e quais as possibilidades de isso acontecer. Portanto, o EKD til principalmente na hora de se formalizar a proposta que dever ser aprovada pelo cliente, pois ao se utilizar as tcnicas descritas por esta metodologia, o documento da proposta se torna um verdadeiro folder de propaganda, porm com todas as informaes, boas e ruins (problemas do cliente), bem esclarecidas e colocadas.

81 As metodologias, na maioria das vezes, se mostram mais simples na teoria do que na prtica e com o EKD no diferente. Porm, essa dificuldade vem do fato das pessoas que aplicam as metodologias no as adaptarem s suas reais necessidades, i. e., elas utilizam recursos da metodologia para resolver problemas que elas no tm na verdade. Nesta seo ser apresentado qual o papel do EKD dentro do desenvolvimento, quais conceitos e prticas desta metodologia so teis nesse contexto e qual o valor que essa metodologia ir agregar ao software de maneira geral.

Afinal, deve-se ter em mente que uma Organizao movida por objetivos, metas e resultados, portanto, a proposta deve especificar da melhor forma possvel os objetivos da Organizao que o software ir contribuir para atingir.

5.1.1 Modelo de Objetivos

Como estudado no tpico referente, o Modelo de Objetivos dentro do EKD descreve objetivos da Organizao, independente da existncia de um sistema de informao. Portanto, a finalidade do Modelo de Objetivos dentro da Modelagem de Negcios, e mais concretamente dentro da elaborao da proposta de

desenvolvimento de software, mostrar quais objetivos da Organizao a serem atingidos (BUBENKO, PERSSON & STIRNA 2001), alguns problemas para atingir esses objetivos, bem como o software ir resolv-los, e novas oportunidades, i.e., como o software ir fazer com que os objetivos sejam mais facilmente alcanados.

A utilizao desse sub-modelo do EKD na elaborao da proposta proporciona ao documento da proposta uma maior objetividade e uma melhor especificao de qual o papel do software dentro da empresa e o que ela vai ganhar adotando este sistema, alm da possibilidade de se identificar possveis oportunidades de inovaes para os processos atuais que iro agregar mais valor ainda ao negcio realizado pela empresa.

82 Na construo do Modelo de Objetivos, uma estratgia interessante criar objetivos de alto nvel, que estaro relacionados ao sistema como um todo e depois refinar (PDUA, 2004) cada um dos objetivos em sub-objetivos, relacionando-os s funcionalidades (mdulos) que compe o sistema. Ou seja, cada mdulo do sistema ter seus objetivos, sendo que cada objetivo pode estar relacionado a mais de um mdulo ao mesmo tempo.

Na elaborao da proposta, fundamental que esses objetivos estejam claramente especificados, pois so eles que iro dizer aos membros da Organizao o porqu do investimento.

Portanto, para guiar a construo desse modelo e inseri-lo na proposta de software, deve-se responder s seguintes perguntas com as respectivas respostas:

1. Quais os objetivos da Organizao relacionados a este sistema?

R: Para o objetivo X os mdulos so A, B e C. Para o objetivo Y os mdulos so B, D e F. A forma mais clara de se responder esta pergunta montar uma tabela semelhante Tabela 1: Relao entre objetivos da organizao e mdulos do sistema.

2. Quais objetivos no esto sendo atualmente alcanados e quais os problemas esto criando este empecilho?

R: O objetivo A no est sendo alcanado por causa do problema P. A forma mais clara de se responder esta pergunta montar uma tabela semelhante Tabela 2: Relao entre objetivos da Organizao e os problemas em se alcan-los

83 3. Quais os objetivos o software ir tornar mais fceis de se alcanar?

R: O objetivo B ser mais facilmente alcanado pelo motivo M.A forma mais clara de se responder esta pergunta montar uma tabela semelhante Tabela 3: Relao entre objetivos da Organizao e oportunidades de se alcan-los

Abaixo segue um exemplo ilustrando o procedimento descrito nas perguntas acima.

Durante a anlise de negcio de uma determinada Organizao, foramse identificados por meio de conversa com funcionrios quais os objetivos da empresa, chegando-se ao seguinte: Objetivo Melhorar a diviso do trabalho Sistema Controle de monografias Disponibilizao on-line cronogramas das aulas atividades dos

Automatizar rotineiras

agilizar

Controle de monografias Sistema de controle de entrega de pauta Emisso automtica de comprovantes que so teis aos docentes Controle de monografias Sistema de controle entrega de pauta de

Dar mais credibilidade ainda ao departamento, tornando as informaes geradas por ele mais seguras e consistentes, armazenando-as de forma prtica e til Promover o bem estar dos alunos

Disponibilizao on-line cronogramas das aulas Controle de monografias Sistema de controle entrega de pauta

dos

de

Tabela 1: Relao entre objetivos da organizao e mdulos do sistema

Objetivo

Problema

84 Melhorar trabalho a diviso do Falta de processos bem definido Falta de um meio central de realizao de atividades As informaes destinadas tanto aos docentes como aos discentes so todas fornecidas pela secretria por telefone, email ou pessoalmente. Cronogramas no atualizados e inconsistentes s vezes fazem os alunos irem a aula em dias que no h aula, ou criar a expectativa de se ter aula com um professor e na verdade ter com outro. Os alunos precisam se deslocar at a UEL ou enviar pelo correio a verso final da monografia.

Promover o bem estar dos alunos

Tabela 2: Relao entre objetivos da Organizao e os problemas em se alcan-los

Objetivo Automatizar e agilizar atividades rotineiras

Oportunidade A entrega das monografias so feitas em CD, ou seja, j so entregues em formato eletrnico, portanto possvel que ela seja entregue via Internet, sem a necessidade de intermediao de tcnicos e secretrios para tal trabalho.

Tabela 3: Relao entre objetivos da Organizao e oportunidades de se alcan-los

5.1.2 Modelo de Regras de Negcio

O modelo de regras de negcio deve ser utilizado quando forem identificadas regras que fujam lgica ou que sejam extremamente importantes para o funcionamento da Organizao. Portanto, importante que o responsvel pela anlise das regras levantadas identifique junto a um membro da Organizao quais as regras no so to bvias e simples e quais no podem ser quebradas em hiptese alguma para que seja colocada na proposta a cincia que a equipe tem em manter a segurana do sistema.

85 Seria inserida na descrio das funcionalidades dentro da proposta, as regras de negcio que respeitas pelo sistema, assegurando, assim, a segurana do sistema.

Exemplo:

Gerao Automtica de Protocolo

Quando um aluno for entregar uma verso da monografia na secretaria do departamento, o sistema deve emitir um protocolo com o nome do aluno, data de emisso, nome da secretria que realizou a operao e um indicativo de qual o tipo do protocolo (Entrega de monografia).

Regra 1: O protocolo no ser emitido pelo sistema caso o aluno no tenha assistido a pelo menos 70% das aulas.

Regra 2: O protocolo no pode ser emitido depois das 18:00.

Regra 3: O protocolo deve ser assinado pelo aluno e por quem o emitiu (secretria)

O exemplo acima ilustra bem uma situao em que os membros da equipe esto cientes de algumas regras, restries e polticas que devero ser implementadas no sistema desenvolvido. Isso da credibilidade ao cliente, que se sentir segurana por no correr o risco de ter suas regras e polticas quebradas, abrindo espao para desorganizao e at fraudes no seu negcio.

86

5.1.3 Modelo de Conceitos

Na elaborao da proposta, este modelo serve para definir alguns termos e entidades existentes no modelo de objetivos e estabelecer de forma clara o escopo da aplicao. Ele particularmente importante para a equipe de desenvolvimento, pois para compreender os objetivos extrados do cliente, a equipe ter que consultar esse modelo para poder compreender exatamente o que o cliente quis dizer e para se ter uma dimenso do tamanho do projeto.

A proposta para o cliente no precisa conter nenhuma informao desse modelo, uma vez que quem definiu as partes dele foram os prprios clientes. Porm, ele de fundamental importncia para a equipe e, portanto, necessria uma forma sistemtica de constru-lo. A sugesto dada por Bubenko, Persson & Stirna (2001) seguir uma srie de perguntas que ele fornece. Porm, utilizando-se a idia do RUP (2002) de processo iterativo, pode-se tornar o processo mais prtico procedendo-se assim: para cada uma das modelagens (objetivos, regras de negcio, processos de negcio, atores e recursos e requisitos e componentes tcnicos) entregue o documento que contm o modelo construdo para cada membro da equipe e disponibilize um local pgina de Internet em formato wiki1 por exemplo para que todos eles possam postar os conceitos e termos que no compreenderam durante a anlise dos documentos. Nesse local de postagem das dvidas, todos da equipe tero acesso e podero responder dvida dos colegas, esclarecendo quais so os conceitos e termos que estavam mal-entendidos. Depois dessa fase de aprendizado coletivo, devem ser coletadas todas as informaes desse local de postagem de dvidas e o modelo de conceitos deve ser construdo.

Um tipo especfico de coleo de documentos ou um software colaborativo usado para criar esses documentos (WIKIPEDIA, 2006).

87 Essa estratgia sugerida aqui interessante, pois ela torna a documentao dos conceitos e termos bem prtica na medida em que ela ser formada a partir de dvidas reais da equipe e no de possveis dvidas, alm do que os conceitos sero esclarecidos segundo a viso e linguagem de todos os membros da equipe e no de um em particular.

5.1.4 Modelo de Processos de Negcios

O Modelo de Processos de Negcios geralmente representado pelos diagramas de atividades, os quais descrevem o fluxo de atividades que ocorrem em cada um desses processos que acontecem dentro da empresa.

Esse modelo no ser utilizado diretamente na elaborao da proposta, pois ele no acrescentar muita informao ao cliente. Porm ele ser de fundamental importncia para a equipe poder identificar oportunidades e problemas dentro do negcio e apresent-los na proposta. Para a equipe de desenvolvimento, esse modelo fundamental, pois ele diz quais so as entradas e sadas dos processos, o que serve como uma espcie de norte para que a equipe avalie se o sistema implementado est realizando o processo todo, i.e., recebendo a entrada desejada e gerando a sada esperada.

Exemplo: Processo de entrega de monografia

88

Entrada: Primeira verso da monografia

Sada: Protocolo de entrega de monografia

5.1.5 Modelo de Atores e Recursos

O Modelo de Atores e Recursos descreve alguns trabalhadores e clientes da empresa bem como os recursos que eles utilizam para realizar as suas atividades. Dentre suas vrias utilidades, destaca-se a dele servir como um instrumento de identificao de acmulos de responsabilidades para alguns atores e da forma de utilizao dos recursos.

89 Sob essa perspectiva, vemos que este modelo serve para identificao de pontos de melhorias do negcio, principalmente relativas diviso do trabalho. Com essas informaes em mos a equipe pode sugerir na proposta melhorias que o sistema pode proporcionar a essa diviso do trabalho e como a empresa ganhar com isso, pois com uma melhor diviso do trabalho os funcionrios que antes ficavam cheios de tarefas para realizarem agora podero produzir algo mais qualificado e melhorar seu servio.

Portanto, em uma abordagem prtica, o Modelo de Atores e Recursos serve para se identificar melhorias de diviso de trabalho, aproveitamento de recursos, diminuio de burocracia e dependncias que o sistema pode proporcionar e que devem ser sugeridas na proposta.

5.1.6 Modelo de Requisitos e Componentes Tcnicos

Dentro da elaborao da proposta, colocar alguns requisitos de alto nvel identificados na Modelagem de Negcios e qual o ganho que ele ir gerar.

Exemplo: Requisito Gerao automtica de protocolo Benefcio Agilidade no processo fazendo com que a secretria possa produzir mais. Segurana. Com a gerao garantida do protocolo, reduzem-se as possibilidades de fraudes. Sistematizao do processo. A gerao do protocolo padronizada, evitando confuses e/ou dvidas por parte dos envolvidos no processo. Consistncia da informao sobre quem entregou e quem no entregou a pauta, dando mais confiana ao

Relatrio de entrega de pauta com notificao aos docentes

90 processo. Facilidade na comunicao da secretria com os docentes, ajudando os professores a se lembrarem de entregar a pauta e possibilitando que a secretria faa isso mais rpida e facilmente. Cumprimento dos prazos de entrega conforme estabelecido. Disponibilizao on-line cronogramas das aulas dos Os professores e os alunos podero saber quando iro 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. Consistncia nos cronogramas. Quando um cronograma sofrer alteraes, automaticamente ele ser atualizado para os professores e alunos, evitando que algum aluno ou professores v para a aula quando no houver.

Tabela 4: Relao dos requisitos com os benefcios gerados

5.2 Planejando e Adiantando o Prximo Passo

Apesar das diversas utilidades da Modelagem de Negcios, o seu objetivo principal auxiliar a construo de um sistema de informao. Portanto, dentro dos modelos de negcio existe a possibilidade e por que no dizer inteno de se construir um modelo que possa depois ser mapeado para os modelos de sistema, tais como os utilizados na etapa de anlise.

Uma sugesto clara e direta dada por Heumann (2001), a de que sejam feitos seguintes mapeamentos: De um processo de negcio para um caso de uso De um caso de uso de negcio para um subsistema

91

De uma entidade de negcio para uma classe de entidade do

sistema

Segundo este autor, esse mapeamento ir facilitar o incio da fase de anlise e design do sistema a ser construdo.

Uma forma mais detalhada colocada no RUP (2002), onde sugerido que: um trabalhador de negcios no modelo de negcios corresponda a

um ator dentro do sistema de informaes. um caso de uso de negcio que tem participao dos trabalhadores

de negcio deve, a priori, ser mapeado para um caso de uso do sistema, mas se o caso de uso de negcios for complexo ou muito grande, ele pode ser divido. os objetos (entidades) e seus relacionamentos identificados no

modelo de objetos de negcio correspondam a classes de entidade com os respectivos relacionamentos dentro do sistema

Seguindo essa proposta dada pelo RUP, Krunchten (2000) fornece um exemplo que ilustra bem essa situao envolvendo os mapeamentos citados acima. A seguir apresentada esta ilustrao.

92 1. Trabalhador de Negcio de Uso do Sistema Ator do Sistema e Caso de Uso de Negcio Caso

1.1. Na figura abaixo est ilustrado o caso de uso de negcio em que um cliente realiza uma transao financeira.

Figura 22: Modelo de Caso de Uso de Negcio Transao Financeira (KRUCHTEN et. al, 2000)

1.2. Na figura abaixo est ilustrado o modelo de objetos de negcio do caso de uso de negcio de transao financeira, que mostra como esse caso de uso feito e quais as entidades e trabalhadores da empresa envolvidos no processo.

Figura 23: Modelo de Objetos de Negcio Transao Financeira (KRUCHTEN et. al, 2000)

93 1.3. Na figura abaixo est representado o mapeamento dos trabalhadores de negcio em atores do sistema e dos casos de uso de negcio que estes atores participam, no caso o caso de uso de negcio de transao financeira, em casos de uso do sistema.

Figura 24: Mapeamento do modelo de negcio para o de sistema (KRUCHTEN et. al, 2000)

94 2. Entidade de Negcio Classe de Entidade

2.1. A exemplo do primeiro mapeamento, na figura abaixo est ilustrado o caso de uso de negcio em que um cliente realiza uma transao financeira.

Figura 25: Modelo de Caso de Uso de Negcio Transao Financeira (KRUCHTEN et. al, 2000)

2.2. Assim como no primeiro mapeamento, na figura abaixo est ilustrado o modelo de objetos de negcio do caso de uso de negcio de transao financeira, que mostra como esse caso de uso feito e quais as entidades e trabalhadores da empresa envolvidos no processo.

Figura 26: Modelo de Objetos de Negcio Transao Financeira (KRUCHTEN et. al, 2000)

95 2.3. Na figura abaixo est representado o mapeamento das entidades de negcio em entidades de classes. No caso as entidades Perfil do Cliente, Conta e Emprstimo foram mapeadas para classes de entidade de mesmo nome no modelo de anlise.

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

Dessa forma, possvel notar que esses mapeamentos iro promover algum adiantamento nas atividades de levantamento de requisitos e de design no sistema, pois a partir dos modelos de negcio chega-se primeira verso do modelo de casos de uso e do diagrama de classes. Isso acarreta no s no adiantamento de trabalho, mas no amadurecimento da compreenso das necessidades e oportunidades identificadas na Organizao-alvo, alm da criao de artefatos utilizados para planejamento desse prximo passo que consistir em mais atividades de construo e implementao propriamente ditas.

96 Esse diagrama de casos de uso j pode ser utilizado para o incio do levantamento de requisitos do sistema, pois nele j estaro descritas algumas funcionalidades. O diagrama de classes, por sua vez, tambm j pode ser usado para o design do sistema, i.e., para construo do modelo de domnio, sendo que nessa construo, essas classes iro ser recheadas com atributos e novos relacionamentos podero surgir, entretanto a origem dessa modelagem se deu por meio do mapeamento do modelo de negcio para o modelo de sistema.

97

6 Concluso
No presente trabalho, foram apresentados os principais pontos dentro da disciplina de Modelagem de Negcios do RUP e algumas tcnicas e metodologias que podem ser utilizados para realizao das suas principais atividades e para obteno das informaes que por ela devem ser geradas.

Como pode ser visto durante o estudo, a Modelagem de Negcios fundamental para qualquer projeto de software, pois ela atende duas necessidades fundamentais desse projeto: comunicao e planejamento. Ela a maior responsvel pela sintonia entre o que o cliente deseja e o que servio prestado ir fornecer, pela compreenso da equipe a respeito da misso do projeto e pelo planejamento geral de todas as etapas do desenvolvimento.

Para que a comunicao com o cliente seja realmente efetiva, importante que sejam utilizadas tcnicas de extrao e organizao do conhecimento e informao. Nesse ponto, o estudo mostrou que a tcnica EKD se mostra uma forte arma para que a equipe, ou os responsveis dentro dela, possam mostrar ao cliente a importncia do software produzido para o seu negcio, destacando a quais objetivos ele est relacionado e quais benefcios diretos ele vai gerar para a Organizao.

Com relao ao trabalho da equipe de desenvolvimento, a forma mais segura e eficiente de comunicao o registro (documentao) das informaes necessrias para que a equipe saiba exatamente a misso do projeto, sem perder o foco. Alm da questo ligada comunicao, o registro das informaes tambm importante para o planejamento, uma vez que essas informaes sero essenciais para que se possa escolher o melhor caminho a se seguir durante o desenvolvimento.

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

98 aproximao da informtica nos negcios. Uma rea particularmente interessante a rea de modelagem de objetos de negcio como atividade preparatria para a modelagem de domnio, que atualmente vem sendo encarada como o modelo principal de uma aplicao. Assim, a modelagem de objetos de negcio tem sua importncia no somente na questo do entendimento do negcio, mas na parte de implementao do projeto, o que mostra um outro ramo de estudo nessa rea que a de construo de modelos reaproveitveis.

Como

contribuio,

presente

trabalho

visou

construir

uma

metodologia para se realizar a Modelagem de Negcios, dividindo-a em duas etapas: aprovao do projeto e planejamento do desenvolvimento, sendo apresentado, como parte da contribuio, a juno da metodologia EKD com algumas tcnicas do RUP para o desenvolvimento da primeira etapa dessa metodologia.

Apesar da juno do EKD com o RUP tambm ser til para a segunda etapa da metodologia sugerida, ela no a contempla totalmente e, portanto, um estudo futuro a se realizar, o desenvolvimento de uma metodologia para realizao da segunda etapa dessa metodologia.

99

100

Referncias Bibliogrficas
ANQUETIL, Nicolas. Diagrama de atividade, diagrama de estado. Disponvel em: <http://www.ucb.br/ucbtic/mgcti/paginapessoalprof/Nicolas/Disciplinas/UML/node7. html>. Acesso em: 10 nov 2006.

BARBALHO, S. C. M., ROZENFELD, H., AMARAL, D. C. Anlise da abrangncia de metodologias de modelagem de empresas. In: 26 Encontro Nacional da Associao Nacional dos Programas de Ps-Graduao em Administrao, 2002, Salvador. ENANPAD. Salvador: ENANPAD, 2002. p.72 75. Disponvel em:

<www.ifm.org.br/congresso/inscritos/teste2.php?id_trabalho=85>. Acesso em: 14 out 2006.

BELTRO,

Andr.

Quanto

Custa

Meu

Design?.

2006.

Disponvel

em: Acesso

<http://www.designbrasil.org.br/portal/opiniao/exibir.jhtml?idArtigo=593>. em 08 nov 2006.

BUBENKO, Janis jr.; PERSSON, Anne; STIRNA, Janis. EKD user guide, Department of computer and systems sciences. Stockholm: Royal Institute of Technology, 2001. Disponvel em: <ftp://ftp.dsv.su.se/users/js/ekd_user_guide.pdf>. Acesso em: 10 out 2006.

CASTRO, Sergio Alexandre de; CAZARINI, Edson Walmir. Um modelo de mudana organizacional contnua atravs da gesto do conhecimento integrando tecnologia da informao e pessoas. Revista Gesto Industrial, v. 1, n. 4, p. 436-443, 2005. Disponvel em:

<www.pg.cefetpr.br/ppgep/revista/revista2005/pdf4/RGIv01n04a02.pdf>. Acesso em: 2 jul 2006.

101 CRUZ, Pedro Oscar de Souza. Heursticas para Identificao de Requisitos de Sistemas de Informaes a partir de Modelos de Processos. 2004. 92 p. Tese (Mestrado em Informtica) Ncleo de Computao Eletrnica, Universidade Federal do Rio de Janeiro, Rio de Janeiro. Disponvel

em:<www.geti.dcc.ufrj.br/downloads/HpReq.pdf>. Acesso em: 10 ago 2006

DEWALT, Craig. Business Process Modeling with UML. Johns Hopkins University, 1999.

EELES, Peter; HOUSTON, Kelli; KOZACZYNSKI, Wojtek. Building J2EE Applications with the Rational Unified Process. Boston: Addison-Wesley, 2002, 288 p.

ERIKSSON, Hans-Erik; PENKER, Magnus. Business Modeling with UML: Business Patterns at Work. John Wiley & Sons, 2000, 459 p.

GIBBS, R. Dennis. Project Management with the IBM Rational Unified Process: Lessons from the Trenches. Upper Saddle River: IBM Press, 2006, 312 p.

HEUMANN, Jim. Introduction to Business Modeling Using the Unified Modeling Language (UML). The Rational Edge, 2001. Disponvel em:

http://www.therationaledge.com/content/mar_01/m_uml_jh.jsp>. Acesso em: 10 jun 2006.

KROLL, Pren; KRUCHTEN, Philippe. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Boston: Addison-Wesley, 2003, 464 p.

KRUCHTEN, Philippe. The Rational Unified Process: An Introduction. 2. ed. Boston: Addison-Wesley, 2000, 320 p.

102 MARQUIONI, Carlos Eduardo. A Modelagem de Processos de Negcio como subsdio fundamental para a identificao dos Requisitos. Disponvel em:

<http://www.choose.com.br/infochoose/artigos/39art03.htm>. Acesso em: 05 jun. 2006.

NG, Pan-Wei. Business Process Modeling and Simulation with UML. The Rational Edge, 2002. Disponvel em: <http://www.therationaledge.com/content/apr_02/t_businessProcessModeling_pn.jsp >. Acesso em: 10 jun 2006

PDUA, Silvia Ins Dallavalle. Mtodo de avaliao do Modelo de Processos de Negcio do EKD. 2004. 252 p. Tese (Doutorado em Engenharia Mecnica) Escola de Engenharia de So Carlos, Universidade Federal de So Carlos, So Carlos.

PDUA, Silvia Ins Dallavalle; CAZARINI, Edson Walmir; INAMASU, Ricardo Yassushi. Modelagem organizacional: captura dos requisitos organizacionais no

desenvolvimento de sistemas de informao.. Revista Gesto e Produo, So Carlos, v. 11, p. 1-20, 2004. Disponvel em: <www.scielo.br/pdf/gp/v11n2/a06v11n2.pdf>. Acesso em: 10 ago 2006

POLLICE, Gary; AUGUSTINE, Liz; LOWE, Chris; MADHUR, Jas. Software Development for Small Teams A RUP-Centric Approach. Boston: Addison-Wesley, 2004, 304 p.

RUP. The Rational Unified Process. IBM Rational, verso 2002.

STIRNA,

Janis.

EKD

Enterprise

Knowledge

Development.

Disponvel

em:

<http://www.dsv.su.se/~js/ekp/ekd_method.html>. Acesso em: 10 out. 2006

103 TEIXEIRA, Gilberto. O que significa metodologia. Disponvel em: <

http://spu.autoupdate.com/ler.php?modulo=21&texto=1338>. Acesso em: 10 out 2006.

WIKIPEDIA.

Rational

Unified

Process.

Disponvel

em:

<http://en.wikipedia.org/wiki/Rational_Unified_Process>. Acesso em: 28 out 2006.

WIKIPEDIA. Wiki. Disponvel em: <http://pt.wikipedia.org/wiki/Wiki>. Acesso em 11 nov 2006.

WordNet.

WordNet

Search

2.1:

notation.

Disponvel

em:

<http://wordnet.princeton.edu/perl/webwn?s=notation>. Acesso em: 07 nov 2006.

Apndice A Proposta em forma de Panfleto

Sistema de Avaliao Docente

Inbrape
(Apresentao de Projeto)

Tiago de Oliveira Stutz

tiagostutz@yahoo.com.br / 9103-8839

Daniel Teleginski Camargo

telecargo@yahoo.com.br / 9941-0825

Eduardo Zanoni Marques

ezmarques@hotmail.com / 9124-0104

Necessidades e Oportunidades
A qualificao profissional sempre foi um dos fatores determinantes para que um indivduo ocupe seu lugar no mercado. Porm, o mercado vem exigindo cada vez mais tempo e dedicao dos profissionais, que acabam ficando sem tempo disponvel para buscarem essa to requisitada qualificao. Diante dessa situao, surge uma evidente necessidade: os profissionais precisam muito se qualificar e melhorar seus currculos, mas no tm tempo disponvel para isso, principalmente os que precisam se deslocar de suas cidades por l no haver instituies de ensino. O que fazer?

Assim, para que as atuais instituies de ensino possam se adaptar a essa nova realidade do mercado, saindo na frente, conquistando e mantendo seus espaos, elas precisam se projetar para oferecer esse novo tipo de servio.

O Papel da Informtica
Papel da Informtica dentro da organizao (cadastros, benefcios, etc...) e no ensino distncia Com o desenvolvimento da tecnologia e a popularizao da informtica, ao parcela da populao passou a ter acesso ao computador e Internet. Os seguintes dados do IBGE mostram essa realidade: 21% da populao de 10 anos ou mais de idade acessaram Internet em 2005 Em 2005, 21% da populao de 10 anos ou mais de idade acessaram Internet, pelo menos uma vez, por meio de computador, em algum local (domiclio, local de trabalho, escola, centro de acesso gratuito ou pago, domiclio de outras pessoas ou qualquer outro local) nos 90 dias que antecederam entrevista. Na populao de 15 a 17 anos de idade, 33,9% acessaram Internet, o maior resultado entre as faixas etrias. Fonte: IBGE, 2005 (http://www.ibge.gov.br) Com base nessas informaes, podemos verificar que o ensino distncia um negcio extremamente vivel e com timas perspectivas. Portanto, as instituies de ensino que desejarem ingressar nessa nova era da educao, devero passar por um processo de informatizao e criao de um cultura digital interna, com a finalidade de construir a infra-estrutura necessria para realizao desses novos processos de negcio, estabelecendo, assim, uma imagem de referncia no mercado.

Um bom comeo agilizar os processos das organizaes, principalmente os que afetam diretamente os alunos e certificarse de estar oferecendo um ensino de qualidade. A soluo que melhor concilia essa necessidade dos clientes e os interesses das instituies o ensino distncia. Com um baixo custo operacional de implantao no exige, por exemplo, deslocamento dos docentes e o benefcio aos alunos da facilidade de acesso a um ensino de qualidade, o mercado de ensino distncia vm crescendo cada vez mais e se tornando a alternativa mais procurada entre os profissionais das diversas reas.

O Inbrape e a Cultura Digital

Um sistema de informao no , como alguns acreditam ser, um sistema puramente tcnico. Na realidade existe uma srie de fatores sociais inerentes implantao de tais sistemas. De fato, o conjunto de aspectos tcnicos de fundamental importncia; no entanto, para que um sistema tenha sucesso ele precisa ser socialmente aceito pela organizao onde ir atuar. Ser socialmente aceito implica que a organizao trabalhe com aquele sistema como parte do seu dia-a-dia criando uma cultura digital. Estudos comprovam que a implantao de sistemas de informao mais complexos so mais facilmente aceitos e menos traumticos quando implantados de forma gradual permitindo que aspectos tcnicos, organizacionais e polticos no que se refere deciso sobre emprego de tecnologias, remanejamento de pessoal e oferta de novos servios possam ser feitos de forma ponderada. A criao de um sistema de avaliao docente permitir que essa cultura digital comece a ser disseminada pela instituio abrindo caminho para funcionalidades mais complexas e de maior impacto com um sistema para gerncia do ensino a distancia

O Sistema de Avaliao Docente

O Sistema de Avaliao Docente um sistema de informao on-line que possibilitar aos alunos da instituio avaliar seus professores de qualquer lugar e em tempo real, fornecendo aos responsveis da instituio relatrios e mecanismos de acompanhamento dessa avaliao. Ao final de cada encontro, uma avaliao ser emitida para os alunos realizarem, proporcionando, assim, um feedback imediato para a instituio a respeito do desempenho do professor e da qualidade do servio oferecido aos seus alunos. Do lado do professor tambm interessante, pois com feedback imediato da aula ministrada, ele poder saber o que precisa melhorar e o que j est bom, garantindo assim a qualidade do ensino oferecido pela instituio.

Outras Funcionalidades No processo de informatizao de uma organizao, necessria a identificao de quais so os elementos chaves que devem constituir sua base de informaes. No caso de uma instituio de ensino, essas informaes so compostas, essencialmente, por dados de alunos (controle acadmico), professores, cursos, instituies conveniadas, projetos pedaggicos e pela maneira como a instituio os organiza e relaciona em seus processos de negcio. Para o Inbrape seria interessante ter um nmero de matrcula associado a cada aluno para que seja possvel um controle exato da quantidade de alunos que a instituio possui e para que o aluno esteja vinculado ela e no instituio parceira. Uma vez que estas informaes estejam devidamente estruturadas e armazenadas, torna-se possvel a disponibilizao de servios que automatizaro tarefas dos funcionrios (como a emisso dos relatrios das avaliaes docentes) e promovero benefcios aos alunos, tais como acesso online a material didtico, consulta de notas, faltas e cronogramas das disciplinas, entre outros.

Panorama do Mercado
Em virtude das vantagens oferecidas pelo ensino a distncia um nmero cada vez maior de organizaes pblicas e privadas vm aderindo a este programa. S na regio sul do pas, de acordo com dados do MEC, existem oito instituies de ensino oferecendo cursos de ps-graduao lato sensu exclusivamente distncia.
Instituio CEFET-PR PUC-PR EDUCON - PR Cursos oferecidos Em suas reas de atuao Em suas reas de atuao

Gesto Estratgica em Direito Contemporneo Especializao Educao em

Desenvolvimento Humano e Tecnolgico Especializao em Gesto Estratgica em Servios e Sistemas de SadeSegmento Publico e Privado Especializao Controladoria Governana em e

MBA Executivo em Gesto Empresarial

UNESC-SC UNISINOS-RS CESUMAR-PR UNIANDRADE-PR Em suas reas de atuao Em suas reas de atuao Em suas reas de atuao Em suas reas de atuao

fonte: MEC (http://portal.mec.gov.br).

Apndice B Proposta Tradicional

Puerto Rico Software

Intranet Mdulo 2
Departamento de Computao UEL
(Proposta de Desenvolvimento)

Daniel Teleginski Camargo

telecargo@yahoo.com.br / 9941-0825

Eduardo Zanoni Marques

ezmarques@hotmail.com / 9124-0104

Tiago de Oliveira Stutz

tiagostutz@yahoo.com.br / 9103-8839

Londrina 2006

11 de dezembro de 2006

1 Anlise de Negcio
Para definio dessa proposta, a equipe realizou uma anlise de negcio no departamento para identificar quais as necessidades e objetivos do departamento, classificando-os segundo as suas respectivas prioridades. Na primeira etapa desse trabalho, foi identificado, atravs de conversas com professores, tcnicos e secretrios, qual o setor do departamento que concentrava o maior volume de trabalho e que precisava de automatizao e sistematizao dos processos. O setor identificado foi a secretaria.

Definido o setor, foram levantados juntamente com os funcionrios da secretaria quais os objetivos e necessidades imediatas da rea e qual a melhor soluo para se atingir esses objetivos, ainda que parcialmente, e atender essas necessidades. A tabela abaixo enumera os objetivos e quais os sub-sistemas (mdulos) a serem desenvolvidos para tornar esses objetivos mais fceis de se alcanar:

Objetivo Melhorar a diviso do trabalho

Sistema Controle de monografias Disponibilizao on-line dos cronogramas das aulas Controle de monografias Sistema de controle de entrega de pauta Emisso automtica de comprovantes que so teis aos docentes Controle de monografias Sistema de controle de entrega de pauta Disponibilizao 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, tornando as informaes geradas por ele mais seguras e consistentes, armazenando-as de forma prtica e til Promover o bem estar dos alunos

Puerto Rico Software

11 de dezembro de 2006

2 Servio proposto
O servio proposto a implementao de dois mdulos e trs funcionalidades extras do sistema. Os mdulos em questo so: mdulo de controle de entrega de pauta e mdulo de controle de monografias. As funcionalidades extras so: emisso de comprovante de participao em banca, emisso de comprovante de aula ministrada e gerao automtica dos cronogramas das turmas. Estes mdulos e funcionalidades extras sero integrados ao sistema atual de forma transparente; estes sero descritos com mais detalhes no decorrer da proposta.

2.1 Mdulo de Controle de Entrega de Pauta

Este mdulo consiste na disponibilizao de um sistema de controle da entrega de pauta das disciplinas dos cursos de ps-graduao do DC (Departamento de Computao) da UEL (Universidade Estadual de Londrina).

Seu objetivo aprimorar a forma como este servio vem sendo realizado pela secretaria do Departamento de Computao, provendo um meio para que as informaes das pautas sejam armazenadas de forma prtica, alimentando informaes que sero utilizadas em outras funcionalidades deste e de outros mdulos do sistema.

Alm de prover o armazenamento destas informaes, este mdulo disponibilizar dois relatrios para tomada de deciso por parte dos secretrios. O primeiro diz respeito ao acompanhamento da entrega das pautas por parte dos professores, oferecendo um mecanismo de notificao para os docentes com atraso na entrega da pauta, buscando, desta forma, evitar que estas informaes sejam lanadas tardiamente no sistema comprometendo outras funcionalidades que dependem destas informaes.

O segundo relatrio apresenta uma lista dos alunos do curso que esto com

Puerto Rico Software

11 de dezembro de 2006

pendncias academicas. Com estas informaes em mos, a secretaria poder notificar, atravs do prprio sistema, os alunos de tal irregularidade. Com isso espera-se que o aluno em estado irregular venha realizar, mais rapidamente, as medidas cabveis para regularizar sua situao perante o curso.

2.2 Mdulo de Controle de Monografias

Este mdulo compreende todas as funcionalidades necessrias para o controle das monografias dos alunos dos cursos de ps-graduao do Departamento de Computao da UEL.

Este controle ter inicio com o cadastro da monografia e com o acompanhamento dos eventos ligados a ela. A seqncia de eventos pode variar de duas formas (1) Sem a necessidade de reformulao: entrega da primeira verso (em espiral), definio da banca por parte do coordenador do curso, homologao no sistema UEL, devoluo da monografia para correo e entrega da verso final (em CD). (2) Com necessidade de reformulao: entrega da primeira verso (em espiral), definio da banca por parte do coordenador do curso, homologao no sistema UEL, devoluo da monografia para reformulao, entrega da verso reformulada (em espiral), devoluo da monografia para correo e entrega da verso final (em CD).

Dentro desta seqncia de atividades existem relaes de dependncia que precisam ser mantidas. Para ajudar nesse controle o sistema oferecer uma serie de relatrios, mecanismos de notificaes e ser responsvel pelas emisses de protocolos e ofcios necessrios que permitiro o acompanhamento da situao de cada aluno nas diversas etapas do processo possibilitando a deteco precoce de eventuais pendncias e agilizao dos processos de regularizao, contribuindo para o fluxo normal entre uma determinada etapa e sua subseqente.

No final do processo de entrega de monografia, o aluno entrega uma verso final de sua monografia em CD e algum funcionrio do departamento fica responsvel 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 verso 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 disponvel no acervo da biblioteca digital do departamento de computao da UEL.

Funcionalidade Relatrio de entrega de pauta com notificao aos docentes

Benefcio Consistncia da informao sobre quem entregou e quem no entregou a pauta, dando mais confiana ao processo. Facilidade na comunicao da secretria com os docentes, ajudando os professores a se lembrarem de entregar a pauta e possibilitando que a secretria faa isso mais rpida e facilmente. Cumprimento dos prazos de entrega conforme estabelecido. Agilidade no processo fazendo com que a secretria possa produzir mais. Segurana. Com a gerao garantida do protocolo, reduzem-se as possibilidades de fraudes. Sistematizao do processo. A gerao do protocolo padronizada, evitando confuses e/ou dvidas por parte dos envolvidos no processo. Conforto para os alunos que no precisaro sair de suas casas para ir para a UEL s para entregar o CD com a verso final. Melhor diviso do trabalho uma vez que nenhum funcionrio ficar responsvel por receber os CDs e controlar quem entregou, bem como submeter a monografia no sistema nou-rau. Melhor utilizao do sistema nou-rau deixando-o sempre atualizada, uma vez que no depender mais de nenhum

Gerao automtica de protocolo e ofcios

Submisso de monografia on-line e integrao com o sistema nourau

Puerto Rico Software

11 de dezembro de 2006

funcionrio para submeter as monografias que estavam em CD. Relatrio de alunos com pendncias acadmicas e mecanismo de notificao aos referidos Agilidade no controle e comunicao da secretria, ganhando-se tempo que ser utilizado para a realizao de outras atividades. Evitar que monografias sejam enviadas para homologao havendo ainda pendncias por parte do aluno causando desconforto para a secretaria. Bem-estar do aluno que poder regularizar sua situao o mais rpido possvel, dando credibilidade ao departamento que demonstra, assim, preocupao com o aluno. Melhora na diviso do trabalho, pois a secretria ter parte do seu trabalho dividido com o coordenador do curso. Facilidade e versatilidade na definio da banca. O coordenador do curso poder fazer de qualquer lugar a definio da banca, descentralizando as tarefas da secretaria. Os professores e os alunos podero saber quando iro 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. Consistncia nos cronogramas. Quando um cronograma sofrer alteraes, automaticamente ele ser atualizado para os professores e alunos, evitando que algum aluno ou professores v para a aula quando esta no houver. Agilidade na emisso do comprovante, uma vez que ele ser feito automaticamente, disponibilizando-o para que os professores possam acrescent-lo em seus currculos.

Definio on-line da banca avaliadora pelo coordenador do curso

Disponibilizao on-line cronogramas das aulas

dos

Emisso automtica de comprovante de ministrao de aula e de participao em banca

Puerto Rico Software

11 de dezembro de 2006

2.3 Funcionalidades Adicionais

Conforme dito anteriormente as funcionalidades adicionais que sero implantadas no sistema so: emisso de comprovante de participao em banca, emisso de comprovante de aula ministrada e gerao automtica dos cronogramas das turmas.

O comprovante de participao em banca e o comprovante de aula ministrada sero emitidos (impresso) com base nos dados do sistema respeitando o modelo estabelecido pelo cliente.

O cronograma da turma ser gerado, tambm, a partir dos dados do sistema e disponibilizados para consulta on-line.

2.4 Benefcios Gerados

Com a utilizao das funcionalidades citadas acima (tanto as dos mdulos como as adicionais) muitos benefcios sero gerados para o

departamento em particular para a secretaria , sendo alguns destes identificados j na fase de anlise de negcio e durante a utilizao do sistema.

Os benefcios que as funcionalidades iro gerar foram identificados junto aos funcionrios da secretaria e esto relacionados na tabela abaixo:

Puerto Rico Software

11 de dezembro de 2006

Puerto Rico Software

11 de dezembro de 2006

3 Metodologia de Desenvolvimento
A metodologia de desenvolvimento ser orientada constante interao com os membros da organizao tanto na coleta de informaes como na prestao de contas com relao ao andamento do projeto. Com relao ao ciclo de vida do desenvolvimento, ser o sugerido pelo RUP, i. e., ser composto pelas fases: Iniciao, Elaborao, Construo e Transio. Durante cada uma das fases, ocorrer iterao sobre as seguintes diretrizes: 1. Modelagem dos processos de negcio - definio dos mdulos e classificao de suas respectivas prioridades de desenvolvimento. 2. Especificao dos requisitos dos mdulos de maior prioridade 3. Prottipos de interface 4. Implementao 5. Testes 6. Implantao Sendo cada uma delas mais ou menos aplicadas dependendo de qual fase do ciclo de vida o desenvolvimento se encontra.

Puerto Rico Software

11 de dezembro de 2006

4 Participao da Organizao
A organizao ter participao fundamental no desenvolvimento do sistema, principalmente nas etapas inicias. Sua contribuio maior ser na definio dos mdulos do sistema: a partir de reunies com membros da organizao e contato com a estrutura de negcio atual ser feita a modelagem desta, bem como o levantamento dos requisitos do sistema, os quais sero definidos com o consentimento dos representantes da organizao. Para que essa sinergia entre a organizao e a equipe desenvolvedora possa ser mantida, a organizao indicar um ou mais funcionrios que tenham autonomia para indicar as necessidades, definir as prioridades, e tomar decises sobre os sistemas a serem desenvolvidos.

Puerto Rico Software

11 de dezembro de 2006

5 Recursos fsicos
Para a realizao do projeto, so necessrios trs computadores (recomendado: 512MB de RAM) ligados em rede e conectados Internet com permisso de administrador, para se instalar as ferramentas utilizadas no desenvolvimento, sendo estas basicamente free software. Alm dos computadores, a disponibilizao de uma sala para acomodao da equipe e dos computadores contribuiria muito para um desenvolvimento mais harmonioso e rpido.

Puerto Rico Software

11 de dezembro de 2006

6 Documentao e Manuteno
Sero gerados diagramas UML, documentaes de cdigo e documentos de auxlio aos usurios com explicaes do funcionamento do sistema. A documentao ser simples e objetiva de modo que seja suficiente para a compreenso do sistema e possibilite a outros desenvolvedores mant-lo.

Puerto Rico Software

11 de dezembro de 2006

7 Cronograma de desenvolvimento
Atividade Modelagem de negcio dos mdulos 1 semana Tempo

Levantamento de requisitos (criao e validao 3 semanas de telas) Apresentao de prottipos Implementao Testes Implantao (treinamento) 2 semanas 4 semanas 2 semanas 2 dias

Puerto Rico Software

11 de dezembro de 2006

8 Informaes da equipe

Papis
Analistas

Responsvel
-

Artefatos
-

Analista do Processo de Tiago de Oliveira Stutz Negcios Analista de Sistemas Daniel Teleginski Camargo

Diagrama de Atividades Diagramas de casos de uso

Prottipo das telas de UI, Designer de Interface de Tiago de Oliveira Stutz, Daniel Documento de Usurio Teleginski Camargo preferncias do usurio

Desenvolvedores Arquiteto de Software Designer Dados de Banco de

Eduardo Zanoni Marques Eduardo Zanoni Marques

Modelo de Dados

Implementador
Integrador*

Daniel Teleginski Camargo, Documentao de Cdigo, Eduardo Zanoni Marques, Tiago Material de Suporte para o de Oliveira Stutz Usurio
Daniel Teleginski Camargo Plano de Teste

Gerentes
Gerente de Projeto

Tiago de Oliveira Stutz

*O Integrador tambm desempenhar o papel de testador, como sugerido pelo RUP.

Puerto Rico Software