Mpn apoio requisitos_sistema 2
Upcoming SlideShare
Loading in...5
×
 

Mpn apoio requisitos_sistema 2

on

  • 534 views

 

Statistics

Views

Total Views
534
Views on SlideShare
534
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mpn apoio requisitos_sistema 2 Mpn apoio requisitos_sistema 2 Document Transcript

  • 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çãoO 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]: 177
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br • 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, 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 projetoO 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. 178
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br 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 adotado3.1. Organização do modelo de processos de negócioO 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. 179
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br 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óciosCaso de uso de Representação de um processo Caso de usonegó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 estereotipadanegó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 estereotipadanegó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
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br3.2. Organização das atividadesPara 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é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. 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. 181
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br 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 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. 182
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br Tabela 2. Resultados das atividades realizadas durante a modelagem dos processos de negócio da organizaçãoAtividade Descrição ResultadosVerificaçã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 deda modelagem de abordados na modelagem de processos de forma precisa o escopo do modelonegócio negócio. de negócio.Levantamento e Descrição em linhas gerais do negócio como Documento textual contendo adescriçã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 decasos de uso de dos atores envolvidos em cada processo. negócio.negócioDetalhamento dos Descrição do fluxo do processo de negócio e Diagramas de atividades com acasos 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 asentidades 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, detalhandode 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 osartefatos 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 deajustes e correções dos artefatos. Processos de Negócio e daidentificados 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. Osartefatos produzidos na modelagem de negócio são utilizados como insumo para aidentificação dos requisitos do sistema.4. Execução do processoPara confeccionar o MPN foi realizado um conjunto de oficinas, baseadas em técnicasde Joint Application Development (JAD [McConnell96]). 183
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br 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 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
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br 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ócio5. Resultados obtidosA 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 185
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.brdesta 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. 186
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.br 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ãoDe 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. 187
  • VI Simpósio Internacional de São Paulo, SP – Brasil 24-26/11/2004 Melhoria de Processos de Software www.simpros.com.brReferências bibliográficasAguilar-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.htmlDaves, 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.htmlPaula 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