Mpn apoio requisitos_sistema 2

177

VI Simpósio Internacional deMelhoria de Processos de Software

São Paulo, SP – Brasil 24-26/11/2004www.simpros.com.br

Um estudo de aplicação de modelagem de processo denegócio para apoiar a especificação de requisitos de um

sistema

Adriana Andrade, Andriele Ribeiro, Eduardo Borges, Wolber Neves

Laboratório Synergia - Departamento de Ciência da Computação –Universidade Federal de Minas Gerais

Caixa Postal 702 – 30.123-970 – Belo Horizonte – MG – Brasil{aandrade, andriele, pereira, wolber}@dcc.ufmg.br

Abstract. Systems specifications are often created either withoutcontextualizing the real problem of the organization, or with a poorunderstanding of its needs. By modeling the business processes it is possible toachieve a better comprehension of the environment in which the system will beused, thus facilitating the identification and analysis of its requirements. Thiswork describes the application of business modeling techniques as an input toproduce a system specification for a public institution of the state of MinasGerais, Brazil, describing the process used and presenting the resultsachieved.

Resumo. Freqüentemente especificações de sistemas são criadas sem que oreal problema da organização seja contextualizado, ou sem que haja realentendimento de suas necessidades. Por meio da modelagem de processos denegócio é possível compreender melhor o ambiente no qual o sistema a serconstruído irá funcionar, facilitando assim a identificação e análise de seusrequisitos. Este trabalho descreve um caso de aplicação de técnicas demodelagem de processos de negócio como subsídio à especificação de umsistema informatizado para uma instituição pública do estado de MinasGerais, descrevendo o processo utilizado e apresentando os resultadosobtidos.

1. Introdução

O sucesso de uma organização está condicionado à eficácia com que os seus processosde negócio são executados. Um sistema informatizado desenvolvido para dar suporte auma organização deve, portanto, estar alinhado aos processos de negócio onde estaráinserido.

Freqüentemente as especificações de requisitos de software são criadas sem quehaja real entendimento das necessidades e problemas da organização. Por meio dastécnicas de modelagem de processos de negócio, é possível compreender melhor oambiente no qual o sistema a ser construído irá funcionar, o que possibilita identificarrequisitos correspondentes às reais necessidades do negócio [Baker 2001].

Modelos de negócio podem trazer vários benefícios no contexto dodesenvolvimento de sistemas de software [Eriksson and Penker 2000]:

178



• Contribuem para que os requisitos sejam completos e reflitam as necessidades denegócio;

• Evitam a tomada de decisões prematuras;

• Permitem que os sistemas desenvolvidos sejam guiados pelo negócio, e nãosimplesmente pela tecnologia;

• Permitem um melhor planejamento da integração dos diferentes componentes dosistema;

• Possibilitam o reuso de lógica de negócio nos diferentes produtos.

Para isso, os modelos representam a arquitetura do negócio. Essa representação érealizada descrevendo-se as partes que compõem os processos da organização, comoelas são estruturadas, e como interagem para prover as funções oferecidas a seusclientes. Há várias notações propostas na literatura para esse fim, das quais podemosdestacar: fluxogramas [Lakin et al. 1996], diagramas UML [Rumbaugh 1999], RADs(role activity diagrams) [Holt et al. 1983], gráficos de Gantt [Aguilar-Savén 2001] e osmétodos IDEF [IDEF 2003].

O trabalho aqui descrito se baseia em uma experiência de aplicação das técnicasde modelagem de processos de negócio utilizando a notação UML, como passo anteriorà especificação de requisitos de um sistema de software para uma instituição pública. Aseção 2 apresenta a contextualização do projeto em que tais técnicas foram aplicadas. Aseção 3 descreve o processo criado para guiar as atividades de modelagem, e a execuçãodo mesmo é descrita na seção 4. Finalmente, a seção 5 expõe os resultados obtidos, e asconclusões são apresentadas na seção 6.

2. Contextualização do projeto

O projeto aqui discutido foi iniciado com a missão de apresentar ao cliente - instituiçãopública do estado de Minas Gerais - uma solução de informatização para seus processosinternos, permitindo a integração entre suas áreas.

Com esse propósito o fornecedor necessitava compreender a estrutura e adinâmica da organização, levantar os problemas atuais, identificar oportunidades demelhoria e promover o entendimento comum quanto à situação desejada para aorganização. Somente após esse trabalho poderiam ser identificados os requisitos para osistema de software que ofereceria suporte à organização.

Para a realização das atividades citadas acima o fornecedor optou pelo uso detécnicas de modelagem de processos de negócio, conforme descrito na seção 3. Parafornecer as informações necessárias à modelagem, o cliente disponibilizourepresentantes com conhecimento do processo e poder de decisão, visto que não haviadocumentação dos processos em uso.

Desde o início do trabalho, com a ajuda do fornecedor, puderam osrepresentantes do cliente destacar alguns dos problemas que viviam, como: a lentidão devários processos executados manualmente, inclusive transferência de informações entresistemas; o retrabalho; o consumo excessivo de papel e conseqüente acúmulo dedocumentos em arquivos físicos; e a descentralização, replicação e inconsistência dedados.

179



Foram considerados dentro do escopo do trabalho somente processos internos daorganização, ficando adiado o tratamento de processos que envolvem a participação deagentes externos.

3. Descrição do processo adotado

3.1. Organização do modelo de processos de negócio

O primeiro passo para a definição do processo a ser utilizado foi a escolha da notação demodelagem UML. A decisão por utilizar essa notação apoiou-se no fato de que ela, alémde utilizar diagramas simples o suficiente para serem compreendidos por clientes eusuários, é a mesma empregada na modelagem de software - o que facilitariaposteriormente o entendimento pelos desenvolvedores do sistema.

Apesar de estarem mais voltados à representação de conceitos de sistemas desoftware orientados a objetos, os diagramas da UML podem ser empregados tambémpara descrever processos de negócio. Para isso alguns perfis (conjuntos de convençõesde personalização da UML) já foram propostos na literatura, como os apresentados em[Eriksson e Penker 2000] e [Ng 2003]. Para este projeto adotou-se o perfil definido em[Ng 2003], por ter melhor suporte da ferramenta de modelagem que seria utilizada noprojeto.

O conceito central para a modelagem dos processos de negócio através danotação escolhida é o de caso de uso de negócio, que representa uma seqüência deações executadas durante a realização de um processo de negócio. Os processosrepresentados pelos casos de uso de negócio geralmente produzem valor para algumcliente da organização; esses clientes são modelados por meio dos atores de negócio. Omodelo de processos de negócio é então formado por um conjunto de casos de uso, cadaum representando um processo de negócio voltado para um cliente.

Para documentar um processo de negócio o modelo apresenta duas visões, umaexterna e outra interna. A primeira é feita através da descrição dos casos de uso, queconsiste no detalhamento passo a passo da interação entre os atores e a organização,durante a execução do processo em questão. Esse detalhamento pode ser feito por meiode descrições textuais (para processos mais simples) ou por diagramas de atividades, emnotação UML. A visão interna é modelada através da realização dos casos de uso, quedetalha como os agentes de negócio (funcionários ou sistemas informatizadosexistentes na organização) interagem entre si e como as entidades de negócio (recursosfísicos, abstratos ou de informação) são manipuladas durante a realização do processo.A realização dos casos de uso é apresentada através dos diagramas de interação(seqüência ou colaboração) da UML.

O modelo de processos de negócio descreve também regras que definem ourestringem aspectos do negócio, para satisfazer a requisitos externos (leis, restriçõesimpostas por outros negócios, etc), e para garantir que os objetivos de cada processosejam alcançados de forma segura. Tais regras de negócio aparecem no modeloassociadas a casos de uso, entidades e/ou agentes de negócio.

A Figura 1 apresenta os elementos que compõem o modelo de processos denegócio, através de um diagrama de classes. A Tabela 1 descreve esses elementos eindica a representação UML de cada um.

180



Modelo de Negócio

Ator de negócio Entidade de negócio

Caso de uso de neg ócio

1..n

1

1..n

1

0..*

1..n

0..*

1..n ma ni pu la >

1

1..n

1

1..naciona >

Agente de negócio

1..n

1..n

1..n

1..n

/\ é responsável por

Regra de negócio

0..*

0..*

0..*

0..*

\/ rege

0..*

0..*

0..*

0..*< rege

0..*

0..*

0..*

0..*

\/ rege

Figura 1. Elementos que compõem o modelo de processos de negócio

Tabela 1. Representação UML dos elementos que compõem o modelo deprocessos de negócio

Elemento Descrição Representação no perfilde modelagem de

negócios

Notação icônica

[Ng 2003]

Caso de uso denegócio

Representação de um processode negócio que gera valor paraalgum cliente externo àorganização.

Caso de usoestereotipado como«business use case»

Ator de negócio Papel desempenhado emrelação ao negócio por alguémou alguma coisa no ambientede negócio.

Ator estereotipado como«business actor»

Agente denegócio

Agente humano ou informáticoque atua internamente nonegócio durante a realização decasos de uso, interagindo comoutros agentes de negócio e/oumanipulando entidades denegócio.

Classe estereotipadacomo «business worker»

Entidade denegócio

Recurso físico, abstrato ou deinformação, utilizado ouproduzido nos processos denegócio.

Classe estereotipadacomo «business entity»

Regra de negócio Regra que define ou restringeaspectos do negócio, com oobjetivo de satisfazer arequisitos externos (leis,restrições impostas por outrosnegócios, etc) e de garantir queos objetivos sejam alcançadosde forma segura.

Não foi utilizada umarepresentação direta naUML para regras denegócio. As mesmasvêm descritas comorestrições, anotações oudescrições textuais.

-

181



3.2. Organização das atividades

Para guiar as atividades realizadas durante a modelagem dos processos de negócio daorganização foi definido um processo a ser seguido e um conjunto de artefatos a seremgerados. A Figura 2 apresenta uma visão geral desse processo.

Após uma etapa inicial de definição de escopo e contexto (representada pelastrês primeiras atividades no diagrama), os casos de uso de negócio são identificados,representando os processos de negócio a serem tratados.

Cada caso de uso identificado é então descrito durante a atividade“Detalhamento dos casos de uso de negócio”. A descrição dos casos de uso de negóciocontém:

• Definição textual breve e objetiva do caso de uso.

• Acionamento: descrição de detalhes de quando o caso de uso é acionado.

• Diagramas de atividades: representação do fluxo do processo de negócio atravésde diagramas de atividades, em notação UML.

• Descrição das atividades: descrição textual de cada atividade apresentada nosdiagramas de atividades.

• Problemas conhecidos: lista dos problemas identificados no processo de negóciorepresentado pelo caso de uso.

• Possibilidades de melhoria: lista das possibilidades de melhoria identificadaspara o processo de negócio representado pelo caso de uso.

• Regras de negócio: descrição detalhada das regras de negócio que regem oprocesso descrito pelo caso de uso.

Dentre esses diversos aspectos documentados para cada caso de uso de negócio,é importante ressaltar aqueles que tratam de melhorias propostas ao processo. Amodelagem de processos de negócio contempla não só a documentação dos processos aserem informatizados, mas também a sua melhoria. Durante a descrição de um caso deuso de negócio, eventuais problemas conhecidos quanto à realização do processo que elerepresenta são documentados e para cada um são propostas possibilidades de melhoria.Por exemplo, baixo desempenho, ausência de padronização das atividades e dificuldadede acesso à informação tratada costumam ser problemas recorrentes. Tais possibilidadessão avaliadas e, se aprovadas, incorporadas ao modelo.

Na medida em que os casos de uso são descritos, os principais conceitosenvolvidos e os recursos utilizados ou produzidos por cada processo vão sendoidentificados e modelados como entidades de negócio, formando o “Modelo dedomínio”. As regras de negócio aplicáveis às entidades são também documentadas.

Uma vez descritos os casos de uso e identificadas as entidades de negócio, opróximo passo é documentar a realização dos casos de uso, descrevendo como osagentes de negócio (tipicamente funcionários ou sistemas existentes na organização)interagem entre si e com as entidades de negócio para executar o processo representadoem cada caso de uso.

182



Início da Modelagem de Processos de Negócio

Fim da Modelagem de Processos de Negócio

Levantamento e descrição do contexto

Identificação dos casos de uso de negócio

Modelagem das entidades de negócio

Definição do escopo da modelagem de negócio

Veri ficação do negócio atual

Geração da DPN

Revi são dos artefatos

Realização dos casos de uso de negóci o

Detalhamento dos casos de uso de negócio

M odelagem de processos de negócio aprovada?

Realização de ajustes e correções identificados

MPN - descrição do contexto

MPN - atores e casos de uso de negóci o

MPN - agentes de negócio

MPN DPN

M PN - model o de domínio

MPN - descrições dos casos de uso

MPN - realizações

[ Sim ]

[ Não ]

Figura 2. Atividades realizadas durante a modelagem dos processos de negócioda organização

Concluindo-se a visão de casos de uso (descrições e realizações de todos oscasos de uso de negócio) e o modelo de domínio, tem-se o Modelo de Processos deNegócio (MPN) completo. O próximo passo é gerar uma versão desse modelo emformato documental, chamada de Descrição de Processos de Negócio (DPN), que éentão revisada pelo cliente e assinada, marcando o final do processo de modelagem deprocessos de negócio. Caso sejam detectados defeitos na documentação gerada durantea revisão, as devidas correções são providenciadas antes da aprovação final.

183



Tabela 2. Resultados das atividades realizadas durante a modelagem dosprocessos de negócio da organização

Atividade Descrição Resultados

Verificação donegócio atual

Levantamento da visão geral do negócio aser modelado.

-

Definição do escopoda modelagem denegócio

Definição dos domínios de negócio a seremabordados na modelagem de processos denegócio.

Documento textual que descreve deforma precisa o escopo do modelode negócio.

Levantamento edescrição docontexto

Descrição em linhas gerais do negócio comoum todo, apresentando o contexto em que osprocessos de negócio estão inseridos.

Documento textual contendo adescrição geral do contexto.

Identificação doscasos de uso denegócio

Levantamento dos casos de uso de negócio edos atores envolvidos em cada processo.

Diagrama de casos de uso denegócio.

Detalhamento doscasos de uso denegócio

Descrição do fluxo do processo de negócio eidentificação de problemas conhecidos,possibilidades de melhoria e regras denegócio aplicáveis.

Diagramas de atividades com adescrição dos fluxos dos processos;documentação de casos de usocontendo descrição das atividades,problemas conhecidos epossibilidades de melhoria.

Modelagem dasentidades de negócio

Identificação das entidades de negóciomanipuladas nos casos de uso e dosrelacionamentos entre elas.

Diagramas de classes com asentidades do negócio e asrespectivas descrições, compondo oModelo de Domínio.

Realização dos casosde uso de negócio

Descrição das realizações dos casos de usode negócio por meio de diagramas decolaboração ou diagramas de seqüência.

Diagramas de interação, detalhandocomo os processos são realizadosinternamente na organização.

Geração da DPN Geração da Descrição de Processos deNegócio, a partir do Modelo de Processos deNegócio.

Versão documental do Modelo deProcessos de Negócio, denominadaDescrição de Processos de Negócio.

Revisão dosartefatos

Revisão pelo cliente da documentaçãoproduzida, realizada como critério deaprovação.

Relatório de revisão contendo osdefeitos detectados e o resultado(aprovação ou reprovação).

Realização deajustes e correçõesidentificados

Correções e ajustes identificados na revisãodos artefatos.

Versão atualizada do Modelo deProcessos de Negócio e daDescrição de Processos de Negócio.

Concluídas as atividades de confecção e aprovação do MPN e da DPN, dá-se início àespecificação do sistema de software a ser desenvolvido como suporte ao processo. Osartefatos produzidos na modelagem de negócio são utilizados como insumo para aidentificação dos requisitos do sistema.

4. Execução do processo

Para confeccionar o MPN foi realizado um conjunto de oficinas, baseadas em técnicasde Joint Application Development (JAD [McConnell96]).

184



Foram realizadas ao todo 11 oficinas, com duração de 4 horas cada. No total,foram especificados 21 casos de uso de negócio, cuja execução contava com oenvolvimento de 18 dos 29 setores da organização. Foram documentadas 183 atividadese identificadas 101 entidades de negócio. A partir dos casos de uso de negócio foramderivados 64 casos de uso de sistema, e a modelagem das entidades do sistema permitiuidentificar três grandes produtos.

A DPN – Descrição dos Processos de Negócio – foi gerada automaticamente apartir do MPN com o uso de uma ferramenta de geração automática de documentação.Toda a informação levantada era registrada no próprio modelo ou anexada ao mesmo ereferenciada por meio de apontadores. Essa forma de documentação trouxe váriosbenefícios para a equipe de analistas, já que todos concentraram seus esforços em umúnico artefato de trabalho. Isso também possibilitou minimizar a duplicação deinformação em vários artefatos, e gerar o documento a ser entregue ao cliente de formarápida e eficiente.

Um ponto importante a ressaltar foi a necessidade de se fazer alguns ajustes noprocesso proposto (descrito na seção 3) ao longo da execução dos trabalhos. Durante amodelagem de processos de negócio, percebeu-se que o principal interesse do cliente eradocumentar a execução interna de seus processos. A interação desses processos com osatores de negócio, na maioria dos casos, não era relevante ou até mesmo não existia.Neste caso, a descrição dos fluxos dos processos de negócios sob uma perspectivaexterna, sugerida pelo processo como parte da descrição dos casos de uso de negócio,não seria representativa. Optou-se então por documentar os processos de negócio apenassob uma perspectiva interna, por meio das realizações.

Outra alteração significativa foi a forma de documentar as realizações: o uso dediagramas de interação para a realização dos casos de uso [Ng 2003] foi substituído pelouso de diagramas de atividades da UML. Cada informação contida nos diagramas deinteração foi mapeada diretamente para os diagramas de atividades: os agentes denegócio foram representados por raias e a interação dos agentes de negócio com asentidades de negócio foi indicada por meio do fluxo de objetos (conforme apresentadona Figura 3). A opção por representar as realizações por meio de diagramas deatividades – ao invés dos diagramas de interação previstos originalmente no processo –se deu por três motivos:

• Utilizando o mapeamento descrito, foi possível representar no diagrama deatividades toda a informação relevante que seria apresentada em um diagrama deinteração;

• A notação utilizada nos diagramas de atividades era mais acessível aosrepresentantes do cliente, devido à semelhança entre os diagramas de atividadese os fluxogramas utilizados pelos usuários para documentar informalmente seusprocessos.

• A representação de desvios no fluxo pôde ser representada de uma forma maisclara e objetiva nos diagramas de atividades.

185



Recebimento de solicitação de convênio/subvenção

Anulação de crédito orçamentário

Agendamento de pagamento

: Solici tação de convênio/subvenção

: Anulação orçamentária

Registro de convênio/subvenção

: Convênio/Subvenção

Registro de transferência financeira

: Transferência financeira bancária

Arquivamento do processo

: Cronograma de pagamento

[Atualizado]

: Contador : Tesoureiro : Gestor de contratos : Responsável p or custos e orçamentos

Agentes de negócio

Entidades de negócio

Figura 3. Exemplo de realização de caso de uso de negócio por meio dediagrama de atividades, destacando os agentes e as entidades de negócio

5. Resultados obtidos

A aplicação da modelagem de processos de negócio trouxe resultados bastantepositivos. A execução dessa etapa antes da realização do levantamento dos requisitos dosistema foi um fator de redução de riscos, tanto para o cliente quanto para o fornecedor.O cliente pôde ter uma visão melhor do seu negócio, identificando as áreas querealmente seriam beneficiadas pela construção do sistema, evitando assim o desperdíciode recursos. Foi interessante observar que, durante as oficinas, o cliente pôde perceberque determinados processos não estavam sendo executados da melhor forma. Diante

186



desta percepção, alguns processos foram remodelados, evitando que o sistema fosseconstruído sobre uma base operacional deficiente.

Para o fornecedor, a execução da modelagem de processos de negócio resultouem maior facilidade na gestão dos requisitos do sistema. Muitas das constantesmudanças que ocorrem durante o desenvolvimento de um sistema decorrem dainexistência de um consenso entre os representantes do cliente sobre a melhor forma dese executar um processo. A modelagem de processos de negócio fez com que esseconsenso fosse alcançado antes do início do levantamento dos requisitos do sistema,tornando esta etapa mais eficiente.

A identificação dos casos de uso do sistema também foi bastante facilitada.Como passaram a conhecer melhor a realidade do cliente, os engenheiros de requisitospuderam ser mais pró-ativos nesta atividade, contribuindo com sugestões e ponderaçõesbaseadas em conhecimento mais sólido. Esta pró-atividade mostrou-se especialmenteútil nas primeiras oficinas, já que naquele momento os representantes do cliente aindanão estavam totalmente seguros com a metodologia de levantamento dos requisitos.

Outro benefício trazido pela modelagem de processos de negócio diz respeito àrastreabilidade dos requisitos. Uma característica de qualidade importante para umaespecificação de requisitos é a facilidade em se determinar os resultados dodesenvolvimento que serão afetados por cada requisito (rastreabilidade para frente), bemcomo a origem de cada um (rastreabilidade para trás) [Paula 2003] [Daves 1993]. Comoos requisitos foram derivados diretamente do Modelo de Processos de Negócio, arastreabilidade para trás foi garantida documentando-se, para cada requisito, o processode negócio que o gerou.

Um ponto importante no desenvolvimento de um sistema, especialmente quandoseu porte não é pequeno, é a sua divisão em produtos. A divisão é uma maneira formalde se exercitar o desenvolvimento incremental, já que produtos coesos e de menor portesão entregues em menor tempo do que um único módulo que contemple todas asfunções. Isto é importante tanto do ponto de vista técnico quanto do de negócio, já quemuitas vezes o cliente não dispõe de recursos para construir todo o sistema de uma sóvez, e a priorização de requisitos dentro de um módulo único não é uma tarefa simples.Esse foi também um ponto em que a modelagem de processos de negócio foi benéfica.Antes de sua realização, cliente e fornecedor imaginavam que o sistema seria compostopor três produtos. Após a modelagem, percebeu-se que o número de produtos erarealmente três, mas a composição dos mesmos foi bastante modificada. Dois dosprodutos foram agrupados em um único, e um produto de controle de fluxo de trabalho(workflow) foi identificado. Apenas um produto permaneceu conforme tinha sidoconcebido no início.

A divisão inicial dos produtos espelhava a divisão funcional da empresa, o quenão se mostrou uma boa idéia do ponto de vista de sistemas. A modelagem de processosde negócio fez com que cliente e fornecedor percebessem que duas das áreas eram muitointegradas, o que justificaria um único produto para atendê-las. Da mesma forma, oproblema de controle de fluxo de trabalho era comum a todas as áreas funcionais, o quejustificaria um produto genérico para este fim, e não a inserção de funcionalidadescorrelatas em um dos produtos específicos para determinada área.

187



Após a divisão dos produtos, um deles foi escolhido para ser especificado econstruído. Seria necessário, portanto, realizar uma estimativa do tamanho do produtoem pontos de função, para orçar-se a fase de Elaboração. O melhor conhecimento daorganização, conseguido por meio da modelagem de processos de negócio, também foifundamental para que essa estimativa fosse bem próxima da contagem oficial de pontosde função, realizada alguns meses depois (após o fim da Elaboração). Percebeu-seinclusive que a aproximação do número real foi maior do que em projetos em que amodelagem de processos de negócio não foi usada.

Como último resultado importante, podemos citar o artefato resultante damodelagem de processos de negócio. Esse documento é importante para o cliente, já queé a documentação dos processos da organização. Mas também do ponto de vista dofornecedor o documento foi de grande utilidade, pois serviu para dar uma visão geral àspessoas que entravam no projeto depois de seu início. Foi uma forma simples e baratade integrar novas pessoas à equipe.

6. Conclusão

De posse dos resultados obtidos com a modelagem de processos de negócio pôde-seconfirmar a grande vantagem em se utilizar esta técnica em uma organização.

A modelagem de processos de negócio ajudou a estabelecer algumas estratégiaspara a especificação de um sistema informatizado, principalmente quanto ao escopo e àdivisão do sistema em produtos candidatos.

O entendimento mútuo do negócio entre cliente e fornecedor favoreceu umtrabalho de maior parceria. Esse entendimento possibilitou ao fornecedor maior poderpara propor otimizações ao negócio através de um sistema, diminuindo-se o risco deembutir no sistema vícios que normalmente estão arraigados às praticas dos processosde negócio de qualquer organização.

Além dos resultados já identificados, pôde-se concluir que a aplicação damodelagem de processos de negócio é um processo que gera benefícios por si só,independentemente da construção posterior de um sistema de software. Através da delafoi possível contextualizar a situação atual do negócio da organização assim comoidentificar seus problemas atuais. A partir dessa identificação foi possível oferecer aocliente um conjunto de sugestões de melhorias à execução de seus processos quepuderam ser incorporadas imediatamente ao seu dia a dia, antes mesmo da construçãodos sistemas de software identificados. O cliente sentiu-se mais seguro em saber quepoderia optar por não especificar e não construir o sistema se ao final do projetoconcluísse que essa era a melhor decisão. E isso não implicaria perda de recursos, já queteria sido realizado um importante trabalho de documentação e reengenharia deprocessos.

O produto final da modelagem de processos de negócio pôde ser comercializadocomo um produto/serviço à parte, o que trouxe maior conforto para o cliente e tornou asnegociações comerciais mais fáceis.

188



Referências bibliográficas

Aguilar-Saven, R., 2001. “Business process modelling techniques and tools”.Department of Production Economics. WP291, Linköping Sweden.

Baker, B. (2001). “Business Modeling with UML: The Light at the End of the Tunnel”,In: The Rational Edge, December/2001.http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/archives/dec01.html

Daves, A. (1993) “Software Requirements: Objects, Functions and States”. PrenticeHall, 1993.

Eriksson, H. and Penker, M. “Business Modeling with UML: Business patterns atwork”, John Wiley & Sons ltd., USA, 2000.

Holt, A. et al., 1983. “Coordination systems technology as a programmingenvironment”. Electrical Communication 57 (4),307 –314.

IDEF (2003). IDEF Family of Methods web page: http://www.idef.com.

Lakin, R. et al., 1996. “BPR enabling software for the •nancial services industry”.Management services, ISSN:0307-6768.

McConnell, S. “Rapid Development”. Microsoft Press, 1996.

Ng, Pan-Wei (2003). “Effective business modeling with UML: Describing business usecases and realizations”,http://www-106.ibm.com/developerworks/rational/library/905.html

Paula Filho, W. P. (2003) “Engenharia de software; fundamentos, métodos e padrões,2.ed.”, Rio de Janeiro: Editora LTC.

Rumbaugh, J., Jacobson, I. and Booch, Grady (1999). “Unified Modeling LanguageReference Manual”, Addison Wesley, 1999.

Technology

Mpn apoio requisitos_sistema 2