Mpn apoio requisitos_sistema 2

VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004
Melhoria de Processos de Software www.simpros.com.br

Um estudo de aplicação de modelagem de processo de
negó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 without
contextualizing the real problem of the organization, or with a poor
understanding of its needs. By modeling the business processes it is possible to
achieve a better comprehension of the environment in which the system will be
used, thus facilitating the identification and analysis of its requirements. This
work describes the application of business modeling techniques as an input to
produce a system specification for a public institution of the state of Minas
Gerais, Brazil, describing the process used and presenting the results
achieved.

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

1. Introdução
O sucesso de uma organização está condicionado à eficácia com que os seus processos
de negócio são executados. Um sistema informatizado desenvolvido para dar suporte a
uma 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 que
haja real entendimento das necessidades e problemas da organização. Por meio das
técnicas de modelagem de processos de negócio, é possível compreender melhor o
ambiente no qual o sistema a ser construído irá funcionar, o que possibilita identificar
requisitos correspondentes às reais necessidades do negócio [Baker 2001].
Modelos de negócio podem trazer vários benefícios no contexto do
desenvolvimento de sistemas de software [Eriksson and Penker 2000]:

177


• Contribuem para que os requisitos sejam completos e reflitam as necessidades de
negócio;
• Evitam a tomada de decisões prematuras;
• Permitem que os sistemas desenvolvidos sejam guiados pelo negócio, e não
simplesmente pela tecnologia;
• Permitem um melhor planejamento da integração dos diferentes componentes do
sistema;
• 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, como
elas são estruturadas, e como interagem para prover as funções oferecidas a seus
clientes. Há várias notações propostas na literatura para esse fim, das quais podemos
destacar: 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 os
métodos IDEF [IDEF 2003].
O trabalho aqui descrito se baseia em uma experiência de aplicação das técnicas
de 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. A
seção 2 apresenta a contextualização do projeto em que tais técnicas foram aplicadas. A
seção 3 descreve o processo criado para guiar as atividades de modelagem, e a execução
do mesmo é descrita na seção 4. Finalmente, a seção 5 expõe os resultados obtidos, e as
conclusõ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ção
pública do estado de Minas Gerais - uma solução de informatização para seus processos
internos, permitindo a integração entre suas áreas.
Com esse propósito o fornecedor necessitava compreender a estrutura e a
dinâmica da organização, levantar os problemas atuais, identificar oportunidades de
melhoria e promover o entendimento comum quanto à situação desejada para a
organização. Somente após esse trabalho poderiam ser identificados os requisitos para o
sistema de software que ofereceria suporte à organização.
Para a realização das atividades citadas acima o fornecedor optou pelo uso de
técnicas de modelagem de processos de negócio, conforme descrito na seção 3. Para
fornecer as informações necessárias à modelagem, o cliente disponibilizou
representantes com conhecimento do processo e poder de decisão, visto que não havia
documentação dos processos em uso.
Desde o início do trabalho, com a ajuda do fornecedor, puderam os
representantes do cliente destacar alguns dos problemas que viviam, como: a lentidão de
vários processos executados manualmente, inclusive transferência de informações entre
sistemas; o retrabalho; o consumo excessivo de papel e conseqüente acúmulo de
documentos em arquivos físicos; e a descentralização, replicação e inconsistência de
dados.

178


Foram considerados dentro do escopo do trabalho somente processos internos da
organização, ficando adiado o tratamento de processos que envolvem a participação de
agentes 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 de
modelagem UML. A decisão por utilizar essa notação apoiou-se no fato de que ela, além
de utilizar diagramas simples o suficiente para serem compreendidos por clientes e
usuários, é a mesma empregada na modelagem de software - o que facilitaria
posteriormente o entendimento pelos desenvolvedores do sistema.
Apesar de estarem mais voltados à representação de conceitos de sistemas de
software orientados a objetos, os diagramas da UML podem ser empregados também
para descrever processos de negócio. Para isso alguns perfis (conjuntos de convenções
de 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 no
projeto.
O conceito central para a modelagem dos processos de negócio através da
notação escolhida é o de caso de uso de negócio, que representa uma seqüência de
ações executadas durante a realização de um processo de negócio. Os processos
representados pelos casos de uso de negócio geralmente produzem valor para algum
cliente da organização; esses clientes são modelados por meio dos atores de negócio. O
modelo de processos de negócio é então formado por um conjunto de casos de uso, cada
um representando um processo de negócio voltado para um cliente.
Para documentar um processo de negócio o modelo apresenta duas visões, uma
externa e outra interna. A primeira é feita através da descrição dos casos de uso, que
consiste 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 meio
de descrições textuais (para processos mais simples) ou por diagramas de atividades, em
notação UML. A visão interna é modelada através da realização dos casos de uso, que
detalha como os agentes de negócio (funcionários ou sistemas informatizados
existentes na organização) interagem entre si e como as entidades de negócio (recursos
fí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 ou
restringem aspectos do negócio, para satisfazer a requisitos externos (leis, restrições
impostas por outros negócios, etc), e para garantir que os objetivos de cada processo
sejam alcançados de forma segura. Tais regras de negócio aparecem no modelo
associadas a casos de uso, entidades e/ou agentes de negócio.
A Figura 1 apresenta os elementos que compõem o modelo de processos de
negócio, através de um diagrama de classes. A Tabela 1 descreve esses elementos e
indica a representação UML de cada um.

179


Modelo de Negócio

1

< rege 0..* Regra de negócio

1..n 0..* 0..* 0..*
aciona > Caso de uso de neg óc io 1..n m ni pu la >
a
1..n

1..n
/ rege / rege
/ é responsável por

1 1..n 0..*
Ator de negócio Agente de negócio Entidade de negócio
0..*

0..*

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 de
processos de negócio

Elemento Descrição Representação no perfil Notação icônica
de modelagem de
[Ng 2003]
negócios
Caso de uso de Representação de um processo Caso de uso
negócio de negócio que gera valor para estereotipado como
algum cliente externo à «business use case»
organização.
Ator de negócio Papel desempenhado em Ator estereotipado como
relação ao negócio por alguém «business actor»
ou alguma coisa no ambiente
de negócio.
Agente de Agente humano ou informático Classe estereotipada
negócio que atua internamente no como «business worker»
negócio durante a realização de
casos de uso, interagindo com
outros agentes de negócio e/ou
manipulando entidades de
negócio.
Entidade de Recurso físico, abstrato ou de Classe estereotipada
negócio informação, utilizado ou como «business entity»
produzido nos processos de
negócio.
Regra de negócio Regra que define ou restringe Não foi utilizada uma
aspectos do negócio, com o representação direta na
objetivo de satisfazer a UML para regras de
requisitos externos (leis, negócio. As mesmas
-
restrições impostas por outros vêm descritas como
negócios, etc) e de garantir que restrições, anotações ou
os objetivos sejam alcançados descrições textuais.
de forma segura.

180


3.2. Organização das atividades
Para guiar as atividades realizadas durante a modelagem dos processos de negócio da
organização foi definido um processo a ser seguido e um conjunto de artefatos a serem
gerados. A Figura 2 apresenta uma visão geral desse processo.
Após uma etapa inicial de definição de escopo e contexto (representada pelas
trê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ócio
conté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és
de diagramas de atividades, em notação UML.
• Descrição das atividades: descrição textual de cada atividade apresentada nos
diagramas de atividades.
• Problemas conhecidos: lista dos problemas identificados no processo de negócio
representado pelo caso de uso.
• Possibilidades de melhoria: lista das possibilidades de melhoria identificadas
para o processo de negócio representado pelo caso de uso.
• Regras de negócio: descrição detalhada das regras de negócio que regem o
processo 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. A
modelagem de processos de negócio contempla não só a documentação dos processos a
serem informatizados, mas também a sua melhoria. Durante a descrição de um caso de
uso de negócio, eventuais problemas conhecidos quanto à realização do processo que ele
representa 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 dificuldade
de acesso à informação tratada costumam ser problemas recorrentes. Tais possibilidades
são avaliadas e, se aprovadas, incorporadas ao modelo.
Na medida em que os casos de uso são descritos, os principais conceitos
envolvidos e os recursos utilizados ou produzidos por cada processo vão sendo
identificados e modelados como entidades de negócio, formando o “Modelo de
domí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, o
próximo passo é documentar a realização dos casos de uso, descrevendo como os
agentes 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 representado
em cada caso de uso.

181


Início da Modelagem de
Processos de Negócio

Verificação do
negócio atual

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

Levantamento e
MPN - descrição do
descrição do contexto
contexto

Identificação dos casos de MPN - atores e casos
uso de negócio de uso de negóci o

MPN - descrições Detalhamento dos casos Modelagem das M PN - model o de
dos casos de uso de uso de negócio entidades de negócio domínio

Realização dos c asos
de uso de negóci o MPN - agentes de
negócio

MPN -
realizações
MPN Geração da DPN
DPN

Revi s dos
ão Realização de ajustes e
artefatos correções identificados

M odelagem de processos de [ Não ]
negócio aprovada?
[ Sim ]

Fim da Modelagem de
Processos de Negócio

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

Concluindo-se a visão de casos de uso (descrições e realizações de todos os
casos de uso de negócio) e o modelo de domínio, tem-se o Modelo de Processos de
Negócio (MPN) completo. O próximo passo é gerar uma versão desse modelo em
formato 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 de
processos de negócio. Caso sejam detectados defeitos na documentação gerada durante
a revisão, as devidas correções são providenciadas antes da aprovação final.

182


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

Atividade Descrição Resultados
Verificação do Levantamento da visão geral do negócio a -
negócio atual ser modelado.
Definição do escopo Definição dos domínios de negócio a serem Documento textual que descreve de
da modelagem de abordados na modelagem de processos de forma precisa o escopo do modelo
negócio negócio. de negócio.
Levantamento e Descrição em linhas gerais do negócio como Documento textual contendo a
descrição do um todo, apresentando o contexto em que os descrição geral do contexto.
contexto processos de negócio estão inseridos.
Identificação dos Levantamento dos casos de uso de negócio e Diagrama de casos de uso de
casos de uso de dos atores envolvidos em cada processo. negócio.
negócio
Detalhamento dos Descrição do fluxo do processo de negócio e Diagramas de atividades com a
casos de uso de identificação de problemas conhecidos, descrição dos fluxos dos processos;
negócio possibilidades de melhoria e regras de documentação de casos de uso
negócio aplicáveis. contendo descrição das atividades,
problemas conhecidos e
possibilidades de melhoria.
Modelagem das Identificação das entidades de negócio Diagramas de classes com as
entidades de negócio manipuladas nos casos de uso e dos entidades do negócio e as
relacionamentos entre elas. respectivas descrições, compondo o
Modelo de Domínio.
Realização dos casos Descrição das realizações dos casos de uso Diagramas de interação, detalhando
de uso de negócio de negócio por meio de diagramas de como os processos são realizados
colaboração ou diagramas de seqüência. internamente na organização.
Geração da DPN Geração da Descrição de Processos de Versão documental do Modelo de
Negócio, a partir do Modelo de Processos de Processos de Negócio, denominada
Negócio. Descrição de Processos de Negócio.
Revisão dos Revisão pelo cliente da documentação Relatório de revisão contendo os
artefatos produzida, realizada como critério de defeitos detectados e o resultado
aprovação. (aprovação ou reprovação).
Realização de Correções e ajustes identificados na revisão Versão atualizada do Modelo de
ajustes e correções dos artefatos. Processos de Negócio e da
identificados Descriçã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. Os
artefatos produzidos na modelagem de negócio são utilizados como insumo para a
identificação dos requisitos do sistema.

4. Execução do processo
Para confeccionar o MPN foi realizado um conjunto de oficinas, baseadas em técnicas
de Joint Application Development (JAD [McConnell96]).

183


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 o
envolvimento de 18 dos 29 setores da organização. Foram documentadas 183 atividades
e identificadas 101 entidades de negócio. A partir dos casos de uso de negócio foram
derivados 64 casos de uso de sistema, e a modelagem das entidades do sistema permitiu
identificar três grandes produtos.
A DPN – Descrição dos Processos de Negócio – foi gerada automaticamente a
partir 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 e
referenciada por meio de apontadores. Essa forma de documentação trouxe vários
benefí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 de
informação em vários artefatos, e gerar o documento a ser entregue ao cliente de forma
rápida e eficiente.
Um ponto importante a ressaltar foi a necessidade de se fazer alguns ajustes no
processo proposto (descrito na seção 3) ao longo da execução dos trabalhos. Durante a
modelagem de processos de negócio, percebeu-se que o principal interesse do cliente era
documentar a execução interna de seus processos. A interação desses processos com os
atores 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 perspectiva
externa, 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 apenas
sob uma perspectiva interna, por meio das realizações.
Outra alteração significativa foi a forma de documentar as realizações: o uso de
diagramas de interação para a realização dos casos de uso [Ng 2003] foi substituído pelo
uso de diagramas de atividades da UML. Cada informação contida nos diagramas de
interação foi mapeada diretamente para os diagramas de atividades: os agentes de
negócio foram representados por raias e a interação dos agentes de negócio com as
entidades de negócio foi indicada por meio do fluxo de objetos (conforme apresentado
na Figura 3). A opção por representar as realizações por meio de diagramas de
atividades – 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 de
atividades toda a informação relevante que seria apresentada em um diagrama de
interação;
• A notação utilizada nos diagramas de atividades era mais acessível aos
representantes do cliente, devido à semelhança entre os diagramas de atividades
e os fluxogramas utilizados pelos usuários para documentar informalmente seus
processos.
• A representação de desvios no fluxo pôde ser representada de uma forma mais
clara e objetiva nos diagramas de atividades.

184


Agentes de negócio

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

: Solicitação de
convênio/subvenção

Recebimento de solicitação Entidades de negócio
de convênio/subvenção

Registro de
convênio/subvenção

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

: Anulação :
orçamentária Convênio/Subvenção

: Cronograma
Agendamento
de pagamento
de pagamento
[Atualizado]

Registro de transferência
financeira

Arquivamento
: Transferência
do processo
financeira bancária

Figura 3. Exemplo de realização de caso de uso de negócio por meio de
diagrama 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 bastante
positivos. A execução dessa etapa antes da realização do levantamento dos requisitos do
sistema 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 que
realmente seriam beneficiadas pela construção do sistema, evitando assim o desperdício
de recursos. Foi interessante observar que, durante as oficinas, o cliente pôde perceber
que determinados processos não estavam sendo executados da melhor forma. Diante

185


desta percepção, alguns processos foram remodelados, evitando que o sistema fosse
construído sobre uma base operacional deficiente.
Para o fornecedor, a execução da modelagem de processos de negócio resultou
em maior facilidade na gestão dos requisitos do sistema. Muitas das constantes
mudanças que ocorrem durante o desenvolvimento de um sistema decorrem da
inexistência de um consenso entre os representantes do cliente sobre a melhor forma de
se executar um processo. A modelagem de processos de negócio fez com que esse
consenso 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 requisitos
puderam ser mais pró-ativos nesta atividade, contribuindo com sugestões e ponderações
baseadas em conhecimento mais sólido. Esta pró-atividade mostrou-se especialmente
útil nas primeiras oficinas, já que naquele momento os representantes do cliente ainda
nã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 uma
especificação de requisitos é a facilidade em se determinar os resultados do
desenvolvimento que serão afetados por cada requisito (rastreabilidade para frente), bem
como a origem de cada um (rastreabilidade para trás) [Paula 2003] [Daves 1993]. Como
os requisitos foram derivados diretamente do Modelo de Processos de Negócio, a
rastreabilidade para trás foi garantida documentando-se, para cada requisito, o processo
de negócio que o gerou.
Um ponto importante no desenvolvimento de um sistema, especialmente quando
seu porte não é pequeno, é a sua divisão em produtos. A divisão é uma maneira formal
de se exercitar o desenvolvimento incremental, já que produtos coesos e de menor porte
são entregues em menor tempo do que um único módulo que contemple todas as
funções. Isto é importante tanto do ponto de vista técnico quanto do de negócio, já que
muitas 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 composto
por três produtos. Após a modelagem, percebeu-se que o número de produtos era
realmente três, mas a composição dos mesmos foi bastante modificada. Dois dos
produtos foram agrupados em um único, e um produto de controle de fluxo de trabalho
(workflow) foi identificado. Apenas um produto permaneceu conforme tinha sido
concebido no início.
A divisão inicial dos produtos espelhava a divisão funcional da empresa, o que
não se mostrou uma boa idéia do ponto de vista de sistemas. A modelagem de processos
de negócio fez com que cliente e fornecedor percebessem que duas das áreas eram muito
integradas, o que justificaria um único produto para atendê-las. Da mesma forma, o
problema de controle de fluxo de trabalho era comum a todas as áreas funcionais, o que
justificaria um produto genérico para este fim, e não a inserção de funcionalidades
correlatas em um dos produtos específicos para determinada área.

186


Após a divisão dos produtos, um deles foi escolhido para ser especificado e
construído. Seria necessário, portanto, realizar uma estimativa do tamanho do produto
em pontos de função, para orçar-se a fase de Elaboração. O melhor conhecimento da
organização, conseguido por meio da modelagem de processos de negócio, também foi
fundamental para que essa estimativa fosse bem próxima da contagem oficial de pontos
de função, realizada alguns meses depois (após o fim da Elaboração). Percebeu-se
inclusive que a aproximação do número real foi maior do que em projetos em que a
modelagem de processos de negócio não foi usada.
Como último resultado importante, podemos citar o artefato resultante da
modelagem 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 do
fornecedor o documento foi de grande utilidade, pois serviu para dar uma visão geral às
pessoas que entravam no projeto depois de seu início. Foi uma forma simples e barata
de integrar novas pessoas à equipe.

6. Conclusão
De posse dos resultados obtidos com a modelagem de processos de negócio pôde-se
confirmar 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égias
para 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 um
trabalho de maior parceria. Esse entendimento possibilitou ao fornecedor maior poder
para propor otimizações ao negócio através de um sistema, diminuindo-se o risco de
embutir no sistema vícios que normalmente estão arraigados às praticas dos processos
de negócio de qualquer organização.
Além dos resultados já identificados, pôde-se concluir que a aplicação da
modelagem 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 dela
foi possível contextualizar a situação atual do negócio da organização assim como
identificar seus problemas atuais. A partir dessa identificação foi possível oferecer ao
cliente um conjunto de sugestões de melhorias à execução de seus processos que
puderam ser incorporadas imediatamente ao seu dia a dia, antes mesmo da construção
dos sistemas de software identificados. O cliente sentiu-se mais seguro em saber que
poderia optar por não especificar e não construir o sistema se ao final do projeto
concluísse que essa era a melhor decisão. E isso não implicaria perda de recursos, já que
teria sido realizado um importante trabalho de documentação e reengenharia de
processos.
O produto final da modelagem de processos de negócio pôde ser comercializado
como um produto/serviço à parte, o que trouxe maior conforto para o cliente e tornou as
negociações comerciais mais fáceis.

187


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”. Prentice
Hall, 1993.
Eriksson, H. and Penker, M. “Business Modeling with UML: Business patterns at
work”, John Wiley & Sons ltd., USA, 2000.
Holt, A. et al., 1983. “Coordination systems technology as a programming
environment”. 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 use
cases 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 Language
Reference Manual”, Addison Wesley, 1999.

188

Mpn apoio requisitos_sistema 2

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Mpn apoio requisitos_sistema 2

Mais de gtiprotec

Mpn apoio requisitos_sistema 2